We stappen momenteel het tijdperk in van ultieme klantgerichtheid en dienstverlening op maat. Producten en diensten worden precies afgestemd op de specifieke eisen en wensen van individuele klanten. Een hypotheek-op-maat, advies-op-maat, de klant of gebruiker staat helemaal centraal. Voor de interne it-processen zou het tegenovergestelde moeten gelden. Want om de it-organisatie flexibel en efficiënt te houden is het juist raadzaam gebruik te maken van standaard tools en best practice-oplossingen in plaats van maatwerk.
Helaas heerst daarvoor nog veel koudwatervrees. Vooral grotere it-organisaties komen vaak in de verleiding hun it-beheerprocessen zelf te definiëren en vast te leggen in diverse tools. Ze doen dat vanuit een vaste overtuiging dat ze uniek zijn en out-of-the-box ITSM-oplossingen daarom onmogelijk kunnen voldoen. Een duur misverstand, want het vergt veel inspanning en geld om een it-managementtool aan te passen op de specifieke procedures en wensen van een onderneming.
Een it-organisatie bestaat uit diverse ontwikkel- en beheerafdelingen die elk met hun eigen tools en processen in de weer zijn. Deze teams mogen vaak autonoom toolselecties maken en hun eigen hulpmiddelen kiezen. De cio bemoeit zich eigenlijk te weinig met het algemene tool-beleid voor it-beheer. Er is vaak ook geen centraal aanspreekpunt of eigenaar aan te wijzen. Het gevolg is een wildgroei aan beheertools die niet goed op elkaar aansluiten. Hierdoor is er geen echte grip op de kwaliteit en prestaties van de it-diensten. Afdelingen werken veel langs elkaar heen en optimaliseren alleen hun eigen terrein, waardoor de end-to-end dienstverlening niet transparant is en maar niet onder controle lijkt te komen. Door die lappendeken aan beheertools komt ook maar weinig stuurinformatie naar boven om de juiste beslissingen te nemen. Het gezamenlijk tot stand brengen van een standaard raamwerk van tools en processen – ook wel ‘IT for IT’ (IT4IT) genoemd – komt maar moeizaam van de grond. Ook als er beleid ten aanzien van it-beheertools is opgesteld, vinden afdelingsmanagers altijd wel een reden om hiervan af te wijken. Ondanks het feit dat it-processen zowel binnen het bedrijf als daarbuiten op eenzelfde manier kunnen worden ingericht, lukt het vaak niet om tot een eenduidige toolkeuze en procesinrichting te komen.
Uitdaging
Is er wel besloten tot één gemeenschappelijk servicemanagement tool, dan ontstaat de volgende uitdaging: hoe voldoen we aan al die verschillende wensen en eisen van de diverse afdelingen die er gebruik van moeten maken? Omdat een standaard werkwijze binnen de it-organisatie ontbreekt, moet men de tool aanpassen aan de afwijkende processen, procedures en wensen van de verschillende it-afdelingen. De verschillende methodes en procedures worden gecombineerd in één tool wat leidt tot veel aanpassingen en een moeizamer gebruik ervan.
ITIL weinig houvast
Hoe ging men tot voor kort bij de implementatie van een servicemanagement-tool te werk? Er werden ITIL-consultants ingehuurd om een procesmodel te maken met in detail uitgewerkte procedures. Een tool werd in veel gevallen pas daarna geselecteerd en vervolgens aangepast aan de specifiek voor het bedrijf ontwikkelde it-procesmodel. Ik moet daar overigens wel eerlijk bij vertellen dat dit in veel gevallen ook wel noodzakelijk was, aangezien veel it-servicemanagementtools na installatie niet eens direct bruikbaar zijn om ITIL-processen te ondersteunen. De meeste tools zijn meer een gereedschapskist met veel vrijheden die maar weinig sturing geven aan it-activiteiten. De out-of-the-box instellingen van veel servicemanagementtools zijn vaak onvoldoende om direct mee aan de slag te kunnen. Daarbij komt ook nog dat ITIL eigenlijk te weinig houvast geeft voor een daadwerkelijke procesinrichting. De ITIL-processen zijn op zo’n hoog niveau gedefinieerd, dat er nog veel werk nodig is om ze concreet te maken en operationeel te krijgen.
Herimplementatie
Na veel moeite en een flinke investering beschikt de it-organisatie uiteindelijk wel over een werkend it-servicemanagementtool. Maar niet voor lang. Na enkele jaren moet de applicatie weer geüpgraded worden naar een nieuwe versie. En als gevolg van de vele aanpassingen is dat een moeizaam proces geworden. In veel gevallen gaat men daarom maar over tot een volledige herimplementatie of kiest men voor een andere leverancier. Het hele proces wordt weer van voren af aan gestart, waardoor veel ITSM-omgevingen niet echt tot volwassenheid komen.
Integratie
Als gevolg van de bedrijfsspecifieke inrichting wordt de integratie van een servicemanagementsysteem met andere tools ook steeds problematischer. Denk aan het koppelen van discoverytools voor het automatisch vullen van de CMDB, monitoring tools en identity- en access management tools. Na vele jaren van investeren in it-tools zijn de meeste it-organisaties er nog steeds niet in geslaagd om een volledige integratie te bewerkstellingen. Met veel kunst en vliegwerk wordt hooguit data uit verschillende systemen gekopieerd en worden rapportages handmatig in elkaar geknutseld.
Versnipperde aanpak
Tegelijk wordt van de it-organisatie steeds meer een end-to-end aanpak gevraagd met integrale processen over alle it-diensten en -afdelingen heen. De huidige versnipperde aanpak ten aanzien van beheertools en proceseigenaarschap maakt dit onmogelijk. Integratie van processen en tools zijn een vereiste om de hele it-keten te kunnen managen, vanaf het indienen van een wijzigingsverzoek naar het ontwerpen, ontwikkelen, bouwen, testen, deployen tot en met het in beheer nemen. Dit vereist een standaard procesmodel, ondersteund door standaardoplossingen.
Een andere aanpak is noodzakelijk…
it-organisaties doen er beter aan mee te liften op een best-practice-model dat continue wordt ontwikkeld op basis van de kennis en kunde opgedaan bij vele honderden bedrijven. Dan kan men voortdurend meegroeien met nieuwe versies van procesmodellen in plaats van zelf opnieuw het wiel te moeten uitvinden. Het idee van één standaard procesmodel lijkt nu voorzichtig draagvlak te krijgen, zelfs bij grote organisaties. Naast een snelle implementatietijd en een forse besparing op kosten draagt een standaardoplossing bij aan betere onderlinge samenwerking en echte integratie van alle it-processen, zowel binnen als buiten het bedrijf. Het belangrijkste is dat men dan kiest voor een best practice procesmodel dat in detail is uitgewerkt en gebaseerd is op een standaard servicemanagementtool zoals van Servicenow, HP of BMC Remedy.
Onderstaande tabel toont de verschillen tussen de huidige ITSM-aanpak en een nieuw werkwijze.
|
Huidige werkwijze |
Nieuwe werkwijze |
|
Afwijkende processen en procedures per afdeling of bedrijfsonderdeel. |
Standaard processen en procedures over alle it-afdelingen heen. |
|
Gefragmenteerde tool-set (veel losse tools) van veel verschillende leveranciers. Beperkte onderlinge integratie. |
Volledig geïntegreerd en gestandaardiseerd it-managementlandschape met een standaard generiek procesmodel (van een beperkt aantal leveranciers). |
|
Intern hosten (en beheren van) beheertools |
It-servicemanagement tools in de cloud (SaaS) |
|
Veel aanpassingen en maatwerk in tools om specifieke procesinrichting te ondersteunen. |
Gebruikmaken van standaard best practices die al volledig geconfigureerd zijn in de tool. |
|
Hoge kosten voor upgrade naar nieuwe versies. |
Eenvoudige upgrade naar nieuwe versies (voortdurend meeliften met nieuwe functionaliteit) |
|
Veel coördinatie van beheertaken en activiteiten buiten beheertools om (e-mail bestuurde it-organisatie) |
Een standaard workflow engine om alle it-taken te coördineren (onderdeel van een ITSM tool) |
|
Diverse rapportage-tools. Veel handwerk om rapportages te maken en te consolideren. |
Geïntegreerde en volledige IT-rapportage uit één it-datawarehouse. |
|
Weinig tot geen stuurinformatie over de performance van de it-organisatie. |
Standaard performance indicatoren |
|
Vele losse administraties ten behoeve van configuratiebeheer, kennismanagement en documentmanagement. Excel als belangrijkste tool. |
Geïntegreerde kennis, configuratie- en documentmanagementsysteem. |
|
Weinig geautomatiseerde interfaces met externe service providers. |
Volledig geautomatiseerde koppelingen de diverse externe service providers en cloud-leveranciers. |
|
‘Van kastje naar de muur’- syndroom bij eindgebruikers |
Vlotte en eenduidige support middels één centrale it-service portal. |
Aansluiting op markt
Er is nog een belangrijke reden om te kiezen voor een best-practice-oplossing in plaats van maatwerk. Organisaties besteden activiteiten steeds meer uit aan meerdere externe serviceproviders. Belangrijk is dan dat de processen tussen die leveranciers goed worden afgestemd en geïntegreerd. Ook dat vraagt om gebruik van standaard procesmodellen om bijvoorbeeld incidenten en wijzigingsverzoeken uit te wisselen. Je kunt daarmee ook eenvoudiger besluiten de hele ITSM-omgeving in de cloud te plaatsen of zelfs af te nemen op basis van een SaaS-abonnement. Je hebt dan geen zorgen meer over versiebeheer of onderhoud en betaalt een vast prijs per gebruiker per maand.
Een nieuwe manier van werken
Er is veel – zo niet alles – voor te zeggen om de organisatie aan te passen aan het tool in plaats van andersom (mits de tool uiteraard een goed werkend standaard procesmodel heeft dat continue wordt doorontwikkeld). Ik heb getracht je daarvan te overtuigen. Maar dan moet ik ook de andere kant benoemen. Als je daadwerkelijk kiest voor een standaard best-practice oplossing, inclusief vooraf gedefinieerde processen, zul je je medewerkers daarmee vertrouwd moeten maken. Op zichzelf is dat niet spannend, want zoals gezegd zijn de processen in de kern overal hetzelfde. Maar toch druk ik je op het hart de mensen tijdig te informeren over je keuze en te betrekken bij de implementatie. Want verandering, hoe klein ook, kan op grote weerstand stuiten. Onderschat daarom niet de communicatie rond je project. De voordelen van een out-of-the box oplossingen zijn evident, maar afscheid nemen van oude gewoonten en vertrouwde handelingen doet altijd even pijn.
Ir. Rob Akershoek, IT4IT-architect bij Logicalis SMC
Vanuit beheersaspect is dit artikel wel te begrijpen, maar wat is de impact voor de “klant” ???
Als je als IT afdelingen een groot bedrijft moet ondersteunen dan heb je binnen zo’n bedrijf te maken met diverse afdelingen en daardoor ook verschillende behoeften.
De wensen en behoeften van de secretaresses zouden best wel eens heel anders kunnen zijn dan die van een innovatie-afdeling.
Een groot gevaar van een “one suit fits all” benadering zoals hier omschreven wordt is dat er of voor de ene afdeling overgedimensioneerd wordt, of voor de andere ondergedimensioneerd wordt.
Zo wil je bepaalde afdelingen, uit oogpunt van beheersbaarheid, niet de mogelijkheid geven om zelf instellingen te wijzigen en/of software te installeren. Voor een innovatie-afdeling is dit echter bijna een must om hun werk goed te kunnen doen.
Een oude systeembeheer wijsheid is:
Als het werkt blijf je er met je poten vanaf.
Het verhaal wat hier geschetst wordt is puur theoretisch want in de praktijk kun je eenvoudig weg niet alles over een kam scheren. Wat dat betreft verwacht je ook niets anders van een IT-architect.
Als je niet oppast dan zadel je systeembeheerders op met tools die zijn nooit gekozen hebben (omdat de manager de goedkopere concurrent wel goed genoeg vond) en daar diep ongelukkig van worden en daardoor hun werk minder goed doen of zelfs gewoon op zoek gaan naar wel een leuke baan.
Geef ze die vrijheid om hun werk zo goed mogelijk in te vullen en houd ze daar verantwoordelijk aan. En een goede systeembeheerder is proactief bezig dus als die aandringt dat iets belangrijk is mag dat niet blijven liggen.
Dat je over de hele linie zoveel mogelijk neuzen dezelfde kant op wilt hebben is logisch maar dat moet geen bureaucratische verplichting worden die je eerder tegenwerkt dan dat je er nut van hebt.
In de praktijk is er vaak sprake van incidenten waarin snel geschakeld moet kunnen worden. Als er dan geen shortcuts mogelijk zijn dan zullen sommige zaken lang duren en raak je mogelijk klanten kwijt of wordt de sfeer er niet beter van. Zolang die uitzonderingen geen regel worden trouwens.
Heb het enige malen gezien dat er vol goede moed grote verandering doorgevoerd werden en alles beter zou moeten zijn. Maar toch lieten de cijfers een jaar of jaren later toch slechtere cijfers zien. Zoals altijd zit het geheim in de details.
Dit artikel zou ikzelf geschreven kunnen hebben. Dank Rob. Ik ben ook voor de out of the box aanpak ipv maatwerk. In the end is het goedkoper, meer standaard, geen problemen met upgraden, etc. etc.
Zoals Johan aangeeft zal dit niet op de support van de beheerafdeling steunen. Die willen liever een best of breed oplossing of de oplossing die ze thuis ook gebruiken of de tool die al 10 jaar geleden out of support is gegaan bij de leverancier, maar nog steeds de beste is.
Het blijft een spel van gelijk hebben en gelijk krijgen in een gevoelige heilige huisjes cultuur van de IT organisatie.
Wat ik in de praktijk zie gebeuren en dan met name bij wat grotere bedrijven is dit: Men gaat maatwerk bouwen op standaard oplossingen.
Dit is de *allerslechtste* oplossing en dient ten alle tijden voorkomen te worden! Je hebt namelijk alle nadelen van maatwerk en alle nadelen van standaard software en geen van de voordelen van maatwerk en standaard software.
De reden is dat bedrijven deze keuze toch maken is:
1) Ze kopen standaard software wat vaak een vereiste is (zelf bouwen doet men niet) en leunen zo op een goede basis.
2) Het is er makkelijker doorheen te krijgen bij beslissingsnemers.
3) Standaard software voldoet niet aan alle vereisten, maar men denkt met de 80 / 20 regel alsnog wel voor elkaar te krijgen
Om even wat voorbeelden te noemen waarom deze keuze slecht is.
– Upgrades zijn weer duur omdat het maatwerk op de nieuwe release getest moet worden waardoor dit uitgesteld wordt met alle gevolgen van dien.
– Het maatwerk wordt weer betaald uit 1 pot (de klant) en niet het delen van de kosten over alle klanten
– Maatwerk bouwen op een bestaande architectuur is complex, betekent altijd het buigen van de bestaande logica (anders was het wel standaard geweest) en is dus complexer en minder logisch
– Als de standaard oplossing een andere kant op groeit dan het maatwerk wordt de technologie schuld exponentieel hoger
– Enorme afhankelijkheid van de maatwerk ontwikkelaars en een doorlopende kostenpost.
Voordelen die men mist als je voor maatwerk op standaard software kiest versus volledig maatwerk of zelf bouwen:
– Men heeft geen eigen keus voor de basis architectuur
– Kan geen volledige eigen keuzes maken
– bij *echt* maatwerk kun je de software aanpassen aan de organisatie, hier mis je dat voordeel.
– Je betaald EN voor de standaard EN voor het maatwerk.
En zo kan ik nog een boek vullen.
Kies standaard en hou je eraan (goed vooronderzoek), je commit je in feite de organisatie aan te passen aan de software, of ontwikkel het zelf (met een partner), maar dan wel vanaf scratch.
De gulden middenweg in deze is dus in ieder geval dodelijk.
Ik heb een heel aantal praktijkvoorbeelden in mijn anekdote boekje, want gek genoeg is de slechtste beslissing diegene die het vaakst voorkomt.
Ik geloof in standaard software op de juiste plekken. Ik geloof in puur maatwerk op de ander juiste plekken.
De enige niet behandelde smaak is de standaard software die zo flexibel is dat je er maatwerk mee kunt bouwen, vaak de zogenaamde “Platform as a service”. Die is veelbelovend, maar ook daar zijn skills voor nodig om het goed in te zetten. Het lijkt een goed idee, maar ben er nog niet helemaal van overtuigd.
@Henri: wat jij in praktijk ziet gebeuren is heel herkenbaar.
De oorzaken die ik gezien heb tot nu toe hangen samen met het artikel: van bovenaf wordt standaard software opgelegd die voor 80% van de organisatie voldoet.
Die andere 20% gaat vervolgens inderdaad lokaal aan de slag om maatwerk te maken boven op de standaard software om op deze manier toch invulling te kunnen geven aan hun behoeften.
Dit zijn helaas vaak verborgen kosten. De kosten van implementatie die gerapporteerd worden naar management gaan alleen over die 80%, de kosten voor het lokale maatwerk zie je nergens terug.
Als eerste is er een wezenlijk verschil tussen ITIL en ITSM, die het respectievelijk hebben over CI’s en assets. Assets vertegenwoordigen een financiële waarde met afschrijvingspercentages maar ontberen onderlinge relaties. Configuration items hebben die relaties wel maar er zijn geen afschrijvingen aan gekoppeld waarmee levensduur niet afhankelijk is van de financiële waarde maar de technische veroudering voor de organisatie.
Kortom, ITSM is een boekhoudkundige benadering welke de plank volledig misslaat om tot efficiëntere afstemming van IT-diensten te komen doordat het kind telkens met het badwater weggegooid wordt. Opmerkelijk dat de auteur stelt dat de organisatie aangepast moet worden aan de tool, dat is gewoon de ‘Wij van WC-eend adviseren WC-eend’ onzin.
Waneer je een timmerbedrijfje of een friture hebt dan kun je idd wel met standaard meuk uit de voeten.
Dat je een wat grotere winkel hebt kun je ook prima je procedures op standaard rommel enten.
Maar het houd als snel op als jij een specialistisch bedrijf hebt, met specialistische procedures.
Dan kom je met SAP en MicroSoft niet meer uit de voeten.
Ik heb veel met dergelijke clubs te maken gehad en werk nu ook voor een bedrijf dat al jaren zeer sucsesvol de hele rotzooi in eigen beheer ontwikkeld.
Dat spaart een hele bak geld uit maar ja je moet er wel goede mensen voor vinden.
En daar lopen weer tegen het aloude probleem. de automatiseerders van tegenwoordig kennen enkel wat standaard oplossingen en blijken niet in staat andere technieken eigen te maken.
Dus moet je vissen in de vijver van automatiseerders die aan zelfstudie doen, en die je niet via de gangbare kanalen gaat vinden.
En zo kom je dan idd toch weer uit op de rommel die iedereen gebruikt en waarvan iedereen het normaal vind dat het bakken geld kost, regelmatig onderuit gaat, nog meer geld kost, heel duur is, een hoop elende oplevert en… ehhh had ik ook al iest gezegd over het kosten plaatje ?
In mijn beleving is overigens de meest gemaakte fout dat het management teveel op haar eigen gevoel opgaat en niet goed overlegd met het systeembeheer zelf.
En een beetje kruisbestuiving tussen de verschillende onderdelen qua systeembeheer kan ook nooit kwaad.
Ik snap het pleidooi voor standaardisatie maar ben het niet helemaal eens met de weg die auteur voorstelt. Een tool als breekijzer voor standaardisering gebruiken lijkt mij eerlijk gezegd geen goed idee, in elk geval niet in staande serviceorganisaties.
Er zijn gestandaardiseerde procesmodellen ontwikkeld waar diverse tools al een aangepaste versie voor leveren en die mee evolueren met de ontwikkeling van het model . Zelf heb ik al enkele keren gewerkt met ISM dat inmiddels door meerdere publicatie- en helpdesk tools wordt ondersteund, zoals Mavim, BPM Protos, TCG Infoland, TOPdesk, Mexon, Axios, Clientele.
Het verschil met de situatie in dit artikel is dat deze tools de (ISM)processen volgen en er ruimte is om binnen die processen, op basis van aanvullende vragen en besluiten de te volgen generieke werkwijze te kiezen. Binnen de vastgestelde werkwijze kunnen eveneens keuzes worden gemaakt voor specifieke werkwijzen bij de afhandeling van (bepaalde) calls of serviceverzoeken alsook voor de verdeling van taken, bevoegdheden en verantwoordelijkheden die daarbij horen. Specifieke werkwijzen kunnen best practices van buiten zijn, maar vaak gaat hem juist om eigen (soms door schade en schande verkregen) best practices – en wat goed werkt moet je niet willen veranderen, maar wel willen borgen.
Goede tools zijn onmisbaar voor een serviceorganisatie, dat is buiten kijf. Goede, gemanagede processen zijn echter veel “onmisbaarder” en die zal je toch eerst op orde moeten hebben, ook als je ze baseert op een gestandaardiseerd model. Tools volgen processen, zogezegd, en niet andersom.
Bij de keuze van tooling is het daarom juist van belang dat zij de door de organisatie gemaakte keuzes kan volgen en ondersteunen en deze niet voorschrijft.
Ik heb een dergelijk artikel al eerder langs zien komen en uitgebreid becommentarieerd. Als je al begint te stellen dat ITIL je te weinig houvast bied dan heb je te weinig kennis van ITIL. Als je dan voor als doet aan kruisbestuiving dan denk ik dat het een tikje te kort door de bocht is.