Begrippen en structuur van BiSL

1. Meer aandacht voor functioneel beheer

In veel organisaties heeft functioneel beheer de laatste tijd in toenemende mate aandacht gekregen. Voor consultants een belangrijke reden om een volledige methodiek te verzinnen, met alles erop en eraan. Zo  kunnen zij in elk geval inspelen op (of was het meeprofiteren van?) de behoefte van organisaties. Als snel zag BiSL het licht. Veel functioneel beheerders vragen zich nu met verbijstering af, hoe zij in het verleden ooit hun taak hebben kunnen vervullen. In feite is er echter niets nieuws onder de zon. In dit artikel willen we weer teruggaan naar de essentie van functioneel beheer. Ook nu is voor functioneel beheer nog steeds geen ingewikkelde methodiek nodig.
Twintig jaar geleden al hanteerden we modellen voor de ontwikkeling van de business alignment van ICT waarin een drietal fasen werd onderkend, namelijk het creëren van:

• technisch hoogwaardige ICT-oplossingen;
• ICT-oplossingen die gebruikers vragen;
• ICT-oplossingen die gebruikers nodig hebben.

1.1 Fase 1: Technisch

Fase1, de fase waarin technisch hoogwaardige ICT-oplossingen worden gecreëerd: 

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.

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. 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 je denkt, dat in een SLA staat wat je precies voor elkaar moet doen, gaat het goed fout. Want dat is de functie van een SLA helemaal niet. Als je een meerjarenovereenkomst sluit, dan mag je 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 je er in overleg niet meer uitkomt. Het letterlijk nemen van een SLA betekent terugvallen naar fase 2 of zelfs naar fase 1. Dat wilt je 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. 
• 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. 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.

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 je zich dus niet verleiden tot de invoering van methodieken of het optuigen van veranderingstrajecten die niet zijn afgestemd op de huidige werkwijze. Neem jouw huidige werkwijze als uitgangspunt en versterk hierin de rol van het functioneel beheer.

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