Veel zorgorganisaties die grote veranderingen hebben doorgevoerd in de zorgteams met het overstappen naar zelfsturing (of zelforganisatie, of zelfstandigheid – geef het beestje maar een naam), richten hun aandacht nu op de ondersteunende processen. Dus ook op hoe het beheer van de informatievoorziening is ingericht, inclusief applicatiebeheer.

Best ingewikkeld, nu voorheen bestaande communicatiekanalen en taakverdelingen niet meer bestaan. Hoe doe je dat dan als er een nieuwe versie van een applicatie is? Of hoe filter je eenvoudige gebruikersvragen van meldingen die mogelijk leiden tot aanpassingen in de inrichting of het gebruik van een applicatie of applicaties? En hoe implementeer je die? Welke organisatievorm hiervoor past bij zelfsturing?

Spoiler alert: verwacht geen panklare, allesomvattende oplossing in dit blogartikel. Graag deel ik wat ik tegenkom bij zorginstellingen waar ik mee spreek of die ik ondersteun bij dit soort vraagstukken. Het is wel duidelijk dat de uiteindelijke vorm maatwerk is voor iedere organisatie – en dat past natuurlijk prima bij de organische benadering van zelfsturing.

Applicatiebeheer: What’s in a name?

De internationale standaard voor functioneel beheer is BiSL (Business Information Services Library). De onderdelen ervan die in dit blogartikel worden beschreven, vallen binnen het model van BiSL uiteen in 2 “domeinen”: de business en functioneel beheer. Hoewel door de stichting BiSL wel voorbeelden worden gegeven van rol- of functiebeschrijvingen, ligt dit niet vast.

Binnen BiSL omvat functioneel beheer de procesclusters:

• “gebruiksbeheer”;
• “functionaliteitenbeheer”;
• “verbindende, uitvoerende processen” (dit duidt o.a. wijzigingsbeheer aan).

Functioneel beheer betreft dus zowel de proceskant als het applicatiebeheer (zowel functioneel als technisch). Iedere organisatie kan hierin een eigen verdeling en invulling aan geven, als alle beheerprocessen maar wel zijn belegd. Voor welke combinaties of uitsplitsingen wordt gekozen, is aan iedere organisatie om zelf te bepalen.

Dus voor alle duidelijkheid: een functienaam als functioneel applicatiebeheerder is heel logisch, maar is een ‘bedachte’ functienaam. Dat verklaart ook waarom de inhoud van die functie voor iedere organisatie weer heel anders wordt beschreven en ingevuld.

Taakclusters staan centraal, niet functies!

Wat beheer je eigenlijk?

Nu duidelijk is dat de standaard gaat over taken en taakclusters en niet over functies, is de volgende logische vraag: wat beheer je eigenlijk?

Dat lijkt heel eenvoudig – en dat is het overigens ook – maar vaak ook een eye-opener:

Als zorgorganisatie beheer je het gebruik, niet de functionaliteit

Zorgorganisaties willen hun invloed op functionaliteit nog wel eens overschatten. Het is heel eenvoudig: de leverancier van de applicatie beheert de functionaliteit. Als gebruikersorganisatie heb je hooguit invloed op de inrichting van applicaties en ligt de belangrijkste aandacht bij het gebruik van de applicatie.

Als we dus kijken naar de  procesclusters van BiSL, moeten zorgorganisaties zich realiseren dat ze intern niet zozeer moeten kijken naar “functionaliteitenbeheer” maar naar “gebruiksbeheer”.

Positionering en rollen

De kern van beheertaken binnen een zorgorganisatie is dus niet “functionaliteitenbeheer” maar “gebruiksbeheer”.  Dan is de volgende logische vraag: waar beleg ik dat? Wedervraag: “wie zou nou het best in staat zijn om het juiste gebruik te beheren?” Het antwoord is eenvoudig: een ervaren gebruiker! In een zelfsturende organisatie is het dus heel logisch dit soort taken in de lijn neer te leggen, niet in een afdeling die zichzelf uitsluitend bezighoudt met de applicatie, maar juist bij degenen die de applicatie ook echt, vaak, zelf gebruiken.

Logischerwijs vragen leveranciers om duidelijkheid bij wie zij moeten zijn als er nieuwe versies zijn en willen zij niet overspoeld worden door gebruikers met allerlei zinnige maar regelmatig toch ook onzinnige vragen (vooral vragen waarop ze het antwoord eigenlijk wel zouden moeten weten). Om die reden is het wel belangrijk dit te – sorry voor het woord – centraliseren.

In de praktijk is het het best dit centrale aanspreekpunt te positioneren op een plek waar de applicatie het meest wordt gebruikt.  Vervolgens moet het gebruiksbeheer wel in de haarvaten van de organisatie worden geborgd, liefst via superusers, ervaren gebruikers die dit beheer als aandachtspunt hebben binnen het team. Zij zijn de belangrijkste aanspreekpunten voor hun teamleden en vanuit de overige rollen in de beheerorganisatie om bijvoorbeeld nieuwe zaken te implementeren.

Voor leveranciers even wennen – voor jou een kans!

Het beheer van functionaliteiten ligt “dus” formeel bij de leverancier. Dat is eigenlijk nooit anders geweest, maar de praktijk wijst uit dat deze wat strakkere benadering voor veel leveranciers even wennen is. Zij zijn zo lekker gewend aan die functioneel applicatiebeheerder die met niets anders bezig is dan met hun applicatie. [Even terzijde: hoeveel tijd is er nou eigenlijk nodig om dat allemaal te doen? Denk aan de Wet van Parkinson: het werk dijt uit naar de beschikbare tijd.]

Ja, die leveranciers zijn er zo aan gewend dat “iemand” “alles” wel oppakt binnen zorgorganisaties dat sommige zaken die verwacht mogen worden voor het geld dat je betaalt, misschien wel ontbreken. Misschien herken je wel iets in het volgende:

• releasenotes komen te laat, zijn incompleet en (op onderdelen) onjuist
• er is geen keuze welke wijzigingen wel en welke niet worden geïnstalleerd bij een update
• bij het testtraject komen fouten aan het licht waarbij je je afvraagt hoe het mogelijk is dat de leverancier deze zelf niet heeft geconstateerd
• handleidingen / werkinstructies die de leverancier meelevert zijn verouderd en /of incompleet en / of niet geschikt voor de gebruikers
• er is geen actueel informatiemodel en overige basisdocumentatie beschikbaar
• het is een ramp zelfs de meest eenvoudige lijstjes of rapportages uit de applicatie te trekken

En zo kunnen we nog wel even doorgaan… Als je dit herkent, dan is je leverancier misschien wat verwend door goedwillende functioneel applicatiebeheerders – die tenslotte ook iets moeten doen voor hun salaris. Ja, dit is wat cynisch, maar helaas maar al te vaak de realiteit.

Ik zeg wel eens: “Je kan met informatie 3 dingen doen: maken, wijzigen en verwijderen. Hoe moeilijk wil je het jezelf maken?” Dat is een oversimplificering, dat weet ik, maar aan de andere kant heb ik vaak de indruk dat zorgorganisaties het zichzelf heel moeilijk maken door wanprestaties van leveranciers te belonen door hen te betalen voor de oplossing van problemen die deze leveranciers zelf veroorzaken!

In een notendop…

• Bij zelfsturing past een heroverweging wat je als zorginstelling moet en wil doen rondom het beheer van processen en applicaties.
• Gebruiksbeheer is de kern van de taak rondom de applicatie(s) en die past het best binnen de lijn.
• Borging binnen de zorgteams is een vereiste, zorg voor geschikte superusers en geef ze ook de uren om hun taken te doen. Ja, het is “erbij” (en dat is niet erg), maar het kost wel tijd.
• Wees duidelijk naar leveranciers van applicaties wat je verwacht voor het geld dat je betaalt. Vermijd black boxes op afdelingen waar op kosten van de zorginstellingen problemen worden opgelost die door de leverancier hadden moeten worden voorkomen of opgelost.
• Maak vraagstukken overdreven simpel. Weiger mee te gaan in “het is allemaal heel complex”. Als “ze” het jou niet kunnen uitleggen, snappen ze het waarschijnlijk zelf ook niet echt…

Wordt vervolgd

Zoals in de inleiding van dit blogartikel al staat, is dit niet het laatste woord over dit onderwerp. Hoe zit het bijvoorbeeld met “eigenaarschap” van processen en applicaties in een zelfsturende organisatie? Hoe ziet het beheer er concreet uit als je gaat werken met superusers en je geen functioneel applicatiebeheerders meer hebt? Wie bepaalt zaken als autorisatie? Hoe maak je goede keuzes en stel je de juiste prioriteiten? (Je kan immers niet alles doen en zeker niet alles tegelijk…) Dus: wordt vervolgd.