Home / Blog / Softwareontwikkeling / 6 tips om de kosten van maatwerk software te verlagen
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:
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?
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 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 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.
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 verlaagt.
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.
Natuurlijk wil niemand dat de kosten van een maatwerk software project uit de hand lopen. De volgende tips kunnen de prijs flink verlagen:
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. 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:
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 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 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.
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 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”.
Denkt u eraan om maatwerk software te 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:
Senet Eindhoven Gestelsestraat 258 5654 AM Eindhoven Bekijk op kaart
KvK nummer: 17115078 Btw nummer: NL807989083B01
