Succesvolle architectuur

 
Succesvolle architectuur
Het verschil tussen gelijk hebben en gelijk krijgen
Architectuurmethoden falen als niet naast functionele ook structurele ondersteuningsaspecten aan bod komen. Bovendien falen ze als daarbij niet vanaf het begin de karakteristieken van de organisatie worden betrokken. Vier praktijkvoorbeelden om te illustreren dat een gedifferentieerde aanpak voordelen heeft. Hét bericht is: stop de ICT-centrische benadering van architectuur.
Een van de klemmende vraagstukken rond de huidige ICT-voorzieningen is hoe de bestuur- en beheersbaarheid ervan te vergroten, zodat men voldoende greep kan krijgen op ontwikkeling en aanpasbaarheid van de ICT-voorzieningen om ‘alignment’ te kunnen bewerkstelligen. Informatiehuishoudingen bestaan uit verschillende generaties oplossingen die, op elkaar gestapeld en aan elkaar geknoopt, moeten doen waarvoor ze zijn ontworpen: het ondersteunen van formele bedrijfsprocessen en informele gebruikersactiviteiten. Maar steeds opnieuw blijkt dat de snelheid en de noodzaak van veranderen groter is dan door ‘automatisering’ kan worden bewerkstelligd. Die rijk gevulde informatiehuishoudingen – voorzien van honderden applicaties en databases, waarvoor duizenden apparaten zoals pc’s, tablets, notebooks, servers en switches in de weer zijn – worden immers gekenmerkt door hun complexiteit, waardoor ze kostbaar zijn in exploitatie en moeilijk aan te passen, zowel door de grote aantallen als door de onderlinge afhankelijkheden. Van ‘architectuur’ wordt verwacht dat de ondersteuning van formele en informele processen flexibeler wordt. Architecten – getraind in het structureren van de informatievoorziening – komen met schema’s, platen en modellen over hoe het in de toekomst allemaal eenvoudiger, sneller en vooral goedkoper kan. Ook díe belofte bestaat al járen. Maar ondertussen wordt er steeds meer gestapeld en steeds meer verknoopt en lijkt de informatievoorziening op een onontwarbare berg ‘koude spaghetti’. Een vluchtige inventarisatie in een organisatie maakt duidelijk dat het werk van de architecten voor 25 procent is gericht op de vernieuwing en voor 75 procent op het laten werken van het nieuwe in combinatie met het bestaande. Kan dat anders?
Aanvliegroute
In de meeste organisaties worden de specifieke functionele delen van de informatievoorziening op dezelfde wijze ingedeeld en aangestuurd als de infrastructurele, gemeenschappelijke delen. Dan wordt, menen wij, de zo gewenste aanpasbaarheid van de informatievoorziening waarschijnlijk nooit bereikt, want dat lukt alleen als bepaalde delen van de informatievoorziening onafhankelijk van functionele veranderingen worden gemaakt, zodat niet elke functionele verandering structurele schokgolven kan veroorzaken. De omgeving van een bedrijf verandert snel en men wil dus ook snel (kunnen) inspelen op die veranderingen – vanuit bedrijfseconomisch belang is dat gewenst. Maar ongelimiteerd aanpassen van de informatievoorziening ontaardt gemakkelijk in ‘quick wins’, ad-hoc ingrepen, modieuze koersveranderingen, complexiteitstoename en – uiteindelijk – afnemend verandervermogen. Het zich louter richten op functionele aanpassingen zonder aandacht aan structurele aspecten te schenken, zal op den duur contraproductief én kostenverhogend zijn. In dit artikel willen wij verduidelijken dat onderscheid tussen functionele en (infra)structurele voorzieningen zin heeft. Daarbij bepleiten we dat de functionele onderdelen van de informatiehuishouding zo veel mogelijk langs de lijnen van het organisatorische landschap worden ingericht, gebruikmakend van gemeenschappelijke infrastructurele voorzieningen die min of meer indifferent voor functionele veranderingen zijn. De organisatorische en bestuurlijke constellatie van het bedrijf dient dus het uitgangspunt te zijn. Het zal de acceptatie en slaagkans van nieuwe voorzieningen namelijk verhogen als er zinvol onderscheid tussen de inhoudelijke aspecten van de informatiehuishouding en de bestuurlijke aspecten wordt gemaakt.
Nutsvoorzieningen
Succes en acceptatie van nieuwe ICT-voorzieningen hangen mede af van de mate waarin een bedrijfsonderdeel ervan afhankelijk is en zichzelf als eigenaar van deze voorziening beschouwt. Heeft een voorziening geen duidelijke eigenaar, dan is er blijkbaar geen aanwijsbaar functioneel belang en zal die voorziening veelal maar moeizaam functioneren en wellicht zelfs niet in gebruik worden genomen. Voor functionele voorzieningen zal het meestal eenvoudig zijn een eigenaar te vinden: dé kandidaat is het bedrijfsonderdeel waarvoor de voorziening wordt ontwikkeld. Voor infrastructurele voorzieningen is dat lastiger, omdat er geen directe relatie is met een specifieke bedrijfsactiviteit.
Vergelijk het met maatschappelijke voorzieningen: zonder overheid zullen deze niet of niet gecoördineerd van de grond komen. Voor ICT blijkt iets soortgelijks: zonder gemeenschappelijk belang en zonder een geaccepteerde eigenaar blijven infrastructurele voorzieningen hooguit op onderdelen op elkaar afgestemd. Voor de ‘harde’ technische infrastructuur zijn er meestal van oudsher rekencentrum-achtige structuren in bedrijf, maar voor de ‘softere’ data- en serviceomgevingen ligt het moeilijker. Vandaar dat ze ook moeizamer van de grond komen.
Teneinde het gewenste bestuurlijk vermogen te verkrijgen blijkt het beter te werken als de verantwoordelijkheid van de bedrijfsspecifieke (functionele) elementen bij het meest betrokken bedrijfsonderdeel zelf wordt belegd. De verschillende bedrijfsonderdelen kunnen immers het beste zelf beoordelen welke functionaliteiten vereist c.q. gewenst zijn en hebben daarvoor meestal voldoende kennis en contacten ‘in huis’. Tegelijkertijd moet er dan wél voor worden gezorgd dat naadloos passende (infra)structurele voorzieningen beschikbaar zijn die dit ondersteunen.
Dergelijke voorzieningen – de ‘nutsvoorzieningen’ in het ICT-domein – kunnen niet aan de verschillende lokale belangen overgelaten worden omdat ze de fundering van de ‘informatievoorziening als geheel’ uitmaken en als bredere ICT-servicebasis dienst doen. Dat betekent natuurlijk niet dat ze de plaats van de voorzieningen bij de verschillende onderdelen kunnen innemen – ze zijn immers algemeen beschikbaar, niet specifiek en daarom vaak voorwaardenscheppend. De opgave is dus om de verantwoordelijkheid van de infrastructurele voorzieningen goed belegd te krijgen. We hebben sterke aanwijzingen dat de mate waarin de infrastructurele, gemeenschappelijke voorzieningen al dan niet gemeenschappelijk moeten worden belegd, afhangt van de bestuurlijke inrichting van de organisatie. Hoe meer geaccepteerd centraal gezag, hoe meer ook wordt geaccepteerd dat gemeenschappelijke voorzieningen centraal worden georganiseerd en centraal worden belegd. Het gaat blijkbaar om een evenwicht, een delicaat evenwicht, tussen lokaal en gemeenschappelijk gezag. Doel is dat ze elkaar aanvullen en versterken, niet dat ze elkaar in de weg zitten. De architectuur dient een passende verdeling mogelijk te maken. Het lijkt ons daarom beter niet alleen op inhoudelijke samenhang af te gaan, maar ook op bestuurlijke mogelijkheden en gewoonten.
Architectuur? Besturing!
Architectuur heeft onder andere tot doel de informatievoorziening op te delen in brokstukken die min of meer onafhankelijk van elkaar kunnen worden gerealiseerd en operationeel kunnen zijn. Vaak maakt men daarbij onderscheid tussen inrichtingsafhankelijk en inrichtingsonafhankelijk. Doel is dan met name om die delen die snel (kunnen) veranderen te (onder)scheiden van delen die minder snel veranderen. Andere indelingen zijn natuurlijk ook mogelijk. In ieder geval hebben alle indelingen tot doel zowel de aanpasbaarheid als de stabiliteit van de informatievoorziening te vergroten met behoud van de door de organisatie vereiste samenhang.
Waarom blijkt uit de praktijk dat dit maar matig lukt? Wij hebben gemerkt dat het bekende inrichtingsonderscheid – onafhankelijk of afhankelijk – veronachtzaamd wordt. Het gaat namelijk niet om een informatie-inhoudelijk maar om een organisatorisch-bestuurlijk onderscheid. Het gaat erom wie de feitelijke beslissingsmacht heeft over welke onderdelen van de ICT en wie daarmee dus eigenaar van die onderdelen is en daardoor verantwoordelijk voor het functioneren ervan.
ICT is te beschouwen als een verzameling samenhangende en samenwerkende onderdelen. In ieder geval ligt dit in het blikveld van de architect. Een deel van die onderdelen – de functionele delen – zijn bedoeld voor die bedrijfsonderdelen die iedere dag weer opnieuw beslissen welke producten en diensten moeten worden geproduceerd en aan de klanten moeten worden geleverd. Een ander deel van die onderdelen – de infrastructurele delen – zijn verbonden met het type bedrijf en vormen de fundering van de informatievoorziening. Platformen, databases, ontwikkelomgevingen, uitwisselingsmechanismen veranderen niet van de ene op de andere dag – dat kán niet en dat wíl ook niemand. Daaruit volgt dat bewerkstelligd dient te worden dat deze infrastructurele onderdelen een andere eigenaar krijgen, met andere verantwoordelijkheden dan de functionele onderdelen. De architectuur dient rekening te houden met deze bestuurlijke consequenties, op straffe van vermenging van specifieke en algemene delen van de informatievoorziening en van ongewenste functioneringsrisico’s.
Bij architectuurontwikkeling ligt veelal de nadruk op functionele analyses en de daaruit voortkomende technisch-inhoudelijke gevolgtrekkingen en ‘oplossingen’. Dat resulteert dan in informatie- en technologie-georiënteerde redeneringen en in voorzieningen en werkwijzen die haaks op de bestuurlijke structuur kunnen staan en om precies die reden niet tot succes kúnnen leiden. Als algemene, infrastructurele ICT-voorzieningen anders worden gebudgetteerd, elders worden ontworpen en anders worden gerealiseerd en beheerd dan te doen gebruikelijk, zullen ze moeilijker van de grond komen en zal er weinig acceptatie voor zijn. Een dergelijke benadering wordt in de meeste ‘architectuurscholen’ node gemist. Let wel: het gaat niet om een of andere randvoorwaarde die aan een ICT-oplossing kleeft, maar om essentiële inperking van de ICT-oplossingsruimte vooraf. Het zal vooral om domeinoverstijgende onderdelen gaan, vaak voorwaardenscheppende zaken, zoals (bijvoorbeeld) security, datalogistiek of evidente overall-efficiencies voor platformen en netwerken. Lang niet alle vraagstukken zijn overigens domeinoverstijgend, al lijkt dat zo. Legacy bijvoorbeeld kan weliswaar een algemeen gevoeld vraagstuk zijn, maar moet toch echt door de veroorzakers worden aangepakt en opgelost – in veel gevallen zijn dat de verschillende organisatorische onderdelen!
Ten slotte: architecten zijn modellenmakers. Uit informatie- en procesanalyses worden patronen gedestilleerd op grond waarvan oplossingsvormen in beeld komen, die daarna aan organisatorische randvoorwaarden worden onderworpen. Zo ontstaan centraal georiënteerde ICT-voorzieningen in een federatieve organisatie of gedeconcentreerde faciliteiten in een centraal geleide organisatie – in beide gevallen: receptuur voor falen. Dit zou wel eens de belangrijkste reden kunnen zijn dat er zelden conform de architectuur wordt geïmplementeerd, omdat er vooral rekening wordt gehouden met een technische optimalisatie en niet met de bestuurlijk-organisatorische uitgangssituatie. Iedereen weet het: architectuur is geen doel op zich, maar louter een middel om onderdelen van de informatiehuishouding in samenhang op te delen. Voor een effectieve architectuur zijn echter óók andere criteria van belang. De, naar onze mening, meest belangrijke vraag is: wie kan er voor welke onderdelen in welke mate verantwoordelijk worden gemaakt? Architectuur zal immers vanuit de organisatorische realiteit overall-kwesties moeten aanvliegen en niet vanuit een of andere theoretische ICT-wereld, op straffe van verspilling van tijd en geld door gebrek aan acceptatie. De consequenties hiervan zijn tweeërlei.
• Knip de architectuur zodanig op dat je één bedrijfseenheid verantwoordelijk kunt maken voor een onderdeel. Met andere woorden: vermijd competentiekwesties, gedeelde verantwoordelijkheden en ongebruikelijke, dus onbeproefde, ontwikkelings- en exploitatievormen.
• Beperk de gemeenschappelijke onderdelen van de architectuur en beleg deze bij dát bedrijfsonderdeel dat het meeste belang heeft bij een gemeenschappelijke inrichting van dit onderdeel. Zo wordt de indeling conform de bestuurlijke en financiële lijnen van het bedrijf.
Afhankelijk van het ondersteuningsvraagstuk dat voorligt en welke architectuuronderdelen daarbij aan de orde (kunnen) zijn, zal het blikveld bepaald moeten worden waarbinnen naar oplossingen wordt gezocht. Het kan om structurele aspecten gaan (centralisatie, decentralisatie, federatieve opzet), om herkenbare patronen in uitvoering (processen, ketens, klantontkoppelpunten, en dergelijke) of om belangrijke kenmerken van de opbouw van producten en diensten. We lichten dit met enkele voorbeelden toe (zie kaders onder aan dit artikel).
Vuistregel voor nutsvoorzieningen
De informatiehuishouding zal, gezien vanuit de verschillende bedrijfsonderdelen, altijd gemeenschappelijke voorzieningen bevatten. Maar die gemeenschappelijke voorzieningenbasis zal er niet bij iedere organisatie hetzelfde uitzien – noch in het technische, noch in het applicatieve en informatieve domein. Dat komt omdat er voor de meeste, zo niet alle, functionaliteiten verschillende realisaties mogelijk zijn. Iedere organisatie maakt daarbij keuzes, bijvoorbeeld op basis van historische ontwikkelingen, beschikbare kennis, bestaande inzichten, vigerende besluitvormingsprocedures en de ‘installed base’. Organisaties hebben bij het kiezen van ontwikkelingsstappen bovendien te maken met hun eigen ‘de facto’ standaarden, die zowel in het business-domein als in het domein van de ICT-ondersteuning voorkomen. Ook de zo te noemen nutsvoorzieningen zijn hieraan onderworpen.
De ‘eerste orde’ automatisering is bij vrijwel alle organisaties achter de rug: administraties zijn geautomatiseerd, de logistieke procesketen wordt ondersteund, de etalage is (deels) gedigitaliseerd en de toonbank ook. De vervolgautomatisering is vaak ingewikkelder: allerlei vernieuwingen brengen ook nieuwe verbanden mee en vergen differentiaties en uitbreidingen in bestaande ketens, nieuwe processtappen en nieuwe ondersteuningswijzen. Het gaat niet om schaalgrootte-veranderingen maar om verfijningen in het net werk van werkwijzen en hun ICT-ondersteuning. Dat leidt dan niet zelden tot een technologiegedreven rechttoe-rechtaan realisatieopzet die geen rekening met organisatie- en omgevingsfactoren houdt. Daarbij wordt de structurele gevolgschade nogal eens onderschat. Advisering door gespecialiseerde externen – die de organisatie meestal nog niet kunnen ‘lezen’, maar wel snel moeten ‘scoren’ – versterkt dit effect.
Vuistregel voor architecten
Architectuur moet vanzelfsprekend bijdragen aan verbeteringen die voor het bedrijf relevant zijn. Vereist is – we zeggen het nogmaals – dat die bijdragen bij het bedrijf passen. Voor gemeenschappelijke voorzieningen geldt dat ook. Architectuur moet functionele wensen en structurele vereisten met elkaar verenigen en de architectuuroplossingen moeten dus passen in de bestaande ‘governance’ én gebaseerd zijn op de bestaande organisatorische grondregels, zoals gehanteerd in besluitvormingsprocessen, budgetverdelingen en verantwoordingscycli. Architectuur moet tenslotte ‘gedragen’ worden door de organisatie. Een goede vuistregel is: als een architectuur niet door alle belangrijke stakeholders wordt begrepen, heb je er geen!
De architectuuropdracht is naar onze mening dan ook: maak onderscheid tussen functionele onderdelen en (infra)structurele onderdelen van de informatievoorziening, op een zodanige manier dat het mogelijk is om voor ieder onderdeel één (en niet meer dan één) eigenaar aan te wijzen. Die eigenaar heeft dan de vrijheid om dat onderdeel naar eigen inzicht in te richten binnen de context van een aantal gedeelde en besloten architectuurprincipes. Met andere woorden: maak niet de theoretisch beste ICT-architectuur, maar maak een architectuur dat het beste werkbaar én bestuurbaar is.
Vuistregel: structurele aspecten vóór functionele
De voorbeelden in de kaders tonen alle vier aan dat de werkvolgorde, waarin eerst de functionaliteit wordt bepaald en daarna pas de structurele kanten als randvoorwaarden worden ingebracht, zo zijn nadelen heeft. Randvoorwaarden komen vaak pas bij implementatie aan de orde en de misser kan dan al onherstelbaar zijn. De omgekeerde werkvolgorde: eerst de structurele kanten doordenken bij het opstellen van de architectuur en daarna pas de functionele aspecten, leidt meestal tot meer realistische oplossingen.
Lessons learned
Uit de voorbeelden komt naar voren dat structuur en functie twee beschouwingsrichtingen voor de architectuur zijn die niet louter vanuit een informatorisch standpunt moeten worden uitgewerkt, maar vooral vanuit bestuurlijk-organisatorisch perspectief. In een paar ‘statements’ samengevat:
• Structurele aanpassingen in de informatiehuishouding zijn vaak moeilijk door te voeren vanwege allerlei lastig omkeerbare relaties en vertakkingen, en daarom zullen structurele vereisten zwaar moeten wegen.
• Gemeenschappelijke voorzieningen reflecteren de besturing (governance) én zijn belangrijk voor de wendbaarheid.
• Ook structurele verbeteringen hebben een duidelijke en begrijpelijke business-impact en kunnen daarom als ‘driver’ van verandering dienst doen.
Advies
In feite komen we tot een advies in viervoud:
• Maak onderscheid tussen functionele voorzieningen en infrastructurele voorzieningen van de informatiehuishouding;
• Richt de functionele onderdelen van de informatiehuishouding zo veel mogelijk in langs de lijnen van het organisatorische landschap;
• Zorg voor gemeenschappelijke, infrastructurele nutsvoorzieningen die dit ondersteunen én die min of meer indifferent voor functionele veranderingen zijn.
• De organisatorische en bestuurlijke constellatie van het bedrijf moet uitgangspunt zijn bij het opstellen en uitwerken van de architectuur.
In één samenvattende zin: het zal de acceptatie en slaagkans van nieuw ontworpen voorzieningen verhogen als tijdig de inhoudelijke aspecten van de informatiehuishouding en de bestuurlijke aspecten worden onderscheiden.
 
Voorbeeld 1: data integratie
In hoeverre het mogelijk is om de gemeenschappelijke voorzieningen al dan niet eenduidig te beleggen hangt af, zo betoogden we, van de effectiviteit van centraal gezag en de gevoelde noodzaak. Als de volledige verantwoordelijk voor een gemeenschappelijke voorziening - in dit voorbeeld data-integratie – bij één
afdeling kan worden belegd, is dat optimaal. Lukt dat niet, door bijvoorbeeld niet toereikende budgetten, niet gevoelde noodzaak of niet geaccepteerde implementatie voor een geïntegreerde gecentraliseerde oplossing, dan moet worden gezocht naar wat wél en wat niet gemeenschappelijk haalbaar is. In plaats van een centraal datawarehouse kan standaardisatie van de data-uitwisseling worden nagestreefd, door het standaardiseren van ETL (Extraction, Transformation
and Load)1, metadata en datacatalogus. Daarmee komt dan tóch een meer geïntegreerde gemeenschappelijk aanpak binnen bereik: ‘bilaterale’ data-uitwisseling
wordt gestandaardiseerd, maar niet via centralisatie.
Noot:
[1] ETL: Extraction, Transformation and Load, is een groep technologieën die veelal gebruikt worden bij de koppeling tussen systemen, waarbij er gestreefd wordt naar een minimale technische en semantische koppeling.
 

Voorbeeld 2: de dertiende maand

Een schoonmaakbedrijf zoekt een financieel pakket. Keuze te over? Nee! Het is namelijk niet alleen de ‘financiële functie’ die de keuze bepaalt. Schoonmaak tikt op weekbasis: de planning is op weekbasis, de uitvoering ook en het personeel wordt per week uitbetaald. Een schoonmaakbedrijf heeft daarom een maand van 4 weken en een jaar van 13 maanden. Rapporteren-per-maand is dan ook vier-wekelijks rapporteren. De bedrijfsklok loopt bij schoonmaakbedrijven dus anders dan bij de meeste organisaties. Dat betekent dat de keuze voor een financieel pakket een wezenlijke organisatiekeuze is. Gewone boekhoudmaanden introduceren afrondproblemen, onnauwkeurige overzichten en leiden tot mistige besturing. In een bedrijfstak die het van de kleine marges moet hebben, is dat hinderlijk en niet aanvaardbaar. De functionele aspecten van de pakketkeuze gaan hier dus samen met de structurele, die van invloed zijn op verschillende andere bedrijfsdomeinen. Die structurele kant kan ons inziens niet als randvoorwaarde bij de inrichting van een of ander financieel pakket dienen, maar is een voorwaarde vooraf die de ‘short list’ van kandidaatpakketten bepaalt. Traditioneel naar ‘marktconforme’ oplossingen zoekend, wordt het belangrijkste organisatiekenmerk gemist!

 

Voorbeeld 3: de printstraat

Een grote verzekeringsmaatschappij kent een aantal verschillende productgroepen. We zoomen in op schadeverzekeringen en zorgverzekeringen. Omdat het bedrijf door een fusie tot stand gekomen is, is een aantal ICT-inrichtingskwesties actueel geworden. Er wordt bijvoorbeeld overwogen alle printwerk in één centrale printstraat af te werken en zo schaalgrootte voordelen te boeken. Dat stuit op een aantal organisatorische en technische bezwaren. Schadeverzekeringen worden dagelijks geprolongeerd: de inboedel wordt getaxeerd, een auto wordt vervangen, men verhuist, etc. Er is sprake van een min of meer continue stroom van nieuwe polissen, groene kaarten, e.d. en dat is redelijk goed te dimensioneren. Zorgverzekeringen worden per kalenderjaar bekeken en zorgen eindejaars voor ‘bulk’ print- en drukwerk. Het schadebedrijf en het zorgbedrijf verschillen trouwens in heel veel aspecten en kunnen hun klantenbestanden wellicht delen, maar daar houdt het mee op. Ze werken ook nauwelijks samen. Eén centrale printvoorziening is daarom waarschijnlijk geen goed idee: er is te weinig gemeenschappelijkheid en er is geen samenwerkingstraditie. De organisatorische afwegingen zullen in dit geval de technische ‘overrulen’. De beoogde efficiencyverbetering zal niet worden geboekt en de proces- en producttechnische verschillen bijten de voorgestelde centralisatie. Voordat de ondersteuning van het print- en drukwerk wordt ontworpen, zullen de karakteristieken van de processen en de eigenaren ervan dus moeten worden vastgesteld.

 

Voorbeeld 4: Procespatronen

Een succesvolle beurs- en congresorganisatie heeft de beschikking over een bekend ERP-pakket, dat maandelijks gedetailleerde rapportages produceert. Nader onderzoek brengt echter boven water dat de ERP-modules omringd worden door een groot aantal spread-sheets, waarmee de organisatie-onderde­len hun feitelijke operationele taken ondersteunen. De ERP-modulen zijn blijkbaar moeilijk benaderbaar, matig aanpasbaar, volgen de werkelijke dynamiek van de activiteiten maar moeizaam en kunnen niet voldoen aan de groeiende ondersteuningseisen en de krapper wordende tijdslijnen. Veel moet handmatig worden geregeld en tijdens ‘de spits’ van een beurs of een congres is het vooral het improvisatievermogen en ‘de telefoon’ en niet de actuele systeeminformatie waar men zich op verlaat. Zaaltoewijzing, vloerindeling, afspraken met exposanten over inrichting en voorzieningen, facilitaire ondersteuning, afspraken met gasten – het gaat om allerhande informatie die door het ERP-systeem niet betekenisvol bijeen wordt gebracht. Openstelling, bewaking, toegang e.d. is overigens maar in beperkte mate van het evenement afhankelijk: het moet áltijd worden geregeld, het liefst op een kwalitatief constante wijze. Na uitgebreide analyses oordeelde de financieel directeur dat het juist de processen van de organisatie zijn die het product vormen en dat planning, uitvoering en afrekening uit herbruikbare procesbomen bestaan. Tóen ging het rap. Bedenk: koninklijk bezoek vereist oranje lopers, extra bewaking, aanwezigheid van de directie, aparte vlaggemasten en nog veel meer, ongeacht beurs of congres. Alle regelingen die daarbij gelden en de prestaties die de organisatie moet leveren, kunnen in een proces­boom worden uitgetekend. Voor de oud-strijdersbij­een­komst of de old-timers­beurs – bij koninklijk bezoek staat vast wat er gebeuren moet, wie het moet doen, welke leveranciers moeten worden inge­schakeld en hoe de ontvangst dient te verlopen. Alle facilitaire en operationele diensten kunnen hun blik hebben op dezelfde activiteitenstructuur, die ver­bonden is met deorganisatie­vloeren waar een en ander zich af moet spelen.

De gezamenlijke voorziening is dus gebaseerd op de notie van herhaalbare processen, onderverdeeld in deelprocessen, elk op hun beurt weer onderverdeeld in ... etc. en op de notie dat die processen ge­stan­daardiseerd kunnen worden als ze zich in de praktijk hebben bewezen. Die procesbomen sturen alles aan, van planning tot afrekening en evaluatie – zie het voorbeeld hierboven van ‘koninklijk be­zoek’. Op grond hiervan is pakketselectie uitgevoerd. Het nieuwe pakket vormt nu de basisvoorziening.

 
 
drs. Tinus de Gouw huis uit bestuurskundige en werkte bij Brainforce/
Capgemini, Ordina en Rabobank, waar hij verantwoordelijk was voor de architectuur van gegevensmanagement, datalogistiek, business intelligence en big data. Momenteel heeft hij een eigen bedrijf DeGouw Trainingen en is hij associate bij IT-eye.
dr. Jan Truijens (truijens.digit@planet.nl) werkte achtereenvolgens bij het rekencentrum van de Universiteit Utrecht, bij consultancybedrijven (James Martin Associates en Stratix) en Rabobank. Tevens doceerde hij parttime aan de Universiteit van Amsterdam. Enkele jaren geleden promoveerde hij op een architectuuronderwerp.

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag