Wanneer u googled op internet zijn diverse voorbeelden te vinden. Helaas is het invullen ervan nog geen garantie voor een gedegen contract. De aard van de afspraken hangt namelijk sterk af van de door u afgenomen dienstverlening en de aard van uw ICT omgeving. Gezien de behoefte trachten we de komende weken, in een aantal artikelen, helder te maken waarop u dient te letten bij het opstellen en afsluiten van een Service Level Agreement.

Deel 1: Welke relatie gaat u aan?

Alvorens een contract aan te gaan is het belangrijk om na te gaan welke verantwoorlijkheid u zelf wilt behouden en welke verantwoordelijkheden u bij uw leverancier(s) wilt beleggen. Pas wanneer dat helder is kan op een goede manier bepaald worden welke eisen u heeft aan het contract met de leverancier.

Voorbeeld vragen hierbij zijn:

a. Wat is de scope van de omgeving waarvoor u een Service Level Agreement wilt afsluiten? Is het een website, de website inclusief externe koppelingen? Een SAP systeem? Of zijn het de werkplekken inclusief kantoorapplicaties? Probeer hiervan een zo helder mogelijk beeld voor uzelf te schetsen.

b. Voor welke diensten wenst u een Service Level Agreement af te sluiten? Is dat voor de instandhouding van de maatwerk applicaties, de doorontwikkeling ervan of wilt u alleen afspraken vastleggen over bandbreedte en hosting van uw servers? Zie ook onderstaande afbeelding:

c. Is de leverancier verantwoordelijk voor de gehele piramide (zie afbeelding) of zijn er delen waarvoor u als organisatie zelf de verantwoordelijkheid wilt dragen of waarvoor derde leveranciers verantwoordelijk zijn?

d. Als er meerdere partijen bij betrokken zijn, is er dan één leverancier die de verantwoordelijkheid voor het geheel draagt of draagt uw eigen organisatie deze verantwoordelijkheid?

Probeer het totaalplaatje zo helder mogelijk voor uzelf op een rij te zetten. Dit zal u in de gesprekken binnen uw eigen organisatie en met leveranciers veel onduidelijkheid en misverstanden besparen. Ook vormt het een mooie aanzet tot het aangaan van een eerste gesprek over de inrichting van een SLA.

Volgende week deel 2: Generieke contract componenten

Hierin beschrijven we de contract componenten die in iedere Service Level Agreement thuishoren, ongeacht of u te maken heeft met een onderhoudscontract, een hostingcontract of een applicatiebeheer contract.

Heeft u naar aanleiding van dit artikel vragen of ondersteuning nodig? Neem dan beslist contact met ons op.

Deze nieuwe site luidt het begin in van “Wu Wise demand management services”. We gaan organisaties ondersteunen bij het uitvoeren van hun IT demand management rol, ofwel bij het aansturen van hun opdrachtnemers, hun IT leveranciers. Dit doen we door te kijken naar gemeenschappeljk belang, door samenwerking te stimuleren, orde in de chaos te scheppen en onbegrip uit de weg te ruimen. Duidelijk afspreken van verantwoordelijkheden is daarbij cruciaal, het eigen straatje schoonvegen niet. Want zo lang we bezig zijn met het zoeken van schuldigen van problemen, zijn we niet bezig met het oplossen ervan.

We wensen u veel plezier op onze website en nodigen u uit de live chat te proberen, onze diensten te bekijken, te reageren op berichten, u te abonneren op de nieuwsbrief en natuurlijk vooral binnenkort nog eens terug te komen. En kunt u wel wat hulp gebruiken bij het aansturen van uw leveranciers? Neem dan beslist contact met ons op.

Hartelijke groeten,

Irene Gelhard & Nicky Hoenderboom

Van jongs af aan leerden onze ouders ons al dat we vervelende of spannende dingen een beetje makkelijker kunnen maken door wat afleiding. De gehate vork-met-spruitjes-en-aardappel werd door moeder omgetoverd in een vliegtuigje, dat voor je het wist in je maag was verdwenen. En op de avond voor die eerste enge spreekbeurt wist vader een verhaaltje voor te lezen, dat zo geruststellend was, dat je optreden bij voorbaat al een daverend succes was.

Hoewel in het algemeen niet erg gewaardeerd door onze leraren, werd het afleiding-zoeken er naar mate we ouder werden alleen maar erger op. Propjes schieten, briefjes, agenda's volkalken, alles leuker dan een saaie les. Hoe saaier de les, hoe meer afleiding er gezocht werd. Een enkele keer kon een les zo leuk zijn dat afleiding niet nodig was, die lessen waren voor de meeste studenten helaas vrij zeldzaam.

Als volwassene doen we weliswaar een stuk serieuzer maar in weze zijn we niet veel anders. De briefjes zijn vervangen door Twitter, LinkedIn en e-mail of gesprekken bij de koffieautomaat en de geruststellende verhaaltjes van onze ouders hebben plaats gemaakt voor een glas wijn of een middag sauna in stressvolle tijden. Het werkelijk opgaan in ons werk noemen we flow, een magisch begrip dat uitdrukt wat er gebeurt wanneer we datgene wat we aan het doen zijn zo leuk vinden, dat geen afleiding meer nodig is. Het feit dat dit woord een bijna mystieke lading heeft, zegt genoeg over hoeveel, of helaas, hoe weinig 'flow' we daadwerkelijk ervaren met zijn allen.

Naar mijn idee ligt de oorzaak van het maar zo weinig aanwezig zijn van ‘de juiste flow’ in ons werk, in het feit dat we onze afleidingen nogal eens tot doel verheffen, veelal zonder dat we het in de gaten hebben. We gebruiken rapportages om niet in gesprek te hoeven gaan, onderzoek om geen pijnlijke maatregelen te hoeven nemen en bureaucratische processen om te voorkomen dat iemand als verantwoordelijke kan worden aangewezen. Niet alleen gebrek aan ‘flow’ maar ook regelmatig falen van projecten of blijvend ontevreden klanten zijn signalen van een overmatig creëren van afleiding. Hier bedoel ik niet mee dat afleiding verkeerd is. In tegendeel, het is een prettige rustverschaffer of gemaksbrenger. De grote vraag bij afleiding is echter altijd: ‘Waarvan willen we zo graag worden afgeleid, wat is er zo vervelend, naar of spannend dat afleiding nodig is?’

Wanneer we niet op zoek gaan naar het antwoord op deze vraag en de minder leuke momenten of situaties uit de weg blijven gaan, wanneer we de afleiding niet meer kunnen of willen onderscheiden van hetgeen we werkelijk willen bereiken, dan gaat er iets flink mis. Er ontstaan framework-fetishisten (zie deze presentatie voor meer uitleg) die denken dat service over modellen gaat, omdat op mensen zo moeilijk grip te krijgen is. Er ontstaan service level agreements zonder dat klant en leverancier ooit overeen zijn gekomen welke dienst er geleverd gaat worden, omdat de werkelijk gewenste dienstverlening te complex is om te leveren. En wanneer klant en leverancier vervolgens met elkaar in de clinch liggen, gaan ze niet met elkaar in gesprek maar wordt een mooi klachtafhandelingssysteem verzonnen of een jurist geconsulteerd. Over afleiding gesproken…

Dit is doodzonde, want antwoord op de eerste vraag biedt een opening naar het vinden van een antwoord op de volgende, veel meer gehoorde vraag: ‘Hoe kunnen we de noodzaak tot afleiding laten verdwijnen?’, ofwel: ‘Hoe kunnen we ons probleem oplossen?’

Volgens mij zijn de meesten van jullie volwassen mensen. Ik pleit daarom voor het volgende: ga eens voor de groep staan wanneer je dat nog nooit gedaan hebt, gooi nutteloze processen overboord, bekijk je werk, klanten, leveranciers en collega’s eens met alle plussen en minnen die erbij horen en besluit oprecht of je ze in 2010 nog een kans wil geven op leuke, menselijke samenwerking. Kijk wat je daar zelf in kunt doen, proef eens spruitjes. Dat gaat in ieder geval heel veel irritatie, boosheid en onbegrip schelen en misschien, heel misschien, wel een tikkie meer plezier in het werk opleveren… Op naar een mooi 2010!

Dit bericht verscheen eerder in Computable.

Service is een heel fijn modewoord, dat te pas en te onpas in de meest verschillende contexten wordt gebruikt. Zo kennen we bijvoorbeeld webservices, een term waarmee applicatiedeeltjes in een internetomgeving worden aangeduid, software as a service, waarmee meestal een pay-per-use achtig verkoopmodel wordt bedoeld en managed services, een aanduiding voor operationeel beheer van servers, operating systems en aanverwante zaken.

De term service kan dus betrekking hebben op verschillende aspecten van ict: soms zegt het iets over de techniek , soms over de verkoopmethode, soms over de aard van de dienstverlening. Maar wat bedoelen we dan eigenlijk met service? Wat alle drie de voorbeelden in het eerdere rijtje gemeen hebben, is dat getracht wordt een geheel aan delen aan te bieden in een totaalpakket. In het geval van een webservice hebben we het over een pakketje functionaliteit, in het geval van software as a service een pakketje housing, applicatiebeheer, licentie en gebruikersbeheer en in het geval van managed services een pakketje housing, hardware, operating system en beheer.

Goede service zou volgens deze gedachtengang dus betrekking hebben op een pakket aan diensten dat goed aansluit op de behoefte van de afnemer. Kijken we nog eens goed naar het eerder genoemde rijtje dan is één ding echter zeker: in alle drie de gevallen zegt het feit dat iets als service wordt aangeboden niets maar dan ook helemaal niets over de manier waarop de dienstverlening wordt ervaren door de eindgebruiker. Zelfs in het geval van software as a service, veelal geschetst als de ultieme eenvoud voor gebruikers, is lang niet altijd sprake van een tevreden eindgebruiker. Niet alleen de uptime van de service kan te wensen over laten, ook de bereikbaarheid en kundigheid van de helpdesk, de kwaliteit van gebruikersdocumentatie, gebruikersvriendelijkheid van de user interface of mate waarin de applicatie kan worden aangepast aan persoonlijke wensen kunnen van grote invloed zijn op de gebruikertevredenheid. Om de zaak nog wat complexer te maken: veelal kennen we veel meer gebruikers dan alleen eindgebruikers.

Een website kan enorm tevreden bezoekers kennen, wanneer de redactie niet overweg kan met het achterliggende contentmanagementsysteem of de systeembeheerder eeuwen bezig is met het doorvoeren van een update, hoe is het dan gesteld met kwaliteit van de totale service? Service is goed, service is geweldig. Maar laten we voortaan, voordat we iets service noemen, eerst eens benoemen wie de afnemers van onze service zijn. En laten we vervolgens, voordat we een SLA of product-dienstcatalogus opstellen eerst eens een uurtje in gesprek gaan met iedere gebruikersgroep, over wat ze wel, en juist niet van ons verwachten. Daar krijgen we veel betere ict-service mee.

Dit artikel verscheen eerder in Computable .

De kaart is niet het gebied. voor diegenen die zich met NLP (Neuro-Linguistisch-Programmeren) bezig houden een bekende term. Hoewel het woord programmeren toch veel IT-ers zou moeten aanspreken, ben ik bang dat de term weinigen van ons iets zegt.

De bedenkers van NLP hebben met deze uitspraak duidelijk willen maken dat een gebied, een omgeving, meer is dan hetgeen kaartenmakers op een landkaart hebben getekend. En dat is maar goed ook, want wanneer kaartenmakers álles wat er is op één en dezelfde kaart zouden zetten wordt het een zootje. Wanneer je echter echt wil weten hoe het in een bepaald land is, moet je er naar toe. Je moet er kunnen voelen hoe warm het is, het eten kunnen proeven en de verhalen van de bewoners horen. En wanneer je écht wilt weten wat er allemaal speelt, is het ook handig ergens een poosje te blijven, je te mengen onder de bevolking en je ogen en oren hun werk laten doen. Dit alles kun je niet met een kaart.

Hier kunnen we in IT land iets van de bedenkers van NLP leren. We maken de mooiste modellen, de prachtigste boeken en verzinnen het ene stappenplan na het andere. Wat we nog wel eens willen vergeten, is dat in iedere context weer andere belangen spelen en iedere mens weer anders reageert. Sommigen noemen dat politiek. Om echt te kunnen begrijpen wat er speelt heeft het geen zin uitvoerig de kaart of het model te bestuderen. We moeten de vloer op, écht in gesprek, dan komen we er – soms snel, soms iets minder snel – pas achter wat er daadwerkelijk speelt en kunnen we ook oplossingen vinden die daadwerkelijk zoden aan de dijk zetten.

Misschien is je klant door zijn laatste leverancier enorm teleurgesteld en wil hij daarom nu iedere onbenullige afspraak die hij met je maakt zwart-op-wit hebben. Misschien functioneren sommige afdelingen beter dan andere omdat de medewerkers zich gesteund voelen door hun leidinggevende. Misschien heeft dat wel niets met de volwassenheid van de organisatie of de gebruikte processen te maken. Misschien toont de business wel zo weinig betrokkenheid omdat zij andersom niet het gevoel heeft dat de IT wil meedenken met háár wensen en behoeften. En misschien houdt diezelfde IT afdeling wel zo strak vast aan alle regels en procedures omdat van hogerhand is aangegeven dat daar aan het einde van het jaar op zal worden beoordeeld.

Wanneer we met zijn allen naar de oppervlakte blijven kijken, naar datgene wat we in eerste instantie waarnemen, zullen we het nooit weten. Wel kunnen we met vingers naar elkaar blijven wijzen tot we een ons wegen, maar echt veel schieten we daar nou ook weer niet mee op.  Van mij mag 2008 het jaar worden van het echte gesprek en het echte begrip in plaats van het zoveelste alignment model… wie doet er mee?

Verscheen eerder in Computable