1. Kanban board #
One of the things you need most is a kanban board of some kind. This makes everyday life easier, as documentation of ongoing and completed tasks is stored. Below are a few examples of software that you can use for this purpose. However, there are an infinite number of possibilities.
| Name | Note | Link |
| Microsoft Teams Microsoft Planner | Both are included in most O365 licenses for businesses. The team can include a Planner, and you can also create channels that the robots can write debugging into if you use Power Automate as your RPA software. | https://www.microsoft.com/da-dk/microsoft-365/business/task-management-software https://www.microsoft.com/da-dk/microsoft-teams/group-chat-software?ms .url=teamscom Internal Power Automate – Introduction |
| Microsoft DevOps Board | A more hardcore tool from Microsoft, probably mostly intended for larger teams/organizations. | https://azure.microsoft.com/da-dk/products/devops/boards/ |
| Monday | An online platform where you can customize a project management solution. They have a great tool for creating kanban boards where you can customize columns and steps in them. | https://monday.com/work-management https://support.monday.com/hc/en-us/articles/115005317249-The-basics-of-a-board |
| Example of documentation | Process documentation example for section 4 | Coding – Modular Structure – RPA Help |
An example from Monday on how to set this up.
2. Profit realization #
When robots take over work, it is typically a gain realization. This can be saved time, money, increased quality of work performed ( reduce errors, very difficult to follow up on ) and the like. Typically, it is something the departments themselves, managers or the like would like to keep track of. You can create a column in your kanban board, and write an approximate annual savings in this. It will only be an estimate, and can be difficult to track over the robot’s lifetime.
If you want a more precise number, which is also saved when a robot is retired, you can, for example, use a database. This can contain tables that a robot logs data into every time it finishes a run. This way you can see more precisely what is being saved continuously after the robot has been put into operation. It also provides historical data that you can sort through. Therefore, it is a good idea to set this up from the start, even if you don’t think you will need it.
It should be mentioned that you cannot use these numbers to measure the productivity of the RPA team. Whereas you can say that a full-time equivalent in hours is 1924 hours, you cannot expect that each developer can deliver this within the first year of the project. Furthermore, when you have been running for a number of years, you may have a year where not much new is developed, but where previous robots continue to add up the hours. Not all processes have a direct time saving or monetary value. Smaller robots can be a quality assurance that reduces errors in work performed, which would otherwise have cost time/money in the other end. Furthermore, learning and practice will take time, and it will be an ongoing process over the years. Furthermore, the more robots you have, the more maintenance you will also have. There may also be times when you invest time in developing templates (reusable code, API setups, etc. ), where the benefits are only seen later in the process. If you have robots running for years, they will earn back their development time and will provide a natural profit in the future. For this reason, over a number of years you should be able to see that you get more man-years out of the project than you have invested.
Table for logging runs. Number will be what the robot does. You might measure the savings per subtask performed, for example +1 per invoice created. In other scenarios where it may be difficult to measure in subtasks, but you know approximately what the total time savings are per time the robot runs, you can note the number as 1 always per run. You can also take a reward for the robot starting and checking if it has something to do. An example might be checking an inbox for relevant emails that need to be processed, just like an employee would set aside time for.
| ID | Robot name | Date | Number |
Table for savings per number of runs for a robot. Here you will have a row per robot, which you can then connect with the other table and calculate the total savings together. Seconds are the savings in seconds per number of runs (for example 300 seconds per completed invoice ) , and the same in kroner if this is relevant.
| ID | Robot name | Subject area | Seconds | Kroner | Update | Comment | Process owner | Developer |
If you want to display your data ( data visualization ), you can use the following for this purpose.
| Name | Note | Link |
| Power Pivot | Built-in functionality in Excel | https://www.rpahelp.org/docs/microsoft-excel/#7-toc-title |
| Microsoft Power BI | Power BI – Introduction – RPA Help https://www.microsoft.com/en-us/power-platform/products/power-bi | |
| Metabase | https://www.metabase.com/ |
3. Process documentation #
It is difficult to say what and how much documentation you actually need for your robots. There are no fixed requirements, but you should have something around each robot. There is no need to take pictures of every single click you make with the mouse or the like. It is very time-consuming to create such documentation, and at the same time it is not accurate for how the robot actually performs the task. It may be that the process owner has to go through a user interface to perform the task, where the robot can do it via scripts with API calls.
Below are the sections I use myself, and a brief description of what they contain. The documentation itself is linked to a kanban board, where there is further information about the process owner, benefit realization, etc.
- Process description – A brief overall description of the process that the robot must perform.
- Code Description – A brief description of each subflow in the code and what it does.
- Flow diagram – A flow diagram that shows the process. It also reflects the relationship between some subflows in the code.
- GDPR considerations – A section that only exists if GDPR considerations have been included in the process.
- Any attachments
