Wat wordt er eigenlijk op maat gemaakt?
Bij maatwerk leg je vast welke informatie iemand ziet, wat die persoon mag veranderen en onder welke voorwaarden een volgende stap mogelijk is. De eigen logica kan bijvoorbeeld bepalen wie een aanvraag goedkeurt, welke capaciteit meetelt of wanneer een opdracht klaarstaat voor planning. Een dashboard maakt die afspraken zichtbaar; het is niet de afspraak zelf.
Een CRM, planningstool, database of klantportaal kan onderdeel van bedrijfssoftware op maat zijn. Ook bestaande software laat vaak inrichting en uitbreidingen toe. Het onderscheid is dus niet simpelweg een eigen scherm tegenover een gekocht pakket, maar welke regels je met configuratie kunt afdekken en waarvoor eigen ontwikkeling en onderhoud nodig zijn.
Een fictief voorbeeld: van servicemelding naar werkopdracht
Stel dat een onderhoudsbedrijf meldingen uit een klantportaal ontvangt. Dit is een fictief uitlegvoorbeeld, geen klantcase of bewezen resultaat. De melding bevat een klantnummer, object, probleemomschrijving en gewenste periode. De planner controleert de informatie; alleen een bevoegde medewerker mag de opdracht vrijgeven.
De bedrijfseigen regel kan zijn: een melding zonder bekend object of met een ontbrekende veiligheidsbeoordeling mag niet automatisch naar de planning. De software zet haar apart met een reden en een eigenaar. De verantwoordelijke persoon beoordeelt de uitzondering; het systeem verzint geen ontbrekende gegevens of goedkeuring.
Het klantenbestand kan in het bestaande CRM blijven en de factuur in de boekhouding. De maatwerklaag hoeft dan alleen de melding, controle, vrijgave en overdracht te ondersteunen. Bij een mislukte koppeling moet zichtbaar blijven wat al verwerkt is en wat opnieuw moet worden geprobeerd, zonder dezelfde werkopdracht dubbel aan te maken.
Beschrijf één route in zes afspraken
Gebruik deze invulzin: “Wanneer [aanleiding] optreedt, ontvangt [rol] de gegevens [invoer] uit [leidende bron]. De stap mag verder als [bedrijfsregel] klopt. Bij een afwijking beslist [eigenaar] en is [herstelhandeling] nodig.” Vul de zin met een echte terugkerende taak; vermijd woorden als slim, flexibel of automatisch zolang niet duidelijk is wat er moet gebeuren.
Werk daarna zes punten uit: de gewenste uitkomst; de personen en hun rechten; de benodigde gegevens en hun bron; de normale beslisregels; de uitzonderingen en herstelstappen; en wat nadrukkelijk buiten de opdracht valt. Noteer bij iedere stap welk resultaat de gebruiker moet kunnen controleren. Zo wordt “een planningsdashboard” een bespreekbare opdracht.
Maak ook één voorbeeld waarin de route niet mag doorgaan. Denk aan een ontbrekend klantnummer, onvoldoende bevoegdheid, een gewijzigde afspraak of een onbereikbare koppeling. Spreek af wie dan handelt en hoe die persoon kan zien dat herstel is gelukt.
Wanneer is maatwerk niet de eerste stap?
Wanneer niemand het eens is over de eigenaar of de werkwijze, automatiseert nieuwe software vooral de onduidelijkheid. Leg eerst het proces vast. Controleer vervolgens of betere inrichting van een bestaand pakket of een eenvoudiger werkafspraak het probleem al oplost. Meer functies zijn geen bewijs dat eigen ontwikkeling nodig is.
Blijven er concrete regels of overdrachten over die de bestaande oplossing niet goed ondersteunt? Vergelijk dan standaardsoftware, een hybride route en maatwerk per onderdeel. Deze uitleg helpt je de taak te beschrijven. Ga je een softwareofferte beoordelen, controleer dan of de scope, aannames en acceptatiecriteria in het voorstel duidelijk zijn.
Welke verantwoordelijkheid blijft na oplevering?
Maatwerk neemt beheer niet weg. Bespreek wie wijzigingen beoordeelt, toegangsrechten beheert, back-ups en herstel test, koppelingen bijwerkt en gebruikers helpt. Maak duidelijk welke documentatie, beheeraccounts en exportmogelijkheden beschikbaar zijn als je later een andere beheerder kiest. De kosten van bedrijfssoftware bestaan niet alleen uit bouw, maar ook uit gebruik, onderhoud en interne inzet.
GOV.UK noemt aanpasbaarheid, totale eigendomskosten en controle over gegevens als aandachtspunten bij technologiekeuzes. Dat is overheidsrichtlijn, geen verplicht MKB-keurmerk. De bruikbare vertaling voor jouw opdracht is concreet: leg systeemgrenzen vast, test belangrijke aannames met een prototype en houd een werkbaar verander- en vertrekpad open.
Een prototype bewijst nog geen veilige productieomgeving. Toegangscontrole, privacy, beveiliging, herstel en acceptatie vragen een beoordeling passend bij de gegevens en de gevolgen van fouten. Beloof geen tijdwinst voordat je de bestaande werkwijze en het werkende resultaat op dezelfde manier hebt gemeten.
Neem een procesbeschrijving mee naar het eerste gesprek
Neem één ingevulde proceszin, de gebruikte systemen, een normale situatie en een foutscenario mee. Geef aan welke beslissingen mensen moeten blijven nemen. Daarmee kan een bouwer gerichter aangeven wat inrichting is, waar een koppeling nodig is en welk deel ontwikkeling vraagt. Bespreek een afgebakende softwareopdracht zodra die grens duidelijk is.
