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.'
Reacties
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.
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 / 7x24) 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.
Niet zo formeel doen allemaal zeg. Een SLA is een afspraak die je maakt zodat ja als organisatie weet wat men mag verwachten. Een SLA wordt door PavaKe afgedaan als iets wat je kunt gebruiken om vooral iets niet te doen. Onzin is dit. Ik krijg ook jeuk van opmerkingen als 'doen waar je voor wordt betaald'. Volgens mij moet je eerst de kaders neerleggen voordat je dit kunt stellen (kaders als SLA, ITIL, enz).
Ook bij grote financiele instellingen wordt met SLA's gewerkt. Business voor hen is hetzelfde als een mensenleven voor een ziekenhuis. Als een belangrijk apparaat kapot gaat moet er per direct een nieuw apparaat worden neergezet. Als de SLA als gegeven (per direct vervangen) goed wordt gehanteerd kan dat bijvoorbeeld betekenen dat het apparaat op de plank moet staan, wekelijks moet worden getest op functionaliteit, enz.
Als je een SLA met elkaar afspreekt kun je daar als organisatie dus ook de middelen voor krijgen om de SLA te behalen.