Chef Kok versus Enterprise Architect

Een jaar of wat geleden was er een TV-programma “Master Chef”. Een soort Idols voor kooktalenten. In dit programma moesten kandidaten (amateurkoks eigenlijk) meedraaien in een keuken van een echte master chef. In zo’n keuken gaat het er dynamisch aan toe.

Ik ben zelf overigens bepaald geen kooktalent en heb op dat gebied ook geen ambities. Eten bereiden kan ik wel, want dat zie ik als een belangrijke basisvaardigheid voor de ondersteuning van mijn gezin. Eten bereiden is een kwestie van het volgen van een in zekere mate vast proces met vaste ingrediënten. Daar komt weinig creativiteit bij kijken en het vereist nauwelijks improvisatievermogen. Maar koken kan ik dus nadrukkelijk niet. Koken is een creatief proces waarbij de kwaliteit van het resultaat in grote mate af hangt van de kennis, improvisatievermogen, finesse en oog voor detail van de kok. Een kok past wel bepaalde vaste bereidingspatronen toe, maar doet dit zoals een muzikant dit doet met akkoorden en ritmische basispatronen. Koken is een kunstvorm en een ambacht tegelijk.

Een chef kok is de baas in de keuken van een restaurant in de zin dat hij bepaalt welke gerechten zijn keuken op welke wijze voort brengt, en in de zin dat hij toeziet op de kwaliteit. Van de keuken van een restaurant wordt een vaste en voorspelbare kwaliteit verwacht. De gerechten die de keuken voort brengt moeten passen bij het (gewenste) imago en kernwaarden van het restaurant, en de beleving van de doelgroep van het restaurant (klanten).

foodarchitect

Een master chef is een erkende meester in zijn vak en heeft een bepalende en richtinggevende functie. Je zou de master chef ook kunnen beschouwen als een Food Architect. Hij is in belangrijke mate verantwoordelijk voor het ontwerpen van de samenstelling en wijze van voortbrenging van nieuwe gerechten. Nieuwe gerechten of verbeteringen van gerechten of de bereidingswijze daarvan worden door de master chef ontworpen op basis van food trends, ontwikkelingen in kooktechniek, seizoenspatronen, et cetera.

Naast het creëren van een nieuw gerecht (vernieuwing) moet een master chef in staat zijn dit gerecht reproduceerbaar te maken voor de keuken van zijn restaurant, met behoud van de verwachte kwaliteit (beheersing). De onvoorspelbare dynamiek rond de  beschikbaarheid en kwaliteit van benodigde ingrediënten, maar ook de trends en ontwikkelingen op het gebied van voedsel en bereidingstechnieken en de verwachtingen van klanten vereist het vermogen om te kunnen anticiperen op veranderingen (toekomstvastheid).

Je ziet het, ik bezie dit allemaal door de bril van een Enterprise Architect. In de ICT wordt de keuken-analogie dikwijls toegepast. Van een ICT-afdeling wordt verwacht dat zij in staat is om binnen voorspelbare tijd, binnen voorspelbare kosten en met voorspelbare kwaliteit informatievoorzieningen voort te brengen. De ingrediënten bestaan uit basisvoorzieningen zoals portal, data warehouse en IAM, maar ook uit nieuw ingekochte technologieën. Van de gemiddelde ICT-afdeling wordt eigenlijk geen kookkunst verwacht maar vooral de bereiding volgens bewezen recepten.

Nu wil ik trouwens niet zo ver gaan dat een Enterprise Architect de baas is van de keuken en altijd een erkende meester is in zijn vakgebied, hoewel dat laatste op zich niet slecht zou zijn. Wel zie ik interessante parallellen tussen een Master Chef en een Enterprise Architect:

Master Chef Enterprise Architect
verantwoordelijk voor het ontwerpen van de samenstelling en wijze van voortbrenging van nieuwe gerechten verantwoordelijk voor het ontwerpen van de samenstelling en wijze van voortbrenging van nieuwe systemen
Nieuwe gerechten of verbeteringen van gerechten of de bereidingswijze daarvan worden door de master chef ontworpen op basis van food trends, ontwikkelingen in kooktechniek, seizoenspatronen, et cetera. Nieuwe of verbeteringen/uitbreidingen aan informatievoorzieningen of de voortbrengingswijze daarvan worden door de informatie architect ontworpen op basis van technology trends, ontwikkelingen in methodieken en architecture patterns, et cetera.
De onvoorspelbare dynamiek rond de  beschikbaarheid en kwaliteit van benodigde ingrediënten, maar ook de trends en ontwikkelingen op het gebied van bereidingstechnieken en de verwachtingen van klanten vereist het vermogen om te kunnen anticiperen op veranderingen De onvoorspelbare dynamiek rond de  beschikbaarheid van gebruikte technologie en de kennis daarvan, maar ook de trends en ontwikkelingen in de markt op het gebied van technologie  en ontwikkelmethoden en de verwachtingen die de klant ten aanzien daarvan heeft, vereist het vermogen om te kunnen anticiperen op veranderingen.

AGNES

Als Geo-Informatiearchitect in de Netbeheersector kom ik graag bij de business thuis. Mijn business (Enexis) vraagt niet direct om Geo-Informatiearchitectuur, maar gewoon om bruikbare en betrouwbare Geo-informatievoorzieningen die snel gerealiseerd kunnen worden. Het Geo Competence Center (Geo-CC) moet maar gewoon zorgen dat die Geo-informatievoorzieningen bruikbaar en robuust zijn.

Bij de buren (andere netbeheerders) gaat het net zo. Los van elkaar realiseren we systemen die veel functionele overlap hebben. De Geo-ICT-leveranciers en -dienstverleners actief in de Netbeheersector zijn hier de lachende derden. We zouden die Geo-ICT-markt en de ontwikkelingen daarin vanuit een gezamenlijke behoefte en referentiearchitectuur  moeten aansturen. En dat is precies waarin AGNES moet gaan voorzien.

AGNES is het “Architectuurmodel voor de Geo-informatievoorziening in de NEtbeheer-Sector”.  Een meisjesnaam in de traditie van referentie-architecturen in de publieke sector (NORA, GEMMA, …).

Onderstaande figuur toont een raamwerk voor een referentiearchitectuur. Vertrekpunt is het beleidskader, het waarom. Voor AGNES bestaat deze uit de wettelijke kaders, maatschappelijke taken en sector-afspraken. Zo zijn netbeheerders WION-plichtig, en daardoor gehouden aan INSPIRE. We moeten in staat zijn om actuele en juiste Geo-informatie te leveren waar dat nodig is.

Raamwerk voor een referentiearchitectuur

Raamwerk voor een referentiearchitectuur

Hierop volgen de principes: het wat. Deze geven houvast bij het maken van keuzes in de ontwikkeling van Geo-informatievoorzieningen. Een belangrijk AGNES-basisprincipe is: “Altijd ter plaatse met een schat aan informatie”. Toegepaste principes die daaruit volgen zijn “eenduidige vastlegging van data” en “toegankelijke data”.

De standaarden en bouwstenen beschrijven de standaard ingrediënten waarmee een Geo-informatievoorziening kan worden gerealiseerd. Registers voorzien bijvoorbeeld in de eenduidige vastlegging en toegankelijkheid van data.

Dit is nog maar een raamwerk dat we samen verder moeten gaan invullen. AGNES voorziet in een gemeenschappelijke, zuivere taal – Agnes betekent trouwens ook “zuiver” – onder de betrokken. Dan zijn “halve woorden” voldoende en wordt samenwerking eenvoudiger.

Raamwerk voor AGNES

Raamwerk voor AGNES

Registers, en snel een beetje!

In mijn professionele context wordt de laatste tijd veel gesproken over “registers”. De business komt er voor bij de ICT-afdeling: zeg, doe mij eens even een register, graag volgende week klaar. Het lijkt een soort nieuwe silver bullit te zijn (“nieuw” is betrekkelijk hoor, dit speelt al enkele jaren).

De te doden weerwolf is dan de combinatie van slechte kwaliteit (volledigheid, juistheid, actualiteit) en slechte integrale beschikbaarheid van alle data over zaken die centraal staan voor de organisatie, zoals klanten en bedrijfsmiddelen.  Met dat laatste bedoel ik dat data in de diverse systemen “weg gestopt”  zitten, en erg moeilijk met elkaar in verband kunnen worden gebracht. Er is geen integraal informatiebeeld over bijvoorbeeld klanten en bedrijfsmiddelen, waardoor bepaalde analyses onbetrouwbare resultaten opleveren of zelfs onmogelijk zijn.

Het voordeel van een echte weerwolf is trouwens dat je daar alleen bij volle maan last van hebt. Dat is dus hooguit 12 keer per jaar. Het is de vraag of je op zo’n incidenteel “probleempje” een business case voor een zilveren kogel en de hele jacht op de weerwolf rond krijgt. Maar van een gefragmenteerd informatiebeeld heb je elke dag last.  De business case voor een register en de jacht op de data is wel te maken lijkt me.

Maar wat is nou eigenlijk een register? De gewenste eigenschappen (zoals ik dat om me heen hoor) zijn:

  1. Het maakt data over één belangrijk type bedrijfsobject (zoals aansluiting, of  bedrijfsmiddel) integraal toegankelijk;
  2. deze data zijn altijd consistent, volledig, actueel en betrouwbaar (authentiek);
  3. Een register is veilig (goed beveiligd tegen ongeoorloofde toegang);
  4. alle gebeurtenissen op de geregistreerde zaken worden bijgehouden (bij aansluitingen bijvoorbeeld: aanleg, inhuizing, uithuizing, leverancierswissel, …);
  5. Een register kan worden gelinkt aan andere (externe) registers zodat data in verband kunnen worden gebracht met andere, gerelateerde data.

Basisregistraties

De overheid heeft het belang van een voorziening met de bovenstaande eigenschappen al langer ingezien, en noemt zoiets een basisregistratie. Het kabinet heeft een heel stelsel van nationale registraties aangewezen (citaat uit Wikipedia-artikel:) waarvan de Nederlandse overheid meent dat daarin met een gerust hart alle vitale gegevens over burgers, bedrijven en instellingen gecentraliseerd kunnen worden opgeslagen. De verantwoordelijken voor het stelsel gaan ervan uit dat deze zogeheten “authentieke gegevens” een dermate hoge kwaliteit zullen hebben, dat de overheid deze gegevens zonder enig verder onderzoek in haar werk zal kunnen gebruiken.

In het bovenstaande citaat heb ik delen vetgedrukt gemaakt. Ze zeggen iets over de eigenschappen die de overheid toekent aan het stelsel van basisregistraties, en je ziet dat deze eigenschappen overlappen met het lijstje hierboven. Allicht zijn de in mijn omgeving geuite requirements t.a.v. registers geïnspireerd door het overheids-model.

Het stelsel van basisregistraties is in detail beschreven in de “Stelselarchitectuur van het Heden“. Het stelsel bevat onder andere de Basisregistratie Personen (BRP), de Basisregistratie Adressen en Gebouwen (BAG) en het Nationaal Handelsregister (NHR). De beoogde doelen van het stelsel  zijn de bestrijding van nationale rampen of fraude, de eenmalige verstrekking van gegevens door burgers en bedrijven en besparing op beheerskosten.

In de Nederlandse Overheid Referentie Architectuur (NORA) vormt de basisregistratie een belangrijke bouwsteen. Er is een lijst met eisen waaraan het moet voldoen, en een lijst met rollen en verantwoordelijkheden. Eigenlijk is het een specificatie van een dienstverlening, en niet van een informatievoorziening.

Register-architectuur

Een register is dus blijkbaar een service die de organisatie (business) verleent. Verder worden in een register in algemene zin gegevens (gebeurtenissen) over de levensloop van objecten  geregistreerd. Dit resulteert in een opzet waarbij alle mutaties aan eigenschappen van een object in de tijd worden bijgehouden.

Als ik het probeer te vatten in een Archimate-schema, kom ik uit op het onderstaande, simplistische plaatje. Ik positioneer het register als een product van de business, dat bestaat uit een cluster van services en kwaliteitsafspraken (contract). Uiteraard draait het register om de registratie van gegevens over een voor de business essentieel business object. Er is een bedrijfsproces dat het beheer van het register realiseert, met daaraan toegewezen de rol van datamanager.

Register-businessarchitectuur
(gemaakt met Archi)

Het blauwe gedeelte van het plaatje gaat over de onderliggende applicatie-architectuur.  Op die laag is de informatievoorziening zichtbaar die in de registerfunctionaliteit voorziet. In bovenstaande plaat wordt die functionaliteit ontsloten via applicatieservices.

Bovenstaande architectuur is heel hoog-over, maar bevat wel de essentie van een Register. Het is vooral declaratief, en zegt dus niets over de manier waarop de Registerfunctionaliteit wordt gerealiseerd. Dat kan op allerlei manieren, maar ik zie vooralsnog maar twee smaken: fysiek register en virtueel register. Die werk ik nog verder uit, dus: wordt vervolgd…

Ontvlechting en sanering

Ontvlechting en sanering, twee ICT-vaktermen. Het zijn eigenlijk “gewone” Nederlandse woorden die door de ICT-wereld zijn geadopteerd. Blijkbaar was dat nodig. Neem bijvoorbeeld “ontvlechting”. Ontvlechten is alleen nodig als er sprake is van onwenselijke vervlechting. In de ICT raken zaken inderdaad nogal eens teveel met elkaar vervlochten doordat die zaken over de tijd, te haastig en op diverse manieren aan elkaar werden geknoopt. En dat gebeurt dan ook vaak herhaaldelijk en jaren achtereen, zodat de ongezonde situatie ontstaat waarin van delen van het geheel niemand helemaal begrijpt waarom het werkt zoals het werkt.

Het werkwoord “saneren” heeft louter betekenissen die nuttig zijn voor de ICT, zoals: opruimen, weer gezond maken, zuiveren en verbeteren. Maar we denken meestal aan deze betekenis: afbreken en vervangen. Natuurlijk zou je liever willen voorkomen dan saneren, maar dat is moeilijk. De druk vanuit de business is vaak te hoog waardoor toch concessies worden gedaan aan kwaliteit en zonder architectuur wordt gewerkt. En zonder overkoepelend toezicht op en zonder overkoepelende besturing van – ofwel, zonder architectuur governance van – ICT-ontwikkelingen komen de haastig neergezette oplossingen meestal niet weer onder architectuur.

Dus als een ICT-landschap over de jaren door vele uitbouwprojecten is verworden tot een complex, instabiel, onvoorspelbaar, moeilijk beheerbaar en lastig uitbreidbaar geheel, waarvan niemand meer helemaal overziet en begrijpt hoe het werkt en waarom, dan wordt het tijd voor ontvlechting en sanering. Dit zijn doorgaans grote uitdagingen.

Ontvlechten is het proces van het in kaart brengen van de complexiteit en het weer terugwinnen van het overzicht en het inzicht. Door ontvlechting komen we weer “in control” van het beheer en de ontwikkeling, zodat met vertrouwen kan worden besloten tot het opruimen van overtollige constructies en het weer beter maken van ongezonde constructies: ofwel sanering .

En als ontvlechting echt een heilloze zaak is, dan rest eigenlijk nog maar één ding: volledige sanering. Dat houdt dus in dat je een compleet ICT-landschap vervangt. Wanneer is ontvlechting heilloos? Dat is niet eenvoudig te beantwoorden, maar levensvatbaarheid en toekomstvastheid zijn belangrijke factoren.

Uiteindelijk hoop je met ontvlechting en sanering te bereiken dat we weer “in control” geraken over het betroffen ICT-landschap, en dat we deze weer voldoende gevitaliseerd hebben zodat het weer een tijd mee kan. Ook doet uw organisatie er verstandig aan haar ICT-processen te ontvlechten en saneren en te zorgen dat aan- en verbouw in het ICT-landschap voortaan onder architectuur gebeurt.

Het belang van Requirements Management en samenwerking met de Business

Begin dit jaar verhuisde ik met mijn gezin naar een nieuw huis. Verhuizingen zijn altijd hectisch, zo ook die van ons. Uiteindelijk ben je over met al je spullen en staat alles min of meer op de plek waar je denkt dat het moet staan. Alle essentiële klusjes zijn gedaan en alles is redelijk aan kant. Natuurlijk blijven er altijd klusjes die nog heel lang in je achterhoofd geregistreerd staan onder “moet ik nog doen, maar kan later wel”. Één zo’n klusje was het op de juiste hoogte hangen van een fotolijst. Klinkt simpel, zou je denken, en dat was het ook. Kwestie van meten, boren, schroefje d’r in, lijstje eraan ophangen en klaar. 

Het ging om een foto van één van de kinderen. De foto’s van z’n broer en zus hingen ernaast. Drie vierkante lijsten van 50 bij 50 cm. Het zijn schitterende afdrukken van mijn prachtige kinderen op canvas dat op een houten frame gespannen zit. Bij de verhuizing waren ze tijdelijk aan de reeds aanwezige schroeven in de muur gehangen. Twee van de drie foto’s hingen keurig met de bovenkantjes gelijk, maar de derde hing 5 cm lager (zie bovenstaand plaatje). Dat heeft mijn vrouw (de business) een tijd lang zonder klachten geaccepteerd. Een onuitgesproken issue dus. Ik (ICT-er) besloot om dit potentiële issue pro-actief op te pakken, en vol goeie moed ging ik ermee aan de slag. Een kwartiertje later bekeek ik tevreden mijn resultaat. De foto’s hangen keurig op de zelfde hoogte, met gelijke onderlinge afstand van elkaar (zie onderstaand plaatje).

Even resumerend: ik had zonder samenspraak met de business een oplossing voor een potentiële issue geïmplementeerd. Ik had geen idee van de verwachtingen van de business, nog van de exacte wensen t.a.v. de implementatie van de verwachte oplossing. A recipe for disaster?

Later op de dag presenteerde ik de oplossing aan de business (mijn vrouw). De reactie was als volgt: “waarom hangt de jongste nog steeds helemaal rechts?”. Ai! Maar ik sprong meteen in aktie. In een handomdraai verwisselde ik de meest linker en de meest rechter foto van plekje aan de muur. Resultaat: 

Shit! Dit was niet in de lijn der verwachtingen. Noch die van mijzelf, noch die van de business. Ik had het issue alleen maar vergroot in plaats van opgelost. Ik had de scope van mijn project ook veel te smal gehouden (verhang foto 3), en impliciet aannames gedaan over de de verwachtingen en wensen van de business én over de flexibiliteit van mijn oplossing. Mijn oplossing ging namelijk uit van een aangenomen uniformiteit in de constructie van de fotolijsten. Echter, die bleek toch niet zo uniform als ik dacht. Fotolijst 3 was namelijk 2 jaar later geproduceerd dan fotolijsten 1 en 2. En jawel, er is een “architectuurafwijking” tussen de twee. Zie onderstaande plaat. Ik kon de haren wel uit mijn kop trekken. Destijds had ik bij het bestellen van lijst 3 de gewenste lijst-dikte moeten opgeven. Fotolijsten 1 en 2 waren mijn referentie-architectuur. Kortom: de oorzaak van het onverwachte resultaat ligt bij de uitvoering van een eerder project. Was ik toen maar uitgegaan van de reeds aanwezige standaard-maten!

Mijn project had dus een diepgaander onderzoek moeten doen naar de exacte requirements van de business en naar de mogelijke oplossingen. Dit had ik in samenspraak met de business moeten doen, en dan was iedereen tevreden geweest. Ik had mijn snelle oplossing naast enkele andere oplossingen moeten zetten en die bespreken met mijn vrouw. Ik zie nu (achteraf) ook de volgende oplossingsrichtingen:

1. eerst de dikte van het houten frame van foto 3 gelijk maken aan die van lijst 1 en 2, en dan pas verhangen

2. een generiek, verstelbaar fotolijst-ophangsysteem (een BAVO voor de ophanging van lijsten) selecteren en implementeren welke kan omgaan met de afwijkende afmetingen van de frames

3. de diktes van de frames van fotolijsten 1 en 2 verkleinen (even de schaaf erover…) en gelijk maken aan die van lijst 3

Je ziet het, ik heb mijn les hier wel uit gehaald. Doe er zelf ook maar je voordeel mee!

Cloudificatie en Cloudisme

Zijn uw processen al gecloudificeerd? Of doet u niet aan cloudisme?

Twee woorden die ik uit mijn dikke duim heb gezogen, maar die op zich levensvatbaar zijn. Misschien worden ze zelfs al gebezigd, maar dat heb ik niet gecontroleerd.

Cloudificatie is dan “het geschikt maken voor de cloud”. Dat stoelt wel op de verwachting dat er iets voor nodig is om een proces (of een deel ervan) “in de cloud” te kunnen stoppen. Ik denk dat die verwachting heel rëeel is, want niet elk proces leent zich zonder meer voor de cloud. Ik heb geen diepgaand onderzoek gedaan natuurlijk. Ik baseer me op pure GBV (Gezond Boeren Verstand).

Mijn GBV zegt me bijvoorbeeld dat processen die in hoge mate bedrijfs-specifiek zijn moeilijker te cloudificeren zijn dan processen die generiek zijn of nauwelijks afwijken van de “marktstandaarden”. Dat zou dan betekenen dat cloudificatie ondermeer inhoudt dat je je processen meer moet standaardiseren om ze te kunnen verclouden.

Ook de strategische waarde van de informatie in een proces bepaalt of en de mate waarin het proces kan worden gecloudificeerd. Hoe hoger de strategische waarde, des te hoger de mate waarin de informatie beveiligd moet zijn. En laat beveiliging nou net een gevoelig onderwerp zijn in cloudificatiediscussies. Cloudificeren zou dan dus voor een belangrijk deel ook kunnen betekenen dat je het procesdeel dat je in de cloud zet ontdoet van strategische informatie en de benodigde koppeling met het oncloudificeerbare procesdeel (de toegang tot strategische informatie) goed beveiligt. Weer mijn GBV hier aan het werk hè, hier ligt geen fundamenteel onderzoek aan ten grondslag.

Cloudisme kan diverse betekenissen hebben. Ik ben daar nog een beetje zoekende. Misschien moet ik het zoeken in de sensatie. Een soort toerisme. Dan wordt de cloud een soort avontuurtje waarvan je terugkomt met foto’s. Leuk joh, clouds! Moet jij ook eens doen!

Of misschien moet ik het zoeken ik blootstelling en risico. Exhibitionisme en fanatisme dus eigenlijk. Ik durf mij bloot te stellen aan de cloud. Oeoeoe. Dat is het andere uiterste van het spectrum. Roekeloosheid is niet iets wat past bij cloudificatie.

Te denken valt ook aan een aandoening of een afwijking, maar die kant wil ik zeker niet op. Voor mijn gevoel is er niets mis met cloudisme. In tegendeel. Cloudisme is gezond.

Nee, ik voel meer voor een betekenis in de richting van een stroming: Realisme. Clouds zijn handig maar niet altijd verstandig en vice versa. Het is mooi om met je kop in de wolken te zitten, maar hou de voeten op de grond. En omgekeerd: nuchterheid is mooi, maar er stel je ook open (toch een beetje blootstelling dus) voor de mogelijkheden en voordelen van de cloud. Dát is cloudisme.

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.