Maurice van Elburg

Maurice van Elburg

consultant en projectleider in de langdurige zorg

Vermijd deze valkuil als je een applicatie gaat selecteren

Een applicatie selecteren doe je – als het goed is – niet zo heel vaak, zeker niet als het gaat om de ondersteuning van het (primaire) zorgproces. Rust op de werkvloer, stabiliteit en continuïteit zijn ook veel waard. Maar zo nu en dan is het onvermijdelijk.

Dan is het ook een kans om de informatievoorziening nog beter te laten aansluiten op de visie van de organisatie. Als het goed is (en helaas is dat niet zo vanzelfsprekend), wordt het proces dat moet worden ondersteund centraal gesteld. De manier van werken leidt tot functionele eisen: wat moet de applicatie allemaal kunnen?

Het lijkt misschien tegenstrijdig, maar in deze vraagstelling schuilt een grote valkuil: als de “wat”-vraag centraal staat bij de selectie van een applicatie, lijken de verschillen tussen de leveranciers relatief klein.

Neem een ECD: in (vrijwel) alle ECD’s kan je een plan maken, doelen en acties definiëren, rapporteren, evalueren, noem het maar op. Het aantal smaken wordt nog beperkter als het gaat om applicaties die de administratieve processen moeten ondersteunen, vooral omdat deze eenvoudig moeten voldoen aan wet- en regelgeving (zoals iWlz). De roemruchte Excel-sheet met ‘ja / nee / in de toekomst’ als antwoordmogelijkheden leidt aan het eind van het selectietraject tot de onvermijdelijke conclusie: “Wat liggen die applicaties dicht bij elkaar!” En dan gaat de prijs de doorslag geven…

Dank je de koekoek. Alle auto’s hebben een stuur, snelheidsmeter, voorlichten, achterlichten, ruitenwissers, een achteruitkijkspiegel, etc. Dat kan niet anders. Maar er zit toch echt een verschil tussen een 2CV en een Rolls.

En daar zit nog heel veel tussen! Zoek je een Toyota of een Volvo? Zonder te willen doorslaan in deze metafoor, alles heeft zijn prijs. Dat geldt voor auto’s en voor applicaties. Zowel voor het product op zich als voor het “serviceapparaat” eromheen.

Het is dus essentieel niet te vragen OF een applicatie iets kan, maar HOE dat is vormgegeven! Vraag uit hoe leverancier bepaalde functionaliteiten biedt, ondersteund door screenshots. Hoe zien de schermen eruit? Wees eerlijk: lijkt het op een boekhoudpakket of worden gebruikers door vormgeving, kleuren, iconen, contextgebonden helpfuncties e.d. geholpen bij het juiste gebruik ervan? Beter nog (1): vraag direct toegang tot een proefomgeving, jawel, nog voordat de fase van de “shortlist” (de laatste 3 applicaties) is aangebroken. Als de leverancier begint te sputteren dat er dan eerst instructies moeten worden gegeven, is de applicatie dan echt wel zo intuïtief als je wilt? Als jij al niet in één keer snapt hoe de applicatie werkt, wat verwacht je dan van de honderden of zelfs duizenden medewerkers die denken in termen van mensen verplegen, verzorgen en ondersteunen? Plus: je kan direct beoordelen hoe het er allemaal uitziet, inclusief op een iPad of smartphone. En hoe zit het met het cliëntportaal en medewerkerportaal? Een ‘rijpe’ applicatie kan door de leverancier op basis van eerdere ervaringen vast wel worden ingericht tot een herkenbare en werkbare omgeving, dus dat zouden ze moeten kunnen laten zien en ervaren. Bij het kopen van een auto maak je toch ook al vroeg een proefrit?

(N.B.: De meeste zorginstellingen zoeken de balans tussen het gebruik maken van best practises in de sector en de flexibiliteit om zaken zo veel mogelijk zelf te kunnen inrichten. Voor zorginstellingen die bereid zijn de prijs te betalen om het echt helemaal op maat te kunnen inrichten, gelden andere spelregels. N.B. 2: Mijn ervaring is dat er – mede door landelijke standaarden – veel overeenkomsten zijn qua proces en informatievraag van zorginstellingen. Vaker is er sprake van andere terminologie, dus dat zou zeker inrichtbaar moeten zijn.)

Beter nog (2): ga op referentiebezoek en sta erop van de gebruikers zelf te horen hoe zij de applicatie ervaren qua mogelijkheden en gebruikersvriendelijkheid. Kijk mee als zij de applicatie gebruiken. Soms is het gewoon al genoeg om de applicatie gewoon eens echt “werkend” te zien. Als het goed is, is er een proef- of testomgeving waar zonder de privacy van mensen te schenden kan worden meegekeken. Houd er ook rekening mee dat bij een referentiebezoek de ‘beste meisjes en jongetjes van de klas’ naar voren worden geschoven.  (Wederom:) als het goed is, is er een gebruikersgroep of iets dergelijks. Kijk eens of er ook andere geluiden zijn – waarbij daar weer rekening moet worden gehouden met het feit dat de ontevredenheid van sommige klanten ook helemaal door henzelf kan worden veroorzaakt. Het blijft lastig…

En tot slot, beter nog (3): voer zelf eens een paar simpele handelingen uit in de applicatie. Gewoon een cliënt opzoeken, een belnotitie vastleggen, een rapportage schrijven of terugzoeken, een afspraak in een cliënt- of medewerkeragenda zetten. En vooral allemaal snel na elkaar, want zo gaat het in de praktijk ook. Nogmaals: is de applicatie echt zo intuïtief als je zou wensen? Zien is geloven. Soms maakt dat de keuze ineens heel makkelijk…

Dit artikel is één onderdeel uit mijn whitepaper Een applicatie selecteren – Hoe doe je dat? Over het selecteren van een applicatie is natuurlijk nog veel meer te zeggen, zoals:
– hoe ziet het selectietraject er in zijn totaliteit uit?
– wie betrekken?
– hoe stel je wegingsfactoren vast?
– welke eisen stel je aan je leverancier?
– hoe formuleer je de functionele en technische eisen? (daar komt bovenstaand onderdeel uit)
– “proof of concept” optimaal gebruiken
– de financiële paragraaf, wat is redelijk waarvoor je moet betalen en hoe te onderhandelen
– het contract
Meer weten? Mail of bel me!