Are Your Employees Drivers or Victims of Process Innovations?

The following was first published on the Harvard Business Review.

To stay competitive, organizations need to continually find opportunities for innovation in key processes such as customer service and product development, and adoption of a new process almost always requires the implementation of new information technology. In his 1990 classic HBR article “Reengineering Work: Don’t Automate, Obliterate,” Michael Hammer argued that IT must drive radical process innovation.

Unfortunately, this creates two problems. First, as Hammer argued, these large investments in new IT systems tend to deliver disappointing results, largely because companies tend to use technology to mechanize old ways of doing business. That is, they leave the existing processes intact and use computers simply to speed them up, rather than redesign them from scratch.

Second, they don’t take enough advantage of the innovative abilities of their people themselves. Employees often feel victimized rather than energized by the changes. They’re subjected to retraining, and they have to radically alter their routines, often in ways that they don’t think will work as well. Hammer nonetheless argued for using the power of information technology to redesign a cross-functional process, then deal with the people issues. Though many workers will resist a new process imposed on them, competitive demands need to override resistance. I heard him say, “We will carry the wounded but shoot the stragglers.”

Front-line employees driving change

Hammer’s thinking was very powerful, but I’d challenge that last point. The best way to solve both of these problems — and make innovation efforts stick — is not to impose a new process or technology system, but rather have front-line employees drive the change. You’ll get fewer stragglers, and end up with better ideas — ideas that come from the people who do the work every day and see the most glaring problems. Avoiding a new technology may not be an option, but it shouldn’t come first.

Look at ING, a leading bank in the Netherlands, which sets about process improvement by first getting its employees to recommend changes, ideally in short iterations and with frequent feedback loops, to avoid depleting people’s energy and to decrease the likelihood of going too far down the wrong path.

David Bogaerts and Jael Schuyer are process improvement experts in ING’s IT and operations group. They say their projects are more successful when they follow the sequence of people, then process, then technology. “If you automate too quickly, you don’t find out what the front-line people need,” they explained to me recently. “We stay with manual workflows longer than others. Until you have a clear idea of what people need, you may automate workarounds and waste. For example, we worked with people in our Automating Department to improve their processes (using “Lean” and “Agile” methods), and we are now looking at technology to further improve the processes in ways that will revolutionize them.”

ING acknowledges that it has occasionally neglected to engage workers adequately, with disappointing results. “In the case of a workflow management software project, we bought the tool and told people to use it,” Bogaerts and Schuyer said. “It was technology first, then process, then people, and it didn’t work very well.”

Enterprise implementations

No doubt new technology systems can help bring about dramatic process improvements, no matter how much employees howl about the change. Yet organizations that implement an enterprise system (ERP, CRM, SCM, etc.) frequently underestimate the costs of front-line resistance. The systems force people to change the way they work, and while they eventually adapt, most implementations are delayed, operations suffer temporarily, and revenue can take a hit, as at Hershey Foods and Lumber Liquidators.

Why not tap into their expertise instead of dragging them along? Your investments will be better spent, and your workforce is much more likely to buy into the whole thing. As Bogaerts and Schuyer said to me, when workers identify improvements in their jobs, a new computer system appears as an opportunity to eliminate waste and better serve customers, not as a threat.

Engaging workers as drivers of process changes may seem like it’s slowing things down, particularly in implementing a revolutionary enterprise system. But what’s your alternative? You either pay upfront and get worker ownership and sustainability of changes, or you pay later to get buy-in and overcome resistance. The ride is much smoother when you can have your workers be drivers, not passengers.

Questions: How have you seen organizations use IT to drive process innovation? Were front-line people the drivers or the victims?


Categories: Continuous Improvement, Disciplines, Process Management

Author:Brad Power

Brad is a consultant and researcher in process innovation. His current research is on sustaining attention to process management. He is currently conducting research with the Lean Enterprise Institute.

Subscribe to the blog

Subscribe and receive an email when new articles are published

5 Comments on “Are Your Employees Drivers or Victims of Process Innovations?”

  1. May 24, 2012 at 8:35 pm #

    Victims 100%. Example: org gets a company to build a new piece of software to merge 4 existing systems without improving the overall process and even elimininating the unecessary. As a result, they got a software so convulated program dies due to funding and they revert back to the old software. Operational people have to be consulted and can play very important parts in coming up with a software that improves their jobs and that can expedite work quicker.

  2. May 26, 2012 at 7:15 am #

    Have you seen users engaged in selecting a large software package or in the merger of existing systems?

  3. June 6, 2012 at 6:30 am #


    I’ve read this post a week or so ago, let it simmer, and came back to it today. There were a few points that really resonated with me and I couldn’t really formulate them until now. One is an observation or tip that I’ve found works well for me as I’ve worked to improve processes (or invent those that don’t exist); the other is a observation around the enterprise or large implementations. Both of these issues revolve around one key problem I think a lot of process improvement projects or efforts suffer from – we don’t know what we don’t know.

    The first is the tip. It is what I’ve always called “Manually Automating” a process. For the most part, everyone in my organization is a whiz at Excel, some have some more advanced Excel (VBS, Macros, etc.) skills along with some database skills. Whenever we have to figure out a new process or refine a process (usually dealing with hand-offs between databases or systems), we manually automate it in Excel. If we can modularize it and take a task or process that didn’t exist and make it work, or reduce the time to execute from 2 days to 2 hours, that is a big win. But, what it does more than that is that it gives us a real feeling for how the process should work. We have to iterate, iterate, iterate, but we do that in a real-time working setting. So, when we get to building or buying a package to solve the problem for us permanently (automating it completely), we have a really good feel for what to do. We then know more of what we didn’t know at the start.

    The observation around the large, enterprise-wide implementations really hits on this issue of accounting for what we don’t know. I’ll assert that most people don’t realize that they execute work by executing processes. Processes are how work gets done. In light of that, you can sit down and take them through process mapping exercises, redesign meetings, etc., but at the end of the day, until they really touch that process and understand how it should happen to get work done, they still don’t know what that automated system will require them to do. The “Big Bang” projects that spend tons of time iterating around process design still have those delays you reference, not because of the approach they took, but because of the nature of the humans in the project. I prefer the methodologies like agile or other methodologies that use sprints to get the users touching and interacting with the “screens” quickly. I’ve found that is key for humans to change. Touch, feel it, see how it is going to require you to do what you do now differently in a new process or system.

    Are these most successful approaches you’ve seen? What others have you seen to help impact the real human side of change?

  4. June 27, 2012 at 6:53 am #

    Ron: I agree that methodologies like agile or other methodologies that use sprints to get the users touching and interacting with the “screens” quickly are key for humans to change.Yet companies often implement big software packages that are imposed, such as hospitals or physicians offices currently implementing new electronic health record systems. Are there ways to engage users and introduce more interaction and smaller reversible experiments when you’re implementing a big package?


  1. BPM Quotes of the week « Adam Deane - May 26, 2012

    […] Process Change – Brad Power Engaging workers as drivers of process changes may seem like it’s slowing […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: