Guidance on IFMS Implementation

1
ICGFM MiamiImplementing an IFMS

• Guidance on IFMS Implementation
• May 2007

2
Setting the scene

• You are the Secretary, Department of Finance in
  Country X
• You have just signed a multi million dollar
  contract with a Supplier to implement the IFMS
  across the whole of Government
• You are happy!
• But now what do you do?

3
You start worrying!

• Why?
• Because most IFMS projects to some extent fail
• And
• Because you should already have made a series of
  preparations
• But mainly
• Because this is where the work really begins!

4
Major stages of an IFMS implementation
5
Configuration design

• Vendor has to configure their package to meet
  specification
• Configuration must be within system options
• Hence carried through to system upgrades
• Budget classification/chart of accounts
• Most critical and most difficult aspect of
  configuration
• This establishes the accounting and reporting
  structure
• A task for accountants not IT specialists
• Each package has own constraints and terminology
• Workflow
• Defined in most packages
• Changes to package workflow may cause major
  problems
• Balance against need to adhere to government
  procedures and practice
• Ensure Financial Rules/Regulations are either
  complied with or amended

6
System architecture

• Central database or
• Distributed databases

7
Hardware network requirements

• Development site
• For vendor to develop test systems
• Training site
• Production servers
• Depends on system architecture
• Likely to be multiple servers for different
  functions
• If distributed databases replication at each site
• Backup disaster recovery arrangements
• Balance of cost and risk
• Networks linking sites
• Wide area and metropolitan area networks
• Technology options
• E.g. fibre optic, wireless, satellite
• Networks at individual sites
• Whose responsibility?

8
Testing

• Testing
• Extensive testing of live data
• Likely to be a series of modules which will
  developed and tested separately, e.g.
• Budget, commitment, general ledger, revenue,
  reporting, payroll, etc
• Requires
• Test scripts
• Development of output formats
• Compliance with IPSAS
• Must be project structure for testing
• User teams to carry out tests
• Sign off required at series of stages
• Configuration design, pilot system tested, live
  system(s)

9
Organisational changes

• Implementation IFMS typically requires
  organisational change
• Often ignored or underestimated
• Typical changes
• Business rules enforced by system
• New workflows
• Electronic authorisation
• Must be consistent management structures
• IFMS changes across government requires whole of
  government ownership
• Other Ministries, Departments and Agencies must
  be involved as early as possible
• An exercise in change management

10
Training of users

• Can only start when system configured
• Training laboratory with copy of system
• Training for
• Users
• Managers
• Technical support
• Capacity for ongoing training
• Needs of new/transferred staff
• Training management structure
• Training of trainers
• Permanent training unit

11
Migration of data and balances

• Simpler under cash accounting
• Only bank and cash balances - must be reconciled
• If moving to modified or full accrual
• Loan balances, advances and prepayments -
  reconcile
• Other assets liabilities balances under full
  accrual
• Map budget to new coding structure
• Budget will have been prepared under old codes
• Consider creating a Statement of Affairs
• If no reliable brought forward balance
• Will previous years data be entered for
  comparison?

12
Merits of different architectures

• Central databases typical of IFMS
• Ensures common coding and standards
• Easier to manage
• Data automatically consolidated for analysis
• But
• Bigger more complex
• Expensive software hardware
• Critically depends on network linking sites
• Difficult to cater for sector specific
  requirements in a centralised system
• e.g. public works, health care, education each
  have unique information requirements

13
Go live

• Critical stage when system goes live -
  beginning of operational use of system
• Go live likely to be phased, e.g.
• By module
• By phasing
• Ideally go live at start of financial year
• Whole years transactions processed on one system
• Same coding structure for whole year
• No need to transfer balances part way through year

14
Need to plan for overlapping operation of IFMS
and legacy systems

• Inevitable situation
• IFMS at some sites
• Old (legacy) systems at other sites
• Legacy systems may be manual or computer based
• Legacy systems must be operated and maintained
  for several years
• As IFMS is rolled out
• To provide access to historic data
• Problems with maintaining legacy systems
• May use old technology
• May use different chart of accounts
• How to consolidate data for reporting

15
IFMS rollout

• IFMS will be progressively rolled out across
  government
• Horizontal or vertical slicing?

16
Rollout Plan for each group of sites
17
Other issues

• Security
• Who owns the information and controls security?
• Should be users, e.g. Ministry of Finance, not IT
  Department
• Access rights
• Levels of access and controls
• Physical security
• Backup and disaster recovery
• Records management
• Will records on legacy system remain accessible?
• Retention and control over records
• Electronic and paper

18
Project Management

• IFMS implementation is a major project
• Needs structured project management
• Preferably use a standard project management
  methodology
• E.g. PRINCE (Projects IN a Controlled
  Environment) developed for UK government
• IFMS implementation managed by government not
  supplier
• Major contract management exercise
• Project management may be sub-contracted

19
The PRINCE II Project Components
20
Project organisation
Project Board
Senior user
Executive
Supplier
Project assurance
Project Manager
Project support
Team 1 Team Leader Team members
Team 2 Team Leader Team members
21
Balance between supplier government roles
22
Matrix of roles
23
Ongoing sustainability of IFMS

• Many IFMS are proving
• Difficult to sustain and/or
• Only cover part of government
• Major problems
• Cost
• Ongoing operational costs
• Maintenance costs
• Software licenses
• Organisational
• Inadequate technical support structure
• Inadequate training resources
• Shortage/turnover of skilled staff
• System design
• System design inadequacies become increasingly
  apparent over time

24
Realising the benefits of an IFMS

• Better fiscal management
• Only if information is utilised
• More optimal resource allocation
• Only if budget system is linked to strategic
  objectives
• Improved management of resources (value for
  money)
• Only if managers utilise financial information
• Reduced fraud and corruption
• If system is designed and used to improve
  controls
• Improved transparency and accountability
• If system information is published in a useful
  format, e.g.
• IPSAS compliant financial statements on
  Government we site

25
Conclusions

• An IFMS can lead to real benefits
• Implementation is challenging
• Must be recognised as a major project impacting
  across government
• Requires substantial resources
• Do not underestimate time
• Sustainability issues must be addressed from the
  start
• IFMS benefits are not automatic
• Must be a strategy to realise the benefits