Hit Counter Code

Sunday, June 9, 2013

A new look at 5S in the Office

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
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: