Technical Specifications for the Core System

SCORING GUIDE

Each question is either important, optional or desirable. Important questions are allocated 5 points, optional items are allocated 2 points while desirable items are allocated 1 point.

During the evaluation, each question will be scored on a scale of 0 to 3, where 3 means that the feature is fully supported while 0 means the feature is absent and there are no plans of customising the system to accommodate it. Scores of 1 or 2 will be granted for questions that are partially met to varying degree. The result will then be subjected to the weights allocated above depending on whether it is Important, Optional or Desirable.

The total scores per section will subsequently be subjected to the weight allocated to that particular section.

The overall score will be prorated to 100% to arrive at the percentage technical score.

THE SCORING TABLE

FULLY MET FAIRLY MET BARELY MET NOT MET 3 2 1 0 IMPORTANT 5 5 3.33 1.6 0 7 OPTIONAL 2 2 1.33 0.6 0 7 DESIRABLE 1 1 0.67 0.3 0 3 Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

General (12) Ease of Use The developed application should be easy to use and I simple in design and look. It should be friendly and pleasing to the eye. Menu driven The application should as much as possible be menu I driven, with drop down selection tables in order to avoid the entry of unverified data. Web-based Interface The application should be web-based and browser I driven. Open, industry The application should be developed using open I standards systems industry standards System Security & An audit trail for tracking all additions, changes and I Audit Trail deletions in terms of who, when and from where done should be available. This trail should be accessible in form of screen enquiries and reports to authorized personnel. Role based security. Access control should be granted I by broadly defined roles Access control should be limited by ability to Read, I Write, Delete at the field level. The system should not discard deleted records but I should retain them in the system in whichever form so long as the information can be accessed by duly authorised personnel whenever required. A user should be able to change his/her password at I any time. Any such change shall be recorded in the audit trail. The Administrator should be able to disable I permissions for any user for an indefinite or specified period of time. Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

The application should have an automatic screen D freeze enabled by the logged in user’s password when terminal is not used for an administrator defined period. The system should have best practice controls on D update of account. Business Continuity The bidder will be expected to propose a business I continuity plan to take care of unexpected events that might impact on service delivery. Backups The application will be expected to have elaborated D online and offline backup procedures, and ability to take full and incremental backups. Archiving of The application will be expected to have the ability to O dormant data archive data designated as dormant. This data will still be accessible to authorised users.

Documentation The bidder should provide online and/or hard copies I of documentation. The online documentation should be accessible for each screen and default to the specific screen the user will be attempting to access.

Centralized database The application will have a centralized database to be I accessed by all users, either at the headquarters or at the branches through the network. Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

Where the network is not operational for any reason, D the branches should be able to carry out essential tasks like cash receipting and statements production. The branch and headquarters should then be synchronized when the network is restored. Customer Customer Employer queries that should be enabled include the I Relationship Management scrutiny of contributions collected, both in the raw Management (3) form (the file submitted) and updated form (in the database). The application should be able to log any I queries/complaints made and track their resolution. Such queries and replies should be scanned/recorded into the Electronic Document & Records Management System (EDRMS). The system should allow members (both employers I and employees) to access and transact their accounts on-line through a variety of channels including but not restricted to web, mobile, ATM subject to appropriate security credentials. Integration (6) Open System The system should use open standards like web I services, SOA e.t.c. to integrate with a variety of different other systems. Integrated with The bidder will be expected to integrate his I Financial System application seamlessly with any open general ledger system. All payments made from the application or accepted by the application should be processed into the financial system seamlessly. Payments All payments processed/transacted in the system must I create procedures that are inline with internationally accepted accounting standards Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

Integrate with The bidder will be expected to interrogate the I Electronic ERDMS directly and pulling up documents relevant to Document & the query. A user should be able to have access to Records ERDMS documents from within the application Management System without having to log out of the Core System. (ERDMS) Integrate with The bidder will be expected to interrogate the AFIS O Automated directly and pulling up documents relevant to the Fingerprint query. A user should be able to have access to AFIS Identification from within the application without having to log out System (AFIS) of the Core System. Integrate with IPRS The Integrated Population Registration Services I (IPRS) database is a Government of Kenya (GoK) initiative to collect data from various registering agencies and hold it centrally. The system should have two way integration allowing NSSF to pick data and push data into the system using web services. Reporting (8) Standard Reports Regular Reports should be available on the menu I The application should integrate with industry I standard report generators to enable the generation of ad hoc reports on demand. All reports should be sent to screen, print, file or e- I mail addresses. User Defined The system should support modification of standard I Reporting reports (sorting, selection or re-arranging columns) and generation of ad-hoc reports to create user defined reports e.g. per branch office, gender, benefit type, age e.t.c The system should allow a user to store user defined I reports for future use Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

The system should be capable of producing regular I reports using date parameters. Reports should also be capable of being printed by I and re-started and from any selected page In the decentralized environment under which NSSF I currently operates, all processes should be able to be analyzed and reported by a variety of dimensions including geographic regions, branches or a combination of these parameters with consolidation for corporate-wide reports. The system should allow users to schedule reports for I automatic generation and routing to predetermined e- mail addresses at regular defined intervals. The application should be able to generate member O and employer static and transaction history. The application should be able to interface with a I standard report generator Member Statements Each member and employer is entitled to a statement I of their account on demand. The application should be able to produce this at any branch office at any time. The application should be capable of sending I statements to members through innovative means i.e. email, SMS etc. Such statements can be sent on request or periodically Registration (10) Employer Create a flexible hierarchy that has branch – zone – I sub-zone and allocate an Account managers (enforcement officers) Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

Register employers, capturing details such as contacts, I addresses, zone, branch, enforcement officer assigned to the zone etc. Ensure the same employer is not registered more than once. Allow for authorized amendments of certain employer I details including legal entity names etc Allow for deactivation and reactivation of employers D Maintain a history of changes of employer details I Allow for web based self service for employer O registration Allow employer details maintenance by duly I authorized personnel. Member Register members, capturing details such as contacts, I addresses, ID number, data imported from IPRS, fingerprints. Ensure the member is not registered more than once. Allow for authorized amendments of certain member I details including legal entity names etc Allow for deactivation and reactivation of member I details Maintain a history of changes of member details I Allow for web based self service for member I registration Allow for member details maintenance by duly I authorized personnel. Print membership On successful registration of a new member, the I card. system should be able to generate an NSSF number to the new member and print a membership card in the format prescribed. Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

Reprinting of cards For members who require cards i.e. Duplicate / I replacements / amendments of membership cards. Contributions and Collections The system should collect and issue receipts for I Returns (10) collections from employers and members. Methods of collections include Bank, cheque, MPESA e.t.c. Employers ordinarily pay for many employees. In order to facilitate convenient payments by I members, the application should be able to accept payments from agents acting on behalf of NSSF. The conditions for cash receipting are the same, and the application should be able to accept soft copy returns of such contributions, together with accompanying payments. Such agents will include money through mobile platforms. Together with the payments, the application should I receive contribution data comprising valid member numbers and the amount contributed for each member. The contribution data should update the member’s and employers accounts after payment is made. The system must be able to monitor payment of I contributions and identify defaulters. It must also generate warning letters and generate a demand letter after the assessment of arrears Contribution receipting should not proceed without I returns. However, if the receipting is allowed without contributions, appropriate reports should be generated for prompt, online reconciliations. Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

When posting returns into member accounts, ensure I that employer and member contributions are stored separated. Accept and process returns Hard (small employers), I soft returns (XL, CSV), self service. Create templates of recurring returns (especially for I small employers), Each contribution should be credited in a member’s I account. The credit should also include the details of the origin of the payment and/or employer. The system should have a web portal to validate and I accept contribution returns. NSSF anticipates that it will also be accepting O contribution returns through emails. These will be automatically extracted from the designated e-mail address and processed. Where returns are received before payment, these I should be held awaiting confirmation of cash receipt The system should have a web based workflow I system for reconciling between collections and returns Bounced Cheques The application should identify employers whose I cheques have been dishonoured. There should be automatic reversal of entries of dishonoured cheques. Reconciliations Reconcile returns with cash receipts I Suspense Allow for posting to member accounts any cash I management confirmed as collected but not posted to the member account Debtors The system should levy Penalties and allow for I management authorised granting of waivers Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

Cash flow The system should generate cash flow forecast reports I forecasting for up to 24 months ahead. Computation of The system should support multiple methods of I Interest computing interest on contributions and crediting the amounts to the member’s account. Compliance (10) Compliance Visits The application should trigger dates for visits and I capture inspections based on predefined parameters and information already held in the system. On return from an inspection, the inspector should be I able to capture directly onto the application the results of the inspection to enable downstream analysis and reporting. The system should be able to monitor compliance I status of employers and generate compliance certificate Government Imprest The system should manage delayed payments by D Government for civil servants. The normal situation is for Government payroll to provide returns, while the cash accompanying is received later when NSSF generates imprest claims (demand notes) Penalties Penalty computation and collection. NSSF imposes a I penalty on employers who make late payments. The application should be able to track late payments and assess the penalties due. Penalties are at present 5% of the amount due, charged each month the payment is late. The application should allow for the reversal of penalties. Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

Suspense Clearance The system should be able to automatically reconcile D members’ accounts immediately missing data is availed. The application should allow for the updating of member accounts by authorized users with contributions paid by the employers’ that are available for the period being updated. Benefit Processing Benefit Workflow The system should allow members to initiate the I (15) benefits application process and track the status online. The system should enable a member to track the I processing off his benefits claims using a variety of technologies including email and mobile phone. All payments must be processed by users with the I appropriate rights depending on the amounts involved. All payments must be processed and approved by I different users. The application should issue a notification letter either O by email, SMS or any other mode of communication when the payment is ready. Member Benefit claims shall be identified through fingerprints I Identification (AFIS) and IPRS documents captured into (EDRMS). During collection of the benefit, The system shall I capture all the details of the person collecting benefit payment. Benefit claims shall be identified through fingerprints (AFIS) and documents captured into (ERDMS). Benefits Structure The system should enable the flexible definition of a I variety of benefits based on parameterised business rules. Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

Age benefit On Age, Withdrawal, Invalidity, Survivor and I Emigration, provident benefits are payable. Each type of benefit has its own rules that should be kept in a table and adhered to when benefits are being processed. The application should be able to compute the total benefit payable. Survivor Benefits For Survivors claims, the benefits officer should be I able to enter the details of all beneficiaries, together with the agreed ratios. The system should maintain a record on the next of I kin and the allocation ratios and should allow the information to be changed from time to time with appropriate security safeguards. Payment Process The application should issue a notification letter either I by email, SMS or any other mode of communication when the payment is ready. The system should enable automated payment of I benefits direct to the member account or any other mechanisms of the member’s choice including MPESA e.t.c. The system should be able to keep a log of un- I collected/un-delivered payments and generate a reports on demand For cases where a full payment has been made, the I application should close that member’s account and transfer it together with the respective member details/documents to a closed member account database before being archived automatically. Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

Where a benefit is partly paid, the application should I allow for the acceptance of a claim for the unpaid balance The application should provide a provision for I payment of benefits for members whose accounts have been reactivated For planning purposes, a report of claims which are I likely to be lodged in the near future (e.g. one to two years) should be generated. The application should provide reminder to members to confirm their account details Reports Reports should be available showing claims at each D stage of the process. The amount of time a claim has taken at each point should also be shown. The application should be capable of analyzing D benefits by types of benefits, generate regular, adhoc and user defined reports Refunds In case of non-qualifying contributions NSSF may O refund both the member and employer. The system should determine amount payable and make refunds to both member and employer. Social grants The application should be capable of capturing grants O and accept new types of grants (Name of grant, amount, conditions etc) and determine which members are eligible at any time. Eligible members should be able to make their claim subject to positive identification Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

New Benefits The application should be capable of capturing new I types of benefits (Name of benefit, amount, conditions etc) and determine which members are eligible at any time. Pensions NSSF plans to introduce a comprehensive social I Management (5) insurance modelled pension scheme. Upon a member claiming pension the application should be able to determine monthly payments due based on the member’s contributions and interest accrued subject to parameterised business rules. The application should have a link to the AFIS/IPRS I system for identification. The system should have a provision to interface with a D smartcard system which shall be used for the purposes of pension payments. The application should be able to link with any third I party systems like banks and mobile phone companies to facilitate the efficient payment of pensions. The application should be able to interface with other I systems i.e. IPRS to facilitate verification of the existence of each pensioner at agreed intervals (say 6 months). Where a pensioner is not verified, payments should stop until such verification is made. Hardware Hardware The system should be capable of running on a variety I Architecture (3) questionnaire of server hardware architectures including support for virtualisation, storage area networks, blade servers, processor architecture (Intel & RISC). The application should be capable of running in a I virtualised server environment. State in order of preference the main virtualisation systems supported. Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

The tenderer is expected to provide his consultants I with working tools including computers The tenderer be expected to use own servers for the I initial configuration and testing of the system. Software Licensing Model NSSF will have a variety of user licensing I Configuration (5) requirements ranging from technical support users, power users, regular system users, occasional users and on-line self-service users. Outline the licensing model that will allow NSSF to cost-effectively deploy this solution for all these users and enable growth. NSSF anticipates to have 10 Administrators, 35 I Management/Supervisors, 135 key users and 500 Users will be trained.

What would be the impact on licensing costs should NSSF add another 100 users to the system? To manage software licensing and support costs I during the implementation period when the system is not in productive use, NSSF would like to assume ownership of the software licences only after the system has been finally installed on NSSF servers during the final phases of the deployment. The tenderer should provide temporary licences for I the installation, configuration and testing of the system. License support and maintenance fees, if any, should start accruing only after the system has gone LIVE. Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

Operating System The application should be capable of running on a I Compatibility variety of server operating systems especially the different flavours of UNIX and Linux. State in order of preference the main operating systems supported. Application The proposed solution is expected to be scalable and I Architecture modular to allow NSSF deploy individual modules as need arises. Indicate the application architecture showing major interfaces between the distinct modules and expected points of interface with other (typical) applications with the NSSF portfolio (e.g. Financials, BI, EDRMS…) Database The application should be database agnostic (free to I Compatibility work with any database). State in order of preference the top three databases recommended for this application. Data conversion (3) Conversion of The tenderer will convert the existing data into the I Existing Database proposed application. The tenderer MUST provide an into the proposed outline of the proposed methodology and human system resources to be deployed in the conversion process. Deployment Plan Project plan Tenderers will be expected to provide a detailed I (5) project plan with key milestones that will form the basis of the final plan to be negotiated with NSSF during contract negotiations. Deployment Deployment The tenderer will be required to outline a detailed I Methodology (5) Methodology deployment methodology that they will follow including indicating key deliverables and the quality evaluation criteria for each deliverable. Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

Training Training Plan Tenderers will be expected to provide a detailed I Methodology (10) training plan. This should include details of the training proposed, location of training, delivery mechanism, knowledge transfer process and any pre requisites (level of awareness etc). Change Change The tenderer will be required to provide a change Management Plan Management Plan management plan to ensure end-user buy-in and (5) speedy adoption of the system. Ongoing Support Support Plan The tenderer will be expected to continue supporting I (5) the system after handing over to NSSF. The level of support to be provided will be expected to diminish progressively as the tenderer transfers skills to NSSF staff.

Attach the support plan indicating the proposed support organisation structure indicating the resources and roles, both within and without NSSF that will be required to continue supporting the system.

Also indicate the support tools & escalation procedures for handling errors, bug fixes and enhancement requests.

Indicate clearly what will constitute an enhancement request and how they will be handled and costed. The Company (10) Business Respond to the attached Confidential Business I questionnaire Questionnaire Skill Set The plan should include the key staff to be employed, I their qualifications, experience and any other relevant details. Functional Area Requirement Additional clarifications Weight State how this will be met (allocated weight in bracket)

Reference Sites The tenderer shall provide three reference sites in the I format provided for in attached appendices. Software Details Questionnaire

Illustrate the application architecture highlighting ALL the modules that make up the solution, even those not currently proposed for NSSF.

……………………………………………………………………………………………………………………………………………… … … … … … … … … … … … … … … … … … … … … … .. ………………………………………………………………………………………………… ………………………………………………………………………………………………….. ………………………………………………………………………………………………… ……………………………………

Explain software architecture and implementation - are there any dependencies to code libraries, platform APIs, and so on?

……………………………………………………………………………………………………………………………………………… … … … … … … … … … … … … … … … … … … … … … .. ………………………………………………………………………………………………… ………………………………………………………………………………………………….. ………………………………………………………………………………………………… ……………………………………

Are they consistent, well designed current interfaces to the database APIs and stored procedures

……………………………………………………………………………………………………………………………………………… … … … … … … … … … … … … … … … … … … … … … .. ………………………………………………………………………………………………… ……………………

Data Architecture – Are external access to the data through well-understood standards supported; is it free from any restriction on use and documented? If not please explain.

……………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………… ………………………………

What ranges of operating systems are supported?

……………………………………………………………………………………………………………………………………………… ……………………………………………………………………

Does the vendor have a user group? Yes/No……………..

If so, where and how often do they meet?

……………………………………………………………………………………………………………………………………………… ……………………………………………………………………

Does the vendor financially support the user group? If not, who does? ……………………………………………………………………………………………………………………………………………… …………………………………………………………………… How often does your company come out with major releases and minor releases? Please indicate your de-support date policy for prior releases.

Major…………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………

Minor…………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………

What is the platform priority established for release of upgraded software releases and versions?

……………………………………………………………………………………………………………………………………………… … … … … … … … … … … … … … … … … … … … … … . ………………………………………………………………………………………………… ……………………

What would it take to move the system to another platform as on order of magnitude?

……………………………………………………………………………………………………………………………………………… … … … … … … … … … … … … … … … … … … … … … .. ………………………………………………………………………………………………… ……………………

What is the proportion of revenue that has been spent on research and development over the past five years? ......

Explain your warranty provisions including how you define a bug vs. enhancement

……………………………………………………………………………………………………………………………………………… … … … … … … … … … … … … … … … … … … … … … .. ………………………………………………………………………………………………… ……………………

Is a data warehousing feature incorporated into the system? Yes/No…………………………………

Are there any known security issues so far? ……………………………………………………………………………………………………………………………………………… … … … … … … … … … … … … … … … … … … … … … .. ………………………………………………………………………………………………… ………………………………………………………………………………………………… ……………………………

List databases supported in order of preference ……………………………………………………………………………………………………………………………………………… … … … … … … … … … … … … … … … … … … … … … .. ………………………………………………………………………………………………… ………………………………………………………………………………………………… ……………………………

Do all applications to be provided run on same database? If not, please indicate which applications run on which other database.

……………………………………………………………………………………………………………………………………………… … … … … … … … … … … … … … … … … … … … … … .. ………………………………………………………………………………………………… ………………………………………………………………………………………………… …………………………….

Can multiple facilities share the same database? If not, please describe why & how to bring together

……………………………………………………………………………………………………………………………………………… … … … … … … … … … … … … … … … … … … … … … .. ………………………………………………………………………………………………… ………………………………………………………………………………………………… ……………………………

Indicate licensing requirements for the database assuming that the same database will be shared with other business applications and that the Social Security System will contribute to about 50% of the database load.

……………………………………………………………………………………………………………………………………………… ……………………………………………………….. ………………………………………………………………………………………………… ………………………………………………………………………………………………… …………………………….

Are these systems running based on the internet technology accessible through browsers for any data access or modification and editing?

……………………………………………………………………………………………………………………………………………… … … … … … … … … … … … … … … … … … … … … … .. ………………………………………………………………………………………………… ……………………………………………………………………………………………….. ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………. Hardware Architecture Questionnaire

Can your system run on a variety of server hardware architectures including support for virtualisation, storage area networks and blade servers.

………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… ……………………………....

Can your system run on Intel and RISC server processor architectures?

………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… ……………………………....

What is the preferred server architecture for your proposed system? Please state Brand Name where appropriate Model(s), capacities and any Mandatory Specifications e.g. capacity, speed, features etc. Please illustrate.

What is the preferred Hardware (printers, personal computers, scanners, cheque readers etc) for your proposed system? Please state Brand Name where appropriate (if more than one, specify top three), Model(s), capacities and any Mandatory Specifications e.g. capacity, speed, features etc

……………………………………………………………………………………………………………………………………………… … … … … … … … … … … … … … … … … … … … … … .. ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… ……………………………………

Can multiple facilities run from one central location?

……………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………… ……………………………… What is the preferred server architecture required to run the solution and all the supporting applications including databases?

……………………………………………………………………………………………………………………………………………… … … … … … … … … … … … … … … … … … … … … … .. ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… ……………………………………

Bearing in mind that the solution will be running in a heterogeneous data centre environment, side by side with other systems e.g. ERP (being selected in parallel via a separate tender), illustrate at least two possible server architectures that would support your application as well as the other typical business solutions.

……………………………………………………………………………………………………………………………………………… … … … … … … … … … … … … … … … … … … … … … .. ………………………………………………………………………………………………… ………………………………………………………………………………………………… ………………………………………………………………………………………………… ……………………………………

Can server functions be combined onto a single machine?

……………………………………………………………………………………………………………………………………………… … … … … … … … … … … … … … … … … … … … … … .. ………………………………………………………………………………………………… ……………………

List Operating Systems preferred in order of preference

……………………………………………………………………………………………………………………………………………… ……………………………………………………………………