turning robotic process automation into commercial success ... · 1 turning robotic process...
TRANSCRIPT
1
Turning Robotic Process Automation into Commercial Success – Case OpusCapita
Aleksandre Asatiani & Esko Penttinen
Introduction
The offices of OpusCapita are located in Keilaniemi, a peaceful district in the Finnish city of Espoo,
offering spectacular views on Baltic Sea and nearby islands, especially during long, summer days. On
one of such August days, Mr. Petri Karjalainen, Senior Vice President responsible for Ventures unit at
OpusCapita, was standing in front of a window in his office, gazing at the horizon. It is this time of the
year when Finns are coming back from their vacations, refreshed and ready for new challenges at work.
A perfect time to kick-start something ambitious. Mr. Karjalainen has a very clear idea what that
“something” is.
Robotic Process Automation (RPA) is a cutting edge technology in the business process automation
game. Early adopters of RPA, in markets such as U.K., report encouraging results, automating their
back-office tasks (Lacity et al., 2015; Willcocks et al., 2015). OpusCapita saw the promise of RPA
early on, and successfully piloted and implemented it internally. Moreover, OpusCapita successfully
sold their software robots to some of their clients already. Implementations were progressing smoothly,
and even skeptical clients expressed their delight over RPA within weeks after robots were deployed.
Everything seemed to be set for success. OpusCapita’s vision of being one to “set the new standard for
financial processes” (OpusCapita Group, 2015a) was just around the corner. However, Mr. Karjalainen
was not celebrating, in fact he was concerned. It seemed as if by gazing at the sea, Mr. Karjalainen was
looking not for the beautiful scenery, but for answers. Amid early success of RPA, Mr. Karjalainen had
a problem at hand, a problem that could jeopardize all the RPA achievements of OpusCapita to date.
The problem is that, on the surface, RPA is so simple once it is deployed it is almost too simple.
Therefore, once client bought and implemented a software robot, which took just 2-4 weeks, there was
no business to be done after that. On the other hand looking at the market size for financial process
automation, merely selling robots did not seem to be sustainable in the long run. Therefore, questions
on Mr. Karjalainen’s mind were: How to sell RPA, to form long-term working relationships with
clients, rather than merely making one-time sales and consulting deals? What customer value can
OpusCapita provide in such relationship? What business model to choose for the technology? What
should be OpusCapita’s strategy to be the RPA market leader in the long run? With these questions in
mind Mr. Karjalainen turns to you, a management consultant, for guidance.
Case Company: OpusCapita
OpusCapita Group Ltd. is a company offering financial processes and outsourcing services, based in
Espoo, Finland (see Table 1). OpusCapita is the financial process automation spin off from Posti Group
2
Corporation, Finnish postal services and logistics provider. Formerly known as Itella Information, in
2013 the company changed its name to OpusCapita, the name borrowed from one of the OpusCapita’s
former acquisitions. Having been in business for over 30 years, OpusCapita initially concentrated on
document handling and invoicing, presently focuses on “comprehensive Purchase-to-Pay and Order-to-
Cash processes” (OpusCapita Group, 2015a). OpusCapita serves large companies and public
organizations helping them automate their financial processes, or taking over the processes completely
through outsourcing deals.
Table 1. Basic information on OpusCapita (Posti Group, 2014)
Basic Facts: OpusCapita
Owner Posti Group Corporation
Chief Executive Officer (as of 2015) Ossi Pohjola
Headquarters Espoo, Finland
Countries of operation Latvia, Lithuania, Norway, Poland, Sweden, Germany, Slovakia, Finland, Estonia
Number of employees 2300
Number of clients 11400
Revenue in 2014 (EUR million) 260
Goal statement ”Setting the new standard for financial processes”
OpusCapita has always tried to be ahead of the curve in financial process automation and outsourcing.
The company introduced electronic invoicing already in 1990s, and expanded their portfolio of services
to financial and payroll outsourcing in 2000s. Now the company is looking to be a standard-setter in
financial processes. The Ventures unit is one of the five main divisions in OpusCapita (see Figure 1).
The unit is responsible for keeping OpusCapita on the forefront of innovation. As technologies such as
cloud, artificial intelligence and robotics make strides towards commercial applications, the Ventures
unit is now focusing on RPA. OpusCapita wants to be the first-mover in comprehensive RPA of
financial services, in Finland and in Europe. The visionary Senior Vice President Petri Karjalainen is
determined to get OpusCapita there.
3
Figure 1. OpusCapita Group organizational chart
Robotic Process Automation
Robotic Process Automation or RPA is the technological replacement of human worker, goal of which
is to tackle structured tasks in fast and cost-efficient manner (Fung, 2014; Slaby, 2012). RPA is
implemented through a software robot, which mimics human worker using software such as ERP
systems or productivity tools. While a word robot may bring mental image of a human-like metal
machine, akin to C-3PO from Star Wars, RPA robots exist only as software installed on a computer.
RPA software earns a robot title based on its operating principle. RPA robot is integrated across IT
systems via front-end, as opposed to traditional software, which communicates with other IT systems
via back-end. In practice, this means that software robot uses IT systems exactly the same way a
human would, repeating precise steps, and reacting to the events on a computer screen, instead of
communicating with system’s Application Programming Interface (API).
While designing software to mimic humans to communicate to other software may sound counter-
intuitive, this approach has a number of advantages. First, it is possible to integrate RPA with virtually
any software used by a human worker, regardless of its openness to the third party applications. Many
corporate IT systems are proprietary with no public API’s, which greatly limits their ability to
communicate with any other systems. RPA solves this issue. Second, RPA can be implemented in a
very short timeframe. Two to four weeks implementation time is a blink of an eye in terms of
enterprise software integration, which can take months or even years. Third, processes automated via
software robots are easily modifiable, even by users of the system. Traditional software requires
advanced coding skills to make any major modifications in the way it operates. On the other hand,
software robots can be instructed through modifying relatively simple logical statements, screen
capture of the process performed by a human, or even modifying graphical process charts. This makes
RPA highly versatile and flexible.
CEO
Sales and Marketing
Order-to-Cash
Purchase-to-Pay
Finance and accounting outsourcing
Document Process
Outsourcing Ventures
Customer and Service Operations
M&A and Strategy
Finance and Admin HR Comms Legal
4
Pros and Cons of RPA for user organizations
Frequently, advocates of RPA present it as a replacement for outsourcing. A company is typically
looking to outsource routine, non-core tasks requiring a lot of FTEs (Full-time equivalent)1, such as
invoice processing, bookkeeping or data entry, to low-cost destinations such as India. While
outsourcing helps to reduce staff costs and concentrate on core operations, there are some challenges to
outsourcing such as hidden cost of management, communication problems and overwhelmingly
complex service level agreements. The promise of RPA is not only to reduce costs even further (robots
can work around the clock with no salary), but also to eliminate the problems with management and
miscommunication. According to Deloitte, RPA can cost equivalent to 0.1 of in-house FTE (Prangnell
and Wright, 2015).
As discussed previously, RPA does not require changing the existing IT systems, as robots mimic
human behavior. Thus, robots can operate fully within the graphical user interface (GUI), leaving IT
systems unchanged. This it a substantial advantage compared to automation achieved through back-end
integration, which frequently requires a significant redesign of existing systems.
Another potential benefit of RPA compared to offshore outsourcing could be avoiding a backlash
related to sending jobs abroad. RPA providers claim that people employed on routine tasks can be
moved to more productive jobs. Robotic automation itself can create jobs in managing robots,
consulting and analytics.
However, there are some downsides to RPA as well. First, while front-end integration brings flexibility
and speed at which it can be implemented, it is still inferior to back-end integration designed for
machine-to-machine communication. In the current state, RPA represents a temporary solution, which
fills the gap between manual processes based on legacy IT systems and redesigned processes running
on fully automated systems.
Second, in spite of the disadvantages associated with outsourcing, the practice has a proven track
record, backed up with a variety of business cases and decades of experience. RPA, on the other hand,
while highly promising, lacks same credentials. Therefore, potential clients of RPA need a persuasive
business case to overcome caution.
Another source of skepticism is the impact of RPA on current employees. While RPA post-
implementation feedback has been mostly positive and no significant job losses have been observed
due to RPA (Lacity and Willcocks, 2015), employees may still see robots as their direct competitors for
a job. This may create tensions between management and employees, even have a destructive impact
on employee morale. Therefore, introduction and deployment of RPA has to be handled delicately and
communicated properly.
And finally, currently RPA is suitable only for a particular type of processes that include only clearly
defined, rule-based tasks, devoid of subjective human judgment. Next we will explore the suitability of
a task for RPA.
1 Full-time equivalent is a measurement unit for a workload required for a task. One FTE equals to one employee working full-time on a task.
5
Task suitability for RPA
To assess the suitability of any given task to RPA, one should evaluate whether the task is routine or
non-routine and whether it requires the use of manual or cognitive affordances (see Figure 2). Highly
cognitive tasks requiring creative thinking, as well as non-routine tasks with no or little recurring
patterns and high variability are a bad fit for automation. The rule of thumb for task suitability for
automation is whether one can precisely write down all the steps of the process, taking into account all
possible events and outcomes along the way. While the advancements in Artificial Intelligence (AI)
enabled automation of some non-routine tasks, the general principle remains same.
Figure 2. Guide to automation potential of the task (adapted from Frey and Osborne (2013))
To determine whether a task is suitable for RPA, more factors need to be taken into consideration.
Table 2 presents the generic criteria for deciding whether a task is suitable for robotic automation.
Beyond the manual and routine nature of a task described previously, a company willing to take on
RPA needs to consider whether it is viable to replace humans with software robots for particular tasks
and what would be the long-term implications of such decisions. These criteria also guide strategic
decisions of RPA providers concerning commercialization and marketing of the technology.
Table 2. Criteria for Robotic Process Automation (based on Fung, (2014) and Slaby, (2012))
Criteria Description
High volume of transactions Task considered for RPA is performed frequently or includes high volume of sub-tasks.
Need to access multiple systems
Task involves accessing multiple systems. Example: copying data from a spreadsheet to a customer registry.
Stable environment
Task is executed within predefined set of IT systems that remain same every time a task is performed.
Low cognitive requirements Task does not require creativity, subjective judgment or complex interpretation skills.
Easy decomposition into unambiguous rules Task is easy to break down into simple,
6
straightforward, rule-based steps, with no space for ambiguity or misinterpretation. Example: Allocate all incoming invoices from Company X with value 3000€ or more to category Y.
Proneness to human error
Task is prone to human specific error, not occurring to computers. Example: Matching numbers across multiple columns.
Limited need for exception handling Task is highly standardized. Little or no exceptions occur while completing a task.
Clear understanding of the current manual costs
Company understands current cost structure of a task and is able to estimate difference in cost and calculate return on investment (ROI) of RPA.
RPA at OpusCapita
OpusCapita promotes software robots as virtual assistants for employees engaged in repetitive tasks
associated with financial processes2. According to OpusCapita’s vision after brief “training” these
virtual assistants will carry the burden of routine tasks, allowing companies to reallocate human
employees to more productive and creative tasks. Among other things, supervising and improving new
digital coworkers could be one of such tasks.
OpusCapita is leveraging its existing knowledge and experience in financial process automation and
outsourcing to establish itself as a credible RPA provider to potential clients. One of the main selling
points is a perfect fit between financial processes and robotic automation. According to Jaakko
Lehtinen, Manager in the OpusCapita’s Ventures unit, “The financial department is a perfectly suited
environment for robotic process automation (RPA), a new technology driving dramatic improvements
in the quality and efficiency of business processes in a number of areas at the moment” (OpusCapita
Group, 2015b).
Implementing RPA in client companies
Currently, OpusCapita takes a number of steps before actual implementation of RPA in the client
organization. While the overall idea of RPA is simple, OpusCapita devotes time to evaluation, analysis
and planning. These steps are required to successfully configure and deploy a robot, and to demonstrate
a clear business case to the skeptical clients. Figure 3 summarizes the stages of RPA introduction in the
client company.
Figure 3. Stages of RPA introduction in the company
During the first stage, OpusCapita consultants conduct a two-hour RPA workshop to understand
overall RPA potential within the future client organization. This includes reviewing of processes 2 https://www.youtube.com/watch?v=yZ8FouJc6ow
RPA potential analysis workshop
Process assessment
Business case
proposal RPA
implementation
7
currently performed by the organization, and pointing out potential areas eligible for RPA. OpusCapita
uses task suitability criteria similar to the ones outlined in the previous section.
In the second stage, OpusCapita assesses concrete processes and underlying tasks, with employees
currently performing these tasks. The goal here is to break down and map process into concrete rule-
based steps. OpusCapita consultants observe employees performing the task, record a process flow, and
note necessary tweaks in the process to make it more “robot friendly“. This stage usually takes
approximately 1 day.
In the third stage, OpusCapita produces a business case for the company based on the information
gathered. The business case outlines how robots will automate the process and how robotic and other
automation can be combined with existing human resources to achieve cost efficiency and enhanced
productivity.
If the client company approves the deal based on the business case, OpusCapita configures a software
robot to perform the processes in question and delivers the robot to the client. In order to guide
software robots through the task, OpusCapita experts create process libraries based on the process flow
recorded previously. Process library contains step-by-step instructions for robots to follow (see Table 3
for a simplified example of robot instructions). In practice, a process library resembles a complex
flowchart, with a multitude of decision points and branches. Once configuration is complete the robot
can be deployed to perform the tasks immediately.
Table 3. Simplified example of instructions for software robot operating across two systems.
Steps for software robots to complete
1. Pick first incomplete transaction from the work queue (the transactions in the queue could have been formulated e.g. by receiving triggers, by reading a specific report, by accessing a specific web portal etc.).
2. Launch application X. 3. Enter specific (fixed or variable) value into a specific field. 4. Click a specific button in an application. 5. Read value in a specific location in application X and store it in variable Z. 6. Launch application Y. 7. (…) 8. Enter variable Z into a specific field in application Y. 9. If an error message is shown, store result about error in a report and move to step 12.
Otherwise proceed to step 10. 10. (…) 11. Store result of a transaction in a report. 12. Pick next transaction and return to step 3.
Business models for RPA
Since the inception of RPA, Mr. Karjalainen and the team at OpusCapita have been discussing possible
business models for their RPA offering. From these discussions four major models have emerged: 1)
License reseller, 2) Value-added consultant and reseller, 3) Software-as-a-Service provider, and 4)
Outsourcing partner (see Table 4). All of the models, however, had some significant flaws, which
needed to be addressed, and Mr. Karjalainen was not fully convinced by any of the four. The search for
the perfect business model was also complicated by the fact that one would need to think not only
about the current state of the RPA market, but also envision developments in the near future. Being on
8
the cutting edge of process automation, developments in RPA business are rapid and turbulent. Thus it
was important to think strategically, in order to ensure OpusCapita’s market leadership in the future.
Table 4. Possible business models for RPA
Model Description Advantages Disadvantages
License reseller Sell licenses for RPA solutions, bundled with standard process libraries. Pay-per-license.
- Easy to enter the market early on.
- No special expertise related to RPA is required.
- No development, maintenance, or customization costs.
- No long-term business.
- Low profit margins. - Low threshold for
competition.
Value-added consultant/reseller
In addition to selling licenses for RPA solutions, offer implementation consulting and support. Pay-per-implementation.
- Provide unique value to the client.
- Competitive advantage through automation expertise.
- Cumulative knowledge base in the long term.
- Limited business opportunity after implementation is complete.
- Limited opportunity to innovate in process redesign.
- Limited control over software tools.
- Fairly low threshold for competition.
Software-as-a-Service (SaaS) provider
Build RPA SaaS, which will easily enable any company to use the service. Configuration of the service will be left up to the user. Provider will offer some ready-made process libraries. Pay-per-use.
- Control over the software.
- Mass-market appeal.
- Easy to scale. - Predictable income.
- Limited customer specific customization.
- Market scale is essential.
- Chance for price competition driving profit margins down.
RPA-enabled outsourcing partner
Offer onshore outsourcing to clients, with a promise to use RPA to complete majority of outsourced tasks. Outsourced processes are redesigned to fit robotic automation. Pay-per-process.
- Familiar model to clients.
- Easy to establish a business case.
- Long-term relationship with a client/lock-in effect.
- Full control over process automation.
- Ability to provide combination of human and virtual assistants to tackle outsourced processes.
- Accumulated intellectual property, such as process libraries, which can be used with future clients.
- Requires outsourcing expertise.
- Requires resources to manage outsourcing partnerships.
- Outsourcing deals can be a tough sell.
- Competition from outsourcing providers
9
License reseller is the most straightforward model of the four. Here, OpusCapita would resell licenses
for the third party software robots to their clients, profiting from commission fees. Ballpark price for
such robot is 3000-5000€, and the commission fees range from 10% to 20%. This model is the easiest
one to execute, as market entry barriers are low and so are the risks. The model requires no significant
investments into software development or building up RPA related expertise. However, this also opens
the door for potential competition. Profit margins for resellers are also small, and since no long-term
business relationships are developed with the client after the deal, OpusCapita needs to ensure a
constant stream of new customers.
Value-added consultant and reseller model resembles the current model of OpusCapita. Value-added
consultants aggregate the automation products into a coherent offering and guide clients through the
implementation process. The value-added consultant uses its RPA and process redesign expertise to
create value for a client. In comparison to a reseller, the value-added consultant has more space to
differentiate from its competitors. In addition, profit margins tend to be bigger. However, the
consultants’ business is limited to the initial implementation, and unlike big ERP projects, which could
take hundreds of billable hours to implement, RPA project takes only a few weeks. Furthermore, the
value-added consultants are limited to the RPA software’s capabilities maintained by a third party.
Compared to the reseller model, it is more difficult for competitors to enter the market; however, all in
all, threshold for competition is still low.
A SaaS provider licenses and delivers the software on subscription basis. In this model, a client pays
the provider for the right to use the software, which is centrally hosted by the provider. In this scenario,
OpusCapita would host, develop and maintain the software robots and sell licenses to all interested
parties. Generally, the SaaS provider model is the least personal, and designed to appeal to the mass
market. While the relationships between the provider and the client tend to be longer, the provider does
not customize the software for the client. Therefore, SaaS providers frequently compete on usability,
feature set and price, instead of value-added expertise. However, unlike “traditional“ self-service SaaS
(e.g. Dropbox), RPA would still require configuration and customization to a degree. Therefore, there
still would be an opportunity for OpusCapita to offer post-sale value-added services.
In the outsourcing partner model, OpusCapita would not expose its clients to RPA. Instead,
OpusCapita makes a regular outsourcing deal taking control over the outsourced processes from the
client. The difference here is that instead of moving process execution to low-cost countries, the
outsourcing provider employs locally hosted RPA. With this model OpusCapita would have the full
control over the processes and the robots, giving the company flexibility to rearrange processes and
share accumulated RPA experience and knowledge across different clients. Conceptually, this model is
the farthest from software business, which directly invades the outsourcing market, a space where
OpusCapita has experience. This model requires specific resources to setup and maintain outsourcing
arrangements. It also may be more difficult to stand out among all other outsourcing providers, since
for the customer the only proxy for RPA benefits would be the price.
10
Market opportunity
Another major issue Mr. Karjalainen and the Ventures unit have to consider is market segment. To
visualize the market for RPA, Mr. Karjalainen uses the famous Long Tail3 figure (see Figure 4).
According to this vision, the most lucrative market opportunity for OpusCapita lies between the head
of the market (with large companies having a full range of automation-ready tasks) and the long tail
(with mostly Small and medium sized enterprises (SME) having a handful of various tasks fit for
automation).
Figure 4. Current vision for market opportunity for Robotic Process Automation
Figure 4 presents these three market segments. The head of the market is out of scope for OpusCapita.
The assumption is that companies with large-scale automation potential have better business case for
implementing RPA independently, in-house. The sheer scale of the project would make it efficient to
develop RPA competence internally, cancelling out cost advantage effect from economies of scale that
third party providers usually have.
The long tail is also seen outside of OpusCapita’s opportunity zone. The assumption here is that SMEs
would concentrate on the software robots, not willing to pay for any additional services, due to
shortage of resources. Another reason is that companies in the long tail may not simply have enough
processes to automate, in order to make a compelling business case.
Therefore, Mr. Karjalainen is planning to capitalize on the middle of the market, a sweet spot, where
companies have just the right number of automatable processes to be persuaded to work with
OpusCapita. But what model would be best for this market? Are some models more fit for this market
than others? Could market opportunity lie elsewhere? Choices Mr. Karjalainen and the team have to
make are tough, with success of the whole venture on the line.
3 A term coined by Chris Anderson in 2004, which he explains in his book “the long tail.“
11
Challenge ahead
Back in Keilaniemi Mr. Karjalainen was already rushing to a meeting with the Ventures team. “There
is no time to lose. If we want to win this game we need to act soon” thought Mr. Karjalainen. Decisions
need to be made. What market should OpusCapita concentrate? How to approach commercialization
of RPA? How to align short- and long-term goals? A fresh, well informed advise from a professional
would help OpusCapita to make the difficult choices and get it right. Or at least that was what Mr.
Karjalainen hoped.
“Good afternoon ladies and gentlemen. It looks like everyone is here already. Let’s start our
meeting…“
Discussion Questions
1. Analyze the market opportunity for RPA. Discuss the assumptions made by OpusCapita; are
these assumptions correct? How would you validate them?
2. Should OpusCapita restrict themselves to financial processes or expand their RPA offering?
3. Should OpusCapita extend their offer to SMEs? Argue why or why not.
4. What business model or models should OpusCapita adopt for RPA? Build a compelling
argument for the alternative model(s). Take into consideration short- and long-term goals. Be
creative and critical; do not restrict yourself to the four models proposed by OpusCapita.
5. Prepare a plan of action for Mr. Karjalainen and the Ventures unit. How should your advice be
implemented? Describe concrete steps and build a compelling case. How would you test and
validate your choices?
References
Frey, C. and Osborne, M. (2013). The Future of Employment: How Susceptible are Jobs to
Computerisation? : 1–72.
Fung, H. P. (2014). Criteria, Use Cases and Effects of Information Technology Process Automation
(ITPA), Advances in Robotic and Automation 3(3): 1–11.
Lacity, M. and Willcocks, L. (2015). What Knowledge Workers Stand to Gain from Automation,
Harvard Business Review. Retrieved August 20, 2015, from https://hbr.org/2015/06/what-
knowledge-workers-stand-to-gain-from-automation
Lacity, M., Willcocks, L. and Craig, A. (2015). Robotic Process Automation at Telefónica O2, The
Outsourcing Unit Working Paper Series (April 2015): 1–19.
OpusCapita Group. (2015a). About us, Opuscapita.com. Retrieved August 31, 2015, from
http://www.opuscapita.com/who-we-are
12
OpusCapita Group. (2015b). Robotic Process Automation: Farewell to the remaining manual routines!,
OpusCapita Newsletter. Retrieved September 7, 2015, from http://www.opuscapita.com/blog-
and-newsletter/newsletter/2015/robotic-process-automation-farewell-to-the-remaining-manual-
routines!
Posti Group. (2014). OpusCapita Annual Review. Retrieved from
http://www.opuscapita.com/media/141315/opuscapita2014_en_final.pdf
Posti Group. (2015). Governance Model, Posti.com. Retrieved September 7, 2015, from
http://www.posti.com/postigroup/corporategovernance/governancemodel.html
Prangnell, N. and Wright, D. (2015). The robots are coming, A Deloitte Insight Report. Retrieved from
http://www2.deloitte.com/content/dam/Deloitte/uk/Documents/finance/deloitte-uk-finance-
robots-are-coming.pdf
Slaby, J. (2012). Robotic Automation Emerges As a Threat To Traditional Low-Cost Outsourcing, HfS
Research : 1–18.
Willcocks, L., Lacity, M. and Craig, A. (2015). Robotic Process Automation at Xchanging, The
Outsourcing Unit Working Paper Series (June 2015): 1–26.