In previous articles of this series, we discussed how to master quality at the tactical and strategic levels. If you are like most readers, you probably nodded your head through article two’s tactical shop-floor view and vigorously shook your head through article three’s strategic view because your organization has the same challenges.

There is understandable hesitation from nearly any organization to make the transition to ultimately master quality at the enterprise level. This hesitation stems from organizations trying to view this transition as an all-or-nothing endeavor. As a result, that gets people seeing roadblocks that don’t necessarily exist.

Let’s take a look at a few.

Solve all the deployment issues in advance

Because previous deployments took a tremendous amount of time, resources, and expense, most organizations want to address every deployment problem before they even begin considering strategy.

That won’t happen. Ever. No matter what system you deploy, you will discover and learn things you could never have anticipated up front.

“We had a client that had previously used an on-premises software and was used to all of the headaches they had managing it,” says Eric Weisbrod vice president of product management at InfinityQS. “When working with us while discussing our enterprise software solution Enact, they wanted to know how it would address some of their very specific requests. The biggest challenge was convincing them that Enact was designed in a fundamentally different way to sidestep these concerns. It took a lot of time for them to come around and trust that their concerns could be addressed without requiring the tools and processes they had previously put in place.”

Solution
Start small. Start small, show success, and then scale. There is no one right way to do this, so organizations can decide what works best for them. For instance, InfinityQS is finding that some large manufacturers are experimenting with becoming more agile and embracing the “fail fast” mindset that smaller startups have been using for years.

Hesitation using cloud on the shop floor

Although most companies have embraced cloud products in the office, having reliable internet on the shop floor is still a new idea for many.

True, installing reliable internet on the shop floor can be a hurdle, but with cloud software, that is effectively the only hurdle. Although that’s not entirely true—connecting with measurement devices comes to mind—for clients using manual data collection, that is the case. Now, instead of figuring out how software will be installed, how database connections will be made, where files will be stored, and how upgrades will happen, the implementation boils down to one well-understood problem to solve: reliable internet on the shop floor.

At a household products manufacturer, there was a learning curve to get thin tablets ready for shop-floor use. Some of the settings for things like laptop mode vs. tablet mode needed to be sorted out. This was something the manufacturer hadn’t dealt with before, so it was frustrating, but once those items were figured out, everything ran smoothly.

Solution
Think about the big picture. Although adding reliable internet to the shop floor seems costly, think about all that you gain:
• Elimination of the effort supporting software installations and upgrades.
• Ability to use lower-cost devices (that are also easier to administer and replace).
• No longer needing the expertise required to deal with database servers, file servers, and so forth.

Deployment planning

When there is the mindset of “all or nothing” for a project, there is this idea that you will need to do the deployment in “one big push.” That isn’t the case at all.

Solutions
Start small. As stated above, the start-small methodology is practical and effective. It takes fewer resources to start with a focused proof of concept, and that success can be shared with similar lines at the same site, or across all sites. This allows everyone to “dip their toe in the water” and agree on standards.

Add licenses as needed. With a license model, such as that employed for InfinityQS’ Enact, users add licenses when they’re ready. Users can do this self-serve, can increase or decrease licenses whenever they like, and can assign licenses to users (typically managers or engineers) or to devices (typically for shop-floor operators and supervisors). This further supports the start-small-and-expand methodology because each site doesn’t have to commit immediately.

Distribute the workload. Most corporate deployments either have a central team that goes from site to site during the deployment, or they have each site deploy itself. With a truly centralized system, you can have the best of both worlds. A few administrators can configure the data collections and dashboards to be used by everyone in the system.

Compatibility with legacy systems

This is somewhat related to the “solve every problem” issue because it has to do with manufacturers that have legacy systems that they’re trying to integrate with a new solution. Although it’s wise to leverage the systems you’ve already got, some of those systems may have you trapped into a way of thinking that just needs to change. It can be painful to seemingly start over with another system, but that is often the best path.

For example, a food manufacturer had external reporting tools that it used for quality management. It was taking large amounts of quality data from the reporting tools, manipulating the data, and then displaying the result in its reporting tool. An enterprisewide SPC system could provide the results directly instead of relying on data manipulation. This would give the manufacturer a more streamlined data integration path, but it meant the company had to look at what it was currently doing, decide if that was what it really wanted to be doing, and if this better path forward would really work with its legacy processes.

Solutions
Look for and expect change. Just because you’ve been doing something one way for years (or decades) doesn’t mean it’s the way you should do things forever. Often, being forced to think differently and to challenge what is truly important can foster breakthroughs that more than make up for the disruptions and discomfort that come with change.

Cost

Many organizations aren’t used to thinking of enterprise software in the cloud as well as software-as-a-service (SaaS) models. This aligns with the “all or nothing” mindset and often doesn’t consider the following points.

CapEx vs. OpEx. The fact that SaaS subscriptions typically come from operating expense budgets instead of capital expense budgets means the budget cycle and process are different. Not necessarily better or worse, just different. This often is a shorter cycle, but that doesn’t seem to be among the considerations for the enterprise deployment team.

Lower-cost devices. Using browser-based software means that lower-cost and more robust devices can be used.

Portable devices. In addition to lower-cost devices, portable devices offer several benefits. For environments that must be washed down or are caustic, the added expense of an enclosure isn’t required. Portable devices can be carried to different parts of the line, so one device can do the job that previously required multiple workstations on the production floor.

Total cost of ownership (TCO). This is a standard cloud discussion, but again isn’t necessarily in the discussion of the enterprise deployment team.

Ramp-up deployment. Along the lines of “CapEx vs. OpEx” is the consideration that with SaaS, you don’t have to purchase all software up front. You pay for what you use, which means the deployment can acquire licenses as needed.

Pay for what you use. Another benefit of subscriptions and paying for what you use is the ability to scale up or down for seasonal or variable workloads. Companies don’t need to buy licenses they won’t need at all times.

Centralized management

This is something most organizations don’t have. It’s simply not part of their current structure because centralized solutions are relatively new in the timeline of many companies.

For a multinational food and beverage manufacturer, most decisions had to be vetted with all of the sites, which was challenging when sites couldn’t agree on how to do things. There were issues about standardization (like which units to use, English or metric); work practices (most manufacturing sites had been around, with their own culture, well before being owned by their current parent company); and even naming conventions (because all sites used an ERP system, but not necessarily the same ERP system or even the same ERP system setup uniquely at each site).

Solutions
There is no one right way to solve the problem of centralized management, but the approaches below have been successful at different organizations.
Standardized, centralized management and oversight. This is the goal of most companies, but it’s difficult to put in place because it involves telling a lot of sites “no” on many topics. Naming conventions must be established, work practices must be standardized (for both what is done and who does the work), and many other items must be addressed.
Standardization at the regional or business unit. Depending on the organization, it might make sense to have a working group composed of various regions or business units (based on products they make) because there may be country or regional requirements for working practices and checks. The needs of an organization that makes dairy products and snack products and confectionery items and meat products will have different requirements within each of those segments. The regional/business unit organization helps ensure alignment across the entire organization on key items (net weight is net weight, right?) but allows flexibility on appropriate items.

Conclusion

As we have emphasized throughout this series, “doing” quality is not the same as mastering it. But we’ve also seen how mastery doesn’t have to mean a long-term effort toward a far-off goal. With the right tools, and the right approach and mindset, the leap between doing and mastering quality may be easier than you’ve assumed it is. The process can begin by removing the barriers to digital transformation as discussed in this article, and concentrating on small deloyments at first. Adopt a quality and SPC solution like Enact to support that transition. With the benefits of cloud, software-as-a-service, and scalable, centralized, and secure enterprisewide solutions, many of the traditional barriers to digital transformation fall away.

Is it time for you to challenge the status quo at your organization? By using data already available in your organization, you can make valuable connections between shop-floor and C-suite requirements. They are the building blocks that will allow you to truly master quality.