ZBC Kennisbank

Dit is typisch een antwoord dat alleen een ICT-er kan geven

 

‘Van je fouten leer je’. Het is een bekend gezegde en de reden waarom in de ICT incidenten worden geregistreerd. Een incident wordt geregistreerd samen met de oplossing als een bekende fout (FAQ). Iedereen die later met zo’n zelfde incident wordt geconfronteerd kan daardoor de oplossing simpel toepassen. Voor de registratie wordt beoordeeld of de fout niet voorkomen kan worden en zo nee of de oplossing adequaat is. Dit is de basis voor de processen incidentbeheer en probleembeheer binnen ITIL.

In een project gericht op het implementeren van een robotstraat bij een papierfabriek, was natuurlijk ook een procedure nodig voor incidentafhandeling. Ik gaf de ontwikkelaar opdracht hiervoor een workflow op te zetten en gaf aan bij welke materiedeskundige aanvullende specs gehaald konden worden voor het proces in de robotstraat.

De schommel

Dertig jaar geleden is mij, net als vele anderen, tot vervelens toe het plaatje van de schommel voorgehouden.

Eigenlijk dacht ik dat dit plaatje wel niet meer actueel zou zijn, nu programmeren relatief eenvoudig is geworden. De werkelijkheid blijkt echter nog steeds weerbarstig te zijn.

Hoe het proces verliep

De eerste fout bij het opzetten van de workflow voor incidentafhandeling lag natuurlijk bij mij. Ik ging ervan uit dat de ontwikkelaar zou begrijpen waarom je incidenten registreert. Dat heb ik hem dus niet uitgelegd. Het enige wat ik wel heb verteld, is dat de robotstraat grotendeels afgeschermd zou worden met hekken, om te voorkomen dat operators tijdens het proces aan het papier zouden komen. Bij een incident zou een hek geopend moeten worden en dat event zou via twee andere systemen gebruikt kunnen worden om de workflow te starten. De gebruiker naar wie ik de ontwikkelaar had verwezen, had dit nog niet scherp op het netvlies staan, want in de productie bestond binnen het bedrijf een gestructureerde incidentafhandeling tot dan toe niet.
De ontwikkelaar en de gebruiker gingen aan de slag. Dat resulteerde in een prachtig functioneel ontwerp van bijna twintig kantjes. Zo’n uitgebreide beschrijving van zo’n simpel proces lees ik natuurlijk niet door. Want wat kan er nu fout gaan?
Vervolgens werd de workflow gemaakt, getest en zoals zo vaak niet overgedragen aan de productiemedewerkers. Het wachten was vervolgens  alleen nog op de oplevering van één van de systemen die het signaal moesten doorgeven.
Tot zover leek er weinig meer aan de hand dan de bijna gebruikelijke ongemakken bij de implementatie van een nieuw ICT-onderdeel. Zie ook ‘Het nieuwe gebruik van de ICT’.)

De schommel werd een gedrocht

Kort voor de oplevering van het systeem kreeg ik een mailtje van een programmeur van de partij die ervoor moest zorgen dat het signaal ‘hek open’ werd doorgegeven, met de vraag of er ook andere incidenten afgehandeld zouden moeten worden dan alleen ‘hek open’. Ik reageerde met de melding “Natuurlijk moet de workflow voor ieder incident binnen de productie, ICT en TD gebruikt kunnen worden”. Ik was me op dat moment nog niet bewust van de impact van die vraag. De ontwikkelaar van de workflow werd ook niet gealarmeerd door mijn antwoord, dat ik hem netjes had ge-cc’t en de betrokken projectleiders roken eveneens geen onraad.
Pas twee dagen later werd ik wakker. Ik realiseerde dat mijn specificatie tekort was geschoten. Want:

  • waarom moest die programmeur van het doorgeefluik van slechts een signaal weten welke incidenten er kunnen voorvallen; het doorgeven van een timestamp en van de herkomst van het signaal is voldoende;
  • ‘hek open’ is niet het incident; het incident vindt plaats in de robotstraat achter het hek en om het op te lossen moet de operator vaak als onderdeel van de oplossing het hek openen om het probleem te verhelpen;
  • als de operator van elk incident van tevoren zelf moet ingeven wat de titel is van het incident voordat de workflow start, kan een incident onder verschillende titels in de database terechtkomen en kan er nooit een database met bekende fouten worden opgebouwd;
  • het van te voren ingeven van de titel van een incident heeft geen nut, is dus bureaucratisch en daarbij dubbel werk voor de operator; het zal maken dat hij de incidentregistratie in de praktijk negeert.

Ik liet daarop de ontwikkelaar van de workflow weten dat het basisschema voor de workflow (zonder escalaties) er als volgt zou moeten uitzien:

Dit is typisch zo’n antwoord, dat alleen een ICT’er kan geven

Ik loop lang genoeg mee in de automatisering om te weten dat dit soort dingen gebeurt. Zo frequent zelfs, dat het eigenlijk een wonder is dat er nog ICT-projecten slagen. Maar daar ben ik aan gewend. Aan één ding zal ik echter nooit wennen. Wat dat is wordt geïllustreerd door het antwoord van de ontwikkelaar van de workflow op mijn vraag naar de status.

“Zoals destijds gespecificeerd is de workflow inmiddels gerealiseerd. De technische uitwisseling tussen de procesautomatisering en de workflow is afgestemd en getest:

  • Een apparaat meldt een storing.
  • De procesautomatisering registreert de storing en start de workflow op en voorziet deze van de volgende informatie: het type incident, tijdstip en de locatie waar het incident heeft plaats gevonden.
  • De operator krijgt een taak uit gedeeld, waarbij hij de mogelijkheid heeft om een beschrijving op te geven van het betreffende incident.

Op dit moment is deze functionaliteit gerealiseerd. Echter de volgende zaken zijn ons inziens nog niet afgerond:

  1. Nog niet alle apparaten worden meegenomen in de incidentenregistratie.
  2. Het classificeren van de incidenttypes. In principe wordt er alleen aangegeven dat er een incident is.

Het classificeren van incident types is veel meer een optimalisatiefase. Wanneer de procesautomatisering het type incident (bij ‘hek open’) kan doorsturen, is dit aanvullende informatie die erg bruikbaar kan zijn voor de operator en eventuele procesoptimalisatie. Wanneer deze informatie echter niet meegestuurd kan worden, kan ze gewoon weg gelaten worden. De operator is dan zelf instaat om een type aan het incident te koppelen. Dit gebeurt gewoon in de workflow.”

Hierop heb ik dus geantwoord met: ‘Dit is typisch zo’n antwoord, dat alleen een ICT-er kan geven’.’
Dat dit nog steeds voorkomt! De herleving van de schommel. Leren ICT’ers het dan nooit? Moet ik misschien mijn verwachtingen bijstellen? Is er nog toekomst voor alignment? (Zie ook ‘Communicatie struikelblok voor alignment’.

DownloadDownload artikel als MS Word document Download artikel als PDF document Print deze pagina Verstuur deze pagina naar een vriend (email)
Auteur(s): Wiebe Zijlstra | 23 maart 2016 | Copyright: ZBC


2 Responses to “Dit is typisch een antwoord dat alleen een ICT-er kan geven”

  1. Norman van Es schreef:

    Alignment slaagt alleen als er en basis (baseline, context, referentie, uitgangspunten, ontwerp, reuqirements, enz.) daarvoor is.

  2. Matthieu schreef:

    Dit is nou typisch het niet nemen van je verantwoordelijkheden als opdrachtgever en afschuiven op een ICT-er.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *