ONE
Deconstruct the Job
Which Job Tasks Are Best Suited to Automation?
Here’s a brainteaser: You are given a candle, a box of tacks, and a book of matches. How do you attach the candle to a wall so that you can light it without dripping wax onto the floor below?
The solution to Duncker’s candle problem is to deconstruct the box of tacks into its parts (box, tacks).1 Then you’ll see that the tacks can attach one side of the box to the wall and attach the candle to the bottom of the box. In experiments, people who receive the box with the tacks inside solve the problem far less often than those given the box with a separate pile of tacks next to it.
What does this have to do with work automation? Work is constructed into job descriptions similar to the box full of tacks. The job descriptions become a repository of competencies, performance indicators, and reward packages. Soon, leaders, workers, and others see the job and its components as one indivisible thing, like seeing the box full of tacks as one thing. This tendency to think of jobs as fixed repositories obscures powerful opportunities to optimize work automation. It leads to the common but overly simplistic question, “How many workers doing a job will be replaced by automation?” The true pattern of work automation is only revealed in the deconstructed work tasks, not the job.
Just as you must take the tacks out of the box to solve the candle problem, you must take the tasks out of the job and then reinvent the job to solve the work automation problem.
Let’s return to the ATM story to see how this works.
The Wrong ATM Question: “How Many Teller Jobs Can Be Replaced?”
Imagine you lead the workforce of a retail bank in the 1970s. Your technology analysts have run the numbers and estimated huge cost savings from replacing the human tellers with ATMs. In fact, because teller machines need not be attached to a full bank branch, your technology planners estimate that eventually you can cut costs even more by reducing the number of full branches, creating mini-branches consisting solely of ATMs. Customers who need services beyond the teller machines will go to one of the fewer traditional bank branches. The technologists are also enthusiastic about risk reduction, because teller machines make fewer mistakes, like failing to complete necessary paperwork or coding transactions incorrectly. They wax eloquent about enhancing the customer experience, because ATMs can process transactions faster so customers spend less time waiting in line. These potential benefits are enticing, but as history shows, simply replacing human tellers with automated machines wasn’t the optimal solution.
The first step to a better solution is to take apart, or deconstruct, the job into work elements or tasks. (The sidebar “Work Elements of the Job of Bank Teller” shows one example of how the deconstructed teller job might look.)
Some tasks, such as processing cash withdrawals, are very amenable to the automation of ATMs. Others, such as counseling customers whose accounts have been frozen due to overdrafts, are not amenable to automation. An ATM can hardly deal with customer frustration and anger.
Deconstructing the teller job into its elements also reveals that job elements could be automated in different ways. Human bank tellers assisting a customer completing a simple transaction can detect when that customer might be receptive to other banking services. A recent Atlantic article featured an interview with Desiree Dixon, a member-service representative at the Navy Federal Credit Union in Jacksonville, Florida, who described her work: “[W]hen you walk into a Navy Federal, [the staff] really understands what you go through as a military spouse or your family being in the military. Unless you’re in that situation, or you have people in relation to that, there isn’t that understanding. When your husband or your sister is out to sea and they’re deployed, and you’re trying to get business taken care of—you may have a power of attorney and it’s in their name. Navy Federal really understands that those things occur.”2
Now you can see more clearly how to group the tasks: some are repetitive (providing requested cash; verifying sufficient funds), while some are variable (collaborating with product designers to improve products and processes). Some require human interactions, empathy, and emotional intelligence (conversing with customers; counseling those who have insufficient funds), while some are done independently (calculating cash balances). Some are physical (giving cash to customers), and some are mental (identifying appropriate additional bank services). You realize that these categories reveal which tasks are very compatible with replacement by an ATM (such as repetitive-independent-physical), and which must be done by humans or automated very differently (variable-interactive-mental). (See table 1-1.)
Deconstructing Jobs into Work Elements
As the ATM example illustrates, you must deconstruct jobs into their key elements and not think in terms of replacing entire jobs. Those elements will reveal the optimization patterns, often hidden when the work is trapped in a job description. That does not mean that jobs will disappear, but rather that they will be reinvented, as work that was aggregated into a “job” is constantly reconfigured and continuously deconstructed and reconstructed. Over time, some work elements will be removed from the job as they are transferred to other work arrangements or automation.
The remaining work tasks may no longer make up a full-time job. However, work automation isn’t just about optimizing one job at a time. Groups of jobs are related, so work automation requires optimizing the related work tasks across several jobs. In a related group of jobs, each job’s content may be reduced by automation, but the remaining human tasks from several related jobs may be combined into a new, reinvented full-time job. Our examples will often focus on a single job for illustration, but you can use the same tools in the more realistic situation where work automation should apply to groups of jobs with related tasks.
How do you find the component tasks within jobs? There are many frameworks. You may be using several of them. You can find the tasks that make up jobs in job descriptions and competency lists. You can also sometimes find them in performance goals and reward components. One online library of work tasks, spanning thousands of different kinds of jobs, is O*Net. Its website says, “[T]he O*NET database, containing hundreds of standardized and occupation-specific descriptors on almost 1,000 occupations covering the entire US economy. The database, which is available to the public at no cost, is continually updated from input by a broad range of workers in each occupation.”3 Figure 1-1 is an adaptation of a graphic produced by AlphaBeta Analysis using data from O*Net to illustrate the automation compatibility of tasks within jobs. As you can see, each job contains many different tasks, and each task has different automation compatibility. Asking if a job is compatible with automation is meaningless, compared to asking how automation compatible each deconstructed task is.
FIGURE 1-1
Automation compatibility of tasks within jobs
The impact of automation is best understood by breaking the economy down into tasks
Source: This work is a derivative of “The Impact of Automation Is Best Understood by Breaking the Economy Down into ‘Tasks,’” by O*net, Alphabeta Analysis, used under CC BY 4.0.
What Makes a Task Automation Compatible?
How do you measure the ease of automating a task? We believe there are three fundamental characteristics, as shown in figure 1-2.
FIGURE 1-2
Three dimensions that determine automation compatibility
Repetitive versus Variable?
Repetitive work is often predictable, routine, and determined by predefined criteria, while more variable work is unpredictable, changing, and requiring adaptive criteria and decision rules.
Most of the work tasks of credit analysts are repetitive. They gather and synthesize similar data for every loan application. They look for the same red flags in each piece of customer data that is pulled from bank records, credit rating agency data, government records, and social media. Generally, repetitive work is more automation compatible with well-established solutions such as RPA, which we describe in chapter 3. RPA can perform such analyses as much as fifteen times faster, with almost no errors. On the other end of the continuum, the work of a human resources consultant is highly variable. Every client situation is different and every problem is unique. This consultant works with analytical tool kits, change management frameworks, and process design techniques that must be customized to diagnose unique problems and solutions. Such work is generally less amenable to automation, but advances in cognitive automation might automate some analytical tasks or learn from previous client engagements.
Independent versus Interactive?
Independent work requires little or no collaboration or communication with others, while work performed interactively involves more collaboration and/or communication with others, and relies more on communication skills and empathy.
Accountants preparing statutory reports for regulators using prescribed templates and decision rules are doing primarily independent work. They can gather data from various sources, synthesize their findings, apply accepted analytical tools, and produce reports with their findings without engaging another person. A good portion of such work is automation compatible using well-established methods. For example, RPA could do the information gathering and synthesis, while AI could do much of the analysis and produce certain basic reports. Call-center agents, on the other hand, are doing interactive work, matching their work to each caller’s unique emotions, needs, and style of communication. Interactive work is generally less automation compatible, but advances in AI and sensors can detect the caller’s emotions and analyze the request to give the call-center employee relevant information to better serve the caller with greater empathy and care.
Physical versus Mental?
Physical work is primarily manual in nature, requiring manual dexterity and often strength, while mental work requires one’s cognitive abilities.
The work of a manufacturing line assembler is physical work. The assembler might gather different parts, weld them together, inspect the work, and move the finished product to another part of the factory. Such work lends itself well to social or collaborative robotics that is the result of combining AI, sensors, and mobile equipment. A collaborative robot could gather and move parts and weld them together to degrees of precision that greatly exceed the skills of a human being. On the other hand, RPA or cognitive automation can often replace or augment the mental work of an accountant.
Job Deconstruction and Reconfiguration: Oil Drillers
The job of oil driller is at the nexus of massive economic and technological change. Traditionally, the natural resources industry is labor intensive, but cost pressures due to declining commodity prices and margins have demanded greater operational excellence. That is the strategic goal that often motivates technologists and operations research leaders to recommend automating work. And they have made significant advances in automating many aspects of the extraction process. While the strategic benefits of technology are enticing, they rely on deep and radical changes in work and the organization. Technology innovations require work transformations across the entire extraction process. Jobs can be reinvented to reduce physical risk, reduce the probability of accidents with dire consequences, and reinvent work so that it is less demanding and more attractive to increasingly scarce talent.
Let’s look at the job of a driller on an oil rig. Much of the work is traditionally repetitive, independent, and physical. In the past, the extensive use of analog equipment emphasized the driller’s experience and expertise in ensuring the smooth operation of the rig. As a result of this human centricity, there was significant variation in the performance of each rig. In addition, the driller often did maintenance based on his feel and sense of when equipment might not be operating optimally. Control of the rig was entirely in his hands. The physical nature of the work meant high labor intensity and relatively low skills.
Such work is very automation compatible. Sensors and AI enable a radical reinvention of the work and the driller’s job. Now drillers need not be exposed to the elements, physically manipulating equipment on their own. Instead, they sit in climate-controlled cockpits. Their work is to monitor digital gauges that control automated functions on the actual rig. Reinventing the job this way allows for some of the driller’s tasks to move to a centralized control center that can monitor multiple rigs at one time by using enhanced sensing equipment and AI that can predict future maintenance events or likely variances in performance. This creates more consistent operating performance. The driller is no longer the only decision maker determining when and how to perform maintenance, because sensors and AI provide specialized maintenance crews with the information to know the optimal schedule and type of maintenance. The job of a driller has been reinvented and is now more mental and interactive. The work is more variable, because automation handles the repetitive parts, saving the human driller for the unique situations.
Table 1-2 shows a sampling of the activities or tasks of the driller following job deconstruction. It classifies the various activities based on our aforementioned categories and assesses whether the work can be performed on-site or at a remote location. Finally, it details the time spent each day on the particular activity.
As a result of the deconstruction of the role, this organization was able to clearly identify how to optimize the application of automation and understand how it would transform various activities. Table 1-3 details the output of the deconstruction, automation, and reconstruction of the driller’s work. Automation will shift minutes of work to other roles, augment activities, eliminate them, or create new activities.
Transformation of the driller’s role as a result of automation
Minutes to perform task (based on 12-hour shift) |
|
Current state of driller’s work activities |
720 |
| Change due to adoption of AI and robotics | |
|
(62) |
|
82 |
|
(65) |
|
45 |
Future state of driller’s work activities |
720 |
As you can see from this example, deconstruction is a critical first step to understanding how to apply automation to transform work. But, the exercise is not merely one of deconstructing jobs to identify substitution or augmentation opportunities; the exercise also reveals new work from automation. Analysis begins with understanding the problem to solve. In subsequent chapters, we detail our framework in which the category of “creating new work” reflects two kinds of problem solving:
- Imagining work that cannot be conceived without combining humans and computers.
- The redefinition of the goal as solving the problem because automation allows a close connection between the work and the user’s problems. (We will illustrate this in greater detail in chapter 5, when we explore the organizational implications of automation and discuss the intriguing case of Haier.)
A recent article reinforces our idea that the opportunities from automation go beyond the mere substitution of human labor at the task level but instead create opportunities for a more expansive rethinking of work.4
We’ll now delve deeper into how automation has played out across other aspects of the natural resources value chain and present some case studies. Table 1-4 summarizes how automation has changed several jobs in the natural resources extraction industry, with an actual case study of each change. The first example is that of the oil driller; the same patterns emerge in the work of related jobs across the industry, described in the other examples.
Reinventing jobs is a vital factor in connecting work to the strategic organizational goals and operational aspirations of technologists. Pioneer Natural Resources, a US oil and gas producer, achieved the strategic and operational goals of reducing the required days to drill new wells so drastically that it cut costs by 25 percent in wells completed. In 2015, the company added nearly 240 wells to the Permian Basin in Texas without adding one new employee.5 That required reinventing jobs, as shown in table 1-4. Such reinvention, guided by work deconstruction, is essential to meet the strategic challenges of a highly competitive and cost-pressured environment and the goals of increasing profits and adjusting to price volatility.
What started with simple remote-controlled machines to improve operating control and reduce variance has evolved to encompass integrating work with sensors, automated analytics, and AI-enabled machines that adapt to changing conditions. The work must similarly evolve and be reinvented.
The Long History of Job Deconstruction
In the 1990s, business process reengineering challenged the fundamental underpinnings of specialization in jobs that had characterized organizations for more than a hundred years. In his seminal Harvard Business Review article, “Reengineering Work: Don’t Automate, Obliterate,” Michael Hammer, the father of reengineering, said,
The usual methods for boosting performance—process rationalization and automation—haven’t yielded the dramatic improvements companies need. In particular, heavy investments in information technology have delivered disappointing results—largely because companies tend to use technology to mechanize old ways of doing business. They leave the existing processes intact and use computers simply to speed them up . . . But speeding up those processes cannot address their fundamental performance deficiencies. Many of our job designs, work flows, control mechanisms, and organizational structures came of age in a different competitive environment and before the advent of the computer. They are geared toward efficiency and control. Yet the watchwords of the new decade are innovation and speed, service and quality. It is time to stop paving the cow paths. Instead of embedding outdated processes in silicon and software, we should obliterate them and start over. We should “reengineer” our businesses: use the power of modern information technology to radically redesign our business processes in order to achieve dramatic improvements in their performance.6
What is often overlooked is that the earlier breakthroughs in process reengineering also relied on job deconstruction, work reinvention, and even the integration of work and automation, albeit using far more rudimentary automation tools than we have today. (See table 1-5.) The following example from Hammer’s article illustrates this beautifully. Hammer referenced the great success Mutual Benefit Life (MBL) had from reengineering its application process:
Mutual Benefit Life, the country’s eighteenth largest life carrier, has reengineered its processing of insurance applications. Prior to this, MBL handled customers’ applications much as its competitors did. The long, multistep process involved credit checking, quoting, rating, underwriting, and so on. An application would have to go through as many as 30 discrete steps, spanning 5 departments and involving 19 people. At the very best, MBL could process an application in 24 hours, but more typical turnarounds ranged from 5 to 25 days—most of the time spent passing information from one department to the next. (Another insurer estimated that while an application spent 22 days in process, it was actually worked on for just 17 minutes.). MBL’s rigid, sequential process led to many complications. . . For instance, when a customer wanted to cash in an existing policy and purchase a new one, the old business department first had to authorize the treasury department to issue a check made payable to MBL. The check would then accompany the paperwork to the new business department. The president of MBL, intent on improving customer service, decided that this nonsense had to stop and demanded a 60% improvement in productivity. It was clear that such an ambitious goal would require more than tinkering with the existing process. Strong measures were in order, and the management team assigned to the task looked to technology as a means of achieving them. The team realized that shared databases and computer networks could make many different kinds of information available to a single person, while expert systems could help people with limited experience make sound decisions. Applying these insights led to a new approach to the application-handling process, one with wide organizational implications and little resemblance to the old way of doing business. MBL swept away existing job definitions and departmental boundaries and created a new position called a case manager. Case managers have total responsibility for an application from the time it is received to the time a policy is issued . . . Unlike clerks, who performed a fixed task repeatedly under the watchful gaze of a supervisor, case managers work autonomously. No more handoffs of files and responsibility, no more shuffling of customer inquiries. Case managers are able to perform all the tasks associated with an insurance application because they are supported by powerful PC-based workstations that run an expert system and connect to a range of automated systems on a mainframe . . . In particularly tough cases, the case manager calls for assistance from a senior underwriter or physician, but these specialists work only as consultants and advisers to the case manager, who never relinquishes control. Empowering individuals to process entire applications has had a tremendous impact on operations. MBL can now complete an application in as little as four hours, and average turnaround takes only two to five days. The company has eliminated 100 field office positions, and case managers can handle more than twice the volume of new applications the company previously could process.7
TABLE 1-5
Reengineering versus deconstruction
Notice how the strategic goals that motivated reengineering (cost, reliability, and efficiency) require reinventing the job of case managers and the other related jobs. Notice how process reengineering required reinventing the job by first deconstructing it and then moving some parts to automation (PCs and early databases), keeping other parts as they were, and adding new work that requires taking full accountability of the case process.
The point is that virtually all organizations have used process reengineering for a long time. That very likely required optimally deconstructing and reinventing jobs. Today, such strategic reinvention could use more advanced automation tools. We might use RPA and AI for most of the data gathering, analysis, and processing, leaving the case manager to review the automated recommendations. Instead of building expensive databases and networks to integrate all data into a single source, the combination of RPA and AI could automatically gather data from multiple independent data sources and apply pattern recognition to analyze structured and unstructured data through natural language processing.
However, whether in process reengineering or automation optimization, the fundamental role of work deconstruction and reinvention is very similar. If your organization has done process reengineering, it has very likely done job deconstruction and reinvention. Now, you can tap those capabilities in service of optimizing work automation, just as they were used to optimize process reengineering.
Deconstructing jobs into work tasks reveals the essential work patterns to optimize automation. The 2017 Willis Towers Watson study of the future of work identified deconstruction as one of the top two future opportunities to enhance organizational readiness for automation. However, deconstruction to identify automation compatibility is just the start. A second vital question asks what payoff work automation can produce. That question takes those same deconstructed job tasks and identifies the value of improved performance. That’s the topic of the next chapter.