Een gezonde samenwerking met je softwareontwikkelpartner

Financiële administratie, logistiek, marketing, legal, schoonmaak en beveiliging. Allemaal bedrijfsonderdelen die veelvuldig door organisaties worden uitbesteed. Waarom? Het is niet de core business en dus zoek je een partner met expertise. Waarom vinden bedrijven deze keuze voor software-ontwikkeling moeilijker? De belangrijkste reden: de vendor lock-in en dat is niet helemaal onterecht.

De vendor lock-in

Een partner aanhaken voor softwareontwikkeling doe je omdat je als organisatie ziet dat het niet je core business is. Door het uit te besteden hoef je er geen kennis over op te bouwen. Die kennis leg je neer bij je softwareleverancier. Deze kan dat bewust of onbewust gebruiken voor klantbinding: ook al wil je switchen van ontwikkelaar, het is praktisch onmogelijk. Een vendor lock-in. Afhankelijkheid van je leverancier, omdat overstappen te complex of kostbaar is.

Er zijn allerlei technische aspecten die de vendor lock-in kunnen veroorzaken:

• Technologiekeuze: niet iedere programmeertaal en niet ieder component wordt breed gebruikt. Andere softwareontwikkelaars willen of kunnen dit niet onderhouden of doorontwikkelen. Wie neemt bijvoorbeeld een programmeertaal waar weinig programmeurs kennis van hebben over? Of een planningsmodule ontwikkeld door jouw leverancier: hoe draag je dat over?
• Kwaliteit: sommige oplossingen zijn dusdanig verouderd, slecht getest of onnodig complex dat overname niet realistisch is. Herbouw is de enige oplossing, maar wil een andere leverancier wel garant staan voor het beheer en onderhoud in de tussentijd?
• Documentatie: wat als die ene sterprogrammeur over alle kennis beschikt, terwijl deze niet of nauwelijks is opgeschreven? Een enorm risico voor de continuïteit bij een eventueel afscheid van je leverancier of als deze ontwikkelaar niet langer bij je leverancier werkt.
  

Daarnaast zijn er juridische zaken die een risico vormen:

• Intellectueel eigendom: wie is eigenaar van de broncode? Heb je als opdrachtgever toegang tot deze broncode? Is dit voldoende om continuïteit te garanderen of mis je toegang tot documentatie of de tooling voor het releaseproces?
• Toegang tot de productiedata: wat zijn je afspraken met je leverancier over de productieomgeving in de Cloud of on-premise oplossing?
• Een soepele overdracht: welke afspraken heb je gemaakt over een eventuele overdracht naar een andere partij, mocht dit onverhoopt noodzakelijk zijn?

Contractafspraken

Voor zich spreekt dat je naast goede SLA-afspraken (Service Level Agreement, afspraken zoals: hoe snel reageert de leverancier bij downtime?) van tevoren moet nadenken hoe je een eventuele overdracht soepel kunt laten verlopen. Zorg dat duidelijk is vastgelegd wie de eigenaar is van de broncode en dat je in het geval van een geschil toegang tot je productieomgeving kunt eisen voor jouw organisatie of jouw nieuwe leverancier. Daarnaast kan een escrow-regeling je broncode veiligstellen bij een faillissement of geschil met je leverancier. Een escrow-regeling legt vast dat de leverancier de broncode deponeert bij een onafhankelijke partij. Zo ben je zeker van toegang tot de broncode. Toegang tot de broncode is echter niet altijd voldoende; daarover meer in het volgende hoofdstuk.

Wees heel bewust in hoeverre je eigenaar bent van het intellectueel eigendom, ook van die planningsmodule ontwikkeld door je leverancier buiten het project voor jou om! Zo voorkom je in elk geval een juridische vendor lock-in.

Assessment of audit

Hoe ondervang je dan je technische risico’s? Het is verstandig software-assessments uit te laten voeren door een derde partij. Deze partij kan jou en je leverancier inzicht geven in de kwaliteit van je software. Dat geeft jou inzicht en een goede assessment geeft je leverancier concrete aanbevelingen om de dienstverlening richting jou te verbeteren.

Drie aspecten die je zeker wilt meenemen in een assessment:

1. De broncode en de kwaliteit daarvan. In de breedste zin van het woord: daarmee bedoelen we ook technologiekeuzes, security en de kwaliteit van testen.
2. De documentatie. Is de documentatie gestructureerd en voldoende voor een ander om mee aan de slag te gaan?
3. Het releaseproces. Is het releaseproces duidelijk en eenvoudig?
   
   

Handel preventief, niet reactief!

Op het moment dat er wrijving ontstaat in de samenwerking kan jouw zoektocht naar zekerheid argwaan creëren bij je leverancier. Een software-assessment kan als een bedreiging worden gezien waardoor de samenwerking verder onder druk komt te staan.

Het advies is dan ook periodiek een assessment uit te laten voeren, juist als de samenwerking met je leverancier gezond is. Vraag om concrete adviezen die in de ogen van de controlerende partij beter kunnen: dat levert concreet resultaat voor meer zekerheid richting de toekomst. En het is zeker slim vooruit te denken bij de uitvoer van een assessment: vraag de controlerende partij een oordeel te vellen of deze in staat is, wanneer dat nodig zou zijn, het onderhoud, beheer en de doorontwikkeling over te nemen.

Meer weten over een assessment van maatwerksoftware? Download dan ook zeker onze whitepaper!