We ended up last time with a simple map that showed, basically, where stuff gets moved, where stuff gets something done to it, and where stuff sits waiting to be moved or have something done to it. So, we’re off to a good start. Now, we need to add some boxes and arrows that show where information moves or sits or is acted on.
OK, so enough talk about boxes and arrows and lets put something on paper. We have a couple of decisions to make before we get started. First, we need to decide just which process to map. It might be that all the products in your operation go through the same process; that makes it easy to decide which process to map doesn’t it? In most cases, though, different products go through different processes. So, you have to pick one to map. (In many cases, you’ll have groups of products that go through a similar processes. If that’s your case, think of creating a process map for a group of products.) Now, I’ve read books that recommended an approach to picking a product or product group to map that involved lots of data gathering and calculations before making a decision. I don’t think it’s that hard. All you have to do is carry on a discussion that addresses these questions:
- Which products/product groups are high volume?
- Which products/product groups are high margin?
- Which products/product groups are important for some other reason, e.g., important new product?
- Which products/product groups are giving us the most problems?
If you have a product/product group that hits two or three of these criteria, go with that one. If none of your products hit more than one criterion, pick whichever product you want to start with, then move on to the others. Then do like we said last time, start with the customer and discuss their needs and the outputs that meet those needs. Then talk about the suppliers and your standards for what they provide.
OK, now you’re ready to connect those boxes and arrows.
Take a look at this example of 5S. What do you think….good example or not? It sure looks good, doesn’t it? I found this example on LinkedIn, along with some comments as to whether or not it’s a good example. Some of the commenters felt it was a good example given that…well, how orderly everthing is. Others felt that it’s not such a good example and it’s not the lack of labeling that they mentioned. Those others asked if five colors of highlighters are really needed. And two different kinds of Post-Its. And two blue and red pens. After all the first S is “Sort”.
I would agree that the Sort is key here but we can’t use circumstantial evidence to assume it wasn’t done. If the user really does need and regularly uses all those highlighters, then it’s a good example of 5S. On the other hand, if the user generally just takes out the yellow one and keeps the others “just in case”, it’s just an exercise in tidiness. Same with the pens and Post-Its.
The moral of the story is, it’s not just the good organization that makes this a good example. It’s the deliberation that went into the effort along the way
This is a PR video but check it out and catch the reference to Visual Management.
So far, we have a process map with boxes and arrows. There is one more symbol I should have mentioned: triangles. We use triangles as the symbol for inventory. Any place in the process where stuff sits, put a triangle there.
In our last post, we talked about getting started on creating a value stream map. We said that creating a simple process map was a good place to start. Now, I could go through the steps of creating a process map but you and I both know that such instruction are…everywhere. Do a websearch for “how to create a process map” and you’ll get a few million hits. Essentially, you just draw boxes and arrows. Or put the process steps on Post-Its that you place on a sheet of newsprint you’ve taped to the wall. Rather than provide detailed instructions, I’ll just pass along a few hints and recommendations that I’ve found helpful.
I was conducting a short workshop on behalf of an agency I work with and the question came up: What do we do after 5S? The quick answer to this question is that you start to implement pull scheduling and production. The longer answer is that you start to simplify/streamline/improve all your processes, both operations and administrative, and you implement team problem solving.
A tool that ties those two answers together is value stream mapping, so let’s talk about that for a bit.
I just came across a term I wasn’t familiar with: obeya. (I think it’s pronounced o-bay-a, but I’m not certain.) It’s used most often in the term “obeya room”, which is a bit redundant given that “obeya” is Japanese for “big room”. I became acquainted with the term in this Industry Week article…you should read it because it provides several examples as to just what an obeya is and how it works.
Turns out that obeya combines a couple of ideas that we’ve all been on board with: collaboration and visual management. The concept is that you put your most important visual indicators together in one room…then you talk about them every day. Several times a day, in fact.
From the article:
“[The plant manager’s] first stop is the command center. “I can quickly — very quickly — determine if I’m on schedule everywhere or, if I’m not on schedule, where am I not on schedule and why am I not on schedule,” he says. Stop two is any place there is a deviation.”
Now, I’m going to pat myself on the back a bit here. This is, nearly verbatim, what I’ve told all my clients is the primary goal of 5S and Visual Management: to be able to tell, at a glance, whether or not a process or several processes are in control or not.
The real benefit of obeya, though, comes through deliberation and discussion of the data displayed by the visuals. Again, from the article:
“What we try to do is let the management team at the manager level lead the meeting,” Redelman says. “We want to encourage direct dialog between the managers so they take ownership of the condition.” The meeting is most effective, he adds, “when the managers and SMEs are gathered, speaking to each other, and the executive team has faded to the back and just offers suggestion when necessary or helps to prioritize the focus to wrap up the meeting.”
Discussions about lean and obeya frequently emphasize the human element, the need for individuals to physically interact with the data to take full advantage of an obeya’s promise. It’s a point Toyota emphasizes as well.”
Did you catch that? It’s not so much that a company simply posts a bunch of visuals around the walls of a room. It’s that managers and associates actually take time to look at and talk about the information on the charts. And the conversations lead to actions. This is a good example of the needed culture change that goes along with all lean methods. My experience has been that it’s actually pretty difficult to create such straightforward change. We’re just talking about regular, frequent, short meetings, after all. Some companies start them, then they fizzle out for a variety of reasons. Other companies never bother. Both types of companies end up wondering why lean methods never really worked for them. I guess they just figured that charts on the walls would, somehow, magically improve their operations.
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.
In my last post, I went over a few basic guidelines to brainstorming. In this post we’ll address that important question: “What the heck do we do with all this stuff we just came up with?”
It’s true that “figuring out what to do with all that stuff” is something of an issue. Do you now start talking about each and every one of those 32 ideas the team just brainstormed? Do you try to weed some ideas out? Do you take a vote on which ideas the team likes best?
Polling the list at this state works well, in my experience. Polling is a method that visually indicates which of the ideas the team has the most interest in. It looks like “voting”…but it isn’t. It acts as an informal prioritization method that doesn’t so much narrow the list as it does uncover which items the team is most interested in pursuing.
Here’s how it works: Everybody gets three tallies to indicate which items on the brainstormed list are the most important, most interesting, best ideas, most likely to succeeed, whatever. By “tallies” I mean that each team member gets three check marks to put next to the items they’re most interested in discussing. All the team members get out of their seats, read all the items on the flip chart sheets (You did write all the ideas on flip chart seats, didn’t you? Or, at least, a dry erase board?) and mark their tallies
There’s an important twist though: Team members can distribute their tallies any way they like. In other words, they can put one tally next to each of three items, or all three tallies next to one item if they wish. The idea is that if someone feels very strongly about an idea, she can indicate that by putting more than one tally next to it.
But isn’t that “gaming the system”? It would be…if there was a system to game. All you’re doing is seeing what items the team is interested in discussing. If someone is so interested in a topic that she is willing to put all three of her tallies next to it, should the team give that idea some consideration?
Once everyone has completed the task, I usually point out (and, maybe, circle) the items with lots of tallies. I also acknowledge the items with just one or two tallies. You might be able to combine some of the items with several tallies to further narrow the list. In any case, the team likely has a manageable list of items to discuss. I’ve often seen teams decide that the tallied items make a good set of ideas that work together and don’t need to be further narrowed down.
One last thing: I sometimes will give more than three tallies. If the list is a long one or if I don’t want to do too much “list narrowing”, I’ll tell each member they can have five or even more tallies.
You’ll find that brainstorming, followed by polling is an efficient way of getting lots of ideas out on the table and working through them.