1. 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. 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. 3 The Selected Parameters Development Period Functionality Compliance with BPR Total Cost of Ownership (TCO) Intellectual Property Rights (IPR) Maintenance and Upgrades Flexibility Integration with other systems and modules Performance and Quality Documentation and Training Software Evaluation Legal Redress

4. 4 Parameter: Development Period COTS Dependent 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 Custom 6 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. 5 Parameter: Functionality COTS Generally 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. 6 Parameter: Compliance with BPR COTS Depends on software applications, average may range from 50% to 80% Acts as a change agent for BPR Custom Almost 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. 7 Parameter: TCO COTS Both 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 Custom No 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. 8 Parameter: IPR COTS Vendor owns source code, including those developed during customization. Custom Client may own source code, but is this really of value?

9. 9 Parameter: Maintenance and Upgrades COTS Maintenance 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 Custom Maintenance 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. 10 Parameter: Flexibility COTS Limited 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 Custom Highly flexible, as required by client Complexity 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. 11 Parameter: Integration with other modules and systems COTS High because this is also in the vendor’s interest Updates will be available as other 3 rd party systems are Proven experience with integration Better chance of a common database and possibility for creating BW Must consider cost of retaining or converting data from legacy Custom Limited, 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 difficult Can transfer domain knowledge built into legacy systems Well suited for fragmented apps but integration can be difficult

12. 12 Parameter: Performance and Quality COTS Stable, 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 Custom Still subject to rigorous testing, even after full deployment Needs continued trouble shooting and debugging

13. 13 Parameter: Documentation and Training COTS Documentation can be of high quality and is available for evaluation Training packages are also readily available, often from 3 rd parties, and can be undertaken at any time Custom Documentation and training are only available at the end of the development cycle Few internal IT departments excel at producing documentation and training courses

14. 14 Parameter: Software Evaluation COTS The 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 Custom No evaluation on the software itself can be done until job is complete No track record for the product or 3 rd party evaluation (Gartner)

15. 15 Parameter: Legal Redress COTS Agreements 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 Custom Agreements contain provisions that acceptance of the software functionality is decided by the client and disagreements are usually resolved in favor of the client

16. 16 Bottom Line COTS Costly 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. Custom Provided 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.