Ejecución y cola de trabajo

Cómo se ejecuta el trabajo — propiedad operativa, cola de trabajo con ranking dinámico, operaciones masivas, asignación según la carga y ejecución móvil en campo.

Operational Health Matrix aborda la resolución de los problemas operativos como un proceso gestionado y no como un conjunto de tareas independientes.

Tras la creación de un Operational Issue, el sistema construye automáticamente el contexto de trabajo, determina la zona de responsabilidad a la que corresponde, aplica la política SLA correspondiente y coloca el objeto en la cola de ejecución.

De este modo se garantiza un ciclo continuo de gestión de los trabajos, desde el momento en que se detecta el problema hasta la restauración confirmada del estado normal del equipo.

Modelo de ejecución

Todo Operational Issue recorre un único ciclo de ejecución.

flowchart TD
  A["Detección"] --> B["Operational Issue"]
  B --> C["Propiedad operativa"]
  C --> D["Planificación"]
  D --> E["Ejecución"]
  E --> F["Verificación"]
  F --> G["Cierre"]
  G --> H["Mejora continua"]

En cada etapa el sistema registra:

  • el responsable;
  • los plazos;
  • el estado;
  • el registro de cambios;
  • las Evidence;
  • las tareas relacionadas;
  • los artículos aplicados de la Knowledge Base;
  • los resultados de la verificación.

Propiedad operativa

Al responsable lo determina la zona de responsabilidad, no un usuario concreto.

Por ejemplo:

CanonPropietario por defecto
no_hourly_archiveIntegración backend
stale_communicationEquipo de comunicaciones
battery_lowServicio de campo
pressure_sensor_stuckMetrología
firmware_regressionEquipo de firmware
registry_duplicateAdministración del registro

Una vez determinada la zona, el sistema asigna un ingeniero concreto teniendo en cuenta:

  • la competencia;
  • la carga de trabajo;
  • la región;
  • el horario de trabajo;
  • el backlog actual;
  • el nivel de habilitación.

Si es necesario, el responsable puede cambiar la asignación manualmente.

Cola de trabajo

La cola de trabajo es una vista dinámica de los Operational Issues activos.

A diferencia de una lista de tareas tradicional, la cola se construye a partir de una combinación de factores:

  • prioridad (Priority);
  • criticidad (Severity);
  • confianza operativa (Operational Confidence);
  • tiempo restante de SLA;
  • impacto de negocio (Business Impact);
  • número de activos afectados;
  • número de reaperturas (Reopen Count);
  • confianza en la Root Cause.

Por defecto, los objetos más críticos suben automáticamente a la parte superior, con independencia del momento de creación.

Pantalla de la cola de trabajo personal con los problemas operativos agrupados por estado y los elementos vencidos situados en la parte superior. Pantalla de la cola de trabajo personal con los problemas operativos agrupados por estado y los elementos vencidos situados en la parte superior.
Mi cola: primero los vencidos, después los pendientes de tomar / en curso / a la espera de confirmación por datos

Categorías de colas

OHM admite varias colas especializadas.

Entrantes (Incoming)

Problemas nuevos a la espera de triaje.

Asignados (Assigned)

Problemas asignados a un ingeniero.

En curso (In Progress)

Trabajos que se están ejecutando en este momento.

A la espera de verificación (Awaiting Verification)

Trabajos terminados, a la espera de confirmación.

Vencidos (Overdue)

Se han incumplido los requisitos del SLA.

Escalados (Escalated)

Problemas escalados automáticamente.

Reabiertos (Reopened)

Problemas que se han vuelto a producir tras el cierre.

Incidentes masivos (Massive Incidents)

Incidentes operativos sistémicos.

Priorización de la cola

Para el ranking el sistema utiliza una prioridad integral.

Por ejemplo:

PriorityScore=wpP+wsS+wbB+wcC+wtTPriorityScore = w_p P + w_s S + w_b B + w_c C + w_t T

donde

  • P — Priority (prioridad);
  • S — Severity (criticidad);
  • B — Business Impact (impacto de negocio);
  • C — Operational Confidence (confianza operativa);
  • T — tiempo restante de SLA.

El valor resultante se emplea exclusivamente para ordenar la cola y no modifica la Priority oficial del objeto.

Operaciones masivas

OHM admite operaciones masivas sobre un grupo de Operational Issues.

Por ejemplo:

  • cambiar el propietario;
  • cambiar la zona;
  • cambiar el SLA;
  • asignar una Root Cause común;
  • fusionar en un Massive Incident;
  • aplicar un Knowledge Article;
  • cambiar la prioridad;
  • exportar.

Todas las acciones masivas quedan registradas en el Audit Trail.

Consideración de la capacidad (capacity)

La asignación de los trabajos tiene en cuenta la carga real de los departamentos.

Cada ingeniero se caracteriza por:

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

Si la carga supera el límite establecido, el sistema recomienda redistribuir los trabajos.

Distribución de la carga

Para evitar la sobrecarga, el sistema aplica un balanceo.

En la distribución se tienen en cuenta:

  • el número de Issues abiertos;
  • la criticidad total;
  • el tiempo medio de resolución;
  • las competencias;
  • la adscripción territorial;
  • el historial de trabajos similares realizados.

Ejecución móvil

La versión de campo de OHM ofrece al ingeniero:

  • la ficha del activo;
  • la ruta;
  • el historial;
  • las últimas Evidence;
  • las fotografías asociadas;
  • las instrucciones;
  • los Knowledge Articles;
  • la posibilidad de adjuntar nuevos materiales;
  • la firma electrónica;
  • la confirmación de la finalización.
Vista del dashboard de Operations Center en formato de teléfono con la cola del ingeniero de campo y los detalles del activo. Vista del dashboard de Operations Center en formato de teléfono con la cola del ingeniero de campo y los detalles del activo.
Diseño adaptativo: el mismo Operations Center en un teléfono

Tras la sincronización, la información queda disponible de inmediato para el despachador.

Temas relacionados

¿Te resultó útil esta página?