What Does the Automation Status Quo Look Like?
A determining factor in the success or failure of companies is their propensity to falling trap to the status quo bias. Think for example of Blockbuster or Circuit City.
If your own company exhibits these traits (and you're accountable or responsible for automation's success), then you'll want to do everything within your purview to transform the business's weaknesses into strengths.
Internal or external IT resources know more about your business than you do
When no one within the business owns automation from a business perspective, that's a problem. Even if the IT providers continue to monitor systems as intended, the business is responsible for monitoring planned application changes, business process performance, and more.
In the event that a business owner leaves the company or department, and the hand-off of an automated process isn't seamless, that could result in IT knowing more about the process than the business. Such a state isn't ideal in the event that something breaks.
Without documentation, resolving issues requires digging up original requirement specifications, reviewing code line by line, and completing additional research just to get caught up to speed and determine how to proceed. Not to mention that if your IT partners are external consultants, then you're at threat for 'always needing consulting.' (Whittaker, n.d.).
Avoiding this situation from requires an investment into knowledge management in advance.
If you'd like to know more about specific documentation that is beneficial to produce and keep up-to-date in an automation program, please subscribe to this site's newsletter to be notified when an article is published on the topic.
Legacy systems which should be sunset are still maintained (and RPA is built on top of them)
If your company is maintaining legacy systems and not finding a healthy balance of when to shut them down, then it may suffer from the status quo bias.
RPA saves costs, but there are many scenarios in which implementing new platforms or upgrading your technology stack is the right answer. Simply relying on RPA to apply 'bandaids' to systems can be convenient, but it doesn't mean that it will always benefit the business in the long run.
If legacy systems stop being supported for example, there will be an immediate push to migrate to newer systems which will invalidate the entire RPA solutioning. Or at least, it will invalidate the investments made into automating the systems that were soon to arrive at their end-of-life.
Legacy systems also create a myriad of risks, including cyber risk. If your company has not quantified the opportunity cost of maintaining the current state, it would be best to do so. Jerry-rigging patches using RPA doesn't count as digital transformation and should be naturally avoided (The Risk of the Digital Status Quo, 2019).
The pitfalls of launching RPA in a culture that is adverse to change
Kim and Kankanhalli (2009) identified three categories of status quo biases within organizations:
- Rational decision making
- Cognitive misperception of loss aversion
- Psychological commitment
All of these biases are directly related to whether an RPA program will succeed. The researchers define rational decision-making as an assessment between the costs and the benefits of change which takes place in advance of transitioning to new solutions. If the cost is greater than the benefits to remain in the current state, and those involved choose to do nothing, then that is the definition of the status quo bias according to the researchers.
In RPA projects, the status quo bias may be at play when employees learn that a vendor is paid hundreds of thousands of dollars to build pilot automation. Should employees decide that their manual work isn't worth the automation investment, it'd sow distrust and could establish a status quo bias. Although the cost might become normalized after some time, and regardless of it being normal to spend more during the investment period, the negative employee perception could in itself manifest a failed initiative.
The cost of an RPA proof of concept could be seen as a transition cost, according to Kim and Kankanhalli. Permanent costs would be seen as the investment required to maintain an RPA program permanently. Should employees perceive a loss of employment as a threat, they'd once again determine that the ‘cost’ of the program isn't worth it to them. The risk that's seen by employees would be defined as the uncertainty cost, per my understanding of the 2009 status quo paper, which would be the result of anxiety of the future state that RPA may create when change isn't well managed.
For employees, Kim and Kankanhalli’s work indicate that even small losses may be seen as losses that are greater than seeming gains due to cognitive misperception.
An employee might see the loss of 2 hours a day of mundane work as the loss of time that they have available to eat their lunch and have a relative amount of psychological safety from colleagues or bosses that threaten their comfort. An individual in this situation could improperly, although understandably, attribute the loss of 2 mundane working hours as being a greater loss than having the opportunity to complete work that is more thought-provoking.
Expanding on cognitive misperception as a leading factor of the status quo bias, consider that 52 percent of employees who voluntarily left their company felt that their manager or leadership could have done something differently to keep them in their job (Wigert, 2019). Oddly enough, over 50% of global companies have difficulty addressing employee retention and 50% of employees leave within the first two years of employment (Wright & Adler, 2019). It’s almost as if business is a coin toss...
In two years half of employees will leave, half of which would have stayed if their manager or leadership acted differently. It's arguable that at least half of the failed RPA initiatives could be resolved if the same management gaps that result in employee attrition were addressed.
If the attrition rate is so poor and if attrition affects productivity, since according to Wright and Adler it takes up to two years before new hires are as productive as tenured employees, you'd think that companies would do something differently to challenge the 'norm.' Knowing these numbers, as employees know throughout the matter of their work and life, it’s easy to see how they might be resistant to RPA.
If a quarter of employees feel like their employers aren’t doing enough to satisfy their expectations, what expectation does leadership with a subpar culture have for projects that rely on subject matter experts to aid RPA business analysts and executives in automating parts of their jobs?
Finally, the other driver for status quo bias is psychological commitment, which is due in part to sunk cost, social norms, and the desire to feel in control (Status Quo Bias in Decision Making on JSTOR, n.d.).
Sunk cost regarding RPA includes prior investments made in streamlining enterprise processes. This includes process improvement workshops, training sessions, and more.
Social norms refer to the social perception of the change — for example, robots will take over the world (as seen in popular science-fiction movies). Social norms for RPA that are negative about robots would detract stakeholders from their commitment to RPA success.
It's a common desire to feel in control. Handing over process execution to a robot and technical analysts definitely checks the box for ‘not feeling in control.’
The paper written by Kim and Kankanhalli, goes on to identify that colleague opinion regarding change can reduce perceived switching costs and increase switching benefits. Organizational support for an RPA initiative may cover transition costs (implementation) but doesn't fully satisfy the sunk costs that employees may feel about abandoning preexisting work.
Even if manual work wasn't that exciting to employees, it's their training and pride in accomplishing that work which they factor into the mental calculus of comparing the benefits of automation versus 'just doing it.'
In a company that doesn’t suffer from status quo bias, the culture would support change well and not remain encumbered by the past. For companies where employees feel the equation of change is against them, change will be much harder.
Release today, patch tomorrow
In today's software world, it's easy for companies to enter a ‘release today, patch it tomorrow’ situation. Whether it's out of interest in building shiny new things to drive sales with clients, or whether it's a result of not properly managing interdependencies between complex technology, carrying technical debt is a huge detractor to digital transformation.
In waterfall projects there eventually comes a point where a system gets decommissioned or the deadline has long passed and there’s a requirement to move onto a new system regardless of potential issues. This is one way technical debt can emerge. In an Agile environment, other factors may result in bugs, defects, and technical gaps, but it's important that the standard for robots is much higher.
The reality is that bots shouldn’t go live with bugs. They should only go live when unknown exceptions are gracefully handled, and all other exceptions get logged as business exceptions.
Bots can be deployed in an incremental fashion, but there's no room for logic ‘gaps’ in their performance, especially given the downstream ramifications. Whereas a bug in a product may cause a customer's action of updating their profile's username to fail, a bug in an automated process may cause hundreds of insurance cases to be improperly closed or worse. Given the volume that unattended robots can handle, it's critical that any company's challenges around technical debt or quality does not carry over to RPA.
One manner to ensure that success is achieved is through proper Agile training, test-driven development, and the use of both Process Definition Documents as well as Solution Design Documents. The reason Agile training is helpful is because it ensures that the right habits and mindset is shared by the teams responsible for building robots. As for test-driven development, it hinges on the business analysts' comprehensive understanding of the requirements and ensures that the context of testing methods provides valuable insight into what truly differentiates a success from a failure (further driving the development quality up and simplifying the user acceptance testing phase).
Footnote:
The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'
References:
Kim, & Kankanhalli. (2009). Investigating User Resistance to Information Systems Implementation: A Status Quo Bias Perspective. MIS Quarterly, 33(3), 567. https://doi.org/10.2307/20650309
Status Quo Bias in Decision Making on JSTOR. (n.d.). https://www.jstor.org/stable/41760530
The Risk of the Digital Status Quo. (2019, October 17). Public Policy Forum. https://ppforum.ca/publications/digital-status-quo/
Whittaker, T. (n.d.). So, what does the status quo look like? https://blog.itsdelivers.com/productive-it-insights/so-what-does-the-status-quo-look-like
Wigert, B. S. M. A. B. (2019, March 13). This Fixable Problem Costs U.S. Businesses $1 Trillion. Gallup.com. https://www.gallup.com/workplace/247391/fixable-problem-costs-businesses-trillion.aspx
Wright, H., & Adler, F. (2019, February 15). Understanding Why Employees Leave: 10 Turnover Statistics You Need to Know. HR Partner. https://blog.hrpartner.io/understanding-why-employees-leave-10-turnover-statistics-you-need-to-know/
