Production problem keep appearing and there isn’t information to fix it? Scott Widener offers a way to use what you already have in hand.
By Scott Widener.
One of the first analyses undertaken in most continuous improvement settings are basic data cuts by readily available characteristics, to see if simple patterns emerge. As examples: is production worse in the first few hours of start-up, do problems occur at similar rates across all shifts, is there a consistent error, are some days better than others, and so forth.
Frequently, this sort of simple analysis is quite insightful, because it allows for quick isolation of something to be tracked, and possibly offers a solution. Under best-case scenarios, the solution may be readily available and this issue is addressed as a matter of course, and is never noted. However, the deeper and unexplained problems are what typically morph into “the projects”.
One of the disconnects of “the project” is that at most companies; there are experts who know how to do things, if they know what it is that they have to do. Therein lies the problem that creates “the project”: there isn’t information to guide a solution.
Think of it like sitting at home and the electricity goes out, which is both irritating and inconvenient, but as you sit on the couch in the dark, the question becomes what to do next. All we know at this stage is that it’s dark, that’s not a good thing because it’s putting a stop to the planned activities. However, what we don’t know is if a main line is down, a thunderstorm interrupted the flow, if a circuit breaker tripped in the panel, etc. As such, what is the proper solution? Without information to frame the problem, this remains unknown, and so we continue to live in what is know: sitting in the dark; literally and metaphorically.
In most companies, data is READILY available, but information is not. There are typically thousands upon thousands of pieces of data collected in servers somewhere and file cabinets upon file cabinets of paper documentation, but all of it is data and not actionable information.
One of the ways to fix this situation is to start merging relevant data together, with the help of the internal company experts, to look for “likely sources” of the problem. By knowing which data to seek, between working with internal IT people who understand the structure of the data and have the means to get it, as well as buckling down with the stacks upon stacks of paper records, good data sets can be generated to then allow for the information picture to come together.
However, at this stage a problem occasionally emerges, typically from the paper records.
Electronic records are characteristically generated on an “event basis” in that a record is created each time something occurs: a valve is opened, a photoeye on a case packer is blocked, a gas flow changes, a transaction completes, etc.
However, paper records, generally kept by people, are typically based on some sort of logical grouping, like a batch.
Recently, this problem emerged at a GPS client, wherein multiple batches of material were created in a production system, and the systems were only tracked on paper with limited electronic data capture.
The easiest means to build information is to have a key field, and typically for batched production, this is some form of “lot number” or other production code. Lot numbers are typically chock-full of information, including the date and location of production, amongst other information.
However, lot numbers are data-entry alphanumeric time-bombs, waiting to explode when they are copied from paper to an electronic format to merge with other data. Given the relatively large number of characters in a lot number, the chances for data-entry errors are reasonably high, and as a key-field, difficult to find. Therefore, an alternative key field for data aggregation, sorting, filtering and searching is preferred.
Given the limited number of batches per day at this client, coupled with the scope and scale of the batches, it was found that reliable, location-based, time-stamps were quite workable. This also works well with commonly used software, such as Microsoft Excel, which uses a continuous clock as the basis for its date and time formats. This continuous clock, which increments by one for each day (therefore, noon on a given day is at time 0.5), serves as a good means to sort and track batches, as it is unique over a small number of batches, and it is much easier to enter a date and time than it is to type out a lot number of many alphanumeric characters slammed together.
What are some of your tricks that have helped to solve a problem? Join the discussion.
By Dewan Simon, GPS Consultant
