Priorities, SLA and escalation

Priority, Severity, and Business Impact

Severity

Severity reflects the technical seriousness of the current condition.

Priority

Priority reflects the order in which work is performed.

Severity and Priority are not the same.

For example, an Issue may carry Severity = High together with Priority = P3.

Such a case is possible when the problem is technically serious but affects a standby asset with no current impact on the operation.

Impact Score

An integral score may be applied for ranking:

where:

• $S$ — severity;
• $B$ — business impact;
• $A$ — number or criticality of affected assets;
• $R$ — safety or regulatory risk;
• $D$ — duration.

Business Impact

OHM supports structured impact fields:

• number of affected devices;
• number of consumers or sites;
• volume of gas at risk;
• duration of degradation;
• potential data loss;
• risk of incorrect commercial metering;
• risk of a field visit;
• risk of an SLA violation;
• information security risk;
• cost of downtime;
• level of reputational impact.

Service Level Management

OHM implements a full-fledged SLA management model.

Control extends not only to the resolution of a problem, but to its entire processing cycle.

flowchart TD
  A["Issue Created"] --> B["Response SLA"]
  B --> C["Acknowledgement SLA"]
  C --> D["Resolution SLA"]
  D --> E["Verification SLA"]
  E --> F["Closure SLA"]

Each stage has its own calculation rules.

SLA Policy

The SLA policy defines:

• the allowed response time;
• the acknowledgement deadline;
• the resolution deadline;
• the verification deadline;
• escalation rules;
• the working calendar;
• exceptions.

The SLA is assigned automatically based on the canon, criticality, and object category.

Working Calendars

The system supports:

• 24×7;
• 12×7;
• business days;
• regional calendars;
• public holidays;
• individual department schedules.

Time outside the working calendar is not counted unless the SLA policy requires round-the-clock response.

SLA Timers

For each Issue, the system simultaneously calculates several independent timers.

For example:

• Time To Response;
• Time To Acknowledge;
• Time To Resolve;
• Time To Verify;
• Time To Close.

Each timer can have its own stop rules.

Pause Conditions

The SLA clock can be paused.

For example:

• waiting for a supplier;
• waiting for access;
• waiting for authorization;
• seasonal restrictions;
• force majeure.

The reason for the pause must be recorded.

SLA Breach

When an SLA is breached, the system automatically:

• changes the state;
• increases the risk level;
• triggers the Escalation Engine;
• creates an audit record;
• reflects the breach in the KPIs.

Escalation Engine

The Escalation Engine automatically transfers a problem to a higher level of responsibility when defined conditions are violated.

Escalation does not depend on user actions and is performed automatically.

Escalation Levels

A typical scenario:

flowchart TD
  P1["P1"] -->|"15 minutes"| L1["Shift Supervisor"]
  L1 -->|"1 hour"| L2["Regional Manager"]
  L2 -->|"4 hours"| L3["Operations Director"]

The specific intervals are defined by the organization’s policy.

Escalation Triggers

Escalation can be triggered by:

• a Response SLA breach;
• a Resolution SLA breach;
• the absence of an assignee;
• the absence of acknowledgement;
• reopening;
• massive scale;
• high Business Impact.

Escalation Actions

When a condition is met, the system can:

• notify the manager;
• change the owner;
• raise the Priority;
• create a Massive Incident;
• create an external ticket;
• notify senior management;
• initiate additional analysis.

All actions are fully logged.

Escalation History

The Issue card contains a complete log:

The history is never deleted and is used in calculating operational KPIs.