Automation of SACCOs - FSD Kenya

More documents

Recommendations

Info

46 • AUTOMATION OF SACCOS: ASSESSMENT OF POTENTIAL SOLUTIONS Customise the application This phase is almost exclusively owned by the vendor. The SACCO would normally only need to be involved to verify design and sign-off. The purpose of this phase is to develop the application from its default state to meet the SACCOs requirements. Application customisation involves: 1. Creating the application design from the requirements, application analysis, and other analysis work products. 2. Adapting the design to address quality requirements and technical constraints, designing for performance. 3. Designing packaged software configuration to meet the business process design and application requirements. Consider alternative solutions to minimise customisation and reduce impact of future upgrades. 4. Designing reports, interfaces, conversions, extensions, forms, and workflows to fill the packaged software functional gaps. Test the application The vendor is exclusively responsible for steps 1 – 4 outlined below. The SACCO is responsible for providing personnel to execute step 5, the user acceptance test. This is critical as the SACCO needs to provide people who are able to write test cases that represent the most extreme events to ‘stress test’ the system. They also need to be able to correctly interpret the results. The purpose of this phase is for the SACCO to confirm that the application fulfils the desired functional and performance requirements. At this stage the SACCO would benefit from referring to the requirements matrix to ensure that what has been required has been delivered and that the application supports the use case or high-level business or strategic purpose. 1. Preparing and executing the assembly test to make sure components work correctly when integrated into a complete application. 2. Preparing and executing the product test to make sure each application meets the product requirements and that all applications work together. 3. Preparing and executing the performance test to make sure the application meets the performance-related metrics, such as response time, availability, and capacity requirements. 4. Performing the mock conversion to test the conversion process. 5. Preparing and executing the user acceptance test to make sure the application meets stakeholder expectations Deploy the application The success of this phase is a dependent on mutual responsibility. The vendor clearly needs to be ultimately responsible for the technical aspects and the SACCO would be best positioned to assess the organisational and people aspect. However, the vendor should be able to build on experience and lessons learned from previous implementations. The purpose of this phase is to roll-out the application in a controlled and safe manner with minimal disruption to customer facing activities. The SACCO needs to be conscious of the skill the employees have obtained through the application training to prevent user error. The team would need to: 1. Plan for deployment i. Develop a schedule of deployment activities and checkpoints. ii. Understand requirements and assumptions regarding the application, business policies and procedures, the physical environment, the technical infrastructure, and the transition of the workforce. iii. Identify risks and critical success factors. 2. Assess deployment readiness 3. Migrate data to production environment 4. Operational readiness test 5. Communication effort 6. Launch training 7. Pilot roll-out 8. Full roll-out Service introduction In parallel with the entire project the organisation that eventually will support the SACCO in using the application is designed and its capability is defined. The application support organisation is a function of the application design. It draws on the functional requirements of the application and the skill level of the users. The support organisation will cover any gap between the application and the user. Assuming that the application is of sufficient quality and has a logical and intuitive interface the need for support should be limited. Until all users are fully trained and have become familiar with the application the need will be higher. Definition of the support organisation and the support requirements could be handled mainly by the SACCO but as previously it would be useful to draw on the vendor’s experience. 1. Define support requirements. 2. Design support organisation. Project management The SACCO should also provide resources for project management even though this responsibility could be shared with the vendor. The purpose is to monitor and control the entire project so that all stake holders have visibility of progress, risks and issues. This includes input such as staff and suppliers and the output by managing scope and requirements. Project management entails: 1. Managing the project using the project plan. 2. Managing project risks and issues to verify that the project meets the business objectives and stakeholder expectations.
3. Managing stakeholder participation and involvement so that they perform their tasks in a coordinated and timely manner (e.g. reviews and signoff). 4. Balancing scope, quality, effort, schedule, budget, and risks at all times. 5. Managing project scope and requirements. AUTOMATION OF SACCOS: ASSESSMENT OF POTENTIAL SOLUTIONS • 47
Page 1 and 2:
AutomAtion oF SACCoS ASSeSSment oF
Page 3 and 4: table of Contents Tables and Figure
Page 5 and 6: list of Abbreviations ASP Applicati
Page 7 and 8: exeCutive SummAry Financial Sector
Page 9 and 10: Chapter 1 introDuCtion 1.1 ConTEXT
Page 11 and 12: Chapter 2 projeCt methoDology 2.1 r
Page 13 and 14: The purpose of the visits was to sp
Page 15 and 16: The fact that the individual lists
Page 17 and 18: A manual of the solution needed to
Page 19 and 20: studies, which have been focused on
Page 21 and 22: for management information purposes
Page 23 and 24: yield on member share capital. The
Page 25 and 26: Thirdly the project team as observe
Page 27 and 28: coordinating their acquisition and
Page 29 and 30: Level 1 Level 2 Description AUTOMAT
Page 31 and 32: Level 1 Level 2 Description AUTOMAT
Page 33 and 34: Chapter 5 AutomAtion Solution ASSeS
Page 35 and 36: they would most probably have been
Page 37 and 38: Accounting and finance AUTOMATION O
Page 39 and 40: fees according to the size of their
Page 41 and 42: social factors. The first would be
Page 43 and 44: the system implementation there wil
Page 45 and 46: In order to evaluate the identified
Page 47 and 48: the functionality Orbit offers by d
Page 49 and 50: ecommendation: To conclude Amtech
Page 51 and 52: 5. Orbit (Neptune) Fulfilment of re
Page 53: Plan the project This phase is esse
Page 57 and 58: option is the acquisition of SACCO-
Page 59 and 60: I) Increase automation AUTOMATION O
Page 61 and 62: III) Governance AUTOMATION OF SACCO
Page 63 and 64: AUTOMATION OF SACCOS: ASSESSMENT OF
Page 71 and 72: Customer data management All detail
Page 73 and 74: Risk management The system provides
Page 77 and 78: 5. orBIT (nEPTunE) AUTOMATION OF SA
Page 81 and 82: 6. T24 MCB (TEMEnoS) AUTOMATION OF
Page 85 and 86: noteS AUTOMATION OF SACCOS: ASSESSM
Page 88: FSD Kenya Financial Sector Deepenin
show all

Automation of SACCOs - FSD Kenya

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?