Software is vandaag de dag overal. Sommige projecten zijn recent opgeleverd, terwijl andere al 20 jaar geleden zijn gemaakt. Voor eigenaren van de laatstgenoemde categorie roept dit vaak veel vragen op.
Als ondernemer kan het voorkomen dat je in de afgelopen decennia behoefte had aan software. En vaker wel dan niet, wordt er uiteindelijk iets op maat gemaakt. Elke ondernemer heeft graag een nichemarkt in handen, en daar bestaat nu eenmaal geen generieke oplossing voor. En zolang de leverancier blijft bestaan, is het onderhoud en de doorontwikkeling van maatwerksoftware meestal gegarandeerd.
Maar het kan wel voorkomen dat een leverancier wegvalt of niet langer ondersteuning biedt. Dit kan te wijten zijn aan verschuivingen in specialisatie, vertrekkend personeel, of stijgende kosten van onderhoudscontracten. In dergelijke gevallen rijst de vraag: wat nu?
Wanneer een nieuwe partij de software gaat onderhouden en/of doorontwikkelen, ontstaan er nieuwe vragen waar eerder meestal nooit over gesproken is. Hoe staat het er namelijk momenteel voor? Is er documentatie beschikbaar? In welke programmeertaal is de software geschreven? Welke afhankelijkheden heeft de software? Dit zijn slechts enkele van die vragen.
Soms stellen opdrachtgevers eisen aan de ontwikkelaar, zoals het gebruik van specifieke talen, technieken of frameworks. Dit wordt vaak gedaan in de hoop dat een dergelijke structuur het gemakkelijker maakt om over te stappen naar een andere partij later. Echter, in de praktijk blijkt het vaak ingewikkelder dan gedacht. Hier zijn enkele typische uitdagingen die desondanks kunnen ontstaan:
- De programmeertaal van de software is verouderd en programmeurs die hiermee kunnen werken zijn moeilijk te vinden.
- Hetzelfde geldt voor verouderde frameworks die binnen het project worden gebruikt.
- Nieuwe ontwikkelaars kunnen hoge kosten in rekening brengen voor het inlezen in de bestaande codebase.
- Nieuwe ontwikkelaars kunnen het project wel oppakken, maar werken mogelijk niet op dezelfde correcte wijze.
- Het kan zelfs zo zijn dat het project te verouderd is en opnieuw moet worden opgebouwd, aldus de nieuwe partij.
Dit zijn allemaal scenario's die een ondernemer met softwarebezit kan tegenkomen, en ze kunnen leiden tot onverwachte kosten en frustraties. Het vinden van de juiste partij om het project over te nemen kan daarom lastig blijken. Ook als er vooraf goed nagedacht is over de noodzaak hiervoor later.
Een van de belangrijkste tips die ik ondernemers kan geven in deze situatie, is om met verschillende partijen te praten. Elke ontwikkelaar heeft zijn eigen werkwijze en expertise, en het raadplegen van verschillende experts kan helpen om een objectief beeld te krijgen van de staat van het project en de mogelijke opties voor overname vanaf dat moment.
Het is bijvoorbeeld de moeite waard om platforms voor freelancers te gebruiken om experts te vinden die bekend zijn met de specifieke technologieën die in het project worden gebruikt. En dus niet in gesprek te gaan met consultants of salespersonen van een eventuele nieuwe partij direct. Door inzichten te gebruiken van onafhankelijke programmeurs, kun je beter bepalen welke route het meest geschikt is voor de overname van het project.
Vraag daarbij aan die programmeurs om tegen betaling een beoordeling te geven van de staat van het project. Dit omvat onder andere hoe gedateerd het is, of het goed gestructureerd is, welke risico's ze identificeren en andere opmerkingen die ze hebben. De kosten van een dergelijke evaluatie wegen niet op tegen de potentiële besparingen die later gerealiseerd kunnen worden bij het selecteren van een nieuwe ontwikkelaar.
Kortom, het vinden van de juiste partij om bestaande maatwerksoftware over te nemen kan een uitdaging zijn, maar door verschillende opties te verkennen en expertise in te winnen, vergroot je de kans op succes. Het gaat erom de juiste partner te vinden die het project écht op de juiste wijze kan overnemen en verder kan ontwikkelen. Daarom is het verstandig om onnodige kosten te voorkomen door eerst onafhankelijke technische experts te raadplegen, en niet direct met de technische of zelfs niet-technische personen te praten van de beoogde overnamepartij.