Gone are the uninspired and terminal perceived benefits of deploying process automation technologies to business as a cost saver through sole FTE reduction. By now, most realise that the real benefits of, and savings from, process automation are elsewhere in the mix.
Digitalisation of business operations through automation brings direct and indirect cost savings among other benefits, and it also requires investment in and commitment to building new enterprise capabilities. The cost savings here are much more meaningful to a business than a contributor's paycheck. And the other benefits, largely over-sighted, are the actual contributors to adding heaps to your service relevancy, sustainability, and competitive advantage. The investments made are in business transformation, workforce development, and in acquiring and operating the right business technologies.
First, a successful business continuously and gradually transforms to meet the expected demands of its surrounding market environment.
Second, a successful business returns to its top-line the investments made in its workforce and is concerned in practically magnifying the effects of its workforce's actual performance to reach new levels (i.e augmenting) - rather than decreasing it (i.e. replacing).
Third, a successful business operates the right technology to meet its business users' and customers' demands for best in class service.
In any other cases or scenarios: that same business most likely has more pressing priorities to tend to as to achieve appropriate service sustainability and competitive ability in an always changing services market. Also alternatively, that same business has leaps to make as to achieve internal as-is efficiency. And lastly, that business must acknowledge that not adapting to and adopting the right new technology is the fastest route to becoming irrelevant in our modern services market.
Observers see how the drastic concept of automating-to-remove rather than automating-to-improve had originally found its way to and then tagged an emerging technology and industry. Now, before describing the real benefits of achieving Digital Process Operations, it is important to pinpoint the fallacies surrounding the automating-to-remove concept-tag. Here we address the fallacies themselves rather than the origins of this tag and its implications on industries.
The fallacy of Automation as a Zero-Sum Game
At the core of the automating-to-remove concept tag is the cognitive bias of zero-sum thinking.
Your interests, you lose. My interests, I win. That is zero-sum in a nutshell. And that is the logic behind the automating-to-remove concept. Automating processes to remove FTEs assumes that there can only be winners and losers, and underpins that the losses of the losers are aligned with the benefits of the winners in a constant-value universe.
While that is a seemingly perfectionist view, yet it is poker-naive and not the one with benefit to any given group or business. It is also an approach that is not sustainable. On the other hand you have the more realistic areas of overlapping interest, that is where the benefit is found and maximised for the same given group of businesses or a business.
When it comes to business operations automation, the non-zero-sum view is not only the viable choice, but it is also the key enabler of the prerequisites to achieving Digital Process Operations. In short, you may be able to automate-to-remove in a process, but that effectively hinders your chances of bringing the right contributors together in the triangle of digitalization. Meanwhile, automating-to-improve enables the three contributing sides of the same triangle. Yes, the three sided shape is simple enough to clarify the three major prerequisites of DigOps.
The fallacy of Automatic Automation
Deploying an automation successfully to operations is only possible after careful and sufficient process discovery, and after an artful build and configuration of a process solution, and after a consideration and adaptation of the transformed environment in which the automation is expected to operate.
The fallacy here is buying-with-expectation of instant deployment, or in expectation of a magic wand, while the truth is that there is no ready made process automation to deploy. In fact, all three time-to-value and cost and effort of process technologies have sharply decreased over the last two decades, but not completely vanished. The chances for an operational end to end ready-made bot matching your process needs are slim if not close to none. With that said, some RPA vendors provide useful components which can be part of an overall automation. Buying with expectation of achieving desirable results through commitment and investment is closer to what you're looking for.
This fallacy in automation being automatic is concerned with automating what it takes to automate in the first place. For example: both automated process discovery or record-to-deploy are quite ambitious. In fact, a tool to overcome the scarcity of competent process analysts, who are able to absorb what it takes to perform a process in a business at an automation suitable level is in demand by automation adopters. Although, an inherent limitation to developing such tools is that process discovery itself is not a repeatable structured process, and thinking that each and every business process can be discovered automatically to magically fit in operational contexts is fallacy.
In conclusion, even the currently most advanced, formalised, and applied form of automated process discovery, namely: process mining, does not remotely provide to aid the keystroke level, click-stream level, and atomic-action level requirements of robotic process automation. If process mining or record-to-deploy construct process models from key-click streams, then, automating as such could miss the entire business context of the process being automated. There isn't a way around it, the competencies for performing process automation cannot be automated just yet.
The fallacy of Deploying-to-Forget
At the outskirts of automating-to-remove is the illusion of the empty office. While effective in scaring your workforce away, if that's what you're looking for, yet it does not do much to assure the continued operations of your new transformed business.
Rather than configuring to deploy, operate, monitor, and maintain, some dream of configure, deploy, and forget. But, in more traditional business terms, do you expect to design a business operation, bring it to action, and forget about it? Probably not. A manual traditional business operation can be compared to a new automated business operation in that both are results-focused and value-oriented. These two contrasted models, and the different levels of automation in between, carry differences in how they are operated.
Similar to traditional business processes, automated and semi-automated ones still require the post-deployment effort, but in new terms. An automated or semi-automated process is enhanced by the automation system, it behaves and responds differently to environment changes, and requires a different and more lightweight set of post-deployment operating activities. Hence: transformation, not magic.
The fallacies from Positioning
These are quite messy. As with any early adoption curve, there are always questions asked. Some of these questions require serious thought before enacting in a business, while others are quite entertaining.
What is this? is it business? is it IT? is it software development? is it Agile? is it operations doing their own IT thing? is it allowed? is my department going to disappear? what if we get hacked? are the robots taking over? what if a robot misbehaves? will we have robot managers? isn't our IT already automating things? is my new robot also on the payroll? does the bot have a name? but you see, our HR needs the birth date of the software, does the bot have a birth certificate? And, we have already automated this a long time ago.
Do I say more? It is none of the above. For starters, see build a lean RPA practice, and add RPA to your BPM practice. There isn't much traditional nor groundbreaking about building and operating a digital workforce other than what is found in business and technology common sense and business process management. Look no further. Keep it simple.
The Real Benefits of Digital Process Operations
Now, having -possibly- cleared some of the thorny fallacies related to automating-to-remove, it's time to touch upon the real benefits of automating-to-improve. Keeping in mind that RPA is currently the most suitable starting point for bringing your business closer to the more intelligent future of Digital Process Operations.
GDPR compliance is expected to cost members of Fortune 500 a combined $7.8bn, or about $16m each .
Entry into force and application by 25 May 2018 requires various business changes to be made and numerous new business processes to be enacted. The legally required changes to your business operations may be first approached by appointing a Data Protection Officer (designation, position, and tasks in articles 37, 38,39).
From there, the changes get more technical and require, for example, your Master Data Management operations to adopt data minimisation practices and to design and implement pseudonymisation by means of encryption or tokenization.
Beyond governance, policy change, and technical requirements there is a new set of business processes which need to be designed and enacted. Resolving to manually enact comes with a price which could be dramatically reduced by automating as much as possible of these processes. Additionally, GDPR comes with some defined time-frames for performing specific actions, realising these time-bounded actions automatically is your best bet to remain compliant and avoid large fines.
We identified a number of GDPR activities and processes which are subject to a high-degree of BPM/RPA automation, here's a non-exhaustive list of these to watch out for:
The cost of compliance to GDPR is less than the cost of non-compliance , this is considering the fines up to 10,000,000 EUR or 2% of annual worldwide turnover and 20,000,000 EUR or 4% of annual worldwide turnover. The true cost of GDPR compliance can be made far less than the cost of non-compliance by adopting process automation for the newly arising processes.
Prime Automation offers GDPR compliance robots for your business systems landscape. Are you interested to know how we can reduce the bill of your GDPR compliance? Contact us for a conversation.
Chances are that you have heard about RPA. You have possibly read some of the hype and maybe some disillusionment. You may have also read about the stumbling bots and how to position RPA in your organisation.
Fantastic. If you have an existing BPM practice and would like to add RPA capability, then first proceed to this bit.
Great. So you don't have a BPM practice but you are really interested in getting things done with RPA, this is for you.
Here are 10 steps to get you up and running. This is what you really need to get things pragmatically started.
We recommend setting a short time-frame to having these items first realised. Here they are:
Download the PDF resource on Building a Lean RPA practice.
You have an existing BPM Practice. Wonderful. More than half the job could be done for you. This article may bring you to terms with the second half and the newer bits.
Does RPA fit with BPM?
Yes. RPA is another form of Business Process Automation. BPA is the cherry at the top of the BPM life-cycle.
In the BPM space some of us have been doing BPA; particularly at the business process layer. Actually, this is the main paradigm for BPMSs' which translate graphical process models to workflow rules which in turn orchestrate application user interfaces. Aha!
In really simple terms, that was BPM at the business process layer. The end result of which is either back-end process integration or human-centric process applications with normal front-end user interfaces.
With time, particularly the WS-* flavor of SOA has moved from an early unified business process layer to building smaller services to address particular concerns at and within the same BP layer. Yet, that same flavor, even with microservices, never really came to realise presentation layer integration. Oops!
After some more time, RPA arrived with some good tools particularly suited for presentation layer integration. Yet, because RPA emerged from outside the traditional BPM space, it hadn't really come to terms with the microservices bit within its own accord.
So, what does that really mean?
Oh well, the following is what that divide does to the overall BPM/RPA landscape:
Here are 4 things you need to bring your BPM practice to terms with RPA. This is what you really need to achieve to bring things together. We recommend setting a short time-frame to having these items first realised. Here they are:
Download the PDF resource on adding RPA to BPM practice.
Various prominent technology analysts and publishers speak of Robotic Process Automation a completely new 'thing', 'trend', or 'wave'. The thing is: RPA truly is a methodology breakthrough in Business Process Automation. Let's consider that for a minute.
This RPA breakthrough is not particularly arising from a new core technology, but from a group of collaborating technologies that are emerging in a robust and enterprise-grade set of vendor supplied systems. Yes, think UI Macro Recorders and Screen Scrapers combined with workflow engines. Then magic happens.
In case you wanted to look more closely into the haystack, you might spot other core integrated technologies, for example: Business Process Execution Language (Oasis WSBPEL), and Microsoft Worflow Engine or simply Microsoft Flow. It is truly fascinating to witness the emergence of RPA as a result of industry and academic research innovations.
With RPA, other previously peripheral technologies such as Optical Character Recognition (OCR) and Image Recognition (IR) seem to have found their way to the BPM space. With this, OCR/IR are two examples from the plethora of artificially intelligent functions foreseen at the third generation of RPA. That makes part of the transition to more Intelligent Process Automation.
Naturally, RPA is rooted in Business Process Management as a practice, and positioned as a new -additional- approach to performing business process automation.
So, what was process automation before RPA?
.Well, traditionally speaking, other than most IT systems being automation engines themselves. BPA at that time was kept for the few enterprises that have reached a top-tier maturity in their business process landscape. Simply because achieving process automation required an existing base of streamlined automation-ready business processes, in real terms, that meant having modelled business processes running in a workflow engine. Many have just never reached that level of business process maturity, or did not want to spend the considerable budgets and time associated with entering the BPM/A space.
Historically, the 1990s largely built on the holistic approaches of the 80s like Total Quality Management and therefore brought mammoth-like enterprise BPM systems such as early IBM BPM and similarly early Oracle BPM. Interestingly, the same era has brought some of the most prominent mammoth legacy systems we face today - the ERP. Reality is, that era was notorious for BPM, largely due to long-running BPM initiatives with big budgets and less than expected business benefits.
Moving along to the 2000s, a time of what could be described as model-orchestrated process automation platforms such as Pega BPM, TIBCO BPM, Bizagi, Camunda BPM, Bonita BPM... etc. It may be fair to think that BPM of the 2000s had recovered from some of the notoriety it had gained in the 1990s. Yet BPM growth at that period suggests that some damage was never recovered.
Surviving the 2000s as a 'BPM software' company had to be considered lucky. It was a time where no major technological breakthroughs had occurred for some time. It was also a time taken for agreement and standardisation, considering the amount of BPM notations and standards which have emerged then.
Negative press on BPM was climbing once again to the peak. Business interest in BPM was somewhat eroding. Between 2004 and 2011 the search term Business Process Management had lost 69% of its global search points on Google Trends.
Having that in mind, one may attribute the BPM technology developed at that time to the to the re-transformed domain of Rapid Application Development (RAD) with the likes of Appian, Mendix, Outsystems, Betty Blocks... Particularly, the BPM focus on rapidly and graphically producing process applications with low code, accompanied with the shift from big-bang waterfalls to agile methodologies had fuelled the foundations of new RAD platforms.
This transition period was a true gamble; and somewhat dependant on a fundamental change to the industry landscape.
It’s January 2015 and Robotic Process Automation is practically unheard off. Fast forward through 2016-17 and the RPA market is forecasted to reach $2.9 Billion by 2021 (Forrester), a slightly reserved number in comparison to other sources.
Meanwhile, on the sell side, the largest RPA software providers are entering late rounds of $30-40 Million funding bringing in somewhere from $70-100 Million each. At least 20 considerable new RPA technology providers have emerged in 2016-17, effectively doubling the overall market landscape. Put all the investments made together with the racing RPA providers and think how this cash is put in a market segment which was mostly non-existent a couple of years earlier. Having reached unicorn valuation by early 2018, the story of UiPath reflects the level of success in this industry.
On the buy-side, the prevailing thought of the first large enterprise adopters was mostly like "This RPA thing seems to be taking off. Maybe we should get someone in to pilot with an 'easy process' and see for ourselves". RPA technology and concepts were proven, and there are several successes in enterprise adoption. Yet, this is the time to scale. Some might think to expand their proofs of concepts to more processes, but what does it really take to scale RPA successfully?
Is this a 'just scale it' paradigm?
The Paradigm Shifts
There are two big paradigm shifts in the RPA space. One is introduced by RPA itself, and another stems from the capability of adopters to position and administer RPA in their businesses.
The first is a shift in the outcomes of performing process automation. Previous BPA was effectively producing more interfaces to be maintained by enterprise users (i.e. it was increasing resource intensiveness). On the other hand: RPA is pragmatically automating existing interfaces and taking the burden of maintaining them. With this shift, RPA is suited for automating the iceberg portfolio of legacy applications, and with that, decreasing resource intensiveness.
The second shift was evident during the 2017 obstacles to scaling RPA in businesses. Yes, it was late-2017 and RPA was stumbling (McKinsey). Some suggested an adoption rate of just 4%. Several robotics programs were put on hold, or CIOs have flatly refused to install new bots (McKinsey). This shift is seen in the position of initial adoption; and later in scaled adoption, and subsequently in the operation of scaled RPA in business.
It is useful to consider this shift from the perspective of the simplistic business-IT spectrum. As such, many of the existing BPM practices began with IT and then transitioned to the intersections of business and IT. However, RPA is first starting with the business side of the spectrum. This shift ushers a variant set of challenges at each stage of the adoption. In fact, where this adoption begins or "mushrooms" in the organisation is as important as how to manage it, scale it, and then achieve the enterprise capability of Digital Process Operations.
The Success of Scaled RPA
Many enterprises are already pursuing RPA programmes at organisation scale. Additionally, Free RPA tools and training resources are available, the use of these tools by employees is showing what could be signs of a more natural digital transformation. As employees are looking to free their time from their most daunting ‘robotic’ activities.
Either way, with an RPA programme or with a more natural adoption, the success of RPA at scale depends on achieving the second of the paradigm shifts in a way suited for each business organisation respectively. There isn’t a one size fits all when it comes to building a digital future of a business, but there is a slow and bumpy transformation towards that future.
Positioning RPA in its right place in the enterprise, within a larger BPM practice, as an additional means to automating business processes could be key to this success, and may smooth the bumpy way to achieve the goal of a more digitalized business.
I'd suggest starting with building a Lean RPA Practice or adding Adding RPA to your existing BPM practice.
An earlier version of this article is published on the Process Excellence Network - PEX.
Super magical technologies are swiftly operating our businesses seamlessly. Intelligent agents are autonomously performing the workloads of thousands at a fraction of the costs and a fragment of the time. Insights are mined from live operational data streams at a glimpse. And our enterprises' agility is being fuelled and mastered by fast substantial and particular decisions. That's one story.
Widespread doom and dismay. Disruptive levels of change to the workplace. Loss of core business know-how. Security threats. Data loss. Unauthorised robot access and control. Exacerbated operational inefficiencies. And robots taking over. In short, That's another story.
Fact is, if you're keeping up with the latest and greatest in robotic process wizardry, you might as well consider all the above as true and, if not here yet, then just around the corner from where we stand.
The first story is somewhat true. RPA is phenomenal in what it brings to the enterprise. And yes, as with any technology of this substance, RPA ushers benefits to be realised and efficiencies to be achieved. Software robots simply report a level of detail which, at scale, amounts to a live operating data stream. Now, what businesses learn and achieve with this new insight is entirely another story.
The second story is also somewhat true. RPA raises new risks to be mitigated. At the technology level security threats to RPA may include unwarranted access to, change, or enaction of robotized business processes. While robots taking over remains a favourite for some, yet in reality is possibly just far fetched. At the business operating level, the risk of excarberating inefficiencies by automating them is very likely to be taking place just as you read this bit.
Furthermore, considering that RPA brushes upon a traditionally large OPEX (i.e. manual office work) with direct digitisation, it does have the potential of becoming a game changer for the respective industries. We'll have to be patient to see this effect coming to practice.
The State of RPA
Meanwhile, some pioneer adopters have proven their initial concepts. Reaped some early benefits. Developed their RPA strategies. And are progressing towards building their organisational capabilities for robotic process automation. While, other adopters may be running into what can be considered traditional hurdles to adopting Business Process Management (BPM) technologies, or any new phenomenal technologies for that matter. As RPA moves to the Trough, my guess would be that part of a second wave of adopters will somehow delve into a considerable amount of re-inventing the wheel and re-proving the same concepts, before reaching the state of readiness to build their organisational RPA capabilities.