Even when automation is a clearly good idea there's a number of issues in selling an automation project. When I started in the industry I had a very heavy interest in automation but automation wasn't considered as widely back then. It's fairly clear that there were a number of issues with the branding of automation projects but the value of automation just kept rising with developments in technology that kept increasing the ROI on automation projects. Increasingly there was big value to be had in being good at automation and being good at selling it to people. Back when I started in the automation field the term Robotic Process Automation (RPA) didn't exist at all, this term really only picked up a few years ago, but more about why that stroke of branding genius happened later. This term is a slightly confusing one because it really has nothing to do with traditional robotics and has mostly been a marketing invention to sell automation products under a new branding. But why was automation in need of a rebranding?
Automation has multiple branding problems
This might sound silly to say but automation is work that is not done by humans. A lot of the issues stem from it being harder to sell the absence of work compared to the presence of work, especially in the context of our current economic system that is based largely on energy expenditure. When people do less work there tends to be less visibility of that work, which can be a practical problem for a manager in an organization. This is especially so in organizations which have a decision making approach that's influenced by cost based accounting since automation will be a very obvious capital expenditure that's visible to the organisation in a clearer way than labour utilization.
When we automate things successfully enough for human involvement to not be needed, people tend to forget fairly quickly what was involved. The value is there, but the people to champion it might not be. With enough automation that's taken for granted, the champions might themselves be laid off and people don't tend to destroy their own jobs deliberately. But over time people retire and move on from, so you sometimes see situations come up like COBOL being a critical technology at various banks where decades of automation has been good enough that it has led to a massive staffing shortfall in certain legacy technologies. Because people didn't have to think so much about what was being automated the notion of succession planning and training new staff for those skills just wasn't front of mind, so now there's an acute talent shortage if people wanted to actually revisit that work.
In the modern IT industry, just like in the 1800's, the major mind share still seems very set on new products and features. New features and products are novelties, and the human mind loves novelties, even if those things aren't necessarily productive or worthwhile. Because of this bias automation, projects and products have a far better chance of being sold if it directly enables something new to be made. Additionally, if new products are created, the automation can sidestep the issues that come about from shrinking the headcount of departments, which is an important political factor in many organizations.
Most people have no intrinsic interest in computers but are very interested in what computers enable, the things that increased computational power and technology have enabled continue to capture the publics attention. But quietly in the backrooms of enterprises everywhere, the less glamorous economic powerhouse of computational enabled automation has remained, quietly returning a massive ROI on the time capital and expertise invested in it. This automation, which has been present since the beginning of the computational industry has, up until the rise of Excel and later RPA, been firmly in the background due to the division of labor combined with visibility issues. There's a huge out of "sight out, of mind" issue with this sort of successful automation.
These visibility issues tend to feed into organizational politics issues. For example valuable back office automation tends to not be seen at all unless it breaks. Because the benefits are often invisible or taken for granted if people's attention is drawn to a process only in the times it breaks, they will tend to get a biased view of the value of those processes and automations. As a result, many executives from a non-technical background find it hard to fully grasp the value of these initiatives because the invisible isn't as easy to conceptually grasp as the visible.
Automation is fundamentally about work NOT done
One of the unique dynamics about automation projects is the removal of work from employees. The overall amount of work the employees do may stay the same after an automation project but for this to be the case it will require those employees to take on some work that they weren't previously doing. Any removal of work will change political power structures that are based on how many direct reports someone has. As such, automation work shifts the balance of power in organizations and will therefore inherently be a political activity.
When you decide to adopt a strategy that involves not doing work you will always have some interesting visibility issues. Outsourcing is an interesting contrast to automation and is often seen as a feasible alternative for many automation tasks when the cost of outsourcing is low enough.
When you approach a task via outsourcing, you have the visibility of the outsourcing agency very clearly in mind: you pay some external services firm money to take care of your problem. When you try to deal with the same problem using automation, you have a whole different project structure that comes with its own set of concerns.
Most automation tasks are about reducing the operational costs of running a business, they tend to enable new business and new features but in an indirect manner from reducing the amount of burden on the general operations of a business. Because automation work is often not connected to a particular customer account or to a new product 1.
Many RPA products have a sales strategy that desperately tries to quantify the benefits of the work not done to sufficiently high up stakeholders in companies. From a design angle a common theme is to create GUIs that are very deliberately designed to look like serious automation is going in the eyes of stakeholders who are unfamiliar with automation. The target audience for many of these automation interfaces are people who will procure them, not the actual users. This conflict is particularly obvious when you see tasks that are better done without a GUI but yet are forced to be done via a GUI in these RPA vendor products. These poor ergonomics for daily use are no accident however, since they represent a way of making automation more visible, especially to stakeholders who are not knowledgeable with automation. These GUIs are often designed in a way that evokes feelings of serious work being done so that a manager or stakeholder can clearly see some visual representation of the automation project while sometimes simultaneously impeding more advanced automation work. More efficient approaches that are less visible run the risk of the automation being forgotten about, leading to people stopping buying from the automation vendor. Modern RPA vendors understand this dynamic very well.
Successful automation is promptly forgotten about
As mentioned in the previous post about the narrow window in which automation projects are recognized if you have a super successful automation project then the project can get forgotten and the automation taken for granted.
This poses a dilemma for someone who's a vendor or a consultant in the automation space. One common strategy found in the RPA space is to very deliberately maintain friction with automation projects. Many vendors very deliberately design their products in such a way that you can't use them in a manner that you'd forget their existence.
In practice this tends to manifest itself in products that lack any sort of APIs. Ironically the RPA vendors don't want you to automate using their products. Part of the motivation for this is a sales one, if people start forgetting that they have successfully automated things then they might also forget to keep paying the RPA vendor. But the other part of it is to try to not lead people down the path of learning how to do this stuff from first principles since that can led people to choose products that are expensive because of the opportunity cost of staff time rather than the cost being manifested in procurement.
Successful automation is a multi-disciplinary affair
To be able to automate a process multiple different abilities have to come together at once. You need people who understand the domain being automated, the context of the business or organization which is doing the automation along with the skills needed to implement. Selling something that requires a number of different skills to come together is hard, especially if the organization doesn't see this sort of work as a priority.
On top of all this you need an organization that will actually allow the automation project to successfully be implemented. Even in an organization that has some automation work in its vision, this isn't something that can be taken for granted at all.
Many automation and RPA products try to sidestep the multidisciplinary skills requirement by directly selling the ability for domain experts to implement their own automation without needing to work with automation practitioners. This sometimes works but it can be at the cost of turning your domain experts into defacto software developers. Many of the worst spreadsheet abominations I have seen have been the result of domain experts being forced to do software engineering work on the side. It might be better to let your employees remain specialized in whatever it is that they are good at, getting them to be more generalized is tempting because it might expand the number of roles they can fill and projects they can work on but might be a bad decision overall.
The great RPA rebrand
Automation projects - at least in their traditional sense - contain many things that you fundamentally must do and cannot buy. This has much in common with learning: you have to put in effort to learn things, this effort is an important part of the learning process so the effort expenditure can't just be bought off the shelf. I mention learning specifically because a huge part of any successful automation project explicitly involves learning about the operations of your organization, both technical and political. Far too often in the software world we see elegant solutions to the wrong questions, learning the requirements lets you learn what the right questions are, this learning process can't simply be bought.
It's much easier to sell things that just involve buying rather than doing. Buying is mostly a question of procurement, but doing starts to involve a lot more factors including people's time and effort. If something requires people to do organizationally uncomfortable things, the sales process gets a lot more difficult. You can buy tools that will help you with automation but ultimately automation is a "doing thing".
In 2018 I was doing a bunch of work with Allison, and I very clearly remember a conversation we had about marketing strategy for automation services. Many of my strongest professional skills are around running automation projects so I was wondering what it would take for me to sell the automation services of my company. As part of doing research into the market we came across many RPA vendor sites and consultancy groups, generally speaking these were highly polished sites with very slick sales processes. Perhaps this slick sales angle was not so surprising after we found out that some of these companies had a workforce which was 75%+ sales staff with a small percentage doing any technical automation work. She noticed something particularly interesting: there was a distinct lack of use of established words from the general purpose automation discipline in any of these vendors writing. Many other terms were coined to cover existing automation techniques with previously established language. Obviously people wouldn't want someone to search up that their "Robot" is actually just another name for a "Virtual Machine" that runs scripts, because they might do some quick due diligence and find that they could do exactly the same task for literally a tenth of the cost or less with the right expertise available to them.
Despite being an automation professional who was delivering large amounts of value to people via automation I remember not hearing about the term "RPA" until maybe 5 years ago. The term RPA seemed to have been coined sometime after the year 2000. Since then a whole RPA branded vocabulary has emerged that frequently just renames concepts in automation that were commonly used in the industry and already had well defined meanings. This explains how I didn't come across it when searching for traditional automation search terms, the language is often deliberately different to the more general purpose approaches and techniques. But likewise people in the RPA space may not find the search keywords to expose themselves to traditional automation techniques, this is not an accident.
While automation and RPA are mostly dealing with exactly the same domain of work, relative to traditional automation the "RPA" branded things seem to put more focus on political and organizational issues than technical ones. RPA products often appeal directly to those whose main barriers are organizational structures which can't easily be changed to make general purpose automation tasks easier in those organizations.
RPA replacing traditional automation - an anecdote
As Repenning and Sterman so accurately commented on, process improvement is hard because it requires a lot of organizational will to change. This is perhaps the main issue for automation, so turning automation from something you do to something you buy has been a crucial marketing move. A story from a couple of years ago illustrates this.
In late 2018 a friend of mine was working at a large company that had a large logistics department, he went to a lot of effort to first understand then improve some of their processes around how freight interacted with warehousing. In particular the organization had a number of Excel sheets combined with a variety of ad-hoc processes to handle these tasks. He had identified ways to enable much more efficient movements of goods between warehouses which he wished to automate. Then a regulatory change occurred which their old process could not accommodate so this served as a catalyst to automate a few things to help maintain compliance and improve efficiency. He made some in house automation using high quality open source tools and this project had turned out to be a major success. Successful enough that his managers encouraged him to take this improvement company wide. The cost savings were too obvious to ignore so he got approval to make an internal app that would allow all the locations to take advantage of these savings and productivity improvements. There was just one catch, the IT department wouldn't actually allow anyone in the company to install the software for the app they made. People complained but the IT department wouldn't budge and as far as I know the IT department managed to fend off any requests to help resolve the issue. If this sounds absurd, its because it is.
Ultimately situations like this are a large part of why Excel is popular: people are actually allowed to use it at work. It's not the best tool for many jobs, but it is a feasible option in regressive organizations that won't enable their employees or even individual departments to decide on which software tools they need to do their jobs. In many enterprises it's very easy to get Excel files handed around between different staff and thus it forms a feasible option for people "to get stuff done™". Part of why this is possible is because this software is frequently installed on all the machines in the organization as part of the Standard Operating Environment (SOE) install as part of some company wide IT decision.
Fast forward a bit and the company got sold a RPA vendor product which was then installed as part of the SOE software on all the company computers. Importantly this sale happened at a high enough level in the organization where they could force the IT department to actually implement it and was sold for a large enough amount of money that not doing so would be a major embarrassment. Suddenly my friend was sent to some training course run by the vendor to learn more about the platform. This was so he could duplicate all the automation work that he had already successfully done with general purpose tools in another general purpose tool, but one now supplied by a vendor and a big contract behind it. He had questions like "how do we use version control with this?" which were "answered" with regressive suggestions like copying files as backups. Effectively the new RPA vendor product represented at the very least a decade of regression (or maybe two) from the state of the art in automation. And falling two decades behind the state of the art in software is just enormous. All of this was because the vendor tools (likely deliberately) don't interact well with existing tools in this space. The friction of these RPA products seems to be deliberate since a little bit of friction will prevent you from completely taking the automation for granted.
But being two decades behind the state of the art is a better situation than having a situation where nobody can do anything at all due to badly constructed IT policies and a lack of management will to deal with an IT department that's not aligned with the companies interests. And such was the devils bargain they faced, get an expensive vendor product or try to deal with a suboptimal organizational situation that's causing inter-departmental issues and preventing the possibility of a cheaper solution. I suspect in this specific case the best long term thing to do would be to restructure the IT department to allow the organization to be more productive. But that would involve a lot of expenditure of political capital and organizational willpower, sometimes it's just easier to capitulate and pay an external vendor than it is to fix your organizational issues.
What we had here was a classic case of a process and management problem that manifested in an automation project. The people involved were highly capable and had already proven that their automation worked via a trial. It was when the implementation of this automation across the company was attempted that the organizational issues preventing progress were exposed. Buying the RPA vendor product was perhaps a matter of expediency in quickly dealing with the regulatory changes since fixing the IT departments unwillingness to support business objectives might have taken too long.
In many cases RPA vendor offerings provide workarounds for self imposed constraints resulting from organizational politics rather than engineering constraints. The economics of this is important to consider since poor governance comes at a high cost, the cost of which becomes directly seen in situations like this. To be clear the option to spend money to avoid political issues is often valuable to many businesses, especially if the alternative was to not do any automation at all. For businesses that see themselves as not "being in tech" there is a strong tendency to try to get the benefits of technological advances without adopting the culture and organizational structures that will allow tech work to actually flourish in a natural manner. Effective use of general purpose free and open source automation tools requires certain management and organizational behaviors in order to be viable. Where these are lacking is where the expensive RPA vendors and automation consultants can provide a "solution" within these constraints or management consultants can propose "solutions" to the organizational level issues, both tend to be very expensive.
By offering procurement of a vendor product as a way to sidestep internal problems — while selling it as an off the shelf automation product — some RPA vendors have seen huge success from their re-branding of traditional automation work.
Sometimes automation is the main product in which different rules apply. This is entirely due to visibility, when automation is the product then automation becomes a visible feature in its own right. For example I am currently working on multiple supply chain and logistics automation products and the friction is far less because the automation is seen as a feature rather than an invisible cost. There's a very clear ROI on this sort of investment in whatever organizational form it takes, but selling it as a feature is so much easier that it borders on the absurd. ↩
This post is part 3 of the "AutomationAndRPA" series: