1

Make vs. Buy

The purpose of this section is not to make a firm recommendation as to whether to recommend COTS or bespoke packages, but rather to discuss the pros and cons of each option against a set of criteria and various parameters

Sources: D. Bhatia and A. Hashim documents; IFMIS Roundtable Documents; other consultant reports.

2

Criteria to be considered

• 1. The required ‘richness’ of the functionality and need for integration with other systems

• 2. The volatility of the functional requirements

• 3. The client organization’s capacity for software engineering and maintenance

• 4. Client maturity in defining its needs and processes

3

The Selected Parameters

Development Period Functionality Compliance with BPR Total Cost of Ownership (TCO) Intellectual Property Rights (IPR) Maintenance and Upgrades

FlexibilityIntegration with other systems and modules

Performance and Quality Documentation and Training Software Evaluation Legal Redress

4

Parameter: Development Period

• COTSDependent on degree of

customization agreed upon by vendor and client, but deployment can be quicker; still must add in time for contract negotiations

Many packages available commercially and users can get demos and information about them quickly

Best for enterprise wide installations

• Custom6 to 12 months for large

applications (or longer depending on the complexity of the application )

Team has to ‘invent a lot of wheels’, duplicating effort

Must start with high level conceptual design and requires top notch technical and PM expertise

Dependence on IT team is very high and difficult to ensure continuity or retention of staff

CAN BE STEP ONE IN PROCESS TOWARDS EVENTUALLY USING COTS

5

Parameter: Functionality

• COTSGenerally comprehensive in both

business and technical functionality, vendor has experience with rollouts

High compliance with international standards including GAAP, best practice

Records and processes all transactions related to budget compilation and execution

Migration path from cash to accruals

• Custom

Client may only need certain modules and not an ERP

Anticipate a perfect fit with business functions

Can help org to firm up the requirements, but this is not the ideal way to do it

6

Parameter: Compliance with BPR

• COTSDepends on software

applications, average may range from 50% to 80%

Acts as a change agent for BPR

• CustomAlmost 100% agreement

with user processes and requirements

Unfortunately, will also conform to ‘bad’ processes

Implementation can be done incrementally so costs can be spread out

7

Parameter: TCO

• COTSBoth initial and recurrent

licensing costs are very high, at least for the first-tier ERP packages

Maintenance fees depend on the type of maintenance agreement

Clients ‘forced’ to accept upgrades if vendor refuses to support previous versions

• CustomNo licenses required

If the creation of an IT department is needed, then the cost can be higher.

Delayed implementation may lead to high costs

If only need a few modules, can be low cost option

8

Parameter: IPR

• COTSVendor owns source code,

including those developed during customization.

• CustomClient may own source

code, but is this really of value?

9

Parameter: Maintenance and Upgrades

• COTSMaintenance and upgrade is

more or less assured, but subject to payment of annual maintenance fees

Few vendors have int’l presence and capability to support apps in LDCs

Only top vendors have capability to respond to WB RFPs

• CustomMaintenance subject to

agreement with developer, or by client’s IT unit.

Upgrades not usually available and have to be separately contracted

Need assurance of available local expertise for enhancements to system

10

Parameter: Flexibility

• COTSLimited to the extent that the

vendor would allow but SW can accommodate substantial levels of functional and technical changes; this is a complex effort which large vendors with software development capacity can accommodate

• CustomHighly flexible, as required

by clientComplexity of engineering

effort increases with greater scope and it is difficult for client gov’ts to achieve good PM over long development period due to gov’t pay scales and incentive schemes

11

Parameter: Integration with other modules and systems

• COTSHigh because this is also in the

vendor’s interestUpdates will be available as

other 3rd party systems areProven experience with

integrationBetter chance of a common

database and possibility for creating BW

Must consider cost of retaining or converting data from legacy

• CustomLimited, but integration

parameters can be included in functional specifications and system design

However, as other systems evolve, new programming on custom solution will be required (forever)

Version control can be difficultCan transfer domain knowledge

built into legacy systemsWell suited for fragmented apps

but integration can be difficult

12

Parameter: Performance and Quality

• COTSStable, as it has been

installed previously and subjected to testing both in simulated and actual production environments

Conforms to industry best practice

Robust, field tested SW

Built in controls and audit trails

• CustomStill subject to rigorous

testing, even after full deployment

Needs continued trouble

shooting and debugging

13

Parameter: Documentation and Training

• COTSDocumentation can be of

high quality and is available for evaluation

Training packages are also readily available, often from 3rd parties, and can be undertaken at any time

• CustomDocumentation and training

are only available at the end of the development cycle

Few internal IT departments excel at producing documentation and training courses

14

Parameter: Software Evaluation

• COTSThe software can be

evaluated immediately

In most cases, the client can try the product before buying it or see an existing installation at another client organization

• CustomNo evaluation on the

software itself can be done until job is complete

No track record for the

product or 3rd party evaluation (Gartner)

15

Parameter: Legal Redress

• COTSAgreements usually contain

provisions that customized functionality is the responsibility of the client

Vendor assumes risk for the basic package and credibility of vendor is very important for future sales

• CustomAgreements contain

provisions that acceptance of the software functionality is decided by the client and disagreements are usually resolved in favor of the client

16

Bottom Line

• COTSCostly but you know what

you are getting; if meets 70%+ of requirements and if desired system is complex, and if customization is not expected to take a very long time, this is good choice.

• CustomProvided SW expertise

available or client has strong IT dep’t and does not need full blown ERP because limited functionality is required, this could be first step of two step transition if client budget is low.