Development

Software-ontwikkeling
Fusie

Maatwerk of confectie?

8 februari 2013

 

Iedereen kent de verhalen van IT-projecten die mislukken: systemen die niet op tijd en binnen budget worden opgeleverd, of erger nog: systemen die niet aansluiten bij de behoefte van de business en de bedrijfsprocessen niet adequaat ondersteunen. Veel leed kan worden voorkomen door vooraf beter na te denken over het systeem dat je wilt, en hoe en waarvoor je het wilt gebruiken. Drie stellingen die dit onderstrepen.

 

1. Het soort bedrijfsproces bepaalt de keuze tussen standaardpakket en maatwerk

Maatwerk of een standaardpakket, het is een eeuwigdurende discussie. Dat er geen eenduidig antwoord is, komt wellicht door het feit dat de oplossing niet ligt in het coderen van een maatwerkapplicatie en evenmin in het parametriseren of configureren van een standaardpakket. Organisaties doen er verstandig aan om op basis van de aard van het te ondersteunen bedrijfsproces te kijken wat maatwerk en wat pakket wordt. Het onderscheid tussen generieke en unieke en bedrijfskritische en niet-bedrijfskritische processen biedt hierbij een goed raamwerk. Geoffrey Moore, bekend van onder andere ‘Crossing the Chasm’, beschrijft zo’n raamwerk in zijn boek ‘Dealing with Darwin’.

Unieke processen zijn processen waarmee een organisatie competitieve en onderscheidende producten en diensten levert aan zijn klanten (zie kader). De producten en diensten die met dit soort processen gerealiseerd worden, zijn vaak de bron van omzet en winst van de organisatie. Generieke processen zijn de processen in een organisatie die niet direct waarde toevoegen aan een product of dienst. Maar als deze processen niet goed functioneren, kan dit wel een nadelig effect op de bedrijfsvoering hebben. Bedrijfskritische processen vormen het hart van de bedrijfsvoering. Als bedrijfskritische processen niet goed functioneren, veroorzaken zij direct een aanzienlijk probleem bij het leveren van producten en diensten. Niet-bedrijfskritische processen zijn de processen binnen een organisatie waarbij de productie of dienstverlening gewoon doorgaat als deze processen stoppen. Voorbeelden van laatstgenoemde zijn processen zoals R&D en marketing. Maar ook ondersteunende processen, zoals de salarisverwerking of de facilitaire dienst.

Ter ondersteuning van de unieke, bedrijfskritische bedrijfsprocessen, is maatwerk de oplossing. Standaardpakketten zijn meer geëigend ter ondersteuning van de generieke processen. Dit is een belangrijke nuancering in vergelijking met het tweede ‘gebod’ van Wouter Keller, waarin hij oproept maatwerk zoveel mogelijk te voorkomen (zie ‘Tien geboden voor systeemontwikkeling' in AutomatiseringGids van 22 november 2012).

 

2. Slim ontwikkelen door hergebruik en genereren

Voor unieke, bedrijfskritische processen is het bij uitstek nodig om maatwerk te ontwikkelen. Maar dan wel op een slimme manier. Dit betekent ten eerste dat bestaande componenten waar mogelijk worden hergebruikt, bijvoorbeeld via webservices. Webservices zijn zelfbeschrijvend, hetgeen wil zeggen dat een systeem aan een ander systeem kan vragen hoe de webservice aangeroepen moet worden en welke gegevens worden teruggegeven. Webservices bieden hierdoor een eenduidige functionaliteit, waarbij de technische implementatie onzichtbaar is voor andere systemen.

‘Slim ontwikkelen’ betekent ten tweede niet coderen, maar genereren. Veel van de code die geschreven wordt, is ‘technische code’ die nodig is om de applicatie aan de gang te houden en om niet-businessgerelateerde, soms vaak platformspecifieke zaken te regelen. En dat is bijna altijd standaard, of via een ‘simpel trucje’ te maken. Door de systeemcomponenten niet te coderen in een programmeertaal, maar op een hoger abstractieniveau te specificeren in modellen, wordt de onderhoudbaarheid sterk verbeterd. De specificaties zelf worden in een metamodel opgeslagen en hierdoor is het mogelijk om goede impactanalyses uit te voeren en wijzigingen juist door te voeren in de specificaties. In een goede ontwikkeltool hoeft de specificatie niet te worden aangepast als de keuze van de doelomgeving verandert.

 

3. Er is bij systeemontwikkeling meer aandacht nodig voor de lange termijn

Meer langetermijndenken is op zijn plaats bij systeemontwikkeling. Als we het hebben over de Total Cost of Ownership van een applicatie, gaat het om de initiële ontwikkelkosten plus de gebruiks- en beheerkosten over de gehele levenscyclus van een systeem. Dit klinkt logisch, maar toch wordt er in de praktijk te vaak gedacht: ‘Het zal mijn tijd wel duren’, en wordt er alleen gekeken naar de korte termijn en daarmee naar de ontwikkelkosten. Aan de gebruiks- en beheerskosten wordt niet of nauwelijks aandacht besteed. En dat terwijl uit recent onderzoek van Gartner blijkt dat de kosten om een systeem te ontwikkelen tot het ‘go live’-moment, gemiddeld slechts acht procent zijn van de totale eigendomskosten. Met andere woorden, 92 procent van alle kosten zit in het draaiend houden en onderhouden van het systeem in de jaren erna.

De gebruiks- en beheerskosten kunnen aanzienlijk worden teruggebracht als tijdens de ontwikkeling niet alleen naar de functionele eisen en wensen wordt gekeken, maar ook rekening wordt gehouden met niet-functionele eisen, zoals efficiency, portabiliteit en onderhoudbaarheid. De beste aanpak om ervoor te zorgen dat niet alleen wordt voldaan aan de functionele, maar ook aan de niet-functionele eisen en wensen, is door te ontwikkelen onder architectuur en door gebruik te maken van moderne modelgedreven ontwikkeltools. Zo zijn portabiliteitskosten praktisch nul en is het mogelijk om de kosten voor onderhoud aanzienlijk terug te brengen. Hetgeen de praktijk telkens weer bewijst.

Voorbeelden van unieke processen:   Voorbeelden van generieke processen:
  • Ingaande logistiek; het ontvangen, opslaan en verspreiden van grondstoffen
  • Productie; omzetten van grondstoffen in eindproduct, leveren van een dienst
  • Uitgaande logistiek; het ontvangen, opslaan en verspreiden van het eindproduct
  • Marketing en verkoop; reclame, prijsstelling
  • Service; installatie, reparatie, training
 
  • Verwerving; de inkoopfunctie
  • Management van menselijk kapitaal (HRM); werving, selectie, training
  • Infrastructuur; algemeen management, planning, financieel beheer, boekhouding

 

Voorkom parametriseren bij standaard­pakketten

Wouter Keller toont zich in het artikel ‘Tien geboden voor systeemontwikkeling’ (AutomatiseringGids van 22 november 2012) een voorstander van het waar mogelijk configureren van standaardpakketten, om zo aan de wensen van de klant te voldoen. Maar de essentie van een standaardpakket is niet voor niets: het te gebruiken zoals het standaard is. Waarom is het anders een pakket? Configureren of parametriseren zet de deur open naar ‘misbruik’ van het pakket. Parametriseren kost niet alleen veel geld, maar tevens verdwijnt zo een belangrijk voordeel van standaardpakketten, namelijk: eenvoudig te installeren nieuwe versies van het systeem. Een veel gebruikte stelregel is om niet meer dan 10 à 15 procent van de aanschafkosten van het standaardpakket aan consultancy te besteden om het systeem aan te passen aan de processen van de organisatie.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!