Samenwerking tussen de beheerdomeinen - deel 2

Al eerder aangekondigd hierbij de artikelenserie die kan helpen bij het inrichten van de samenwerking tussen IV (informatievoorzienings)-management, applicatiemanagement en infrastructuurbeheer, meestal functioneel beheer, applicatiebeheer en technisch beheer genoemd.

Deel 1, ICT-beheerdomeinen laten samenwerken, gaat in op de redenen waarom een goede samenwerking cruciaal is. Het geeft ook aan dat volledige integratie van de drie domeinen ongewenst is. Essentieel zijn duidelijke koppelvlakken, goede afspraken en overeenstemmende organisatievolwassenheid.

Deel 2, Goede taakverdeling cruciaal bij afhandelen verstoringen, concludeert dat het voor een goede afhandeling van verstoringen van belang is dat er heldere afspraken zijn gemaakt tussen alle betrokkenen over de werkwijze en de onderlinge taakverdeling. Verder moeten de goede mensen op de goede plek zitten. Wat de beste manier van inrichten en samenwerken is, hangt af van de aard van de producten en diensten die door de servicedesk worden ondersteund.
In dit artikel is een aantal handvatten aangereikt voor het maken van keuzes hierin.

Deel 3, Continue kwaliteit: samenwerken bij dagelijks beheer van applicaties, gaat in op de samenwerking tussen enkele andere dagelijkse beheerprocessen, die te maken hebben met de beschikbaarheid, betrouwbaarheid en performance van de informatiesystemen en de continuïteit bij calamiteiten. Deze aspecten zijn samengevat onder de noemer ‘continue kwaliteit’. De samenwerking tussen de beheerprocessen wordt wederom beschreven aan de hand van BiSL, ASL en ITIL. Continue-kwaliteitsaspecten zijn belangrijk voor succesvol end-to-end service management. Het is essentieel dat de drie beheerdomeinen in onderling overleg de eisen van de business vertalen in passende maatregelen voor continue kwaliteit. Daarnaast moet er regelmatig, frequent contact zijn over de resultaten van die maatregelen en over aanpassingen die eventueel nodig zijn.

Deel 4 en 5 gaan in op Samenwerken bij wijzigingen op applicaties. Het eerste deel gaat over het samenwerken bij het opstellen en verwerken van de requirements en bij het bepalen van de consequenties van een voorgenomen wijziging (impactanalyse). Het tweede deel behandelt een aantal andere belangrijke aspecten van het wijzigingsproces, zoals de samenwerking bij de planning, het ontwerpen en het testen van een release.
Zeker ook bij het doorvoeren van wijzigingen op applicaties is het van belang dat heldere afspraken zijn gemaakt tussen alle betrokkenen over de werkwijze en de onderlinge taakverdeling. Die afspraken gelden de kwaliteit en de opleverdata van de uit te wisselen producten als wijzigingsverzoeken, impactanalyseresultaten, requirements, ontwerpen, te testen
programmatuur, testverslagen en andere documentatie. Het aanwijzen van een eindverantwoordelijke voor de totale wijziging die met name de planning bestuurt, kan veel problemen voorkomen.

Deel 6, Samenwerken bij contractueel aansturen beheeractiviteiten, concludeert dat het bij het opstellen van contracten in het algemeen, en van SLA’s in het bijzonder, van belang is om alle belanghebbende partijen hierbij te betrekken. Probeer er wel zoveel mogelijk voor te zorgen dat de gebruikersorganisatie voor de betreffende applicatie(s) slechts met één partij een SLA afspreekt. Deze partij voert dan de regie over de onderliggende ICT-leveranciers.
Verder is het belangrijk om werkbare SLA’s op te stellen; denk goed na over wat echt nodig is voor de ondersteunde bedrijfsprocessen. Spreek meetbare dienstenniveaus met elkaar af, niet te weinig maar vooral ook niet te veel. Alleen dan hebben alle betrokkenen plezier van de contracten.

Het 7de en laatste deel, Samenwerken bij ontwikkelen toekomststrategie, gaat in op het strategische niveau: hoe zorg je ervoor dat klantorganisatie en ICT-organisatie opgelijnd zijn en blijven? Het behandelt onderwerpen als applicatieconsolidatie en het vormgeven van de strategische samenwerking.

Samenwerking tussen de drie beheermodellen en -domeinen

In de tijd dat ASL en BiSL ontwikkeld werden (en hun voorgangers R2C en FBM) richtte ITIL zich nog voornamelijk op Infrastructuurbeheer, oftewel technisch beheer. ITIL heeft zich de afgelopen jaren verder ontwikkeld en is nu een model voor IT Service Management in de volle breedte. ASL was voor applicatiebeheer en BiSL voor functioneel beheer (om even in de Looijen-termen te blijven, zie item Welkom). Het risico van drie modellen voor drie domeinen is dat iedereen zich op zijn eigen domein terugtrekt en dat de samenhang wordt vergeten. Terwijl het leveren van een adequate informatievoorziening juist heel sterk afhangt van communicatie en samenwerking. Waarom dan niet één model? Daar is een aantal redenen voor. In de Link "Effectieve samenwerking tussen de beheerdomeinen" kunt u daar meer over lezen.

Daarnaast is vorig jaar een artikelenreeks verschenen in het IT Beheermagazine van 7 artikelen waarin ingegaan wordt op de onderwerpen waarin je het meeste moet samenwerken en hoe je dat kunt inrichten. Deze artikelenreeks is nu nog alleen bij mij op te vragen (en uiteraard te lezen in IT Beheer Magazine van dec 2006 tot juli 2007), maar zal zo spoedig mogelijk via links beschikbaar worden gesteld.

In een volgende bijdrage in deze blog zal ik ook inhoudelijk wat dieper op de materie ingaan.

Welkom

Hallo, welkom bij (alweer :-) ) een blogspot over IT Service Management.

Waarom deze site? Wij Nederlanders zijn gek op procesmodellen, alleen ITIL® en CMMI waren voor ons niet genoeg. Delen en Looijen hebben jaren geleden drie IT-beheerdomeinen onderkend. Elk van deze domeinen kent zijn eigen behoeftes en op basis daarvan zijn dan ook voor elk van deze domeinen eigen modellen ontwikkeld. Op deze site meer informatie over deze modellen: ASL (Application Services Library) voor applicatiemanagement, BiSL (Business Information Services Library) voor operationeel functioneel beheer + informatiemanagement. Dit laatste model is uitsluitend bedoeld voor degenen die informatievoorziening nodig hebben, de vraagkant/businesskant, de opdrachtgevers van IT. ASL is een model voor de aanbodzijde, voor leveranciers van IT-diensten.

Ik ben een van de mensen die aan de basis hebben gestaan van deze modellen, heb er veel praktijkervaring mee opgedaan en heb veel gepubliceerd over de relaties van deze modellen onderling en met andere modellen/methodes. Door middel van deze blogspot wil ik nog meer doen aan kennisverspreiding over deze modellen en hun samenhang.

Ik ga proberen ook een discussiedeel te maken in deze blog, waar u uw vragen kunt stellen. Publicaties zijn via de links of via links naar andere sites te downloaden.

Voor niet-Nederlanders is een Engelse versie gemaakt van deze site (zie links). De inhoud van beide sites is niet exact hetzelfde, omdat er voor de Nederlandstalige markt meer informatie voorhanden is.