BLOG

Softwareontwikkeling

6 tips om de kosten van maatwerk software te verlagen

14 september 2020

Wat is goedkoper; maatwerk of standaard?

U heeft een uitdaging: een proces dat ondersteuning nodig heeft of een extra service die u wilt aanbieden. Hiervoor heeft u software nodig en u bekijkt de opties. Als u een keuze moet maken tussen handmatig verder werken of een maatwerk oplossing,  dan zal schaal meestal de doorslaggevende factor zijn. 

Maar een keuze maken tussen maatwerk software of standaard software is lastiger. In deze afweging zullen uiteindelijk prijs en kwaliteit de hoofdrol spelen. Kwaliteit is moeilijk te bepalen, maar het is zeker mogelijk om op inhoudelijke argumenten een besluit te nemen.

Maatwerk software sluit vaak beter aan bij de organisatie en haar bestaande werkwijzen. Het geeft de mogelijkheid om te differentiëren van de concurrentie, om een hoger niveau van dienstverlening te leveren.

Standaard software daarentegen is vaak “battle tested”. Veel problemen en uitdagingen zijn al eerder door anderen ondervonden, en opgelost. Het is mogelijk om aan te sluiten bij “best practices”. Ook geeft standaard software veel duidelijkheid: het is mogelijk om voor aanschaf een goed beeld te vormen en “what you see is what you get”.

Prijs is veel lastiger te plaatsen. Vaak wordt er vanuit gegaan dat standaard software per definitie goedkoper is dan maatwerk software. Dat is vaak het geval, maar zeker niet altijd.

Er zijn drie redenen waarom standaard software (achteraf) wel eens duurder blijkt te zijn dan maatwerk software:

  1. Soms blijkt dat de maandelijkse kosten voor de licentie (óf de eenmalige aanschaf), in combinatie met uitbreidingen en consultancy, toch niet zo voordelig zijn als gedacht.
  2. Soms blijkt het licentiemodel verborgen kosten te bevatten, bijvoorbeeld hogere kosten bij meer gebruik of belangrijke functionaliteiten die alleen bij een duurdere ‘variant’ van de software beschikbaar zijn.
  3. Soms blijkt dat de aanpassingen in de manier van werken die nodig zijn om aan te sluiten bij de standaard software, hoge kosten met zich meebrengen (bijvoorbeeld door lagere productiviteit).

In dit artikel gaan we in op de prijs van maatwerk software. Welke onderdelen kent de prijs van maatwerk software? Wat heeft invloed op de prijs? En het belangrijkste: hoe kan je de prijs op een verstandige manier meenemen in je besluit?

Prijsmodellen: nacalculatie of fixed-price

Natuurlijk zijn er eindeloos veel mogelijkheden om tot een prijs te komen, maar bijna altijd zal de prijs uitkomen op twee concepten: softwareontwikkeling op (1) nacalculatie of (2) fixed-price.

Nacalculatie

Nacalculatie is simpel: er wordt een prijs per uur afgesproken, en er wordt een team van ontwikkelaars ingezet. Belangrijk is wel om duidelijke afspraken te maken met de leverancier over het project. Wie bepaalt de functionaliteit van de applicatie, en hoe wordt deze gewenste functionaliteit vastgelegd? En wie voert er uiteindelijk het projectmanagement?

Een groot voordeel van nacalculatie is de flexibiliteit en vrijheid, een nadeel is natuurlijk een beperkte hoeveelheid duidelijkheid.  Gedegen projectmanagement kan dan inzicht geven in de progressie die wordt geboekt, om op die manier toch een goede vinger aan de pols te houden.

Vaak wordt gedacht dat een vinger aan de pols alleen mogelijk is bij een ‘waterval’ project waar vooraf een duidelijk ontwerp is, en een tijdlijn met tussentijdse  opleveringen. Maar ook bij een agile project met duidelijke communicatie en een regelmatige demonstratie van de software die is ontwikkeld, is een goede vinger aan de pols mogelijk.

Bijkomend voordeel is dat bij een agile project sneller naar een werkend product wordt toegewerkt. Door deze software snel in gebruik te nemen, nog voordat alle functionaliteiten zijn voltooid, kan de investering sneller worden terugverdiend.

Fixed price

Fixed price is wat ingewikkelder. Niet elke leverancier biedt fixed price projecten aan, vanwege het risico dat elk project met zich meebrengt. Als een leverancier dit wel doet, dan zal er in de prijs natuurlijk altijd een bedrag zijn opgenomen om risico’s af te dekken.

Een vaste prijs zal altijd zijn gebaseerd op duidelijke afspraken en een duidelijk ontwerp. Er zijn vele discussies, conflicten en zelfs rechtszaken gevoerd tussen leverancier en klant over wat die duidelijke afspraken nu eigenlijk inhielden. Het is geen uitzondering wanneer daar verschillen van inzicht over ontstaan.

Mogelijkheden om bij te sturen naar nieuwe inzichten – zoals deze eigenlijk altijd ontstaan tijdens een ontwikkelproces – zijn beperkt. En het risico dat additionele functionaliteit later toch nodig is of dat er functionaliteit is ontwikkeld die toch niet nodig bleek, is altijd aanwezig. Bijsturing dient ook altijd schriftelijk te worden vastgelegd hetgeen vaak leidt tot een flinke administratie met addenda ten behoeve van wijzigingen en aanvullingen. De afgesproken fixed price wordt daarmee ook telkens hoger.

Ontwikkelkosten

De prijzen voor bovenstaande prijsmodellen komen uiteindelijk op dezelfde manier tot stand. De (verwachte) hoeveelheid benodigde ontwikkeluren wordt vermenigvuldigd met een uurtarief, en in het geval van fixed price wordt er nog enige vorm van risicodekking toegevoegd.

Het is om die reden dan ook erg aantrekkelijk om te werken met de partij met het goedkoopste uurloon: dit lijkt al snel het goedkoopste. Maar niet elke ontwikkelaar is even ervaren of werkt even snel. Ook twee junior programmeurs zijn niet altijd even snel als één senior: kwantiteit wint niet van kwaliteit.

Ook de gebruikte technologie, zoals programmeertaal, platform of database-engine kunnen een grote invloed hebben op de ontwikkelkosten. Over het algemeen hebben programmeurs voor veel voorkomende talen een lager uurtarief dan programmeurs voor een meer exclusieve taal of techniek. Ook kan er in sommige talen sneller ontwikkeld worden, wat het aantal benodigde uren en daarmee de prijs verder verlaagd.

De techniek heeft ook invloed op de later benodigde hosting- en beheerkosten. Dus zorg dat u deze kosten meeneemt in uw keuze voor een technologie en/of programmeertaal.

6 tips om een hoge prijs voorkomen

Natuurlijk wil niemand dat de kosten van een maatwerk software project uit de hand lopen. De volgende tips kunnen de prijs flink verlagen:

  • Wees goed voorbereid, en voorkom vertragingen. Veel extra kosten komen voort uit het niet op orde hebben van de benodigde informatie. Zorg dus dat zoveel mogelijk uitgezocht is vóórdat de softwareontwikkelaar aan het werk gaat:
      • Zorg dat de probleemstelling, gebruikers/actoren en globale functionaliteiten duidelijk zijn. Zorg dat deze duidelijk en overzichtelijk op papier staan.
      • Zorg dat aan de praktische voorwaarden is voldaan: zorg dat de huisstijl en het domein beschikbaar zijn en zorg dat toegang en documentatie beschikbaar zijn voor externe software waaraan gekoppeld wordt.
      • Zorg dat de interne contactpersonen duidelijk zijn en dat deze kenbaar zijn gemaakt richting de softwareontwikkelaar. Zorg ervoor dat vragen snel en duidelijk worden beantwoord. Een goede samenwerking is van groot belang.
      • Maak bij de projectvoorbereiding samen met de softwareontwikkelaar een lijst van zaken die voorbereid en aangeleverd moeten worden, met bijbehorende deadlines, en zorg dat deze zaken op tijd zijn!
  • Maak gebruik van (open source) standaardsoftware, en breid deze uit met de functionaliteit die mist. Gebruik bijv. een inlogsysteem dat u intern al in gebruik heeft (bijv. Azure AD waarmee u inlogt op Office 365, of Google Login waarmee u inlogt op Google Apps) om ook in de nieuwe applicatie in te loggen. Of gebruik de open source oplossing ‘Magento’ voor uw nieuwe webshop, en breid deze uit met eigen functionaliteit.
  • Besef goed welke keuzes in het begin van het project gemaakt moeten worden en welke keuzes kunnen wachten.
    Sommige keuzes hebben een grotere impact dan men zou denken, en om hiervan terug te keren moeten veel kosten gemaakt worden. De assumptie dat een wijziging weinig tijd kost kan daarom erg gevaarlijk zijn. Bespreek de kosten van een wijziging dus altijd met de softwareontwikkelaar, en maak de juiste afwegingen.
    Het tegengestelde kan ook waar zijn. Sommige wijzigingen lijken heel groot te zijn, maar blijken na overleg met de softwareontwikkelaar toch niet zo groot te zijn.
    Over het algemeen is het wel zo dat het vaak goed is om keuzes uit te stellen tot het laatste moment. Als de softwareontwikkelaar zegt dat een keuze zonder negatieve gevolgen later gemaakt kan worden, dan is het ook beter om dat te doen. Op die manier voorkom je dat er teveel keuzes in het begin gemaakt moeten worden (wat het gedegen afwegen van voors- en tegens moeilijk maakt), en je voorkomt ook dat er keuzes gemaakt worden die met later opgedane kennis niet zo gemaakt zouden zijn.
  • Weet wanneer te automatiseren – en wanneer niet. Vaak is het ontwikkelen van een nieuwe maatwerk applicatie dé mogelijkheid voor de organisatie om na te denken over de bedrijfsprocessen en hoe deze geautomatiseerd kunnen worden. De verleiding is dan heel groot om alle activiteiten, en de daarbij horende uitzonderingen, in software te vangen. Toch zijn vaak juist deze uitzonderingen een grote kostenpost. Durf dus de afweging te maken om functionaliteiten die waarschijnlijk maar beperkt van toepassing zijn niet toe te voegen, of tenminste uit te stellen.
  • Originaliteit is nodig. Werk samen met de software partner om functionele deelgebieden te vinden waar veel kosten verborgen zijn, en denk samen aan originele oplossingen om hetzelfde resultaat te bereiken, of manieren om de functionaliteit te versimpelen. Soms betekent dit dat een werkproces moet worden aangepast, maar vaak is het versimpelen van zo’n proces en de daarbij behorende software uiteindelijk een voordeel voor iedereen. Het is belangrijk om terug te durven gaan naar het probleem wat opgelost moet worden (in plaats van de oplossing die is voorgedragen), en samen met de softwareontwikkelaar alternatieve oplossingen te bedenken.
  • Blijf nadenken. Vaak ligt er een grote focus op de software in het initiële ontwikkelproces. Er wordt een strak budget aangehouden, en er wordt goed afgewogen welke functionaliteit wel en niet nodig is. Maar als de software dan eenmaal (succesvol) in gebruik is genomen, wordt er vaak veeluitgegeven aan additionele functionaliteiten zonder erbij stil te staan of er een echte noodzaak is daarvoor.. Soms wordt er bij elke uitzondering die wordt ondervonden contact opgenomen met de softwareontwikkelaar.Goed nieuws voor de softwareontwikkelaar, maar voor uw organisatie is het waarschijnlijk beter om de kosten-baten afweging te blijven maken.

Onderhoud aan software en een dienstenniveau-overeenkomst (DNO)

De prijs van maatwerk software bestaat natuurlijk niet alleen uit de ontwikkelkosten. Ook de kosten voor beheer- en hosting moeten worden meegenomen.

Nadat de software is ontwikkeld moet deze, in het geval van cloud, in de lucht gehouden worden (hosting) en er moet onderhoud worden gepleegd (beheer). Afspraken hierover worden meestal vastgelegd in een dienstenniveau-overeenkomst (DNO) of service level agreement (SLA).

Het afsluiten van de DNO bij dezelfde partij die ook de software ontwikkelt is vaak een logische keuze, dus zorg ervoor dat ook de DNO is besproken voordat het project wordt gegund. Dit voorkomt nare verrassingen vooraf. De behoefte aan een simpele of uitgebreide DNO hangt vaak af van het gebruik van de software. Een ‘simpel’ hulpmiddel zal over het algemeen een simpele DNO kennen, terwijl een complexe, bedrijfskritische applicatie die van belang is voor de bedrijfsvoering een uitgebreidere DNO kent.

Een simpele DNO bevat vaak de hosting van de applicatie (zonder verdere uptime-garanties) en een responstijd voor werkzaamheden in het kader van onderhoud, die op aanvraag uitgevoerd kunnen worden. Het onderhoud zelf zal altijd worden betaald.

Een uitgebreide DNO kan onderstaande afspraken bevatten: 

  • Kwaliteit van hosting. Denk aan ‘uptime’ (hoe vaak mag de software onbeschikbaar zijn) en snelheid (hoe lang mogen pagina’s laden).
  • Veiligheid en betrouwbaarheid. Hoe garandeert de leverancier dat de software veilig is? Welke maatregelen worden genomen? Hoe wordt met persoonsgegevens omgegaan? En welke standaarden worden gehanteerd? Zijn er backups, en hoe vaak worden deze gemaakt?
  • Gebruik van de applicatie. Welke omgevingen zijn er beschikbaar (is er bijvoorbeeld een instructie-omgeving?) Met welke computers, telefoons en tablets is de applicatie te gebruiken? En welke aanvullende software of hardware is daarvoor nodig?
  • Servicedesk. Is er een servicedesk beschikbaar? En zo ja, op welke tijden? Welke meldingen mogen daar worden geplaatst? Hoe snel worden deze behandeld?
  • Overlegstructuren en escalatie. Hoe wordt er overleg gevoerd tussen de leverancier en de klant? En hoe worden escalaties afgehandeld?
  • Onderhoud. Welk onderhoud wordt er binnen de DNO uitgevoerd, en misschien nog belangrijker, welke niet? De verschillende soorten onderhoud (correctief, preventief en adaptief) worden in de paragrafen hieronder verder beschreven.

Correctief onderhoud

Bij het correctief onderhoud worden fouten en storingen in de software verholpen.

Het is belangrijk dat er duidelijke afspraken worden gemaakt over welke fouten en storingen worden gerepareerd, hoe er onafhankelijk wordt bepaald of iets een fout óf een nieuwe functionaliteit is en hoe snel deze fouten en storingen worden verholpen. Normaliter worden er diverse niveaus gehandhaafd, waarin de grootte van de storing bepaalt hoe snel de oplossing wordt geleverd.

Preventief onderhoud

Preventief onderhoud gaat eigenlijk om het voorkomen van correctief onderhoud. Hieronder valt dus het monitoren van de applicatie en het herstellen van mogelijke problemen, het bijwerken van software-versies, het bijwerken naar een nieuwe versie van een programmeertaal en het verbeteren van de algemene kwaliteitseigenschappen van de software (zoals veiligheid, stabiliteit en snelheid).

Stel duidelijke doelen, bijvoorbeeld over hoe snel softwareversies worden bijgewerkt of het voldoen aan standaarden voor informatiebeveiliging, en maak afspraken in de DNO over hoe hieraan gewerkt wordt.

Adaptief onderhoud

Adaptief onderhoud bevat alle wijzigingen die benodigd zijn aan de applicatie, bijvoorbeeld door gewijzigde wetgeving of nieuwe wensen vanuit de organisatie.

Over het algemeen wordt adaptief onderhoud niet opgenomen in een DNO, maar het kan interessant zijn om dit wel te doen. Over het algemeen wordt dit uitgevoerd aan de hand van een vast budget per jaar. Van dit budget worden dan kleine wensen en benodigde wijzigingen uitgevoerd. 

Dit voorkomt een offertetraject voor elke kleine wijziging, en zorgt er zo voor dat de softwareontwikkelaar snel kan reageren op wensen uit de organisatie. Soms kunnen softwareontwikkelaars ook een interessant tarief aanbieden als er zo’n vast budget wordt gehanteerd. Dit maakt het opnemen van adaptief onderhoud in de DNO extra interessant.

Intellectueel eigendom

Het komt nogal eens voor dat een project voor de ontwikkeling van maatwerk software met een bittere nasmaak eindigt, niet vanwege een slecht resultaat, maar vanwege onenigheid over het intellectueel eigendom.

Het ligt het voor de hand dat het intellectueel eigendom van de software die voor u gemaakt is, bij u ligt. Maar dat is niet altijd het geval. Het is dus belangrijk om duidelijke afspraken te maken over wie het intellectueel eigendom over welk deel van de software bezit. 

Over het algemeen is het doel natuurlijk om zoveel mogelijk van het intellectueel eigendom zelf te behouden. Maar soms is dit niet helemaal mogelijk. De softwareontwikkelaar maakt misschien gebruik van andere software(bibliotheken) om de maatwerk applicatie te maken, en kan in dat geval niet het intellectueel eigendom aan u overdragen. In dat geval is het belangrijk om een oneindig doorlopende licentie te verkrijgen, oftewel een “perpetual license”.

Aan de slag met maatwerk software

Denkt u eraan om maatwerk software te willen laten ontwikkelen? Wilt u een beter idee krijgen van de kosten én baten van zo’n project?  Senet heeft jarenlange expertise met maatwerk software en wij kunnen u van een gedegen advies voorzien. Een vrijblijvende afspraak is altijd mogelijk, onze software specialisten staan voor u klaar!

Voor meer inzicht in hoe Senet een verscheidenheid aan klanten in het onderwijs, logistieke, industriële en financiële branches ontzorgt met maatwerk software, lees ook eens onze referentie cases, zoals bijvoorbeeld:

Interesse in een gesprek?

neem contact op met Frank Houweling

Neem contact op

Zie onze privacyverklaring.