De kunst van het neerzetten

Koud kunstje
Een nieuwe applicatie “neerzetten” is een vertrouwd kunstje. Iedereen schijnt het te kunnen, dus kun je het makkelijk uitbesteden (software developers kun je met containers tegelijk bestellen). Neerzetten is dan het proces dat begint vanaf het moment dat het project accoord krijgt om te starten tot en met de oplevering. Het omvat ruwweg het ontwerp (O), de bouw (B), het testen (T) en het opleveren van de applicatie. Zo gepiept.

Pilots
Voor de zekerheid kan je eerst even in een kleine context kan experimenteren met een pilot project, waaruit dan zo’n geweldig goed resultaat komt dat je er meteen mee live kunt gaan in de hele organisatie. Scheelt vaak ook een hele hoop bureaucratisch gedoe.

Agile
Vaak wordt het neerzetproces ook opgeknipt in meerdere kleine nederzettinkjes. Agile, noemen ze dat dan in mooi Nederlands. De agile variant “Scrum” is heel populair de laatste tijd. Ik zie dan altijd een karate-dojo voor me waarin de scrum master met oosterse bewegingen zijn kunsten vertoont, maar dat terzijde. In een agile aanpak wordt er met regelmatige tussenpozen, steeds een deel van de beoogde applicatie bij aangezet. Iedere aanzetting doorloopt de stapjes O, B en T. Zo krijgt de opdrachtgever regelmatig de gelegenheid om nieuwe requirements toe te voegen (of juistom requirements af te zwakken of in zijn geheel te laten vallen als hij doorkrijgt dat het kunstje toch wat ingewikkelder blijkt als eerst ingeschat). Het mooie is in ieder geval dat de opdrachtgever veel momenten krijgt om invloed uit te oefenen.

Iemand ander’s probleem
Nu wil het geval dat ik nét even iets te vaak heb gezien dat er bij het neerzetten van een applicatie iets heel belangrijks wordt vergeten, of gemakshalve beschouwd als iemand ander’s probleem, namelijk: het in beheer nemen. Zou dat dan soms heel erg lastig en ingewikkeld zijn? Lastig? Nee, wel anders. Het in beheer nemen van iets houdt in dat je de verantwoordelijkheid op je neemt om erop toe te zien dat de conditie van het in beheer genomene op peil blijft. Zo zorgt een museum ervoor dat de conditie van door anderen gemaakte kunstwerken op een dusdanig niveau blijven dat de de mensheid nog lang van de kunstwerken mag blijven genieten.

Applicatiebeheer
Om een applicatie met een kunstwerk te vergelijken gaat misschien wat ver. Applicaties zijn vaak veel kortere levensduren toegedacht. Dat ze het vervolgens veel langer uithouden dan ooit werd bedacht mag dan wellicht worden toegeschreven aan de bovenmenselijke inspanningen van het applicatiebeheer dat tot uiterste ROI werd gerekt. In het geval van applicaties houdt beheer ten minste in dat deze functioneel bruikbaar blijven en waarde blijven houden.

Instortgevaar
In de praktijk (vooral bij de wat bejaardere applicaties) lijkt applicatiebeheer vooral op het voorkomen van instorten. Gek genoeg zijn we altijd weer heel verbaasd als een applicatie plotseling bijna “over datum is”. De oorspronkelijke leverancier heeft de stekker eruit getrokken en had daar al jaren van te voren voor gewaarschuwd. Er komen echt geen patches meer. Vanaf Windows 7 wordt de werking niet meer gegarandeerd. Gelukkig kon de levensduur van XP dan weer collectief met ruim 10 jaar worden gerekt.

Paniek! Gauw een pilot!
En als het boeltje dan echt bijna op instorten staat, dan moet in allerijl een vervangende applicatie worden neergezet, en vlug een beetje, want tijd is geld. En om zowel budgettaire als bureaucratische motieven beginnen we dan met een experimentje met een nieuwe veelbelovende technologietrend. Voila, een nieuw pilot project is geboren. En wonder boven wonder, die nieuwe technologie werkt fantastisch! En het kost niks, want het is nog open source ook! Eh, beheer, zouden jullie zo vriendelijk willen zijn om de verantwoordelijkheid op je te nemen om deze nieuwe applicatie met die bovenmenselijke zorg die we van jullie gewend zijn voor ons te onderhouden? Fijn! Het kringetje is weer rond.

Beheerbelang
Beheer is meestal de onuitgenodigde gast bij het neerzetten. Op zijn best wordt deze gast vlak voor oplevering uitgenodigd om te beoordelen of het opgeleverde in beheer genomen kan worden. Dan valt er niks meer bij te sturen voor beheer. Beheer is een belangrijke stakeholder in de organisatie, met eigen belangen die indirect altijd die van de organisatie behartigen. Laat ze van begin af aan meestrijden in de scrum-dojo en je zult zien dat dat in beheer nemen ook een koud kunstje kan zijn. 

Stof tot nadenken

Bij ons in de keuken staat een kast. Het is zo’n handig Zweeds meubel dat we ooit als bouwpakket kochten. Het is met het ons gezin meegegroeid door er steeds uitbreidingen bij te kopen. Het begon met 3 staanders en wat planken. Met de functie van stereo-en-TV-meubel. Heel overzichtelijk en het wekelijkse afstoffen (onderhoud) kostte nauwelijks moeite.

Nu is het een uitgebreid wandmeubel met vele functies. Hieronder volgt een kleine selectie van de huidige manieren van gebruik:

  • Entertainment (stereo, spellen, legpuzzels, knutselmaterialen)
  • Financiën (archief voor betaalde facturen, spaarvarkens, beker met kleingeld voor de wekelijkse uitbetaling van zakgelden en voor giften aan collectanten)
  • Bar (buiten bereik van kinderen houden van sterke dranken en stoffige wijn-, bier- en borrelglazen)
  • Kantoor (uitpuilend postvakje, printer, oplaad-station voor gadgets)
  • Bibliotheek (kookboeken, tijdschriften)
  • Expositie (fotolijsten, kinderkunstwerken)

Je begrijpt dat dat afstoffen nu veel meer moeite kost. Sterker nog, zelfs de externe partij waaraan wij de schoonmaak van ons huishouden hebben geoutsourced waagt zich hier niet aan. Veel te veel werk. Bovendien is er een veel te groot risico dat de processen die zich in en rond de kast afspelen, door het afstoffen in de problemen komen. Kortom: dat afstoffen gebeurt niet. Het is veel te specifiek en dus te lastig. Daarentegen weet onze ZPZP-er (zelfstandige poetser zonder personeel) wel raad met de vloeren, de badkamer en de toiletten, want dat is gewoon standaard-poetswerk.

Moeten we op basis daarvan dan concluderen dat outsourcing alleen goed werkt voor gestandaardiseerde processen? Het is in ieder geval wel veel eenvoudiger en minder risicovol. En je kunt altijd heel gemakkelijk van je outsourcingspartner af, want er zijn genoeg anderen die het hetzelfde kunstje kennen. Toch?

Moeten we wellicht ook concluderen dat een uitbreidbaar, multifunctioneel systeem uiteindelijk slecht onderhoudbaar wordt? Volgens mij hangt dat heel sterk af van de mate van regie. Mijn gezin bestaat nu uit 6 personen. Ieder gezinslid geeft zijn eigen invulling aan het gebruik van onze keukenkast. Er is feitelijk onvoldoende regie over het gewenste gebruik ervan. We laten de boel een beetje de boel omdat we onze energie al opmaken aan de primaire gezinsprocessen. Daardoor waagt niemand zich aan het wegwerken van de stoflagen in onze keukenkast.

Gebrek aan standaardisatie en regie kan dus leiden tot een stoffige bedoening, vooral in de hoekjes waar de dynamiek laag is, zoals bij mijn verzameling borrelglaasjes, want ik drink maar heel af en toe (geen primair proces…). En omdat er zoveel stof op ligt, laat ik die mooie borrelglazen maar gewoon stoffig en drink mijn slaapmuts uit een espressokopje (koffie drinken is voor mij wél een primair proces). En zo zie je dat er door achterstallig onderhoud ook nog eens oneigenlijk gebruik van middelen ontstaat. Wat een zooitje. Ach, het geeft in ieder geval stof tot nadenken.