De valkuilen van pakketselecties

“De grootste valkuil is dat in processen die snel veranderen vaker de behoefte zal ontstaan om het ondersteunende pakket te wijzigen, terwijl precies in deze situaties een standaardpakket niet de oplossing is.” 

Software ondersteunt organisaties, organisaties veranderen gaandeweg en dus is het op een gegeven moment tijd voor een pakketselectie. Logisch, toch? Nee. Terug naar het begin: het jaar 1859. Charles Darwin publiceert ‘The origin of species’, zijn boek over de evolutietheorie. In een notendop beschrijft hij dat populaties zich ontwikkelen door middel van natuurlijke selectie: overleven doe je door je zo goed mogelijk aan te passen aan veranderende omstandigheden, niet door de grootste of sterkste te zijn.

De realiteit van pakketselectie

Mensen en organisaties ondervinden continu aan den lijve dat omstandigheden veranderen. Informatiebehoeftes, samenwerkingsvormen, wetgeving, technologische mogelijkheden, het zijn allemaal voorbeelden van zaken die veranderen in onze omgeving. De ene verandering is acuut en abrupt, de andere geleidelijk. Feit is dat we ons als organisaties moeten aanpassen om relevant te blijven in onze omgeving. Dus dat doen we. We passen ons aan, door onze strategie en tactiek te wijzigen. Door nieuwe business modellen te ontwikkelen, processen anders in te richten en functies te veranderen of creëren. Omdat software in al deze zaken ondersteunend is, ontstaat er een gat. Er is een verschil tussen de behoefte van de organisatie en het aanbod vanuit de ondersteunende automatisering. Tijd voor een nieuw pakket?

Het aanschaffen en implementeren van een nieuw ‘pakket’ is vaak helaas niet de juiste, duurzame oplossing. Het is een technische oplossing die een bepaalde set standaardfunctionaliteit levert met daarin in het beste geval een beperkte mate van flexibiliteit. Het starten van een vergelijkend onderzoek ligt op de loer: welk pakket past het beste bij de wensen of heeft het meeste te bieden? Het probleem is dat er in veel gevallen een cyclus zal ontstaan: er wordt nieuwe software aangeschaft om een proces te ondersteunen, dat proces verandert en er ontstaat opnieuw een mismatch. Wellicht evolueert het pakket gaandeweg, maar gaat dat wel snel genoeg en in de gewenste richting?

De vraag is niet welk pakket het beste past bij het wensenlijstje. De vraag is hoe je als organisatie een fundering creëert die je in staat stelt om te evolueren en relevant te blijven in je omgeving. Hoe verandering geen hoofdpijndossier wordt, maar hoe je het omarmt en er je voordeel uit haalt. Hoe werkt dat in de praktijk?

Stap 1: breng structuur aan in verandering.

Welk proces verandert in welk tempo? Het Bimodal IT’ model van Gartner is één van de manieren om hierin bewustzijn en een tweesporenbeleid te creëren. Dit model stelt dat een organisatie en haar IT zijn opgebouwd uit twee modi:

  • Mode 1 is geoptimaliseerd voor processen die langzaam en weinig veranderen (en daarom mogelijk voorspelbaar zijn);
  • Mode 2 is geoptimaliseerd voor processen die vaak en/of snel veranderen (en daarom mogelijk onvoorspelbaar zijn).

Een organisatie zal in de meeste gevallen uit beide modi bestaan. Er zullen dus zowel processen en applicaties zijn die in Mode 1 opereren als in Mode 2. In welke modus een proces en applicatie zich bevinden wordt bepaald door hoe er met het proces, de applicatie en de levenscyclus wordt omgegaan en hoe dit door de onderliggende technologie wordt geborgd. Een Transport Management Systeem (TMS) kan bijvoorbeeld in de ene organisatie een Mode 1 applicatie zijn en in de andere een Mode 2 applicatie.

Stap 2: zorg dat IT mogelijkheden biedt in plaats van een kostenpost is.

IT is alleen een kostenpost wanneer de verkeerde keuzes gemaakt worden. Iedere zoveel jaar nieuwe software aanschaffen die vervolgens in hoog tempo veroudert, is inderdaad zonde van het geld en een bron van frustratie. In stap één is bepaald welke processen en daarmee applicaties in welk tempo veranderen en dit is waardevolle informatie:

  • Processen in Mode 1 veranderen langzaam en weinig. Software in Mode 1 is daarom ‘built to last’ en verandert langzaam en sequentieel. Over het algemeen zijn deze kenmerken te vinden bij standaardpakketten en een pakketselectie is dan een logische vervolgstap. Het is daarin verleidelijk om te focussen op de gewenste functionaliteit of een vergelijking van de functionaliteit van verschillende pakketten. Het draait echter om het ondersteunen van uw unieke bedrijfsproces. Het is daarom zaak om het te ondersteunen proces in kaart te brengen en de beschikbare pakketten te selecteren op basis van hoe goed ze dit proces ondersteunen.
  • Processen in Mode 2 veranderen vaak en/of snel en zorgen ervoor dat eventueel aangeschafte software snel veroudert. Deze processen vragen om een platform waarmee in hoog tempo flexibele software op maat kan worden gerealiseerd. Software in Mode 2 is dus ‘built to change’. Een voorbeeld van een dergelijk platform is Mendix. Doordat dit platform modelgedreven is wordt de business leidend in de realisatie van applicaties, wordt de samenwerking met IT verbeterd en kan snel flexibele software worden gerealiseerd.

Het conceptuele applicatielandschap dat op deze manier ontstaat is hiernaast weergegeven.

Pakketselectie en de valkuilen

Kortom, er is een plaats en tijd voor pakketselecties. De grootste valkuil is dat in processen die snel veranderen vaker de behoefte zal ontstaan om het ondersteunende pakket te wijzigen, terwijl precies in deze situaties een standaardpakket niet de oplossing is. Wanneer een pakketselectie wel de juiste aanpak is, is het verleidelijk om te onderzoeken welke mogelijkheden verschillende pakketten bieden om op basis daarvan een wensenlijst samen te stellen of een winnaar te selecteren. Dit terwijl de hele selectie in eerste instantie draait om het ondersteunen van uw bedrijfsproces en niet om welke functionaliteit er allemaal te koop is. Breng daarom het te ondersteunen proces in kaart en zoek daar een geschikte oplossing bij.

Terug naar het overzicht