Artikel

Pakketselectie: Waar ging het mis?

Steeds vaker gaan bedrijven over tot het aanschaffen van standaard pakketten ten behoeve van hun primaire bedrijfsprocessen. Vaak leidt de aanschaf van een standaard pakket echter tot teleurstellingen. Pakketten blijken toch de gewenste functionaliteit niet af te dekken of blijken minder goed te passen in het applicatielandschap. Daarnaast doen zich op langere termijn teleurstellingen voor zoals een gebrek aan benodigde flexibiliteit of een nieuwe release die toch niet dat brengt wat ervan werd verwacht. In dit artikel wordt een aantal tips en handvatten gegeven die helpen deze teleurstellingen te voorkomen en die bekende valkuilen bij de selectie van standaard pakketten helpen te omzeilen.

Voor we het gaan hebben over standaard pakketten is het praktisch om wat kaders neer te zetten. In het kader van dit artikel worden onder standaard pakketten verstaan “pakketten die op allerlei wijzen te koop worden aangeboden waarmee (een deel van) een bepaald bedrijfsproces kan worden ondersteund.” Voorbeelden zijn pakketten voor het beheer van het klantenbestand (CRM), boekhoudpakketten, maar ook pakketten voor bijvoorbeeld de verzekeringsadministratie. Als voordelen van dergelijke pakketten worden meestal de lagere kosten en de snelheid van invoeren genoemd. Nadelen zijn meestal het niet precies aansluiten op de gestelde eisen (en dus het aanpassen van de standaard functionaliteit) en het feit dat het vaak lastig is dergelijke pakketten te laten interfacen met andere systemen binnen de organisatie.

Tegenover standaard pakketten staan (veelal zelf ontwikkelde) maatwerkoplossingen. Deze oplossingen worden meestal al of niet met hulp van externe partijen ontwikkeld op basis van de processen en de requirements van het desbetreffende bedrijf. Daar waar standaard pakketten vaak niet helemaal aansluiten op de processen van een bedrijf, kan als voordeel van maatwerkapplicaties worden gezien dat bij deze applicaties juist het bedrijf zelf als uitgangspunt is gekozen. De functionaliteit zal hierdoor dus juist wel goed aansluiten op het bedrijfsproces. Nadeel is veelal de lange doorlooptijd van het zelf bouwen van een applicatie en de uiteindelijk opgeleverde kwaliteit hiervan.

In dit artikel wordt ingegaan op de criteria op basis waarvan kan worden bepaald of het verstandiger is voor een bepaald bedrijf om standaard pakketten aan te schaffen voor bepaalde functionaliteit of dat het juist beter is te kiezen voor een maatwerkoplossing.

Wanneer is een standaard pakket een geschikte oplossing?

Tegenwoordig zoeken bedrijven steeds vaker hun heil in de aanschaf van standaard pakketten. De redenen hiervoor zijn over het algemeen gelegen in verwachte lagere ontwikkelkosten (in vergelijking tot de eigen IT-afdeling) en teleurstelling in de door de eigen IT-afdeling opgeleverde oplossingen.

Toch is een pakket niet altijd dé oplossing die een bedrijf zoekt. Of een standaard pakket geschikt is als oplossing is afhankelijk van de bedrijfsstrategie. Wanneer men afgaat op Michael Treacy en Fred Wiersema zijn er eigenlijk drie mogelijke bedrijfsstrategieën die kunnen leiden tot een voordeel ten opzichte van de concurrentie:

  • Operational excellence: De focus ligt op efficiency, het stroomlijnen van de processen en het produceren van hoge aantallen.
  • Product leadership: De focus ligt op ontwikkeling en innovatie, time-to-market en hoge marges in een korte periode.
  • Customer intimacy: De focus ligt bij het aanpassen van diensten en producten aan de wensen van de klant. Uiteraard staan daarbij ook het op tijd leveren van producten en diensten en betrouwbaarheid hoog in het vaandel.

Wanneer dit wordt afgezet tegen de kracht van standaard pakketten - namelijk het feit dat zij een goedkope oplossing bieden voor de ondersteuning van standaard processen en standaard producten - blijkt dat deze pakketten het meest geschikt zijn voor bedrijven die hebben gekozen voor de Operational excellence strategie.

Het gebruik van standaard pakketten bij een strategie van Product leadership is meestal geen goede keuze. Door het feit dat innovatie in producten over het algemeen leidt tot geheel nieuwe parameters van de applicatie en dus tot aanpassing van het datamodel van de applicatie, moet een dergelijke applicatie met name op dataniveau zeer flexibel zijn. Juist deze flexibiliteit is strijdig met het feit dat pakketten standaard oplossingen leveren.

Ook wanneer is gekozen voor de strategie van Customer intimacy ligt een keuze voor standaard pakketten minder voor de hand. Zeker wanneer producten en diensten regelmatig worden aangepast aan de wensen van de klant. Op een dergelijk moment kan nog maar nauwelijks worden gesproken van standaard diensten en producten. En in die standaard ligt juist de kracht van de standaard pakketten.

Er kan dus worden gesteld dat standaard pakketten het meest geschikt zijn voor gebruik in organisaties die een strategie van Operational excellence hebben gekozen. De belangrijkste vraag in het begin van het kiezen van een geschikte IT-oplossing is dus “Zijn wij een standaard bedrijf met standaard producten en diensten?”. Wanneer op deze cruciale vraag het antwoord “Ja” is, kan de keuze voor een standaard pakket worden gerechtvaardigd.

Vóór het selecteren van een pakket

Men is geneigd om op het moment dat is geconstateerd (of al is besloten) dat een standaard pakket een geëigende oplossing is, een aantal algemene requirements op te stellen en vervolgens hiermee een pakket te gaan selecteren. In de praktijk is dit veel te mager. Men moet eerst een goed en gedetailleerd beeld van de gewenste oplossing hebben voor er kan worden gestart met het selecteren van een pakket. Men zal vooraf eerst een grondige analyse moeten uitvoeren op de eigen producten, diensten en processen. Het is immers de bedoeling dat het pakket de gevoerde producten en diensten volledig ondersteunt en zo goed mogelijk in de bestaande processen kan worden ingevoegd. Daarom zullen de producten, diensten en processen zeer gedetailleerd moeten worden uitgewerkt en geanalyseerd. Juist in de details kunnen immers onoverkomelijke verschillen met bepaalde pakketten worden geconstateerd.

Daarnaast zal ook een aantal non-functionele requirements moeten worden meegenomen. Ook hier kan een gedetailleerde uitwerking ervan problemen na de selectie voorkomen. Met name de performance bij de aantallen die men wenst te gaan bewerken met het pakket is een aspect dat goed moet worden voorbereid. En bij aantallen moet zowel aan aantallen concurrent users als aan aantallen op het gebied van data worden gedacht.

De selectie zelf

Wanneer helder is welke functionaliteit en welke producten, diensten en processen het pakket moet gaan ondersteunen, kan worden begonnen met de daadwerkelijke selectie. Op allerlei wijzen (internet, bekende leveranciers, literatuur etc.) kan worden gekomen tot een shortlist van leveranciers en pakketten die in aanmerking zouden kunnen komen om uiteindelijk te worden geselecteerd.

Intern kan vervolgens worden gekeken welke medewerkers geschikt zijn om over het te selecteren pakket met de desbetreffende leveranciers te gaan praten. Hierbij moet worden gelet op zaken als objectiviteit, de juiste kennis en de juiste vaardigheden. Ook is het goed de selectie niet uit te laten voeren door slechts één persoon, maar door een kleine groep van personen die complementair zijn ten opzichte van elkaar. Een voorbeeld samenstelling van een dergelijk team zou bijvoorbeeld kunnen zijn: proceseigenaar, architect, toekomstig beheerder, requirements engineer en een eindgebruiker.

Wanneer dit allemaal is geregeld, kunnen afspraken worden gemaakt met de desbetreffende leveranciers om de lijsten van processen, producten, diensten en aanvullende requirements door te lopen. Hierbij is het zaak om zeer goed op te letten wat een pakket uit zichzelf kan (generieke functionaliteit) en wat er eventueel zou moeten worden aangepast aan het desbetreffende pakket (maatwerkfunctionaliteit). In beginsel moet ernaar worden gestreefd om maatwerkfunctionaliteit zoveel mogelijk te voorkomen.

Daarnaast scheppen de verkoopafdelingen van pakketleveranciers vaak hoge verwachtingen ten aanzien van de prestaties en flexibiliteit van hun pakketten. Hierbij zijn kreten als “dit zit in de volgende release” en “dit is eenvoudig aan te passen” commerciële dooddoeners van de eerste orde. Iedere verkoper gebruikt deze argumenten om een pakket te kunnen verkopen. Net zoals de flexibiliteit en stabiliteit van het pakket die ongetwijfeld enorm zullen worden geprezen.

Een ander belangrijk onderdeel van het selectieproces betreft ook het opvragen van referenties. Het is hierbij ook zeker aan te raden om deze referenties te gaan bezoeken en ze uit te horen over hun ervaringen met het pakket aan de ene kant en over de leverancier aan de andere kant. Op deze manier kan een goed beeld worden verkregen van de mogelijkheden van het pakket en van de leverancier.

Op enig moment zal alle relevante informatie zijn verzameld en kan worden begonnen met de verschillende pakketten uit de shortlist tegen elkaar af te zetten. Dit is ook het moment om stil te staan bij de eventueel aan te brengen maatwerkfunctionaliteit in het pakket. Het is goed mogelijk om maatwerkfunctionaliteit te splitsen in twee verschillende algemene typen, namelijk onontkoombaar (bijvoorbeeld interfaces met eigen systemen) en te voorkomen (functionaliteit die vooraf beschreven is als zijnde een intrinsieke interne functionaliteit van het standaard pakket). Maatwerkfunctionaliteit is over het algemeen een kostbare aangelegenheid. Niet in eerste instantie om te laten bouwen, maar veeleer in latere instanties om deze maatwerkfunctionaliteit in de lucht te houden. Een leverancier zit namelijk in principe niet te wachten op maatwerkfunctionaliteit. Wat er dan immers gebeurt, is dat er een aparte versie van het standaard pakket ontstaat die apart moet worden onderhouden. Kortom, bij de verkoop zal maatwerkfunctionaliteit geen bezwaar blijken, maar tijdens het gebruik en onderhoud zal het een bepaald soort ballast gaan worden. De maatwerkfunctionaliteit zal immers ook aan onderhoud onderhevig zijn. Daarnaast ontwikkelt de leverancier zijn eigen pakket ook door. Dit kan er uiteindelijk toe leiden dat er een dusdanig nieuwe versie van het pakket wordt vervaardigd dat de in een eerdere fase aangebrachte maatwerkfunctionaliteit niet meer op het generieke pakket past. Oftewel, deze maatwerkfunctionaliteit zal geheel opnieuw moeten worden ontwikkeld; uiteraard geheel op kosten van de klant. Dit kan zelfs zover gaan dat er moet worden gekozen voor het in de lucht houden van de oude versie van het pakket specifiek voor de desbetreffende klant. Dit maakt het geheel nog vele malen duurder.

Maatwerkfunctionaliteit moet dus zoveel mogelijk worden voorkomen. Dit kan bewerkstelligd worden door een zeer kritische selectie, maar ook door het eventueel aanpassen van producten en processen aan de mogelijkheden van de aangeboden standaard pakketten. Hoewel het op voorhand niet voor de hand ligt producten of processen aan applicaties aan te passen, kan een kritische blik vooraf op deze onderdelen nooit kwaad. Door vooraf bepaalde inefficiëntie of inconsistentie uit producten of processen weg te halen, kan de selectie sterk worden vereenvoudigd. Overigens niet alleen op het moment van het selecteren van het pakket, maar ook tijdens de verdere levenscyclus van het gebruik van het pakket.

Het contract

Wanneer men heeft besloten over te gaan tot de aanschaf van een bepaald pakket, moet er een contract worden opgesteld en getekend. Men is hierbij geneigd om met name te kijken naar de aanschafprijs en de prijs van de licenties etc. Wat over het algemeen wordt vergeten, is het eenduidig definiëren wat maatwerk is en hoe hiermee moet worden omgegaan. Ook het definiëren van wat klein onderhoud is en wat niet, wordt vaak achterwege gelaten. Met als gevolg dat er in de gebruiksfase onenigheid ontstaat over wat een kleine aanpassing is die direct kan worden aangebracht en niet releaseafhankelijk is, en wat er moet worden gezien als maatwerk en wat als generiek.

Aangezien de klant afhankelijk is geworden van de leverancier, kan de leverancier zich hierbij een steeds hardere onderhandelingstactiek veroorloven. De klant kan immers toch geen kant op. Zelfs de introductie van nieuwe producten en diensten gaat hierbij afhankelijk worden van de snelheid waarmee de leverancier het pakket kan en wil aanpassen.

Conclusie

De aanschaf van een standaard pakket om primaire bedrijfsprocessen te ondersteunen is geen sinecure. Vaak blijkt achteraf dat deze aanschaf uiteindelijk gedurende de levensduur van het pakket meer geld heeft gekost dan het zelf ontwikkelen van de desbetreffende functionaliteit zou hebben gedaan.
Het aanschaffen van een standaard pakket is interessant als er sprake is van een bedrijfsstrategie van Operational excellence, de selectie zeer consciëntieus en gedetailleerd wordt voorbereid en maatwerkfunctionaliteit wordt voorkomen.

Dit artikel is op persoonlijke titel geschreven.

Categorie:   
Auteur(s)
afbeelding van jurriross
Jurri Ross
Atos Origin - Business Consultant

Jurri Ross is bij Atos Origin werkzaam als Business Consultant, maar schrijft dit artikel op persoonlijke titel. Gedurende zijn langdurige carrière op het grensvlak van levensverzekeringen, pensioenen en IT, is hij zich steeds meer bewust geworden van het verschil tussen de ideale wereld van de theorie en de praktijk van alledag.
De praktijk blijkt complexer en weerbarstiger dan vaak wordt aangenomen. Deze wijsheid deelt hij met jonge professionals, in opleidingstrajecten en af en toe publiceert hij er ook over.
Door het analyseren van specifieke businessvraagstukken in relatie tot mogelijke IT-oplossingen, hoopt Jurri lezers en toehoorders even afstand te laten nemen van de waan van alledag. Daarbij durft hij het aan om politiek correct taalgebruik te vermijden en pijnpunten helder te benoemen, maar wel op een menselijke en constructieve wijze.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.