Maatwerk of configuratie? Dilemma’s en beheersing

25 januari 2022

3/10 De 10 valkuilen van een ERP implementatie

In onze reeks “mogelijke valkuilen bij een ERP implementatie” schreven we eerder over de complexiteit en het belang van data en over de scope creep. Vandaag staan we stil bij de volgende valkuil; Maatwerk of configuratie? Dilemma’s en beheersing.

Bent u op zoek naar een kort antwoord? Dan is het antwoord als volgt: géén maatwerk is alleen mogelijk voor die organisaties die bereid zijn hun eigen interne standaarden en procedures aan te passen omwille van vooraf geïmplementeerde best practices. Alle anderen zullen moeten vertrouwen op configuratie en maatwerk.

De meeste softwareleveranciers scheppen op dat hun software klaar is om elke uitdaging voor elk bedrijf “out-of-the-box” aan te gaan, maar slechts weinigen houden zich aan hun woord. Het is zeer onwaarschijnlijk dat een standaard-systeem effectief kan worden gebruikt binnen “zomaar” elke organisatie.

Hoewel het waar is dat u moet streven naar het minimaliseren van maatwerk, kunnen zelfs grote aanpassingen middels maatwerk efficiënt worden beheerd als een goed proces wordt toegepast.

Vooral grotere en/of oudere bedrijven hebben hun werkwijzen ontwikkeld, die bewezen hebben effectief te zijn en niet aangepast moeten worden aan het nieuwe systeem.

Hoewel configuratie en maatwerk hetzelfde klinken, zijn ze in feite significant verschillend in betekenis. We leggen ze hieronder uit.

Wat is configuratie?

Configuratie omvat alle wijzigingen die u aan een product kunt aanbrengen vanuit het perspectief van de gebruikersinterface.  Leveranciers leveren meestal configuratietools, waarmee u het systeemgedrag in beperkte mate kunt wijzigen. Dit omvat zaken als:

• Wijzigingen in het datamodel, inclusief definitie van nieuwe objecttypes en attributen die deze beschrijven;
• Definitie van levenscycli en levenscyclus statussen;
• (deels) Definitie van workflow;
• Definitie van objectsjablonen (product, bibliotheek, enz.) – inclusief rollen binnen containers en definitie van toegangsbeheerregels;
• Beheer van systeemgedrag via voorkeuren.

Met andere woorden, configuratie is een systeemaanpassing waarvoor geen toegang, wijziging, implementatie, enz. van de broncode van het systeem vereist is. Om deze reden beschouwen veel mensen de mogelijkheid om de software te configureren (en dus de configuratie zelf) ook als een integraal onderdeel van het standaard pakket.

Configuraties worden over het algemeen ondersteund tussen systeemversies, dus als u uw systeem upgradet, hoeft u zich meestal geen zorgen te maken over het upgraden van de configuratie naar een nieuwere versie.

Wat is maatwerk?

Aan de andere kant is maatwerk alles wat verder gaat dan configuratie. Maatwerk is elke systeemwijziging welke wijziging of uitbreiding van de broncode van het systeem vereist (d.w.z. implementatie, ontwikkeling), omdat het gewenste resultaat niet kan worden bereikt door alleen configuratie.

In de meeste gevallen zijn voorbeelden van aanpassingen:

• Triggers die een bepaalde actie/systeemgedrag activeren wanneer een bepaalde gebeurtenis plaatsvindt;
• Nieuwe gebruikersacties en wizards;
• Workflows (sommige gevallen) – Met de meest pakketten kunt u code schrijven bijvoorbeeld als u wat aangepaste verwerking wilt doen terwijl u uw workflow uitvoert;
• Systeemintegraties – bijna alle systeemintegraties zijn op maat gemaakt;
• Enkele gevallen van geavanceerde bedrijfsrapportage;
• Diverse implementaties van aanvullende bedrijfsregels.

Softwaresystemen, hebben meestal hun eigen levenscyclus en worden van tijd tot tijd geüpgraded door hun leveranciers. Wanneer u uw systeem upgradet naar een nieuwere versie, mag u er nooit van uitgaan dat uw aanpassing goed zal werken. Systeemleveranciers introduceren upgrades, wijzigingen enzovoort in hun kernproducten, waardoor sommige aanpassingen misschien niet nodig zijn, maar sommige delen ervan kunnen ook stukjes code adresseren die niet langer bestaan ​​(of functioneren zoals het eerder deed) in het kernproduct – die kan allerlei soorten schade aanrichten.

Bij elke systeemupgrade met aanwezige aanpassing moet rekening worden gehouden met de inspanningen die nodig zijn om de compatibiliteit van de aanpassing met de nieuwe versie en de upgrade ervan te verifiëren.

Ter vergelijking: een upgrade van een standaard-systeem kan soms binnen enkele uren worden voltooid. Als er complexe en uitgebreide aanpassingen aanwezig zijn, kan dit maanden of zelfs jaren duren.

Wat is het verschil tussen configuratie en maatwerk?

Zoals u kunt zien, is het belangrijkste verschil tussen configuratie en maatwerk dat het eerste meestal kan worden bereikt via de gebruikersinterface van het systeem, terwijl het laatste vereist dat programmeurs nieuwe/gewijzigde functionaliteit coderen.

Maatwerk kan (en is meestal) veel complexer en moet op de juiste manier worden beheerd. Anders zal de implementatie ervan resulteren in een systeem vol bugs en fouten, of zelfs helemaal niet starten (!), waardoor het onbruikbaar wordt en dus een grote verspilling van geld en moeite.

Hoe weet ik of maatwerk nodig is?

Er zou geen systeem of oplossing kunnen worden ontworpen om alle klanten in alle industriële branches optimaal te bedienen. In veel gevallen zal maatwerk inderdaad onvermijdelijk zijn.

Daarom moet u op twee dingen vertrouwen:

• De ISV welke een systeem maakt, zou het tenslotte het beste moeten weten;
• Onafhankelijke partner, systeemintegrator, wederverkoper met toegevoegde waarde, enz. – die u kan helpen uw behoeften te evalueren en u te helpen bepalen wat nodig is;
• Of uw processen aanpassen naar het systeem.

Hoe moet ik aanpassingen beheren?

Softwareontwikkeling en systeembeheer, vaak DevOps genoemd, kan een behoorlijk complex onderwerp zijn. Hierbij de minimaal noodzakelijke randvoorwaarden:

• Gebruik een versiebeheersysteem voor uw broncode;
• Gebruik een systeem om de ontwikkelingsvoortgang, taken, problemen, gebruikersverhalen, sprints, enz. bij te houden;
• Integreer de twee hierboven goed zodat niemand iets in de bibliotheek kan veranderen als hij niet aan een specifiek object werkt;
• Gebruik geautomatiseerde tests voor elke aangepaste code (bij minimale eenheidstests);
• Gebruik geautomatiseerde creatie van een omgeving (indien mogelijk – vereenvoudigt en vermindert de inspanning en tijd aanzienlijk) en bouw implementatietools;
• Automatiseringstools nauw integreren met tests, broncode en het ALM-systeem;
• Gebruik meerdere validatieomgevingen (bijvoorbeeld: programmeurscode in een Dev-systeem, testers testen op een Testsysteem, definitieve gebruikersacceptatietests worden gedaan op een QA-systeem – en tot slot wordt er niets veranderd aan de productie, tenzij onderdeel van een officieel releaseschema , gevolgd, beheerd en gevalideerd).

Uiteraard is het bovenstaande sterk vereenvoudigd. Echter, sommige organisaties nemen een hoog risico door deze best practices niet te volgen. Dit eindigt bijna altijd, vroeg of laat, in een ramp.

Bestaat er zoiets als teveel maatwerk?

Ja. Aanpassingen variërend van enkele tientallen tot vele duizenden regels code zijn eerder regel dan uitzondering. Het was beheersbaar, maar nauwelijks. Het beheren van afhankelijkheden tussen verschillende pakketten werd langzaam een ​​nachtmerrie en het was bijna onmogelijk om een ​​probleem te traceren naar een wijziging in een vereiste en een stuk code dat door een bepaalde persoon was ontwikkeld. Het testen en debuggen van de oplossing vergde weken, zo niet maanden, voor elke release.

Tegenwoordig brengen leveranciers vaker dan ooit nieuwe systeemversies uit. Net als bij fysieke producten, worden ook voor software Product Lifecycles ingekort tot slechts een paar maanden volledig ondersteuning. Hoe vaker de upgrades, hoe meer tijd er moet worden besteed om ervoor te zorgen dat configuratie en (vooral) maatwerk blijft werken zoals verwacht.

Conclusie

Hoewel het misschien gemakkelijk is om te zeggen dat je maatwerk ten koste van alles moet vermijden, is er geen “one size fits all”. Hoewel het waar is dat u moet streven naar het minimaliseren van maatwerk, kunnen zelfs grote aanpassingen efficiënt worden beheerd als een goed proces wordt toegepast. Uiteindelijk moet de beslissing om te kiezen voor configuratie of maatwerk een weloverwogen beslissing zijn op basis van de werkelijke behoeften en vereisten van uw organisatie.

Wilt u weten hoe wij in dit proces kunnen ondersteunen? We vertellen u er graag meer over.

• Categories:
• Projecten ERP Company