'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.'
In mijn ogen is een SLA vooral iets om je, als leverancier, achter te kunnen verschuilen als het wat langer duurt dan wat de klant verwacht had. Kijkend naar het voorbeeld van Richard Kamman: hij verwacht meteen geholpen te worden, maar moet in het ergste geval 4 uur wachten.
Het nadeel van het uitbesteden van dit soort dingen, en afspraken maken via een SLA is dat de betrokken monteurs en SLA managers niet betrokken zijn bij hetgeen de klant doet.
De monteur krijgt een melding, ziet dat ‘ie 4 uur de tijd heeft, dus eet nog even op z’n gemak, legt de kinderen op bed en gaat dan eens op z’n gemak richting ziekenhuis. Verzin er zelf nog e.e.a. bij, maar die 3u59 krijgen we wel vol. De monteur is zich van geen kwaad bewust. Ook de SLA-manager is weer helemaal tevreden, alles binnen de afgesproken 4 uur gehaald.
Maar nu krijgt de vader van de SLA-manager een hartinfarct, en moet accuut gedotterd worden. Helaas heeft het röntenapparaat wat hiervoor gebruikt moet worden een storing, en de monteur is al opgeroepen, maar blijft nogal lang weg. Na 3u59 minuten hoort de SLA manager dat het probleem verholpen is, en dat zijn dierbare vader eindelijk geholpen kan worden. Helaas is het hart onherstelbaar beschadigd, waardoon na het dotteren nog operaties nodig zijn enz enz enz….
Is dezelfde SLA-manager nu nog zo tevreden over die 4 uur ?
Het is inderdaad een kosten-baten verhaal, maar bijvoorbeeld de röntgenapparaten die gebruikt worden bij dotteren of aneurysma’s kosten soms meer dan 1 miljoen euro. Wanneer je als (klein) ziekenhuis op de kosten moet letten, zet je die er niet even een 2e naast (nog even los van de extra kosten voor het inrichten van een 2e behandelkamer)
Ook het hoger kostenplaatje voor een snellere service volgende de SLA kost vaak onevenredig Voor die meerprijs is het vaak rendabeler om een stukje ICT ondersteuning in eigen huis op te zetten. Voordeel is ook dat je dan vaak wel betrokken personen in huis kunt krijgen.
Overigens hoort hier wel een kanttekening bij: instellingen als ziekenhuizen hebben in hun CAO vaak geen rekening gehouden met een ICT-expert, waardoor deze soms onderbetaald worden voor het werk wat ze verzetten. Ook hier zal over nagedacht moeten worden.
Ik snap de zorgen van Kamman, die overigen goed verwoord zijn. Maar toch ik krijg een kromme-tenen-gevoel bij dit artikel.
Als de opdrachtgever wat anders krijgt dan verwacht, dan had deze dat eerder vast moeten leggen (dat had meestal ook gekund en dus gemoeten), En ander moet de SLA gewoon aangepast worden. Niet de SLA maar wat nodig is, moet centraal staan. Wil je bijvoorbeeld voor sommige situaties een korte maximale oplostijd, dan moet je dat expliciet vastleggen en niet alleen de gemiddelde korte oplostijd.
Een SLA moet na een tijdje van proefdraaien meer dan 99% van de werkelijke situaties dekken. Die situaties moeten van te voren door de opdrachtgever en opdrachtnemer (en onderliggende partijen) bedacht zijn, vanuit de ervaring en expertise van beide zijden. Daarbij is het belangrijk om samen van te voren ook worst case scenario’s te bespreken. Zo kan het bijvoorbeeld voorkomen dat de geteste reservecomputer van de operatiekamer het ook niet doet op het moment suprême.
Natuurlijk zijn situaties die men niet van te voren had kunnen bedenken en dan moet je creatief samenwerken.
Overigens, SLA’s zijn geen protocollen maar afspraken over dienstenniveaus. De protocollen worden toegepast om aan de SLA’s te kunnen voldoen.
Een SLA is niet meer dan een stuk gereedschap en zoals met ieder stuk gereedschap moet je er ook mee om kunnen gaan om het nuttig te kunnen gebruiken.
Als je op de OK’s binnen een half uur (NB. kantoortijden / 7×24) een nieuwe PC wilt hebben, dan kan je dat vastleggen en staan daar kosten tegenover.
Over het algemeen ligt het plaatje nog veel complexer en wil je bv. dat een uitval van van je applicatie op die computer met toegang tot je patientinformatie niet langer dan 30 minuten duurt. Daarvoor zal je al de complete keten van afhankelijkheden moeten meenemen en dan niet alleen hard- en software, maar ook je beheerders, changeproces enz.
Dan ben je er nog lang niet. Proactief monitoren om fouten te voorkomen, SLA monitoren op rapporteren en bijsturen (inderdaad PDCA). Disaster Recovery regelmatig testen en bijsturen.
Tja, allemaal veel te duur en complex, dus we doen toch alleen maar SLA’s en klagen achteraf als het mis gaat en roepen dan dat het beter moet.
[citaat] ‘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.’
Door alle onzin over SLA’s in operatiekamers (goede afspraken maken hoort bij de taak van de manager!) die dhr Kamman verkondigt, let niemand meer op de zeer verontrustende uitspraken in de laatste alinea.
Dit soort denkwijzes toont aan waarom bijvoorbeeld een landelijke EPD zo’n slecht idee is. De verantwoordelijke managers verschuiven hun eigen verantwoordelijkheid naar de ICT-afdeling en gaat het mis ‘het zij zo’. Tijdens ontwerp en realisatie op de benodigde maatregelen willen besparen, onvoldoende controle uitvoeren en als het mis gaat wijzen naar de uitvoerder. ‘Het zij zo, het ging onze pet te boven….’
Volgens mij wil ik in deze sector helemaal geen SLA.
Ik wil een toegewijde, bij voorkeur lokale, ICT-er, die begrijpt dat er mensenlevens op het spel kunnen staan (in het geval van de OK) en privacy van mensen geborgd moet kunnen worden (in het geval van een EPD).
Niks geen SLA waarachter men zich kan verschuilen mocht het wat langer duren dan verwacht, of als er een foutje gemaakt wordt. Sommige dingen moet je niet uit willen besteden.
PaVaKe, wat denkt u, wie verschuilt zich achter de SLA; degene die de SLA primair opgesteld heeft (de opdrachtgever) of de opdrachtnemer (en dat kan een interne zijn)?
En wat denkt u, zou die toegewijde, bij voorkeur lokale ICT-er er geen baat bij hebben dat van te voren bekend is wat er van deze ICT-er en diens collega’s (en subcontractors) verwacht wordt?
Proactief gezamenlijk nadenken over wat nodig is, wat kan gaan gebeuren en wat dat kan betekenen, is heel belangrijk. Dan leer je elkaars problematiek, kunnen en beperkingen kennen en kunnen nieuwe oplossingen bedacht worden.
De aanwezigheid van loyale ICT-ers met de juiste expertise, is zoals bekend, wel een vereiste, maar geen garantie. Ik heb wel meer SLA’s gezien die niet werken of die niet (kunnen) nagekomen worden.
@John van Voren
Mag ik jouw vraag beantwoorden met een wedervraag: waarom moeten we dit allemaal vast gaan leggen in een SLA?
Is dit niet gewoon “doen waar je voor betaald wordt”?
Wat er van mij verwacht wordt staat aan de ene kant in mijn functieomschrijving, en aan de andere kant wordt er van mij een stuk professionaliteit verwacht om hier op de juiste manier invulling aan te geven.
Zeker voor interne partijen zou dit niet nodig moeten en mogen zijn. Ze dienen immers allemaal dezelfde baas, en daarmee als het goed is ook hetzelfde belang.
Ik heb het helaas in de praktijk gezien: de ene interne partij moest voor iedere “klus” een projectovereenkomst hebben met het hoofdproject voordat ze iets deden. Het schrijven en laten ondertekenen van deze overeenkomst kostte ongeveer 4 keer zoveel tijd als de hoeveelheid werk die uitgevoerd moest worden. Zo worden projecten dus helaas onnodig duur…..
PaVaKe, ik snap uw frustraties niet m.b.t. de SLA’s, beheerafspraken, diensten niveauovereenkomsten, of hoe men de afspraken ook wilt noemen. “Gewoon doen waar je voor betaald wordt” is niet zinnig zonder eerst afspraken te maken. Men moet toch het “waar voor” kennen. Anders gaat de ICT-er op de stoel van de opdrachtgever zitten. Het lijkt me niet erg slim als de IC-er gaat beslissen of een medisch team op een bepaald moment een bepaalde ICT-dienst nodig heeft.
Werken zonder goede afspraken is als een voetbalwedstrijd van kleine jongetjes, waarbij iedereen enthousiast achter de bal aanholt. F-junioren leren al dat dit niet al te slim is omdat dan niet doelgericht en dus niet als team gewerkt wordt. Waarom zouden volwassen en doorgaans goed opgeleide ICT-ers beheer en projecten niet heel veel slimmer aanpakken?
De klant (ook de interne) bepaalt wat geleverd moet worden (moet het betalen/financieel verantwoorden), de ICT-er als professional bepaalt hoe het ICT-werk gedaan moet worden om het door de klant gewenste product of dienst op te leveren.
PaVaKe, vreemd genoeg accepteert u wel een functieomschrijving. Een functieomschrijving is een nogal generieke omschrijving van met name de TBV’s. Het heeft zijn beperkingen. Hoe gedetailleerder men de functieomschrijving maakt, des te eerder is deze weer achterhaald; zelfs bij een output gerichte functieomschrijving. Buiten de ambtenarij en trendvolgers wordt de functieomschrijving daarom amper gebruikt. Daar wil men niet dat men zich achter een functieomschrijving kan gaan verschuilen. Dat indekken ziet je vooral in de softe sector; zie uw eigen voorbeeld.
(Overigens vraag ik me af waarom de interne opdrachtgever niet snel kan en wil tekenen als de werkzaamheden nodig zijn. Als ik een auto van een halve ton koop, dan komt er ook niet eerst een contract in staat wat voor een soort bouten gebruikt moeten worden om de spatborden vast te bevestigen.)
Gezien de vele omvangrijke kostenoverschrijdingen bij ziekenhuizen, lijkt het me juist goed als er afspraken gemaakt worden en verifieerbaar nagekomen.
@John van Voren
Die frustratie, zoals jij het noemt, komt vooral voort uit ervaringen dat men een SLA vooral gebruikt (of liever nog: misbruikt) om dingen niet te hoeven doen of niet zo snel als de gebruiker verwacht.
Op het moment dat je wel alles wil of dingen sneller wil, betaal je als klant meteen de hoofdprijs.
Ook heb ik een aantal ervaringen met SLA’s die afgesloten zijn door SLA-managers of hoe ze zich dan ook willen noemen, die geen idee hebben van de impact van hun keuzes.
Een leuk voorbeeld hiervan is één van mijn vorige banen, waar we 24uurs ondersteuning moesten bieden op de backbone van het bedrijfsnetwerk.
Op een ochtend, rond 07:15u kon ik niet inloggen. Echter, de helpdesk van ons lokale netwerk was pas om 09:00u aanwezig.
Navraag bleek dat de extra kosten om deze ondersteuning al om 07:00u te laten beginnen onevenredig hoog waren.
Dat onze afdeling daardoor niet de 24uurs ondersteuning kon bieden was “bijzaak” in de ogen van die SLA-manager
(in dit geval moesten we dus maar zelf naar het datacentre toe om daar rechtstreeks op de backbone het probleem op te gaan lossen)
Grappig overigens dat je een functieomschrijving wel ziet als iets om je achter te verschuilen, maar een SLA niet. Wat dat betreft zijn deze 2 vergelijkbaar.
Ze beschrijven beiden een raamwerk met daarin hetgeen je geacht wordt te doen. Op het moment dat het er niet in staat kun je 2 dingen doen:
– je erachter verschuilen, niets doen onder het mom van “dat is niet afgesproken” –> dit leidt dus tot de eerder genoemde frustratie
– het probleem binnen de grenzen van je kunnen en mogelijkheden oplossen om daarmee je klanten/collega’s/organisatie verder te helpen –> dit is de proffesionele houding die ik verwacht, maar helaas niet zo vaak meer tegenkom.
@PaVaKe, de verwachte diensten niet krijgen betekent doorgaans dat de opdrachtgever de verkeerde eisen heeft gesteld. En die opdrachtgever is niet de SLA-manager. Aangezien opdrachtgevers bij een ziekenhuis hoog tot heel hoog opgeleid zijn, mag van hen verwacht worden dat ze heel goed in staat zijn om vast te stellen wat ze nodig hebben, wat ze daarvoor kunnen betalen, et cetera.
De SLA-manager moet leveren wat afgesproken is en wat als afgeleide daarvan verwacht mag worden. Natuurlijk moet de SLA-manager intensief meedenken met de klant, de opdrachtgever goed voorlichten over de functionele aspecten (en dus beperkingen). Verder moet deze vooral open staan voor aanpassingen van de SLA.
Een SLA manager mag nooit bepalen of een beperking van ICT-diensten slechts een bijzaak voor de opdrachtgever zou zijn. Dan gaat die SLA manager op de verkeerde stoel zitten.
Eén van de kritische factoren is dus goede communicatie tussen beide partijen, ongeacht of er uitbesteed wordt. Men moet elkaar aanvullen en kunnen vertrouwen. Een hoofd ICT van het Assens ziekenhuis vertelde me eens dat specialisten heel moeilijk in de omgang zijn. Vanuit zo’n uitgangssituatie is het lastig om de heldere en haalbare afspraken te maken, laat staan SLA’s gezamenlijk te gaan optimaliseren.
Zoals eerder gezegd, je kan niet alles van te voren voorzien; een SLA is nooit alles dekkend. Bij onverwachte calamiteiten moet men er snel samen uitkomen. De opdrachtgever mag dan van ons voorstellen verwachten voor een (eenmalige) extra dienst, die eventueel tegen een meerprijs geleverd mag worden. Zoiets kan meestal snel op een operationeel niveau afgesproken worden. Een beknopte – via e-mail bevestigde – afspraak tussen bijvoorbeeld een hoofd van een lab en een senior beheerder, kan al voldoende zijn. De handtekeningen van de voorzitter van de Raad van Bestuur en de CIO zijn echt niet nodig, nee zelfs niet wenselijk.
En als de CFO zich achter een te krap gebleken SLA wil gaan verschuilen en niet wil uitbetalen (dat komt helaas wel eens voor), dan moet voorzitter van de Raad van Bestuur deze terugfluiten. Professionaliteit mag je van beide kanten verwachten. Er sterven binnen de gezondheidszorg al veel te veel mensen door domme bezuinigingen. En volgens mij hebben ziekenhuisdirecties door dat dit ook veel geld kost.