Pakketsoftware testen, hoe standaard is standaard?

Veel organisaties maken gebruik van standaard software oplossingen. Zulke pakketsoftware biedt aanzienlijke voordelen, zowel financieel als in snelheid van implementatie. Doordat de software is toegespitst op een bepaald domein hoeft het wiel niet opnieuw uitgevonden te worden door de afnemer.

Ook wordt de complexiteit van het ontwikkelen van eigen software ‘weggestopt’ achter een contract met de leverancier: die draagt zorg voor het ontwerp, het (door)ontwikkelen van functionaliteit, en steeds vaker ook voor de infrastructuur en hosting (cloud-oplossingen). De afnemer hoeft zich alleen bezig te houden met de door hem gewenste functionaliteit. Zo richt ieder zich op zijn eigen expertise.

Tot zo ver het goede nieuws. Het  blijkt dat de implementatie en het gebruik van pakketten alsnog tot flinke hoofdpijndossiers kan leiden. Veel voorkomende problemen uit de praktijk zijn:

–          De snelheid en benodigde inspanning waarmee het pakket geïmplementeerd kan worden vallen tegen. De oplossing blijkt toch niet voldoende geënt op de eigen business specifieke situatie, waardoor alsnog substantieel in maatwerk moet worden geïnvesteerd. Met als gevolg aanzienlijke uitloop van het traject met consequenties van dien voor de beheersbaarheid van het project in termen van doorlooptijd en budget.

–          Het gebruik van maatwerk wordt versterkt door de trend dat enerzijds pakketten breder en daardoor meer generiek worden. Anderzijds, de toenemende (denk aan tweede en derde generatie erp-gebruikers) ervaring  bij afnemers leidt tot meer specifieke wensen – en daarmee vaak maatwerk – ten aanzien van de functionele ondersteuning.

–          De vele configuratie-instellingen, zeker in combinatie met maatwerk, vraagt onverwacht veel tijd van de afnemer voor met name het (acceptatie)testen.

–          Door de complexe inrichting en maatwerk is de onderhoudslast hoger dan verwacht en beperkt dit eveneens de mogelijkheden voor snelle upgrades naar een nieuwe versie.

Ter illustratie, een handels- en productiebedrijf in de metaalsector koos recent voor één van de grotere ‘standaard’ erp-oplossingen. Door een aantal  sectorspecifieke eisen (ten aanzien van onder andere de artikelstructuur, een kerncomponent van veel erp-systemen) leidde dit tot ongeveer zeshonderd dagen aan maatwerk (softwareontwikkeling) op een implementatie van in totaal bijna twaalfhonderd mandagen, ofwel 50 procent van het totale budget. Een bedrijf in de staalsector implementeerde een Mid market erp-oplossing. Waar in de regel voor een dergelijke oplossing een budget van 250 tot driehonderd dagen voldoet, was meer dan het dubbele nodig door de integratie van een branchespecifieke add-on.

Wat voor pakketten zijn er?

Hoewel functionaliteit vaak leidend is, is het voor de afnemer ook zaak om te begrijpen wat voor software aan het pakket ten grondslag ligt. Hoe standaard is nu eigenlijk een standaardpakket? Grofweg kan onderscheid worden gemaakt in de volgende categorieën pakketten:

–          Turnkey (‘kant-en-klaar’-)pakketten: een ‘klassiek’ stuk pakketsoftware dat bij elke afnemer in dezelfde hoedanigheid draait. Iedereen krijgt dezelfde software en die werkt, met  configuratie van wat instellingen, out-of-the-box. Voorbeelden hiervan zijn in den extreme Microsoft Office, maar in de erp-markt kan je ook Exact en Afas hieronder scharen. Bij deze variant zien we in toenemende mate dat er ‘addons’ geleverd kunnen worden die de ‘standaard’ aanvullende, veelal meer gespecialiseerde, functionaliteit bieden of waar tegen middels webservices door derden aanvullende functionaliteit ‘aangebouwd’ kunnen worden

–          ‘Bouw’- of configureerbare pakketten: pakketten die zeer brede markten bedienen  en dus veelvuldig moeten worden aangepast aan de specifieke situatie van de afnemer. Deze pakketten hebben veel mogelijkheden voor parametrisatie, inrichting van business rules en enige vorm van ‘scripting’ dan wel maatwerkmogelijkheden. Voorbeelden zijn de typische meer op ‘enterprise’ gerichte erp-systemen als SAP,  MS Dynamics AX, Infor LN en Oracle JD Edwards.

–          Software platformen: software waarmee  binnen een moderne ontwikkelomgeving een oplossing gerealiseerd kan worden. Deze zijn vaak sneller te maken dan maatwerksoftware omdat het platform al een bepaalde basis biedt, zoals schermen, interfaces en het instellen van business logica. In het erp-domein bieden leveranciers als Thinkwise en Codeless hiervoor oplossingen. Maar deze platformen kunnen ook toegespitst zijn op bepaalde domeinen, zoals Mendix voor apps, Tibco voor soa of bpm, et cetera. Aanzienlijke inspanning is nodig om op deze platformen een werkende oplossing te maken, en ook worden soms complexe delen van de functionaliteit in andere pakketten of technologieën ondergebracht.

–          Buitencategorie: er zijn ook oplossingen waarbij de afnemer feitelijk een soort referentiearchitectuur aankoopt (een ‘blueprint’). Alle software moet zelf ontwikkeld worden met een technisch platform of technologie. Het ‘pakket’ schrijft alleen voor hoe dit gedaan moet worden, op basis van een, vermeende, brede kennis van een domein. In de praktijk blijkt het ‘generieke’ ontwerp vaak niet praktisch genoeg voor de werkelijke gevallen van de afnemer en kunnen er zeer beperkt eigen ontwerpkeuzes gemaakt worden om zowel functionele als niet-functionele (bijvoorbeeld performance) eisen goed te krijgen.

Inzicht geeft grip

Bij de selectie en implementatie van pakketten richt de afnemer zich normaal gesproken volledig op het functioneel testen van het systeem. Deze black-box benadering past goed bij de aanname dat het binnenste van de pakketten de zorg van de leverancier is, maar geeft weinig inzicht in een aantal problemen die hun oorzaak vinden in de techniek met als gevolg een niet goed functionerende oplossing en/of een hoge beheerlast. Dit gebrek aan inzicht zorgt ervoor dat niet op een gepaste manier de discussie aangegaan kan worden over hoe de problemen op te lossen, of beter, deze vooraf te voorkomen.

De aard van het pakket bepaalt in sterke mate welke problemen zich kunnen voordoen. Er zijn verschillende, complementaire, instrumenten waarmee inzicht in de aard van het pakket verkregen kan worden:

–          Architectuur reviews: Met architectuur wordt bedoeld hoe het pakket is opgebouwd en vanuit welke aannames en overtuigingen ontwerpbeslissingen genomen zijn. Deze keuzes hebben gevolgen voor hoe de software uitgeleverd kan worden en hoe configuratie of maatwerk mogelijk is. Neem bijvoorbeeld het delivery model (hosted, managed, SaaS-achtigen, multi-tenancy): op welke wijze zit dit in de architectuur van het pakket? Staat de kern los van klant-specifieke modules? In welke mate heeft een afnemer last van wijzigingen die voor een andere afnemer nodig zijn en hoe snel kunnen updates uitgerold worden naar alle afnemers. Hebben modules en maatwerk een eigen ontwikkel- en deliverycyclus? Zijn stabiele koppelpunten voor configuratie of maatwerk gedefinieerd? Door middel van het onderzoeken van de architectuur van het pakket kan duidelijk worden welke risico’s of gevolgen bij de afnemer op het bord kunnen komen. Ter illustratie: een pakket voor hypotheken bestaat in alle marketingbrochures duidelijk uit een ‘core’ en een ‘shell’, waarbij de shell alle klant-specifieke variatie bevat. Bij een review blijkt dat het onderscheid tussen de core en de shell nog niet volledig uitgekristalliseerd is, waardoor wijzigingen voor afnemer A zeer waarschijnlijk effect hebben op de shell van afnemer B.

–          Code inspecties: Van de generieke code van een pakket is het zinvol om vast te stellen van welke kwaliteit deze is (mogelijke kwaliteitsaspecten zijn onderhoudbaarheid, reliability, security, etc.). Hogere onderhoudslast is primair een probleem voor de leverancier, maar een groeiend onderhoudsteam moet uiteindelijk wel betaald worden en langere oplevertijden zijn direct zichtbaar voor de afnemer. De verwachtingen kunnen zo wel afgestemd worden.  De kwaliteit van het maatwerk en de wijze waarop dit is geïntegreerd is eveneens van belang. Idealiter is het maatwerk tegen het pakket aangezet (‘aanbouw’) en is niet gekozen voor het aanpassen van generieke delen (‘verbouw’). De hoeveel maatwerk an sich is ook een belangrijke indicator. Naar mate meer maatwerk nodig is dient de afnemer zich 2 vragen te stellen: 1) is dit pakket nog geschikt voor wat ik wil, en 2) is wat ik wil wel realistisch en echt noodzakelijk?

–          Evaluaties van het ontwikkelproces: Als afnemer wil je zekerheid dat de leverancier op een volwassen manier omgaat met de softwareontwikkeling. Denk hierbij aan het gebruik van best-practices, zijn deze opgesteld en afgestemd op het soort pakket (het delivery model, de wijze van configureren en eventueel maatwerk). Ook het aantal afnemers is van invloed. De ontwikkeling van een ‘kant-en-klaar’-pakket met vele afnemers (zoals Microsoft  Word) wordt veel sterker gedreven door de leverancier dan een configureerbaar pakket in een niche markt met drie afnemers. In het laatste geval hebben de afnemers mogelijk verschillende belangen die de leverancier en het pakket in een spagaat dwingen. Een ervaren of standvastige leverancier gaat hier met goede focus mee om, en laat de oren niet te sterk hangen naar de afnemers. Een goede blik op de wijze waarop de leverancier omgaat met innovatie en wijzigingsverzoeken werkt verhelderend.

Als voorbeeld van het inzetten van deze instrumenten kijken we naar een beroepsorganisatie die op basis van het open source pakket Sugarcrm een nieuw ledenadministratiesysteem liet ontwikkelen door een implementatiepartner. Sugarcrm biedt out-of-the-box een prima set aan functionaliteit, maar specifieke zaken als registraties voor evenementen of verkoop van jaarboeken moesten zelf ontwikkeld worden. Sugarcrm heeft een ‘studio’ waarmee nieuwe tabellen en schermen gedefinieerd kunnen worden, waarna de studio de benodigde php-code genereerd. Verdere logica kan in deze code toegevoegd worden. Bij afronding van het project is gekeken hoe het eindresultaat eruit zag. De implementatiepartner was gespecialiseerd in Sugarcrm en had zich keurig aan de principes van het pakket gehouden. In de praktijk bleek de studio een te beperkte tool, en werd de php-code zelf geschreven, maar wel op zo’n manier dat deze voldeed aan de architectuurstandaard en dus ook bij updates van het pakket niet omviel. De hoeveelheid maatwerk was aanzienlijk en gaf aan dat Sugarcrm eigenlijk geen standaardfunctionaliteit had voor de specifieke activiteiten van de beroepsorganisatie. De vraag is natuurlijk of een ander pakket een betere match had gehad met deze functies, en met andere aspecten die ook meewegen zoals gebruiksvriendelijkheid en kosten.

Top 5 aanbevelingen uit de praktijk

1. Wees al tijdens de selectie van standaardpakketten alert op de verschillende typen van standaardpakketten die er bestaan. Bespreek dit expliciet met de beoogd leverancier en vraag bij referenties die al enkele jaren met het standaardpakket werken na hoe zij hier tegenaan kijken.
2. Eis bij contractering het ‘Right-to-Audit’ op de code, zodat een externe derde onder de motorkap kan kijken en voor een oordeel kan geven over de architectuur, kwaliteit van (maatwerk)code, modulariteit, api’s en de werkwijze van de leverancier.
3. Blijkt tijdens de selectie dat op een aantal onderdelen substantieel maatwerk of stevige ‘configuratie’ nodig is – met name op bedrijfskritische onderdelen – zorg dan dat je tijdens de ‘proof-of-concept’ fase, alvorens een definitieve beslissing te nemen, de genoemde instrumenten inzet om de eigenschappen van het pakket te begrijpen. Denk aan het ‘doorprikken’ op aanwezige business logica achter datavelden en eventuele wijzigingen in de ‘core’ van het pakket. Elke software toepassing in een branche stelt in de regel specifieke eisen aan basisdragers in de oplossing, zoals het datamodel. Wijzigingen in het datamodel hebben direct consequenties voor bijvoorbeeld aanwezige rapportages en, bij erp an sich al een ‘standaard’ pijler in de oplossing, de artikelstructuur. Blijf realistisch over hoe goed een pakket bij de eisen en wensen past en zoek een balans: volledig verbouwen is ten zeerste af te raden, volledig ‘het pakket blijven volgen’ en de eigen processen en organisatie aanpassen is in de regel ook niet 100 procent haalbaar.
4. Beoordeel de development guide van de leverancier, zeker als je kiest voor een ‘bouwpakket’. Deze guide dient in ieder geval te beschrijven wat configureren inhoudt, waar maatwerk begint en welke kwaliteitsstandaarden daarop van toepassing zijn, de beschikbare tooling (denk aan libraries en ondersteuning voor ontwikkelaars) en de structuur / architectuur (is dit bijv. gericht op het ‘afdwingen’ van juist gebruik). De development guide moet duidelijk aangeven binnen welke lijntjes gekleurd kan worden, en op welke wijze hier het beste aan voldaan kan worden. Hierin moeten niet alleen criteria voor de code en architectuur afgedekt worden, maar ook de bijkomende ontwikkelprocessen (zoals versiebeheer, deployment en testen).
5. Belangrijkste tip is tot slot om te voorkomen dat je terecht komt in een situatie van veel maatwerk of zeer stevige configuratie. Dit kan door tijdens het inkoop-/selectietraject veel aandacht te besteden aan de kwaliteit van de leverancier. Het aantal en het niveau van business consultants die specifieke bedrijfsprocessen kunnen vertalen naar standaard it-oplossingen zijn bijvoorbeeld  cruciaal. Daarnaast tonen – recente – referenties uit soortgelijke sectoren aan of de leverancier ervaring heeft met sectorspecifieke processen en hiervoor mogelijk al eerder gebouwd maatwerk tot onderdeel van zijn standaardpakket heeft gemaakt.

Zeeger Lubsen, adviseur bij de Software Improvement Group, Onno Wasser en Arne Smedema, beiden adviseur bij it-adviesbureau Mitopics