Execution and work queue

The Operational Health Matrix treats the remediation of operational problems as a managed process rather than a set of independent tasks.

After an Operational Issue is created, the system automatically builds the work context, determines the responsible operational zone, applies the corresponding SLA policy, and places the object into the execution queue.

This ensures a continuous work management cycle from the moment a problem is detected until the confirmed restoration of the equipment’s normal state.

Execution Model

Every Operational Issue passes through a single execution cycle.

flowchart TD
  A["Detection"] --> B["Operational Issue"]
  B --> C["Ownership"]
  C --> D["Planning"]
  D --> E["Execution"]
  E --> F["Verification"]
  F --> G["Closure"]
  G --> H["Continuous Improvement"]

At each stage, the system records:

• the responsible party;
• deadlines;
• state;
• change log;
• Evidence;
• related tasks;
• applied Knowledge Base articles;
• verification results.

Operational Ownership

Responsibility is determined by the operational zone, not by a user.

For example:

Once the zone is determined, the system assigns a specific engineer based on:

• competence;
• workload;
• region;
• work schedule;
• current backlog;
• clearance level.

If necessary, a manager can change the assignment manually.

Work Queue

The work queue is a dynamic view of active Operational Issues.

Unlike a traditional task list, the queue is built from a combination of factors:

• Priority;
• Severity;
• Operational Confidence;
• SLA Remaining Time;
• Business Impact;
• Number of Affected Assets;
• Reopen Count;
• Root Cause Confidence.

By default, the most critical objects automatically rise to the top regardless of creation time.

Queue Categories

OHM supports several specialized queues.

Incoming

New problems awaiting triage.

Assigned

Problems assigned to an engineer.

In Progress

Work currently underway.

Awaiting Verification

Work completed, awaiting confirmation.

Overdue

SLA requirements have been violated.

Escalated

Automatically escalated problems.

Reopened

Problems that recurred after closure.

Massive Incidents

Systemic operational incidents.

Queue Prioritization

The system uses an integral priority for ranking.

For example:

where

• P — Priority;
• S — Severity;
• B — Business Impact;
• C — Operational Confidence;
• T — Remaining SLA Time.

The resulting score is used exclusively for sorting the queue and does not change the object’s official Priority.

Bulk Operations

OHM supports bulk operations on a group of Operational Issues.

For example:

• change the owner;
• change the zone;
• change the SLA;
• assign a common Root Cause;
• merge into a Massive Incident;
• apply a Knowledge Article;
• change the priority;
• export.

All bulk actions are recorded in the Audit Trail.

Capacity Awareness

Work assignment takes into account the actual workload of departments.

Each engineer is characterized by:

• Active Issues;
• Verification Queue;
• Planned Work;
• Availability;
• Current Capacity.

If the workload exceeds the defined limit, the system recommends redistributing the work.

Workload Distribution

The system uses balancing to prevent overload.

Distribution takes into account:

• the number of open Issues;
• total criticality;
• average resolution time;
• competences;
• territorial affiliation;
• history of performing similar work.

Mobile Execution

The field version of OHM provides the engineer with:

• the asset card;
• the route;
• the history;
• the latest Evidence;
• related photographs;
• instructions;
• Knowledge Articles;
• the ability to attach new materials;
• an electronic signature;
• confirmation of completion.

After synchronization, the information immediately becomes available to the dispatcher.