As I mentioned in Part I of this blog two-parter, standardization in manufacturing is a dirty word to some folks. It seems “unattainable,” and therefore not worth discussing. But I’m here to say that standardization is attainable, so once again, let’s discuss.
For Part II, I’m going to dive into the challenges presented by standardization…and how we can deal with them. So, in Part I, we talked about the benefits of standardization, including:
- Rapid deployment (less costly, too)
- Ease of maintenance
- Unparalleled visibility
- Power of the Cloud to reduce hardware, software, and personnel costs
And we talked about meanings of standardization, including:
- Naming conventions
- Software products
- Work practices
- Within the software—functionality
- Looking at the results of measurements
We also discussed the internal differences that many organizations deal with, and how we can’t let those thwart standardization efforts. It’s helpful to know and understand the benefits of reaching alignment (which isn’t necessarily the same as agreement), of standardizing wherever and whenever you can. Then, when you run into these difficulties, you can see how important it is that you come to an understanding and standardize things within your organization.
And, believe me, the benefits of standardization in manufacturing far outweigh the temporary headaches. (Sorry to repeat myself, but it seemed important!) So, let’s look at some of the challenges associated with standardization.
Consistency is Key—But it’s also Challenging
In my opinion, consistency (which I mentioned in Part I) is probably the biggest benefit of standardization in manufacturing. As an example of this in practice, I have worked with two very large companies that went about their quality software deployments in very different ways.
Company A deployed a very standardized system. They were also adamant about communicating what the plan was. Essentially, they told their employees, “This is what we’re building, and this is what you’re going to get at the site.” Despite employees’ grumblings, the company didn’t waver and pushed forward.
The end result of this seemingly “draconian” deployment method was that they were able to deploy at approximately 80 sites in 18 months. How were they able to deploy on such a large scale over such a short period of time? Standardization.
Company B approached their deployment a bit differently. Since they had facilities in the US and in Europe, there were many different practices at sites acquired over time. One specific issue that came up was “Do we use the metric system for everything?” Unfortunately, they didn’t standardize and when they ran reports for the entire company, they had results in multiple units. Was this the end of the world? No. Were they able to perform comparative analyses easily? Often, not as easily as they had hoped.
If you extrapolate that over multiple measurements, for multiple products, you can see what a plate of spaghetti that turns out to be. The best results for enterprise-wide reporting will always come from a standardized system. It makes deployment easier; it makes reporting better; and it enables you to make better decisions.
The Slippery Slope
We all know that operators on the shop floor are critical for rapid adoption of any system. The operators are the primary users of any quality software system, and they must buy in. Most companies are just not willing to say no, outright, to their operators. This leads to concessions.
You can give in to operators’ needs and desires. Standardization doesn’t have to be an all-or-nothing endeavor. But you can’t really just “give them what they want” every time, either. It’s great for operator adoption, but it’s a slippery slope.
When you start making concessions, that can slip into a few more concessions, then a few more, and so on. That can ultimately impact your ability to use the data you collect. So, what I’m getting to is this: your decisions on what to standardize need to be conscious decisions. You need to balance your need for quality system adoption with the need to standardize, so that everything goes as smoothly as possible.
Conscious Standardization in Manufacturing
One large company I worked with did a great job with their deployment, and with standardization, by making each decision a well-thought-out conscious decision. They basically said:
“We’re going to try to get buy-in, and then we’re going to give the operators what they need. But the end goal is we still need common naming conventions and work practices to make the investment we made in the system worthwhile.”
And, so, they were careful about where they capitulated to operators and where they dug in their heels. At the very least, standardization discussions with all the interested parties forces an organization to have these types of conversations.
Variations on a Theme
One thing that really struck me as I worked with this large company was that, like smaller companies (and perhaps more so, since they were sooo big), everyone in the various plants and on different lines thought that the way they did things was how everyone did things.
I can attest to the cold hard fact that, unless you have gone through a rigorous standardization exercise, this is never the case.
It’s not until you sit everyone down that you come to realize what really goes on—how everyone does things in their own way. The differences, in some cases, may be minor, but they are there.
So, if I were to give one piece of advice to any company thinking of standardization, it would be this: make sure the conversations take place. And not just the first few times, but repeatedly, because it takes a while to hammer these things out. When people start to drift back into their daily routines, these things can easily be forgotten and left behind.
Standardizing Work Practices
Another form of standardization is work practices. So, not even thinking of software, but just in general, standardizing how you do things across your organization is important.
Standardizing Systems for Quality in Manufacturing
Okay, full disclosure, this is where we talk about Enact®, the InfinityQS Quality Intelligence platform. But with good reason. It’s perfect for standardization.
I’ve been to organizations in which some of the facilities do their work on paper, others on spreadsheets, some on InfinityQS software, and some on other (competitor’s) software. It’s a mish-mash. And it’s not efficient.
Just getting everyone on the same system, and particularly one with a centralized data repository (like Enact), is huge. We’ve found that the centralized data repository is essential to standardization. Without a centralized data repository, it’s tempting to allow the site to do “just this one thing” differently. Remember those comments about the slippery slope?
All Your Data in One Place
Let’s say you had two different people with two different spreadsheets. If you want to make comparisons, then at some point you need to either pull up both spreadsheets for a side-by-side view or copy and paste from both into a third spreadsheet—in which case you’re putting all the data in one location. So, a centralized data repository makes sense.
Standardizing Within the System
Good software will reward your standardization. In order to reap the benefits of a good quality software system—to report your findings in a coherent way—you need to standardize everything. It’s amazing to me how minute the differences can be to wreak havoc on your reporting. Here’s an example:
Some time back, we worked with a company that did not name things consistently. They wanted to look at their quality data by work center, which is an excellent idea. The challenge came when multiple quality engineers didn’t realize they were working in a centralized system. When they each created data collections for Work Center 123, the names included: WC-123, WC 123, WC 123 (note the 2 spaces?), WC_123, WC123, WC*123, etc.
So, when they looked in their database, they had seven different versions of the same process. They just had no idea. They didn’t meet beforehand to hammer out standardized naming conventions. Going back to fix problems like this is often time consuming and can be expensive. They weren’t happy, to say the least. It’s a tough way to learn a lesson.
Enact helps you standardize. Items are named once. Period. And you’re all working from the same set of data, because it’s in a centralized data repository. But what about users that speak different languages? That’s a whole other topic, but rest assured Enact has it covered. Furthermore, Enact then gives you the option to customize how you, the individual user, view the data on your dashboard. (That’s a whole other discussion, too—see the link below.)
Please see all the Enact links below to learn more about this exciting new tool. Roll up your sleeves, have those tough conversations, consciously decide, work through problems, and enjoy the benefits of your hard work. Happy standardizing!