ICGFM Miami Implementing an IFMS

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. Build and test • 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)

7. 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

8. 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

9. 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?

10. 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?

11. System architecture Central database Distributed databases Ministries & other agencies have own ledgers and databases but managed centrally Ministries & other agencies enter data locally but all processed on single database Central general ledger Central consolidation & management Ministry A ledger Ministry C ledger Ministry A Ministry C Ministry B ledger Ministry B • Central database or • Distributed databases

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 Vertical slicing Phase 1: whole of Ministry A Phase 2: whole of Ministry A Ministry A Ministry B Horizontal slicing Phase 1: all Ministries Dep’t 1 Dep’t 2 Dep’t 1 Dep’t 2 Phase 2: Departments Project Agency Project Agency Phase 3: Projects & agencies • 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