How to crack transformations of outdated tax systems with COTS (Commercial-Off-The-Shelf) software?

[former_member190765]

For a long time I lived in a sea-side village which is part of a major city. The heart of the village consisted of 1-dollar shops, pawn shops, hairdressers and government departments. Although many house-holds around the village had a reasonable income, the village lacked soul was testament to many empty shops. After 6PM there was no one in the streets. People looking for entertainment travelled to the neighbouring towns rather than spending their money directly in their own village. It was like a self-fulfilling prophecy. Whenever I asked my friend – a local realtor – When do you expect the turn-around? His answer was; “It is not bad enough yet for it to change”. The village still somehow “worked”.

For 10 years working as Solution Manager in the taxation space (or field), I was involved in assessments of transformation projects moving outdated legacy tax environments into a central modern platform. Often transformation was replaced by further Band-Aids and I felt reminded of my realtor friend saying “It is not bad enough”. I then asked my-self what is “bad enough”, if not the current status-quo?

Overall the value statements of digital agendas in the taxation field are universal: Increase Tax Yield / Improve Compliance / Close the Tax Gap / Improve customer service / Improve efficiency / TCO reduction / Increase System Agility and these agendas need more modern taxation platforms. Modern, low-touch taxation cannot be achieved with 30+ year old legacy stovepipe landscapes. While books could be written about this topic and many challenges are clearly cross-industry, here is

A selection of the encountered issues:

The existing system landscape of the taxation authority consists of a myriad of different bespoke built tax systems, built as silos on different technology stacks. The silos often align with tax types, domination of political powerhouses and even complete technology camps. A single-source of truth, central taxpayer record does not exist. Functional reuse (e.g. registration, common payment system, address verification, forms processing) either does not exist, or exists via new functional island systems. Those “functional hubs” have not only resulted in many new interfaces, but also in data duplication. Data reuse then often led to new decoupled “data hubs”. Those “data hubs” are then supposed to deliver the single source of truth. Really? Moving data around landscapes is the pest of modern real-time computing and should be avoided if possible. The further the core technology aged, the missing agility of those core systems led to new low-risk and low-price islands in the form of excel sheets and/or Access DB solutions. Eventually it resulted in architecture diagrams plastering walls as no one could read the zoom-out versions of them on a power-point slide anymore. At times the Service Oriented Architecture (SOA) paradigm was used, for purposes other than intended, to suggest that decoupled, integrated, small functions are more cost effective/agile than an integrated standard platform. Analytical business warehouses are still to this date seen as natural data hubs where tax compliance activities happen. Government reorganisations in all shapes and forms have aggravated the situation over the years and have also led to further variety of IT technologies.
Often a massive workforce (often comparable with a medium size software company) is needed to maintain those system landscapes. Costs of the systems are sometimes not directly measured because education programs for public servants have transferred IT investments into public servant salaries. In many countries it was “politically inappropriate” to reverse this situation. In some low cost countries software license costs for standard software is higher than programming labour and I have seen software development taxation projects coding stock-standard case/document management, reporting, workflow, correspondence and similar available COTS-functions. The programming language skill of your workforce should play a negligible role in this journey. The “cement” of the old legacy landscapes is thick and hard; they are inflexible and have never been built for digital, omni-channel consumption and CRM-style customer service. A literally dying workforce is not available to maintain/understand the 30 year old coding. It is impossible to extract and manipulate data in/from those core systems. Hard-coded rules lead to policy and legislation freeze or new point solutions. In other words, the taxation authority is concreted in “form-based” (sometimes even paper-based) taxation. Political agendas introducing changes are handled in new silos in order to meet strict timelines. Not only is the technology running away from these old systems, often the technology components are simply going “out of maintenance”. Across the silos, accounting practices vary widely, which leads to double accounting, reconciliation and missing ability to account on an accrual-basis.

Sounds like the situation is evil enough, so what hinders the successful transformation to a central COTS platform for all tax types?
While governments will never jeopardize their tax collection, the transformation to a new platform is a major, risky, costly undertaking often exceeding election cycles. Externally, political leaders are rarely (re)-elected promising a better, more efficient tax system. Often funding is done on individual project level without the overall, long-term, strategic transformation in mind. In a nutshell transformation programs often run out of political support. On the complexity side, no major transformation happens with a “Big Bang” implementation, so a new COTS platform will start with new, temporary interfaces into the old legacy world. This complexity is often used to argue that initial transformation projects to the new platform are more expensive than adding “band aids” to existing legacy systems. The value of the new platform will incrementally increase only over time with every new function/tax type transferred. Economy of scale value comes with tax type reuse of platform functions. Often I have heard that the business, with its aging workforce, is resistant to change. But in my opinion “transformations exclusively driven by IT” is sometimes a better description of this omnipresent situation. In the end the transformation needs to serve the taxation business and the external taxpayer community; so they need to be an integral part of the journey from the very start. What is true is that business is used to think in their tax type silos and cannot imagine the value achieved by an organisation with the ability to operate cross tax-type. In addition an ingrained, legacy-build mindset is one of the biggest stumbling blocks for COTS implementations. An implementation project set up to treat the transformation like a legacy build development project is doomed to fail. Successful COTS implementations do not start with an in-depth, green-field requirement gathering producing hundreds of papers describing data models, screens, messages and so on. Such demands e.g. for detailed field-level detailed data models are usually not appropriate for a COTS selection and should raise immediate red flags.

Where to start? – Time, Funding, Delivery

Tax transformations are costly and an absolute pre-requisite is the political sponsorship at the highest government level. It can be only achieved with transparency of the predicted value of the program. Funding of projects must enable the adoption of strategic options, rather than expecting the first project to incur the cost of the up-front strategic investment. As massive transformation programs will take time, legacy and policy changes will not stand still during the projects. So prepare for ongoing adjustments without changing the core program principles. Prepare for a long journey with ongoing momentum and give your chosen COTS-implementation partner early visibility. While “breathing time” in between projects is good, implementation partners need to have a clear roadmap to invest on an ongoing basis into your transformation. This will enable them to invest, on-board and retain the best possible resources on your program. The resulting system of the transformation will be the basis for the next 20-30 years to come. So transfer/inheritance of old system complexity into the new world should be avoided at all cost. Consideration should definitely include simplification options with regards to architecture, legislation, policy and so on. While taxation is a complex matter, achieving simplicity should be a mantra of your transformation. Simplicity should also question existing architecture paradigms. Do you really need to have a separate business warehouse e.g. using in-memory technology? Does your risk and compliance engine need to operate on a separate business warehouse? How can you achieve instant, real-time, pre-emptive tax compliance if tax operation and compliance engines are decoupled? Cloud-options? Internet of Things ? Think out-side the old paradigms as technology has moved on/is still moving rapidly and legislation/policy must sooner or later follow. Make “Digital First” your strategy and question the necessity for outdated channels. Your new architecture should minimize systems and data movement. Every data duplication/movement might equate to a future data reconciliation. Define a central, simple architecture and a common process blue-print for all tax types. Initiate a “why not COTS-product” approach. It is not a reason to go back to a cluttered best-of-breed product approach simply because the COTS product cannot compete in one functional aspect. Simplification does not stop with a simpler architecture, but must also take the possibility of legislation simplification into account. The program must have central political control and mandate ongoing procurement decisions. Instant need e.g. from one specific department should be weaved into the program and not enhance the legacy while the program is active. Favour consolidation and de-commissioning at all times. Involve the COTS vendor into your journey regarding visibility of strategic direction and Co-Innovation options. Understand and align with your COTS-vendor application and technology roadmap. In order to leverage the roadmap, sensible application upgrades need to be part of your journey. As I have worked closely with typical ERP back-end projects before, I was quite astonished to see the level of excitement when COTS tax systems were upgraded and the users got new features out-of-the-box. Define what policy and legislation system agility into the future means. As it is one of the major goals of your new system, KPIs and use-cases should be defined. Rule-engines are a great tool to provide decision visibility, but only if implemented correctly. Ask whether the business can understand the business context and whether it is possible to alter certain rules with ease. Define the testing and governance process of such changes. It usually requires a strict “configure before build” mantra. While policy and legislation changes vary greatly in complexity, I have seen tax departments overestimating the level of effort in order to implement changes.

As COTS products can be implemented by many implementation partners, choose a consultancy partner who has sound operational industry and product knowledge and retains their architects on-board (you do not want to start costly upskilling of consultants on the project).

First projects … ?
There is no straight answer to this question, but here are some of the common patterns I have encountered.

1. Master data consolidation and quality plays a major role in any transformation. Many non-integrated legacy system usually own their taxpayer master record. Master data in the different system will be of different quality e.g. when it comes to communication and address information. How do you identify and consolidate the same parties? How do you validate the records and resolve contradictions? Many activities can be done via data services way before your transformation journey starts. Master data governance tools (such as SAP MDG) can help to overcome the bridge time when legacy and COTS platform operate on the master data.


2. Migration is a massive task and should not be taken lightly. How long into the past shall tax transactions be migrated? It might be easy to align this question to the legal necessity to reassess tax returns or even longer because all other systems shall be decommissioned as soon as possible. But this option might not be very economical. The tax forms and the aligned legislation has very likely changed during the last 10 years and statistics will show you that the percentage of amendments will decrease drastically over time. So do you really want to implement 10 year old outdated forms/legislation on the new platform if only a very low percentage of the forms will be reassessed. Depending on your statistics and tax types, your migration strategy might vary. Also the migration journey shall start at the beginning of your project. Migration should be an integral part of your testing from day 1 on, otherwise e.g. the data quality from the legacy system might surprise you too late in the project.


3. Should you start with tax types or functions or a mixture of both, is a fundamental question of every transformation. The easiest answer could be to move tax type by tax type with all functions onto the new platform. This approach might work very well if your organisation is completely siloed within tax types otherwise this leads to a situation where taxation staff and taxpayers need to work on multiple systems. COTS solutions should be able to allow integration with the legacy environments and allow a mixture of function and tax types. For example I have seen central online registration or debt management services across tax types.


4. If you have a natural segregation of your taxpayer population, then it should be a program planning consideration. So e.g. focus on business taxes or personal taxes. As personal income tax is in general very complex and high risk, I have seen most tax organisation starting with less complex business taxes.


5. In order to get familiar with the new COTS platform, a proof-of-concept/pilot project is a good idea. Non-complex tax types with a limited number of taxpayers such as excise taxes are a great starting point. It is low risk and allows learning and visualization for future tax types to come.


6. While the temptation is huge to take the transformation as a pool of tactical improvements which are needed and funded anyhow, this behaviour usually leads to a new island solution on the COTS platform acting like a new wheel in your legacy stovepipe environment rather than a replacement of your legacy environment.

SAP and its implementation partners world-wide are highly committed to successful transformation programs in the taxation space. Tax and Revenue Management - as part of the digital core of our S/4 HANA in-memory technology supports a unique, intelligent, customer centric low-touch taxation platform for years to come. Please contact us in order to explore your options.