Wat kost maatwerksoftware? Maak scope, onzekerheid en beheer vergelijkbaar

Een prijs begint bij een afgebakende werkstroom

Vraag eerst welke taak de eerste versie van begin tot einde ondersteunt. Een klantportaal voor het indienen van documenten is een andere opdracht dan een portaal dat wijzigingen beoordeelt, afspraken bevestigt en facturen laat corrigeren. Ook als beide voorstellen één startscherm tonen, verschillen hun beslissingen en controles. Beschrijf daarom een normale taak en een belangrijke uitzondering voordat je bedragen naast elkaar legt.

Een fictief adviesbureau wil klanten gegevens laten aanvullen. In de eerste variant uploaden zij documenten die medewerkers handmatig beoordelen. In de tweede variant leest het systeem gegevens uit, vergelijkt die met bestaande records en stelt wijzigingen voor. Het tweede ontwerp omvat ander onderzoeks-, test- en beheerwerk. Zonder die verschillen kan het goedkoopste voorstel vooral een kleinere opdracht blijken te beschrijven.

GOV.UK Service Manual: How the discovery phase works ↗

Maak de prijsopbouw leesbaar

Splits de begroting in begrijpelijke resultaten: procesonderzoek, ontwerp, technische basis, gegevensoverdracht, gebruikershandelingen, testen en invoering. Dit hoeft geen urenstaat met iedere kleine activiteit te worden. Wel moet je kunnen herkennen welk werk de belangrijkste onzekerheid wegneemt en welk werk een aantoonbare functie of beheerhandeling oplevert. Vraag om uitleg bij posten waarvan de uitkomst onduidelijk blijft.

Let op kosten die buiten de ontwikkelopdracht vallen. Denk aan licenties, hosting, gebruik van externe diensten, interne voorbereiding en instructie voor medewerkers. Onderzoek of terugkerende kosten inbegrepen zijn of apart worden gefactureerd. Een aannemelijk bedrag voor de bouw vertelt weinig over de totale werkwijze wanneer gegevensopschoning, toegang regelen of dagelijkse beoordeling niet in de vergelijking worden meegenomen.

Behandel onzekere afhankelijkheden als onderzoek

Een bestaande database, beperkte API of onbekende productregel kan de raming sterk beïnvloeden. Benoem de specifieke onzekerheid: kan een aanvraag met bijlagen worden opgehaald, is een vaste identificatie beschikbaar of kunnen rechten per organisatie worden afgedwongen? Een korte haalbaarheidstest kan daar gericht antwoord op geven. Spreek vooraf af wat het onderzoek moet aantonen en wie de benodigde informatie levert.

Een onzeker onderdeel verbergen in een globale opslag maakt de begroting minder bespreekbaar. Maak liever duidelijk welke uitvoering al kan worden geraamd en welk besluit volgt na onderzoek. Bij het adviesbureau kan een eerste technische proef uitwijzen dat historische bijlagen niet via de beschikbare export komen. Dan kan de scope worden aangepast voordat een brede migratiebelofte onderdeel van de bouwopdracht wordt.

Bij een begroting horen ook toegang, documentatie en de mogelijkheid om later met een andere ontwikkelaar door te werken: Nieuwe software opleveren: regel code, accounts, gegevens en doorontwikkeling.

Waarom uitzonderingen de omvang veranderen

De normale route geeft zelden het hele werk weer. Een klant kan een document vervangen terwijl een medewerker het beoordeelt. Een externe dienst kan wel opslaan maar geen bevestiging teruggeven. Een gebruiker kan bij meerdere organisaties horen. Dergelijke gevallen veranderen gegevensmodellen, toegang, foutafhandeling en de benodigde proefset, ook wanneer er nauwelijks extra schermen bijkomen.

Kies de uitzonderingen die voor jouw organisatie bepalend zijn en bespreek welke in de eerste versie worden ondersteund. Andere gevallen kunnen voorlopig via een afgesproken handmatige route lopen. Dat kan de eerste investering beperken, mits iemand het werk kan uitvoeren en de overgang later herkenbaar blijft. Een expliciete beperking is beter te begroten dan een algemene verwachting dat alle bestaande situaties automatisch worden afgehandeld.

Werk een eigen kostenvergelijking uit

Maak een tabel met eenmalige werkzaamheden, terugkerende kosten en interne inspanning. Gebruik de aangeboden bedragen en noteer periode, omvang en inbegrepen werk. Een variant kan minder bouw vragen maar meer beoordeling door medewerkers. Een andere kan extra automatisering bevatten met meer test- en beheerwerk. Beide kunnen passend zijn; de uitkomst hangt af van werkelijk gebruik en van de gekozen verantwoordelijkheid.

Gebruik een fictieve rekenstructuur om het verschil te zien: uitgaven in het eerste jaar bestaan uit de afgesproken eenmalige invoering plus twaalf maanden terugkerend gebruik, aangevuld met apart geraamd intern werk. Vervang alle posten door eigen gegevens. Controleer dat een dienst niet tegelijk in een abonnement en als losse kostenpost wordt meegeteld. Houd bedragen, tijdseenheden en capaciteitswaarde gescheiden zodat de berekening uitlegbaar blijft.

Onderzoek waarde zonder een besparing te beloven

Meet hoeveel tijd het huidige proces vraagt en welk deel daarvan de nieuwe versie mogelijk verandert. Neem zoeken, controle, herstel en uitzonderingen mee. Minder overtypen kan ruimte geven voor ander werk, maar verlaagt niet vanzelf het salarisbudget of de externe rekening. Beschrijf daarom eerst welke capaciteit vrijkomt en welke concrete activiteit de organisatie daarmee wil ondersteunen.

Vergelijk na de pilot dezelfde taakdefinitie en periode. Een nieuwe applicatie kan aanvankelijk meer instructie vragen of een probleem zichtbaar maken dat eerder verborgen bleef. Beoordeel daarom niet alleen snelheid maar ook volledigheid, begrijpelijke voortgang en herstelwerk. Kies een paar meetbare indicatoren met eigen doelen. Het onderscheid tussen indicator en doel uit Google SRE helpt een resultaat beoordelen zonder iedere verbetering direct in euro’s uit te drukken.

Google SRE: Service Level Objectives ↗

Verbind fasen aan beslissingen en bruikbare resultaten

Een gefaseerde opdracht is zinvol wanneer een afgeronde stap een echt besluit mogelijk maakt. Onderzoek kan eindigen met aangetoonde toegang en een gegevensafspraak. Een eerste versie kan één complete klanttaak ondersteunen. Een pilot kan bewijs geven over dagelijks gebruik en uitzonderingen. Vraag bij iedere fase welk resultaat beschikbaar is en welke informatie nodig is om een volgende investering te beoordelen.

Voorkom dat fasering alleen een betalingsschema wordt terwijl alle onzekerheid pas op het einde samenkomt. Het adviesbureau kan eerst met een beperkte klantgroep documentaanvulling testen en pas daarna automatische verwerking onderzoeken. Leg vast hoe de bestaande werkwijze ondertussen doorgaat. Een kleine stap moet nog steeds werkbaar zijn; onafgemaakte overdrachten kunnen anders meer operationele kosten veroorzaken dan de begroting laat zien.

Neem onderhoud en verandering serieus

Software blijft afhankelijk van gebruikte diensten, bibliotheken, accounts en bedrijfsregels. Bespreek wie meldingen opvolgt, updates beoordeelt en veranderingen test. Maak het verschil duidelijk tussen afgesproken beheerwerk, het herstellen van een defect en nieuwe functionaliteit. Die grenzen bepalen welke terugkerende inspanning werkelijk is gedekt en welke besluiten later opnieuw aan de opdrachtgever worden voorgelegd.

Vraag ook hoe een tweede ontwikkelaar een kleine wijziging kan uitvoeren. Beschikbare code, bouwinstructies en proefgevallen beïnvloeden de overdraagbaarheid van toekomstig werk. Een lage initiële prijs kan minder aantrekkelijk worden wanneer iedere verandering eerst reconstructie vereist. Dat betekent niet dat alle documentatie uitgebreid moet zijn; zij moet de belangrijkste beslissingen, afhankelijkheden en beheerhandelingen begrijpelijk genoeg vastleggen voor de afgesproken organisatie.

Vergelijk voorstellen met dezelfde open vragen

Vraag bij elk voorstel welke aannames zijn gebruikt, welke werkzaamheden zijn uitgesloten en welke afhankelijkheden nog moeten worden bevestigd. Leg een normale taak, twee uitzonderingen en de gewenste eerste invoering naast de beschreven oplevering. Een leverancier moet kunnen uitleggen hoe het voorstel daarop aansluit en waar een alternatief of kleiner begin verstandig kan zijn.

Sluit de begroting af met de gekozen scope, een verantwoordelijke voor inhoudelijke besluiten en een route voor wijzigingen. Een project kan leren en veranderen zonder dat de financiële afspraken onbegrijpelijk worden. De kern is dat nieuw werk herkenbaar wordt beoordeeld op zijn gevolgen. Daarmee vormt de prijs onderdeel van een verklaarbare opdracht in plaats van een los getal waarmee ongelijksoortige oplossingen worden gerangschikt.

Van uitleg naar een concrete projectkeuze

Leg je aannames, open vragen en oplevercriteria vast in de bijbehorende tool. Gebruik de dienstengidsen om uitvoering en afbakening te bespreken.

• Maatwerksoftware ↗
• Klantportaal Laten Maken ↗

Vragen over dit onderwerp

Verder met een aansluitende vraag