We always want to maximise our investments, so what is the best approach to introduce automation? Is it better to develop an automation unit that is focused on a small number of centrally developed and controlled automations, or to empower our teams to develop automations within service lines?
How about a centralised function for automation?
Creating a dedicated unit is often our first thought when rolling out new technology. We are unsure how the new technology will work alongside our existing business-as-usual processes and there is likely to be a training and skills gap within the existing staff. With a dedicated team, we can invest in experts who will be able to develop a professional service offering. Through a dedicated team, we can:
- Develop and apply a consistent branding
- Enforce quality standards and controls
- Create documentation templates and standards
- Enforce release gateways
- Concentrate training and staff development to minimise costs
- Set expectations on the reliability and robustness of automation
- Showcase automation as a professional service
This centralised function can on paper be very attractive. It enables a business to deliver automations that have a professional look and feel and meet high standards of quality and functionality.
But…
By concentrating this capability in a small team we are limiting the capacity to develop new automations, sacrificing throughput for control and consistency. These capacity constraints can be perceived as a lack of urgency from the development team. And the slow progress on the promise of automation can lead to disillusion with the automation programme in the wider organisation.
Expert automation teams also suffer from being experts in automation technology, and not subject matter experts in the business. Without high levels of engagement with service lines, the team will struggle to create automations that meet business needs. Requirement gathering is an essential part of the process for developing automations, but it can be difficult to get exact user requirements and engagement from stakeholders.
Indeed, teams, for whom automation could be a cost-effective option, might question the ability of an outside department to automate their work. This could either be because they feel the automation team has no knowledge of their working practices, or they are fearful about the loss of elements of their role to automation. When teams don’t see themselves as part of the future this can lead to resistance, and ultimately failure of the programme seeking their input.
In the face of such resistance, it can be tempting for development teams to look inward. Falling back on best practice principles and solutions that have worked in other areas, or for other customers. Inevitably they create solutions that meet best practice, but not business need. They become an echo chamber, hearing only their own ideas and innovations that they think the business needs. This can, sadly, result in unused and unwanted automations that the business never asked for.
With a centralised function, we get the benefits of control and standardisation, but this comes at the cost of a slower return on investment. For this to be successful the automation team must work as part of a multi-disciplinary team with experts across the subject matter areas. Vitally, they must actively engage and seek collaboration at every stage in the process.
Shouldn’t we be opening this up to everyone?
An alternate approach is to make the automation software available to all in the same way that we do with tools such as Excel. Instead of a dedicated team, we allow teams to explore the capability within their own service lines, developing what they need, when they need it. By empowering teams in this way, we:
- Enable creativity and innovation from within service lines across the business
- Reduce concerns about automation through visibility
- Enable staff development and learning
- Allow subject matter experts to design the automations they need
- Enable teams to move at a pace they are comfortable with
However, this only works if the service lines have staff with the skills, capacity, and interest in creating automated solutions. Empowering automation as an organisation wide capability is a huge organisation development challenge. Whilst there may be service lines eager to develop skills in this area, there will be others who have little interest. And for these, without a centralised function they will have no route for automation of their work.
With no central coordination, control, or standards there is a high risk that the quality and robustness of the automations created will vary wildly and that teams duplicate functionality. Instead of helping business processes, the automations could complicate service delivery, compromise quality, and lead to staff frustration and distrust in automation solutions.
By opening up automation to all staff members there is a risk that control of the capability could be lost. Instead of a professional aligned service offering, we end up having created a library of partially finished, inaccurate automations that don’t deliver reliable and accurate solutions.
Is there a middle ground?
Thankfully this scenario is not unique to automation, and we can look to other industries and technologies to find resolutions for similar circumstances. The most applicable are the app stores within our mobile phones.
App stores contain hundreds of thousands of apps. Almost all of them are developed by third parties with little or no relationship to the mobile phone manufacturer. These apps are all very different. Some are very useful and popular; others are not worth downloading. However, they have the same thing in common. They have all had to meet the app store’s minimum criteria. As a user, we know when selecting an app that it will work on our phone's operating system and that there will be some level of support. We also have the option to search for apps from known companies that we trust, look up reviews, and see notes on any updates.
This operating model retains a centralised team, but instead of all automations being developed by them, their role is to develop and promote standards for automations that service lines developing them can work within –hosting and managing an Automation store if you like. This centralised team act as quality control for the automations and ensure that a minimum standard has been met before an automation can be considered suitable for sharing more widely.
This doesn’t mean that all automations will be a success. But it does ensure that there is consistent branding, documentation, and user support for those created. It provides a route for teams that want to benefit from automation but don’t have the skills to develop their own, who can use the central team to support development. The organisation can even go one step further with the possibility to create trusted central automations from those that were originally user generated.
This Automation Centre of Excellence bridges the gap between the two models and enables innovation and governance to co-exist.
How are we developing our own Automation Centre of Excellence?
Over the past 12 months we, at SCW, have been investing in automation programmes and growing our skills and experience to support the emerging customer needs we have seen. Working with industry partners we have developed our own Centre of Excellence frameworks and evaluation tools.
Applying these frameworks to automation programmes we have been delivering within SCW has enabled us to critically evaluate the strengths and weaknesses of these automations and create a strong platform for future automation delivery for our customers.
For more information contact Tom Counsell, Deputy Director of Research and Development, SCW Innovation,
