'Stel, er is een computer stuk in een operatiekamer en volgens de SLA moet die binnen vier uur zijn vervangen', zegt Richard Kamman, informatiemanager bij het Amphia Ziekenhuis. 'Als de ict'er vervolgens na 3:59 minuten aan komt met de nieuwe computer, dan doet hij volgens de regels zijn werk goed. De statistieken zien er fantastisch uit, maar eigenlijk is alsnog niemand tevreden. Immers moet een computer op zo'n belangrijke plek zo snel mogelijk vervangen worden.'
Kamman mist de waarde van service level agreements (SLA's). 'Het is gewoon een protocol wat gevolgd wordt, terwijl er in noodsituaties veel meer nodig is dan dat. De ict'er moet weten wat er gaande is en daarop inspelen. Dat wordt hem of haar extra moeilijk gemaakt door het op afstand beheren van de ict-apparaten binnen het ziekenhuis. Daarom moet de ict'er meer in gesprek gaan met de klant. Ik noem het graag nazorg voor het proces. Als je iets aanlevert, vraag dan of het echt is wat de klant wil, in plaats van ervan uit gaan dat je de opdracht goed hebt voltooid.'
Het Amphia Ziekenhuis maakt gebruik van een elektronisch patiëntendossier (EPD) met software van het Amerikaanse Epic Systems Corporation. 'Ik denk niet dat veel ziekenhuizen mee zullen gaan met het landelijke EPD. Het regionale schakelpunt is een stuk interessanter. We hebben zelf een intern EPD om patiënten te registreren, onderzoeksresultaten bij te houden etc. en gaan dat regionaal gezien uitbreiden. Dat legt een grote druk op de ict'ers binnen de organisatie.'
Tablets en Wi-Fi
Sowieso verwacht Kamman een grote klus voor de ict-afdelingen van zorginstellingen. 'Vroeger werkten we met honderd solitaire ziekenhuizen en nu worden dat steeds grotere organisaties. Langzaam verandert alles naar netwerklocaties en dat betekent dat de ict de zware taak krijgt om te zorgen dat alle netwerken met elkaar in verbinding staan en dezelfde functionaliteiten kennen. Die ontwikkeling moeten we in de gaten houden'.
Momenteel wordt het Amphia Ziekenhuis verbouwd, waardoor de ict een achterstand oploopt. 'Ik zie het als een grote achterstand dat we nog geen Wi-Fi in het ziekenhuis hebben', zegt Kamman. 'Ik verwacht dat binnen enkele jaren zorgverleners allemaal met tablets rondlopen. Van de EPD-software bestaat ook een app die wij nog niet gebruiken, maar die op een tablet fantastisch tot zijn recht moet komen.'
Beveiliging
Er komen daar natuurlijk voor de ict-beveiligingsvraagstukken bij. Hoe zorg je dat mensen je patiëntgegevens niet mee naar buiten nemen? Kamman: 'Wederom een zwarte taak voor de ict. Ik vind dat je moet kunnen aantonen dat je je best hebt gedaan het geheel zo veilig mogelijk te maken, maar als mensen inbreken of misbruik maken, dan zij het zo. Het allerveiligste is om alle ict uit te zetten en dat is natuurlijk geen optie.'
Volgens mij is het een kwestie van juiste afspraken maken. Indien je vindt dat op een OK een computer zo snel mogelijk gemaakt moet worden kun je dat toch gewoon in een SLA afspreken.
Verder denk ik dat het goed is om moderne technologie in te zetten op het moment dat dit nodig is. Beveiligingsproblematiek is oplosbaar. Het gaat er maar om hoe je dit bekijkt.
Als een PC (of applicatie) zó cruciaal als hier geschetst, mag ik toch hópen dat je een continu beschikbare uitwijk hebt of een afdoende alternatief?
Op zich herken ik het fenomeen wel dat SLA(‘s) een soort van ICT-protocol vormen. Maar, ze moeten gaan over beschikbaarheid van functionaliteit in het primaire proces. Dus, gemeten op het aantal verstoringen dat gebruikers melden op (een van) de systemen.
Zeker wel afspraken maken dus! Niet over hersteltijden en -acties, maar aanspreken van het ICT vakmanschap op zoek naar mogelijkheden om het primaire proces te op een volwassen manier te ondersteunen.
Overigens een heel reële houding t.a.v. beveiliging: zet alles in het werk, maar houd wel in het oog dat je zelfs dan nog geen garanties hebt…
De A is van Agreement. Een afspraak tussen klant en leverancier over het niveau van dienstverlening. Het is (zo veel mogelijk) de vastlegging van de (veelal impliciete) verwachtingen van de klant. Voor een OK zijn er natuurlijk andere verwachtingen dan voor een administratieve PC. Dat zou dan ook naar voren moeten komen in de SLA. Eventuele maatregelen om die diversiteit in dienstverlening te kunnen adresseren kunnen door ICT aangegeven worden: bijv. een extra computer plaatsen, of sneller vervangen, etc.
Belangrijk is dus dat het spel vraag-aanbod goed gespeeld wordt en impliciete verwachtingen expliciet worden in de SLA.
Akkoord met Maarten.
Indien geen downtime gepermitteerd is moeten andere technische middelen ingezet worden i.p.v. een ordinaire vervanging binnen de 4 uur. Daartegenover staat natuurlijk een prijs. En wat blijkt nogal dikwijls? De business wil wel een hoge beschikbaarheid,
maar is niet bereid om daarvoor de prijs te betalen…
Spreek voor de OK dan een scherper Service Level af! Daar hoort dan ook een hoger kostenplaatje bij. Dat is dan wel de consequentie. Als je gebruik wilt maken van de generieke SLA met een laag kosten-nivo dan is het ook niet zo gek om net als anderen de generieke dienstverlening krijgen. SLA’s zijn dus niet zo gek. Maar spreek de juiste SLA’s af en accepteer dat er hogere kosten verbonden zijn aan een scherpere SLA.
Edwin wil voor de OK een scherper SLA en neemt de kosten voor lief.
Dat is nu net het probleem van al die SLA’s met externe dienstverleners! Het wordt een papieren exercitie, met tabellen en grafieken hoe de ICT dienstverlener acteert op de vragen van de klant, De dienstverlener verliest de feeling met de klant (papier only he?) en de klant voelt zich onbegrepen.
Als een klant, door een hoog afbreukrisico (zoals een ziekenhuis), nu zo veeleisend is (en terecht), neem dan de regie weer in eigen hand! Dus gooi de ICT dienstverlener eruit, neem weer eigen mensen aan met feeling en hart voor het bedrijf en je zult zien dat de dienstverlening weer op rolletjes loopt.
Inderdaad, gewoon een kwestie van een slecht SLA (of een slechte dienstverlener die niet wil werken aan de hand van andere dan zijn standaardservicelevels).
Wellicht niet dekkend in -1- keer voor elke situatie, maar met behulp van een goede Plan-Do-Check-Act cyclus moet je als organisatie toch behoorlijk helder kunnen krijgen wat het moment is waarop je tevreden bent. Misschien moet je als organisatie dan ook wel andere (softere)indicatoren als tevredenheid etc benoemen.
Pas als je als organisatie grip op je processen hebt, dus: goede controls, goede monitoring en bijsturing, kun je met deze gegevens de SLA’s met leveranciers bijstellen. En dit zou een strakkere (lees vaak duurdere) SLA kunnen zijn, maar wellicht kom je tot de conclusie dat de bestaande SLA veel te strak is ingezet en wellicht goedkoper zou kunnen.
Dit is overigens niet alleen op ICT van toepassing, maar speelt ook in andere processen zoals: kwaliteitsmanagement, patiensveiligheid, informatiebeveiliging.
@PeterJ: Niet eens met het feit dat het zonder meer aan de (externe) dienstverlener ligt. Immers de externe dienstverlener heeft een belang bij een tevreden klant. Als de klant niet tevreden is heeft de dienstverlener een probleem.
@ Machteld: Kan ook zijn dat de dienstverlener wel van goede wil is, maar dat de organisatie (nog) onvoldoende weet wat ze wil. Dan is het natuurlijk wel lastig om ‘dekkende’ SLA’s te maken.
Wat een onzin al dit soort discussies over een SLA in levensbedreigende situaties. Iemand ooit gehoord over een SLA in de cockpit van een vliegtuig? Heb ooit de dealing room van een bank mogen inrichten en daar stonden gewoon dubbele pc’s zodat als er een stuk ging er geen probleem was.
En wat is trouwens de business case van een noodaggregaat in een ziekenhuis?
Het krampachtig vasthouden aan de letter van een SLA (hoe strak je e.e.a. ook afspreekt) getuigt van een gebrek aan flexibiliteit en klantgerichtheid. De tevredenheid bij klant-opdrachtgever en klant-gebruiker over een dergelijke leverancier verschilt vaak als dag en nacht. Je loopt dan het risico dat “de operatie geslaagd is maar de patiënt is overleden”.
Interne en externe (ICT)leveranciers die hier aan vasthouden gedragen zich als cost center ipv als value adding center en zullen door hun klant als zodanig worden behandeld.
@PeterJ: het (on)nut van een SLA is niet 1:1 gelinkt aan het feit of een leverancier intern of extern is. Ik kom daar in het artikel ook niets over tegen.