Ook voor ITIL geldt: wij van integratie vinden integratie bijzonder! En ITIL bijzonder handig!
Om de zomer met een feestje te starten, heb ik mijn ITIL4 Foundation gehaald. Oké, ik was een paar dagen te vroeg (het was een paar dagen vóór 21 juni), of tsja, eigenlijk rijkelijk laat, want er zijn er al 2 miljoen certificaten uitgereikt vóór het mijne.
Maar met vele jaren ervaring met integratie, inclusief actieve deelname in diverse ITIL(achtige) processen, leek mij dit een mooie gelegenheid om de aandachtsgebieden van integratie in ITIL in de spotlights te plaatsen.
Kort over ITIL
ITIL (Information Technology Infrastructure Library) is een raamwerk voor het beheer en de levering van IT-diensten. ITIL4 richt zich op het Service Value System (SVS). Dit SVS omvat alle aspecten die een serviceprovider moet beheersen om waardevol te zijn voor de klant. Dit SVS bestaat uit verschillende belangrijke componenten: Guiding Principles (Leidende Principes; zeven basisrichtlijnen die helpen bij het maken van beslissingen en het sturen van activiteiten), Governance (het raamwerk dat ervoor zorgt dat de organisatie haar doelen nastreeft en haar principes volgt), Practices (34 uitgebreide praktijkgebieden die de processen en middelen beschrijven die nodig zijn voor effectieve dienstverlening), Continual Improvement (een voortdurende focus op het verbeteren van diensten, processen en praktijken) en de Service Value Chain (SVC; het kernproces dat de daadwerkelijke waardecreatie vormgeeft).
Het zijn de Practices waar ik in dit blog nader op in ga – want hier vind je de meest herkenbare dagelijkse processen. En het wordt géén cursus ITIL, maar ik zal voor iedere Practice aangeven wat de aandachtspunten voor integratie zijn.
Practices
Er zijn in totaal 34 Practices, verdeeld over drie hoofdgroepen (de meest voorkomende zijn ook onderdeel van het Foundation examen):
Integratieplatform vs integraties
Bij het realiseren van ‘integratie’ wordt onderscheid gemaakt tussen een integratieplatform en de integraties. Het integratieplatform huisvest integraties. Zolang er geen integraties zijn, gebeurt er letterlijk niks. Soms kan er een reden zijn om onderscheid te maken bij een Practice tussen het integratieplatform en de integraties, maar het kan ook verdomd lastig uitpakken – maar dat zal hieronder duidelijk worden toegelicht.
Algemene managementpraktijken
Architectuurmanagement (Architecture Management) dient ook voldoende aandacht te besteden aan integratie. Ik heb, helaas, vaak genoeg meegemaakt dat integratie niet goed op de kaart staat, zowel bij architecten als de overige stakeholders in IT. Dit kan ertoe leiden dat er bij het realiseren van integraties géén gebruik wordt gemaakt van de laatste integratiepatronen of -technologieën, of dat er niet wordt opgemerkt dat er behoefte is aan extra integratiepatronen of -technologieën. Het is sowieso een pre wanneer er een gespecialiseerde integratie-architect is die dan voldoende voorlichting over het integratielandschap en de geldende integratieprincipes geeft aan de andere architecten, projectmanagers, product owners en overige IT stakeholders.
Financieel management van services (Service Financial Management) leidt vaak tot de perceptie dat ‘integratie’ alleen maar geld kost. Zodra je echter waarde toekent aan de diensten die je ermee kunt faciliteren of ontsluiten, dan blijkt dat ‘goede’ integratie ook waarde heeft. En hoewel ik nog amper heb meegemaakt dat ‘integratie’ intern wordt doorbelast, zijn er natuurlijk wel legio cases waarbij je verdient met de service die je via integratie aan externe afnemers of partners ontsluit, bijvoorbeeld wanneer je een KvK-uittreksel digitaal aanvraagt, dan betaal je daarvoor. Mocht het wél spelen dat interne diensten worden doorbelast: bedenk dan dat niet iedere interface even belangrijk is. Ondersteunen ze primaire of kritieke processen: Dan is 24×7 support waarschijnlijk een logische keuze. Wil je dat daar bewuste keuzes over worden gemaakt? Reflecteer dat dan ook bij het intern doorbelasten, anders kiest iedereen standaard voor de meest uitgebreide optie. Daarnaast zie ik dat incidenten vaak onterecht bij ‘integratie’ belanden en zou je ook kunnen nadenken over het doorbelasten van (onterechte) incidenten. Al is het maar om de Practice Voortdurend verbeteren te stimuleren.
Informatiebeveiligingsmanagement (Information Security) speelt zowel voor het integratieplatform als de integraties. Omdat je je middels ‘integratie’ kunt openstellen aan de buitenwereld, is dit bij uitstek een hot spot voor ongenode gasten. Je zult op het integratieplatform zowel de beveiliging van het platform zelf goed op orde moeten brengen, als ook de bouwblokken beschikbaar stellen voor de individuele interfaces voor een goede beveiliging op interfaceniveau. Één interface kan zomaar de zwakste schakel vormen in je beveiliging ten opzichte van de buitenwereld. Mocht je bij het inrichten van het integratieplatform nog niet kunnen voorzien wat er in de toekomst aan data over het platform zal gaan (persoonlijke gegevens, vertrouwelijke gegevens, medische gegevens, betaaltransacties, etc) dan moet je bij je afnemers (diegenen die integraties gaan realiseren) aangeven wat de beperkingen zijn, bijvoorbeeld géén medische gegevens. Mocht dan later blijken dat er tóch behoefte is aan het faciliteren van medische gegevens, dan zul je in overleg met security een fit-gap analyse moeten doen op je integratieplatform en de benodigde maatregelen nemen alvorens het integratieplatform vrij te geven voor medische gegevens.
Kennismanagement (Knowledge Management) is essentieel voor integratie. Ik noemde het al bij Architectuurmanagement: de voorlichting aan het begin van een ontwikkeltraject is ontzettend belangrijk om vanaf het begin op het juiste spoor te zitten qua integratiepatronen en -technologieën. Maar ook later: de trend is realiseren van integraties te decentraliseren, wat inhoudt dat er niet meer (alleen) centraal integratiespecialisten betrokken zijn bij het realiseren van integraties, maar ook ‘normale’ ontwikkelaars in de diverse teams die op zoek zijn naar ondersteuning en kennis over hoe zij integraties kunnen realiseren.
Leveranciersmanagement (Supplier Mangement) geldt voor integratie zoals bij andere aspecten. Let er echter op dat een integratieplatform vaak een laagje in de lasagne vormt: je hebt er een basisplatform (operating system, containerplatform, etc) voor nodig (als je een integratieproduct installeert), je maakt gebruik van andere diensten (zie de diverse servicemanagement-praktijken) – wellicht neem je een compleet integratieplatform-as-a-service af, en er worden integraties gerealiseerd. Dat kan potentieel een complexe samenhang van (interne en externe) leveranciers opleveren.
Meting en rapportage (Measurement and Reporting) richt zich op strategisch en tactisch niveau (management-informatie) en maakt daarbij gebruik van uitkomsten van Monitoring en eventmanagement. Ook op het gebied van integratie van groot belang, maar waak ervoor dat integratie niet een verkapt ‘allestoringen.nl’ (technisch monitoringplatform) wordt.
Organisatieverandermanagement (Organizational Change Management) speelt een belangrijke rol wanneer je kijkt naar integratie-architectuurtrends. Zo wordt het werken met de modernere integratietechnologiën zoals API’s en Events vaak gecombineerd met het decentraliseren van het realiseren van integratie. Ook wordt er vaker onderscheid gemaakt tussen wie er verantwoordelijk is voor het integratieplatform versus de individuele integraties. Daarnaast wordt ook de demarcatie tussen integratie en infra/netwerk-activiteiten strikter. Hier spelen dan ook veranderingen in de organisatie een rol. Zoek altijd de balans tussen wat qua visie en strategie is bepaald voor de toekomst, en wat er nu nog actueel in de praktijk speelt. Dat kunnen twee compleet verschillende werelden zijn, dus de overgang van de één naar de ander moet goed overdacht worden. Review bij zo’n overgang ook de impact daarvan op alle andere Practices. Kijk ook goed of organisatie en IT goed matchen – de manier waarop IT wordt georganiseerd volgt vaak de organisatiestructuur (zie ook Conway’s Law), andersom blijkt in de praktijk niet tot het gewenste resultaat te leiden.
Personeels- en talentmanagement (Workforce and Talent Management) is ook voor integratie van groot belang. Integratiespecialisten/architecten zijn schaars, mede een reden om het ontwikkelen van integraties te decentraliseren. Gartner spreekt van ‘citizen developers’, die zouden over minder specifieke kennis hoeven te beschikken. In de praktijk zien we deze laatste ontwikkeling nog niet zo’n grote vlucht nemen (op het gebied van integratie).
Portfoliomanagement (Portfolio Management) speelt ook voor integratie: welke integratiediensten gaan er verleend worden? Hoe ga je je integratie inzetten om gegevens, diensten en functionaliteiten te ontsluiten en uit te wisselen? Oftewel: hoe ziet je integratie-portfolio eruit? Op welke integratiepatronen/technologieën richt je je? Welke klanten en gebruikers heb je?
Projectmanagement (Project Management) omvat vele aspecten, waaronder stakeholder management. En dat klopt ook voor integratie: zorg dat de integratie-architect (of solutionarchitect) op tijd aan boord is om te voorkomen dat het project verkeerde of gedateerde keuzes maakt.
Relatiemanagement (Relationship Management) speelt bij integratie net zoals bij andere aspecten. Echter, omdat integratie altijd ergens tussen zit kunnen de relaties over de hele end-to-end keten complex worden. Verder kan er onderscheid zijn in relaties op het niveau van het integratieplatform (eerder verticaal, infrastructuur gerelateerd) versus de individuele integraties (eerder horizontaal, de keten volgend).
Risicomanagement (Risk Management) verschilt ook voor het integratieplatform en de individuele integraties. De risico’s van een geheel integratieplatform kunnen qua impact enorm zijn en per individuele integratie kan het per stuk verschillen. Ook hier geldt dus: op beide niveaus moeten er degelijke analyses worden gedaan.
Strategiemanagement (Strategy Management) kan een sterke wisselwerking hebben met integratie. Zo kan het de doelstelling van een organisatie zijn om veel gegevens te ontsluiten (bijvoorbeeld openbare registers), waar je dan qua integratie-architectuur rekening mee houdt.
Voortdurend verbeteren (Continual Improvement) speelt in ITIL eigenlijk altijd en overal een rol. Dat is voor integratie niet anders. Al zie ik wel in de praktijk dat ‘ongezien maakt ongeliefd’ en het (preventief, technisch) verbeteren van integratie(s) valt vaak moeilijk aan waarde te koppelen. Daarnaast maakt de (gepercipieerde) complexiteit van integratie, bijvoorbeeld door het groot aantal stakeholders, of met name externe stakeholders, het er niet uitnodigender op om (technische) verbeteringen door te voeren. Maar ook bij integratie geldt dat voortduren verbeteren van groot belang is.
Servicemanagement-praktijken
Bedrijfsanalyse (Business Analysis) zou ook altijd het onderwerp ‘integratie’ moeten omvatten: onderwerpen als processen en bedrijfsoverstijgende diensten zijn hier onderdeel van. Daarnaast blijkt uit ervaring dat bij een goede (initiële) analyse kennis van integratie erg kan helpen – zeker wanneer er analyses plaatsvinden op reeds bestaande processen die gebruik maken van oudere, complexe integraties (soms met businesslogica).
Beschikbaarheidsmanagement (Availability Management) ligt bij integratie iets complexer dan normaal. Aan de ene kant is integratie vaak onzichtbaar – je ziet het pas als het niet werkt. Aan de andere kant hangt de beschikbaarheid van integratie vaak af van de beschikbaarheid van andere systemen (endpoints). Daarnaast kan een integratieplatform prima functioneren, terwijl individuele integraties (bijv RESTufl API’s) eruit liggen doordat een back-end systeem niet beschikbaar is. Dan is integratie wel beschikbaar, maar de afgenomen service niet. Dit leidt vaak tot verwarring, en kan bij terugkomende incidenten tot irritaties leiden. De ervaring leert dat het ‘niet functioneren van een interface’ meestal een oorzaak heeft buiten het integratieveld. Daarnaast geldt voor de beschikbaarheid van een integratieplatform dat het platform minstens zo beschikbaar moet zijn als de hoogst gewenste beschikbaarheid van een interface.
Capaciteits- en prestatiemanagement (Capacity and Performance Management) geldt zowel op het niveau van het integratieplatform als de individuele integraties. Naast het continue monitoren (het kan zo maar zijn dat een interface in de loop der tijd intensiever gebruikt wordt), is het ook belangrijk om een check uit te voeren bij het introduceren van nieuwe interfaces. Hoeveel verkeer zal deze interface moeten afhandelen? Kan het onderliggende integratieplatform dat aan? Werkt het platform dan nog snel genoeg?
Change enablement (Change Enablement) is ook van toepassing op integratie. Zowel wijzigingen in het integratieplatform als in individuele integraties dienen het gekozen changeproces te doorlopen (inclusief review/approval Design Authority). Het is van groot belang dat changes in integraties worden afgestemd met de eigenaren en beheerders van de betreffende gekoppelde applicaties. En dat geldt ook andersom, al wordt dat regelmatig over het hoofd gezien. Als door een change in een broen/doel-applicatie deze er een tijd uit ligt dan zou de beheerder van de gekoppelde interfaces dit op voorhand moeten laten weten. Deze situatie kan namelijk voor allerlei signaleringen/alarmen zorgen bij integratie doordat bijvoorbeeld back-end systemen niet meer te bereiken zijn. Het is goed om hier vóóraf afspraken over te maken. Hiernaast kan is het soms onduidelijk wie de eigenaar van een interface-change is. Wanneer deployments/releases door een integratieteam worden uitgevoerd, wil dit niet per se zeggen dat zij ook de eigenaar van de change zijn. Wél de uitvoerder, maar de eigenaar van een change is ook diegene die ‘m heeft geïnitieerd/aangevraagd. In de regel zal een integratieteam dat nooit doen (behalve als het gaat om changes van een integratieplatform).
Incident management (Incident Management) is voor integratie vaak wat complexer omdat niet altijd duidelijk is of integratie (een interface) er uit ligt, of dat het een back-end systeem is. De ervaring leert dat een incident voor integratie meestal wordt veroorzaakt door een verstoring (of een change) in een ander systeem, meestal een back-end systeem dat niet meer te benaderen is: dat kan tijdelijk zijn, of permanent – bijvoorbeeld na een niet afgestemde verhuizing van een applicatie naar een andere server (of de cloud). Goede tweede is het opeens aanleveren van anders gestructureerde informatie, na een change in een bronsysteem. Dit laat ook weer het belang zien van Bedrijfsanalyse en Change enablement. Maar het kan natuurlijk ook zo zijn dat (delen van) het integratieplatform niet beschikbaar is/zijn.
IT-assetmanagement (IT Asset Management) is ook van toepassing op integratie. Met name een integratieplatform kan worden gezien als IT Asset (er is bijvoorbeeld vaak een licentie voor nodig, hardware, etc).
Monitoring en eventmanagement (Monitoring and Event Management) wordt bij voorkeur door een ander team (bijvoorbeeld IT4IT) aangeboden als dienst, waar integratie dan gebruik van maakt. Dit wordt ook vaak gelinkt aan Observability, zodat de hele keten in de gaten wordt gehouden.
Problemmanagement (Problem Management) geldt ook gewoon voor integratie, met ook hier de kanttekening: Waar hoort het eigelijk thuis? Bij integratie of bij een back-end systeem?
Releasemanagement (Release Management) geldt ook gewoon voor integratie. Maar er moeten wel zaken over de gehele keten worden afgestemd.
Servicecatalogusmanagement (Service Catalogue Management) speelt op twee niveaus: welke services (bouwblokken) biedt het integratieplatform aan integratie-ontwikkelaars en welke integraties worden er functioneel geboden? Standaard (of: veel gebruikte) services kunnen ook worden vertaald naar een Servicerequest (zie Servicerequestmanagement). Hier kun je ook te maken krijgen met externe gebruikers (bijvoorbeeld indien externe partijen toegang willen tot een publiek beschikbare API). Sommige integratieplatformen komen ook met functionaliteit om een servicecatalogus in te richten (bijvoorbeeld een Developers Portal).
Serviceconfiguratiemanagement (Service Configuration Managament) is ook van toepassing op integratie. Zo kunnen zowel een integratieplatform als de individuele interfaces als een Configuratie-item worden gezien. Het mooie hiervan is dat CI’s aan elkaar kunnen worden gelinkt in de CMDB, zodat je in één oogopslag kunt zien wanneer een bepaalde applicatie wordt aangepast (of verwijderd) welke interfaces en andere applicaties dit raakt. En welke interfaces door welk integratieplatform worden gefaciliteerd.
Servicecontinuïteitsmanagement (Service Continuity Management) omvat thema’s zoals disaster recovery. Vaak wordt dit bepaald aan de hand van een BIA. Bij die laatste zijn sommige aspecten meer van toepassing op een integratieplatform, en sommige aspecten meer op individuele interfaces. De (impact van) een BIA-score van een Integratieplatform zouden niet limiterend of blokkerend moeten werken voor de individuele interfaces. Dit vereist goed vooruitdenken bij het inrichten van een integratieplatform én het regelmatig onderhouden van het integratieplatform (checken bij het toevoegen van nieuwe of gewijzigde interfaces).
Servicedesk (Service Desk) is ook voor integratie van groot belang. Wat het complex kan maken is dat integratie en integraties ‘onzichtbaar’ zijn en vaak onbekend bij gebruikers die contact opnemen met de servicedesk. Het is dus noodzakelijk dat de bemensing van de service desk (of documentatie bij een online service desk) goed op de hoogte is van de concepten integratieplatform en integraties en het liefst ook een ‘best guess’ kunnen maken of een incident thuishoort bij integratie, het ontvangende back-end systeem of het verzendende back-end systeem. Het is ook van groot belang dat wanneer integratie-incidenten moeten worden doorgezet naar externe partijen (als bijvoorbeeld de weerberichten-server van de meteorologische dienst eruit ligt) de servicedesk beschikt over de betreffende contactgegevens.
Servicelevelmanagement (Service Level Management) is ook van toepassing op integratie en wel op de twee niveaus: integratieplatform en integraties. Indien een keten uit meerdere (externe) organisatie-onderdelen bestaat, kan het complex worden om alle Service Level Agreements goed te beheren. Het kan de moeite lonen om per interface te bepalen hoe kritiek deze is, zodat er een bijpassend Service level kan worden vastgesteld. Vaak wordt dit niet formeel gedocumenteerd, maar wordt er door een beheerteam een inschatting gemaakt hoe snel incidenten op specifieke integraties moeten worden verholpen. Ook komt het vaak voor dat tijdens het vaststellen van een incident er standaard een hoge prioriteit aan wordt gekoppeld (namelijk de standaard prioriteit).
Serviceontwerp (Service Design) is ook voor integratie van groot belang, zowel voor een integratieplatform als voor integraties. Een goed serviceontwerp draagt ook weer bij aan een goed Servicecatalogusmanagement en zo het voorkomen van dubbel werk (door hergebruik makkelijker te maken).
Servicerequestmanagement (Service Request Management) speelt op twee niveaus: Welke services (bouwblokken) biedt het integratieplatform aan integratie-ontwikkelaars, en welke integraties worden er functioneel geboden? Op beide niveaus kunnen standaard service requests worden opgesteld. Bijvoorbeeld voor het aanvragen van toegang tot een integratieplatform, of toegang tot specifieke interfaces (bijvoorbeeld API’s). Het kan ook zijn dat sommige zaken via het integratieplatform zelf zijn aan te vragen en af te handelen (bijvoorbeeld bij API Management via het Developers Portal). Dan moet er een afweging worden gemaakt of die mogelijkheid gebruikt wordt, of dat tóch via een andere route, bijvoorbeeld de Servicedesk, een verzoek kan worden ingediend. Hier kun je ook te maken krijgen met externe gebruikers (bijvoorbeeld indien externe partijen toegang willen tot een publiek beschikbare API).
Servicevalidatie en testen (Service Validation and Testing) dienen ook voor integratie plaats te vinden. Let erop dat de hele keten, maar dan ook écht de hele keten wordt doorgetest. Dus wanneer gegevens uiteindelijk in een rapportage belanden, zullen ook deze rapportages moeten worden getest én gecontroleerd op juistheid en volledigheid van informatie. Testen kost vaak meer tijd en moeite dan vooraf gedacht: Het end-to-end proces is soms complex en kan veel betrokken partijen kennen; niet alle gekoppelde systemen beschikken over een passende testomgeving; er onvoldoende mankracht is om alles secuur te testen. Testautomatisering heeft dan ook een sterke voorkeur. Dit kost weliswaar een investering, maar zodra het staat bespaar je een hoop tijd, bijvoorbeeld bij het her-testen bij changes van interfaces en/of changes in (upgrades van) het integratieplatform.
Technische beheerpraktijken
Infrastructuur- en platformmanagement (Infrastructure and Platform Management) moet ook voor een integratieplatform op orde zijn. Denk ook aan ‘doorverkochte’ componenten: Wellicht installeer je de software van je integratieplatform op een onderliggend platform, dus iemand die dan een integratieplatform benut, benut indirect ook de onderliggende infrastructuur. Deze gelaagdheid moet goed worden vastgelegd zodat het duidelijk is wie waarvoor verantwoordelijk is, en wie waarvoor kan worden gecontacteerd in het geval van (hoge prio) incidenten.
Software-ontwikkeling en -management (Software Development and Management) geldt zowel voor het integratieplatform als voor de integraties. Het strekt tot de aanbeveling om integraties zo uniform mogelijk te realiseren, ook indien integraties níet centraal worden ontwikkeld en beheerd.
Uitrolmanagement (Deployment Management) geldt ook gewoon voor integratie. Maar er moeten wel zaken over de gehele keten worden afgestemd.
Conclusie
Integratie moet als een serieus onderwerp worden meegenomen in de Practices: tijdig én met kennis van zaken. De complexiteit bij integratie zit in onder meer de volgende aspecten:
- Integratie werkt in de perceptie van velen als een façade voor van alles en nog wat, en daardoor ook als plek waar incidenten zouden plaatsvinden. De realiteit leert echter dat de meeste incidenten die aan integratie worden toegewezen níet door integratie zelf komen maar door problemen met bijvoorbeeld een back-end systeem, of een infrastructuur-issue. En als het dan tóch aan integratie blijkt te liggen, is de onderliggende oorzaak vaak een onnodige complexiteit, al dan niet veroorzaakt door het opnemen van business logica – dus dan is het een gevolg van foute integratie-architectuur keuzes (in het verleden)
- Zeker bij integratie met externe partijen wordt het soms onduidelijk hoe (oa) incidenten moeten worden opgepakt. Deze zouden zo snel mogelijk naar de externe partij moeten worden doorgezet, maar de manier waarop (en door wie) is soms niet duidelijk. Daarnaast blijkt regelmatig dat er geen goede contactgegevens zijn (geen 24×7, persoonlijk emailadres van iemand die op vakantie is of al niet meer bij de externe partij in dienst is) of geen goede afspraken (SLA’s)
- Daarnaast geldt bij changes die worden uitgevoerd door een integratieteam dat het integratieteam zelf níet de eigenaar van deze changes zou moeten zijn, maar slechts de uitvoerder. Het integratieteam heeft niet de benodigde businesskennis over de change, en heeft ook niet de expertise om bijvoorbeeld de planning te bepalen – daar ligt eigenaarschap dus bij de bedenker van de change
- De betrokkenheid van integratie vanaf het begin is van essentieel belang. Het is lastig om later nog bij te sturen omdat er al een té complexe oplossing is vastgesteld
Daarnaast zijn er een aantal trends gaande in de integratiewereld die impact hebben op diverse ITIL4 Practices:
- Onderscheid tussen integratieplatform en integraties: Een platform heeft andere verantwoordelijkheden dan individuele integraties – dit geldt ook voor de teams die verantwoordelijk zijn voor het platform vs de integraties
- Decentralisatie van het realiseren van integraties: Steeds meer organisaties kiezen voor een gedecentraliseerd self-service model. Bij het decentraliseren van het realiseren van integraties verhuist ook de beheerverantwoordelijkheid voor deze integraties mee – let op, dat staat dan (in de regel) los van het beheer van het onderliggende integratieplatform
- En wanneer integraties decentraal worden beheerd, let er dan op dat incidenten op een efficiënte wijze naar het correcte beheerteam worden doorgezet. En dat kan best lastig zijn wanneer een gebruiker constateert dat er iets niet werkt en geen idee of dat aan een interface kan liggen – hoe kan de servicedesk dat dan wél weten?
Kortom: de (perceptie van de) complexiteit van integratie weerspiegelt zich vaak in de ITIL-gerelateerde processen in een organisatie. Licht al deze processen eens door met een integratie-expert. Er valt nog veel efficiëntie (tijdswinst) te behalen door een aantal complexe scenario’s na te spelen en te kijken wat er beter zou kunnen. Oh ja… dit is natuurlijk onderdeel van de Voortdurend verbeteren Practice!
