Falen met software is een dure hobby

24 september 2020

Gijs in 't Veld,

Voormalig CTO en Principal Consultant

Er wordt elke dag veel uitgegeven aan het realiseren van software oplossingen. Organisaties zien kansen om zich te onderscheiden en digitaal te innoveren met maatwerk. Deze software wordt tegenwoordig ontwikkeld met low code app-, data- en integratieplatforms, geboden door cloud leveranciers. De praktijk leert helaas dat we zo op nog grotere schaal onbruikbare oplossingen produceren.

Waar gaat het mis? Een berucht artikel, “why software fails” uit 2005 beschrijft dit in detail. Het is treurig om te zien dat er nog niet veel veranderd is in de afgelopen 15 jaar. Hieronder belicht ik twee van de belangrijkste redenen voor het falen van software oplossingen:

  • Unrealistic or unarticulated project goals – de strategie, aanpak en doelstellingen zijn niet duidelijk geformuleerd
  • Badly defined system requirements – de wensen en eisen voor de oplossing zijn niet goed in kaart gebracht

Beide redenen zorgen ervoor dat je pas op een laat moment in het traject er achter komt dat de software niet gaat leveren wat eigenlijk de bedoeling was en kun je waarschijnlijk grotendeels opnieuw beginnen. Een dure grap dus.

Platformstrategie en aanpak

Het inzetten van een low code platform om daarop maatwerk te realiseren is een strategische keuze voor elke organisatie. Maar met het aanschaffen van het platform is maar een klein hobbeltje genomen. Met welk doel gaan we dit platform inzetten? Welke leidende principes hanteren we? Welke bedrijfsdoelen gaan we helpen behalen? Hoe past het in het applicatielandschap en hoe gaan we om met informatiearchitectuur? Hoe gaan we deze verandering binnen de organisatie managen? Hoe meten we het succes?

Bij veel organisaties zien we nog steeds dat de IT afdeling hier een leidende rol speelt, terwijl het allemaal om business oplossingen gaat. De business wenst zich te onderscheiden van de concurrenten en wil digitaal innoveren. Om zo een groter marktaandeel te behalen of de marges te verbeteren. Het innoveren van business processen en daarmee verregaande optimalisaties doorvoeren is iets wat niet thuis hoort in de systems of record. Dat zijn vaak robuuste, administratieve applicaties die ook eigenlijk commodity zijn. Steeds vaker zijn dit SaaS applicaties. Iedereen gebruikt dezelfden.

Waar je het onderscheid kunt maken is in het slim aan elkaar koppelen van deze applicaties en cloud services. Door data te verzamelen en te verrijken en nieuwe inzichten te vergaren. Door het inzetten van kunstmatige intelligentie. En op de persona’s gerichte maatwerk apps, die precies doen waar de betreffende persoon in haar deel van het bedrijfsproces behoefte aan heeft. En liefst zonder al te veel in- of over te typen. Laat de gecombineerde data het meeste werk voor je doen.

Fouten gemaakt in strategie en architectuur (business-, applicatie- en informatiearchitectuur) kunnen dure gevolgen hebben. Hoe eerder je in het software voortbrengingsproces fouten weet te vermijden, hoe goedkoper het is. Zoals in het bovengenoemde artikel zo mooi is verwoord: als je een breifout hebt gemaakt en daar pas veel te laat achter komt, kun je bijna helemaal opnieuw aan de trui beginnen. Daarmee gaat veel tijd en geld verloren.

Het belangrijkste onderwerp om tot een goede strategie, aanpak en doelstellingen te komen is om workshops met de juiste stakeholders te organiseren. Begin hierbij altijd met een workshop die bepaalt welke stakeholders er precies nodig zijn en zorg ervoor dat ze genoeg tijd beschikbaar hebben. Als dit niet zorgvuldig gebeurt, is de kans op falen verderop in het proces veel groter.

User-centered design

Als je het aan de eindgebruikers van software oplossingen vraagt hoe dingen beter kunnen, weten ze het meestal wel. Of, denken ze het te weten. De kunst is om de juiste gebruikers bij elkaar te krijgen en er naast te gaan zitten tijdens het uitvoeren van hun werkzaamheden.

Maar daarnaast is het belangrijk om van proceseigenaren te weten te komen hoe processen nu het beste gedigitaliseerd en geoptimaliseerd kunnen worden. Vaak wordt nog gedacht in oude oplossingen; “in het huidige systeem gebeurt het zo”. Een gebruiker is in principe maar een klein radertje in het geheel, en heeft vaak geen zicht op het grotere doel van zo’n proces en hoe dingen echt verbeterd kunnen worden. Om echt innovatieve functionaliteit toe te voegen. Om die klant echt beter te kunnen gaan bedienen.

Er wordt nog veel te vaak inside out gedacht. De echte why (de vraag achter de vraag) is moeilijk te achterhalen. Dat vergt creativiteit van de UX designer. Het draait tegenwoordig om customer-centric UX en niet meer om organization-centric UX (zie ook “How UX is transforming business” in Forbes). En het vertalen naar goede requirements is echt wel een vak, waar dit soort mensen goed in getraind is en veel ervaring mee heeft. Het zijn vaak niet eens “techneuten”. Door eerst de gebruikersinteractie en procesflows uit te tekenen en eventueel in een prototype te gieten kan er al heel snel met eindgebruikers en proceseigenaren afgestemd worden of het aan de eisen en wensen voldoet. En of het inderdaad een verbeterd proces oplevert.

Eigenlijk begint daar het change proces al; iedereen moet worden meegenomen in dit optimalisatieproces. Met de ontwikkelaars in het DevOps team wordt vervolgens besproken of het technisch haalbaar is. Voordat er ook nog maar een regel code geschreven is. Dit kan allemaal prima gecombineerd worden met een agile aanpak, waarbij er met elke sprint weer waarde wordt toegevoegd. Op deze manier is fail fast mogelijk, en kan het in de volgende sprint bijgestuurd worden. Zo wordt het realiseren van innovatieve software oplossingen goedkoper en krijg je echt precies wat bijdraagt aan de in de strategiefase bepaalde doelstellingen. Doelstellingen die uiteraard ook customer-centric moeten zijn!

Shadow IT uit de schaduw halen