## Box 1. Replace or Maintain/Enhance? ## Source details **Canonical URL:** [Box 1. Replace or Maintain/Enhance?](https://www.imf.org/-/media/files/publications/tnm/2017/tnm1702.pdf) ## Other formats - [Markdown version](/-/media/files/publications/tnm/2017/tnm1702.pdf.md) - [Structured JSON version](/-/media/files/publications/tnm/2017/tnm1702.pdf.json) --- ### Suitability - Business models evolve and existing systems "may no longer have the necessary functionality to provide the support that is needed." - Assessment must determine whether to: - rebuild/add new functionality to the existing system, or - replace it with a system which can provide that functionality. - Example: a system may have a return processing function, but it cannot support amendments, or cannot accept returns electronically. ### Maintainability - Systems architecture evolves; modern design (service-oriented, message based, loosely coupled service-oriented architecture) has replaced tightly coupled integration. - Modern design allows regularly changed parameters (tax rates, form labels, etc.) to be handled by configuration of codes tables or rules rather than changes to program code. - Over the life of a system, maintenance costs (both in dollar terms and available knowledge of legacy systems) will rise to a degree where they are no longer sustainable, indicating the need for replacement. - Note: “Legacy” is used to refer to the existing systems. ### Risk to the business - System complexity typically increases over time due to business and systems improvements/fixes. - Documentation of incremental changes is commonly inadequate, both for individual changes and cumulative effects on overall design. - Systems are often maintained/operated by a small number of highly skilled operatives with long-standing connections to the system, increasing operational risk if those staff become unavailable. ### Technical viability - The technical base (databases, operating systems, etc.) is subject to generational change; current version designated “N,” previous “N-1,” etc. - Suppliers typically support versions up to N-2; support for older versions becomes increasingly expensive. - Compatibility issues arise among mixed-version products; at some stage replacement becomes necessary. - A common response is to pay a supplier to keep an old version working; as the number of users requesting this decreases, costs to remaining users rises. ### Build versus Buy: key considerations - Historical progression: - Early bespoke (one-of-a-kind) systems required custom build. - Commercial-Off-The-Shelf (COTS) systems emerged and matured; many administrations now use second generation COTS systems. - Custom development (Build): - Individual programs conceived, designed, developed using internal or external expertise. - Requires skilled analysis, design and development team; uses a traditional and lengthy waterfall approach (consecutive steps: conceptual design; detailed requirement specification; analysis; detailed design; build; test; deploy; and review). - Once design is developed it is “locked in”; extensive tailoring to specific business needs. - Worldwide trends indicate decline in custom development as commercial products become more viable. - COTS (Buy): - Core systems embody good practice features and are configurable to cater for differences between administrations. - Designed to be put in place without major customization, but will lead to some process, procedure or legal redesign. - Allows relatively quick “Agile” iterative implementation since product includes basics of a core tax system and permits prototyping and evolution via module configurations. - In category 1 tax administrations, COTS can automatically introduce good practice processes where existing processes are manual or not well developed. ### COTS vs Custom — comparative findings - COTS acquisition: - More predictable cost. - Known tested product. - Shorter implementation—less time to market. - Lower risk profile—product can be demonstrated in operation in other administrations. - Known performance parameters and hardware requirements. - Product comes with warranty from vendor. - Usually requires single procurement process. - Likely to require some business process compromises although should already embody good-practice. - Business Process Reengineering (BPR) is usually conducted in parallel with system installation. - Vendor supplies capability to install, configure and support. - Vendor can supply upgrades and run/maintenance over life of system. - Documentation readily available and updated. - Can be evaluated before purchase. - Flexibility may be limited by vendor. - Custom design and build: - Estimated cost but high likelihood of over-run. - Unknown outcome from very long and involved design and build process; heavy testing requirement. - Longer process, high likelihood of over-run. - Higher risk profile—unproven product. - Performance parameters and hardware requirements developed during design/build/test process with associated hidden costs. - Administration totally responsible for faults. - Probably requires multiple processes for individual components or services. - Can be tailored to business process requirements although risk of reintroducing existing poor practices. - BPR is conducted prior to system design to establish detailed user requirements. - Administration responsible for developing, maintaining and retaining staff and skills. - Administration responsible for maintaining staff/skills for run/maintenance. - Documentation preparation and maintenance subject to development team outputs (requires discipline to maintain documentation and change control). - Can only be evaluated after completion. - Flexibility only limited by technical issues, capability, and finance. ### Total Cost of Ownership (TCO) and lifecycle costs - Full costing of any option should occur prior to project commencement and be on a Total Cost of Ownership (TCO) basis. - TCO should include initial outlay and ongoing costs: licences, maintenance costs, upgrade provisions, operations costs, etc. - Maintenance/enhancement costs can often be as much as 50 percent of the initial outlay in the first year of operation. - Second release of functionality is common at the end of the first year; this work is not covered by vendor warranty and should be factored into cost models. ### Alignment and process guidance - Implementation choice should ensure system objectives and functionality align to organizational strategy. - Research on international best practice should be commenced before process design is confirmed. ### Typical core tax administration functionalities (high-level) - All tax systems need to identify taxpayers, process information to determine who owes money, and collect tax. - Core modules referenced include: Taxpayer Service; Form Processing; Taxpayer Registration; Events Calendar; Taxpayer Accounting; Revenue Accounting; Payment Accounting; Audit Case; Arrears Case; Filing Case; Audit Selection; Revenue and Analysis. ### Box 2. High-Level Requirements for IT Systems Supporting Tax Administrations — select condensed highlights - Taxpayer Registration: - Issue and maintain a national tax identification number for all taxpayers. - Calculate and maintain a check digit and internal referencing. - Capture and store registration details for different tax types in a ‘whole of client’ view. - Integrate registration with returns and payment processing; deregister and archive with restore ability. - Allocate one identification number for a legal entity and link branches; link directors/partners details. - Generate registration management information and an audit trail of accesses and adjustments. - Payments Processing: - Capture identification number, tax type, payment period, payment type, and payment amount. - Update taxpayer and revenue accounts automatically; interface with banks and “e-payment.” - Reverse payment data, manage retransmissions, process dishonored payments; process to suspense account if necessary. - Generate management information for reconciliations, revenue reports, payment statistics, suspense account reports, and an audit trail. - Form Processing: - Process tax forms for all tax types; support self-assessment principles including identity checks, record date of filing, acceptance of declared liability, perform arithmetical calculation, compare submitted information with database, store form data. - Be easily configured for new tax types or changes. - Reconcile third-party income details; receive forms electronically and generate electronic receipts. - Process amended forms/assessments; issue assessment notices and refunds electronically. - Raise default assessments where appropriate; archive form information and produce management information and audit trails. - Taxpayer and Revenue Accounting: - Maintain an account for all taxpayers; account for all debits and credits for all tax types in a ‘whole of client’ view. - Allow online enquiry and taxpayer web access with appropriate security. - Calculate and impose penalties and interest; automatically adjust them on reassessments. - Structure accounts to identify tax, penalties, interest; age debts; archive nil balance accounts; generate statements of account. - Offset credits and debits within and across tax types; support debits, credits, transfers, refunds, penalties, adjustments, write offs. - Produce management information on overall account status, general ledger, and audit trails. - Events Calendar: - Determine expected forms (including ‘nil return’) and automatically generate appropriate returns for each revenue type. - Determine due dates according to legislation and administrative arrangements; allow approved extensions. - Automatically generate requests/demands after nominated periods, escalate demands after further periods, and allocate cases for manual follow up in the case management system. - Generate management information on expected vs received forms, outstanding forms, age of outstanding forms by office and nationally, and provide an audit trail. - Arrears Management: - Detect outstanding debts and automatically generate demands after nominated periods, including penalties and interest. - Report outstanding debts by taxpayer in a “whole of taxpayer” view and automatically retain taxpayer debt history. - Escalate demands, allocate cases for manual follow up, rank cases for manual intervention based on risk criteria (size, age, number of revenue types, taxpayer history). - Support installment collections, approved write-offs, local and national debt collection plans. - Generate management information on level and composition of debt, volume of new debt, amount collected, amount written off, age of debt, number of taxpayers in debt, status of case management allocations, and provide an audit trail. ### Case Management and Related Systems #### Case Management core functions - 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. #### Audit Support system requirements - 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. #### Taxpayer Services system requirements - 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. #### Revenue Reporting and Forecasting system requirements - 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. #### Analytical Capability requirements - 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 and non-functional requirements - 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. - Non-functional requirements such as operating environment, performance parameters, security, network operations, expected volumes, etc. will need to be described or estimated. - 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. - Key acronyms used: MIS – management information system; RMS – Risk management system. ### How can a product be selected? (COTS considerations) - COTS products can be demonstrated via direct approach to administrations or through an RFI process. - Detailed user requirements are not needed for COTS systems; business processes will be developed to best use the selected product. - Functional capabilities described above can be used to evaluate relative capabilities of products. - Comparison should include outcome questions such as: - How will the system provide: an integrated set of processes and systems that caters for all products? - How will the system provide: an effective analysis, audit and advice capability? - How will the system provide: effective, improved taxpayer service? - How will the system provide: improved enterprise-wide management of work? - How will the system provide: an IT system with integrity and performance? - How will the system provide: productivity and sustainability benefits? - Responses by vendors can be compared against needs of the tax administration and generic procurement requirements, e.g., cost, provider profile, warranty, maintenance, reference sites (existing users), etc. - Particular attention to vendor team strength and assurance that their “A-Team” is sufficiently available. - Reliable information about reference sites (existing users) is essential and may include site visit(s). - Procurement risk of this evolving approach can be mitigated by comprehensive program management and continuous rigorous assessment against achievement of outcomes; consider engaging an external assurer to ensure propriety and value-for-money. ### Implementation and customization guidance - Business process redesign and other changes can be performed in parallel with system implementation. - COTS products typically allow a high level of configuration sufficient to reflect different tax-types, periods, rates, workflow and approval points without code-level customization. - Recommendation: keep software customization at code level to an absolute minimum to avoid increased cost and reduced benefit; adapt internal business processes before contemplating customization. ### Contract issues and support arrangements - Procurement contracts for COTS products should be framed differently from “waterfall” solutions. - Common payment structure: initial payment for software, followed by payments tied to achievement of particular functional modules, with a loading retention for final integration where all modules interact. - Balance required between adequate recompense and acceptable overall outcome. - Vendors likely to offer a range of support services; ongoing support should be tailored to administration’s level of IT capability. - If administration maintains and operates the system in-house, include a much greater training element in procurement. - Provision for ongoing support should be made in the initial procurement to avoid vendor “lock-in”. ### Project timeline example - The timeline shown in Figure 3 indicates a two-year period for procurement and implementation (minimum elapsed time). - Tasks and durations listed in the timeline example: - 12w1. RFI - 8w2. RFP/T preparation - 8w3. RFP/T reply - 32w4. Reference site visits - 12w5. Response evaluation - 6w6. Contract finalization - 1d7. Start implementation - 4w8. Install dev hardware - 2w9. Install base software - 32w10. BPR by module - 40w11. Configure software - 4w12. Install prod hardware - 8w13. System testing - 8w14. UAT - 1d15. Prod implementation - Acronyms: RFI – Request for expressions of interest; RFP/T – Request for proposal/tender; UAT – user acceptance testing. *Technical Notes and Manuals 17/02 | 2017 — Box 1. Replace or Maintain/Enhance?* ### Box 1. Replace or Maintain/Enhance? ### Box 1. Replace or Maintain/Enhance? ### Suitability - Business models evolve and existing systems "may no longer have the necessary functionality to provide the support that is needed." - An assessment must determine whether to: - rebuild/add new functionality to the existing system, or - replace it with a system which can provide that functionality. - Example: a system may have a return processing function, but it cannot support amendments, or cannot accept returns electronically. ### Maintainability - Systems architecture evolves; modern design (service-oriented, message based, loosely coupled service-oriented architecture) has replaced tightly coupled integration. - Modern design allows regularly changed parameters (tax rates, form labels, etc.) to be handled by configuration of codes tables or rules rather than changes to program code. - Over the life of a system, maintenance costs (both in dollar terms and available knowledge of legacy systems) will rise to a degree where they are no longer sustainable, indicating the need for replacement. - Note: “Legacy” is used to refer to the existing systems. ### Risk to the business - System complexity typically increases over time due to business and systems improvements/fixes. - Documentation of incremental changes is commonly inadequate, both for individual changes and cumulative effects on overall design. - Systems are often maintained/operated by a small number of highly skilled operatives with long-standing connections to the system, increasing operational risk if those staff become unavailable. ### Technical viability - The technical base (databases, operating systems, etc.) is subject to generational change; current version designated “N,” previous “N-1,” etc. - Suppliers typically support versions up to N-2; support for older versions becomes increasingly expensive. - Compatibility issues arise among mixed-version products; at some stage replacement becomes necessary. - A common response is to pay a supplier to keep an old version working; as the number of users requesting this decreases, costs to remaining users rises. ### Build versus Buy: key considerations - Historical progression: - Early bespoke (one-of-a-kind) systems required custom build. - Commercial-Off-The-Shelf (COTS) systems emerged and matured; many administrations now use second generation COTS systems. - Custom development (Build): - Individual programs conceived, designed, developed using internal or external expertise. - Requires skilled analysis, design and development team; uses a traditional and lengthy waterfall approach (consecutive steps: conceptual design; detailed requirement specification; analysis; detailed design; build; test; deploy; and review). - Once design is developed it is “locked in”; extensive tailoring to specific business needs. - Worldwide trends indicate decline in custom development as commercial products become more viable. - COTS (Buy): - Core systems embody good practice features and are configurable to cater for differences between administrations. - Designed to be put in place without major customization, but will lead to some process, procedure or legal redesign. - Allows relatively quick “Agile” iterative implementation since product includes basics of a core tax system and permits prototyping and evolution via module configurations. - In category 1 tax administrations, COTS can automatically introduce good practice processes where existing processes are manual or not well developed. ### COTS vs Custom — comparative findings (table prose converted to bullets) - COTS acquisition: - More predictable cost. - Known tested product. - Shorter implementation—less time to market. - Lower risk profile—product can be demonstrated in operation in other administrations. - Known performance parameters and hardware requirements. - Product comes with warranty from vendor. - Usually requires single procurement process. - Likely to require some business process compromises although should already embody good-practice. - Business Process Reengineering (BPR) is usually conducted in parallel with system installation. - Vendor supplies capability to install, configure and support. - Vendor can supply upgrades and run/maintenance over life of system. - Documentation readily available and updated. - Can be evaluated before purchase. - Flexibility may be limited by vendor. - Custom design and build: - Estimated cost but high likelihood of over-run. - Unknown outcome from very long and involved design and build process; heavy testing requirement. - Longer process, high likelihood of over-run. - Higher risk profile—unproven product. - Performance parameters and hardware requirements developed during design/build/test process with associated hidden costs. - Administration totally responsible for faults. - Probably requires multiple processes for individual components or services. - Can be tailored to business process requirements although risk of reintroducing existing poor practices. - BPR is conducted prior to system design to establish detailed user requirements. - Administration responsible for developing, maintaining and retaining staff and skills. - Administration responsible for maintaining staff/skills for run/maintenance. - Documentation preparation and maintenance subject to development team outputs (requires discipline to maintain documentation and change control). - Can only be evaluated after completion. - Flexibility only limited by technical issues, capability, and finance. ### Total Cost of Ownership (TCO) and lifecycle costs - Full costing of any option should occur prior to project commencement and be on a Total Cost of Ownership (TCO) basis. - TCO should include initial outlay and ongoing costs: licences, maintenance costs, upgrade provisions, operations costs, etc. - Maintenance/enhancement costs can often be as much as 50 percent of the initial outlay in the first year of operation. - Second release of functionality is common at the end of the first year; this work is not covered by vendor warranty and should be factored into cost models. ### Alignment and process guidance - Implementation choice should ensure system objectives and functionality align to organizational strategy. - Research on international best practice should be commenced before process design is confirmed. ### Typical core tax administration functionalities (high-level) - All tax systems need to identify taxpayers, process information to determine who owes money, and collect tax. - Figure 1 (referenced) lists core modules such as: Taxpayer Service; Form Processing; Taxpayer Registration; Events Calendar; Taxpayer Accounting; Revenue Accounting; Payment Accounting; Audit Case; Arrears Case; Filing Case; Audit Selection; Revenue and Analysis. ### Box 2. High-Level Requirements for IT Systems Supporting Tax Administrations — select condensed highlights - Taxpayer Registration: - Issue and maintain a national tax identification number for all taxpayers. - Calculate and maintain a check digit and internal referencing. - Capture and store registration details for different tax types in a ‘whole of client’ view. - Integrate registration with returns and payment processing; deregister and archive with restore ability. - Allocate one identification number for a legal entity and link branches; link directors/partners details. - Generate registration management information and an audit trail of accesses and adjustments. - Payments Processing: - Capture identification number, tax type, payment period, payment type, and payment amount. - Update taxpayer and revenue accounts automatically; interface with banks and “e-payment.” - Reverse payment data, manage retransmissions, process dishonored payments; process to suspense account if necessary. - Generate management information for reconciliations, revenue reports, payment statistics, suspense account reports, and an audit trail. - Form Processing: - Process tax forms for all tax types; support self-assessment principles including identity checks, record date of filing, acceptance of declared liability, perform arithmetical calculation, compare submitted information with database, store form data. - Be easily configured for new tax types or changes. - Reconcile third-party income details; receive forms electronically and generate electronic receipts. - Process amended forms/assessments; issue assessment notices and refunds electronically. - Raise default assessments where appropriate; archive form information and produce management information and audit trails. - Taxpayer and Revenue Accounting: - Maintain an account for all taxpayers; account for all debits and credits for all tax types in a ‘whole of client’ view. - Allow online enquiry and taxpayer web access with appropriate security. - Calculate and impose penalties and interest; automatically adjust them on reassessments. - Structure accounts to identify tax, penalties, interest; age debts; archive nil balance accounts; generate statements of account. - Offset credits and debits within and across tax types; support debits, credits, transfers, refunds, penalties, adjustments, write offs. - Produce management information on overall account status, general ledger, and audit trails. - Events Calendar: - Determine expected forms (including ‘nil return’) and automatically generate appropriate returns for each revenue type. - Determine due dates according to legislation and administrative arrangements; allow approved extensions. - Automatically generate requests/demands after nominated periods, escalate demands after further periods, and allocate cases for manual follow up in the case management system. - Generate management information on expected vs received forms, outstanding forms, age of outstanding forms by office and nationally, and provide an audit trail. - Arrears Management: - Detect outstanding debts and automatically generate demands after nominated periods, including penalties and interest. - Report outstanding debts by taxpayer in a “whole of taxpayer” view and automatically retain taxpayer debt history. - Escalate demands, allocate cases for manual follow up, rank cases for manual intervention based on risk criteria (size, age, number of revenue types, taxpayer history). - Support installment collections, approved write-offs, local and national debt collection plans. - Generate management information on level and composition of debt, volume of new debt, amount collected, amount written off, age of debt, number of taxpayers in debt, status of case management allocations, and provide an audit trail. *Technical Notes and Manuals 17/02 | 2017 — Box 1. Replace or Maintain/Enhance?* ### 7. A Case Management system that can: ### 7. A Case Management system that can: ### Case Management core functions - 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. ### Audit Support system requirements - 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. ### Taxpayer Services system requirements - 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. ### Revenue Reporting and Forecasting system requirements - 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. ### Analytical Capability requirements - 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 and non-functional requirements - 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. - 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. - Key acronyms used: MIS – management information system; RMS – Risk management system. ### How can a product be selected? (COTS considerations) - COTS products can be demonstrated via direct approach to administrations or through an RFI process. - Detailed user requirements are not needed for COTS systems; business processes will be developed to best use the selected product. - Functional capabilities described above can be used to evaluate relative capabilities of products. - Comparison should include outcomes questions such as: - How will the system provide: an integrated set of processes and systems that caters for all products? - How will the system provide: an effective analysis, audit and advice capability? - How will the system provide: effective, improved taxpayer service? - How will the system provide: improved enterprise-wide management of work? - How will the system provide: an IT system with integrity and performance? - How will the system provide: productivity and sustainability benefits? - Responses by vendors can be compared against needs of the tax administration and generic procurement requirements, e.g., cost, provider profile, warranty, maintenance, reference sites (existing users), etc. - Particular attention to vendor team strength and assurance that their “A-Team” is sufficiently available. - Reliable information about reference sites (existing users) is essential and may include site visit(s). - Procurement risk of this evolving approach can be mitigated by comprehensive program management and continuous rigorous assessment against achievement of outcomes; consider engaging an external assurer to ensure propriety and value-for-money. ### Implementation and customization guidance - Business process redesign and other changes can be performed in parallel with system implementation. - COTS products typically allow a high level of configuration sufficient to reflect different tax-types, periods, rates, workflow and approval points without code-level customization. - Recommendation: keep software customization at code level to an absolute minimum to avoid increased cost and reduced benefit; adapt internal business processes before contemplating customization. ### Contract issues and support arrangements - Procurement contracts for COTS products should be framed differently from “waterfall” solutions. - Common payment structure: initial payment for software, followed by payments tied to achievement of particular functional modules, with a loading retention for final integration where all modules interact. - Balance required between adequate recompense and acceptable overall outcome. - Vendors likely to offer a range of support services; ongoing support should be tailored to administration’s level of IT capability. - If administration maintains and operates the system in-house, include a much greater training element in procurement. - Provision for ongoing support should be made in the initial procurement to avoid vendor “lock-in”. ### Project timeline example - The timeline shown in Figure 3 indicates a two-year period for procurement and implementation (minimum elapsed time). - Tasks and durations listed in the timeline example: - 12w1. RFI - 8w2. RFP/T preparation - 8w3. RFP/T reply - 32w4. Reference site visits - 12w5. Response evaluation - 6w6. Contract finalization - 1d7. Start implementation - 4w8. Install dev hardware - 2w9. Install base software - 32w10. BPR by module - 40w11. Configure software - 4w12. Install prod hardware - 8w13. System testing - 8w14. UAT - 1d15. Prod implementation - Acronyms: RFI – Request for expressions of interest; RFP/T – Request for proposal/tender; UAT – user acceptance testing. *Source: Technical Notes and Manuals 17/02 | 2017* --- _Source: https://www.imf.org/-/media/files/publications/tnm/2017/tnm1702.pdf_