De eerlijke standaardkeuze voor elk bedrijfsproces is standaardsoftware. Boekhouding, e-mail, salarisadministratie, projectbeheer, klantrelatiebeheer: voor al deze zaken bestaan uitstekende producten, die een voorspelbaar maandbedrag kosten en door iemand anders worden onderhouden. Je eigen versie daarvan bouwen is bijna altijd een vergissing.
En toch worden er elke dag maatwerkapplicaties gebouwd, om goede redenen. De kunst is herkennen wanneer je zo'n reden hebt en wanneer je gewoon gefrustreerd bent over een tool die je niet goed hebt ingericht.
Signalen dat standaardsoftware nog steeds de juiste keuze is
- Het proces is een commodity. Factureren, boekhouden, e-mailmarketing, ticketing. Jouw manier van werken is niet wat je bedrijf onderscheidt.
- De wrijving zit in de inrichting, niet in de mogelijkheden. De tool kan wat je nodig hebt; niemand heeft hem ingericht. Een middag met de documentatie of een consultant verslaat een ontwikkelproject.
- Er is geen eigenaar. Maatwerksoftware heeft iemand binnen het bedrijf nodig die bepaalt wat ze doet en dat blijft bepalen. Zonder die persoon verwatert ze.
- Het team is klein en het volume is laag. Handmatige stappen die een uur per week kosten, zijn nog lang goedkoper dan software.
Signalen dat maatwerk de moeite waard is
- Het proces is je onderscheidend vermogen. De manier waarop je offreert, plant, assembleert, inspecteert of levert is waarom klanten voor jou kiezen, en geen enkel product brengt dat goed in kaart.
- Spreadsheets zijn het systeem geworden. Als de echte werkwijze in spreadsheets leeft die tussen drie tools heen en weer gaan, met mensen die bij elke stap gegevens overtypen, draait het bedrijf al op maatwerksoftware. Alleen is die kwetsbaar en zonder versiebeheer.
- Je betaalt voor gebruikers en functies die je niet gebruikt, omdat de enige tool die jouw ene ongewone eis dekt een enterprise-suite is.
- Gegevens moeten stromen tussen systemen die niet met elkaar praten, en de omwegen zijn handmatig.
- Klanten of partners hebben zicht nodig op je operatie: orderstatus, documenten, goedkeuringen, boekingen. Portalen zijn zelden standaard, omdat elk bedrijf andere dingen laat zien.
De middenweg, die meestal het antwoord is
Maatwerk hoeft niet te betekenen dat alles wordt vervangen. De succesvolste projecten die we zien, houden de standaardtools en bouwen het ene onderdeel dat ontbreekt:
- Een koppeling die gegevens automatisch verplaatst tussen de tools waar je al voor betaalt, zodat de spreadsheet verdwijnt. (Zie onze gids over koppelingen in gewone taal.)
- Een portaal dat bovenop je bestaande systemen zit en klanten of buitendienstmedewerkers precies laat zien wat ze nodig hebben.
- Een enkele workflowtool voor het ene proces dat geen enkel product afhandelt, met al het andere zoals het is.
Elk hiervan is een fractie van "bouw ons een systeem", en elk lost het werkelijke probleem op.
Een eerste versie afbakenen
Is maatwerk gerechtvaardigd, dan is het grootste risico dat je te veel bouwt. Een goede eerste versie:
- Dekt één werkwijze van begin tot eind, niet vijf werkwijzen half. Kies de werkwijze die het meeste pijn doet.
- Vervangt de spreadsheet, niet het boekhoudpakket. Houd de grenzen van de bestaande tools aan en koppel ermee.
- Heeft een benoemde eigenaar die test, over wijzigingen beslist en nee zegt tegen scope.
- Komt vroeg bij echte gebruikers, ook als hij ruw is, want wat mensen er werkelijk mee doen verandert het plan.
- Heeft vanaf dag één een onderhoudsafspraak: wie werkt afhankelijkheden bij, waar wordt hij gehost, wat gebeurt er als iets kapotgaat op maandagochtend om negen uur.
Wat het kost, wordt bepaald door het aantal verschillende schermen en regels, de systemen waarmee gekoppeld moet worden en hoeveel bestaande gegevens overgezet moeten worden. Dat zijn de dingen om vast te leggen in de briefing; de technologiekeuze volgt eruit.
Vragen aan wie het gaat bouwen
- Van wie zijn de code en de gegevens aan het einde? (Van jou, als het goed is.)
- Waar gaat het draaien, en wat kost dat per maand?
- Hoe worden updates, back-ups en beveiligingspatches na de lancering geregeld?
- Welke documentatie en toegang krijgen we, zodat een andere ontwikkelaar het kan overnemen?
- Wat is de kleinste versie die nuttig zou zijn, en kunnen we daar beginnen?
Een ontwikkelaar die daar ontspannen op antwoordt, is er een waarmee je kunt werken. Wil je een werkwijze doornemen en horen of maatwerk daarvoor het juiste antwoord is, beschrijf hem dan in gewone woorden. Vaak is het antwoord een kleine koppeling in plaats van een applicatie, en dan zeggen we dat.