Deze case beschrijft de inrichting van het functioneel beheer van de website en het intranet van organisatie <PPPP>. Het beheer werd grotendeels gedaan door ICT-beheerders, die onderhoud pleegden op de website als ze even tijd hadden. Content werd onregelmatig aangeleverd door gebruikers. Als er voldoende nieuws was, werd er een nieuwsbrief verstuurd aan medewerkers en relaties. Aan de website werd echter steeds meer interactiviteit toegevoegd en de online informatievoorziening verving steeds meer het offline gebeuren. Dat maakte het noodzakelijk het functioneel beheer van de website als regulier proces in te richten. Bovendien zou door het omzetten van offline communicatieprocessen naar online een aanzienlijke kostenbesparing gerealiseerd kunnen worden. De directie van <PPPP> besloot daarom over te gaan tot de inrichting van het proces functioneel websitebeheer in combinatie met een coachingstraject. Omdat het primaire doel communicatie is en veel van de activiteiten daarvoor uitgevoerd worden door de afdeling communicatie en voorlichting, treedt het functioneel beheer nu  primair op als demand organisatie naar de ICT-afdeling. Voor het functioneel beheer is de ICT-afdeling een single-point-of-contact. Zij onderhoudt de relaties naar de leveranciers van infrastructuur en software.

Cyclus 1: Aantrekkelijkheid van de website verhogen

De eerste cyclus, gericht op het verbeteren van de aantrekkelijkheid van de website en het intranet, werd gestart met een workshop van 1 dagdeel voor de afdeling communicatie, de beoogde functioneel beheerders, de twee huidige webmasters van de ICT-afdeling en de projectleider.
Allereerst werd een antwoord gezocht  op de vraag, wanneer  een veelvuldiger gebruik van de website door  de doelgroep voor de hand zou liggen.

• De website zou altijd een actuele informatiebron moeten zijn.
• Teksten op de website zouden  outside-in moeten worden geschreven (dus bekeken vanuit de behoefte van de doelgroep).
• De navigatie zou moeten verbeteren
• De interactie op de website zou verbeterd moeten worden (zowel online als offline).

Voorts werd met de deelnemers een eerste inventarisatie gemaakt, welke processen en mensen in de toekomst in elk geval gebruik zouden kunnen maken van de website, waarom ze dat zouden doen en onder welke condities zij de website als primair communicatiemedium zouden willen gebruiken.
Daarna kregen de deelnemers als ‘huiswerk’ de opdracht mee andere websites te bekijken en daarvan de sterke punten te noteren. Deze bevindingen waren bedoeld om te worden gebruikt als input voor het herontwerp van de website tijdens een brainstormsessie. Daarnaast werden bij potentiële partners die mogelijk via de website wilden aanbieden, wensen en eisen geïnventariseerd.
Tijdens de brainstormsessie die vervolgens werd gehouden, werd eerst een voorbeeldwebsite gekozen en aan de hand daarvan werd bekeken welke functionaliteiten van de huidige website weggelaten zouden moeten worden en welke nieuwe toegevoegd. Met dit in het achterhoofd werden op een brown paper met behulp van diverse kleuren post-its de verschillende soorten pagina’s ontworpen. Van deze pagina’s werd steeds een fotootje genomen, zodat de sessie niet opgehouden werd door het documenteren van de brainstorm. Op deze wijze ontstond een boom van informatiepagina’s met daarnaast een boom gericht op af te nemen services. Het verschil tussen het intranet en internet verviel door het definiëren van verschillende autorisaties. Er werd een tracking & tracing systeem gedefinieerd, om bezoekersgedrag te volgen, zodat beter ingespeeld zou kunnen worden op de behoeften van bezoekers. De brainstormsessie werd afgesloten met een instructie van een half uur over hoe content voor de website geschreven moet worden.
Vervolgens gingen de betrokkenen aan de slag in een pilot. De webmasters maakten met een ontwerper een eerste concept van de site, in hoofdzaak een assemblage van bestaande open source software functionaliteiten. Bestaande content werd geredigeerd en op de site geplaatst. Met een aantal aanbieders van content (campagnes) werden afspraken gemaakt over de levering van content en de rapportage van de reactie van bezoekers op deze content. De pilot duurde twee maanden. ZBC heeft tijdens deze cyclus op afroep ondersteuning geboden.

Cyclus 2: Inrichting van het functioneel beheer en ‘live’

Ook cyclus 2 werd gestart met een workshop, waaraan alle betrokken uit de eerste cyclus deelnamen.
Als eerste werden de problemen van alle betrokkenen geïnventariseerd in een standaard format:

• “Ik zou willen weten ………”
• “Hoe zorgen we ervoor dat ………”

Door gebruik van dit format was het mogelijk om eenvoudig een actie te formuleren, die alleen nog hoefde te worden toegewezen aan een actiehouder. De acties werden vervolgens toegewezen en gegroepeerd. Zo ontstond op natuurlijke wijze een projectteam inrichting functioneel beheer waarin belegd:

• redactie inclusief relatiebeheer content providers;
• ontwikkelen en organiseren campagnes of diensten ten behoeve van derden inclusief PR;
• beheer van de content van de website (plaatsen content, aanmaken formulieren, vindbaarheid, linkstructuur);
• servicedesk voor een soepele communicatie (telefonisch en online) en het afhandelen van de logistiek rondom campagnes;
• algehele coördinatie (financieel, demand management naar ICT en externe partijen, kwaliteit).

Alle betrokkenen zijn daarna aan de slag gegaan met het afhandelen van de actielijst. Voorts is de vernieuwde site live gegaan, waardoor ook een aantal campagnes en de response hierop uitgevoerd konden worden.
De valkuil in deze cyclus was, dat allerlei acties toch bij ZBC neergelegd zouden worden. Door de ondersteuning in deze fase te budgetteren kon dit worden voorkomen, zodat de gevonden oplossingen in ieder geval pasten in de <PPPP>cultuur. ZBC werd dan ook vooral gevraagd om plannen, ontwerpen en stukken te reviewen.

Cyclus 3: Project wordt proces

Cyclus 3 startte ook weer met een workshop, waarin de vorige cyclus werd geëvalueerd. Enkele belangrijke conclusies waren:

• Vooral op het hoofdkantoor is het gebruik van de website meer dan verdubbeld. Verwacht wordt dat diverse offline brochures vervangen kunnen worden door een online versie.
• Het bestaande open source CMS kan gemakkelijk uitgebreid worden met plug-ins, en hoeft daardoor voorlopig niet vervangen te worden.
• Het organiseren van online campagnes vergt aanzienlijk minder tijd dan eerdere offline campagnes, terwijl de response ongeveer gelijk gebleven is.
• De afdeling communicatie heeft ondanks de extra online inspanningen meer tijd gekregen. Ook hoeft minder vaak een externe partij ingeschakeld te worden om een campagne te promoten.

De slotconclusie was, dat nu de tijd rijp was om alle functioneel beheertaken die tot dan toe projectmatig werden opgepakt, te formaliseren tot een proces en te komen tot een afbakening van taken. De globale verdeling uit het vorige hoofdstuk (die op dat moment  nog niet echt duidelijk was) werd afgesproken. Ook werd een plan opgesteld om vooral alle medewerkers die niet het hoofdkantoor als primaire vestiging hadden, meer te betrekken bij het online gebeuren door waar mogelijk de communicatie te laten verlopen via webseminars en webmeetings. (Zie ook ‘Vergaderen, presenteren en samenwerken op afstand’.) Het medium webseminar zou tevens gebruikt gaan worden voor voorlichting aan derden over activiteiten en best practices van <PPPP>.
In de volgende maanden werden de processen beschreven in communicatieschema’s, om zo vast te leggen, wie waarvoor verantwoordelijk en bevoegd is en vooral om te voorkomen, dat response uitblijft en afspraken niet nagekomen worden.
In deze fase bleef de begeleiding van ZBC meest beperkt tot het geven van feedback op webseminars en het reviewen van procesbeschrijvingen en de dienstenportfolio.

Resultaat van de coaching

Nu, anderhalf jaar na afloop van dit traject, kan geconcludeerd worden dat online communicatie volledig geaccepteerd is binnen <PPPP>. Het gebruik van de website is verzevenvoudigd en vrijwel dagelijks wordt de webconferencing omgeving gebruikt voor vergaderen of samenwerken op afstand of voor presentaties. Dit is zelfs zo’n succes gebleken, dat de logistiek rondom dit proces (met behulp van KPN en ZBC) is geautomatiseerd.
De kosten van het gebruik van diensten via de website worden inzichtelijk gemaakt aan andere afdelingen door beprijzing van de diensten. Dit heeft het kostenbewustzijn van alle afnemers verhoogd en vele offline communicatie is vervangen door een veel goedkopere online variant en de kwaliteit en actualiteit van de informatievoorziening zijn toegenomen.

Download:         

Gerelateerde artikelen:

1. Casestudy Training Outsourcing werkplekbeheer
2. Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer
3. BiSL maakt functioneel beheer wel erg ingewikkeld

In deze case beschrijving gaat het om de selectie en implementatie van outsourcing van het werkplekbeheer (ca 100 werkplekken) van organisatie <PPPP>. Tot dan toe had <PPPP> een eigen computerruimte en het technisch beheer daarvan werd grotendeels gedaan door externe leveranciers, die op afroep kwamen opdraven. Dit leidde tot een matige service, veel irritatie als de verschillende leveranciers elkaar daarvan de schuld gaven, hoge kosten en uitstel van noodzakelijk preventief en adaptief onderhoud. Het serverpark was ook aan vervanging toe. De directie van <PPPP> besloot daarom over te gaan tot outsourcing van het serverpark en de werkplekken. ZBC heeft het outsoursingstraject gecoacht.

Cyclus 1: De leveranciersselectie

De eerste cyclus, gericht op het selectieproces, werd gestart met een workshop van 2 dagdelen voor het management, de functioneel beheerders en de projectleider.
Tijdens het eerste dagdeel werd eerst een beeld geschetst van wat wel en niet verwacht mag worden van outsourcing van werkplekbeheer. (Zie ook ‘Outsourcing van werkplekbeheer is meer dan kostenbesparing alleen’.) Daarnaast kwamen de afwegingen om wel of niet Europees aan te besteden aan de orde (zie ook ‘Hoe voorkomt u een Europese aanbesteding bij ICT-outsourcing?’) en de keuze voor het soort leverancier. (Zie ook ‘Alleen leveranciers die groot en sterk genoeg zijn, kunnen bij outsourcing denken aan Customer Intimacy, mits …’). Tijdens  het tweede dagdeel werd vooral ingegaan op het selectieproces zelf. (Zie ook ‘Selectie leverancier voor outsourcing werkplekbeheer’.)
Vervolgens heeft de projectleider van <PPPP> in een aantal interviews de behoeften geïnventariseerd en in samenspraak met ZBC uiteindelijk 15 knock-outcriteria bepaald. Deze zijn voorgelegd aan de directie en met een beetje passen en meten werd uiteindelijk een lijst met 17 knock-outcriteria vastgesteld. Deze zijn verpakt in een request for proposal (RfP) en naar een zestal leveranciers gestuurd.
Tijdens cyclus 1 werd een aantal keren de mening van ZBC gevraagd. Ook werd ZBC gevraagd om voorbeelden van documenten. In de meeste gevallen kon ZBC aan dit verzoek voldoen. Verder heeft ZBC een review uitgevoerd op de RfP.

Cyclus 2: De keuze van de leverancier en de oplossing

Ook de tweede cyclus werd gestart met een workshop voor het selectieteam. Vragen die tijdens deze workshop aan de orde kwamen:

• Hoe moeten antwoorden van leveranciers worden geïnterpreteerd?
• Hoe kan de eerste selectie uitgevoerd worden, zodanig dat er nog twee leveranciers en hun oplossingen overblijven?
• Wat moet ter tafel komen in het gesprek met die kandidaten?
  Dat gesprek gaat allereerst over wie de contractpartij is (niet de holding maar de business unit, mits deze een zelfstandige rechtspersoon is) en over wat de hiërarchie moet zijn in de documenten, waaruit de SLA bestaat. De algemene leveringsvoorwaarden van de leverancier staan zeker niet bovenaan. En verder gaat dit gesprek over het inregelen van het technisch applicatiebeer binnen het outsourcingscontract. Weliswaar bieden de meeste leveranciers dit niet standaard aan. Maar bij <PPPP> gaat het er uiteraard om verlost te worden van het gekibbel tussen leveranciers. <PPPP> wil dus een single-point-of-contact bij problemen en incidenten als de informatieverwerking op de werkplek verstoord wordt.

Vervolgens heeft het selectieteam de selectie uitgevoerd en met de leveranciers gesproken. Op verzoek van <PPPP> heeft ZBC deelgenomen aan die gesprekken en aan de evaluatie om tot een keuze te komen. Verder heeft ZBC een review uitgevoerd op het voorgestelde contract en verbeterpunten aangereikt.

Cyclus 3: De implementatie van het vernieuwde werkplekbeheer

Ook de derde cyclus werd weer gestart met een workshop. Ditmaal voor het management, de functioneel beheerders en de projectleider van zowel <PPPP> als van de gekozen leverancier. Er werd vooral ingegaan op aspecten waarvoor <PPPP> verantwoordelijk bleef en op wat nieuw was. Aandachtspunten waren o.a. 

• sanering van verouderde software (van de 85 applicaties op de server bleven nog 19 over) en hoe hiermee om te gaan (gewoon weggooien van allerlei software met nog slechts enkele gebruikers was geen optie);
• implementatie van een aantal noodzakelijke procedures (zie ook ‘BiSL maakt functioneel beheer wel erg ingewikkeld’);
• opstellen van een gedragscode (zie ook ‘Vervang uw gedragscodes door één ethische code’);
• opschonen van de honderden scripts om overzichten te maken vanuit de bedrijfsapplicaties;
• inrichting van een pilot om de acceptatietest uit te voeren;
• migratie naar ‘thin clients’, met behoud van een aantal ‘fat clients’.

Ook hierbij werd weer in veel gevallen de input geleverd door ZBC en aangepast door <PPPP>.
Daarnaast werden de projectleider van <PPPP> en twee functioneel beheerders getraind om de rol van demand-manager te kunnen vervullen naar derde partijen. Ze werden tevens verantwoordelijk voor de interne controle op de nieuwe procedures en de gedragscode en voor de rapportage hierover aan de directie.

Resultaat van de coaching

Nu, een jaar na afloop van dit traject, kan geconcludeerd worden dat de angst die bestond bij >PPP> om met een grote leverancier in zee te gaan, ongegrond is gebleken. Juist die leverancier  bleek in staat naar andere toeleveranciers zaken vloeibaar te maken, die eerder in beton waren gegoten. De service aan de gebruikers is volgens afspraak. Weliswaar niet op basis van ‘het onmogelijke doe we direct; wonderen duren iets langer’. Maar onacceptabele wachttijden komen niet meer voor. De kosten per werkplek zijn met circa 10% verminderd. Dit was weliswaar minder dan gehoopt, maar van meet af aan is gesteld, dat een betere service en continuïteit belangrijker zijn dan kostenbesparing.

Download:         

Gerelateerde artikelen:

1. Casestudy Training functioneel beheer website
2. Outsourcing van werkplekbeheer is meer dan kostenbesparing alleen
3. Selectie leverancier voor outsourcing werkplekbeheer

1. Meer aandacht voor functioneel beheer
2. Oplossingen die niet werken
3. Functioneel beheer is wel de oplossing
4. Houdt functioneel beheer simpel

1. Meer aandacht voor functioneel beheer

De aandacht voor functioneel beheer groeit in veel organisaties aanzienlijk, en terecht. Voor consultants een belangrijke reden om een volledige methodiek met alles erop en eraan te verzinnen, zodat zij in elk geval kunnen inspelen op (of was het meeprofiteren van?) de behoefte van organisaties. En dus zag als snel BiSL het licht. Met verbijstering vragen veel functioneel beheerders zich nu af, hoe zij in het verleden ooit hun taak hebben kunnen vervullen. Maar in feite is er niets nieuws onder de zon. In dit artikel willen we weer teruggaan naar de essentie van functioneel beheer. Ook nu is daar nog steeds geen ingewikkelde methodiek voor nodig.
Twintig jaar geleden hanteerden we al modellen van de ontwikkeling van de business alignment van ICT met een drietal fasen, te weten het creëren van:   

1. Technisch hoogwaardige ICT-oplossingen;
2. ICT oplossingen die gebruikers vragen;
3. ICT oplossingen die gebruikers nodig hebben.

1.1 Fase 1: Technisch

Onderstaand plaatje geeft fase1 weer, de fase waarin technisch hoogwaardige ICT-oplossingen worden gecreëerd:   

Figuur1: Technisch hoogwaardige ICT-oplossingen

Er staat tussen de gebruikers en de automatiseerders prominent een muur. Over die muur gooien de gebruikers eisen, wensen en problemen, waarna de automatiseerders gaan nadenken en een technisch perfecte oplossing proberen te maken. Helaas moeten vervolgens de gebruikers verzuchten: ‘Het is misschien wel een schitterende oplossing, maar helaas niet voor ons probleem’.
Uiteraard vond het management dit niet acceptabel. Het verordonneerde, dat de zeggenschap bij de gebruikers kwam te liggen. Dan zouden deze misverstanden niet meer kunnen optreden. Kortom, de organisatie migreerde naar fase 2.   

1.2 Fase 2: ICT-oplossingen die gebruikers vragen

Ook fase 2, de fase waarin ICT-oplossingen werden gecreëerd die gebruikers vragen, kunnen we weer in een plaatje weergeven:   

Figuur2: ICT-oplossingen die gebruikers vragen

De gebruikers denken na, verzinnen een schitterende oplossing en gooien vervolgens hun ideeën over de muur. De automatiseerders worden in de rol van ober gedwongen en serveren dat wat de klant wil. Dat het technisch niet meer kan kloppen, dat kan de gebruikers moeilijk worden verweten. De meest draconische systemen zagen het licht en de onderhoudsinspanningen namen exponentieel toe, om er maar voor te zorgen, dat de gecreëerde wangedrochten bleven werken. Kortom, het was volstrekt helder, dat dit ook niet de oplossing was. Het echte probleem was natuurlijk de muur. Tijd voor fase 3.   

Fase 3: ICT-oplossingen die gebruikers nodig hebben

Fase 3 kunnen we als volgt in een plaatje weergeven:   

Figuur3: ICT-oplossingen die gebruikers nodig hebben

De muur is afgebroken. De gebruikers communiceren met de automatiseerders om samen tot een oplossing te komen, die voor de business functioneel ideaal is en technisch gezien perfect. Helaas wordt dit ideaalbeeld zelden bereikt. Ook nu is er nog vaak niet sprake van een goede communicatie tussen beide partijen. Dit wordt meestal veroorzaakt door allerlei waanideeën, waardoor een echte samenwerking, zeker bij de planvorming, wordt verstoord.   

2. Oplossingen die niet werken

2.1 Door aanbesteden blijft de muur bestaan

Tegenwoordig is de trend, dat ICT-werkzaamheden moeten worden aanbesteed. In feite gaan we daarmee terug naar fase 2, de fase waarin oplossingen gemaakt worden, die gebruikers vragen en geen oplossingen die gebruikers nodig hebben. Dat is de belangrijkste reden, dat zoveel overheidsprojecten ook nu nog de mist in gaan (minder functionaliteit, hogere kosten dan was afgesproken en uitloop). (Zie ook ‘Europees aanbesteden leidt vaak tot minder marktwerking en hogere prijzen’.) Het is dus geen kwestie van onkunde van één van beide partijen. Het is een kwestie van een afgesproken oplossing, waarvan tijdens het project vaak duidelijk wordt, dat die een functioneel of technisch wangedrocht is.   

2.2 Een SLA is niet zaligmakend

Om een goede samenwerking mogelijk te maken, moeten er natuurlijk overeenkomsten gesloten worden tussen klanten en leveranciers. Maar wanneer u denkt, dat in een SLA staat wat u precies voor elkaar moet doen, gaat het goed fout. Want dat is de functie van een SLA helemaal niet. Als u een meerjarenovereenkomst sluit, dan mag u ervan uitgaan, dat de samenwerking steeds beter gaat verlopen en dat er een verbetercyclus ontstaat. De SLA regelt deze samenwerking en niet de prestatie. Het is een vangnet voor als er een situatie ontstaat, waarin u er in overleg niet meer uitkomt. (Zie ook ‘ICT-service management: contact is belangrijker dan contract’.) Het letterlijk nemen van een SLA betekent terugvallen naar fase 2 of zelfs naar fase 1. Dat wilt u uiteraard niet.   

2.3 Gebruik van standaardpakketten

Tegenwoordig worden binnen organisaties steeds meer pakketten geïmplementeerd. Oppervlakkig gezien lijkt dit een goed idee. In de praktijk leidt het echter tot allerlei ongewenste bijwerkingen:   

• Leveranciers creëren een lock-in voor hun diensten, zodat een steeds grotere afhankelijkheid ontstaat van één of enkele ICT-leveranciers.
• Marktleiders houden zich nauwelijks aan gedefinieerde open standaards. Hierdoor houden ze de lock-in in stand. (Zie ook ‘Bedrijfstype, en niet functionaliteit, bepalend bij ERP-selectie’.)
• Open Source Software is vaak nog onvoldoende professioneel om een serieus alternatief te vormen. Maar moeten we blij zijn met Google als de opvolger voor Microsoft en SAP?

Daarnaast worden pakketselecties vaak op een verkeerde manier uitgevoerd. Een ieder wordt gevraagd of hij nog aanvullende eisen en/of wensen heeft. Op grond daarvan wordt een waslijst opgesteld voor de Request for Proposal (RfP). De winnaar is dan vanzelfsprekend het pakket met de meeste functionaliteit. Dat is echter vaak niet het pakket dat een organisatie echt nodig heeft. (Zie ook ‘ERP-selectie en -implementatie: eerst van een muis een olifant maken en daarna omgekeerd’.) Het gaat dus om goed demand management. Met de in dit hoofdstuk genoemde maatregelen wordt dat niet afgedekt.   

3. Functioneel beheer is wel de oplossing

Als een organisatie op een effectieve wijze wil samenwerken met haar ICT-leveranciers, dan is het dus nodig, dat de muur gesloopt wordt en blijft. Dat betekent dat er mensen beschikbaar moeten zijn, die zowel de bedrijfsprocessen als de ICT begrijpen. Vaak zijn dit de functioneel beheerders. Zij vormen de ‘gaten’ in de muur, waardoor communicatie mogelijk is. Met een gat wordt niet een veredeld doorgeefluik bedoeld. De functioneel beheerders moeten naar beide kanten het demand management kunnen invullen en naar beide kanten namens de andere partij kunnen onderhandelen. In feite zijn de functioneel beheerders de vleesgeworden SLA tussen de business en de ICT.
BiSL identificeert in deze zin grotendeels de processen die van belang zijn voor deze rol van functioneel beheer. De uitwerking van die processen maakt BiSL echter wel heel ingewikkeld.
De basis van functioneel beheer vormen de onderlinge afspraken voor samenwerking, waarbij beide partijen erop kunnen rekenen, dat deze nagekomen worden. Dit wordt op tactisch niveau beschreven. Deze stabiele toestand kan op twee manieren worden verstoord, namelijk door:   

• een incident, waardoor één van beide partijen afspraken niet nakomt.
  Dit incident moet verholpen worden, waarbij het uitgangspunt moet zijn:’de vervuiler betaalt’. Deze incidentafhandeling wordt door BiSL marginaal besproken.
• een wijzigingsvoorstel ingediend door één van de partijen,
  dat wil zeggen één van de partijen wil een aanpassing van de afspraken.
  De impact van de wijziging moet worden bepaald en na goedkeuring door beide partijen worden afspraken aangepast en wordt de wijziging gerealiseerd en geaccepteerd. In feite gaat het hele operationele beheer van BiSL (wijzigingenbeheer) inclusief alle subprocessen over dit issue.

Een uitvloeisel van het wijzigingenbeheer is de inkoopfunctie die het functioneel beheer moet invullen. Dit niet in de betekenis van inkoper (afsluiten van transacties). Het functioneel beheer moet de behoefte specificeren en vervolgens regelen, dat er ingekocht wordt, ongeveer zoals de afdeling P&O verantwoordelijk is voor het aantrekken, het begeleiden en het evalueren van het functioneren van medewerkers. De harde kant van het inkopen ligt vaak bij de ICT-afdeling of eventueel bij een externe partij. (Zie ook ‘Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens’.)
Tenslotte moet de dienstverlening (wederzijds) geëvalueerd worden. In feite gaat het hier om de interne control functie, waarin bekeken wordt of de procesafspraken ook inderdaad nageleefd zijn. Binnen ITIL vinden we deze functie grotendeels binnen het proces problem management. Maar ook aan de kant van het functioneel beheer zou dit proces ingericht moeten zijn, waarbij functioneel beheer niet als uitvoerder maar als bewaker van de ICT-dienstverlening en alles wat hier mee samenhangt rapporteert aan het gebruikersmanagement, dat uiteraard eindverantwoordelijke blijft.   

4. Houdt functioneel beheer simpel

De hoofdtaak van functioneel beheer is het in stand houden van de alignment tussen de business en ICT, niet als inkoper, jurist, techneut of controleur, maar vooral als procesbegeleider van de samenwerking en het onderlinge begrip. De functioneel beheerders voorkomen dagelijks, dat de muur tussen gebruikers en ICT weer opgeworpen wordt. Functioneel beheer is niet de buffer tussen twee strijdende partijen, maar zorgt ervoor, dat beide partijen hun gezonde verstand blijven gebruiken. (Zie ook ‘Valkuilen functioneel beheer volgens BiSL’.) Miscommunicatie mag niet leiden tot regeldrift, juridisch geneuzel en toezichthouders. ICT-dienstverlening is mensenwerk en dit kan alleen verbeteren door tweezijdig processen beter op elkaar af te stemmen. Hiervoor zijn eenzijdige methodes als BiSL of ITIL meestal niet de oplossing. (Zie ook ‘Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 1′.) Vaak is het voldoende om een duidelijk communicatiemodel te hebben voor de koppelvlakken, zoals in het artikel ‘Blauwdruk processen IT-organisatie’ wordt uitgelegd aan de hand van het volgende plaatje:   

Figuur4: Communicatiemodel voor de koppelvlakken

 Het is vooral van belang goede afspraken te maken over deze koppelvlakken. Niet op basis van wat de methode voorschrijft, maar op basis van wat handig is voor de samenwerking en wat aansluit op de aanwezige competenties. Daarnaast is het noodzakelijk het volgende model, waarin de processen wijzigingsbeheer, incidentbeheer en probleembeheer zijn ingevuld, in te vullen voor het geheel aan ICT-dienstverlening. Van belang is om in overleg te bepalen wie welke rol invult.
Vaak kan de uitleg over en het invullen van deze samenwerkingsmodellen en bijbehorende procedures in enkele dagen plaatsvinden (zie ook ‘Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer’) en zijn complexe trajecten, die vaak het gevolg zijn van de implementatie van BiSL of ITIL, niet nodig. Ook voor alle betrokkenen die wel bekend zijn met ITIL of BiSL is het een uitstekende werkwijze. De aanpak is tenslotte gebaseerd op beide methodieken.
Laat u zich dus niet verleiden tot de invoering van methodieken of het optuigen van veranderingstrajecten die niet zijn afgestemd op de huidige werkwijze. Neem uw huidige werkwijze als uitgangspunt en versterk hierin de rol van het functioneel beheer. In de volgende casestudies kunt u lezen hoe u zo’n traject kunt opzetten met minimale inspanningen en kosten:  

• Casestudy Training functioneel beheer website;
• Casestudy Training Outsourcing werkplekbeheer.

Op deze wijze kunt u wellicht de oplossing vinden voor de spagaat waarin u gedwongen wordt: enerzijds besparen op uw kosten en anderzijds het leveren van meer service.  

Herziene versie 18 maart 2010

Download:         

Gerelateerde artikelen:

1. Afbakening taken functioneel beheer baseren op behoefte
2. Valkuilen functioneel beheer volgens BiSL
3. Samenwerking tussen gebruikers en de ICT-afdeling door functioneel beheer

1. Functioneel beheer verschilt per bedrijf
2. Zelf het wiel uitvinden?
3. Cursus functioneel beheer, ICT- en applicatiebeheer
4. Mogelijke issues

1. Functioneel beheer verschilt per bedrijf

Op papier lijkt het zo gemakkelijk en aantrekkelijk: het functioneel beheer, ingericht volgens BiSL, als regisseur van de ICT-functie, zodat de bewaking van de eisen en wensen van gebruikers geborgd is en de ICT’ers zich verzekerd weten van sparringpartners die deskundig zijn en ook de belangen van de ICT begrijpen.
De praktijk is echter vaak weerbarstig. (Zie ook ‘Valkuilen functioneel beheer volgens BiSL’.) De ICT’ers hebben hun processen al lang ingericht volgens ITIL en ITIL sluit vaak allerminst aan op BiSL. De gebruiker heeft zijn plek zwaar bevochten en is niet bereid zijn bevoegdheden zomaar op te geven. Functioneel beheer volgens BiSL wordt hier maar wat tussen gefrommeld en dan vaak uitsluitend op operationeel niveau en het met elkaar in balans brengen van de methoden krijgt meestal geen prioriteit. (Zie ook ‘Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 1′.)
De functioneel beheerder treedt vaak op als een leeuwentemmer zonder zweep; hij moet de leeuwen (gebruikers en ICT’ers) vriendelijk vragen om netjes hun kunstjes te doen. Als dan blijkt, dat de leeuwen in het verleden een grote aversie tegen elkaar hebben opgebouwd, dan wordt zijn hoofdtaak al gauw het uit elkaar houden van de vechtende partijen door vanaf twee kanten de klappen op te vangen. En daar de functioneel beheerders in de meeste organisaties toegewezen zijn aan afdelingen waar ze eigenlijk niet thuishoren, is hiërarchische escalatie van de problematiek ook zinloos; het management heeft tenslotte wel meer aan het hoofd. (Zie ook ‘Afbakening taken functioneel beheer baseren op behoefte’.)
Kortom, hoe je functioneel beheer soepel laat werken, verschilt per organisatie.

2. Zelf het wiel uitvinden?

Gelukkig is het probleem van maatwerk niet zo groot. Functioneel beheer is altijd nodig geweest, ook al wisten we vroeger nauwelijks dat het zo heette. Het was vaak een rol die per situatie ingevuld werd en daarom zijn er ervaringen genoeg met functioneel beheer.
Vijftien jaar geleden schreven we al over deze problematiek. (Zie ‘Blauwdruk processen IT-organisatie’.) We introduceerden het verhaal over de koppelvlakken tussen gebruikers en ICT en de koppelvlakken tussen ontwikkeling en in stand houden. En wat we nu functioneel beheer en functioneel applicatiebeheer noemen, zat toen in hoofdzaak vervlochten in de koppelvlakken.

Figuur 1: Koppelvlakken tussen gebruikers en ICT

De probleemstelling en de oplossingen zijn echter nog steeds hetzelfde. Het gaat er niet om waar de koppelvlakken precies liggen. Het gaat erom dat hierover goede afspraken gemaakt worden, waarbij de ervaringen van de betrokkenen maximaal benut worden. Een massale implementatie van ITIL of BiSL leidt alleen maar tot veel bureaucratie en dus irritatie.
Het model dat we destijds introduceerde voor de inrichting van ICT beheer (zie ‘Inrichtingsmodel IT-beheer’) is dan ook nog steeds bruikbaar; het probleem van functioneel beheer is immers nog steeds een probleem van communicatie, verantwoordelijkheden en bevoegdheden. Wel is het instrumentarium deels vernieuwd.
Op onze site vindt u de best practices van de organisatie van ICT van zeker 15 jaar en bekeken vanuit diverse invalshoeken (functioneel/technisch; strategisch/tactisch/operationeel; mate van volwassenheid), methodieken (ITIL/BiSL/ASL/Prince2/ SDM/RAD) en organisatiemodellen. Vrijwel al deze best practices zijn nog steeds uitstekend bruikbaar als je maar weet in welke situatie en in welke samenhang deze best practices het best gebruikt kunnen worden.
Het inrichten van functioneel beheer is dan ook vaak niet meer dan het kiezen van de goede en vooral ook passende bouwstenen. En dat begint niet bij de theorie van de methodiek, maar bij uw concrete behoefte en situatie.

3. Cursus functioneel beheer, ICT- en applicatiebeheer

Dat heeft uiteraard impact op de opleiding van de betrokkenen. Natuurlijk kunt u op zoek gaan naar een algemene cursus BiSL of een standaard cursus ‘Organisatie van ICT’. Wat in deze generieke cursussen geleerd wordt, sluit echter zelden aan bij uw specifieke situatie en behoefte. Het geleerde in de cursus kan veelal niet toegepast worden en dat leidt tot frustratie. Ook voor onze generieke cursus ‘Organisatie functioneel beheer en ICT-beheer’ voor middelgrote en kleinere organisaties’ bleek dit te gelden.
Daarom komen we nu met een bedrijfsspecifieke aanpak. We hebben het totale beheerlandschap in kaart gebracht. In een workshop van enkele uren met de opdrachtgever of de contactpersonen van de klant presenteren we het totale landschap en bepalen dan samen welke best practices passen op de betreffende organisatie, eventueel opgesplitst naar doelgroepen. Dit worden de opleidingsmodules. Het geleerde kan desgewenst direct vastgelegd worden in standaards en procedures, maar dat is de interne keuze en de interne activiteit van de organisatie. Wel kunnen wij een dergelijk traject coachen.

3.1 Doel en afbakening

Kort gezegd gaat het om het op een pragmatische manier effectiever en efficiënter organiseren van de processen rond ICT. De totale levenscyclus omvat:

• behoeftebepaling,
• planvorming,
• aanschaf of ontwikkeling,
• implementatie,
• functioneel en technisch (applicatie)beheer.

Het grootste deel hiervan heeft u op orde, dus daar hoeven we ons niet druk om te maken. Het traject start daarom met een kort voorgesprek waarin twee aspecten aan de orde komen:

• De contactpersoon of opdrachtgever geeft aan welke problemen er zijn en wat de behoeften zijn.
• Wij laten vervolgens zien welke best practices we hiervoor hebben ontwikkeld en wat we dus voor u kunnen betekenen.

Als u een globaal beeld wilt krijgen van hoe die landkaart eruit kan zien, dan nodigen we u graag uit voor ons webseminar ‘Organisatie ICT-beheer voor middelgrote organisaties’.

3.2 Aanpak en uitvoering groepstraining-on-the-job

Onze aanpak voor groepstraining-on-the-job is als volgt.

• Per opleidingsmodule wordt een ‘probleemeigenaar’ aangewezen. Deze probleemeigenaar heeft belang bij de oplossing en de bevoegdheden om hierover afspraken te maken met andere betrokkenen. Dit kan een ICT-manager zijn, een functioneel beheerder of een lijnmanager. Met deze probleemeigenaar worden afspraken gemaakt over de te realiseren doelen.
• In een workshop van één of twee dagdelen wordt het onderwerp behandeld, worden best practices aangereikt en keuzes gemaakt, waarbij afspraken gemaakt wordt over de rollen van alle betrokkenen.
• Met de probleemeigenaar worden de uitkomsten geëvalueerd en wordt afgesproken hoe we de resultaten in concrete acties en een actieplan kunnen vertalen.
• De acties worden intern uitgevoerd en vervolgens door de probleemeigenaar geconsolideerd.

Uiteraard kunnen we coaching bieden bij het uitvoeren van de acties, veelal door het leveren van sjablonen of door het uitvoeren van reviews. Deze coaching vindt meestal op afstand plaats.

3.3 Evaluatie en beheersing

Periodiek is er een afstemmingsgesprek met de contactpersoon of opdrachtgever, waarin de resultaten besproken worden en vervolgafspraken worden gemaakt.
De onderwerpen worden vooraf goedgekeurd door de contactpersoon of opdrachtgever. Hetzelfde geldt voor het afgesproken actieplan.

3.4 Condities en randvoorwaarden

Tarieven:

• Werkzaamheden bij u op locatie: € 125,-
• Werkzaamheden op locatie van ZBC: € 110,-
• Het voorgesprek is gratis.

Omdat alle werkzaamheden op afspraak en afroep plaatsvinden (nul uren contract), is dit traject voor u gemakkelijk te beheersen. In de praktijk hebben deze trajecten 4 uur tot 8 weken in beslag genomen.

3.5 Meer weten

Is uw ICT-dienstverlening verder dan ‘het onmogelijke doen we direct; wonderen duren iets langer maar we beloven niets’, maar nog niet vastgeroest in procedures, dan past deze opleiding waarschijnlijk goed bij u. Wilt u meer weten over onze groepstraining-on-the-job, dan kunt u bellen met 0318 641 898 of reageren via het reactieformulier.

3.6 Case study

Een voorbeeld van een dergelijk traject kunt u lezen in Casestudy Training Outsourcing werkplekbeheer

4. Bijlage: Mogelijke issues

In principe komen alle onderwerpen in onze ICT-kennisbank in aanmerking voor de groepstraining-on-the-job. Voor de hand liggende onderwerpen kunnen zijn:

Blauwdruk processen IT-organisatie

Een beschrijving van de proces architectuur van een IT-organisatie in relatie tot haar omgeving.

Voorbeeld opzet handboek voor ICT kwaliteit deel 1 (2 en 3)

Dit praktijkvoorbeeld van een kwaliteitshandboek publiceren wij in drie delen. Het handboek is uitstekend te combineren met een watervalmethode voor systeemontwikkeling en dus met outsourcing, met Prince 2 en met ITIL.

ICT en functioneel beheer steeds meer logistieke processen

Als ICT niet je core business is, moet je niet eens willen investeren in functioneel beheer en ICT-beheer of in hardware of software. Het is gewoon een facilitaire dienst zoals schoonmaak, vervoer, catering of security dat ook zijn. Dat doe je ook niet zelf.

Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 1

Beschrijving van knelpunten, oplossingen en alternatieven als deze drie frameworks (BiSL, ASL en ITIL) naast elkaar geïmplementeerd worden.

Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens

ICT  is mateloos complex geworden. Als ICT niet je core business is, moet je ICT dan ook uitbesteden aan partijen voor wie de beheersing van complexiteit dagelijks werk is. Pas dan krijgen ook gebruikers in middelgrote organisaties de service die ze verdienen.

ICT-service management: contact is belangrijker dan contract

De gemiddelde service manager is meestal een goed opgeleide en goed gebekte techneut, die zich niet laat  ondersneeuwen door gebruikers en business managers. Als het echter de intentie van de ICT-afdeling is haar klanten tevreden te stellen, dan zijn andere vaardigheden nodig.

Inrichtingsmodel IT-beheer

Hoe ITIL te implementeren voor een betrouwbare en flexibele IT-dienstverlening, gebruik makend van moderne bedrijfskundige principes en zonder te verzanden in een bureaucratie.

Besparingen door gebruik van professionele Service Level Agreements – SLA’ s

Beter goed gejat dan slecht verzonnen; dit geldt zeker bij het opstellen van een SLA. De meeste checklists zijn gemaakt voor complexe omgevingen en opgebouwd uit meerdere Service Level Agreements en geven veel overhead. In dit artikel meer over de valkuilen van deze werkwijze.

Valkuilen functioneel beheer volgens BiSL

Functioneel beheerders zijn niet te benijden. Ze heten de regisseurs van de informatievoorziening te zijn, maar dat geldt alleen in het weekend, als business en ICT er niet zijn. Ook BiSL is niet het gewenste breekijzer. Het is gebaseerd op een aantal aannames die in de praktijk vaak onjuist blijken te zijn.

Projectinrichting en opdrachtbeheer

De basis voor een gezond project is een goede samenwerking. Voorwaarde hiervoor is helderheid over de rollen, die vervuld moeten worden en de hierbij horende verantwoordelijkheden en bevoegdheden.

Opdrachttypen voor projecten

Afhankelijk van de fase, waarin een project verkeert, is er een andere verdeling van verantwoordelijkheden en bevoegdheden nodig. Via gedefinieerde opdrachttypen is dit eenvoudig te realiseren.

Waarom veel organisaties niet met projecten kunnen omgaan

Projectmatig werken is zo gewoon geworden, dat we eigenlijk niet eens meer nadenken over hoe we het moeten doen en vooral niet over waarom we het zouden moeten doen. In dit artikel meer over het hoe en waarom van projectmatig werken, over de rol van de projectmanager en over de verdeling van verantwoordelijkheden en bevoegdheden, zodanig dat projectmatig werken beheersbaar blijft.

Kwantitatieve risicoanalyse IT-projecten

U weet ongetwijfeld dat veel projecten de mist ingaan. Vaak is dit een kwestie van opportunisme, waarbij risico’s vanwege het ’superieure team’ gebagatelliseerd worden. Natuurlijk is de kwaliteit van mensen van belang. Maar het invullen van de randvoorwaarden voor het project levert toch meer garantie voor succes. In dit artikel meer over de uitvoering van een kwantitatieve IT-project risicoanalyse.

Selectie leverancier voor outsourcing werkplekbeheer

Vaak wordt de selectie van een leverancier voor outsourcing van werkplekbeheer gedaan aan de hand van een waslijst aan eisen en wensen. Van veel daarvan zou u zich moeten afvragen wat de toegevoegde waarde ervan is. U kunt daarom beter kiezen voor een beperkt aantal knock-out criteria die er werkelijk toe doen.

Outsourcing van werkplekbeheer is meer dan kostenbesparing alleen

Voor de meeste ICT-organisaties is het niet rendabel om zelf over ICT-competenties en infrastructuur te beschikken. Outsourcing met als doel het just-in-time inkopen van dergelijke diensten geeft de gebruiker vaak een veel betere prijs-prestatieverhouding.

Recessie dwingt ICT-bedrijven tot herziening SWOT-analyse

Iedere bedreiging is tevens een kans. Dat geldt zeker in 2009, nu niet alleen de technologie zich ontwikkelt, maar vooral ook de markt verandert.

Download:         

Gerelateerde artikelen:

1. Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 2
2. Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 1
3. BiSL maakt functioneel beheer wel erg ingewikkeld

1. ICT heeft bruggenbouwers nodig
2. Wie wil nog zelf het beheer doen?
3. De wereld van de gebruiker
4. ICT-beheer is logistiek 

1. ICT heeft bruggenbouwers nodig

Eigenlijk is het diep triest dat de ICT-wereld nog altijd gebukt gaat onder kinderziekten, terwijl andere branches die al lang overwonnen hebben. (Zie ook ‘ICT-bedrijven zijn uitblinkers in het leveren van onprofessionele services’.)
Net als alle nieuwe bedrijfsmiddelen was automatisering zo’n vijftig jaar geleden alleen weggelegd voor een aantal liefhebbers die zelf alle know-how over techniek en programmeren in huis hadden om die eerste computers iets te laten doen. Maar de tijd heeft niet stil gestaan. Hardware en software zijn steeds intelligenter en bruikbaarder geworden en steeds meer gaan presteren. Veel ICT’ers zijn echter niet uit hun ivoren toren gekomen en zijn daardoor stil blijven staan.
Als we het beeld zouden gebruiken, dat ICT u over een rivier moet brengen, dan ziet het tegenwoordige plaatje er als volgt uit:

Figuur1: ICT als 'stepping stones'

 De doorwaadbare plek in de rivier uit het verre verleden is vervangen door een serie stepping stones en door van steen tot steen te springen kunt u tegenwoordig bij het oversteken van de rivier met een beetje mazzel uw voeten droog houden. Dat echter een brug een veel effectievere verbinding is tussen de oevers van een rivier dan een aantal stepping stones, en dat een brug veel prettiger is in het gebruik, dat is ICT’ers ontgaan bij hun zoektocht naar steeds nieuwe doorwaadbare plaatsen en het leggen van stepping stones. U kunt de overkant van de rivier toch met droge voeten bereiken via de stenen, zo redeneren ze.
Maar wat u wilt, is niet primair die rivier oversteken. U wilt van A naar B. En toevallig ligt tussen A en B een rivier. Als u echter van A naar B gaat, dan wilt u niet merken dat u daarbij een rivier oversteekt. Op de snelweg van uw bedrijfsprocessen gaat u ervan uit, dat er een brug gebouwd is. Natuurlijk snapt u, dat die brug dan beheer en onderhoud nodig heeft. Maar daar wilt u zich niet druk over hoeven maken.
Helaas, in ICT-land zijn bruggenbouwers schaars.

2. Wie wil nog zelf het beheer doen?

De kern van een comfortabel ICT-gebruik is het beheer, zo lezen we overal, onder meer ook op deze site. En dat is waar voor organisaties waarvoor ICT-toepassingen ‘core business’ zijn, zoals ICT-bedrijven of gegevensverwerkende industrieën als banken, verzekeraars en centrale overheden. Voor dit soort organisaties is ICT de belangrijkste productiefactor en kan het lonen de ontwikkeling en het beheer zelf uit te voeren. (Zie ook ‘Blauwdruk processen IT-organisatie’.)
Vanuit het perspectief van die organisaties is ICT-beheer weer te geven als in bijgaand plaatje (te lezen van rechts naar links):

Figuur 2: ICT-beheer vanuit het perspectief van de ICT-bedrijven

 Het kloppend hart wordt gevormd door de technische infrastructuur met de centrale servers, de databases en de generieke software (met uiteraard alle beheervelden) waarop de bedrijfssoftware draait met per applicatie de eigen applicatiebeheerders, soms nog netjes opgedeeld in functioneel beheerders en technisch beheerders. (Zie ook ‘Organisatie en inrichting functioneel applicatiebeheer’.) Voorts wordt de fysieke werkplek van de gebruikers inclusief de communicatie ondersteund met desktops, PDA’s, telefonie, printers enzovoort, uiteraard ondersteund door eerstelijns en tweedelijns support via de onvermijdelijke operationele ITIL-processen. Aan de buitenkant zitten natuurlijk in veel gevallen nog de gebruikers. Er wordt echter steeds meer naar gestreefd daarvan zo veel mogelijk weg te automatiseren. Want dat doet men, als ICT inderdaad de belangrijkste productiviteitsfactor is in een bedrijf en ‘goed is goed genoeg’ een te laag ambitieniveau is.

3. De wereld van de gebruiker

De wereld van de gebruiker in organisaties waar ICT geen ‘core business’ is, ziet er echter geheel anders uit. De gebruiker in zo’n organisatie maakt voor zijn activiteiten gebruik van de facilitaire infrastructuur en diensten van het bedrijf, variërend van vervoer, catering, security, klimaat, meubilair tot ICT. Als er iets niet werkt, dan belt de gebruiker de facilitaire dienst. Die regelt dat er iemand komt om het te repareren, meestal van buitenaf. Daarnaast wordt opdracht gegeven voor preventief beheer. Hoe dat allemaal is geregeld, interesseert die gebruiker nauwelijks, als hij maar effectief gebruik kan maken van alle facilitaire en ondersteunende voorzieningen. Hooguit wil de gebruiker bij aanschaf van nieuwe middelen inspraak hebben in de eisen die gesteld worden aan de te leveren dienst.

Figuur 3: ICT-beheer vanuit het perspectief van de gebruiker

 Merkwaardig is dat er in het ICT-landschap vaker storingen optreden dan bij welke facilitaire dienst dan ook, terwijl er toch meestal een aparte dedicated afdeling ICT is. Zou het misschien beter gaan zonder die beheerders met al hun bureaucratische processen?
Ja, natuurlijk! Dat geldt zeker voor een middelgrote organisatie met vaak  een onderbezette ICT-afdeling, die ook nog kampt met een tekort aan competenties. Het zou arrogant zijn te denken dat deze ICT-afdeling de gebruiker een betere dienstverlening kan bieden dan een professioneel ICT-bedrijf. Voor andere facilitaire diensten geldt dat toch ook niet? Of is inkopen van ICT-diensten misschien zo ingewikkeld?

4. ICT-beheer is logistiek

Dat ICT-beheer en functioneel beheer voor ICT-bedrijven en gegevensverwerkende industrieën vaak essentieel zijn, staat buiten kijf. ICT-beheerders en functioneel beheerders zijn vaak de pioniers. Zij zorgen voor innovatie. Zij hebben de ICT groot gemaakt door concurrentievoordelen te creëren.
Er ging echter iets fout, toen andere bedrijven tegen ICT gingen aankijken als tegen een aantal ICT-processen en vonden dat deze specialistische processen conform ITIL, BiSL, ASL, Cobit enzovoort dan ook voor hen bedrijfsprocessen zouden moeten zijn, toen deze bedrijven ICT gingen beschouwen als een verzameling stepping stones met instructies voor de doe-het-zelver, in plaats van als een goed geconstrueerde brug, die gebruiksklaar is op het moment dat hij nodig is om van A naar B te komen.
Maar bedrijven waarvoor ICT geen core business is, hebben er toch helemaal geen behoefte aan een puzzel te leggen, waarvan de stukjes door tig leveranciers geleverd worden en waarvoor niemand de totale oplossing geeft? Zij willen toch helemaal geen nieuwe paden banen? Ze gebruiken liever de kant en klare brug, ook al weten ze dat deze door nog duizenden anderen wordt gebruikt. En als ze toevallig naar een andere plaats willen, dan nemen ze gewoon een andere brug. Zelfs al moeten ze daarvoor een stukje omrijden.
ICT kan voor uw organisatie zo simpel zijn. ICT is eigenlijk niet meer dan een faciliteit die ervoor zorgt dat de goede informatie in de goede vorm op het juiste moment op de goede plaats aanwezig is tegen minimale kosten. Kortom, de oplossing voor een logistiek probleem. En het gaat daarbij voor u om zaken als inkopen en voorwaarden, zaken als leverbetrouwbaarheid , als just-in-time. De kern van het beheer is het professioneel inkopen van ICT en het goed bewaken van de levering en de kosten. Daarvoor hoeft u geen verstand van ICT te hebben. U moet alleen de goede diensten en competenties tegen aantrekkelijke financiële voorwaarden inkopen bij een betrouwbare leverancier. (Zie ‘Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens’.) Want u heeft tenslotte toch ook liever een brug die zijn waarde al vele malen in andere organisaties heeft bewezen, dan een aantal stepping stones die u als een volleerd ontdekkingsreiziger nog zelf moet leggen?

Download:         

Gerelateerde artikelen:

1. Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens
2. BiSL maakt functioneel beheer wel erg ingewikkeld
3. Outsourcing van werkplekbeheer is meer dan kostenbesparing alleen

1. Als de regie van ICT-beheer uw probleem is
2. Functioneel beheer als core business
3. Demand en supply
4. Integratieknelpunten BiSL, ASL en ITIL
5. Integratie van BiSL, ASL en ITIL 

1. Als de regie van ICT-beheer uw probleem is

In het artikel ‘Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 1′ hebben we de integratie van ITIL, ASL en BiSL benaderd vanuit de frameworks zelf, in historisch perspectief. We hebben daarbij geconstateerd, dat deze integratie in feite alleen nodig is voor organisaties waarvoor informatievoorziening ‘core business’ is en die geen direct contact meer hebben met de klant, zoals banken, verzekeraars en centrale overheden. (Zie ook ‘ICT en functioneel beheer steeds meer logistieke processen’.)
Echter, niet iedere organisatie waarvoor informatievoorziening geen ‘core business’ is, is al zo ver, dat de automatisering wordt uitbesteed. Als uw ICT-afdeling met ITIL werkt en vooral is gefocust op de ICT-infrastructuur, dan is de aanvulling van BISL natuurlijk waardevol. U zult dan immers als afnemer een actieve rol moeten vervullen om uw behoefte in te vullen. U heeft dus de regie. En uw rol als regisseur zult u waar moeten maken. Want, zo eindigde deel 1 van dit artikel, als u niet krijgt wat u wilt hebben, dan hebben niet de specialisten gefaald, dan hebt u gefaald.
In dit deel van het artikel gaan we ervan uit, dat de regiefunctie voor u noodzakelijk is en bekijken we de integratie vanuit het regiecentrum. Als voorbeeld nemen we de ervaringen van het agentschap BPR (Basisadministratie Persoonsgegevens en Reisdocumenten) bij het vormgeven van de beheerorganisatie aan de hand van deze drie beheermodellen. We bespreken de problemen die BPR daarbij is tegengekomen en de wijze waarop men hiermee is omgegaan. Net als in de meeste van onze artikelen over functioneel beheer (zie ook ‘Organisatie en inrichting functioneel applicatiebeheer’) is het drievoudig beheermodel van Looijen genomen als uitgangspunt voor de integratie van de ‘demand en supply’-ketens. 

2. Functioneel beheer als core business

BPR is een agentschap van het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK). Het agentschap is eindverantwoordelijk voor de jaarlijkse uitwisseling van ongeveer zestig miljoen berichten met algemene persoonsgegevens en de productie en distributie van jaarlijks 1,2 miljoen paspoorten en 900.000 Europese identiteitskaarten. De eerste opdracht van BPR daarbij is ervoor te zorgen dat de infrastructurele functie van de gemeentelijke basisadministratie en de reisdocumenten naar behoren werkt. Daarnaast beheert BPR verschillende registers en informatiesystemen, waaronder het Basisregister Reisdocumenten, het register van burgerservicenummers (BSN) en de centrale component(en) van de moderne GBA.
Het beheren van deze registers omvat zowel functioneel beheer, als applicatiebeheer als technisch beheer. Het functioneel beheer is verantwoordelijk voor zowel het opstellen van het Logisch Ontwerp als de uitvoering van het gegevensbeheer.

• Het Logisch Ontwerp beschrijft zowel het functioneel ontwerp van de informatiesystemen en het berichtenverkeer als de ao-procedures voor het beheren van de registers.
• Het gegevensbeheer van BPR omvat het bewaken van de kwaliteit van het berichtenverkeer en de volledigheid van de verwerking van de berichten in het betrokken register. BPR besteedt het applicatiebeheer en technisch beheer uit, maar voert wel een gestructureerde regie over de verschillende leveranciers.

Het functioneel beheer is dus de core business van BPR. De functioneel-beheerprocessen zijn daarmee de primaire bedrijfsprocessen. (Zie ook ‘BiSL maakt functioneel beheer wel erg ingewikkeld’.)

3. Demand en supply

BPR hanteert voor het beheer van de registers het drievoudig beheermodel van Looijen, zoals hieronder is weergegeven.

Figuur1: Drievoudig beheermodel van Looijen

Voor technisch beheer heeft BPR als enige jaren geleden ITIL als referentiemodel gekozen, waarbij alleen wordt gekeken naar de Service Support Set en de Service Delivery Set van ITIL 2000. Voor de invulling van de beheerprocessen heeft BPR gekozen voor het gebruik van ASL (Application Service Library) en BiSL (Business Information Services Library), respectievelijk voor de applicatiebeheerprocessen en de functioneel-beheerprocessen (waaronder gegevensbeheer). Dit sluit
aan bij het advies van de Nederlandse Overheid Referentie Architectuur (NORA).
Omdat BPR niet alle beheerprocessen zelf uitvoert, is onderscheid gemaakt tussen beheerprocessen die invulling geven aan de vraagkant (demand) en beheerprocessen aan de ondersteunende kant (supply). Door deze verdeling van de beheerprocessen ontstaan de volgende beheerdomeinen:

Fguur2: Demand and Supply

De opdrachtgever is de feitelijke klant van BPR, en BPR is regievoerder over het uitbestede applicatiebeheer en technisch beheer. Dit demand-supplymodel wordt al enige jaren door BPR als basisprincipe gebruikt.
De drie beheerdomeinen vormen een keten van beheerprocessen, waarin een drievoudige demand-supplyrelatie is vormgegeven. Hierbij stelt de opdrachtgever de eisen aan de dienstverlening vast en is BPR voor het technisch beheer en applicatiebeheer de makelaar die deze dienstverlening realiseert en bewaakt, door onderaannemers aan te stellen en daar de regie over te voeren.
Alle drie de beheermodellen BiSL, ASL en ITIL beschrijven de beheerprocessen op aparte lagen, te weten op strategisch, tactisch en operationeel niveau. Schematisch kunnen we de beheervelden als volgt weergeven:

Figuur3: Beheervelden op strategisch, tactisch en operationeel niveau

4. Integratieknelpunten BiSL, ASL en ITIL

Bij de integratie van de beheermodellen bleken verschillende knelpunten op te treden (zie ook ‘Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 1′), waarvan we de belangrijkste zullen bespreken aan de hand van bovenstaande drievoudige demand-supplymatrix (D/S-matrix), waarin BPR de beheerprocessen van de drie modellen heeft ingevuld. In deze matrix kan een proces volledig binnen één kolom worden geplaatst, zoals bijvoorbeeld het behoeftenbeheerproces (cel 7).

4.1 Overlap en witte vlekken

De praktijk is echter weerbarstig. Aan een proces als incident management geven zowel BPR (cellen 14, 15 en 17) als de leveranciers invulling (cellen 16 en 18). In dat geval moet onderscheid worden gemaakt tussen besturende (demand-) en uitvoerende (supply)subprocessen. De procedures van dit proces worden verdeeld over de demand-en supplypartijen.
Ook bleek al snel dat een aantal cellen van de matrix (bijna) geheel leeg bleef. Zo beschrijft ITIL 2000 geen strategische beheerprocessen (cellen 5 en 6). BPR heeft dit probleem opgelost door de strategische beheerprocessen van ASL te gebruiken voor de invulling van het strategisch niveau van het technische beheer (cellen 5 en 6).
Verder zijn er aan de demandkant van de klant op operationeel niveau (cel 13) nauwelijks beheerprocessen te onderkennen. Dit in tegenstelling tot de situatie bij veel andere organisaties, waar er aan de kant van de klant businessanalisten zijn, die eisen stellen aan informatiesystemen (‘Specificatie’), super users die een eerstelijnsondersteuning geven (‘Gebruikersondersteuning’) en acceptanten die nieuwe systemen en wijzigingen accepteren (‘Acceptatie’). Bij BPR bestaat de dienstverlening echter uit het beheren van een register en het bijbehorende berichtenverkeer. Hierbij is geen sprake van een gebruikersinterface en is het aan de afnemer om deze berichtendienst in te passen in zijn administratieve organisatie.

4.2 Vermenging strategisch, tactisch en operationeel niveau

Een tweede knelpunt was dat ITIL en ASL een aantal beheerprocessen definiëren met dezelfde naam, maar deze op een verschillend niveau plaatsen, zoals de processen availability management, ICT continuity management en capacity management. Het bleek niet nodig om deze processen op twee niveaus te beleggen; BPR heeft deze duale processen alleen op het tactisch niveau onderkend.

4.3 Ontbreken van de klantrol

Een derde knelpunt was het feit dat het drievoudig D/S-model vereist dat de klant de eindregie heeft over de keten van demand- en supplybeheerprocessen. De drie beheermodellen zouden hier tot op zekere hoogte invulling aan moeten geven door een passende voorziening daarvoor te bieden op elke laag, maar doen dat niet. Aan het proces problem management bijvoorbeeld geeft alleen ITIL invulling. ASL heeft dit proces deels ingevuld in het kwaliteitsmanagementproces, en dan op tactisch niveau. BPR heeft ervoor gekozen om deze gaten op te vullen: aan problem management geeft bijvoorbeeld de applicatiebeheerleverancier invulling.
In de praktijk komt het ontbreken van de klantrol vaak voor (geen tijd, geen expertise, geen aandacht). Deze kan dan ingevuld worden door de rol van demand management expliciet te beleggen bij een daartoe geëquipeerde partij in de leveringsketen. Dergelijke partijen zijn echter schaars.(Zie ook ‘Net als mannen worden ICT-bedrijven bijna nooit volwassen’.)

4.4 Synoniemen en redundantie

Het vierde struikelblok waar BPR tegenaan liep, waren de vele synoniemen, zoals financieel management (BiSL), kostenmanagement (ASL) en Financial Management for IT Services (ITIL). Ook geven BiSL en ASL synoniemen voor Service Level Management en de Release Managementprocessen van ITIL. Dit is een handicap voor beheerders die de beheermodellen nog niet kennen. BPR heeft de terminologie van ITIL als standaard gehanteerd, omdat dit beheermodel bij de beheerders bekend is.
BPR had samen met de leveranciers behoefte aan de invoering van alle drie de beheermodellen, maar het aantal beheerprocessen dat moest worden onderkend, ingericht en bestuurd, was te omvangrijk. Bovendien was er veel redundantie tussen de beheermodellen, wat de D/S-structuur vertroebelde. Zo definiëren alle drie de beheermodellen change management, financial management for ICT services en service level management. Dit was op te lossen door de drievoudige D/S-matrix terug te brengen tot een tweevoudige D/S-matrix door het demand management van het technisch beheer en applicatiebeheer samen te voegen. Hierbij werden alleen die beheerprocessen van ASL overgenomen, die een significante toegevoegde waarde vertegenwoordigden boven de ITIL-beheerprocessen.

4.5 Verschillende detailleringsniveaus

Het zesde knelpunt was het verschil in detailleringsniveau van de beheermodellen. Zo geeft ASL veel meer aandacht aan het change managementproces door dit uit te vergroten in zes subbeheerprocessen (het cluster ‘Onderhoud & vernieuwing’). Ook het BiSL-beheermodel heeft change management uitvergroot, in dit geval in vier subbeheerprocessen (het cluster ‘Functionaliteitenbeheer’). Omdat BPR de D/S-supplyketen horizontaal van links naar rechts wilde kunnen invullen, was het verschil in detailleringsniveau lastig. Omdat functioneel beheer het primaire proces is van BPR is er als uitgangspunt gekozen voor de meest uitgebreide beschrijving.

4.6 Ontbreken van de IC-functie waardoor aansturing adhoc is

Het zevende en laatste belangrijke knelpunt bleek te liggen in het ontbreken van regiefunctionaliteit in de beheermodellen. Zo geven de gekozen beheermodellen geen invulling aan de aansturing van het operationeel beheer van de infrastructuur. Daarom is gekozen voor de beheerprocessen die gedefinieerd zijn in het boek ICT Infrastructure Management van ITIL. Verder ontbreekt het aan een monitorfunctie. In principe kan deze functie als een onderdeel van het service level management worden gezien. (Zie ook ‘ICT Service Delivery is gebaseerd op pro-actief Service Management’.) ITIL geeft hier echter bijzonder weinig aandacht aan, en voor BPR is het van cruciaal belang voor zijn regiefunctie. Daarom heeft BPR monitoring als een apart proces onderkend: het heeft de SLA monitor van de berichtenketens vormgegeven door zowel E2E-ketenmetingen te (laten) verrichten per berichtensoort als componentmetingen per technische component die in een keten is betrokken. 

5. Integratie van BiSL, ASL en ITIL

De drie beheermodellen BiSL, ASL en ITIL kunnen heel goed samen worden gebruikt als referentiemodel. Wel zijn dus de nodige aanpassingen noodzakelijk om tot een harmonieus geheel te komen.
BPR had het voordeel, dat het in feite met een schone lei kon beginnen, zonder dat het daarvoor eerst het verleden met al zijn gevoeligheden moest afbreken. Ook was de druk om het beheer goed in te richten bijzonder groot. Alle gemeenten in Nederland zijn immers afhankelijk van een goede inrichting. De grote investering in tijd en geld voor de integratie van BiSL, ASL en ITIL was dan ook verantwoord te noemen.
Vaak zijn tijd en geld een groter knelpunt. Meestal zal men dan ook voor een meer pragmatische oplossing moeten kiezen. Mogelijkheden zijn bijvoorbeeld:

• Grotere organisaties die zijn te typeren zijn als informatieverwerkende industrieën, hebben vaak de schaalgrootte en expertise om de bestaande implementaties van BiSL en ITIL stap voor stap naar elkaar toe te laten groeien en deze investering terug te verdienen.
• Middelgrote en kleinere organisaties missen meestal de capaciteit en de noodzaak om de verschillende vormen van beheer te professionaliseren. Om toch te kunnen beschikken over professioneel beheer is het dikwijls handig om het beheer zoveel mogelijk uit te besteden (zie ook ‘Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens’).
• Een derde variant is een samenwerking tussen middelgrote bedrijven via een shared service center, om de benodigde schaalgrootte te krijgen. Hierbij moeten wel de valkuilen ontweken worden zoals die worden beschreven in het artikel ‘Shared Service Center: zelf pompen of verzuipen’.
• Ook kunnen ICT-bedrijven zich specialiseren in het leveren van full service aan middelgrote en kleinere organisaties. Zij zullen hiertoe voor de supply-kant operational excellence moeten ontwikkelen om zelf te leveren. Tegelijkertijd moeten zij voor de demand-kant standaards ontwikkelen, zodat het eenvoudig wordt voor klanten de ICT-diensten waaraan behoefte is in te kopen bij één partij, die vervolgens zelf optreedt als ketenregisseur (zie ook ‘ICT en functioneel beheer steeds meer logistieke processen’).

Belangrijk is in elk geval om nu keuzes te maken voor de toekomst. ITIL, ASL en BiSL zijn frameworks van meer dan 10 jaar oud. De vraag is of het voor u de moeite waard is, om hier nu nog in te investeren. (Zie ook ‘Outsourcing van werkplekbeheer is meer dan kostenbesparing alleen’.)
ZBC onderkent de behoefte aan een lean and mean werkend geheel, waarin alle soorten beheer nauw samenwerken en heeft daartoe een begeleidingstraject ontwikkeld ‘Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer’. Hoe zoiets ook voor u uitgewerkt kan worden, leest u in de Casestudy Training Outsourcing werkplekbeheer of in de Casestudy Training functioneel beheer website.

Herziene versie: 9 april 2010

Bron: Drs. ing. Bart de Best RI : ‘Drievoudig demand en supply: Agentschap BPR maakt keuzes bij integratie ITIL, ASL en BiSL’ In: IT beheer 10. december 2006.

Download:         

Gerelateerde artikelen:

1. Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 1
2. Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer
3. BiSL maakt functioneel beheer wel erg ingewikkeld

1. ICT-beheer vaak complexer dan ICT zelf
2. Veel synoniemen
3. ITIL voor het beheer van de technische infrastructuur
4. BiSL met als invalshoek de business
5. ASL: vreemde bult of waardevolle toevoeging?
6. Waar is de klant gebleven? 

1. ICT-beheer vaak complexer dan ICT zelf

Al vanaf het begin bestaan binnen de automatisering de aandachtsgebieden IT-beheer en servicemanagement. Drie belangrijke ontwikkelingen binnen deze aandachtsgebieden zijn: Information Technology Infrastructure Library (ITIL), Application Services Library (ASL) en Business Information Services Library (BiSL). Alle drie frameworks die afzonderlijk van grote waarde zijn, maar elkaar in de praktijk vaak tegenwerken. Dat komt doordat ITIL, ASL en BiSL vaak los van elkaar worden geïmplementeerd binnen verschillende onderdelen van hetzelfde bedrijf.  (Zie ook ‘BiSL maakt functioneel beheer wel erg ingewikkeld’.) En het los van elkaar implementeren van deze drie frameworks staat garant voor mismatch en miscommunicatie.
Balans tussen ITIL, ASL en BiSL ontstaat door het onderkennen en het overwinnen van deze historische frictie. Er zal serieus gekeken moeten worden naar mogelijkheden van integratie of synchronisatie, waarbij de drie frameworks elkaar aanvullen in plaats van tegenwerken.
Integreren betekent dan, dat niet alleen de activiteiten samengevoegd worden, maar dat ook het procesmanagement in één hand komt te liggen en daarmee dus de procesverantwoordelijkheid. In geval van reeds ingerichte processen ligt hier het risico van een oplaaiende competentiestrijd, zeker bij inmiddels gevestigde ITIL/ASL/BiSL-processen met een hoge score op de KPI-lijst. Eigenlijk zou men met de integratie moeten beginnen nog voordat elk framework zich gesetteld heeft.
De belangrijkste vraag vooraf is echter of deze integratie wel uw probleem is. Veel interne en externe ICT-leveranciers willen u dat wel laten geloven. 

2. Veel synoniemen

De drie frameworks moet afzonderlijk geïmplementeerd kunnen worden. Ze bevatten daardoor nogal wat overlappende processen. Helaas verschillen in deze processen per framework de terminologie en de diepgang.
Zo kennen we de synoniemen financieel management (BiSL), kostenmanagement (ASL) en Financial Management for IT Services (ITIL). Ook kennen BiSL en ASL verschillende benamingen voor Service Level Management en de Release Managementprocessen van ITIL. Vaak wordt de terminologie van ITIL als standaard gehanteerd, omdat dit beheermodel bij de beheerders het meest bekend is.
Een ander knelpunt is het verschil in detailleringsniveau van de beheermodellen. Zo schenkt ASL veel aandacht aan het ene change managementproces van ITIL door dit uit te vergroten in zes subbeheerprocessen (het cluster ‘onderhoud & vernieuwing’). Ook het BiSL-beheermodel heeft change management uitvergroot, in dit geval in vier subbeheerprocessen (het cluster ‘functionaliteitenbeheer’).
In dit artikel willen we een overzicht geven van de mogelijkheden tot integratie, geredeneerd vanuit de frameworks. In ‘Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 2′ benaderen we vooral de ketenintegratie van service en delivery processen met meerdere partijen. 

3. ITIL voor het beheer van de technische infrastructuur

ITIL implementeren is niet gemakkelijk. (Zie ook ‘Inrichtingsmodel IT-beheer’.) Het is veranderen en veranderen doet altijd pijn. Om praktische redenen wordt dan ook meestal gekozen voor een gefaseerde invoering. De focus zal in het begin liggen bij die processen die de meeste kans bieden op het daadwerkelijk creëren van herkenbare meerwaarde voor zowel de klantorganisatie als de serviceorganisatie.
Vaak zien we dat ITIL-implementaties zich in eerste instantie beperken tot het domein van de traditionele infrastructuur. Kijk bijvoorbeeld maar naar het dekkingsgebied van Configuration Management (de centrale administratie van assets). Wat ITIL betreft zouden in de configuration management database (CMDB) alle configuration-items (CI’s) terug te vinden moeten zijn, waarvan men kennis moet hebben om te kunnen komen tot een gewaarborgde dienstverlening. In de voorbeelden geeft ITIL zelf aan dat dit kan variëren van hardware en software tot documentatie, procedures en contracten. In de praktijk zien we echter, dat slechts hardware in de CMDB wordt opgenomen, en soms ook nog software. Zelden treft men CI’s aan in de vorm van een sluitende beschrijving van softwarecomponenten anders dan operating systems, protocollen en drivers. De bedrijfsmatige toepassingen komen meestal helemaal niet in beeld of worden slechts op zeer globale wijze in de CMDB opgenomen.
Hetzelfde zien we terug bij Incident Management. Er wordt vooral nagedacht over hoe verstoringen op de hardware kunnen worden aangepakt en hoe daarvoor een workaround kan worden geboden. Ondersteuning van bedrijfsapplicaties hoort wel tot het domein, maar de praktische realisatie laat veel te wensen over. Zeker in middelgrote en kleinere organisaties, waar de capaciteit ontbreekt om deze expertise te onderhouden. Maar vaak wordt dat pas zichtbaar als een gebruikersorganisatie outsourcing overweegt. (Zie ook ‘SaaS is voor de gebruiker meer dan alleen stroom uit het stopcontact’).
Duidelijk is dus, dat met alleen een ITIL-implementatie de gestelde doelen veelal niet gehaald worden. 

4. BiSL met als invalshoek de business

Binnen ITIL zijn de contacten met de klant terug te vinden op drie niveaus: op operationeel niveau (via de servicedesk), op tactisch niveau (als gesprekspartner voor Service Level Management) en op strategisch niveau (als gesprekspartner voor het tamelijk onbekende ITIL-proces Customer Liaison). Dat binnen de klantorganisatie ook het één en ander moet plaatsvinden om de dienstverlening correct te ontvangen en te begeleiden, wordt hiermee geadresseerd. Binnen ITIL worden hiervoor echter verder geen handvatten geboden. Het lijkt meer te gaan om een rol als van een afdeling ‘goederenontvangst’ dan om een rol van opdrachtgever.
Verder zien we dat de meeste functioneel beheerders medewerkers zijn die min of meer per ongeluk in die rol zijn terechtgekomen, vaak zonder duidelijke functieomschrijving, afbakeningen van verantwoordelijkheden en toekenning van bevoegdheden. De rol van de functioneel beheerder lijkt dikwijls een restpost te zijn, waar alles terechtkomt wat niet op de één of andere manier belegd is bij of de technisch beheerders of de ‘domme gebruikers’. Het echt positioneren van de rol van functioneel beheerder in de organisatie is altijd een groot probleem geweest, daar de inrichting steeds sterk organisatieafhankelijk was. BiSL kan in dit verband de ‘missing link’ zijn.
De vraag is echter of er een ideale match ontstaat. Enerzijds is de functioneel beheerder dus de uit nood geboren schakel die in ITIL geheel ontbreekt. Anderzijds biedt BiSL een volledig framework, dat echter niet is afgestemd op ITIL. (Zie ook ‘Begrippen en structuur van BiSL’.) Kunnen de overlappende processen binnen de frameworks samenwerken? En hoe dan?
Ook komt in alle drie de modellen een vorm van service level management voor, evenals een vorm van contractmanagement. Gaat contractmanagement uit BiSL afzonderlijke gesprekken aan met de service level managers uit de corresponderende ASL- en ITIL-processen? Wie zorgt dan voor de waarborging van de samenhang tussen die individueel opgestelde SLA’s? Of moeten de rollen van service level manager van ASL en ITIL samengevoegd worden, zodat er één gesprekspartner is voor de klant? En hier blijft het niet bij. Neem bijvoorbeeld gebruikersondersteuning, en dan met name de rol en afhandeling van verstoringen. Vaak is binnen elk framework een afzonderlijke servicedesk ingericht. Meerdere servicedesks die naar elkaar doorschakelen, het lijkt niet bevorderlijk voor een effectieve en efficiënte afhandeling van calls.
Hoe dan ook, het BiSL-framework gaat verder dan alleen functioneel beheer. Ook de aandachtsgebieden van informatiemanagement hebben een duidelijke positie. Dit roept echter weer onmiddellijk de vraag op, in hoeverre aan de gebruikerskant een specialistische managementrol gedefinieerd moet worden, zeker als ICT alleen een facilitaire dienst is en geen ‘core business’. (Zie ook ‘ICT en functioneel beheer steeds meer logistieke processen’.) 

5. ASL: vreemde bult of waardevolle toevoeging?

Een groepering die zich bij een ITIL-implementatie vaak in de steek gelaten voelt, is die van de technische applicatiebeheerders. In de praktijk zien we vaak een traditionele scheiding tussen infrastructuur- en applicatiebeheer. Een scheiding die zich niet altijd beperkt tot de hiërarchische positie, maar zo nu en dan ook terug te vinden is in de communicatie, de afstemming, de begripsvorming en het al of (vooral) niet gemeenschappelijk gebruik van tools en methodes.
ASL is daar op een zeer handige wijze ingesprongen. Vanuit ASL bekeken is ITIL voor het technische infrastructuurbeheer bestemd. ASL zelf richt zich op het ondersteunen en vormgeven van het applicatiebeheer. In de opbouw van ASL kunnen we een aantal onderdelen onderkennen, die iets toevoegen aan het ITIL-framework. Maar het is vaak niet zinvol om naast het ITIL-framework ook nog het ASL-framework te omarmen. Door de grote overlap zou dat de bureaucratie tot een verlammende hoogte opjagen. Veel beheerorganisaties hebben al een gevestigde ITIL-inrichting. Deze zal dan ten opzichte van een eventuele ASL-implementatie tamelijk dominant zijn. Neem daarom ITIL als uitgangspunt en pas de bruikbare ASL-elementen in in de procesmodellen van ITIL. Alleen als ontwikkeling en onderhoud van bedrijfssoftware uw core business is, kunt u overwegen om ASL als basisframework te gebruiken.
De toegevoegde waarde van ASL bestaat uit een aantal uitbreidingen in het procesmodel en de concrete vertaling van een aantal oorspronkelijke ITIL-processen naar aspecten en behoeften die binnen het applicatiebeheer zijn te onderkennen. Een voorbeeld is het configuratieproces binnen ASL. Hier maakt men specifiek onderscheid tussen applicatieve, infrastructurele en dienstverlenende objecten. Deze dienstverlenende objecten zouden ook in het ITIL-configuratieproces een plaats kunnen krijgen, maar daar beperkt men zich vaak tot de Service Level Agreements (SLA) en mogelijk Operational Level Agreements (OLA).
Een andere verdienste van ASL is dat het een aantal processen een operationele positie heeft gegeven, terwijl ITIL ze op een meer tactisch niveau plaatst. Denk bijvoorbeeld aan beschikbaarheidsbeheer. Een groot manco van dat proces bij veel ITIL-implementaties is dat men de neiging heeft te blijven hangen in de definitie van wat gemeten moet worden om het gerealiseerde beschikbaarheidsniveau te kunnen vaststellen. Daadwerkelijk concrete maatregelen blijven achterwege of zijn slechts zo oppervlakkig, dat er praktisch weinig mee bereikt kan worden. De enige concrete resultaten zijn dan ook voornamelijk te vinden op het gebied van het verhogen van de beschikbaarheid van de infrastructuur, door middel van redundantie en het wegnemen van single points of failure.
Als het gaat om beschikbaarheidsmaatregelen die concreet kunnen worden toegepast op de bedrijfsapplicaties, dan moet er gebruik worden gemaakt van de suggesties die binnen ASL worden aangereikt. Ook hier zou het bijzonder spijtig zijn als de ITIL- en ASL-variant van het proces als twee zelfstandig opererende processen gaan functioneren. Een combinatie van de twee zou een grote meerwaarde betekenen, waarbij ITIL-beschikbaarheidsbeheer vooral op tactisch niveau een aantal doelstellingen en maatregelen definieert die operationeel een vertaling vinden binnen het applicatiebeheer en het infrastructuurbeheer. 

6. Waar is de klant gebleven?

Stelt u zich voor dat u manager bent in de gebruikersorganisatie van een business unit en u moet een aantal afgesproken KPI’s halen. Het is wel zeker, dat deze KPI’s niets te maken hebben met ITIL, BiSL of ASL. Automatisering is voor u een faciliteit die nodig is om uw KPI’s te halen. Voor automatisering zijn specialisten nodig en u vindt het vanzelfsprekend, dat zij standaards en methodieken gebruiken. Dat er meerdere frameworks zijn, dat zal u een zorg zijn, zolang u er maar geen last van heeft en het nut van de frameworks zich vertaalt in een betere service. Voor u als manager is automatisering een facilitaire dienst, die u meestal inkoopt net als andere facilitaire diensten voor gebruik door uw medewerkers, zoals bijvoorbeeld telefonie, security, vervoer, catering, klimaat enzovoort. (Zie ook ‘Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens’.) Hiervoor heeft u zelf ook geen specialisten in dienst. Die diensten koopt u ook in.
Maar niet iedere organisatie is al zo ver, dat de automatisering wordt uitbesteed. Als u ICT niet uitbesteedt, kan de aanvulling van BISL waardevol zijn, als uw ICT-afdeling met ITIL werkt en vooral is gefocust op de ICT-infrastructuur. Dan zult u als afnemer een actieve rol moeten vervullen om uw behoefte in te vullen. U zult zelf uw eisen moeten bepalen en vervolgens moeten shoppen bij allerlei interne en externe aanbieders om uw behoeften in te kunnen vullen. U heeft de regie en u zult uw rol als regisseur moeten waarmaken. Want niet die specialisten hebben gefaald, als u niet krijgt wat u wilt hebben, maar u hebt gefaald. Te zot voor woorden natuurlijk, maar helaas vaak nog wel de praktijk in ICT-land. (Zie ook ‘ICT-bedrijven zijn uitblinkers in het leveren van onprofessionele services’.)
Vaak zien we dat klanten dit niet meer pikken en tenslotte zelf maar hun toevlucht nemen tot het opzetten van een gespecialiseerd shared service center op het gebied van automatisering. In ‘Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 2′ benaderen we vooral deze integratie van service en delivery processen met meerdere partijen vanuit dit perspectief.
ZBC onderkent de behoefte aan een lean and mean werkend geheel, waarin alle soorten beheer nauw samenwerken en heeft daartoe een begeleidingstraject ontwikkeld ‘Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer’. Hoe zoiets ook voor u uitgewerkt kan worden, leest u in de Casestudy Training Outsourcing werkplekbeheer of in de Casestudy Training functioneel beheer website.

Herziene versie: 6 april 2010

Bron:
Ton van Lieshout, 'Integratie ITIL, ASL en BiSL; door overwinnen historische tegenstellingen is
mismatch tegen te gaan'. In: Automatisering Gids nr. 39, 26 september 2008.

Download:         

Gerelateerde artikelen:

1. Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 2
2. Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer
3. BiSL maakt functioneel beheer wel erg ingewikkeld

Vroeger was ICT lekker overzichtelijk. Er werd gewerkt op basis van ‘Het onmogelijke doen we direct, wonderen duren iets langer, maar we garanderen niets’. Daar echter organisaties in toenemende mate afhankelijkheid zijn geworden van hun ICT, is deze werkwijze niet meer houdbaar. Standaardmethoden als ITIL hebben hun intrede gedaan, er zijn SLA’s opgesteld, stuurgroepen zijn ingericht en er is uitgebreid gegoocheld met verantwoordelijkheden en bevoegdheden. Het gevolg is wel, dat iedere flexibiliteit uit de ICT-dienstverlening is verdwenen. Irritatie en onbegrip zijn hierdoor toegenomen. De outsourcingspogingen van diverse bedrijven hebben deze nog eens versterkt. Ook de kwaliteit van de ICT-dienstverlening is er veelal niet door verbeterd, ondanks vuistdikke procedure handboeken.

Het ergste is, dat zowel de ICT’ers als de gebruikers, gesteund door hun management, vaak meer kissebissen over procedures dan over de inhoud. Waar het naar toe moet is daarbij meestal helemaal onduidelijk. Het lijkt dikwijls dweilen met de kraan open.

Diverse malen hebben we organisaties mogen helpen met het dichtdraaien van die kraan. Graag willen we u hierover vertellen in het webseminar ‘Organisatie ICT, functioneel beheer en projecten’. En we zijn natuurlijk ook benieuwd naar uw ervaringen.

Onze webseminars houden we steeds van 16.15 uur tot 17.00 uur. Om deel te kunnen nemen heeft u alleen een internetverbinding en een telefoonlijn nodig. Voor meer informatie kunt u de handleiding voor deelnemers raadplegen. U kunt zich voor het webseminar ‘Organisatie ICT, functioneel beheer en projecten’, eventueel samen met collega’s, aanmelden via het aanmeldingsformulier. Na aanmelding krijgt u per mail een bevestiging van uw deelname. Data voor andere webseminars  kunt u vinden in de agenda. Ook via onze nieuwsbrief houden we u op de hoogte.

Webseminars die mogelijk ook interessant voor u zijn:

• Webseminar Pragmatische aanpak informatiebeveiliging volgens ISO 27002 (=ISO 17799) en NEN 7510′
• Webseminar Business continuity, een aanpak uit de praktijk

Om gebruik te kunnen maken van de formulieren op deze site moet u eerst inloggen. Als u nog geen inlogcode heeft, sturen wij u deze per mail, zodra u zich heeft geregistreerd. U kunt zich via het registratieformulier snel en eenvoudig registreren.

Download:         

Gerelateerde artikelen:

1. Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens
2. Casestudy Training functioneel beheer website
3. Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer

1. Voor grote ICT-leveranciers is onze organisatie toch niet van belang?
2. Marktontwikkelingen hebben ICT-leveranciers veranderd
3. Hoe grote bedrijven klein kunnen worden
4. Wat mag u van een grote dienstverlener verwachten?
5. Hoe u kunt zien of een grote leverancier echt past?
6. Een sterke leverancier die ‘customer intimacy’ levert 

1. Voor grote ICT-leveranciers is onze organisatie toch niet van belang?

U bent een kleine of middelgrote organisatie. Voor de levering van uw ICT-diensten maakt u bij voorkeur gebruik van eveneens kleinere of middelgrote ICT-bedrijven. Voor hen bent u tenslotte belangrijk. Zij nemen tenminste nog de moeite om zich te verdiepen in waar u zich mee bezighoudt. Zij staan altijd voor u klaar als u een probleem heeft. Dat u daarvoor later een factuur krijgt, vinden zij vanuit de optiek van de service redelijk, zelfs al zijn zij juist zelf de veroorzaker van dat probleem. Vanuit relationele overwegingen maakt u hiervan geen punt. Flexibiliteit heeft tenslotte een prijs en u bent graag bereid om die prijs te betalen. (Zie ook ‘Voor onvolwassen organisaties is een SLA een samenlevingscontract; de liefde regel je daar buiten’). Ook zijn zij niet te beroerd om de wensen van uw gebruikers serieus te nemen en mee te denken over hoe aan deze wensen kan worden voldaan.
Natuurlijk zijn er ook ergernissen over uw kleine of middelgrote leverancier, want waarom:

• wordt voor hetzelfde probleem steeds weer een nieuwe oplossing gevonden?
• gaat, als er bij een leverancier een beheerder opstapt, de know-how over uw ICT-infrastructuur steeds weer verloren?
• worden afspraken, vooral die over structurele verbeteringen, vaak niet nagekomen?
• nemen de ICT-beheerkosten ieder jaar toe?
• neemt de beschikbaarheid van de ICT-infrastructuur af?

Ondanks deze ergernissen echter lijkt de situatie nog altijd beter dan wanneer u zaken zou doen met grote ICT-leveranciers. Leveranciers voor wie u minder bent dan een kruimeltje van het koningsmaal dat zij gewend zijn te consumeren. Voor wie u een nummer in een rij bent, die begint met de top 100 van de Nederlandse bedrijven, die uiteraard altijd met voorrang behandeld worden. Leveranciers die u torenhoge tarieven in rekening brengen voor nauwelijks gekwalificeerde medewerkers.

2. Marktontwikkelingen hebben ICT-leveranciers veranderd

De grote ICT-leveranciers kregen echter in de afgelopen jaren te maken met een aantal grote veranderingen. (Zie ook ‘ICT-productleveranciers en detacheerders verliezen concurrentieslag met ICT-dienstverleners’.) Grote klanten wilden bezuinigen op hun ICT-budgetten en wilden vooral voorspelbare kosten. Het dure uurtje-factuurtje-werk werd geschrapt. Het kostbare onderhoud van kennis bij de eigen ICT’ers werd uitbesteed. Investeringen werden ingeruild voor langlopende outsourcingscontracten, waarbij alleen nog betaald hoefde worden voor gebruik. Het arbeidsmarktprobleem en de ermee samenhangende kosten werden verschoven naar de leverancier. Het vendormanagement naar tientallen leveranciers werd grotendeels uitbesteed naar één ’single point of contact’. (Zie ook ‘Outsourcing van werkplekbeheer is meer dan kostenbesparing alleen’.)
De grote ICT-leveranciers hadden geen keuze. Ze moesten zich in hoog tempo aanpassen om aan de eisen van hun klanten te kunnen voldoen en toegevoegde waarde te kunnen leveren op aanbieders van offshore outsourcing in lage-lonen-landen. Er moesten snel hoogwaardige en voor de klant kosteneffectieve standaards worden ingevoerd. Verder konden risico’s niet langer bij de klant worden neergelegd. Ze kwamen voortaan voor rekening van de leveranciers, waardoor zij zelf het slachtoffer werden van de eigen fouten. Kortom, er moest in rap tempo geprofessionaliseerd worden. Door de omvang van de outsourcingscontracten konden de investeringen echter ook weer terugverdiend worden.
Maar inmiddels is het laaghangende fruit bij de top 500 van de Nederlandse organisaties grotendeels geplukt. Nu staan de grote ICT-leveranciers voor de uitdaging om de gerealiseerde voorsprong verder uit te nutten. De totale markt bij middelgrote bedrijven is uiteindelijk groter dan die bij de top 500 in Nederland. Alleen is deze markt natuurlijk veel meer versnipperd. Bovendien is de kennis van deze markt bij grote ICT-aanbieders nogal beperkt. Eerdere pogingen om deze markt te benaderen hebben vaak wel tot omzet geleid, maar door de hoge overheadkosten zelden tot winst.
Bij de top 500 is wel aangetoond, dat bij outsourcing de prijs per standaard werkplek spectaculair kan dalen. Dat dit niet ten koste hoeft te gaan van de service aan de gebruikers, is ook bewezen. Maar hoe valt dit concept uit te rollen naar middelgrote bedrijven, zonder dat de marge of het concurrentievoordeel verdampt?

3. Hoe grote bedrijven klein kunnen worden

De uitdaging voor de grote ICT-aanbieders is dus geworden: ‘klein’ worden, vooral in overheadkosten. Dat betekent geen dure marketingcampagnes meer, maar komen met een aanbod dat zichzelf kan verkopen. Dat betekent ook flexibiliteit die gebaseerd is op een supermarktmodel, waarbij de klant zelf kan kiezen wat hij wil hebben, in de hoeveelheid die hij nodig heeft, voor een prijs per eenheid en ondergebracht in een ‘winkelcentrum’ waarin de klant zelf eenvoudig de weg kan vinden. Juist dit laatste is van belang.
Veel grote ICT-leveranciers zijn te beschouwen als een soort bouwmarkt, met professionele vakmensen als klanten, vakmensen die precies weten wat ze wel en niet willen hebben en die ook exact weten hoe basisproducten te assembleren. Middelgrote of kleinere organisaties missen vaak de expertise om zelf te assembleren en te integreren. Ze wenden zich daarom van oudsher tot de detailhandel, die maatwerk kan leveren, uiteraard tegen veel hogere kosten. Wat we nu zien, is dat grote ICT-dienstverleners een soort IKEA-concept gaan hanteren. In de ‘winkel’ is precies te zien hoe iets wordt. De klant krijgt echter een serie bouwelementen mee naar huis. Maar iedere leek kan hiermee het gewenste op maat kan maken. IKEA is met deze aanpak, niet voor niets, marktleider geworden.

4. Wat mag u van een grote dienstverlener verwachten?

Er zijn een aantal kenmerken waaraan u kunt zien of eengrote ICT-leverancier echt bij u als kleinere organisatie past:

• De levering van de dienst voor middelgrote en kleinere bedrijven is ondergebracht in een aparte business unit, die verantwoordelijk is voor haar eigen resultaat. Die business unit kent dus sowieso geen grote klanten, die misschien met voorrang behandeld moeten worden.
• Het dienstenpakket bestaat doorgaans uit een aantal standaardonderdelen:
  • de basiswerkplek met standaard Windows, Office en Outlook en de mogelijkheid om thin clients in te zetten; die remote werkplek kan ook gebruikt worden bij werken op een andere locatie.
  • de mogelijkheid om deze basiswerkplek per organisatie of per gebruiker uit te breiden met standaardopties; daarbij gaat het om applicaties als Adobe Acrobat Pro, MS Access, MS projects of om extra opslagruimte per gebruiker of per afdeling;
  • de mogelijkheid om op deze basiswerkplek bedrijfsapplicaties te gebruiken, zoals ERP-, CRM-systemen of branchespecifieke systemen; het kan nodig zijn om een applicatie eerst geschikt te maken voor de online werkplek, maar de kosten hiervoor zijn doorgaans gering; daarnaast zijn additionele werkplekdiensten te verkrijgen zoals VoIP (internettelefonie) of conferencing service voor telefonisch vergaderingen of
  • presenteren of samenwerken op afstand (zie ook ‘Vergaderen, presenteren en samenwerken op afstand’);
  • met in begrip van support en het beheer op deze diensten.

Al deze diensten zijn standaard en liggen in principe op de plank.
Belangrijke valkuil bij de selectie van een leverancier is, dat u die selectie benadert vanuit de gedachte van een Europese aanbesteding. (Zie ook ‘Europees aanbesteden leidt vaak tot minder marktwerking en hogere prijzen’.) Meestal is de basis hiervoor een waslijst met eisen. Als u niet vooraf bepaalt wat u werkelijk wilt, dan loopt u het risico dat een leverancier als hierboven beschreven het aflegt tegen een andere leverancier in de markt, die nauwkeurig uw offerte aanvraag volgt en bereid is alles aan te bieden tegen een meerwerk-tarief. De basisprijs zal dan namelijk niet noemenswaardig verschillen. Maar tijdens de looptijd van het contract zult u waarschijnlijk te vaak verrast worden door meerwerk, omdat de gekozen leverancier niet geïnvesteerd heeft in standaardisering van opties en die opties dus nog moet maken. (Zie ook ‘Selectie leverancier voor outsourcing werkplekbeheer’.)

5. Hoe u kunt zien of een grote leverancier echt past?

Het feit dat een grotere leverancier u een standaardbasispakket en standaardopties van de plank kan leveren, betekent dat u in elk geval een scherpe prijs en professionele dienstverlening krijgt. Dat wil uiteraard nog niet zeggen, dat de leverancier bij u past. Hij is in staat ‘operational excellence’ te leveren. Maar u verwacht ‘customer intimacy’. En daar is meer voor nodig:

• Genoemd is al, dat de dienst ondergebracht moet zijn in een business unit of dochter, die volledig gericht is op middelgrote en kleinere organisaties. Anders wordt u als klant ondergesneeuwd door grotere klanten.
• Als middelgrote of kleinere organisatie heeft u een eigen ICT-afdeling die te klein is om full service te leveren aan gebruikers. U kunt immers niet alle kennis onderhouden, vooral niet die van de software. Een grote leverancier heeft deze capaciteit wel. Hij moet bereid zijn om u van deze kennis gebruik te laten maken. Of die bereidheid er is blijkt onder andere uit het volgende:
  • De leverancier biedt aan om ook het applicatiebeheer te doen en gebruikersondersteuning te bieden op de applicaties (zie ook ‘Integratie is de sleutel tot bruikbaarheid van SaaS als een echte dienst’). Ook levert de leverancier support op communicatiediensten zoals VoIP en conferencing services.
  • De leverancier is bereid het demand management en vendor management van u over te nemen naar andere ICT-leveranciers. De leverancier biedt dus een single point of contact voor al uw ICT-gerelateerde zaken.
  • Het contract met de leverancier bestaat niet uit een dik pak papier met juridische statements. Het is een hiërarchie met op de laagste niveaus de standaard leveringsvoorwaarden en de standaard productbeschrijvingen, en op het hoogste niveau een paar A4-tjes met aanvullende afspraken en wijzigingen op de lagere niveaus. Niet de standaard vormt de basis voor de deal, dat doen de gemaakte afspraken en die zijn maatwerk. (Zie ook ‘Voor onvolwassen organisaties is een SLA een samenlevingscontract; de liefde regel je daar buiten’) En dat bespaart u veel tijd.

Belangrijk hierbij is welk deel van de services de leverancier wil bieden als onderdeel van het standaardpakket. Als al deze zaken als meerwerk worden aangeboden, dan kunt u erop rekenen, dat uw ICT-kosten nog steeds onvoorspelbaar en hoog zullen blijven.

6. Een sterke leverancier die ‘customer intimacy’ levert

De aanbiedersmarkt is sterk in beweging met allerlei overnames, teneinde outsourcing van werkplekbeheer te kunnen bieden en alles wat daarmee samenhangt. Overnames zijn aan de orde van de dag. Zo heeft Detron onlangs Squire en Kender Thijssen overgenomen. KPN nam onder andere Getronics (gericht op  grotere bedrijven) over en kocht ApplicationNet (gericht op middelgrote en kleinere bedrijven). Ook zitten er nog een aantal fusies en overnames aan te komen, veelal van kleinere bedrijven die nu nog onvoldoende kritische massa hebben om ook operational excellence te kunnen leveren. Zo proberen organisaties versneld hun achterstand in te lopen. Ze richten zich allemaal op de braakliggende markt van nog een paar honderdduizend werkplekken bij middelgrote en kleinere bedrijven, die de komende vijf jaar in Nederland bediend willen worden. De marktleiders in Nederland hebben stuk voor stuk nog geen 3% van deze potentiële markt in handen. Voor hen is het dus zaak om u nu over de streep te trekken.
U zult begrijpen dat ook u als kleinere organisatie momenteel zeer interessant bent voor grote aanbieders van outsourcing van werkplekautomatisering en werkplekbeheer. Voor u dus een uitgelezen kans om u verder te gaan oriënteren op de mogelijkheden.

Download:         

Gerelateerde artikelen:

1. Outsourcing van werkplekbeheer is meer dan kostenbesparing alleen
2. Hoe groot moet je zijn voor Offshore ICT-outsourcing
3. Voor veel overheden geen verschil tussen Outsourcing BPO en Shared Service Center SSC