Jarenlang hadden hardwerkende bankiers alle financiële touwtjes stevig in handen, maar achteraf bleken de resultaten toch niet zo degelijk als gedacht. Sterker nog, we zitten nu midden in een recessie en er moet veel veranderen. Zo is het ook met servicemanagement. Onze Beheer-experts aan het woord.
Patrick Janssen, ict-servicemanager, Jugo
Een service level agreement, of ook wel SLA genoemd, is als het bankwezen; als je doorgaat op de weg die je eens bent ingeslagen en niet kritisch bent over de gevolgen van je gekozen strategie, dan kan het leiden tot ernstige problemen, wellicht met een recessie tot gevolg. Overstappen van de eens zo goed werkende ‘serviceproces' SLA naar een recessiebestendige ‘businessproces' SLA is van groot belang om een naderende recessie in servicemanagementland te voorkomen. Bijkomend voordeel is dat de bedrijven weer in staat worden gesteld zich te richten op hun corebusiness, zodat de winsten weer kunnen groeien en uiteindelijk ook het bankwezen uit de recessie kan komen.
Mark Smalley, directielid internationale zaken, ASL BiSL Foundation
Even een stapje terug. Wat is er aan de hand? Er is toename van complexiteit, zowel van de systemen die beheerd worden als de ict-organisatie die het beheer uitvoert én de gebruiksorganisatie die de ict aanstuurt. Bij een focus op de organisatorische aspecten zie je decentralisatie van sturing aan de vraagzijde en meer verscheidenheid in de vraag. Aan de aanbodkant is er toenemende specialisatie van spelers met als gevolg meer rollen en partijen. Zo'n complex geheel laat zich niet in één proces gieten, je moet de oplossing zoeken in het standaardiseren van de interfaces tussen de partijen. Noem het maar service-oriented servicemanagement.
Aad Brinkman, principal consultant, Aranea Apreton
Waar het naar mijn idee tijd voor wordt is het gebruiken van een SLA waar een SLA voor bedoeld is. Het kan al een heel stuk helpen als iedereen de juiste terminologie gebruikt. Een SLA is een ‘agreement', een overeenkomst tussen onderdelen van één organisatie. Vaak tussen de ict-afdeling en de gebruikersorganisatie. Aan een interne overeenkomst zitten geen juridische consequenties en de financiële consequenties zijn linker broedzak, rechter broekzak. De afspraken in de SLA vertaald naar een contract met een externe leverancier heet een ‘underpinning contract' en de naam zegt het al: een contract. Dat onderscheid echt benoemen en hanteren neemt al een hoop onduidelijkheid weg. Een agreement geeft ook al aan dat het om twee partijen gaat. Het is dus noodzakelijk dat er een gesprek plaatsvindt tussen leverende organisatie (ict) en de afnemende organisatie (de klant). Daar is een proces voor: service level management.
De organisatie waar dit proces wordt ‘gespeeld' zoals het ‘gespeeld' moet worden, moet ik nog tegenkomen. Als dat wel gebeurt komen er SLA's die vanuit de business worden gevoed en reële afspraken bevatten die ict ook daadwerkelijk kan nakomen. Inderdaad de SLA's waarin een beschikbaarheid van 99,9 procent wordt beloofd, maar een proces om beschikbaarheid te managen (availability management) zijn vaker regel dan uitzondering. Ook zijn er weinig consultants die dat probleem durven te benoemen en deze richten zicht op de ict-vraag ‘operationele processen in te richten'. Deze processen ondersteunen de dienst, maar de processen die de dienst moeten leveren (tactische processen) zien we nergens. Dat veranderen (in gedrag) maakt de SLA een krachtig instrument. Een crisis is daar niet voor nodig.
Hans Timmerman, technical officer, EMC Nederland
Het is natuurlijk zo dat onze ict-infrastructuur de afgelopen tien jaar enorm complex is geworden, waardoor het managen van deze structuren navenant lastiger is geworden. Daarnaast zijn bedrijven steeds afhankelijker geworden van diezelfde infrastructuur en worden veel diensten steeds bedrijfskritischer en afhankelijker van elkaar. Als de servicemanagementorganisatie niet meegroeit om deze complexiteit te kunnen managen, krijg problemen. We zien op dit moment dat technologiebedrijven technische oplossingen in de markt brengen om deze complexiteit wat betreft serviceleverantie te virtualiseren. Dat betekent dat onder die virtuele laag de (technische) complexiteit alleen maar toeneemt. De consequentie is dat je die toegenomen complexiteit alleen nog maar kunt managen als je het vergaand integreert en automatiseert. Wat we dan ook zien gebeuren.
Echter, automatiseren betekent dat je organisatie op een totaal andere wijze moet worden ingericht en dat ook aan mensen andere eisen worden gesteld. In die zin is het waar dat het dus niet langer van belang is dat een individueel ticket binnen één schakel volgens het SLA wordt opgelost. Het is van belang dat het gehele businessproces weer op gang gebracht wordt, daar worden immers de winsten gemaakt voor een bedrijf. De enige mogelijkheid om dat laatste mogelijk te maken is integratie en vergaande automatisering. Er is een ‘operational readiness' nodig die de organisatie moet bereiken om vergaande virtualisatie succesvol te kunnen doorvoeren en om, naast de capex, vooral de opex-voordelen te kunnen realiseren. Het vermogen (of onvermogen) om die ‘operational readiness' te realiseren, is in mijn ogen de kritische succesfactorvoor het wel of niet blijvend kunnen managen van je ‘businessproces' SLA's.
Frank Niessink, principal consultant, DNV-CIBIT
Dit is een voorzet om de aansluiting tussen business en beheer te verbeteren en ik pleit daarbij voor bedrijfsprocesgerichte teams. Helaas wordtgeen rekening met de wet van behoud van ellende. Die is echter wel van toepassing, want een betere aansluiting bij de business leidt tot een slechtere aansluiting bij de technologie. De teams per bedrijfsproces zullen weliswaar meer kennis krijgen van de business, maar staan daardoor ook verder af van de technologie. Elk bedrijfsproces is over het algemeen afhankelijk van meerdere soorten technologie. In ieder team heb je dus kennis van al die technologie nodig. Al die kennis in elk team opnemen levert grote, dure teams op met in elk team een netwerkspecialist, een DBA'er, een e-mailspecialist, een storagespecialist, een java-ontwikkelaar, een user interface-ontwerper, etc. Omdat dit in de meeste situaties te duur is zullen teams moeten bestaan uit generalisten die nergens echt specialist in zijn.
Wellicht dat een combinatie van bedrijfsprocesgerichte teams en technologiegerichte teams zou kunnen helpen? Dat maakt dan zowel kennis van bedrijfsprocessen als technologiespecialisten mogelijk. Helaas zal de wet van behoud van ellende ook hier eenvoudig roet in het eten gooien in de vorm van afstemmingsproblemen tussen de twee soorten teams…
Dave van Herpen, management consultant, Sogeti Nederland
Er wordt één cruciaal aspect vergeten: vertrouwen. Waar het nu aan schort in de financiële sector is vertrouwen; vertrouwen van de consument en aandeelhouder, maar ook vertrouwen tussen dienstverleners onderling (interbancaire leningen) of zelfs in het volledige financiële systeem. Juist in deze situatie leunt de business vooral op de inbreng van haar leveranciers, met ict als een van de voornaamste enablers om de huidige crisis te boven te komen.
Natuurlijk kun je het instrument SLA inzetten om ‘de wet van behoud van ellende' zoveel mogelijk te beperken, maar in mijn optiek schreeuwt de marktsituatie eerder om proactiviteit en ondernemerschap vanuit ict. Dus niet alleen maar vooraf vastleggen wat ict minimaal moet doen (SLA), maar juist die stap extra zetten om het vertrouwen van de business te winnen. Denk hierbij aan ict-gedreven initiatieven voor kostenbesparing, snellere time-to-market of imagoverbetering. Daarbij is businesskennis natuurlijk meer dan welkom, dus bedrijfsprocesgerichte teams kunnen wel degelijk (bijvoorbeeld als taskforces) worden ingezet om concrete verbetervoorstellen te operationaliseren. Of deze bedrijfsprocesgerichte teams ook in de dagelijkse operatie efficiënt zouden werken, ligt volledig aan de te behalen doelstellingen, omvang en complexiteit van de ict-organisatie en het ict-landschap. Door op deze wijze vertrouwen te wekken en te behouden, hoop ik dat ict'ers volgend jaar niet op witte gympen door de binnenstad hoeven te lopen, om te voorkomen dat ze worden herkend en aangevallen worden door woedende demonstranten.
Melle Lelieveld, manager service management, Winvision
Er zit een cruciaal verschil tussen een leverancier en een partner. Een leverancier levert wat er gevraagd wordt, niet meer en niet minder. Een partner vertelt de klant niet voor welk onderdeel ze wel of niet de verantwoordelijkheid hebben, maar neemt de verantwoordelijkheid. De financiële sector heeft teveel gekeken naar hoe kan ‘ik' het gevraagde leveren en er snel zoveel mogelijk aan verdienen. Dit is een sprekende illustratie van een leverancier, waarbij niet kritisch gekeken wordt naar de vraag ‘ben ik wel de juist partij om te leveren en zijn er geen efficiëntere oplossingen?'.
Sinds twee jaar zijn we het partnerschap aangegaan met al onze klanten en is een SLA een stuk papier wat bij het sluiten van een contract overeen wordt gekomen en vervolgens ergens heel diep in de archiefkast wordt weggestopt. Als een organisatie servicegericht werkt is het namelijk niet nodig om de responsetijden, clausule bij beëindiging, escalalatiepaden, etc. nog een keer na te zoeken. Een partner neemt de verantwoordelijk dat de gebruikers ‘happy' zijn. De servicemanager heeft een cruciale rol richting de klant als wel naar de interne organisatie. Als een servicemanager van een serviceorganisatie het verzoek krijgt om functionaliteit te leveren, stel dan kritische vragen om erachter te komen of dit echt de vraag is en ga intern na wie dit het meest efficiënt kan leveren. De servicemanager is het verlengstuk van de klant. Dit zorgt er ook voor dat er geen eilandjes ontstaan waardoor de klant steeds een heel stuk moet zwemmen naar een ander eiland (leverancier). Een partner adviseert de klant en zorgt op zijn beurt dat alles onder de motorkap geregeld is op de meest efficiënte wijze.
Experts gezocht
Computable is bezig om al zijn 25 topics te voorzien van een expertpanel. Voor de komende tijd zijn wij op zoek naar experts op de volgende vakgebieden:
Internet: internet@computable.nl
eHRM: ehrm@computable.nl
Besturingssystemen: besturingssystemen@computable.nl
Beleid: beleid@computable.nl
Maatschappij: maatschappij@computable.nl
ICT-branche: ict-branche@computable.nl
Ben jij expert op een van bovengenoemde vakgebieden, stuur dan een e-mail met je gegevens (naam, functie, bedrijf, werkzaamheden) naar het bijbehorende e-mailadres.