THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Published in TDAN.com October 2001

[The following is an excerpt from an early chapter from the book titled Workflow Modeling: Tools for Process Improvement and Application Development, by Alec Sharp and Patrick McDermott, copyright 2001, Artech House Publishers. A link to part two of this article appears at the end of the article.]

Introduction

This excerpt from a chapter in our book covers how to build an as-is workflow model. You need techniques to get started (which is often the hardest part), to maintain progress (avoiding inappropriate detail and distractions), and to validate the model. It is not as simple as just grabbing a pen and starting a diagram.

The first part of this article will cover items 1 & 2 below. The article in it's entirety will progress through:

1. Building the team
2. Organizing and initiating the modeling session
3. Getting started by building the handoff (level 1) model
4. Adding detail with a flow (level 2) model
5. As necessary, developing a task (level 3) model, and even doing some task analysis if the situation warrants it.

There is no one right way to proceed - every situation is different, and each analyst has different strengths. We will provide solid frameworks, but you will need to augment and adjust to suit the situation. The right technique is the one that works - produces the necessary model without having to quell a rebellion.

Difficulties can and will arise - these will be dealt with in the next chapter. Two bear mentioning now, because they come up so often, and they are so important to our philosophy and approach.

Issues at the extremes

Many teams encounter at least one of two issues, the extremes of time spent on as-is modeling – too much, or too little (or even none).

First and foremost is getting the as-is workflow model done within your (and the project’s) lifetime. We could tell a horror story here - the 167-foot-long as-is model that consumed all of a project’s time and resources, resulting in the cancellation of a promising project. Many projects fail because the team gets bogged down in detail and runs out of time and the project dies on the vine, or the participants (subject matter experts) get bored and/or frustrated and stop participating effectively. The problem – each additional level of detail begets more detail which begets detail. A key concept - we are seeking to understand the as-is, not document it in excruciating detail! You will want to quickly build a first level (handoff level) workflow model, and then add controlled amounts of detail, one level at a time, but only if a gating checkpoint is passed that confirms the need for additional detail.

Second, at the other extreme, is getting started at all. There may be pressure to skip as-is modeling altogether, as suggested by some of the early books on BPR (later ones recognized that this step is essential). Experienced project leaders and analysts usually do not object. Resistance typically comes from the extremes: senior managers or detail-oriented technicians. Fortunately, this happens less often now. People who have skipped the as-is step have been burned, and now recognize that it is essential, even if they’re not thrilled about it. The two most common reasons: They think, “Hey, we all know how this works,” or “Why waste time mapping a process that we’re going to replace?”

The point is: we’re seeking to understand the as-is, not document it in excruciating detail, and if the as-is really is well understood, this step will go quickly. Skipping this step is a false economy - experience shows you’ll pay later because:

• You must understand the as-is in order to identify specifically why it behaves the way it does (the good aspects to preserve and the bad aspects to eliminate, improve, or replace).
• It will ensure focus on fact, not opinion, and demonstrate that improvement is possible.
• You will need to establish a performance baseline in order to show improvement and justify the project.
• You need to know who (job titles or actors, and organization) will be affected to get their input.
• You need to know who will be affected to prepare for training, and so forth. This is critical - you must understand current tasks to know if they must be carried out in the new process, and besides, people’s jobs are changing.
• You will also need to thoroughly understand the current process in order to maintain interfaces to other systems and commitments to other processes. This is also critical - there are ALWAYS important interconnections and dependencies that will be disrupted if they are not identified. Similarly, some are useless and might be reimplemented if they aren’t understood.

There are a couple of strategies if there is opposition to as-is modeling. Both rely on the supposition that if you can demonstrate that the current process isn’t well understood, the participants will see the value. As noted, if the current process actually is well understood, this will go quickly.

One strategy is the “please, humor me” approach. Say, “Let’s just spend enough time to see if we’re essentially on the same wavelength.” Get permission to run one session (approximately three hours) to produce a handoff level model, using the cloud diagram approach described subsequently. This session often demonstrates that everyone is not on the same wavelength about who is involved and what the critical handoffs are. You then have agreement to proceed.

The other strategy is to try to capture important information without formally doing as-is modeling. First, review information from the process frame (you will have to do this anyway). Do we all agree on the event and result that frame the process? Do we agree on the main milestones between the event and the result? Have we accurately listed all the actors (the people, organizations, systems, and so forth) that have a role in achieving those milestones? Does anyone else contribute or have a stake? When everyone is on board, ask a few key questions:

• Would it be possible to list the main tasks or responsibilities of each of these parties? Let’s try.
• Will anyone else be impacted (i.e., their work will change in some way that must be planned)? How will it change?
• Do we know all the interactions or connections with other processes (inbound or outbound)? Let’s build a quick list.

If the answers to these questions came readily and with agreement, then you probably have enough information that you don’t have to do as-is modeling and you’re not going to convince anyone it is necessary. Usually, though, these questions raise differences of opinion and there is agreement to do at least a little as-is.

Assembling the team

Give some thought to team diversity. A mix of perspectives is crucial to accuracy and progress. Otherwise, results will be skewed, crucial activities will be missed, and you will keep hitting a wall when you don’t have the right person to answer a question. The participants must be able to work together in a group session. This will take much longer if you try to do it as a series of one-on-one interviews.

Participants must include representatives from all relevant organizational units or areas, which might be defined by organizational structure or functional area, by geography, by product line, by customer or market, and so forth. “Relevant” means they play a role in the as-is process, or directly depend on it in a significant way. In the simple case, you will have representation from each organizational unit that participates in the process, and won’t have to worry about factoring in geography, product line, and market segment. Good luck!

Participants should include management or supervisory personnel and front line workers or individual contributors. A common reaction: “Oh, no! Not all at once, they can’t work together!”. Well, they do in other successful organizations, and besides, they have to, or process improvement will fail. Both perspectives are essential, and in our experience, each group always learns from the other. Individual workers learn from each other what other areas do, what the interdependencies are, and they learn from management about the organization’s issues and direction. Management learns what really happens at the front lines now (as opposed to 5, 10, or 15 years ago) and what issues or obstacles their people face. It may initially be uncomfortable, but the facilitator (which is you if no one else fills the role) and the structure imposed by building a model help everyone to participate. Working on an as-is model has proven so successful at improving communication, developing a broader understanding, and team building that we have recommended it even when the process doesn’t apparently need improvement.

Participants should include customers and suppliers. A common reaction: “Oh, no! We can’t let them see how bad the process is!” They probably already know, and besides, they almost surely know some things about the process that you don’t. Sometimes the customer did substantial work that the internal process performers were not aware of. The customer might ride herd on the process or act as the tickler file to ensure that things keep happening. Other times, the customer carries out handoff and transport activities. A personal example: I contacted the dealership when a major home appliance failed, and they provided me with paperwork for the authorized service organization, which in turn provided me with paperwork for the local repair agency. I can attest this was an opportunity for delay, error, and frustration. Customers and suppliers may be internal to the organization, or external to it. There is the most reluctance to including external customers, suppliers, or other trading partners, but in the age of e-business and e-commerce, where business processes cross the firewall (i.e., organizational boundaries), it is becoming a fact of life.

In general, everyone who touches the work must be involved. This might involve, for example, IT staff. Computer systems, especially batch processing, may play a critical role (add value, move the work along, or introduce delay). IS or IT representatives should therefore participate, although with the caveat to stay out of eye-glazing detail. (A long, complex batch job stream should be mapped out in a separate session – IS only.)

Major process improvements have been accomplished using modern enterprise application integration (EAI) tools by linking batch (and other) steps in real time. There are even cases where IT staff performed significant, daily “babysitting” of systems, such as watching for exceptions, revising or correcting data, or routing work. As before, they should participate in the sessions, with the same caveats: no eye-glazing detail.

Preparation

We don’t want to turn this into a book on facilitation or project management, but here are a few miscellaneous points and guidelines.

Team organization

The sponsor, or the sponsor’s chosen representative, is critical. One key role for the sponsor is to help to identify and secure participants. You probably won’t have the pull on your own to obtain the necessary release time.

Generally, a project is organized into the core team, full time, responsible for all aspects of running the sessions including preparation, facilitation, and documentation. You will need a project leader plus one or two people acting as process analyst, and one or two people with broad subject matter expertise. You’ll also need participants representing various areas, whose participation level will vary with area or level of detail.

Scheduling

How long will it take? The short answer is: “Longer than you think.” A process with 10 or 15 actors, and scores or hundreds of steps, will not be mapped in one 3-hour session, more like three to five half-day sessions. Full-time availability of the participants (content experts) is ideal, but unlikely. Everyone is busy these days, and full time may be more than you can use anyway. Realistically, two to three sessions per week, each lasting half a day (the morning is preferable), are a realistic goal.

Facilities

This item can make a big difference. A dedicated room is hugely beneficial – you can leave materials up, have core team meetings on site, avoid distractions, and so forth. Cramped rooms produce cramped results. Ideally you will have a room that allows participant seating in a wide U or semicircle. Allow no energy holes - you will want participants as close together as comfortably possible, with no empty chairs. You need large whiteboards at the front (the open side of the wide U). Walls of whiteboards are the best. You’ll need good air circulation and climate control, and plain side and back walls (no pillars, windows, artwork, and so forth) to allow posting of material. If there are windows, they should be at the back. Interruptions are a problem, so you will need a way to control e-mail and voicemail time.

Supplies

In addition to a PC for documenting results, you will need:

• Flipchart pads;
• Pens (whiteboard and permanent);
• Butcher paper or other wide roll of paper;
• Big Post-Its (“yellow stickies”).

Starting the modeling process with a facilitated session is the most workable approach – it’s hard to abstract behavior into a model while observing it. However, always finish by confirming your conclusions through direct observation. The usual cycle is:

1. Plan.
2. Hold a team session.
3. Do field work (interview and observe).
4. Back to step 1, and repeat as necessary.

Part two of this article will appear in the next issue of TDAN.com. In the second part, Alec and Patrick will cover the building of the handoff (level 1) model; adding detail with a flow (level 2) model; developing a task (level 3) model. Part two of this article can be now be found at http://www.tdan.com/view-articles/4970.

Order this book through Amazon.com Today!