Exec Summary
A leading manufacturer of specialized metal products for the aerospace industry had significant challenges with visibility into their finishing shop. The issues were primarily around downtime and bottlenecks. They were having a negative impact on the plant’s production throughput, revenue, and on-time delivery. After a few conversations and a Digital 360 review, it was clear a Manufacturing analytics / IIoT solution was required to monitor the machines to get accurate, real-time data from the plant.
An IIoT solution was put in place to monitor 23 presses and CNC machines. The results of the solution were very valuable. They were able to get accurate, real-time data which enabled them to find the causes of downtime, do some root cause analysis, apply corrective actions, get a nearly 40% reduction in downtime, and set themselves up for addressing more valuable challenges.
Lessons Learned
- Use the Digital 360 process to identify low complexity.
- Run every project like a project.
- Always do a Site Survey and review the machines in person.
- Emphasize to the operations staff that IIoT solutions are there to help them.
- To solve a challenge around machines, find the biggest buckets of time or resources spent.
- Project planning, the Project Charter, the Project Launch meeting, and continuous communication throughout the project between the manufacturer and Ectobox enabled the project to go smoothly.
Introduction
We’re doing something different here. We are going to talk transparently about a customer and how they were able to solve some challenges in their plant. In this situation, we will talk a little about the IIoT solution in place. However, most of this will focus on details typically not discussed regarding IIoT / Data-Driven Manufacturing solutions.
Specifically, we’ll discuss topics including specific steps the manufacturer took to solve their challenges and their learnings, how we and the manufacturer worked together on certain aspects of the pilot project, the value the company got from the project, and even some hiccups along the way on both sides. Our hope is that you’ll find this valuable and can learn a thing or two from the discussion. We will highlight the lessons learned for the manufacturer which you might find valuable. (We have removed the names for sake of confidentiality.)
Background
The company is a specialized foundry/manufacturer that produces specialized ferrous and non-ferrous products from foundry mold to the final finished product. They have a finishing area comprised mostly of CNC machines. One of the final stages of processing the metal is to finish the products in 3- and 5-axis CNC machines.
Challenge
They knew they were having issues with production. They determined this by looking at the number of products going out the door, the number of operators and machines, and the estimated cycle times. The team felt they should be getting more production than they were, but didn’t have any strong data to back up that argument.
The operators were reporting that they were working full tilt. So, some team members were recommending to the president that they buy another couple of machines and hire some new operators. However, there were a couple of instances where the president walked around the plant with one of the manufacturing engineers and asked a critical question…why were so many of the machines idle when he walked by. It was then that the manufacturing engineer realized they needed better data.
Data could be obtained manually by putting together a spreadsheet with dropdowns for downtime reasons, and record data manually. But who will record the data reliably? As a manufacturing or process engineer, you can’t be there yourself. Our COO here at Ectobox, Dave Grafton, in a prior position, worked at a plant that didn’t have any manufacturing analytics / IIoT solution at the time. To solve a certain challenge in the plant he had to spend a full 3 days with the operators on the plant floor to understand what’s going on. Obviously, a manufacturing or process engineer can’t spend 3 days gathering data for each of the problems in the plant. There needs to be an automated way to get the data.
If the manufacturer is truly working to become a data-driven company, they should be able to provide the data to the smart people in the plant who are solving the problems…the manufacturing engineers, process engineers, Lean and continuous improvement teams, and also the operators.
With an IIoT solution providing up to the minute data directly from the plant floor and operators, the plant engineers can quickly iterate through issues, solving problems, and moving to the next problem.
The manufacturing engineer at this plant realized getting operators to record more data manually wouldn’t work. She also realized the idea of spending anywhere between 1 and 3 days full-time on the plant floor also wouldn’t work.
Her situation was also compounded by multiple other issues in the plant (no plant has only one issue, as we all know). The other issues included scheduling and on-time delivery challenges, bottlenecks, certain machines experiencing some excessive downtime for unknown reasons, a need to rearrange the flow in the foundry, and there were several Lean Kaizen events to finish out. So what does one do? What do you do in this kind of situation?
Where to Start
In this kind of situation, the first thing to do is step back and clarify your priorities. To do that one should use a process that answers these questions:
- Where should time be spent to get the biggest value to the company?
- What challenges in the company have the lowest complexity and highest value?
These questions can be answered by spending a bit of time (not a lot) with a small team going through a straightforward process that we call a Digital 360 (aka Digital Operations 360 Review). The end of the process produces a valuable, validated roadmap of tasks and projects to tackle. This process gets all information about the challenges on the table and produces a validated and valuable roadmap of what challenges to tackle next and how.
This clarity on the challenges for this manufacturing company and the resulting roadmap was important. There were a lot of issues, a lot of competing interests for the manufacturing engineer’s time and for the company’s other resources. Going through this process was our first recommendation to this company when we were introduced to them.
We’ll admit, it can be a challenge to pull a small team of leadership and some team members together, and focus on this process. However, once it’s done the value of the process and the roadmap are huge.
Here is a quick summary infographic on how it works. 
The result of the Digital 360 was a roadmap with the priority being a pilot project to monitor machine utilization with downtime reason codes. Gathering production data turned out to be a nice-to-have solution in the short term and, therefore, wasn’t required. The downtime data with reason codes was selected because it was a lower-cost option for monitoring the machines and provided the highest value and return, relative to other projects on the roadmap. The team also decided to run the project as a pilot project on 2 machines. This turned out to be a nice way to introduce the new technology and the new data to operators, manufacturing engineers, and leadership.
Lesson Learned
Use the Digital 360 process to identify low complexity, high value challenges to solve and create a roadmap. That helped this company clarify that a pilot project to address machine downtime was the most valuable and simplest project to execute.
Project Planning
Once the decision on the pilot project for monitoring 2 machines for downtime with reason codes, we recommended the project be treated like a “real” project. Some companies will immediately dive into setting up the technology. Then when things go wrong in the project and scope creeps there is no limit defined, no line drawn in the sand to know when to adjust, approve changes, or pull the plug.
For this, we always use a Project Charter document. Here is a sample we use for some larger projects. We are big believers in keeping things simple. Having said that there is also a Goldilocks zone for planning projects, even the small ones…not too much, not too little, spend just the right amount of time planning. And that time planning is proportional to the size, complexity, and value of the project.
If nothing else, define the following basic criteria and check-in with the people in the project around these parameters on a weekly basis:
- Goal/Objective of the project: make the goal a clear, SMART goal, maybe include ROI (Return on Investment)
- Due Date: when will it be done
- Budget: money and time/resources to spend on the project
- First several tasks, to get the project started
- Primary Stakeholders: Who is the PM on each side of a project (vendor and client), and who are making the decisions on the project
Lesson Learned
Run every project like a project, with a goal, budget, due date, several next tasks defined, primary stakeholders defined, and check status weekly. For more formal projects use a Project Charter document.
This concept helped the manufacturer gain clarity on the project, success criteria, and the potential ROI. It seemed this wasn’t practiced often at the company. The manufacturing engineer liked the process and has since used it on other projects with success.
Business Case and ROI
Part of defining the project plan is defining the goal. That goal should include the project achieving some value for the company. This can also be the ROI (Return on Investment). The people planning the project should define a metric for determining whether the project and solution were a success. Simply saying the project is done, the machines are connected, and pulling data isn’t sufficient. You need to dig another level deeper.
What is a hypothesis you can create about the project? Here’s an example: “We believe we can reduce downtime on a single machine by 40%, which produces an additional $30K in product each month.” Creating a hypothesis provides extreme clarity for measuring success. The IIoT system implemented, if that’s the solution being put in place, should also be able to provide those actual numbers…you should be able to see 40% downtime improvement on a chart, and see the $30K additional manufacturing value on a screen.
Project Launch
For this project, as we do for all projects, we went through a short Project Launch call/meeting with the manufacturer. On the customer’s side, the call included the CEO as the Sponsor in the Project Charter, the Manufacturing Engineer as the Champion, an IT person, and the plant manager. In the meeting, we reviewed the outlines of the project plan, confirmed some details, scheduled the first couple of activities including the On-site Visit and when to connect the machines, and ended the meeting.
Site Survey- Choosing the correct IIoT Solution
We conducted a Site Survey as the next step in the project. The idea of a Site Survey is to review the machines in question to confirm how we will connect to and get data from them, review the layout of the machines and network availability, etc. For getting data from the machines often it’s a question of whether they have the capability to provide data via a common data communications protocol like MTConnect, FOCAS/FOCAS2, or similar. If that’s not possible our alternative is to use external/noninvasive sensors with small, reliable PLCs to get data from the machine (e.g., Banner Engineering sensors with a DXM gateway or similar products). We then create our BOMs (Bills of Materials), pull or order the products needed, and schedule the installation on-site.
The Site Survey was a valuable activity. We’re often told by the company what machines we’ll be connecting to and sometimes provided a lot more detail than needed. However, we always find some surprises which, if not uncovered, would’ve been very costly during the project. This alone makes the On-Site Visits worth it.
For this project, we were given some information on the machines regarding the manufacturers of the CNC machines and the controllers on the CNC machines. This list included the make and model numbers of the controllers and other data. It was a good thing we required the Site Survey, as we always do. It turned out some of the information on the machines was incorrect. Had we showed up with equipment based on the list of machines without seeing them we would have had to make some extra trips. The ethernet ports on one of the machines were buried inside the machine after some customization by the vendor. The other machine required an external sensor and IoT gateway.
Lesson Learned
Always do a Site Survey and review the machines in person to confirm how to connect and get data out, understand the network availability, etc.
IIoT Solution
We then installed a single IoT gateway device (i.e., an industrial PC with machine connectivity software) and connected it to their Haas machines. We worked with the client to make small adjustments to the configuration of some machines (e.g., modify some settings in the Haas machines to make MTConnect data available). Then the machine connectivity software was configured, the machine connected, and tests were performed for pulling data from the machine.
While the machines were being connected our team worked with the manufacturer’s team including the manufacturing engineer and some leadership to set up SensrTrx. One of the best solutions we can put in place is where the customer knows how to set up and use the product so they don’t need to rely on our team for every little change in the future.
Once the IoT gateways were connected to the SensrTrx platform in the cloud over a secure firewall the client was able to immediately see data for their machines.
Training of a few team members on the SensrTrx platform was brief, about 1.5 hours in total. Once the manufacturing engineer was training on the system she then trained the operators on the 2 machines for how to use the Operator Screens. That training also took only 1-1.5 hours. She emphasized to the operators, as everyone should including the company’s leadership, that the system wasn’t being used to allow big brother to watch them. It was about giving them and her data they all needed to do their job better, which is to do a better job for themselves, for their teammates on the plant floor, to operate more efficiently, and to grow the company because it’ll all benefit the staff even more.
It turned out that some operators that were initially resistant to the project ended up being champions of it, especially with the profit share program already in place for the staff. They realized the level at which they were producing (i.e., not up to snuff), and they were accountable to each other and themselves once they saw actual downtime and production numbers.
We have many times over that the numbers always go up after an IIoT solution is put in place. Often companies measure at an OEE of around 30% and in a matter of 6-9 months are able to get OEE up to 60% to 90% merely by implementing IIoT systems and sharing the data.
Lesson Learned
Emphasize to the operations staff that IIoT solutions are there to help them. The numbers always go up after an IIoT solution is put in place and the data is shared with everyone. The people on the shop floor do care and do want to do better for themselves and for the company.
How to Clearly Identify Issue
The manufacturing engineer was ecstatic to finally see accurate, real-time from the machines that made sense. She was immediately able to see some of the downtime issues with reason codes. She let the system collect data for about a week to ensure she had good data for a normal operating week. This is when the manufacturing engineer’s real work started…finding out where the issues are and solving them.
She needed to figure out where the biggest bucket of wasted time was, nonvalue add time. This analysis of finding nonvalue add time can be done by creating an accurate Value Stream map during the initial analysis process (Digital 360), which we often like to do. The issue with the Value Stream map is that is a snapshot of a point in time and can quickly become out of date. That data is also available on an ongoing basis from an IIoT solution to get accurate, real-time data.
In this situation, the Pareto charts on downtime by occurrence and downtime by time from the SensrTrx IIoT platform were the best places to get the data.
The idea for addressing the downtime issue is to clearly identify the biggest bucket, and then to get as specific as possible with that biggest bucket to enable valuable analysis. In other words, for downtime, get reason codes that are actionable.
For this client, the biggest bucket or issue was a lot of calls to maintenance. It was clear “Call Maintenance” as a downtime reason code wasn’t actionable, it wasn’t the information that helped determine the core cause. Therefore, the manufacturing engineer quickly realized she needed to adjust the setup of SensrTrx to ask the operator for the 2nd level of detail if they selected Call Maintenance. She was able to do that within minutes and without having to take any new training classes or write any new code.
Once the data is specific and actionable, then the next step is to determine the cause using Root Cause Analysis. One should ask themselves if the problem is uptime, utilization, runtime, or cycle time. Is the machine running in the most efficient way?
Typically, most issues don’t occur during the production of the part on the machine, i.e., the value adds time on the machine. The cycle times or value-added time on the machine are often the smallest part of the time spent creating the project. The issues are often in the nonvalue add time, which is before and after the cycle time (i.e., changeovers, setups, programming, etc.). A typical number for the nonvalue-add time we see in discrete manufacturing time is 80-95%. It’s a startling number, 80%-95% of the time spent by a company to produce a product is not considered value-add time, time that is directly valuable to creating the project.
Maybe the issue is the changeovers are too long. Digging deeper in a Root Cause Analysis could determine that the person doing the changeovers isn’t very good at them and therefore takes too long. Or maybe the run-time could be the issue, it’s too long. Why would that be? Maybe the tools are dulling and need to be changed out. Getting accurate, real-time data on these issues into an IIoT platform for problem-solving can help identify these issues in a Root Cause Analysis process.
Once the cause is determined, then a corrective action needed to be created.
After the corrective action is in place the IIoT solution should be used to validate the corrective action was appropriate and the core issue is being solved.
Lesson Learned
To solve a challenge around machines, find the biggest buckets of time or resources spent. Then get clear, actionable reasons for the cause. Then do a Root Cause Analysis to drill into the true cause. Finally, establish a Corrective Action to put a solution in place.
Often the true causes of challenges will be in that 80%-95% nonvalue-add time spent before and after the part is produced.
For this manufacturer they found the cause of the issues were twofold:
- Misclassification of some downtime as maintenance where it should’ve been classified as changeovers; and
- Changeovers being done incorrectly then caused problems with the machine running efficiently, which then resulted in calls to maintenance.
The corrective actions were:
- better training on changeovers; and
- identifying a couple of operators as the most efficient and accurate change-over people, and setting them up for success as the go-to people for doing certain complex changeovers.
The manufacturing engineer monitored the downtime data for the two pilot project machines for an additional 1 ½ months and confirmed the corrective actions helped reduce the downtime by an initial 25%. She has since worked to reduce downtime by an additional 20% and beat the original metrics that defined success for the project.
Hiccups in the IIoT Solution
There were some hiccups in the project, there always are. Any company is lying if they said a project went perfectly. In this story, we’ll open up the kimono to show that no project is ever perfect. The challenge is then to still reach successful conclusions on valuable projects in spite of the challenges that inevitably come up. We’ll briefly review some of those challenges and how they were handled by everyone.
In this project the issues included:
- IT/OT connectivity issues – Communication over the firewall between the IT network and the plant network).
- Addressing Wi-Fi coverage – The pilot machine was located around the corner and behind a metal latticework from the Wi-Fi router. This prevented good connectivity and required the use of a repeater.
- Supplies of products – The pilot project was implemented during the COVID pandemic which interrupted the supply chain and slowed delivery of a couple of devices). It has a small effect on the project schedule.
- Extra trip – Ectobox missed a couple of details on the connectivity of the machines and had to make an extra trip to fix the issue. It had a small effect on the project schedule.
- Leadership – The project was slow to start due to a lack of support by some leadership at the manufacturer, but then the ship was righted and quickly got on track.
All these issues ended up being small and were readily handled. The star of the project was the manufacturing engineer. She worked tirelessly to ensure everyone was on the same page, machines and operators were prepped, she learned the tool in 1 ½ hours, got a lot of value out of the completed solution, was a champion of implementing the IIoT solution on the remaining machines, and was wonderful to work with.
Lesson Learned
Project planning, the Project Charter, the Project Launch meeting, and continuous communication throughout the project between the manufacturer and Ectobox enabled the project to go smoothly and handle the small hiccups that are bound to happen in any project. Without that work ahead of time, the project could have gone much differently.
Summary
The manufacturer in this situation had issues with excessive downtime on some CNC machines. The recommended approach in this project was to use a logical process to identify the priorities in the plant and a roadmap for tackling the most valuable and least complex challenges. This lead to implementing a pilot project on two machines to test the SensrTrx system, drive adoption in the plant incrementally, and solve some real, live issues with machine downtime.
The project was successful, reducing downtime on the pilot project machines by about 45% to start. The manufacturing engineer is working on the process and using the SensrTrx IIoT platform to further the downtime. The next challenge to tackle on the roadmap defined from the Digital 360 is production scheduling and bottlenecks. SensrTrx and the real-time, accurate data from the machines will be critical to identifying the bottlenecks, why they exist, and how to eliminate them.
The IIoT solution is now being scaled up to all the other machines in the plant. In the end, the solution will likely prevent the company from spending about $500K in capital costs to buy a new machine which is no longer necessary at current order levels (do more with what you have). Additionally, the company is increasing production and revenue by about $340K/machine/yr (2 shifts/day, 7 hrs/shift, 20 days/mo, 6 parts/hr, $110/part = $185K/mo production revenue for 1 machine).
