Deze website maakt gebruik van cookies. Klik hier voor meer informatie.

Artikelen

Een website: leveranciersonafhankelijkheid voorop!

Veel organisaties die aan een websitesysteem beginnen komen na verloop van tijd in de problemen door een onverwacht fenomeen: de zogenaamde lock-in situatie. Daarbij ontstaat met de aanschaf van een weliswaar gebruiksvriendelijk systeem, tevens vaak, bewust of onbewust, afhankelijkheid van de leverancier. Ook websites gebaseerd op zogenaamde niet-commerciĆ«le Open Source systemen kunnen voor deze lock-in zorgen. Afhankelijkheid brengt de continuĆÆteit van het websitesysteem in gevaar en kan tot desinvestering leiden.

Websites: steeds meer functionaliteiten

Bij het vullen van content (teksten en afbeeldingen) voor een website blijft het veelal niet voor de meeste organisaties. De website kan tevens een belangrijk instrument zijn of worden voor het besparen van kosten, het verzamelen van gegevens en het verwerven van nieuwe klanten. Het is dan ook belangrijk dat niet bij iedere wens tot het toevoegen van nieuwe functionaliteiten moet worden overgegaan tot de aanschaf van een geheel nieuw systeem (om nog maar niet te spreken over de onrust binnen de organisatie over wéér een nieuw systeem). Nog erger is het wanneer de organisatie vanwege de hoge kosten van een nieuw systeem niet kan inhaken op nieuwe ontwikkelingen en zich aan moet passen aan een steeds meer verouderend systeem. Toch is dit voor veel organisaties een terugkerend dilemma omdat ze afhankelijk blijven van hun leverancier of de beperkingen van hun website systeem: een zogenaamde leveranciersafhankelijkheid of lock-in.

Niet bewuste en bewuste leveranciersafhankelijkheid

Meestal ontstaat leveranciersafhankelijkheid niet bewust: de programmeercode (in dat geval ook wel “spaghetti structuur” genoemd) van een website systeem is dan zodanig opgebouwd dat geen enkele (andere) leverancier er ooit nog wijs uit kan worden.Soms ontstaat deze situatie ook bewust: voor de leverancier is dit erg prettig omdat voor langere tijd een bepaalde klant gegarandeerd klant blijft omdat hij niet meer weg kan.

Voor de klant zelf wordt een lock-in meestal pas negatief wanneer één van de volgende situaties ontstaat:

  • De leverancier stopt ermee of wordt overgenomen
  • De leverancier kan of wil niet bijblijven met de technologische ontwikkelingen
  • De leverancier kan er zelf op een gegeven moment moeilijk nog iets aan toevoegen bijvoorbeeld doordat de medewerker die het heeft bedacht ermee stopt
  • Er ontstaat onenigheid met de leverancier
  • Er moeten aanpassingen gedaan worden aan het systeem (wat zeker de eerste paar jaar na de eerste implementatie vaak voorkomt)
  • Er moeten koppelingen worden gemaakt met bestaande systemen zoals een managementinformatiesysteem

Open Source lock-in

Open source software is software waarvan de broncode vrij beschikbaar is en welke iedereen in principe vrij en gratis mag downloaden, aanpassen en gebruiken. Ook Open Source software biedt helaas vaak geen adequate oplossing voor het lock-in fenomeen. Sterker nog, het zorgt zelf ook voor een lock-in. De achtergrond daarvan ligt in de ontstaansgeschiedenis: veel open source projecten worden in eerste instantie ontwikkeld voor een bepaald doel door een programmeur. Deze programmeur stelt het vervolgens (meestal gratis) beschikbaar aan de rest van de wereld. Een andere programmeur (kan aan de andere kant van de wereld zijn) pakt dit uit hobby op, voegt er iets aan toe en stelt het eveneens beschikbaar aan de wereld. Via een zogenaamd forum (een soort van digitaal prikbord) blijven deze met elkaar in contact en stemmen ze de ontwikkeling af. Doordat iedereen een stukje programmeert op zijn eigen manier en er steeds meer zaken bijkomen in het project wil de structuur van dergelijke projecten wel eens erg onoverzichtelijk worden. Ook is er geen garantie of aansprakelijkheid mogelijk: wanneer je een probleem hebt moet je dit melden op het bewuste forum in de hoop dat iemand dat op tijd oppakt (het blijven vrijwilligers), het probleem weet op te lossen zonder een nieuw probleem te creëren en vervolgens een nieuwe (stabiele) versie beschikbaar maakt. Je moet je voorstellen dat je de motor van je auto in elkaar laat zetten met onderdelen van tien verschillende merken door tien verschillende monteurs die elkaar niet in levende lijve zien.

Hoewel er positieve uitzonderingen zijn stranden veel open source projecten na verloop van tijd door verlies van interesse of tijd van de oorspronkelijke ontwikkelaars. Ook al is er bij open source dus geen sprake van een leverancier die bewust klantafhankelijkheid creëert, de aspecten van het wegvallen van een leverancier en de opbouw van de code blijven niettemin overeind en zorgen dus voor een eigen lock-in.

Leveranciersonafhankelijkheid

Een oplossing is gelukkig mogelijk: door bij een keuze voor een professioneel systeem niet alleen te focussen op functionaliteit en prijs op dat moment maar ook op leveranciersonafhankelijkheid. Leveranciersonafhankelijkheid wordt bereikt door de volgende zaken met de leverancier te regelen:

  • Eis een modulaire (liefst zogenaamd object georiënteerde) opbouw van de code; dit heeft als extra voordeel dat later onderhoud minder tijd zal kosten
  • Eis een heldere naamgeving van bestanden
  • Eis een heldere documentatie die ook door andere leveranciers gebruikt kan worden
  • Eis dat het systeem voldoet aan de gangbare (open) standaarden voor internetontwikkeling
  • Eis dat er gebruik wordt gemaakt van bijvoorbeeld PHP/mySQL gebaseerde technieken omdat hier veel leveranciers in zijn en omdat zich hierbij de broncode en de functionaliteit zich op één en dezelfde plaats bevinden
  • Eis dat de hosting (de plaats waar het website systeem draait) niet bij de leverancier zelf hoeft te zijn (anders loop je de kans dat deze de hosting omgeving zodanig heeft ingericht dat niemand anders deze software kan draaien)
  • Laat bovenstaande eisen controleren door een andere leverancier na oplevering van het geheel; deze leverancier moet er binnen twee dagen uit kunnen komen
  • Eis de auteursrechten en het intellectueel eigendom van de software op na oplevering
  • Eis dat er geen sprake mag zijn van licenties, maar slechts van een eenmalig bedrag; eventueel wel met een onderhoudscontract
  • Zoek een leverancier van voldoende omvang en specifieke specialisatie in websitebouw
  • Vraag referenties aan van klanten van de leverancier in kwestie
  • Ga nooit maar zo akkoord met de algemene voorwaarden; Let erop dat de leverancier niet het intellectueel eigendom behoud maar dat die rechten overgaan naar de afnemer zelf.

Het bovenstaande biedt de beste garantie tegen het lock-in fenomeen en zorgt ervoor dat de organisatie de beschikking kunnen krijgen over een website systeem dat op de toekomst is voorbereid.

Artikel gepubliceerd in:

Onderwijsmanagement (oktober 2005)

COS magazine (november 2004)

http://www.managementkennisbank.nl (2008)

Op September 14, 2011


Ingediend door Webdesigning.nl BV Zwolle

Hanzelaan 276, Zwolle