Voor een relatief snelle en goedkope automatiseringsoplossing van bedrijfsprocessen kan worden gekozen voor een standaardpakket. Na een zorgvuldige analyse van de bedrijfsprocessen kan een pakketkeuze worden gedaan. Het pakket moet uiteraard zo goed mogelijk aansluiten bij de gewenste functionaliteit. Daar waar de gewenste functionaliteit niet kan worden bereikt met het gekozen pakket, zal maatwerk ontwikkeld moeten worden.

Door: Joop Jentink

Voor of tijdens het implementeren van een pakket kan duidelijk worden dat het pakket niet voldoet op punten als:
• Interfacemogelijkheden met andere systemen.
Indien het bestaande pakket al interface-mogelijkheden bevat, moet hier dikwijls aan gesleuteld worden om de gewenste interactie met de andere systemen te waarborgen.
• Output-wensen van gebruikers.
Dikwijls hebben gebruikers van een pakket extra wensen m.b.t. de output van het pakket. Zo wil men graag lijsten welke door een vroegere applicatie konden worden geproduceerd ook in de nieuwe applicatie kunnen oproepen. Lijsten welke wel door het pakket kunnen worden geproduceerd moeten nogal eens worden aangepast met extra gegevens, specifieke bedrijfsgegevens of logo's.
• Volledigheid van het datamodel.
De voorgedefinieerde entiteiten zijn soms niet afdoende om de gewenste gegevens te kunnen beschrijven. Het pakket kan de mogelijkheid bieden om een aantal velden flexibel te benoemen. In dat geval kan worden volstaan met een extra inrichtingstaak van het pakket. Indien zo'n mogelijkheid niet bestaat, zullen aanpassingen verricht moeten worden op het datamodel en de onderhouds-schermen.

Bij het ontwikkelen van maatwerk aan een pakket is het noodzakelijk zo goed mogelijk aan te sluiten bij de structuur van het pakket zelf. Op het maatwerk moet voortdurend onderhoud worden verricht omdat voor het pakket dikwijls patches en nieuwe releases moeten worden doorgevoerd. Om te voorkomen dat iedere wijziging van het bestaande pakket grote implicaties heeft voor het maatwerk moet zoveel mogelijk worden aangesloten op binnen het pakket bestaande functies en procedures.

De meegeleverde informatie is vaak onvolledig
Tijdens de bouw van maatwerk op een bestaande applicatie blijkt het vaak lastig te achterhalen welke business-rules in de applicatie zijn geïmplementeerd. Vaak is de meegeleverde documentatie onvolledig of ontoereikend. De ontwikkelaars van het maatwerk moeten dan zelf in de sources van de applicatie achterhalen hoe bepaalde gegevens benaderd kunnen worden. Keuzes die hierbij gemaakt worden moeten goed gedocumenteerd worden om later onderhoud soepel te laten verlopen. De organisatie waarvoor maatwerk wordt gemaakt heeft vaak wel mensen beschikbaar om patches door te voeren op de bestaande applicatie of om applicatieset-up instellingen te wijzigen, maar heeft niet altijd mensen beschikbaar om de impact op het maatwerk te doorgronden. Goede documentatie is dan van groot belang. De leverancier van het pakket is immers niet op de hoogte van het maatwerk, zodat wijzigingen op het pakket vanuit de leverancier niet getest kunnen worden op de impact van deze wijzigingen op het maatwerk. Vaak beperkt de klant zich tot het op hoofdzaken hertesten van het maatwerk na een wijziging op het pakket.

Als duidelijk wordt dat van het pakket in een later stadium een web-enabled versie zal worden ontwikkeld is het natuurlijk verstandig om hierbij ook alvast rekening te houden bij het ontwikkelen van maatwerk. Vooral bij de ontwikkeling van output kan men alvast vooruit lopen op het feit dat hetzelfde maatwerk ook zonder al te veel aanpassingen web-enabled gemaakt kan worden.

Het standaardpakket van Oracle voor finance en manufacturing, Oracle Applications, scoort goed ten aanzien van problemen die kunnen ontstaan bij ontwikkeling van maatwerk. Binnen het pakket zijn voorzieningen getroffen waardoor zelf ontwikkelde schermen en rapporten eenvoudig geïntegreerd kunnen worden met bestaande schermen en rapporten. Verder is de documentatie goed en bevat het pakket een grote hoeveelheid voorgedefinieerde rapporten welke, na eventueel een aantal aanpassingen, door de gebruiker in het menu kunnen worden gehangen. Veel entiteiten hebben zogenaamde flex-fields zodat de gebruiker zonder tussenkomst van een ontwikkelaar extra velden binnen entiteiten kan definiëren en deze in schermen kan opnemen.

Het is van groot belang dat al in een vroeg stadium wordt bepaald wat er aan maatwerk zal moeten worden ontwikkeld bij keuze van bepaalde pakketten. Ook moet worden onderzocht of het pakket voldoende ondersteuningsmogelijkheden voor maatwerk biedt en hoeveel onderhoud zal moeten worden gepleegd bij installatie van een batch of bij introductie van een nieuwe release.