turning robotic process automation into commercial success ... · 1 turning robotic process...

12
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

Upload: hanga

Post on 13-May-2018

257 views

Category:

Documents


6 download

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.