Office Process Mapping

I’ve been working with a client recently as part of an initiative to improve several of its core processes.  This is a non-manufacturing client, so the processes we’re working on are all administrative or “office procedures”.  I’ve done a bit of this sort of thing over the years but have never worked with so many process improvement teams in such a short period of time.  It’s been a regular “office process mapping and improvement boot camp”.

Here are some things I’ve learned over the years and that have been reinforced in my recent experience:

Start with a Project Charter

It’s important that the team start with an energetic discussion of “What are we doing here and what’s expected of us?”  That’s what a project charter is for.  It’s not “getting the form filled out” that’s important, it’s the discussion that takes place that serves to get the team members on the same page.  There are lots of Project Charter formats out there.  Choose one that’s available or design one to match your own needs and circumstances.  There are lots of generic forms on the interweb.  Some are simple, others are pretty complicated.  Whatever works for you.  But, again, it’s the conversation that important, not filling in lots of fields on a form.

Map the Process As Simply as You Can

Choosing the “level” at which the team will map the process can be a challenge.  At too high a level, there can be too little detail, at too low a level, too much detail.  I usually talk about the “2000 foot level”; high enough so that the team doesn’t get into the weeds of describing, in detail, each and every task associated with the process but low enough so that the basic steps are identified.  I’ve found that even fairly complicated processes can generally be captured in ten to twenty steps.

It’s important to map the Current State with the assumption that each step is carried out without anything going wrong.  Teams can get way down into the weeds with respect to all the steps that they undertake when things don’t go right.  So, you present the question:  “How does the process work now assuming everything goes the way it’s supposed to?”  You’ll get to all the bad things and problems later on.  Right now, you just want to get the process mapped, not identify everything that can go wrong.

I use three symbols for mapping processes: a circle for the first and last process steps, squares for all the steps in between, and arrows.  That’s it.  No decision diamonds, nothing.  My experience has been that most of the other symbols are used to account for sub-processes and steps that are made necessary by variances and problems.  That’s not what we want to capture at this point.  That said, I admit that I’ve had to occasionally use decision diamonds in a process map to identify legitimate choice points.  But it’s been very occasionally.  The large majority of the time, two circles and a bunch of boxes and arrows works just fine.

Brainstorm Process Step Variances

A variance is something/anything that goes wrong or might go wrong at a particular step of the process.  For example, variances for the process step, “Ship the product”,  might be:

  • Product doesn’t get shipped
  • Wrong product gets shipped
  • Wrong quantity gets shipped
  • Product is shipped to the wrong address
  • Product is shipped via wrong carrier
  • And so on.

The team brainstorms these variances and the usual guidelines to brainstorming apply.  In other words, don’t get wrapped up in long discussions of each possible variance; just write it down and move on.m  You’ll sort through them later.

One useful parameter on the brainstorming of variances to keep in mind:  The variances should occur at the step being focused on at the moment.  If a variance occurred at an earlier step but is caught or observed at the focus step, it goes under that earlier step.  For example, if the step under focus is “Budget requests are reviewed and approved”, a variance like “Manager submits wrong budget format” isn’t a variance at that step.  The manager submitted the wrong budget format at an earlier step, not at the inspection step.  Variances that occur at the “review and approve” step might include:

  • Review and approval is delayed
  • Incorrect format gets approved

By the same token, be careful of brainstorming variances that are actually desired outcomes of the step.  Let’s imagine that you’re mapping the process for hiring and you’re focusing on the step “Review resumes”.  In that case, “No suitable resumes are identified” wouldn’t be a variance.  Weeding out undesirable resumes is exactly what the step is designed to accomplish.  Sure, “no suitable resumes”  might be a hassle for the organization but it’s not because mistakes or errors took place at that process step.

You’ll find that this step of brainstorming variances creates a lot of team energy.  The members will engage in lots of discussion of the variances, even when you remind them of the brainstorming guidelines.  That’s OK…mostly.  You don’t want to squelch energy.  Let them talk about variances a bit and keep them moving.  So long as the team doesn’t get engaged in “debates” as to whether a variance is a big deal or not or discussions of solutions, you’ll be OK.

Prioritize the Variances

The most useful tool to use initially in prioritizing any brainstormed list is polling. I usually give the team members more than three tallies when polling process variances, maybe five to seven, depending on how many variances were brainstormed.  At this point, you’ll have a good visual as to which process problems are front and center for the team.

Develop Improvement Actions for Important Variances

You’re on the home stretch here.  I put up a good, old-fashioned four column action planning page on the flip chart (Action/Assigned To:/Target Date/Status) and go to the variances with the most tallies.  I ask, “What actions or steps do we need to take to reduce or eliminate this variance?”  There is generally a good bit of discussion at this stage.  Some of the “action ideas” will be pretty broad (“A training program for new hires”) and will need to be broken down into specific tasks (“Work instructions documented for all tasks”).  Others will be more specific (“Purchase new copier”) but might need some preliminary work carried out (“Develop business case for a copier and get three quotes.”)

But, hey, you know how to put together an action plan, right?

Follow Up Meetings

Now, we get to, what might be, the toughest stage of the whole enterprise…following up on all that initial work to actually get something done.  Brainstorming and coming up with new ideas is lots of fun.  Developing standard procedures and getting quotes for a new copy machine…not so much.

The team will need to meet no less often than bi-weekly to make sure that improvement efforts move forward.  In most cases, management will need to actively encourage these meetings.  It gets very easy to cancel meetings or for individual team members to miss meetings because of the regular workload.  Managers need to make certain that meetings are being held, attendance is good, and time frames are being met.

Even after the improvement actions are implemented, the team needs to meet to evaluate their effectiveness.  Six to twelve months of bi-weekly meetings can be difficult to sustain but it’s necessary if you’re to have any hope of creating real, lasting change in your business processes.

 

 

Bad Problem Solving + Dysfunctional Company = Assured Failure: Part One

Industry Week has a series of articles that you should read: Lean and Continuous Improvement: Twelve in 12.  I haven’t read them all yet, but it looks like a good collection.

Right now, I want you to read the first article, “Would Doctor Deming Have Been A Black Belt?”.  It’s more interesting than it sounds, so go ahead…I’ll wait right here.  I’m especially interested in having you read the case study embedded in the article.

On reading the article, I went down to the comments section, thinking I’d read a set of sharp denigrations of the company and the approach to problem solving portrayed in the example.  None of the commenters mentioned the example.  My guess is that Deming would say something like, “Neither Six Sigma nor any other improvement approach has a chance of providing value in this organization until it replaces some managers and significantly changes its culture.”

ANY manager who would put a team to work on order entry, then threaten the team leader with losing his or her job because the costs of the process weren’t reduced isn’t fit for his or her job.  ANY leadership team that would see fit to take advantage of process performance improvement by reverting back to previous performance so as to enable the reduction of capacity, needs to be replaced by the board.  Right now.  We’re talking about a dysfunctional organization led by utterly incompetent “managers”.  There’s no chance that any approach to continual improvement would work under such circumstances.

All this is apart from the bad approach to process improvement carried out by the “black belt”.  But I’ll address that in my next post.

Lean Cuisine gets Lean

I was just reading an article in Bloomberg Businessweek (Nestle Tries a Different Recipe For Lean Cuisine…it doesn’t seem to be on the website yet).

Here’s a line from the article:

A $50M innovation center opening July 22 in Solon, OH should let Nestle try recipes faster.

I’m posting this because it illustrates the primary value of lean methods and tools: shorter cycle times.  Notice that the quote says nothing about developing recipes more cheaply.  It’s “faster”.  Nestle will be able to get more products into the market in a given time period.  And it’s willing to spend $50M to do it.  That’s a decidedly strategic amount of money from which, Nestle hopes, it gets a decided strategic advantage.

Now, I don’t know if any of the money has been spent on mapping and improving the actual recipe development process.  One hopes so.  Spending money on capital isn’t “lean” per se, while process improvement is.

In any case, Nestle recognizes what many allegedly “lean companies” too often don’t:  it’s not about reducing costs or “getting more efficient”.  It’s about increasing strategic capacity.

 

A Good Lean Case Study….Sort of

I found this article (Case Study: VIBCO’s Lean Transformation Journey) while scouring around for lean blogs to recommend.  I was actually hoping for more nitty-gritty as to how the company carried out its transformation but, to tell the truth, it’s mostly the usual “we created a True North and kept it as our guide” stuff.

So, why the link?  Well…this:

“I personally extend an open offer to come to the GEMBA at VIBCO – contact us to request a tour. Tours are typically three hours, preferred Tues/Thursday, the only requirement is that top leader from the visiting organization be present.”

According to the post, VIBCO is in Rhode Island.  I’ve never been there or seen the operations, so I can’t vouch for it one way or the other.  But it’s not every day a senior exec broadcasts an invitation to spend three hours with any yahoo who wants to see his place.  If you get in touch with him and visit the plant, let me know what you find.