«

»

Waarom flexibiliteit voor standaardisatie gaat

 

images-2Standaardiseren?

Vanuit een rationeel oogpunt lijkt het logisch om te standaardiseren op één softwareleverancier. Een geïntegreerde oplossing klinkt aantrekkelijk. Producten sluiten dan mooi op elkaar aan. In theorie althans. In de praktijk valt dit nog wel eens tegen omdat grote softwarebedrijven andere bedrijven met innovatieve concepten opkopen in een poging om zich snel aan te passen. De oplossingen moeten dan geïntegreerd worden in de bestaande portfolio’s. Iets wat de nodige tijd en inspanning vereist. En simpelweg, kun je wel overal goed in zijn als leverancier?

Belangrijker is de vraag of het complete portfolio (nog) wel goed bij uw vraag aansluit. Hoe breder het portfolio des te lager deze waarschijnlijkheid wordt. Ofwel ‘de wet van de remmende voorsprong’. Hoe groter het marktaandeel en hoe breder het portfolio, hoe lastiger het wordt om ontwikkelingen snel te volgen. Is het niet beter om voor elke benodigde functionaliteit de beste oplossing te kiezen?

Ontwikkelingen gaan steeds sneller

Wat betekent dit voor u? Volgt u voor 100% één bepaald concept of kiest u voor de beste oplossingen uit de markt en accepteert u dat u te maken krijgt met meerdere leveranciers en mogelijke integratievraagstukken? Standaardiseren op één concept heeft als nadeel dat u zich verbindt aan het lot van deze leverancier. Aan de andere kant rijst de vraag of u wel voldoende kennis op kunt bouwen van meerdere concepten. Kan uw IT-afdeling dat aan? De praktijk leert dat IT’ers liever niet switchen van technologie. Dit betekent voor hen dat ze meestal opnieuw moeten beginnen. Iets wat niet iedereen gegeven is. Omschakelen van Microsoft naar Google of andersom? Of van Microsoft naar Apple? En wat vinden de eindgebruikers daarvan?

Verregaande standaardisatie, een utopie?

Op één paard wedden wordt steeds risicovoller. Vandaag is Microsoft groot en morgen klopt Google of Apple aan de de deur met beter passende oplossingen. Misschien besluit Amazon wel om zich op uw branche te storten. Of er is een niche-speler die een fantastische oplossing heeft. In de praktijk zien we dat deze ontwikkelingen niet te remmen zijn. Innovatie komt binnen via de eindgebruikers en niet via de IT-afdeling. Bij de eindgebruiker komen de nieuwe concepten binnen die functioneel goed passen zonder op de technische architectuur te letten.

De IT-afdeling is hierover niet meer in control en moet zich aanpassen aan de eindgebruikers. Standaardiseren op één platform en investeren in diepgaande technische productkennis is daarom steeds minder zinvol. Dit leidt slechts tot minder flexibiliteit. Morgen heeft u misschien compleet andere kennis nodig. Wat betekent dit voor de personele bezetting en de competenties van uw IT-afdeling? Specialistische kennis zal om deze reden steeds vaker uitbesteedt worden. De focus wordt verlegd naar het optimaal toepassen van de oplossing, een taak van functioneel beheer. Het adequaat voeren van regie over externe specialisten en het goed inrichten van functioneel beheer wordt steeds belangrijker. Alleen dan bent u flexibel genoeg om de ontwikkelingen te volgen. Charles Darwin voorspelde het al:

Flexibiliteit voor standaardisatie

“Het is niet de sterkste soort die overleeft, noch de meest intelligente. Het is degene die zich het beste kan aanpassen.”

Gerelateerde berichten:

1 reactie

  1. Gijs van der Laan

    Mooi artikel!

    Overigens kun je in een gedifferentieerd applicatielandschap nog steeds gestandaardiseerde processen uitvoeren. Dus vanuit de eindgebruiker kun je nog steeds spreken van standaardisatie. De strekking van het artikel, dat je goed moet nadenken over het inrichten van het ICT-landschap en de daarvoor benodigde kennis in huis en buitenshuis zonder op zoek te gaan naar steeds weer een nieuwe heilige ICT-graal, onderschrijf ik volledig.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *

Je mag deze HTML-tags en attributen gebruiken: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>