1. Organizational placement #

When deciding where an RPA team should be located organizationally, there are a multitude of options. I am taking a fictional municipality as my starting point, for which I have made an organizational chart as shown. Marked in red are IT and Digitalization , where it is most optimal to locate your team. Here you can borrow skills and avoid bottlenecks in development. In some cases, these are still two separate departments, and in that case it is most appropriate to locate it in IT . The thoughts behind this choice are described below.

The basis for placing it in IT is the know-how and resources that already exist in an IT department. For example, some data that needs to be accessed through a user interface can be found in a SQL database, where you can make extracts from instead. By having access to the knowledge, and possibly the skills that need to be used for this from IT , you can develop faster and more stable operations. In addition, IT has knowledge of their IT infrastructure, which can tease RPA software in between. This can be everything from group policies, firewall ports, virtual machine maintenance, daily challenges and the like. Here you are also in the loop on a daily basis when updates are planned or crashes occur, so you can react faster.

Digitization is also an option, as it will be a natural part of RPA development. It is not uncommon to map a process and find that data is not digital enough for the robot to do the work. After that, it is typically a task for the digitization department to see if the problem can be solved. Forms are typically the problem, as these are filled out the old-fashioned way with a pencil or pen, scanned and sent around to several hands. If you bring form software into your RPA team, such as Xflow , you can move forward without involving digitization. However, there will be times when it ends up in a real digitization task.

As an alternative to these two, you can create an Automation Department , if you have the size of the organization. This department can deal with RPA , AI , machine learning , process optimization and digital forms . However, you will still need to have cooperation with IT and digitalization , as you will touch on these areas. Very few organizations have reached this point where they use all of these topics. However, it is not unlikely that such departments may become common in the future.

As a final consideration, it is possible in some RPA software to have so-called citizen developers . These are ordinary employees who can also create RPA processes specifically for their own department. Power Automate Desktop is an option for this, as the license is included in many existing licenses ( Education, Business Basic, Enterprise, etc. ). However, it only provides access to the development software itself, where you can build the code and run your robots in Attended mode on your own machine in the Default environment. However, there are not good experiences with this, as the code is typically of poor quality even if it works. Furthermore, it causes problems when an employee who has owned such flows stops, as it then stops running. It will typically be the RPA team that is tasked with maintaining such codes, and it provides more work than benefit. For this reason, it is not something that can be recommended unless you want to invest resources in training internal employees thoroughly.

2. Robot users #

It is not safe from a security perspective to have one robot user with access to everything. Furthermore, from personal experience, it is very tedious and time-consuming to have to split a user’s rights to several at a later time. Therefore, you should plan from the start how you will manage users for the project. Furthermore, it can also help to provide an overview of how many licenses will be used for the project in addition to the RPA software licenses. This includes Office, program-specific and similar.

The ideas below are based on the English term compartmentalization , which can be considered a restriction of access to information within different areas. The extreme version of this is to create one robot user per process, which in my opinion is wasteful. Whether you have 5 robots doing invoicing or 1, they typically have the same access in the same program to be able to perform the task. It can also be difficult to comply with password policies when you end up with 30+ users who have to change regularly. There are also more angles of attack from hackers, as they then have 5 options instead of just having to get hold of one of the users to access the same data. It can also make you lose track when you start to have many robot users.

If we take the organization chart from earlier as a starting point, we can, for example, set up users as follows:

You can create a user where it makes the most sense. In the above case, it is created at the management level, as they are very similar to each other, and typically will have access/rights to the same things. However, for the staff, it is split up into several users, as these may end up having access that is extra sensitive, and preferably should not cross each other.

Small notes on the thoughts behind this:

• A service account can be nice to have in cases where you can only get shared access to a system ( KMD Nexus as an example ).
• The service account does not necessarily need an Office license, the 7x will probably end up needing it, plus possibly other similar licenses. This should be taken into account in the financial section.
• Some old software has a maximum character limit of 6 in usernames
• You don’t need to create each robot before it is actually used.
  • From experience, not all departments are equally quick to embrace the idea, and therefore you can focus on those who are willing to do so at the beginning.

3. Economy #

There are costs when running RPA projects, both for software, salaries and any hardware / licenses the robots need. For the same reason, you should think about how you will cover these costs on an ongoing basis. RPA software licenses are relatively cheap. At the time of writing, you can get a Power Automate unattended robot and 2x developer licenses for just under DKK 1,200 per month. As mentioned in the robot users section, another typical license that needs to be used is an Office license.

In terms of employee salaries, almost all RPA projects start in a pilot phase. Here, existing employees are involved, working x number of hours per week . So it can be difficult to calculate the salary as a cost to start with. When you get out of the pilot phase, however, and you need to have full-time employees for your RPA project, a somewhat larger project will also be needed. The licenses are small money compared to what it costs to have full-time employees.

For the same reason, you should investigate how you will finance your project. You can initially run a ” no worries IT pays ” and provide it as an extra service from the IT department. Once the project is up and running, and it requires full-time employees to run it, the annual bill quickly runs into hundreds of thousands if not millions of kroner, primarily for wages. From here, it can be difficult to budget it without getting extra funds for the purpose from somewhere.

To explain what the best experiences look like, it is easiest to start with one of the bad ones. An arrangement has been tried where a department has to pay for the development and later ongoing operation of an RPA process. On paper, it sounds like an excellent idea, but it can be difficult to set a price for both services. Furthermore, there is a risk that the RPA project will stall, as you will then be competing on equal terms with consulting firms that offer the same service in the city. At the same time, you will get a bottleneck, as there is bureaucracy every time a department has to select a process for RPA. Here, we are compensated with time and money, whether it is even worth developing the RPA process. Some processes do not save money or time, but they do ensure the quality of some work. An example I have had myself was a report that was to be sent to the mayor once a month. It was a process that did not take the employee long to complete, but it was often downgraded or forgotten among more important tasks. Such an RPA process may take a day to develop, but what will it cost to operate? If it costs more to develop than the hourly wage of the employee, then it is rarely worth it for the department to have it done. So you risk missing out on many processes with RPA potential, simply because there is a price to have it developed.

The best experiences, on the other hand, are where you have to think as little about the economy as possible. For example, the department with the RPA project can have its budget increased in order to be able to offer this service. Where the money is to be taken from is up to any managers and budget negotiations. Alternatively, you can collect a fixed amount from the departments that want to be part of the project, in order to spread the costs evenly. This can also help encourage departments to utilize the service, since they pay for it anyway. Furthermore, it is the individual departments that get a benefit, typically in the form of hours released, kroner saved or quality assurance that reduces errors and oversights.

4. Team #

Name	Note	Link
Gartner	A more complete list of what RPA software exists	https://www.gartner.com/reviews/market/robotic-process-automation
Belbin	Overview of Meredith Belbin’s theory of team roles, can be used for recruiting employees for RPA	https://www.belbin.com/about/belbin-team-roles

It can be difficult to figure out who and what qualifications you need for an RPA employee, as it is still very new. My own opinion is that you cannot run it like a traditional project with regular roles. Typically, you will have a small team of 1-3 employees for the first few years of running the project. Typically, you start part-time with RPA until there are so many processes that you can deal with it full-time. For this reason, it is important that everyone in the team can cover the different roles to a certain extent. For example, if you divide into a project manager ( project management, find processes for RPA ) and a developer ( coding robots, responsibility for the software ), the project will be vulnerable if there is a staff shortage later. That said, you can have a primary role in the team, but at the same time be able to take care of some of the others when the need arises. Continuing the example from earlier, it could be conceivable that a project manager is responsible for finding and testing processes for possible RPA development. The person should also be able to create simple processes in the RPA software, possibly with help in the form of UserLibraries / templates created and maintained by the developer. At the same time, there may also be times when there are many requests from the organization, where the developer must also help find and uncover processes.

It would be difficult to explain in free text what roles and competencies are needed in an RPA team. For this, I have chosen to take as a starting point Meredith Belbin’s 9 roles in a team. It should be mentioned that an employee can have several roles. These provide a very good insight into what is needed, and can possibly be used by recruitment staff. Below is an outline of what it is about. In consideration of the roles being swapped around / reworked when they are translated, this is based on the English titles.

I think there are two primary roles in an RPA team: developer and process cultivator ( for lack of a word ). Since you don’t need a traditional project manager, one of the two roles can also have this under them. Furthermore, RPA deals with low-code, so you don’t have to be a programmer to be able to do RPA development. For the same reason, both roles will have some things in common.

A developer typically has the technical skills, in the form of IT knowledge in programming ( primarily scripting languages ) and software. At the time of writing, there is no education in RPA, but the developer can typically be found in an IT department, where they have some of the skills in the table below. This can be anything from database sharks to programmers. IT support students also meet the requirements, as they gain many of the skills at school, and can be used in the RPA project in this role as well . It is a clear advantage if the person concerned can create so-called UserLibraries ( code snippets that can be reused) that the process developer can also easily use. An example could be the one below, where the code is created and maintained behind the scenes by the developer. Here, the process developer simply has to insert an address, and then gets a BFE ( specific real estate ) number, which they can use in their own code.

A process cultivator has the skills to find potential RPA processes and maintain the relationship with the process owners. Typically, this is an employee within the company who has a great deal of knowledge of workflows, procedures, legislation and the like that can be contributed to the RPA team. They can also be system owners or super users of some of the software that employees use in the company.

Below is an overview of the two roles and what each may offer. It should be thought of as a wish list, and skills do not have to be at an expert level but for household needs.

	Developer	Process grower	Common
Belbin type	Thought	Social	Action
Competencies	Scripting Powershell Python VBScript API Database / SQL Regular Expressions	Already familiar with the organization Relevant legislation Workflows Good relationships with several departments	Basic understanding of coding Understanding of flow / processes Super user/system owner of software in the organization Digital forms
Notes	Found in IT departments. IT support students are a good resource as they meet many of the above requirements. Can also be found out in the city.	This role is more important to find in your own organization, as it requires prior knowledge of the organization.*

* With personal experience from several organizations, it takes time to build relationships and knowledge of the organization when you come from the outside. Furthermore, it is easier to sell RPA as a service to employees if you have the relationships and trust in place. Employees in the organization may be distrustful at first, thinking that it is a cost-saving exercise, with a round of layoffs to follow.