MAY 2021LIFE SCIENCES REVIEW9RPA USE IN INDIRECT TAXATIONThe 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 RoleFor 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. Felix HassineIn 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
< Page 8 | Page 10 >