With the emergence of low-code and no-code automation platforms like Microsoft Power Automate and UiPath Studio X, creating automated workflows by oneself has never been easier. Employers can now encourage and empower their personnel across their organisation to develop and consume automations en masse. People able to do this are often called citizen developers. Using citizen developers allows organisations to tackle the tail-end of processes and tasks that might have previously been outside the scope of their digital transformation program. The next wave of process automation is truly here! Except…
Much like you can't give a person a car and expect them to know what to do with it, having access to an automation platform will not make people develop their automations. Maybe employees are excited to automate their tasks and know how to use the automation tool, but how to ensure the wheel is not re-invented repeatedly across the whole organisation? It's almost as if governance and support are needed…
Gartner's definition of a citizen developer is as follows: "A user who creates new business applications for consumption by others using development and runtime environments sanctioned by corporate IT."
Note the last part: "sanctioned by corporate IT". This implies the IT must be involved. Even though citizen developers are – more often than not – from the business side.
Also, even though creating these automated workflows is easier than ever before, not everybody can become a citizen developer per se. Managing the compliance of individual automations and the overall value of the automation stack requires multiple roles involved in any successful implementation, which we will be discussing next.
The roles
Five stakeholders enable scalable citizen developer programs, which you can see in the table below:
| Role | Function |
|---|---|
| CD Power Users | Create automated workflows for themselves and others in their team/unit |
| Suggest automation ideas | |
| CD Regular Users | Create automated workflows for themselves |
| Suggest automation ideas | |
| CD Consuming Users | Use automated workflows created by others |
| Suggest automation ideas | |
| Automation Centre of Excellence | Authorises new automation projects |
| Manages and prioritises the pipeline | |
| Owns the CD-quality assurance process | |
| Manages and maintains the automations they own | |
| IT | Facilitates the implementation of automations for CD users |
So, even though citizen developers create automations, other roles are needed as well. The goal is to optimise the work of the employees. The involvement of both the Automation CoE and IT is crucial as the whole citizen developer program can end up in disarray without them. This is not a too dissimilar situation to the macro-making days of the '90s. Testing, maintainability, transparency, KPI monitoring and knowledge transfer are all critical even in smaller automations. But how to manage all this?
The Governance Model
To govern, you don't just need a governing body. Just like with RPA, you'll, of course, need a governance model as well, the use of which is monitored and enforced by the Automation Centre of Excellence. You can see our proposed model for citizen developer program in the diagram below. It can be a part of the broader automation program governance model.
Let's take a look at what it contains.
It all starts with the presentation of automation ideas. Citizen developers must submit all ideas to the Automation CoE for approval. CoE can collect ideas via a submission form made with MS Forms, for instance.
The approval has multiple purposes:
1.
If the automation seems unfeasible, no further effort needs to be spent in building a citizen developer-powered solution.
2.
If the automation is feasible and appears to have the potential to be implemented more widely in the organisation, it can be prioritised higher up in the pipeline. Broader implementations also benefit from educating people who may not yet have been exposed to the citizen developer program.
3.
If the automation has been already created elsewhere in the organisation, it can be made available to the submitter.
Once an automation idea is approved, it's time to ensure the person creating the automation has the tools they need to build it. Furthermore, the developer must also complete adequate training if not completed yet.
Like other process automation projects, it is vital to capture the logic and reasoning behind the automation to a solution description document.
And, to ensure the automation does what it is supposed to do and precisely that, 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 oneself, it may have extensive effects. For instance, a robot that forwards certain emails will have to be precisely defined and tested to prevent it from going haywire due to an oversight by the developer. It is also crucial to take care of the exception handling, something that citizen developers tend not to understand.
Once the automation goes live, and if it will be available to more than one person, CoE should take ownership. Otherwise, you run the risk of losing access to the automation when the creator leaves the organisation and someone needs to rebuild it from scratch.
If there are plans to expand automation in any way or form, it's good to start a regular change request process. The CoE again determines the priority of the change.
As you can see, governance is genuinely needed to succeed in a citizen development program. 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. Ensure everyone is aware of what's expected of them and steer the efforts by setting appropriate targets. Is your top priority perhaps to reach many 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 look for such opportunities actively 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 current salary could create the virtuous cycle needed to democratise development efforts. But who knows - there is no simple answer here.
A successful citizen developer program requires more than just access to 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!
Article by: Niko Lehtonen, Product Manager