Influencing information systems practice: The action principles approach applied to robotic process and cognitive automation

Assumption 1: practitioners are thoughtful agents

Practitioners are assumed to be thoughtful agents capable of action based on free will, power, intelligence, emotion, creativity, and self-reflection, but who operate within the affordances and confines of their environments (Giddens, 1984; Lacity, 2019). Furthermore, practitioners are able to express reasons for and consequences of their actions and the actions of others, if asked. As Anthony Giddens wrote, “To be a human being is to be a purposive agent, who both has reasons for his or her activities and is able, if asked, to elaborate discursively upon those reasons” Giddens (1984: 3). From this assumption, it follows that IS researchers must engage in a dialogue with practitioners to learn about the associations they make between actions and results.

Assumption 2: action principles are guides, not laws

Aurigemma and Mattson (2019) argue that for some IS contexts (like security), practices may not be universal, but rather, practices may need to be tailored for specific contexts. We assume action principles to be useful guides; we do not consider action principles to be “laws” or even “best practices.” Consistent with Hume (1739), we are aware of the limitations of claiming blanket generalizations based on empirical evidence. Whereas “best practices” imply that mimicry is always recommended and will always produce similar results, an action principle may not be effective in every context; it is for the thoughtful practitioner to decide. As such, action principles created from early adopters are offered to future adopters for their consideration and guidance. The thoughtful practitioner decides the usefulness of an action principle depending on the objectives the organization is trying to achieve; whether the organization has the absorptive capacity to implement the action principle effectively; and timing—there are better times than others to act. Such future adopters are presumed capable of assessing the applicability of practices garnered from other contexts; it is for the thoughtful practitioner to decide the timing and extent to which action x would likely produce result y within his or her organizational context.

Identify a relevant emerging IS phenomenon

IS researchers are fortunate in that IS practices and technologies evolve quickly, so there is never a shortage of emerging phenomena to study. Contexts that are uncharted, ambiguous, and complex provide the greatest opportunity to generate novel findings (Daft, 1983) and are also often the most enjoyable to investigate. To ensure relevance, the emerging phenomena should also be of interest to practitioners. ⁴

Select early organizational adopters using purposive sampling

Action principles fieldwork begins with the study of one or more early organizational adopters that have already completed the implementation of the technology or practice. A purposive sampling strategy is used. According to Palinkas et al. (2015), purposive sampling is used to identify and select information-rich cases for “the most effective use of limited resources” (p. 533). Purposive sampling requires a researcher to develop selection criteria that meet the aims of the study (Henry, 1990; Teddlie and Yu, 2007). To study emerging phenomena using an actions principles approach, sites should be selected based on organizations that have completed the implementation long enough for outcomes to be assessed. Practitioners within these organizations are especially knowledgeable about or experienced with the phenomenon of interest (Creswell and Plano Clark, 2011) and are willing to participate (Bernard, 2002; Palinkas et al., 2015; Spradley, 1979). Furthermore, IS researchers should initially aim to examine implementations that realized business value to minimize the risk of studying a “fad” (Hirschheim et al., 2012). ⁵

Using the contacts made at the IRPA, Ascension Shared Services and the Associated Press were selected as the first sites. Key practitioners within these organizations agreed to participate; Meanwhile, the CMO of Blue Prism provided introductions to two more case studies at Telefónica O2 (a telecommunications provider) and Xchanging (a BPO provider), both based in the United Kingdom. In this project, we conducted four simultaneous investigations before developing action principles. However, IS researchers may begin to develop action principles based on a single implementation (see, for example, Lacity and Willcocks, 2016b).

Engage with and interview key participants

Once access has been granted, the IS researcher begins to engage with “key informants” (Elmendorf and Luloff, 2006; Marshall, 1996; Seidler, 1974; Tremblay, 1957), which we prefer to call “key participants.” Key participants are practitioners placed in organizational positions that provide access to the answers for the research questions under study (Elmendorf and Luloff, 2006). In our service automation research, typical participants included vendor account manager, vendor operational staff, business executive responsible for business benefits, IT and RPA senior executives, automation developers, automation centers of excellence staff, internal process users. Triangulation of participants and of other sources is an integral part of the research method (see Note 6 for more details). This maximizes the chances of collecting relevant viewpoints and information that the researchers may not have considered in advance (Tremblay, 1957). Key participant interviews are appropriate when seeking answers to questions in which the subject matter is sensitive (like automation) and when researchers are more concerned with the quality, not quantity of responses (Fontana and Frey, 1994; Mahoney, 1997; Yin, 2003).

During interviews, the IS researcher aims to understand what drove adoption decisions, the actions practitioners took during the entire adoption journey, and the outcomes they experienced. The interview can begin with a very simple request: “Tell us the story of your organization’s implementation journey from your perspective.” As each interviewee tells his or her story, the IS researcher listens for (1) gaps in the narrative to ask follow-up questions; (2) claims not yet understood which need clarification; and most vitally, (3) statements about the actions an interviewee attributes to an outcome. The latter becomes the foundation for the action principles.

Note that prior to this process, the IS researcher may well have a set of assumptions about what will be discovered, how the technologies will be developed and deployed, what will work, and what will not. Typically, these will be derived from prior research findings, extant theories, and explanations on how emerging technologies are organizationally experienced and managed. While a set of assumptions, even hypotheses, may be held by the IS researcher, these will be held in abeyance as much as possible, though, in the course of research, there may be opportunities that can be grasped to discover whether the accumulating evidence is corroborating those prior assumptions, or otherwise. Interestingly, looking at the automation research under review, after the first round of data collection, we derived findings on action principles that confounded our original assumptions, such as our assumption that employees would be threatened by automation. There are dangers, we concluded, in getting data to fit prior theory and assumptions, and the action principles approach seeks to circumvent, or at least mitigate, this risk. ⁶

Develop action principles

The IS researcher reviews the transcripts to identify results—the degree to which the implementation was a success or failure on dimensions such as financial, operational, and strategic outcomes—and the actions each interviewee attributed to affecting the outcomes. This is an interpretive act (Myers, 2013); the researcher interprets participants’ reflections and finds a common language to express a shared understanding of the associations they make between actions and results. For example, the researcher may find that different participants used different terms to express similar ideas—or conversely, used similar terms to express different ideas. In addition, stakeholders may not agree across interviews, yielding interesting differences that require further sense-making (Weick, 1995). If the data collection is rich enough, the IS researcher writes up the case history with the action principles as the lessons learned. The write-up is reviewed by each participant, which may result in edits to the action principles.

Action Principle: According to one participant in one organizational adoption (Telefónica O2), let business operations lead and do not involve IT in the RPA initiative (action) to speed implementation (outcome).

When Butterfield began the RPA adoption investigation, he chose to lead it himself; he also chose to exclude IT because he felt that IT leaders had already developed very negative ideas about RPA. The IT team had a mature Business Process Management System (BPMS) in-house and questioned why additional automation software was needed. The IT team also incorrectly assumed that RPA tools were just “screen scrapers,” an earlier toolset that functioned quite poorly. Butterfield explained,

[the IT team viewed RPA as] screen scraping, which isn’t fit for an enterprise company—Unsupported macros created by keyboard warriors in darkened rooms in our offices, people left to their own devices to create macros, running unsupported and quite often needing regular check-ups to keep them running. That was the stigma that we originally received from our colleagues in technology.

Later in the interview, Butterfield described how he almost lost his job because he did not inform IT that he was testing new software. He had given his own logon ID and password to the software robots. When the RPA tool executed many transactions in a short period of time, Telefónica O2’s Fraud and Security team were alerted to an intruder, who they traced back to Butterfield’s logon ID. Butterfield reminisced, “Although it was scary to be escorted by the Head of Security into a private room, we actually proved the RPA concept quite well!” We asked if he would include IT if he had to do it over. He said no:

I’d rather apologize for something I’ve done than seek permission for doing it in the first place. And I think as a pioneer in anything, whether it be RPA or digital customer services which is where most of my passion lies, I think if you seek permission for everything you do, everything slows down. Things can get stuck in governance for years and years.

Pat Geary, the CMO for Blue Prism, was the second person we interviewed at Telefónica O2. As Telefónica’s tool provider, we were particularly interested in his view on the role of IT in RPA success. He thought business operations should lead, but that IT needed to be involved for the long-term operational success of RPA. He said,

The minute we engage with business owners, we insist on speaking with the IT function. When we talk to IT, we explain that we have a product that is designed to appease their requirements for security, scalability, auditability, and change management.

Geary explained that the IT department needs to know what the software robots do and how they interact with systems under IT’s control. Otherwise, when the IT department updates their systems, the software robots connecting to them might cease to function. He also thought that IT could help assess RPA tools. For the Telefónica O2 case, we now had an interesting difference:

Action Principle: According to one participant in one organizational adoption (Telefónica O2), let business operations lead but involve IT early in the RPA initiative (action) to ensure long-term operational success (outcome).

While Butterfield’s and Geary’s advice conflict, each participant’s explanation is defendable. We were very curious as to how future interviewees would view the role of IT in RPA implementations.

As a second example of creating an action principle, we developed the following action principle based on Butterfield’s tool selection behavior:

Action Principle: According to one participant in one organizational adoption (Telefónica O2), use a controlled experiment to assess tools (action) to select the tool that delivers the best financial value (outcome).

While many practitioners do a proof-of-concept—a small-scale pilot trial that tests the technical viability of a new innovation—Butterfield did an interesting twist by extending the proof-of-concept into a controlled experiment that pitted the IT department’s BPMS solution against Blue Prism’s RPA software. This experiment allowed Butterfield to directly compare RPA with BPMS. Functionally, the solutions were nearly identical, but RPA delivered better financial value. With the BPMS solution, Butterfield would need to pay for IT resources like IT project managers, designers, and developers. With RPA, Butterfield just reassigned some people from a process improvement team to a process automation team with zero effect on the Back Office budget. Butterfield said, “Our projections showed that RPA for 10 automated processes would pay back in 10 months. In contrast, the BPMS was going to take up to three years to payback.” The 3-year business cases estimated zero net financial benefits with BPMS and nearly £1 million with RPA. In the subsequent interview with Geary, he confirmed that Butterfield’s controlled experiment was effective. In addition, he wished that organizations would adopt this practice to assess the Blue Prism tool directly with other RPA tools, not just with a BPMS. Thus, the provisional action principle was updated to reflect his corroboration:

Action Principle: According to two participants in one organizational adoption (Telefónica O2), use a controlled experiment (action) to select the tool that delivers the best financial value (outcome).

By now, readers see how action principles are derived within a context. The approach captures similarities among participants by incrementing the “n” in the form “according to n participants in one context, action x contributed to result y.” The approach captures differences among participants by creating separate action principles; the researcher can expound upon the differences when writing results.

Across contexts, the “n” and the “m” are incremented to represent similarities. For example, none of the first four organizations (Ascension Shared Service, Associated Press, Telefónica O2, and Xchanging) used RPA to fire internal employees as suggested by the popular press (Devlin, 2015; Ford, 2015; Thompson, 2015). Instead, the RPA tools were performing mundane tasks so that employees could focus on more value-added work. When Telefónica O2 used RPA to automate mundane tasks like SIM swaps—the process of replacing a customer’s existing SIM card with a new SIM card but keeping the customer’s existing number—Butterfield redeployed workers to other tasks. A journalist at the Associated Press, it turns out, would rather interview a CEO than write a corporate earnings report. An accounts payable associate at Ascension Shared Services would rather reconcile records than copy and paste fields from a spreadsheet into an Enterprise Resource Planning (ERP) system. An operations clerk at Xchanging would rather interact with clients (insurance brokers) than spend hours structuring and validating field data for a corporate report. All four organizations were under pressure to do more work without adding more headcount, and RPA was a way to achieve it. The following action principle was created:

Action Principle: According to ten (out of ten) participants in four organizational adoptions (Ascension Shared Service; Associated Press; Telefónica O2; and Xchanging), use RPA to automate mundane tasks (action) to focus employees on more value-added work (outcomes).

Other interesting similarities and differences arose across contexts. Returning to the role of IT, business sponsors at Ascension Shared Services excluded the IT department and for similar reasons as given by Butterfield: IT involvement would delay progress. However, the business sponsors at the Associated Press and Xchanging included IT, and for similar reasons provided by Geary, namely that long-term operational success relies on IT involvement. The action principles, after 10 interviews in four contexts became

Action Principle: According to three participants in two organizational adoptions (Telefónica O2 and Ascension Shared Services), let business operations lead and do not involve IT in the RPA initiative (action) to speed implementation (outcome).

Action Principle: According to seven participants in four organizational adoptions (Ascension Shared Service; Associated Press; Telefónica O2; and Xchanging), let business operations lead and involve IT early in the RPA initiative (action) to ensure long-term operational success (outcome).

There were also unique practices. Telefónica O2 was still the only organization that identified a controlled experiment; Xchanging was the only organization that specifically mentioned fixing process flaws before automation, re-using components, and multi-skilling the software robots as a way to extract more business value. Table 1 captures the action principles across the first four organizations. The table entries can be converted to the form, “According to n participants in m contexts, action x contributed to result y.”

OPEN IN VIEWER

Table 1.

Action principles after the first round of data collection.

Site	Ascension Shared Services	Associated Press	Telefónica O2	Xchanging
Number of interviews	3	1	2	4
1. Use RPA to automate mundane tasks (action) to focus employees on more value-added work (outcome)	3	1	2	4
2. Gain C-suite support (action) to legitimate and support the RPA initiative (outcome)	3	1	2	4
3. Use a controlled experiment to assess tools (action) to select the tool that delivers the best financial value (outcome)			2
4. Include multiple expected benefits in business cases for service automation (action) to achieve the greatest value for the organization, employees, and customers (outcome)	3	1	2	4
5. Develop comprehensive criteria to select the best processes to automate (action) to achieve the greatest value for the organization, employees, and customers (outcome)	3	1	2	4
6. Let business operations lead and do not involve IT in the RPA initiative (action) to speed implementation (outcome)	2		1
7. Let business operations (BO) lead and involve IT early (action) to ensure long-term operational success (outcome)	1	1	1	4
8. Communicate the intended effect on jobs early in the process (action) to obtain employee buy-in and to prevent panic and sabotage (outcomes)	3	1	2	4
9. Do-it-yourself rather than hire outsiders (action) to capture the most financial benefits (outcomes)	2		1	2
10. Continually improve the automated processes (action) to extract more business value (outcome)	3		2	4
11. Fix discoveries about process flaws before deploying RPA (action) to prevent merely performing a bad process more efficiently (outcome)				2
12. Reuse components (action) to scale quickly and to reduce development costs (outcomes)				2
13. Multi-skill the robots (action) to extract more financial value (outcome)				2

RPA: robotic process automation. (source: authors)

Continue fieldwork

The researcher proceeds with subsequent fieldwork by finding more early adopters to investigate using purposive sampling; the researcher may wish to select additional sites that vary the sample by industry, geography, size of firm, success rates, specific tool, etc. In addition to purposive sampling, snowball sampling may be employed to find additional sites. With snowball sampling, existing participants are used to help recruit future participants (Kuzel, 1992) and it is particularly useful for identifying experts (Christopoulos, 2007). ⁷

While interviewing participants in the next sites, we still began with the request: Tell us your automation story from your perspective. After participants shared their experiences, we asked follow-up questions—this time focusing on action principles identified in the first round of data collection that the participant had not yet discussed. Where these action principles evident in this context? With each round of fieldwork, action principles were created for each site, compared to prior sets of action principles, and combined or revised as needed. Table 2 provides an example of the evolution of action principles based on the addition of KPMG, Deakin University, SEB Bank, and Zurich Insurance. One will note some practices have been further corroborated, some revised, and some new ones (in bold text in Table 2) have been created.

OPEN IN VIEWER

Table 2.

Action principles after a subsequent round of data collection.

Site	Ascension Shared Services	Associated Press	Telefónica O2	Xchanging	KPMG	Deakin University	SEB Bank	Zurich Insurance
Number of interviews	3	1	2	4	4	5	2	2
1. Use RPA service automation tools to automate mundane tasks (action) to focus employees on more value-added work (outcome)	3	1	2	4	4	5	1	2
2. Gain C-suite support (action) to legitimate, support, and provide resources for the RPA service automation initiative (outcome)	3	1	2	4	4	5	2	2
3. Use a controlled experiment to assess tools (action) to select the tool that delivers the best financial value (outcome)			2
4. Include multiple expected benefits in the justification for service automation investments (action) to achieve the greatest value for the organization, employees, and customers (outcome)	3	1	2	4	2	2	1	1
5. Develop comprehensive criteria to select the best processes to automate (action) to achieve the greatest value for the organization, employees, and customers (outcome)	3	1	2	4	3	2	1	1
6. Let business operations lead and do not involve IT in the RPA initiative (action) to speed implementation (outcome)	2		1
7. Let business operations (BO) lead and involve IT early (action) to ensure long-term technical operational success (outcome)	1	1	1	4	4	5	2	2
8. Communicate the intended effect on jobs early in the process (action) to obtain employee buy-in and to prevent panic and sabotage (outcome)	3	1	2	4	4	5	2	1
9. Do-it-yourself rather than hire outsiders (action) to capture the most financial benefits (outcomes) Select the best sourcing option (action) to ensure the success of the implementation (outcome).	2		2	2		1	1	1
10. Continually improve the automated processes (action) to extract more business value (outcome)	3		2	4	3	4	3	2
11. Fix discoveries about process flaws before deploying RPA service automation (action) to prevent merely performing a bad process more efficiently (outcome)				2		3	1	1
12. Reuse components (action) to scale quickly and to reduce development costs (outcomes)				2
13. Multi-skill the robots (action) to extract more business value (outcome)				2
14. Don’t underestimate the data challenge (action) required to get cognitive automation tools to perform competently (outcome)					3	3	1	1
15. Supervise the learning of the service automation tool (action) to prevent machines from making new decisions without human direction and approval (outcome)					4	4	2
16. Invite customers to try service automation, but keep other channels open (action) to promote customer experimentation (outcome)						3	1
17. Compare training the automation tool to training a new employee (action) so that stakeholders expect the tools to be as competent as new employees, not as competent as experts (outcome)					2		1
18. Have a higher societal purpose (action) to warrant the investment in cognitive automation (outcome)					4
19. Manage as an innovation program (action) to increase experimentation and to rapidly shift direction (outcome)					2		1
20. Consider competitors’ reactions (action) to prevent mis-messaging to customers (outcome)						1
21. Don’t look for a Swiss Army Knife: select a tool that does one thing well (action) to ensure technical success (outcome)								1

RPA: robotic process automation; IT: IT department.

As an example of an action principle gaining corroboration, consider the one on using service automation tools to automate mundane tasks (action) to focus employees on more value-added work (outcome). At least one participant from all four cognitive automation contexts mentioned this action principle. For example, Cliff Justice, Partner, US Leader, Cognitive Automation and Digital Labor at KPMG said KPMG aimed to apply cognitive technologies to liberate skilled workforce from routine tasks to more fully use their qualifications and critical thinking skills. KPMG recruits thousands of employees each year, often people with advanced professional degrees and certifications. Such professionals expected their careers to be filled with challenging work that use their expertise, judgment, problem-solving, and decision-making skills. The reality at KPMG was that highly skilled professionals spent too much time focused on mundane tasks. According to Cliff Justice, “Cognitive is a net positive for people to innovate and to allow people to invent new things.”

In addition to KPMG, participants from Deakin University, SEB Bank, and Zurich Insurance expressed similar ideas. Thus, the action principle considering these eight contexts was:

Action Principle: According to 22 (out of 23) participants in eight organizational adoptions, use service automation tools to automate mundane tasks (action) to focus employees on more value-added work (outcome).

As an example of a revision, the initial version of the action principle pertaining to sourcing was, “Do-it-yourself rather than hire outsiders (action) to capture the most financial benefits (outcomes).” In subsequent contexts on the adoption of cognitive automation tools (rather than RPA tools), the organizations engaged consultants to help with the implementations because they lacked the in-house skills needed to deploy these more complex technologies. The action principle became, “Select the best sourcing option (action) to ensure the success of the implementation (outcome).”

As an example of a new action principle, consider the one about data requirements:

Action Principle: According to eight participants in four organizational adoptions (KPMG, Deakin University, SEB Bank, and Zurich Insurance), don’t underestimate the data challenge (action) required to get cognitive automation tools to perform competently (outcome).

Cognitive automation tools, which use machine learning algorithms, are programmed differently from other tools. Machine learning requires programming computers so that the tool performs tasks competently based on prior examples, not just based on logic rules. Participants in our study were unprepared for the enormous number of high-quality prior examples needed. (Andrew Ng, founder of Google’s Brain Deep Learning Project, wrote that it takes tens of thousands of labeled pictures to recognize people, and tens of thousands of hours of audio paired with written transcripts to recognize speech (Ng, 2016)). Some participants were surprised to learn that the tool could not read low-resolution images, deal with unexpected data types, nor process much of the natural language text. These early adopters spent a lot of time and resources developing good examples to feed to the tools. For example, Deakin University collected 20,000 student queries and then categorized them by intent (with IBM’s help) to reduce the set to 2000 questions. Then, Deakin University engaged the help of 100 employees to pair each question with the correct answer to serve as the “ground truth” for Watson. Once the correct answers were identified, the next step entailed “content uplift,” where answers were appropriately worded and structured for Watson ingestion before Watson was ready to be tested. According to participants at Deakin University, the effort was worthwhile in the end, as they reported significant value for the institution, students, and staff (Scheepers et al., 2018).

Since new contexts were still revealing new and insightful action principles, fieldwork continued. Purposive sampling helped to diversify further the industries, geographies, processes, and tools examined. We conducted more interviews with early organizational adopters, their service automation providers, and advisors to build 22 detailed client adoption journeys (see Table 3). It is useful to establish that the 22 organizations initially were all “successful” adopters that realized one or more business benefits. We have permission to name 11 of the organizations. We assigned pseudonyms to the others (indicated by an asterisk in Table 3).

OPEN IN VIEWER

Table 3.

Client adoption journeys.

Company name or pseudonym*	Industry	Head-quarters	Adoption location	Realm	First processes automated
1. Ascension Shared Services	Healthcare	US	BO	RPA	Employee record updates; payments
2. Associated Press	Media	US	BO	RPA	Corporate earnings reports
3. Telefónica O2	Telecommunications	UK	BO	RPA	SIM Swaps; pre-calculated credit
4. Xchanging	BPO provider	UK	BO	RPA	Premium advice notices
5. KPMG	Professional Services	US	Innovation Center	CA	Business development; risk assessment; audit
6. Deakin University	Higher Education	Australia	BO	CA	Student queries and engagement
7. SEB Bank	Financial Services	Sweden	IT	CA	IT Services desk; customer services
8. Zurich Insurance	Insurance	Switzerland	BO	CA	Personal injury claims
9. Blue Cross Blue Shield-North Carolina	Healthcare Insurance	US	BO	RPA	Claims processing
10. Biotech*	Biotechnology	Netherlands	BO	RPA	Financial close
11. Building Society*	Financial Services	UK	BO	RPA	Mortgage lending and savings
12. Consulting*	Professional Services	France	BO	RPA	Multiple services
13. Energy*	Natural Gas	Russia	BO	RPA	New customer registration
14. Financial Services*	Financial Services	UK	BO	RPA	Payroll verification
15. Financial services*	Financial Services	South Africa	BO	RPA/CA	Consumer Credit
16. Healthcare*	Healthcare	UK	BO	RPA	Patient registration
17. IBM Division	Professional and IT services	UK/Netherlands	IT	RPA/CA	Help desk ticketing
18. Insurance*	Insurance Services	UK	IT	RPA	Pension enrollment
19. Manufacturing*	Consumer Goods	Germany	BO	RPA	Back office processing
20. Utility*	Electric and Gas	Germany	BO	RPA	Meter reading feasibility checks
21. VHA	Healthcare	US	IT	RPA	Web crawls for product descriptions
22. Virgin Trains	Transportation	UK	BO	CA	Incoming customer correspondence

RPA: robotic process automation; BO: Business Operations; IT: IT department; BPO: business process outsourcing. (source: authors)

In 2017 and 2018, we also conducted multiple interviews on failures, which were largely informed by the tool providers and advisors. (Few of their clients wished to discuss failures on record.) We asked interviewees to diagnose the actions which led to failure. We were now able to assess that failures were associated with not applying at least some of the action principles. For example, we learned that at one organization, a manager was told to generate a 10% headcount reduction with RPA in 6 months. When employees got wind of this, some of the best employees left (which the organization hoped to retain), and some remaining employees refused to cooperate with the service automation team. The action principle is “according to one participant in one context, using RPA to terminate employees (action), resulted in employee backlash.” We documented these “negative” action principles as “risks” (41 across the automation lifecycle) in Lacity and Willcocks (2017a).

End fieldwork when knowledge returns diminish

Field research ends when no new significant insights are being revealed. One can think of this as a form of “theoretical saturation” (Glaser and Strauss, 2008).

OPEN IN VIEWER

Table 4.

Action principles after 22 adoption journey data.

Relevant to		RPA	CA	Robust or distinctive
Strategy	1. You get what you pay for: Focus on long-term value rather than short-term ROI (action) to gain the most value from service automation tools (outcome)	√	√	R
	2. Strategy drives investments: Include multiple expected benefits in the justification for service automation investments (action) to achieve the greatest value for the organization, employees and customers (outcome)	√	√	R
	3. Consider competitors’ reactions (action) to prevent mis-messaging to customers (outcome)		√	D
	4. Use RPA as forward reconnaissance for CA (action) to gradually build automation skills and to use RPA savings to defer some CA costs (outcome)	√	√	D
	5. Strategy envisions longer-term human workforce needs (action) and develops automation and HR plans to gradually meet that vision (outcome)	√	√	D
Sourcing	6. Select the best sourcing option (action) to ensure the success of the implementation (outcome).	√	√	R
	7. If sourcing with a BPO or tool provider, incentivize the provider to share the benefits of automation (action) to prevent them from taking all of the savings (outcome)	√	√	R
Program management	8. Manage RPA as a traditional business case (action) to increase returns on investment (outcome)	√		R
	9. Manage cognitive automation as an innovation program (action) to increase experimentation and to rapidly shift direction (outcome).		√	R
	10. Manage cognitive automation as a learning project (action) to adapt quickly to early lessons learned (outcome)		√	D
	11. Select the organizational unit that is best-suited to own the automation program (action) to achieve the desired priority (speed; longevity) (outcome).	√	√	R
	12. Find the “Lewis and Clark” program champions (action) who will overcome obstacles to ensure project implementation (outcome)	√	√	R
Process selection	13. Take the robot out of the human: Use service automation tools to automate mundane tasks (action) to focus employees on more value-added work (outcome)	√	√	D
	14. Aim for the triple win: Develop comprehensive criteria to identify the best processes to automate (action) to achieve the greatest value for the organization, employees, and customers (outcome)	√	√	D
	15. Fix discoveries about process flaws before deploying service automation (action) to prevent merely performing a bad process more efficiently (outcome)	√	√	R
Tool selection	16. Use a controlled experiment to assess tools (action) to select the tool that delivers the best financial value (outcome)	√		D
	17. Don’t look for a Swiss Army Knife: select a tool that does a few things well (action) to ensure technical success (outcome)	√	√	R
	18. Negotiate the optimal level of client-provider transparency pertaining to machine learning algorithms (action) to ensure a good relationship (outcome)		√	D
	19. Expect technical challenges as a first mover (action) to minimize disappointments (outcome)	√	√	R
Stakeholder buy-in	20. Manage up: gain C-suite support (action) to legitimate, support, and provide resources for the service automation initiative (outcome)	√	√	R
	21. Manage down: communicate the intended effect on jobs early in the process (action) to obtain employee buy-in and to prevent panic and sabotage (outcomes)	√	√	R
	22. Report financial savings in terms of “hours back to the business” (rather than FTE savings)(action) to reinforce that automation is used to liberate employees from routine tasks (outcome)	√	√	D
	23. Manage expectations out: be transparent with customers that they are interacting with automation tools (action) to maintain high ethical standards and acceptance (outcome)	√	√	R
Design, build, and test	24. Pareto’s rule: automate the smallest percentage of tasks that account for the greatest volume of transactions (action) to deliver the most business value (outcome).	√	√	R
	25. Don’t underestimate the data challenge (action) required to get cognitive automation tools to perform competently (outcome)		√	D
	26. Find new data sources if “dirty” data cannot be cleaned (action) to get the cognitive automation tool to perform competently (outcome).		√	D
	27. Compare training the automation tool to training a new employee (action) so that stakeholders expect the tools to be as competent as new employees and not as competent as experts (outcome)	√	√	D
Run	28. Redesign employee scorecards so that employees are credited with productivity gains contributed by their robot teammates (action)	√	√	D
	29. Invite customers to experiment with the automated service, but keep other channels open (action) to ensure good customer service (outcome)		√	D
	30. Invite customers to provide feedback (action) to help improve the performance of a cognitive automation tool (outcome).		√	R
	31. Keep subject matter experts continually engaged in data curation (action) to keep the automation relevant (outcome).	√	√	D
	32. Robots need supervisors: supervise the learning of the service automation tool (action) to prevent machines from making new decisions without human direction and approval (outcome)		√	R
	33. Rethink human talent and skills (action) needed for long-term success (outcomes)	√	√	R
	34. Assign clear roles of responsibility (action) to keep the automation operational and relevant (outcome)	√	√	R
Maturity	35. Reuse components (action) to scale quickly and to reduce development costs (outcomes)	√		R
	36. Multi-skill the robots (action) to extract more business value (outcome)	√		D
	37. Create a Center of Excellence (CoE) (action) to disseminate the technology across the organization (outcome)	√	√	R
	38. Integrate RPA and Cognitive initiatives (action) to deliver end-to-end service automation (action)	√	√	D
	39. Continually innovate (action) to deliver value to customers, employees and shareholder (outcome)	√	√	R

RPA: robotic process automation; BPO: business process outsourcing; ROI: return on investment; FTE: full-time equivalent. (source: authors)

By comparing Tables 1, 2, and 4, one can also see how action principles evolved with more data collection. Returning yet again to the role of IT, we initially identified two action principles “let business operations (BO) lead, do not involve IT” and “let business operations (BO) lead, but bring in IT early.” In subsequent contexts, we found four organizations where IT successfully led the service automation program (IBM, VHA, an insurance company and a financial services firm). Two of the IT-led cases were automating IT processes (e.g. IT help desk ticketing)—not business processes—so it made sense for IT to lead. At one site, the IT Director had spent years in business operations, so he had the business knowledge to lead the RPA program. This additional evidence led us to alter the action principle to

Action Principle: Select the organizational unit that is best-suited to own the automation program (action) to achieve the desired priority (speed; longevity) (outcome).

Next, we discuss how one might evaluate a set of action principles.

Robustness

Action principles are “robust” if the action is found to affect outcomes across multiple participants and sites, not only within the particular study of an emerging phenomenon, but across other studies as well. Highly robust action principles reaffirm what managers already know about successful technology implementations; they capture what is “the same” about an emerging phenomenon. For example, most of the participants from the 22 organizations in the service automation project suggested the principle “gain C-suite support (action) to legitimate, support, and provide resources for the service automation initiative (outcome).” This is a robust finding within the study, but it is quite commonly known to apply to any type of organizational adoption. For example, many IS studies found that “top management support” (action) contributes to the success of IT implementations (outcomes) (e.g. Bharati and Chaudhury, 2010; Liang et al., 2007; Nelson, 2007; Yetton et al., 2013). Table 4 suggests that of the 39 action principles, 22 (56%) are robust. While robust action principles are important, the research may be of limited interest and value to practitioners if it only produces robust action principles that are commonly known.

Distinctiveness

Action principles are “distinctive” if the action is unique to the emerging phenomenon. These action principles are of the most interest and value to future adopters; they inform practitioners what is different about an emerging technology or practice. From Table 4, 17 practices (44%) are distinctive to RPA, cognitive automation, or both. We noted above, for example, that cognitive automation tools need to be programmed differently than other tools. Specifically, the tools require many labeled examples to function competently. The action principle alerts future adopters to this idiosyncrasy.

Another example of a distinctive RPA action principle is “multi-skill the robots (action) to extract more financial value (outcome).” Each RPA software robot has its own software license. Several early adopters licensed a robot for each process; if 30 processes were automated, 30 software licenses were bought. (In 2015, each license cost about US$10,000). However, Xchanging figured out it could configure the same robot to perform multiple processes, provided they were scheduled to run at different times.

As another example of a distinctive action principle, consider “use RPA as forward reconnaissance for cognitive automation (action) to gradually build automation skills and to use RPA savings to defer some of the costs of cognitive automation (outcomes).” RPA tools have two distinctive features—they are configured (not programmed) and they are non-invasive (see Appendix A)—which make them less expensive and easier to deploy than other tools. However, RPA tools only work for highly structured data with precise processing rules. In contrast, cognitive automation tools can operate on unstructured data using inference-based processes, but they can be much more expensive than RPA tools. According to some early adopters, senior executives need to see substantial results from the less expensive and faster deployed RPA automation projects before they were willing to invest in expensive and time-consuming cognitive automation programs. RPA generated enough in savings to help fund the next investment in cognitive tools. Todd Lohr, Principal, US Transformation Enablement Leader at KPMG explained:

We’ve done RPA automation. We’ve built 290 bots. We’ve saved a ton of money. RPA just scratches the service on what automation can do. The transformative value is in the cognitive-type technologies. We want to start experimenting with those, finding use cases and investing in that area. [We asked senior management], are you supportive? They say “Yes!” If we had asked for that 12 months ago before delivering tens of millions of dollars in savings from RPA, we would have been denied.

To recap, robust action principles identify what is the “same” and distinctive action principles identify what is “unique” about an emerging technology or practice. A mix of robust and distinctive action principles should be the primary criterion for evaluating a set of action research principles. To this, we add another discretionary criterion: provocativeness.

Provocativeness

Provocative action principles are distinctive action principles that are particularly dissonant, shocking, intriguing, or surprising. From our service automation research, we were surprised to learn that in multiple sites, employees anthropomorphized their software robots. We first became aware of this behavior at Xchanging. Amanda Barnes, a technician at the company, had named her software robot “Poppy,” after Remembrance Day 2014—which is signified by poppies in the United Kingdom, the day the software robot went into production. She helped to configure Poppy to automate some of the routine tasks associated with her job. She referred to Poppy as a junior team member. She created an image to depict her robot (see Figure 3).

OPEN IN VIEWER

Figure 3.

An Xchanging employee’s depiction of her software robot.

As more Xchanging teams adopted RPA across functions, divisions, and geographies, additional employees named their robots Henry, Sunny, Timmy, Tommy, Feebz, etc. Employees also held a global internal contest as to the “coolest” robot—(Poppy won).

We next experienced this behavior at a retail company where the employees named all 40 of the software robots “Dennis,” beginning with Dennis 1, Dennis 2, through to Dennis 40. Employees distinguished among their “personalities.” One employee described Dennis 17 as a “rascal”—a robot that was less obedient than the others and required more attention. In the third company (an energy company)—employees played on the name “Robert” and called their robots Robo Di Nero, Robo Martinez, etc. At SEB bank, IPsoft’s tool was named “Aida” and described as a virtual assistant.

Reflecting on this practice with participants, we realized that the action of anthropomorphizing software could only occur because employees were confident that the automations were there to help them, not to displace them. The pre-cursor to this confidence was management communicating the purpose of the automations, which was to let the software do the tedious tasks, thus freeing employees for more interesting work. We ended up with the provocative insight to deploy service automations to “take the robot out of the human.” Its facilitating action principle is “communicate the intended effect on jobs early in the process (action) to obtain employee buy-in and to prevent panic and sabotage (outcomes).”

With the intense public focus on job creation, the optics of automation can be perceived as “job killers,” which leads us to discuss the “elephant in the room”: How did participants claim that service automation delivered financial benefits without job loss? Participants in our study primarily used service automation to take on more work without adding more headcount. When service automation scaled to the point where fewer people were needed, they redeployed employees to more value-added positions, slowed hiring, and/or waited for natural attrition. One company reduced its reliance on a BPO provider. One provocative practice that emerged was “report financial savings in terms of ‘hours back to the business’ (action) to reinforce that automation is used to liberate employees from routine tasks (outcome).” For example, one global professional services firm with a few hundred thousand employees generated 800,000 h back the business from RPA, which, if converted to full-time equivalents (FTE), would be 400 FTEs. In reality, the automations relieved thousands of workers from dreary tasks within their jobs; it did not automate 400 jobs. By reporting the labor savings in terms of hours, organizations better signal that they are using service automation to free up employees for more value-added work.

Thus far, we have discussed assumptions, the process of knowledge creation, and evaluation criteria for an action principles approach. Next we discuss knowledge dissemination.

Disseminate action principles to practitioners

A single early-adopter story that yields significant insight can make an important contribution to practice. Managers in other organizations who are about to launch their own adoption journeys are desperate for any insights. The outlets for dissemination might include online research briefings, LinkedIn posts, blogs, news media, trade magazines, or publication outlets with short cycle times. Social media and online outlets can reach hundreds, even thousands of practitioners quite quickly. Practitioners that participate in the research are often willing to help disseminate findings. ⁸

Disseminate findings useful to academics

IS researchers can disseminate findings useful to academics by providing insights into emerging technologies in organizational contexts. This can lead the way for follow-up research, or help to corroborate or disconfirm parallel research, perhaps carried out using different research methods. Such findings can also contribute to further theory development. Action principles may also make a number of theoretical contributions, particularly to what Gregor (2006) classifies as “explanation” and “design and action” theories. Explanatory theories explain what is, how, when, why, and where, but they do not make predictions. Given the assumptions of (1) practitioner agency and (2) action principles are guides (not laws), an action principles approach is not designed to develop predictions. The action principles approach may also contribute to “design and action theories” which aim to explicate how to do something effectively. The research has contributed to a degree toward conceptualization—action principles is a distinctive concept as well as method. Our findings also produce conceptualizations such as the “triple win” possible from automation in terms of shareholder, customer and employee value, and on the four-phase learning curve organizations seem to go through with automation. ⁹

In terms of theory and methodology, the action principles approach has many features in common with Bayesian inference. A Bayesian learner starts with a set of hypotheses about the world. With new data, the hypotheses that are compatible with the data become more likely (or in our terms, more “robust”), while the hypotheses that are not compatible become less likely (or impossible). After seeing enough data, a single hypothesis dominates, or a few do. Bayesian statistics are, of course, the basis for much quantitative research in IS and other fields, as well as for the development of algorithms through machine learning. The action principles approach also bears many common features with Dewey’s pragmatic theorizing and approach to research inquiry (Dewey, 1929). The approach also fits in the spiral model of theory building presented by Rivard (2020). With her, we see theorizing as a craft and as such a highly iterative process, moving, as we do with the action principles approach, through erudition, motivation, definition, imagination, explanation/presentation, and contribution. Her experience confirms that the overall spiral process and several of its activities are relevant to inductive theory building based on qualitative data collected as with the action principles approach.

Site selection bias

Purposive and snowball sampling have recognized limitations, particularly in terms of site selection bias (Foley, 2018). Both methods are prone to anchoring bias in that it is difficult to assess whether the sites are representative of other organizations (Atkinson and Flint, 2004). In addition, snowball sampling is prone to community bias because the first set of participants strongly affects the subsequent set of participants. To overcome community bias, the initial set of participants should be as diverse as possible (Morgan, 2008). As applied to our automation research, the sites were diverse in terms of industry, geography, tasks automated, and tools adopted. The sites were biased initially in favor of successful outcomes by design to minimize the risk of studying a fad (see below) and to increase the contribution to future adopters, who prefer to learn from peers who have already been successful (DiMaggio and Powell, 1991).

Informant bias

As an additional epistemological concern, relying on key informant (participant) interviews has one major drawback: informant bias (Marshall, 1996). Multiple interviews with different stakeholders are recommended to compensate for the weaknesses of bias and error (Seidler, 1974). For the service automation research, we aimed to interview at least three participants at each site. In practice, we found their views to be highly consistent or could be synthesized relatively easily (Tremblay, 1957). When views conclusively diverged, we captured these differences with separate action principles.

Chasing fads

By studying early adopters, one concern with the action principles approach is that IS researchers and practitioners may waste time investigating a “fad” that may soon disappear (Hirschheim et al., 2012; Wang, 2010; Weick, 2001). A fad is a short-lived innovation that fades because it fails to deliver business value or because another innovation rapidly usurps it. Examples of technology fads include Google Glass, e-book readers, and three-dimensional (3D) televisions. IS researchers can mitigate this risk in two ways. First, researchers can study successful early implementations that delivered evidence-based results, serving as proof-of-value. If early adopters are gaining value, it is more likely the innovation is not a fad. Second, researchers can select a topic that represents a class of new technologies or practices. For example, an IS researcher might investigate wearable technologies, for which Google Glass is just one specific tool; or portable devices, for which an e-book reader is just one example; or 3D technologies for which a 3D television is just one example.

Overwhelming the practitioner

The action principles approach aims to provide comprehensive guidance, particularly for line managers in charge of deploying an emerging technology or practice. Practically, however, a large number of action principles can place a significant cognitive load on practitioners. In our service automation example, we created 39 action principles. Some IS researchers have convincingly argued that IS research should focus practitioners on a few CSFs (Bullen and Rockart, 1981; Rockart, 1979). While an action principles approach produces comprehensive coverage of an emerging phenomenon, the results can be tailored for different audiences who need fewer details. An IS researcher might, for example, write an article that covers only the action principles associated with strategy for senior managers, or only the distinctive action principles for Chief Information Officers, or only the action principles related to human resources for an HR manager.

Misalignment of academic performance incentives

Culturally, individual institutions with narrow standards for promotion and tenure that reward only academic research in top academic journals may discourage adoption of approaches aimed at influencing practice. We are, however, encouraged by the welcoming of these ideas in several “basket of eight” IS journals, and also by several senior IS academics. For example, Rudy Hirschheim recently wrote a provocative essay in the Journal of the AIS titled, “Against Theory: With Apologies to Feyerabend.” He wrote,

My plea therefore, is that instead of focusing on what contributions one’s research makes to theory, we should focus on the contributions one’s research makes to understanding—what new insights does the research generate, in particular as they relate to changing or helping practice; do the insights resonate with practitioners; how would these insights change the way practitioners see particular problems, particular solutions? (Hirschheim, 2019a: 1344).

The action principles approach provides one path forward.