Een nieuwe applicatie kiezen: zo pak je dat aan

Ook als je zeker weet dat de applicatie die jij beheert de juiste is, is het goed om de applicatie onder de loep te nemen. Je kan namelijk ook de aanname doen dat het nog perfect past. En als je het echt zeker weet, heb je niks te verliezen toch?

Vragen die je zou kunnen stellen om kritisch naar je applicatie te kijken zijn bijvoorbeeld: Voldoet de applicatie nog steeds aan onze eisen? Zijn er inmiddels nieuwe softwareleveranciers die mogelijk beter aansluiten bij onze organisatie? En ook staan softwareleveranciers niet stil, misschien kan een applicatie nu iets wat bij aanschaf nog niet kon? Past de deze applicatie nog binnen ons nieuwe of bestaande beleid. 

Weet jij hoe de keuze tot het aanschaffen van de applicatie waar jij als IV-professional veel mee werkt tot stand is gekomen? 

Als je geen idee hebt kan het een leerzame vraag zijn! Maar het gebeurt vaak genoeg dat een applicatie gekozen wordt omdat een collega bij een andere organisatie er zo fijn mee gewerkt heeft, omdat het is aangeraden door een consultant en soms heb je helemaal geen of weinig keuze. Dit kan zo zijn omdat op sommige gebieden softwareleveranciers monopolisten zijn of heb je als organisatie zulke speciale wensen dat je op zoek moet naar een softwarebouwer, in plaats van leverancier. Een andere optie is dat een belangrijke ketenpartner werkt met dezelfde software en is daarom de keuze snel gemaakt. Redenen genoeg en vaak, als een applicatie er eenmaal is, koppelingen er zijn, eindgebruikers weten hoe het werkt is het makkelijker om dezelfde applicatie te blijven gebruiken. 

Zit je in de positie waarbij je om je heen kan gaan kijken voor een toevoeging aan je applicatielandschap of een vervanging van een bestaande applicatie? 

Als er dan toch wat te kiezen valt is het fijn als je een gedegen keuze kan maken tussen verschillende leveranciers met een goed uitgestippeld proces. 

In dit artikel vind je enkele handvaten waar je in zo’n geval aan moet denken. Het kan daarbij zijn dat niet alle zaken voor jouw organisatie relevant zijn, bijvoorbeeld als je als organisatie te maken heeft met aanbestedingen.  

Toch is een vooronderzoek en daarna een kosten-batenanalyse een must voor een weloverwogen beslissing. 

Het vooronderzoek zou op zijn minst moeten bestaan uit drie onderdelen, probleemanalyse, intern onderzoek en extern onderzoek. 

Probleemanayse

Om te beginnen de probleemanalyse: Welk probleem of problemen wil je dat deze applicatie op gaat lossen en/of welk (kritisch) bedrijfsproces moet deze applicatie ondersteunen? 

Probeer daarbij de volgende vraag te beantwoorden en de twee zinnen aan te vullen. Dit mag ook meerdere keren. 

• Voor wie lost dit iets op?
• Wat kan hij/zij daarmee?
• Wat is het voordeel tenopzichte van de huidige situatie?

Stel deze vragen ook aan een dwarsdoorsnede binnen je organisatie en zeker aan je beoogde eindgebruiker en beheerder. Als het moment van adaptatie gaat komen is er een veel grotere kans van slagen als in het vooronderzoek collega’s al zijn meegenomen! 

Inventarisatie huidige applicaties

De tweede hele belangrijke vraag, die vaak overgeslagen wordt is: Wat hebben we al in huis? Zeker (middel)grote organisaties hebben vaak al een heel applicatielandschap, en wie weet zijn er al applicaties in bezit die jouw probleem (deels) op kan lossen. Zorg dat zowel business, IV en ICT zijn aangehaakt, pas met alle perspectieven vertegenwoordigd kan je goed bepalen wat er nodig is, maar ook wat er al is.  

Capaciteitscheck

Daarnaast vraagt een nieuwe applicatie zowel inzet tijdens het implementatieproces, als daarna. Is die capaciteit er wel? Dit betekent niet dat de applicatie er niet moet komen, maar wel dat je het moet plannen. Het kan zijn dat je pas volgend jaar deze wens in vervulling kan laten gaan. 

Benchmark

En tot slot, extern onderzoek. Zijn er vergelijkbare organisaties met mogelijk dezelfde uitdagingen? Waarom het wiel opnieuw uitvinden als dit niet nodig is?  

Zijn er organisaties in hetzelfde domein, met vergelijkbaar formaat en vergelijkbare processen? Dan kan je elkaar op vele vlakken helpen. 

Liggen deze organisaties niet voor het oprapen? Naast vergelijkbare organisaties kan je ook in contact treden met potentiële leveranciers over de mogelijkheden, praat met vakgenoten over hun ervaringen ook al zijn ze niet werkzaam bij een vergelijkbare organisatie en/of schakel professionele hulp in. 

Vaak ligt bij een kosten/batenanalyse de nadruk op de kosten, uiteraard moeten de kosten opwegen tegen de baten. Alleen sommige zaken zijn moeilijk kwantificeerbaar. Zou het bijvoorbeeld een flinke verhoging van de tevredenheid van je medewerkers kunnen betekenen? Los van de kosten, is het verstandig om in ieder geval de relevantie te bepalen de applicatie en leveranciers- vereisten op te stellen. 

Het investeren in een applicatie kost naast geld, ook tijd en inzet. En de toekomst is moeilijk te voorspellen, maar ook zonder glazen bol zijn de volgende twee vragen meestal wel te beantwoorden: 

• Is dit over vijf jaar nog steeds relevant
• Worden we wendbaarder? 

Mocht het antwoord nee zijn bij vraag 1 dan is een applicatie geen oplossing. Applicaties zijn om lange termijn doelen en processen op orde te brengen. Is het tijdelijk? Probeer dan een andere oplossing te vinden.  

Organisaties, zeker in het sociaal domein kunnen uitdagingen ondervinden vanuit twee kanten. Aan de ene kant wordt de medewerker steeds mondiger en door de krapte op de arbeidsmarkt mogelijk veeleisend(er) en aan de andere kant zijn organisatie ook steeds meer gebonden aan wet- en regelgeving door de overheid. Wendbaarheid is daarbij het codewoord, kan je met de aanschaf van een applicatie de medewerker tegemoet komen? En/of makkelijker inspelen op ontwikkelingen in de maatschappij? Dan is dat een groot pluspunt. 

Het mooiste zou zijn als we een standaardlijstje zouden hebben voor applicatievereisten. Maar aangezien het afhangt welke probleem de applicatie oplost of welk (kritisch) bedrijfsproces deze applicatie ondersteunt en hoe jouw organisatie is ingericht, is dat moeilijk te realiseren. 

Wat je wel kan doen, is aan tafel met alle belanghebbenden te bepalen, hoe MEGA belangrijk is het? 

• Minimum > het absolute minimum dat de applicatie zou moeten kunnen
• Essentieel > alle essentiële vereisten 
• Graag > als de applicatie het zou kunnen, zou het heel mooi zijn
• Aangenaam > de echte ‘nice to haves’, superleuk als je je eigen avatar kan kiezen, maar verre van belangrijk 

Applicatievereisten kunnen echt van alles zijn en is afhankelijk van jouw organisatie. 

Een voorbeeld:  

Device onafhankelijkheid. Stel, al jouw collega’s hebben een laptop dan kan hier ‘graag’ volstaan, maar werkt een deel van jouw collega’s op tablets, kan het opeens een essentiële vereiste zijn. 

Andere voorbeelden kunnen zijn: moet het kunnen koppelen met andere applicatie(s), voldoet de applicatie aan wet- en regelgeving (altijd een Minimum). Wat deze applicatievereisten zijn moet je ophalen binnen jouw organisatie en daarna samen bepalen of het MEGA is.  

Wie weet heb je in je vooronderzoek al de nodige potentiële leveranciers gesproken, maar bij het bezoek bij de leverancier voor je nieuwe potentiële applicatie – welke applicatie dan ook, is het fijn om in ieder geval antwoord te krijgen op de volgende vragen: 

1. Kan de leverancier aan de applicatievereisten (in ieder geval de ME, van MEGA) voldoen?
2. Is er veel maatwerk nodig? En kan de potentiële leverancier dit leveren? (Maatwerk heeft als groot voordeel dat een applicatie beter aansluit bij de wensen van een organisatie, maar als groot nadeel dat je minder wendbaar wordt en ondersteuning in maatwerk kan veranderen).
3. Welke kosten zijn waaraan verbonden? Denk dan ook aan mogelijke kosten voor eigen personeel en verborgen kosten. Is het een platte, simpel beheer(s)bare applicatie of heb je binnen je eigen personeel een expert nodig? Verborgen kosten bij een leverancier zouden kunnen zijn: hoge consultancy tarieven, opleidingen of uitbreiding licenties.
4. Hoeveel en welke hulp wordt er geboden bij de implementatie? Maar ook daarna. Is een servicedesk inclusief of moet er voor ieder ticket worden betaald?
5. Wat staat er in het Service Level Agreement (SLA)? En zijn de voorwaarden van de SLA onhandelbaar? Ga daar vooral over in gesprek.