Overslaan en naar de inhoud gaan

Effect ERP op applicatiebeheer vaak onderschat

De motieven om over te stappen op een ERP-oplossing zijn vaak zeer divers, maar de belangrijkste reden is toch wel het streven naar een betere integratie en ondersteuning van de bedrijfsprocessen met behulp van één deugdelijk en professioneel informatiesysteem. Met andere woorden: met de invoering van één ERP-platform wordt gestreefd naar vergaande integratie van de bedrijfsprocessen inclusief de onderliggende informatievoorziening.
Carriere
Shutterstock
Shutterstock

Wat nogal eens wordt vergeten is dat de invoering van een ERP-platform niet alleen voor de bedrijfsvoering, maar ook voor het beheer en de ICT-beheerorganisatie vergaande gevolgen heeft. Met name de afhankelijkheid van één platform en de complexiteit die schuilgaat achter de vergaande integratie dwingen de ICT-beheerorganisatie zich te bezinnen op de (her)inrichting en professionalisering van het beheer, het applicatiebeheer in het bijzonder. Het applicatiebeheer is namelijk het domein waar functionele deskundigheid en applicatiedeskundigheid in combinatie moeten leiden tot werkende oplossingen binnen het ERP-systeem. Steeds meer organisaties oriënteren zich bij de (her)inrichting van het applicatiebeheer op het ASL-model (Application Service Library), omdat dit qua structuur en terminologie goed aansluit bij de ITIL-methodiek, waarmee veel beheerorganisaties al bekend zijn. In navolging van het succes van ITIL als de standaardprocesinrichtingsmethodiek voor technisch beheer, lijkt de ASL-methodiek, door de groeiende behoefte aan een professioneel inrichtingsmodel, aan het begin te staan van eenzelfde succesvolle ontwikkeling binnen het applicatiebeheer. Het beheer van een ERP-platform wordt gewoonlijk ondergebracht bij een - vaak speciaal daarvoor ingericht - Competence Center. Hoewel in de praktijk blijkt dat de inrichting hiervan nogal kan verschillen, is er in alle gevallen sprake van een ERP-specifieke invulling van applicatiebeheer. De toepassing van de ASL-methodiek zou - in theorie - dan ook in de gewenste inrichtingskaders voor het Competence Center kunnen voorzien. In de praktijk blijkt de ASL-methodiek echter nog de nodige onduidelijkheden en tekortkomingen met zich mee te brengen, zeker als deze methodiek wordt toegepast voor ERP-beheer binnen een Competence Center. Het negeren van die tekortkomingen kan ertoe leiden dat organisaties, ondanks de inrichting van zo’n centrum, van de regen in de drup komen. Tekortkomingen De belangrijkste tekortkomingen van ASL, voor toepassing in een ERP-Competence Center, zijn als volgt samen te vatten: » Een van de belangrijkste gevolgen van de invoering van een integraal ERP-platform is dat niet alleen de beheerorganisatie, maar ook de bedrijfsvoeringsprocessen met deze integratieapecten worden geconfronteerd. Alleen een professionele applicatiebeheer- organisatie zal in staat zijn om deze integratie-aspecten op waarde te schatten en een juiste plaats te geven. Daarvoor is enerzijds expertise noodzakelijk met kennis van de geïntegreerde bedrijfsprocessen en anderzijds expertise van de applicatie-inrichting van de ERP-omgeving. Met andere woorden: het applicatiebeheer dient zich zowel te richten op de techniek als op de functionaliteit van de applicatie. Beide vormen van expertise kennen een zekere tegenstrijdigheid maar zijn allebei noodzakelijk binnen een ERP-Competence Center. De samenwerking is randvoorwaardelijk voor het beheer van het ERP-systeem en moet daarom eenduidig worden georganiseerd. Binnen een ERP-Competence Center vinden we daarom doorgaans een scheiding tussen functioneel en technisch applicatiebeheer. Het ASL-model kent dit onderscheid niet. Het verdient dan ook aanbeveling om een dergelijk onderscheid aan het ASL-model toe te voegen. In zeer omvangrijke en complexe ERP-omgevingen zou zelfs overwogen kunnen worden om separaat nog een cluster integratiemanagement op te nemen. » Evenals bij het technische beheer is er ook binnen het applicatiebeheer sprake van operationele werkzaamheden. Daarbij moet niet alleen gedacht worden aan monitoring & tuning, maar ook aan omgevingenbeheer, het ondersteunen van de (batch) planning en het begeleiden van incidentele productie-opdrachten. Vooralsnog ontbreken deze elementen binnen het ASL-model. » Het gebruik van een iteratieve ontwikkelmethodiek is tegenwoordig eerder regel dan uitzondering. Desondanks gaat het ASL-model vooralsnog louter uit van sequentiële systeemontwikkeling. Daarnaast hebben de verschillende ERP-omgevingen vaak een eigen ontwikkelmethodiek en tooling. De ASL-beschrijving voor het onderdeel applicatie-ontwikkeling kan daarom ook maar beter met de nodige terughoudenheid worden gehanteerd, en misschien zelfs beter wel helemaal worden vervangen door meer actuele methodieken. » Een gemis binnen de ASL-methodiek is het ontbreken van expliciete aandacht voor personeelszorg. Met name binnen ERP-Competence Centers is er een voortdurende strijd om over voldoende deskundige medewerkers te kunnen beschikken. Met name de combinatie van bedrijfsmatige en ICT-technische kennis zorgt ervoor dat de ERP-applicatiebeheerders tot een schaarse groep deskundigen behoren. Het werven en aan boord houden van deze schaarse en dus goed betaalde deskundigen vraagt een gedegen strategie. Het specifiek toevoegen van het aspect personeelsbeheer aan de sturende processen van ASL zou tot aanzienlijke versterking van de methodiek leiden. » Het ASL-model geeft expliciet invulling aan portfoliomanagement. Portfoliomanagement kent normaliter een sterke relatie met de financiële bedrijfsvoering en wordt bij de meeste organisaties in de ICT plannings- en controlcyclus opgenomen. De verantwoordelijkheid voor portfoliomanagement binnen applicatiebeheer zal daarom beperkt moeten blijven tot adviesvorming om niet te conflicteren met andere sturende processen, behalve natuurlijk voor de systemen die het applicatiebeheer zelf gebruikt, zoals ontwikkelomgevingen. Met deze nuance dienen beheerorganisaties rekening te houden. » Voor een ERP-omgeving is ook geïntegreerd gegevensbeheer essentieel. Het samenbrengen en onderling afstemmen van de werkzaamheden van verschillende bedrijfsprocessen vraagt vaak al de nodige inspanning, maar het gezamenlijk gebruiken van gelijksoortige gegevens en daarmee standaardiseren van die gegevens, vraagt van menig implementatieproject vaak een buitenproportionele inspanning. Het is dan ook geen zeldzaamheid dat gegevensstandaardisatie ook na implementatie in de beheerfase nog geruime tijd doorloopt. Het applicatiebeheer heeft hierin een belangrijk aandeel bij het onderhoud van gegevensbanken en structuren. Vooralsnog wordt aan de gegevensstandaardisatie en integratie in het ASL-model nog onvoldoende aandacht besteed. Prestatie Met andere woorden, de implementatie van een ERP-platform stelt hoge eisen aan de organisatie en het beheer. Alleen een professionele applicatiebeheerorganisatie zal in staat zijn het hoofd te bieden aan de specifieke en complexe problemen van het ERP-beheer. De ASL-methodiek kan tot op zekere hoogte van nut zijn bij de inrichting van een voor het ERP-beheer opgezet Competence Center. Maar zowel wat betreft de organisatorische inrichting, als de procesinrichting zal men niet altijd houvast kunnen vinden bij de ASL-methodiek. Hetzelfde geldt voor de inrichting van de applicatie-ontwikkeling, die in ASL slechts zeer summier wordt behandeld. Ook ten aanzien van de complexe integratieaspecten die het beheer van een ERP-platform met zich meebrengt zal ASL - vooralsnog - geen volledig referentiemodel bieden. Kortom, de ASL-methodiek is een zeer serieus te nemen referentiemodel om te komen tot een professionele inrichting van het applicatiebeheer. Dit in zichzelf is al een prestatie die nauwelijks kan worden onderschat. Misschien wel juist door het succes van de ITIL-methodiek is het applicatiebeheer (en zeker als die ook het beheer van ERP-systemen omvat), veel te lang onderbelicht gebleven. Met de komst van ASL wordt het eindelijk mogelijk om ook rond het applicatiebeheer een volwassen discussie te voeren. De bovengenoemde tekortkomingen moeten dan ook in dit licht worden gezien. Blijft echter wel de constatering dat het huidige ASL-model nog enige verbetering behoeft voordat het zich als ‘best practice’ binnen ERP-beheer eenzelfde status zal kunnen aanmeten als bijvoorbeeld ITIL. Zeker voor gebruik van ASL binnen een ERP-Competence Center zal deze methodiek vooralsnog met beleid en de nodige terughoudendheid moeten worden toegepast. Winfried Nanninga (Winfried.Nanninga@Capgemini.com) en Jacques Wetzels (Jacques.Wetzels@Capgemini.com) zijn managingconsultants bij Capgemini. Zij adviseren over beheerinrichting, ERP-Competence Centers en ICT business alignment.ASL-model Gezien de grootschalige vervanging van maatwerkapplicaties door ERP-systemen is de vraag gerechtvaardigd in hoeverre ASL ook kan worden gebruikt bij het applicatiebeheer van deze systemen. Vaak wordt dit in zogenaamde ERP-Competence Centers geconcentreerd. De hoofdelementen van ASL zijn: 1) beheer; 2) onderhoud & vernieuwing; 3) verbindende processen; 4) sturende processen; 5) strategische processen. Deze hoofdelementen vormen samen het zogenaamde ASL-framework (zie figuur). De beheerprocessen binnen ASL zijn vooral gericht op het technische applicatiebeheer en het is dan ook niet verwonderlijk dat hier een grote overeenkomst bestaat met de ITIL-beheerprocessen vanuit het technisch beheer. De processen onderhoud en vernieuwing bevatten de ontwikkelingscyclus die bestaat uit vijf opeenvolgende fases: impactanalyse, ontwerp, realisatie, test en implementatie. In deze sterk sequentiële aanpak lijkt geen enkele ruimte voor iteratie. Het ASL-model kent nog een aantal richtinggevende, sturende en verbindende processen. Wat hierin positief opvalt is dat het wijzigingsbeheer als verbindend proces een centrale plek binnen de ASL-methodiek krijgt toegewezen. De sturende processen omvatten: planning & control, cost management, quality management en service level management. Elk proces vervult op zich een nuttig doel binnen de beheerorganisatie. De strategische processen vallen uiteen in Applications Cycle management (ACM) en Organization Cycle Management (OCM). Het ACM richt zich op de langere termijn en kijkt niet alleen naar de vernieuwing en innovatie van de bestaande applicatie maar middels portfoliobeheer ook naar de applicatielaag als geheel. Krachtig is dat op een gestructureerde en verantwoorde wijze wordt nagedacht over de voortzetting en - waar mogelijk - de verhoging van de toegevoegde waarde van de applicaties voor de bedrijfsvoering. Dit zou in feite ook een van de kerntaken van het Competence Center moeten zijn, namelijk: het op een proactieve wijze ondersteunen van de bedrijfsvoering met verbeterde en innovatieve ERP-functionaliteit. Uiteraard is het daarvoor van groot belang dat het Competence Center dient als een intermediair en katalysator tussen de eigen organisatie en de ERP-leverancier. Bij het OCM ligt de focus niet op de applicatie maar juist op de applicatiebeheerorganisatie. Hierbij worden interessante vraagstukken behandeld als, welke diensten moeten we leveren, wat is onze marktpositie, wie zijn onze klanten, welke middelen en methodieken moeten we hanteren et cetera. Beheerarchitectuur In zijn meest elementaire verschijningsvorm is de beheerorgansiatie te verdelen in de primaire functies: functioneel, applicatief en technisch beheer. Het applicatiebeheer vormt daarbij een brug tussen enerzijds het ‘bovenliggende’ functionele beheer en het ‘onderliggende’ technische beheer. Binnen applicatiebeheer zelf komt dit tot uiting door de aanwezigheid van twee tegenstrijdige expertisegebieden die nauw moeten samenwerken. We kunnen de scheiding in expertisegebieden in het applicatiebeheer verduidelijken door onderscheid te maken tussen ‘functioneel applicatiebeheer’ en ‘technisch applicatiebeheer’. Binnen functioneel applicatiebeheer wordt vooral gekeken op welke wijze de applicatie beter kan worden aangesloten op de gebruikerswensen en het gebruik binnen de organisatie als geheel. Bij het technisch applicatiebeheer ligt de nadruk vooral op het functioneren van de applicatieprogrammatuur en de onderliggende databases. Als we daarnaast nog een onderscheid maken in de expertise die gericht is op het systematisch ontwikkelen van applicatieprogrammatuur, dan valt het applicatiebeheer in feite uiteen in drie verschillende domeinen. Waar er echter tussen het functioneel, applicatieve en technische beheer een primaire functiescheiding bestaat, daar is binnen de drie functiedomeinen van het applicatiebeheer slechts sprake van een secundaire functiescheiding. Het Competence Center omvat in principe alle drie de functiedomeinen van het applicatiebeheer, dus zowel het functionele applicatiebeheer, het technische applicatiebeheer als ook de applicatie- of systeemontwikkeling. Deze drie kennisdomeinen zijn essentieel om te kunnen voldoen aan de eisen die interactie met de directe omgeving stelt.

Lees dit PRO artikel gratis

Maak een gratis account aan en geniet van alle voordelen:

  • Toegang tot 3 PRO artikelen per maand
  • Inclusief CTO interviews, podcasts, digitale specials en whitepapers
  • Blijf up-to-date over de laatste ontwikkelingen in en rond tech

Bevestig jouw e-mailadres

We hebben de bevestigingsmail naar %email% gestuurd.

Geen bevestigingsmail ontvangen? Controleer je spam folder. Niet in de spam, klik dan hier om een account aan te maken.

Er is iets mis gegaan

Helaas konden we op dit moment geen account voor je aanmaken. Probeer het later nog eens.

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in