Process Reengineering Primer

In a good economy, organizations invest in process reengineering to promote operational efficiency, competitive advantage, market agility, and to improve day-to-day human factors.

In a struggling economy, organizations must also invest as efficiency, competitiveness, agility, and human factors are more vital to business success than ever.

Reengineering business processes is trickier than it sounds. Having an outsider involved can loosen tensions around problems, and help move the reengineering steps in a positive direction.

Process reengineering has three major steps

First, target vital processes. Every business has them. Some have one, some hundreds. Don't boil the ocean. Select a few critical, related processes to start. Then start.

It's typically easy to know which processes to choose. They are very core to the business, involve the most people, span the longest time, and often are the most painful.

Second, get stakeholder consensus on the process as it is today, the "as-is" model. Usually, this is difficult; most workers loosely agree, but individually customize their part of the process.

The goal is a model which all (or most) stakeholders agree represent today's process – even at a high level. Moreover, they agree to use it. Simply codifying process like this creates efficiencies.

A codified process helps create accountability insofar as task responsibility. It also helps new employees understand their role systematically, rather than organically.

Third, include management to reengineer the "as-is" model into a "to-be" model. Don't shoot for perfection. Clean up glaring flaws and work to improve day-to-day human factors.

What is a day-to-day human factor? These are process areas that drive people crazy. Things like superfluous paperwork, repetition, duplication, and throw-away, legacy busywork.

Models can be high-level or detailed. Err on the side of high-level. "Adaptive discovery" is a concept to implement the process happy path now and slowly fold in edge cases over time (if ever).

The real world

Having a "to-be" model isn't the same as working the "to-be" model. Once you have a better, more-ideal model ready, it's time to create a strategy to put it into everyday life.

Introducing a "to-be" model is not easy. Here are some tips:

1. Keep it flexible. The "to-be" model isn't perfect, yet. You may need to tweak it on-the-fly; you will disprove assumptions. Have someone authorized to make these changes.
   
2. Open doors. Make sure stakeholders have an avenue to give feedback. They are your best measure to success and the fastest path to failure (user acceptance).
   
3. Remember the pain. Workers won't like this level of change right away. Make it easier by reminding them of the "as-is" problems addressed by the "to-be" model.
   
4. Top down. Getting models mapped is a bottom-up approach; implementing them is top-down. Management must be bought in, and reiterate "this will happen" no matter what.
   
5. All at once. Granted, some existing work will need to complete using the old model. However, pick a date. From then on, no new work follows the old model – bring down the hammer.
   

Use a system

In the software world, Business Process Management (BPM) is the tool family that implements process models, presents tasks, governs adherence, and reports progress. They can be free, expensive, simple, and complex. Whichever you choose, just choose. A BPM can contribute to a "to-be" model's success more than any other factor (other than user acceptance).

Here's where some complexity comes in. An expert should have been used to help reengineer your processes. An expert should be used to integrate a BPM.

I have introduced BMP three ways. As a software architect, I think a lot about how to integrate BPM with systems. To that end, I think these represent the only viable options. They are:

1. Full Integration. We built a line of business system from scratch. BPM was in its DNA. Using the system was using the BPM if the user knew it or not.
   
2. Partial Integration. We extended an existing system. Users interacted with a side-by-side application which also monitored user activity to minimize manual inputs.
   
3. No Integration. We implemented a status tracking system for manual processes which could not be otherwise tracked. Users used task lists to interact with the BPM.
   

Which option you pick will greatly impact user acceptance. Sometimes you only have two choices, sometimes one. You should know your choices, understand the implications, and choose.

Reporting Shangri-La

Workflow nirvana from the perspective of the worker has to do with authority, responsibility, and clarity. But, workflow nirvana from the perspective of management has to do with efficiency, visibility, enforcement, and reports.

Reports in workflow try to answer some common questions:

1. What is making my process slow?
   
2. What could make my process faster?
   
3. What if I made a change like XYZ?
   
4. How are my employees performing?
   
5. What's the current status of ABC?
   

Here's the problem. Reports are at the end. You need data to see trends. So, many organizations feel reports can be shelved for a later date. They are correct. However, most NEVER return to them and NEVER garner the exponential benefits they offer.

If you read nothing else, read this: the myriad benefits of reengineering business process pale to the benefits delivered through back-end reports. Follow the steps above, but don't stop until you have the reports necessary to answer your specific business questions.

Next, I'll talk about agility with BPM and "continual improvement".