The State Bank of Pakistan (SBP) has directed banks and DFIs to evaluate a fine outline for the possible system change/conversion and have it properly documented.
The central bank has given some reference points to the banks and DFIs so that they could be ready for all types of system/software switchovers, as applicable to peculiar circumstances.
SBP has given the banks/DFIs option to decide on a particular mode of switchover keeping in view the maturity and complexity of their institution, the risks involved and time line considerations etc. Further, while selecting any particular strategy, the importance of planning, documentation, integration with business systems, testing & refining should not be overlooked. However, the strengths of phased switchover mode need to be given due regard.
I) After going through Business reengineering if decision is made for switchover (either through purchase of an off the shelf software/developing a software in house or outsource), a 'Team/Committee' should be formed. This team should be responsible for all the planning work for the new system and deciding on the requirements of bank/DFI in this regard (Complete business processes should be outlined and documented). This phase should be given due consideration because any important point if omitted at this stage will not be part of the end product.
II)The composition of the team/committee is critical. It may include business users of the application system, IT personnel and also among others senior level management in banks representing Operations, Finance and Planning, Treasury & Internal audit functions etc.
III) The Committee should decide on whether to go for Commercial-off-the-shelf Software (COTS) or customised product (make or buy analysis).
IV) In case of decision to find suitable product off the shelf, or outsource its development, in particular, following points may be of relevance:
a. Calling of expression of Interest, short listing according to a defined criterion, developing request for proposal (RFP), its issuance and then evaluation of the bids submitted in response to the RFP while keeping in view various prospects ie Financials, technology, Project Management experiences, history of similar projects etc.
b. The selection should be in line with the criteria decided upfront to ensure that the new system is suitable for needs of individual bank/DFI.
c. In other cases, going for developing a customised product should be considered.
(In the initial selection exercise when multiple solutions are evaluated and compared special care should be taken in comparing the 'total cost of ownership' of each solution. Quite often, the cost of the solution quoted is like the tip of an iceberg. The total cost of ownership should include cost of licence/third-party software usage, hardware required, network bandwidth requirements etc which can result in substantial increase in the total cost. The area of customisation required and its associated cost is often underestimated. Implementation cost of international packages can sometimes exceed the cost of the software itself. Warranty periods and annual maintenance charges should be considered for the next five years when calculating total cost of ownership, for comparison purposes).
V) The most important step during this process is communication and co-ordination. In this regard, it is vital for the 'Team/Committee' to arrange for need based as well as regular meetings for mutual understanding and timely decision making to ensure that potential problems or conflicts can be discovered and resolved early.
VI) There is need for gaining the knowledge of existing software and new software features through extended interaction between 'Team' and software writers and an explicit go-ahead to software writers is a must. It will help to develop a software meeting the bank's needs & facilitate smooth switchover.
VII) Staff should be informed early on to make them feel as if they are a part of the conversion process to make procedural changes more easily accepted.
VIII) Critical steps and key risks involved should be identified and documented. In addition, the gaps in the existing solutions and within the proposed solutions should also be a documented with suggestions to bridge the same.
IX) Taking feedback after writing the software through discussions/presentations/surveys etc from all the users so that software meets the expectations/requirements.
X) There should be a separate 'Team' responsible for implementation, reporting the status to senior management on regular basis.
XI) It should be part of the plan that the 'Team' would regularly report back to the senior management/BOD to keep all appraised.
XII) The new software (and associated hardware as needed) should be introduced into the whole system in phases to facilitate a smooth transition, along with requisite security checks and controls.
XIII) It is imperative to perform regular quality checks at various stages of implementation in light of the quality assurance plan.
XIV) Testing of new system in pilot branches (selected for the purpose based on the suitable criteria) for a standard period and correcting errors in reports produced by new software till system becomes error-free may be preferable. It is vital to improve upon the software in light of the feedback and problems faced in test implementation. However, depending on the technique for switchover adopted by bank/DFI and taking into account the associated risks, testing may be done in parallel mode or under test environment.
Further, the support required after the change may be longer in case of instant change over without parallel run, which along with other associated risks are to be weighed by bank. Therefore, decision to go for testing in simulated environment only, should be carefully made by the committee for well-defined considerations.
XV) Effective dealing with the problem of conversion to new package in interim stages by devising suitable software etc if needed to overcome the problems encountered in transitional periods, in addition to a sound overall Disaster recovery Plan is essential.
XVI) Developing the training materials and supporting documents. Vendor may provide instructions, but banks/DFIs should create checklists for various processes as well as ensure the documentation that takes into account the bank/DFI's objectives and procedures. These materials can also be used during staff training.
XVII) Banks/DFIs should familiarise the personnel of branches selected in phases, with new hardware and software. Key staff persons from each department of branch should be trained in a simulated environment.
XIII) Off-site training or classes hosted by the vendor give the necessary expertise, but banks should have their 'Team' present at all times to point out issues unique to the bank or answer any specific related questions. Also keep in mind that team did go through a learning period. This knowledge may prove to be sufficient for in-house training.
XIX) Obtaining the user acceptance, carrying out performance and security tests before actual switchover and the related bug fixing by the vendor.
XX) Going for parallel run for extended periods and correcting errors in the books produced by new software to ensure the credibility.
XXI) Formal switchover and there should be constant extensive supervision for a reasonable time to ensure effective and reliable functioning after switchover.
XXII) It is advisable for banks/DFIs that contract package with vendor includes the training to staff, on-site support, Scope enhancements/ up-dation at later stage, maintenance & Support services (including Service level agreements), suitable Warranty etc.
XXIII) Gaining excellence in IT Project Management through following standard IT Project Management methodologies.
Comments
Comments are closed.