CONTENT
Terug naar community
Magazine
Proceedings
Blogs
Master thesis
Zoeken
THEMES
The CIO speaks
The architect answers
The business decides
Effect of architecture
SOA
BPM
Methods
Principles
Financial services
Public sector
Health sector
Most popular items
 
 
BLOGS
Een pakket is meer dan alleen software
Erwin Oord   
Wednesday, 04 August 2010

In een vorig artikel heb ik betoogd dat de keuze voor een maatwerkoplossing heel verstandig kan zijn in situaties waar je als organisatie jezelf wilt onderscheiden van anderen. De andere kant van het verhaal gaat over ICT-oplossingen voor ondersteunende processen. Daaronder versta ik hier processen die, hoe essentieel ook voor het bedrijf, niets toevoegen aan de identiteit van de organisatie en haar producten. Elke organisatie kent tientallen van dergelijke processen, variërend van het inkopen van kantoorartikelen tot de jaarlijkse beoordelings- en salarisronde voor het personeel.

Mijn eerste boodschap zal weinig verbazing wekken: bouw voor deze ondersteunende processen geen maatwerkoplossing, maar koop een standaardpakket. Er zijn er genoeg op de markt, denk aan leveranciers als Oracle of SAP. De redenen om voor standaardpakketten te kiezen zijn bekend: de kwaliteit van een in softwareontwikkeling gespecialiseerde leverancier; de zekerheid van software die al door anderen in de praktijk is gebruikt; de snelheid van software ‘op de plank’; de besparing van met andere klanten gedeelde ontwikkelkosten.

De keuze voor een standaardpakket brengt echter nog een voordeel met zich mee, dat helaas door de meeste klanten niet (h)erkend wordt. Het voordeel waar ik op doel is dat de leverancier tijdens de ontwikkeling van het softwarepakket veel expertise heeft opgedaan over de bedrijfsprocessen die zijn pakket ondersteunt. Niet alleen is die leverancier jaren bezig geweest met ontwerp en ontwikkeling van zijn pakket, hij heeft ook implementaties begeleid bij vele klanten. Bij elk van die implementaties heeft de leverancier een kijkje in de keuken van de klant kunnen nemen! Daardoor staat een standaardpakket bol van de praktijkervaringen en reflecteert de software het ultieme bedrijfsproces. Tenminste, als de leverancier zijn werk goed heeft gedaan.

Maar de klant is eigenwijs. Nieuw pakket oké, maar dan wel met het bestaande proces. Dat werkt immers al twintig jaar... De kans dat dat proces beter is dan de gecombineerde praktijkervaring van leverancier en talloze klanten die voorgingen, is natuurlijk minimaal, maar gek genoeg wordt naar dat argument niet geluisterd. Een proces is uiteindelijk niets meer dan een hulpmiddel om iets voor elkaar te krijgen maar mensen en organisaties hechten er enorm aan.

En dus moet het standaardpakket geconfigureerd worden om de unieke bedrijfsprocessen van de klant te ondersteunen. En daar gaat het mis. Niet alleen kost zo’n traject enorm veel tijd en geld, maar omdat wordt afgeweken van het proces dat de basis was voor het ontwerp van het pakket, komen ook allerlei rafelrandjes in de software aan het licht. Daar moet dan weer een oplossing voor gevonden worden en zo verwordt het standaardpakket tot een ontwikkelplatform voor iets dat verdacht veel lijkt op maatwerk. En uiteindelijk bijna net zo duur blijkt.

Mijn tweede boodschap is daarom: Laat je oude processen los en accepteer dat een standaardpakket met een eigen proces komt. Besteed je geld niet aan customisation maar aan een gedegen begeleiding van de mensen die met het pakket gaan werken. Voor een fractie van de kosten verzeker je jezelf zo van een geslaagde ingebruikname!

Erwin Oord ( This e-mail address is being protected from spam bots, you need JavaScript enabled to view it ) is principal consultant en partner bij ArchiXL






Comments (1)
RSS comments
Written by This e-mail address is being protected from spam bots, you need JavaScript enabled to view it on 04-08-2010 16:53
 
 
Hmm, ik vind de argumenten niet sterk. Het wordt geďmpliceerd dat processen zomaar te veranderen zijn en dat goed is om processen te veranderen omwille van ver doorgevoerde standaardisatie bedacht door leveranciers. Het klinkt communistisch: "one size fits all" producten, bedacht door partijleiding met andere belangen die in dit geval meestal nooit in deze specifieke organisatiemodder heeft gestaan. 
Je eigen processen niet voortdurend verbeteren is natuurlijk niet goed, maar deze zomaar in een big-bang vervangen (lees: waterval en technologiegedreven) is iets wat we moeten afleren. De procesverbeteringen is een complexe bezigheid, met name door zachte aspecten. 
 
Zelfs bij een succesvolle implementatie van een standaardpakket, ontstaan erg vaak problemen dat mensen natuurlijke afkeer hebben om slaaf te worden van een pakket met alle gevolgen van dien. 
Deze afkeer is terecht. Het zijn de mensen die diensten of producten leveren; processen en helemaal standaard pakketten zijn slechts middelen. 
 
En de laatste argument is de belemmering van innovatie en mogelijkheden tot verbetering. Als je laat leiden door een pakket, dan zijn de verbetermogelijkheden en onderscheidendvermogen sterk verminderd. Een vendor is afhankelijk van wensen van vele partijen, waarbij oplossingen generiek zijn. Ofwel voor niemand echt optimaal.

 

Only registered users can write comments.
Please login or register.

 

Via Nova Architectura is not responsible for the content of blogs, but authors and readers are asked to adhere the following guidelines. Authors are strongly encouraged to check facts, cite sources, present balanced views, acknowledge and correct errors. Respect copyright, fair use and financial disclosure laws. Please do not disparage organizations, or individuals. Being critical of someone's practice is acceptable, when it is done in a professional manner. Prevent usage of marketing statements. Comments should be relevant to the specific post they are attached to. Spam, flaming, personal attacks, and off-topic comments are not permitted. Readers are requested to notify This e-mail address is being protected from spam bots, you need JavaScript enabled to view it of any violations. The editor holds the right to remove any statements that, in the editors opinion, infringe the above guideline(s). The author receives a notification of this action.