Ik werk nu al wat jaren in de ICT maar merk dat er overal een probleem is met betrekking tot het documenteren van de omgeving. Beheerders hebben altijd een hekel aan het beschrijven van hun werkzaamheden. Overal hoor ik hetzelfde verhaaltje, “Ik krijg geen tijd om te documenteren” of “ik heb geen zin in documenteren”. Krijgen ze tijd om standaard handelingen te beschrijven voor een overdracht naar de eerste of tweede lijns beheerders, dan krabben ze zich eerst op hun hoofd.
Er is bijna nergens een standaard sjabloon te vinden voor het overdragen of beschrijven van taken. De eerste vraag die ik meestal krijg is: wat moet ik beschrijven en hoe moet ik het beschrijven. Mijn methode is begin gewoon met het uitvoeren van de handeling die je wilt beschrijven en maak tijdens het uitvoeren screenshots. Plak al deze screenshots in een document en je hebt een begin van je werkinstructie. Als je dit hebt gedaan kun je het verhaal bij de plaatjes gaan zetten. Of je de screenshots laat staan is geheel aan de persoon/organisatie. Zelf heb ik de insteek dat één plaatje vaak meer zegt dan een hele lap tekst. Alleen screenshots zeggen daar en tegen ook helemaal niets. Dus er zal wel iets van begeleidende tekst bij moeten.
Standaard hoofdstukken
Daarnaast heb je nog de standaard hoofdstukken waar dit document/werkinstructie over gaat. Of voor wie het is geschreven, versiebeheer van het document, verklarende woordenlijst en ga zo maar door. Versiebeheer is bijvoorbeeld een goed onderdeel om te beschrijven. Hierdoor weet je wie wat in het document heeft aangepast en wat de reden hiervan is geweest.
Tijd
'Ik krijg geen tijd binnen het project of tijdens het beheer om een goede documentatie op te zetten.' Dit is iets wat je bij veel beheerders hoort. Persoonlijk vind ik dit onder de categorie 'zelf medelijden' vallen. Als je ingeroosterd bent om beheertaken uit te voeren, dan heb je ook tijd om documentatie op te stellen. Echter iedere beheerder hoor je dan zeggen dat dit niet kan/mag van de baas. Waarom niet??? Daaronder hoort ook het opstellen en bijhouden van documentatie. Zonder deze documentatie kun je nooit een goede overdracht doen naar nieuwe collega’s of je eigen afdeling als ze iets moeten doen als jij er niet bent.
Bijhouden
Als je de documentatie eenmaal hebt opgezet is het zeker zo belangrijk om dit ook bij te houden. Upgrades, Service Packs, nieuwe installaties. Dit zijn allemaal redenen om de bestaande documentatie eens onder de loep te nemen en eventueel waar nodig bij te werken. Als dit structureel gebeurd dan is het bijhouden van documentatie een kwestie van een uurtje.
Beschikbaarheid
Een ander punt is, niet alleen bij documentatie van systemen en software, waar je de documenten neerzet. Je kunt het in een gedeelde map op het netwerk neerzetten of op een SharePoint achtige omgeving plaatsen. Waar precies vind ik minder belangrijk. Wat ik wel belangrijk vind, is dat het altijd te benaderen is. Dus als een server of applicatie crasht, moet het niet zo zijn dat de documentatie ook weg is. Een goede bereikbaarheid is een must. Hoe doe je dat? Voorbeeld kan zijn een cluster van SharePoint servers, een DFS systeem of via een backup/restore methode. Welke methode gebruikt wordt is minder belangrijk. Zolang er maar over wordt nagedacht.
KISS
KISS hoor ik je denken? Nou Keep It Simple and Stupid, dat is mijn insteek bij documenteren. Zorg ervoor dat iedereen met een mavo-diploma de zaken kan uitvoeren. Niets is zo frustrerend als er een systeem of applicatie onderuit gaat en de primaire guru’s zijn niet bereikbaar. Zonder goede documentatie wordt het een uitdaging om alles weer goed in de lucht te krijgen. Laat daarom je collega’s je documentatie doorlezen en eventueel uitvoeren. Snappen zij wat de bedoeling is, dan is het document helder genoeg om in tijd van crisis en stress te gebruiken. Snappen ze het niet, vraag dan wat er onduidelijk is en probeer het op een andere manier te beschrijven. Alleen op deze manier weet je dat het door iedereen te beheren valt.
Borgen
Een van de weinige manieren die mogelijk werkt om de beheerders hun eigen documentatie bij te laten houden is het verantwoordelijk maken voor deze documenten. Zorg dat er vanuit nieuwe projecten goede documentatie wordt opgeleverd en neem geen projecten in beheer zonder duidelijke en heldere documentatie.
Conclusie
Beheerders zullen altijd een hekel blijven houden aan het documenteren van hun bekende omgeving. Echter is het van belang dat er vanuit de organisatie ook tijd en druk wordt uitgeoefend om deze documentatie te eisen van hun beheerders. Een van de opmerkingen die ik zelf vaker maak is 'je hoeft maar naar buiten te lopen en door een bus overreden te worden'. Met deze opmerking probeer ik de mensen dan bewust te maken van het feit dat je het niet altijd zelf in de hand hebt dat je geen overdracht kan doen naar een andere collega. Door het hebben van documentatie kunnen de werkzaamheden altijd doorgaan.
Een echte beheerder houdt van documenteren.
Na de backups regelen en de infrastructuur draaiende houden is het een van haar/zijn topprioriteiten.
Worst case scenario plan is ook uiterst belangrijk, maar hier gaat meer tijd in zitten en dit is het beste te doen tijdens een ‘komkommertijd’.
Het Screenshot vs Tekst verhaal is wel erg grappig omdat ik het zo herken! Ik hou van tekst, maar veel mensen die ik tegenkom houden ook vaak veel van plaatjes.
Ik ben geen echte beheerder, en zeer zeker geen goede (systeembeheer is gewoon niet mijn ding, ik bouw het liever), maar documenteren doe ik graag… ik zie er te veel voordelen aan. Wellicht als duidelijk gemaakt wordt dat documenteren niet bedoeld is als bezigheidstherapie maar dat je er echt iets aan hebt, dat er dan welicht iets meer aandacht aan wordt besteed.
Plaatjes doe ik niet aan, ik schrijf immers geen documentatie voor de leek, maar voor vakgenoten waarvan ik mag verwachten dat die voldoende gekwalificeerd zijn. Bovendien screenshots…. ik doe geen MicroSoft dus bij mij valt er weinig te zien.
“Echter is het van belang dat er vanuit de organisatie ook tijd en druk wordt uitgeoefend om deze documentatie te eisen van hun beheerders….”
Precies, en daar is waar het vaak mis gaat. Tijd is geld, investeren kost geld, dingen die geld kosten en niet direct iets opleveren wil de baas niet. Dat heet “kort termijn denken”. Dit is meer en meer een trend aan het worden, als het maar werkt en HOE het werkt maakt dan niet uit. Dus even een oplossing ertussen ‘persen’, dit zie je voornamelijk bij de programmeurs afdeling. ‘even er iets tussen hacken’, met het gevolg dat na een langere periode er een ontzettende puinhoop ontstaat. Ik begrijp bazen en sommig projectleiders niet, het moet allemaal snel en hoe het werkt maakt ze niet uit. Duurzaamheid is niet meer van deze tijd, wat ontzettend ‘dom’ is. Misschien is deze werkwijze, kortzichtigheid wel te gerelateerd aan alle technieken om ons heen, wanneer iets net onder de knie hebt is er alweer een nieuwe techniek die zich aandient.
Op de werkvloer is al jaren duidelijk dat door de toenemende complexiteit van ICT-infrastructuren een goede en gecontroleerde kennisborging cruciaal is voor efficiënt beheer.
Essentie is hierbij niet alleen een goede methodiek, maar vooral ook de controle. Het kennisvoorraadbeheer moet daarbij losgekoppeld moeten worden van de technische content, zodat gericht informatie kan worden aangevuld, en er geen ‘eilanden’ ontstaan. Groot voordeel voor de technici is ook dat er dan bewust informatie wordt gevraagd in plaats van ‘even documentatie maken’.
Met een goede KO (Knowledge Officer) en een goed gedefinieerde methode van kennisborging kunnen zo heel wat frustraties worden voorkomen.
Naast documentatie is het belangrijk om als beheerders een gezamenlijke ingang te hebben zodat informatie niet redundant en/of inconsistent wordt of op verschillende plaatsen opgeslagen. Dit kan d.m.v. een CMDB (configuratie management database).
Je kunt dan voor alle machines of softwareproducten een object maken.
Per object kan dan informatie toegevoegd worden, zoals links naar documentatie en relaties met andere objecten zoals leveranciers, contracten licenties et cetera.
Met de complexiteit van de huidige systemen en de continue veranderingen waaraan deze onderhevig zijn is het maken en bijhouden van veranderingen gewoonweg een onhaalbare zaak. Een document is alweer bijna verouderd als je het hebt gemaakt en je hebt nooit een garantie dat het document de werkelijkheid weerspiegeld.
Het is veel interessanter als beheerder om software te schrijven die in staat is om leesbare (bijv. HTML) documentatie periodiek of op verzoek kan genereren en die vervolgens te publiceren op een website.
Met een beetje scripting kom je al een heel eind.