TURNING ROBOTIC PROCESS AUTOMATION INTO

COMMERCIAL SUCCESS – CASE OPUSCAPITA

Teaching case

PREPRINT

Cite as: Asatiani, A., & Penttinen, E. (2016). Turning robotic process automation into commercial
success–Case OpusCapita. Journal of Information Technology Teaching Cases, 6(2), 67-74.

Aleksandre Asatiani & Esko Penttinen

ABSTRACT
OpusCapita Group is a Finnish company offering financial processes and outsourcing services to
medium-sized companies and large corporations. OpusCapita particularly focuses on comprehensive
Purchase-to-Pay and Order-to-Cash processes. In hopes to stay ahead of the curve in financial process
automation, OpusCapita is betting on Robotic Process Automation (RPA). This teaching case presents
challenges faced by Mr. Petri Karjalainen, Senior Vice President at OpusCapita Group, who is looking
for ways to introduce RPA to the market, and provide added value to new and existing customers.

Keywords: Robotic process automation, outsourcing, business model, financial administration,

strategy, teaching case.

1
INTRODUCTION

The offices of OpusCapita are located in Keilaniemi, a peaceful district in the Finnish city of Espoo,

offering spectacular views on the Baltic Sea and the nearby islands, especially during long, summer

days. On one of such August days, Mr. Petri Karjalainen, Senior Vice President responsible for the

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 the U.K. report encouraging results automating their

back-office tasks (Lacity and Willcocks, 2016; Willcocks et al., 2015). OpusCapita saw the promise of

RPA early on, and successfully piloted and implemented software robots internally. Moreover,

OpusCapita successfully deployed their software robots with a number of clients. 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 the 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 simplicity and self-sufficiency of RPA compared to traditional

back-end integration process. Therefore, once a client bought and implemented a software robot, which

takes just 2-4 weeks, there is no business to be done after that. By implementing RPA clients are

looking for self-sufficiency and independence from external parties. 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: What business model to choose for the

technology? What should be OpusCapita’s strategy to ensure RPA market leadership in the long run?

What customer value can OpusCapita provide to their customers in the long run? With these questions

in mind, Mr. Karjalainen turns to you, a management consultant, for guidance.

2
CASE COMPANY: OPUSCAPITA

OpusCapita Group Ltd. is a company offering financial processes and outsourcing services, based in

Espoo, Finland (see Appendix Exhibit 1). OpusCapita is the financial process automation spin off from

the Posti Group Corporation, a 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.

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 Appendix

Exhibit 2). 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 build on this trend and

be a competitive player in offering comprehensive RPA of financial services, in Finland and in Europe.

The visionary Senior Vice President Petri Karjalainen is determined to ensure OpusCapita has a

prominent position in the RPA market.

ROBOTIC PROCESS AUTOMATION

Robotic Process Automation or RPA is the technological imitation of a human worker, the goal of

which is to tackle structured tasks in a 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 produce a 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 the term robot based on its operating principle. An RPA robot is integrated across

IT systems via front-end, as opposed to traditional software, which communicates with other IT

3
systems via back-end. In practice, this means that the software robot uses IT systems exactly the same

way a human would, repeating precise, rule-based steps, and reacting to the events on a computer

screen, instead of communicating with system’s Application Programming Interface (API).

While designing software, which communicates to other software by mimicking human behavior, 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 third party

integration. 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. Implementation time of two to four weeks is a blink of an eye

compared to enterprise software integration, which can take months or even years. Third, processes

automated via software robots are easily modifiable, even by the users of the system. Traditional

software requires advanced coding skills to make any major modifications to 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.1

Pros and Cons of RPA for user organizations

Advocates of RPA frequently 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)2, 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. However, estimates of RPA-related cost-savings vary greatly. A typical software

robot can cost an equivalent of 0.1 (Prangnell and Wright, 2015) to 0.19 (Slaby, 2012) of an in-house

FTE, and 0.33 (Willcocks et al., 2015) to 0.5 (Institute for Robotic Process Automation, 2015; Slaby,

2012) of an offshore FTE.

1
To read more on automation and RPA, we refer the reader to a list of suggested reading at the end of this
teaching case.
2
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.

4
As discussed previously, RPA does not require changing the existing IT systems, as robots mimic

human behavior. Thus, robots can operate fully within the user interface (UI), leaving IT systems

unchanged. This it a substantial advantage compared to automation achieved through back-end

integration, which frequently requires a significant redesign of the existing systems.

Another potential benefit of RPA compared to offshore outsourcing could be avoiding the backlash

related to sending jobs abroad. RPA providers claim that people employed on routine tasks can be

moved to more productive jobs. In the long run, robotic automation itself could create jobs in robot

management, consulting and sophisticated data 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 of outsourcing 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 similar credentials. Therefore, potential clients of RPA need

a persuasive business case to overcome caution.

A third source of skepticism is the impact of RPA on current employees. While the 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, any 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.

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 1). 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 to determine 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 1. 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 1 presents the generic criteria for deciding whether a task is suitable for RPA. 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 inform strategic decisions of

RPA providers concerning commercialization and marketing of the technology.

6
Table 1. Criteria for Robotic Process Automation (based on Fung, (2014) and Slaby, (2012))

Criteria Description

Task considered for RPA is performed frequently

High volume of transactions or includes high volume of sub-tasks.

Task involves accessing multiple systems.

Example: copying data from a spreadsheet to a
Need to access multiple systems customer registry.

Task is executed within predefined set of IT

systems that remain same every time a task is
Stable environment performed.

Task does not require creativity, subjective

Low cognitive requirements judgment or complex interpretation skills.

Task is easy to break down into simple,

straightforward, rule-based steps, with no space
for ambiguity or misinterpretation. Example:
Allocate all incoming invoices from Company X
Easy decomposition into unambiguous rules with value 3000€ or more to category Y.

Task is prone to human specific error, not

occurring to computers. Example: matching
Proneness to human error numbers across multiple columns.

Task is highly standardized. Little or no exceptions

Limited need for exception handling occur while completing a task.

Company understands current cost structure of a

Clear understanding of the current manual task and is able to estimate difference in cost and
costs 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 processes3. According to OpusCapita’s vision, after a brief “training” these

virtual assistants will be able to 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 their potential clients. One of the main

selling points is the perfect fit of financial processes to robotic automation. According to Jaakko

Lehtinen, a 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

3
OpusCapita Software Robots https://www.youtube.com/watch?v=yZ8FouJc6ow

7
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 the actual implementation of RPA in a 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 2 summarizes the main phases of RPA introduction

in the client company.

Business
RPA potential analysis Process case RPA
workshop assessment implementation
proposal

Figure 2. Stages of RPA introduction in the company

During the first stage, OpusCapita consultants conduct a two-hour RPA workshop to understand the

overall RPA potential within the prospective client organization. This includes reviewing of the

processes currently performed by the organization, and identifying of potential areas eligible for RPA.

OpusCapita uses a set of task suitability criteria similar to the ones outlined in the previous section.

In the second stage, OpusCapita assesses the processes and the underlying tasks with the employees

currently performing these tasks. The goal here is to break down and map the process into concrete

rule-based steps. The OpusCapita consultants observe employees performing the task, record a process

flow, and note some necessary tweaks in the process to make it more “robot friendly“. This stage

usually takes approximately one day.

In the third stage, OpusCapita produces a business case for the company based on the information

gathered. The business case outlines how the robots will automate the process and how robotic and

other automation can be combined with the 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 the

software robots through the task, OpusCapita experts create process libraries based on the process flow

8
recorded previously. The process library contains step-by-step instructions for robots to follow (see

Exhibit 3 in Appendix for a simplified example of robot instructions). In practice, the process library

resembles a complex flowchart, with a multitude of decision points and branches. Once the

configuration is complete, the robot can be deployed to perform the tasks immediately.

Business models for RPA

Since the inception of RPA, Mr. Karjalainen and his 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 2). 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

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.

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. A ballpark price for

such a robot is 3000-5000€, and the commission fees range from 10% to 20%. This model is the easiest

one to execute, as the 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

model 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.

9
Table 2. Possible business models for RPA

Advantages for Disadvantages for

Model Description OpusCapita OpusCapita

License reseller Sell licenses for RPA - Easy to enter the - No long-term
solutions, bundled with market early on. business.
standard process - No special expertise - Low profit margins.
libraries. Pay-per- related to RPA is - Low threshold for
license. required. competition.
- No development,
maintenance, or
customization costs.

Value-added In addition to selling - Provide unique - Limited business

consultant/reseller licenses for RPA value to the client. opportunity after
solutions, offer - Competitive implementation is
implementation advantage through complete.
consultation and automation - Limited opportunity
support. Pay-per- expertise. to innovate in
implementation. - Cumulative process redesign.
knowledge base in - Limited control over
the long term. software tools.
- Fairly low threshold
for competition.

Software-as-a-Service Build RPA SaaS, which
(SaaS) provider 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 - Limited customer
software. specific
- Mass-market customization.
appeal. - Market scale is
- Easy to scale. essential.
- Predictable income. - Chance for price
competition driving
profit margins down.

RPA-enabled Offer onshore - Familiar model to - Requires

outsourcing partner outsourcing to clients, clients. outsourcing
with a promise to use - Easy to establish a expertise.
RPA to complete business case. - Requires resources
majority of outsourced - Long-term to manage
tasks. Outsourced relationship with a outsourcing
processes are client/lock-in effect. partnerships.
redesigned to fit robotic - Full control over - Outsourcing deals
automation. Pay-per- process automation. can be a tough sell.
process. - Ability to provide - Competition from
combination of outsourcing
human and virtual providers
assistants to tackle
outsourced
processes.
- Accumulated
intellectual property,
such as process
libraries, which can
be used with future
clients.

10
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 RPA and process redesign expertise to create

value for a client. In comparison to the reseller model, the value-added consultant has more space to

differentiate from competitors. As a result, 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. In addition, there is a

potential problem with scaling up the business rapidly. OpusCapita has a limited number of consultants

and training new ones takes time. This might become a bottleneck if OpusCapita’s RPA business starts

to grow fast. 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, the 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,

features 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

would still 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 would make 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,

OpusCapita employs a 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. Instead of delivering RPA to client companies through IT-projects

(delivering a software robot), in the outsourcing partner model, OpusCapita would focus on enticing

their client companies to make outsourcing contracts with OpusCapita. OpusCapita has rich experience

11
and a set of competences in the outsourcing field, which they can leverage in this model. The

outsourcing model requires specific resources to setup and maintain outsourcing arrangements.

However, it 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.

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 Tail 4 figure (see Figure 3).

According to this vision, the most lucrative market opportunity for OpusCapita lies between the head

of the market and the long tail. In this case, the head of the market refers to processes, which contain a

large number of tasks suitable for automation (based on the characteristics given in Table 1). The long

tail, on the other hand, consists of processes where there is only a limited number of tasks suitable for

automation. The market opportunity for RPA then lies in between these two extremes. The reasoning

for this is that while the head of the market would be very lucrative for RPA, a very competitive market

of back-end integration specialists and consultants already serves it. Back-end integration here means

that companies opt to modify their back-end systems in order to automate the process in question,

instead of using software robots that function on front end. This choice of relying on back-end

integration, in turn, is driven by the fact that there exist large number of repetitive manual tasks to

warrant a large back-end integration IT project. Also, the large-scale automation potential would

suggest that the client might be better off implementing RPA independently, in-house. The sheer scale

of the project would make it efficient to develop RPA competences internally, cancelling out the cost

advantage effect from economies of scale that third party providers usually have. On the other hand,

the long tail is problematic for RPA due to the fact that it is difficult to automate with RPA.

Implementing RPA into a process situated at the long tail would be too costly and the resulting benefits

limited. In other words, the processes in the long tail may not simply have enough tasks to automate, in

order to make a compelling business case. Figure 3 illustrates the head of the market and the long tail.

4
A term coined by Chris Anderson in 2004, which he explains in his book “the long tail.“

12
Figure 3. Current vision for market opportunity for Robotic Process Automation

While there is some positive correlation between the size of a company and the number of tasks, this is

not always the case. A small company with labor-intensive routine tasks is more likely to be

OpusCapita’s client than a large multi-national with only few tasks fit for automation.

Therefore, Mr. Karjalainen is planning to capitalize on the middle of the market, a sweet spot, where

the processes have just the right number of automatable tasks to be persuaded to work with

OpusCapita. But what model would be the best for this market? Are some models a better fit for this

market than others? Could market opportunity lie elsewhere? Choices Mr. Karjalainen and the team

have to make are tough, with the success of the whole venture on the line.

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

needed to be made. What market should OpusCapita concentrate on? How to approach

commercialization of RPA? How to align short- and long-term goals? Original, well informed advice

from a professional would help OpusCapita to make the difficult choices and get it right. Or at least

that was what Mr. Karjalainen hoped.

13
“Good afternoon ladies and gentlemen. It looks like everyone is here already. Let’s start our

meeting…“

DISCUSSION QUESTIONS

Your task is to build a compelling recommendation to Mr. Karjalainen. To get you started, consider the
following discussion questions:

1. Analyze the current market OpusCapita is operating in. How has market situation changed

from the one described in the case? Create a SWOT analysis of OpusCapita’s competitive

positioning.

2. Analyze the market opportunity for RPA. Discuss the assumptions made by OpusCapita; are

these assumptions correct? How would you validate them?

a. Should OpusCapita restrict themselves to financial processes or expand their RPA

offering?

b. Should OpusCapita extend their offer to long tail of the market? Argue why or why

not.

3. 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.

4. 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?

14
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.

Institute for Robotic Process Automation. (2015). Introduction To Robotic Process Automation.

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. and Willcocks, L. (2016). Robotic Process Automation at Telefónica O2, MIS Quarterly

Executive 15(1): 21–35.

OpusCapita Group. (2015a). About us, Opuscapita.com. Retrieved August 31, 2015, from

http://www.opuscapita.com/who-we-are

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

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.

15
RECOMMENDED ADDITIONAL READING
Brynjolfsson, E., and McAfee, A. The second machine age: work, progress, and prosperity in a time of

brilliant technologies. WW Norton & Company, 2014.

Carr, N. (2014). The glass cage: automation and us. WW Norton & Company.

Chui, M., Manyika, J., & Miremadi, M. (2015) Four Fundamentals of Workplace Automation.

McKinsey Quarterly, November 2015. Retrieved April 7, 2016 from

http://www.mckinsey.com/business-functions/business-technology/our-insights/four-

fundamentals-of-workplace-automation

Etzioni, O. (1996). Moving up the information food chain: deploying softbot on the World Wide Web,

Proceedings of the 13th National Conference on Artificial Intelligence (AAAI-96) : 4 – 8.

Frey, C. and Osborne, M. (2015). Technology at work. The Future of Innovation and Employment, Citi

GPS: Global Perspectives & Solutions.

Institute for Robotic Process Automation. (2015). Introduction To Robotic Process Automation.

Lacity, M., & Willcocks, L. (2015). Robotic Process Automation: The Next Transformation Lever for

Shared Services. The Outsourcing Unit Working Paper Series (July 2015): 1-35.

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

Salovaara, A., Lyytinen, K. & Penttinen, E. (2015) Flexibility vs. Structure: How to Manage Reliably

Continiuously Emerging Threats in Malware Protection, Hawaii International Conference on

System Sciences (HICSS), Hawaii, USA, January 5-8, 2015.

Willcocks, L. and Lacity, M. (2016). Service Automation: Robots and the Future of Work, United

Kingdom: Steve Brookes Publishing.

Willcocks, L. P., Lacity, M., & Craig, A. (2015). The IT function and robotic process automation. The

Outsourcing Unit Working Paper Series (May 2015): 1-39.

16
APPENDIX

Basic Facts: OpusCapita

Owner Posti Group Corporation

Chief Executive Officer (as of 2016) Patrik Sallner

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”

Exhibit 1. Basic information on OpusCapita (Posti Group, 2014)

CEO

Sales and Marketing

Finance and Document

Order-to- Purchase-
accounting Process Ventures
Cash to-Pay
outsourcing Outsourcing

Customer and Service Operations

M&A and Finance and

HR Comms Legal
Strategy Admin

Exhibit 2. OpusCapita Group organizational chart

17
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.

Exhibit 3. Simplified example of instructions for a software robot operating across two systems.

18