Connect Everything or Just Key Assets?

Introduction

What drives the decision around scope within the plant? What are the key factors to consider? Here is a good list to start with.

First off, always begin with value. The overall benefits to be received will be the primary driving factor in the scoping decision. The business case study should be performed in such a way to create a complete roadmap instead of being used to justify a single initiative. This roadmap will lay out the desired end state when it comes to functionality. There are some portions of the cost that are constant across the plant (some software licensing) and parts that scale with the number of assets connected (if sensors or retrofitting are required). Also, time to value needs to be considered here as it is often critical to get a rapid time to *first value* in these projects. Again, those webinars and articles referenced earlier go into a lot of depth on this business case and roadmap analysis.

The roadmap will drive the use case selection. The key here is whether the implementation will be focused on a single use case, or is it being looked at as a transformation effort? While the single use case is likely to be centered around a particular group of assets, the transformation project should be inclusive of most assets in the facility (even HVAC!). I recognize that this is more of a spectrum than an either/or choice. The ends are very clear – it is the middle that seems like a gray area. At the risk of spoiling the rest of the presentation – most of the time the default should be to connect as many assets as possible.

The next item to consider is which resources are going to need to be involved in the implementation. To drive long-term success, it is important to involve any stakeholders in the implementation that will be impacted by the project. At the very least, each person that will be impacted downstream should get visibility and have a representative colleague involved in the actual project team. For smart factory implementations, this list can grow quite large: operators, production management, process engineering, continuous improvement, quality and IT should all have representation in a full-factory implementation. When the scope is limited, it can obviously be a more limited group of people that will be involved in the project. It is important that those people get visibility because we will be asking everyone to change how they do work to utilize the capabilities of the new system.

As a result, the readiness of those resources for the change is critical to determining scope. If the computer skills of the workforce or their sophistication for interpreting data are lacking, that should shape some of the decisions made around implementation. It may not mean that change should not be undertaken, it may just mean that more time needs to be allotted to upskilling the workers. Another factor to consider is whether the continuous improvement infrastructure is in place to utilize the information coming from these systems to make the process better. After all, collecting the data and presenting pretty charts and graphs alone doesn’t keep machines running more often. Somebody still needs to use that data to make changes to the process.

The final factor to consider in this list is the impact on production these projects can have. For plants with older equipment there may be a need to retrofit them with newer controllers or additional sensors. This might mean taking those machines out of production while the retrofit is happening. This can be a big impact to the plant and a large hidden cost of the project. The same with the need to take workers off the line to provide them with training on new software, hardware or standard work. Again, this doesn’t mean that the transformational approach should be avoided. It just needs to be considered and included in the project planning.

When to Connect Just a Few Key Assets

When does it make most sense to perform a tight, focused implementation and connect just a few key assets? As I’ll show in the following sections, there are select circumstances where this is the case. Let’s explore a few of them.

Technical Proof of Concept

The first example of connecting to just a few assets is when performing a technical proof of concept. In this case, the emphasis is on whether the technology will work within the company’s environment. This is much different from a POC or pilot where the company is trying to prove out the value attainment, which I’ll discuss later.

For this effort, the scope is to validate that the following all function as promised by the vendors. This is not a comprehensive list, but it is a good sample:

• Sensors
• Data Collection (from sensors, from machine controllers, etc.)
• Networking within the plant
• Networking to any cloud-based portions of the solution
• Bandwidth
• Data Storage
• Cybersecurity
• Reporting
• Workflows
• Integration

This effort is deemed a success if the test plans for each of the elements is passed. This project should not only have a limited scope in the number of assets to be connected but should also be time-limited so that the company can move on to the full-scale implementation.

Goal is to Fix a Particular Problem

The next example is when there is an issue in the plant that is a burning platform that must be fixed. In this case, the company isn’t trying to transform the way that manufacturing happens. They are just looking to solve one particular problem that is costing them a lot of money every day, month and year. This could be a downtime issue, quality issue or other type of problem, but it is persistent, and the company is looking for a solution.

Usually, this type of situation only exists on a limited number of assets. If all the machines were giving this much trouble, nothing would ever get built! Many plants have this type of a problem. There is a set of machines that becomes the constraints to manufacturing output because they just can’t stay running. Maintenance has worked on these machines for years, as has engineering. The vendor has been involved, but the machines are still having major downtime issues. The next step in these cases may be to implement a system that pulls information from those machines to provide additional diagnostics and monitoring. Perhaps even predictive capabilities.

When the scope is this tight, the number of people involved in the project can be limited. Only the people that work with those machines need to learn the new solution and how to use it to improve the process. As a result, it does not require changes to the overall processes in the plant. The people working with those machines are highly motivated to use the smart factory solution, though, because the machines have been such a large issue for so long. They are willing to use a different solution because most of their job is focused on keeping those problem children in line.

Predictive Maintenance

Predictive maintenance projects are often great examples of smart factory issues targeted at fixing problems on a limited number of assets. As an example, I have a customer in the automotive industry that has a mill that had been costing them over $5M in repair costs every year – that doesn’t even include the lost revenues from all the downtime. When they were looking at smart factory solutions, they were laser-focused on what would help them keep that one mill up and running more effectively.

More broadly, it sometimes does not make sense to implement predictive maintenance solutions across all the assets of a plant. Simply put, improving the performance of many pieces of equipment does not provide enough payback to justify the investment. The focus for these implementations is on a couple of scenarios. The first is on constraining assets where the output of the plant could be increased if these machines could be kept running more effectively. The second is on those machines where maintenance costs are particularly high, such as my automotive customer mentioned earlier.

Predictive maintenance (and quality, as I’ll talk about in a minute) is somewhat unique among smart factory solutions. The number of people interacting with these systems is usually limited. Depending on the solution chosen, they may require a significant amount of expertise to get good results from the models. This could involve data science people within the organization or external consulting personnel. They can be very beneficial, but they are also generally isolated systems.

Predictive quality projects are very similar in nature. These are typically implemented in processes where the company is looking to identify causes of variance in production. They may believe that certain input or process variables will serve as leading indicators for quality issues in the product. This is also usually an isolated project instead of being broad-based across the plant.

When to Connect Everything

Let’s look at the other end of the spectrum. When should the company connect all of the equipment, or at least the vast majority of it? In my experience, any time a company is implementing a system such as OEE systems, IoT systems or other cases where process and behavior change will be required to get the value from the solution, it makes most sense to go broad.

When the Goal is Transformation

This was the center of the webinar from two weeks ago on “Driving Long-Term Value with I-IoT”. Without repeating everything from that talk, here are some of the highlights.

When implementing use cases hoping to drive long-term, transformational change in the factory, the focus on the use cases needs to be more broad than simply putting a data collection system in place. The focus shifts from the technology solution to the people in the organization. What can be utilized from the new solution to enable them to be more effective, produce more, and have increased job satisfaction? How can these systems help orient people towards taking action? After all, that’s the primary goal we are trying to achieve with the transformation, not to show pretty charts and graphs. Finally, thought should be given at how to share information across different systems. I’ll cover this in much more detail later.

The other main tenet from the previous webinar was around getting adoption of these systems on the shop floor. Getting wide-spread adoption of these new solutions generally requires cultural change on the shop floor. This is extremely difficult to achieve when the software is only on a limited number of machines. As an example, against my recommendations, I had a customer implement an IoT solution on two assets out of hundreds on the shop floor. The operators rotated through those stations throughout the day and the machines were a small portion of the supervisor’s responsibilities. For the engineers and maintenance personnel, those were just two machines out of the entire plant that they had to support. While the project was a technical success, the people involved stopped using the solution shortly after it was put in. Their standard work was built around the machines that did not have the IoT system in place, so they didn’t use the solution at the other machine, either. After a few months of this, I was able to show management that the software was doing exactly what was promised, but they needed to implement more broadly and adapt the standard work for everyone to incorporate the solution. They’re now a great success story.

These solutions often require additional skills from the workforce that just don’t get prioritized when the systems are on limited pieces of equipment. Or it becomes a hurdle when trying to cross-train workers to rotate between different jobs. Having a common system, common approach and universal standard work can help adoption tremendously.

Stacking Functionality

When implementing smart factory, the goal should be to create an initial baseline of functionality where the systems are connecting to the machines, collecting the data and storing the information. From there, a near infinite number of capabilities can be layered on top to transform the factory. These can be thought of as layered sprints adding additional functionality one piece at a time. The best part is that while the value from the implementation continues to grow, the costs of the software and hardware remain relatively fixed. There is a positive ROI from the initial implementation. But the long-term value explodes as layers are added.

Over the next few sections, I will touch on each of these topics.

Establish Common Reporting

Once the data is being persisted, updating how manufacturing data is reported is one of the first steps to take further advantage of the new capabilities. These are just a few examples of what can be done with the information available through these systems.

For one, much of the manual data collection and reporting that happens in manufacturing today can be eliminated. For example, the collection of downtime information on paper tick sheets or in Microsoft Excel can be eliminated. That data can be collected directly from the machine with some light additions from the operators, when necessary if the machine doesn’t have the reason for the downtime.

Since the information is being bottled at the source in real-time from the machines, it can also be displayed on the shop floor in (near) real-time, as well. This can be used to replace pace boards, SQCM boards or other visual controls that are maintained manually on the floor today.

This information can also be used for real-time management reporting. At a simple level, this can be used for providing visibility to the real-time status and performance inside the offices. At a deeper level, it can be used for things like real-time cost variances when combined with financial data.

Period KPI reporting can also be automated. Whereas today it takes a number of people in the plant to compile data into an array of Excel reporting for KPI reporting, that can all be automated where the data is available. This really highlights why it is so valuable to get all (or nearly all) of the equipment on the same system.

Finally, this can be a big part of any paperless factory initiative.

Integrate Across Systems and Departments

When the whole shop floor is connected, there are a huge number of possibilities that open up when combining that shop floor data with other systems. This is not anywhere close to an exhaustive list, but it gives a great idea of how transformational it can be when all the machines are reporting data.

Maintenance Management System:

Connecting the information from the machines to the maintenance management system enables a lot of additional capabilities within manufacturing. One example is to present autonomous maintenance checklists to the operator each morning (or whenever the task would be due). This works best when it is a common process no matter who is working at which machine that day. By including work instructions for the tasks, it can greatly simplify job rotations and having people step in for absent workers.

These systems can also be combined to analyze the preventive maintenance plan. The goal is to do enough PM tasks to keep the equipment in optimal condition, but to not do any more than is absolutely required. The combination of the systems can be used to continually monitor the PM schedule and analyze what should be done more or less frequently, what should be added and what should be eliminated.

They can also be combined to automate the ticketing system. When the machine goes down, the smart factory system will immediately know not only the status, but what the machine is reporting as the error codes. If they are recognized, the system can communicate with the maintenance management system to automatically create a ticket to minimize the mean time to repair. I went into depth on this process in a previous article.

Another piece of analysis that can be done with the information from the two systems combined is spares and tooling management analysis. The data can show how much stock to carry in much greater detail than the MMS system alone. In addition, if predictive capabilities are being incorporated in the implementation, the spares required for the predicted failure modes can be ordered in advance of need on the shop floor.

Quality Management System:

As with the maintenance management system, there are a myriad of potential touch points between the shop floor data and the QMS system, as well. I’ll touch on a few of those here.

Several of the items listed here are similar in nature – when researching causes for quality issues, everything is quality data. That includes machine data, production data, testing information and more. This can be used to automate CAPA reporting in the QMS, provide support for analyzing causals for the quality issues and support design of experiments or analysis of variance studies. If that last topic is of interest, join us on 4/20 for our webinar Wednesday when we do a deep dive on that topic.

Additionally, the systems can be combined for quality documentation, as well. For example, the information from production, test and inspections can be automatically gathered into a certificate of compliance to ship with the product out to a customer that requires such documentation. 

ERP / Finance Systems:

There are many, many more examples of what can be done with this integration than are listed here. This is only a taste of what is possible! First off, the information from production can give Finance complete visibility into the tasks, material, and resource consumption in manufacturing. This can help them generate a real-time cost variance analysis or alter how they perform allocations to be based on actual data from the shop floor.

Inventory tracking can be significantly eased by automating the tracking of material movement within the factory.

In addition, data can flow the other way to provide business context in the shop floor reporting. For example, downtime and quality issues can be dollarized so that people can see the costs associated with those issues and prioritize the response accordingly.

Planning and Scheduling:

Planning and scheduling can be significantly improved with data from the shop floor. Scheduling is extremely sensitive to the starting conditions in the facility. These can be set precisely when all the equipment is reporting its current status through the smart factory system. Additionally, the amount of run time required for processing different tasks can be captured in great detail through the smart factory solutions, as well. This will increase the quality of the planning by quite a bit versus the “standard times” that exist at many companies. Reporting can also be done in real-time for schedule adherence and the upcoming schedule can be displayed on the shop floor.

Combining these systems also creates the possibility of closed-loop, real-time planning systems that are completely adaptive to changing conditions on the shop floor. These types of planning systems are not possible without having the complete shop floor wired into the smart factory solution.

Facilities:

A couple of quick examples here. The first is being able to track the environmental impact on manufacturing. I have worked with several companies whose production is extremely sensitive to conditions such as humidity. Working with a spice manufacturer, we performed a study on the impact of humidity on their filling operation and how to adjust for clumping at different humidity levels. Another example in the food industry is the need for cold-chain certification for certain products. Monitoring the readings throughout the facility and being able to document where the product was always is critical to automating this process.

Engineering:

There are a *lot* of details behind this but combining a company’s smart factory systems with their product lifecycle systems and other engineering systems allows for significantly enhanced Design for Manufacturing or Design for Six Sigma processes. Just one example of potential interaction is the automation of product FMEA data collection.

Customer Service:

Warranty data is often analyzed on its own, separate from the information from production when those goods were produced. By combining these systems, correlations can be found of which factors in manufacturing are predictive of items that will end up in warranty downstream. Likewise, the information from the field service group and the call center can be used to identify where manufacturing processes may need to be adjusted.

Implement Advanced Use Cases

Finally, using the layers we added earlier for data, reporting and integration, we can create some advanced workflows to support previously manual processes in the plant. I’ve done detailed webinars and articles on each of these, so I won’t go into too much detail here. But these are very powerful capabilities that can help a company become a world class manufacturer.

Automating visual controls on the shop floor can help reduce many forms of waste, while influencing the behavior of the people in manufacturing in the desired directions. Problem solving skills are, at best, uneven amongst the people in most companies. By creating workflows that automate many portions of data collection and analysis, it can raise the effectiveness of everyone in the entire organization. Digital management operating systems can create alignment from the executives all the way through the shop floor. They can mirror the policy deployment process in the company and enable everyone to see where they stand at all times to see if they’re winning or losing that day, week, month and year.

Value Stream Mapping can be largely automated with the data in these systems. Instead of a valuable process that is done occasionally and then put into a drawer, the VSM can become a living management tool that can show current performance of manufacturing against what is documented in the VSM.

Similarly, Failure Mode and Effect Analysis systems can be created that utilize the information from the shop floor to populate and update the failure modes, the probabilities of failure and more. In the other direction, the FMEA analysis can help determine what data should be collected to maximize the probability of detection and to identify recommended actions when particular failure modes are observed.

These are just a few examples, there are many more advanced workflows that can be created once the whole shop floor is connected.

Closing Thoughts

In summary, I generally recommend that companies plan to connect as much of the equipment as they can over time. Start by connecting the machines where the data and inherent functionality in the smart factory system will provide immediate value. But then plan to expand the data collection and layer on additional functionality over time. It makes sense to proceed this way because of the value of the additional use cases, the need for common standard work across the shop floor, helping to drive adoption, and being able to reach the advanced workflows.

What are your thoughts? Do you agree that implementing on specific assets is a special case? Do you feel differently? Have you achieved any of those advanced use cases in your implementation? Let us know in the comments, and please give a like and a share.

Thanks!