70140 REVIEW OF iBAS Integrated Budget and Accounting System Moving Toward 2nd Phase of iBAS (iBAS+) Ministry of Finance Government of Bangladesh March/April 2010 Strengthening Public Expenditure Management (SPEMP) Multi-Donor Trust Fund Program Contents Acknowledgement .................................................................................................................................. 1 Executive Summary................................................................................................................................. 1 1. Introduction .................................................................................................................................... 5 2. iBAS as a Future Base for FMIS Development................................................................................. 7 2.1 iBAS Database ........................................................................................................................... 7 2.2 iBAS Software ............................................................................................................................ 7 2.3 Platform Summary .................................................................................................................... 7 3. Functional Development ................................................................................................................. 8 3.1 Integration Proposal ................................................................................................................. 9 3.2 District Office Systems ............................................................................................................ 10 4. Technical Design Concerns ........................................................................................................... 12 4.1 Inefficient Code ....................................................................................................................... 12 4.2 Database Indexing ................................................................................................................... 12 4.3 Pay-Point Funds Checking ....................................................................................................... 13 4.4 System Integrity Reporting ..................................................................................................... 13 4.5 Audit Trail and Data Protection .............................................................................................. 13 4.6 Journal Files and Summary Tables .......................................................................................... 13 4.7 Chart of Accounts Limitations ................................................................................................. 14 4.8 Security ................................................................................................................................... 14 4.9 Other Issues ............................................................................................................................ 14 5. Summary ....................................................................................................................................... 15 6. Options for Moving Forward......................................................................................................... 16 7. Financial System Functionality ...................................................................................................... 16 8. Strategy for Achieving System Functionality ................................................................................. 18 8.1 Business Process Review ......................................................................................................... 18 8.2 Define User Requirements and Development Objectives ...................................................... 19 8.3 Network Capacity .................................................................................................................... 19 8.4 System Design Specifications .................................................................................................. 20 9. Options for Financial System Development.................................................................................. 20 9.1. Ongoing Development of Current iBAS ................................................................................. 20 9.2. Design New System iBAS 2 ..................................................................................................... 21 9.3. Procure COTS FMIS (Off-the-shelf Product) ........................................................................... 22 9.4 Options Timetables ................................................................................................................. 23 10. Recommendation...................................................................................................................... 23 Annex 1 ................................................................................................................................................. 25 Annex 2 ................................................................................................................................................. 26 Acknowledgement This report is prepared as part of Strengthening Public Expenditure Management (SPEMP) Multi- Donor Trust Fund Program. The SPEMP is funded by UKaid from DfID, DANIDA,and European Union and administered by the World Bank. The overarching objectives of the SPEMP are a) strengthen and modernize core institutions of budgeting within the government with particular emphasis on introducing a performance orientation in public financial management; and b) enhance demand for better budget outcomes by improving the effectiveness of formal institutions of financial accountability, in particular, Comptroller an Auditor General’s Office and the financial oversight committee of the Parliament. This report, an independent review of Integrated Budget and Accounting System (iBAS), is initiated upon the request of the Ministry of Finance and is intended to provide objective assessment of the current iBAS and make concrete, practical recommendations for improvement. The main author of the report is Bruce Pollock, independent consultant, and the report is task-managed by Junghun Cho and Suraiya Zannath of the World Bank. Rubaba Anwar has provided excellent administrative support for this task. The team expressed its gratitude for excellent support and cooperation from officials in the Ministry of Finance, Office of Comptroller and Auditor General and other agencies. 1 Executive Summary This review of iBAS (Integrated Budget and Accounting System) is an opportunity to assess the state of development and the capacity of iBAS in its current form to be a suitable platform for ongoing development of a budget and accounting system for the Government of Bangladesh. iBAS has helped the Government of Bangladesh (GoB) and the Ministry of Finance(MoF) to make considerable and absolutely necessary steps forward in both the use of computers and networks and also in developing familiarity and use of computer-based financial systems. iBAS has also greatly improved the speed of reporting and the increase in controls that improved reporting to management provides. These developments are to be lauded as real advancements for MoF and the Government. The major factors considered in reviewing the current version of iBAS as the platform for ongoing development identified a number of elements of a sound and standard form of financial system not present in iBAS and which would form a major hindrance to its ongoing development. These concerns mainly focus around: 1. Lack of Integration - iBAS is not integrated but is running on two distinct systems, one for Budget and one for Accounting, each hosted on different main servers in different physical locations in Dhaka. This poses significant challenges for iBAS to form the basis for ongoing development of financial system development. In addition to separate budget and accounting systems, the current iBAS also faces the following challenges: 2. Pay point funds checking unavailable. As the central version has no budget numbers in the accounting system, funds checking is undertaken manually. District Offices have no budget system installed and also must funds check manually. To achieve a suitable outcome, integration is required as is expanded functionality such as commitment accounting and full procurement processing and available at all locations using iBAS. 3. Security control is restricted and data integrity compromised by:  lack of internal integrity checking of data within the iBAS systems;  complete reliance on a third party reporting tool (Crystal Reports) for all data extraction;  lack of development environments so that changes to data and program code can be made directly into the production environment; and  lack of an audit trail, essential for data integrity checking, protection of authorized users and for error/fraud management. 4. Design limitations of iBAS resulting from: 1  inefficient database table indexing which reduces the speed and efficiency of extracting reports and also slows transaction recording for users;  inefficient code design that results in areas of iBAS re-loading entire screens when it is only necessary to refresh changed fields on a screen;  use of mid-scale development tools (VB.net, .Net framework etc) which may be significantly challenged for efficiency of operations as the functionality and user numbers increase;  use of SQL as the database which may also be challenged as capacity and demand on the database increases with functionality and user numbers; and  network limitations which have constrained the network effectiveness by restricting the transmission of transaction data between District Offices (DOs) and Dhaka. 5. Reporting and Functionality is limited due to:  the Chart of Accounts being restricted to a current limit of dimensions or ‘fields’ that constrain the capacity to report beyond those dimensions (such as Location, Program, Activity etc);  functionality restricted to cash-based transaction recording effectively at the point of bill submission for payment;  lack of core financial functionality such as procurement, commitment accounting, debtors, creditors, cash management, asset management, inventory management, audit trails etc;  budget restricted at the high or aggregate level of the Chart of Accounts whereas, to facilitate pay-point funds checking, budget allocation needs to be cascaded down to the Spending Unit level;  very limited support for cash forecasting and management; and  information on both debtors and creditors cannot be collected until almost the point of receipt and payment. The proposed interface between the two systems to provide a link between budget and accounting data is effectively a patch over an underlying design flaw that effectively eliminates the real option of using the current version of iBAS as a suitable platform for ongoing significant development to gradually transform iBAS into a comprehensive equivalent of Financial Management Information System (FMIS). Moving Forward MoF should undertake a comprehensive Business Process Review of all financial and budget transactions irrespective of whether the decision is to retain the current version or to undertake 2 either of the proposed two Options presented in this Report. Current manual practices have been computerized by iBAS and this has resulted in MoF bypassing the opportunity and the need to review all processes that might otherwise produce significant savings in effort, time, costs and information flows to managers and decision makers. The current combination of software and database are largely aimed at mid-sized application development and may not be capable of the amount of development and the combination of user and data volumes that might be envisaged to develop over the next few (5 or so) years and some consideration should be given to transporting the FMIS development environment to a high-end capacity environment before stresses appear in operations. Two distinct alternatives to attempting to further develop iBAS in its current base are available for GoB to consider: Option 1: Rebuild iBAS from the ground up using a design that is architecturally sound and based on designs that largely mirror modern ‘Best-of-Breed’ financial systems that would be compatible with the current and expected ICT and communications environment in Bangladesh. The tools used for the rebuild should be robust and capable of supporting the design and build and ongoing development and it is suggested using Java and Oracle as the base. Option 2: Procure a suitable Commercial-Off-The-Shelf (COTS) solution that is already capable of operating in environments at least somewhat similar to Bangladesh. There is frequently expressed concern about cost but when comparisons are made over product life cycles, in-house developments are often as costly as COTS in real terms. Option 1 would require MoF to undertake a comprehensive analysis and identification of all current and likely future functional requirements for financial systems once the business processes had been reviewed and agreed. Based on the process review and functional requirements, a comprehensive design process would set parameters for the building and rollout of the new iBAS. Built, test, document, train and data conversion prior to implementation across all user locations, including SOEs. Timing for the entire process for Option 1 would require a minimum of 4 years with minimal enhancements (such as pay-point checking) or considerably longer should additional functionality be required. Cost, including all consulting, hardware, software, contractors, MoF staff time, license fees for all operational software (database etc) can be expected to amount to between $m 6 to 10, excluding significant expanded functionality over current iBAS. Option 2 would require essentially the same time period to conduct business process reviews and functional requirements definition and documentation. This would be followed by procurement, implementation and rollout with a total likely timeframe of 5 years following preliminary activities. Total cost might be between $m 10 and 15 but providing comprehensive accounting and budgeting functionality and reporting. 3 Whole of life costs traditionally are similar between bespoke and COTS but with COTS expected to be considerably less risky over whole of life. It is recommended that MoF should urgently consider and determine the preferred course of action and place the current version of iBAS on a care and maintenance basis, reallocating resources to whichever of the two options is chosen. 4 1. Introduction iBAS is the name for integrated Budget and Accounting System. It was developed from the earlier Transaction Accounting System (TAS) which needed replacing because it was based on old technology and required enhancement. TAS was badly afflicted with software problems and was proving both functionally unsuitable and technically unsustainable. iBAS was initially seen as a modern replacement/updating of TAS and was developed initially as a simple transaction recording system. During development it was decided to add a Budget module but as the transaction system was already under way and budget had traditionally been seen as a quite separate process from accounting, a completely separate Budget system was developed. There were no links at all with the accounting system, notwithstanding that the new system was to be called ‘integrated’. Each system was developed as completely stand-alone with separate servers, one for each functional system and hosted in different locations, one in the Comptroller General of Accounts (CGA) offices and the other in the Budget Wing of the Finance Division. Together, and with the earlier TAS, these systems have created the necessary computer-based environment across government finance areas where, prior to their introduction, computer use was largely unknown in most operational areas of finance and networking did not exist. Through the introduction of these systems, particularly iBAS, computer usage and reliance on computers has become established and provided the environment into which it will be far easier to introduce more and more sophisticated computer-based financial management systems and facilities across almost all government finance areas. Where iBAS is viewed as a step in the development of computer- based systems, the ongoing development of iBAS forms a continuous path to full computer-based accounting. A further development provided by iBAS has been the rapid production of reports, improved report quality and monitoring and control features available to management that has added considerably to both the capacity to manage and the scope of management tools at their disposal. The combination of these considerable developments has contributed to an appreciation of iBAS by many and a growing reliance on systems. At the same time, there seems acute awareness and complaints from staff to the current shortcomings of the system and the desire to see further system development. The accounting (transaction) system basically records transactions at the point of payment request. There is no pre-payment process recorded and therefore no budget validation, commitment or obligation recording so almost no assistance to cash management and cash forecasting. iBAS, representing itself as Integrated Budget and Accounting System does not achieve any of these functions in the system’s current status. It is not integrated, it does not support budget fully and only covers one small aspect of accounting. Integrated refers to systems where data, entered once, is available to fulfil all functions of that data without the need to enter the same data again for other functions in the one, fully integrated, 5 system. iBAS consists of two separate and stand-alone application systems hosted on their own servers and databases. Budget refers to a system that allows for budget entry according to budget classifications and the chart of accounts, allocate the budget, manage and amend the budget and report against that budget and compare it with other data (actual) that relate to the budget. Budgeting should be available at any point Users require, namely at whatever level of the Chart of Accounts a User either wants funds control or budget reporting. The current status has only one version of the Budget system hosted in the Budget Wing of the Finance Division and budget data is held only at the highest level of the Chart of Accounts. No budget data or systems are available for District Offices and those central agencies in Dhaka (line Ministries etc) do not have any breakdown of budget data below the Ministry level, that is, no budget allocated in iBAS down through Departments, activities etc as they may wish. Funds control through iBAS against approved budget must be managed manually at all but the highest level of the organizational structure. Accounting refers to a system that records transactions against the chart of accounts (CoA), validates against that CoA and the budget held against that chart, manages all budget related actual expenditure or proposed expenditure and reports accordingly. Accounting functionality generally includes all procurement activities from requisition through to payment for goods, classification of goods into inventory/assets, creditor management with vendor details, commitment accounting and funds checking, revenue and debtor management, cash management, banking, bank reconciliations, bank account management, reporting, chart of accounts management. From the perspective of iBAS being an accounting system, it currently only records transactions when the Bills are presented for payment and then processes payment as required. While the system can transfer data to banks for payment, few agencies have data links to the banks and therefore manually prepare checks and print check lists for delivery to Banks so that the banks can assess presented checks against the list to ascertain validity. While these problems are not all the fault of iBAS design or build, it reflects an unusual setting of priorities when the capacity to introduce Electronic Fund Transfer (EFT) seems to be placed above resolving the fundamental challenges MoF faces and that could be directly supported by a truly integrated and comprehensive FMIS. iBAS should undertake all these described functions but in its current state, provides very few of them. 6 2. iBAS as a Future Base for FMIS Development There are a number of issues relating to the potential future of iBAS. The separation of the functionality of the system into Budget as a stand-alone, and Accounting with few of the normal accounting functions, makes the task of using it as a base to develop a product that starts to resemble a true FMIS more than usually difficult. The challenge is to find a suitable development starting point. As it would appear there are effectively two separate databases in the system, one for budget and one for accounting, merging the two becomes virtually impossible. An issue that surrounds the debate over iBAS is a lack of clarity of just what iBAS is. iBAS has aspects that need to be isolated into their constituent parts. 2.1 iBAS Database The database is Microsoft’s SQL and is a major worldwide commercial strength database for up to large midrange applications. It is the major competitive product against Oracle although Oracle has greater capacity for large scale data management. SQL should be capable of supporting the iBAS operations within its current scope of usage and users but could come under stress if iBAS were to be developed into a full range financial system. 2.2 iBAS Software Software of iBAS has been developed within the Microsoft .Net Framework using Visual Basic as the coding product and ASP.Net for screen build. This is a common and reasonably popular development tool for web-based software development. While it was released initially about 10 years ago, Microsoft has upgraded the product on a number of occasions (now at version 4) since its first ‘commercial strength’ release in about 2003. However, this environment may also find capacity limits should iBAS develop into a full functioned FMIS, particularly if the stated objectives of MoF see the functional inclusion of non-core systems such as Payroll, Provident Fund and Pension systems incorporated. 2.3 Platform Summary The combination of SQL, VB.Net and .Net provide a sound, commercially viable development environment so that, at this current level of development, it is possible to assert that the tools used to develop and operate a functional software product are viable and frequently used around the world for corporate or enterprise applications in web-based environments. Security capability of SQL, VB and .Net is sound and not subject to successful third party attacks as have many other Microsoft products. The current combination of software and database are, however, largely aimed at mid-sized application development and may not be capable of the amount of development and the combination of user and data sizes that might be envisaged to develop over the next few (5 or so) years and some consideration should be given to transporting the FMIS 7 development environment to a high-end capacity environment before stresses appear in operations. 3. Functional Development Using a combination of SQL and VB, the application product which constitutes iBAS was developed as the financial system for Bangladesh. The tools used were and are satisfactory and the .Net Framework has been added to a number of COTS FMIS products as a ‘front end’ allowing those international software systems to operate across the internet (Java and other products have been similarly used). The environment is flexible and has the reputation of being a fast development tool, the combination of which provides a suitable environment for application development. The issue is not with the tools per se, except for the observations on their limitations described below. The issue is with the suitability and capacity of those tools being used to develop a large financial system for the entire country and the design and functionality of that software (iBAS). The iBAS product to some extent reflects the history of financial activity in Bangladesh. Over many years, Budget and Expenditure were seen as separate activities and the design of iBAS, while focussing on web enablement, maintained this separation with databases developed to support budget and transactions as separate functions. Transaction (accounting) was built first and the decision to add budget was taken after development commenced and was therefore developed separately from transactions. This divided development remains within the current design of iBAS and while the current developers maintain they have created the capability to merge data (but not databases) from the two databases into a functioning integrated system, this function has not yet been implemented (because of the need for a ‘policy’ decision. It is understood that no formal policy should stand in the way of integration and the GoB has agreed in the past to clear the way for this level of integration and yet, as a core requirement of an ‘integrated’ financial system, this has not been implemented). The central Government iBAS in Dhaka that is available to all line agencies (other than the State Owned Enterprises (SOEs) that are also Self Accounting Units) has a configuration that can be represented as in Figure 1. While the tools and the environment used to develop the two systems that make up iBAS are not an issue in the current context of iBAS, the design and architecture of the software and the associated communications environment are flawed. The Budget database is hosted on servers located in the Budget Wing of the Finance Division and the transaction/accounting database is hosted on servers located at the offices of the Comptroller-General of Accounts, while at District Offices, only the Accounting system is available. This physical separation places both components of the iBAS system under different managements and potentially under different sets of policies controlling access, security, maintenance, standards, reporting and even, potentially, system modifications. The overall network of iBAS is shown in Fig 2: 8 Fig 2: Current iBAS Networked Configuration in Bangladesh As a base from which to continue to develop a financial system, iBAS has clear design problems. The database is usually built with the tables required for budget and accounting being included in a single database architecture. Data stored in tables is available to all areas of the functional system built over the database. 3.1 Integration Proposal Software development will be used to provide the appearance of integration at the front end (user interface) while behind the scenes, data is extracted from each database, manipulated as required by the software and then stored back into its separate databases and tables. The proposed ‘fix’ to the problems of non-integration can be reflected in Figure 3: 9 Fig 3: Proposed Solution For Integration The concerns with this approach mainly focuses on the efficiency of this design and the impact possible on performance and database designs and sizes as iBAS is functionally developed. Should iBAS be functionally enhanced to cover procurement, accounts payable, inventory, assets, payroll etc and then further upgraded to accrual accounting, the demands on the link between the two databases will increase dramatically as more ‘funds available’ validation is required at every step of the transaction process, not just the once-per-transaction required under current transaction recording. Funds checking occur at virtually every step of the process and this will magnify the demands on the makeshift solution by many multiples. In addition, because the two databases need to be updated each time a transaction passes the funds available check, each database will effectively contain every transaction and every step of each transaction even though the actual data stored will vary between systems. This increases the data sizes and can therefore reach a critical size factor in terms of both database management and data storage. This could reach a stress point for SQL server, which lacks the large data storage and management capacity of some other high-end database system. 3.2 District Office Systems District Office (DO) systems are required because of a problem with the intended data replication between local DO databases and the central system. The original design of the network architecture 10 required that all data be stored in a single central server (single for transactions only, budget is only stored on the central budget server). The design had all users across Bangladesh accessing and recording on the single transaction environment. Network capacity across Bangladesh would not permit such an environment so each of the 60 or so DOs have a Local Area Network (LAN) and a server containing the transaction software and database for iBAS. There is no Budget server or system at District level. Were the budget system available to the accounting system, it does not hold data at a level of detail that would support budget validation at the level of transaction recording and budget analysis to support management decisions. The central transaction system in CGA is set up to ‘poll’ each DO at regular (12 minute) intervals when connections are available and sweep aggregated data from the DO servers into the central server, providing the CGA with updated aggregate data but not at the transaction level detail that was originally required through data replication. The CGA server setup allows authorized users to connect virtually seamlessly with each DO Server for detailed transaction information as and when required. The failure of the data replication process would appear largely due to network capacity (bandwidth) but unless and until some linkage can be tested, it cannot be asserted whether the difficulty is solely bandwidth or whether replication setup, application software or server capacity may also be contributors to the problems. Should it be required (as seems likely), that the budget server will also have to be implemented at each DO to allow for funds availability checking for each transaction processed at DO level, the problem will simply compound. This inability of replication highlights a serious problem with the original network architecture design. All Dhaka-based agencies of Government, except for the self-accounting entities (SOEs) connect online to the two central servers and the transaction data is stored on the central servers. The SOEs, which include large commercial focused entities such as Roads and Transport, Railways etc and others such as the security focused entities, including Defence, do not connect to iBAS and therefore leave a considerable gap in the context of whole-of-Government data and reporting. Estimates are that storage demands of the Transaction server in CGA are about 25 GB and another 100 GB spread across the different DO transaction servers. The Budget server is understood to store about 20gb of data. Given the very basic functional structure of transaction recording and the lack of detail in the budget data, compounded by the apparent need for budget servers to be added to each DO, data sizes can rapidly multiply over the period of any development. Budget servers at each DO seem to be required to allow the introduction of pay-point funds checking and budget validation, which is a stated aim of iBAS development. Based on network reliability and power shedding (blackouts) which are a frequent reality of life in Bangladesh, DO Budget servers in DOs seem a requirement. It would be possible to incorporate budget data in the transaction servers to avoid duplicating servers but the issue then arises as to who would be responsible for the accuracy and reliability of the budget data should it not be the responsibility of the Budget Wing of the Finance Division and other ministries in Dhaka. Current manually maintained local budget data is under the control of the local CG office in the districts but management of budget should be under the local budget department in an electronic data environment. It is not presently clear where the responsibility lies but the Budget Wing of the 11 Finance Division of the MoF seems concerned only with the electronic maintenance and development of aggregated central budget data. 4. Technical Design Concerns There are two additional basic issues with the technical design of iBAS other than those serious problems mentioned above, plus a number of functional deficiencies. 4.1 Inefficient Code The first relates to inefficient code used in at least some parts of the system. One serious example is in the transaction system and it relates to screen design and refresh. In the context of relatively poor and unreliable network access in Bangladesh, some transaction screens are rebuilt each and every time data is entered or selected from pull-down menus on the screen. This complete screen refresh has two major drawbacks. The first is the time it takes to refresh a screen after every field data entry. The other is that the load on the network between the PC and the server is multiplied dramatically during data entry and this is completely unnecessary. It is only necessary to refresh the affected field and leave the screen otherwise intact. Complete screen refresh absorbs scarce bandwidth because it requires the entire screen to be re-transmitted during data entry. There are a number of ‘header data’ fields required to be entered before transaction details can be added. Each of these header data fields leads to a screen refresh, then the transaction data is added and screen refresh occurs every time each of the 5 fields of transaction data is entered. Multiply this by the number of transaction lines for multiple expenditure allocations required for some Bills presented for payment and the number of screen refreshes can quickly add to 50 or more. 4.2 Database Indexing The other problem is with inefficient indexing of database tables. Indexing controls the software’s access to the correct database tables and table fields during transaction processing and report extraction. Where poor indexing exists, the software and database are required to do much more detailed searching for the correct location of data than would otherwise be necessary, slowing response times for users. Indexing establishes the link between the software program and the appropriate database table and field locations for the efficient transfer of date to (transaction recording) and from (reporting) the database and user. An example may be where indexing is directed to a table where the individual records exist but the required data is a total of that data and stored in a related table. The data process must therefore search the incorrect table, sum all the base data to present the correct total while the correct total already is stored in the related table but is unused. The database can therefore be required to sum a very large number of transactions each time a report is run, while the correct total is available almost instantaneously. 12 4.3 Pay-Point Funds Checking In the Budget system, budget is held only at the high level of budget, with no breakdown to Spending Units or other elements of the Chart of Accounts. Without a detailed breakdown into spending unit levels, the objective of integrated budget and accounting within the system cannot be achieved. This means that even with the unimplemented interface ‘fix’ between the two systems, pay-point budget validation would not seem possible even in Dhaka agencies let alone DOs where there is no current budget system, even at the high level of budget. 4.4 System Integrity Reporting All reporting on iBAS relies on Crystal Reports, a third party report writing tool. Crystal is a highly regarded and internationally used tool and there are no problems with it being used with iBAS. The problem is with the apparent complete lack of hard coded reports being generated from within the iBAS code. All system integrity reporting and control is, or should be, hard coded into the software to ensure that it ‘can’t’ make mistakes and also that it is free of human error. Relying on an external report writer to extract integrity checking reports (such as a basic trial balance) leaves the issue of integrity checking to the correct report development in Crystal Reports and these reports can be changed, structural updates to control records (Chart of Accounts) may not be reflected in standard system reports and integrity can be compromised. Whenever any modification is made to the system, to check that the data retains its integrity (i.e. is both complete and accurate), the software itself should be programmed to ensure the data is correctly installed and maintained. Relying on an external report for this integrity checking is high risk. 4.5 Audit Trail and Data Protection There appears to be no conventional concept of an audit trail in either systems except for default trails maintained by the database and therefore subject to manipulation or deletion. The audit trail in conventional financial systems records every detail of an added or changed record both before and after the change is stored in the database. Tools such as standard and hard coded reports within the software would then allow an authorized user to access those reports where a problem had been detected in the transaction data. Missing or changed transaction records are frequently caused by an unauthorized person accessing directly to the database and overtyping records to change or delete data that should not be changed. As it is possible within iBAS for an authorized person to directly access the database, a fully protected audit file is essential for the protection of both the government resources and the authorized users. 4.6 Journal Files and Summary Tables The conventional concept of a journal file and summary tables do not specifically exist within iBAS although it could be claimed that the table data structures forms such a function. This can be related to the indexing problem. 13 The lack of a ‘conventional’ journal file means functions like conventional debits and credits are not maintained but are implicit within the use of pluses and minuses used either by default or by User data entry. A system claiming to be an ‘accounting’ system should maintain explicit conventions of accounting. 4.7 Chart of Accounts Limitations The Chart of Accounts is limited in the number of fields that it supports, even in the transaction system and this limits the capacity of iBAS in its current form to support ongoing reforms and enhancements in the areas of financial data capture, reporting and control. Should GoB introduce program budgeting, location identification, multiple charts of accounts (as would be required if, for example, State Owned Enterprises that are currently self-accounting entities were bought into the Government accounting and reporting system. A considerable but generally misunderstood challenge to CoA structures with the introduction of program budgeting is where cross-cutting programs (such as Education covering public health education provided by Health Services) span multiple line agencies, DOs etc. To accommodate any such change in iBAS would require the significant restructuring from database through all function processing and reporting within the iBAS accounting system. 4.8 Security Security and system protection both need a detailed review in their own right. Currently direct access to production system database tables is allowed for authorized users but this should be seen as a security breach of the highest order, without some additional supporting security such as an audit trail maintained in an encrypted file but readable as a standard system report. Because of the separate installations that exist in DOs and separate from the central accounting system, security has been set up in such a way that each time a user moves location, they must be identified in that new role with a completely new UserID to log on to iBAS. This has clearly frustrated many users from comments made. It is also a major flaw in security of data as it becomes difficult to almost impossible to trace an individual user as they move from one assignment to another. The problem is the failure of an audit trail of individual users that would allow an audit to track and trace a user who may, for example, be significantly error prone in data entry or worse, be suspected of fraud or corruption. Some of the most insidious frauds perpetrated using financial software has been hidden from view by a user being able to change UserID to hide their trail. With iBAS, the system actually imposes this process, creating a clear breach of standard security structures. 4.9 Other Issues Other frequently reported problems were not specific to iBAS itself but to its environment, namely the low level of training and training documentation, user help and the frequent load shedding. UPSs are generally available but are not of the ‘smart’ variety that is capable of shutting down the computer prior to the UPS battery expiring. If the User fails to shut down their computer or the 14 computer is on but unattended during a power failure, the UPS will only delay the time of shutdown and possible damaging power surge that can damage the computer and/or server. 5. Summary In summary, the basic design of iBAS contains significant flaws in its architectural and software design. Many of the existing limitations and constraints in the systems can be addressed but there are many significant flaws that are intrinsic to a lack of adequate design and experience of people who have been involved in the development of the systems. These technical people undoubtedly have real and effective skills in software development and the use of the development tools. What appears to be lacking is the experience of financial system design. It is concluded that fundamental problem of two distinct systems (separate budget and accounting databases) and other deeply set design issue poses significant challenges for current state of iBAS serving as an information technology platform for more modernized public financial management in Bangladesh, thus, requires urgent and well-targeted intervention to address shortcomings identified in the report. Other concerns observed that are not directly related to iBAS but more to the environment in which iBAS operates. It was noticed that there seems only to be a production environment whereas prudence and security suggests that there should be a development environment, a testing/training environment and a production environment. Changes to any part of the system should firstly be developed in the development environment, tested in the Test environment before being transported into production and documentation and change control are essential to maintain full system documentation, audit-ability and audit trails of changes. Risks are significant when access can be made directly to the production environment as there is no audit trail and there would be no way of knowing if illegal or unintentional changes were made in the production system or its data. Even where very limited numbers of staff have access, the risk then is if staff (or contractor) is unavailable for any reason, there may be no access available to anyone else to cover during unexpected absences. 15 6. Options for Moving Forward Bangladesh is in clear need of the capacity to continually access expanding functional capacity in the support to ongoing reform that a financial system can provide. This raises two directly related questions the Government must consider and determine upon:  What future capability does the GoB need from a financial system?  What is the best strategy to achieve this required capacity? These questions cannot be decided independently of each other. The decision on the first question directly determines the options available to answer the second. 7. Financial System Functionality While the technical environment and specific functional requirements for financial systems can vary slightly from country to country, there is a strong commonality that all financial software systems, bespoke or COTS, always provide. The differences are not in what the functionality is but how it is applied and the pace of adoption of functionality into the finance areas of a government. Standard software functionality is the clear direction that expressed views about iBAS development have identified either directly or implied in indirect comments of need and/or frustration. These major areas of functionality include: 1. Integrated budget and accounting (that is, a ‘real’ iBAS) 2. Pay point funds checking 3. Security 4. Data integrity 5. Reporting 6. Commitment accounting (requires Procurement) 7. Capacity to move to accrual accounting (requires Accounts Payable and Receivable, Asset Management, Inventory Management, full interfaces with Banks, Debt Management, Taxation, Customs, Payroll etc) 8. Program budgeting 9. Budget development 10. Fully flexible Chart of Accounts 16 11. Incorporation of SOE entities 12. Capacity to produce whole-of-government financial reports compliant with international standards. Functionally, the system might be reflected as: Fig 4: Integrated FMIS Compliant With Standard Software Capacity An FMIS should then be viewed in the context of the IMF/World Bank Treasury Reference Model, as recently revised and reflected in the following figure, where the central and core software system described as the Treasury System is iBAS and the core functionality of iBAS as a ‘standard’ FMIS contains the functions, as a minimum, as described in Figure 4. Figure 4 provides a general view of the core FMIS/Treasury System while Figure 5 shows the FMIS as the core financial system around which all other systems depend and relate. 17 GFM Landscape Functional Processes and Systems For Government Fiscal Management Macro MOF issues Budget Systems for Macro Economic Macro Economic Forecasting Guidelines Call circular Economic Framework Forecasting Budget Preparation Line Ministries submit Budget Preparation Systems Budget proposals Capital- Recurrent-Personnel Complement Approved Budget Vendors MOF / Line Ministries Employees Enter Pensioners Apportionments Treasury System Payments Allotments Releases Transfers Budget Management General Ledger TSA Bank Budget Execution Monitor Budget & Fiscal Reporting Execution Accounting Cash Management Line Ministries/SUs Enter Taxes Duties and Commitments Fiscal Reporting POs/Contracts Payments Receipts Vendor Invoices Commitment Procurement Tax Payers Management Management Goods Receipts Payment requests Treasury reviews/ enters payment Payroll requests and releases Debt service Pension payments for payment Debt payments Cash Bank Monitors receipts Servicing Management Reconcilliation Bank reconciliation Commitments Cash management Position, Payroll and Line Ministries/ Payroll & Pensions Loan Receipts Treasury enter payroll/ Pensions Management pension transactions Systems Information Loan Receipts Debt Management Dept enters Loan Debt Management Debt Management agreements System Donors Repayment requests Revenue Adm. Depts. Loan Agreements Tax Assesments Assess Tax Revenue Receipts Revenue Administration Receive Revenue Revenue Administration Information Receipt Information (Tax and Customs) (Taxes and Customs) from Treasury and Systems Reconcile with assessments Audit Organization Performs Audit of Auditing Government Auditing Systems A. Hashim Transactions March 2007 Fig 5: Modern View of the IMF/World Bank Treasury Reference Model 8. Strategy for Achieving System Functionality A number of factors must be taken into account and a number of actions would be required before any attempt to define full functionality and design a system for use in MoF in Bangladesh. 8.1 Business Process Review Prior to any project to enhance iBAS into a more stable and functional software financial system, MoF should undertake a detailed review of its business processes. The current version of iBAS largely mirrors part of the manual processes that occur in both budgeting and accounting transactions and while this has provided significant benefits, as discussed elsewhere, may not (and generally doesn’t) form a useful basis for ongoing system development. A comprehensive process review will achieve two distinct benefits for the ongoing development of a FMIS. 1. Allow MoF to streamline current processes that will enhance efficiency, reduce waste, provide increased transaction security and be a better fit to processes compatible with both standard system operations and international good practice. 18 2. Identify key strategic processes, check points, activities and current process blockage points and propose their improvement as part of determining user requirements and basic system design requirements. Considerable opportunities for achieving the greatest benefits from computerization are frequently lost because those computer-based systems simply mirror existing processes and add more work to users because they often must maintain manual processes and key data into a software system. 8.2 Define User Requirements and Development Objectives Partially as part of a business process review and partly separately, MoF must undertake a very detailed user requirements specification based on new processes and also on the planned future development and enhancement of a financial system. Where functional requirements are based round efficient and effective practices, a software system adds direct value to current (and future) work practices by taking over functions that are currently duplicated often many times over for little or no added benefit to the process and even add to problems by slowing processes, loss of records, mistakes, malpractice etc. By having a view of where financial system functionality will evolve over time, the fundamental design of the system, even if implemented gradually and in parts, will allow for phased implementation of functional enhancements in the software that avoids major redesign and redevelopment of a system (such as is required in the present iBAS) to effectively achieve strategic objectives. 8.3 Network Capacity While the networking infrastructure in Bangladesh is currently fragile and unstable, due in part to the network itself and to power supply problems, it is clear from many other emerging economies that the development of network infrastructures progresses at a considerable pace. One of the major design factors to be considered in a financial system design is the emerging capacity of networks to expand and stabilize rapidly. There are also new technologies that can better use ‘old copper’ (old but existing copper wire telephone lines and exchanges) for much improved data transmission capabilities. Software coding when designed with these limitations in mind, can also maximise capacity across old copper by structuring that software to minimize data transmission volumes but still achieve required results with existing infrastructure. When this capacity is built into a design, once networking improves, the design will lower networking costs through reduced need of bandwidth. Discussions with network providers would enable MoF to gain insight to short and medium term plans for network enhancements, redundancy, technology, geographic coverage, timetable and bandwidth capacity to help define inputs to the possible network options available for an expanded functional scope of the future iBAS. 19 8.4 System Design Specifications With a comprehensive framework of capacity and knowledge, the development of iBAS, in whatever form it might take, can be planned, development tools and environment determined and final user requirements and system design undertaken and agreed among both technical and business users. 9. Options for Financial System Development There are 2 apparent options for the further development of iBAS available to MoF and GoB. These options are: 1. Re-design iBAS comprehensively into a fully updated version (iBAS 2) but building on the current system. 2. Procure a Commercial-of-the-Shelf package FMIS suitable for the functional requirements of MoF. 9.1. Ongoing Development of Current iBAS This Report suggests there are a number of significant problems with the current version of iBAS, including:  Unintegrated Budget and Accounting  Poor design  Inefficient software  Database table indexing problems  Significant deficiencies in functionality and security  Built as a ‘mirror’ of manual processes  High resource skills in technology but limited experience in financial systems ‘standards’. These and many other concerns strongly suggest a different course of action should be considered by MoF in Bangladesh. The current version of iBAS should be placed on a care-and-maintenance basis while existing resources are directed to which-ever of the two alternatives are determined as the preferred strategic direction of Government Alternative courses of action must be considered. These basically come down to either starting again with an iBAS 2, properly designed and with development controlled by experts familiar with the functional design and development or core financial systems for Government or, alternatively, procure an existing and tested standard suite of financial software. 20 9.2. Design New System iBAS 2 The option to build a completely new version of iBAS (‘iBAS 2’ or ‘iBAS+’ or other suitable name) is one of the two realistic options available to MoF. By taking the current functionality of both the budget and accounting systems and the available reports would be the starting point for a new design but the design would have to follow a detailed business process review, user requirements identification and specification and a full architectural redesign to have a genuine integrated system (Fig 4) with the capacity to link out (Fig 5) into other related systems. The design would have to consider the current challenges of a fragile network, particularly between Dhaka and District Offices and the use of technology that reduced demand on network traffic to a minimum. The development tools, operating systems and database should also be considered in the environment where iBAS 2 may become a much expanded functional system with greatly enlarged user transaction volumes. This analysis and system design would require a minimum period of 6 months to undertake, with a further minimum of 3, but likely 6 months to implement essential business process changes. MoF should then engage experienced experts (most probably from the same consultants) to oversee the actual hard coding of the system functional design, its documentation, testing, training, data conversion and implementation across all current users and, desirably, within existing SOEs. Building and preparing a new system that at best is similar to the functionality of the current iBAS (but with all normal internal security and integrity features) and using existing but retrained technical skills would require an estimated 12 months to reach integration testing stage. Implementation across existing sites using iBAS would, with data conversion and retraining of users, require a minimum of 12 months following pilot and parallel running evaluations, for a total time of 18 months. Taking the opportunity to introduce additional functionality such as basic procurement, commitment accounting, pay-point funds checking and vendor management would add a further 12 months to the total time. This suggests a project duration from commencement to implementation of a partial FMIS of 48months, although some savings in time might be possible by overlapping some activities with others, assuming human resources were sufficient to deliver parallel activities such as multi-site rollouts within the context of running existing iBAS with iBAS 2 for the duration of the implementation. Introducing additional functionality such as fully functioning Accounts Receivable and Payable, Asset Management Cash Management etc would add considerable additional time to the project as most enhanced functions are new to both the development team in Dhaka and the user population. More time, again, would be required if the opportunity were taken during the project to introduce additional reforms such as Program Budgeting or other options available through the financial review and reform processes. 21 Costs of such a development are considerable. Extensive use would be required of experienced international consultants particularly where reforms and enhancements to budgeting, accounting and reporting were involved. When the system is fully implemented, regular maintenance and ongoing changes to system functionality as driven by aspects of the reform program would add considerably to whole-of-life costs. Retention of staff and local consultants with the human capital levels required to maintain and develop a bespoke system and to keep pace with both domestic change requirements and international good practice and accounting standards is challenging to most developing countries. 9.3. Procure COTS FMIS (Off-the-shelf Product) Commercially available financial systems are quite numerous and many would be appropriate to the environment in Bangladesh. Procurement and implementation times are about the same as bespoke systems, the difference being that COTS products are delivered with full standard functionality and regular releases keep the functionality up-to-date with demands of users. There is external support available to client users such as MoF and MoF would be able, and would be advised, to undertake all of the day-to-day operations of such a system and also develop staff capacity to support most problem resolution as and when it occurred. Modern FMISs are largely table-driven, meaning that user control caters for much of the ongoing changes necessary to reflect changes in functional demands, process changes etc once modules have been implemented. Such systems are capable of phased implementation in terms of functionality and license fees can be agreed with the supplier, reflecting both user numbers and functionality being used. Time to implementation would be 3 to 5 years from commencement with 5 years being about the normal timetable. Costs of selecting and implementing a fully functional COTS FMIS for Bangladesh could be between US$10 – 15m, tending to the lower level, with annual maintenance charges for support and standard enhancements generally in the range of 17% to 25% of the license fees, not the full implementation price (which includes all the implementation service costs and are often between 50% to 80% of the total procurement price). To implement a COTS product in MoF, all of the early steps required for an iBAS 2 project would still be required, namely the business process reviews and determination of user functional requirements. The process would then diverge from bespoke design into procurement activities but the overall time to completion are most likely to be similar or with soe(??) time saving to the bespoke option. 22 9.4 Options Timetables Activity Year 1 Year 2 Year 3 Year 4 Year 5 Future Common Activities Business Process Review Define User Requirements Option 1 - iBAS 2 Retrain and Design v Build/Test/Document v User Training/Implementation v New Functionality v Option 2 - COTS FMIS Procurement v Configure/Test v User Training/Implementation v Fig 6: Comparative Timetables for Options 1 and 2 Many variables can affect the timeframe for each of the Options suggestedso that the timetables in Figure 6 may vary considerably. The important point to note is that the time frame for Option 1, iBAS 2 is based on replicating the functionality of the current iBAS with some possible minor functional enhancements but including pay point funds checking, as this development is partially developed in iBAS. The time frame for the COTS option, Option 2 is for the implementation of full FMIS functionality although within the suggested time frame, much of the functionality may not be released to users but a phased release may be considered. Decisions on phasing would be considered as part of project plan formulation and would depend on an assessment of user capacity building at that time. 10. Recommendation This report will not recommend which of the latter two options MoF should decide upon. The Ministry does need to make a decision reasonably soon between the redesign of iBAS into iBAS 2 or to commence a project of implementation of a COTS product. The report does, however, recommend that further development of the current iBAS should be terminated as soon as any essential existing development work is completed and the system be placed on a care and maintenance basis while resources are moved from iBAS to the implementation of whichever option MoF (and GoB) decide upon. Should MoF decide to move away from the current iBAS, it is Recommended that an International Consultant should be identified and appointed to undertake a detailed analysis of the technical environment, human resource capacity and user requirements and develop a strategy for MoF and GoB on how to move forward. Such a strategy document would also provide MoF with a sound basis for making the decision about direction, either toward iBAS 2 or to a COTS product. The development of the strategy suggested would also define a comprehensive set of user requirements specifications that would then, along with information contained within the strategy, 23 form the basis for the Terms of Reference for either the procurement of a new COTS FMIS or an International Consultant to design and either build, or oversee the building of, a COTS-equivalent FMIS. 24 Annex 1 The mission comprised of meetings with the following people: Dr. Mohammad Tareque, Secretary, Finance Division, Ministry of Finance Mr. Ranjit Kumar Chakraborty, Additional Secretary, Finance Division, Ministry of Finance and Project Director, Deepening MTBF and Strengthening Financial Accountability (SPEMP –Deepening MTBF and Strengthening Financial Accountability Project) Mr. Kazi Shafiqul Azam, Joint Secretary, Budget Wing Mr. Anisur Rahman, Additional Comptroller General of Accounts Ms. Salma Begum, Chief Accounts Officer (CAO) Home Ministry Mr. Mohammad Ashraful Islam, Chief Accounts Officer, Primary Education Ministry Mr. Abdus Sobhan, Chief Accounts Officer, Ministry of Health and Family Welfare Mr. Sanaul Huq, Ex-Controller General of Accounts District Accounting Officer, Gazipur Mr. Omar Khan, Senior Development Advisor, Canadian International Development Agency (CIDA) Representatives from donors of SPEMP: DfID, EU, DANIDA, 25 Annex 2 Terms of Reference for Assignment Strengthening Public Financial Management Improvement Program (SPEMP) Project A: Deepening MTBF and Strengthening Financial Accountability Terms of Reference (TOR) Performance Review of Integrated Budgeting and Accounting System (iBAS) Introduction 1. The Government of Bangladesh, under a Multi Donor Trust Fund (MDTF), administered by the World Bank on behalf of a group of donors (DfID, EC, RDE, RNE, and CIDA) will be implementing the proposed Public Financial Management Improvement Program (PFMIP) over a period of 5 years. 2. Under this Grant, the Bangladesh Ministry of Finance (MoF), on behalf of the Government of Bangladesh (GOB) intends to continue with major, across-country, reform of its financial management. It includes both supply side elements (improving budget and financial management systems within the executive) and demand side elements (Comptroller and Auditor General - C&AG, Public Accounts Committee etc - PAC and civil society) encompassing all areas of financial management reform. SPEMP would include three discrete projects (A, B, C), corresponding to the implementation of core reform activities respectively under three entities, Ministry of Finance (MoF), C & AG, and Parliament Secretariat. Project Management Structure 3. Under the overall guidance and leadership of a Project Steering Committee, the Project (A) which became effective in November 2009 and being implemented by the Ministry of Finance through a Project Management and Coordination unit (PMCU). The unit is headed by a Project Director and supported by a team of Management /Implementation Consultants, Additional Project Director and other project staff who will be serving government officials. The PMCU will be responsible for implementation of project components and activities under the project and day-to-day oversight of the operations, compliance with agreed procedures, maintaining liaise with Line Ministries and regular interaction with Lead Donor Agency. Project Objectives 4. The overarching objectives of the project A is to strengthen the basic institutions for budget management and accountability mechanisms of government, with a particular emphasis on the 26 performance focus of the MTBF and the establishment of a comprehensive government wide accounting, reporting and financial management system. 5. The project includes 9 (nine) components, of which one is related to A-5 “Accounting and Financial Reporting�. The objective of this component is to move toward the establishment of a fully functional GIFMIS ( including integration of budget and accounting modules) in government (building on the present iBAS platform), improve the quality of accounts and timeliness of financial reporting for consistency with international standards, and support informed public sector management decision making. As a prerequisite, appropriate linkages or interfaces shall be established between the GIFMIS and the Procurement Management Information System (PROMIS) developed under PPRP. Context and Objective of the Assignment: Government Financial Management Information System 6. The Integrated Budgeting and Accounting System (iBAS), introduced under the FMRP is the platform that the GoB uses currently to implement its accounting and financial reporting. While there have been significant strides in this venture, the reported accuracy, quality of financial data and the effectiveness of financial reporting mechanisms remained a major concern under the current system. 7. The current FMIS, iBAS, is the Ministry of Finance’s preferred solution for its core accounting system. The bespoke application has been under development by the FMRP consultants. However, iBAS is at present confined to separate stand-alone Budget and accounting modules, is only partially built, and has been implemented in only some of the intended line Ministries and entities. 8. The lack of integration between the budget and accounting modules means that users compare budget data with transaction data manually, thereby failing to deliver a potentially core benefit of an integrated FMIS. iBAS is still undergoing development and correction of software errors since it was introduced to replace its predecessor, Transaction Accounting System. It embodies current business processes as dictated by the GFRs/Treasury Rules which, in themselves, require re-engineering. 9. It is designed to have a flexible and expandable Chart of Accounts (currently 4 fields/13 characters) as well as expandable functionality. Some parts of a vendor record facility and some elements of a banking interface are embedded in the application although, at present, the Government banks can only partially interact with the system. 10. iBAS has no procurement, accounts payable, associated funds control (commitments), accounts receivable, complete banking module, and is essentially cash basis accounting. It is also reported by selected MTBF Ministries that iBAS is currently not fully supporting their information needs, or the development of the MTBF. The consulting team for iBAS, on the other hand argued that 27 as iBAS is an open-ended FMIS solution, and that the additions to the functionalities as required under an ideal IFMIS can be accommodated. Scope of Work 11. To mitigate the effects of any potential shortcomings of iBAS as the government-wide FMIS application, the MOF accepted following recommendations which are considered important and the component was designed to achieve following initial requirements:  The viability of the base design, as well as the sustainability of the application during and after the development stage, must be checked to confirm it as being suitable for further development into a core FMIS within the IFMIS overall environment as anticipated under the project.  Whether it would be an appropriate strategy to change emphasis from a central, budgeting and accounting system, to one in which Ministry specific systems are developed to cater to line ministries information requirements and a budgeting and accounting module, a function which is currently a part of the IBAS system, is developed as a part of the ministry specific system. 12. A core activity to be implemented at the initial stage will therefore include an analysis of the software architecture, technology base, and user requirements, and a viability assessment of the application prior to developing a detailed User requirements specification. The viability assessment will establish the suitability of iBAS to fulfil the role as the core FMIS and any remediation required as a result of the initial assessments. This includes the capacity of the system to support large numbers of users and with a greatly expanded functionality. Upon completion of the remediation process, the chart of accounts would need expansion for added consistency with the IMF GFSM 2001, and include the program classification to better support the MTBF, additional functionalities including commitment control, funds releases, virements and re-appropriations/reallocations, banking and banking interface, system security and data integrity controls. Full integration (data added once, stored once) and adequate system security will be an integral part of all enhancement designs. 13. An HRMIS that would support payroll and pension payments, an Asset Management System, and a Government Provident Fund System, is not initially planned under the above scope of work. However, provisioning the development of a potential interface of HRMIS with the FMIS is one of the activities that the development of iBAS or any other application will eventually entail. Additional interfaces for Debt Management, Taxation and Customs Revenue System will also need to be developed on an as-needed basis. 14. For long term sustainability, it is necessary to ensure that hard ware and infrastructure software can be maintained, enhanced and replaced as and when their useful life expires. The project therefore included provisions for hardware and the requisite software during the 5 year period of implementation. 28 15. The main objective of the consultancy is therefore to carry out a detailed assessment, in light of above mentioned findings and recommendations and provide Ministry of Finance with related review information that helps the new SPEMP Project A MISC consultants to achieve the core objective of the component i.e sustaining the maintenance of iBAS as a preferred FMIS solution of government as well as undertaking the implementation of a strengthened FMIS solution, building on iBAS. Key IBAs review Requirements: 16. The review should make an assessment of the existing system vis - vis the requirements of a full function IFMIS that corrects the deficiencies highlighted in paragraphs 6-10 above and determine whether:  The basic system design is scalable in terms of extended functional coverage envisaged for the new system; i.e., whether the functionalities lacking in the existing system can be added on.  What would this entail in terms of time, effort and cost? (The annexes give the detailed data entity relationship diagrams etc. For the existing system. The analysis should make an assessment of what new entities etc. would need to be added for the system to perform as a full function GFMIS).  The analysis should also assess whether it would be possible to preserve some modules of the existing system and add the additional functionalities, or would it be necessary to re- write even those parts of IBAS which are currently being used.  Whether the systems deployment architecture is appropriate (centralized /distributed) and whether the existing system can be deployed at the other additional sites that are envisaged in the new set of requirements?  What are the Government plans for improvement of the basic telecommunications infrastructure over the next five years assess and whether the architecture choices made earlier would take full advantage of the new telecom environment when it comes into place. 29  Whether the technology platform chosen for systems development and implementation, mainly in terms of Application software development tools/ DBMSs etc. is still appropriate? Whether it is scalable in term of the extended coverage envisaged for the new system. If not what changes should be made.  The review should try to determine why the full functionality envisaged in the existing system has not been deployed as yet. What have been the primary constraints? Aare these technical or are they institutional and how they should be resolved so that the NEW system development effort also does not stall after some time?  What is the quality of data in the databases of the old system? If there are problems why have they occurred, what additional controls are required to avoid this. Can this data be usefully be migrated to the new system.  What technical capacity has been mobilized by the GoB to develop and implement the old system? Has this been sufficient? Would it be possible to even further enhance this capacity to custom develop even a more sophisticated full function iFMIS.  What is the level of training of staff in the MoF / agencies, required to support the new old systems. Are there any gaps in this area which will need to be met? Duration of Assignment 17. The consultant will provide a detailed report to the Junghun Cho (Senior Public Sector Specialist, TTL of SPEMP Project A) and Suraiya Zannath (Senior Financial Management Specialist) of the World Bank in Dhaka Office, including presentation of key findings and recommendations within three (3) months of the assignment. The assignment is expected to commence on March 01, 2010, end on April 30, 2010, and is expected to cost US$ 36,000 (Thirty Six Thousand US Dollars). General Requirements of Consultants 18. The consultant is expected to be well versed with the issues of (i) chart of accounts design with reporting in accordance with international accounting and reporting standards (ii) installation, commissioning and functioning of computer-based IFMIS (iv) developing financial policies, processes and standards for the recording and reporting of all forms of government financial transactions ( treasury functions) through the system, (v) clear understanding of the design, 30 development, and implementation of training and capacity building strategies and (vi) public sector budgeting (including MTBF) and accounting (preferable). 19. Given the highly technical nature and type of this assignment, the consultant is expected to have experience of similar assignments including work experience in the developing economies/ countries, with demonstrated diverse range of skills and expertise. Deliverables 20. An outline/ synopsis of deliverables required from the consultancy are summarized below. The TOR at the time of request for proposal will provide more details.  Inception Report, with a format of detailed Aide Memoire after the field visit to Dhaka, to be presented to the TTL within two weeks of field visit, who will share the report with the MoF officials, Project Director and SPEMP team.  Draft reports required to address all activities should be presented to the TTL for discussion and reconciliation of views, prior to the submission of the final reports.  The consultant must submit a comprehensive final report after incorporation of comments and suggestions of the TTL, MoF officials and the SPEMP team. The consultant is also expected to make presentation, highlighting key findings to the Management and Implementation Support Consultant.  As the deliverables are intended to provide inputs for SPEMP-A MISC consultants for improving iBAS, the consultants shall work closely with relevant MISC consultants should they be identified from the current on-going bidding process. Reporting Requirements: 21. The consultant will work in close collaboration with the Project Director of the Project Management and Implementation Unit, Ministry of Finance, who will provide necessary support and arrange meetings/visit to relevant office /officials/stakeholders and seek guidance as and when necessary. Additional Information: 22. To facilitate consultant’s work, he/she will be given access to all relevant documents of the MOF and practical orientation on current IBAs system. To this end, MOF has shared additional information. 31