Esecuzione e coda di lavoro

Come viene svolto il lavoro — titolarità operativa, coda di lavoro ordinata dinamicamente, operazioni massive, assegnazione che tiene conto della capacity ed esecuzione mobile sul campo.

Operational Health Matrix considera la risoluzione dei problemi di esercizio come un processo gestito e non come un insieme di attività indipendenti.

Dopo la creazione di un Operational Issue, il sistema costruisce automaticamente il contesto di lavoro, determina la zona operativa responsabile, applica la politica SLA corrispondente e colloca l’oggetto nella coda di esecuzione.

In questo modo è garantito un ciclo continuo di gestione dei lavori, dal momento in cui il problema viene rilevato fino al ripristino confermato del normale stato dell’apparecchiatura.

Modello di esecuzione

Ogni Operational Issue attraversa un unico ciclo di esecuzione.

flowchart TD
  A["Rilevazione"] --> B["Operational Issue"]
  B --> C["Titolarità"]
  C --> D["Pianificazione"]
  D --> E["Esecuzione"]
  E --> F["Verifica"]
  F --> G["Chiusura"]
  G --> H["Miglioramento continuo"]

In ogni fase il sistema registra:

  • il responsabile;
  • le scadenze;
  • lo stato;
  • il registro delle modifiche;
  • le Evidence;
  • i Task correlati;
  • gli articoli della Knowledge Base applicati;
  • gli esiti della verifica.

Titolarità operativa

La responsabilità è determinata dalla zona operativa e non dal singolo utente.

Ad esempio:

CanonTitolare predefinito
no_hourly_archiveIntegrazione backend
stale_communicationTeam comunicazioni
battery_lowAssistenza sul campo
pressure_sensor_stuckMetrologia
firmware_regressionTeam firmware
registry_duplicateAmministrazione del registro

Una volta determinata la zona, il sistema assegna un ingegnere specifico in base a:

  • competenze;
  • carico di lavoro;
  • regione;
  • orario di lavoro;
  • backlog corrente;
  • livello di autorizzazione.

Se necessario, il responsabile può modificare manualmente l’assegnazione.

Coda di lavoro

La coda di lavoro è una vista dinamica degli Operational Issues attivi.

A differenza di un tradizionale elenco di attività, la coda è costruita a partire da una combinazione di fattori:

  • priorità (Priority);
  • gravità (Severity);
  • confidenza operativa (Operational Confidence);
  • tempo SLA residuo;
  • impatto sul business (Business Impact);
  • numero di Asset interessati;
  • numero di riaperture (Reopen Count);
  • confidenza sulla Root Cause.

Per impostazione predefinita, gli oggetti più critici risalgono automaticamente in cima alla coda, indipendentemente dal momento della creazione.

Schermata della coda di lavoro personale con l'elenco dei problemi di esercizio raggruppati per stato e gli elementi scaduti in cima. Schermata della coda di lavoro personale con l'elenco dei problemi di esercizio raggruppati per stato e gli elementi scaduti in cima.
La mia coda: prima gli scaduti, poi da prendere in carico / in lavorazione / in attesa di conferma dai dati

Categorie di code

OHM supporta diverse code specializzate.

In arrivo (Incoming)

Nuovi problemi in attesa di triage.

Assegnati (Assigned)

Problemi assegnati a un ingegnere.

In lavorazione (In Progress)

Lavori attualmente in corso.

In attesa di verifica (Awaiting Verification)

Lavori completati, in attesa di conferma.

Scaduti (Overdue)

I requisiti SLA sono stati violati.

In escalation (Escalated)

Problemi sottoposti automaticamente a escalation.

Riaperti (Reopened)

Problemi ripresentatisi dopo la chiusura.

Incidenti massivi (Massive Incidents)

Incidenti sistemici di esercizio.

Prioritizzazione della coda

Per l’ordinamento il sistema utilizza una priorità integrale.

Ad esempio:

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

dove

  • P — Priority (priorità);
  • S — Severity (gravità);
  • B — Business Impact (impatto sul business);
  • C — Operational Confidence;
  • T — tempo SLA residuo.

Il punteggio ottenuto è utilizzato esclusivamente per ordinare la coda e non modifica la Priority ufficiale dell’oggetto.

Operazioni massive

OHM supporta operazioni massive su un gruppo di Operational Issues.

Ad esempio:

  • cambiare il titolare;
  • cambiare la zona;
  • cambiare l’SLA;
  • assegnare una Root Cause comune;
  • unire in un Massive Incident;
  • applicare una Knowledge Article;
  • cambiare la priorità;
  • esportare.

Tutte le azioni massive vengono registrate nell’Audit Trail.

Considerazione della capacity

L’assegnazione dei lavori tiene conto del carico effettivo dei reparti.

Ogni ingegnere è caratterizzato da:

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

Se il carico supera il limite stabilito, il sistema raccomanda una ridistribuzione dei lavori.

Distribuzione del carico

Per prevenire il sovraccarico il sistema applica il bilanciamento.

Nella distribuzione vengono considerati:

  • il numero di Issues aperti;
  • la criticità complessiva;
  • il tempo medio di risoluzione;
  • le competenze;
  • l’appartenenza territoriale;
  • lo storico dei lavori analoghi eseguiti.

Esecuzione mobile

La versione da campo di OHM mette a disposizione dell’ingegnere:

  • la scheda dell’Asset;
  • il percorso;
  • lo storico;
  • le ultime Evidence;
  • le fotografie correlate;
  • le istruzioni;
  • le Knowledge Articles;
  • la possibilità di allegare nuovi materiali;
  • la firma elettronica;
  • la conferma di completamento.
Vista in formato telefono della dashboard di Operations Center con la coda dell'ingegnere sul campo e i dettagli dell'asset. Vista in formato telefono della dashboard di Operations Center con la coda dell'ingegnere sul campo e i dettagli dell'asset.
Layout responsive: lo stesso Operations Center su telefono

Dopo la sincronizzazione, le informazioni diventano immediatamente disponibili all’operatore di centrale.

Argomenti correlati

Ultimo aggiornamento il

Questa pagina è stata utile?