The lean tool 5S was conceived and developed in a manufacturing
environment. It is a very effective tool at eliminating some of the most
senseless and aggravating sources of wasted time and energy. It only makes
sense that we would all make the next logical leap and attempt to put the same
practice to work in our office environment. However, most attempts tried to
follow exactly the same practice we learned on the manufacturing floor. So we
organize our cubicle or office room the 5S way but we didn’t save any noticeable
time or eliminate any waste.
That is because our cubicle
work surface is not where we work. It is where we sit, and where we put
reference materials, but our work takes place on our computer systems. It is
the digital system of files, software tools, and communication pathways that we
must 5S if we want to experience real results.
Looking back, “5S” stands for:
• Sort—organize and throw away what is not important
• Set—make limits and establish a place for everything
• Shine—make sure everything is in working order and ready for use
• Standardize—establish standard practices so that the other “S’s” become easier and keeping up with the system becomes automatic
• Sustain—make it an everyday habit to do the above; don’t let things lose their readiness
• Sort—organize and throw away what is not important
• Set—make limits and establish a place for everything
• Shine—make sure everything is in working order and ready for use
• Standardize—establish standard practices so that the other “S’s” become easier and keeping up with the system becomes automatic
• Sustain—make it an everyday habit to do the above; don’t let things lose their readiness
The power of 5S is that it effectively eliminates the waste
associated with not having the right tools or information handy when we need
them. To get an idea, just think about your day today. How much time have you
wasted so far searching through emails for one particular message, digging
through electronic files for information, or battling with software that wasn’t
set up right or wasn’t available? Most of us spend a great deal of our day just
looking for things we need to do our job. 5S addresses that.
So, we figured out that we need 5S applied to our business
intranet more than to our desktops. But there are still many mistakes we can
make that will sabotage our efforts, and no one has put out any guidelines to
direct us around them. Let’s consider a few that are common so we can avoid
those at least.
Don’t make arbitrary decisions, or arbitrarily follow directions,
about locating or moving files or tools
One of the biggest lean or 5S disasters that can befall the office
environment is to arbitrarily start moving files around. Unfortunately, it’s
also one of the easiest mistakes to make.
It sometimes happens when an improvement team is overeager to
organize and doesn’t consider how the files got where they are, who accesses
them, or what connections might be broken if they are moved. Usually, though,
at least one person on a team has the sense to stop the madness and point out
the potential folly.
Most often, we walk into work one day to find all our files gone
when a manager who does not use the files dictates that all of a certain group
or type of file be relocated to a specific drive or folder. This occurs when
that manager perceives that the 5S expectations for the digital system aren’t
manifesting, and that manager decides to force the issue.
The problem we create when we just move a file is the sundering of
every existing memory, habit, digital link, reference, or pointer to that file.
If the file is important, we should assume, because it is usually true, that
someone, a group, or a function has links or pointers to that file. If those
links and pointers are part of an enterprise resource planning (ERP) system, we
probably just ruined a great deal of work and a great many reference links
within the system.
Moving
files is easy. Figuring out why hundreds of people are angry, wasting time, or
why a carefully configured system is no longer functional is hard. Putting
everything back together is also hard.
Imagine
the chaos if some of those files, drawings, specifications, or regulations are
shared with other design centers, suppliers, or test centers outside of your
organization. When their links are broken, how much time and energy will your
teams spend trying to fix that problem? What kind of delays will occur in your
chain while everyone waits? What kind of penalties or expedite fees might that
incur?
Before
moving any files, be very careful to ascertain who uses or needs those files,
and be proactive about communicating a change or updating links before making
the move. It’s the easiest and costliest mistake to make, but one that is also
easily avoided by asking some questions we should be asking anyway.
Standardize very little to standardize easily
One of
the easiest ways to practically standardize the use of file folders across many
functions or responsibilities throughout the organization is not to dictate how
file folders will be organized, but instead to standardize how everyone will
explain how the folders are organized. Standardize how, not what.
There is
no way that any team can possibly predict the best way that any other team’s
information and folder structures—or their own for that matter—can most
efficiently be organized. Determining a good or excellent organization requires
substantial experimentation. Add on the problem of arbitrary reorganization, as
mentioned above, and you can see that it takes time and careful thought to
figure out how things are “best.”
So don’t
try to predict it and dictate it. Instead, insist that every functional folder
make a text document the very first file in the top-level folder. If the
document name begins with multiple zeros, 000FileRules or 0000Folder5S, it will
very likely be the first one in the order by default. That text document shall
contain that function’s rules and guidelines for how the folders within are organized
and named.
When
everyone is accustomed to the standard of finding and reading the rules at the
top of the top folder, there is no excuse for anyone to break from the rules.
There is also no excuse, if the rules are clear, for anyone to be unable to find
the information he needs, even if it is in another group’s folder structure.
Think long-term use, not short-term easy
The
behavior that most sabotages the 5S philosophy toward digital information is
the one by which we keep all of our developing information in a project folder.
Sure, during the project, only the project team needs the information, but when
the project is over, the people who want or need the information often had
little or nothing to do with the project.
So when
we go looking for test data, or supplier agreements, or process capability
studies, we have no idea what project folder to look in. No one remembers, two
years after the product launch, that the XB99 product was developed by a
project code named Fairy Dust. And even if we do ask everyone we know and dig
through old, archived project folders to find it, we don’t know where in the
folder to look. Is it in the engineer’s folder, or the test lab’s folder, or
the project manager’s folder?
Get out
of the habit of keeping project folders. Or, limit project folders to
correspondence records only. Instead of doing what is easiest during the
project, make a habit of planning for what data will be needed, by whom, and
where, after the project is over.
Instead
of associating everything with a project, associate it with that part of the
business that will live beyond the project and to which the information truly
belongs. In product development environments, that association is to the
product.
When the
project begins, open an information file structure for a new product in the
system, detailing how and where it will forever reside. Associate or link
important information that should persist after the project is complete to that
product.
Eventually
some switch will be triggered to identify the product as “released,” meaning it
is in production. When that happens, permission will be required to make
changes to associated information, but prior to that event, it should be just
as easy for team members to update information in the final system as it is in
a project folder.
The habit
of putting the information, in the beginning, where it should live in the end,
automates the 5S behavior for us. It also gets everyone in the habit of knowing
exactly where and how to look for information they need, either during the
project, or years after product launch.
Limit: one
The
second “S” for “set” has two meanings. One is to establish a place where your
tools or information should always be found. The second is to set limits on how
many there are in that location. When talking inventoried components, tools, or
supplies, this makes sense. When we are talking about information, especially
any form of documentation that could be used for or against us in a liability
suit, tax audit, contractual disagreement, or policy or instructions, there
should ever be only one.
One copy
of any “official” information is prudent. One copy of any piece of any kind of
information is smart and efficient. As soon as there are two copies, it becomes
nearly impossible for anyone to be sure she is looking at the correct one.
Make it a
sin to copy information. Make it mandatory to review, comment, edit, or redline
information in-place. Otherwise we create uncountable mistakes, redos,
confusion, duplicated work, and disagreements. We risk corrupting or losing
information when we copy information.
-
Condensed from “5S Your Digital Workspace, Carefully” by Alan Nicol in
Qualitydigest.com
No comments:
Post a Comment