Abstract
This technical note is the second of three addressing information technology (IT) themes and issues relevant to tax administrations. This note addresses how to select a suitable IT system for core tax administration functions. Note one covers the use of IT in tax administrations and how to develop an information technology strategic plan (ITSP). The third note focuses on implementation of a commercial-off-the-shelf (COTS) system. These technical notes are primarily for tax administrations that have no technology to manage their core tax processes, or their technology is limited and outdated. These notes focus on core tax functions and do not address other business systems (e.g., payroll, finance, document, and asset management systems).
This technical note is the second of three addressing information technology themes and issues relevant to tax administrations. This note addresses how to select a suitable information technology (IT) system for core tax administration functions. The first note covers the use of IT in tax administrations and how to develop an information technology strategic plan (ITSP) and is intended for developing country tax administrations that are largely manual or have outdated legacy IT systems. The third note focuses on implementation of a commercial-off-the-shelf (COTS) system in a developing country tax administration. Ideally, the notes would be read in order but a tax administration that already has an ITSP may choose to go to note two to determine the type of system most suited to its circumstances or straight to note three if the preferred system has been selected. The content of these technical notes reflects the themes and issues the IMF Revenue Administration Divisions are frequently called upon to assist member countries with.
These technical notes are primarily for use by tax administrations that have no technology to manage their core tax processes, or their technology is limited and outdated. The notes may however, also be of interest to more advanced administrations. These notes focus on core tax functions and do not address other business systems (e.g., payroll, finance, document, and asset management systems). For advanced IT tax administrations, there is a wealth of other information available including the OECD Forum on Tax Administration publication: Technologies for Better Tax Administration. A Practical Guide for Revenue Bodies, May, 2016.1
This technical note and manual (TNM) addresses the following questions:
How to decide to keep or replace systems?
How can the “build versus buy” decision be made?
What is a typical set of functionalities seen in a modern administration?
How can a product be selected?
What contract issues need to be considered?
How long will it take to complete the project?
Sophisticated information technology (IT) support has become an essential part of the fabric of modern tax administrations. IT plays a pivotal role in all aspects of tax administration—taxpayer interactions and service, registration, processing, accounting, work automation, workflow regulation, case management, and risk analysis and treatment. As administrations mature, the need for significant changes to the level of IT support emerge.
As well as being an essential part of a tax system’s operation, the level of investment in IT systems is a significant proportion of an administration’s budget, both in terms of capital and ongoing expenditure. Shortcomings in IT support for key functions or directions will eventually raise the question of whether a system needs replacing.
I. How to Decide to Keep or Replace Systems?
In general, a decision on whether to keep or replace systems can be made using four parameters: suitability; maintainability; risk; and technical viability. These are examined in Box 1.
Tax administrations that have very little or rudimentary IT support for their operations (Category 1 administrations) will not need to go past the first parameter, as whatever systems support they have is by definition insufficient. However, all parameters will apply, though to different extents, to those tax administrations which have IT systems that have not kept up with their needs (Category 2) administrations as well as more advanced administrations.
Replace or Maintain/Enhance?
Suitability—As business models evolve, systems in place may no longer have the necessary functionality4 to provide the support that is needed. An assessment needs to be made whether it is more effective to rebuild/add new functionality to the existing system or to replace it with a system which can provide that functionality.
Maintainability—Over time, systems architecture5 also evolves. Modern design such as a service-oriented, message based, loosely coupled service-oriented architecture has replaced systems featuring high levels of integration and tight coupling6 of functions. As well, modern design allows regularly changed parameters such as tax rates, form labels, etc. to be dealt with by simple configuration of codes tables or rules, rather than needing changes to the actual program code which is a much more complicated process.7 Over the life of a system, maintenance costs (both in dollar terms and available knowledge of legacy systems8) will rise to a degree where they are no longer sustainable, indicating the need for replacement.
Risk to the business—Again, over time, the complexity of a system typically increases, reflecting business and systems improvement/fixes. It is common for documentation of these changes to be inadequate, both in terms of individual changes and to the effect that the cumulative changes have on overall design. In many such cases, the system is maintained/operated by a small number of highly skilled operatives who have a direct and long-standing connection to the system. The continued viability of the system is dependent on these staff members and the risk of their unavailability increases over time.
Technical viability—The technical base of systems is subject to generational change9 of the base products and the ability/willingness of suppliers to continue support for out of date versions of those products. Typically, a version of N-2 will be supported, but as versions grow older than that, individual arrangements for support become increasingly expensive. Additionally, in the mix of systems and sub-systems that together form the “system” as a whole, issues of compatibility arise as various versions of different products seek to co-exist. At some stage, replacement will be necessary.
II. How can the “Build versus Buy” Decision be Made?
How can the “Build versus Buy” decision be made?
Once a decision has been made to replace the core systems, tax administrations searching for new IT systems are faced with a common decision: Build versus Buy.
Historically there was only one choice—in the early days of IT systems bespoke (one-of-a-kind) systems had to be built. Then came simple bespoke systems built specifically for tax administrations. Now there are commercial systems available that can be bought virtually “off-the-shelf” (COTS). These early commercial-off-the-shelf systems, known as COTS, were criticised, but this has changed over time as the developers have built more sophisticated COTS systems using their knowledge of international good practice in tax administration. Many developing tax administrations are now using second generation COTS systems.
Custom development (external or internal) solutions (Build)
In custom-developed solutions, individual sets of programs are conceived, designed, and developed into a system using internal or external expertise. In this situation, a skilled and comprehensive analysis, design and development team needs to be engaged or created and maintained. This process uses a traditional and lengthy waterfall approach10 requiring detailed design to be confirmed prior to any build progressing. In core tax systems, this is a long and detailed process, often requiring a level of knowledge a tax administration simply does not have—how they would like to see systems and procedures operate in the future. Nevertheless, once a design is developed, it is “locked in” so technical design and build can proceed. These teams then develop the new system which is extensively tailored to the specific business needs. World-wide trends indicate that there is a decline in the custom development approach as more viable commercial products have become available.
Commercial-Off-The-Shelf (COTS) solutions. (Buy)
Core systems solutions which embody good practice features of tax administrations have emerged and matured in the marketplace. These solutions, although configurable11 to cater for differences between administrations, are designed to be put into place without major customization,12 but inevitably lead to some form of process, procedure or even legal redesign within the organization to accommodate their features.
The existence of these packaged systems presents a significant opportunity to administrations—not only do they represent a modern systems suite which has been designed with reference to other tax administrations, they also embody (and in some cases prescribe) the same level of knowledge and experience in their inherent business processes.
In category 1 tax administrations where existing business processes are not well developed or are manual and do not reflect good practice, this style of reform can also have the benefit of automatically introducing good practice processes as well as systems.
Implementing a COTS system does not demand the use of a lengthy waterfall approach. In most cases a relatively quickly “Agile” style iterative approach can be used. This does not remove the need for an organization to know what it wants from a system, but because the product already includes the basics of a core tax system, it allows business processes to be prototyped and evolved as a series of module configurations are carried out.
COTS vs Custom Comparison
When deciding whether to Build or Buy, features of both options should be considered. Some of these issues are explored below:
|
|
|
|---|---|
| More predictable cost. | Estimated cost but high likelihood of over-run |
| Known tested product. | Unknown outcome from very long and involved design and build process. Heavy testing requirement. |
| Shorter implementation—less time to market. | Longer process, high likelihood of over-run. |
| Lower risk profile—product can be demonstrated in operation in other administrations. | Higher risk profile—unproven product. |
| Known performance parameters and hardware requirements. | Developed during the design/build/test process with associated hidden costs. |
| Product comes with warranty from vendor. | Administration totally responsible for faults. |
| Usually requires single procurement process. | Probably requires multiple processes for individual components or services. |
| Likely to require some business process compromises although should already embody good-practice. | Can be tailored to business process requirements although risk of reintroducing existing poor practices. |
| Business Process Reengineering (BPR) is usually conducted in parallel with system installation. | BPR is conducted prior to system design in order to establish detailed user requirements. |
| Vendor supplies all capability to install, configure and support. | Administration responsible for developing, maintaining and retaining staff and skills |
| Vendor can supply upgrades, (which will be a response to issues experienced by their whole client base) as well as run/maintenance over life of system. | Administration responsible for developing, maintaining and retaining staff and skills. |
| Documentation readily available and updated. | Documentation preparation and maintenance subject to development team outputs (requires discipline to maintain documentation and change control). |
| Can be evaluated before purchase. | Can only be evaluated after completion. |
| Flexibility may be limited by vendor. | Flexibility only limited by technical issues, capability, and finance. |
|
|
|
|---|---|
| More predictable cost. | Estimated cost but high likelihood of over-run |
| Known tested product. | Unknown outcome from very long and involved design and build process. Heavy testing requirement. |
| Shorter implementation—less time to market. | Longer process, high likelihood of over-run. |
| Lower risk profile—product can be demonstrated in operation in other administrations. | Higher risk profile—unproven product. |
| Known performance parameters and hardware requirements. | Developed during the design/build/test process with associated hidden costs. |
| Product comes with warranty from vendor. | Administration totally responsible for faults. |
| Usually requires single procurement process. | Probably requires multiple processes for individual components or services. |
| Likely to require some business process compromises although should already embody good-practice. | Can be tailored to business process requirements although risk of reintroducing existing poor practices. |
| Business Process Reengineering (BPR) is usually conducted in parallel with system installation. | BPR is conducted prior to system design in order to establish detailed user requirements. |
| Vendor supplies all capability to install, configure and support. | Administration responsible for developing, maintaining and retaining staff and skills |
| Vendor can supply upgrades, (which will be a response to issues experienced by their whole client base) as well as run/maintenance over life of system. | Administration responsible for developing, maintaining and retaining staff and skills. |
| Documentation readily available and updated. | Documentation preparation and maintenance subject to development team outputs (requires discipline to maintain documentation and change control). |
| Can be evaluated before purchase. | Can only be evaluated after completion. |
| Flexibility may be limited by vendor. | Flexibility only limited by technical issues, capability, and finance. |
One of the major differences between a COTS system implementation and the other options is that the costs can be established prior to making a decision to proceed. Options involving in-house design and build efforts are much harder to estimate. Many such large-scale projects fail because of underestimation of cost, complexity and time-to-market factors. Full costing of any option selected should occur prior to commencement of the project and needs to be on a Total Cost of Ownership (TCO) basis. TCO should not only include the initial outlay, but also ongoing costs such as the cost of licences, maintenance costs, upgrade provisions, operations costs, etc. It is worth noting that maintenance/enhancement costs can often be as much as 50 percent of the initial outlay in the first year of operation. As users familiarize themselves with the system, further requirements inevitably emerge. The response to this is that it is common for a second release of functionality to be developed and deployed at the end of the first year. This work is not covered by any warranty provided by the vendor—it is further development work and should be factored in to cost models.
Another significant difference can be with business processes. Implementation of a COTS product can deliberately adopt those business processes inherent to the product. That is, the way the organization works is changed to match the processes already built into the product selected. In cases where existing business processes are far from best practice, this style of implementation can also have the benefit of automatically introducing good practice processes as well as systems. Whatever the option chosen, research should be commenced on international best practice before process design is confirmed.
Whichever approach (build or buy) is chosen, the system objectives, and the functionality must align to the organizational strategy. See Technical Note 1 Use of Technology in Tax Administrations – Developing an Information Technology Strategic Plan for more detail.
III. What is a Typical Set of Functionalities Seen in Modern Tax Administrations?
But all tax systems are different… This is an often-heard statement. But in essence, all tax systems are the same—they need to identify taxpayers, process information so they know who owes money to whom and collect tax. Typical functionality in core tax administration IT systems is demonstrated in Figure 1: Functionality needed in a tax administration IT system.
Functionality Needed in a Tax Administration IT System
Citation: Technical Notes and Manuals 2017, 002; 10.5089/9781475581126.005.A001
The following presents a high-level set of requirements that any IT system should normally support in order to deliver the services required by a tax administration.
High-Level Requirements for IT Systems Supporting Tax Administrations
1. A Taxpayer Registration system that can:
Issue and maintain a national tax identification number for all taxpayers, and cater for business license activities.
Calculate and maintain a check digit and internal referencing to ensure the validity of these identification numbers.
Capture and store specific registration details for different tax types in a ‘whole of client’ view.
Integrate the registration system with all other core business functions, e.g., returns and payment processing, so that registration details are stored and maintained once, but reused by other systems.
Deregister taxpayers and archive information in such a way that it can be restored.
Allocate one identification number for a legal entity, but enable branches of an entity to be linked.
Allow for linking details where taxpayers are directors of companies and or are partners in partnerships.
Generate registration management information, e.g., registrations by entity type, by office, by region, by sector, by industry, and an audit trail of any accesses and adjustments made.
2. A Payments Processing system that can:
Capture identification number, tax type, payment period, payment type, and payment amount.
Update these details into the taxpayer and revenue accounts automatically.
Automatically interface with external payment method options, e.g., banks, “e-payment.”
Reverse payment data and manage any re-transmissions of payments data including the processing of dishonored payments.
Have the ability to process a payment to a suspense account if taxpayer or account details are not known.
Generate management information that enables: (1) payments reconciliations; (2) revenue reports; (3) payment statistics; (4) report on suspense account activities; and (5) an audit trail of accesses and any adjustments made.
3. A Form (tax declaration/tax return) Processing system that can:
Process tax forms (declarations/returns) for all tax types, including business licenses.
Support fully the principles of self-assessment for processing declarations/returns, including: (1) check taxpayer identity against the taxpayer registration system; (2) record date of filing/lodgment; (3) acceptance of the tax liability declared by the taxpayer; (4) perform arithmetical calculation based on the data in the form (declaration/return); (5) compare information submitted against information held within the database for the taxpayer; and (6) storage of tax form (declaration/return) data in the database.
Be configured easily to cater for new tax types or changes to existing taxes.
Be able to perform a reconciliation of third-party income details with information declared.
Receive forms (declarations/returns) electronically.
Generate electronic receipt for electronic tax forms (declarations/returns).
Process amended tax forms (declarations/returns) or assessments.
Issue assessment notices electronically and issue any subsequent refund electronically to a customer’s/taxpayer’s bank account.
Raise default assessments where a tax form (declaration/return) has not been lodged where appropriate.
Archive, to an environment that can be restored if required, form (declaration/return) information where the account balance is nil at an appropriate determined time.
Produce management information on quantity of forms (declarations/returns) received, and an audit trail of any accesses or adjustments made.
4. A Taxpayer and Revenue Accounting system that can:
Develop and maintain an account for all taxpayers.
Account for all debits and credits for all tax types in a ‘whole of client’ view.
Enable all tax types to be recorded in the same style of account.
Allow proper identification of all information passed to it from the payment and returns processing systems.
Calculate due dates for incoming transactions.
Allow for amendments to be made via reassessments, account adjustments, transfers, etc.
Allow online enquiry to all details of a taxpayer’s account.
Allow, with appropriate security, taxpayers to view their account via web access.
Calculate and impose late/nonpayment penalties and charge interest if appropriate.
Automatically adjust penalties and interest if an amendment to an assessment is made.
Structure the account so that details can be clearly identified between tax, penalties, interest, while being able to present all the taxpayer’s account balances across all tax types.
Age debts.
Archive, to an environment that can be restored if necessary, nil balance account details at the appropriate determined time.
Generate a statement of account, in either paper or electronic form for a particular tax type, or consolidated for all tax types.
Offset credits and debits within a tax type and across tax types.
Provide for a variety of accounting transactions, e.g., debits, credits, transfers, refunds, penalties, payments, adjustments, write offs, etc.
Produce management information on overall account status, general ledger for the department and wider government, and an audit trail of any accesses or adjustments made.
5. An Events Calendar capability that can:
Determine whether a form (declaration/return) for a particular tax type should be expected from a taxpayer. This includes a ‘nil return’. Automatically generate appropriate returns for each Revenue type.
Determine the due date for all tax form (declaration/return) types according to legislation and administrative arrangements.
Allow an extension to the due date for filing/lodgment of a form (declaration/return) if a taxpayer’s request is approved.
Automatically generate a request/demand for the form (declaration/return) after a nominated period, after the form (declaration/return) has not been filed.
After a determined period, automatically issue a more strongly worded demand if the form (declaration/return) has still not been filed.
After a further determined period, if the form (declaration/return) is still outstanding, allocate the case for manual follow up via the case management system. Manual follow up may involve issuing a default assessment, or if warranted, possible prosecution for failure to file the form (declaration/return).
Generate management information reporting on how many forms (declarations/returns) were expected, how many were received, how many are still outstanding, the age of the outstanding forms (declarations/returns) for all offices, and be able to consolidate this information on a national basis. An audit trail of any accesses or adjustments made is also required.
6. An Arrears Management system that can:
Detect cases where there is a debt outstanding and payable.
Automatically generate a demand for payment of the debt after a nominated period when the payment was not received, and payment of penalties and interest if the payment has been made late.
Report all outstanding debts by taxpayer, so that coordinated action can be taken across all debts owed by the taxpayer in a “whole of taxpayer” view.
After a further period, automatically issue a stronger demand for the debt to be paid.
Automatic retention of a taxpayer’s debt history must be updated to the database.
After a further determined period, if the debt is still outstanding, allocate the case for manual follow up via the case management system.
Rank debt cases for manual intervention based on risk assessment criteria, e.g., size of debt, age of debt, number of revenue types involved, taxpayer history, etc.
Support collection of outstanding debts by installments.
Allow debt cases to be cleared via approved write-off processes.
Support the compilation of local and national debt collection plans.
Generate management information on level and composition of debt, the volume of new debt, the amount of debt collected and the amount written off, the age of debt, the number of taxpayers who are in debt, status of cases allocated via the case management system, and an audit trail of any accesses or adjustments made.
7. A Case Management system that can:
Manage all types of workflow for an individual case, e.g., a taxpayer audit, a taxpayer debt, a disputed assessment, an outstanding return, and responding to taxpayer correspondence.
Prioritize cases to be created and allocated using predetermined risk assessment criteria.
Electronically assign cases by a supervisor to case officers on the basis of relative priority.
Record case details at the time of case selection.
Display other cases involving the same taxpayer.
Record actions taken and date.
Generate standard letters and notices initiated by the case officer.
Record case notes.
Permit re-allocation of cases.
Record time to action cases and maintain status of case, e.g. pending, closed, etc.
Notify supervisors if cases are not being resolved in a timely manner.
Retain and retrieve case history indexed by the taxpayer identification number.
Generate determined management information for all case types, such as cases created, cases closed, cases still outstanding, elapsed time for actions, and maintain an audit trail of any accesses or adjustments made.
8. An Audit Support system that can:
Conduct financial analysis of form (declaration/return) and other data to automatically select cases for audit.
Prioritize selected audit cases based on predetermined risk management criteria.
Allocate cases for manual action via the case management system.
Provide information for the preparation of the annual audit work plan.
Provide tools to assist with audit activities, e.g., software that can analyze taxpayer accounting records, links to other 3rd party information and reference material, and the ability to work remotely from a taxpayer site.
Record audit activities and results.
Update risk data according to outcomes of audit.
Generate determined management information on the numbers, timeliness and results of audits, the success rate of audit cases selected, changes to selection criteria, and maintain an audit trail of any accesses or adjustments made.
9. A Taxpayer Services system that can:
Support the development of taxpayer services products.
Provide staff and taxpayers with access to rulings database, public information, standard questions, and answers for frequently asked queries.
Ensure information and downloadable forms on the department’s website are accurately maintained.
Allow interaction with the taxpayer through the website, and with proper security, allow taxpayers to view their account details on-line.
Provide channel choices for communication—print, email, text, electronic message, etc.
Receive and record taxpayer correspondence which is then managed via the case management system.
Receive and record taxpayer disputes, appeals, objections and amendments which are then managed via the case management system.
Generate determined management reporting with an automated audit trail of any accesses or adjustments made.
10. A Revenue Reporting and Forecasting system that can:
Report on all revenue assessed across all tax types, nationally, by office, by sector, and by industry and have the ability to analyze information at further levels if required.
Enable real time reports to be generated by department officials.
Track revenue collection against predetermined budgets for specific tax types and for the revenue as a whole.
Create and maintain revenue forecasting models that can determine “what if” scenario planning outcomes for tax policy budget changes, and for determining the possible result of a specific compliance strategy intervention work activity.
11. An Analytical Capability that can:
Receive and assemble data from multiple sources (including Customs data).
Cater for multiple views of data with multi-indexing capability.
Provide analysis tools for risk assessment, trend analysis, “what-if” scenario analysis, etc.
Generate pre-defined reports.
Respond to requests for ad-hoc reports and analysis.
Other features
Access to various compartments of the system/groups of taxpayers should be determined and controlled by role-based security permissions, if possible, linked to the HR system.
Additionally, non-functional requirements such as operating environment, performance parameters, security, network operations, expected volumes, etc. will need to be described or estimated.
Linking the Functionality in a Fully Integrated IT System
When properly linked in an integrated tax system this functionality should enable the main activities of a tax administration to be supported by the IT system as outlined in Figure 2.
Integrated IT system—Functionality Structure and Main Information Flow
Citation: Technical Notes and Manuals 2017, 002; 10.5089/9781475581126.005.A001
Key: MIS – management information systemRMS – Risk management systemIV. How can a Product be Selected?
COTS products are in operation in many tax administrations. There is ample opportunity to see them demonstrated either by direct approach to the administrations, or as a result of a Request for Information (RFI) process presented to the market.
The major difference from a traditional suitability assessment process is that detailed user requirements are not needed in the case of COTS systems as business processes will be developed to best use the selected product. The functional capabilities along the lines described above can be used to evaluate the relative capabilities of products. That comparison can be accompanied by a set of outcomes questions such as:
How will the system provide:
a. An integrated set of processes and systems that caters for all products?
b. An effective analysis, audit and advice capability?
c. Effective, improved taxpayer service?
d. Improved enterprise-wide management of work?
e. An IT system with integrity and performance?
f. Productivity and sustainability benefits?
Responses by vendors to the tender issued (market offerings) can be compared with their relative abilities to meet the needs of the tax administration, and with the capabilities each market offering presents at a functional level, along with other generic procurement requirements, e.g., cost, provider profile, warranty, maintenance, reference sites (existing users), etc.
Particular attention needs to be given to the strength of the vendor team. Vendors may have several installations going on at the same time. It is extremely important that they demonstrate assurance that their “A-Team” is sufficiently available for the assignment. Reliable information about reference sites (existing users of a system) is essential before any final decision is made. This would include extensive discussions with those sites and may include site visit(s).
This is an evolving approach to modern IT systems procurement. Because this method does not fit the older “textbook” style of procurement—where detailed user requirements and specifications are already known—it can be perceived as having a high-risk profile. However, the procurement risk itself needs to be balanced against the needs of the administration in terms of timing and alignment with best practice. Procurement risk can be mitigated by ensuring comprehensive program management and a continuous and rigorous assessment against achievement of outcomes. Allied to this could be engagement of an external assurer, whose role would be to ensure propriety and integrity in the procurement process and value-for-money in the delivery of products and services.
Once a selection is made, the business process redesign and any other changes required can be performed in parallel with the system implementation. It should be noted that COTS products routinely allow a high level of configuration. This configuration capability is usually sufficient to reflect different tax-types, periods, rates, etc. It also allows different workflow and approval points etc. so most needs should be able to be catered for without actually customizing the product itself.
The tax administration should make every effort to ensure that software customization at code level is kept to an absolute minimum, as customization will defeat the purpose of selecting a COTS package solution and will greatly increase the cost (and likely reduce the benefit) of the overall IT systems upgrade. Typically, organizations that opt for COTS solutions for their IT needs consider adapting their internal business processes before contemplating customization of the new software. Since the package will already embody typical features of modern tax administration business processes, an administration’s business processes can be redesigned to ensure alignment with the new system—effectively a reverse re-engineering of the business processes. The need for customization of the new system to the administration’s business processes will consequently be reduced. This approach will therefore significantly curtail the implementation timeframes and is likely to be less expensive.
V. What Contract Issues Need to be Considered?
Procurement contracts for COTS products need to be framed differently from “waterfall” designed solutions.13 Whereas a “waterfall” solution would usually have payment points related to the consecutive stages of the process, COTS implementations, because of their necessarily iterative process, involve a more complicated set of variables. It is common to schedule an initial payment for the software itself, followed by payment points attached to achievement of particular functional modules, e.g., registration, return processing etc., but a loading retention needs to be made for the integration of the final product, where all modules interact in the intended manner. Achieving a balance between providing adequate recompense for effort and achieving an acceptable overall outcome needs to be designed into the contract.
Ongoing maintenance and new releases
Vendors are likely to offer a range of support services for their products. Apart from obvious warranty matters, ongoing support will need to be tailored to the requirements of the administration depending on their level of IT capability. If an administration chooses to maintain and operate the system in-house, a much greater training element should be incorporated, whereas a lower level of training may be required if it is envisaged that the vendor will provide those services on an ongoing basis. Whatever level of support is chosen, provision should be made for it in the initial procurement to avoid vendor “lock-in” at a later date where the administration effectively has no choice but to have the vendor perform the required follow-up work, leaving them at the mercy of the vendor to potentially overcharge and profit from the situation.
VI. How Long will it Take to Complete the Project?
Whilst satisfying the IT needs of an administration via a COTS option provides a clear advantage in terms of implementation time, it is still not a quick process. Once a decision is made to investigate products with a view to purchase, a simple timeline can be assembled. The timeline shown in Figure 3 indicates a two-year period for procurement and implementation. It is not a full project plan—it does not include important tasks such as change management, data migration, etc. which would be conducted contemporaneously. Nor does it highlight a series of specify/build/test phases that exist within the tasks 10 and 11. This should be considered the minimum elapsed time to procure and install a product. It assumes all tasks are met within the allocated timeframes and all decisions are made promptly.
COTS Procurement and Implementation Timeline Example
Citation: Technical Notes and Manuals 2017, 002; 10.5089/9781475581126.005.A001
Acronyms:RFI – Request for expressions of interestRFP/T – Request for proposal/tenderUAT – user acceptance testingThe OECD Tax Administration 2015: Comparative Information on OECD and Other Advanced and Emerging Economies reported average IT costs for all OECD revenue agencies at around 11-12 percent of total expenditure with some reporting over 20 percent of total expenditure. For non-OECD countries the expenditure is generally much lower.
Margaret Cotton is a Senior Economist in the Fiscal Affairs Department of the IMF. Gregory Dark is a member of the IMF’s roster of fiscal experts.
Although basic functions may exist, the way those functions operate in the context of the wider system may no longer be what is needed—e.g. a system may have a return processing function, but it cannot support amendments, or cannot accept returns electronically etc.
The way programs are arranged and assembled to provide functionality
How programs are designed to operate with others: tight coupling is at direct coding/interface level whereas loose coupling uses modern message-based technology such as Enterprise Application Integration (EAI) for communication between modules/programs/systems. This allows much greater flexibility in maintenance.
Modern packages allow changes to be made via in-built options, whereas older systems have these values hard-coded into programs. Configuration does not alter the program itself, whereas hard-coded values require re-programming of the system—a much more involved process. Configuration changes can be done in shorter timeframes and at a much lower cost.
“Legacy” is a term used to refer to the existing systems.
Things like databases and operating systems are regularly updated by suppliers. The current version is designated “N,” the previous one is N-1 and so on. Over time, the way these things work evolves to a stage where a new version will not work with some other products of a different vintage. A common response to this is to pay a supplier to keep their old version working. As the number of users requesting this decreases, costs to the remaining users rises.
Consecutive steps of a Waterfall Approach are: conceptual design; detailed requirement specification; analysis; detailed design; build; test; deploy; and review.
Configurations is the use of provided options to achieve “personalization” of a product, e.g., like selections from dropdown boxes commonly seen.
Customization entails changes to the underlying code as opposed to configuration. Any customization makes version upgrades of the product more expensive and difficult.
Described in more detail on page 5.
