Africa Enterprise Challenge Fund
1. Background
- The Africa Enterprise Challenge Fund (AECF) transforms lives by providing investment funding and technical assistance to commercially viable businesses that improve the lives of rural communities. It mobilizes donor funding to support early and growth-stage businesses in agriculture and renewable and clean energy sectors, with a focus on improving incomes and employment for rural and marginalized groups. It is a non-profit organization, with its headquarters in Nairobi and operational centres in Somalia, Ethiopia, Dar-es-Salaam, Mozambique, Nigeria, South Sudan, Côte d’Ivoire, Burkina Faso and Benin.
1.2 Since our launch in 2008 at the World Economic Forum, AECF has built the resilience of rural and marginalized communities by catalyzing innovative private sector business models with patient capital and growth support services across Sub-Saharan Africa.
2. Invitation
2.1 Through this request for proposals (“RFP”), the AECF is planning to implement an Enterprise System that will manage the Portfolio process for AECF and integrate with the Finance System (ERP) I.e. Microsoft Dynamics 365 Business Central. The system will manage the full project life cycle i.e, the investee origination process as well as the subsequent steps up to the disbursement of the funds to the qualifying investees, the repayment process, provision of reports, investee statements, and management dashboards
2.2 Proposals must be submitted to [email protected] no later than 12th April 2024, 17:00 HRS East Africa Time
2.3 Prospective proposers should send an email to [email protected] requesting for process map and any other clarifications/questions before 20th March 2024, 17:00HRS East Africa Time
2.3 The AECF may, at its discretion, cancel the requirement in part or whole. It also reserves the right to accept or reject any proposal, annul the selection process, and reject all proposals at any time before selection, without thereby incurring any liability to proposers/firms.
2.4 Proposers may withdraw the proposal after submission provided that written notice of withdrawal is received by the AECF before the deadline prescribed for submission of proposals. No proposal may be modified after the deadline for submission of proposals. No proposal may be withdrawn in the interval between the deadline for submission of proposals and the expiration of the period of proposal validity.
2.5 All proposals shall remain valid and open for acceptance for a period of 180 calendar days after the date specified for receipt of proposals. A proposal valid for a shorter period may be rejected. In exceptional circumstances, the AECF may solicit the proposer’s consent to an extension of the period of validity. The request and the responses thereto shall be made in writing.
2.6 Effective with the release of this solicitation, all communications must be directed only to the Procurement department by email at [email protected]. Proposers must not communicate with any other person of the AECF regarding this RFP.
3. Request for Clarification of RFP documents
3.1 A prospective proposer requiring any clarification of the solicitation documents may notify the AECF in writing via the email address [email protected] by 20th March 2024. The AECF will respond in writing to any request for clarification of the solicitation documents that it receives by the due date. Written copies of the AECF response including an explanation of the query but without identifying the source of inquiry will be posted on the AECF website.
4. Amendments to RFP Documents
4.1 At any time before the deadline for submission of proposals, the AECF may, for any reason, whether at its initiative or in response to a clarification requested by a prospective proposer, modify the RFP documents by amendment. All amendments will also be posted on the AECF website.
5. Language of Proposals
5.1 The proposals prepared by the proposer and all correspondence and documents relating to the proposal exchanged by the proposer and the AECF, shall be written in English.
6. Submission of Proposals
6.1 Proposers shall submit their proposal in soft copy via email [email protected] Technical and Financial proposals must be submitted in separate documents and with a clear subject description of the proposal (technical or financial) by the date and time stipulated.
6.2 Proposals must be sent ONLY to the address provided above. Proposals sent to any other addresses will be rejected.
6.3 The Financial proposals shall include all applicable taxes quoted separately. If taxes are not mentioned in the financial proposal, The AECF shall consider that they are included in the prices provided.
6.4 The financial proposal shall include implementation costs, license costs, and expected recurrent costs for at least the first 3 years.
7. Late proposals
7.1 Any proposals received by the AECF after the deadline for submission of proposals will be rejected.
8. Conflict of Interest
8.1 In their proposal, proposers must confirm that, based on their current best knowledge, there are no real or potential conflicts of interest involved in rendering Services to the AECF.
9. Confidentiality
9.1 Information relating to the evaluation of proposals and recommendations concerning the selection of firms will not be disclosed to Firms that submitted proposals.
Statement of Work
- The AECF is planning to implement a Portfolio Management Information system that will handle end-to-end project lifecycle and portfolio management for investees (projects)
- The solution is required to automate the following processes as per the program life cycle:
- Business Development Phase
- Funding Proposal Development with collaboration capability
- Development of budgets
- Document repository for supporting documentation (all file types)
- Action tracker
- Inception Phase (Pre-Implementation)
- Creation of a program with standard program features e.g. implementation cycle/plan, target location, funder, programme code etc
- Development of budgets
- Development and tracking of work plans
- Development of standard templates to be used in the competition phase e.g. term sheets, eligibility criteria, marking criteria
- Results Measurement Framework for the program
- Document repository for supporting documentation (all file types)
- Competitions Management Application
- Development and tracking of work plans
- Application portal – with a standard concept note
- Automated eligibility screening
- In-system marking and scoring against the scoring criteria (team marking + 1 overall marker). Qualitative and quantitative scoring.
- Progress dashboard(s)
- Due Diligence
- AECF-Investee interphase for standard templates upload, download & exchange – Business Plan, Financial Model, Due diligence documents
- Document repository for supporting documentation (all file types)
- Standard investment memo
- Automated compliance screening checks, or integration to a third-party tool for Anti Money Laundering (AML), KYC (Know Your Customer) & PEP (Politically Exposed Persons) with a trigger system based on profiling.
- Dashboards
- Approval workflows and approval mechanisms by approval committees (internal & board level)
- Investment award letters
- Contract development interphase
- Monitoring & Evaluation
- Project planner (periodic)
- Project results measurement plan
- Processing of disbursements and collections
- Loan module
- Project management portal (interphase between AECF & Company)
- CRM (inbuilt or interphased)
- Reporting
- Program progress dashboard – budget, results measurement,
- Project performance dashboard
- Standard project metrics reports
- Project Close out
- Close out notification/letter
- Archive
- Other General Considerations; Design required workflows on the system to allow end-to-end processes on the system.
- The system should have the ability to link projects to the respective programmes and the ability to track and reconcile project funds vs. program budgets; results measurement plans (RMP) for overall programme vs. RMP for projects.
- Ability to translate currencies based on set criteria or through integration with the ERP (Microsoft Dynamics 365 Business Central).
- Ability to offer basic translation services – English, French, Arabic, German & Portuguese
- Design and customize a document repository that will hold all the documents and reports generated from the portfolio process.
- Implement the approval process flow onto the system and configure to fit the AECF governance structure
- Configure the approval matrix onto the system to allow all approvals to be done on the system.
- Integrate the Portfolio Management Information System to different systems like the core financial system, Microsoft Dynamics 365 Business Central(ERP), Power BI, Tableau
- Provide the licensing model for the software
- Ensure the system has provision for canned and ad-hoc reports
- Provide responsive and timely maintenance & support services for the platform over the duration of its use.
The general scope of work
The scope of work primarily consists of five elements as follows:
- Supply, implementation, and installation of a suitable Portfolio management information system, database, and related software. 3 years of maintenance after the implementation project.
- Advice on installation and commissioning of appropriate platform & supporting software, and network links, in association with AECF’s chosen service providers.
- Setting up of the necessary ICT infrastructure and application support function with minimum requirements delivering a performance level and availability requirement suitable for AECF.
- Implementation services including application installation, custom development, data conversion and migration, training and change management, documentation, fitting the solution’s specific customer support arrangement, and warranty services.
- Optional, on-demand support services, especially for the period beyond implementation project closure.
The proposed project plan should cover the activities listed above.
Specific Duties and Responsibilities of the Implementor
The Implementor will be responsible for the following:
- Responding to the RFP and executing the same if selected, describing the process to be followed for supply and implementation of the software.
- Supply a suitable Portfolio Management Information System indicating specific modules and justification for satisfying the functional and technical requirement specifications laid down in this document.
- Test the solution configured and provide quality assurance within the project.
The product proposed by the Implementor must comply with the mandatory criteria below;
- It must be of the latest commercially available and acceptable version, at the time of
commencement of project implementation.
- It must have all functions described in business process requirements as natively integrated applications on a single interoperable open platform and not the integration of multiple products and overlapping middleware.
- It must provide a mandatory Single-Sign-On authentication matching with the AECF’s current environment; Microsoft Azure.
- Upgrade to new releases should not become mandatory for the next three years from
the date of installation.
- It must have a product roadmap for the last 3 years and the next 3 years, demonstrating a vendor commitment to continuous investments and enhancements for the specific Portfolio Management Solution.
- It must be upwards scalable in size, capacity, and functionality to meet changing business and technical requirements, thereby enabling AECF to be adaptable to change.
The vendors will be required to provide detailed documentation on the following in their technical response:
- The Portfolio Management Solution, required customization if any, tools, database, network performance and the related software being supplied to meet the functional and technical requirements set out in this document.
- The process to be followed in the installation and configuration of the Portfolio Management Solution, tools, database, and related software.
- The process to be followed for maintenance and upgrade of the Portfolio Management
Solution, applying patches, tools, database, and the related software.
- Specifications that are most suitable for running the solution provided to AECF comprising of the operating systems, administration tools, bandwidth requirements, firewalls, and any other item required for the proposed solution considering AECF’s serverless environment, with all core current and future applications running on virtual machines in an external Cloud environment.
Implementation services
The Implementor will be responsible for the following during the implementation;
- Design and implementation of system architecture
- Project management, planning, and scheduling various phases of the implementation
- Verify and ensure the completeness of business process descriptions and their mapping against the capabilities of the Portfolio Management Solution
- Conceptualizing, configuring, developing, customizing, validating, and implementing the solution, including developing and testing interfaces, custom applications, data conversion where required, training and change management, documentation etc.
- Providing post-go-live support.
Each of the tasks is described in detail below. Some of these are also explained in detail further in this section.
Design and implementation of system architecture
The implementor shall be entirely responsible for the architecture of the system implemented to satisfy all features, functions, and performance as described in this document. The system architecture description provided in this document is for guidance only. The vendor should validate the description as necessary to provide a complete solution.
The System architecture shall be developed with the following guidelines in mind:
General System Architecture Guidelines
- The system architecture should be based on open and prevailing industry standards and protocols.
- The system will be Cloud-based or cloud-ready, centrally deployed and accessed.
- Role-based access shall be planned to ensure high granularity without compromising on the security needs of the application.
- The system shall be designed to be scalable and extensible.
Application Design
- The application design should be a services-based architecture for all environments.
- All application components should have a browser-based user interface with a common look and feel.
- All production applications must have high availability.
- All systems must consider appropriate security, performance, efficiency, and maintainability issues.
- Must have a web-based Investee Self-Service portal that would be available to investees without a full license requirement.
Data Management
- Data will be owned, shared, controlled, and protected as a corporate asset.
- Shared data will have consistent formats and definitions and be independent of applications.
- Data should only be accessed through application/interfaces to create, update and
modify
- The system must have an inbuilt data repository allowing data to sit and be accessed within the system
Infrastructure
- The architecture should be designed for extensibility and scalability
- The system must be designed in such a way that it supports all future enhancements, load balancing of the application, presentation, and data layers of the system.
Project management, planning and scheduling
Project Team
- The implementor will form a full-time team for the project consisting of the Project Manager, Functional Leaders and other team members. The key team members should be professionally qualified/trained in their tasks and should have requisite Portfolio Management Solution implementation experience. Swapping of resources during the project will not be permitted without prior approval by AECF.
- The implementorshould specify the expected involvement of AECF employees within the project team structure. The implementor should further describe the recommended composition and terms of reference of the Project Steering Committee.
- The implementor’s project plan will adequately account for User Acceptance testing, and documentation related to Controls, Security, and Segregation of Duties; and the activities will adequately account for the implementation of controls identified in our business processes.
Implementation Plan
The date of award of the contract to the Implementor will be considered as the start date of implementation.
Below are the guidelines to be adhered to;
- The implementor should propose a suitable project plan in such a manner that overall timelines, as specified in this document, are adhered to. The implementor should provide a detailed schedule for all items as per the total scope of work matching with the implementation plan.
- The Implementorwill further detail the project plan in the early stages of the project and get it validated by AECF. The project plan should include the following at the minimum:
- The project is broken up into logical phases and sub-phases;
– Activities making up the sub-phases and phases;
– Key milestones and deliverables along with their dates;
– Start date and end date for each activity;
– The dependencies among activities;
– Resources / Consultants to be assigned to each activity;
– Resources (core team, business team and process owners) expected from AECF
for each activity.
- In addition to the implementation plan, the Implementor should formulate and submit other key documents including, but not limited to, the following:
- The Interface Strategy describing high-level interface points between Portfolio
Management system & Financial Management System (ERP);
- Data Conversion Strategy describing the data elements that would need to be converted and the process to be followed for the same;
- Solution Design Strategy including the system test strategy;
- Risk Management Strategy, identifying, analyzing and evaluating the project risks and the process to be followed in mitigating those risks;
- Training Strategy, describing and implementing the proposed approach in providing training to various categories of users;
- Change Management strategy and Post implementation support strategy;
- In addition to the strategy-level documentation above, implementation-related documentation is expected. All documentation will be in English and subject to review and acceptance by AECF. It is expected that documentation will capture an adequate level of detail and will be presented professionally to AECF.
Project Reporting
- The Implementor should describe the proposed project reporting methodology. As a minimum, a progress report to AECF is expected each fortnight. The frequency may be increased during critical phases of the project. Additionally, the Implementor shall report continuously, project risks, mitigation, exceptions, and issues that require the immediate attention of AECF.
- The AECF will nominate an internal focal point, to ensure seamless coordination between
the parties.
- The Implementor will via its Project Manager be responsible for attending meetings of the Project Steering Committee, informing the membership about progress and status, discussing potential options ahead, and seeking clearance for potential change requests.
Developing, configuring, and testing the solution
The implementor will also be responsible for the following;
- Developing and customizing the solution based on the business processes, proposed improvements, and satisfying the business and reporting requirements of AECF; Configuring the solution including the development of necessary interfaces with external data sources and basic platform applications;
- Ensuring that the necessary controls and security are configured in line with AECF’s policies and controls and are acceptably automated to the extent possible.
- Conducting Unit Tests, System Integration Tests, User Acceptance Tests, Stress Tests, and other tests and making necessary changes to configuration/setup based on the test results, implementation of pre-go live audit recommendations, etc.;
- Training and change management;
- Data conversion and migration; and Go-live and cutover activities.
Providing post-go-live support
Below are the guidelines for post-go-live support;
a. The Implementor will provide post-implementation support for six months from the go-live of all implemented modules from the final go-live date.
b. The Implementor will provide guidelines in setting up and managing the Portfolio Management Solution customer support regime including the processes to be followed in logging requests for assistance, assigning requests to specific individuals, escalating calls to technical, business, or vendor actors, recording resolution and tracking overall time frame from logging a call to its resolution.
c. The Implementor will provide a meaningful Portfolio Management Solution Service Level Agreement that helps in managing expectations and roles between users and internal/external Portfolio Management Solution service providers.
d. In addition to the above-mentioned post-go-live support, the Implementor may be requested by AECF to provide additional support for problem resolution, enhancements etc.
e. The Implementor will describe its team for post-implementation support along with their roles, job descriptions, and profiles of key individuals. If such additional support is expected to be charged separately, then the Implementor will propose time and material rates for this as mentioned in the price bid separately.
- The Implementor shall co-operate with AECF in the conduct of any post-implementation audit (by a party other than the Implementor), if so desired to be conducted by AECF, during the period of post-go-live support. The Implementor shall also be responsible for implementing the audit recommendations without any additional charge. Also, in the event of AECF conducting an independent pre-go-live audit, the Implementor shall render all necessary support for the audit, including implementing the changes/improvements if any are recommended, free of additional charges whatsoever.
Functional scope
The new system should be a centralized, Cloud-ready Portfolio Management Solution maintaining all the data under a single database.
Technical scope
The features that characterize the system shall include, but not be limited to the following:
a. User Interface
Below are the guidelines for the user interface;
- The end-user interfaces could be web interface or Graphic User Interface (GUI) based.
- The Implementor should account for access from remote locations with weak internet connections.
- Most Portfolio Management Solution user interactions should as well be
feasible via mobile devices running on Android, Apple iOS, and Windows.
- Wherever possible, data should be available for entry from a drop-down list. There
should be field-level validation of the data being entered. In case of an error in data type, the error message should be customized to AECF specification.
- It should be possible for the system administrator to restrict certain values for entry to specific users. It should also be possible for the users to retrieve data entered incorrectly and change the same subject to a defined security procedure.
- The system should be capable of reusing the data once captured, to ensure the integrity of data.
b. Single Point Data Entry
Below are the guidelines for data entry;
- The system should be able to automatically capture data from other retained legacy/process control systems through integration.
- There should be a single set of data which once created should be available for use by all users, thereby eliminating the need for multiple data entries and ensuring data consistency across the system. This applies not only to the transaction-level data but also to all master data, which may be shared across functions.
c. Centralized / Common Master Data
Below are the guidelines for master data capture and storage;
- The solution envisaged by AECF assumes a centralized master data repository to be shared by all the units based on their requirements.
- Centralized/Common master data repository means that there would be only one set of master data across the organization capable of maintenance from any or all units with centralized approval workflow.
- The master will have data common to all units as well as data specific to a unit.
- While managing data, the system must provide adequate control and security for addition, modification, deletion, and validity. The values will be assigned to individual units based on their requirements.
- The Implementormust ensure that the Portfolio Management Solution proposed by them has an extensive facility concerning maintaining an audit trail. The system shall be able to define audit trails, audit logs, and transaction logging requirements. It shall enable audit trails online, and tailor audit requirements by modules.
d. Audit Trail
Below are the guidelines for the system audit trail;
- Any addition, deletion, or modification to an existing record, whether master or
transaction must bear the date and time stamp, the name of the log-in user who made the change, and the terminal from which the change was made. It should also be possible to maintain details of the original record and subsequent changes to the record. Standard audit-related reports should also be available.
e. Online Help Facility
Below are the guidelines for the online help user support functionality;
- The system should also provide context-based online help capability for every process in the proposed solution. This online help facility should be customizable to make it AECF processes specific. The Implementor must indicate how it proposes to make the online help tailored to AECF.
g. Modularity
Below are the guidelines for the system’s modular implementation;
- AECF expects the proposed Portfolio Management Solution to be modular in nature allowing for a modular implementation.
- The system will initially be required to cover a range of business processes across various functional areas/modules, but it should also allow the addition of more functional modules as and when required, which should seamlessly integrate into the core system without encountering any technical issues.
- Integration between such new modules and the modules already implemented should be seamless and should not require significant development effort.
h. Scalability
The Portfolio Management Solution being proposed by the Implementor must be scalable both in terms of the business rules, volume of transaction, and master data but also in terms of defining new entities and structure.
i. 24/7 Support Operations
The Implementor must ensure that the Portfolio Management Solution is supported by 24/7 operations. This is necessary as AECF will work with implementation partners and stakeholders across all time zones worldwide.
j. Reports
Below are the guidelines for reporting needs;
- It is expected that all the out-of-the-box reports will be reformatted as per AECF’s
requirements and fields could be replaced/removed if required.
- It is expected that custom reports may need to be developed if the standard reports available in the Portfolio Management Solution Product do not meet AECF specific requirements. These reports would include those, which would extract and present information already in the database in a specified format or could require some intelligence/calculations built into it.
- The Implementorshall explain how AECF’s need for agility and flexibility in reporting will be addressed without costly custom development work. A brief description of the methodology should be included in the response to the RFP.
- In addition, the Implementor is required to train AECF Core/ Technical Team members on
- the methodology of building custom reports, so that AECF can take up the additional development on need basis.
k. Data Validation and Migration
Below are the guidelines for data validation and Migration;
- The Implementor is expected to prepare and submit a Data Conversion Strategy Document during the initial study stage of the project describing the broad data elements to be manually entered or in an automated fashion.
- A tentative timeframe for developing the potentially necessary scripts, testing the same and eventual execution on the Production environment should also be indicated.
- The Implementor shall:
- Describe the approach and tentative plan for training AECFs core
– Identify data elements (Master and Transactional) to be migrated;
– Ensure collection of all data required from identified sources with AECF assistance;
– Support AECF in aiding the cleansing, enriching, and formatting of pre-existing data categories;
– Prepare and validate data mapping structure;
– Prepare data migration scripts and templates
– Run successful trial data migration;
– Upload data to the new test and production system upon acceptance by the data owners;
– Reconcile and validate migrated data and status of transactional data; and
– Create new/additional data mandatory in the new system.
l. Training Scope
AECF believes that the key to successful Portfolio Management Solution implementation will be the Implementor’s ability to train AECFstaff in operating the proposed business solutions. In this context, the Implementor is expected to:
team members and end-users along with the tentative time frame;
- Include the training budget in the proposal;
- Provide a description of the training hand-outs and/or operating manuals to be provided to the core team members and the end-users;
Training programs will have to be organized for separate categories of users based on functions, roles, responsibilities and geographic locations. The Implementor will be responsible for the preparation of the training material and end-user manuals. End-user manuals should cover “how to use” concepts for all Portfolio Management Solution modules to be implemented.
m. Change Management Workshops
In addition to the above, the Implementor will create a change management approach and workstream to identify issues anticipated in the change management process and propose solutions to overcome these. The Implementor is expected to conduct the change management programs on a one-on-one individual basis or in groups and at different locations.
The goal of change management in the context of AECF would be:
– Collaborative working – shared sense of purpose and ownership;
– Technology adoption as a means of efficient service delivery; operations of submissions and approvals in workflow environment;
– Adoption of Business Intelligence tools for analysis and supporting decision-making;
– To create a knowledge-sharing culture in the organization;
– Self-initiated view of learning and readiness to learn from each other;
– The overall climate of trust and involvement;
– Partnering mindsets and capabilities.
Change Management will be a key milestone in the project and will be subject to acceptance.
Technical Proposal
1. The Technical Proposal must be submitted separately and clearly marked on the document and email subject “Technical Proposal”. No details of a financial nature whatsoever should be included in this Technical Proposal. Failure to comply with this requirement will result in the disqualification.
2. Proposers are requested to submit a Technical Proposal that demonstrates the capability to deliver requested services
3. To facilitate a faster evaluation and comparative analysis of the proposals, we recommend that the proposals be structured in the following manner:
a. Expertise of Firm/Organization – This section should provide details regarding the management structure of the organization, organizational capability/resources, and experience of the organization/firm, the list of projects/contracts (both completed and
on-going, both domestic and international) which are related or similar in nature to the requirements of the RFP.
b. Proposed Methodology, Approach, and Implementation Plan – This section should demonstrate the implementor’s response to the RFP/scope of services by identifying the specific components proposed, how the requirements shall be addressed, as specified, point by point; providing a detailed description of the essential performance characteristics proposed; identifying the works/portions of the work that will be subcontracted; and demonstrating how the proposed methodology meets or exceeds the specifications while ensuring the appropriateness of the approach to the local conditions and the rest of the project operating environment.
c. Management Structure and Key Personnel – This section should include the comprehensive curriculum vitae (CVs) of key personnel that will be assigned to support the implementation of the proposed methodology, clearly defining the roles and responsibilities vis-à-vis the proposed methodology. CVs should establish competence and demonstrate qualifications in areas relevant to the TOR.
In complying with this section, the implementor assures and confirms to AECF that the personnel being nominated are available for the Contract on the dates proposed. If any of the key personnel later becomes unavailable, except for unavoidable reasons such as death or medical incapacity, AECF reserves the right to render the proposal non-responsive. Any substitution of personnel arising from unavoidable reasons shall be made only with the approval of AECF.
d. Other Information as may be relevant to the Proposal – The Technical Proposal shall not include any financial information. A Technical Proposal containing any form of financial information that could lead to the determination of the price offer may be declared non-compliant.
Financial Proposal
Pricing Information
- The Financial Proposal should include pricing information covering the requirements covered in this document
2. The Financial Proposal document must be clearly marked “Financial Proposal” as well as the email subject. NO details of a financial nature whatsoever must be included in the Technical Proposal. Failure to comply with this requirement will result in disqualification.
- The financial component shall include the following:
- Fee structure and pricing details in US dollars including all expenses and applicable taxes;
- A financial methodology that explains the rationale of the financial component and how it offers the best value;
- A financial plan that clearly links all costs to activities and outputs detailed in the work plan with associated payment mechanisms;
- Unit rates
- Total Lump sum Contract amount
Financial proposals that do not have the above details will be disqualified.
4. The implementor shall include and clearly show all expected taxes in the financial component.
5. The AECF reserves the right to give preference to the most appropriate baseline in terms of expected economies of scale for the AECF.
6. The financial proposal shall be fixed price and not based on Time & Material. It should contain real efforts in terms of man-days (i.e. Junior, Intermediate, Senior, etc.) and price per man-day for each category. Based on the Technical proposal (Workplan, methodology, personnel, goods and services to be supplied under the contract, and the unit rates, the bidder must provide a total lump sum fixed price for determining the financial score and contract value. The financial proposal should provide the financial total contract price as well.
Company Profile Form
Please respond to all questions within your proposal.
Company details – vendor’s name:
Name:
General Information
PrimaryContact
Address
Postal Code
Country
Telephone
Website
The parent company, if any
Subsidiaries, Associates and/or Overseas Rep(s), if any
Year established
Type of organization
Public Enterprise ( ) Private Company ( )
Organization sponsored by donors ( ) Other (please specify) ( )
Type of Business
ICT Software Implementor ( )
Software Vendor ( ) Consulting Company ( )
Other (please specify) ( )
Summary of main business activities
No. of employees (by location)
In-house working language(s)
Bank Name
Bank Address Account Holder Account Number
SWIFT
Prior experience with international organizations
List contracts undertakenin the last three years with a similar scope.
BRIEFLY listrecent clients for whom you producedsimilar deliverables as well as values: Attach additional sheets ifnecessary.
1
2
3
4
Contract disputes
List any disputes your company has been involved in over the last three years
References
List suitable reference projects and contacts.
What options would there be for a site visit to a reference project and/or the vendor’s site?
1
2
3
Partners
If this is apart bid, list relevant recent experience of working with partners.
Are there already formal or informal preferredpartnership agreements in place?
1
2
3
Conflict of Interest
Are there any likely circumstances or contracts in place that may introduce a conflict of interest with the parties to this contract? If so, explain how this will be mitigated
1
2
Timelines
1. The AECF will follow the timeline below for this RFP. Any changes to this timeline will be posted on the AECF website. Please note that the target dates and may be adjusted.
Event
Responsible Party
Date (and time, EAT*)
1
Posting of RFP
AECF
11 March 2024;
2
Last date for requests for process map and/or clarification of the RFP
Vendor
20 March 2024; 17.00HRS
3
Last date to reply to questions received/ Last date for amendment
AECF
22 March 2024; 17.00HRS
4
Last date for submission of the proposal
Vendor
12 April 2024; 17.00HRS
*EAT: East Africa Time (Nairobi)
Evaluation Criteria
A. Evaluation and Comparison of Proposals
The proposals will be evaluated in a staged procedure, with the evaluation of the technical proposal being completed prior to any financial proposal being opened and evaluated. The financial proposal will be considered only for submissions that fulfill the minimum technical requirements.
B. Acceptance of Submissions
All proposers are expected to adhere to the requirements for submitting a proposal.
Any proposals that fail to comply will be disqualified from further consideration as part of this evaluation. In particular:
- Full compliance with the formal requirements for submitting a proposal;
- Submission of all requested documentation
The Technical Proposal shall include information to demonstrate the current soundness and financial position of the submitting organization:
- Organizational: a brief description, including ownership details, date and place of incorporation of the firm, objectives of the firm, partnerships, qualifications and certificates, etc.
- Statement of Satisfactory Performance of similar services fromthe firm’s top 3 (three) Clients in terms of Contract Value the past 3 (three) years. Contact details of the mentioned clients must be provided.
- Listing of proposed personnel, experience and qualifications
- Comments on the RFP and how the firm will address the requirements
- Methodology and approach
C. Evaluation of Technical Proposal
A reviewing committee shall be established to evaluate each technical proposal. The committee will comprise of evaluation and technical specialists. The technical proposal is evaluated individually based on its responsiveness to the technical requirements and will be assessed and scored according to the evaluation criteria.
Technical proposals that score at least 75 points out of 100 will be considered as qualified for the review of financial proposal. Any proposal less than that will be disqualified from proceeding to the next step and its financial proposal shall be reviewed.
The Technical Proposal will account for 70% (weight of 0.70) of the evaluation score.
D. Evaluation of Financial Proposal
The financial proposal of all offerors, which have attained the minimum score in the technical evaluation, will be evaluated subsequently.
The lowest evaluated Financial Proposal will be given the maximum financial score.
The Financial Proposal will account for 30% (weight of 0.30) of the evaluation score.
E. Consolidated evaluation
The total score of 100 points will consist of 70 points weighted from technical evaluation and 30 weighted points from the financial evaluation. The firm achieving the highest combined technical and financial score will be invited for contract negotiations.
F. Award
The Award will be made to the responsive implementor who achieves the highest combined technical and financial score, following the negotiation of an acceptable contract. AECF reserves the right to conduct negotiations with the implementor regarding the contents of their offer. The award will be in effect only after acceptance by the selected proposer of the terms and conditions and the technical requirements.
Expected Evaluation Method
Submitted proposals will be evaluated against a detailed evaluation criterion. Below is the indicative evaluation sheet. AECF reserves the right to use an updated evaluation criterion at the time of actual evaluation of proposals/systems.
1. Instructions
1.1 Completion of this document
Please complete each part of this Annex 1 (unless otherwise indicated) or provide a brief explanation where this is not possible using the space available. The vendors are asked to
respond by addressing the following:
Does your proposed solution meet the requirements as stated?
If the solution fully meets the requirement, please answer “Yes” under Fully Available column. If the solution meets the requirement partially, please indicate the percentage of the requirement under Partial (%) column and address the difference percentage under Gap (%) column. If the solution does not meet the requirement at all, please answer “Yes” under N/A column.
If the answer is “Partly” in the Partial (%) and Gap (%) column, please address the impact of the gap under Gap Impact column and the mechanisms or functionalities which will be used to address the gap under Gap Addressing Mechanism column. The vendors are also welcome to make suggestions or comments in the comment/Observation column.
Annex 1: Evaluation Criterion
ID
Requirements
Vendor
Short Name
Description
Priority
Fully
Available
Partial
(%)
N/A
Gap (%)
Gap
Impact
Gap Addressing Mechanism
Comment/ Observation
1
AECF Template
Customization
The system has the functionality to manage competitions using web-accessible customized forms on a need basis for use externally to collect information. Customization of AECFtemplates – Competition, Concept Notes, Funding Proposals and Review Template)
High
2
Form
Modification
Ease of form modifications
-Vendor needsto specify whether the form modification needs to be done by them or it can be modified by AECF
High
3
Data Transfer between stages
Data transfer between different stages: competition stage, concept note stage etc.
High
4
Concept note marking
The system has the functionality to support concept note-marking on the system, with scoring and comments captured for the various users
High
5
Process documents reviews
The system has functionality to support document reviews during the investee selection process with a workflow configured on the system. The system allows AECF to build in the document templates and change them on need basis to fit the need
High
6
Financial statement analysis
The system has functionality for financial statement analysis
High
7
Integration requirements
The system must offer a rich set of APIs including but not limited to Java, .NET, Rest, Web services, CMIS APIs
High
8
Document viewer
The system must provide a web-based document viewer
High
9
Workflows
The application should provide out-of-the-box workflows to allow custom configuration of approval processes on the system
High
10
Compatibility with Microsoft platform
The system should be compatible with common Microsoft based system tools e.g. Power BI, Office 365, Microsoft Dynamics 365
High
11
Document management
The system should be able to reference documents in the inbuilt document repository as well as those attached via links to external sources e.g. cloud storage locations
High
12
Filling/folder Structure Support
The system should support a filling structure where an agreed folder structure is auto-generated for any newly created account
High
The AECF currently receives Concept Notes and other supporting documents in a word, excel or PDF template through email. Investees also send supplementary documents (financial analysis, due diligence reports, bank statements etc.) in word, excel and pdf files.
ID
Requirements
Vendor
Short Name
Description
Priority
Fully
Available
Partial
(%)
N/A
Gap (%)
Gap
Impact
Gap Addressing Mechanism
Comment/ Observation
13
Eligibility
Questions
Before applicant submitsConcept Notes and Funding Proposals, they should be asked eligibility questions
High
14
Form Intake
Intake of concept notes and/or funding proposals
High
15
Form Save and return
Applicant to save Concept Notes and Funding Proposals as drafts and return whenever to finish
High
16
Mandatory Fields
Some fields must be marked as mandatory
High
17
Submission
/Resubmission
Applicant to submit/resubmit Concept Notes and Funding Proposals. Once resubmitted, both applicants and reviewersshould be able to see the changes that have been made and different versions of the document
High
18
Endorsement
Endorsement of the application by the applicant’s officer in
charge
High
19
Supplementary
Documents
The applicant can upload supplementary documents (word, excel, pdfetc.)
High
20
Rich Text fields/HTML
Allow the applicant to copy/paste pictures/charts/tables within the fields (HTML or rich text)
High
21
Text fields
Include drop-downs, checkboxes, and text fields in the application
High
22
Spelling check
Provides spell-check
High
23
Form ID
Concept Notes/ Funding Proposals are given their own unique ID for the database
High
24
Online Help
Online help function and User Guide to assist an applicant in filling out Concept Notes and Funding Proposals. It would be ideal to have a detailed description of the field pop-up once a user puts a mouse over the field
High
25
Form Builder
A complex form builder (business logic included in the form) should be available. This includes an applicationform, checklist,approval forms etc.)
High
26
Providing
Countries
information
Single proposal with multiple countries/accredited entities
High
27
Dependency on other projects
Funding proposal could be relevant to one single project or several sub-projects.
High
28
Use of different financial
instruments
Funding proposal could have multiple financial instruments (grant, loan, equity,guarantee and
debt)
High
29
Discard application
The applicant can discard an application not yet submitted so that they can restart an application from scratch
High
30
User-Defined
Field
User-defined fields and additional custom fields are required
High
31
Word Count
Word count function for each field
Low
Portal/Dashboards
The minimum information to be displayed on the dashboard
ID
Requirements
Vendor
Short Name
Description
Priority
Fully
Available
Partial
(%)
N/A
Gap (%)
Gap
Impact
Gap Addressing Mechanism
Comment/ Observation
32
Dashboard for Investee
Investees should be able to see lists of Concept Notes and Funding Proposals when they log in – thisincludes submitted and work-in-progress Concept Notes and Funding Proposals
High
33
Information
Document Folder
The information Document Folder should contain board decisions or any other documents the investee should be aware of.The solution should have an acknowledgment checkbox for the investee to click if they have read the documents or not.For any newly updated documents, the alertmessage should notify the investee to read the documents and the investee should click an acknowledgment checkbox.
High
34
Dashboard for Reviewers (Internal
Reviewer)
The Reviewers should be able to see the list of submitted Concept Notes and Funding Proposals when they log-in. The Dashboard should be
different for different reviewers
High
35
Dashboard for Administrator (Internal
Reviewer)
An administrator should be able to see all submitted
Concept Notes and Funding Proposals
High
36
Dashboard for Sector Lead (Internal
Reviewer)
Sector Lead should be able to see all submitted
Concept Notes and Funding Proposals
Sector Lead should be able to assign the submitted Concept Notes and Funding Proposals to a Portfolio Officer
High
37
Dashboard for
Portfolio Officer (Internal Reviewer)
The Portfolio Officer should be able to see submitted Concept Notes and Funding Proposals that have been assigned to them by the Sector Lead.
High
38
Dashboard for Technical Reviewers (Internal
Reviewer)
Technical Reviewers should be able to see submitted Concept Notes and Funding Proposals that have been assigned to them by the Portfolio Officer and approve
High
39
Dashboard for investment committee (External Reviewer)
Independent investment committee should be able to see submitted Funding Proposals that have been assigned to them by Sector Lead and approve
High
40
Dashboard for Board Members/ Advisors
(External
Reviewer)
Board Members and Advisors should be able to see Funding Proposals that have been assigned to them by Sector Lead or Officer in charge. They
will not be required to see all the internal review processes. They should be only able to see the documents assigned to them.
High
41
Filter/Search
Function
For both investee and AECFusers, there should be filter & search functions
High
42
Project Summary
Page
When investee or AECF users click the project name or ID, the system should lead them to the project summary page where it outlines a summary of the project
High
Review of submitted documents
43
Historical Relationship Details
History of a relationship with prospective applicants, for example, what types of instruments they have applied for or been given in the past
High
44
Track change
Ideal for Reviewers to make comments like word online (with track changes/commentsetc.)
High
45
Review applications in a
meeting
A group of people can view a batch of applications ina meeting so that they can come to a joint recommendation. The recommendations from all previousrecommendation stages must be visible for each application
High
46
Generate meeting minutes
AECF user can generate meeting minutes so that a summary of all the recommendations/ decisions
can be circulated to the attendees and other interested parties
High
47
Document forms atdifferent
stages
Checklist, review forms, monitoring forms, financial and completed proposal evaluations and technical
sign off documentation to be provided
High
48
Text Fields
Include drop-downs, checkboxes and text fields in the application
High
49
Dynamic
Workflow
Dynamic workflow by applicationis required
High
50
Custom
Workflow
Custom workflow by application is required
High
51
Confidential comment section for AECF
The confidential comment section for AECF is required. This confidentialcomment should not be visible to the investee but should be only visible to assigned people
High
52
Change Log
Change log of the documents needs to be available toAECF & Investee
High
ID
Requirements
Vendor
Short Name
Description
Priority
Fully
Available
Partial
(%)
N/A
Gap (%)
Gap
Impact
Gap Addressing Mechanism
Comment/ Observation
52
Submitted document revision
Investee should not be able to edit documents once submitted. They should be only able to revise/edit once the reviewer sends back.
High
53
Communication
Capture
Capturing all communications/exchanges related to projects
High
54
Template
Letters/Emails
Create and use letters/ emails template
High
55
Condition tracking
The system should track the status of a document, and stage in the process, inform of the current state
High
56
Reworks with comments
Every reviewer should be able to revert the process to earlier touchpoints with provision for comments and direct re-route option for non-material changes, and different routing conditions for different amendments
High
Internal & External Email Notifications
The solution is required to allow AECF to send email notifications – e.g. acknowledgement email, reminder notification, late notification, etc. – to entities at various points in the process and auto business process based on the business rule settings.
ID
Requirements
Vendor
Short Name
Description
Priority
Fully
Available
Partial
(%)
N/A
Gap (%)
Gap
Impact
Gap Addressing Mechanism
Comment/ Observation
57
Email Notification content
Email notificationcontent should contain a link to the document, ID, the project name and the task to be conducted
High
58
Email Integration
The solution should allowseamless integration with AECF email server and automatically store all communications related to investee with the subject containing specific Identification.
High
59
External Email
Notification
Investee should be able to receive email notifications whenever reviewers send back the forms and send messages
High
60
Internal Email
Notification
Portfolio officer should receive an email notification once they are assigned on a project
High
61
Internal/External
Notification
Users should receive email notifications whenever Reviewers makes comments on reviewed documents and send messages
High
62
External Email
Notification
Board/advisors should receive an email notification when document is sent for their review
High
63
Email Audit Trail
All communication associated with one file ID to be accessible for audit purposes
High
64
Deadline
Each process step to have deadlines and the user is warned/alerted
High
Reporting Requirements
The solution is required to produce standard reports, ad-hoc reports, and on-demand reports across entities, process, regions, etc. The solution should be able to generate reports in pie chart, bar chart, table, spreadsheet etc.
ID
Requirements
Vendor
Short Name
Description
Priority
Fully
Available
Partial
(%)
N/A
Gap (%)
Gap
Impact
Gap Addressing Mechanism
Comment/ Observation
65
Visibility
The reporting function only available to selected users
High
66
User-defined columns
Users should be allowed to add a column of the information they want to see
High
67
Dashboard coverage
The reporting function should cover all types of financial instruments
High
68
Timeline
Tracking
Project timeline as well as disbursement timeline to be generated and systematically tracked and monitored
High
69
Reporting
Function
The system should allow the users to save reports and also make small updates to standard reports
High
Allows users to have favorite reports without navigating a much larger set and save
High
70
Quantitative report
The reporting should allow AECF to identify the total number of applications received, the number of applications by status etc.)
High
71
AdvancedReporting function
The reporting data should be easily converted to pie charts, bar graphs and be exportable to common analysis tools e.g powerBI, Tableau
High
User Management / Access Right Management
ID
Requirements
Vendor
Short Name
Description
Priority
Fully
Available
Partial
(%)
N/A
Gap (%)
Gap
Impact
Gap Addressing Mechanism
Comment/ Observation
72
Account
Management
There should be multiple but limited numbers of accounts per investee
High
73
At investee’s request, some applications should be only visible to certain users within the investee organization i.e named users
High
74
Shadow a public user
AECF or Solution system administrator can “shadow or impersonate” a user (i.e. see the users’ data) so that they can provide online or telephone support (this needs to be done without having to ask for investee’s log-in details)
High
75
User
Management
The Administrator should be able to activate/deactivate any user
High
76
Reassignment
Investee should reassigntheir users withintheir organization after AECF’s approval.
High
77
Reviewerscan be additionally assigned and removed at any time by Sector Lead or Administrator depending on the situation (ex. sick leave, vacationand etc.)
78
Log-in
Credentials
Users should be able to easily reset lost credentials
High
79
Terms and
Conditions
All users, including AECF staffs, should agree on terms and conditions page when they first log-in
time).
High
80
Create user group
A system administrator to create a group of users
High
81
Assign roles to groups
A system administrator can assign roles
High
Performance & Monitoring
ID
Concept Note & Funding Proposals Requirements
Vendor
Short Name
Description
Priority
Fully
Available
Partial
(%)
N/A
Gap (%)
Gap
Impact
Gap Addressing Mechanism
Comment/ Observation
82
Qualitative data
Intake of qualitative data with no limits in the number of words that can be received
High
83
Quantitative data
Intake of quantitative data (indicators – to be expressed as figures, percentages or scorecards)
High
84
Document by applicant
Intake of documents that can be uploaded and tagged by the investee as necessary (for example “evaluation report”)
High
85
Alert system to
investees
Each project/programme has a different timeline. The user should be able to insert the expected date of the evaluation report/Final evaluation report as perthe project term sheet. All dates should be tracked and linked to alert system sending email alerts.
High
86
Feedback
Interface for feedback between the AECF and theinvestees concerning the submission of the reports
High
87
Dashboard
(indicator)
Visualization of indicator progresses towards the targets set
High
88
Dashboard
(workplan)
Visualization of the associated progress in relation to the workplan submitted.
It is usefulto have a status check system for each outputin the workplan so that the entity can mark each output of the project in three types of status “not started” – “in progress” or “completed”
High
89
PDF conversion
Export function of the information submitted in PDF
High
90
Reporting
Exporting the dashboard in PDF and xls. Formats.
High
Finance Specific Requirements
ID
Requirements
Vendor
Short Name
Description
Priority
Fully
Available
Partial
(%)
N/A
Gap (%)
Gap
Impact
Gap Addressing Mechanism
Comment/ Observation
91
Financial data
Financial data should be accommodated (e.g. bank name and address, account number and account holder’s full name, swift (BIC) code, IBAN, etc.) and Finance should be able to review the information
High
92
Payment
schedule transfer
Payment schedule or structure should be part of investee data & Finance should be able to review the information
High
93
Formal document required
Should have a formal document signed by both parties (e.g. contract) uploaded to the system
High
94
Multiple currencies
The system should support multiple currencies
High
95
Payment authorization
process
Should be able to set the payment authorization level and process (e.g. multiple levels of reviews
separated from the preparer and see when and
who prepared and approved the payment for the approved payment or disbursement
High
96
Payment request
Finance initiates disbursement only when an approved payment request is received
High
97
Payment lock feature
Have a payment lock feature for all disbursements pending approval
High
98
Historical data and ageing report generation
Should be able to generate the historical data (e.g. all payments made to a certain project for the last
30, 90, 180 days, etc.) as well as the ageing report
(e.g. all or a certain outstanding payment to a certain project due within next 30, 90, 180 days)
High
99
Batch payment
Should be able to make a batch payment
High
100
Partial payment
Should be able to spit the payment or make a partial payment and mark the transactions or milestones for which the payment is being made
High
101
Payment to be linked to
performance
There should be a link between M&E and Finance to hold the disbursement in the case when M&E Performance milestone is not achieved
High
102
Funding source
Should be able to see the funding source for each payment (e.g.grant, loan, etc.)
High
103
Payment tracking
All payments should be tracked, for example, by the budget allocated, amount approved, the amount paid,
unallocated, etc.
High
104
Download and print
Should be able to download and print at all stages of thepayment process in excel or PDFformat
High
105
Max grant value
Have a function to set the max grant value for each project and validation against over-disbursement. No disbursement should be allowed that would lead to the disbursed amount exceeding the commitment amount.
High
106
Link to ERP
Allow integration to ERP (Micorosft Dynamics 365 Business Central)
High
Compliance Specific Requirements
ID
Requirements
Vendor
Short Name
Description
Priority
Fully
Available
Partial
(%)
N/A
Gap (%)
Gap
Impact
Gap Addressing Mechanism
Comment/ Observation
107
Conflict of
Interest
All the reviewers should be asked to click Conflict of Interest Agreement for each document they are asked to review
High
108
Screening functionality
The system should have functionality or allow for integration to the screening system for AML, PEP and KYC
High
Technical requirements/specifications
ID
Requirements
Vendor
Short Name
Description
Priority
Fully
Available
Partial
(%)
N/A
Gap (%)
Gap
Impact
Gap Addressing Mechanism
Comment/ Observation
109
Dependency
The system needs to allow integration to Microsoft Dynamics 365 Business Central ERP which handles finance functions e.g. disbursements, repayments tracking
High
110
Document
Management
Version control, Track change, collaboration and all standard file formats need to be supported
High
111
Electronic signature or approval/certification of submitted documents. The system should allow integration to DocuSign electronic signing tool
High
112
All documents/letters to be automatically stored in one place to make sure that all documentation and correspondence related to the project to be stored
in a single place
High
113
Data
Management
The solution should support data migration, imports and exports of data to formats including Word, PDF, Excel, CSV, XML, etc. to the solution.
High
114
The system stores documents in the database as objects rather than links OR the system has an inbuilt document management tool that has a repository thus holding all documents inside the system
High
115
Automatically saves data throughout aweb session,or at a minimum prompts the user to save data regularly.
High
116
Search function
The solution should allowreviewers to have advanced search functions to filter by;
Name of investees
Location
Name of Portfolio Officer in charge
Institution type
Invested Amount
Status/progress
Project Amount
High
117
The solution should also allowthe users to search thecontents of the document repository
High
118
Training
Provides user training in person and remotely
High
119
Scalability
The solution scales based on varyingvolumes of workload.
High
120
Interface/Integration
The solution integrates with Microsoft Dynamics 365 Business Central. The solutionwould interface with the system to request payments and to track and validate financial data.
High
121
Watermark
All documents to have watermarks (user name, timestamp, approval)
High
122
Hardcopy to be printed with watermark (user name, timestamp)
High
123
User Activity
Audit
All user activity should be traceable by the system administrator (audit log of which file has been accessed by whom and when)
High
124
Data Encryption
Manage data encryption using strong passwords
High
125
Auto-save
A user’s work is saved automatically while completing a form so that they don’t lose their work on timeout
High
126
The Solution must have built-in support for all types of information ranging from structured, transactional data to unstructured content & Images
High
127
The solution must be able to support a wide range of Windows Operating systems
High
128
The solution should be able to support multiple database types, but Microsoft SQL must be one of them
High
129
The solution must be able to support a wide range of virtualization vendors to install the solution, but Microsoft Azure must be one of them
High
130
The system must allow administrative roles to retrieve, display and re-configure systems parameters and settings made at configuration time
High
131
The application must be able to monitor available storage space and notify administrative roles as per set limits when action is needed
High
132
Where the system supports multiple repositories, it should allow an administrative role to specify which repository automatically stores which type of document
High
133
Developer Mode
The system should allow for developer mode allowing for internal authorized controlled development for customization of reports, field captions etc
High
How to apply
Proposals must be submitted to [email protected] no later than 12th April 2024, 17:00 HRS East Africa Time
2.3 Prospective proposers should send an email to [email protected] requesting for process map and any other clarifications/questions before 20th March 2024, 17:00HRS East Africa Time
For more information, please visit our website as per the link below.
Deadline: 12 Apr 2024