In veel technische afdelingen ontstaan innovatieve concepten en ideeën als reactie op specifieke zakelijke uitdagingen. Ingenieurs verdiepen zich bijvoorbeeld in de materie om deze uitdagingen aan te gaan. Ze verzamelen data uit verschillende bronnen, gieten dit in spreadsheets en bekomen zo nieuwe inzichten of gebruiken de spreadsheet als een hulpmiddel bij toekomstige taken. Data analisten hebben dan weer vaker een analyse of experiment opgezet in een Databricks notebook of hebben een Machine Learning model getraind.
Vaak blijken deze resultaten of tools niet alleen waardevol voor henzelf, maar ook voor andere (administratieve) afdelingen, de arbeiders op de werkvloer of zelfs voor klanten. Maar hoe transformeer je een conceptueel technisch idee tot een operationele tool die bruikbaar is door mensen die geen ingenieur of data analist zijn? En nog belangrijker, hoe zorg je ervoor dat deze mensen daadwerkelijk deze tool gaan gebruiken?
Van idee tot app
Technische afdelingen zijn vaak sterk in het bedenken van innovatieve concepten en datastructuren. Echter, om van een proof of concept naar een operationeel bruikbare tool te komen, is nog een andere set vaardigheden nodig: het technisch bouwen van een applicatie en het grondig begrijpen van de werkprocessen van de gebruiker om de tool goed te laten integreren. Dat laatste aspect mag niet worden onderschat in een operationele omgeving. We kennen allemaal wel een voorbeeld van een goedbedoelde tool die niet wordt gebruikt omdat de oude manier van werken efficiënter is.
Keuze technologie en architectuur
Bij het ontwikkelen van een applicatie zijn er verschillende factoren die de keuze van de technologie en architectuur beïnvloeden. Heeft de applicatie dynamisch toegang nodig tot externe data, moet er data worden opgeslagen, wie zijn de gebruikers, moeten gebruikers authentiseren, zijn er verschillende soorten gebruikers, zijn er security overwegingen, in welke omgeving zal de applicatie worden gebruikt (administratie, productie, buitenwerkers), is interactie met andere applicaties gewenst? Dit zijn slechts enkele van de vele overwegingen. Het is belangrijk al deze factoren te overwegen en dan pas een technologie en architectuur te bepalen en niet omgekeerd. De technologie moet de gebruiker dienen en niet omgekeerd. Het lijkt logisch, maar hiertegen wordt vaak gezondigd. Verkopers en technici schermen namelijk graag met technologische termen, terwijl de kwaliteit van de code en de gebruiksvriendelijkheid van de applicatie veel meer impact zullen hebben op de uiteindelijke ROI. Niemand heeft iets aan een applicatie met lage adoptie.
Voordeel voor de gebruiker
Om bruikbaar te zijn in een operationele omgeving moet de tool een voordeel opleveren voor de gebruiker of de organisatie. Het volstaat niet om de ‘functional requirements’ op te lijsten, omdat deze te algemeen zijn om een gebruiksvriendelijke ervaring te garanderen. Denk maar aan hoe je een auto zou omschrijven in functional requirements, in veel gevallen zullen zowel een Porsche, een Smart of zelfs een camionette voldoen aan de functionele eisen. De makers van de applicatie moeten de wil, de interesse en de gave hebben om de gebruiker te begrijpen. Er moet dus geïnvesteerd worden in het begrijpen van de processen en in een dialoog met de gebruiker. Samen moet er nagedacht worden hoe de applicatie best werkt om een productiviteitswinst of kwaliteitswinst te genereren. Dat is vaak een iteratief proces dat enige flexibiliteit van de makers van de applicatie vereist. Daarom is het belangrijk om bij het ontwerpen van de architectuur rekening te houden met die nood aan flexibiliteit.
Data onderhoud
Een ander belangrijk aspect van gebruiksvriendelijkheid is het vermijden van dubbel data-onderhoud. Het is één van de meest gehoorde klachten van werknemers dat bepaalde gegevens in verschillende (niet communicerende) applicaties moeten worden ingegeven wat niet alleen contraproductief maar ook zeer demotiverend is. Zorg er dus voor dat de applicatie data ophaalt als deze reeds beschikbaar zijn.
Belangrijke stappen naar succes
Het omzetten van een innovatief idee in een operationele tool kan een hele uitdaging zijn, maar wanneer goed uitgevoerd, zal die niet alleen een stevige ROI opleveren maar ook motiverend werken voor de gebruikers. Of je nu samenwerkt met je interne IT-afdeling of een externe partner, het vereist:
- Een goed uitgewerkte proof of concept.
- Technologische kennis voor het bouwen van een applicatie.
- Ervaring in het zich eigen maken van business- en werkprocessen.
Het begint met een idee en eindigt met een krachtige motor die organisaties in beweging brengt.
