Skip to content

Classify operating modes (the classification queue)

Shifts record when the plant ran in which operating mode — but whether a stop was planned maintenance or a technical failure is a human decision. That classification is what gives the availability KPIs (MA · OA · OSF) their meaning: whatever you leave unclassified shows up in the metric as unclassified time, and the UI states a lower bound for how much it may hurt. Ideally this is a daily routine — part of the morning meeting.

  • Permission: analytics:classify — without it you can see the queue, but the page says: “You have no right to classify — your administrator can grant it (Master data → Roles).” Validation is a separate right (analytics:validate) — deliberately: the person who classifies and the person who signs off can be two different people.
  • Prerequisite: an applied recipe (it provides the classification categories — see the Recipes page) and recorded operating-mode segments in the shift log.
  1. Open the classification queue. From the analytics overview header via the “Classification — {recipe}” button, or — when the unclassified downtime warning shows at the top of the page — via the “Classification” link next to it. The queue always belongs to one site: the site picker in the tab bar tells you which one.
  2. Pick the period. The ‹ › stepper under the title moves between months (or the selected period kind) — last month’s backlog is reached the same way. The “Recorded” filter shows only entries awaiting classification; the “Period” button shows every entry of the period, including already classified ones.
  3. Classify the segment. Pick the category from the row’s dropdown (only the deepest level is selectable — the parents follow from it), then “Save classification”. The list shows where each value came from: ⚙ = catalogue rule · ✎ = manual classification — manual always beats the rule.
  4. (If you have the right) validate. The “Validate” button moves the classified row to “Validated”. Re-classifying resets validation — the sign-off applied to the old content.

The row’s state goes “Recorded” → “Classified” (after validation, “Validated”), and the affected period’s metrics are recomputed — the unclassified-time warning on the dashboard shrinks or disappears. Every classification leaves an audit trail: who decided, and when.

What you see Why What to do
“You have no right to classify — your administrator can grant it (Master data → Roles).” You lack the analytics:classify right. Ask your administrator; the right is a toggle in Master data → Roles.
“No entries awaiting classification on this site.” Everything in this period is classified — or you are looking at another site’s queue. Step to an earlier period with ‹ ›, or switch sites in the tab bar.
“The Analytics module is disabled — your classifications stay readable and exportable, but new ones cannot be recorded.” The module entitlement is off. Reading/exporting still works; enabling is done on the provider (OPEREX) side.
“Too many rows ({n}) — pick a shorter period and download again.” The CSV download hit the row cap. Narrow the period with the stepper and download in parts.
  • Unclassified time is never treated as zero-impact. The metric does not guess: the UI states a lower bound for how much unclassified time may hurt — which is exactly why keeping the queue current pays off.
  • Rule-based (⚙) classification is only a default. It comes from the recipe’s catalogue; your manual (✎) decision overrides it, and the system never swaps it back on its own.
  • Download: “Download classification (CSV)” carries the currently filtered period — “The classification is your work — it stays downloadable even when the module is off.”

Last updated: