Jarenlang hadden hardwerkende bankiers alle financiële touwtjes stevig in handen en werden er flinke en degelijke resultaten geboekt, tenminste zo leek het. De touwtjes, ja die hadden ze stevig in de hand en ook de winsten waren er, 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.
Jarenlang hebben bedrijven gewerkt met een groot aantal serviceproviders die de touwtjes stevig in hadden hadden. De laatste jaren echter zie je de trend dat meer en meer bedrijven hun services geconsolideerd afnemen van één of slechts een beperkt aantal serviceproviders. Hoe dan ook, bij elke constructie die wordt gekozen heb je te maken met het maken van afspraken en/of het opstellen van contracten.
Zo'n contract, 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.
Een voorbeeld ter illustratie. In nagenoeg 100 procent van de huidige SLA's staat zoiets als 'een prio 1-incident moet worden opgelost binnen acht uur' vermeld. Op zich geen probleem als de service-organisatie daarop is ingericht en alle betrokken partijen zodanig samenwerken dat ze die acht uur ook echt halen zodat de business hun activiteiten weer kunnen voortzetten. Hierin schuilt echter een veelvoorkomend probleem.
Door de huidige setup van veel serviceproviders (veel kleine groepen met elk hun eigen capaciteit) is het vaak onmogelijk om alle schakels zodanig te laten samenwerken dat de acht uur ook daadwerkelijk wordt gehaald. De zogenaamde 'servicesilo's' weten vaak niet eens waarom ze een incident snel moeten oplossen en wat de businessconsequentie is als de oplossing op zich laat wachten. Als er een eenvoudig recept bestond om dit op te lossen, dan was de recessie wellicht ook al lang onder controle of was deze niet eens uitgebroken. Het is schijnbaar niet eenvoudig, temeer omdat het een samenspel betreft van vele facetten binnen een service-organisatie.
Een goede start kan echter al gemaakt worden door niet meer met 'serviceproces-driven' SLA's te werken maar over te stappen naar een 'businessproces-driven' SLA. Hierbij zorg je ervoor dat er geen eilandjes ontstaan voor 'incidentmanagement', 'probleemmanagement', 'capacitymanagement', etc. met elk hun eigen verantwoordelijke manager, maar dat er teams ontstaan die een volledig businessproces van hun klant ondersteunen. Bij de steeds complexer wordende omgevingen is het dus niet langer van belang 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.
Overstappen van de eens zo goed werkende 'serviceproces' SLA naar een recessiebestendige 'businessproces' SLA is daarom 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.
Kleine correctie:
“Jarenlang hadden hardwerkende bankiers alle financ�le touwtjes stevig in handen en werden er flinke en degelijke resultaten geboekt”
Degene die het BANKSYSTEEM (zelf wel virtueel geld hebben, het alleenrecht op de geldhandel, geld uitlenen aan anderen en met MEER RENTE terugkrijgen of kunnen vorderen, via wet, beslaglegging!!) hebben uitgedacht, hebben er hard voor gewerkt dat de gehele wereld nu van – de door henzelf geschapen – structuur afhankelijk is en blijft.
De rest van de “bankiers” copieert dit (banksysteem moeder) kunstje en houd hun handjes op om de rente te vangen of je huis in te pikken als je het niet meer kunt opbrengen… Das echt hard… een ander laten werken voor jouw winst.. Slim systeem zonder SLA’s..om al slapen rijk te worden over de rug van een ander
Waar het naar mijn idee tijd voor wordt is het gebruiken van een SLA waar een SLA voor bedoeld wordt. Het kan al een heel stuk helpen als iedereen de juiste (!) terminilogie gebruikt. Valkuil nummer 1 staat in dit artikel. “Een contract tussen een Service Provider en een afnemer wordt SLA genoemd.” Een SLA is een “agreement”, een overeenkomst tussen onderdelen van 1 organisatie. Vaak tussen de ICT afdeling en de gebruikersorganisatie. Aan een interne overeenkomst zitten geen juridische consequenties en de financiele 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 plaats vindt tussen leverende organisatie (ICT) en de afnemende organisatie (de klant). En 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 gebeurd komen er SLA’s die vanuit de business worden gevoed en reeele afspraken bevatten die ICT ook daadwerkelijk kan nakomen. Inderdaad de SLA’s waarin een beschikbaarheid van 99,9% 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 de dienst moeten leveren (tactische processen) zien we nergens. Dat veranderen (in gedrag) maakt SLA ene krachtig instrument. Een crisis is daar niet voor nodig.
Op zich een aardige vergelijking die je probeert te leggen. 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 service management organisatie niet meegroeit om deze complexiteit te kunnen managen, krijg je het probleem dat je beschrijft.
We zien op dit moment dat technologie bedrijven – als VMware, Cisco en EMC – technische oplossingen in de markt brengen om deze complexiteit wat betreft service leverantie te virtualiseren. Maar 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 heb je gelijk dat – zoals je zegt – ‘het is dus niet langer van belang dat een individueel ticket binnen 1 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.’ En – zoals ik zei – 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.
Hans Timmerman, EMC Nederland
Patrick doet een voorzet om de aansluiting tussen business en beheer te verbeteren en pleit daarbij voor bedrijfsprocesgerichte teams. Helaas houdt hij daarbij geen 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 die Patrick voorstelt 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 netwerk specialist, een DBA’er, een email specialist, een storage specialist, een java ontwikkelaar, een user interface ontwerper, etc. Omdat dit in de meeste situaties te duur is zullen Patricks 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 eten gooien in de vorm van afstemmingsproblemen tussen de twee soorten teams…
In bovenstaande analogie vergeet Patrick 1 cruciaal aspect: vertrouwen. Waar het nu aan schort in de financiele sector is vertrouwen; vertrouwen van de consument en aandeelhouder, maar ook vertrouwen tussen dienstverleners onderling (interbancaire leningen) of zelfs in het volledige financiele systeem. Juist in deze situatie leunt de business vooral op de inbreng van haar leveranciers, met IT 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 IT. Dus niet alleen maar vooraf vastleggen wat IT minimaal moet doen (SLA), maar juist die stap extra zetten om het vertrouwen van de business te winnen. Denk hierbij aan IT-gedreven initiatieven voor kostenbesparing, snellere time-to-market of imagoverbetering.
Daarbij is businesskennis natuurlijk meer dan welkom, dus de door Patrick genoemde bedrijfsprocesgerichte teams kunnen wel degelijk (bijvoorbeeld als taskforces) worden ingezet om concrete verbetervoorstellen te operationaliseren. Of deze bedrijfsprocesgerichte teams ook in de dagelijkse operatie efficient zouden werken, ligt volledig aan de te behalen doelstellingen, omvang en complexiteit van de IT-organisatie en het IT-landschap.
Door op deze wijze vertrouwen te wekken en behouden, hoop ik dat IT’ers volgend jaar niet op witte gympen door de binnenstad hoeven, om te voorkomen dat ze worden herkend en aangevallen door woedende demonstranten?
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 niet 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 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 2 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 archief kast wordt weggestopt. Als een organisatie Servicegericht werkt is het namelijk niet nodig om de responsetijden, clausule bij be?indiging, escalalatiepaden 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 de 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, zoals Patrick beschrijft, 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.
Melle Lelieveld, Winvision
Even een stapje terug. Wat is er aan de hand? Er is toename van complexiteit, zowel van de systemen die beheerd worden als de IT-organisatie die het beheer uitvoert ?n de gebruiksorganisatie die de IT aanstuurt. Patrick focust op de organisatorische aspecten. Daar zie je decentralisatie van sturing aan de vraagzijde en meer verscheidenheid in de vraag. En 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 Service Management.