De interessantste vraag over een webapplicatie is niet wat hij kan, maar wat hij vervangt. Een webapplicatie is software waarin je via de browser werkt: mensen loggen in, voeren gegevens in en een proces loopt er van begin tot eind doorheen. Dat is iets anders dan je website, die informeert en overtuigt; dat verschil werkten we eerder uit in een website vertelt, een webapplicatie werkt. Een webapplicatie verdient zijn plek pas als het werk dat hij overneemt je nu al geld kost, in uren, in fouten of in klanten die wachten.
Dat moment is niet voor elk bedrijf aangebroken. Bijna elk proces kan beter, dus die vraag brengt je niet verder. De vragen die ertoe doen: hoe vaak komt het werk terug, staat het proces stil genoeg om het vast te leggen, en dekt een bestaand pakket het niet al?
Drie plekken waar de winst zit
Een webapplicatie verdient zich vrijwel altijd op een van drie plekken terug. De eerste is intern herhaalwerk: gegevens die iemand overtypt van het ene systeem naar het andere, offertes die uit losse spreadsheets worden samengesteld, een planning die elke week opnieuw met de hand wordt gemaakt. Elk geval op zich is klein; opgeteld kost het iemand elke week een fors deel van zijn werktijd.
De tweede plek is het klantcontact. Klanten bellen of mailen voor een status, een document of een bestelling die ze zelf hadden kunnen afhandelen als ze bij hun gegevens konden. Een portaal haalt die vragen weg bij je team en geeft klanten antwoord op het moment dat ze het zoeken, ook buiten kantooruren. Die winst staat op geen urenstaat, maar je merkt hem aan een stillere telefoon.
De derde plek is werk dat wacht op een volgende hand. Een aanvraag die in een mailbox ligt tot iemand hem goedkeurt, een order die pas verder kan als de binnendienst hem heeft gezien. Hier zit de winst niet in minder uren, maar in doorlooptijd: het proces beweegt zonder dat iemand eraan hoeft te trekken.
Drie voorwaarden voordat de som kan kloppen
Of die winst de investering waard is, hangt af van drie voorwaarden. Ze klinken vanzelfsprekend, maar wie er een overslaat, rekent zich rijk.
De eerste is herhaling. Eenmalig werk rechtvaardigt zelden software, en dat geldt ook voor werk dat vervelend is maar weinig voorkomt. De som is hoe vaak het werk terugkomt maal wat elke keer kost, en aan allebei de kanten moet iets van betekenis staan.
De tweede is een stabiel proces. Software legt een werkwijze vast. Verandert het proces nog maandelijks omdat het team nog zoekt hoe het moet, dan leg je iets vast dat niet af is, en begint het aanpassen op de dag van de oplevering.
De derde is een proces dat een pakket niet dekt. Voor boekhouding, urenregistratie of een gangbaar salesproces bestaan uitstekende standaardpakketten; maatwerk is daar zelden te verantwoorden. Maatwerk wint waar het proces het onderscheid van je bedrijf draagt en een pakket je dwingt je werkwijze te verbuigen. Waar die grens ligt, lees je in wanneer een maatwerk webapplicatie wint van SaaS.
Signalen dat je beter nog wacht
Soms is het eerlijke antwoord: nog niet. Deze signalen wijzen daarop.
- Het proces verloopt elke keer anders en bestaat vooral in het hoofd van een collega. Wat je niet kunt beschrijven, kun je niet laten ontwikkelen.
- De gegevens die de applicatie nodig heeft, staan nergens betrouwbaar: klantgegevens in drie versies, prijzen in een spreadsheet die niemand bijhoudt. Een applicatie maakt dat zichtbaar, niet beter.
- Het werk komt een paar keer per jaar voor. Hoe vervelend het ook is, de som komt dan niet rond.
- Een standaardpakket dekt het proces vrijwel volledig, en wat ontbreekt is een gewoonte, geen vereiste.
- Niemand heeft tijd om tijdens de ontwikkeling mee te kijken en te testen. Software die zonder de werkvloer wordt gemaakt, past zelden bij het werk.
Herken je twee of meer van deze signalen, dan is wachten geen uitstel maar een besluit. Je bespaart de investering en, belangrijker, je voorkomt software die niemand gebruikt.
Wat je doet als het nog te vroeg is
Wachten betekent niet stilzitten. Leg eerst het proces vast zoals het nu werkelijk loopt, stap voor stap, inclusief de omwegen. Dat levert vaak al verbeteringen op waar geen software voor nodig is, en het is de beschrijving die een ontwikkelpartner later nodig heeft.
Meet daarna een paar weken hoeveel tijd erin gaat zitten en hoe vaak het misgaat. Hoe je dat aanpakt, en waarom de uren maar het zichtbare deel van de kosten zijn, lees je in handmatig data kopiëren kost meer dan de uren die je ziet.
Staat het proces bijna stil, begin dan klein: een eerste versie die alleen het kernproces afdekt, in gebruik bij de mensen die er dagelijks mee werken. Zo zie je of de werkwijze houdt voordat je de rest laat ontwikkelen. Hoe klein zo’n eerste versie mag zijn, lees je in MVP of volledig uitgewerkte software.
Pas dan maak je de rekensom: de uren maal wat een uur je organisatie kost, maal hoe vaak het werk terugkomt, tegenover de volledige investering inclusief het onderhoud in de jaren na de oplevering. Een uitgewerkt voorbeeld van die som staat in waarom software op maat juist voor middelgrote bedrijven loont.
Drie vragen om het moment te toetsen
Wil je snel scherp krijgen of het moment er is, dan volstaan drie vragen.
- Hoeveel uur per week zit er in het handwerk dat de applicatie overneemt, en bij wie ligt dat werk?
- Wat kost een fout, zoals dubbel ingevoerde gegevens of een gemiste levering, en hoe vaak gaat het mis?
- Hoeveel vragen handelt je team af die klanten zelf hadden kunnen beantwoorden als ze hun gegevens konden inzien?
Komt er op alle drie een klein getal uit, dan is een webapplicatie op dit moment niet belangrijk voor je bedrijf, hoe overtuigend het verhaal van een leverancier ook klinkt. Komt er op een van de drie een getal uit dat je niet wilt laten liggen, dan heb je de basis van je businesscase. Bewaar die antwoorden: ze zijn straks je nulmeting als je wilt meten of de software zich terugverdient.
Herken je zo’n terugkerend proces, maak de toets dan eerst samen met iemand die er dagelijks in werkt. Op onze pagina over webapplicaties en portalen lees je wat we ontwikkelen voor organisaties die dat punt bereikt hebben. En is het antwoord op dit moment nog niet, dan zeggen we dat liever aan het begin van een gesprek dan aan het eind van een project.