Tools zijn al zo oud als de weg naar Rome. En ouder. En in de hype van digitale transformatie is de roep om tools alleen maar groter. Er zijn meer tools dan ooit en het eind is nog niet in zicht. Maar in de dagelijkse praktijk blijven organisaties worstelen met de keuze voor de juiste tool.

Een paar mythes die ik al ruim twintig jaar hoor tijdens toolselecties die ik begeleid blijven maar rondzingen. Dus leek het me tijd om ze te benoemen en hopelijk te ontkrachten.

Mythe 1 – De IT’ers kunnen prima de requirements opstellen

“Want tools dat is technologie nietwaar? En dat is ingewikkeld en dat kun je maar beter aan IT’ers overlaten.”

Ik vergelijk dit met het laten kiezen van je auto door de monteur. Dan krijg je een auto waarvan de motorkap altijd openstaat, want dan kan hij er makkelijk bij. Uit ervaring kan ik je vertellen dat het rijden met een open motorkap lastig en zelfs levensgevaarlijk is. Niet doen dus.

Requirements zijn eisen en wensen die je stelt aan een tool. Functionele requirements gaan over de manier waarop de tool moet werken en niet-functionele requirements stellen randvoorwaarden aan de tool zelf. Die niet-functionele requirements worden meestal door IT’ers en andere specialisten zoals de privacy-officer opgesteld en dat is helemaal prima.

Maar hoe de tool dagelijks moet helpen om een doel te bereiken, moet echt worden bepaald door de mensen die elke dag met die tool moeten werken. Als je dat niet doet, krijg je tool die niet werkt voor deze mensen. Of die alleen met heel veel maatwerk en heel veel gedoe toch een beetje werkt zoals het zou moeten. Niemand neemt je dat in dank af.

Mythe 2 – Gebruikers weten toch niet wat ze willen

“Maar gebruikers weten toch helemaal niet wat ze willen? Steve Jobs zei toch ook zoiets?”

Kijk nog even naar de titel van deze mythe. Waarom zeggen we ‘gebruikers’ en niet ‘professionals’? Mensen zijn namelijk geen gebruikers, maar professionals. Professionals die zijn opgeleid en in dienst genomen om een bepaald doel te bereiken. En die tool helpt daarbij. Dus niemand weet zo goed wat de tool moet kunnen als de professional.

En zeg nou zelf, hoe vreemd klink deze uitspraak: “Professionals weten toch niet wat ze willen!” Maar door mensen te labelen als gebruikers vertel je impliciet al dat ze domme willoze robots zijn die ‘Het Systeem’ (met hoofdletters) maar niet kunnen waarderen.

Steve Jobs bedoelde niet dat je mensen niet moet vragen wat ze willen, je moet ze alleen niet letterlijk vragen wat de tool moet doen. En nog erger: wat de requirements precies zijn. Mensen willen op een makkelijke, interessante, leuke en liefst ook bevredigende manier een doel bereiken. Je krijgt inderdaad nog letterlijk bruikbare functionele requirements van professionals.

Dus vraag ze wat ze zoal op een dag doen en waarom. En bespreek en observeer hoe het beter kan. Kijk naar wat ze doen en hoor wat ze zeggen. Vertaal dat in scenario’s en ‘user stories’ en bespreek dat met de professionals. Het is vervolgens de kunst - en jouw vak als professional - om dit te vertalen naar requirements.

Mythe 3 – Als we te veel eisen, zijn er straks geen tools

“Ja maar. Als we dát allemaal vragen is er straks geen tool die daaraan kan voldoen!”

Dit is ook weer zo’n hardnekkige mythe die ik vaak hoor. Ten eerste zijn er tienduizenden tools en bijna al die tools zijn ontwikkeld om de eisen en wensen in de markt te bedienen. De kans dat er geen tool te vinden is, is zeer klein. In mijn 20+ jaar carrière heb ik het in elk geval nog nooit meegemaakt.

En wat vraag je eigenlijk van een tool? Een retourtje Mars? Een tool die met één druk op knop ‘automagisch’  alle informatie verzamelt, cureert, verrijkt, publiceert en weer doet verdwijnen als de tijd rijp is?

Mijn ervaring is dat juist leveranciers allerlei eigenschappen aan hun tool toekennen die op zijn minst overdreven zijn of eigenlijk helemaal geen nuttige functie hebben. Het is aan jou om daar doorheen te prikken.

Mythe 4 – Als we te veel eisen, kost dat alleen maar maatwerk

“We willen zoveel, dat kan nooit standaard in een tool. Dus dan moeten we dat laten maken voor heel veel geld!”

Dit is een mythe, maar wel een met een kern van waarheid. Maar dit ligt niet aan de eisen, maar aan de verkeerde tool die je hebt gekozen. De tool kan niet wat je wil en vreemd genoeg heb je een tool gekozen die daar helemaal niet aan voldoet. Of misschien had je de tool al – zie mythe 6 – en werd je gedwongen om die te nemen. Dan heb je inderdaad een probleem. Maar nogmaals, dat ligt niet aan je eisen maar aan je tool.

Als je in het begin niet goed duidelijk maakt wat je allemaal en precies wilt, is de kans op maatwerk levensgroot. Over dit soort debacles lees je regelmatig in de media. Miljoenen en miljarden die werden verspild aan maatwerk, omdat in het begin niet duidelijk is gemaakt wat men echt nodig heeft.

Dus eis alsjeblieft zoveel als je nodig hebt. Maak wel onderscheid tussen wensen, eisen en essentiële eisen. In het aanbod van de leveranciers kun je zien wat dat allemaal moet kosten en dan kun je alsnog sommige eisen laten vervallen of onderhandelen over de prijs of de manier waarop aan de eis wordt voldaan.

Mythe 5 – De tool moet gebruiksvriendelijk zijn

“We willen een gebruiksvriendelijk systeem”. “De zoekmachine moet goed werken.” “We willen een toptakenmodule.”

Met dit soort requirements kun je niets, maar ik zie ze eigenlijk altijd in een lijstje staan. Dit krijg je als je professionals letterlijk naar hun requirements vraagt. Zie ook mythe 2. En daar heb je niets aan, want wat betekent “gebruiksvriendelijk?” Hoe meet je dat en hoe vergelijk je de ene tool met de andere op gebruiksvriendelijkheid?

En wanneer werkt de zoekmachine goed? En wat is in vredesnaam een “toptakenmodule”?

Een requirement moet wel SMART zijn, dus volledig geoperationaliseerd en helder zijn voor iedereen inclusief de leverancier. Als professional kun je helpen om elke requirement SMART te maken en ook te bepalen hoe je dit gaat gaat beoordelen en erop gaat wegen.

Mythe 6 – Weet je wat? We nemen de gratis tool die we al hebben

“Waarom neem je X niet? Die hebben we al en we betalen al voor de licenties. Dus het kost je niets!”

Er is een hardnekkige mythe – die vooral bij IT-ers leeft – dat de organisatie al een tool heeft die alles kan en die nog gratis is bovendien. Hoe mooi kan het zijn? Wat ze alleen niet vertellen – en vaak ook niet weten – is dat van die tool niet alle modules zijn aangeschaft of gelicenseerd. Dus vaak moeten die nog worden bijbetaald.

Een tool die alles met de druk op de magische knop kan, bestaat niet. Er is altijd configuratiewerk nodig en dat kost geld. En als de tool eigenlijk niet geschikt is, is er zelfs maatwerk nodig. En dat is kostbaar en zeer risicovol. Dus van gratis is geen sprake.

Het is altijd verstandig om eerst te kijken welke tool die je al hebt kan voldoen aan de requirements. Organisaties gebruiken vaak een plethora aan tools die de kluwen van informatiesystemen alleen maar groter en minder beheerbaar maakt. Maar beoordeel die bestaande tools wel op hun geschiktheid en zet ze niet klakkeloos in.

Blijf hoe dan ook vasthouden aan je functionele requirements en beoordeel ook de tools die je al hebt op hun geschiktheid.

Mythe 7 – We kiezen een open source tool, want dat is goedkoper

“Open source is goedkoper en dan hebben we ook geen ‘vendor lock-in’!”

Op de een of andere manier is ‘open source’ nog steeds een ding. Maar open source is gewoon een licentiemodel. Het zegt niets over de kwaliteit van de tool, noch in positieve noch in negatieve zin.

Dat open source gratis of in elk geval goedkoper is, is ook niet altijd waar. De meeste informatiemanagementsystemen zijn geen kant-en-klare systemen. Dus er is altijd configuratiewerk nodig en dat kost geld. je betaalt alleen niet voor de licentie van de tool. Hoewel ook dat de laatste jaren niet meer per se waar is, omdat veel open source leveranciers een betaalde ‘Enterprise’ editie aanbieden naast de gratis ‘Community’ editie. Want organisaties willen wel ondersteuning en garantie op de tool en dat kost nou eenmaal geld.

Sommige open source leveranciers bieden ook additionele modules die tegen een flinke prijs beschikbaar zijn. Dat die modules niet open source beschikbaar zijn, is volgens mij een teken aan de wand.

Ik heb in de jaren al veel toolselecties begeleid waarbij zowel open source als proprietary tools kandidaat waren. En daarbij heb ik eigenlijk nooit significante prijsverschillen gezien tussen deze tools. De prijs wordt voornamelijk bepaald door het configuratiewerk en het jaarlijkse onderhoud.

Dit gaat dan wel om de grotere omgevingen. Want hier komt de disclaimer: voor kleine omgevingen is een SaaS- of open source tools vaak gratis of spotgoedkoop.

Hoe te beginnen met een toolselectie

In een toolselectie kiest een organisatie de digitale middelen die kunnen bijdragen aan de digitale transformatie. Tools en technologie kunnen de digitale transformatie ondersteunen, op voorwaarde dat de juiste eisen en wensen (requirements) worden opgesteld en professionals goed worden begeleid in het gebruik van de tools.

De eerste stap in de toolselectie is de analyse waarin de eisen en wensen (requirements) worden vastgesteld. Verzamel de niet-functionele requirements bij IT, Legal, de privacy-officer en andere specialisten. Organiseer workshops met een representatieve groep van professionals in de organisatie en stel samen scenario's op van een ideale dag en hoe digitale middelen daaraan kunnen bijdragen. Die moeten vervolgens worden vertaald in functionele requirements.

Scenarios zijn de rode draad

De met de professionals opgestelde scenarios zijn de rode draad in de toolselectie en ook de implementatie en acceptatie van de tooling. Eerst worden de scenarios vertaald naar functionele requirements.

Vervolgens worden de scenarios gebruikt in de toolselectie door de potentiële leveranciers te vragen om in een demonstratie enkele scenarios uit te werken. De bij de demonstratie aanwezige professionals kunnen dan beoordelen of de tooling voldoet aan hun wensen.

Maar daarmee is de rol van scenarios nog niet uitgespeeld. Bij de implementatie zijn de scenarios het ijkpunt waarop de geïmplementeerde tooling wordt beoordeeld. Is de tooling nog niet optimaal voor het gewenste scenario, dan moet de tool worden bijgeschaafd.

De scenarios spelen ook een rol bij de training van de professionals in het gebruik van de tooling. Een goede training is voornamelijk opgebouwd rondom de scenarios; die zijn namelijk herkenbaar voor de professionals. Daarmee vermijd je ook een saaie 'knoppentraining'.

De scenarios blijven de basis voor elke optimalisatie van de tooling. Verandert het proces of de werkwijze van de professional? Dan komt er eerst een aangepast scenario als basis voor de aanpassing in de tooling. Vanuit het perspectief van de professional.