Felix Hassine, VP Corporate Tax at Kuehne+Nagel
A few years back, we started the journey of automating several components of the indirect tax processes into RPA. For those who are not familiar, indirect tax (we should say “transactional tax”) is the area of taxation where taxes are levied on each transaction. The most commonly known transactional tax is the VAT. However, some countries also have transactional withholding taxes or additional specific-purpose transactional taxes such as levies for education, public transportation, or health. Why is transactional tax so demanding for requiring RPA? Transactional tax gives no option, but to have the taxes calculated correctly at the moment when the operator presses enter on the transactional booking. Given sometimes incredible volumes, legal requirements of recoding and accruing taxes instantly, any other option is closed out. For us in a multinational company, the driver for introducing RPA came several years back, from the sudden need of updating large amounts of master data records. We are now 2.5 years later, and our understanding of the use of the RPA has much evolved.
The enclosed points are the results of many discussions about using RPA robots in our department.
OUR GOVERNANCE RULES IN A NUTSHELL
We had to clarify rather quickly what we need RPA for, what doesn’t require RPA, what we want to achieve, and how we want to measure its benefits. All these are basic questions composing the governance model of RPA for Indirect Tax.
The following are, therefore, our own definitions, and I would totally understand if some companies or specializations would adopt other standpoints when the driving RPA in-house.
WHAT RPA IS FOR IN OUR INDIRECT TAX ENVIRONMENT
We focus on building robots to address a process or sub process with a) meaningful volume, b) repetitive actions, c) criticality of execution (i.e. on a specific event or on a particular date, or both), and, d) that can be executed by a robot managed centrally from a production centre.
In our methodology, risk is maximal and is endorsed on both sides of the development chain (developers and users), so that they win together or fail together 
It might be tough to some, but any robot not in line with these criteria has a large chance of being rejected. As a matter of facts, RPA can be used for anything; it may even be misused as a substitute of workflow, of an ETL tool, or excel macro. Being clear on what it is intended for, helps in staying focused.
WHAT WE INTEND TO ACHIEVE WITH RPA
Over time, we see three gradual levels of use for our robots:
1) RPA-mimicking-humans: Robots as an aide sitting on an individual desktop, which enables creating a series of fast actions and are launched as attended “scripts” into a side window. This is usually how the adventure into RPA-land starts.
2) RPA-data-integrator: Robots that run attended or unattended whose purpose is integrating data. These robots aim at creating complex integration driven by business users– this is important. Such robots respond to basic needs that are required quickly, that would be too long to detail to traditional IT development, and that the process users need in order to have transactions in order.
3) RPA-Virtual-worker: Robots whose intent is to monitor and react to specific events, exactly as if a permanent staff would constantly monitor incoming transactions. The usual type of events modelled is errors, which we want to prevent. In our case, errors such as misused transactions, or misused data, or VAT rates, or exemptions, or wrong master data, etc.. Such robots behave as permanent staff never going to sleep, and capable identify and send (and more actions) the lists of faulty transactions.
STRUCTURE OF THE RPA ENVIRONMENT
The RPA investment consists os implementing a development team, a production environment collecting the “portfolio” of robots, defining a governance model, and an owner for this governance model.
The governance model strongly depends on what needs to be achieved. Many technical departments, envision RPA strictly as RPA-mimicking-humans. RPA can be implemented as such, and it may be a sound option for some types of ultra-repetitive processes. When so, the only important KPI is the “man-day-equivalent”. In clear: how many man-days can a robot substitute? In Indirect Tax, as an example, we had such cases when a declarant had to download, cleanse, and structure three reports per legal entity for twelve legal entities, each month. A RPA-mimicking-humans robot was implemented in a week and saves about an hour per report.
However, we think this type of robots are just scratching the surface of what can be achieved; you can get more by accepting a deep dive into the process details. This translates into a transformation workshop, enabled by a transformation owner, and special rights in regards to the process. This role is “the gatekeeper”.
THE GATEKEEPER ROLE
For this article, we have decided to focus on a key role in our development approach: The “gatekeeper”, or governance owner, in charge of understanding every process to be deployed a robot into. The gatekeeper has a unique role within the development process, with the following responsibilities:
• Approve or Reject a Request for Robot. Some designs would not make sense, for example, when they address process without sufficient volume, or non-routine steps, or maybe executed with another existing system designed on purpose.
• Specify the robot’s actions. Whereas the usual methodology of IT specialists is a “specification sheet” consuming several months of a tiring “ping-pong” with the process users, the role of the gatekeeper oppositely is to understand the work-steps and reduce the specification to a few hours within a brainstorming workshop with the process participants. In order to achieve this, the gatekeeper has the right to accept, reject, modify, and challenge a process in place. The gatekeeper works side by side with the process stakeholders. Having been that gatekeeper for years, I often told stakeholders “you will get 80 per cent of what you tell us you need, but you will get it in two weeks, and we will see the remaining 20 per cent when you get the first version”. In traditional software design, the specification sheet is used by IT stakeholders as a shield for potential post-delivery critics. Simultaneously–this isn’t a coincidence–the motto of this traditional process is to keep development teams as far away from process users as possible and to take no risk. By opposition, in our methodology, the risk is maximal and is endorsed on both sides of the development chain (developers and users), so that they win together or fail together. The gatekeeper is the coordinator of that risk and is at the forefront of it.
• Ensure that be the Future Robot Design Integrates Well into the Process. In order to achieve this, he/she has to first understand what process the robots will be inserted into, and can–in most time has to–change the said process to make sure the robot’s actions integrate well. To clarify, for data-integrator or virtual-worker robots, I have not once yet seen a process that could be inherited as-is and robotised. In each case, processes contain exceptions, which originate from history. The Gatekeeper has to understand the exceptions and, in most cases, revise the process. Without such action, complex robots cannot be integrated.
