Een instrument waarvan aanschaf, aanpassing, en invoering heel kostbaar kunnen zijn. Zonder nu meteen de analogie met de nieuwe kleren van de keizer naar voren te willen brengen, is het raadzaam te reflecteren op het verschil tussen gegevens en informatie.
Een zaaltje van de schaakclub. Ik speel met zwart. De partij is redelijk gevorderd. De club-kampioen komt langs, werpt een korte blik op de stelling, en zegt: “zwart gaat verliezen”. Een treffend voorbeeld van het verschil tussen gegevens en informatie.
De gegevens zijn de posities van de stukken. Met mijn beperkte kennis kijk ik naar de stelling om een volgende zet te bepalen, en hopelijk een goede zet. De kampioen beschikt over exact dezelfde gegevens, maar met zijn kennis overziet hij de stelling en genereert vervolgens wezenlijk andere informatie: zwart staat op verlies, er is geen slimme volgende zet. Als ik vraag om uitleg is de kans groot dat hij daarvoor een lange en voor mij zelfs onbegrijpelijke uiteenzetting nodig heeft.
Informatie vereist kennis
Hoe maken we van gegevens informatie? Door kennis los te laten op die gegevens. Wie beschikt over die kennis? Het is de gebruiker van de gegevens, of althans dat zou moeten. Met de informatie die de gebruiker genereert gaat hij aan het werk. Daarnaast zorgt informatie ervoor dat zijn “oude” kennis wordt vergroot, en leidt tot “nieuwe” kennis. Dat is een van de essenties van leren. Het plaatje toont het bedoelde mechanisme.
Een minder deskundige gebruiker haalt uit gegevens minder dan een terzake kundige gebruiker. Of trekt zelfs foute conclusies. Discussies tussen een boekhouder en een onderhoudsmanager over “de” onderhoudskosten zijn dan ook vaak vermakelijk om aan te horen: twee werelden die beschikken over dezelfde data, en er met hun eigen kennis hun eigen informatie van maken. En daardoor met verschillende beelden van de werkelijkheid komen. En daar een gesprek over aangaan.
Deskundigen wensen betrouwbare gegevens
In Onderhoud spreekt men graag over onjuiste of ontbrekende data. Denk aan de onderhoudsmanager, maar ook aan werkvoorbereiders, maintenance engineers, monteurs. Een klassieke valkuil bij de inrichting van onderhoudssoftware is dan ook de vraag aan gebruikers: “welke informatie heeft u nodig?” Impliciet wordt daarmee gevraagd hun hersen-activiteiten te expliciteren. Nog erger is de reactie van sommige IT-projectleiders: “waar heeft u in vredesnaam al die gegevens voor nodig?” Voor de gebruiker is een beter bewijs van onkunde niet denkbaar.
De kernvraag die gesteld moet worden is natuurlijk: “ Hoe komt het dat de gebruiker nu niet beschikt over de juiste data?” U zult concluderen dat het genereren van betrouwbare dynamische gegevens (bijvoorbeeld gegevens op een werkaanvraag) meer en andere dingen vraagt dan software. En dat het vullen van een systeem met betrouwbare statische gegevens (denk aan een equipment-gegevens, aan een Bill of Materials, en ook aan technische documentatie) veel tijd en geld kost.
Vaak is er wel geld voor een ERP-systeem, een maintenance dashboard en de bijbehorende consultants, maar geen geld voor het vullen van het systeem met de data die de gebruikers nodig hebben. Zij krijgen te horen dat zij het systeem zelf mogen vullen tijdens hun dagelijkse werk. Zo wordt de deskundige onthouden wat hij nu juist echt nodig heeft voor zijn functioneren: betrouwbare gegevens.
Een praktijkvoorbeeld
Enige jaren geleden adviseerde ik een onderhoudsdienst in Wallonië. Een van de doelstellingen: het door Productie gevraagde werk op tijd klaar hebben. De situatie: al het werk was urgent en moest meteen worden uitgevoerd, een grote backlog van opdrachten, en preventief onderhoud dat niet tijdig werd uitgevoerd.
We besloten o.a. Productie “op te voeden”. We maakten onderscheid tussen urgentie en prioriteit. Urgentie was de mate van spoed waarmee het werk gestart moest worden. Urgentie 0 en 1 waren bestemd voor calamiteiten en risico-situaties. Urgentie 2 kon gepland aangepakt worden. Voor urgentie 2 verplichtten we Productie na te denken over de gewenste leverdatum. Die moesten zij vermelden op de werkaanvraag.
We organiseerden een overleg waarin de definitieve leverdata werden afgesproken. Onderhoud gaf de garantie de afgesproken leverdata te respecteren. Prioriteit is iets anders dan urgentie. De prioriteit van een opdracht geeft de plaats in de wachtrij aan. Prioriteiten veranderen in de tijd. Een gepland werk waar nog niets aan is gedaan en waarvan de afgesproken leverdatum morgen is, heeft een hogere prioriteit dan een opdracht die pas over 6 weken klaar moet zijn. De prioriteiten van het uit te voeren werk werden door de planners bepaald bij het opstellen van de planning.
Productie was in het begin niet zo overtuigd van de voorgestelde aanpak. Het moeten nadenken over een gewenste leverdatum was moeilijk. En er was de neiging voor urgentie 0 en 1 te kiezen, want dan ging Onderhoud meteen aan de slag. Na enkele maanden, met forse controle op het naleven van de spelregels, bleek er veel resultaat te zijn. Het aantal urgente opdrachten was op een acceptabel niveau gekomen en Onderhoud hield zich aan de afgesproken leverdata. Iedereen tevreden. En een stap dichter bij beheersing van onderhoud.
Een informatieprobleem
Een van de indicatoren die we maandelijks bijhielden betrof het aantal aanvragen met urgentie 0 en 1, als percentage van het totaal aantal aanvragen. Een afbeelding van deze indicator ziet u hiernaast. We hebben het originele plaatje overgenomen, vandaar dat het franstalig is.
Wat opvalt: na november treedt een dramatische verhoging op van het percentage urgente aanvragen. Aan u de vraag om met uw kennis van zaken de gegevens te interpreteren en er uw eigen informatie van te maken.
U bent inmiddels uitgedacht, en heeft mogelijk redenen kunnen verzinnen voor dit verschijnsel. De directie in het hoofdkantoor keek ook naar dit plaatje (het maintenance dashboard!). In maart kregen we via de staf verontruste vragen: zijn de installaties aan het instorten?; zijn de projectresultaten minder duurzaam dan jullie ons steeds hebben verteld?, en:doen jullie nog wel aan preventief onderhoud?
De oorzaken
Het zal u wellicht verbazen, maar de echte reden was een go-live van het nieuwe ERP-systeem (in dit geval SAP PM) in december. Dat kon u niet weten, dus u hebt de gegevens waarschijnlijk anders geïnterpreteerd. De directie wist dit wel, maar had door gebrek aan kennis van onderhoud én van de inrichting van SAP de gegevens ook anders geïnterpreteerd (zie de vragen).
Om uw kennis te vergroten dient u nog een paar zaken te weten:
In SAP PM wordt urgentie prioriteit genoemd. Dit is een semantische kwestie, maar getuigt wel van een gebrek aan elementaire bedrijfskundige kennis.
In SAP PM wordt aan een prioriteit (bedoeld wordt: urgentie) op de werkaanvraag door het systeem automatisch een leverdatum toegekend, op basis van een voorgeprogrammeerde tabel.
Het bedrijf had gekozen voor een uniforme inrichting van SAP PM, dus voor alle fabrieken hetzelfde. Uiteraard hadden wij gewezen op onze ‘best practice’, die we inmiddels met succes toepasten. Maar we stonden alleen, althans volgens de projectleider, en er werd geen rekening gehouden met onze wensen.
Om uw kennis te verdiepen dient de onderstaande tabel, en let dan op het verschil tussen SAP en wat wij in het project hadden afgesproken.
Onze vrienden van Productie kwamen er snel achter dat Z3 in SAP een leverdatum genereerde van 1 maand later. Dat vonden zij in veel gevallen te laat. En in plaats van de datum te vervangen, kozen ze voor Z2, waarmee het werk in onze KPI werd opgenomen.
Vanuit het project lieten we de zaak bewust op zijn beloop, om met feiten aan te tonen dat onze eerdere flexibiliteit en discipline waren vervangen door een onjuist en rigide automatisme. Er is maanden geprobeerd de inrichting van SAP of de tabel op dit punt te wijzigen, maar dat is onder het mom van harmonisatie tussen fabrieken consequent geweigerd door de SAP-projectleiding.
Na een half jaar hebben we het probleem uiteraard procedureel opgelost: alle leverdata van aanvragen met Z3 moesten door Productie van een nieuwe, realistische leverdatum worden voorzien. Slechts twee muisklikken per aanvraag meer dan eigenlijk noodzakelijk, dus onbelangrijk. Maar een nog steeds voortdurende bron van ergernis bij Productie en Onderhoud, ook al omdat er heel wat meer van dit soort voorbeelden waren.
De nieuwe kleren van de keizer
Maintenance dashboards, en meer algemeen de interpretatie van benchmarks, prestatie-indicatoren en trends, vragen om diepgaande kennis en relevante deskundigheid. Hoger management heeft vaak de illusie dat ze met een dashboard eindelijk beschikken over informatie over dat weinig transparante onderhoud. Ze realiseren zich dan niet dat daarvoor kennis nodig is.
Kennis waarover zij meestal niet beschikken of zelfs niet willen beschikken. Ze neigen er daardoor ook toe de complexiteit van het dagelijks leven in een fabriek te ontkennen. Naast kennis zijn bovendien betrouwbare gegevens nodig, en daaraan ontbreekt het in de praktijk ook nogal eens. Met onjuiste gegevens is een dashboard al helemaal een farce.
Zonder betrouwbare gegevens en zonder relevante kennis is het kostbare dashboard een gadget voor goedgelovigen, waardoor een onjuist beeld van de werkelijkheid kan ontstaan. Het is jammer dat daardoor geld wordt verspild, en de mensen in het veld worden blootgesteld aan bestuurlijke drukte en aan interventies die getuigen van ondeskundigheid. Geen wonder dat de echte gebruikers, de kampioenen, dan mentaal afscheid nemen.
