Process Monitoring or Production Monitoring—Why Not Both?

To date I have written few articles on effective process monitoring, making the case that third-party monitoring is the most robust option for accomplishing this. That said, I’m not sure if I have conveyed how important it is to also have a real-time production-monitoring system. Ideally, it should be a manufacturing execution system (MES) that can be used in conjunction with process monitoring.

At a previous company, I was part of a team tasked with identifying and successfully integrating such a system into the operation. This column will hopefully explain my thought process, and what I was looking for in this type of system to both manage production and provide effective process monitoring. I’ll also share some of the roadblocks you might face with this type of project, or at least what I and my team were able to provide solutions for.
 

Finding the Best Fit

While working as technical shared service manager in the medical side of our industry, I was tasked with identifying a real-time production monitoring system—the aforementioned MES.  This task had been attempted many times over the years at this facility and had continually hit roadblocks due to systems falling short of providing what everyone in the facility wanted. Many systems had been proposed to the management staff, and each one was shot down because none of them met everyone’s expectations or requirements.

I didn’t want this project to stall in the same way previous attempts to introduce monitoring to this facility had petered out.

The first thing I realized was that no out-of-the-box system would be perfect for everyone, but if we could identify a system that could be customized, we could eventually get there. The goal of the project should be to allow all departments to provide input on the planned system. That said, you can’t allow pushback from others to stall the project either. When this happens, you have to be willing to make a decision that might not be popular with everyone but is necessary to keep the project going.
 

Trust me, I had my share of those decisions to make, and I knew the goal would be to either modify the system or modify our production procedures, as needed, to best utilize its capabilities. So, not exactly ignoring my colleagues’ needs or concerns, but rather understanding that the system or the company could evolve to meet them in the future. I didn’t want this project to stall in the same way previous attempts to introduce monitoring to this facility had petered out.
 

Process Monitoring as an Afterthought

A majority of the systems that had already been considered at this facility were predominantly production-monitoring systems that happened to have some process-monitoring capabilities.  Considering that my background has almost exclusively been in scientific injection molding, I of course prioritized process monitoring as a critical system requirement.

The problem I had with a majority of the production-monitoring systems on the market was that their process-monitoring capabilities were almost an afterthought. This is a good time to point out that the system that was required for this particular molder needed to be able to provide effective third-party process monitoring to accomplish one of the main goals I had set for the project.

Since the injection molding process itself is part of the medical molding qualification, verification of the process is required throughout a manufacturing run. The current practice at the time was for a process technician to document the qualified process outputs four times a day on a cycle checklist. This meant that one of our highly trained technical resources was spending time doing fill-in-the-blank paperwork instead of utilizing his skill set in more value-added activities. On top of this, typographical errors could result in significant waste. If the process technician accidently wrote down a nine instead of a six on this cycle checklist, it could easily result in parts being scrapped going back to the previous accepted entry.

In the medical molding industry, we couldn’t rely solely on verification of the part’s form, fit and function to release product. We had to prove we had produced the parts within the verified process limits. To eliminate what lean manufacturing would refer to as “Skill Waste,” the process-monitoring system must be able to independently capture these outputs. In addition, it must be able to segregate a shot that failed to fall within the approved control limits and be capable of interrupting the machine cycle if the number of segregated shots exceeded a predetermined threshold limit.

Production-monitoring companies are experts in MES systems but not often experts in injection molding.

A big lesson I learned was the importance of developing critical requirements for the system upfront with your team based on the operation’s current procedures before starting to evaluate potential monitoring systems. This is when it pays off to have project team members who actually perform the job. They can provide details that are often overlooked by those who are not hands-on. As far as system requirements go, keep in mind that if your customer doesn’t require this type of process verification, the process-monitoring requirements may not have to be completely independent of the machine’s native process-monitoring capabilities.

If this is the case, requirements for your operation could be reduced to a system that uses the machine’s monitoring capabilities and allows for the presses to be networked into the system. That said, remember that effective process-monitoring systems are complex systems that require process, machine and mold expertise to develop. Production-monitoring companies are experts in MES systems but not often experts in injection molding.

This was evident when reviewing each system’s capabilities. Companies that tried to provide a “jack of all trades” product, typically fell short of being best in class in anything. That’s my opinion, and I will say that there are systems on the market that have brought in the necessary skill set to improve process monitoring, but they are miles behind industry leaders in effective process monitoring.

It became apparent early on in the project that if the system was going to monitor an injection molding process effectively and manage production effectively, we needed to look into a system for each, instead of an all-in-one approach. When I first recommended this concept, it was fairly controversial. Fellow managers brought up concerns about getting team members to use one system, let alone two, which is a legitimate fear. No matter what system you decide on, if it is not used, it is worthless to you.
 

Of course, cost was a concern, as well as managing multiple systems’ infrastructures; but I felt strongly enough about this approach that I decided to focus the project on applying multiple systems, each providing the best solutions for our plant’s requirements. Once I focused the project in this direction, it quickly became clear which process-monitoring system would meet our needs.

From the process-monitoring prospective, RJG had been optimizing third-party process monitoring for years and offered multiple levels of process-monitoring software and hardware. I invited them to present their eDart system to the team, and while wrapping up this presentation they happened to mention a company in England that developed production-monitoring software that could run on the RJG’s eDart hardware.
 

Customization as Key

Intouch Monitoring provides user-interface software that can run on the RJG’s eDart HMI (human-machine interface). At first I was concerned that this could be my argument in reverse, with regard to process monitoring on production-monitoring systems—the polar opposite of we had been evaluating.

We invited Intouch Monitoring (intouchmonitoring.com) to our facility to present its system, and the differences between its product and the other production-monitoring systems were glaringly obvious. This was a robust system with a unique approach.

It offered multiple tools like job scheduler, Gantt charts, and OEE options, as well as bidirectional communication with many ERP systems, including the big names in the industry. Up until this point, I had become rather disappointed with the production-monitoring systems we had reviewed.

In particular, I was becoming more and more concerned that there was almost no customization available with these systems. That would mean that procedures would have to change at our facility to fit within the system, and change can be problematic when producing parts for the medical industry. It’s not just because people don’t like change (as most don’t), but there could be a cost or a customer approval required, or more likely both.

No matter what system you decide on, if it is not used, it is worthless to you.

Intouch’s approach was to customize reports to mimic the reports that we wanted to keep, and to work within the procedures that were required by our customer. This, as much as the software’s ability to run on the RJG eDart hardware, sold us on the system. So now we had identified the systems that we thought provided our best opportunity for success, and I was excited that we found two systems that each specialized in one type of monitoring. Because they share hardware, this would alleviate some of those concerns mentioned by other members of the management team.
 

Process and Production Integration

There were no more worries about the cost of HMIs for each system, but once I started to learn more about the Intouch software’s integration with the RJG eDart hardware, I realized there would still be an issue with getting team members to use two systems. To start a new job, the operator would have to begin on the Intouch software and then go back to the eDart side and start the job again. Even though the Intouch Monitoring software was installed on the eDart, the Intouch software had no idea it was on an eDart, and the eDart had no communication with the Intouch software.

So, when I said I was concerned about the integration of the two systems, that’s really because they weren't integrated at all. During the first meeting with both companies, I made it very clear that for us to proceed, the systems had to be integrated, and that’s when this project got exciting. It was surreal working with both teams, coming up with ideas and developing what would eventually become an award-winning, best-in-class system.

A production-monitoring system is only successful if people use it. If everyone is not willing to use the system, then it becomes a very expensive visual representation of your plant floor layout.

The integration at the machine was seamless. An operator would find the next job on the Intouch user-interface software, and once the start button was selected, that job would load up in both systems. Process templates and control limits would autopopulate on the eDart side, and cycle standards would populate on the Intouch side. As the integration evolved, the need to manually start a job was replaced with RJG’s mold-tag hardware. Once the eDart was connected to the mold’s pressure transducer or mold tag, Intouch would automatically load the job in both systems—a high-tech handshake of two leading monitoring companies. The system was eventually upgraded to the point that the machine would not start if the job wasn’t started in the monitoring system or if the water temperature wasn’t set properly. There is so much more these systems could do, and I could go on forever, but I would like to discuss a bit on the launch process that we used to help promote the use of the system. 
                                 

The Key to Success

A production monitoring system is only successful if people use it. Full stop, end of sentence. If everyone in your facility is not willing to use the system, then it becomes a very expensive visual representation of your plant floor layout. Those big screens throughout your plant look good, but if that’s all you want, it can be done much cheaper.

So the big challenge was: How do we get everyone willing to use this system? First off, picking the right team helps. One of my biggest takeaways from my lean training was the use of SMEs—subject matter experts—as part of either problem-solving or continuous-improvement projects. Involving the team members that actually do the work not only helps identify true root causes, it gives those team members ownership of the solutions. Solutions that they will then help hold other team members accountable for adhering to. Making sure this project had team members that would use the system as part of their daily responsibilities was key.

The next idea was to try to impact the current procedures as little as possible, specifically if they were effective. It is a good idea for the system to be used in conjunction with procedures and reports that you are already using. That’s a big one, by the way. What if the reports the system generates were to look similar, if not identical, to the reports that team members have been generating by hand?

This system-generated report therefore is something everyone is already familiar and comfortable with, but we are able to generate it in less time, with less resources, and often it’s real-time data, so you don’t have to wait 12 hours to find out you ran 10% scrap rates. Don’t get me wrong: In the end, we made many improvements that required changes, but we made them in stages, and we were able to do so because the system was so versatile.

We also tried to make changes that had as minimal an impact as possible on what the customer required. The best example for this was the cycle checklists that the process techs had been completing four times a day. We went as far as doing installation qualification on each machine when the system was installed to confirm the data was reliable, that an out-of-process shot was automatically rejected, and that excessive rejects would prompt a cycle interruption.

Even though we were now able to provide proof that every part packaged off the machine was within the validated process limits, the customer still required the four-times-a-day cycle checklist. So, I challenged the Intouch team to provide us this same checklist using the eDart data that could be printed and sent out with each customer shipment.

Since we had now fully integrated both systems, we were able to complete this action item and free up skilled technical resources to focus on value-added activities. This was the fun side of the project, but the true success of this system was still in the hands of the team members that needed to use it every day. So how did we do it?  I have to say it was a plan established by one of the founders of Intouch Monitoring. His background in manufacturing and launching the system represented a crawl-before-you-walk plan.

That seems obvious, right? We use that phrase all the time, but if you spend a million dollars of your boss’s budget, see how willing they are to watch this system crawl to action. It’s definitely a little more difficult when you think of it that way, isn’t it? It wasn’t quite that dramatic for us, but there was a great deal of pressure to get it utilized, as there should have been.

First step was just asking the team to enter a downtime code. That’s it. Enter a downtime code each and every time the HMI requests one. Every morning we would track the overall downtime and the coded downtime and communicate the results to the team members. We would spend additional time training team members with higher deltas, and we developed a process flow and procedure. These process flows and procedure would eventually be combined to create the system manual for our plant. We then got mold setters and process technicians entering their own downtime. Entering the correct downtime became second nature.

A machine would be stopped by a process technician for a mold change, and they would immediately select down for “material.” A material handler would change the material and immediately change the downtime to “changeover.” The mold setter would finish the mold change and change the downtime to “process technician,” and so on.

Think of the data this provided us to help reduce changeover times. We were able to quickly identify areas of waste during a changeover and make improvements. Once downtime was fully mastered, we started on scrap entry classification. Each new task would be mastered much more quickly than the preceding one, and even though it may have taken a little more time than just flipping a switch, the results were proving to be well worth it.

I can say with zero doubt that being involved in a project like this has been one of the highlights of my career. Pushing the entire team to solve issues to add functionality to this system—which at that time hadn’t been done before—and then seeing it work was very rewarding. I’m sure there is a point where the Intouch team was sick of hearing me say, “I need it to (insert unreasonable request here)—when can you have it ready?” Or having the RJG team look at me like a madman when I asked them to prove that a brand-new cavity-pressure transducer would be accurate, but then have them surprise me a few weeks later with transducer verification equipment. These systems can be tremendously successful and can provide hard dollar savings. The biggest challenge can be getting everyone to agree on a system, and sometimes you just have to thank everyone for their input—and then you make a decision.    

ABOUT THE AUTHOR: Robert Gattshall has more than 22 years’ experience in the injection molding industry and holds multiple certifications in Scientific Injection Molding and the tools of Lean Six Sigma. Gattshall has developed several “Best in Class” Poka Yoke systems with third-party production and process monitoring such as Intouch Monitoring Ltd. and RJG Inc. He has held multiple management and engineering positions throughout the industry in automotive, medical, electrical and packaging production. Gattshall is also a member of the Plastics Industry Association’s Public Policy Committee. In January 2018, he joined IPL Plastics as process engineering manager. Contact: (262) 909-5648; rgattshall@gmail.com.