In ‘Kijk op Regie’ willen we je in een reeks artikelen deelgenoot maken van onze visie op en aanpak van regie en regisseren. In dit vierde artikel de vraag: wat is het verschil tussen Regie en SIAM?
We krijgen als Regiewijzers regelmatig vragen als: ‘Is Regie en SIAM nu hetzelfde?’, of ‘Is SIAM het operationele (run) deel van Regie?’, of ‘Wat moet ik naast SIAM nog meer regelen voor goede Regie?’
In dit artikel geven we antwoord op deze vragen door te kijken naar de overeenkomsten, maar vooral naar de verschillen. We doen dit door de scope van het DSG Framework (regie) te vergelijken met het SIAM Framework.
In de vorige drie artikelen zijn we, via de metaforen van filmregisseur, dirigent en sportcoach, tot een definitie van IT-regie gekomen:
“Regisseren van IT is het geven van richting aan, organiseren van, begeleiden van en evalueren van de samenwerking tussen gebruikers van en leveranciers van digitale diensten met als doel de maximale toevoegde waarde van deze diensten te realiseren.”
We hebben ook vastgesteld dat je als IT-regisseur actief bent in een of meerdere van de waardestromen: innovatie, implementatie en/of operatie, zowel aan de vraag en de aanbodzijde. Deze waardestromen worden soms net iets anders genoemd, maar de essentie blijft gelijk.
Een bekend ‘model’ voor het inrichten van regie is het zogenaamde ‘Demand Supply Governance Framework’ van Eraneos (voorheen: Quint). De onderstaande figuur.
Dit model laat (verticaal) de verschillende domeinen (Business, Regie, Provider) zien en in ieder domein de focusgebieden (processen, capabilities) waar ieder domein voor verantwoordelijk is. Binnen het domein van Regie wordt ook nog onderscheid gemaakt tussen regie van de vraag en regie van het aanbod.
Het laat horizontaal ook het onderscheid zien tussen Strategisch (Plan), Tactisch (Change) en Operationeel (Run). En het toont de verschillende delivery flows (waardestromen) ‘Standaard Diensten’ (Operatie, Incidenten, Requests), ‘Wijzigingen’, ‘Projecten’ en ‘Beleid’.
Tot slot laat het model ook duidelijk zien dat aan de business-zijde er meerdere bedrijfsonderdelen zijn die producten/diensten vragen en dat aan de provider-zijde er meerdere interne en externe leveranciers van producten/diensten zijn.
SIAM staat voor Service Integration and Management. Het is een aanpak voor organisaties die IT-diensten laten leveren door meerdere leveranciers.
In zo’n multi-vendor omgeving kan al snel een probleem ontstaan. Verschillende leveranciers leveren elk een onderdeel van de IT-dienstverlening, maar niemand is verantwoordelijk voor het geheel. Incidenten blijven tussen partijen hangen, processen sluiten niet op elkaar aan en rapportages zijn versnipperd.
SIAM introduceert daarom een centrale functie: de service integrator. Deze partij zorgt ervoor dat alle leveranciers samenwerken als één geïntegreerde dienstverlener.
De service integrator richt zich onder andere op: integratie van service management processen, end-to-end service management, coördinatie van leveranciers, gezamenlijke prestatiesturing en de governance van de operationele dienstverlening.
Als je SIAM gelijkstelt aan de taken en verantwoordelijkheden van de Service Integrator dan richt SIAM zich vooral op de operationele levering (supply) van IT-diensten.
Als we een gelaagd model voor SIAM (Service Integration and Management) willen maken dan valt op dat het model altijd 90 graden gekanteld wordt ten opzichte van het DSG Framework).
Het is niet moeilijk om hier ook de laag van de Business en van de Providers in te zien. En het lijkt dan ook logisch om de lagen ‘Retained Capabilities’ en ‘Service Integrator’ samen als de laag ‘Regie’ te zien.
De ‘Retained Capabilities’ is feitelijk dat deel van de IT-organisatie dat ‘overblijft’ als je alle service integrator en service provider taken/verantwoordelijkheden hier onderscheidt. Die vallen immers in die specifieke lagen. Maar wat doen die ‘Retained Capabilities’ dan precies?
Als we inzoomen op de gecombineerde laag, ‘zijn alle focusgebieden (processen, capabilities) van het DSG Framework hier dan ook in vertegenwoordigd? Hiervoor moeten we de SIAM Body of Knowledge erbij pakken en naar de verantwoordelijkheden van de verschillende rollen kijken.
Een andere plek in de SIAM Body of Knowledge om te kijken is in het nieuwe Process Compendium, waar de processen zijn ingedeeld naar strategisch, tactisch en operationeel:
Met een beetje creativiteit zou je de strategische processen redelijk op de rol van Retained Capabilities kunnen plotten. En de tactische en operationele processen lijken prima in de laag van de Service Integrator te passen.
Als je SIAM gelijkstelt aan de gecombineerde verantwoordelijkheden van de Retained Capabilities en de Service Integrator dan komen we al veel dichter in de buurt Regie.
Maar toch lijkt er een belangrijk deel onderbelicht: de vraagzijde. Zowel op de strategische laag (plan), tactische laag (change) als de operationele laag (run) is het onduidelijk wie verantwoordelijk is voor het ophalen, afstemmen en bundelen van de vraag.
Er zijn een aantal taken en verantwoordelijkheden van de Retained Capabilities die hier wel op gericht lijken, maar zo duidelijk als in het DSGF Framework heeft SIAM het niet beschreven.
Er is verschil in scope tussen SIAM en Regie:
Ook is er verschil in focus tussen beide benaderingen:
Het verschil lijkt subtiel, maar is belangrijk. In de praktijk gaat de grootste complexiteit in IT-organisaties vaak niet alleen over leveranciers, maar over de samenwerking tussen: business en IT, vraag- en aanbodzijde, projecten en operatie, interne en externe teams.
Dat kan gaan over strategische samenwerking rond digitale innovatie, samenwerking tussen business en IT in projecten, of samenwerking tussen leveranciers in de operatie.
Conclusie: in de praktijk hoeven IT-Regie en SIAM elkaar niet uit te sluiten. Integendeel: ze vullen elkaar goed aan.
IT-Regie richt zich op het sturen van samenwerking in de gehele waardeketen van digitale diensten. SIAM richt zich op het integreren van leveranciers binnen de operationele dienstverlening.
In de praktijk zien we regelmatig dat organisaties SIAM implementeren in de hoop daarmee de complexiteit van hun IT-landschap op te lossen. Er wordt een service integrator benoemd, processen worden geharmoniseerd en leveranciers krijgen gezamenlijke KPI’s. Toch blijkt de praktijk vaak weerbarstig. Incidenten blijven tussen partijen hangen, leveranciers werken nog steeds langs elkaar heen en de business ervaart weinig verbetering.
Een belangrijke oorzaak is dat SIAM zich primair richt op de integratie van operationele dienstverlening, terwijl de onderliggende samenwerkingsvraag vaak breder is. Als er geen duidelijke regie is op de samenwerking tussen business, IT, projecten en leveranciers, ontstaat er al snel onduidelijkheid over prioriteiten, verantwoordelijkheden en besluitvorming. De service integrator probeert dan in de operatie problemen op te lossen die eigenlijk eerder in de keten ontstaan.
Zonder duidelijke Regie ontbreekt vaak:
In zo’n situatie wordt van SIAM verwacht dat het problemen oplost die eigenlijk buiten het domein van service integratie liggen. Het gevolg is dat SIAM vooral bezig is met symptoombestrijding in de operatie, terwijl de echte oorzaak ligt in het ontbreken van regie over de samenwerking in de gehele waardestroom.
SIAM kan daarom een belangrijk instrument zijn binnen de operationele dienstverlening, maar alleen wanneer het wordt geplaatst binnen een bredere context van Regie. Juist die regie zorgt voor richting, samenhang en gedeelde verantwoordelijkheid tussen alle partijen die betrokken zijn bij digitale diensten.
De toenemende digitalisering van organisaties zorgt ervoor dat steeds meer partijen betrokken zijn bij het realiseren van digitale diensten. Business stakeholders, interne IT-teams, cloudproviders, softwareleveranciers en implementatiepartners werken samen in complexe ecosystemen. In zo’n omgeving is het niet voldoende om alleen de operationele dienstverlening goed te organiseren.
SIAM kan helpen om leveranciers in de operatie te integreren en zo stabiele dienstverlening te realiseren. Maar om daadwerkelijk waarde te creëren met digitale diensten is meer nodig. Dan is er iemand nodig die de samenwerking tussen al die partijen richting geeft, organiseert, begeleidt en evalueert.
Daar ligt het domein van Regie. De regisseur kijkt niet alleen naar processen en contracten, maar vooral naar de samenwerking die nodig is om digitale diensten te laten ontstaan, veranderen en functioneren. Over de grenzen van organisaties, teams en waardestromen heen.
En juist in een wereld waarin IT steeds meer een ecosysteem wordt, wordt die rol alleen maar belangrijker. Want uiteindelijk ontstaat waarde niet uit technologie of contracten, maar uit goede samenwerking tussen mensen en organisaties. En precies dát is waar regie het verschil maakt.
In volgende artikelen zullen we de waardestromen (of delivery flows) in detail onder de loep nemen. Wat gebeurt er precies in ieder gebied? Wat moet het resultaat zijn? Wat betekent het voor het type regisseur, zijn/haar taken en zijn/haar vaardigheden?