By John Gmutza, Principal Engineer

If it is doing its job, a manufacturing execution system (MES), fulfills the role of system of record by collecting “all” data associated with the manufacturing process:

  • Operation results
  • Cycle time
  • Traceability information (barcodes, etc.)
  • Process parameters
  • Defect reports
  • Etc.

The traditional way to tap into this data avalanche is with reports. A useful system has many reports covering all the parts of the database. A very useful system has ways to create targeted reports.

Ask, Don’t Tell

Reports are passive documents. They deliver actionable information only if asked the right “question,” which means the game is on for people in roles like Line Supervisor:

  • Which report contains the desired data?
  • Is this data collated in a way that answers the question?
  • Are there appropriate filtering criteria to “zero in” on the answer?

A system that provides hundreds of reports using the same data sliced-and-diced multiple ways without actionable information creates a time-consuming diversion from the question being researched which usually ends without a satisfying result.

Meanwhile, the underlying “problem” persists.

Don’t Quit Quitting

Even if a suitable report exists, the “passive document” quality of reports is still a barrier to timely acquisition of “higher-level” knowledge or situational awareness:

Situational awareness is the ability to identify, process and comprehend the critical elements of information about what is happening with regards to the “mission.

More simply, it’s knowing what is going on around you.

To reach a state of situational awareness with the passive document model presented by traditional reports requires vigilant monitoring for the “trigger” conditions present in that data. Unfortunately, very few of us have the luxury to “park it” all day in front of those report(s), frantically refreshing and scanning for “actionable intelligence.”

Rules Rule!

How can we flip this paradigm on its head? By turning passive documents into active documents, in the form of rules-driven notifications. This is the heart of Business Intelligence (BI).

This model directly implements the “trigger” conditions as rules in e.g. JavaScript, and runs on a dedicated “rules engine.”

Example: Instead of constantly refreshing the “Top 10 Defects Report” to analyze defect trends, program a rule to perform this analysis and send a notification if it “fires” based on trigger events or some combination of triggers.

Tell, Don’t Ask

As more triggers are identified, more rules are created. The rule engine manages the rule executions on a periodic basis (e.g. every 15 minutes), and actively monitors the conditions so the line isn’t dependent on one person viewing a report for detection.

Notification is a critical part of this process – it is what provides timely information delivery to those in a position to effect a remedy.

Continuing the example from the last section, when the “defect” rule fires, it “broadcasts” to interested parties, possibly via multiple communication channels:

  • Email
  • Text message
  • Audio alert
  • Etc.

This is awesome because the interested parties rarely have access to the reports containing the trigger information or the spare time to actively monitor them.

Example: A Line Supervisor, if they are working, is not in front of the computer running reports, they are on the line (supervising)! When the rules engine identifies the defect trend, the Line Supervisor receives an email or text message on their mobile device with the identifying information in-hand (e.g. “Excessive defects at Station OP10”).

To learn more about how you can create situational awareness in your plant, contact us.

Learn more about our MES system, IntelliWORKS, here.


About the Author: I am the Principal Architect of IntelliWORKS. I have decades of experience in the software industry and the main lesson I’ve learned is that technologies constantly change, but the sources of errors stay the same.