Creating a value stream map starts with creating a process map.
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.
I’ve found that, perhaps, the most useful tool for teams isn’t used that much: good ol’ brainstorming. I’m not sure why this is the case. There’s no better tool for getting lots of ideas on the table in a short order. (Actually, I do have a few hypotheses as to why teams don’t use brainstorming more, but I’ll save them for another post.) With that in mind, I’m going to review some guidelines for team brainstorming.
Quantity NOT Quality
When the team is brainstorming, the idea is to come up with lots of ideas. Lots and lots of ideas. The goal (at this point) is quantity of ideas, not quality. Quality will come later…right now: quantity.
I used to train and facilitate employee teams back at Jones and Laughlin Steel. During the training, I’d have each team brainstorm problems in the department with the intention of picking one of the problems to address as a team. I’d tell the team, “…and we’re not going to go to lunch until you have 150 ideas on these flip chart sheets.” Invariably, the teams thought the task to be any easy one: “Only 150? Heck, we got thousands of problems down there at the mill!” Just as certainly, the teams would struggle once they got to twenty or so ideas. Eventually, each team figured out that wild, crazy, nonsensical ideas were allowed, even encouraged: a team member would brainstorm “Those damn Martians sneak in the plant at night and reset the equipment settings.” That idea and others like it would get added to the list and we always got to 150 “ideas” by lunch.
I rarely set brainstorming targets as high as that. In fact, never. I do use techniques like asking, “What’s another idea?” and waiting until I get one. Or saying something like, “Let’s get a few more ideas to fill up this page.” (This assumes I’m writing the ideas on a flip chart, of course.)
Don’t quit brainstorming after the first few ideas are out there and the group pauses. Keep pushing for a few more ideas.
Don’t Evaluate, Assess, or, even, Discuss the Ideas
Many discussions don’t go well because a “social barrier” to idea generation develops. Here’s the way the “social barrier” works: Jane comes with an idea and everyone else starts evaluating, analyzing, assessing, going over, under, and around it. After twenty minutes of that, no decisions have been made and Bob comes up with a suggestion…which is followed by another half-hour or so of evaluation, analyzation, etc., etc.
Two things happen here:
A lot of time is used up discussing few ideas,
As team members see the gauntlet that ideas are run through, they become reluctant to participate by tossing out new ideas.
Neither of these dynamics are of much help. To overcome them, let everyone know that the most discussion that’s allowed is, maybe, a bit of clarification. But let there be no, “How good, really, is this idea?” type discussion. There will be time for that sort of conversation later. Write the idea on a flipchart sheet and move on.
If It Comes to Mind, Say It
There’s another barrier to ideas that operates in groups…I call it the “individual team member barrier”. Ann thinks of an idea but holds on to it: “Naw, the team will never go for that.” She thinks of another but hold onto it, too: “Seems like we tried that awhile back.” She develops a third idea but is silent again: “I better think that one through. This team really puts new ideas through the mill.”
The team never gets to hear Ann’s ideas because she’s filtering them herself. This guideline is meant to overcome that self-filtering. Crazy idea? Get it up there. Sounds a lot like something that was already mentioned? No problem…write it down again. Exceeds the laws of physics? Who cares?
There are obvious boundaries to this guideline; personal attacks and so forth would, of course, be out of line. But most groups understand that. I’ve never had a team exploit this rule by going too far with it (not even a team back at Jones & Laughlin whose members told me that they had only volunteered in order to figure out a way to get revenge on their supervisor.)
Modify, Change, Tag On, Add to Ideas That Have Already Been Mentioned
Often, a team will become silent simply because everyone is trying to think of a brand new, fresh and novel idea that no one has come close to mentioning. And that stifles brainstorming. Members should keep reviewing the list and be willing to toss out variations of ideas already on it. Arnold sees an idea on the list: “Cellphones provided by the company” and adds “Tablet computers provided by the company”. Roger looks at the fishbone and sees: “High air temperature” as a cause of PVC pipe scrap and adds: “Low air temperatures” and “High humidity”. You get the idea, I’m sure.
The only problem with brainstorming is that it’s not used enough by teams. You can overcome this by always having a flipchart easel an pad or dry erase board at all your meetings…then say, “Hey, let’s brainstorm this!”
The last element of Straighten and See assures that information about the work that is to take place at each location is carried out consistently and effectively. We’re going to discuss three elements of this Straighten and See Component: Visual Display, Visual Metrics, and Visual Control
