Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Fixed grammatical errors, improved the formatting

...

Post deployment planning is a critical part of any software implementation.     We We advise MFI’s financial institutions to review the checklists on the pages below to prepare for production activity.   All All items should be documented, tested, and put into place as soon as possible.For examples of documents from specific deployments, see the deployment project pages.

Overall System Administration and Maintenance

...

  • Bandwidth considerations:   Monitor Monitor the bandwidth volume for the first month.   Is Is the bandwidth contract sufficient?
  • Data center and access:
    • Do you need to account for both local and remote access?
    • Are instructions for accessing remotely documented?
    • Who should have access to the data center, and do they have the necessary permissions/clearances?

...

See our System Administration Documentation for tips on monitoring and logging.

  • What Which areas will be monitored? 
  • How will they be monitored? 
  • What will this information be used for? 
  • What tools are necessary? 
  • Who will be responsible for these tasks?

...

What are the criteria for determining when to upgrade hardware, etc.   What is the process for upgrading server hardware and software?

Disaster recovery and contingency planning and testing. 

Problems occur in production, and you must be prepared for them.  Review this checklist make sure you have considered, DOCUMENTED, and TESTED the response to problems occur.

Testing the Process

Testing should include:

...

...

Documenting the Process

  • Compile list of emergency contact information, including vendors and contacts at the MFI (Who should be called in the event of an outage?)
  • Instruction for restoring a system should be detailed and clear.  Try to write them for a new user.
  • Make sure a procedure exists for updating existing disaster recovery documentation as new scripts are added/removed.  ( setting up a monthly email reminder to make these updates is often a good idea).
  • Good versus bad examples <we will document some examples of good versus bad documentation here in the future>

Problems and Responses

Types of problems that can occur, and how to prepare for them:

  • Natural disasters (e.g. flooding of main office or branch offices), fires, and political emergencies
    • OFF SITE DATA STORAGE: make sure data is stored at a location that is not the head office only for BOTH the database and the OS. <link>
    • Well-documented procedures for recovery steps <link>
    • Contact list <link to template>
  • Security breach of Mifos server or Act of sabotage by staff
    • What are the processes for immediately changing passwords.  Are they documented?
    • What needs to be evaluated for your organization(check accounts, database evaluation)?
  • Failure or loss of Mifos server, database and/or server disk storage
    • Make certain scripts are running for database backups.
    • Make certain scripts are running for OS backups
    • Make certain backup and recovery procedures are DOCUMENTED IN DETAIL
    • Restoring the OS
    • Restoring the database
    • Mifos configuration settings
    • Any custom scripts that may be running
    • Verifcation test plan (10-12 trials to make to ensure system is functioning properly and stable)
    • Make certain all scripts are stored in a documented location and include instructions for recreating the production setup
  •  Loss of Internet access/power at main office or branch office
    • What procedures need to be in place for working around the problem at a branch?  Document and test.
    • What procedures need to be in place at the Head Office in the event of extended power outage?
  • Loss of key staff members
    • Staff turnover is a fact of running an organization.  Make sure all procedures, instructions, and important details are documented and available to newer staff members who may be forced to troubleshoot or process a recovery. 

Documentation

All system administration and maintenance processes should be documented

Hiring/staffing to support this function

Everyone should understand who is responsible for each function in this area.  Ensure that each area is covered by the existing staff or new staff is hired/outsourced.

Troubleshooting and end-user support

  • Processes for end user support and issue resolution
  • Hiring/staffing to support this function

...

  • Training new employees on Mifos.  What will the process be?   How will this work?
  • Identify ongoing training needs for existing employees and ensure those needs are met.
  • Identify and implement measures for evaluating training success and gaps in training
  • Documenting how Mifos fits in with all operations within the MFI outside financial institution outside of the IT team

Mifos upgrades and bug fixes

...

  • Determining whether upgrades or bug fixes are required:
    • What criteria will your organization use for determining this to ensure that it is minimally disruptive to the organization, but still gaining benefit of upgrades/bug fixes when necessary?
  • Upgrade process /bug-fix process:
    • Who will be responsible for making sure that this is executed successfully at your organization? 
    • What will the process be? 
    • What type of test hardware is required to do acceptance testing on an upgrade/bug-fix? 
    • What kind of user acceptance testing and training will be done for upgrades?
  • Hiring/staffing to support this function
  • Documentation

Determining future needs in Mifos product

Bug fixes

New features and enhancements

...

  • Process for determining requirements for new reports <TO UPDATE>
  • Process for having new reports added into Mifos

Hiring/staffing to support this function