With the emergence of low-code and no-code automation platforms, creating automated workflows by oneself has never been easier. Employers are now able to encourage and empower their personnel from all across their organization to create and consume automations en masse. People able to do this are often called citizen developers. This allows organizations to tackle the tail-end of processes and tasks that might have previously been outside the scope of their digital transformation program.
However, having access to an automation platform is not going to make people develop their own automations. And even if everyone was excited to automate their own job and knew how to use the automation tool, how does one ensure the wheel is not being re-invented many times over across the whole organization?
Although creating these automated workflows is far easier than before, not everybody can become a citizen developer. Managing the compliancy of individual automations and the overall value of the automation stack successfully requires multiple roles.
The stakeholders that enable scalable citizen developer programs are:
CD Power Users, who create automated workflows for themselves and others in their team/unit and suggest automation ideas.
CD Regular Users, who create automated workflows for themselves and also suggest automation ideas.
CD Consuming Users, who use automated workflows created by others and suggest automation ideas.
The Automation Centre of Excellence, which authorizes new automation projects, manages and prioritizes the pipeline, owns the CD quality assurance process and manages and maintains the automations they own.
Lastly, the IT facilitates the implementation of automations for CD users.
So, even though citizen developers create automations, there are other roles that are needed as well. The goal is to optimize the work of the employees. The involvement of both the CoE and the IT is crucial as without them the whole citizen developer program can end up in disarray. This is not a too dissimilar situation to the macro-making days of the 90’s. Testing, maintainability, transparency and KPI monitoring are all important.
The governance model
To govern, you don’t just need a governing body. Like with RPA, you’ll need a governance model, the use of which is monitored and enforced by the CoE. The citizen developer program governance can be made a part of the broader automation program governance model. Let’s go through the items in the model one by one.
It all starts with the presentation of automation ideas. All ideas should be sent to the CoE for approval. This could be done via a submission form made with MS Forms, for instance.
The approval has multiple purposes:
- If the automation seems unfeasible, no further effort needs to be spent in building a citizen developer-powered solution.
- If the automation is feasible and appears to have potential to be implemented more widely in the organization, it can be prioritized higher up in the pipeline. Wider implementations also have the benefit of educating people who may not yet have been exposed to the citizen developer program.
- If the automation has been already created elsewhere in the organization, the existing automation can be made available to whomever presented the idea.
Once an automation idea has been approved, it’s time to ensure the person creating the automation has the tools they need to build it. This also includes completing adequate training if none has been done yet.
Like other process automation projects, it’s important to capture the logic and reasoning behind the automation to a solution description document.
And, to ensure the automation does exactly what it is supposed to, a quality assurance process must be in place to validate and verify it before going live with the solution. Even if a person is building an automation for themselves, the effects may be widely felt. For instance, a robot that forwards emails will have to be precisely defined and tested to prevent it from going haywire due to a development oversight. Exception handling must also be taken care of, and
it’s something that with which citizen developers tend to struggle.
Once the go-live step has been taken, if the automation is or will be made available to more than one person, the ownership should be taken by the CoE. Otherwise you run the risk of losing access to the automation when the creator leaves the organization, and it has to be rebuilt from scratch. If the automation is wanted to be expanded in any way or form, a regular change request process should be started. The priority of the change is determined by the CoE.
As you can see, governance is truly needed. Otherwise, instead of structure and scalability, you end up with chaos and entropy.
How to make it work?
Start small. Enable a team rather than a whole business unit. Consult a skilled partner to avoid pitfalls. Identify the potential power users, regular users and consumers. Make sure everyone is aware of what’s expected of them and steer the efforts by setting appropriate targets. Is your top priority perhaps to reach a number of automated workflows or an amount of time saved with said automations?
Also, it is not a given that employees start automating the exact tasks they are paid to do in the first place. A culture that encourages automations and empowers employees to actively look for such opportunities is a must-have for success. Perhaps an approach where the CoE rents automations from citizen developers by paying a capital income-type fee on top of the existing salary could create the virtuous cycle needed to really democratise the development efforts. But who knows - there is no simple answer here.
To succeed, a citizen developer program requires more than just access to a technology. And with the right kind of approach, you can control the chaos and enable your people to perform much better in their everyday work. Happy citizen developing, and happy governing!
Niko Lehtonen, service value manager for intelligent document processing, Digital Workforce Services