De mythe van de leveranciers-onafhankelijkheid
Noot: Social media! De inspiratie voor dit stukje kwam uit een korte Twitterconversatie. Dank dus aan @litrik en @frank_be, die het op hun beurt weer oppikten van @netlash, die de boter dan weer haalde bij @JanBenedictus. (Hoezo, een journalist geeft zijn bronnen niet prijs? Dat is een old-media-gedachte hoor.) Ik mag trouwens niet vergeten om ergens in een volgend stukje mijn privéheckler Dirk Janssens uit te leggen dat gratis toch bestaat, zo bijvoorbeeld deze stukjes. Maar dit geheel terzijde.
Laten we bij de les blijven. De zonde zal mezelf niet vreemd zijn, maar een van de klassieke pro-opensource argumenten, zeker tijdens een verkoopsgesprek, is dat van de leveranciersonafhankelijkheid. U weet wel, we bouwen je website met Drupal en de klant is dan vrij om op een ander over te gaan voor onderhoud of uitbreiding, mocht hij of zij dat willen. Immers, ik moet toch ook niet heel mijn leven tanken bij het tankstation naast de garage waar ik mijn auto kocht?
Helaas, na al die jaren is mijn geloof in die zogenaamde leveranciersonafhankelijkheid fel verminderd. Immers, wanneer heeft men een derde partij nodig om een softwareproduct in een organisatie in te schakelen? Als de benodigde aanpassingen de interne technische competentie overstijgen.
Het is aan die derde partij, de integrator, dan gelegen om een bepaald product te installeren, te configureren, en dergelijke meer. En het is aan de interne competentie gelegen in hoeverre men achteraf onafhankelijk kan worden van die (of een andere) leverancier.
Eigenlijk is het simpel en de bouwanalogie is te evident om ze te negeren: probeer eens een stielman te vinden die garantie wil geven op het werk van een concullega. Geen herstellingswerken, geen verdere uitbouw van Vlaamse koterijen, nee: gewoon garantie – dat wat gebouwd is zal werken zoals het ontworpen is. En dan spreken we in de bouw nog over een ‘redelijk’ gestandaardiseerde omgeving: bij IT staat een dergelijke standaardisatie nog steeds in de peuterschoenen.
De hinderpalen
Of we het nu willen horen of niet, er zijn enkele zaken die leveranciersonafhankelijkheid fel in de weg staan.
Standaardisatie dus, niet alleen wat betreft producten en methodologie, maar ook, misschien zelfs vooral wat betreft klantenwensen. Pareto-regelgewijs is het niet in die 80% dat men afhankelijk wordt, het zijn die 20% waarin uw IT-boer zorgt dat het pakket exact zal doen wat u wenst… en waar u tot het einde der tijden voor zal blijven betalen om het te onderhouden. Let op, standaardisatie heeft ook een belangrijk nadeel: het leidt tot verminderde diversiteit, bloedarmoede en mono- of duopolies. En die kennen we hier al in de telecomsector, nietwaar?
Een tweede aspect is domeinkennis. Een IT-project bestaat uit een mix van productkennis, vakmanschap en inlevingsvermogen. Het lijkt misschien evident, maar een (goede) IT’er moet weten wat de regels achter een klassieke dubbele boekhouding is (of vloeistofdynamica, crowd control en/of ongeschreven regels door sociologie), en moet ook nog eens al die specifieke domeinen en hun patronen kunnen vertalen in een architectuur, in regeltjes code. Misschien vindt u wel die andere garagist, maar heeft die nog nooit gesleuteld aan de bedrading van pakweg uw ziekenwagen, weet u wel.
Voor het derde aspect moeten we de hand aan de eigen boezem drukken. Hoe vaak gebeurt het dat tijdens een verkoopproces de prijs gedrukt wordt, in de hoop of wetenschap dat die centen achteraf gerecupereerd gaan worden via een duur onderhoudscontract, change requests of extra bestellingen?
Nee, ik geloof niet in leveranciersonafhankelijkheid voor minder dan een triviaal IT-project. In de sector infrastructuur of logistiek zal het mogelijk zijn om uw tonercartridge op een ander te bestellen, maar met uw ERP-, CRM-, CMS- of maatwerkleverancier blijft u altijd een beetje getrouwd. Zaak dus om te zorgen voor een basis van vertrouwen van bij de start, voor de goesting om een relatie op langere termijn aan te gaan. Want eigenlijk wordt zowel klant als leverancier daar beter van.
Ziezo, volgende keer ga ik dieper in op het reële nut van open source. Al was het maar omdat ik Dirk dat verschuldigd ben.
