We have a new hero. For years this person has travelled the world performing Indirect Tax automation projects and installing Tax Technology software. He takes with him the largest cabin bag that will fit into the overhead locker of the budget airline with the tightest carry on luggage restrictions, and an iPad. He is educated, clever and a chameleon, forever adapting to the daily rough and tumble of the world of Tax Technology. At a customer site, where most perceive him as diligent and a good technician, he likes to keep something in reserve.
He has adopted a pseudonym for the Tax Technology arena to which he is dedicated. He took the “V” from VAT and the “I” from Indirect Tax, and put one on top of the other to create a “Y”. When incorporated with the business applications upon which solutions are built it became “Y@ ERP”, meaning “VAT and Indirect Tax on ERP”, but pronounced “Wyatt Earp”. Most just call him Wyatt without reference to the renowned gambler and deputy sheriff who took part in the gunfight at the OK Corral in 1881. Secretly, Wyatt enjoyed the association. However, today, he was about to be faced with a major technical challenge …
The call came late on a Friday. “Wyatt, we need you at client site on Monday. The project’s gone south and they’re refusing to pay. We need your help”. Three minutes later Wyatt rang off and booked a flight.
On Monday, after a few formalities, he walked into the office where his colleague (let’s call him Derek) was already deep in test results. Even before the perfunctory handshake his left hand was pointing at a print out (yes, the client still liked paper). The customer had lots of VAT challenges and had bought a tax engine.
Derek was a good tax person but lacked a technical background. Wyatt was unfamiliar with the ERP and a custom connection to the tax engine was being built. The developers knew the software and were talented, but unfamiliar with tax. They were using the tax engine in a odd way and they struggled to get more than 80% of their unit test cases to pass. Every time a problem was fixed new scenarios would go wrong. This had been going on for almost 6 months. At one point Derek clocked 72 hours in one week but it made no difference. It was time to deep dive; Wyatt rolled up his sleeves.
There were a lot of moving parts. The requirements were complex with numerous interacting criteria. The configurations in the tax engine and the custom-built connection had been designed with considerable dependency between the two. It was clear that they had not managed to encapsulate the underlying concepts nor implement them. It did not help that they were pushing the capabilities of the tax engine to the limit. The business requirements, project plan and test cases were well documented but there was almost nothing regarding the technical design or configuration strategy.
Late on Wednesday, with this analysis in hand, Wyatt was in earnest conversation with his account manager for this engagement who was several time zones away.
“They’re thrashing”, said Wyatt.
” What do you mean they are ‘thrashing’. What does that mean?”, replied the account manager. Wyatt explained it’s like a fish in an empty bucket – no matter how much it thrashes about it remains in the bucket and cannot make any kind of forward progress. The interdependencies within the components of the solution had become sufficiently confused that it was no longer possible to work out all the relationships between them. To touch something was to break something else.
“So what do we do now?”. Wyatt hesitated, and then replied, “We have to start again; relook at the whole thing from the ground up. I don’t think there’s another way”.
“How long?”, the account manager asked. “Three months”.
“What!!”. The noises on the other end of Wyatt’s mobile became indistinct. The next day Wyatt overheard two of the customers’ senior staff discussing how disappointed they were that the account manager had said it would take another 6 weeks.
The next several weeks were intense. Firstly, Wyatt spent many hours with his colleague understanding the ins and outs of the customer’s VAT rulings and interpretation. After a few passes the key themes were uncovered along with the order of precedence between them. Next, it was a case of understanding what the custom built connection was doing. Fortunately, everyone was always able to answer Wyatt’s questions even if they could not understand why the solution would not work overall. The demands placed upon the tax engine were greater than it could handle without careful planning.
Gradually, the foundation for a new solution started to emerge. The tax engine configurations were sufficiently complex that certain logical constructs, borrowed from lower level programming languages, were employed. Initially the pass rate for the test set dropped to below 10%. The connection was tidied up by removing the overlapping and conflicting semantics hidden within the usage of the data elements. This might sound complicated but in reality this means only that one data element carries one piece of information and lacks uncontrolled dependency on any other (the concept of normal forms borrowed from relational data modeling). The pass rate for our test set hit 25%, then 40%, then 87%. After initial concern, the customer was now pleased enough to pay one of the outstanding invoices.
From that point it still took some time to complete the task and document the design including the reasoning behind it. However, by now 6 weeks were well passed and the writing was on the wall for Wyatt’s company. One of the last actions was to send the customer test results with a 100% pass rate, but it made no difference. The damage had been done and it was too late. Wyatt packed his cabin bag, grabbed his iPad and left.
The customer had struggled with sky-high ambitions that did not take into account the imperatives and disciplines required for this kind of technology adoption. Like all powerful business software, a tax engine’s flexibility can be both its strength and its weakness. If employed within its sweet spot then for the most part it will implement smoothly without overburdening the skill set of a reasonably competent implementer. The problems come when the software is asked to perform outside its comfort zone.
Wyatt was unhappy that his company had lost a customer but noted wryly that he had been the catalyst for a solution even though his CV alone would never have won him the work. As long as he had access to people that knew the missing detail regarding the specific unfamiliar applications, he had the skills and approach necessary to pull the pieces together. From a business perspective, most Tax solutions and their underlying ERPs are ultimately trying to achieve the same things, and usually by employing the same basic IT concepts – which leaves the difference between the products as mostly circumstantial (or just syntax).
That was a few years ago and the customer is now a contented user of the tax engine. Wyatt’s designs are the foundation of the solution to this day as it applies tax treatments to a taxable basis that runs into $billions per annum.
Do you have stories of projects that went wrong but succeeded in the end? To share your experiences and to follow Wyatt’s upcoming adventures please join and comment at our blog pawpawtaxology.com, where we lead an independent discussion on these matters as one more step towards the effective digital transformation of the Tax function at major corporations.
No comment yet, add your voice below!