Wanneer kies je voor het ontwikkelen van eigen software?
In deel 2 gaan we meer inzoomen op het maken van een beslisschema om zo antwoorden te krijgen of software zelf te ontwikkelen of toch voor een kant-en-klare oplossing te gaan. En wat zijn dan belangrijke zaken om niet uit het oog te verliezen?
Beslisschema
Het zou mooi zijn als er een beslisschema gemaakt kan worden met aan de ene kant jouw eisen en wensen en aan de andere kant de optie om software zelf te ontwikkelen (of gebruik te maken van een bestaande applicatie).
Met een dergelijk beslisschema met het eventueel toevoegen van wegingsfactoren kan er een meer eenvoudiger besluit of advies gegeven worden.
Eenvoudige onderdelen van een dergelijk beslisschema bestaan grofweg uit de volgende onderdelen:
- Aan welke criteria moet er minimaal aan worden voldaan?
- Ga je voor een standaardoplossing of besluit je toch voor maatwerk te gaan?
- Welke prioriteiten hanteer je en voeg je daar nog wegingsfactoren aan toe?
- Wat zijn de initiële kosten, verwachte beheerkosten- en trainingskosten, licentiekosten?
- Wat zijn de verwachtingen voor ontwikkelings- en uitbreidingskosten?
Vraag: kiezen voor een bestaande oplossing of zelf gaan ontwikkelen?
Het is een lastige keuze om vooraf te bepalen of je voor een bestaande oplossing kiest of dat je besluit toch zelf software te gaan ontwikkelen. Je zou de volgende vragen kunnen stellen:
- Hoe uniek zijn de procedures binnen je organisatie?
- Welke software draagt het meest bij aan jouw ambitie?
- Hoeveel tijd heb je voor het begeleiden van een ontwikkeltraject?
- Hoeveel kennis heb je in huis?
- Kan ICT mij voldoende ondersteunen?
- Gaan we de software zelf hosten? Of in de cloud?
Neem in je beslissingstraject altijd beide opties mee; zelf doen of uitbesteden.
Vergelijken van standaard software met een maatwerk applicatie
In het onderstaande schema zie je de verschillen in grote lijnen.
| |
Standaard oplossing |
Maatwerk oplossing |
| Functionaliteit |
Vast |
Bepaal jezelf |
| Werkwijze |
Vast |
Situationeel |
| Veiligheid |
Hoog (meestal) |
Hoog |
| Flexibiliteit |
Gedeeltelijk |
Volledig |
| Locatie dataopslag |
Lokaal of op infrastructuur leverancier |
Eigen (virtuale) infrastructuur, cloud |
| Schaalbaar |
Laag |
Hoog |
| Intregratie |
Afhankelijk |
Hoog |
| Controle |
Laag |
Hoog |
| Support |
Helpdesk |
Ontwikkelaar, Servicedesk |
| Risico |
Acceptatie medewerkers |
Kennisopbouw in eigen organisatie |
| Eigendom |
Niet |
Organisatie |
| Advieskosten |
Hoog |
Gemiddeld |
| Ontwikkelkosten |
Alleen voor extra's |
Hoog |
| Licentiekosten |
Per gebruiker en/of voor organisatie |
Minimaal |
| Implementatie |
Hoog |
Laag |
| Scholing |
Gemiddeld |
Laag of minimaal |
| Onderhoud |
Gemiddeld |
Gemiddeld |
Welke factoren bepalen de kosten?
Bij de keuze voor een applicatie laten maken is het goed om te weten welke factoren de kosten bepalen. Hieronder een overzicht:
- Inventarisatiekosten
- Uurtarief van de ontwikkelaars
- Vakkundigheid van de ontwikkelaars
- Technologie; toekomstbestendig van code en architectuur
- Bestaande componenten; open source of hergebruik van basis functionaliteit
- Intellectueel eigendom
- Onderhouds- en hostingkosten
- Interne uren of externe kennis
Hieronder volgt een toelichting op deze 8 factoren.
- Inventarisatiekosten
Dit zijn de kosten voor het analyseren en vastleggen van de eisen en wensen voor de software. Dit kan variëren van workshops en offertegesprekken tot een proof of concept. Hoe grondiger de inventarisatie, hoe beter de verwachtingen worden afgestemd.
- Uurtarieven
De uurtarieven van ontwikkelaars verschillen sterk, afhankelijk van hun ervaring, locatie, en expertise. Lokale ontwikkelaars zijn vaak duurder (€80 tot €150 per uur), terwijl outsourcing naar landen als Oost-Europa of Azië lagere tarieven kan bieden (€40 tot €80 per uur), maar dit kan ook communicatie-uitdagingen opleveren. Wij hebben daar geen goede ervaringen mee. Een tegenmaatregel zou kunnen zijn om aanvullende projectbegeleiding in te zetten.
- Vakkundigheid van de ontwikkelaars
Meer ervaren ontwikkelaars werken sneller en leveren kwalitatief betere code, wat op lange termijn kosten kan besparen. Ook is hun expertise op het gebied van security, privacy en data van belang. En hoe is een partner ingewerkt in jouw branche? Of moet er nog veel tijd gestoken worden om de informatiepositie te versterken?
- Technologie; toekomstbestendig van code en architectuur
De keuze voor technologieën (zoals programmeertalen, frameworks, en databases) heeft invloed op de kosten. Het is belangrijk om te kiezen voor toekomstbestendige technologieën die goed onderhouden worden, om problemen en extra kosten in de toekomst te voorkomen. Ga je voor een gesloten systeem van een leverancier waarbij je bepaalde afhankelijkheden aan durft?
- Bestaande componenten; open source of hergebruik van basisfunctionaliteit
Het gebruik van open-source software of hergebruik van eerder ontwikkelde componenten kan de kosten verlagen. Denk aan bestaande inlogs, rapportagetools, of dashboards die niet helemaal vanaf nul gebouwd hoeven te worden. Ook een groot voordeel van een open-source oplossing: over een langere periode kan je veel besparen op licentiekosten (per gebruiker).
- Intellectueel eigendom
Wie de eigenaar is van de broncode kan de kosten beïnvloeden. Als jij als klant het intellectueel eigendom wilt hebben, kan dit leiden tot hogere kosten. Dit biedt echter wel de vrijheid om de software later zelf aan te passen of verder te ontwikkelen.
- Onderhouds- en hostingkosten
Na de oplevering moeten de applicaties gehost worden, waarvoor servers en infrastructuur nodig zijn. Daarnaast zijn er kosten voor het onderhouden en up-to-date houden van de software (via een SLA - Service Level Agreement).
Neem mee in jouw berekening dat een applicatie vanaf de start nog niet af is. De meeste applicaties worden afhankelijk van de diepgang en reikwijdte meer intensief gebruikt door (nieuwe) klantengroepen en vragen meer onderhoud en neem mee dat er ook uitbreidingsverzoeken komen. Het is dan slim om de uitbreidingskosten wel te budgetten.
- Interne uren en externe kennis
De ontwikkeling van software vraagt tijd van je eigen team voor het geven van feedback, testen en het begeleiden van het proces. Als je zelf niet genoeg capaciteit of kennis hebt, kan het inhuren van een externe product owner of projectmanager noodzakelijk zijn.
Veelvoorkomende fouten bij softwareontwikkeling
Bij het zelf ontwikkelen van software worden vaak een aantal veelvoorkomende fouten gemaakt, die de kwaliteit van de software of de efficiëntie van het ontwikkelproces negatief kunnen beïnvloeden. Hier zijn de meest gemaakte fouten:
- Onduidelijke doelstellingen en eisen
Een van de grootste fouten is het starten van een project zonder heldere, concrete doelen. Als je niet precies weet wat de software moet doen of welke problemen het moet oplossen, kunnen ontwikkelaars moeite hebben om de juiste functionaliteiten te leveren. Dit leidt vaak tot vertragingen, extra kosten en een product dat niet aansluit op de behoefte.
- Gebrek aan planning en prioritering
Softwareprojecten mislukken vaak door slechte projectplanning. Zonder een duidelijke roadmap en prioritering van functies kunnen ontwikkelteams verdwalen in een ongestructureerd proces. Het is belangrijk om eerst een Minimum Viable Product (MVP) te definiëren en vervolgens de roadmap te volgen voor toekomstige uitbreidingen.
- Het niet betrekkenen van eindgebruikers in een vroeg stadium
Veel bedrijven maken de fout om de software te ontwikkelen zonder gebruikers of stakeholders vroegtijdig te betrekken. Hierdoor wordt de software vaak ontwikkeld op basis van aannames die niet overeenkomen met de daadwerkelijke behoeften van gebruikers. Vroege en regelmatige feedback is cruciaal om fouten te voorkomen en de acceptatie te vergroten.
- Verkeerde technologiekeuze
Het kiezen van de verkeerde technologie of architectuur kan desastreuze gevolgen hebben voor de lange termijn. Vaak worden verouderde technologieën gekozen omdat het team er bekend mee is, terwijl nieuwe technologieën betere prestaties en toekomstbestendigheid zouden kunnen bieden. Dit kan leiden tot meer onderhoudskosten en zelfs de noodzaak om de software te herbouwen.
- Slechte documentatie
Het niet vastleggen van beslissingen, code en processen zorgt voor problemen bij onderhoud, opschaling en toekomstige uitbreiding van de software. Goede documentatie is essentieel om een project efficiënt te beheren, vooral als er nieuwe ontwikkelaars bij het project komen.
- Onvoldoende testen
Een veelvoorkomende fout is het overslaan of minimaliseren van tests. Dit kan leiden tot fouten en bugs die pas later, vaak in een productieomgeving, aan het licht komen. Het is belangrijk om zowel handmatig als automatisch testen uit te voeren en te investeren in kwaliteit om dure fouten te voorkomen.
- Slechte communicatie binnen het team
Gebrek aan communicatie tussen ontwikkelaars, projectmanagers en stakeholders leidt vaak tot misverstanden en verkeerde interpretaties van de vereisten. Het is belangrijk om duidelijke lijnen van communicatie en regelmatige updates en feedbacksessies te hebben.
Wat ook regelmatig terugkeert zijn wisselingen in het kernteam. Wat voor vertragingen of extra kosten kan leiden.
- Te veel functies in één keer willen bouwen
De poging om meteen een volledig af product te bouwen kan leiden tot "feature creep," waarbij steeds meer functies worden toegevoegd en de complexiteit toeneemt. Dit zorgt vaak voor vertragingen en hogere kosten. Het is beter om een eerste werkbare versie (MVP) te bouwen en functies later stapsgewijs toe te voegen.
- Geen aandacht voor schaalbaarheid en onderhoud
Veel software wordt ontwikkeld zonder oog voor toekomstige schaalbaarheid en onderhoud. Als het product succesvol is en groeit, kan het zijn dat de software onvoldoende is voorbereid op een grotere gebruikersbasis of complexere eisen, wat kan leiden tot grote herstructureringskosten.
- Verwaarlozen van beveiliging
Beveiliging wordt vaak over het hoofd gezien in de vroege fasen van ontwikkeling, maar is van cruciaal belang om de integriteit en vertrouwelijkheid van gegevens te waarborgen. Het implementeren van security best practices vanaf het begin kan problemen en schandalen in de toekomst voorkomen.
Door deze valkuilen te vermijden en te focussen op goede planning, communicatie, testen en schaalbaarheid, kunnen veel problemen bij softwareontwikkeling worden voorkomen.
Conclusie
Na het lezen van
deel 1 en deel 2 van het artikel weet je nog steeds niet wat het laten ontwikkelen van een applicatie kost. Maar je weet wel welke vragen je moet beantwoorden en welke keuzes je zou kunnen maken.
Het laten ontwikkelen van maatwerksoftware brengt diverse kosten met zich mee, variërend van inventarisatie en uurtarieven tot integratie en onderhoud. Door vooraf goed na te denken over zaken zoals de doelgroep, noodzakelijke functionaliteiten en mogelijke integraties met bestaande systemen, kun je de kosten beter inschatten en weloverwogen beslissingen nemen.
Hoewel de initiële investering hoog kan zijn, biedt maatwerksoftware vaak flexibiliteit en groeipotentieel die standaardoplossingen niet altijd kunnen bieden. Door het maken van een solide businesscase en het helder formuleren van prioriteiten, leg je de basis voor een succesvolle en kostenefficiënte softwareontwikkeling.
Advies is om op de volgende vragen een helder antwoord te formuleren:
- Ambities op lange termijn
- Bedrijfsdoelstellingen
- Beschikbare tijd en budget
Met deze voorbereiding kun je, samen met een softwarebedrijf, de kosten achterhalen en starten met software innovatie.