Guidance on IFMS Implementation May 2007 ICGFM Miami Implementing an IFMS.

Guidance on IFMS Implementation

May 2007

ICGFM MiamiImplementing an IFMS

ICGFM – IFMS Implementation - 2 May 2007imcl

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?


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!


Major stages of an IFMS implementation

Build & test live systemBuild & test

model system

Detailconfiguration design

01/01/2008 31/12/2009

2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12

Train users

Migrate data & balances

Organisational changes at pilot sites

Set up hardware & networks

Go live at pilot sites

Phased rollout to other sites(several years)

Financial year

Contractor mobilises


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


System architecture• Central database or• Distributed databases

Central database

Central general ledger

Ministry A

Ministry B

Ministry C

Ministries & other agencies enter data locally but all processed on single database

Distributed databases

Ministry A ledger

Ministry B ledger

Ministry C ledger

Central consolidation & management

Ministries & other agencies have own ledgers and databases but managed centrally


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?


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)


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


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


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?


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


Go live• Critical stage when system “goes live” - beginning of

operational use of system• Go live likely to be phased, e.g.

1. By module

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


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


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

Ministry A

Dep’t 1 Dep’t 2

Project Agency

Ministry B

Dep’t 1 Dep’t 2

Project Agency

Horizontal slicing

Phase 1: all Ministries

Phase 2: Departments

Phase 3: Projects & agencies

Vertical slicing

Phase 1: whole of Ministry A

Phase 2: whole of Ministry A


Rollout Plan – for each group of sites

2. Organisational Change

3. Hardware networksAt each site & network

4. Training

5. Data migrationReconcile balances

6. Go live

7. SupportOngoing support and

help desk

1. PlanChangeover plan

Identify Sites

Repeat process for every group, e.g. Ministries, and for each

phase


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


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


The PRINCE II Project Components

Organisation

Planning

Controls

StagesRisk

management

Quality management

Configuration management

Change control

Directing a projectStart up

Initi-ating

Start/end

stages

Stage control

Managing products

Project closing


Project organisation

Project BoardSenior user

Executive Supplier

Project Manager

Team 1

Team Leader

Team members

Team 2

Team Leader

Team members

Project assurance

Project support


Balance between supplier & government roles

· Increased cost may become prohibitive

· If risk too high no firms may be willing to accept contract

· Gov’t minimises risk· Overcomes lack of

Gov’t capacity· More rapid

implementation

Increased role and risk borne

by Government

Increased role and risk borne by IFMS supplier


Matrix of rolesRole Gov’t Supplier Comment

1. Project management May be sub-contracted

2. Legal and regulatory framework

3. Software delivery & configuration

4. Hardware and networks May be separate contracts or combined with software - turnkey

5. Initial user training Should be training of trainers

6. Ongoing training Could be continued by supplier or outsourced

7. Preparing data for migration to IFMS

8. Organisational changes and change management

9. Ongoing system operation Could be operated by supplier or other contractor – out-sourcing

10. Ongoing support Could be outsourced


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


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


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

Guidance on IFMS Implementation May 2007 ICGFM Miami Implementing an IFMS.

Documents

Transcript of Guidance on IFMS Implementation May 2007 ICGFM Miami Implementing an IFMS.