Wat is een vendor lock-in?
Met de term vendor lock-in wordt een situatie aangeduid waarin de klant met handen en voeten gebonden is aan een bepaalde leverancier. Omdat dat natuurlijk voordelen voor hen oplevert, creëren leveranciers graag een systeem dat het moeilijk maakt om over te schakelen op andere software en/of integraties te maken met applicaties van derden. Ook om technische redenen kan dit moeilijk zijn.
Op welke manier een klant afhankelijk is van de leverancier en de mate waarin, hangen af van hoe het systeem en de data worden opgeslagen. In een on-premise omgeving hebben bedrijven hun systemen en gegevens op hun eigen servers staan – en hebben daarmee volledig controle over hun gegevens. Maar vaak zien we in zo’n situatie dat de leverancier lange contractperiodes hanteert. Om de samenwerking te beëindigen moet de klant of veel geduld hebben, of een hoge boete betalen…
Als er sprake is van een cloud-hosted systeem, dan kan de afhankelijkheid van de provider nog groter zijn. Omdat de data van het bedrijf buiten de eigen omgeving worden gehost, heeft het niet meer de volledige controle over die gegevens. Bovendien kan de interoperabiliteit (samenwerking tussen het bestaande systeem van de klant en dat van de leverancier) of het overbrengen van gegevens problematisch zijn. Bijvoorbeeld omdat de leverancier geen mogelijkheden voor integratie met andere systemen aanbiedt of omdat het formaat van de data niet geschikt is voor de omgeving van de leverancier.
Wist je dat? Softwareleveranciers zijn wettelijk verplicht om de persoonsgegevens die zij hosten over te dragen aan klanten die daarom vragen. Niet alle gegevens zijn echter persoonlijk. Het is daarom belangrijk dat dit soort zaken met betrekking tot de data duidelijk worden omschreven in het softwarecontract.
Hoe kan een vendor lock-in worden voorkomen?
Ook als u tevreden bent over de oplossingen van een leverancier, is het raadzaam te voorkomen dat er volledige afhankelijkheid ontstaat. Denk bijvoorbeeld aan de situatie (en de paniek) die zich eind 2020 voordeed, toen de Google-diensten waarvoor authenticatie vereist is, gedurende een uur niet meer werkten. Veel bedrijven zagen zich gedwongen hun werk te onderbreken omdat hun hele omgeving op Google stond.
Om te voorkomen dat het te afhankelijk wordt van één leverancier, kan een bedrijf de volgende stappen nemen:
- Overweeg om open source software aan te schaffen. Leveranciers die eigen (closed source) software aanbieden stellen de broncode niet beschikbaar. Hun afnemers kunnen die dus ook niet zelf ontwikkelen. De code van open source oplossingen is daarentegen wel beschikbaar voor gebruikers. Die kunnen haar niet alleen verder ontwikkelen, maar ze behouden ook meer vrijheid: als het bedrijf niet tevreden is over de leverancier, dan kan het gemakkelijk een andere zoeken. Maar er zijn ook risico’s verbonden aan het toegang hebben tot de code. Want het vraagt de nodige expertise om verantwoord aan een systeem te kunnen werken. Is die niet of onvoldoende aanwezig, dan kan dat tot storingen leiden als gevolg van een gebrek aan kennis van het systeem. Bovendien worden veel van de wijzigingen die het bedrijf in het systeem aanbrengt, aangebracht in de vorm van patches. Als deze niet goed worden beheerd, kunnen er twee problemen ontstaan: de mogelijkheid bestaat dat de patches bij een software-update niet (goed) werken, en er kunnen beveiligingsrisico's ontstaan als ze verkeerd zijn geconfigureerd.
- Voorkom een situatie waarin alle oplossingen van dezelfde leverancier zijn. Het is waar dat de integratie dan optimaal is, maar niet elke leverancier is in alles even goed. Dus vergelijk systemen van verschillende aanbieders goed met elkaar en koop (met alleen oog voor een gemakkelijke integratie) niet zomaar alles bij dezelfde leverancier. Dat heeft nog een ander voordeel: met bijvoorbeeld een ERP-systeem van leverancier A en een CRM-systeem van leverancier B kan bij het uitvallen van een van beide systemen met het andere gewoon worden doorgewerkt.
- Zorg voor een goede samenwerkingsovereenkomst. Een heel belangrijke bepaling waarmee een te grote afhankelijkheid van de leverancier wordt voorkomen, is bijvoorbeeld de ‘data reversibility’-clausule. Deze geeft de klant het recht om zijn gegevens terug te halen bij de leverancier. Het Digiboek Juridische aspecten bij implementatie en gebruik van IT-systemen bevat de belangrijkste punten die niet over het hoofd mogen worden gezien voor, tijdens en na het sluiten van een softwarecontract.
- Overweeg een private cloud of een on-premisesysteem. Als het systeem en de data in de public cloud van de provider zijn ondergebracht, dan is de afhankelijkheid groot. Daarom geven sommige bedrijven er de voorkeur aan om het systeem en/of de gegevens op hun eigen hostinglocatie te hebben (hetzij cloud, hetzij lokale server). Deze optie is echter niet altijd mogelijk. Het is daarom raadzaam om bij de keuze van een provider goed na te gaan of het mogelijk is om het systeem en/of de gegevens elders onder te brengen.
Let op! Tegenwoordig worden veel systemen in SaaS-vorm aangeboden, waarbij het systeem niet door de klant kan worden gehost. Maar meestal is het wel mogelijk de data in een private cloud of op de eigen server te plaatsen. Door dit te doen, behoudt het bedrijf de controle over zijn gegevens en kunnen deze probleemloos worden overgezet als er van software wordt veranderd. In het Digiboek Systeem- en dataopslag komen de verschillen in veiligheid, kosten en onderhoud voor on-premise en cloud-opslag (publiek, privaat en hybride) aan de orde. Ook de aandachtspunten bij het gebruikmaken van een datacenter passeren de revue.
