Prioridades, SLA y escalado

Prioridad, Severity e impacto de negocio

Criticidad (Severity)

Severity refleja la gravedad técnica del estado actual.

Prioridad (Priority)

Priority refleja el orden en que se ejecutan los trabajos.

Severity y Priority no son lo mismo.

Por ejemplo, un Issue puede tener Severity = High junto con Priority = P3.

Un caso así es posible cuando el problema es técnicamente grave pero afecta a un activo de reserva, sin impacto actual sobre la operación.

Puntuación integral (Impact Score)

Para el ranking puede aplicarse una puntuación integral:

donde:

• $S$ — criticidad;
• $B$ — impacto de negocio;
• $A$ — número o criticidad de los activos afectados;
• $R$ — riesgo de seguridad o regulatorio;
• $D$ — duración.

Impacto de negocio (Business Impact)

OHM admite campos estructurados de impacto:

• número de dispositivos afectados;
• número de consumidores o emplazamientos;
• volumen de gas en riesgo;
• duración de la degradación;
• posible pérdida de datos;
• riesgo de una medición comercial incorrecta;
• riesgo de un desplazamiento a campo;
• riesgo de incumplimiento del SLA;
• riesgo de seguridad de la información;
• coste del tiempo de inactividad;
• nivel de impacto reputacional.

Gestión del nivel de servicio (SLA)

OHM implementa un modelo completo de gestión de SLA.

El control no abarca solo la resolución del problema, sino todo su ciclo de tratamiento.

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

Cada etapa tiene sus propias reglas de cálculo.

Política SLA

La política SLA define:

• el tiempo de respuesta admisible;
• el plazo de confirmación;
• el plazo de resolución;
• el plazo de verificación;
• las reglas de escalado;
• el calendario laboral;
• las excepciones.

El SLA se asigna automáticamente en función del canon, la criticidad y la categoría del objeto.

Calendarios laborales

El sistema admite:

• 24×7;
• 12×7;
• días laborables;
• calendarios regionales;
• días festivos;
• horarios propios de cada departamento.

El tiempo fuera del calendario laboral no se contabiliza, salvo que la política SLA exija una respuesta ininterrumpida.

Temporizadores de SLA

Para cada Issue, el sistema calcula simultáneamente varios temporizadores independientes.

Por ejemplo:

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

Cada temporizador puede tener sus propias reglas de parada.

Condiciones de pausa

El cómputo del SLA puede pausarse.

Por ejemplo:

• espera de un proveedor;
• espera de acceso;
• espera de autorización;
• restricciones estacionales;
• fuerza mayor.

El motivo de la pausa debe quedar registrado.

Incumplimiento del SLA

Cuando se incumple un SLA, el sistema automáticamente:

• cambia el estado;
• eleva el nivel de riesgo;
• activa el Escalation Engine;
• genera un registro de auditoría;
• refleja el incumplimiento en los KPI.

Motor de escalado (Escalation Engine)

El Escalation Engine transfiere automáticamente el problema a un nivel superior de responsabilidad cuando se incumplen las condiciones establecidas.

El escalado no depende de las acciones del usuario y se ejecuta de forma automática.

Niveles de escalado

Escenario típico:

flowchart TD
  P1["P1"] -->|"15 minutos"| L1["Jefe de turno"]
  L1 -->|"1 hora"| L2["Responsable regional"]
  L2 -->|"4 horas"| L3["Director de operaciones"]

Los intervalos concretos los define la política de la organización.

Disparadores del escalado

El escalado puede desencadenarse por:

• el incumplimiento del Response SLA;
• el incumplimiento del Resolution SLA;
• la ausencia de ejecutor asignado;
• la ausencia de confirmación;
• la reapertura;
• el carácter masivo;
• un Business Impact elevado.

Acciones de escalado

Cuando se cumple una condición, el sistema puede:

• notificar al responsable;
• cambiar el propietario;
• elevar la Priority;
• crear un Massive Incident;
• crear un ticket externo;
• notificar a la alta dirección;
• iniciar un análisis adicional.

Todas las acciones quedan íntegramente registradas.

Historial de escalados

La ficha del Issue contiene un registro completo:

El historial nunca se elimina y se utiliza en el cálculo de los KPI operativos.