Beste Lydia. 
 
Ja, ik denk dat functiescheiding absoluut noodzakelijk is en zal zijn in “onze” wereld. Net als dat Montesquieu hem in zijn driedeling onmisbaar verklaart in zijn wereld. 
 
In mijn idee gaat het principe van functiescheiding niet mank. Zoals ik hem nu ingevuld zie in de informatie & IT-sector gaat hij mank omdat onjuist ingevuld wordt. Dat is mijn betoog. 
 
Ik weet niet of ik je helemaal begrijp als je zegt dat “(IT-)architectuur niet beschouwd kan worden als de IT variant voor de wetgever”. Mijn probleem daarbij is dat IT-architectuur geen wetgever is. Wetgever is een functie, “iets” dat door een mens of door een organisatie van mensen “gedaan” wordt: wet geven. Architectuur, welke dan ook, is geen functie en kan dus geen wetgever zijn. In beperkte visie zou je architectuur als de wet kunnen zien. Dat zou echt een erg mechanisch gebeuren zijn, alsof een architectuur een model zou zijn. Ik weet dat IT-architecten en (IT-)Enterprise Architecten architectuur zo vaak benaderen en dat past ook een beetje bij het tactische niveau in de organisatie waar IT thuis hoort. Een soort maakbare wereld. 
In lijn met je redenering zou er een wetgever moeten zijn die de wet geeft. Net als dat er een instantie moet zijn die de gegeven wet handhaaft. Dezelfde wet, dus. Architectuur is veel breder, maar dient ook gegeven en gehandhaafd te worden. Stellen we hier architectuur, om verschil te kunnen maken, gelijk aan visie, dan zal immers de visie gegeven moeten worden en wat gebeurt binnen de visie moeten passen.  
 
Je spreekt over strategie en richtlijnen rond het IT-veld en beperkt de discussie tot dat IT-veld. Dat is een lastige. (IT-)Enterprise Architectuur en IT-architectuur, twee wat andere manieren van kijken naar en vanuit hetzelfde: IT, zijn feitelijk afgeleiden. Niet via formules, maar via een bepaalde mate van interpretatie. In termen van strategische bedrijfsmiddelen spreken we niet over IT. IT is als hulpmiddel een kapitaalgoed, terwijl informatie (& communicatie) zelf een bedrijfsmiddel is. Strategie, richtlijnen enz. worden in de praktijk steeds meer niet om IT geformuleerd, maar rond de informatie waar een organisatie mee te maken heeft en dient te hebben. Daarom strekt het IT-veld zich uit tot het tactische niveau, niet hoger. Dat heeft niets te maken met het feit dat IT van strategisch belang is voor vele organisaties. Auto’s zijn dat ook, maar toch hebben we een Ministerie van Verkeer en niet van auto’s.  
 
Zoals ik al gezegd heb is architectuur feitelijk (onderbouwde) visie. Uitgewerkt tot op het niveau van regels en richtlijnen die gehandhaafd moeten worden om de visie überhaupt te kunnen realiseren. Om de juiste IT in te kunnen zetten heb je slechts in tweede instantie IT-richtlijnen nodig. Het is veel belangrijker om te weten dat een Bank primair slechts met 3 soorten informatie te maken heeft. De basis om richtlijnen enz. uit te kunnen vaardigen op basis waarvan goed passende IT gevonden en ingezet kan worden. Niet de (IT-)Enterprise Architectuur of de IT-architectuur geven de bedrijfsrichtlijnen die nodig zijn om de goede IT in te kunnen zetten, maar de visie op de informatie van de organisatie. Het woord informatiearchitectuur wordt in de IT-wereld volledig anders gebruikt, maar dat zou een goed woord hiervoor zijn. 
 
IT-Business alignment is in feite een tweede kanteling van idee en werken. De eerste was het niet meer in separate computers denken en werken, maar het door kanteling creëren van een consistente IT-infrastructuur. De tweede is dan het kantelen van het denken in applicaties naar het denken in applicatie (en gegevens) infrastructuren. SOA is daar feitelijk een nieuwe versie van.  
De derde kanteling zit buiten de IT-wereld. Het heeft te maken met het niet meer bedenken van specificaties per te creëren applicatie, maar het neerzetten van een consistente basis, een nogal ander soort architectuur, door de kennis van de informatie bedrijfsbreed vast te stellen en te beheren. In feite een hoeveelheid kennis waaruit specificaties voor een te ontwikkelen nieuwe IT-oplossing afgeleid kan worden. We komen dan ontzettend dicht bij wat we vraagorganisatie noemen, of retained organisation. Het heeft alles met regie te maken. 
Natuurlijk klopt dit bij de verschuiving van product- naar klantgericht in mijn voorbeeld, want uiteindelijk zal een specificatie een bij de organisatie passende (= aligned) oplossing moeten bieden binnen het IT-landschap. SOA is dan niet meer of minder dan het ordenen van die IT-infrastructuur (applicatiedeel), zodat IT-oplossingen beter blijven aansluiten bij die organisatie.  
Jammer alleen dat de IT-wereld vaak nog niet het begrip service in SOA gelijk wil stellen aan dat zelfde woord in het bekende acroniem SLA. Grappig trouwens dat iets als SAAS er wel zoveel dichter bij komt. 
In mijn idee is IT-Business alignment dus het punt waar het bij IT om gaat, maar niet het einde van het denken. De genoemde derde kanteling creëert een goede vraagsituatie, waarbij IT-business alignment de top van de aanbodsituatie is. Waar informatiekunde de IT-wereld tegenkomt, waar strategisch niveau het tactische niveau tegenkomt. 
 
Wat jij bouw en beheer (\\\"management\\\") noemt vertaal ik in te managen werkzaamheden rond investeringen (wat IT-projecten genoemd worden) en exploitatie (wat beheer genoemd wordt) werkzaamheden. Als ik dit naar vraag/aanbod of strategisch/tactisch moet vertalen, dan zijn deze werkzaamheden en hun management zoals aanbod als tactisch. En ja, onder de juiste voorwaarden en condities outsourcebaar. 
 
Governance: waarom niet gewoon management? To govern, regeren. Is Balkenende een manager? 
 
Het maken van strategische keuzes is een normaal principe binnen strategisch management. Koop ik een vliegtuig, of bouw ik er zelf één? En als ik er één koop, moet dat vliegtuig dan vooral snel kunnen, of comfortabel zijn? Of moet het vooral veel kunnen vervoeren? Moet het “groen” zijn, dus vooral weinig milieubelastend en ga zo maar door. Vul voor vliegtuig een ander kapitaalgoed in, zoals IT, en het past precies. De architectuur om dit te kunnen is echter een kompleet andere dan een (IT-)Enterprise Architectuur of een IT-architectuur. Die laatste twee gaan over de IT-infrastructuur, terwijl de eerste over de organisatie en haar behoefte aan informatie gaat. 
Of het werk goed gedaan wordt? Is dat een IT-issue, of een strategisch? Als je het goed zou doen zou je pas met IT beginnen als er sluitende afspraken met “gebruikers”management zijn gemaakt. Tenzij die afspraken niet goed zijn is het zaak om binnen de afspraken te blijven. IT-management probleem, waarbij zij verantwoording afleggen aan de organisatie. Aanbod naar vraag, tactisch naar strategisch (dit laatste bij het oplossen van grotere problemen). In functiescheiding is het dus de stellende/bepalende (jij zegt wetgevende) functie die afspraken voor de vraagzijde maakt, en is het de uitvoerder, hier de IT-ers cq. IT-management, die de opdracht aanneemt (aannemer is voor investering of exploitatie), dus uitvoerend (jij zegt uitvoerende macht). Auditors (ik noem ze informatiekundigen, of informatiearchitecten in een compleet andere betekenis dan waar de IT-wereld ze in drukt) controleren dan voor de vrager of de uitvoerder het goed doet. Uit de hoek van die controleurs komen ook de mensen die de visie/architectuur/wet kennen en die via specificaties/bestekken vertalen naar uitvoerders. Binnen die architectuur kan de uitvoerder dan invulling geven aan de te maken oplossing. En zo is functiescheiding rond, en zelfs vertaalbaar naar onze bekende Baron. 
 
Hoe is functiescheiding zou invullen? Het staat hierboven eigenlijk al. Met nog een paar punten. 
 
1. Het is principieel onjuist dat bedrijfsprocessen en IT onlosmakelijk met elkaar verbonden zijn. Een flagrant voorbeeld is het idee dat geld uitgeven voor een bank gelijk is aan een ATM, een flappentap. In de 90-er jaren dacht men ook dat het bedrijfsproces geld-uitgeven niet meer nodig was omdat er ATM’s waren, en hoe verkeerd was dat. Nu er veel meer kanalen zijn is dat bedrijfsproces weer in volle glorie aanwezig, en is de alignment per kanaal een belangrijk middel voor vraag en aanbod om elkaar te vinden. 
 
2. Richtlijnen voor de inzet van IT hebben slechts in tweede instantie te maken met IT. Zeker nu IT onder de motorkap aan het verdwijnen is zijn de richtlijnen enz. steeds minder op IT dan op het bedrijfsmiddel Informatie. Een voorbeeld. Stel je stelt een lange reeks richtlijnen en uitgangspunten op waaraan een IT-leverancier moet voldoen om een gewenste IT-oplossing te realiseren. Wat je dan vooral doet is je IT-oplossing duurder maken! Zeker als ook nog eens de IT-oplossing door een IT-leverancier geëxploiteerd moet worden. Want waarom zou je uitgangspunt IBM zijn als je bepaalde informatie op een bepaalde manier nodig hebt? Misschien heeft een IT-leverancier wel een perfecte oplossing op HP draaien en kan hij die zo kopiëren en inpassen in wat een organisatie al heeft. 
Ik weet dat dit vloeken in de IT-kerk is, maar het is wel de discussie van het onder de motorkap verdwijnen. Als jij MS-Word in SAAS ter beschikking krijgt, doet het er dan iets toe of dat op Windows, Linux of MVS draait? Of met EMC of Iomega harde schijven gewerkt wordt? En dat is precies de omslag. 
Regie moet zo min mogelijk te maken hebben met IT. Maar organisaties moeten wel vertellen en afdwingen dat ze de “services” krijgen die ze nodig hebben. Daar zit de regie, niet in de IT-wereld. Daar zit IT-management. 
 
3. IT-professionals dienen niet gezien te worden als materiedeskundigen, en dat worden zij wel. Dat betekent niet dat een IT-professional geen verzekeringsdeskundige kan of mag worden, maar dan is hij/zij dus geen IT-professional meer. Ergo: IT-professionals die zich zo zwaar in bedrijfsproces storten dat ze zich als materiedeskundigen gedragen luisteren niet meer naar de echte materiedeskundigen. En creëren dus iets dat zij als IT-professional vinden dat materiedeskundigen nodig hebben omdat ze hier en daar aan die materiedeskundigheid hebben geroken. Hoe was het ook weer: 70% van de IT-projecten leveren niet op wat de organisatie graag wilde. 
Mijn ervaring, als informatiekundige met de nodige IT-ervaring, is dat als je echt in gesprek gaat met materiedeskundigen je dingen hoort en ziet waar zo vaak overheen gewalst is en wordt dat je er griezelig van wordt. Tegenwoordig licht ik vaak organisaties door op informatie en IT, en de problemen zijn zo vaak zo logisch en flagrant dat je echt niet begrijpt hoe het in hemelsnaam zo geworden is. En je wil niet weten hoe groot de uitdaging dan is om het weer naar iets normaals bij te buigen met alle belangen en meningen.  
In mijn ervaring is de IT-professional al zwaar genoeg belast als zij/hij zich bezig houdt met IT en echt goed luistert naar de organisatie. Dat gebeurt alleen zo weinig. 
 
4. Vendor management is voor mij niet gelijk aan vraagmanagement. Vraagmanagement is namelijk ook boven de interne IT-ers. Ook zij realiseren investeringen in IT of exploitatie van IT voor de organisatie. Regie strekt zich daarmee over ALLE IT-investeringen en -exploitatie uit, zonder uitzondering. Dus ook over alle IT-professionals. 
Vraagmanagement en regie baseert zich op kennis van informatie en, in 2e instantie, over hoofdlijnen voor informatie hulpmiddelen als IT. 
 
Ja, goed vraag/vendor management is natuurlijk goed voor organisatie en IT-leverancier. Stel dat een organisatie goed weet wat ze wil (kennis van hun informatie) en dit ook goed kan duidelijk maken, dan kan de IT-leverancier die dat begrijpt ook beter maken wat nodig is. Simpel. Als de IT-leverancier eerst nog eens, onder druk van tijd en geld, moet gaan uitzoeken wat de organisatie wil, dan is de kans dat het nodige divergeert zo ontzettend groot. Met de gevolgen die we op dit moment haast overal zien. 
 
Ik zie dus, in wat jij Trias Politica noemt, bepalend/stellend (wetgevend), uitvoerend en controlerend (rechterlijk). Je zegt: “Of je adviseert de regie, of je voert uit, of je controleert (in opdracht van de klant)”. De regie binnen de klant is bepalend/stellend cq. wetgevende macht. De IT-leverancier is de uitvoerende macht. Advies aan regie en controle voor klant ligt wat mij betreft niet ver uit elkaar. Ja, de rol is anders want de eerste begint vooraf en de tweede is achteraf, maar beide zijn feitelijk controlerend. De eerste legt vast wat de regie wil en kan dit ook uitleggen, de tweede kijkt of de uitvoerder de uitleg ook begrepen heeft. We weten dat het handig is om de uitlegger en de auditor, de controleur, gescheiden rollen te laten zijn. In meer IT-termen: informatie analisten en testers zijn verschillende vaklieden. Is het handig om de informatie analist te laten testen? Hangt ervan af, want de manier van werken en de bijbehorende is duidelijk anders. 
 
Natuurlijk kan je op verschillende momenten meer rollen hebben. Mijn ervaring is wel dat een adviseur geen manager moet zijn, en andersom. Uitvoerenden die door willen groeien zullen dan ook vaak bij doorgroeien moeten kiezen tussen vakinhoudelijk en managerial. Van uitvoerend naar adviseur is dan meer in lijn, want managers dienen zich te richten op het proces en minder op de inhoud. En dat is een hele omschakeling. En dat alles nog buiten het vak, maar wel als richtlijn rond de te scheiden functies. 
 
Tja, metaforen kan je niet altijd kompleet doorvoeren. Toch is functiescheiding, zoals ik eerder zei, een absolute noodzaak als we naar een volwassen informatie & IT-sector willen. Alleen zijn er nog een reeks andere principes neergezet moeten worden. Neem nu bijvoorbeeld de linking-pin van Rensis Likert. De driedeling sturend, uitvoerend en adviserend/controlerend herhaald zich dan over de niveau van de organisatie, waarbij een uitvoerend orgaan op een hoger niveau een sturend orgaan kan/zal zijn op een lager niveau, en zo dus de linking-pin, de vertaler. Logisch in vendormanagement, want de uitvoerende vendor zal ook sturend zijn/haar voor zijn personeel. Enz. Over functiescheiding gesproken….. 
 
 
Steven van ’t Veld 
 
 
\n  
 
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken