In mijn studententijd zat ik een jaar in de commissie van een studentenvereniging. Dat was een uitermate leerzame tijd. Na dat jaar kwam er een nieuwe club jonge honden, die alles opnieuw moest uitvinden. Het leek me toen handig om met een aantal mensen op schrift te stellen wat we zoal geleerd hadden: hoe dingen werken, waar je op moet letten, bij wie je moet zijn, etcetera. Dat zou dan een handig klein schriftje worden met wat tips, zodat men wat sneller was ingewerkt.
Dat bleek nogal uit de hand te lopen.
Een eerste brainstorm resulteerde in ruim over de honderd onderwerpen. Over elk daarvan schreven we zo een paar bladzijden vol met losse ideeën. Daar dan weer een bruikbaar samenhangend verhaal van maken, kostte al snel een hele avond, per onderwerp.
Ik moet wel eens aan die ervaring terugdenken als ik zie hoe projecten in hun laatste fase merken dat ze ‘nog een paar dingen aan beheer moeten overdragen'. Ook dat loopt uit de hand, en meestal ook nog eens aan twee kanten. Het project schrikt van de rijstebrijberg aan technische en operationele details die nodig blijken te zijn voor fatsoenlijke en betrouwbare productie. Tegelijk lopen de beheerders binnen de kortste keren hopeloos achter met het verwerken van al die informatie. Vervolgens vinden de projectleden de beheerders lui, en vinden de beheerders de projectleden slordig.
Zo schiet het natuurlijk niet op met die kennisoverdracht.
Wat mij na de commissie opviel was hoeveel van die kennis eigenlijk al doende wordt opgedaan, en nooit ergens is vastgelegd. In veel gevallen zijn we ons zelfs niet eens bewust van die kennis. Zo zit het blijkbaar ook met de overdracht van ontwikkeling naar beheer.
Misschien is dit wel een van de redenen waarom outsourcing moeilijk verloopt. Vaker dan niet blijken we de processen onvoldoende te begrijpen om ze goed te kunnen documenteren, als we al de tijd krijgen om die documentatie te maken.
Ons schriftje? Dat is dus nooit afgekomen. Hopelijk gaat het met de beheerhandleiding van uw systeem beter.
Dag Peter,
Ik denk dat zeer veel mensen dit zullen herkennen. De echte wereld en dus de echte processen zoals ze in de praktijk verlopen zijn veel uitgebreider en minder gestructureerd dan software over het algemeen faciliteert. Net als kennismanagement (in feite je schriftje) ziet iedereen het belang wel, maar is er weinig draagvlak om het serieus op te pakken omdat het niet direct bijdraagt aan het primaire productieproces. En als je van te voren alle details bekijkt wordt het al snel te complex en duur en begint niemand eraan.
Er zijn overigens twee strategieen voor het overdragen van kennis. Het vastleggen en kunnen ontsluiten en het persoonlijk overdragen middels seminars, workshops en pairing. In jouw voorbeeld is dat laatste lastig omdat het overdragen in “batches” gaat, er komt een nieuwe lichting. Toch denk ik dat met name het “samen doen” beter werkt dan het schriftje, omdat het schriftje meestal toch niet gelezen wordt (not invented here syndrome). Gecodificeerd kennis management werkt pas als het geintregeerd wordt in de bedrijfprocessen (ontwikkelen en in beheernemen is overigens ook een proces) en met een soort van stimulering of beloning. Omdat te bereiken moet het al in het DNA zitten en draagvlak hebben op het hoogste niveau (niet bij de IT of HRM manager, maar bij de CEO).
Maar goed, ik ga te lang door. Herkenbaar artikel en hier kun je net zoveel over schrijven als over cloud computing, meer dan over IPv6. Dat gezegd hebbende denk ik dat de business case voor Ipv6 een stuk kansrijker is… (er veel over schrijven doet het besef groeien)