Capturing the Flow of Information

Business901 Podcast Transcription
Implementing Lean Marketing Systems

Capturing the Flow of Information
Guest was Ben Graham

Related Podcast:
The Granularity of Process Mapping

Sponsored by

Copyright Business901


Ben B Graham has been helping
people make sense of their processes
for over thirty years. He is President of
The Ben Graham Corporation and
author of the book ‘Detail Process
Charting: Speaking the Language of
Process’ published by John Wiley
Publishers. His company pioneered the
field of business process improvement,
and since 1953 has provided process
improvement consulting, coaching and
education services to organizations across
North America. Ben has worked with many
organizations to fix process-related
problems, build process libraries and develop
effective, process-focused, continuous
improvement programs. His organization
publishes Graham Process Mapping Software,
which is designed specifically for preparing
detail process maps.

You can find out more about Ben and the Graham Process
Mapping software at http://processchart.com.


Transcription of Podcast
Joe Dager: Welcome everyone. This is Joe Dager, the host of
the Business 901 Podcast. With me, today, is Ben Graham. He
has been helping people make sense of their processes for over
30 years. He's the president of the Ben Graham Corporation and
author of the book "Detail Process Charting," published by John
Wiley. His company pioneered the field of business process
improvement, and, since 1953, has provided process
improvement consulting, coaching, and education services. Ben
has worked with many organizations to fix process-related
problems, build process libraries, and develop effective process
focus continuous improvement program.
His organization publishes Graham Process Mapping software,
which is designed specifically for preparing detail process maps.
Ben, thanks for joining me and I would like to compliment you in
this world of technology. It is refreshing to see a niche developer
that has successfully survived through the years.
The obvious question is. How did you do it?
Ben Graham: Well, thanks Joe. I think it's because we have a
product, something that's very reality based and it gets the job
done. I'm a the third generation in my company to do this work
and its work that was-- the principal tool we used was developed
by my grandfather. It's as applicable today or maybe even more
so with so many processes kind of hidden in electronics. It's very
applicable. It gets down to the fundamentals of process work and
we get a chance, by applying this tool, to see what's in a process
and it makes it clear enough so we can make intelligent decisions
about it.
Joe: I think there's sometimes confusion about process
mapping. Tell me what process mapping is and isn't.


Ben: There're a lot of different types of process maps that you'll
see out there. Process mapping is laying out a process flow. A
process is a series of steps that accomplishes a specific task. A
process map lays those steps out. When I say that there're a lot
of variations, the variation comes at the level of detail that those
maps have. You may have a process map that's got two or three
steps in it to lay out a process where another one will have 150
steps. That's a level of detail situation.

Quite a few, if you did a search on process maps--a Google
search on process maps--you'd - -, you'd see thousands and
thousands of maps. Many of them are displayed on a single 8.5 x
11 page. They're very high level. They give you an idea of what's
going on in the process and that can give you some focus points.
But a detailed map, which is the kind that I've used, identifies all
the documents in a process. By document, I mean the forms,
emails, spreadsheets, systems, anything that conveys
information. It lays out all the documents and lays out the depths
of what each one of those does and how they relate to each
other, how information from one is used on another.
With that kind of information, you can make decisions about each
of those documents. That's a difference between the high level
and the detail map.

Joe: When I look at process mapping, I think a lot of people
think of Visio or, like you just mentioned, a lot of this stuff out on
the web. This is not really what process mapping, more
specifically your software, is about, is it?
Ben: That's right. Most maps are probably drawn with Visio.
Visio comes with a lot of different shapes and such that you can
use to create whatever you want. Unfortunately, when people are
doing that they're reinventing the wheel and they're usually doing
something or often doing something that's not going to be
repetitive. They're not going to be able to use it again. Somebody

else will see it and they'll probably start with something different.
There are a lot of variations on what's sometimes referred to as
the box and arrow method, which is a box, arrow, diamonds for
decisions. Then sometimes people insert their own symbols in
there.
Joe: When you mention all the different shapes and everything
and the consistencies of having that common shape, it makes it
much easier for people to understand and share, doesn't it?
Ben: Well, the problem is they have to invent the method they
use every time. Is the flow chart going to flow left to right to
indicate changes through time? Is it going to go up and down? Is
it going to go around in circles? Is a phone call represented by a
box or is it represented by a telephone? Who knows? If there's
not a consistent method behind it, it's going to change and
people are going to have trouble following it down the road. I
think that's the biggest issue with Visio and other programs like
that is that they're great for drawing a one-time picture of
something, a diagram of something. But for process work, we
want to have some kind of structured methodology behind it, and
there are several.
But with Visio and other diagramming packages, you have to
bring your method to the table. You have the symbols there, and
you have to figure out how to put them together and which ones
you want to use and so forth.
Joe: I always think process mapping seems to get identified with
Six Sigma and value stream mapping with Lean. Why is that and
what's the difference? Can we maybe do a process map before we
do a value stream?
Ben: Process mapping has been around for a long time to help
people understand processes. It originated near the turn of the
last century in manufacturing with what was called a flow process
chart, which was a tool that manufacturing, machine shops and

so forth, used to follow the flow of a part through its
manufacture. Very powerful tool and that is what has evolved into
the detail charting that we use. There is no reason why we can't
do a value stream map and a process map. As a matter of fact,
the value stream map gives you a high level view of what's going
on in the manufacturing environment, typically. That's where I
have found them to be most useful.

They identify where information flows are. If you have some
questions about that information flows, that's a great opportunity,
then to use a detailed process map to see how that information is
flowing through the shop floor, also from the office to the shop,
or wherever the flow is and whatever media it is using.
You can get the details of that. Is it electronic and it's sent to
terminal or it’s printed out and then hand walked over
someplace? Or is it a piece of paper that is walked out and
handed to somebody? All of these details of the process flow can
be seen with a detail map, and that just adds more value to the
analysis.

Joe: So you're saying a value stream map is done first and then
the process map adds a granularity to it.
Ben: In a case where a value stream map adds value, which is
in a manufacturing environment, I don't see the same value if
you were doing work principally in the offices or in a service
organization. It could be, but that not where I've seen its value.
I've seen its value in the manufacturing. Yeah, that's what I
would say.
Joe: Why doesn't everybody use detailed process mapping?
What stops them from using it?

Ben: There're a few reasons. The biggest one is that most
people don't know about it. They don't know that there is a
structured method that is available for doing that. Another one is

that you have an opportunity to draw a map that takes up a page
and another map that takes 15 feet of wall space. There're two
ways to look at that. Which is going to be easier to create and
which is going to be easier to work with? A lot of people will opt
the shorter, simple map. But, unfortunately, that's not going to
give you the kind of information you need to make intelligent
decisions about the process. It's going to guide you in the right
direction, possibly. But then you have to dig down to get the
details.
Whereas the detailed map, it identifies every occurrence of
information change in the process. You're able to pinpoint right
there on the map what you have to dig in and try to figure out
without a map if you just used a simpler, high-level map.
Joe: So is this something that I should blow up on a wall and do
this process map, or do I use this software to copy all the sticky
notes I put up on a wall?
Ben: When we collect data, it is similar to value stream
mapping. You want to walk the floor and capture the data. You
don't want to bring people into a room where they're away from
the day-to-day work. You want to go out to the floor or to the
desk where the people are working to capture the data so that
you don't overlook those non value-added type of tasks that
people tend to forget away from the work. They tend to focus on
the value-added steps, "I take this document and I update the
system," something like that. They tend to overlook the fact that
they have to refer to a standards book or they have to make a
photocopy or they have to go down the hall to do something. All
these things are the non value-added steps that we'd like to get
out of the process as much as we can.
Joe: Outside of attending a workshop, what is the best way to
introduce process mapping software? I find that most software


that there is this big stumbling block, a barrier to jump into the
fray, per se. How would you recommend getting started maybe?

Ben: There is a lot of information in the Internet and,
unfortunately, it's hard to sift through, because there's so much
stuff and so many different ways to approach this. But if you
really want to understand, pick a method and look for information
on how to collect the data for that method, how to string symbols
along, and try to get a... What you want is a solid methodology
behind the mapping that you choose so that it's repetitive and
that people can come back in two years and review the same
process, understand what it is, and it can service a foundation for
continuous improvement to keep getting better year after year.
Joe: Process mapping is very much doing current state, future
state type work, right?

Ben: Absolutely. You want to have a picture of what's going on
now, and then you tap into the experience of the people who do
the work. You sit them in front of the map that you've picked, the
current state or the as-is process that you've documented and
step through it, step by step. Another reason why the detailed
map is valuable, because you can say...You're asking them a
question about putting a document into an inbox or making three
copies of it that get distributed, and so forth. They can make
those kinds of decisions.
You do the same thing with a higher-level map. You've got to dig
into the step, which is really a function, and it doesn't break it
down into the specific documents and tasks that you're doing with
those documents.
Joe: How do I know how much detail to put in a map?

Ben: The way that we approach that is that we've got a set of
eight symbols that describe this kind of work that's going on.
Basically, it's the type of work whether you're doing work, you're

checking work; the work is moving from one location to another,
or it's just sitting there doing nothing. A step which, by the way,
is not included in a lot of methods. If the step activity changes
then you want to put in another symbol. Also, if, for instance,
you're updating a system and you're using a document to do that
and then you use a different document, so you have a different
source providing information. Well, there's a situation where you
have two steps that are both a value added step, but they're
concurrent because you're using different information to input
them. Same thing if you had a different person doing the work.
So, when something, the person, the source document, or the
type of work changes, we want to capture that. If we do that,
we'll have a pretty detailed map that anyone who's involved in
that work can understand well enough to make intelligent
decisions about it.

Joe: What's the limitation of process mapping? Can I put
everything about the process on a document?
Ben: There are certain types of activities that occur. For
instance, a meeting where people go get together as a group and
make some decisions about something that's occurring in the
process. Which, to capture the details of that, would be very
difficult because it could change every time they have a meeting,
the next item that passes through that process could be handled
differently. Situations like that, we handle with a convention
that's called a stop/start. We put in some information about that
that just says, "This is a meeting going on," and then whatever
the results of that meeting are, a report or something; we pick
back up there.
Joe: The way you describe process mapping to me, this is a very
live document. It's something that I actually work with.
Ben: Well, if you're not using it then it has no value and it was a
waste of time. These things can be used, too, for training. If you

have a new manager come in they need to understand what's
going on in their area, they can use it. It's used for development
of systems that support the process. They can see where all the
information changes are. It's easy to dig in and find out
specifically what information has changed. If you know where
they're happening and what documents they're happening with,
it's easy to figure what's going to be needed for the development
work.

Joe: In this process mapping and service work and some of the
service design type things that I get involved with, there's a lot of
interest in customer journey maps or service blueprinting, as
they're called. Can process software be used for that?
Ben: We don't get into the emotion aspects of a customer
journey map, but we do capture with a process map all the touch
points where a customer is directly involved in a process, whether
it's an internal customer or external customer. We have a detail
process map, captures all the players in the process and where
their touch points are. From that aspect, they're comparable. But
I think that, once again, they could work together.
Joe: You're saying you can capture the touch points, the front
stage actions, the back stage actions, and maybe even some of
the support processes. But you're lacking the empathy side. Is
that a fair way to say it?
Ben: Yeah. We're capturing reality, regardless of how people feel
about it when we're doing an as is process. We're capturing what
happens. Now, when we get into analysis and we want to
improve the process, that's where having that other map can
provide some input possibly. We find out where the hurt points
are and that can give us some focus on where we want to make
some changes.
Joe: Now, you have a workshop coming up. I think it's October
17th through 19th. Can you tell me about the workshop?

Ben: Well, the workshop is designed for facilitators, people who
want to draw process maps and guide teams of people that work
on the process to improvement. It's just a couple days so it's a
pretty hands-on, intensive course. But we teach people how to
map. We go through, spend a whole day on drawing process
maps. Then we go through a case study, guide a person through
the process of setting up the projects, drawing the map for the
project, putting together a team, going through analysis,
preparing a proposal, and then implementing. It's a lot of
material to cover, but it really helps to prepare a person to do
this work for themselves.
Joe: When we talk about the team concept in process mapping,
is that how a process map should be done? Should we be
throwing this up on a big screen and walking through it with a
team?

Ben: I prefer not to put it on a screen because you limit what
you can see. I've done it that way before and if that's what we
have available, that's what we used. But what I prefer to do is
print out a map. If you don't have a plotter available to print out
a 15 foot or 20 foot long map, you can usually go down to a local
Kinko's or something place like that and get one printed pretty
easily. You put the entire map on the wall and that way people
can walk through it and you focus, when you're doing your
analysis you're focused on just one step in one small section of
the map, but you can see how it can affect the rest of the map.
That's the value you get when you put the whole chart up at
once.

Joe: The Ben Graham Corporation, then, is probably just as
much about teaching and developing learning atmosphere than it
is just about software.

Ben: Absolutely. When we were founded, my grandfather was
working for Standard Register back in the '40s when he


developed this method. They actually spun him off to start
teaching people this method on his own, under his own name, to
put it at arm's length from their sales force. They didn't want it to
come off as a gimmick. Since 1953, we've been offering training
courses in this. The training has naturally led to some coaching
and consulting work. The software is a relative newcomer to our
mix, but we introduced it in 1990.

Joe: One of the problems I have with software and why, even
though I'm somewhat of a geek, I shy away from it a little bit, it's
because people think they're going to get a software to solve the
problem, but the problem still exists after buying the software.
Ben: Absolutely. We try to impress on people that our software
is a tool like Word or Excel, but it's specific for doing processes.
When you print out a chart, people tell us, "Well, it's not pretty.
I'd like to make this font bigger and I'd like to be able to add
these things to it." That's not our purpose. Our purpose is to
create a consistent tool that people can use to understand and
analyze a process. I encourage them to print it out, to mark it up,
to use it as a tool.
The software's not going to solve their problems, but the people
who learn how to use it well are. Learning how to use it well as a
big part of that for process mapping is learning how to gather the
data. Once you've gathered the data, drawing the chart is a
relatively simple task.
Joe: What would you like to add that maybe I didn't ask about
Ben Graham Corporation or a process mapping?
Ben: Our company has been a pioneer in this field. What we do,
our software is based on our methodology. It's the principle tool
behind our methodology, but it's really the method, and sticking
to the method that helps a person take an improvement project
from beginning to end. Knowing how to set up a project, and then
making sure everybody's aware of what's going on. Most

importantly, this is finally starting to come into the mainstream,
but tapping into the experience and ingenuity of the people that
do the...essential for a good process. That doesn't mean that
they're going to come up with all the ideas, but they know the
work, they know the details of every step in a process, far more
than a single symbol is going to show.
You'll have to invite IT or developers in or vendors in when the
idea is that when it looks like what we need to do is change the
way we're doing the work. But you also need to have the
experience there to understand what really has to happen to the
work in order to get the job done.
Joe: I think this is the reason you've stuck around so long is that
you really look at how you change the way people do their work.
You look past just putting a product out to that person. You
actually work with someone to change the way they do their
work. I think that's the key.
Ben: Well, we take the focus off the person and put it on the
work. Then we ask them about it. It's just amazing, we often
hear about people's resistance to change. I rarely encounter that.
The reason is that people aren't so much resistant to change as
they are resistant to somebody else telling them how to change.
When you include them in the change process, really include
them, and take their suggestions to heart. They come up with
good ideas; they make the changes, and they buy it. They buy it
because it's theirs.
Joe: I think that's a great way to end the conversation. I'd like
to thank you very much, Ben. How can someone contact you?
Ben: The easiest way would be through the website at
www.worksimp.com or processchart.com, either one of those will
give them information to contact us.


Joseph T. Dager
Business901
Phone: 260-918-0438
Skype: Biz901
Fax: 260-818-2022
Email: jtdager@business901.com
Website: http://www.business901.com
Twitter: @business901

Joe Dager is president of Business901, a firm specializing in
bringing the continuous improvement process to the sales and
marketing arena. He takes his process thinking of over thirty
years in marketing within a wide variety of industries and applies
it through Lean Marketing and Lean Service Design.

Visit the Lean Marketing Lab: Being part of this community will
allow you to interact with like-minded individuals and
organizations, purchase related tools, use some free ones and
receive feedback from your peers.

Marketing with Lean Book Series included in membership

Lean Sales and Marketing Workshop

Lean Service Design Workshop


Capturing the Flow of Information

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Mehr von Business901

Mehr von Business901 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Capturing the Flow of Information