Acquiring an integrated financial management system on behalf of a government is not a decision to be taken lightly. Within your country you are the senior official with responsibility for government accounting, perhaps with the title of accountant-general. Your country is one described as a low income or emerging economy – for example in Africa, Asia or the former Soviet Union. Your present accounting systems make use of computers, but with a mixture of systems which have been developed over the years. You have decided that you want to acquire a new Integrated Financial Management System (IFMS) to replace your existing treasury management systems and you want to know where to begin.
Before even starting the acquisition process the fundamental question needs to be asked – why acquire new financial management systems at all? The private sector drivers for change – cost saving and gaining a competitive advantage – work differently for governments. In many countries, public financial management has traditionally meant ensuring expenditure is kept within the budget and that such expenditure complies with the financial rules. Concepts of financial management as an information system to improve the efficiency and effectiveness of government, provide transparency, ensure accountability and control corruption are quite new. Traditional accounting systems are not geared to these new objectives, hence reforming public financial management is likely to be a requirement for various forms of external support. In such situations, implementation of an IFMS provides the essential infrastructure for the required improvements in public financial management.
However, you should also be aware of the downside of such an IFMS acquisition:
- acquiring an IFMS is not a quick fix. It is likely to take years to implement fully and cost millions of dollars
- during this period other reforms may be delayed waiting for the new system to be implemented
- a new IFMS is not in itself improved financial management. It is an information tool that can help achieve the desired reforms
- an IFMS implementation can fail or, more commonly, may not realise in full the expectations from the system
- to realise the benefits from the IFMS, surrounding systems, financial rules and institutional structures will have to change
- sustaining an IFMS is likely to place new demands on government for technical support staff and ongoing financing, e.g. licence fees.
Acquiring an IFMS is not a decision to be taken lightly. It requires careful consideration, and a decision to proceed should have high level government support and commitment. Furthermore, an IFMS is a major project, and as such requires a structured project management approach. The UK Government PRINCE (PRojects IN Controlled Environments), version 2, is non-proprietary and one of the most widely used methodologies. However, if after careful evaluation a decision to acquire an IFMS is taken, then what next?
There are six stages to the process:
- Stage 1 Plan for the IFMS
- Stage 2 Identify funding
- Stage 3 Define user requirements
- Stage 4 The bidding process
- Stage 5 The selection process
- Stage 6 Contract negotiation
- Stage 7 Implementation
Stage 1 Plan for the IFMS
Planning involves a high level design of the system, identification of surrounding changes required and actions to make the new system sustainable.
The first consideration is to decide precisely what the IFMS will cover – the business architecture and IFMS parameters. Four activities dominate government financial management – budget preparation, budget execution, accounting and reporting. Within these activities are many important government functions, often extending beyond financial management, e.g. payroll (typically a very large proportion of government expenditure), procurement, tax collection, cash and debt management. Many of the transactions will be the responsibility of individual government ministries and organisations, often using their own systems, e.g. tax collection.
In general, the greater the coverage of the IFMS, the greater the potential benefits, but also the greater the complexity, cost and risk of failure. Big integrated systems will inevitably require a large integrated software package, demand substantial technical skills and place heavy demands on hardware and networks. There is a judgement decision on the balance between the benefits of comprehensive integration against cost and risks, and this decision can only be made in the context of a specific country. The decision on the architecture and parameters is a management decision, but it must be informed by technical advice on the issues and options.
Planning also involves identifying the technical architecture – for example how are transactions initiated outside the accountant-general’s office to be incorporated into the IFMS? How many users will have on-line access to information? What security is required, and what procedures will be put in place to protect against disasters, e.g. a fire destroying the computer centre? There are a number of alternative solutions to these and other issues, but in total they will define the networks, servers and workstations required for the system – the technical architecture. Planning also involves considering the surrounding organisational structures, regulations, human and financial resources. The implementation of an IFMS is likely to impact on all of these if it is to be successful. Organisationally, some units may exist for functions that will be automated or integrated with other functions, and there will need to be specific organisational points responsible for managing the IFMS and supporting users. Financial rules, and sometimes legislation, often specify forms and procedures which may need to be changed (e.g. electronic authorisation rather than paper signatures). Human resources must be trained to operate and manage the new systems, and technical support must be available for the new IFMS. Budget provisions must be established for new costs, e.g. software licence fees, support contracts. Records management must be addressed – how long are electronic records to be kept, in what format, and how will access be controlled?
At the planning stage, other related reforms need to be identified and sequenced. Revisions to the chart of accounts are likely to feature among such reforms. The chart of accounts is the key to both integration and interface with external systems. For example, it will be very difficult to transfer payroll information to the accounting system if each uses a different classification for payroll expenditures, and this applies whether payroll systems are part of IFMS or separate.
Planning is fundamental to the success of the IFMS. Time and effort at this stage will yield benefits later. Furthermore, the planning stage can be used to build understanding and ownership of the changes by the users.
Stage 2 Identify funding
There is no simple answer to how much an IFMS costs. It depends on the size and complexity of the system, as defined in the business and technical architecture. The World Bank conducted a survey of 34 IFMS implementations and found the average cost was US$12.3m. However, there is a wide variation within this average. The minimum cost, even for a small system and related hardware just in the Ministry of Finance, is unlikely to be less than US$2m.
For many countries, this scale of expenditure will require some external funding. Given the current focus on improving public financial management, such funding is usually not difficult to identify, but does require a clear definition of the planned system. If the country does not provide such definition, the danger is that the funding agency may effectively take over the project and push their approach and solutions. In any event, if the acquisition is to be funded by concessional loans or grants, the procurement requirements of the funding agency will have to be observed, so it is easiest if these are built into the process from the start.
Stage 3 Define user requirements
You must identify and clearly state the user requirements. This will be in the form of a series of statements, for example:
- the system must allow for current and previous year transactions to be available for on-line enquiry and reporting
- previous year’s data-files to be backed-up, and subsequently be accessed off-line for enquiry and reporting.
Requirements should be categorised as mandatory or desirable. The vendor will be required to demonstrate that it can satisfy all mandatory requirements, and as many as possible of the desirable requirements. Key mandatory requirements should be carefully specified, such that if a bidder fails to meet a requirement, the bid may be rejected. This, of course, must be clearly documented for the vendor in the bid documents when they are prepared.
In order to make a proper evaluation, test scripts may be developed for key requirements, using, where appropriate, dummy transactions, which the vendor will be required to process to demonstrate that the functionality works as required.
The evaluation of the competing systems will take account of the vendor’s written response to the user requirements, as confirmed by reviewing at least a sample against the test scripts. To facilitate the process, test scripts are normally provided in advance to a vendor so that it can set up a demonstration.
Developing user requirements should involve existing users, but is a process that needs to be carefully managed. When asked, users will normally specify detailed requirements that replicate existing processes and usually make most mandatory! Also, detailed requirements create a number of problems:
- the opportunity to use the more efficient workflows and transaction processing of the package may be lost
- the further the requirements move from the way the package is designed to operate, the greater the cost, time and risk of implementation failures, and
- the vendor may have to develop procedures or modules that are not part of the package. These will be very expensive, and may not be supported through future upgrades.
Although there must be defined user requirements, these should be kept to high level requirements that are matters of principle rather than detailed procedures. Working with users to develop this approach can be a change management exercise and help prepare for the inevitable procedural changes when the IFMS is implemented.
The second article will cover the remaining four stages – bidding, selection, contract negotiation and implementation.
Michael Parry is chairman of International Management Consultants Limited (IMCL), responsible for supervising projects across four continents, as well as speaking regularly at international conferences. He has been financial management adviser to the Government of Nepal and participated in projects to improve financial management in countries in Europe, Asia, Africa and the Pacific.
Source: ACCA
0 komentar:
Posting Komentar