An event is embedded within a time continuum, something you can visualize as a line that has a start and an end. For example, the time allocated to a shift, the planned time of a work week, and so forth.

In this time span, we have time in which machines are scheduled to work and time in which they aren’t scheduled to work. We need to separate unscheduled production time from scheduled production time for accurate OEE analysis and other analytics. This ensures that time that’s off-limits due various reasons such as labor regulations or Kosher certification requirements (no work during the Sabbath), does not impact KPIs.

Scheduled production time is divided into three sub-categories: production time, planned stops that result in downtime and unplanned stops that result in downtime.

So the breakdown of a week's time for a machine could look like this:

And the weekly KPIs for this machine would be based on the scheduled time of 140 hours.

When applying the stop event data model for tagging your data accurately, you will first decide which stop event groups should be classified as Planned Downtime, which stop event groups should be classified as Unplanned Downtime, and which stop event groups should be classified as Unscheduled time.

After creating your groups per these classifications, you will assign the various stop event reasons to their groups. These reasons inherit automatically* the group's time classification. For example, you may have one group for labor related stops that are planned, and another group for labor related stops that are unplanned such as an operator's sick leave or accident.

In the following illustration you can see that the Maintenance group is classified as Planned Downtime and includes reasons for stops that are planned maintenance, while the Machine Failures group classified as Unplanned Downtime, includes reasons for stops that were not planned.

Finally, the Off Time group classified as Unscheduled, includes reasons in which the machine is not operating because it wasn't scheduled to work.

Distinguishing between unplanned stops to planned stops is important. A major goal is to reduce unexpected stops, but analyzing planned stops is also important since it contributes to ongoing improvement in production planning.

Now that you understand time management basic concepts, we’ll go over how you set this up and how to analyze stop event data.

For information about auto-reported micro stops, those very short stops that can be automatically tagged as such by the system to prevent distracting operators with these stops, while still aggregating their data and reporting stop event reasons, see the related articles section.

We consolidate various reasons into categorized groups to establish manageable entities with specific focuses. These groups are collectively monitored and analyzed, while still allowing for detailed examination of individual reasons within each group. In focusing solely on individual reasons, you risk losing sight of the broader context, and make it difficult to trace causal connections.

To illustrate, let's consider an example where we have organized reasons into five groups. As mentioned previously in the introduction, each group should be classified. This classification is indicated in parentheses.

To each group we added 3 reasons:

Next, let's establish targets. Setting targets provides us with a reference point for measuring performance. When our groups are coherent, it enables us to identify causal relationships between them. For instance, within the example groups, if our preventive maintenance activities are effective, we should achieve the target for reducing unplanned maintenance downtime. Conversely, if our preventive maintenance efforts are insufficient, it's likely that we'll surpass the target for unplanned maintenance downtime.

Analyzing the data according to specific reasons offers valuable insights into causality.

Stop event groups and reasons can be added manually through the Stop Events Customizations page, or imported using manual data sync, which is a more time-efficient method, especially suited for sites with many groups and many reasons.

Setting targets is available for each stop event group. You can do so when adding or updating a stop event group, or you might find it more convenient setting the targets for all groups at once through the dedicated Stop Events Group Targets page in the Targets Management module.

Setting the target % of each group reflects what you consider to be acceptable downtime for this stop event reasons group out of the scheduled production time.

The system supports either setting a general target % for the group, or setting in advance monthly targets for the year.

Setting monthly targets aligns with operational excellence in manufacturing principles by gradually incrementing the target improvement to reach your final target. For example, in January the target downtime percentage could be 11% and gradually be adjusted month by month until December where it could be 7%.

However your system is configured (general target or monthly targets), Matics provides maximum flexibility and target values can be adjusted as needed.

Matics converts these targets to percentage-based infographics featuring informative tooltips, which compare the set targets to actual performance values, so you can understand just how close to your mark these actual values are.

To conclude:

Matics offers (a) the flexibility to set and continually adjust targets, (b) an extensive selection of real-time data shift components and historical aggregated-data insights, and (c) automation capabilities through rules to trigger actions based on performance relative to targets. For instance, in cases where unplanned downtime surpasses the predetermined target, automated notifications can be triggered to alert relevant stakeholders before the target is reached and thus potentially mitigate the issue.

Instructions on how to do so are part of the Manual Sync article.

You can see how well the reporting of stop event reasons for each machine is going through the Shift tab's Machine Performance - Table View component, or the Aggregated Machines Performance component. In the manager app's Shift tab for each machine you can see this in the Unreported Stops infographic.

Retroactive analysis of reported and unreported stop events by machine is offered through insight 100.

The special case of certain CNC machines that have a phase during production in which the machine itself isn't working while its operator is performing manual work, required a way to tag this pseudo downtime correctly. This is offered through the work type called Manual work when configuring stop reasons.

Reasons are part of groups and usually inherit the group's classification (Unscheduled, Planned, Unplanned), but in this case the system ignores the group classification and knows to add this type of stop reason to production time.

Since you have to choose a group classification, it makes sense to group Manual work reasons under the Planned classification.

Even though time spent on manual work is aggregated under production time, various insights provide you with data analytics regarding manual work per se, for example insight #157: Time distribution by machine.

Configuring Stop Event Generation

Reporting Stop Event Reasons