Electronic Government Procurement Implementation Types: Options for Africa AUTHORS: Blandine Wu Chebili - World Bank Group Hunt La Cascia - World Bank Group François Collineau - CKS Consulting Arnaud Salomon - CKS Consulting Baptiste Calvet - CKS Consulting Yoann Moreau - SQUAD 2 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA © 2021 International Bank for Reconstruction and Development / The World Bank 1818 H Street NW, Washington DC 20433 Telephone: 202-473-1000; Internet: www.worldbank.org Some rights reserved. This work is a product of the staff of The World Bank with external contributions. The findings, interpretations, and conclusions expressed in this work do not necessarily reflect the views of The World Bank, its Board of Executive Directors, or the governments they represent. The World Bank does not guarantee the accuracy of the data included in this work. The boundaries, colors, denominations, and other information shown on any map in this work do not imply any judgment on the part of The World Bank concerning the legal status of any territory or the endorsement or acceptance of such boundaries. Nothing herein shall constitute or be considered to be a limitation upon or waiver of the privileges and immunities of The World Bank, all of which are specifically reserved. Rights and Permissions: This work is available under the Creative Commons Attribution 3.0 IGO license (CC BY 3.0 IGO), http:// creativecommons.org/licenses/by/3.0/igo. Under the Creative Commons Attribution license, you are free to copy, distribute, transmit, and adapt this work, including for commercial purposes, under the following conditions: Attribution—Please cite the work as follows: 2021. E-Procurement Implementation Type Report. Washington, DC: World Bank. Translations—If you create a translation of this work, please add the following disclaimer along with the attribution: This translation was not created by The World Bank and should not be considered an official World Bank translation. The World Bank shall not be liable for any content or error in this translation. Adaptations—If you create an adaptation of this work, please add the following disclaimer along with the attribution: This is an adaptation of an original work by The World Bank. Views and opinions expressed in the adaptation are the sole responsibility of the author or authors of the adaptation and are not endorsed by The World Bank. Third-party content—The World Bank does not necessarily own each component of the content contained within the work. The World Bank therefore does not warrant that the use of any third- party-owned individual component or part contained in the work will not infringe on the rights of those third parties. The risk of claims resulting from such infringement rests solely with you. If you wish to reuse a component of the work, it is your responsibility to determine whether permission is needed for that reuse and to obtain permission from the copyright owner. Examples of components can include, but are not limited to, tables, figures, or images. All queries on rights and licenses should be addressed to World Bank Publications, The World Bank Group, 1818 H Street NW, Washington, DC 20433, USA; e-mail: pubrights@worldbank.org. ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA I 3 Acknowledgments This report was authored by a World Bank team comprising Blandine Wu Chebili (Sr. Procurement Specialist, EPSPA) and Hunt La Cascia (Sr. Procurement Specialist, EPSPA), and team from CKS Consulting comprising François Collineau (Director Expert), Arnaud Salomon (Director Expert), Baptiste Calvet (Technology Expert) and from SQUAD company, Yoann Moreau (Security Expert). The report benefited from the inputs of the following World Bank colleagues who kindly agreed to serve as peer reviewers: Felipe Goya (Procurement Practice Manager, EAWRU), Anand Kumar Srivastava (Sr. Procurement Specialist, EAWRU), Knut J. Leipold (Lead Procurement Specialist, EAERU), and Khuram Farooq (Sr Financial Management Specialist, EPSPA). A special thanks to interview partners from the Government of Rwanda, Mauritius, Tunisia, Uganda and Ivory Coast, for sharing their experiences and insights. 4 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Table of Contents Acknowledgments................................................................................................................................................. 3 Acronyms............................................................................................................................................................... 7 Executive Summary............................................................................................................................................. 8 Context, objectives, and content of the study.................................................................................................. 9 The three implementation types...................................................................................................................... 9 State of the art in IT security.......................................................................................................................... 11 e-GP developers market survey..................................................................................................................... 11 Cost modeling................................................................................................................................................. 12 Benefit-Cost Ratio (BCR)............................................................................................................................... 14 Results of the Cost-Benefit Analysis (CBA)................................................................................................... 15 Chapter I - Context and definitions................................................................................................................... 19 Objectives of the study on e-GP implementation types................................................................................ 22 Chapter II - Overview of the different implementation types........................................................................ 24 2.1 Overview of information systems project characteristics....................................................................... 25 2.2. Custom development............................................................................................................................... 26 2.3. COTS......................................................................................................................................................... 30 2.4. SaaS......................................................................................................................................................... 34 2.5 The Open-Source Software option........................................................................................................... 38 2.6. Synthesis of the major differences between the three implementation modes................................... 38 2.7. Issues related to IT security when implanting an e-GP......................................................................... 39 Chapter III – Market Survey............................................................................................................................... 43 3.1. General presentation of the overall e-procurement market................................................................. 44 3.2. Presentation of the e-GP market............................................................................................................ 48 Chapter IV – Cost-Benefit Analysis................................................................................................................... 68 4.1. Custom, COTS, and SaaS Cost Models.................................................................................................. 69 4.2. BCR Analysis............................................................................................................................................ 76 4.3. Cost-Benefit Analysis (CBA).................................................................................................................... 78 4.4. Synthesis of the analysis......................................................................................................................... 93 Chapter V – Return on experience.................................................................................................................... 94 5.1. Presentation of the Case Study section.................................................................................................. 95 5.2. Case Study #1: Rwanda........................................................................................................................... 96 5.3. Case Study #2: Tunisia.......................................................................................................................... 101 5.4. Case Study #3: Uganda......................................................................................................................... 106 5.5. Case Study #4: Mauritius...................................................................................................................... 110 5.6. Case Study #5: Ivory Coast.................................................................................................................... 114 5.7. Nigerian States SaaS e-GP Framework Agreement............................................................................ 117 TABLE OF CONTENTS I 5 Conclusion......................................................................................................................................................... 118 References......................................................................................................................................................... 121 Appendix 1. Summary Sheet for each software developer.............................................................................. 125 Appendix 2. Market Survey Questionnaire........................................................................................................ 135 Appendix 3. Data Collection Matrix................................................................................................................... 142 Appendix 4. Fundamentals of IT security......................................................................................................... 145 Appendix 5. Top 10 Web Application Security Risks......................................................................................... 153 List of Figures Figure 1: The two main types of project methodology for Custom software development projects ��������������� 27 Figure 2: Typical COTS implementation process and planning......................................................................... 31 Figure 3: Typical SaaS implementation process and planning......................................................................... 35 Figure 4: Comparing the characteristics of the three implementation types.................................................. 39 Figure 5: e-Procurement suite developer market shares in 2019.................................................................... 45 Figure 6: Market general information................................................................................................................ 46 Figure 7: e-GP developers general information................................................................................................. 48 Figure 8: Developers mapping based on the analysis of the questionnaire/survey results............................. 50 Figure 9: Functional coverage, by feature and phase........................................................................................ 52 Figure 10: Solution types provided by the 18 suppliers that responded to the survey..................................... 53 Figure 11: Functional coverage by solution type................................................................................................ 54 Figure 12: Capacity to implement e-GP solution in Africa................................................................................ 55 Figure 13: Most frequent implementation phase repartition............................................................................ 56 Figure 14: implementation role distribution analysis........................................................................................ 57 Figure 15: Estimated implementation time per software developer type......................................................... 58 Figure 16: On-premises experience and acceptance of the surveyed software developers............................ 60 Figure 17: Data hosting: internal or external hosting....................................................................................... 61 Figure 18: Number of e-GP developers for each hosting services firm........................................................... 61 Figure 19: Number of e-GP developers for each hosting services firm........................................................... 62 Figure 20: Number of solution providers hosting data in each continent........................................................ 62 Figure 21: E-GP developers who have their applications audited annually...................................................... 64 Figure 22: Number of suppliers by financial model.......................................................................................... 65 Figure 25: Design & Build budget per implementation type............................................................................. 71 Figure 26: Impact of the cost drivers on the “Design & Build” budget............................................................. 72 Figure 27: Planning Design & Build per scenario............................................................................................. 73 Figure 28: Cumulative e-GP ownership costs over 5 years per implementation type..................................... 74 Figure 29: Project complexity per scope............................................................................................................ 75 Figure 30: Average duration of Custom / COTS projects (with high level of customization)............................ 80 6 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Figure 31: Average shift compared to the initial schedule................................................................................ 80 Figure 32: Achievement of original project objectives....................................................................................... 83 Figure 33: e-GP Case Study – Rwanda............................................................................................................... 96 Figure 34: UMUCYO project planning................................................................................................................. 97 Figure 35: Functional coverage of UMUCYO...................................................................................................... 98 Figure 36: UMUCYO supplier YouTube guide.................................................................................................... 100 Figure 37: e-GP case study – Tunisia............................................................................................................... 101 Figure 38: TUNEPS Project planning............................................................................................................... 102 Figure 39: TUNEPS functional coverage.......................................................................................................... 103 Figure 40: e-GP case study – Uganda.............................................................................................................. 106 Figure 41: EPP project planning....................................................................................................................... 107 Figure 42: EPS functional coverage.................................................................................................................. 108 Figure 43: e-GP Case study - Mauritius........................................................................................................... 110 Figure 44: EPS Project Planning...................................................................................................................... 111 Figure 45: EPS functional coverage.................................................................................................................. 112 Figure 46: e-GP case study - Ivory Coast......................................................................................................... 114 Figure 47: SIGOMAP project planning.............................................................................................................. 115 Figure 48: Top 10 application security risks (last version of the OWASP top 10 issued in 2017)................... 147 Figure 49: Steps with high security risks in an e-GP system.......................................................................... 151 ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA I 7 Acronyms BCR Benefits/costs ratio CAGR Compound Annual Growth Rate CBA Cost/Benefit Analysis CF Cash flows COTS Commercial off-the-Shelf D&B Design and Build e-GP electronic-Government Procurement EO Economic Operator EOI Expression of Interest ERP Enterprise Resource Planning GUI Graphical User Interface ICT Information and Communications Technology IPF Investment Project Financing IT Information Technology OCDS Open Contracting Data Standard P2P Procure-to-Pay PPP Public-Private Partnership PV Present value RFI Request for Information S2C Source-to-Contract SaaS Software-as-a-Service SLA Service Level-Agreement STP Source to Contract T&E Time and Expenses TCO Total Cost of Ownership WBG World Bank Group Executive Summary ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA I 9 Executive Summary Context, objectives, and content of the study In recent years, more and more African governments are looking to implement e-GP solutions to address some of the challenges associated with public procurement, such as: • Harmonizing internal processes to optimize their execution, • Increasing transparency and traceability, • Generating financial gains, • Facilitating access to public procurement for all economic actors. This study was motivated by the World Bank’s commitment to help African governments implement an e-GP solution that best meets their needs and constraints. For countries having and using already an e-GP system, this will help to enhance the development and updating of their system. The three implementation types The three implementation types presented in this paper can be described as follows: 1 Custom software designates solutions that have been developed specifically for the needs of a given organization and that are not packaged for resale. 2 COTS (Commercial-Off-The-Shelf) refers to a software acquired from a software developer or open source that is used as-is or with configuration, or that can be tailored with a layer of specific code layered on top of it. 3 SaaS (Software-as-a-Service) refers to software that is provided as a shared service made available over the web and that can be used as-is or with the addition of configuration without any specific coding. The main differences between the three implementation modes are: • Custom projects require more technical expertise and more resources than COTS/SaaS projects. • Custom projects are by far the most complex to handle. They require project leaders to have strong functional, technical, and information technology (IT) project management skills and their active participation in all development stages. • With Custom projects, the source code is owned by the customer, even if the development is entrusted to an IT company. On SaaS/COTS projects, the source code belongs to the software developer and the customer has no or limited access to it. 10 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA • With SaaS and COTS projects, the source code is based on feedback from multiple clients whereas the source code is personalized and tailored to the specific customer’s needs with a custom solution. • With Custom projects, management of hosting/data is under the customer’s responsibility which generally implements on-premises hosting. For COTS, the client can choose between on-premises and outsourced hosting and, for some cases, a mix of both hosting solutions. For SaaS projects, hosting is the responsibility of the software developer and, in most cases, hosting of the data is in the cloud. • With SaaS Projects, corrective/evolutive maintenance, help-desk support, and security controls are the responsibility of the software developer and/or its system integrator. All these activities are described in a Service Level Agreement (SLA). On Custom projects, all these activities are organized and managed by the customer who may rely on external providers, internal resources, or a mix of both for these activities. • With Custom projects, budgets are based on how much development efforts the project requires. With SaaS and COTS projects, the pricing model is based either on a subscription fee or user licenses and an implementation budget. To further assist practitioners, this report explains in detail the differences between the three types from an operational, technical, and contractual point of view, as presented below. Custom COTS SaaS Software System Software System Mix Key actors in build-design* Solution provider IT dept. developer integrator Mix developer integrator Mix Organization Software System Software System Mix Key actors in run Solution provider IT dept. developer integrator developer integrator Intensity of project ownership low med. high low med. high low med. high Code personalization low med. high low med. high low med. high Code limited full limited full limited full Code accessibility closed access access closed access access closed access access Vend. Gvt. Vend. Gvt. Vend. Gvt. On premise** Hosting and data security On premise** Off premise or off-premise Liabilities Maintenance Help-desk Application security n license tio ip Acquisition mode fix fee T&E license subscription cr bs su Source: Authors EXECUTIVE SUMMARY I 11 State of the art in IT security Discussions with the various representatives of the countries in Africa have highlighted the interest of making a synthesis of the issues, good practices in information systems security and the essential requirements to be included in the specifications of e-GP projects (whether they are Custom projects, COTS or Custom). This part clearly demonstrates that SaaS/COTS software developers deploy much more resources for application and data security than custom solutions. e-GP developers market survey By pooling the World Bank’s database and expert reviews, 60 software developers with the capacity to provide eProcurement solutions for the public sector have been surveyed. 18 of them responded to our detailed questionnaire. Three types of e-GP software developers were identified: 1 “Full-suite” developers, who offer suites covering the entire procurement process but are generally not very public sector oriented. 2 “Specialized” e-GP developer system developers, who specialize on the optimization of public procurement process. 3 “Niche” software developers, who focus their expertise on a very specific function, a part of the procurement process for which their application is recognized. Key findings of the market survey are the following: • The functional area which is best covered by software developers is the “pre-awarding” phase (e-Publishing, e-Tendering, and e-Evaluation modules). • The least well covered modules by the e-GP developer system developers are those related to the post-awarding phase, in particular the functionalities related to e-catalogues, e-signature, and e-complaints. • All respondents stated that they were able to deploy their solution in Africa. This, even though almost none of these software developers have offices on the African continent. • There is a relative diversity of organization models proposed by the software developers. Three main distributions of roles between software developers and their system integrators have been identified (“Full-Service Software developer,” “Developer Builds and system integrator Runs,” “Full-Service system Integrator”). • Only 15 percent of the software developers have their own data centers and offer to host the customer’s data directly on their premises. Most software developers rely on data hosting services providers. • On-premises hosting is not the model of choice for SaaS and COTS software developers, since the support they can offer to customers is generally of lower quality in this case. 66 percent of the respondents would agree to consider the on-premises option but only 44 percent of the software developers surveyed have already done it. • There is a relative diversity of pricing models. To ensure quality competition, governments must be able to include in the tender documents as many metrics as possible to enable all suppliers to produce a reliable costing. 12 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Cost modeling A cost model for the functional scope surveyed1 was built based on the data collected from the market survey at a global level and from enquiries to 54 African countries. Three project scenarios were considered; their budgets are shown below: 1 “Theoretical” scenario – a project without unforeseen and undesirable events. 2 “Use case” scenario, which includes a certain number of undesirable events. 3 “Worst case” scenario, which simulates a project with several difficulties/undesirable events. Total budget (Over a 5-year period) sensitivity to inductors (Budget Year N) Theoretical Use case Worst case 5000 4975 4500 4203 4000 to m Cus 3647 3643 3500 3367 C OT S 3242 3000 2916 2640 S aa S 2500 2467 Source: Authors 1. e-Procurement planning, e-Publication/Notification, e-Tendering, e-Evaluation/e-Awarding, e-Registration, Vendor manage- ment, Procurement Monitoring and Reporting. EXECUTIVE SUMMARY I 13 The following is a summary of the analysis of responses from the study. Custom COTS SaaS Time to market Project easiness Solution fit Benefits Interoperability Maintainability Security Sovereignty Total Cost of Ownership Costs Ease of budget mgt. Risks of failure High Moderate Low Source: Authors Based on the analysis, key conclusions are the following: • For the same functional scope, Custom projects require a higher budget than SaaS or COTS projects (up to 60 percent more expensive). This trend is visible in the design and build phases, as well as in the run. • In addition, Custom projects are more sensitive to cost inductors, and therefore more likely to drift from a budget perspective. • In terms of planning, Custom projects tend to last longer than COTS and SaaS projects, and their planning deviation is generally more significant. 14 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Benefit-Cost Ratio (BCR) The BCR ratio enables determining the attractiveness of an investment by dividing the present value of the expected benefits by the present value of the generated costs. If a project has a BCR greater than 1.0, the project is expected to deliver a positive net present value to a government. If a project’s BCR is less than 1.0, the project’s costs outweigh the benefits, and it should not be considered. Authors’ calculation of the Benefit-Cost Ratio shows that: • Investing in a Custom project is not attractive to “small” countries with a public procurement spending lower than US$1 billion. In the “Use case” scenario, the BCR is slightly below 1, which means that the country will struggle to recover the funds invested. Where significant difficulties are met during the Custom project (“worst case” scenario), the investment is not profitable at all. For these small countries, COTS projects do not appear to be very appropriate either. Only SaaS projects seem to provide a financial benefit in all scenarios for this group of country. Theoretical Use case Worst case Custom 1.26 0.94 0.59 COTS 1.57 1.37 1.05 SaaS 2.20 1.95 1.58 • For countries with public procurement spending of US$1,5 billion, all three implementation types represent an interesting investment in the “Use case” scenario. However, the SaaS scenario offers a return on investment twice as high as Custom projects and 42 percent higher than COTS projects. In addition, in the “Worst case” scenario, SaaS continues to offer a good return on investment and COTS projects a fair return, which is no longer the case for the Custom project. Theoretical Use case Worst case Custom 2.27 1.72 1.06 COTS 2.83 2.47 1.90 SaaS 3.96 3.51 2.84 • For countries with public procurement spending of US$3 billion, all three implementation types represent an interesting investment in the “Use case” scenario. However, the SaaS scenario offers a return on investment almost twice as high as Custom projects, and 38 percent higher than COTS projects. In addition, in the “Worst case” scenario, SaaS and COTS continues to offer a good return on investment, whereas return is lower for the Custom project. Theoretical Use case Worst case Custom 4.01 3.00 1.84 COTS 4.97 4.40 3.39 SaaS 6.84 6.02 4.53 EXECUTIVE SUMMARY I 15 Results of the Cost-Benefit Analysis (CBA) This section compares the benefits and drawbacks of the different implementation modes on the evaluation criteria below: Implementation Time The field study highlighted that the duration of the Design and Build phase for COTS – with high weight of customizations – and Custom projects is about 25 months. The complexity of these implementation types often causes project schedules to slip. Countries that have opted for these two types of implementations have seen a deviation of around 60 percent from the original schedule. SaaS and COTS project with low weight of customizations are faster if the procurement process has been conducted thoroughly. Our modeling leads to the conclusion that the planning for these implementation types is 9-13 months. Ease of project management from government perspective Custom projects with a high weight of customization are very demanding projects from the “customer” perspective. Project management teams start from scratch and usually do not draw on past experiences. They have to cover all the dimensions associated with the IT development process and additionally coordinate numerous stakeholders and expertise. Conversely, SaaS and COTS projects with limited customizations benefit from the simplification of a pre-packaged solution and the experience of deploying the application to numerous customers. There is less technical expertise required to mobilize and coordinate. Project management is therefore less caught up in technical issues and more focused on how to model the functional expectations in the modules of the chosen solution. Solution fit Solution fit is twofold: the ability to meet end-users’ requirements and the ease of use. In theory, the main attraction of Custom software and of COTS solutions with high level of customizations is that all requirements can be met. The survey of such projects already implemented in Africa shows that the governments did not get exactly what they wanted in the end. The difficulty of writing detailed functional specifications early in the development process and resource/technical constraints led to a situation where not all requirements were met. On their side, e-GP SaaS solutions meet most needs as over time they incorporate best practices from many public organizations into the product development to maximize customer satisfaction. However, certain specificity in the management rules or very specific processes will be more difficult to translate into the solution. Regarding ease of use, SaaS and COTS editors are engaged in a real race for a better “User Experience,” and they improve product usability based on the feedback of thousands of users. It is more difficult for Custom projects to compete on this point and to mobilize all the expertise required, such as user interface (UI) and/or user experience (UX) engineers. Interoperability COTS and SaaS solutions are usually delivered with data integration tools such as API toolbox and connectors, which allow connection with third party systems. In addition, COTS and SaaS software developers have experience in developing interfaces for their multiple customers, and their 16 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA software is sometimes designed to integrate natively with “mainstream” applications such as SAP or ORACLE. In the case of Custom projects, all interfaces are designed at the time of the system creation, which requires significant technical skills and resources to be allocated to this task. Maintainability Maintainability can be defined as the ease of the “day-to-day” administration of the system on both technical and functional dimensions and the ability to improve the system over time. With SaaS/ COTS mode, the software developer takes care of the modifications and updates necessary for the integration of the various software bricks and components that make the solution. In the Custom world, it is the technical team’s responsibility to do the impact studies, development, and testing. From a time and cost point of view, this is more expensive than SaaS mode, which distributes the effort and cost across all customers. Besides, in SaaS mode, features allowing a “non-technical” resource to handle functional administration are developed. SaaS solutions anticipate functional administration in their design, but it is harder to anticipate the real needs in terms of functional administration on Custom projects. SaaS continuously incorporates customer feedback into the product roadmap. The market study shows that the SaaS/COTS software developers surveyed make at least one major release of their product every year, and sometimes two. But it is the software developer who decides on how to prioritize the evolution requests received from all customers. In other words, a given customer is not sure that these evolution requests are quickly considered. In theory, Custom-built software allows customers to add or remove features on the fly. But in practice, once the software is built, most of the project team is disbanded and re-assigned to other projects. Even when that is not the case, every evolution of the product is a mini project that takes time and money. Security In relation to IT security, there are two different dimensions to consider: security of application and infrastructure, and security of data. Ensuring the security of an application and infrastructure requires costly software components, audits, and processes. Regarding application security, it is commonly acknowledged by the cybersecurity community that choosing a SaaS/COTS application from a trusted software developer is more secure as it can spread these costs over all its customers. Data security was frequently mentioned by African governments as the main reason for choosing Custom projects. However, the study shows that SaaS software developers are now able to provide a level of security at least equal to that of “on premise” hosting. Sovereignty Sovereignty can be analyzed on two dimensions: data sovereignty and autonomy in the management and evolution of the system. Custom projects and COTS are generally associated with on-site hosting of the solution. In Africa, a trend seems to be developing in favor of data centers pooling the hosting of all the IT solutions used by governments, which offers substantial guarantees of data sovereignty. Some examples of these “government clouds” are detailed in the case studies in this report. Most SaaS e-GP systems are hosted in the cloud. But this does not mean that there is no guarantee of sovereignty. It is technically possible for the solution to be hosted in a data center in the customer’s country, or the software developer may agree under certain conditions to EXECUTIVE SUMMARY I 17 host the solution on the customer’s premises, as described in the market survey. Besides, most SaaS e-GP developers offer a “single-tenant” multi-instance) architecture that guarantees the total partitioning of data between clients. It is also possible to require data encryption at the server level that makes the data inaccessible to anyone with physical access to the data centers. All three implementation modes allow the customer to have control over the administration of the tool in everyday life. In the Custom mode, this is achieved by perpetuating the teams that managed the project phase and change management. It is therefore important to provide for the financing of these teams beyond the project phase, as several countries interviewed stressed. In COTS and SaaS projects, sovereignty involves a transfer of know-how from the software developer to the government teams. The training of administrators and their support during the handover phase must be precisely described in the project specifications and in the software developer/system integrator’s contract. Since the government may have limited influence on the roadmap of the software developer, it is important to ensure that the software developer adequately covers the functional needs that are not implemented in the first project wave, or that it can interface with another solution easily to meet the need. It is also possible to ask software developers to commit to delivering a feature that is not currently available. Total Cost of Ownership Cost modeling has shown that implementation projects to deploy Custom or COTS with high level of customizations cost twice as much as SaaS solutions implementation projects. In addition, the total cost of ownership over five years for Custom projects is 60 percent higher than for SaaS or COTS projects with a low share of customization. There is also a stronger tendency for Custom/ COTS projects with high level of customizations to drift from a budgetary point of view. Ease of budget management Budgeting and management are easier in the SaaS/COTS mode with low share of customizations. Financial modeling and market research have shown that SaaS/COTS is more predictable. The government can more easily have a definitive vision of the costs related to a given functional scope. The pricing models adopted by SaaS/COTS software developers are also interesting for their flexibility. The amount of the licenses will adapt to the progressive deployment of the software. In the Custom/COTS model with a high level of specific costs, all project costs are charged to the project, regardless of the actual use of the solution. Risks of failure Risks associated with the purchasing process should not be underestimated. On Custom projects, it is sometimes difficult to evaluate the ability of an internal or external team of developers to produce the desired application. With SaaS/COTS projects, the risk is to conduct an insufficiently detailed study of the capabilities of the market’s solutions – in terms of functionality, integration, administration capabilities, etc. – and to ultimately choose a solution that is far from the priority expectations and incompatible with the government’s constraints. The responses from the study have shown that the risk of budget and schedule slippage is much greater for Custom and COTS projects with a high proportion of specific projects. The field study clearly showed that these projects also show a significant gap between the initial ambition and the actual realization. 18 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Two important risks must also be considered for the success of the project in the long term: the risk of dependency and the risk of obsolescence. The risk of dependency is higher on Custom projects. As IT skills are rare and difficult to retain, there is always a dependence on certain key profiles, especially in Custom projects. In SaaS/COTS projects, there is a real risk of dependence on the software developer and/or system integrator who may be the only one able to carry out more complex evolutions. This risk is however manageable if the different cases are contractually foreseen. The risk of obsolescence should also not be underestimated; it tends to be higher for Custom projects. The difficulty of keeping up with technological developments should not be taken seriously. It is becoming more and more difficult to make the right choices and to follow the evolution of IT frameworks, languages, and components. In this regard, the SaaS/COTS model is more comfortable, because the technological upgrade of the application is necessary for the long term (business) survival of the software developer, and is therefore managed in a mutually beneficial manner for all customers. In all cases, as each country context is different, it is recommended that a preparation phase be carried out upstream of the project to ensure that the procurement needs of the various government entities are properly identified and framed. Chapter I Context and definitions 20 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Chapter I Context and definitions E-Government Procurement (e-GP) is defined in the World Bank as “the use of a transactional information system by government institutions and other public sector organizations in conducting and managing their procurement activities and relationships with suppliers for the procurement of works, goods and services required by the public sector.” It should not be confused with e-procurement, which is a generic term to designate the use of information and communication technology to handle and to manage any or all transactional steps of the procurement process. An e-GP system can be therefore considered as e-procurement applied and compliant with public procurement regulations. In practical terms, the implementation of e-GP involves the deployment at a national level of web applications that secure and improve the efficiency and transparency of public procurement from bidders planning to contract management and including purchase orders. In its previous reports on the topic, the World Bank has specified the functional areas covered by e-GP solutions.2 Ideally, the functional coverage of a complete e-GP system should include the following three areas: 1 The pre-award phase, from planning the project through the results of the bid evaluation process. 2 The post-award-phase, from the award of the contract till completion. 3 The supporting features. Functional coverage Pre-awarding phase Post-awarding phase Suppporting features e-Procurement Planning Contract management e-Registration e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters Source: Authors 2. E-Procurement Toolkit: E-Procurement Preparation http://eprocurementtoolkit.org/sites/default/files/2016-10/e-Procurement_ Preparation-Rapid_e-Procurement_Toolkit.pdf CHAPTER I - CONTEXT AND DEFINITIONS I 21 An e-GP system should also meet the following technical characteristics: • Data integration capacity: capacity of the e-GP to communicate with other existing systems by sending, collecting, and processing data. • Secure Data Hosting, sovereignty, and integrity. • Application reliability and availability (guaranteed by SLA). • System flexibility: capacity to develop new features without investing much in terms of [financial and human] resources and time. • Data and application security Interface with the accounting Integration tools to seamlessly systems in order to receive the communicate with all back-end systems Examples amounts of liquidated orders and Strong and third-party business services: of common monitor the expenditure on contracts integration • Enterprise Application interface interfaces capabilities (EAI toolbox) to help orchestrate the on e-GP Web service interface with public/ data trasnfer with external systems systems external supplier database to ensure • API console to deploy, manage and test the existence/compliance of the suppliers Location of the datacenters Reliability and availability High security standards Hosted in the country of the system guaranteed by service level agreement (SLA) - Security of the data Technical • Or hosted in a country that has (authentication, back-up, ratified the Malabo Agreement prerequisites Flexibility of the system to recovery plan) • Or hosted in a country subject to adapt to organizational changes - Application security RGPD, with a provider that does not (encryption of the database, present any risk of extraterritoriality Scalability intrusion prevention, etc.) Source: Authors The Malabo Convention, the African Union Convention on Cyber Security and Personal Data Protection,3 aims to strengthen and harmonize the legislation of African Union countries in the two areas by creating a normative framework that can serve as a basis for the design of laws, and covers three specific major activities: 1 Electronic transactions. 2 Protection of personal data. 3 Cybersecurity and the fight against cybercrime. 3. https://au.int/en/treaties/african-union-convention-cyber-security-and-personal-data-protection. 22 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Objectives of the study on e-GP implementation types To assist governments in their decision-making process, the World Bank has conducted this analysis, comparing three implementation types for e-GP solutions: Custom, Commercial-Off-The- Shelf (COTS), and Software-as-a-Service (SaaS). It has also conducted a global market survey of the e-GP software developers which is included in the report. The objective is to share knowledge of common approaches to establishing an e-GP system. By investigating cost-benefit analysis of implementation time, cost, hosting solutions, and sustainability of the business models, client countries will be better able to take informed decisions on the approach based on international practices and implementation methodologies. This will permit them to leapfrog traditional methods of software development, and operation and maintenance processes. It is to be noted that while all findings and recommendations can be applied to other countries, the report will specifically focus on the Africa region. Indeed, Africa is the region which is truly lagging behind the rest of the world when it comes to e-procurement. Also, African governments are more interested in what other African governments are doing, providing outside experience and recommendations very often does not work well in the context of the region. Therefore, all the vendors in the market analysis were specifically asked about their African products and services. For the cost-benefit analysis, only data for African countries was collected; as a result, only five African countries were interviewed for more details. The focus on both the private and public sector was done on purpose. The private sector is more advanced in the use of ICT, including e-procurement, and the public sector can learn a lot from their experience. Successful e-procurement systems are based on a marriage between the vendors and the governments. Therefore, while the primary audience for this report is government authorities and experts in public procurement, private entities including vendors, consultants, and services providers will also benefit from the in-depth analysis described in the report. The study opens with a description of the three different implementation types: Custom, COTS and SaaS (Chapter II). This part explains the details of each type of implementation with respect to terminology, implementation methodology, and the financial model. The specific characteristics of each mode, the typical project organization, the typical profiles/expertise to be mobilized, the sharing of responsibilities between the client and the different stakeholders, the methodology traditionally implemented, and the benefits and limitations of each implementation type, are described. CHAPTER I - CONTEXT AND DEFINITIONS I 23 Chapter III details the analysis of the e-GP market. Several market surveys on Source-to-Contract (S2C) and Procure-to-Pay (P2P) solutions have been conducted by research companies such as Gartner or Forrester. However, there is no study that focuses on the subset that represents the market for e-GP solutions. Chapter III includes a mapping of the different software developers or firms that have developed one or more e-GP solutions, and several analyses on the main characteristics of the market: • The different types of e-GP developers in the market. • A ranking of the best/least well covered features on the marketplace. • An analysis of the most used e-GP implementation models. • An analysis of data hosting and application security policies. • An analysis of pricing models and market prices for the main features. • An assessment of the capacity of the e-GP solutions developers to deploy their solution in Africa. • One summary sheet per software developer. All this information should enable governments to have an overview of the market trends and to adapt their e-GP implementation strategy and specifications. The following methodology was applied for the preparation of the market survey: • Sixty software developers were prequalified as potential e-GP solutions developers. • A market survey questionnaire was elaborated (refer to Appendix 2) to analyze the company profile, functional coverage, implementation model, data hosting and security and pricing models. • The questionnaire was sent directly to the pre-qualified software developers. To reach a maximum of e-GP software’s potential developers, the Word Bank also published the « market survey » questionnaire on the platform www.wbgeconsult2.org. • The response rate was one-third, with 18 completed questionnaires received. Chapter IV describes financial modeling of project costs and a comparison of recurring costs across implementation types. It also includes an analysis of the return on investment of the three implementation modes using Benefit-Cost Ratio (BCR) approach. All the previous analyses are then synthesized in a Cost-Benefit Analysis (CBA) that presents the relevance of the implementation types, based on 10 criteria. Finally, Chapter V details the main case studies in Africa and the results of interviews. Chapter II Overview of the different implementation types ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA I 25 Chapter II Overview of the different implementation types This study focused on public procurement entities, but the characteristics of each implementation type described in this section are also applicable to the private sector. 2.1 Overview of information systems project characteristics 2.1.1 Information System (IS) implementation phases First, it is important to understand how different solution providers, software developers, and system integrators are from each other. Solution provider is a generic term that designates companies offering all types of IT products and services. This includes software developers, system integrators, hosting service companies, among others. The term, software developer, refers to companies that develop (code) and commercialize their own software. A system integrator is a company which supports the public procurement entity through the whole process of IS implementation—the installing of a new software product, the upgrading of an existing one, or conversion to a different product, into the information services system within an organization4. The system integrator can be the software developer itself, or another solution provider (including in some cases consulting companies). There are generally three different phases of software implementation: 1 The Design phase. This is the phase during which the e-GP developer or system integrator, where applicable, focuses on defining the features requested by the client. The design phase is generally based on the specifications provided by the public procuring entity during the acquisition phase, combined with functional and technical workshops with project managers and end-users. During this phase, user roles are specified – with user profile authorizations designed accordingly – and the workflows are documented. Thereafter, the software developer or system integrator, as applicable, defines an implementation strategy, with resources requested for the build phase, planning of the project, testing organization, etc. The design phase takes place at the beginning of the project and requires participation from all the various stakeholders. 2 The Build phase. This is the phase during which the e-GP developer or system integrator, as applicable, builds the solution, based on the needs identified during the design phase. This phase is divided into development (configuration/customization); testing; and deployment of the software. Well-designed configuration and code significantly reduce the number of tests runs and maintenance-related problems. 4. Project Management Institute: IS/IT system implementation projects, tools and techniques for success: https://www.pmi.org/ learning/library/new-systems-upgrading-existing-implementations-453 26 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 3 The Run phase. This phase includes the adoption of the e-GP system by the end-users and the support and maintenance activities. Once the system is deployed, there is still much work related to the maintenance of the software. First, there may be corrections to apply. In addition, all end-users must be trained and regularly supported when encountering bugs or misunderstanding a feature. With a wider spread in use of the software will come the need new functionalities. An effective implementation will therefore involve significant business process changes within the organization. 2.1.2 Different approaches to develop an e-GP system There are different approaches for a government that wishes to develop an e-Procurement system. 1 Government-owned and operated. Here, the government develops and runs the e-Procurement system, relying on its own internal resources. Sometimes, the government might require help from a third party to support one or several phases of the project, but these external partners do not own any part of the system. They are just providing IT or consultancy services. 2 Government-managed service. The government does not own the e-Procurement system; it is developed and owned by a third-party, which also operates the software. However, the government retains ownership of the data and support services, including user support and training. Generally, the government relies on internal resources such as dedicated teams and hardware to support the run phase and manage the relation with the system developer. 3 Public-private partnership (PPP). In this model, the system is developed and operated by a third-party. However, after a certain period, the ownership of the system is often transferred to the government. 2.2. Custom development Custom software refers to bespoke solutions that are developed to the needs of a given organization and that are not packaged for resale. Custom software development is used for unique business processes that are not easily mapped to specific technology products. 2.2.1. Organization Design & Build phases • Usually, Custom software development is handled by a third-party commissioned by the public procurement entity. The solution can also be designed by an in-house team of developers. This type is less frequent, because pulling internal resources from daily work may cause slowdowns for operations and staff may not be trained or experienced in the required technology. • When a customer decides to begin development on Custom software, it starts from scratch, and it has to cover all of the dimensions associated with the IT development process. In some rare cases, a custom solution can also be developed based on a previous project led by the software editor. A Custom project moves through the familiar steps of requirements gathering, code construction, testing, and deployment. It applies the same methodologies as any other software project, such as Agile, DevOps,  or Rapid Application Development, and therefore, CHAPTER II - OVERVIEW OF THE DIFFERENT IMPLEMENTATION TYPES I 27 the designing of customized software requires significant resources and expertise. Figure 1 below presents the two main types of project methodology for Custom software development projects. The classical team within the software developer comprises: • A System Architect who defines the structure of the information system, identifies constraints and technological specifications. • A user interface (UI) designer for the visual of the user interface. • A user experience (UX) Designer to enhance the navigation of the users. • Front end engineers who develop the client-side—the part of the application that users interact with and send requests to. • Backend engineers, who handle the server-side—storing and organizing data, ensuring everything on the client-side works as required. • A technical project manager or a Lead Developer. • Resources to install and manage the technical infrastructures (servers) during the project phase. Figure 1: The two main types of project methodology for Custom software development projects Waterfall methodology + Clearly defined stages Gather specifications - Separation of duties between functional and technical teams Design Build & - Requires users to know upfront precisely what you need (vs. trying it and refining) configure Test - Longer lead times Produce - More risk of rework Agile methodology + Flexible and adaptable changes Prototype Prioritize Agile sprint + Faster (time to completion) Work cycle for sub-deliverables + Easier to align with business + Reduced risk Configure or develop Test with users - Can be more complex to manage Source: Authors 28 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA The Customer brings the functional expertise: • A Product Owner who is responsible for prioritizing the tasks and for planning the scope of work for the duration of the project In other words, the product owner is the connection point between the team, and users. This resource needs to have a thorough understanding of the needs of the public procurement entity. • Key Users to help in the prioritization of the needs and participate to the testing phases. • Clients, often assisted by a consulting firm with expertise in the functional part of the project. The consultancy firm usually also provides operational assistance to monitor the indicators of project planning and implementation (Project Ownership Assistance). In Custom projects, the testing of the solution can be very challenging: • Given that the software is most often designed from scratch, it is necessary to run several rounds of “unitary” testing to ensure that there will be no major bug or problem related to the code. • In addition, the user acceptance testing is sometimes hard to complete. Custom developed solution often requires several tests before providing a pleasant and efficient user experience. RUN PHASE Generally, corrective maintenance (fixing bugs) and evolutive maintenance (new features) are carried out by the Solution provider which was selected to develop the solution. Public procurement entities sometimes seek to re-internalize maintenance for sustainability reasons. This is not always easy, In fact, training internal resources to maintain the solution may take months. Trained staff may leave and create vacuum of institutional memory. The deployed system may also be very complex to understand and operate, depending on technical choices that were made during the conception— code language, solution framework, etc. INTENSITY OF PROJECT MANAGEMENT OWNERSHIP The customer’s active participation is required in all the stages, and notably for:  • Prioritization of the needs. The public procurement entity must have an in-depth understanding of its organization and procurement processes, so that they can address relevant specification and allow the software developer to develop a software that will meet all the expectations. • Testing of the software every 2-3 weeks so that the team can make minor adjustments along the way, hence avoiding project extensions due to major modifications at the end. • Monitoring the daily metrics that show how a project is progressing. 2.2.2. Code personalization and ownership • The code is tailored to the needs of the public procurement entity, which can theoretically replicate all its processes in the e-GP system. Indeed, e-GP implementation should not be merely to automate existing manual processes, but to create workflows that reduce inefficiencies and remove redundancies. Depending on the available budget, Custom software may allow the customer to add or remove features as needed, or change functionality as the organization shifts focus and/or grows. CHAPTER II - OVERVIEW OF THE DIFFERENT IMPLEMENTATION TYPES I 29 • Since the developed code becomes the property of the government, there are no theoretical restrictions on the access to the code. Care should be taken to ensure that the clauses transferring intellectual property from the solution providers to the customer are properly formulated and in accordance with the regulations in force. 2.2.3. Liabilities Following are issues that need to be covered once deployment is in place; the cost for each of these should be included in the overall budget. Hosting: • Management of hosting/data is under the government responsibility. The public procurement entity decides on the hosting modalities: on-premises hosting (operated by resources or managed by a service provider), or off-premise hosting handled by a hosting services provider, specialized in the cloud. Maintenance: • Corrective maintenance (fixing of bugs) is most often entrusted to the solution provider who carried out the application, or joint internal/external teams. • Evolutive maintenance (new features to be developed). The public procurement entity defines which new features will be developed. The requests for evolution are then qualified, quoted, and managed by the software developer or an internal team. Help Desk Support: • Help Desk Support is most often entrusted to the solution provider who developed the application; it may also be entrusted to a joint internal/external team. Application and data security: • Customer technical teams have complete control over security and data protection policies. Security protocols must be continuously reviewed. The customer needs to ensure any relevant third parties have stringent procedures and policies in place. For more information on this, please refer to Chapter 2.7 – Security fundamentals; the section also describes best practices for application and data security. 2.2.4. Acquisition mode • Companies bid based on how much development time the project requires and how much it costs. These bids are not “set in stone,” as some projects may require additional time and costs. The upfront costs of developing a Custom software are much higher than the implementation costs of a pre-packaged solution. The cost is not fixed and may exceed the forecasted cost—see the CBA analysis in Chapter IV. Custom software hosting on-premises also requires the acquisition of additional hardware, data center resources (facility and electricity), and administrative staff for the infrastructure. One of the drawbacks to consider is the possibility of lagging behind when the technology changes. This is because the public authority may not have IT as its main business and may not be sufficiently agile to respond quickly to technological changes. 30 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 2.3. COTS The acronym “COTS” stands for Commercial-Off-The-Shelf. The software industry does not have a common understanding of what a COTS product is. Hence COTS may be one of the most diversely defined terms in current software development and it can refer to many different types and levels of software. To prevent possible confusion, we adopted the following definition: A COTS-based system is a software available commercially and acquired from a software developer or via open source that is used as-is or with configuration, or that can be tailored with a layer of specific code on the top of it. 2.3.1. Organization DESIGN AND BUILD PHASE As the features are already developed, COTS projects follow a process quite different from Custom projects, with more effort put into requirements, tests, and integration, and less in design and code development. Figure 2 details typical COTS implementation process and planning. Fewer resources (personnel, knowhow, and machines) are needed compared to a Custom project. The classical team comprises: • Software developer and/or certified system integrator resources. • Technical experts in charge of the general/detailed design of the target solution: how the different modules fit together, main business rules, data flows, and interfaces required. Technical experts may also take charge of the configuration (parametrization of the modules) and/or of custom code providing the missing functionalities (“adware”). • Functional experts who help to prioritize the business requirements and match them into the solution. Key questions are: How do we map our business processes in the different modules? What are the main business rules to be configured? How much back data will we migrate? What are the integration points with our existing systems?5 Functional experts play a key role as they guide the elicitation, negotiation, and validation of user requirements. This role requires minimum technical background – knowing the data model, possibilities, and limitations of the chosen solution – and socialization ability. COTS projects must accept flexibility in requirements. When COTS is selected, some requirements are immediately satisfied, some other requirements become easy to implement, and others may be more difficult if not impossible to obtain. Not every software developer/system integrator has the functional competence to enable the customer to make these key tradeoffs. This role is therefore sometimes carried out by a third-party consulting firm that positions itself as a Business Analysis Consultant. The consultancy firm usually also provides operational assistance to monitor the indicators of project planning and implementation (Project Ownership Assistance). 5. https://www.oecd.org/tax/forum-on-tax-administration/publications-and-products/introducing-a-commer- cial-off-the-shelf-software-solution.pdf. CHAPTER II - OVERVIEW OF THE DIFFERENT IMPLEMENTATION TYPES I 31 Figure 2 below presents the percentage of time allocated to each phase of a COTS implementation project, based on data collected through 40 implementation projects conducted by CKS Consulting. Figure 2: Typical COTS implementation process and planning Phase 1: Phase 2: Phase 3: Phase 4: Development & Design User testing Finalization implementation General design based Development and Complete testing Data transfer and on prototype implementation via “delivery of the solution by the general deployment loops”, based on a 1st version end users • System of the configured solution architecture • UAT (User • Configuration acceptance testing) • Requirement analysis • Development of interface • Discrepancy resolution • Mapping of the requirement of the solution • Identification • Custom development of adware development • Adware integration • Unitary testing 30% 60% 80% 90% 100% Several implementation sprints (V1, V2, ...) Source: Authors RUN PHASE In almost all cases, corrective maintenance (fixing bugs) is affected by the software developer or the integration partner. Regarding evolutive maintenance (new features), several situations arise: • It can be a question of procuring and activating a new module present in the software selected. In this case, the system integrator will take charge of the implementation following the same methodology as for the initial perimeter. • If it is a question of modifying a configuration that has already been carried out – for example, workflows or management rules – the system integrator partner is also mandated. The partner qualifies the adaptation effort, sends quotes, and carries out the modifications. 32 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA • In some cases, the desired evolution is not possible in the COTS software. In this case, the software developer remains the ultimate decision maker on the functionalities available and on the schedule for releases. Consequently, the customer has little or no influence on the above issues as they affect the application. One of the most common remedies in such a case is to add custom code to the components to provide the missing functionalities.6 INTENSITY OF PROJECT MANAGEMENT OWNERSHIP The government’s contribution to the e-GP project implementation using COTS is less intense than on a Custom development project. It would include an iterative discussion between the users and the project teams on what existing processes can be changed to accommodate the existing functionalities of the system. The customer’s role focuses on the following activities: • Business needs definition and prioritization. The customer must develop a structured evaluation framework, informed by key stakeholder’s needs and priorities, to ensure organizational alignment. For instance, the customer must assess the suitability of using COTS right “out-of-the-box” and only altering the human workflow processes to use it. • Ensuring the overall governance of the project and the steering committees that make it possible to carry out functional decisions. • Facilitate the mobilization of internal teams to ensure that the product meets expectations, particularly during the test phases. • Software developer interaction of technical, administrative, and commercial kinds.7 2.3.2. Code personalization and ownership The source code is based on feedback from multiple clients and is, per definition, not personalized to one customer needs. This does not mean that the features cannot be personalized. There are basically two possibilities to personalize a COTS: • Customizing requires the technical team to modify a program or write a new program to satisfy new needs. Customizations can be basic or much more invasive, changing the core application. In most cases, the specific code added to the original e-GP system is owned by the government, depending on the terms of the contract negotiated with the e-GP developer. • Configuration uses tools in the application to meet specific requirements without adding specific code to the solution. These terms are not always well defined, and as a result there is a bit of confusion. • Customization means more effort and more risk. This is because a programmer develops new features without using the tools that are available in the system, but by adding new code. In the event of a release upgrade that allows customers to benefit from new functionalities or improved user-experience, for example, some portions of that specific code may become incompatible. Customized systems are generally quite complicated and expensive to maintain over time. Public procurement entities therefore try to avoid them by modifying processes or finding workarounds in configuration mode. 6. https://www.pmi.org/learning/library/custom-off-the-shelf-strategy-6137. 7. https://www.oecd.org/tax/forum-on-tax-administration/publications-and-products/introducing-a-commer- cial-off-the-shelf-software-solution.pdf. CHAPTER II - OVERVIEW OF THE DIFFERENT IMPLEMENTATION TYPES I 33 • Configuration means less effort and less risk. Configuration is much more stable because it does not modify the solution beyond what was intended when it was designed. This is because the configuration is based only on existing tools in the solution, which allow developers to modify functionalities in a particular way. The configuration does not change the structure of the solution. Configuration is inherently better because it is working within the application, using existing features that were designed specifically to modify the application. Code accessibility and ownership: • In most cases, access to the code is impossible or limited. • COTS solutions may also be open source, which guarantees access to the code. Government can then fork the source code—create a variant branch of the code from the source code. 2.3.3. Liabilities Hosting: • There is a mix of on-premises and outsourced hosting (which is becoming the standard). In the first case, hosting/data becomes the government responsibility. In the second case, it is the software developer or a mixed responsibility. Maintenance: • In most projects, maintenance is carried out by a specialized system integrator. There are also cases where corrective and evolutive maintenance is carried out by a mix of internal and external teams. Help Desk support: • Software developers usually offer a first-level service that handles simple requests such as password management, creation/modification of users, and rights. • These external help desks also deal with user mainly for functional and technical issues. Application and data security: • If the solution is implemented “out-of-box” or has been personalized through configuration, the responsibility for application security lies with the software developer. These solutions are regularly tested by specialist teams and/or third parties, and benefit from automatic security updates. If specific code has been added – customization – the responsibility is generally shared by the software developer, the system integrator who made the code, and the customer. Chapter 2.7 describes best practices for application and data security. 2.3.4. Acquisition mode For COTS, the customer does not own the software and pays for the right to use it. There are two financial models offered by COTS software developers: the perpetual license and the subscription fee. • Purchasing software with a perpetual license allows the customer to use the software for an indefinite period by paying a single upfront fee. In addition, the customer also pays the maintenance and other support fees on a yearly basis. This is the “historical” model for 34 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA purchasing software. From an accounting perspective, the customer will generally capitalize the cost of acquiring the software. For financial statement purposes, management will need to evaluate the estimated useful life of that software and amortize the cost, using an acceptable amortization method. • During the last decade, many COTS software companies have shifted their revenue models from a perpetual license to a subscription-based model. In this model, the customer makes regular payments each year (or each quarter/month) to use the software. A key difference between the two models is that subscriptions include everything—the right to use the software, maintenance, and technical support, whereas term licenses only include the right to use the software. From an accounting point of view, the transaction is considered a service contract and generally requires a company to expense the cost for the duration of the contract. Benefits to this model include lower up-front costs and avoiding lengthy capital expenditure approval processes. It is also necessary to get a quote for the software implementation service: Design, Build, and Change Management. The software developer and/or his system integrator will then provide a fixed price estimate that depends on the number of workshops to be conducted, the number of functionalities to be implemented, the number of interfaces, and the complexity of the project. 2.4. SaaS “SaaS” stands for Software-as-a-Service (SaaS). It is an additional step as all development activities, infrastructure management and maintenance efforts are shared with all users. It refers to software that is provided to the consumer as a (shared) service made available over the web, with no hosting or installation required. The software developer is responsible for managing the software stack, hosting, maintenance, and other services. The customer can configure the software in accordance with the software capabilities. 2.4.1. Organization DESIGN AND BUILD PHASES The implementation process and project organization for SaaS are quite similar to COTS-type projects, but with more effort put into requirements, test, and integration and less in design and code. Figure 3 below presents typical SaaS implementation process and planning. Fewer resources are needed compared to a Custom Project/COTS project. The typical team is made of: • Software developer and/or certified integration partner resources • Technical experts in charge of the general/detailed design of the target solution: how the different modules fit together, main business rules, data flows and interfaces required… • Technical experts in charge of the configuration (parametrization of the modules). On pure SaaS projects, the target is to exclude any customization. This is also the reason why the level of IT qualifications on these projects is lower compared to COTS. The resources involved are certified on the technology chosen but do not necessarily have an IT background. They use configuration tools predeveloped in the solution without having to work on the code. CHAPTER II - OVERVIEW OF THE DIFFERENT IMPLEMENTATION TYPES I 35 • Functional experts who help prioritize the business requirements. They guide the elicitation, negotiation, and validation of user requirements. This role requires minimum technical background – knowing the data model, possibilities, and limitations of the chosen solution – and relational ability. On SaaS projects, some other requirements are easy to implement using configuration, and others may be more difficult if not impossible to obtain. Governments must be prepared to adapt some of their very specific processes to fit the solution. Therefore, it is important to see how the specifics of a country’s laws can be taken into account by a SaaS project. Not every software developer/system integrator has the functional competence to guide the customer to make these key tradeoffs. This role is therefore sometimes carried out by a third- party consulting firm that positions itself as a Business Analysis Consultant. The consultancy firm usually also provides operational assistance to monitor the indicators of project planning and implementation (Project Ownership Assistance). Figure 3 below presents the percentage of time allocated to each phase of a SaaS implementation project, based on the data collected through 40 implementation projects conducted by CKS Consulting. Figure 3: Typical SaaS implementation process and planning Phase 1: Phase 2: Phase 3: Phase 4: Development & Design User testing Finalization implementation General design based Development and Complete testing Data transfer and on prototype implementation via “delivery of the solution by the general deployment loops”, based on a 1st version end users • System of the configured solution architecture • UAT (User • Configuration acceptance testing) • Requirement analysis • Development of interface • Discrepancy • Integration tests resolution • Mapping of the requirement of the solution 30% 60% 80% 90% 100% Several implementation sprints (V1, V2, ...) Source: Authors 36 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA RUN PHASE Corrective maintenance (fixing bugs) is carried out by the software developer or a certified system integrator, as applicable. Regarding evolutive maintenance (new features): Several situations arise: • To procure and activate a new module (present in the software suite), the system integrator will take charge of the implementation following the same methodology as for the initial perimeter. • To modify a configuration that has already been carried out (workflows, management rules), the system integrator partner is also mandated. The partner qualifies the adaptation effort, sends quotes, and carries out the configurations. • In some cases, the desired evolution is not possible in the SaaS software. In SaaS mode, any customization is theoretically avoided to compensate for a functional weakness of the tool, as is the case with adware in the COTS implementation mode. In this case, the software developer remains the ultimate decision maker on the functionalities available and on the schedule for releases. Consequently, the customer has little or no influence on the above issues as they affect the application. The ability to influence the software developer’s roadmap depends, among other things, on the weight that the customer represents on the software developer’s activity and the number of customers. INTENSITY OF PROJECT OWNERSHIP The customer role focuses on the following activities: • Business needs definition and prioritization. The customer must develop a structured evaluation framework, informed by key stakeholders’ needs and priorities to achieve organizational alignment. For instance, customer must assess the suitability of using the SaaS right out-of-the-box with only altering the human workflow processes to use it. • Ensure the overall governance of the project and activate the steering committees that make it possible to carry out functional decisions. • Facilitate the mobilization of internal teams to ensure that the product meets expectations, particularly during the test phases. • Software developer interaction at technical, administrative, and commercial levels. 2.4.2. Code personalization and ownership Personalization: The source code is, per definition, not personalized to one customer needs. The solution can be personalized through limited configuration, using tools in the application to meet specific requirements without the use of code. Customizing (writing new code programs, class files, scripts) is theoretically excluded on SaaS projects. Besides, SaaS software developers do not provide easy access to their source code. CHAPTER II - OVERVIEW OF THE DIFFERENT IMPLEMENTATION TYPES I 37 2.4.3. Liabilities Hosting: • This is the responsibility of the software developer. All data hosting activities and the maintenance of an adequate level of security are described in an SLA between the government and the software developer. Maintenance: • The corrective and evolutive maintenance is managed by both the software developer and/or the system integrator (maintenance of the government configuration). Help Desk support: • The Help desk is managed by both the software developer and/or the system integrator. Software developers usually offer a first level service that handles simple requests: password management, creation/modification of users, and rights. These external help desks also deal with user functional issues. Application and data security: • This is the responsibility of the software developer. All data hosting activities and the maintenance of an adequate level of application security are described in an SLA between the customer and the software developer. Chapter 2.6 describes best practices for application and data security. 2.4.4. Acquisition mode • During the last decade, most SaaS software companies have shifted their revenue models from a perpetual license to a subscription-based model. In this model, the customer makes regular payments each year (or each quarter/month) to use the software. A key difference between the two models is that subscriptions include everything: the right to use the software, maintenance, and technical support; term licenses only include the right to use the software. From an accounting point of view, the transaction is considered a service contract and generally requires a company to expense the cost over the duration of the contract. Benefits to this model include lower upfront costs and avoiding lengthy capital expenditure approval processes. • Most SaaS editors still accept under certain conditions to contract in “perpetual license” mode. Purchasing software with a perpetual license allows the customer to use the software for an indefinite period by paying a single upfront fee. In addition, the customer also pays the maintenance and other support fees on a yearly basis. This is the historical model for purchasing software. From an accounting perspective, the customer will generally capitalize the cost of acquiring the software. For financial statement purposes, management will need to evaluate the estimated useful life of that software and amortize the cost, using an acceptable amortization method. It is also necessary to get a quote for the software implementation service: Design, Build, and Change Management. The software developer and/or his system integrator will then provide a fixed price estimate that depends on the number of workshops to be conducted, the number of functionalities to be implemented, the number of interfaces, the effort expected usually on the basis of man month effort, and the complexity of the project. 38 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 2.5 The Open-Source Software option An open-source software (OSS) is an application built by a community of developers that anyone can access, modify, and enhance. OSS are created to be freely available, and their license usually indicates that any updates from contributors will become free and accessible to the whole community. OSS should not be confused with “open standard,” which designates a standard for implementation like HTML and SQL. Besides, open-source shall not be confused with open architecture, which designates privately designed architectures whose specifications are made public by designers. In this e-GP study, OSS was not considered as a separate implementation type. There are a few examples of e-GP projects based on an OSS solution, but the customization layers added make them ultimately similar to COTS projects. In theory, OSS offer undeniable advantages such as savings on licensing costs, advantageous timeframes (the tool is available), and the pooling of efforts between “customers” to improve the system. In reality, OSS tend to be less easily customizable than COTS or SaaS solutions on the market. It can also be difficult or expensive to find competent profiles or companies capable of configuring/customizing the OSS. The cost of mobilizing resources can then completely erase the savings on the cost of licensing. Besides, the choice of OSS implies “betting” on the long-term dynamism of the community that develops and improves the software. There is clear evidence that many OSS solutions see their community decline over time, making the product obsolete. This problem is regularly pointed out, particularly regarding the ability of OSS models to detect and correct security flaws. Before moving towards an OSS, governments should carefully study the dynamism of the community through indicators such as the number of developments made, or the number of “loads” recently made. 2.6. Synthesis of the major differences between the three implementation modes Figure 4 compares the main features of the three implementation modes on several dimensions: • Organization of the implementation project: • The typical parties involved in the Design (solution design) and Build (technical implementation and testing) phases. • The typical parties involved in the Run phase (administration and maintenance of the application). • The intensity of the project management activities—the effort that the client must produce to manage the project. • Personalization, accessibility, and ownership of source code. • Distribution of responsibilities between the parties involved about hosting, maintenance, help desk, and application security. • The different modes of acquisition of the application. CHAPTER II - OVERVIEW OF THE DIFFERENT IMPLEMENTATION TYPES I 39 For the Africa Region, SaaS has a very good future as it is an excellent alternative for most African countries going forward. The recently implemented SaaS solution in subnational Nigerian states and the positive experience in the Caribbean Islands may encourage African countries to adopt more SaaS solutions. Figure 4: Comparing the characteristics of the three implementation types Custom COTS SaaS Software System Software System Mix Key actors in build-design* Solution provider IT dept. developer integrator Mix developer integrator Mix Organization Software System Software System Mix Key actors in run Solution provider IT dept. developer integrator developer integrator Intensity of project ownership low med. high low med. high low med. high Code personalization low med. high low med. high low med. high Code limited full limited full limited full Code accessibility closed access access closed access access closed access access Vend. Gvt. Vend. Gvt. Vend. Gvt. On premise** Hosting and data security On premise** Off premise or off-premise Liabilities Maintenance Help-desk Application security n license tio ip Acquisition mode fix fee T&E license subscription cr bs su Source: Authors Note: In the Organization part, for Key actors in “Design-Build” and “Run” phases, the size of the cell varies according to the frequency of the “scheme” (it does not vary according to the contribution of each player). The analysis is based on 40 implementation projects conducted by CKS over the last 10 years. 40 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 2.7. Issues related to IT security when implanting an e-GP The number of cyberattacks has never been rising so fast. A 2020 Ponemon Institute study discovered that companies spend $3.86 million per incident and that in 2019-2020, organizations lost around $400 billion to cyber theft and fraud, worldwide.8 This cost includes both the direct damage, as experienced in infrastructure downtime and, reputational loss, for example, and the indirect damage—fines for affected data subjects after a data breach, and fines due to GDPR violations.9 Regarding IT security, there are two dimensions to consider: Requirements to ensure data confidentiality, data integrity and Data security data availability Requirements for the developer to identify, prevent and fix all application Application security vulnerabilities at the different stages of the product lifecycle 2.7.1. Prerequisites for securing an e-GP system To ensure that an e-GP system remains secure, a number of principles must be respected: 1 Promote employee awareness about security risks: Ensure that government users are aware of security risks and know the best practices to keep the application safe, such as no login sharing and no opening of suspicious links. 2 Secure the application development: Ensure that there is no security risk or vulnerabilities when the solution is being developed or updated. This is generally way more expensive and time consuming for the government in Custom projects than in COTS or SaaS projects, because the government has to handle everything on its own—train the development team, implement security check software, etc. 3 Ensure infrastructure protection: The hardware dedicated to data hosting and the servers must be kept safe. Once again, infrastructure protection tends to be much more expensive in Custom projects than in COTS or SaaS projects. Indeed, in Custom projects, the government must set up protection measures such as firewalls, intrusion detection software, or data backups in different data centers. In SaaS and COTS project, this is entirely handled by the e-GP developer. 4 Ensure the scalability and fault tolerance of the solution: It is important to ensure that IT resources can adapt in the event of an increase or decrease in activity in the solution. COTS and SaaS solutions make it possible for governments not to invest much on additional infrastructure to answer those types of needs, while Custom e-GP projects require the government to set up additional hardware to implement new accesses. 5 Use cryptography on application and on data transfers: To protect the confidentiality of data, it is important to make it unreadable by unauthorized people. Using encryption to do so is the most common method and can also be completed with the use of the blockchain, which is often considered the best security option in terms of data integrity. The implementation type does not impact the encryption of the data at all, the methods remain the same for all types. 8. Cost of a Data Breach Report 2020. https://www.capita.com/sites/g/files/nginej291/files/2020-08/Ponemon-Global-Cost-of-Data- Breach-Study-2020.pdf. 9. https://www.nbcnews.com/tech/security/ponemon-institute-n364871. CHAPTER II - OVERVIEW OF THE DIFFERENT IMPLEMENTATION TYPES I 41 6 Deploy Identity and Access Management strategy and account provisioning systems: Identity and access management (IAM) is about defining and managing the roles and access privileges of users to the applications. In the case of SaaS/COTS, cloud providers most often offer an IDaaS (Identity as a Service) solution and can implement it with your agreement on your environment, adding an additional layer of security to your data access. 7 Have a security incident response plan: In case of an attack, the government should be able to deal with it quickly. In SaaS or COTS projects, the e-GP system developer is responsible for response plans and generally have trained and dedicated resources prepared to answer such cases. In Custom projects, the government must maintain its security team and update its security response plan on a regular basis, which tend to be costly and time consuming. Maintaining the security of an e-GP system is often demanding and expensive. In a Custom e-GP project, the government usually manages the infrastructure alone, in addition to training of users and internal developers, which represents a major investment. It is therefore necessary, when estimating costs for a Custom e-GP system project, to include funding dedicated to IT security in the final budget. COTS and SaaS projects free the government from handling technical issues, making the cost of security often lower as it is shared with the e-GP system developer’s other customers. Deploying a SaaS or COTS solution might reduce the government investment needed to secure its e-GP systems, but the government still needs to ensure that security considerations are considered during the procurement phase, when the government selects the e-GP developer. Indeed, the government must make sure the offer selected will adequately meet security needs by checking whether or not the e-GP system is audited on a regular basis, that the infrastructure architecture is secure enough, and by evaluating components of the offers related to IT security, such as backup plans, disaster recovery procedures, and certifications. 2.7.2. Data and e-GP steps to be secured at first There are three types of data than can be at risk in an e-GP system: Low resale value, quite easy to restore. Public data Example: Specifications, awarded suppliers, Low risk level number and amount of contracts, etc. Alteration of this type of data might paralyze Non-public data a procurement process. with low Medium/low risk level resale value Example: Supplier evaluation, addresses, manager names, etc. Business secret information, which could Non-public data damage the supplier’s activities and with high compromise ongoing procurement processes. High risk level resale value Example: detailed offers of the suppliers (business secret). 42 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA The e-GP steps that could represent a risk in terms of data security are the following: Pre-awarding phase Post-awarding phase Suppporting features e-Procurement Planning Contract management e-Registration e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters Source: Authors These processes concentrate most of the sensitive information related to business secrecy and the alteration or deletion of the data has no doubt the most important consequences for the contracting authorities. A hacking could indeed lead to important consultation delays, cancellations, delays in government projects, and serious damages for some companies, if confidential information were made public. Chapter III Market survey 44 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Chapter III Market survey The market survey report starts with a rapid overview of the global e-Procurement solutions market, highlighting its key figures, trends, and main players. Chapter 3.2 focuses on the e-GP solutions market as a subset of the overall market. This section includes a mapping of the different e-GP solution developers and developer fact sheets (for those who responded to the market survey questionnaire). The main objective is to provide a general overview of existing offers. This section includes several analyses on the main characteristics of the market: • The different types of software developers active on the market. • A ranking of the best/least well covered features on the marketplace. • An analysis of the main implementation models selected for e-GP projects. • An analysis of data hosting and application security policies. • An analysis of pricing models and market prices for the main features. The market analysis also includes an assessment of the capacity and willingness of the operators to deploy their solutions in the African continent. 3.1. General presentation of the overall e-procurement market 3.1.1. Key figures of the e-procurement suite developer market According to a study conducted by Appsruntheworld,10 the market value for e-procurement software developers in 2015 was approximately $4,978 million. By 2019, it had grown by 15 percent to $5,680 million. By 2024, forecasts estimate that the market will continue to grow to a value of approximately $6,360 million, equivalent to a compound annual growth rate (CAGR) of approximately 2.4 percent. Another study, conducted by Forrester Research estimates the global value of the market at $8 billion in 2019, and predicts a meteoric growth over the next 5 years. The sector is experiencing average but constant annual growth, which is explained by the strengthening of the position of the procurement function in the strategy of companies. It induces a digitalization of the processes to gain in efficiency and security, to improve the quality of monitoring and strengthen the links with other key functions of the companies, such as finance, logistics, and legal. The global e-procurement solution market is moderately concentrated and competitive, with many players of different sizes, operating at the domestic scale as well as in the international market. The market is dominated by about a dozen software developers who share nearly 60 percent of the market share. The undisputed leader in the sector remains the German giant SAP-ARIBA, which has a market share of nearly 22 percent since 2015, shown below in Figure 7. 10. https://www.appsruntheworld.com/top-10-procurement-software-editors-and-market-forecast/. CHAPTER III - MARKET SURVEY I 45 Figure 5: e-Procurement suite developer market shares in 2019 Exhibit 1: 2019 Procurement applications market shares split by top 10 procurement vendors and others, % SAP Other Oracle Coupa Software Zycus GEP Ivalua Mercateo Infor Jaggaer BasWare Source: Authors 3.1.2. Typical e-Procurement suite developers profile The information presented below in Figure 8 are based on a public list of 91 e-Procurement developers published by the Appsruntheworld website.11 Most Procurement IS developers on this list are from North America (41 out of 91, approximately 49 percent). In second place is Europe (37 percent), with France leading the continent in terms of number of Procurement IS developers, followed by Germany where SAP, the leading firm in the market, is located. Most of these suppliers were created between the early 1990s and 2010. After 2010, the number of new suppliers has decreased drastically. It can be observed that the market is mainly composed of small and medium-sized Procurement IS developers; almost 80 percent of them have sales revenues less than US$50 million. Some of biggest developers in terms of revenues are subsidiaries of larger companies. Therefore, it is sometimes difficult to obtain exact information on the size and turnover generated solely by the e-Procurement as the activity metrics are integrated into the overall figures of the parent company. 11. https://www.appsruntheworld.com/cloud-top-500/Procurement/. 46 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Figure 6: Market general information Country classification Workforce classification # of e-GP developers per country # of employees per e-GP providers company <20 The United States of America ---- 41 20-100 >500 11% France ---------------------------- 9 Germany -------------------------- 6 9% The United Kingdom -------------- 6 Japan ----------------------------- 3 52% Canada --------------------------- 2 28% Other ---------------------------- 21 100-500 Creation date classification Turnover classification # of e-GP developers per creation date Average annual turnover (2018-20) 2020 and after -------------------- 0 >50 M$ From 2010 to 2020 ---------------- 7 <5 M$ From 2005 to 2010 ---------------- 6 20-50 M$ 21% 0% From 2000 to 2005 --------------- 17 From 1995 to 2000 --------------- 14 50% From 1990 to 1995 --------------- 13 5-20 M$ 29% From 1980 to 1990 --------------- 15 Prior to 1990 --------------------- 17 Source: Authors CHAPTER III - MARKET SURVEY I 47 3.1.3. Market characteristics and trends The market is relatively mature: • The existing solutions are well thought (well designed and adapted to most typical procurement processes, regardless of the sector) the design costs of basic features are lower than 20 years ago. The equipment rate within large companies is quite high in all economic sectors. Companies are convinced of the added value brought using e-procurement to mutualize and dematerialize their purchases, while homogenizing their processes. • From this point of view, the public procurement entities are lagging far behind, since public organizations are generally much less well equipped than private companies. Finally, the recent COVID-19 crisis has increased the need for digitalization and has therefore increased the appetite for Procurement suites. This fact is even more visible for public organizations in which online procurement is not deeply implemented yet. To remain competitive and sustain their development, software developers must adapt, and are therefore adopting key strategies. The main ways of differentiation for software developers are in their areas of focus/expertise; they may: 1 Develop a full e-procurement suite covering the S2C and P2P processes. 2 Adopt a “best of breed” approach by specializing in one functional/categorial area, for example, reporting and decision-making tools; direction production items in the industry; intellectual services; or by developing a vertical approach on one sector, such as health. 3 Offer strong integration capabilities, “out-of-the-box” integration with major Enterprise Resource Planning (ERP) systems, and with suppliers and third-party business services. 4 Improve the ease of use through number of clicks required to place an order, create a purchase, or to search and view information quickly. 5 Personalize a system to the customer’s processes through configuration activities, as opposed to customizing activities. 6 Embed disruptive technologies such as AI in order to eradicate repetitive and low-value added tasks (machine learning) or in order to produce predictive analytics. The year 2020 saw many industries across the globe struggling. The COVID-19 pandemic and its consequences have increased the need for procurement flexibility and agility, especially in a post-crisis world. As a result, e-procurement software developers are currently increasing their focus on disruptive technologies to ensure that their solution will adequately meet the client’s needs and expectations, given that the COVID-19 crisis has raised challenges across multiples sectors. 48 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 3.2. Presentation of the e-GP market 3.2.1. Profiles of the e-GP developers The information presented below in Figure 9 is based on the sourcing list of suppliers that were contacted in the framework of the market survey. This list identifies software developers who can develop an e-GP project in African countries: • Most suppliers are from North America (USA and Canada) and Europe. There are also relevant firms in Asia, particularly in India and in South Korea. There are just a few firms from Africa and South America. • Some suppliers from this list are leading firms of the global S2P suites vendor market, with relevant experience in the public sector. Several companies are subsidiaries of larger corporations and communicated the figures of their parent company, which explains the relatively high proportion of companies with a turnover higher than US$100 million, and staff count higher than 500. • In addition, most companies of the list were created between 1995 and 2005. The number of young companies – created after 2010 – is much lower, as well as the number of “ancient” firms, those created prior to 1995. Figure 7: e-GP developers general information Country classification Workforce classification # of e-GP developers per country # of employees <20 The United States of America -----11 >500 6% 20-100 France ---------------------------- 4 The United Kingdom -------------- 4 36% Canada --------------------------- 2 33% Finland --------------------------- 2 India ----------------------------- 2 25% 100-500 Creation date classification Turnover classification # of e-GP developers per creation date Annual turnover (2018-20) >100 000 M$ <5 M$ 2020 and after -------------------- 0 From 2010 to 2020 ---------------- 5 From 2005 to 2010 ---------------- 5 25% 33% From 2000 to 2005 --------------- 8 From 1995 to 2000 --------------- 8 From 1990 to 1995 --------------- 2 17% From 1980 to 1990 --------------- 5 20-100 000 M$ 25% Prior to 1990 --------------------- 3 5-20 M$ Source : auteurs CHAPTER III - MARKET SURVEY I 49 3.2.2. Mapping and positioning of the e-GP developers Methodology To carry out this market research, the authors relied on different complementary sources: 1 By pooling the World Bank’s database and expert reviews, 60 software developers with the capacity to provide e-Procurement solutions for the public sector were identified. 2 A market survey questionnaire was then built (please refer to appendix #2) with different sections: company profile, functional coverage, implementation model, data hosting and security and pricing models. 3 The questionnaire has been sent to the pre-qualified suppliers. To reach a maximum of e-GP software’s potential developers The WBG published the « market survey » questionnaire on their platform. The developers were given six weeks to send the questionnaire back. 4 The response rate was approximately one-third with 18 questionnaires received. They all presented their offers in an exhaustive manner and provided a good deal of information on market trends. The 18 suppliers that responded were: Atexo, E-Procurement Technologies Limited (ProcureTiger), Bip Solutions, Bonfire, EASIBUY, European Dynamics, Guadaltel, GEP (NB Ventures, Inc.), In-tend Limited, IOS Partners, Inc., Ivalua SAS, Market Dojo Ltd., Nextenders, Neqo, Otwarty Rynek Elektroniczny (Market Planet), ProcurementExpress.com, Synertrade Inc., and uStudio. 5 The data transmitted by the developers were cross-referenced with government feedback on the implementation of solutions already financed by the World Bank, mainly on projects implemented in Africa. 6 Finally, the information was cross-referenced with the data available on website of the World Bank’s Global Public Procurement Database (GPPD)12. 12. Global Public Procurement Database (GPPD): https://www.globalpublicprocurementdata.org/gppd/ 50 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Mapping of the software developers The graph below in Figure 10 summarizes the positioning of the e-GP developers who responded to the market survey questionnaire), according to two major criteria: functional coverage and e-GP developer’s maturity/interest in regard of the public sector. 1. Functional coverage corresponds to the percentage coverage of the e-GP features. For each supplier, the percentage is based on the supplier’s response to the market survey questionnaire, converted into a 1-10 score. 2. The e-GP developer’s maturity/interest in regard of the public sector, assessed from the questionnaire responses, is based on: • The number of projects carried out in the public sector by software developers. • The percentage of their revenues generated with public organizations. • The strategic importance they give to specific public procurement functionalities in their business operations. Figure 8: Developers mapping based on the analysis of the questionnaire/ survey results Niche software developers e-GP specialists Generalist Full suites Nextenders IOS Partners Guadaltel European Dynamics 10 Ivalua NEQO Atexo In-tend Jaggaer 9 Bonfire SAP Ariba 8 Public sector maturity interest EASiBuy Oracle 7 Synertrade Coupa GEP 6 BiP Solutions 5 Basware Corcentric Zycus 4 ProcureTiger 3 uStudio 2 ProcurementExpress.com Marketplanet 1 Market Dojo 0 0 1 2 3 4 5 6 7 8 9 10 Functional Coverage Source: Authors CHAPTER III - MARKET SURVEY I 51 Three different types of e-GP developers can be identified: • “Generalist” full suites. These are the software developers who cover most of the required functionalities. They are not necessarily the best positioned in terms of maturity/interest for the public sector, which can be explained by their credentials with private companies. Most of these software developers have recently focused on the needs of the public sector, which is now considered to be an important growth driver. This does not mean that they are not capable of carrying out an e-GP deployment project for public organizations. It rather shows that their strategy was not oriented only towards the public sector at this stage. Moreover, the coronavirus pandemic in 2020 has grown the interest of “generalist” in the public sector. Indeed, public institutions particularly needed to control their purchase during this tough period. This category also includes the e-GP modules of the main ERP systems. • e-GP specialists. These e-GP developers cover fewer modules than the previous group, but they usually offer more advanced features in their areas of specialization. They usually have a major maturity/interest for the public sector and cover the core e-GP features: publication of public procurement contracts, specific public procedures, contract management adapted to the public sector, etc. In addition, these e-GP developers can generally more easily commit to integrating new features relevant to public clients into their roadmap if these are missing now. • Niche software developers. These software developers provide solutions that cover only a small part of the expected e-GP features, and do not necessarily aim at public procurement entities. However, their expertise on their functional coverage is recognized. HOW E-GP MODULES LINKED TO ERP SUITES The functional coverage of ERP systems remains focused on the “procure-to-pay” and transactional aspects, as well as on the management of reference data (products, articles, etc.). These e-GP modules developed in ERP suites are generally behind in terms of spend analysis, e-sourcing, and supplier information management features. There is also a superior customer experience and user- friendliness of the “best of breed” tools, particularly regarding information search, e-procurement catalogues, and workflows. Originally focused on S2C processes, specialized e-procurement vendors have grown organically and now offer sophisticated, robust, and stable solutions that compete with ERP on P2P. ERP S2C modules tend to be more complex to implement and maintain whether they are in the Cloud or on premise. Their data model tends to be less open and their ability to configure purchasing processes is more limited. In addition, even when ERPs have acquired some specialized S2C solutions to fill their functional gaps, this does not make them fully unified full-suite solutions, based on a single source code and a single database. This technological “millefeuille” becomes a major source of complexity in the build and run phases. The data collected during the study does not allow for a precise evaluation of the consequences of this complexity on project costs. However, it is commonly accepted that ERP purchasing projects have a higher project cost. 52 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 3.2.3 Average coverage of the three main functional areas by the marketplace The functional area best covered by e-GP developers is the “pre-awarding” phase—from modules 1 to 6 in our market survey questionnaire. The e-Publishing, e-Tendering, and e-Evaluation modules are those for which the suppliers cover on average more than 86 percent of the needs. The least covered modules by the e-GP developers are those related to the post-awarding phase, in particular the functionalities related to e-catalogues, and certain support functionalities—transverse search, e-signature, e-complaints, etc. COTS-based systems developers that do not cover all the functionalities state that the missing functionalities can be proposed by adding specific code. Figure 11 below shows the average functional coverage of e-GP features by e-GP developers. Figure 9: Functional coverage, by feature and phase 0% 50% 100% PRE-AWARDING PHASE 86% 1. e-Procurement Planning 80% 2. e-Publication/Notification 87% 3. e-Tendering 89% 4. e-Reverse Auctions 87% 5. e-Evaluation/Awarding 86% POST-AWARDING PHASE 61% 6. e-Procurement Planning 77% 7. e-Publication/Notification 55% 8. e-Tendering 46% 9. e-Reverse Auctions 66% SUPPORTING FEATURES 66% 10. e-Registration 56% 11. Vendor Management 76% 12. Transverse Search 36% 13. Monitoring and reporting 81% 14. e-Complaints 40% Source: Authors 15. e-Signature 58% 16. Integrity Filters 58% CHAPTER III - MARKET SURVEY I 53 3.2.4. Implementation Types proposed (SaaS, COTS, Custom) Another important element to consider and analyze is the implementation mode proposed by each software developer. The software developers were asked to state the implementation type(s) they adopt. The breakdown is presented below in Figure 12. Figure 10: Solution types provided by the 18 suppliers that responded to the survey Number of software editors providing each solution: High Medium Low SaaS 17/18 Custom 9/18 COTS 7/18 Source: Authors Several observations can be made at this stage: • The SaaS mode is considered by most software developers as the most relevant to implement e-GP solutions. • Only one software developer indicated that the Custom solution was the most adapted to the project, although the same software developer is also proposing the two other types of solutions. • Half of the software developers state that they can carry-out projects in different modes (SaaS and COTS) or even in all three implementation modes. This suggests that these software developers do not propose a SaaS model in the strict sense of the term, but they may be moving towards this model, which offers greater prospects for growth, profitability, and capitalization for the company. It is likely that these software developers are implementing a COTS approach, while trying to reduce as much as possible the customizations to avoid creating several versions of their software and therefore more easily converge towards a pure SaaS model. 54 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Moreover, it is also very interesting to cross-reference the type of solutions selected with the functional coverage, as in Figure 13 below: Figure 11: Functional coverage by solution type Custom COTS SaaS 100% 100% 100% 87% 87% Supporting Supporting 80% features features Supporting features Post- Post- awarding awarding Post- phase phase awarding phase Pre- Pre- Pre- awarding awarding awarding phase phase phase Source: Authors Custom and COTS (87 percent) are the implementation modes that were deemed the most likely to cover all needs. It is not surprising to see that Custom solutions can very broadly cover the needs, as they are tailor-made for the requirements of a given organization. But on the other hand, one may also think the coverage declared by software developers offering a Custom mode should theoretically be 100 percent, assuming no budgetary constraints exist. The coverage rate reported by software developers in Custom mode may therefore illustrate a cautious attitude about the complexity of certain e-GP functionalities, particularly features relating to catalogues and P2P processes, functionalities 7-8-9 in our analysis grid—see Appendix 2. It is also logical that the average percentage of functional coverage is lower on SaaS solutions (80 percent) since not all software developers provide full suites but tend to specialize in one part of the process. The software developers who only proposed a SaaS solution with a lesser functional coverage lowered the average of the SaaS solution model. CHAPTER III - MARKET SURVEY I 55 3.2.5. Implementing e-GP solution in Africa 3.2.5.1. Capacity to deploy in Africa All respondents stated that they were able to deploy their solution in Africa. This, even though almost none of these software developers have offices on the African continent—see Figure 14. Figure 12: Capacity to implement e-GP solution in Africa 100% of the responding e-GP developers e-GP developers suppliers (18/18) declare that with physical presence with certified they can implement in Africa in Africa (offices) partners in Africa Yes Yes 1 Yes 7 18 No 11 17 No Source: Authors To some extent, these answers are not very surprising as most of the tasks related to software integration can be done remotely. Around 25 percent of respondents declared that they could deploy functional resources on-site in Africa, even without having offices on the continent, resources travelling from Europe or the American continent. More technical resources are usually located in research and development (R&D) offices, and most software developers state that they do not deploy technical resources on-site until it is necessary. Another important topic is the ability to mobilize a certified partner in Africa, at least for COTS and SaaS. A certified partner is a company that has received an official certification attesting to its ability to implement a given software. This certification is provided by the software developer in most cases, after the partner has passed certification exams. In this study, some software developers stated that they manage implementation without the intervention of a third-party system integrator, which is common with small- to medium-size software developers. Sixty-three percent of the software developers surveyed have one or several certified partner(s) in Africa. These partners are either large generalist IT consulting firms with a presence in Africa (EY, Capgemini, Accenture), specialized e-GP system integrators, or consulting firms with a knowledge of public procurement and/or of the local culture. Several of the software developers who responded have already carried out projects for African public organizations and, in some cases, have already deployed the e-GP of an African government— for example, in Gabon, Nigeria, Tanzania, Uganda, and Zambia. 56 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 3.2.5.2. Preferred role distribution for the e-GP projects The software developers were questioned on their preferred role distribution for implementation projects. Three typical roles distributions emerged, as presented below in Figure 15. Figure 13: Most frequent implementation phase repartition Full-service Software developer Full-service 1 Software developer 2 without Run workforce 3 System integrator Certified Software Software System Certified developer developer Integrator System or Client Integrator Design, Design, Design & Build Run Build & Run Build & Run Source: Authors In the first mode, “Full-Service Software developer,” the software developer is responsible for the entire integration of the software and its application maintenance. Seventy-two percent of software developers surveyed specified that they could carry out the different phases of e-GP projects (Design, Build and Run) themselves, without relying on the assistance of a third-party system integrator. They stated having the required resources to carry out e-GP projects. Generally, they mentioned that the intervention of third-party functional consultants is often necessary to guide the business construction of the software during the Design phase. Full-Service developers usually say that they are flexible enough and that they nevertheless may be able to work with a system integrator, when customers request for it to lower their dependency on the software developer. Some software developers also specify that the customer may also wish to manage application maintenance in-house (Run). The second mode, “Developer builds and system integrator runs,” corresponds to the case where the largest part of the Design and Build workload is managed by the software developer, while the application support and maintenance is delegated to a third-party system integrator. Twenty percent of software developers surveyed stated that they systematically call on system integrators for the Run phase (for level 1 and 2 application support) or they call upon the system integrator in specific situations. CHAPTER III - MARKET SURVEY I 57 In the third role distribution, “Full-Service System integrator,” the software developer leaves the management of all project phases (design, build, run) to a certified system integrator. The system integrator intervenes as early as the design and build phase, to help the customer define its core model and implement it with configuration or customization. In this case, the software developer only intervenes a little, only to add non-standard functionalities with specific code. In the Run phase, the software developer will only intervene in case of major anomalies or evolution requests requiring work on the code. As previously mentioned, very few software developers operate on this model, which requires a certain maturity and a certain critical size to manage the certification of system integrators. Among the respondents to the questionnaire for this study, only one software developer declared that it works exclusively on this model. In theory, however, the more a software developer grows, the more it tends towards this model. Among respondents of the market survey questionnaire, 16 can handle the design and build phase themselves, one systematically calls a certified system integrator, and one works in collaboration with a system integrator most of the time. In addition, 14 software developers can handle the run phase themselves, while two will systematically call for a certified system integrator, and two will provide resources but simultaneously rely on a certified system integrator. All the respondents who stated that they could provide the workforce for design, build, and run phases also agree to delegate to a certified system integrator when the customer demands it. In any case, the distribution of responsibilities between the software developer, the external integrator, and the contracting authority is always defined in a responsibility alignment matrix (Ex: RACI type matrix) and attached to the Service Level Agreement (SLA). Figure 16 illustrates these findings. Figure 14: Implementation role distribution analysis Workforce for build Workforce for run N/A Certified integrator Certified integrator 1 1 Mix 2 2 16 14 Software developer Software developer Number of software developers by role distribution models Full service integrator Software developers without run workforce 1 3 13 Full service software developer Source: Authors 58 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 3.2.5.3 Typical e-GP Implementation Planning For the surveyed functional scope, most software developers estimate the Design and Build phases between six months and one year. The solutions for which the estimated project duration is shorter are proposed by the e-GP specialist, since they were originally designed to meet public procurement entities. Conversely, the “generalist suites” are those for which the estimated project time is 12 months, if not more. Figure 17 below captures the estimated implementation time per type of software developer. If the estimated project durations for SaaS and COTS solutions are generally shorter, the estimated durations for Custom solution projects are generally much longer for the same software developer, when several implementation types are being considered. It must be noted that this analysis of the duration of project deployment based on responses received from the survey is not perfectly accurate. It is very complicated for a supplier to estimate the duration of a deployment project without first having read the technical specifications and the size of the project (number of entities and users involved). Figure 15: Estimated implementation time per software developer type Editor type Features Implementation duration e-GP specialist • Least configurable solutions Less than Limited-scope solutions • Very specialized functionalities 6 months • Configurable solutions Generalist full-suite 6 months • Solutions covering the complete scope of functionalities to a year • Completely configurable solutions, adaptable to all needs and sizes of corporation More than Complete full-suite • Choices can be made between a wide range of available a year functionalities covering all the scope in depth Source: Authors CHAPTER III - MARKET SURVEY I 59 3.2.6. Data hosting and security 3.2.6.1. On-premises versus off-premises hosting As of today, on-premises hosting appears to be the most used for e-GP solutions implemented in Africa. For instance, all the African countries that responded to our data collection matrix indicated that they have on premise hosting for their e-GP solution. Based on this observation, authors sought to find out the on-premises implementation capacities of the various software developers surveyed. Based on the responses received, the following can be deduced: 1. On-premises hosting is not the model of choice for SaaS and COTS developers, since the support they can offer to customers in this option is generally of lower quality. • It is more difficult for the software developers to reproduce anomalies, to correct them, and to deliver patches. • The software developer loses leverage to guarantee good response times. • It is more difficult to guarantee the correct functioning of certain modules. • More fundamentally, an on-premises application requires specific processes to be put in place, which represents additional costs. 2. Software developers may agree to comply with a requirement for on-premises hosting in particular cases. Sixty-six percent of the respondents would agree to consider it, but only forty-four percent of the software developers surveyed have already done it. This is one of the first elements that software developers seem to consider when they receive a tender. Their decision to accept the hosting mode usually depends on two questions: • Are the revenue prospects with the customer deemed sufficient? • Does the specific regulatory framework (on data sovereignty, for example) and the criticality of the data circulating on the platform really require it? Before making this decision, software developers like to meet with the customers’ technical teams. This type of discussion is not always easy to arrange during the procurement phase; it is typically an issue that can be addressed during sourcing interviews prior to tenders. Christina Wocin 60 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Figure 16: On-premises experience and acceptance of the surveyed software developers Sofware developers who have never implemented their solution on-premise and would not consider to doing so 6 Sofware developers who have already implemented their solution on-premise Sofware developers who have 10 never implemented their solution on-premise but would 2 consider to doing so Source: Authors In case of on-premises hosting, all respondents strongly emphasized that their responsibility for data management is limited; the software developer only must specify the hardware requirements for hosting the solution. The client then becomes completely responsible for data security and technical administration of the servers. Most also mentioned that they are generally obliged to downgrade the service level agreements, particularly regarding the correction of anomalies. 3.2.6.2. Presentation of data hosting solutions proposed by software developers In order to identify the different data hosting offers, the questionnaire was designed to ask the different software developers contacted about their hosting capacities, especially on the issues of data security, and application security. As shown in Figure 19, of the 18 software developers who responded to the market survey, only three have their own data centers and offer to host the customer’s data directly on their premises. The other software developers rely on data hosting service providers. Figure 20 shows the distribution of software developers among hosting services firms. CHAPTER III - MARKET SURVEY I 61 Figure 17: Data hosting: internal or external hosting 15 3 External hosting E-GP developers datacenters (BIP solution Ltd, European Dynamic, In-tend Limited) Source: Authors Figure 18: Number of e-GP developers for each hosting services firm Clever Cloud OVH Noris Network 1 2 Orange 1 1 Google Cloud Platform 1 Amazon Web Services 4 Aptum Technologies 1 Telehouse 1 Echinix 1 1 CtrlS Data Center 2 Rackspace 4 Microsoft Azure Data Centers Source: Authors 62 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA The survey found that most developers use hosting vendors that host data in Europe or the United States. Today, there are very few companies in Africa specializing in data hosting that are large enough and reliable, from a security point of view, to be able to host the data processed in an e-GP system. The table and Figure 21 below. Figure 19: Number of e-GP developers for each hosting services firm Data hosting service provider mainly used by e-GP software developers Location of the data centers OVH • France Amazon web services (AWS) • USA, Brazil, United Kingdom, China, Japan, Australia CtrlS Data center • India Microsoft Azure Data centers • USA, Mexico, Canada, Brazil, Europe (France, Germany, United Kingdom, Austria, Poland, Spain, India, China, Japan, Australia, South Africa Rackspace • USA, United Kingdom, Russia, China, Australia Equinix • USA, Europe (France, United Kingdom, Germany, Italy, Spain, etc.), Middle East, China, Japan, Singapore, Australia Telehouse • USA, France, China, Singapore, United Kingdom, Japan, Turkey Aptum technologies • USA, Canada, United Kingdom Google Cloud Platform • USA, Canada, Brazil, United Kingdom, France, Germany, Spain, Italy, Netherlands, Middle East, India, China, Japan, Taiwan, Singapore, Indonesia, Australia Orange • France Noris Network • Germany Figure 20: Number of solution providers hosting data in each continent 14 12 12 10 8 9 6 4 2 2 0 0 0 0 North America Europe Asia South America Africa Oceania Source: Authors CHAPTER III - MARKET SURVEY I 63 3.2.4.3. Hosting and data security A distinction must be made between multi-tenant and single-tenant SaaS solutions. In IT, multi- tenant or multi-entity refers to a software architecture principle that allows a software to serve several client organizations from a single installation. It is different from a multi-instance (or single tenant) architecture where each client organization has its own software installation instance. Potentially on a multi-tenant application, the security holes are more important in case of error in the code. The main risk is that a user finds a loophole to access the data of other clients on the same server. It is therefore recommended to move towards “single-tenant” solutions for e-GP solutions. Not all the software developers deploy “single-tenant” architecture, and this point should be evaluated during the selection process. Most software developers or the hosting companies to which they subcontract certify their services to prove their quality. All the external hosting services providers used by e-GP developers surveyed have one or several certifications. Among these certifications, the following are the most frequent: (i) ISO27001, “Information security management;” (ii) ISO 9001, “Quality management;” (iii) SOC 1; and (iv) SOC 2. When interviewed about their data protection policy, software developers most often refer to the requirements of the contracts that bind them to the data centers. As part of the study, the software developers reported good practices that are common among data center providers. When it comes to physical security, there are common practices both among software developers with their own data centers and those using third-party hosting providers. Among the most common are: • Ensuring that the building design is secure—no windows, limited number of entries, fire escapes without grip outside the building, wall thickness, diverse barriers to limit the circulation of vehicles around the building. • Surveillance and limited access to the data center and to the physical servers. Data centers are closely monitored, with permanent security guards, video surveillance of the building itself and, in most cases, of the surrounding area. To prevent any intrusion, accesses are controlled: contactless badges, biometric recognition systems, single-person locks, permanent accompaniment of visitors by a data center employee. • Temperature control: Data centers must be kept at a constant temperature throughout the year. For this reason, they incorporate advanced cooling systems that prevent the servers from fluctuating in temperature. • Fire prevention device: The data center must be protected from fire. There are generally two types of alarms: one that will detect potential fire departure and stop it, and one that will activate fire security devices such as fireproof doors. Many hosting service providers also create a copy of the data hosted for a client in another data center, to ensure that the data will be recovered in case of damage. • Encryption: Some data centers offer data encryption at the server level, which makes the data inaccessible to anyone with physical access to the data centers. 64 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 3.2.4.4 Application Security The market research highlights that most e-GP SaaS software developers implement security policies and have very stringent security processes in place. The best practice observed by some software developers in the market study is to carry out code reviews by independent organizations. Ideally before the release of each new version to verify that new vulnerabilities have not been created. The most advanced software developers perform penetration tests with the 3-box system: black box (the testers know nothing about the application and try to get into the application by any means), grey box (One user registered on the application tries to find a flaw to acquire new authorizations), white box (the tester has access to the code and identifies security flaws in the different layers of code). Some e-GP developers even have an entire department dedicated to code security. In the framework of the market survey questionnaire, 15 suppliers out of the 18 respondents declared that their code was audited on an annual basis by a third-party company—see Figure 22 below. Figure 21: E-GP developers who have their applications audited annually No 3 25 Yes Source: Authors CHAPTER III - MARKET SURVEY I 65 3.2.5. Supplier financial model 3.2.5.1. Financial model types of the surveyed suppliers. Most e-GP developers responding to the survey typically operate with a financial model that combines a subscription fee – annual, or calculated on a quarterly basis, for example – and a license model, as presented below in Figure 23. Figure 22: Number of suppliers by financial model Subscription fee model only N/A 2 1 License mode only 6 Other 8 8 Both subscription fee and license Source: Authors 3.2.5.2. Pricing models There are two kinds of pricing models: 1. Simplified pricing models which are based on one single parameter. This is either the number of users or the number of tenders managed by the client on the platform. These two parameters are probably the ones that a government can most easily estimate. The benefit of this first model is therefore its simplicity and predictability. 2. Models with a combination of several parameters. • The combination is mainly composed by the number of tenders plus the number of contracts and/or purchase orders managed in the tool. These two parameters are related to the purchasing strategies deployed by the client (allotting, number of framework agreements, bundling of orders, etc.) and are therefore more difficult to foresee. • Combinations that consider the number of suppliers is quite rare. Only 10 percent of the e-GP developers interviewed generate revenues from suppliers who submit offers through the solution. One of these two e-GP developers even offers a no-cost model for the acquiring organization, with the entire cost of the software supported by commissions/participation fees collected from the e-GP developers. • In addition to relying on “business objects”, some models add more technical price factors: the amount of data stored, and the computing power required. To simulate the cost of acquisition, the government must therefore be able to convert business objects into units of work of an IT nature. This is certainly the least transparent and predictable pricing model. This combination seems to be used mainly by e-GP developers whose original business is the provision of tender publication platforms. 66 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA There is a relative diversity of pricing models. To ensure quality competition, governments must be able to include in the tender documents as many metrics as possible to enable all suppliers to produce a reliable costing. Figure 23 below summarizes the parameters used by e-GP developers who responded to the market survey to set the price of license: • # of users: number of agents using the software in the buying organization. Two types of users are generally considered: “full-users” and “read-only users.” • # of suppliers: number of suppliers registered. • # of tenders: number of tenders prepared and published through the system. • # of contracts: number of contracts drafted and managed through the system. • # of purchase orders: number of purchase orders created and sent to the suppliers through the system. • Quantity of data stored: total space required to store the data processed through the system. • Computing power: computing power required by the e-GP developer to run the system. Figure 23: Pricing models # of users # of signed # of Purchase Quantity of Computing # of suppliers # of tenders (government) contracts Orders data stored power used Atexo BiP Solutions Bonfire EASiBuy ProcureTiger European Dynamics GEP Guadaltel In-tend IOS Partners Ivalua Market Dojo NEQO Nextenders Marketplanet ProcurementExpress Synertrade uStudio Source: Authors CHAPTER III - MARKET SURVEY I 67 3.2.5.2. Estimated costs from the suppliers who replied to the market survey questionnaire- Based on the surveyed functional scope, the software developers were asked in the market questionnaire to estimate the cost of the Design and Build phases and the amount of licenses. Their responses on the average, minimum, and maximum amounts estimated are presented below in Figure 24. Figure 24: Amounts estimated by surveyed software developers Cost of the e-GP implementation, according to the software developers (K$) Licenses (K$/year) Design & build phase (K$) Average 265 197 Min 150 90 SaaS Max 478 300 Median 240 200 Average 220 121 Min 100 90 COTS Max 350 175 Median 200 110 Average 0 N/A Min 0 N/A Custom Max 0 N/A Median 0 N/A Source: Authors Chapter IV Cost-Benefit Analysis ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA I 69 Chapter IV Cost-Benefit Analysis 4.1. Custom, COTS, and SaaS Cost Models 4.1.1. Methodology 4.1.1.1. Parameters and convention The cost model was built based on the following parameters: • A total period of 5 years • Functional scope below: e-GP SCOPE 1. e-Procurement planning   2. e-Publication/Notification   3. e-Tendering (from the supplier’s perspective)   4. e-Evaluation/e-Awarding   11. Software developer management   13. Procurement Monitoring and Reporting Key metrics: • Intensive users (creating tenders...): 250 • Tenders (per year): 1500 • 20 Ministries • Read-only and validators: 1000 • Suppliers: 5000 70 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA The model is based on the following inputs: • The project costs (Design and Build phases) from the market survey were adjusted with some operational data from the 54 African countries surveyed. • Total implementation budgets: • For COTS and SaaS projects: The implementation budget, excluding interface and change management, is the one provided by the software developers in the market study on the functional scope mentioned above. • For Custom projects, the implementation budget was estimated by crossing two methods: • Analysis of the answers of the service providers who responded to the question (small sample). • Calculation of a target budget based on existing projects and a comparative approach of functional perimeters (definition of complexity multipliers on the functional perimeter and the interfaces between the sample projects and the study perimeter). • A typical interfacing budget was calculated with a senior integration expert. • For the Custom and COTS projects: a senior network expert estimated the size and cost of the machines, and the installation of an “on-premise” hosting service based on the above metrics. • The total budgets were then divided into different cost components (design, configuration, customization, testing, interfaces, and change management) according to typical ratios used in IT project costing models. • The model includes a relatively significant budget of $300K to carry out the communication/ awareness operations from the beginning of the project, and to implement the various training waves. This budget is slightly lower for SaaS solutions, as there is less effort to design the communication/training materials (adaptation of existing communication/ training materials). • The typical duration of the implementation modes is the theoretical duration announced by the software developers for the three implementation modes and for the functional scope under study. • Recurring costs (Run phase) are based on the results of the supplier market study and reprocessed with certain data from the African countries surveyed. • COTS and SaaS licenses: Average amounts provided by software developers. • Annual hosting costs for Custom and COTS projects: Evaluation of the cost of management, security and back-up services provided by a network expert. • Maintenance, technical, and functional administration costs according to typical ratios used in IT project management. CHAPTER IV - COST-BENEFIT ANALYSIS I 71 4.1.1.1. Cost drivers and related case scenarios Cost factors impacting the cost components mentioned above were defined. The objective is to simulate the economic impact of “unfortunate” events frequently encountered on IT projects in the three implementation modes: • Governance problems with a direct impact on the duration of the project and therefore on project management costs.13 • Lack of process knowledge and low capacity to specify/validate needs, which leads to a percentage of projects that must be abandoned and then rebuilt. • Difficulties in interfacing with existing information systems. The different cost factors have been grouped into three scenarios: • “Theoretical” scenario: Case of a project without unforeseen and undesirable events. • “Use case” scenario, which includes a certain number of undesirable events affecting the cost components. • “Degraded” scenario, which simulates a project with several difficulties/undesirable events, major changes affecting the purchasing/public procurement organization, and requiring a significant overhaul of certain functionalities or management rules during Design and Build. 4.1.2. Comparison of the cost models of the different implementation modes according to the three scenarios 4.1.2.1 Cost of the Design and Build phases The cost modeling highlights the following findings: • In the median scenario (“use case”), Custom projects cost about 2.5 times more than the implementation budget required for SaaS/COTS solutions. Figure 25: Design & Build budget per implementation type (K$) - Use case 2000 1500 1882 1000 783 707 500 Custom COTS SaaS 0 13 https://www.objectstyle.com/agile/software-projects-failure-statistics-and-reasons. 72 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA There is also a stronger tendency for Custom projects to drift from a budgetary point of view. • The difference in the “Design & Build” budget between the theoretical scenario and the “use case” scenario reflects the classic challenges encountered in IT projects (approval, need to redo, respect of deadlines). In the case of Custom project, the difference in the “Design & Build” budget between those scenarios is 22 percent. In the scenario where the project difficulties intensify (Worst case scenario), the budget drift increases to almost 60 percent higher than the “theoretical” budget. • In SaaS or COTS projects, the budget variance between the theoretical scenario and the degraded scenario is lower, as shown below in Figure 27. Figure 26: Impact of the cost drivers on the “Design & Build” budget Design & Build budget variance according to the scenarios Theoretical Use case Worst case 2600 2406 2200 1882 1800 1400 1537 Custom 993 1000 COTS 783 930 600 713 580 SaaS 707 200 The cost model shows that the selected drivers have a greater impact on the Custom budgets. • This is because of longer execution times which mechanically impact certain costs, such as project management costs – internal and external resources mobilized to manage the progress of the various teams, for example. Since Custom projects require much more effort, any lengthening of the schedule has a strong impact on the Design and Build cost. • Custom projects are very sensitive to the “redo,” because any modification heavily impacts the cost components. Each modification is complicated to manage and requires a complete software development process—specification, development, unit tests, acceptance tests. In the case of a SaaS or a Custom project with a reasonable amount of customization, it is much easier to deal with adjustments during the project. The adjustment cost will be inversely proportional to the configuration capacities of the chosen software. • Validation and decision-making difficulties have a greater impact on Custom projects, given the number of different actors/expertise to be coordinated—see description in Chapter II. CHAPTER IV - COST-BENEFIT ANALYSIS I 73 • Custom projects offer less flexibility in terms of team management. They make it harder to adapt the resources/means involved according to the progress of the project schedule. For instance, when important decisions regarding the implementation project are put on hold, it is difficult for the government to demobilize the project team. The risk is to destabilize a part of the production chain and make resources unavailable when the time comes to relaunch the activity. In the case of SaaS/COTS projects, it is easier to reach an agreement with the software developer/system integrator to postpone its intervention, for example, to delay the production launch of a module. The temporarily disengaged resources are generally invested in other projects managed in parallel by the software developer, and the “stop and go” situations are much easier to handle as there are fewer technical subjects to manage in parallel. • The field survey showed a tendency to underestimate the budget required for the change management effort. For instance, the Tunisian representatives interviewed stated that change management and communication costs were underestimated in the initial budget, which significantly slowed down the deployment. The modeling of the drivers of the project also shows that the duration of the worst-case scenario is twice as long as in the theoretical scenario (see Figure below). Figure 27: Planning Design & Build per scenario Planning sensitivity to the project inductors Theoretical Use case Worst case 30 27 25 to m Cus 20 17 15 C OT S 18 12 12 13 10 8 SaaS 6 9 5 0 In the “Worst Case” scenario, the “Design & Build” schedule for Custom projects increases to 27 months, while the COTS/SaaS schedule increases to 18 and 13 months, respectively. It is interesting to note that the average duration of the “Design & Build” phases for Custom projects (or COTS with a high degree of customization) among interviewed African countries is 25 months. This average observed duration is therefore like the “Worst Case” scenario in our model. We can therefore conclude that the worst-case scenario is highly prevalent in the e-GP projects carried out in Africa in recent years. 74 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 4.1.2.2 Total costs over 5 years (Design, Build and Run) Regarding total costs (including the recurring costs) over five years, the conclusions of the financial modeling are as follows: • In the “use-case scenario, the total cost of Custom e-GP projects over 5 years is on average 60 percent higher than for SaaS projects, and on average 25 percent higher than for COTS projects (with a reasonable amount of customization), as presented below in Figure 29. Figure 28: Cumulative e-GP ownership costs over 5 years per implementation type Total budget (Over a 5-year period) sensitivity to inductors (Budget Year N) Theoretical Use case Worst case 5000 4975 4500 4203 4000 to m Cus 3647 3643 3500 3367 C OT S 3242 3000 2916 2640 S aa S 2500 2467 Source: Authors • The costs of managing corrective maintenance, managing the technical infrastructure, and managing the various layers of the solution are higher in the Custom/COTS mode than in the SaaS mode. In the case of Custom projects, these high costs erase the “competitive” advantage induced by the absence of user licenses. For example, the cost of setting up and managing the technical infrastructure with “on-premise” hosting alone represents 9-10 percent of the total cost of ownership of the e-GP platform. • Custom and COTS solutions (with a significant proportion of customizations) are generally more expensive to maintain and administer from a functional perspective. SaaS/COTS solutions with a low proportion of customizations have administration modules that are proven by all customers. These customers have pushed for the development of functionalities that CHAPTER IV - COST-BENEFIT ANALYSIS I 75 enable productivity gains when it comes to carrying out simple operations such as modifying a user’s authorization or more complex operations such as modifying the actors or rules of a workflow. This type of “back-office” feature is generally less advanced in Custom solutions that have not been enriched by feedback from multiple customers. In addition, in SaaS/COTS projects, helpdesk and level 1 support costs are divided among customers, whereas Custom projects bear 100 percent of the functional support costs dedicated to the project. • Upgrades are also more expensive in Custom or COTS models with a large proportion of customization. Any modification is more difficult to manage and requires a complete software development loop as in the “Design & Build” phase (specification, development, unit tests, acceptance tests). 4.1.3. Cost model applied to the entire e-GP functional scope The above conclusions would probably be even more striking if the cost analysis were conducted on the entire functional scope of e-GP. Indeed, several complex features were not included in the cost model: the “e-purchasing” module (transformation of purchase requests into orders, management of receipts and payment orders), “catalog” management (hosted e-procurement catalogs, punch-out catalogs, item management) and e-signature for instance. All these areas require complex business rules. Moreover, these features also require very easy-to-use and extremely well-thought screens. Additionally, they require a significant interface capacity to be optimized. Figure 30 lists modules of an e-GP that were not included in the analysis and cost modeling. List of modules not considered in the analysis: 5. e-Reverse Auctions 6. Contract Management 7. e-Catalogues 8. Catalogue Management 9. e-Purchasing 14. e-Complaints 15. e-Signature 16. Integrity filters A comparative study of the functional and interfacing complexity of the studied perimeter and the “set aside” perimeter was carried out. It concludes that implementing all the functionalities would be 2.5 times more complex than the studied perimeter. Figure 29: Project complexity per scope 100 80 x 2,5 60 60,2 100 40 39,8 20 BCR 0 Scope surveyed Scope not surveyed Full scope 76 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 4.2. BCR Analysis The previous analysis made it possible to carry out a “Benefit-Cost Ratio” (BCR) to compare the return on investment of the different implementation types. The BCR ratio allows to summarize the attractiveness of an investment by dividing the present value of the expected benefits by the present value of the generated costs. It is a ratio widely used to compare the relative interest of different investment projects. The ratio was used here to compare the interest of investment on the three implementation modes according to the following formula: BCR Where: BCR = Benefit-Cost Ratio PV = Present Value CF = Cash Flow of a period (classified as benefit and cost, respectively) i = Discount Rate or Interest Rate (5% in this case) N = Total Number of Periods t = period in which the Cash Flows occur The “PV” of costs is based on the data from the financial modeling detailed in the previous chapter. The “PV” of benefits. It is assumed that the three modes of implementation produce the same economic effects according to the following assumptions: • Overall, public procurement spending represents on average 13 percent to 20 percent of GDP according to the World Bank’s GPPD. The low range was considered as a precaution. • Amount “processed” annually = amount of public spending that is effectively renegotiated every year = 1/3 (one-third) of the amount of public procurement spending is usually renegotiated every year. • Calculation of economic effects, inspired by the methods used in certain countries to set targets for gains achieved through cross-functional transformation projects (implementation of new levers, aggregation of demand and digitalization (1)): • No savings on 1/3 of the amount processed annually. • Moderate impact on 1/3 of the amount processed annually via increased transparency and stimulation of competition: 0.5% per year. • Important impact on 1/3 of the expenditure: 1% per year. The field study confirms these hypotheses. The African countries we surveyed mostly cited the gain related to increase in number of quotes received for “small bids.” For instance, In Tunisia, TUNEPS has allowed small value contract tenders to increase from two bids to five, on average. In Rwanda, before the deployment of UMUCYO, the average number of bids per small tender was approximately 1. Today, the average number of bids per small tender is 5.3. CHAPTER IV - COST-BENEFIT ANALYSIS I 77 4.2.1. Analysis of the BCR Ratio for countries with public procurement spending of less than $1 billion Investing in a Custom project is not attractive to these “small” countries. In the “Use case” scenario, the BCR is slightly below 1, which means that the country struggles to recover the funds invested. Regarding significant difficulties met during the Custom project (“worst case” scenario), the investment is not profitable at all. There is a significant loss of value with a BCR below 0.6. This is due both to the significant increase in the cost of implementation and to the lengthening of the deadlines which reduces the production of financial gains over the period. COTS projects do not appear to be very appropriate either, as their financial interest is rather limited with a BCR ratio of 1.37 in the “Use case” scenario and a risk of financial loss in the “Worst case” scenario with a BCR close to 1. Only SaaS projects seem to provide a financial benefit in all scenarios. From this point of view, they are the most relevant implementation types for those countries where public procurement does not reach a critical size to justify other types of implementations. Theoretical Use case Worst case Custom 1.26 0.94 0.59 COTS 1.57 1.37 1.05 SaaS 2.20 1.95 1.58 4.2.2. Analysis of the BCR Ratio for countries with public procurement spending between $1 billion and $1.5 billion For these countries, all three implementation types represent an interesting investment in the “Use case” scenario. However, the SaaS scenario offers a return on investment twice as high as Custom projects and 42 percent higher than COTS projects. In addition, in the “Worst case” scenario, SaaS continues to offer a good return on investment and COTS projects a fair return, which is no longer the case for the Custom project. For these countries, Custom projects therefore have a higher risk profile than the other two implementation types. Theoretical Use case Worst case Custom 2.27 1.72 1.06 COTS 2.83 2.47 1.90 SaaS 3.96 3.51 2.84 78 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 4.2.3. Analysis of the BCR Ratio for countries with public procurement spending of $3 billion For these countries, all three implementation types represent an interesting investment in the “Use case” scenario. However, the SaaS scenario offers a return on investment almost twice as high as Custom projects and 38 percent higher than COTS projects. In the “Worst case” scenario, SaaS and COTS continues to offer a good return on investment, which is less true for the Custom project. Once again, for these countries, Custom projects therefore have a higher risk profile than the other two implementation types. Theoretical Use case Worst case Custom 4.01 3.00 1.84 COTS 4.97 4.40 3.39 SaaS 6.84 6.02 4.53 4.3. Cost-Benefit Analysis (CBA) This chapter synthesizes the findings from the previous chapters and especially from the financial modeling, the market research, the field research, and the interviews conducted in African countries. Further, the chapter compares the benefits and drawbacks of the three implementation types on the following evaluation criteria: Time to market Project easiness Solution fit Benefits Interoperability Maintainability Security Sovereignty Total Cost of Ownership Costs Ease of budget mgt. Risks of failure CHAPTER IV - COST-BENEFIT ANALYSIS I 79 4.3.1. Time to market Custom COTS SaaS Time to market The implementation timeframe has two components: the time required for the procurement phase, the design and build phase. 4.3.1.1. A 9-month procurement process on average The field study shows that the average time of procurement of e-GP is about 9 months, regardless of the implementation type. For all three types of projects, it is theoretically necessary to define the target solution as precisely as possible: its functionalities, its interfaces with other systems, the technical architecture and security requirements. In the case of Custom projects, it is essential to have aligned the different parties on the prioritization of functionalities. It is also necessary to describe them in a sufficiently precise way so that the various providers can quote. In the case of COTS and SaaS projects, a similar prioritization of needs must be done at a precise level of granularity. The specifications sent to the service providers must include a precise list of expected functionalities (in a dedicated appendix, most often in Excel) and interfacing and security requirements. The different modes then differ more strongly in the way suppliers’ offers are evaluated. In the case of a Custom project, the assessment most often focuses on the methodology proposed by the supplier, its experience in similar contexts and the profiles used to carry out the project. In some cases, the selection process may include the presentation of a mock-up to test the providers. However, this mock-up generally presents the architecture of the menus and obviously includes few functionalities. In the case of COTS/SaaS projects, in addition to the criteria mentioned above, the evaluation goes much further on the features. In fact, it is a means of performing a gap analysis between the government’s expectations and the various solutions on the market. One of the key moments is the organization of demonstrations with the different software developers, which allow scenarios to be developed based on case studies (prepared by the service providers according to the guidelines given in the specifications by the government). The analysis conducted is therefore more precise but also heavier to drive. Feedback has highlighted several important risks in this phase that greatly influence the future success of the project. 80 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 4.3.1.2. The Design and Build Phase: Custom and COTS projects (with high level of customizations) The field study highlighted that Custom or COTS projects with a significant weight of customizations is generally spread over several years depending on the number of contracting authorities and the functional scope of the project. The average duration for these two types of e-GP projects is of 25 months for the Design and Build phases. The shortest implementation schedule observed for a relatively complete Custom/COTS e-GP system is that of Rwanda, 12 months. Figure 30: average duration of Custom / COTS projects (with high level of customization) Minimum Maximum 12 months 60 months Average 25 months The complexity of these implementation types and particularly the number of work streams to be coordinated simultaneously (see the “project complexity” parameter of the analysis) often causes project schedules to slip. On average, the countries surveyed that have opted for these types of implementations have seen a deviation of around 60 percent from the original schedule, which is consistent with the study’s modeling. Figure 31: Average shift compared to the initial schedule Average shift compared to initial schedule +130% +20% Maximum observed +60% Minimum observed CHAPTER IV - COST-BENEFIT ANALYSIS I 81 SaaS and COTS projects with low level of customizations SaaS and COTS projects with low weight of customizations are faster if the procurement process is conducted thoroughly. In practice. Getting started with SaaS software typically takes a couple of months. The study’s modeling leads to the conclusion that the planning phase in the “use case” scenario is 9 months and 13 months in the worst-case scenario. These figures are well above the average time estimated by the e-GP developers who participated in the market study (7 months). There are probably several explanations for this, including: • Most suppliers consulted have little experience of the African market and tend to underestimate the factors slowing down the implementation process • They did not want to display “non-selling” implementation times. 4.3.2. Ease of implementation Custom COTS SaaS Project easiness Custom and COTS projects with high level of customization • As detailed in Chapter II, Custom and COTS with high level of customization are very demanding projects from the “customer” perspective. When an organization decides to begin development on Custom software, it starts from scratch, and it must cover all the dimensions associated with the IT development process. The designing of customized software therefore requires significant resources and a different level of state-of-the-art expertise (please refer to Chapter II). This different expertise may be hard to find internally or even on the local market through external recruitment or IT specialized providers. • Coordinating these different expertise/tasks can also be complex. Throughout the duration of the project, the government project team must have a solid background in IT project management, allowing them to coordinate and control the progress of the various technical teams and to validate their work. The government project team would comprise System Architect, UI (User Interface), UX (User Experience), Front end Engineers, Backend Engineers, Lead Developer, resources to install and manage the technical infrastructures (servers) during the project phase. • This complexity is multiplied if the project’s governance is weak. When the functional choices (management rules, workflows, authorization matrices, data model) are not identified and decided upon upstream and it becomes necessary to “break down” to rebuild, all the technical expertise must be mobilized once again. This can lead to a lot of back-and-forth between the different technical layers of the project, which becomes very complex to manage. The project management team must also have a very detailed understanding of the business issues and functional needs. 82 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA • In Custom projects, the testing of the solution can also be very challenging. Given that the software is most often designed from scratch, it is necessary to run several rounds of testing to ensure that will be no major bug or problem related to the code. SaaS/COTS projects with low level of customizations As the features are already developed, the complexity of these projects is logically lower. As detailed in Chapter II, these projects follow a process quite different from Custom projects, with more effort put into requirements, testing, and integration; less in design and code. • Less technical expertise is needed to mobilize and coordinate on this type of implementation. Project management is therefore less caught up in technical issues and is more focused on how to model the functional expectations in the various modules of the chosen solution. Far fewer resources (personnel, know-how and machines) are needed compared to a Custom Project. The classical team is made of Software developer and/or certified integration partner resources (technical experts) in charge of the general/detailed design of the target solution, and technical experts in charge of the configuration (parametrization of the modules). • The customer’s participation is less intense than on a Custom development project, and the role focuses on the following activities: • Business needs definition and prioritization. The customer must develop a structured evaluation framework, informed by key stakeholders’ needs and priorities to ensure organizational alignment. For instance, the customer must assess the suitability of using the SaaS right out-of-the-box with only having to alter the human workflow processes to use it. • Ensuring the overall governance of the project and the steering committees that make it possible to carry out functional decisions. • Facilitating the mobilization of internal teams to ensure that the product meets expectations, particularly during the test phases. • E-GP developer will undertake interaction at technical, administrative, and commercial levels. 4.3.3. Solution fit Custom COTS SaaS Solution fit Solution fit can be defined as the ability to meet end-users’ requirements, to reflect the “business rules,” and the ease of use. CHAPTER IV - COST-BENEFIT ANALYSIS I 83 4.3.3.1. Ability to meet end-user’s requirements In theory, the main attraction of custom-built software is that all requirements can be satisfied. This is in fact an illusion. First, customer does not exactly get what he wants but more precisely what he is able to write in detailed functional specifications at the beginning of the project. Besides, resource and technical constraints main features must be prioritized. And in the end not all requirements are met. The field survey provides an interesting insight into this point. Countries that have already implemented an e-GP project were asked to evaluate the fulfillment of the original objectives assigned to their project. Fifty percent rated 6 or above out of 10, which highlights the significant discrepancies between the initial functional ambitions and the results obtained in the Custom and COTS projects, with high level of customization. The results are captured below in Figure 34. Figure 32: Achievement of original project objectives On a scale of 1 to 10, how would you rate the achievement of the original project objectives? % of respondents 10/10 7/10 12,5% 6/10 25% 5/10 12,5% 3/10 12,5% 2/10 25% 12,5% e-GP SaaS solutions typically meet most needs of most public organizations. Over time, they incorporate best practices from many public organizations into the product development to maximize customer satisfaction. After all, their very existence relies on it. In addition, public procurement regulations and the processes and organization of public procurement are quite similar between African countries. There is therefore a definite advantage in using software that has already been implemented in another public organization. Besides, SaaS solutions often produce options that public agents have not considered. But it is true that certain specificity in the management rules or very specific processes will be more difficult to translate into the solution. SaaS/COTS projects must accept flexibility in requirements. When a SaaS/COTS system is selected, some requirements are immediately satisfied, some other requirements become easy to implement, and others become difficult. On SaaS/COTS projects, the ability to reflect procedural specificity depends strongly on the configuration capacity of the chosen software—this is a major point of evaluation during the tender. In sum, these types of projects must be ready to give up very specific requirements. 84 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA On COTS projects, apart from the configuration capacity, project managers have another remedial solution: adding custom code to the components to provide the missing functionalities (Please refer to Chapter II for more detail). In several COTS projects reviewed – please see case studies in Chapter V – the selected solution lacked some required functionalities, and significant customizations were added. 4.3.3.2. Ease of use SaaS software benefits from the feedback of thousands of users, allowing the developers to improve the relevance of the features over time. There is generally a strong correlation between the number of users and the ease of use of a solution. Most SaaS e-GP developers are also engaged in a real race for ease of use. One of the strong trends of the last few years is to get business platforms to be as easy to use as Business-to-Consumer (B2C) platforms. The commonly used expression is for example to create “Amazon like” features. It is certain that SaaS e-GP developers devote a significant part of their R&D to the constant improvement of usability. For example, each new version generally includes various improvements on the user interface. It is more difficult for Custom projects to compete on this point. For example, it will be difficult to get a User Interface (UI) designer or a User Experience (UX) expert to work on the screens: the resource is scarce on the market and must be integrated into the project as soon as possible. 4.3.4. Interoperability (Ability to interface with other governmental systems) Custom COTS SaaS Interoperability SaaS/COTS solutions tend be superior on the connection with third-party applications as they come with “baked-in” application programming interfaces (APIs), which are “connectors” that allow two programs to exchange information, and which facilitate integration with a wide-range of third-party services. Open APIs allow most SaaS solution to integrate with a wide range third party software. In Custom projects, it is usually difficult to design (due to lack of experience) and implement a consistent solution with all possible interface engines. Custom solutions are generally much less advanced in their interfacing capabilities. In addition, the multitude of interfacing projects handled by e-GP developers and system integrators in SaaS mode form a learning curve that allows them to go faster and at a lower cost than a technical team that discovers the specifics of a particular interface. But ultimately, one important thing to keep in mind is that any e-GP software will only be able to integrate with third-party software if said software has built-in “gates” that allow it. It is worth checking to what extent existing software allows for this, whether you choose the SaaS/COTS route or the Custom route. If we take the example of an e-GP system that needs to transmit order/invoice information once it has been approved, it should be checked upstream whether the Integrated Financial Management Information System (IFMIS) is able to “talk” with other software – usually through APIs – and how it is able to process and receive data streams. CHAPTER IV - COST-BENEFIT ANALYSIS I 85 Explanation of the e-Procurement modules which exists in ERP applications. • Many ERPs on the market, such as Oracle, SAP, Workday, provide their own procurement modules. These modules include features including supply chain management, order management, eCommerce, vendor management, marketplace, and inventory management. The modules are tightly coupled with the other ERP modules and therefore information flows seamlessly through the system. However, the costs to implement the modules can be quite expensive as is the licensing of the procurement modules. • There are several useful functions that procurement modules of ERPs provide. These including the ability to create and manage purchase orders and make payments to vendors. Additionally, ERPs support eCommerce and have robust vendor modules allowing the vendor to submit invoices directly through a self-service feature. ERPs can also provide a rich sourcing network, minimizing the need for vendor outreach, although prepopulated vendors tend to be more oriented to the private sector. Vendor relationship management modules also help to coordinate vendor communication effectively. • Customizing procurement modules in ERPs to be compliant with public procurement regulations can be challenging and costly. Additionally, scope changes after implementation can also be expensive as the changes trickle through the rest of the ERP. Interfacing projects with IFMIS solutions often face significant challenges, regardless of the implementation type. The first difficulty is to ensure data consistency between the e-GP and IFMIS systems. Indeed, these interfaces are rarely based on real time protocols and continuous data update, because that would overload the application and severely degrade the user experience. In most cases, data is exchanged once a day in a nightly batch. Therefore, some referential data, for example, suppliers and contracts, may exist in several places with potential discrepancies. It is therefore imperative to define which system is the master over the other in order to guarantee the uniqueness and consistency of the data. These interfaces therefore require the implementation of complicated data testing and validation processes. The most advanced e-GP tools on the market have the capacity to set very precise rules such as data loading in several stages, subject to certain conditions and verification of duplicates. The finesse of the interface settings must be an important evaluation criterion during the bidding phase. IFMIS-e-GP interfaces are complex IT projects to implement. From a technical viewpoint, the functionalities of sending and receiving data – how the software technically connects to another system to deposit information – have been greatly improved over the last 10 years. Thus, it is easier to exchange “current” data “through standardized APIs and connectors. However, as soon as the data structure is modified on the e-GP or IFMIS side, the data exchange is more complex. The more projects move away from the “standard,” the greater the effort needed to adapt the tables and “toolboxes” on both sides, and the greater the need to go back and forth to develop and test the two half-interfaces (the one that “sends” and the one that “receives”). The project team must be careful not to twist the data model of the e-GP solution too much, that is, not to stray too far from the structuring of the “standard” tables in order to facilitate the maintenance of the interfaces over time. Otherwise, it can lead to great difficulties to maintain the e-GP/IFMIS interfaces. 86 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 4.3.5. Maintainability Custom COTS SaaS Maintainability Maintainability can be defined as the ease of day-to-day administration of the system on both technical and functional dimensions, the ability to improve the system over time. 4.3.5.1. Ease of technical and functional administration With SaaS/COTS mode, the e-GP developer takes care of the modifications necessary for the integration of the various software bricks that compose the solution. The developer also offers a contractual guarantee that the bricks will match perfectly. In other words, the SaaS model takes care of the integration of the basic bricks and the Customer does not have to worry about it at all. For example, the update of Single Sign On (SSO) protocols for a user identification interface will be done in a transparent way for the customer. In the Custom world, it is the technical team’s responsibility to carry out impact studies, development, and testing. From a time and cost consideration, this is more expensive than in SaaS mode, which distributes the effort and cost across all customers. The mutualized management of component versioning is also a major advantage in SaaS/COTS. SaaS/COTS developers have tools and teams that allow them to know the current versions of the various standard components used in an e-GP system, such as search engine, excel extractors, and graphic components. The software developers thus integrate the updated version into their roadmap. Experience in the field shows that Custom projects are generally not as well organized in this respect. They do not always anticipate the effort required to update components. Maintenance budgets are generally used to keep the application running as is, but do not always allow sufficient time to study the upgrades. This is a major issue, because poor control of component versions can lead to security breaches and higher costs; it is more expensive to carry out a major update in a hurry than to manage it gradually. In SaaS mode, features allowing a “non-technical” resource to handle functional administration are developed. The customer does not need any access to the technical layers of the tool in order to make usual modification on profiles, users, thresholds, and workflows. In fact, SaaS solutions anticipate functional and technical administration in their design. A large part of the design time is spent anticipating how customers will be able to change the rules they have specified at a given moment. In other words, the day-to-day functional and technical administration of the tool is considered very early in the design and development cycle. On Custom projects, it is harder to anticipate the real needs in terms of functional administration. It is quite frequent that administration functionalities developed on Custom projects are not used very often, while on the contrary some missing functionalities are badly needed. This is due to the difficulty of bringing together the functional and viewpoint on the day-to-day management of the tool upstream in the development cycle. CHAPTER IV - COST-BENEFIT ANALYSIS I 87 4.3.5.2. Ability to improve the system over time SaaS continuously incorporates customer feedback into their product roadmap. this is a strength of this type of solution and this how the developers maximize customer satisfaction, thwart competition, and ensure business success. Their existence depends on it and the customer is guaranteed that the product will evolve over time. SaaS solutions also usually follow agile development techniques, an approach that favors short development cycles and new releases at a rapid pace. As part of the process, SaaS companies incorporate extensive user testing to align product specifications with market demands. The costs of all this are integrated with their pricing model, so there are no “surprise bills” for the upgrades. The market study shows that the SaaS/COTS developers surveyed make at least one major release of their product every year, and up to two major releases annually. The analysis shows that these releases contain improvements on usability or functional administration and new features or modules. However, it is important to bear in mind that evolution requests will be considered among hundreds of others. They will probably not all be integrated in the next version because the software developer must prioritize the requests coming from multiple customers. It also happens quite often that the software developer’s roadmap is more influenced by their own strategic orientations, such as the desire to diversify with new types of customers or to counter the advances of a competitor, which do not always match with the upgrades considered as priorities by the customers. It is generally accepted that the more strategic the customer is for the software developer, in terms of finance or image, the more the requests are prioritized. Therefore, it is sometimes a good decision to use a software developer of intermediate size in order not to be drowned in the mass. In theory, custom-built software allows the customer to add or remove features as the organization grows. But in practice, once the software is built, most of the project team is disbanded and reassigned to other projects. Even when that is not the case, every evolution of the product is a mini project that takes time and money. Too many evolutions on a Custom project can result in a loss of project scope and a product that is not as effective or different from what was originally intended. 4.3.6. Security Custom COTS SaaS Security The security of e-GP solutions, which are relatively exposed to the risk of attack, has two main components: application security and data security. 4.3.6.1. Application security Generally, it is not the type of implementation that defines the level of application security but rather the intrinsic quality of the code. However, the survey has clearly demonstrated that SaaS/ COTS editors deploy greater resources to guarantee application security than Custom solutions. Ensuring a maximum level of security requires very experienced internal resources, and can be very expensive. Therefore, the advantage of the SaaS/COTS model is really that the cost of this security is distributed among all customers. 88 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA The market research found that leading SaaS software developers implement strong security policies and have very stringent security processes in place. • The best practice observed by some software developers in the market study is to carry out code reviews by independent organizations, ideally before the release of each new version, to verify that new vulnerabilities have not been created. The most advanced software developers perform penetration tests with the three-box system: (i) black box – the testers know nothing about the application and try to get into the application by any means; (ii) grey box – one user registered on the application tries to find a flaw to acquire new authorizations; and (iii) white box – the tester has access to the code and identifies security flaws in the different layers of code. • The software developers studied sometimes have a dedicated security team. As security is at the heart of their business model, SaaS software developers can dedicate much greater resources than happens for a Custom project. Among the leading software developers, security teams have 5-10 engineers dedicated to the security of the application. • According to the information received, these best practices have not been implemented on the Custom projects surveyed. 4.3.6.2. Data security The survey highlighted that there is no evidence that Custom solutions are safer on data security. It also showed that there is a real difference in maturity among software developers on this subject. As far as data hosting is concerned, there are different variants of hosting in the SaaS/COTS models. A move toward “single-tenant” solutions for e-GP solutions is recommended, to choose an e-GP developer that has been evaluated by third parties and that encrypts the data stored in the cloud. It is also worth checking the ability of e-GP developers to recover quickly from a large-scale data loss incident. This is also criteria which SaaS e-GP developers’ offer is unmatched. 4.3.7. Sovereignty Custom COTS SaaS Sovereignty 4.3.7.1. Data sovereignty Custom and COTS are generally associated with on-site hosting of the solution. In Africa, there are a several cases of pure “on-premise” hosting (servers hosted on the premises of the competent authority). But a trend seems to be developing in favor of data centers pooling the hosting of all the IT solutions used by governments. Some examples of these “government clouds” are detailed in the case studies. These two types of hosting offer substantial guarantees of data sovereignty. By definition, a SaaS e-GP system is in the cloud. But this does not mean that there is no guarantee of sovereignty: CHAPTER IV - COST-BENEFIT ANALYSIS I 89 It is technically possible for the solution to be hosted in a data center in the customer’s country. Most e-GP developers offer a “single-tenant” (multi-instance) architecture that guarantees the total partitioning of data between clients. It is possible to require data encryption at the server level that makes the data inaccessible to anyone with physical access to the data centers. The special case of software developers whose parent company is in the USA should be mentioned. Under the extraterritoriality principle of the Clarifying Lawful Overseas Use of Data Act or CLOUD Act (H.R. 4943),i an American e-GP solution developer and/or a developer hosting customer data via a data center provider subject to American law is bound to transmit all data required by the American authorities. As a consequence, the nationality of the data center provider can also be key to data sovereignty, regardless of the data server’s location. (i) The Clarifying Lawful Overseas Use of Data Act or CLOUD Act (H.R. 4943) is a United States federal law enacted in 2018 by the passage of the Consolidated Appropriations Act, 2018, PL 115-141, Division V. The CLOUD Act primarily amends the Stored Communications Act (SCA) of 1986 to allow federal law enforcement to compel U.S.-based technology companies via warrant or subpoena to provide requested data stored on servers regardless of whether the data are stored in the U.S. or on foreign soil. 4.3.7.2. Ability to manage and upgrade the tool in independent manner. All three modes allow the customer to have control over the administration of the tool in everyday life. In the Custom mode, this can be achieved by perpetuating the teams that manage the project phase and change management. Several countries interviewed stressed that it is important to provide for the financing of these teams beyond the project phase. From the projects studied, these teams have between 15 and 20 full-time equivalents (FTEs) of product owners, development and network engineers, technical and functional administrators, in addition to training and help-desk teams. If the government outsources the developments in Custom mode, it will have to carry out a transfer of know-how to internal teams, if it wishes to resource the maintenance of the application in current life. In general, Custom projects create a very strong dependency on a few key resources, especially the developers who wrote the lines of code. If the original developers leave, it is almost inevitable that something will go wrong when their code must be changed. In COTS and SaaS projects, the study observed the same need to plan and finance the governmental teams that will take care of the technical/functional administration of the solution (simple or moderately complex settings, user creation, etc.) and of change management. This involves a transfer of know-how from the software developer to the government teams: the training of administrators and their support during the handover phase must be precisely described in the specifications and the software developer/system integrator’s contract. In SaaS/COTS projects, the customer is considered autonomous to manage the simple/medium complex settings and the administration of the tool after having been duly trained. When change requests are more complex, it is generally strongly recommended to use the services of the system integrator who managed the project (or another) or to entrust these tasks directly to the software developer. SaaS COTS-based development thus introduces a certain dependence on the software developer/system integrator. The contract must precisely foresee the distribution of roles and responsibilities for dealing with the different levels of anomalies or change requests and must list all the commitments that the software developers will have to respect in terms of service level agreements (SLA) on the performance of the application and the correction times. 90 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Besides, we have seen that the government may have limited influence roadmap of the e-GP developer. During the selection phase, it is therefore important to ensure that the e-GP developer adequately covers the functional needs that are not implemented in the first project wave (or that it can interface with another solution easily to meet the need). It is also possible to ask e-GP developers to commit to delivering a feature that is not currently available. 4.3.8. Costs Custom COTS SaaS Total Cost of Ownership Costs Ease of budget mgt. 4.3.8.1. Total cost of ownership The cost model has shown that: • Implementation projects for Custom or COTS with high share of customizations cost twice as much as SaaS solutions implementation projects. In addition, the total cost of ownership over five years for Custom projects is 60 percent higher than for SaaS or COTS projects with a low share of customizations. • There is also a stronger tendency for Custom/COTS projects with high level of customizations to drift from a budgetary point of view. The difference in the “Design and Build” budget between the theoretical scenario and the “use case” scenario reflects the classic challenges encountered in IT projects (approval, need to redo, respect of deadlines). In the case of Custom projects. The difference in the “Design and Build” budget between those scenarios is 22 percent. In the scenario where the project difficulties intensify (worst case scenario), the budget drift increases with a budget almost 60 percent higher than the “theoretical” budget. The BCR approach has shown that: • For smaller countries with public procurement spending less than US$1 billion, only SaaS projects seem to provide a financial benefit in all scenarios. From this point of view, they are the most relevant implementation types for those countries where public procurement does not reach a critical size to justify other types of implementations. • For countries with public procurement spending of more than US$1.5 billion, all three implementation types represent an interesting investment in the “Use Case” scenario. However, the SaaS scenario offers a return on investment twice as high as Custom projects and 42% higher than COTS projects. CHAPTER IV - COST-BENEFIT ANALYSIS I 91 4.3.8.2. Ease of budget management The preparation and management of the budget are easier in the SaaS/COTS mode with a little bit of specification. • Financial modeling and market research have shown that SaaS/COTS is more predictable. Thegovernment can more easily have clarity on the costs related to a given functional scope. The previous chapters of this paper have also shown that it is easier to manage “waiting phases” on SaaS/COTS projects – long validation times or waiting for a regulatory change – and that “stop and go” effects are less costly. • The pricing models adopted by SaaS/COTS e-GP developers are also interesting for their flexibility. These models allow for an adjustment of the license fee according to the number of users registered on the application. In other words, the amount of the licenses will adapt to the progressive deployment of the software. In the Custom/COTS model, with a high share of specific costs, all project costs are charged to the project regardless of the actual use of the solution. 4.3.9. Risks of failure Custom COTS SaaS Risks of failure High Moderate Low The previous chapters have shown that the risk of budget and schedule slippage is much greater for Custom and COTS projects with a high proportion of specific projects. The field study clearly showed that Custom/COTS projects with a high level of specificity show a significant gap between the initial ambition and the actual realization. Other risks have been identified in the previous chapters: • Risks associated with the purchasing process. The previous chapters have shown that the evaluation of bids on Custom projects is carried out on less tangible criteria in the absence of a solution to “dissect”. On Custom projects, it is sometimes difficult to evaluate the ability of an internal or external team of developers to produce the desired application. With SaaS/ COTS projects, the risk is to conduct an insufficiently detailed study of the capabilities of the market’s solutions (in terms of functionality, integration, administration capabilities, etc.) and to ultimately choose a solution that is far from the priority expectations and incompatible with the government’s constraints. • The risk of obsolescence should also not be underestimated. The difficulty of keeping up with technological developments should not be underestimated. It is becoming more and more difficult to make the right choices and to follow the evolution of frameworks, languages, and components... In this sense, the SaaS/COTS model is more comfortable because the technological upgrade of the software developer is a condition of long-term survival and is managed in a mutualized way for all customers. 92 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA • As far as security is concerned, there is no real reason to conclude that one type of implementation guarantees better application or data security. • The risk of dependency and vendor “lock-in.” • As these are fields where skills are rare and difficult to retain, there is always a dependency on certain key profiles, especially in Custom projects. In SaaS/COTS projects, there is a real risk of dependency on the software developer and/or system integrator who may be the only one able to carry out more complex evolutions. • The worst-case scenario is to be locked in with a supplier while the solution remains unstable, incomplete or impossible to evolve within the time and cost constraints. There are a few good practices to consider in all three types of implementations to reduce dependency on the vendor(s): • The first factor that leads to lock-in situations is the inability to transfer e-GP data to a new system. Usually, contracts do include a commitment from the vendor to return the data “in a usable form.” However, the wording is often too vague, and the vendor simply hands over a “flat” data file. A good practice for e-GP systems is therefore to impose a commitment to provide the database with links between tables, without which it will remain unusable. In the SaaS model, this commitment can be a little complex to obtain insofar as the publisher considers that the links between the tables constitute its “data model” and therefore its intellectual property. To deal with this problem, another good practice has recently emerged. It consists of exporting data in real time to a “data lake” both for decision-making purposes and in preparation for a possible migration plan. • The second factor that leads to lock-in is the lack of technical skills within the government (client) teams. Regardless of the type of implementation, the client must understand at least the technical fundamentals of the solution being implemented. For example, it is crucial that the government knows how to make simple settings in the case of a SaaS or COTS project, or that they can judge the quality of the code developed by the software developer in the case of a Custom project. This technical knowledge will enable them to alert project sponsors at the right time and to make decisions on issues such as technical limitations of the chosen solution justifying workarounds, alerts on technical choices that are too complex to maintain or that present significant risks of regression over time. This technical knowledge will also make it possible to challenge the software developer’s proposals in terms of deadlines and budgets, and to better manage them throughout all the phases. In the three implementation types, know-how transfer should be organized from the early stages. In SaaS/COTS projects, there is usually a structured certification approach that allows internal teams to train and update their knowledge relatively easily. In Custom or COTS projects with a high level of customization, the best practice is to involve internal teams in the development as early as possible. • It is also necessary to formalize very clear commitments on the technical and functional documentation of the project and especially on its update during the whole life cycle of the solution. The updating of the configuration specifications (SaaS), the technical and functional specifications of the various modules (Custom/COTS), and the description of the interfaces must be included in the costing of the service providers. This requirement necessarily has a cost, but it allows to secure the project and to facilitate the transfer to a new service provider or to internal teams. CHAPTER IV - COST-BENEFIT ANALYSIS I 93 • To avoid blockages linked to tariff negotiations on the evolution of the e-GP solution, it may be helpful to set upstream the price of typical units of work (simple, moderately complex, complex evolutions) and to ensure the “relevant” qualification of evolutions over time. The more technical knowledge the government team has about the solution, the more likely it is to qualify the changes correctly. It is also advisable to contractually commit the software developer to include in its product any missing functionality, that is, non-eliminatory functionalities but “nice to have” at the time of selection. 4.4. Synthesis of the analysis Figure 35 below presents a summary of the analysis discussed in this chapter. Figure 35: Summary of Survey Results Custom COTS SaaS Time to market Project easiness Solution fit Benefits Interoperability Maintainability Security Sovereignty Total Cost of Ownership Costs Ease of budget mgt. Risks of failure High Moderate Low Source: Authors Chapter V Return on experience ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA I 95 Chapter V Return on experience 5.1. Presentation of the Case Study section As part of this study, researchers sought to learn more about the governments that have already implemented procurement software. Indeed, such an analysis should allow all interested to better understand what types of solutions are the most popular, the typical SLA conditions negotiated between governments and software developers, the most chosen hosting modes, the typical costs for these types of projects, the kinds of planning they induce. Additionally, what conclusions can be drawn from the implementation of an e-GP, what the risks are, and how to avoid them. African governments implementing/with an implemented e-GP A “Data Collection Matrix” was sent to all African governments to learn more about their e-GP projects. The matrix was divided into several sections which e-GP project managers were asked to complete. These sections were as follows: • Identity: General information about the project (WB project, type of solution, year the project started, selected software developer, system integrator, responsible entity, etc.). • Functional coverage: Section based on the definition of the core mode presented in Chapter I. • Integration complexity: Information on the interfaces developed • e-GP system key figures: Number of users, active or inactive, number of tenders, contracts, purchase orders, expenses incurred via the e-GP system, gains made, etc. • Implementation schedule: Dated description of the different phases of the project • Project costs broken down by phase (build and run), and by type (supplier costs and internal costs, license costs) • Data hosting: Data hosting methods – on/off-premises, supplier, etc. • Fees applicable to the use of the system: For example, publication fees, bid submission fees. • Feedback: Rating from 1 to 10 of the management of several issues related to the implementation of an e-GP system – user acceptance, system flexibility, change management, compliance with the schedule and budget, etc. The Data collection matrix is presented in Appendix 3. After receiving the responses from the countries and analyzing the data, further information was collected through the Data Collection Matrix by arranging interviews with the e-GP implementation project managers of the responding governments. The countries which agreed to provide more information were: Côte d’Ivoire, Mauritius, Rwanda, Tunisia, and Uganda. 96 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 5.2. Case Study #1: Rwanda OVERVIEW OF THE RWANDAN E-GP PROJECT Figure 33: e-GP Case Study – Rwanda PUBLIC AUTHORITY E-GP IMPLEMENTATION TYPE TECHNOLOGY PROVIDER COTS (Open source) KONEPS Rwanda Public Procurement Authority CONTEXT In 2013, the Rwandan government decided to build a partnership with the Korean government to develop a customized version of the Korean e-GP. Korea Telecom and the RPPA created a joint venture named African Olleh Services, in charge of developing a new version of the Korean e-GP KONEPS. When the software was finally developed, the RPPA acquired the ownership of the e-GP and became fully responsible for the maintenance and support. FUNCTIONAL COVERAGE Pre-awarding phase Post-awarding phase Suppporting features e-Procurement Planning Contract management e-Registration e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters PLANNING Partnership between End of Design & Build Deployment Rwanda and Korea Start of the Pilot Phase still in progress 2013 2014 2015 2016 2017 2018 2019 2020 2021 Creation of OAS End of Pilot Phase Beginning of the project UMUCYO becomes mandatory HIGHLIGHTS COST OF THE PROJECT Data Hosting: - The data is hosted on-premises, at the Rwanda National Data center (RNA), which hosts the data for most government systems. $12,4M Total cost since the beginning of the project Other: - Mandatory use of the e-GP for all governing bodies (100% of Total Design & Build cost $7,8M procurement spendings) Annual running costs $800K - Increase of the average number of bidding suppliers per tender Costs Overrun None - 6 interfaces developed with other systems CHAPTER V - RETURN ON EXPERIENCE I 97 PROJECT ORGANIZATION In 2013, the government of Rwanda requested the World Bank to conduct a feasibility study on the implementation of an e-GP. Following the World Bank’s recommendations, the Rwandan government decided to partner with South Korea to deploy a customized version of the Korean e-GP: KONEPS. This solution was very well known and had proven to be efficient to achieve security and transparency in public procurement.14 To achieve it, they created a joint venture between the state-owned Korea Telecom (KT) and the Rwandan government, named Africa Olleh Services (AOS). The Rwandan government contracted the development of UMUCYO with this company at the end of 2014. The design and development phase was handled by AOS, with KT providing nearly 50 developers to achieve the design and build (50 percent on-site). The Rwanda Public Procurement Authority (RPPA), in charge of the project governance, led the design phase. At the end of the partnership, after completing a knowledge transfer process from KT to the RPPA, the Rwandan government obtained ownership of the code. Today, the application maintenance is handled by the RPPA alone. Finally, the hosting of the solution is ensured by the Rwanda National Data center (RND), which is in charge of hosting most of the Rwandan government systems. PROJECT PLANNING Figure 34: UMUCYO project planning Partnership between End of Design & Build Deployment Rwanda and Korea Start of the Pilot Phase still in progress 2013 2014 2015 2016 2017 2018 2019 2020 2021 Creation of OAS End of Pilot Phase Beginning of the project UMUCYO becomes mandatory TIMELINE 2014: It took a year to establish AOS and award the development of the solution, from the moment when the partnership was signed. 2015-2016: The design and build phases lasted for 18 months, from 2015 to 2016. 2016-2018: The pilot phase was launched in 2016, lasted for 1.5 years, approximately. 2018: Beginning of the general deployment, when the use of UMUCYO became mandatory for all governing bodies Today, UMUCYO is still being deployed and enhanced. FUNCTIONAL COVERAGE 14. https://www.worldbank.org/en/news/feature/2018/09/05/how-rwanda-became-the-first-african-country-with-an-electronic-procure- ment-system. 98 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA The current version of UMUCYO is the same as the one deployed in 2018. It covers almost the entire Pre-Awarding phase (except for e-Auctions). When it comes to the Post-Awarding phase, the solution only covers the catalog management features. It has an e-contract module that only allows you to view contracts, not to modify them. The functional coverage has evolved since the deployment of the solution. Figure 35: Functional coverage of UMUCYO Pre-awarding phase Post-awarding phase Suppporting features e-Procurement Planning Contract management e-Registration e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters Although there has not been a major version upgrade, many features have been added. Here are a few examples of “small enhancements” implemented since 2018: • Enhancing bid size limit. • Enhancing reporting capacities of UMUCYO. • Automating financial bids opening for consultancy tenders. • Enhancing the linkage with IFMIS (financial management software). Many interfaces were developed from the beginning of the project. Today, there are six running interfaces with other government systems, including an interface with the government ERP System. The interface with IFMIS is very important, as the objective of the RPPA was to allow buyers to plan their procedures taking into account budgetary variables. KEY METRICS The following metrics have been reported in our Case Study Interview (2021): % of procurement value processed through UMUCYO 100% Number of governing bodies registered in the solution 210 Number of total users 2,000 CHAPTER V - RETURN ON EXPERIENCE I 99 The following metrics have been reported from 2018, in the 2018-2019 annual RPPA report: Tenders advertised 4,895 Opened 4,072 Signed contracts 4,705 Bidders who tendered at least once 2,490 Bidders awarded at least once 1,601 Total bids submitted 21,586 Total number of suppliers registered 6,456 Average bid per tender 5.3 Prior to the implementation of UMUCYO, the average number of bids per tender was approximately 1. It has increased a lot, thanks to the use of the e-GP. PROJECT COSTS The total budget invested in the Rwanda e-GP project is approximately $12 million. No cost overruns were identified. The budget spent on the design and build phase (between 2014 and 2018) was approximately $7.8 million, channeled through AOS. Since the general deployment in 2018, the application maintenance budget is estimated at approximately $800K per year. This budget takes into account bug fixes, user support, hosting costs, new features development, and hardware costs. The RPPA’s internal team dedicated to the management of the solution is estimated to be around 15 full-time people, comprising project manager, development team, procurement specialists, legal specialist, operations team (network and hardware specialists), IT specialists dedicated to databases, and support team. RETURN ON EXPERIENCE According to the Rwandan respondents, organizing the project with the Korean government and KT made it possible for Rwanda to accurately estimate the cost of the project and benefit from the experience of a well implemented e-GP. Making a joint venture with experienced e-GP owners was probably one of the key factors to avoid overruns and implement an efficient solution. It also helped a lot to develop technical features such as the interfaces. In this case, the following methods have proven to be efficient to foster the adoption of the e-GP by all the stakeholders: • Making UMUCYO mandatory to use for all governing bodies by law: • Forces all the buyers to adapt and learn how to purchase through the software. • Compels all the suppliers willing to access public tenders to use the software. • Investing in communication and training for all end-users involves: • Demonstrations/workshops/training sessions. • YouTube promotional content / user guides. • Training sessions in internet coffees. 100 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Figure 36: UMUCYO supplier YouTube guide As regards project governance, it is essential to build the project team as early as possible. Rwanda struggled during the knowledge transfer process, as their project team was not entirely built. They had to select the members in a hurry, while the training was ongoing. CHAPTER V - RETURN ON EXPERIENCE I 101 5.3. Case Study #2: Tunisia OVERVIEW OF THE TUNISIAN E-GP PROJECT Figure 37: e-GP case study – Tunisia PUBLIC AUTHORITY E-GP IMPLEMENTATION TYPE TECHNOLOGY PROVIDER COTS (Open source) KONEPS Haute instance de la commande publique (HAICOP) CONTEXT In 2011, the Tunisian government built a partnership with Korea to develop a customized version of KONEPS, the Korean e-GP, which had proven to be a valuable tool to foster e-procurement and therefore improve public procurement transparency and efficiency. Today, TUNEPS is perfectly running and is being deployed over the whole country. The HAICOP is the sole owner of the code, maintains the solution and enhances it with the help of private IT providers. FUNCTIONAL COVERAGE Pre-awarding phase Post-awarding phase Suppporting features e-Procurement Planning Contract management e-Registration e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters PLANNING Partnership with Korea Beginning of the & selection of private pilot phase Deployment IT providers 1st tender publication still in progress 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 12 months 60 months 28 months Beginning of the End of Pilot Phase Design & Build phase TUNEPS becomes mandatory HIGHLIGHTS COST OF THE PROJECT Data Hosting: - The data is hosted on-premises, at the CNI (National Computer Center), which hosts the data for most government systems. $5,7M Total cost since the beginning of the project Other: - 40 % of specific code added to the original Korean software Total Design & Build cost N/A - Mandatory use of TUNEPS for all governing bodies Annual running costs N/A - 4 interfaces developed with other systems Costs Overrun None 102 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA PROJECT ORGANIZATION In 2011, the Governments of Tunisia and Korea signed a partnership to develop a customized version of KONEPS for Tunisia. Given the difference between public procurement laws in Korea and in Tunisia, much customization was needed . At first, Haute Instance de la Commande Publique (HAICOP) was planning to develop specific code “in-house,” with internal IT resources, and the Korean experts would only have to provide the standard version of KONEPS and train HAICOP resources to maintain and enhance it. However, due to the lack of technical resources at the time, HAICOP had to call for external and private operators to support them in the development of specific features. This customization was financed through fundraising. Today, HAICOP is the sole owner of the code and it maintains the e-GP with internal resources, providing assistance to the users and fixing issues. HAICOP also keeps enhancing the solution with the help of private operators. The solution is hosted on premises, at the CNI (National Computer Center) of Tunisia, which hosts most government systems. PLANNING OF THE PROJECT Figure 38: TUNEPS Project planning Partnership with Korea Beginning of the & selection of private pilot phase Deployment IT providers 1st tender publication still in progress 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 12 months 60 months 28 months Beginning of the End of Pilot Phase Design & Build phase TUNEPS becomes mandatory TIMELINE July 2011: Signing of the financing agreement. Creation of the Technical and Steering Committees. July 2011 - December 2011: Selection of private operators to assist in the design and build phase. 2012: Design and Build phase (12 months). 2013: Official inauguration of TUNEPS; the project is ready to be deployed. Launching of the selection process by KOICA to designate the officer in charge of developing the e-Procurement system in Tunisia. June 2014: First tender published. June 2014-2018: Gradual deployment over pilot entities, the largest entities in terms of public expenditure. In 2018, following the positive results of the “pilot” phase, the Tunisian government promulgated a decree making the dematerialization of public procurement via TUNEPS mandatory.15 The decree provided for a progressive adherence: first public companies, then ministries, followed by non- administrative public establishments and, finally, a generalization to communities.16 15. https://chroniques.tn/2019/05/tuneps-le-nouveau-systeme-tunisien-dachats-publics-en-ligne-obligatoire-a-partir-de-01-septembre-2019/. 16. https://www.webmanagercenter.com/2014/06/18/151461/tunisie-marches-publics-tuneps-tn-une-avancee-dans-la-bonne-gouvernance/. CHAPTER V - RETURN ON EXPERIENCE I 103 FUNCTIONAL COVERAGE Figure 39: TUNEPS functional coverage Pre-awarding phase Post-awarding phase Suppporting features e-Procurement Planning Contract management e-Registration e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters The current functional coverage is complete, but it required a significant amount of customization work in 2012. It is estimated that Custom features represent 40 percent of the total features of the current e-GP. Custom features developed during the design & build phase included: • Authentication and user profiles. • Contracts and small value procurement. • Notifications. • Reporting/Mailing. • Excel upload for supplier bids. The functional coverage of TUNEPS is continuously being enhanced, and HAICOP is planning on adding the following features: • e-Payment (approval of invoice, interface with government ERPs). • Contract management and contract spends monitoring. • Litigation management. For contract management, the feasibility study recommended the development of a Custom system, interconnected with TUNEPS. A tender to select a private operator to develop it is ongoing. As for the interfaces, 3 are developed and fully functional: • One interface with the governmental financial IS allowing to verify the attestation related to the tax status. • One interface with the social security system allowing to verify the affiliation of the bidder to a social security system. • One interface with the central bank’s IS allowing the transmission of the interbank exchange rate (for the conversion of bids in foreign currencies). 104 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA In 2020, Korea and Tunisia partnered again to launch the TUNEPS 2 project17 to enhance the current solution, adding new technologies such as a Training center, hardware equipment, cloud technologies, and software update. KEY METRICS The following metrics were obtained from the interview with the Tunisian respondents: Number of public buyers registered on the solution (users) 1,350 Annual number of tenders processed through the platform 6,000 Number of suppliers registered in TUNEPS 12,00018 One the main benefits is the increase in the average number of offers for small purchases, from three before TUNEPS was implemented, to 5 today. PROJECT COSTS In 2011, the estimated total cost of the project was approximately $5.7 million. The Design and Build costs were approximately $4.8 million. The Annual running costs since 2014 are approximately $155,000 per year ($935,000 over six years), including $72,000 of hosting fees. At this point, no cost overruns have been identified. Money is still being spent to enhance the software; the e-contract management module is to be developed soon. In 2021, the staffing of HAICOP’s “e-Procurement Unit” is estimated at approximately 19 FTEs, divided into three groups: (i) a project management group, with seven FTE; (ii) a technicians/engineers group of six FTE (two development engineers, two system engineers, one network engineer, one person dedicated to the testing); and (iii) a Helpdesk group of five FTE; plus one full-time assistant. RETURN ON EXPERIENCE In terms of project organization: • When designing the project teams, ensure that you have enough technical resources to be autonomous in the development of specific features. Since HAICOP did not have the required internal resources, and decided not to recruit, they had to call upon private operators to develop specific code. • The initial budget did not consider the communication and awareness-raising components, which made it harder during the implementation phase for everyone to adopt the solution. The budget also underestimated the scope and importance of this component of the project. It is therefore recommended that, from the outset, an action plan for deployment/communication and associated funding should be planned. When 17. the solution is ready to be deployed: https://africanmanager.com/25-musd-de-la-coree-du-sud-pour-le-tuneps-2/. 18 •https://www.oecd.org/mena/governance/improving-e-procurement-environment-tunisia-fr.pdf CHAPTER V - RETURN ON EXPERIENCE I 105 • Making the use of the e-GP mandatory for all governing bodies is a great incentive to foster a global adoption of the software. • It is necessary for the government to provide funds to guarantee the maintenance of operations and the improvement of the e-GP system. In the Tunisian case, HAICOP’s e-procurement unit should have an allocated budget in order to anticipate the end of the budgets provided by the fundraisers. • It would also be interesting to give HAICOP a regulatory authority over the e-GP system. 106 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 5.4. Case Study #3: Uganda OVERVIEW OF THE UGANDAN E-GP PROJECT Figure 40: e-GP case study – Uganda PUBLIC AUTHORITY E-GP IMPLEMENTATION TYPE TECHNOLOGY PROVIDER COTS EUROPEAN DYNAMICS Public Procurement and Disposal of Public Assets Authority CONTEXT After conducting a study with EY, the Public Procurement and Disposal of Public Assets Authority awarded the development of the Ugandan e-GP to European Dynamics. The initial objective was to build an end-to-end S2P suite, mandatory for all governing bodies. The portal was developed within 4 years and is currently at the pilot phase. At the same time, the Ugandan government has initiated a new project to develop internally another e-GP, to be ready by 2023. FUNCTIONAL COVERAGE Pre-awarding phase Post-awarding phase Suppporting features e-Procurement Planning Contract management e-Registration e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters PLANNING Preliminary study Awarding to ED with EY to design Beginning of the Pilot phase the core model Design & Build phase still in progress 2014 2015 2016 2017 2018 2019 2020 2021 8 months 28 months 24 months 18 months Beginning of the End of the D&B phase procurement phase Beginning of the Pilot phase HIGHLIGHTS COST OF THE PROJECT Data Hosting: - The data is hosted at The National Information Technology Authority-Uganda (NITA-U), an autonomous statutory body. $4,15M Total cost since the beginning of the project Other: - 75 % of specific code added to the original software Total Design & Build cost $1,55M - Shift compared to initial schedule: 50% Annual running costs $876K - No interface due to high development costs4 Costs Overrun None - New homegrown e-GP project started CHAPTER V - RETURN ON EXPERIENCE I 107 PROJECT ORGANIZATION The Public Procurement and Disposal of Public Assets Authority (PPDA) conducted a preliminary study with Ernst & Young (EY) to design the core model of their e-GP. Following this, the PPDA decided to select a private software developer to develop their e-GP. After a procurement phase, they awarded the development to European Dynamics (www.eurodyn.com). An information and communications technology (ICT) team was formed to work in liaison with the software developer.19 European Dynamics oversaw: the Business Process Reengineering assignment that was conducted at the beginning of the implementation project; .defining the detailed specification of the e-GP system; and building the e-GP system. The Ugandan government is considering develop a new homegrown procurement system (internally developed). The allocated budget for this new project is approximately $4 million, and the new e-GP system is expected to be ready by 2023. PROJECT PLANNING Figure 41: EPP project planning Preliminary study Awarding to ED with EY to design Beginning of the Pilot phase the core model Design & Build phase still in progress 2014 2015 2016 2017 2018 2019 2020 2021 8 months 28 months 24 months 18 months Beginning of the End of the D&B phase procurement phase Beginning of the Pilot phase TIMELINE 2015: A study was conducted by PricewaterhouseCoopers to specify the target solution. 2016-2018: Procurement process (28 months) – gathering of all functional requirements, opening of international bids. European Dynamics was the most suitable bidder, out of 15. December 2017: Awarding of the contract to European Dynamics. 2018 – July 2020: Design and Build phase (20 months). July 2020: Beginning of the pilot phase.20 The project is currently at the pilot phase. The shift compared to initial schedule is approximately + 50 percent. 19. https://www.ppda.go.ug/download/ppda_annual_reports/ppda_annual_reports/PPDA-Annual-Report-2017-2018.pdf. 20. https://www.devdiscourse.com/article/other/1174598-uganda-civil-aviation-authority-launches-egp-system-to-unclog-pro- curement-process. 108 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA FUNCTIONAL COVERAGE Figure 42: EPS functional coverage Pre-awarding phase Post-awarding phase Suppporting features e-Procurement Planning Contract management e-Registration e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters Today the solution is an end-to-end source to procure suite. However, at the start of the project, some key functionalities were missing. The estimated amount of Custom developed features is 75 percent of the final solution, which makes it an “almost Custom” project. The 25 percent not customized were essential for the solution to centralize the procurement processes of different entities. More importantly, the only interfaces that were developed are: integration with the business registration system; integration with the SMS notification gateway; and integration with the Social Security Fund compliance system. However, this is not satisfactory, given that the original objective was to link the system to the e-Tax payment and gateway system, and the IFMIS system. However, it became quickly clear that 35 percent of the total contract amount would be spent for the development of interfaces for the 10 governing bodies taking part in the pilot phase. This means that it would be very expensive to extend the software to all contracting authorities. Management did not approve this change request. This is the reason why the Ugandan government is considering developing their own homegrown e-GP. KEY METRICS The following metrics come from the Data collection matrix that was sent to the government. Ugandan officials confirmed this information during the follow-up interview. Current total number of users registered in the solution 1,000 Current number of suppliers loaded in the solution 3 Number of public organizations registered in the solution 10 The platform is currently unable to integrate suppliers. CHAPTER V - RETURN ON EXPERIENCE I 109 PROJECT COSTS Cost repartion during the design and build phase (in K$) Design Project management assistance 99 350 Change requests 200 900 Build The estimated total budget for this project is $4.15 million. The total budget for the design and build phase (2018-2020) was $1.24 million, distributed as follows: • Design $99,000. • Build: $900,000. • Change requests: $200,000. • Project management: $350,000 of project management. These figures do not take into consideration internal costs. The annual running cost paid to European Dynamics is $873,000 per year, without the hosting costs. However, since the contract was terminated in 2021, the Uganda government will not invest more in maintenance for the coming years. RETURN ON EXPERIENCE It appears that the Ugandan government is not fully satisfied with their current solution due to: the delay caused by the strong need for customization; and incapacity to develop interfaces at affordable cost. In order to prevent this from happening in a similar project, the Ugandans recommend the following practices to acquire an e-GP system. • Detail the requirements related to the integration with other systems during the procurement phase and define clear commitments about the interfaces in the contract. It is very important for the acquiring (client) organization to provide as many details as possible on the technical requirements, on the processes as they should be reproduced in the app, and on the interfaces with other systems. • It is better to check the understanding and the interpretation of the requirements during tender. The tendering procedure must allow for demonstrations (of system and vendor capability, for example) and due diligence. • The software developer should have local presence in the country; it takes a lot of time to discuss things online. Proximity helps to speed up the project. A local presence would have helped a lot in knowledge transfer so that maintenance and support would have been easier. • Clarify the governance: need for one deciding structure/organization that will cut off all the disagreement. • Call on the services of a project management ownership consulting firm right from the beginning. 110 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 5.5. Case Study #4: Mauritius OVERVIEW OF THE MAURITIAN PROJECT Figure 43: e-GP Case study - Mauritius PUBLIC AUTHORITY E-GP IMPLEMENTATION TYPE TECHNOLOGY PROVIDER COTS NEXTENDERS SIFY TECHNOLOGY Public Procurement Office (PPO) CONTEXT In 2013, the government of Mauritius selected Nextenders and Sify technology to develop their e-GP system. Both companies were in charge of adapting their existing system and maintain it after the implementation. Their implementation methodology was very original : they decided to deploy the software before it was fully developed, and they have been continuously enhancing it ever since. The code is owned by the providers. FUNCTIONAL COVERAGE Pre-awarding phase Post-awarding phase Suppporting features e-Procurement Planning Contract management e-Registration e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters PLANNING Awarding of the contract 1st tender publication to Nextenders The solution is gradually deployed, Beginning of the Design phase while being developed 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 12 months 48 months 26 months End of design Roadmap achieved Beginning of the Build phase The solution is fully deployed HIGHLIGHTS COST OF THE PROJECT Data Hosting: - The System is hosted on premise, by the government of Mauritius, on the government Cloud. $2,98M Total cost since the beginning of the project Other: - High specific code added to the original Korean software Total Design & Build cost $1,45M (60% of the maintenance cost is dedicated to enhancement) Annual running costs $300K - 90% of procurement spend processed through the solution Costs Overrun None CHAPTER V - RETURN ON EXPERIENCE I 111 PROJECT ORGANIZATION The solution is called ePS. The project type is COTS, based on the Nextenders solution (India). The contract was awarded to a consortium of Nextenders and Sify Technology. The consortium took charge of all the phases – design, development, testing, training, change management – of the project, along with the government internal resources that were allocated to the ePS implementation. The solution was not deployed all at once; the modules were installed one after the other as they were developed. Since the solution was deployed, maintenance of EPS has been outsourced to Nextenders, in liaison with the Public Procurement Office of Mauritius.21 PROJECT PLANNING Figure 44: EPS Project Planning Awarding of the contract 1st tender publication to Nextenders The solution is gradually deployed, Beginning of the Design phase while being developed 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 12 months 48 months 26 months End of design Roadmap achieved Beginning of the Build phase The solution is fully deployed TIMELINE 2013: Awarding of the contract to Nextenders and Sify Technology. 2014: Design of the core model of the solution, beginning of the build phase, expected to last 18 months. September 2015: Deployment of the software, publication of the first tender. The solution is not yet complete, and the roadmap is not achieved. But the Mauritian government decided to deploy anyway and to keep enhancing the software while it runs. 2015 – 2017: Build phase; the solution is gradually deployed as new features are developed and ready to be implemented. July 2017 – December 2018: Warranty period. 2019 - date: The roadmap is achieved, the original model is complete, and the solution is fully deployed. It is still being enhanced. In all, it took 60 months to design and develop the core model. Since the design and build phase was expected to last 18 months at most, this means a delay of 230 percent in delivery schedule. The delay was caused by the amount of customization required to meet the initial expectations. No specific governance issues were identified. 21. Mauritius Digital Government Summit 2014 e-procurement System G2G G2B G2C P. Goburdhun Member, Procurement Policy Office 8th October 2014; Organized by the Ministry of Information and Communication Technology, Republic of Mauritius. 112 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA FUNCTIONAL COVERAGE The ePS covers the pre-awarding phase entirely. Currently, it does not cover post awarding features, beside contract management. As the solution is still being enhanced (with 60% of the maintenance fees allocated to the development of additional features). In 2020, two new features were added: e-Auctions and Contract Authoring. EPS is not interfaced with any other application/database from the Mauritius state. The effort to integrate with government tools (e.g., accounting and financial tools) was considered too extensive, particularly because of the limited exchange capabilities of these systems. Figure 45: EPS functional coverage Pre-awarding phase Post-awarding phase Suppporting features e-Procurement Planning Contract management e-Registration e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters KEY METRICS The following metrics come from the Data collection matrix completed by the Mauritian government, and confirmed by Mauritian officials in the follow-up interview. Number of suppliers registered in the solution (2020) 3,205 Number of tenders published through EPS (2020) 2,750 Savings made through the use of ePS 20% PROJECT COSTS The total project cost is estimated to be $2.98 million. The Design and Build phase cost approximately $1.45 million. The annual running costs is $300,000 per year, totaling $1.53 million since the deployment in 2015. Sixty percent of the maintenance cost is allocated to enhancements. Within the PPO (Public Procurement Office), a team of 12 FTEs is dedicated to ePS. This team oversees system administration, Help Desk, Single Point of Contact (SPOC), training, testing, and project management. CHAPTER V - RETURN ON EXPERIENCE I 113 RETURN ON EXPERIENCE Strong sponsorship within all the government bodies and committed support of all the stakeholders is required to achieve the e-GP implementation. Change management is underestimated: • In Mauritius, many buyers from government bodies are reluctant to using IS, when they have been working with other methods for more than 30 years. • Some suppliers also tend to be reluctant to use the new system, given that they have been proceeding differently for years, and given that it makes all procurement procedures fully transparent. When it comes to the maintenance of the solution, the contract/SLA should include escalation mechanisms in case of recurring errors. 114 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 5.6. Case Study #5: Ivory Coast PROJECT OVERVIEW Figure 46: e-GP case study - Ivory Coast PUBLIC AUTHORITY E-GP IMPLEMENTATION TYPE TECHNOLOGY PROVIDER SIGOMAP Custom N/A Public Procurement Office (PPO) CONTEXT In Ivory coast, there already was a public database gathering all public contracts. The Public procurement Office has begun a project of e-GP development in 2019, to extend the perimeter of its by designing the core model of the solution. The Ivory Coast has divided the functional coverage into 2 perimeters that will be developed over 2 different project phases. Perimeter A covers e-Planification, perimeter B covers e-Publication to e-Awarding. FUNCTIONAL COVERAGE Pre-awarding phase Post-awarding phase Suppporting features e-Procurement Planning Contract management e-Registration e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters PLANNING Beginning of the Design phase 2018 2019 2020 2021 24 months The design of the core model is complete, there is currently a feasibility study going on to estimate the impacts and technical requirements to develop perimeter A HIGHLIGHTS COST OF THE PROJECT Data Hosting: - The solution is completely developed from scratch, with internal resources of the Public Procurement Office. N/A Total cost since the beginning of the project Other: - The System will be hosted off-premise, by the SNDI, in Ivory Coast. Total Design & Build cost N/A Annual running costs N/A Costs Overrun N/A CHAPTER V - RETURN ON EXPERIENCE I 115 PROJECT ORGANIZATION In March 2019, the Ivorian government launched a project to develop their e-GP, named SIGOMAP. The tool is intended to complement the functionality of SIGMAP, the country’s public procurement referencing tool. The decision was made for a Custom solution. The project is divided into two scopes, A and B, which will be developed in turn. Scope A covers the e-Procurement planning and Scope B covers the rest of the S2C process, from publication to contract award. In parallel with the design phase, an impact study is being conducted to identify the changes induced by the deployment of such a solution as well as the needs in terms of resources. PROJECT PLANNING Figure 47: SIGOMAP project planning Beginning of the Design phase 2018 2019 2020 2021 24 months The design of the core model is complete, there is currently a feasibility study going on to estimate the impacts and technical requirements to develop perimeter A October 2019: Beginning of the project, gathering the functional requirements, and conception of the structure of the solution. Drafting of the specifications. 2021: Core model is designed. After that, a feasibility/impact study is being conducted to implement Scope A. FUNCTIONAL COVERAGE The target functional coverage should be the following: • E-Procurement Planning • E-Publication • E-Tendering • E-Evaluation • E-awarding SIGOMAP is still under development. 116 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA KEY METRICS The are no metrics yet, since the solution has not been deployed. PROJECT COSTS No forecasts or budget were obtained for this project. The internal team of the Ivorian government, dedicated to the development of Scope A, comprises: a project manager, key users, mobilized for 15 months for 10 percent of their time, development team (seven full time developers. RETURN ON EXPERIENCE The reasons why the Ivorian government favored custom development are: • Difficulties in the past to make software developers understand the concepts/processes of public procurement. • Willingness to have total control of the system from start to finish. • Willingness to make the IS evolve quickly according to the regulatory evolutions, which can be numerous. The Custom mode seemed to be the most suitable to integrate these changes and to make the e-GP system evolve more quickly. CHAPTER V - RETURN ON EXPERIENCE I 117 5.7. Nigerian States SaaS e-GP Framework Agreement An example of a successful deployment of a framework agreement for GovTech procurement comes from Nigeria, where the Kaduna State Public Procurement Authority served as the lead purchaser and represented a group of purchasers to procure a SaaS electronic government procurement (e-GP) suite.22 The framework agreement was structured for award to a single vendor for a period of three years. By using the framework agreement approach, the purchasing group was able to streamline the procurement procedure for all 36 states in Nigeria. As a result, instead of each state running its own individual procurement process, all Nigerian states can sign call-off contracts with the same terms and conditions as stated in the framework agreement with the winning vendor. 22. Kaduna State Procurement Authority, “Request for Bids, Framework Agreement(s) for Procurement of Information Service – Software as a Service,” December 18, 2019, http://procurement.edostate.gov.ng/wp-content/uploads/2019/12/Request-for-Bids.pdf. Conclusion ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA I 119 Conclusion Most African countries which have launched e-GP projects have chosen either to implement Custom solutions or COTS solutions with a significant share of customizations. Four main reasons are generally cited for this decision: (i) IT and data security; (ii) the guarantee of sovereignty offered by this implementation type; (iii) the specificity of the processes and management rules which make it difficult to implement a “pre-package” software; and (iv) the need to make the system evolve more easily without depending on a private operator. This survey demonstrated that the choice to implement Custom or COTS solutions with significant customizations was not necessarily the most appropriate for several reasons: 1 Projects featuring Custom and COTS with high proportion of customizations are identified as the most complex and risky projects. They are very demanding, from the customer perspective. 2 Custom and COTS with high proportion of customizations are more likely to cause budget or schedule drift, while SaaS projects are less prone to this risk. Custom or COTS projects with a significant proportion of customizations are generally spread over several years, depending on the number of contracting authorities and the functional scope of the project. On average, the countries surveyed that have opted for these types of implementations have seen a deviation of around 60 percent from the original schedule. Difficulties related to project governance affect this type of project more heavily and amplify budget and schedule deviations. 3 There are significant discrepancies between the initial functional ambitions and the results obtained in the Custom and COTS projects with high proportion of customizations. Many SaaS e-GP developers specialized in the public sector now offer pre-packaged solutions that integrate the possibility of adapting to regulations and constraints related to public procurement. These specialized solutions already contain key functionalities for public purchasing organizations, such as e-Publication, e-Tendering, e-Evaluation, and functionalities ensuring supplier transparency and integrity. These players have a great deal of experience and their solutions have been tested with many public customers. This ensures their capacity to implement projects in different business contexts. Some e-GP developers have already developed and implemented very complex e-GP solutions in various countries. 4 The running costs of a Custom solution (maintenance, evolution, support, hosting, etc.) are very high, compared to SaaS/COTS with low share of customizations. The maintainability of a SaaS solution is higher through better component versioning, robust administration modules, and since all other “running activities/costs” are distributed across the different customers. 5 SaaS and COTS solutions are superior on the connection with third-party applications as they come with “baked-in” APIs, which are “connectors that allow two programs to exchange information, and which facilitate integration with a wide-range of third-party services. 6 Custom solutions are not safer than the other two types. The survey clearly demonstrated that SaaS/COTS software developers deploy much more resources for application and data security than Custom solutions. In addition, it is very rare that Custom solutions developed in-house are audited by third-party organizations. 120 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS CHAPTER V - RETURN ON EXPERIENCE FOR AFRICA 7 Hosting data in the cloud does not necessarily mean that there is no guarantee of sovereignty: • It is technically possible for the solution to be hosted in a data center in the customer’s country. • Most e-GP developers offer a single-tenant (multi-instance) architecture that guarantees the total partitioning of data between clients. • It is possible to require data encryption at the server level that makes the data inaccessible to cyber pirates or anyone with physical access to the data centers. Finally, it is highly recommended that a preparation phase be carried out upstream of the project to ensure that the procurement needs of the various government entities are properly identified and framed, resulting in: • The Identification and prioritization of needs. • A mapping of internal processes and flows. • A matrix of benefits and costs related to the project. • An inventory of current applications used by the government. • A precise supplier sourcing that enables the client to know upstream which e-GP developers will be able to submit relevant offers during the tender phase. • A complete consultation file, including precise data on: • The interfaces to be developed with other systems • A precise estimate of the entities that will have access to the solution and the different users • A precise estimate of the volume of operational data that will be managed via the solution All this information equips suppliers to provide a relevant costing for the project. On the other hand, insufficiently accurate RFP documents can inhibit e-GP developers’ responses. To ensure complete, quality preparation, it is recommended that the client calls upon project management support firm to provide technical and functional expertise in the preparation of the project. ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA I 121 References Chapter II – Presentation of the implementation types • Debunking seven common myths about cloud, McKinsey (October 2020). • https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/ debunking-seven-common-myths-about-cloud. • Software Development Handbook Transforming for the digital age.pdf, McKinsey (January 2016). • https://www.mckinsey.com/industries/technology-media-and-telecommunications/ our-insights/software-development-handbook-transforming-for-the-digital-age. • Introducing a Commercial Off-The-Shelf Software Solution, OECD (2019). • https://www.oecd.org/tax/forum-on-tax-administration/publications-and-products/ introducing-a-commercial-off-the-shelf-software-solution.pdf. • https://www.pmi.org/learning/library/custom-off-the-shelf-strategy-6137. • https://www.nbcnews.com/tech/security/ponemon-institute-n364871. • https://www.veracode.com/state-of-software-security-report. • https://cio.economictimes.indiatimes.com/news/digital-security/by-2022-at-least-95-pc- of-cloud-security-failures-will-be-organizations-fault/65438790. • https://analyse-innovation-solution.fr/publication/fr/php/objet-pdo-et-securite-mysql. Chapter III – Market Survey Appsruntheworld website, and studies: • https://www.appsruntheworld.com/top-10-procurement-software-editors-and-market- forecast/. • https://www.appsruntheworld.com/cloud-top-500/Procurement/. Software developers responses to the Market Survey Questionnaires and additional documents they provided • Please refer to Annex 2. African governments responses to the Case study data collection matrix • Please refer to Annex 3. 122 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Software developers websites: • http://www.atexo.com/. • https://www.ariba.com/. • https://www.coupa.com/. • https://www.ivalua.com/. • https://www.procuretiger.com/pt/. • https://synertrade.com/en/. • https://www.zycus.com/. • https://www.basware.com/en-en/home/. • https://www.gep.com/. • https://www.neqo.eu/. • https://www.jaggaer.com/. • https://www.bipsolutions.com/. • https://www.procurementexpress.com/. • https://gobonfire.com/. • https://www.eurodyn.com/. • https://www.eauctionservices.com/. • https://marketdojo.com/. • https://www.guadaltel.com/. • https://www.in-tend.co.uk/. • https://www.nextenders.com/. • http://iospartners.com/. Chapter IV – Cost-Benefit Analysis The conclusions are mainly based on the analyses made in the previous sections and on the case studies. Some additional documentary resources were used: • https://www.information-age.com/projects-continue-fail-alarming-rate-123470803/ • https://www.objectstyle.com/agile/software-projects-failure-statistics-and-reasons REFERENCES I 123 Chapter V – Return on experience Preliminary research (per country) RWANDA: • UMYCIO platform: https://umucyo.gov.rw/. • World Bank GPPD: https://www.globalpublicprocurementdata.org/gppd/. • https://www.worldbank.org/en/news/feature/2018/09/05/how-rwanda-became-the-first- african-country-with-an-electronic-procurement-system. • Data collection Matrix results—refer to Appendix 3. • Interview with the project management team. TUNISIA: • TUNEPS platform: https://www.tuneps.tn/index.do. • World Bank GPPD: https://www.globalpublicprocurementdata.org/gppd/. • https://chroniques.tn/2019/05/tuneps-le-nouveau-systeme-tunisien-dachats-publics-en- ligne-obligatoire-a-partir-de-01-septembre-2019/. • https://africanmanager.com/25-musd-de-la-coree-du-sud-pour-le-tuneps-2/ • https://www.oecd.org/mena/governance/improving-e-procurement-environment-tunisia-fr.pdf. • https://www.webmanagercenter.com/2014/06/18/151461/tunisie-marches-publics-tuneps- tn-une-avancee-dans-la-bonne-gouvernance/. • Data collection Matrix results—refer to Appendix 3. • Interview with the project management team. UGANDA: • Government Procurement Portal (GPP): https://gpp.ppda.go.ug/. • World Bank GPPD: https://www.globalpublicprocurementdata.org/gppd/. • https://www.devdiscourse.com/article/other/1174598-uganda-civil-aviation-authority- launches-e-GP-system-to-unclog-procurement-process. • PPDA Annual report 2018: https://www.ppda.go.ug/download/ppda_annual_reports/ppda_ annual_reports/PPDA-Annual-Report-2017-2018.pdf. • Data collection Matrix results—refer to Appendix 3. • Interview with the project management team 124 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA MAURITIUS • e-Procurement System of Government of Mauritius: https://eproc.publicprocurement. govmu.org/. • World Bank GPPD: https://www.globalpublicprocurementdata.org/gppd/. • Mauritius Digital Government Summit 2014 e-procurement System G2G G2B G2C, presented by P. Goburdhun. Member, Procurement Policy Office 8th October 2014; Organized by the Ministry of Information and Communication Technology, Republic of Mauritius. • Data collection Matrix results—refer to Appendix 3. • Interview with the project management team. IVORY COAST • World Bank GPPD: https://www.globalpublicprocurementdata.org/gppd/. • Data collection Matrix results—refer to Appendix 3. • Interview with the project management team. LIST OF INTERVIEWEES PER COUNTRY COUNTRY INTERVIEWEE FUNCTION Rwanda Public Procurement Authority Francine Gatarayiha e-Procurement Project Manager Rwanda Public Procurement Authority RWANDA Celestin Sibomana Manager, Research, Capacity Development and Monitoring Rwanda Public Procurement Authority Jean-Luc Ziravuga Purchase manager for e-procurement Khaled El Arbi President of the High Authority for Public Procurement Sonia Ben Salem e-Procurement Unit Director Rim Zehri Director General of the National Observatory of Public Procurement Sonia Ben Salem Director General of the TUNEPS Unit TUNISIA Controller of Public Procurement, Head of Department at the Manel Nasri TUNEPS Unit Nizar Abdelli Chief Controller of Public Procurement, Director of the TUNEPS Unit Sawsen Naccache Head of Department at the TUNEPS Unit REFERENCES I 125 COUNTRY INTERVIEWEE FUNCTION Public Procurement and Disposal of Public Assets Authority Benson Turamye Director Public Procurement and Disposal of Public Assets Authority Florence Nakyeyune Project Manager UGANDA Ministry of Finance, Planning and Economic Development David Kiyingi Nyimbwa Commissioner, Procurement Policy and Mgt. Dept Ministry of Finance, Planning and Economic Development Lawrence Semakula Accountant General Hirendranath Procurement Policy Office Rambhojun Director Procurement Policy Office MAURITIUS Gawesh Jawaheer Project Manager e-Procurement System / IT Consultant Bhagwansing Procurement Policy Office Dabeesing Member Information, Training and Communication Systems Ahoua Ouattara Director Anassin Sylvie Patricia Information, Training and Communication Systems IVORY COAST AYE Chief Operating Officer Statistics and Studies Amadou Bokoum Director 126 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Appendix 1 Summary Sheet for each software developer Atexo SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR ATEXO FRANCE 70 YES High % of turnover: 100% FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: French government Pre-awarding phase (93%) Post-awarding phase (42%) Suppporting features (61%) Country: France Year: N/A e-Procurement Planning Contract management e-Registration Budget: 2 000 000 $ e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): France Precision on the financial model: Developer Integrator Mix Hosting services provider: OVH • Number of tender Security State Annual • Quantity of DATA stored Workforce for run Certification certification audit Developer Integrator Mix ISO27001; PCI-DSS, SOC 1 Type II, SOC 2 Type II Bip Solutions SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR BIP SOLUTIONS UK 174 YES Medium % of turnover: 50% FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: Government of Lebanon Pre-awarding phase (60%) Post-awarding phase (10%) Suppporting features (32%) Country: Lebanon Year: N/A e-Procurement Planning Contract management e-Registration Budget: 2 000 000 $ e-Publication/Notification e-Catalogues Supplier management Client: Government of Bahamas e-Tendering Catalogue management Transverse search Country: The Bahamas Year: N/A e-Reverse Auctions e-Purchasing Monitoring and reporting Budget: 300 000 $ e-Evaluation/Awarding e-Complaints Client: Dubai Expo e-Signature Country: UAE Year: N/A Integrity filters Budget: 1 600 000 $ IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): France Precision on the financial model: Hosting services provider: BIP servers Developer Integrator Mix • N/A Security State Annual Workforce for run Certification certification audit Developer Integrator Mix ISO27001; ISO9001 APPENDIX 1. SUMMARY SHEET FOR EACH SOFTWARE DEVELOPER I 127 Bonfire SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR BONFIRE CANADA 100 YES High % of turnover: 100% FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: Cayman Islands Government Pre-awarding phase (68%) Post-awarding phase (15%) Suppporting features (50%) Country: Cayman Islands Year: N/A e-Procurement Planning Contract management e-Registration Budget: 450 000 $ e-Publication/Notification e-Catalogues Supplier management Client: Texas Dept. of Transportation e-Tendering Catalogue management Transverse search Country: USA Year: N/A e-Reverse Auctions e-Purchasing Monitoring and reporting Budget: 250 000 $ e-Evaluation/Awarding e-Complaints Client: Delaware Dept. of Social Services e-Signature Country: USA Year: N/A Integrity filters Budget: 45 000 $ IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off): Canada, USA, Germany Precision on the financial model: Hosting services provider: AWS Developer Integrator Mix • Bonfire offers single invoice on an annual basis for Security State Annual subscription service; however, agencies may pay the Workforce for run Certification certification audit entire term upfront at a discounted rate. The price of the Developer Integrator Mix SOC 2 Type II license is based on the number of users. EASIBUY SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR EASIBUY USA 15 YES Medium - High % of turnover: 80% FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: Cayman Islands Government Pre-awarding phase (87%) Post-awarding phase (15%) Suppporting features (86%) Country: Cayman Islands Year: N/A e-Procurement Planning Contract management e-Registration Budget: 180 000 $ / year e-Publication/Notification e-Catalogues Supplier management Client: City of Los Angeles e-Tendering Catalogue management Transverse search Country: USA Year: N/A e-Reverse Auctions e-Purchasing Monitoring and reporting Budget: 300 000 $ / year e-Evaluation/Awarding e-Complaints Client: State of Connecticut e-Signature Country: USA Year: N/A Integrity filters Budget: 300 000 $ IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): USA Precision on the financial model: Hosting services provider: AWS Developer Integrator Mix • Monthly per use Security State Annual • The price of the licenses depends on the number of tenders Workforce for run Certification certification audit Developer Integrator Mix AWS certifications 128 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA European Dynamics SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR EUROPEAN GREECE 650 YES High DYNAMICS % of turnover: 100% FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: Zambia’s Public Procurement Auth. Pre-awarding phase (95%) Post-awarding phase (90%) Suppporting features (82%) Country: Zambia Year: N/A e-Procurement Planning Contract management e-Registration Budget: 2 100 000 $ e-Publication/Notification e-Catalogues Supplier management Client: PPRA of the Govt. of Tanzania e-Tendering Catalogue management Transverse search Country: Tanzania Year: N/A e-Reverse Auctions e-Purchasing Monitoring and reporting Budget: 1 700 000 $ e-Evaluation/Awarding e-Complaints Client: Govt. of Ghana, Ministry of Comms. e-Signature Country: Ghana Year: N/A Integrity filters Budget: 2 400 000 $ IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): Greece Precision on the financial model: Hosting services provider: ED datacenters Developer Integrator Mix • License price based on the number of user / Security State Annual contracting authorities Workforce for run Certification certification audit Developer Integrator Mix ISO27001 GEP SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR GEP INDIA 1200 YES Medium % of turnover: N/A FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: University of California Pre-awarding phase (100%) Post-awarding phase (100%) Suppporting features (96%) Country: USA Year: N/A e-Procurement Planning Contract management e-Registration Budget: 14 000 000 $ e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): N/A Precision on the financial model: Hosting services provider: Microsoft Azure Developer Integrator Mix • The annual subscription fee depends on the number of users Security State Annual by modules implemented, and on the number of suppliers. Workforce for run Certification certification audit Developer Integrator Mix SOC1 and SOC2 SSAE 16 / ISAE 3402 ; ISO / IEC 27001:2005 APPENDIX 1. SUMMARY SHEET FOR EACH SOFTWARE DEVELOPER I 129 Guadaltel SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR GUADALTEL SPAIN 240 YES High % of turnover: 98% FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: Spanish Federation of Municipalties Pre-awarding phase (75%) Post-awarding phase (36%) Suppporting features (46%) Country: Spain Year: N/A e-Procurement Planning Contract management e-Registration Budget: 450 000 $ e-Publication/Notification e-Catalogues Supplier management Client: Ajuntament de Barcelona e-Tendering Catalogue management Transverse search Country: Spain Year: N/A e-Reverse Auctions e-Purchasing Monitoring and reporting Budget: 2 000 000 $ e-Evaluation/Awarding e-Complaints Client: Ayuntamiento de Sevilla e-Signature Country: Spain Year: N/A Integrity filters Budget: 1 500 000 $ IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): Ireland Precision on the financial model: Hosting services provider: AWS Developer Integrator Mix • No information on the pricing model. Security State Annual Workforce for run Certification certification audit Developer Integrator Mix Amazon certifications In-tend SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR IN-TEND UK 35 YES High % of turnover: 95% FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: Dept. of Finance & Economic Growth Pre-awarding phase (100%) Post-awarding phase (50%) Suppporting features (82%) Country: St Lucia Year: N/A e-Procurement Planning Contract management e-Registration Budget: 110 000 $ e-Publication/Notification e-Catalogues Supplier management Client: European Union Capacity Building e-Tendering Catalogue management Transverse search Country: Somalia Year: N/A e-Reverse Auctions e-Purchasing Monitoring and reporting Budget: 200 000 $ e-Evaluation/Awarding e-Complaints Client: United Nations e-Signature Country: N/A Year: N/A Integrity filters Budget: 500 000 $ IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): UK Precision on the financial model: Hosting services provider: In-tend’s datacenters Developer Integrator Mix • 1st Year License plus annual Hosting fee, based on Security State Annual the number of tenders, contracts, purchases orders Workforce for run Certification certification audit processed through the software. Also based on the Developer Integrator Mix ISO 27001/22301/9001 quantity of Data stored 130 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA IOS Partners SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR IOS PARTNERS USA 40 YES High % of turnover: 90% FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: IFC and World Bank Pre-awarding phase (100%) Post-awarding phase (44%) Suppporting features (46%) Countries: Malawi, Moldova, and Latvia Year: N/A e-Procurement Planning Contract management e-Registration Budget: 300 000 $ e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): USA Precision on the financial model: Host. serv. prov.: Microsoft Azure, Rackspace Developer Integrator Mix • Price factors depend on the solution type (COTS/SaaS) Security State Annual Workforce for run Certification certification audit Developer Integrator Mix ISO27001, CMMI-LIII Ivalua SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR IVALUA FRANCE 635 YES Medium % of turnover: N/A FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: City of New York Pre-awarding phase (100%) Post-awarding phase (100%) Suppporting features (100%) Country: USA Year: N/A e-Procurement Planning Contract management e-Registration Budget: N/A e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off): USA, Europe, Canada Precision on the financial model: Host. serv. prov.: Mic.Azure, Equinix, Aptum Developer Integrator Mix • Subscription price based on the number of users per Security State Annual modules activated Workforce for run Certification certification audit Developer Integrator Mix ISO 9001/14001/27001, SOC 1 Type II, SOC 2 Type II APPENDIX 1. SUMMARY SHEET FOR EACH SOFTWARE DEVELOPER I 131 Market Dojo SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR MARKET DOJO UK 35 YES Medium - Low % of turnover: 12% FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: Kent County Council Pre-awarding phase (65%) Post-awarding phase (9%) Suppporting features (21%) Country: UK Year: N/A e-Procurement Planning Contract management e-Registration Budget: 10 000 $ e-Publication/Notification e-Catalogues Supplier management Client: Bedford Borough Council e-Tendering Catalogue management Transverse search Country: UK Year: N/A e-Reverse Auctions e-Purchasing Monitoring and reporting Budget: 10 000 $ e-Evaluation/Awarding e-Complaints Client: Creative Education e-Signature Country: UK Year: N/A Integrity filters Budget: 3 000 $ IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): N/A Precision on the financial model: Hosting serv. provider: Google Cloud Platform Developer Integrator Mix • Flexible pricing options Security State Annual • Price of license depends on the number of users Workforce for run Certification certification audit Developer Integrator Mix ISO27001 Marketplanet SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR MARKETPLANET POLAND 80 YES Medium - Low % of turnover: 22% FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: Govt. Admin. Service Center Pre-awarding phase (100%) Post-awarding phase (80%) Suppporting features (50%) Country: Poland Year: N/A e-Procurement Planning Contract management e-Registration Budget: 200 000 $ e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): Poland Precision on the financial model: Hosting services provider: Orange Developer Integrator Mix • License price is based on the number of users, purchase Security State Annual orders, quantity of data stored, computing power used, Workforce for run Certification certification audit and number of environments purchased. Developer Integrator Mix TBD 132 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA NEQO SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR NEQO FRANCE 12 YES High % of turnover: 100% FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: DAE (Ministry of Finance) Pre-awarding phase (60%) Post-awarding phase (20%) Suppporting features (54%) Country: France Year: N/A e-Procurement Planning Contract management e-Registration Budget: 150 000 $ e-Publication/Notification e-Catalogues Supplier management Client: French Brittany Region e-Tendering Catalogue management Transverse search Country: France Year: N/A e-Reverse Auctions e-Purchasing Monitoring and reporting Budget: 120 000 $ e-Evaluation/Awarding e-Complaints Client: Belgian Ministry of Economics e-Signature Country: Belgium Year: N/A Integrity filters Budget: 25 000 $ IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): France Precision on the financial model: Hosting services provider: OVH, Clevercloud Developer Integrator Mix • License price depends on the number of users and Security State Annual of the associated scopes of functionalities (six functional Workforce for run Certification certification audit scopes in total). Developer Integrator Mix ISO27001 ; PCI-DSS, SOC 1 Type II, SOC 2 Type II Nextenders SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR NEXTENDERS INDIA 40 YES High % of turnover: 95% FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: Ministry of Finance & Ec. Dev. Pre-awarding phase (100%) Post-awarding phase (100%) Suppporting features (86%) Country: Mauritus Year: N/A e-Procurement Planning Contract management e-Registration Budget: 2 991 109 $ e-Publication/Notification e-Catalogues Supplier management Client: Public Procurement & Asset D. Board e-Tendering Catalogue management Transverse search Country: Botswana Year: N/A e-Reverse Auctions e-Purchasing Monitoring and reporting Budget: 1 541 464 $ e-Evaluation/Awarding e-Complaints Client: Dept. of Budget and Management e-Signature Country: Philippines Year: N/A Integrity filters Budget: 2 920 000 $ IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): India, Singapore Precision on the financial model: Host. serv. prov.: Amazon AWS, Mic. Azure Developer Integrator Mix • License price is based on the number of suppliers, Security State Annual tenders, signed contracts, and purchase orders. Workforce for run Certification certification audit Developer Integrator Mix ISO 27001; STQC APPENDIX 1. SUMMARY SHEET FOR EACH SOFTWARE DEVELOPER I 133 ProcurementExpress.com SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR PROCUREMENT IRELAND 25 YES Medium - Low EXPRESS.COM % of turnover: 10% FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: Davies County Pre-awarding phase (13%) Post-awarding phase (75%) Suppporting features (32%) Country: USA Year: N/A e-Procurement Planning Contract management e-Registration Budget: 5 000 $ / year e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): USA, EU Precision on the financial model: Hosting services provider: Amazon AWS Developer Integrator Mix • License price is based on the number of users. Security State Annual Workforce for run Certification certification audit Developer Integrator Mix Procure Tiger SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR PROCURE INDIA 200 YES Medium TIGER % of turnover: 25% FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: Government of Bangladesh Pre-awarding phase (68%) Post-awarding phase (15%) Suppporting features (50%) Country: Bangladesh Year: N/A e-Procurement Planning Contract management e-Registration Budget: 2 450 000 $ e-Publication/Notification e-Catalogues Supplier management Client: Bharat Petroleum Corp. Ltd. e-Tendering Catalogue management Transverse search Country: India Year: N/A e-Reverse Auctions e-Purchasing Monitoring and reporting Budget: 1 150 000 $ e-Evaluation/Awarding e-Complaints Client: Pune Municipal Corporation e-Signature Country: India Year: N/A Integrity filters Budget: 350 000 $ IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): India Precision on the financial model: Hosting services provider: CtrlS Data Center • License price depends on the modules opted i.e. Purchase Developer Integrator Mix Security State Annual Requisition, E-tender, Auction, Contract Management etc. Workforce for run Certification certification audit • Perpetual License, Pay per Event, Supplier Pays, Developer Integrator Mix ANSI TIA 942 A ; ISO 9001/22301/27001/270018, etc. % Commission basis, etc. 134 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Synertrade SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR SYNERTRADE USA 360 YES Medium % of turnover: N/A FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: World Bank Group Pre-awarding phase (100%) Post-awarding phase (100%) Suppporting features (82%) Country: USA Year: N/A e-Procurement Planning Contract management e-Registration Budget: 2 500 000 $ e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): Germany, USA Precision on the financial model: Host. serv. prov.: Noris Network, US Rackspace Developer Integrator Mix • License price is based on the number of tenders, signed Security State Annual contracts, and purchase orders. Workforce for run Certification certification audit Developer Integrator Mix SOC 2 Type I, SOC 2 Type II and ISO 9001, ISO 27001 uStudio SUPPLIER IDENTITY NAME COUNTRY # OF EMPLOYEE ABILITY TO IMPLEMENT IN AFRICA INTEREST IN PUBLIC SECTOR USTUDIO UKRAINE 27 YES Medium % of turnover: 25% FUNCTIONAL COVERAGE RELEVANT EXPERIENCE Client: Ministry of Economic Development Pre-awarding phase (77%) Post-awarding phase (59%) Suppporting features (39%) Country: Ukraine Year: N/A e-Procurement Planning Contract management e-Registration Budget: N/A e-Publication/Notification e-Catalogues Supplier management Client: Transparency International Ukraine e-Tendering Catalogue management Transverse search Country: Ukraine Year: N/A e-Reverse Auctions e-Purchasing Monitoring and reporting Budget: N/A e-Evaluation/Awarding e-Complaints Client: State of Connecticut e-Signature Country: Moldova Year: N/A Integrity filters Budget: N/A IMPLEMENTATION TYPE DATA HOSTING AND SECURITY PRICING MODEL Custom COTS SaaS On premise Off-premise Subscription fees Perpetual software license Workforce for build Hosting location (if off-premise): N/A Precision on the financial model: Hosting services provider: N/A Developer Integrator Mix • Forfeit for the development and implementation Security State Annual • Smaller fee for the 12 month of maintenance of a basic Workforce for run Certification certification audit version while improving it with advanced functionality Developer Integrator Mix ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA I 135 Appendix 2 Market Survey Questionnaire This section presents the questionnaire sent to publishers in the procurement suite market as part of the supplier survey. It is divided into 5 parts: 1 “Company” tab, for suppliers to describe some of the characteristics of their company. 2 “Functional coverage” tab, in which the suppliers described the functionalities that their solution covers, relative to the total functional coverage of the e-GP as imagined by the bank. 3 “Implementation” tab, in which the Software developers present the deployment methods of the solution, as well as their methodology. 4 “Hosting & Security” tab, in which vendors present the hosting methods for their solution, as well as various security-related features of their offer. 5 “Financial model” tab, in which suppliers present the acquisition mode of their solution. “Company” section INFORMATION ON YOUR COMPANY 1. COMPANY PROFILE Name Year of incorporation Turnover in 2019 (in K$) Turnover in 2020 (in K$) Projected turnover for 2021 (in K$) % of revenues generated with public customers Number of employees 2. CREDENTIALS 1. Please fill the following table with examples of projects you were part of. 2. You can add as many lines as you think is relevant in Project Description Country Client Budget (scope, main features, this section. name (K$) planning) 3. Please focus on your experience in African countries, if applicable. Experience in implementing purchasing e-Government procurement solution (purchasing Information System specifically designed for Government bodies and public procurement) Experience in implementing e-procurement/ e-purchasing solutions in private organizations 3. PUBLIC SECTOR What are the major trends you see in the market for online public procurement solutions? What are your strategic priorities with regard to the public sector? (main features to be developed, partnerships, ...) 4. LOCATIONS Where are the development centers (R&D) based? Where are your sales offices based? 136 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA “Functional coverage” section FUNCTIONAL COVERAGE OF YOUR e-GP SOLUTION Information about your e-Procurement solution Name of the solution Commercialized since (year) ? List of all the public customers using the solution Is the solution based on open source ? Supported by If not supported in standard, the solution? can be added with specific code (Select (Select Yes or No) Features Yes or No) Pre-awarding phase 1. e-Procurement planning 1.1 Purchasing project preparation (requirements gathering, planification, strategy, etc.) 1.2 Purchasing project approval (workflow) 1.3 Grouping / consolidating projects in programs or plans 2. e-Publication/Notification 2.1 Tender workspace creation and workflow setup 2.2 Assigning tenders to buyers and manage the “team” workload 2.3 Tender documentation preparation (including templates, authoring, …) 2.4 Tender questionnaire preparation 3. e-Tendering (from the supplier’s perspective) 3.1 Submission of questions by the supplier, reading of answers 3.2 Creation and submission of bids 3.3 Bid security (privacy, acknowledgment of receipt, etc.) 4. e-Evaluation/e-Awarding 4.1 Management of bids opening/closing dates 4.2 Evaluation of the offers (financial and technical) 4.3 Assistance to the awarding process 5. e-Reverse Auctions 5.1 e-Auctions (English, Dutch, Japanese) Post-awarding phase 6. Contract Management 6.1 Contracts Repository 6.2 Contract Authoring and approval 6.3 Management of contract negotiations, amendments, renewals (including notifications) 6.4 Management of Key Performance Indicators on contracts 6.5 Spend control on contracts 7. e-Catalogues 7.1 Catalogue workspace management 7.2 Catalogue browsing 7.3 Cart management 8. Catalogue Management 8.1 Catalogue preparation 8.2 Catalogue submission 8.3 Catalogue approval 8.4 Catalogue versioning 8.5 Catalogue activation 9. e-Purchasing 9.1 Requisition 9.2 Quotation 9.3 Purchase order 9.4 Invoice 9.5 Payment 9.6 Goods receipt note APPENDIX 2. MARKET SURVEY QUESTIONNAIRE I 137 Supporting features 10. e-Registration 11. Vendor management 11.1 Vendor general information (legal requirements) 11.2 Legal documents storage 11.3 Management of vendor performance 11.4 Complaints and claims from the supplier 12. Transverse search 13. Procurement Monitoring and Reporting 13.1 Notifications and alerts 13.2 Audit trails : possibility to associate any transaction with a documentary source 13.3 Business Intelligence Reporting & Dashboard 13.4 Open Contracting Data Standard (OCDS) 14. e-Complaints 15. e-Signature 16. Integrity filters 17. Data Integration capabilities 17.1 Please detail your capacities in terms of data integration and interoperability (EAI, ETL, …) 138 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA “Implementation” section IMPLEMENTATION AND SUPPORT PRACTICES Please select Please feel free an answer to add comments Q”What is the Implementation mode of the solution ? Custom • SaaS model COTS • Commercial-Off-The-Shelf (COTS) SaaS • Custom Developments ?” Where are the resources/services based that support the “DESIGN” and “BUILD” phases of an implementation project ? (Country) Do you think that you have the capacity to implement in African countries ? Do you have certified partners in Africa to assist you in technical implementation? (if yes, provide names) Please describe the typical role distribution during DESIGN and BUILD Phases (distribution of the role between the IT provider, integrator, provider, customer, …) Example : • Who is in charge of the specification workshops (functional workshops, core model...)? Editor or Integrator? • What type of interlocutors are required on the government side? For what purpose? • Who is in charge of the testing? • Who is in charge of the change management? Please describe the typical role distribution in RUN phase (maintenance, support, evolutions) Example : • Who is in charge of the Level 1 user support ? Level 2 user support ? Editor or Integrator? Both? • Who is in charge of developing small enhancements ? Editor or Integrator? Both?” Additional information you may want to share APPENDIX 2. MARKET SURVEY QUESTIONNAIRE I 139 “Hosting and security” section TECHNICAL, HOSTING AND SECURITY FEATURES OF YOUR e-GP SOLUTION 1. Supported browsers and devices List of the certified browsers compatible with the solution (tested and approved by the provider) Is the solution supported on mobile devices ? 2. Hosting of the data Location of the data center facilities (Country) Name of the hosting service provider(s) you rely on (MS Azure, Amazon, OVH…) List of certifications obtained by your hosting service provider(s) Please provide details about the hosting physical security (access controls, guards, dedicated locked racks, power supply, ventilation, fire safety) Please provide details about server access security (IPSc, VPNs…) Has your e-GP solution already be implemented on premise ? (Solution installed and running on computers on the premises of the organization using the software, rather than at a remote facility such as a server farm or cloud) If you already have implemented your solution on premise, please describe how you proceed (sharing responsibility with the customer, technical requirements for the application to run, etc.) Would you accept to consider the “on premise” option ? (solution installed and running on computers on the premises of the organization using the software, rather than at a remote facility such as a server farm or cloud) In case of an on-premise implementation, what would be the approximate percentage surcharge on the project/maintenance costs ? (in %) Additional information you may want to share 3. Application Security Has the technical architecture and security of the solution already been audited and certified by a State? If yes, which one(s) ? List of Certificates of Compliance related to Security Management Are application security, identification and authentication practices audited annually by independent bodies? If yes, which one(s) ? Additional information you may want to share 140 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA “Financial model” section PRICING MODEL OF YOUR e-GP SOLUTION 1. Licenses SaaS COTS Custom* What is your standard pricing model for license: SaaS COTS - A subscription fee model (priced on a quarterly basis for example)? *If your comapny develops custom - A software license ( paid up-front in one lump sum)? based solutions, - Other ? (please specify) please go directly to the section #3 Are you able to offer both models? Does the cost of the license depend on: SaaS COTS Comments - Number of users (belonging to the customer organization)? - Number of suppliers? - Number of tenders? - Number of signed contracts? - Number of Purchase Orders? - Quantity of data stored? - Computing power that is used? On which other parameters does the price of the licenses depend? SaaS COTS In your opinion, what is the approximate “market price” of • 20 Ministries • Intensive users (creating tenders...): 250 • Tenders (per year): 1500 • Read-only and validators: 1000 • Suppliers: 5000 the licenses? • according to the metrics listed (price range in K$) K$ K$ • and for all modules covering the pre-awarding phase and the reporting features (features 1 to 4, 10, 11 and 13 in excel sheet Comment if your functional coverage is different from the one “Functional coverage”) specified on the left. 2. Implementation costs for COTS and/or SaaS SaaS COTS Comments In your opinion, what would be the estimated total cost in k$ for “design” and “build” phases: • based on the same functional scope (features 1 to 4, 10, 11 and 13 in excel sheet “Functional coverage”) K$ K$ • without the cost of interfaces and historical data migration • and given the project metrics provided above In your opinion, what would be the approximate duration of the project (design and build phases), in months? In your opinion and based on your experience, what are the main risks on such a project? Which best practices would you recommend in regard of the implementation of e-GP Solution ? APPENDIX 2. MARKET SURVEY QUESTIONNAIRE I 141 3. Section ONLY dedicated to “Custom Solution providers” (not for SaaS / COTS editors) What was the implementation budget (in k$ ) on previous development projects conducted by your company covering the pre-awarding phase and the reporting features (features 1 to 4, 10, 11 and 13 in excel sheet “Functional coverage”) K$ (Excluding the interfaces and historical data migration) ? What was the duration of the project in months? Which best practices would you recommend in regard of the implementation of e-GP Solution? 142 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Appendix 3 Data Collection Matrix The data collection matrix is the document sent to all African governments to find out the status of their e-GP projects – for those who have already implemented an e-GP or wish to implement one in the coming years. This matrix is composed of several sections: • Project identity, to collect general information about the project – dates, type, suppliers, project management ownership, etc. • Functional Scope, to describe the functional coverage of their e-GP in place or under development. • Integration complexity, which describes the systems with which their e-GP is interfaced, as well as the difficulty of developing the interfaces. • System metrics, which details the e-GP system’s adoption, use, and benefits. • System implementation planning, which presents the design and deployment schedule of their e-GP, mentioning possible drifts. • Project cost, to declare the total project budget and to break down the costs according to the various phases and sites. • Hosting of the data, to describe how the e-GP will be hosted. • Applicable charges, to list any additional charges and describe how they are costed by the government. • Experience feedback, to note different aspects of the project, describe what they would have changed if the project were to be repeated, and provide a number of tips for countries to read the study. APPENDIX 3. DATA COLLECTION MATRIX I 143 Below are examples of questions asked in some of these sections: A. Identity e-GP system name e-GP system URL Country Implementation type (Custom, Cots, SaaS) Starting date of the project (date of award to the IT provider / developer) Supported language 1 Supported language 2 Supported language 3 Supported language 4 Supported language 5 Supported currency 1 Supported currency 2 Supported currency 3 Supported currency 4 Supported currency 5 Project based on open source? World Bank project number World Bank project name World Bank project status (Pipeline, Active, Closed) World Bank project amount World Bank project allocation for e-GP components e-Procurement System assess by the World Bank for World Bank Financed Projects (Yes/No) e-Procurement System used by the World Bank (Yes/No) World Bank procurement methods supported by e-Procurement Systems (RFQ/NCB/ICB/Other) (if other, please comment) IT provider / developer Vendor names and details Integrator on project organization Project Management Ownership Other Service Level Agreement (SLA) (In addition to your comments, please feel free to add any document presenting the SLA) 144 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA B. Functional scope Yes, No, Under Development, Planned in next 2 years Pre-awarding phase e-Procurement Planning e-Publication/Notification e-Tendering (Submission, Bidding, Quotation...) e-Reverse Auction e-Evaluation / Awarding Post-awarding phase e-Contract Management e-Catalogues e-Catalogue Management e-Purchasing Supporting features e-Registration e-Vendor Management Transverse Search Monitoring and Reporting / BI e-Complaints e-Signature Advanced electronic certificate authentication Document electronic signing Action electronic signing Other Integrity Filters Others Tender documents are downloadable e-Procurement assessments C. IMPLEMENTATION COSTS MODÈLE DE TARIFICATION DE VOTRE SOLUTION e-GP INTERNAL COSTS 1. IMPLEMENTATION COSTS PROVIDERS COSTS # of man.days Preliminary study Design General Conception K$ K$ Detailed Conception Development / Customization Interfaces and integration with legacy systems Build UAT, Data Migration, Go Live support K$ K$ Training and change management Deployment Project Management Project Management Ownership K$ K$ New hardware or upgrades to support the new system Operating systems and lower layers Infrastructure K$ K$ Network connectivity IT related services Total K$ K$ MODÈLE DE TARIFICATION DE VOTRE SOLUTION e-GP 2 LICENSE COSTS SINCE BEGINNING OF PROJECT K$ K$ MODÈLE DE TARIFICATION DE VOTRE SOLUTION e-GP INTERNAL COSTS 3. ANNUAL RUNNING COSTS PROVIDERS COSTS # of man.days Functional and technical administration Corrective maintenance RUN K$ K$ Evolutive maintenance (Improvements costs) Other operations costs Assumptions or comments ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA I 145 Appendix 4 Fundamentals of IT security The number of cyberattacks has never been rising so fast. A recent Ponemon Institute study discovered that companies spend $3.86 million per incident and that over the last two years, organizations lost around $400 billion to cyber theft and fraud, worldwide.23 This cost includes both the direct damage, as experienced in infrastructure downtime and reputational loss, for example, and the indirect damage—fines for affected data subjects after a data breach, fines due to GDPR violations.24 MAIN CONCEPTS Regarding IT security, there are two different dimensions to consider: (i) security of data, and (ii) security of application and infrastructure. Data security: Different data states and the Central Intelligence Agency (CIA) triad First, it is important to look at the three basic states of data and understand the types of risks associated with them. 1. Data at Rest • Data at rest is housed physically on computer data storage in any digital form. When data is in this state, information security is ensured by some dedicated components such as firewalls, antivirus, or data loss prevention mechanisms. As any security solution or mechanisms, it is not 100 percent accurate and efficient. The encryption of data at the end of the chain can then be used to overcome these limitations. 23. Cost of a Data Breach Report 2020. https://www.capita.com/sites/g/files/nginej291/files/2020-08/Ponemon-Global-Cost-of-Da- ta-Breach-Study-2020.pdf. 24. https://www.nbcnews.com/tech/security/ponemon-institute-n364871. 146 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 2. Data in transit • Data in transit is also known as “data in motion” or “data in flight” and refers to a stream of data moving through any kind of network—for example, an email being sent is an example of data in transit. However, when it arrives in the recipient’s inbox, it would then become data at rest. • When in transit, it means data are “on a journey,” and hence more vulnerable than the previous state. At every step of transfer, an attacker could access the data, if no secure channel is used. 3. Data in use • This refers to data currently being updated, processed, erased, accessed, or read by a system. In this state, data could be accessible by anyone if no tight access controls are in place. The key here is to ensure that identification, authentication, and authorization mechanisms are correctly implemented to avoid any problems. As to data security, another fundamental concept is the “CIA triad,” also known as the “three great security principles:”25 1 Confidentiality of the data: Data must not be exposed to unauthorized people. 2 Integrity of the data: Data must be completely accurate and without any alteration by unauthorized people. 3 Availability of the data: The information is accessible by authorized users only. Data security is a major concern, even more when choosing the application hosting business model. Faced with this risk, public or private organizations have the option of assuming this responsibility or delegating data hosting to a trusted application developer to take care of security. APPLICATION SECURITY AND OWASP TOP 10 Application security is defined as the steps a developer takes to identify, fix, and prevent security vulnerabilities at the different stages of the software development cycle. Having applications checked regularly for security flaws is becoming more and more essential since they are more and more targeted. According to Veracode’s State of Software Security report, 83 percent of the 85,000 applications they tested had at least one security flaw.26 The Open Web Application Security Project (OWASP) Top 10 represents a broad consensus of the most-critical web application security flaws as shown in the figure 51. 25. 21 https://www.techopedia.com/2/27825/security/the-basic-principles-of-it-security. 26. https://www.veracode.com/state-of-software-security-report. APPENDIX 4. FUNDAMENTALS OF IT SECURITY I 147 Figure 51: Top 10 application security risks (last version of the OWASP top 10 issued in 2017) The risks associated with these flaws are numerous and can have massive consequences. If these flaws are “unpatched,” an attacker could: (i) easily gain “root” access (admin access) to the infrastructure; (ii) hijack some high privileges user sessions; (iii) deface the web application; and (iv) alter, or steal the data. Application developer security (SaaS) or in house security (“Custom”) minimum requirements: The following requirements must be respected to avoid a cyber incident or at least control its damages. These are minimum requirements and activities subject to specific regulations such as defense secrecy or financial institutions, and also may be subject to even more stringent procedures. 1. ENSURE EMPLOYEE AWARENESS ABOUT SECURITY RISKS Security is everyone’s mission. Even when the best security mechanisms are implemented, if employees share accounts, password or click on suspicious links, the whole infrastructure will be in danger. There are countless cases where infrastructure (on-premises or in cloud) was completely corrupted by some malware following some phishing attacks. One good illustration of this is the love/hate relationship of users with their passwords and the temptation to share them across different logins. A 2020 survey conducted by the company LastPass27 found that 66 percent of employees store their passwords insecurely or reuse the same password from one application to another. ! Human always is the weakest element in information security! 27. https://www.lastpass.com/. 148 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 2. SECURE THE APPLICATION DEVELOPMENT If government chooses to go for a Custom solution, one of the issues to be addressed is ensuring that the development cycle is secured. Two means to do so are: (i) train the development team to basic security principles, based on the OWASP top 10 mentioned earlier, and (ii) implement automated security check software, such as Checkmarx, Veracode, or SonarQube. Both actions are costly, in terms of time and money. As regards application security, it is commonly acknowledged by the cybersecurity community that choosing a SaaS/COTS application from a trusted software developer is more secure. During the selection process, governments must check that the SaaS solution will have undergone many security checks (Ideally before the release of each new version to verify that new vulnerabilities have not been created). The most advanced Software developers perform penetration tests with the 3-box system: (i) black box, where the testers know nothing about the application and try to get into the application by any means; (ii) grey box, where one user registered on the application tries to find a flaw to acquire new authorizations; and white box, where the tester has access to the code and identifies security flaws in the different layers of code. As security is at the heart of their business model, SaaS/COTS Software developers can dedicate much greater resources than happens for a Custom project. The advantage is obviously that the cost of application security is distributed among all the customers. 3. ENSURE INFRASTRUCTURE PROTECTION For a Custom development project, the following measures should be undertaken: • Implementation of security mechanisms on the IT infrastructure: • Firewalls. • Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS)—IDS designed to prevent malicious activity within a network. • Implementation of data backups. The two data centers should be far enough apart so that they could not both be impacted by the same incident. These mandatory measures involve a combination of hardware and software that tend to be very expensive. As such, they should not be underestimated in the budgeting process. The cost of maintaining this framework all along the lifecycle should also not be underestimated. For instance, government should perform regular updates of the various equipment and should put in place some backups tests to be sure that if any incident happens, it could always have access to its application. This implies having a full security team handling its infrastructure. For a SaaS/COTS project, the following measures should be undertaken: • Government must ensure that the SaaS/COTS software developer undergoes regular security audit and complies with applicable security norms. Not having these means sensitive data might not be kept secure all along the various stages of storage, processing, and transmission. • The costs to manage the infrastructure mentioned above will indeed be spread among all the customers of the company that offers the SaaS solution. On this aspect, a SaaS/COTS hosted in cloud option is less expensive. APPENDIX 4. FUNDAMENTALS OF IT SECURITY I 149 4. ENSURE THE SCALABILITY AND FAULT TOLERANCE OF THE SOLUTION Another requirement is to ensure that the solution automatically adapts IT resources if access requests to it increase or decrease. With most robust SaaS cloud solutions, the entire infrastructure is built to answer to on-demand requests and to avoid customers having to invest in huge on-site physical infrastructure. This is an evaluation criterion that should not be forgotten in the selection process of SaaS/COTS software developers and is a must-have for any Custom projects. Furthermore, the government must ensure the application availability in case one component of the solution fails. Governments must analyze the guarantees offered by SaaS or COTS software developers on this aspect. For a Custom project, RAID (Redundant Array of Inexpensive Disks) fault- tolerance systems must be implemented to avoid downtime in case one disk fails for any reason. 5. USE CRYPTOGRAPHY ON APPLICATION AND ON DATA TRANSFERS To protect confidentiality of data, it is important to make it unreadable by unauthorized people. The best method to do so is encryption, which converts plain text into a secret code that hides the information. Today, the leading cryptographic algorithm is the Advanced Encryption Standard (AES) created in 2001 and which supersedes the Data Encryption Standard (DES), which was published in 1977. The mechanism uses encryption keys allowing the encryption/decryption processes. The algorithm described by AES is a symmetric-key algorithm, meaning the same key is used for both encrypting and decrypting the data. With this security mechanism, even the software developer or the data hosting provider cannot access the data, if the keys have not been shared. The idea is to prevent unauthorized people gaining access to these keys. Thus, some stringent and rigorous strategies to manage these keys must be put in place. The implementation of a blockchain is often mentioned as an ultimate solution to guarantee data integrity. Indeed, blockchain combines data encryption with the fact that each “block” of data within the peer-to-peer network must be modified, which makes data theft or alteration almost impossible from a technical point of view, and economically prohibitive. However, the same difficulty in securing access to the keys used to access and decrypt data is found in the blockchain. Identity fraud on “private keys” (or wallet keys) at the time of authentication of participants is still frequent. The identity theft observed on some monetary blockchains suggests that from a security point of view, private key authentication systems are not yet fully mature. 6. IDENTITY AND ACCESS MANAGEMENT (IAM) STRATEGY AND ACCOUNT PROVISIONING SYSTEMS Identity and access management (IAM) is about defining and managing the roles and access privileges of users to the applications. Users include customers, partners, vendors, and employees. The central objective of IAM systems is a digital identity per individual. Once this digital identity has been established, it must be maintained and monitored. IAM systems provide administrators with the tools and technology to change a user’s role, track their activities, create reports on those activities, and enforce policies on an ongoing basis. These systems are designed to ensure compliance with corporate policies and government regulations. “Identity has become more important since COVID made physical boundaries irrelevant,” says Andras Cser, vice president and IAM analyst at Forrester Research. More companies have turned to remote users and have also given users outside the organization greater access to their internal systems. “As digital transformation has accelerated, identity has become the cornerstone of customer acquisition, management and retention,” he adds. The disruption caused by COVID has exposed weaknesses in many organizations’ IAM architecture and significantly accelerated the evolution of IAM, according to Gartner’s latest 2021 Planning Guide for IAM report. 150 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA Regardless of the implementation type chosen, IAM is crucial for security. In the case of SaaS/ COTS, cloud providers most often offer an IDaaS (Identity as a Service) solution and can implement it with client’s agreement on the environment, adding an additional layer of security to data access. 7. HAVE A SECURITY INCIDENT RESPONSE PLAN A cybersecurity attack occurs at least every hour and governments must be prepared to deal with them. A data breach must be managed with an appropriate plan: quick reaction to qualify the problem, setting up a crisis unit, and managing communication. Teams managing Custom projects must therefore regularly update their security plan and train their teams on the topic. In case of security incidents on a SaaS or COTS solution, it is the software developer’s team that takes the lead. Their staff is generally well prepared for such incidents. It is also important to analyze the tools and processes used by vendors for crisis management during the selection process. Data and e-GP steps to be secured first What data is most at risk in an e-GP system? 3 categories of data can be considered: 1 First, there is data made public in accordance with the principle of transparency in public procurement. For example, the names of suppliers who win contracts, the amount of the contracts, the specifications, or the estimated quantities. This first category of data is not really at risk; its resale value is low, and it is relatively easy to restore the information for the continuity of operations if it were to be stolen. 2 Then there is data that is not publicly available and whose resale value is low: supplier evaluations, supplier addresses, the names of sales managers, etc. The risk related to this data is not so much theft but rather its alteration for destabilization purposes. It is foreseeable that this data could be modified to create a major disruption or paralyze a country’s public procurement: notification sent to the wrong contacts, orders sent to the wrong addresses, modified composition of orders, etc. 3 The third category is the most sensitive. This includes non-public data relating to the detailed offers of suppliers as well as the evaluations made by the contracting authorities during the consultation phases: detailed commercial proposals, unit prices given by suppliers, very precise and confidential technical data sheets, and the evaluation of offers made by the prescribers. All this data is classified as business secret. If made public, it could cause financial damage to suppliers operating in highly competitive sectors. Besides, all these data are at the heart of the procurement process. If they are stolen or altered, the entire tendering process is compromised, leading to significant delays or cancellations of procedures and ultimately to a significant destruction of value for the country. Which steps of the procurement process are most at risk in an e-GP system? Within the processes covered by e-GP systems, the steps that concentrate the most security risks are those of e-tendering, reverse auctions, and e-evaluation/awarding. Indeed, these processes concentrate most of the sensitive information related to business secrecy and the alteration or deletion of the data will undoubtedly have the most important consequences for the contracting authorities. For example, a hacking could lead to important consultation delays, cancellations, delays in government projects, and serious damages for some companies, if confidential information were made public. APPENDIX 4. FUNDAMENTALS OF IT SECURITY I 151 The contract management and e-purchasing stages also raise significant issues. These stages handle price and confidential data and their hacking could destabilize the order’s supply chain, slow down government projects, and weaken the suppliers’ network—due to payment delays for example. However, to prepare for the case of an attack, it is important to set up a back-up system: the data could easily be restored, and it would be possible to use more traditional tools to place or track orders, for example, by excel and e-mail. Regarding supporting features, it is important to ensure the security of the e-registration process so as not to allow one supplier to impersonate another, for example. Figure 52: Steps with high security risks in an e-GP system Pre-awarding phase Post-awarding phase Suppporting features e-Procurement Planning Contract management e-Registration e-Publication/Notification e-Catalogues Supplier management e-Tendering Catalogue management Transverse search e-Reverse Auctions e-Purchasing Monitoring and reporting e-Evaluation/Awarding e-Complaints e-Signature Integrity filters Source: Authors REGULAR AUDITS (CODE, INFRASTRUCTURE, SECURITY PROCESS): A MUST-HAVE How can the client be sure that the software developer or the Custom solution developed maintains a reliable security system over time? How can vulnerabilities be identified as early as possible and a risk mitigation plan implemented? The solution lies in conducting regular audits with the help of experts specialized in cybersecurity. Some companies are leaders on these various audits and are qualified by government authorities. To ensure the security of the e-GP application, it is essential that the software developer tests it from multiple points of view and with different methodologies to ensure that the application is resilient to cyberattacks. The various audits to be handled are: code audit, organizational audit, architecture and configuration audit and intrusion tests. CODE AUDIT The goal of this activity is to detect any flaws in the code of the application. To perform this kind of activity, a dynamic analysis tool like Checkmarx, SonarQube, or Veracode may be used for a preliminary check. After this automated check, the auditor will manually review the code, checking if it contains some deprecated functions or any other basic issue. This check is the first security fence. 152 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA ORGANIZATIONAL AUDIT Does the software developer or the Custom project developers update the security processes on a regular basis? The only way to check this dimension is to perform an organizational audit. It consists in identifying weaknesses linked to security management process. Many issues are checked during this audit, including security policy, human resources, asset management, integration of security into the lifecycle of cloud systems, and network security. ARCHITECTURE AND CONFIGURATION AUDIT This audit analyzes precisely the architecture deployed within the cloud solution or client’s on- premises systems to check if the hardening of each component is up to date and all security parameters are enforced. INTRUSION TESTS Is it possible for unauthorized people to gain some access to the e-GP system? Is it possible for such people to exploit some vulnerabilities and have “root” privileges? The only way to make sure they cannot is to go for an intrusion test to confirm that defenses are holding up as intended. EXTERNAL PENTEST INTERNAL PENTEST Several modes could be used during this activity, such as Black-Box mode (intrusion tests without any knowledge of the target); Grey-Box mode (intrusion tests with an access to some unprivileged account to check the possibility to have a privilege escalation on the system); and White-Box mode (intrusion tests with complete knowledge of the target and with an access to the source code). INPUT INPUT OUTPUT OUTPUT BLACK-BOX TESTING WHITE-BOX TESTING ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA I 153 Appendix 5 Top 10 web application security risks The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications. 28 1 A1:2017 – Injection: Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.29 2 A2:2017 – Broken Authentication: Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently. 3 A3:2017 – Sensitive Data Exposure: Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser. 4 A4:2017 – XML External Entities (XXE): Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks. 5 A5:2017 – Broken Access Control: Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc. 6 A6:2017 – Security Misconfiguration: Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured; they must also be patched/upgraded in timely fashion. 7 A7:2017 – Cross-Site Scripting XSS: XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser, which can hijack user sessions, deface web sites, or redirect the user to malicious sites. 28. https://owasp.org/www-project-top-ten/. 29. https://analyse-innovation-solution.fr/publication/fr/php/objet-pdo-et-securite-mysql. 154 I ELECTRONIC GOVERNMENT PROCUREMENT IMPLEMENTATION TYPES: OPTIONS FOR AFRICA 8 A8:2017 – Insecure Deserialization: Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks. 9 A9:2017 – Using Components with Known Vulnerabilities: Components, such as libraries, frameworks, and other software modules run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts. A10:2017 – Insufficient Logging & Monitoring: Insufficient logging and monitoring, coupled 10 with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show that the time taken to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring. Electronic Government Procurement Implementation Types: Options for Africa AUTHORS: Blandine Wu Chebili - World Bank Group Hunt La Cascia - World Bank Group François Collineau - CKS Consulting Arnaud Salomon - CKS Consulting Baptiste Calvet - CKS Consulting Yoann Moreau - SQUAD