SOP for akut instrumentfejlfinding

En SOP for akut instrumentfejlfinding: indhent procesdata om en endnu unavngiven fejl, diagnosticer det implicerede instrument, vej sikkerhed og produktionshastegrad, og vælg fjernløsning eller feltudkald.

Brug denne skabelon

Hvad er SOP for akut instrumentfejlfinding?

En kunde ringer ikke til Insatechs ServiceDesk for at rapportere, at en transmitter er fejlet. De ringer for at sige, at reaktortemperaturen driver, at en flowtotal ikke stemmer med masseblancen, eller at en alarm ikke vil klare, og i det øjeblik ved ingen, hverken operatøren i telefonen eller den, der tager opkaldet, endnu hvilken sløjfe der reelt er fejlbehæftet. Det hul er grunden til, at dette diagram sætter "Indhent procesdata og symptomer fra kunden" og "Diagnosticer hvilket instrument eller hvilken måling der er impliceret" før noget, der ligner en løsningsbeslutning: et femminutters opkald, der springer direkte til "send en tekniker", kan udkalde nogen til den forkerte del af anlægget, mens et femminutters opkald, der springer direkte til "prøv at nulstille den", kan guide en kunde gennem den forkerte sløjfe på en proces, der stadig er nedbrudt. Diagnosetrinnet findes, fordi fejlen ved indtag har et symptom, endnu ikke et navn.

"Vurder sikkerheds- og produktionskonsekvens samt hastegrad" ligger bevidst mellem diagnose og beslutningen "Fjernfejlfinding tilstrækkelig?", ikke efter den. En drivende niveautransmitter på en ikke-kritisk buffertank og en fejlet tryktransmitter på en sikkerhedsinstrumenteret sløjfe giver samme slags telefonopkald, men de kan ikke få samme respons, og Insatech har ikke råd til at opdage det ved først at beslutte, hvordan det skal fikses, og først bagefter spørge, om løsningen var akut nok til at retfærdiggøre en tekniker på vejen. Dette er den akutte, ikke-planlagte søster til SOP for servicebesøg: anmodning og udkald: den SOP's ServiceDesk-triage forudsætter, at problemet allerede er afgrænset, og ruter det simpelthen fjern-eller-på-stedet ud fra bekvemmelighed og kompleksitet, mens denne starter fra en proces, der er nedbrudt lige nu, et instrument der endnu ikke er identificeret, og et konsekvensopkald, der skal foretages, før fjern-versus-udkald-beslutningen, ikke foldet ind i den.

Diagrammet antager ikke, at den første løsning virker. "Test instrumentet og bekræft at procesaflæsningen er korrekt" fører ind i en anden beslutning, "Fejl bekræftet løst?", og et "Nej" ruter til "Eskaler til engineering for yderligere diagnose" frem for at lukke sagen på en reparation, der reelt ikke er verificeret mod processen. Hver række bærer også en navngiven ansvarlig og et timetal via de indbyggede kolonner People og Workload, så BI-panelet for arbejdsbyrde på tværs af en uge med ikke-planlagte opkald kan vise, hvor meget af Nadia Kirks tid der gik til diagnose og fjernløsninger, over for hvor meget af Thomas Riis' gik til reparationer på stedet, på en proceslinje hvor intet af det var planlagt på forhånd.

Hvad dette flowchart dækker

I denne skabelon

  • Indtag under diagnostisk usikkerhed: "Kunde rapporterer procesproblem" over "Indhent procesdata og symptomer fra kunden" til "Diagnosticer hvilket instrument eller hvilken måling der er impliceret", trinnet der gør et vagt symptom til en navngiven sløjfe
  • Konsekvensvurdering før beslutningen: "Vurder sikkerheds- og produktionskonsekvens samt hastegrad" kører før beslutningen "Fjernfejlfinding tilstrækkelig?", ikke efter, så hastegraden fastlægges, mens responsen stadig vælges
  • Fjern-eller-udkald-grenen: et "Ja" fører til "Guid kunden gennem korrigerende handling på afstand", mens et "Nej" fører til "Tildel og udkald feltteknikker til stedet", "Klargør kalibreret reserveinstrument og referenceudstyr" i Kalibreringslaboratorium-banen og "Reparer eller udskift instrumentet på stedet" i Feltservice
  • Verifikation før afslutning: begge veje mødes ved "Test instrumentet og bekræft at procesaflæsningen er korrekt", der fører ind i beslutningen "Fejl bekræftet løst?" frem for at antage, at den første løsning holdt
  • Fornyet diagnose-sløjfen: et "Nej" på "Fejl bekræftet løst?" ruter til "Eskaler til engineering for yderligere diagnose" og tilbage ind i diagnosetrinnet, i stedet for at lade en uløst sag stå markeret som lukket
  • Navngivne ansvarlige og timetal på hver række via kolonnerne People og Workload, så BI-panelet for arbejdsbyrde kan adskille Nadia Kirks fjerndiagnosetimer fra Thomas Riis' reparationstimer på stedet på tværs af en uge med ikke-planlagte akutopkald

Hvornår du skal bruge skabelonen

  • I standardiserer, hvordan Insatechs ServiceDesk og Feltservice håndterer en akut, uafgrænset procesklage, hvor den ringende endnu ikke kan fortælle jer, hvilket instrument der er forkert, og vil have rækkefølgen diagnose-før-beslutning fastlagt på ét diagram frem for overladt til, hvem der tilfældigvis tager telefonen
  • I har brug for en klar grænse mellem denne SOP og SOP for servicebesøg: anmodning og udkald: denne er til en proces, der er nedbrudt lige nu, med instrumentet stadig uidentificeret, den anden til en anmodning, der allerede er afgrænset
  • En tekniker blev udkaldt til noget, der viste sig at kunne løses over telefonen, eller en kunde blev guidet gennem en løsning på en sløjfe, der reelt krævede en sikkerhedskritisk instrumentudskiftning, og I vil have konsekvens-før-beslutning-porten til at fange det tidligere næste gang
  • I onboarder en ny ServiceDesk-koordinator eller feltteknikker og skal have en reference for præcis, hvad der bliver spurgt om og vurderet, før et fjern-eller-udkald-opkald træffes
  • En første reparation holdt ikke, og I vil have en dokumenteret eskaleringsvej ind i yderligere diagnose, i stedet for at sagen stille og roligt genåbnes, som var den ny

Sådan fungerer det

  1. Erstat banerne med jeres faktiske responsroller

    Dette diagram bruger ServiceDesk, Feltservice, Kalibreringslaboratorium og Engineering. Hvis jeres ServiceDesk- og udkaldsfunktioner er adskilt, eller et separat specialistteam ejer eskaleret diagnose, så giv den rolle sin egen bane frem for at folde den ind i Feltservice, siden overleveringen som regel er der, hvor et symptom stille og roligt antages diagnosticeret af nogen, der antog, at nogen anden allerede havde indsnævret det.

  2. Skriv reelle hastegradskriterier ind i konsekvensvurderingen

    "Vurder sikkerheds- og produktionskonsekvens samt hastegrad" har brug for et angivet grundlag, for eksempel om den impliceret sløjfe er sikkerhedsinstrumenteret, knyttet til en tilladelsesgrænse, eller driver en produktionsstandsning, ikke bare et mavefornemmelses-skøn. Sæt de faktiske kriterier ind i rækkens kommentarfelt, så den der træffer fjern-eller-udkald-beslutningen, ikke er afhængig af hukommelsen om, hvad der tæller som akut.

  3. Sæt en reel tærskel på fjern-versus-udkald-beslutningen

    "Fjernfejlfinding tilstrækkelig?" er kun en sikker gren, hvis der er en aftalt grænse for, hvornår telefonvejledning ophører med at være passende, for eksempel enhver sikkerhedsinstrumenteret sløjfe eller ethvert gentaget opkald om samme fejl. Angiv den tærskel eksplicit frem for at overlade den til, hvem der har opkaldet den dag.

  4. Sæt People og Workload på hver række, før I stoler på BI-panelet

    Workload-panelet kan kun summere timer for de rækker, der har dem. Udfyld People og Workload for hvert trin, mens I tilpasser diagrammet, og brug realistiske indsatstimer frem for forløbet tid, så en ikke-planlagt akutuge rent faktisk viser sig som en travl uge for den rette person.

  5. Beslut, hvad der lukker fornyet diagnose-sløjfen

    "Fejl bekræftet løst?" fungerer kun, hvis der er en angivet test, for eksempel en stabiliseret aflæsning over en defineret periode, der tæller som bekræftelse. Ellers kan en tekniker under tidspres markere en fejl som løst ved det første plausible fix i stedet for et verificeret, og sløjfen tilbage gennem "Eskaler til engineering for yderligere diagnose" udløses aldrig, når den skulle.

Ofte stillede spørgsmål

Hvad udløser starten på den akutte fejlfindingsproces?

Processen starter ved "Kunde rapporterer procesproblem": en kunde ringer og beskriver en proces, der opfører sig forkert, ikke en navngiven instrumentfejl. "Indhent procesdata og symptomer fra kunden" og "Diagnosticer hvilket instrument eller hvilken måling der er impliceret" findes netop, fordi det på dette tidspunkt endnu ikke er fastslået, hvilken sløjfe der reelt er fejlbehæftet.

Hvordan adskiller denne sig fra SOP for servicebesøg: anmodning og udkald?

SOP for servicebesøg: anmodning og udkald forudsætter, at problemet allerede er afgrænset, og triagerer simpelthen en allerede forstået anmodning mellem fjernsupport og et besøg på stedet. Denne SOP starter tidligere og under mere pres: en proces der er nedbrudt lige nu, et instrument der endnu ikke er identificeret, og en sikkerheds-/produktionskonsekvensvurdering, der skal ske, før fjern-eller-udkald-opkaldet, ikke foldet ind i det.

Hvorfor kommer konsekvensvurderingen før fjern-versus-udkald-beslutningen frem for under den?

"Vurder sikkerheds- og produktionskonsekvens samt hastegrad" er en separat række, der kører før "Fjernfejlfinding tilstrækkelig?", så hastegraden fastlægges på sit eget grundlag, for eksempel om en sikkerhedsinstrumenteret sløjfe er impliceret, frem for at blive foldet ind i bekvemmeligheden ved, hvilken respons der tilfældigvis er lettest at arrangere den dag.

Hvad sker der, hvis løsningen, fjern eller på stedet, ikke reelt løser fejlen?

Begge veje mødes ved "Test instrumentet og bekræft at procesaflæsningen er korrekt", der fører ind i beslutningen "Fejl bekræftet løst?". Et "Nej" ruter til "Eskaler til engineering for yderligere diagnose" og tilbage ind i diagnose, så en uløst sag diagnosticeres på ny med specialistviden i stedet for at blive lukket på en uverificeret løsning.

Hvem beslutter, om et reserveinstrument byttes ind frem for repareret?

Den beslutning ligger inde i "Klargør kalibreret reserveinstrument og referenceudstyr" i Kalibreringslaboratorium-banen: for en sikkerhedsinstrumenteret eller produktionskritisk sløjfe er en direkte udskiftning fra kalibreret lagerbeholdning som regel hurtigere og sikrere end et forsøg på feltreparation, hvilket er derfor rækken findes som sit eget trin frem for foldet ind i "Reparer eller udskift instrumentet på stedet".

Del af

QueryChart-funktioner til denne proces

Brug denne skabelon

Mere i SOP-skabeloner

Browse all SOP-skabeloner

Akut instrumentfejlfinding (fra rapport til genoprettet drift): Indtag → Diagnose → Konsekvens og responsbeslutning → Løsning → Verifikation og afslutning
SOP for akut instrumentfejlfinding