Functioneel beheer bij pakketten (deel 2)

Besturen van IT-dienstverleners door de klant Functioneel beheer bij pakketten (deel 2)

3.3

Functioneel beheer bij pakketten (deel 2)

141

a een eerder artikel over functioneel beheer bij pakketten wordt in dit artikel ingegaan op een specifieke vorm van pakketgebruik, namelijk gemeenschappelijk gebruik van applicaties. Dit komt met name voor bij grote, complexe organisaties. De handvatten uit het eerdere artikel over het beheer van pakketten zijn hier ook noodzakelijk, maar zijn niet voldoende. Aanvullende maatregelen zijn vereist. Grote organisaties waar gemeenschappelijk applicatiegebruik plaatsvindt, worstelen vaak met het beheer van gemeenschappelijk gebruikte applicaties. In dit artikel wordt een aantal aanvullende handvatten voor het beheer van dergelijke applicaties aangereikt.

N

Auteurs: Frank van Outvorst en Ralph Donatz zijn beiden werkzaam als consultant bij PinkRoccade Atribit.

3 DEFINITIE In het IT Beheer Jaarboek 2003 is een artikel opgenomen over de noodzaak en het nut van functioneel beheer in organisaties waar gebruik wordt gemaakt van standaardpakketten. In het betreffende artikel wordt de volgende definitie gehanteerd voor een standaardpakket: Van een standaardsoftwarepakket is sprake wanneer een applicatie is ontwikkeld voor of wordt gebruikt door meerdere (interne of externe) klanten. De kopers/gebruikers van het pakket hebben grote overeenkomsten in hun processen die door (de functionaliteit van) het standaardpakket kunnen worden ondersteund. De twee belangrijkste kenmerken van een standaardpakket zijn: • De afnemer van het pakket heeft niet direct invloed op de functionaliteit. De functionaliteit is in de basis voor alle afnemers hetzelfde.

• De broncode van het pakket is eigendom van de (interne of externe) leverancier, waardoor niet zelfstandig aanpassingen kunnen worden gedaan aan het pakket, anders dan het instellen van parameters.

3 SITUATIES De praktijk leert dat er feitelijk onderscheid kan worden gemaakt tussen drie situaties waarin sprake is van een standaardsoftwarepakket: 1. standaard productsoftware in de markt; 2. standaard productsoftware in de productieketen; 3. standaard productsoftware binnen de eigen organisatie. De eerste twee situaties bij standaardpakketten De eerste twee situaties zijn reeds uitgewerkt in het artikel van vorig jaar. Hierbij is met name geconstateerd, dat in deze situaties in de praktijk onvoldoende aandacht wordt besteed aan het functioneel beheer. Dit leidt

IT Service Management, best practices Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

142

Situatie 1: Standaard productsoftware in de markt

Situatie 2: Standaard productsoftware in de productieketen

Leverancier Standaard pakket

Afnemer Standaard pakket




Leverancier Standaard pakket



Organisatie 1


Organisatie 2

Organisatie 3

Productieketen Organisatie / bedrijf

Situatie 1: Standaard productsoftware binnen de eigen organisatie

Staf Organisatieonderdeel 1 Businessunit A

Organisatieonderdeel 2 Businessunit A

= leverancier standaard software

Organisatieonderdeel 3

Businessunit b

Businessunit C

Onderdeel A

= afnemer standaard software



Figuur 1 Situaties waarin sprake is van een standaardsoftwarepakket

tot diverse knelpunten, op de volgende terreinen: • Onvoldoende gebruik - niet of onvoldoende gebruik van het standaardpakket doordat de functionaliteiten van het pakket tekort blijken te schieten in de praktijk. • Slechte relatie met de leverancier - onvoldoende afspraken met de pakketleverancier waardoor de ondersteuning van de leverancier niet aansluit bij de behoeften binnen de gebruikersorganisatie, of het versiebeleid van de leverancier is zodanig strak dat afnemers gedwongen zijn mee te gaan naar een hogere versie van het pakket zonder dat hieraan behoefte of noodzaak bestaat bij de afnemer. • Ontevreden eindgebruikers - de ondersteuning van het werken met het pakket schiet binnen de eigen organisatie tekort, of de geboden functionaliteit wordt als onvoldoende beleefd. • Hoge kosten - door onvoldoende aansluiting tussen het bedrijfsproces en het pakket, of door niet goed doordachte aankoop van een pakket, kunnen de kosten hoger

uitvallen dan op voorhand was aangenomen. De maatregelen die in het artikel worden aangereikt richten zich met name op de afnemerszijde van standaardpakketten waarbij de relatie en communicatie met de pakketleverancier natuurlijk belangrijke aandachtspunten zijn. In het artikel worden de volgende maatregelen met name genoemd: • inrichten van service level management; • inrichten van planning & control en kostenmanagement; • beleggen van systeemeigenaarschap; • toekennen van de rol van kerngebruiker aan medewerkers binnen de bedrijfsprocessen; • afbakenen van werkzaamheden op het gebied van technisch beheer, applicatiebeheer en functioneel beheer; • toekennen van rollen op het gebied van portfoliomanagement en life cycle management aan leden van het management;

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


• inrichten van de processen specificaties opstellen en wijzigingenbeheer. De derde situatie De derde situatie kent een geheel eigen problematiek. Deze problematiek heeft met name te maken met het inrichten van alle relaties tussen de betrokken ‘leveranciers’ en ‘gebruikers’-partijen en met het inrichten van beheer aan de aanbiederzijde. Om deze reden wordt in een apart artikel specifiek op deze derde situatie ingegaan. In het eerste artikel over het functioneel beheer bij pakketten kwam met name de afnemerskant van het functioneel beheer aan de orde. In dit tweede artikel wordt aandacht besteed aan de aanbiederkant van het functioneel beheer. De focus in dit artikel blijft gericht op organisaties waarin gebruik wordt gemaakt van applicaties. Er wordt niet ingegaan op organisaties die het ontwikkelen en op de markt aanbieden van standaardsoftwarepakket als primaire bedrijfsproces hebben. Immers, voor deze organisaties is deze vorm van functioneel beheer een randvoorwaarde om te overleven en daarmee een vanzelfsprekend aandachtspunt. Voor organisaties die een heel ander primair bedrijfsproces hebben (bijvoorbeeld aanbieden van verzekeringsproducten of het aanbieden van openbare orde en veiligheid) is deze vorm van functioneel beheer geen vanzelfsprekendheid. In de praktijk zien wij dan ook veel - met name grotere organisaties worstelen om met deze problematiek om te gaan. Dit artikel is bedoeld om daarbij ondersteuning te geven, door enerzijds bewustwording van de problematiek op gang te brengen en anderzijds door het aanreiken van handvatten om met deze problematiek om te gaan.

STANDAARD PRODUCTSOFTWARE BINNEN DE EIGEN ORGANISATIE Beschrijving van de situatie Binnen grote organisaties bestaan veel situaties waarin gesproken kan worden van het gebruik van standaardpakketten, hoewel er

daarbij strikt genomen geen sprake hoeft te zijn van de aanschaf van een standaardpakket bij een (externe) leverancier. In dergelijke gevallen is er sprake van dat binnen één organisatie meerdere, verschillende gebruikersorganisaties (organisatieonderdelen) opereren die allemaal gebruik maken van dezelfde applicatie. Elke gebruikersorganisatie kent daarbij haar eigen primaire bedrijfsproces en heeft haar eigen verantwoordelijkheid, taakstelling en bedrijfsresultaat. Als voorbeeld van meerdere, verschillende gebruikersorganisaties binnen één organisatie kan gedacht worden aan verschillende business units binnen hetzelfde concern, verschillende diensten of directies binnen een gemeente of provincie of meerdere productiebedrijven (waar eventueel verschillende producten worden vervaardigd) van een internationaal opererend industrieel concern. Gemeenschappelijk gebruik De verschillende gebruikersorganisaties maken voor de ondersteuning van hun bedrijfsprocessen gebruik van dezelfde applicatie. Je kunt dit aanduiden als medegebruik of gemeenschappelijk gebruik.

143

3

SITUATIES MET STANDAARD PRODUCTSOFTWARE BINNEN DE EIGEN ORGANISATIE (GEMEENSCHAPPELIJK GEBRUIK) De situatie waarin sprake is van gemeenschappelijk gebruik van standaard productsoftware binnen de eigen organisatie kent een aantal specifieke kenmerken. Deze kenmerken komen eigenlijk op de een of andere manier altijd wel terug bij alle organisaties die in deze situatie verkeren. Autonome organisatieonderdelen De verschillende organisatieonderdelen die gebruik maken van dezelfde applicatie (‘gebruikersorganisaties’ genoemd) zijn alle vrij in de wijze waarop zij hun procesuitvoering en -inrichting vorm geven. Dit betekent dat een gebruikersorganisatie voor de inrichting van haar processen in principe geen


144

rekening (hoeft) houden met de procesinrichting bij andere gebruikersorganisaties. Wel functioneert er boven de verschillende gebruikersorganisaties nog een gemeenschappelijk eindverantwoordelijk niveau, bijvoorbeeld een concerndirectie. Vanuit dit corporate niveau kunnen natuurlijk wel randvoorwaarden en kaders worden gesteld aan de verschillende gebruikersorganisaties. Grote organisaties en complexe besluitvorming Het gaat om middelgrote tot grote organisaties. Dit is logisch, want bij kleinere organisaties is er vaak helemaal geen sprake van een opdeling naar organisatieonderdelen die in deze mate eigen verantwoordelijkheden hebben voor hun eigen processen en resultaten. Kenmerk van grote organisaties is natuurlijk wel, dat hierin veel hiërarchische lagen voorkomen of dat er anders veel functionarissen zijn die op een of andere manier een grote invloed hebben op beslissingen die genomen moeten worden. Kortom, bij grote beslissingen zijn veel partijen binnen de organisatie betrokken of veel partijen menen dat zij betrokken moeten zijn. Dit leidt tot complexe besluitvormingstrajecten. Geleidelijk ontstaan Gemeenschappelijk gebruik van een reeds bestaande applicatie binnen een grote organisatie ontstaat meestal geleidelijk. Vaak wordt er niet bewust gekozen voor dit gemeenschappelijk applicatiegebruik. Gemeenschappelijk gebruik ontstaat vaak als gevolg van bedrijfsreorganisaties waarbij een organisatieonderdeel wordt opgedeeld in meerdere onderdelen. Voor de ondersteuning van de procesuitvoering is dan nog steeds de ene applicatie beschikbaar die altijd al werd gebruikt. Wat ook nog wel eens voor wil komen, is dat na een fusie of andere samenwerkingsvorm tussen twee organisaties besloten wordt, om geen dubbelingen in aanwezige applicaties toe te staan. Het kan dan gebeuren dat een of meer applicaties worden uitgefaseerd en de verschillende bedrijfsonderdelen voortaan gebruik gaan maken van een overgebleven applicatie die dan al elders

binnen de organisatie in gebruik is. Een andere grond voor gemeenschappelijk gebruik kan liggen in het veronderstelde gemak en de voordelen van een uniforme informatievoorziening. Dit kan er toe leiden, dat verschillende bedrijfsonderdelen besluiten om gebruik te gaan maken van een elders binnen het concern al in gebruik zijnde applicatie. Let wel, dit laat onverlet dat er ook situaties voorkomen waarin wordt besloten tot nieuwbouw of aanschaf van een nieuwe applicatie die binnen het gehele concern gebruikt moet gaan worden. Dit is feitelijk weer een verbijzondering van gemeenschappelijk gebruik binnen grote organisaties. De specifieke kenmerken van een dergelijke situatie komen in het eerste artikel over pakketgebruik aan de orde. In dit artikel ligt de focus meer op eigen maatwerkapplicaties die door meerdere gebruikersorganisaties gebruikt gaan worden. Afhankelijkheden binnen het grote geheel en corporate informatiemanagement De grote organisaties waar gemeenschappelijk applicatiegebruik voorkomt, kennen over het algemeen een hoge mate van complexiteit. Vaak ook bestaat er een heel scala aan applicaties. Deze applicaties hebben vrijwel allemaal interfaces of andere relaties met elkaar. Vrijwel geen enkele applicatie functioneert volledig zelfstandig. Deze relaties gelden over het algemeen nog sterker voor de technische infrastructuur. Er bestaan vrijwel geen organisaties die voor elke applicatie een aparte technische infrastructuur hebben ingericht. Dit betekent dat applicaties draaien op dezelfde technische infrastructuur. Om de gemeenschappelijke infrastructuur goed te benutten en om de relaties tussen al de verschillende applicaties te managen wordt op corporate niveau een of andere vorm van centraal informatiemanagement ingericht. Van hieruit worden kaders en richtlijnen aangegeven. Dit is ook vrijwel altijd een omstreden, moeilijke rol door de aanwezige autonomie bij de diverse gebruikersorganisaties.



Centraal applicatiebeheer De applicatie die gemeenschappelijk gebruikt wordt, is over het algemeen gewoon een eigen maatwerkapplicatie. Het applicatiebeheer voor deze applicatie is vrijwel altijd centraal ondergebracht bij een (interne of externe) applicatiebeheerorganisatie. Dit is dan vaak het team dat ook de applicatie heeft ontwikkeld en daarna het beheer op zich heeft genomen. Soms is deze applicatiebeheerorganisatie organisatorisch ondergebracht binnen een business unit (een van de gebruikersorganisaties voor de applicatie), soms opereert deze onder de vlag van de centrale ICT-afdeling. Het komt ook voor, dat het beheer ge-outsourced is naar een externe applicatiebeheerder. We hebben nog nooit geconstateerd dat het applicatiebeheer over verschillende applicatiebeheerorganisaties is verspreid. Geen speciale aandacht voor beheer Doordat in veel gevallen het gemeenschappelijk gebruik min of meer toevallig ontstaat, wordt niet van meet af aan onderkend dat er een speciaal geval van applicatiegebruik aan het ontstaan is. Hierdoor is er minder aandacht voor het (functioneel) beheer van deze applicatie dan wenselijk is. Immers, de gemeenschappelijk gebruikte applicaties vertegenwoordigen vrijwel zonder uitzondering aanzienlijke belangen: er is/wordt over het algemeen veel in geïnvesteerd, ze ondersteunen meerdere processen of processen op meerdere plaatsen binnen de organisatie en deze applicaties zijn over het algemeen groot en complex. Kortom: het gaat hierbij om applicaties die in hoge mate bedrijfskritisch zijn en op een zeer specifieke manier worden gebruikt, maar het beheer is hier onvoldoende op toegesneden. In het volgende hoofdstuk van dit artikel wordt nader ingegaan op de problemen die hieruit kunnen voortvloeien.

BESCHRIJVING VAN SPECIFIEKE PROBLEMEN WAAR MEN TEGENAAN LOOPT Voorbeeld A Veel betrokken partijen belemmeren besluitvorming Binnen een grote financiële dienstverlener wordt een grote, al wat oudere applicatie gebruikt voor de financiële afhandeling van transacties. In de loop der tijden zijn veel verschillende business units gebruik gaan maken van deze applicatie. Een van de business units is verantwoordelijk voor het beheer en onderhoud van deze applicatie. De verschillende gebruikmakende business units hebben uiteenlopende belangen bij en eisen aan het systeem. Telkens ontstaat weer een heel gevecht over de vraag welke eisen en wensen wel en welke niet gehonoreerd worden. Voordat een eis of wens gehonoreerd wordt gaat daaraan een heel traject van onderhandelingen vooraf. Eigenlijk blijkt met iedere wijzigingsronde iedere betrokken business unit in toenemende mate ongelukkig met de ontstane situatie. Deze situatie wordt versterkt door twee factoren: 1. Een duidelijke visie op de rol en positie van de applicatie en de daarvoor benodigde functionaliteit van de applicatie ontbreekt. 2. De business unit waar het beheer en onderhoud van het systeem is ondergebracht, is ook maar een van de partijen in het grote onderhandelingsspel dat uiteindelijk moet leiden tot besluiten over functionaliteitaanpassingen. De business unit kan geen eigen weg hierin kiezen, omdat er nog op allerlei andere vlakken allerlei relaties met de overige business units bestaan en men vóór alles werkbare relaties wil behouden.

145

3

In situaties zoals die hiervoor zijn beschreven spelen vaak diverse problemen. Wij behandelen deze problemen nu in willekeurige volgorde.


146

Versiekeuze / specifieke functionaliteit voor specifieke gebruikersorganisatie Doordat binnen de verschillende gebruikersorganisaties de processen zich toch vaak in een eigen richting ontwikkelen, gaan ook de behoeftes aan door de applicatie te leveren functionaliteiten uiteenlopen. Op enig moment gaan daarbij knelpunten ontstaan voor wat betreft de mogelijkheden om alle gewenste functionaliteiten binnen die ene applicatie te realiseren. De vraag dient zich dan aan of het wellicht zinvol zou zijn om van de ene gedeelde applicatie meerdere versies te maken die dan elk een eigen gebruikersorganisatie bedienen. Echter, bij nadere analyse blijkt dan weer dat dergelijke versies onderling ook weer veel overeenkomsten hebben, doordat het hart van het systeem

voor beide versies gelijk zou zijn. Dit zou dan weer dubbel onderhoud met zich meebrengen, hetgeen een ongewenste situatie zou opleveren. Een andere overweging zou kunnen zijn om voor elke aparte gebruikersorganisatie eigen, specifieke functionaliteit toe te voegen. Indien dit gebeurt, blijkt vaak dat toch verschillende andere gebruikersorganisaties ook geïnteresseerd zijn om deze functionaliteit (voor een deel) te gebruiken. Dit leidt dan weer tot discussies over verrekening van de initiële investering voor deze specifieke functionaliteit. Discussie hierover ontstaat met name ook, doordat bij de ontwikkeling van de specifieke functionaliteit geen rekening is of wordt gehouden met medegebruik of gedeeltelijk medegebruik. Niet in modulariteit

Voorbeeld B Ontbreken van centrale aansturing leidt tot incoherent applicatiegebruik Een grote organisatie binnen de decentrale overheid besluit over te gaan tot een nieuwe, centrale applicatie voor de gehele organisatie. Deze applicatie dient ter ondersteuning van secundaire bedrijfsprocessen. Binnen deze organisatie zijn ongeveer 50 bedrijfsonderdelen aanwezig en elk bedrijfsonderdeel kent dit secundaire bedrijfsproces. Wel is het zo, dat elk van de bedrijfsonderdelen een eigen specifieke taak heeft en een daarmee samenhangende eigen werkwijze en cultuur. Uit deze verschillen komen ook allerlei onderling verschillende wensen en eisen ten aanzien van de nieuwe applicatie voort. Daarnaast is op corporate niveau een centraal beleid voor het secundaire proces geformuleerd waaraan in principe ieder bedrijfsonderdeel zou moeten voldoen. Vanuit dit centrale beleid vloeien ook allerlei wensen en eisen ten aanzien van de nieuwe applicatie voort. Op centraal niveau is een servicebureau actief, dat belast is met het begeleiden van de ontwikkeling en implementatie van de nieuwe applicatie. Van oudsher bezit dit servicebureau al veel kennis van dit secundaire bedrijfsproces. Tijdens de ontwikkeling en (voorbereiding op) implementatie van de nieuwe applicatie wordt het servicebureau geconfronteerd met een enorme hoeveelheid wensen en eisen ten aanzien van de nieuwe applicatie. Het servicebureau probeert hierin gemeenschappelijke wensen en eisen te ontdekken en begeleidt centraal de realisatie van de bijbehorende functionaliteiten. Voor de overige wensen en eisen worden de bedrijfsonderdelen direct doorverwezen naar de leverancier die de applicatie ontwikkelt. Deze ontwikkelt in overleg met het betrokken bedrijfsonderdeel de gewenste functionaliteit. Dit gaat buiten het servicebureau om. Na verloop van tijd blijken de kosten voor de applicatie de pan uit te rijzen en wordt een onderzoek ingesteld naar de gang van zaken. Een van de uitkomsten van dit onderzoek is dat een onbeheersbare situatie is ontstaan: - Er is nergens een totaaloverzicht van de beschikbare functionaliteit. - Er is geen volledig overzicht van het gebruik van de applicatie. - Er is op vrijwel geen enkele manier sprake van uniform gebruik van de applicatie binnen de totale organisatie. - Van een geïntegreerde administratie over de hele organisatie heen kan dus ook geen sprake zijn en dit heeft weer allerlei vervelende gevolgen voor managementinformatie.



in de opzet en realisatie van de functionaliteit, niet in beheer en niet in besluitvorming en overlegvormen over deze functionaliteit. Onvoldoende borging voor alle meewegende belangen Een veelvuldig terugkerende uitdaging voor organisaties waarbij sprake is van gemeenschappelijk gebruik, is het vinden van een mechanisme voor het omgaan met alle belangen die spelen. Hierbij kunnen twee factoren een rol spelen: 1. Duidelijkheid omtrent systeemeigendom - Het komt regelmatig voor, dat in geval van gemeenschappelijk applicatiegebruik geen duidelijke afspraken zijn gemaakt over het systeemeigendom van de gemeenschappelijk gebruikte applicatie. Dit betekent dat er geen duidelijke plaats binnen de organisatie is waar het mandaat ligt voor de besluitvorming over

de toekomst en of (functionele) wijzigingen aan het systeem. Het kan daarbij zijn, dat er geen eenduidige plaats binnen de organisatie is waar besluiten genomen worden, dat er geen concreet en duidelijk budget beschikbaar is om de genomen besluiten ten uitvoer te brengen of dat er geen eenduidige plaats is binnen de organisatie van waaruit opdrachten verstrekt worden aan de (interne of externe) ICT-leverancier die het applicatiebeheer voor de betreffende applicatie uitvoert. 2. Rol en positie van de systeemeigenaar Wat ook regelmatig voorkomt, is dat er wel een duidelijke systeemeigenaar voor de gemeenschappelijk gebruikte applicatie opereert, maar dat deze een rol en positie binnen het grotere concern heeft, die niet afwijkt van de overige gebruikersorganisaties. Dat betekent, dat deze systeemeigenaar ook allerlei applicatiewensen heeft

147

3 Voorbeeld C Conflicterende belangen en dubbele petten Bij een (andere) internationaal opererende verzekeraar-dienstverlener wordt gebruik gemaakt van een grote, complexe applicatie. Deze applicatie ondersteunt de verwerking van verzekeringen voor twee verschillende markten. Voorheen waren de bedrijfsactiviteiten voor deze twee markten ondergebracht bij een business unit. Bij een reorganisatie gericht op meer klantenbinding is deze business unit opgeknipt in twee zelfstandig opererende business units. Het beheer van de applicatie is ondergebracht bij een van de twee business units onder directe verantwoordelijkheid van de financieel directeur. Na verloop van tijd gingen de processen en marktbenadering van de twee verschillende business units steeds verder uit elkaar lopen. Dit betekent dat niet automatisch alle wijzigingen in de applicatie voor de ene business unit ook bruikbaar zijn voor de andere business unit. Er ontstaat wrijving tussen de twee business units over het uiteenlopen van de functionele behoeften en de wijze waarop dit in het systeem verwerkt moet worden. De business unit die het systeem in beheer heeft, heeft immers al meer dan voldoende functionele wijzigingen in de pijplijn om het totale beschikbare budget dat voor systeemonderhoud beschikbaar is op te souperen. De andere business unit zou eventueel wel extra financiële middelen beschikbaar willen stellen voor extra onderhoud, maar er is te weinig (deskundig) personeel om alle gewenste wijzigingen voor beide business units op te pakken. De financieel directeur van de voor beheer en onderhoud verantwoordelijke business unit is ongelukkig omdat hij het gevoel heeft dubbele belangen te dienen: aan de ene kant een goede procesgang (en de daarvoor noodzakelijke ondersteuning) binnen zijn eigen business unit en aan de andere kant de constante druk vanuit de andere business unit om ook aan hen concessies te doen, waardoor voor de eigen business unit een suboptimale situatie zou resulteren. Binnen de andere business unit is men ook niet tevreden: men heeft het gevoel dat men onvoldoende bediend wordt met benodigde aanpassingen in het systeem.


148

om de eigen procesuitvoering adequaat te kunnen ondersteunen. Voor de besluitvorming over de applicatie voelt men dan van twee kanten druk: aan de ene kant de behoeften vanuit het eigen bedrijfsproces en aan de andere kant de eisen vanuit de andere gebruikersorganisaties. In beide gevallen is het lastig om de belangen van alle betrokken partijen op een juiste wijze mee te laten wegen. In het eerste geval is er geen duidelijk mechanisme aanwezig dat met de verschillende belangen om kan gaan. In het tweede geval is de besluitvormende partij zelf een van de belanghebbende partijen in het gebruik van het systeem. Dit leidt tot applicatie-inhoudelijke discussies waarbij de uitkomst van de beslissing centraal staat (namelijk de resulterende applicatiewijziging) zonder dat er voldoende oog is voor de belangen die ten grondslag liggen aan de gewenste applicatieaanpassingen. Het systeemeigendom met alle bijbehorende taken, verantwoordelijkheden en bevoegdheden is in dergelijke gevallen vaak een heet hangijzer waaraan niemand zich wil branden. Echter, een goed en duidelijk systeemeigendom is voorwaarde voor effectief beheer van de applicatie. Complexe en stagnerende besluitvorming over beleid en wijzigingen Wellicht voortkomend uit het hiervoor geschetste probleem (onvoldoende borging voor het meewegen van de verschillende belangen) wordt hier de problematiek vanuit het proces van besluitvorming nog eens apart aan de orde gesteld. Vaak is bij gemeenschappelijk applicatiegebruik sprake van gedwongen winkelnering. Voor de in gebruik zijnde applicatie is eigenlijk geen echt alternatief beschikbaar. Overgaan naar een heel andere applicatie is vanuit kostenoogpunt, onderlinge afhankelijkheden of gestelde corporate kaders vaak niet mogelijk. Men heeft dus slechts een geringe mate van keuzevrijheid. Als de geboden functionaliteit niet voorziet in de behoefte kan men hier wel wat aan proberen te doen, maar de ultieme onderhandelingsfactor - de

applicatie voortaan niet meer gebruiken en overgaan naar iets anders - is geen optie. Dit vertroebelt discussies en besluitvorming. Deze situatie wordt nog verergerd indien binnen de organisatie ICT-uitgaven nog gezien worden als overheadkosten die leiden tot opbouw van een algemeen budget, van waaruit applicatie-ontwikkelwerkzaamheden bekostigd worden. In een dergelijke situatie bestaat er onvoldoende koppeling tussen het verwachte nut of de opbrengsten van een wijziging en de investering die een (of meer) gebruikersorganisatie(s) daarom bereid is (zijn) te plegen.

Voorbeeld D Business unit belang versus corporate belang Binnen een holding opereren diverse werkmaatschappijen. Sommige zijn groot, andere zijn klein(er). Een van de kleinste werkmaatschappijen heeft slechts behoefte aan beperkte functionaliteit ter ondersteuning van de secundaire bedrijfsprocessen. Omwille van de uniformiteit wordt op corporate niveau besloten dat alle werkmaatschappijen (dus ook de kleintjes) gebruik zullen maken van een grote, complexe applicatie die zeer veel meer functionaliteit biedt dan met name die kleintjes nodig hebben. Hiermee wordt tegemoet gekomen aan de functionaliteitbehoeften van de grote werkmaatschappijen. Een dergelijke grote applicatie brengt ook een veel grotere beheerlast met zich mee: moeilijker om mee te werken, meer zaken die ingesteld moeten worden, complexere structuur, etc. Daarnaast zijn de kosten voor de aanschaf van deze applicatie veel hoger. Dit leidt ertoe dat de kleine werkmaatschappij zich gesteld ziet voor een relatief enorme kostenpost. Helaas is deze werkmaatschappij niet de enige die zich hiervoor gesteld ziet. Het is de vraag of op corporate niveau een goede afweging is gemaakt waarbij duidelijk is dat alle meerkosten opwegen tegen de voordelen van de uniformiteit en een geïntegreerde administratie.



Naast de ontbrekende marktwerking door de gedwongen winkelnering, het ontbreken van business cases waarin relaties tussen opbrengsten en kosten worden gelegd, is ook de omvang van de organisatie een factor in de complexiteit van de besluitvorming. Zoals reeds in het voorgaande beschreven zijn de organisaties waarin gemeenschappelijk applicatiegebruik speelt allemaal groot. Daarmee neemt de complexiteit van de besluitvorming nog verder toe. Tot slot kan besluitvorming nog verder gecompliceerd worden doordat niet altijd even duidelijk is hoeveel en welke partijen allemaal een rol (moeten/willen) spelen bij de besluitvorming: diverse gebruikersorganisaties, vaak allemaal met een eigen ICT-afdeling, daarnaast nog een centrale informatiemanagementafdeling, een centrale ICT-afdeling, vaak ook een of meer externe partijen voor applicatiebeheer of technisch beheer, een centrale procesafdeling en externe weten regelgeving die een rol speelt voor de besluitvorming. Conflict tussen unit belang en corporate belang De laatste apart te adresseren problematiek betreft conflicterende belangen op decentraal en centraal niveau. Hierbij speelt voor een decentrale gebruikersorganisatie de afweging hoe men om moet gaan met corporate richtlijnen zonder de eigen belangen uit het oog te verliezen. Hierbij spelen dus niet de belangen van de andere gebruikersorganisaties die de applicatie gebruiken een rol, maar juist de belangen vanuit het corporate niveau. De belangen op corporate niveau zijn vaak gericht op gebruik van gemeenschappelijke infrastructuur, relaties tussen de verschillende systemen en geïntegreerde informatievoorziening en managementinformatie. Van hieruit komen dan de kaders en randvoorwaarden waaraan de verschillende organisatieonderdelen moeten voldoen. Hierbij geeft het corporate niveau juist geen richtlijnen op applicatieniveau, hoewel voor de gemeenschappelijk gebruikte applicaties natuurlijk wel een unit-overstijgend belang bestaat.

Voorbeeld E Groot en klein in dezelfde applicatie Meerdere overheidsorganisaties maken gebruik van dezelfde applicatie voor de ondersteuning van één van hun secundaire bedrijfsprocessen. Tussen deze organisaties zitten departementen, universiteiten, agentschappen en zelfstandige bestuursorganen (zbo’s). Deze organisaties verschillen in omvang, werkwijze en complexiteit. Natuurlijk brengt dit ook weer met zich mee, dat de verschillende organisaties verschillende behoeften aan functionaliteit hebben en verschillende eisen aan de applicatie stellen. Toch maken al deze organisaties gebruik van dezelfde applicatie en moeten zij door dezelfde deur kunnen. Om dit te kunnen realiseren zijn een aparte functioneel-beheerorganisatie en een uitgebreide overlegstructuur in het leven geroepen. Vanuit de functioneel-beheerorganisatie wordt veel energie en tijd gestoken in overleg met de gebruikersorganisaties en in voorbereiding van de besluitvorming over uit te voeren functionaliteitwijzigingen en een systeembeleid.

149

3

MAATREGELEN Uit de voorgaande analyse van gemeenschappelijk applicatiegebruik kunnen diverse maatregelen worden afgeleid die problemen kunnen voorkomen of oplossen. Met de voorgaande beschrijvingen worden handvatten aangereikt om de problematiek die kan spelen te herkennen en bespreekbaar te maken. In dit hoofdstuk worden de mogelijke maatregelen besproken. Schematisch kunnen deze maatregelen in 5 stappen worden ondergebracht (figuur 2). Stap 1: onderkennen van situatie van gemeenschappelijk gebruik Een eerste belangrijke stap is het onderkennen van gemeenschappelijk gebruik en de daarbij behorende noodzaak om aandacht te besteden aan een effectief functioneel beheer dat is afgestemd op deze specifieke


Stap 1 Onderkennen gemeenschappelijk gebruik 150

Stap 2 Beleggen systeemeigendom

Stap 3 Inventariseren belangenpartijen

Stap 4 Inrichten communicatie

Stap 5 Vormgeven life cycle management Figuur 2 Een 5-stappenplan voor het bepalen van maatregelen

situatie. Een passend en effectief functioneel beheer ontstaat niet vanzelf. Hier dient voldoende aandacht en energie aan te worden besteed. Een eerste fase hierbij is gericht op organisatiebrede awareness ten aanzien van de noodzaak van functioneel beheer, die omgezet kan worden in voldoende commitment voor de volgende stappen. Voor het uitvoeren van de volgende stappen biedt het model voor functioneel beheer een bruikbaar kader. Dit model is beschreven in het IT Beheer Jaarboek 2002. In het voorgaande artikel over beheer van pakketten is reeds een aantal onderdelen uit het model voor functioneel beheer belicht die bruikbaar zijn voor het beheer van pakketten. In dit artikel wordt specifiek voor het gemeenschappelijk gebruik van applicaties nog een aantal extra elementen uit het model gebruikt. Het model voor functioneel beheer wordt op dit moment verder uitgewerkt tot een Business Information Systems Management Library (BISML) om daarmee nog meer ondersteuning te kunnen bieden.

Stap 2: beleggen systeemeigendom en eerste inrichting functioneel beheer Noodzakelijk voor een effectief functioneel beheer is het inrichten van een adequate besluitvorming over de toekomst van de applicatie. Hiertoe dient het systeemeigendom helder en eenduidig te worden belegd. We zagen echter al, dat helder en eenduidig belegd systeemeigendom alléén niet voldoende is voor effectief functioneel beheer. Het is belangrijk om daarbij te onderkennen dat er bij gemeenschappelijk applicatiegebruik in feite twee verschillende belangen bestaan: de belangen van de afzonderlijke gebruikersorganisaties en een overstijgend belang dat meer gericht is op de toekomst van de applicatie vanuit een gebruikersorganisatie-overstijgend belang. Om het systeemeigendom goed te laten functioneren is een omslag noodzakelijk. De systeemeigenaar dient zich niet te meer laten leiden door de eigen belangen met betrekking tot de functionaliteit van de applicatie,



Leveranciers Management

Ontwikkelingen Omgeving

Ontwikkelingen Technologie

Infor-

Richting gevend

Gebruikersorganisatie Ontwikkelingen

Organisatie v/d Informatievoorziening

mation Coor-

Lifecycle Management

Portfolio Management

151

dination Ontwikkelingen Organisatie Inhoudelijke Toekomst Informatievoorziening

Keten Management Inrichting Organisatie Informatievoorziening

Sturend

Planning en control

Kosten management

Kwaliteits management

Service level management

Wijzigingen Gebruikers ondersteuning

Beheer Bedrijfsgegevens

beheer Specificeren

Toetsen en Testen

Implementeren

Onderhoud Procedures

Uitvoerend Beheer bedrijfszekerheid Gebruiksbeheer

Release Overdracht

Functionaliteitenbeheer

Figuur 3 Model voor functioneel beheer (PinkRoccade)

3 maar dient meer oog te krijgen voor de belangen van alle betrokken partijen. Dit vereist een andere manier van acteren: namelijk van uitsluitend applicatie-inhoudelijk gericht naar meer aandacht voor het besluitvormingsproces. Het belang van de systeemeigenaar verschuift van juiste functionaliteit binnen de applicatie naar tevreden gebruikersorganisaties die de applicatie ook daadwerkelijk gebruiken. Om dit te bereiken is het aanbieden van de juiste functionaliteit een van de instrumenten, maar beslist niet het enige. Deze overgang pleit ervoor, om het systeemeigendom te beleggen bij een partij die geen eigen procesbelangen heeft bij de functionaliteit die uiteindelijk binnen de applicatie wordt gerealiseerd. Indien het systeemeigendom wordt belegd bij een aparte instantie die speciaal belast is met dit systeemeigendom, dan dient deze instantie wel voldoende mandaat en middelen te krijgen om besluiten te kunnen nemen en om genomen besluiten ook daadwerkelijk ten uitvoer te kunnen brengen.

Een van de eerste inrichtingsstappen die vervolgens gezet moet worden is het inventariseren van alle betrokken partijen en hun belangen. Stap 3: inventariseren van partijen en hun belangen Het proces van informatiecoördinatie is zeer belangrijk voor de systeemeigenaar. Voor de systeemeigenaar van een gemeenschappelijk gebruikte applicatie is het immers van belang om goed met de belangen van alle betrokken partijen om te gaan. Het is daarbij cruciaal om dan ook alle betrokken partijen helder in beeld te hebben. Bij grote organisaties is dat vaak al een hele klus. Het proces van informatiecoördinatie gaat over de expliciete verantwoordelijkheid om alle betrokken partijen te achterhalen en op een werkbare manier bij de besluitvorming te betrekken. Dit wil niet zeggen, dat bij de besluitvorming alle partijen een stem moeten hebben, of dat consensus vereist is. Wel wil het zeggen dat bewust een besluitvormingsproces wordt ingericht dat helder en eendui-


152

dig is voor alle betrokken partijen, en waarbij op een zorgvuldige manier alle belangen worden meegenomen. Een dergelijk besluitvormingsproces, gecombineerd met de juiste communicatie, is een ander middel voor een systeemeigenaar om de doelstelling van tevreden gebruikersorganisaties te bereiken. Stap 4: inrichten communicatie met alle partijen Als alle partijen in beeld zijn gebracht met daarbij hun verschillende belangen dient een werkbare samenwerkings- en communicatievorm te worden gecreëerd. Belangrijke aspecten waaraan daarbij aandacht moet worden besteed, zijn vormen van gebruikersoverleg, wijze van budgetverdeling en financiering van voorgenomen wijzigingen, besluitvorming over wijzigingen aan de hand van business cases, et cetera. Het gaat er hierbij niet om dat iedereen betrokken is bij de besluitvorming en daarbij z’n eigen belangen verdedigt. Het is wel belangrijk, dat alle betrokken partijen hun belangen inzichtelijk hebben en dat alle partijen er op kunnen vertrouwen dat hun belangen op de juiste wijze worden meegenomen

in de besluitvorming. Hiertoe is het opstellen van een model van verantwoordelijkheden een nuttig hulpmiddel. Zo’n model kan er uitzien als figuur 4. Hierbij wordt uitgegaan van een voorbeeld waarin de organisatie de volgende functies kent: Corporate Informatiemanagement (CIM), systeemeigenaar (SE), ICT-serviceteams (ST) en rekencentrum (RC). Als er in de aspect-regel een X staat, heeft de betreffende functie geen verantwoordelijkheid voor dit aspect, bij G een globaal bepalende verantwoordelijkheid, bij R een randvoorwaardelijke verantwoordelijkheid en bij I een verantwoordelijkheid om de invulling te bepalen. Het opstellen van een dergelijk model is op een aantal punten nuttig: • Het maakt ieders belangen inzichtelijk. • Het maakt onderlinge relaties in belangen duidelijk. • Het geeft weer op welke wijze belangen en verantwoordelijkheden samenhangen. • Het geeft weer op welke wijze de verschillende belangen worden meegenomen in de besluitvorming. • Het geeft richting aan de opzet van de communicatie- en besluitvormingsstructuur.

Gedefinieerde Meerdere partijen verantwoordelijkheden Verantwoordelijkheden op deelterreinen

O S I

CIM

SE

ST

RC

Beleidsmodel

G

R

X

X

Informatie architectuur

I

R

X

X

Applicatie architectuur

I

R

R

X

Ontwikkel architectuur

I

R

R

X

Exploitatie architectuur

I

R

X

R

Figuur 4 Model van verantwoordelijkheden



Corporate management

Randvoorwaarden, kaders

systeemeigenaar klantbelangen

Gebruikersorganisatie 1


153


Figuur 5 Positie van de systeemeigenaar

Voor de systeemeigenaar is het hierbij van belang dat hij zich zoveel mogelijk buiten de partijen opstelt en geen ander belang nastreeft dan het zo goed mogelijk dienen van alle belangen. Hierbij ontstaat als het ware voor de systeemeigenaar een rol die vergelijkbaar is met de rol van een externe pakketleverancier die streeft naar het verkrijgen en behouden van tevreden klanten. Stap 5: vormgeven life cycle management in relatie tot portfoliomanagement Nu alle betrokken partijen duidelijk zijn en heldere structuren voor besluitvorming en communicatie zijn gedefinieerd kan de volgende stap worden gezet. Deze stap behelst het vormgeven van een applicatiebeleid. Hiertoe dienen de processen uit het model voor functioneel beheer rond de inhoud van de informatievoorziening inhoud te krijgen, uiteindelijk uitmondend in een duidelijk life cycle management voor de onderhavige applicatie. Het life cycle management dient te worden gevoerd vanuit het perspectief van gemeenschappelijk gebruik. Door de onafhankelijke opstelling van de systeemeigenaar is hiervoor nu ook ruimte geschapen. Wel is het de verantwoordelijkheid van de systeemeigenaar dat bij het life cycle management ook rekening wordt gehouden met de gewenste inpassing van de applicatie binnen de totale applicatieportfolio op corporate niveau. Hierbij kunnen een informatiearchitectuur en procesmodellen van grote waarde zijn. Met deze architectuur en modellen is het mogelijk om te komen tot een heldere afbakening van de functionaliteit van de applicatie. Dit levert grote voordelen op bij de besluitvorming over

het wel of niet opnemen van specifieke functionaliteit voor specifieke gebruikersorganisaties. Het gebruik van procesmodellen verloopt verder analoog aan de wijze zoals die beschreven is in het voorgaande artikel.

CONCLUSIE Om voor alle drie de situaties bij pakketgebruik een effectief beheer in te richten, blijkt het noodzakelijk te zijn dit functioneel beheer op een aantal niveaus in te richten. Het functioneel beheer voor de derde situatie (gemeenschappelijk gebruik) is daarmee niet anders dan voor de eerste twee situaties (zoals beschreven in het artikel van 2003). Ook de in dat artikel genoemde maatregelen blijven noodzakelijk. Echter, voor de derde situatie zijn deze maatregelen niet voldoende. Aanvullend op deze maatregelen moet een extra laag van beheer worden ingericht. In het artikel van 2003 is al beschreven dat functioneel beheer op twee niveaus moet worden ingericht: • applicatiegebruiksniveau - directe ondersteuning van de gebruikers, monitoring van de werking van de applicatie en de afstemming tussen proces en applicatie; • procesniveau - vanuit het procesmodel de gewenste functionaliteiten definiëren en geboden functionaliteiten beoordelen.

3

In het voorliggende artikel wordt hieraan nog een derde niveau toegevoegd: • het organisatieniveau - optreden als systeemeigenaar, waarbij een heldere verantwoordelijkheid ligt voor een goedwerkend besluitvormingsproces en communicatiestructuur, alsmede voor een life cycle


Corporate management

Informatiemanager Beheer infrastructuur

154 Management Autonome Gebruikers organisatie

Functioneel beheer ondersteuning eindgebruiker

Systeemeigenaar

Service team

Applicatie Services organisatie Gebruikers

Omgeving Bv wet- & regelgeving

Functioneel beheer gebruiksniveau

Figuur 6 Relaties en aandachtsgebieden bij functioneel beheer

management voor de applicatie die past binnen de totale applicatieportfolio op corporate niveau. Met deze constateringen wordt nog meer de spin-in-het-web positie van het functioneel beheer benadrukt. Functioneel beheer moet op veel plaatsen en niveaus binnen organisaties worden uitgevoerd en onderhoudt veel relaties. In figuur 6 worden de verschillende aandachtsgebieden en relaties nog eens samengevat.

LITERATUUR • Delen, G.P.A.J. en M. Looijen. Beheer van informatievoorziening, CAP Gemini Publishing, Rijswijk 1992. • Deurloo, C.D., R. van der Pols en M.E.E. Meijer-Veldman. ‘Model voor functioneel beheer’. In: IT Beheer Jaarboek 1998, ten Hagen & Stam, 1998. • Deurloo, Kees, Frank van Outvorst en Remko van der Pols. ‘Een nieuw functioneel-beheermodel, De ervaringen van vijf jaar functioneel beheer’. In: IT Beheer Jaarboek 2002, ten Hagen & Stam, 2002. • Franken, Bert, Pauli van Eek, e.a. Functioneel beheer als managementinstrument, Spherion Technology Group BV, Zeist,

• Looijen,M. Beheer van informatiesystemen. Kluwer, 1997. • Outvorst, Frank van, Kees Deurloo en Peter van der Zee. ‘De praktijk van functioneel beheer - het model voor functioneel beheer in de praktijk’. In: IT Beheer Jaarboek 2001, ten Hagen & Stam, 2001. • Outvorst, Frank van en Ralph Donatz. ‘Functioneel beheer bij pakketten’. In: IT Beheer Jaarboek 2003, ten Hagen & Stam, 2003. • Pols, Remko van der. ‘Chaostheorie in Informatiebeleid’, In: Informatie, NGI/SAI/ten Hagen & Stam, december 1999. • Pols, Remko van der. ASL, een framework voor applicatiebeheer, ten Hagen & Stam, 2001. • Pols, Remko van der. Nieuwe informatievoorziening, Informatieplanning en ICT in de 21ste eeuw, Academic Service, 2003. • Steijger, Ton, en Kim Ophorst. Functioneel beheer, Realisatie van de Informatievoorziening, Spherion Technology Group BV, Zeist, 2001. • Thiadens, Th. Beheer van ICT-voorzieningen, infrastructuren, applicaties en organisatie, Academic Service, 1999.


Functioneel beheer bij pakketten (deel 2)

Recommend Documents