Dit betekent dat bedrijfsvoeringsystemen weer helemaal ‘hot’ zijn. Deze werkpaarden van de automatisering waarmee de processen worden ondersteund waren enkele decennia geleden zo’n beetje de eerste toepassingen van ICT die brede invoering vonden. En nu staan ze weer helemaal in het centrum van de belangstelling om het organisaties mogelijk te maken het internet-tijdperk te betreden. M&I/Partners heeft veel ervaring met bedrijfsvoeringsystemen. Hierover hebben wij de afgelopen jaren gepubliceerd in diverse tijdschriften, en deze publicaties zijn de basis van dit boek.
Voorbeelden uit de gemeentelijke overheid, sociale zekerheid, de industrie, het onderwijs en de openbare orde en veiligheid laten zien wat er zoal goed en fout kan gaan bij pogingen om met ICT de operatie te verbeteren, waar de kansen liggen en welke valkuilen er zijn. Het pad naar operational excellence is kronkelig en leidt langs diepe ravijnen, maar voert uiteindelijk naar grote hoogte. Wandelaars doen er goed aan eerst deze gids te raadplegen.
M & I PA R T N E R S
Verschillende aspecten komen daarbij aan de orde. ICT is techniek, en de technologische ontwikkelingen zijn onstuimig geweest (en zijn dat nog steeds). Maar niet alle hypes beklijven, en het is nodig om kritisch te zijn ten aanzien van de gouden bergen die soms worden beloofd. ICT is ook veranderen, organiseren, managen, en ook dat is een belangrijke dimensie van ICT-projecten, zeker bij bedrijfsvoeringsystemen. En ICT is ook inkoop – een aspect dat vaak niet de aandacht krijgt die nodig is waardoor veel initiatieven een ‘valse start’ maken.
O P E R AT I O N A L E X C E L L E N C E V E R E I S T E X C E L L E N T E P R O C E S O N D E R S T E U N I N G
Operational Excellence is de norm. Steeds meer organisaties, ook in de publieke sector, willen hun dienstverlening via het internet aanbieden, en dat kan alleen als alles intern goed op orde is. Want om zaken te kunnen doen via internet moet de back-office naar de voorkant worden gehaald: de processen moeten worden geautomatiseerd (al dan niet met behulp van self-service door de klant) en de systemen moeten worden ontsloten.
Operational Excellence vereist excellente procesondersteuning De eisen aan bedrijfsvoeringsystemen worden steeds hoger
M&I/Partners is een onafhankelijk adviesbureau op het snijvlak van organisatie-inrichting en informatievoorziening. Zie www.mxi.nl.
Eindredactie: Jaap de Mare
De kracht van toewijding
H200 Omslag Boekje_OpExcll_ONT.indd 1
08-08-2008 15:48:38
Bronnen De inhoud van dit boek is grotendeels gebaseerd op artikelen uit de volgende bronnen: •
Automatisering Gids, weekblad voor ICT-ers. verschijnt 50 keer per jaar, uitgeverij SDU. Zie www.automatiseringgids.nl Hoofdstuk 3 is gebaseerd op diverse artikelen uit de Automatisering Gids van 2005-2007
•
Overheid Innovatief, magazine voor beslissers binnen Rijk, Provincie en Gemeente op het snijvlak van overheid en ICT, verschijnt 6 keer per jaar, uitgeverij Kluwer Hoofdstuk 4 is gebaseerd op het artikel ‘Nieuwe bedrijfsvoeringssystemen breekijzer voor verandering’ uit de Overheid Innovatief van oktober 2006
•
TIEM, Tijdschrift voor Informatie en Management, verschijnt 6 keer per jaar, uitgeverij TIEM. Zie www.tiem.biz Hoofdstuk 5 is gebaseerd op het artikel ‘ICT-projecten niet geschikt voor control freaks en hokjesdenkers’ uit de TIEM van maart 2006
•
Gids voor Personeelsmanagement, vaktijdschrift voor HR-professionals, verschijnt 10 keer per jaar, uitgeverij Kluwer. Zie www.gidsonline.nl Hoofdstuk 6 is gebaseerd op het artikel ‘Van onbespreekbaar naar vanzelfsprekend, nieuw HRM-elan bij Gemeente Rotterdam’, uit de Gids voor Personeelsmanagement van januari 2007
•
De Kracht van Toewijding: improviseren op het grensvlak van ICT en verandering, boek uitgegeven ter gelegenheid van het 20-jarig bestaan van M&I/Partners, 2005, uitgeverij Academic Service. Zie www.mxi.nl Hoofdstuk 7 en 9 zijn gebaseerd op een tweetal hoofdstukken uit dit boek
•
Profiel, vakblad voor de BVE-sector, verschijnt 9 keer per jaar, uitgeverij Profiel Producties. Zie www.profielvakblad.nl Hoofdstuk 10 is gebaseerd op het artikel ‘Hoogwaardige ICT-ondersteuning: applicatie-architectuur die toekomstproof is’ uit de Profiel van november 2007
Operational Excellence vereist excellente procesondersteuning De eisen aan bedrijfsvoeringsystemen worden steeds hoger
Eindredactie: Jaap de Mare
1
Copyright M&I/Partners, september 2008 Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt worden door middel van druk, fotokopie, microfilm of op welke andere wijze dan ook zonder voorafgaande schriftelijke toestemming van M&I/Partners. Productie: Drukkerij Bakker Baarn Vormgeving kaft: Volta_ontwerpers, Utrecht Cartoons: Tochtstrips.nl Dit boek is in eigen beheer uitgegeven en is verkrijgbaar bij M&I/Partners, www.mxi.nl/boekBVS
2
Woord vooraf Ooit, in de jaren negentig, gold Operational Excellence nog als een strategische optie om je als organisatie te onderscheiden1. Die tijd is voorbij: voor organisaties binnen én buiten de marktsector is het tegenwoordig een levensnoodzaak je processen goed voor elkaar hebben. Bedrijfsvoeringsystemen moeten er voor zorgen dat dit ook lukt. Internet heeft een revolutie tot stand gebracht in de verwachtingen die burgers en consumenten hebben van de snelheid en nauwkeurigheid waarmee processen worden uitgevoerd. U zoekt werk? Dan schrijft u zich on-line in als werkzoekende op www.werk.nl en heeft u onmiddellijk toegang tot het volledige bestand van vacatures. U wilt gaan trouwen in Den Haag? Alle mogelijkheden, inclusief beschikbaarheid en opties, kunt u vinden en reserveren op www.onshaagsehuwelijk.nl. U heeft een vergunning aangevraagd? Dan kunt u de voortgang van uw aanvraag altijd even nakijken op de site. Deze nieuwe verwachtingen
1
Zie Treacy & Wiersema, De discipline van marktleiders, 1996
3
stellen hoge eisen aan de manier waarop processen ondersteund worden. Geen formulieren die van bureau naar bureau worden geschoven, geen lijstjes die apart worden bijgehouden, geen verschillende systemen die ieder een deel van de benodigde informatie kunnen leveren maar onvoldoende met elkaar geïntegreerd zijn. De ‘on-demand’ wereld is een feit, en dat betekent dat processen vergaand geautomatiseerd moeten worden, dat systemen real-time gekoppeld moeten worden, dat de activiteiten van verschillende afdelingen naadloos op elkaar moeten aansluiten. Welkom in een wereld waarin operational excellence de norm is. Gelukkig biedt ICT talloze mogelijkheden om deze uitdagingen aan te gaan, maar eenvoudig is het niet. De bedrijfsvoeringsystemen, de mastodonten van de automatisering, moeten op de schop en dat zijn moeizame trajecten. Dit boek bundelt de inzichten van de adviseurs van M&I/Partners op dit gebied. Het zijn grotendeels bewerkingen van artikelen die eerder in tijdschriften of in het boek ‘De kracht van toewijding’ verschenen. Samen geven ze een breed beeld van de uitdagingen voor organisaties bij het aanpassen van hun bedrijfsvoering aan de eisen die er in deze tijd aan worden gesteld. Veel leesplezier! Jaap de Mare M&I/Partners
4
Inhoudsopgave Inleiding: bedrijfsvoeringsystemen zijn weer helemaal actueel Deel A: ontwikkelingen
7 11
Hoofdstuk 1
Hypes van vroeger die blijvertjes bleken: BPR, ERP, EAI, workflow en internet 13 Erik Samson en Bert Melief
Hoofdstuk 2
Hypes van nu: web services, SOA, BPM en BPEL Erik Samson
Deel B: organisatie (inkoop, verandermanagement) Hoofdstuk 3
Inkoop
22 33 35
Joop Schuilenburg 3.1 3.2 3.3 3.4
Hoofdstuk 4
Hoofdstuk 5
inkoop bedrijfsvoeringsystemen te complex voor inkoopafdeling Softwareaanbieders rekenen te veel voor onderhoud Richtlijn maakt dialoog bij aanbestedingen mogelijk Dynamisch aankoopsysteem werkt niet zoals bedoeld
35 41 46 50
Nieuwe bedrijfsvoeringsystemen zijn een breekijzer voor verandering Jaap de Mare
55
ICT-projecten niet geschikt voor control freaks en hokjesdenkers Jaap de Mare
59
Deel C: cases
63
Hoofdstuk 6
Nieuw HRM-elan in Rotterdam Bob Hotho, Willem-Jan Herckenrat en Jaap de Mare
65
Hoofdstuk 7
Procesbesturing in de sociale zekerheid Jaap de Mare
70
Hoofdstuk 8
Regionalisering brandweer vraagt keuzes in bedrijfsvoering Arend de Jong
Hoofdstuk 9
Implementatie van een centraal HRM-systeem Jan Houben
78 90
Hoofdstuk 10 Applicatie-architectuur bij het ROC van Amsterdam 100 Hans Doffegnies en Jaap de Mare
5
6
Inleiding: bedrijfsvoeringsystemen zijn weer helemaal actueel ‘The problem of production has been solved’ schreef John Kenneth Galbraith, een bekend econoom, eind jaren vijftig. Als hij had vermoed welke duizelingwekkende ontwikkelingen zich na die tijd nog op het gebied van (industriële) productie zouden voordoen, dan zou hij zich zeker wat terughoudender hebben uitgedrukt. Geldt hetzelfde voor bedrijfsvoeringsystemen? De werkpaarden van de automatisering waarmee processen worden ondersteund? Het zijn ongeveer de eerste toepassingen van computers; al in de zestiger jaren van de vorige eeuw begon men met het automatiseren van financiële administraties, salarisadministraties, voorraadadministraties et cetera.. En de ontwikkeling is nooit meer gestopt. Steeds zijn er nieuwe mogelijkheden, nieuwe technologieën, nieuwe perspectieven op het terrein van bedrijfsvoering. En ook nieuwe noodzaken, want de eisen aan de operationele effectiviteit van organisaties worden steeds hoger. Het automatiseren van administratieve processen, of het ondersteunen ervan met ICT, is nooit eenvoudig geweest en is dat nog steeds niet. Miljarden Euro’s worden er uitgegeven aan ERP-, maatwerk- en andere systemen, en vaak ligt er veel bloed op het kussen. Moeizame implementaties, schuivende tijdlijnen, tekortschietende functionaliteit, budgetoverschrijdingen…. Iedereen kent wel voorbeelden uit zijn eigen omgeving en anders lezen we er wel over in de krant als het over de belastingdienst, het UWV of de paspoorten gaat. Bij M&I/Partners hebben we veel ervaring met bedrijfsvoeringsystemen: met het maken van het bestek en het aanbesteden van een nieuw systeem, met het projectleiderschap voor de bouw en implementatie, met het verandermanagement dat nodig is om het nieuwe systeem te laten ‘landen’, met het ontwerpen van een slimme architectuur waarin ieder systeem een goed gedefinieerde plek heeft, met het beoordelen of een bestaand systeem kan worden verbeterd of dat er een nieuw systeem moet worden aangeschaft, et cetera. En daarbij hebben we veel verschillende rollen vervuld: ‘hands-on’ tot de knieën in de modder, als adviseur slimme dingen roepend vanaf de zijlijn, als kwaliteitsmanager of auditor. Een deel van onze ervaringen hebben wij met de buitenwereld gedeeld in de vorm van eigen publicaties, boeken en artikelen in een breed scala van tijdschriften.
7
Wij vonden het tijd worden om onze publicaties te bundelen, om een overzicht te geven van verschillende aspecten die bij bedrijfsvoeringsystemen van belang zijn. Sommige artikelen zijn dusdanig bewerkt dat ze nauwelijks meer te herkennen zijn, andere zijn vrijwel ongewijzigd geplaatst. Met elkaar kunnen ze iedereen helpen die op beleidsniveau beslissingen moet nemen over bedrijfsvoeringsystemen of deze beslissingen moet voorbereiden. In het eerste deel gaan we in op de belangrijkste ontwikkelingen op het gebied van bedrijfsvoeringsystemen in de laatste 15 jaar. Dan gaat het over hypes, over gevleugelde begrippen die na verloop van tijd onvoldoende zweefvermogen bleken te beschikken, of juist blijvertjes bleken en ons inzicht tot grote hoogten hebben getild. Hoofdstuk 1 gaat over de blijvertjes, over inzichten die nu gemeengoed zijn geworden. Dan gaat het over ERP, EAI (Enterprise Application Integration) en Workflow, over BPR (Business Process Re-engineering) en Internet. Hoofdstuk 2 gaat over de hypes van nu, over inzichten waarvan nog moet blijken of ze zullen beklijven: Web Services, SOA (Service Oriented Architecture), BPEL (Business Process Execution Language) en BPM (Business Process Management). Ontwikkelingen met grote perspectieven, maar waarbij ook de nodige relativering vereist is. In het tweede deel gaat het over organisatorische zaken die van belang zijn bij nieuwe bedrijfsvoeringsystemen. Daarbij concentreren we ons op twee aspecten: inkoop en verandermanagement. Hoofdstuk 3 is volledig gewijd aan inkoop en de valkuilen bij het acquireren van bedrijfsvoeringsystemen. Inkoop is een belangrijk onderwerp omdat veel richtinggevende keuzes al voorafgaand aan de acquisitie van bedrijfsvoeringsystemen moeten worden gemaakt. M&I/Partners heeft één van de meest vooraanstaande experts op dit gebied in zijn midden. Hoofdstuk 4 gaat over het verandermomentum dat kan worden gegenereerd als er een nieuw bedrijfsvoeringsysteem wordt geïmplementeerd. Een momentum dat zelf al van grote waarde kan zijn voor een organisatie! Hoofdstuk 5 is een kort artikel dat de essentie samenvat van een boek dat enkele adviseurs van M&I/Partners enkele jaren geleden hebben geschreven over verandermanagement, ‘De Kracht van Toewijding, improviseren op het snijvlak van organisatie & ICT’. De conclusie luidt dat ICT-projecten (en bedrijfsvoeringprojecten in het bijzonder) niet geschikt zijn voor control freaks en hokjesdenkers. Het derde deel bestaat uit cases die bovenstaande zaken illustreren en ook eigen waardevolle lessen bevatten. Hoofdstuk 6 gaat over het project ‘Mensen met Pit’ van de gemeente Rotterdam, een groot project 8
waarbij zowel een nieuw HRM- als een nieuw financieel systeem werden geïmplementeerd, en waarbij men uiteindelijk veel meer gezamenlijk deed dan van tevoren was verwacht. Hoofdstuk 7 gaat over een mislukt project bij een sociale verzekeringsinstelling om het proces van aanvragen van een uitkering door middel van workflow te ondersteunen. Van mislukte projecten valt vaak meer te leren dan van geslaagde, en dat blijkt ook hier. Hoofdstuk 8 gaat over de uitdagingen bij de brandweerkorpsen in Nederland die gaan samenwerken in zogeheten veiligheidsregio’s (aansluitend op de regio-indeling van de politie). Dit geeft de nodige uitdagingen op het gebied van de organisatie en ondersteuning van de bedrijfsvoering. Hoofdstuk 9 beschrijft het weerbarstige proces om een centraal HRM-systeem te implementeren bij een onderneming met twee zeer verschillende divisies. Hoofdstuk 10, tenslotte, beschrijft het pad dat het ROC van Amsterdam bewandelt om tot een geïntegreerde applicatie-architectuur te komen, een situatie waarin verschillende systemen ieder hun eigen, goed gedefinieerde plekje hebben en goed met elkaar samen werken.
Wat zijn bedrijfsvoeringsystemen? Bedrijfsvoeringsystemen zijn systemen die administratieve processen ondersteunen. Dit kunnen zowel primaire processen (rechtstreeks voortkomend uit de taakstelling van de organisatie) als ondersteunende processen zijn. Bij primaire processen kan worden gedacht aan de afhandeling van een verzekeringsclaim, de reservering van een vliegtuigstoel, de aanvraag van een uitkering, de administratie van pensioenaanspraken, de aanvraag van een vergunning, etc. Hier vinden we vaak sectorspecifieke applicaties (b.v. studentadministratiesystemen in het onderwijs, de ‘4all’ suite van Centric voor gemeentes); bij grote unieke organisaties zoals Belastingdienst, UWV en CWI komen ook veel maatwerkapplicaties voor. Een ontwikkeling die we daarbij zien is dat ook ‘unieke’ applicaties steeds vaker worden ontwikkeld met behulp van bestaande standaardsoftware. Zo is het Sonar-systeem waarmee het CWI werkzoekenden administreert gebouwd in Siebel, een standaard CRMsysteem. Ook de Belastingdienst is onlangs tot de conclusie gekomen dat, ondanks de unieke taakstelling van de dienst, slechts een enkele bedrijfsfunctie als uniek kan worden bestempeld; alle andere functies zouden met behulp van standaardapplicaties ondersteund kunnen worden2.
2
zie ‘Belasting stapt over op standaardsoftware’, Automatisering Gids 24/2007
9
Bij ondersteunende processen gaat het om administraties die in elke organisatie voorkomen: financiële administratie, factureren en debiteurenbewaking, personeelsadministratie en andere HRM-processen, CRM (Customer Relationship Management), facilitaire processen, of administraties die vooral in industriële organisaties voorkomen: produktieplanning, inkoop, voorraadbeheer, logistieke planning etc. Hier vinden we de brede standaardapplicaties, de applicaties die op meer of minder gestandaardiseerde wijze de betreffende processen ondersteunen: Exact, Account View, Beaufort, HR Access etc.. Als er verschillende functionele gebieden door één applicatie worden ondersteund dan spreken we van ERP-systemen, en dat zijn de ware giganten van de software-industrie: SAP, Oracle e-business suite, PeopleSoft, Microsoft Dynamics, etc
10
deel A
Ontwikkelingen
11
12
Hoofdstuk 1 Hypes van vroeger die blijvertjes bleken: BPR, ERP, EAI, workflow en internet Bert Melief en Erik Samson3 Omdat bedrijfsvoeringsystemen zo vitaal zijn voor bijna iedere organisatie zijn er veel ‘hypes’ geweest die telkens weer ‘the next big thing’ beloofden. En omdat de ontwikkelingen in de wereld van de ICT onverminderd snel gaan, is er telkens wel weer iets interessants te melden, zijn er steeds weer relevante ontwikkelingen met interessante perspectieven. De bekende ‘hype cycle’ van Gartner (zelf één van de grote leveranciers van hypes) geeft aan dat na een eerste golf van belangstelling en enthousiasme doorgaans een fase van ontnuchtering plaats vindt, van teleurstelling. Daarna vindt eigenlijk de beslissende fase plaats waarin hypes hetzij op de vuilnisbelt van de ICT-geschiedenis belanden, hetzij ophouden hype te zijn en een plekje vinden in de standaard ‘body of knowledge’ van de ICT-wereld. Dit hoofdstuk behandelt enkele hypes van de laatste 15 jaar die tot de laatste categorie behoren, die in meer of mindere mate onderdeel zijn van de bagage van iedere ICT-er in het veld van bedrijfsvoeringsystemen: BPR: Business Process Re-engineering, het radicale herontwerp van processen vaak met behulp van ICT
Hypes Een hype (afgeleid van het Grieks: hyper = boven) is een verschijnsel dat bovenmatige media-aandacht krijgt en daardoor belangrijker lijkt dan het in werkelijkheid is. Het gevolg van dit mechanisme kan zijn dat iets wat als een hype begint, uitgroeit tot een werkelijk belangwekkend verschijnsel. Wanneer een verschijnsel in een korte periode mateloos populair is geworden, en ontstaan is zonder exceptionele mediaaandacht, wordt dit een rage genoemd
3
dit hoofdstuk is een bewerking van ‘Business Process Management: gaat het echt iets betekenen?’ Congresbundel 'Direction: Service Oriented Enterprise', Studievereniging SBIT, november 2006
13
ERP: Enterprise Resource Planning, de allesomvattende bedrijfsvoeringsystemen waarin financiën, HRM, logistiek en allerlei andere disciplines op geïntegreerde wijze worden ondersteund EAI: Enterprise Application Integration, het op een slimme en overzichtelijke manier aan elkaar knopen van allerlei verschillende bedrijfsvoeringapplicaties Workflow: de ‘ultieme’ procesondersteunende software Internet: de koning aller hypes, die ook op het gebied van bedrijfsvoeringsystemen een enorme impact heeft gehad en nog steeds heeft. SOA, web services, BPEL en BPM: service georiënteerde architecturen (SOA), met name op basis van web services, die gerealiseerd worden door de business processen te managen (BPM) en te vertalen met een business proces uitvoeringstaal (BPEL), een samenspel van methoden, technieken en hulpmiddelen die de kloof tussen business en IT moet verkleinen. Deze hype wordt in het volgende hoofdstuk beschreven.
BPR Business Process Re-engineering, populair in de jaren 90 van de vorige eeuw, hield zich bezig met radicale procesverbeteringen binnen en tussen organisaties. Het boek van Michael Hammer en James Champy: ‘Reengineering the Corporation’ uit 19934 was een bestseller die door managers in alle geledingen werd gelezen. BPR gaat ervan uit dat het soms nodig is om een onderneming radicaal opnieuw te ontwerpen en te reorganiseren (met een schone lei beginnen) teneinde de kosten te verlagen en de kwaliteit te verhogen. De nieuwe mogelijkheden van informatietechnologie zijn daarbij de sleutel, en het boek van Hammer en Champy noemt fraaie voorbeelden van processen waar dramatische verbeteringen in kosten, kwaliteit en doorlooptijd gerealiseerd konden worden. Maar het gaat bij BPR zeker niet alleen om de inzet van informatietechnologie maar ook om een nieuwe visie op waar de toegevoegde waarde van een organisatie eigenlijk ligt (altijd vanuit het perspectief van de klant) en hoe deze tot stand komt. Het resultaat is niet alleen een procesverandering en de inzet van (veel) meer ICT, maar ook een organisatieverandering die aansluit op de manier waarop de toegevoegde waarde voor de klant wordt gecreeerd.
4
Bron: Michael Hammer en James Champy: "Reengineering the Corporation" HarperCollins, 1993.
14
In het midden van de negentiger jaren werd BPR steeds vaker gebruikt als een eufemisme voor downsizing. Hele bedrijven, zoals American Airlines en Apple, gingen op de schop en werden zodoende dramatisch afgeslankt maar konden daardoor overleven. Maar er waren ook veel teleurstellingen, organisaties waar onder het vaandel van BPR wel afgeslankt werd maar geen procesverbeteringen werden doorgevoerd, waar een hoop stof werd opgewerveld maar weinig beklijfde, waar de ambities torenhoog en de resultaten gering waren. Wat uiteindelijk is blijven hangen is het inzicht dat de toegevoegde waarde van een organisatie alleen vanuit het perspectief van de klant gedefinieerd kan worden, dat er vanuit dat perspectief vaak belangrijke procesverbeteringen mogelijk zijn en dat de slimme inzet van ICT daar een belangrijke rol in kan spelen. De technologie die dat mogelijk maakt heeft zich sedert de hype van BPR sterk verder ontwikkeld (zie ook hoofdstuk 2 van dit boek) dus ook wat dat betreft is het goed om het gedachtegoed van BPR in ere te houden.
ERP Enterprise Resource Planning is een naam die de lading steeds minder dekt (vooral het ‘Resource Planning’). Ontstaan vanuit de industrie, en dan vooral de ‘operations’ kant (planning, logistiek), heeft het zich ontwikkeld tot de verzamelnaam voor het integraal ondersteunen van vrijwel alle administratieve processen van organisaties: van primaire processen zoals productplanning, voorraadbeheer, inkoop, interactie met leveranciers, klantenservice, orderafhandeling, en ook van ondersteunende processen zoals de financiële administratie, Human Resource Management, Customer Relationship Management, facilities management etc. ERP-systemen zijn sterk procesgericht, en de inrichting van deze systemen vergt dan ook aanzienlijke inspanningen rond procesanalyse en nieuwe werkprocedures. Het zijn vaak enorme systemen, met bekende namen als SAP, Oracle, PeopleSoft, J.D. Edwards (deze laatste twee zijn tegenwoordig onderdeel van Oracle), Navision/ Dynamics (Microsoft) en nog verscheidene anderen. Het wezen ervan is dat ERP al de hierboven beschreven functionele gebieden met elkaar integreert, waardoor het bijvoorbeeld mogelijk wordt een verkocht product ook direct in te plannen in de productie, daarvoor de benodigde onderdelen en grondstoffen te bestellen, de factuur te versturen, en dit alles te boeken in de financiële administratie.
15
In de industrie is ERP zeer succesvol gebleken. In de financiële wereld, zorg, overheid en onderwijs is het later en minder breed doorgedrongen; ERP-systemen worden daar vooral in het HRM- en financieel administratieve domein ingezet. De integratie van de verschillende functionele gebieden en de sterke procesondersteuning zijn de grote voordelen van ERP, maar aan ieder van deze medailles zit ook een keerzijde. ERP-systemen zijn vaak goed in het integreren van de verschillende modules die het zelf bevat, maar minder goed in het integreren met andere toepassingen. Dit komt mede doordat ERP-systemen gebruik maken van een centrale database, waar andere applicaties niet of moeilijk op kunnen aanhaken. Het gevolg is dat organisaties die eenmaal enkele modules van een bepaald ERPsysteem hebben aangeschaft, ook voor andere functionele gebieden modules van het betreffende systeem gaan inzetten – ook als deze modules op zichzelf genomen wellicht niet zo goed zijn. Dit voorkomt problemen ten aanzien van integratie maar het beperkt wel de keuze. Klanten ervaren vaak een hoge ‘lock-in’: eenmaal klant van (b.v.) Oracle is het niet eenvoudig meer om voor deelfunctionaliteiten andere applicaties in te zetten. Overigens zijn hier volop ontwikkelingen in omdat ook ERP-leveranciers beseffen dat ze niet het volledige speelveld van benodigde functionaliteiten kunnen bieden, dat het voor klanten van belang is ook andere applicaties goed te integreren met het ERP-systeem. De technologische mogelijkheden op het gebied van integratie (o.a. op basis van een Service Oriented Architecture, zie volgende hoofdstuk) zijn volop in ontwikkeling en de ‘openheid’ van de ERP-systemen neemt langzaam toe. Ook het andere grote voordeel van ERP, de procesondersteuning, heeft z’n keerzijde. Om een ERP-systeem goed in te kunnen richten moeten alle relevante processen eerst in kaart worden gebracht, waarna ze ingericht (‘geparametriseerd’) worden in het systeem. Dit betekent niet alleen dat het inrichten van een dergelijk systeem een omvangrijk project is, het betekent ook dat het niet zo eenvoudig is om de processen vervolgens weer te veranderen. Gebruikers van ERP-systemen hebben vaak het gevoel dat de processen ‘in beton gegoten’ worden en dat de flexibiliteit goeddeels verdwenen is: procesverbeteringen leiden tot ‘changes’ in het systeem en die vragen in een ERP-systeem een grote inspanning en hebben daardoor vaak een vrij lange doorlooptijd.
16
“ERP-pakketten zijn als een mooi meisje: de schoonmoeder krijg je er ook bij”
ERP is al lang geen hype meer: het is gemeengoed in de industrie en ook steeds meer daarbuiten. Mede door de ontwikkeling van de technologie (zie volgende hoofdstuk) worden ERP-applicaties steeds minder monolithisch en zijn ze steeds beter in te passen in een architectuur waarin ook andere applicaties hun plek hebben.
EAI Enterprise Application Integration is een term voor de methoden en tools die gericht zijn op het integreren, consolideren en coördineren van verschillende applicaties in een onderneming. Daarbij gaat het dus om het ondersteunen en stroomlijnen van de raakvlakken tussen de verschillende applicaties. Als er slechts enkele raakvlakken zijn dan is een point-to-point integratie meestal voldoende. Dit heeft veelal de vorm van een rechtstreekse koppeling tussen de databases van de te koppelen applicaties. Koppelingen op de database-laag zijn echter riskant omdat het moeilijk is om de integriteit van de database van de ontvangende applicatie te garanderen; accountants hebben er dan ook vaak een grote hekel aan. Een ander groot nadeel van point-to-point koppelingen is dat het onover17
zichtelijk wordt en de beheerlast fors toeneemt als het aantal koppelingen toeneemt. EAI adresseert beide nadelen van point-to-point koppelingen. Er wordt geïntegreerd op de ‘business logic’ laag, het deel van de applicatie waar de logica van het systeem wordt gedefinieerd. Op deze laag kunnen allerlei controles op de gegevens worden uitgevoerd waardoor corruptie van de database van de ontvangende applicatie wordt voorkomen. Technisch gezien wordt de koppeling uitgevoerd met berichtenverkeer (veelal gebaseerd op XML), wat betekent dat de integratie niet ‘real time’ is maar op zijn best ‘near real time’ Om de onoverzichtelijkheid en beheerlast van grote aantallen koppelingen te vermijden wordt er door EAI een ‘message broker’ (een berichtenmakelaar) gebruikt. Wijzigingen in systemen worden als een bericht naar de message broker gestuurd (en dus niet naar alle ontvangende applicaties zoals bij point-to-point integratie); ontvangende applicaties voor wie deze wijziging relevant is hebben een ‘abonnement’ op het betreffende type wijziging en ontvangen het betreffende bericht. EAI kan in zeker opzicht gezien worden als een alternatief voor ERP. Bij ERP vindt de integratie tussen de verschillende functionaliteiten binnen de applicatie plaats; in de (theoretische) situatie dat alle door een organisatie benodigde functionaliteiten door één ERP-pakket zouden worden geleverd is er dus geen integratie met andere applicaties (en dus ook geen EAI) nodig. Andersom kan worden gesteld dat een ‘best of breed’ strategie (niet één allesomvattende ERP-applicatie maar verschillende applicaties voor verschillende functionele gebieden) dermate veel koppelingen tussen applicaties met zich mee brengt dat een dergelijke strategie zonder EAI geen goed werkbare situatie oplevert. Maar het onderscheid tussen EAI en ERP is aan het vervagen nu ook de belangrijkste ERP-leveranciers EAI-software aanbieden (SAP NetWeaver, Oracle Fusion Middleware en Microsoft Bizztalk) – al was het maar om hun ERP-systemen te kunnen laten communiceren met ‘omringende’ systemen. EAI is nog steeds volop actueel voor organisaties die hun applicaties op een duurzame manier met elkaar willen integreren. De meest actuele hype rond procesverbetering en applicatie-integratie, de Service Oriented Architecture gebaseerd op web services (zie volgend hoofdstuk) bouwt in feite voort op de concepten van EAI.
18
Workflow De negentiger jaren zijn ook de decade dat workflow z’n entree maakte in de vocabulaire van menig ICT-er. In workflowmanagementsystemen doorloopt een 'case' een van tevoren gedefinieerd proces. Afhankelijk van het proces gaat een case van de ene medewerker of afdeling naar de volgende; de medewerker hoeft alleen de eigen taken uit te voeren: het systeem zorgt dat de case in het juiste werkbakje terecht komt voor de volgende stap. Zo kan het werk zeer gestructureerd worden uitgevoerd en heeft het management op ieder moment inzicht in de stand van zaken. Workflowmanagementsystemen waren vooral in het begin van de jaren negentig van de vorige eeuw een hype, waarbij de verwachting was dat steeds meer organisaties steeds meer processen met behulp van workflow zouden willen ondersteunen. Geen dossiers meer die (fysiek of digitaal) ‘achter het bureau glijden’, geen onduidelijkheid over wie nu wanneer wat moet doen … de verwachtingen waren hooggespannen. Er kwamen zowel gespecialiseerde workflow-pakketten op de markt als workflow-modules van de ERP-leveranciers. De verwachtingen werden echter niet helemaal waargemaakt. Workflow staat geen spontane variaties in de procesgang toe: wat niet van tevoren is gedefinieerd, is niet mogelijk. Dat maakt workflow voor veel processen te rigide; gebruikers voelden zich in een keurslijf gedwongen en vonden dat hun eigen professionaliteit wordt miskend (“ik weet echt zelf wel wat er moet gebeuren, daar heb ik geen systeem voor nodig”). Een voortdurend punt van aandacht bij workflow-systemen is de performance. Dit is een inherent zwak punt van workflow-systemen vanwege de manier waarop ze de database gebruiken. In de meeste workflowsystemen worden de rapportages daarom niet vanuit de live database gedaan, maar vanuit een afslag daarvan. De laatste tijd is er echter sprake van een wederopstanding. Nieuwe workflowpakketten zijn flexibeler, laten zich gemakkelijker integreren met andere applicaties en kunnen heel snel worden ingericht. Ze zijn vaak een onderdeel van implementaties van Document Management Systemen, waarbij het proces van het plaatsen, wijzigen en verwijderen van documenten met behulp van workflow wordt ondersteund. Het fundamentele punt dat elk proces van tevoren gedefinieerd moet zijn, is echter gebleven.
19
Internet Internet kan met recht de ‘koning van de hypes’ worden genoemd. Rond de eeuwwisseling was er een enorme hype rond het Internet (toen nog met hoofdletter geschreven) die een economische hausse genereerde die zijn naoorlogse gelijke niet kende. Toen de hype over zijn hoogtepunt heen was volgde een recessie die aantoonde dat internet weliswaar een enorme impact had op allerlei zaken in de maatschappij, maar dat de wetmatigheden ten aanzien van economische cycli nog steeds gelden. De invloed van het internet was en is natuurlijk enorm, ook op alles wat met bedrijfsvoering en bedrijfsvoeringsystemen te maken heeft. Daarbij kunnen twee dimensies worden onderscheiden: de eisen die aan de bedrijfsvoering worden gesteld, en de mogelijkheden om aan deze eisen te voldoen. Internet heeft een enorme impact gehad op de verwachtingen van burgers en consumenten over de snelheid van handelen van organisaties en over de inzichtelijkheid in de voortgang van processen. Via internet zijn processen die vroeger in de ‘back office’ plaats vonden voor iedereen transparant geworden. De voorbeelden zijn legio: het kopen van reizen of kaartjes via internet (‘helaas zijn het door u gewenst aantal kaartjes op die avond niet meer beschikbaar, maar bij de matineevoorstelling op zondag is nog wel plek’), het kunnen volgen van een bestelling via internet (‘uw bestelling is vandaag verzonden’), het kopen én direct geleverd krijgen van software en muziek downloads – het aantal voorbeelden is vrijwel onuitputtelijk. En al lang niet meer alleen in de marktsector, maar ook bij de overheid, het onderwijs, de gezondheidzorg et cetera. Internet heeft niet alleen de eisen die aan de bedrijfsvoering worden gesteld enorm aangescherpt, het heeft ook de mogelijkheden om aan deze eisen te voldoen in hoge mate verruimd. Daarbij kan onderscheid worden gemaakt tussen technologische en functionele mogelijkheden. Op technologisch gebied kan worden gesteld dat internet-technologie overal terug te vinden is. Nadat eerst het Internet Protocol (IP) al de standaard was geworden voor datatransport is de browser steeds meer de standaard aan het worden voor de gebruikersinterface van applicaties. Dit biedt zowel voordelen qua beheer van applicaties alsook qua ontsluiting, b.v. van buiten de muren van de eigen organisatie. En ook op het gebied van gegevensuitwisseling tussen verschillende applicaties 20
zijn de moderne standaards (XML en alle afgeleide protocollen) grotendeels op internet-technologie gebaseerd. Men zou kunnen stellen dat het onderscheid tussen internet technologie en andere technologieën in feite niet zo relevant meer is. Ook op functioneel gebied heeft internet de nodig invloed gehad in de wereld van de bedrijfsvoeringsystemen. Dit betreft vooral de openheid van de applicaties, en in het verlengde daarvan ook de openheid van organisaties. Bedrijfsvoeringsystemen kunnen worden ‘opengesteld’ voor klanten en leveranciers die self-serving hun deel van het proces uitvoeren. In het verlengde daarvan heeft ook de ketenintegratie een enorme vlucht genomen. In de dagen vóór internet bleef ketenintegratie beperkt tot slechts enkele sectoren die strakke afspraken hadden gemaakt met leveranciers en met behulp van Edifact standaarden berichten met elkaar uitwisselden (b.v. de automobielbranche, de bouwmarkten en nog enkele branches). Standaarden als XML verlagen echter de drempel tot integratie aanzienlijk en maken ook een veel flexibelere integratie mogelijk. Dit heeft het b.v. in de sociale zekerheidssector mogelijk gemaakt om informatie uit een veelheid van verschillende bronnen (over allerlei inkomenscomponenten) vanuit een centrale plaats te ontsluiten om zo bijstandsfraude te ontdekken. Al met al kan worden gesteld dat ook op het gebied van bedrijfsvoeringsystemen internet de ‘koning der hypes’ is – een hype die niet verdampt, maar die in hoge mate ook de komende jaren de agenda voor bedrijfsvoeringsystemen zal bepalen.
21
Hoofdstuk 2 Hypes van nu: web services, SOA, BPM en BPEL Erik Samson Al sinds mensenheugenis wordt er gesproken over ‘business alignment’, het afstemmen van de IT op de doelstellingen en processen van de organisatie. Er gaapt een kloof tussen wat de business wil en wat IT levert. Bovendien – zo zegt men - loopt de IT steeds achter bij de wens, de IT is niet flexibel en bovendien is iedere verandering duur. De IT moet flexibel worden, ‘agile’ zoals dat nu heet, efficiënt en effectief. De technologische ontwikkelingen van de laatste jaren creëren hier ook nieuwe mogelijkheden voor. Een oud probleem verdient een nieuwe oplossing. En de technologische mogelijkheden zijn door de inzet van (web) services en daarmee samenhangende technologieën, weer toegenomen.
Bibliotheken en objecten Al sinds de jaren vijftig van de vorige eeuw is het duidelijk dat computers lange reeksen opdrachten nodig hebben om wat complexere opdrachten uit te voeren. Een reeks opdrachten noemen we een programma of applicatie. Om overzicht te houden moeten die lange reeksen opdrachten gestructureerd worden. De talen waarin computerprogramma’s vanaf de jaren veertig van de vorige eeuw geschreven werden, ging steeds meer structuur en hulpmiddelen bieden. Vanaf de jaren vijftig werd gebruik gemaakt van programma-bibliotheken, verzamelingen van computerprogramma’s (een programma is niets anders dan een rij instructies) die in een ander programma geplakt konden worden. Zo’n bibliotheek bestond b.v. uit programma’s voor het sorteren van getallen of het berekenen van gemiddelden of standaard deviaties. Een programma uit een bibliotheek moest op een nauwkeurig gespecificeerde manier worden aangeroepen door het ‘hoofdprogramma’ en leverde dan een actie (sorteren) of een waarde (het gemiddelde). De aangeroepen delen van de bibliotheek werden een echt onderdeel van het programma, waren in dezelfde taal geschreven als het hoofdprogramma dat het aanriep en konden alleen op dezelfde computer verwerkt worden. De bibliotheek-programma’s waren heilig. Je mocht er niet in wijzigen, want daar hadden andere gebruikers last van. Daarom werd een nieuw 22
paradigma ontwikkeld: object georiënteerd programmeren. Wat kort door de bocht geformuleerd komt het erop neer dat de programmeur een afgeleide van een bibliotheek-programma kon maken. Dit afgeleide programma had alle eigenschappen van het bibliotheek-programma, maar met allerlei toevoegingen die de programmeur zelf maakte. Er ontstond een soort hiërarchie, een ouder-kind-relatie. Het kind had alle eigenschappen van zijn ouders, plus nieuwe eigenschappen. De programmeeromgeving hielp de programmeur de bibliotheekprogramma’s te vinden en de hiërarchie bij te houden. Ook object georiënteerd programmeren leidt tot programma’s in één taal die op één machine uitgevoerd moeten worden. De volgende stap was dat het programma machine onafhankelijk werd. Door het aanbrengen van een ‘laag’ tussen het programma en de machine ontstaat een ‘virtuele’ machine. Een voorbeeld hiervan is Java: een machine onafhankelijke object georiënteerde programmeertaal. Een logische vervolgstap is een programma gebruik te laten maken van een bibliotheek of bibliotheek-programma’s die op een andere machine, in een andere ruimte, een ander gebouw, stad of land staat. Het hoofdprogramma moet dan over een netwerk het bibliotheek-programma aanroepen en het resultaat ook weer over het netwerk terugkrijgen. Het hoofdprogramma kan zelfs helemaal uitgekleed worden en is niet meer dan een dirigent die informatie van het ene bibliotheekprogramma (service) naar het andere stuurt. En dat alles taal- en machine-onafhankelijk. Zie daar de service georiënteerde architectuur, een logische volgende stap in de wereld van systeemontwikkeling.
(web) services en SOA De term ‘web services’ is verwarrend en wordt vaak ook nog op verschillende manieren gebruikt. Oorzaak van de verwarring is de term ‘service’ die een afwijkende betekenis heeft in de term ‘web service’. Met de term ‘web services’ wordt (over het algemeen) de technologie aangeduid waarmee verbindingen wordt gelegd, terwijl ‘services’ datgene aanduidt dat door ‘web services’ met elkaar verbonden wordt. De serviceleverancier verleent de dienst op verzoek van de serviceafnemer. De leverancier en de afnemer maken gebruik van webservicetechnologie om verzoek en resultaat te communiceren.
23
Deze communicatie moet voldoen aan een aantal standaarden om ook echt een web service te zijn, waarbij gebruik gemaakt wordt van XML, SOAP, WSDL en UDDI: eXtensible Markup Language (XML) is een standaard om de data in een bericht betekenis te geven (betreffen de data bijvoorbeeld een titel, een auteur of een uitgever), Simple Object Access Protocol (SOAP) wordt gebruikt om de data over te brengen en kan gezien worden als de enveloppe waarin de data verstuurd worden, Web Services Description Language (WSDL) is de standaard die de service beschrijft en aangeeft hoe met de service gecommuniceerd moet worden, De Universal Description, Discovery and Integration (UDDI) standaard is het ‘telefoonboek’ waarin services zich bekend maken aan de rest van de wereld. Communicatie op basis van web services heeft als voordeel dat deze sterk is gestandaardiseerd en daardoor wereldwijd en generiek is te gebruiken. Het nadeel is dat dit generieke gebruik betaald moet worden met heel veel overhead, veel meta-informatie die moet worden uitgewisseld. Dit verhoogt de kosten en remt de snelheid. De belangrijkste nadelen van web services op dit moment zijn dat een groot deel van de substandaarden nog niet zijn uitontwikkeld, en dat de snelheid van web services voor heel wat toepassingen onvoldoende is omdat XML tekstgebaseerd is en dus ‘breedsprakig’.
24
Directory
Di re
1
Service provider
ice rv Se
sc de
n ti o rip
u
g sin
SD W
L
3
2
ct or
Qu er yr es po ns es us ing SOAP messages
y
qu
er ie
s
W SD L
Service provider
4
XMML service request based on WSDL XML service response based on WSDL 5
•
A service provider describes its service using WSDL. This definition is published to a directory of services. The directory could use Universal Description, Discovery, and Integration (UDDI). Other forms of directories can also be used • A service consumer issues one or more queries to the directory to locate a service and determine how to communicate with that service • Part of the WSDL provided by the service provider is passed to the service consumer. This tells the service consumer what the requests and responses are for the service provider • The service consumer uses the WSDL to send a request to the service provider • The service provider provides the expected response to the service consumer Bron: http://www.service-architecture.com
Een service georiënteerde architectuur (SOA) is in essentie een architectuur opgebouwd uit services die met elkaar communiceren. De communicatie kan een eenvoudige uitwisseling van data zijn, maar het kan ook een complexe gecoördineerde actie van een groot aantal services inhouden. In dat geval is een aparte service (of zelfs een aantal aparte services) nodig die de communicatie regelt. Service georiënteerde architecturen zijn niet nieuw. De eerste SOA werd geïntroduceerd in 1996 en was gebaseerd op Distributed Component Object Model (DCOM). Vaak bieden deze ‘oude standaarden’ meer snelheid en robuustheid dan nu met web services realiseerbaar is. 25
Een SOA kan dus ook geïmplementeerd worden met een ander communicatie-regime dan dat van de web services (zoals DCOM, COBRA, Java Messaging Service). Indien de communicatie wel met web services wordt geregeld is er sprake van ‘een SOA op basis van web services’. De Enterprise Service Bus (ESB) wordt door velen gezien als een belangrijke component van een SOA. Het merkwaardige is dat er echter (nog) geen duidelijke definitie van een ESB bestaat. Leveranciers geven een eigen invulling aan de term ESB. Microsoft heeft zelfs helemaal geen ESB als separaat product in het assortiment, maar stelt dat de functies van een ESB in haar andere producten zijn ingebouwd. Grofweg kan ESB worden geduid als datgene dat de functionaliteit biedt om de communicatie goed te laten verlopen. Afhankelijk van de invulling van de leverancier worden daarbij zoal de volgende functies geleverd: routering van berichten (bijv. meerdere geadresseerden), vertaling van berichten (bijv. van EDI naar SOAP), bewerking van berichten (bijv. toevoegen of weghalen van onderdelen) en event-handling (bijv. logging en foutafhandeling).
26
Er zijn ook andere dan busstructuren om services te koppelen:
SOA/BPM/BPMS Business Process Modeling5 (BPM) staat voor de methoden en technieken om bedrijfsprocessen in kaart te brengen. Deze modellen worden in de bedrijfskunde met name gebruikt in het procesmanagement en in de analyse en ontwerp van informatiesystemen. Onder SOA/BPM wordt over het algemeen verstaan dat procesondersteunende informatiesystemen gebouwd worden door het bedrijfsproces te modelleren waarna vanuit deze modellen informatiesystemen worden gegenereerd. Deze systemen zijn opgebouwd uit services die via web services met elkaar communiceren. Voor het genereren van de informatiesystemen vanuit een procesbeschrijving kan daarbij gebruik gemaakt worden van Business Process Execution Language (BPEL). BPEL is een standaardtaal voor het orkestreren van web services tot business processen. De kracht van BPEL is dat eenmaal gedefinieerde business processen direct uitvoerbaar kunnen zijn in een SOA-gebaseerde infrastructuur. BPEL is ontstaan uit een initiatief van IBM, Microsoft, BEA Systems, SAP en Siebel en wordt nu onder auspiciën van het standaardeninstituut OASIS6 verder ontwikkeld. Hoe zou BPM moeten werken? Een bedrijfsproces kan worden gedefinieerd in een grafische ontwikkelomgeving door het simpelweg aanklikken van web services die op de onderliggende systemen in een organisatie al bestaan of ten behoeve van het betreffende bedrijfsproces zijn gebouwd. Door deze gebruiksvriendelijke methode kunnen business
5 6
http://nl.wikipedia.org/wiki/Business_Process_Modeling OASIS: Organization for the Advancement of Structured Information Standards http://www.oasis-open.org
27
analisten samen met IT-specialisten processen definiëren die vervolgens met een ‘druk op de knop’ kunnen worden geladen in een BPM Systeem (BPMS) en uitgevoerd in een op SOA gebaseerde infrastructuur. Althans in theorie. In de praktijk bestaan er echter diverse niet te onderschatten hindernissen. Zo is BPEL een taal voor het orkestreren van web services. Als de te gebruiken web services nog niet bestaan, moeten deze eerst ontwikkeld worden. Voorts is BPEL nog sterk in ontwikkeling. Verschillende leveranciers hebben eigen uitbreidingen op de standaard gerealiseerd die niet uitwisselbaar zijn (b.v. op het gebied van werkprocessen waarbij mensen betrokken zijn (zgn. human workflow). De grafische representatie voor het definiëren van een BPEL proces behoort overigens ook niet tot de standaard. Tenslotte heeft de taal nog slechts beperkte mogelijkheden voor meer complexe programmeerconstructies. SOA: niet nieuw, wel vernieuwend Samenvattend is de service georiënteerde architectuur een software oplossing bedoeld om een onderneming in staat te stellen een verscheidenheid aan processen te organiseren en uit te voeren. In een SOA zijn applicaties niet meer een massief geheel van functies en processen, maar applicaties worden samengesteld uit losse services. Een service is een enkelvoudige zelfstandige functie. De functie kan op verzoek uitgevoerd worden door een computer waarbij het niet uitmaakt waar die computer staat, van welk merk de computer is, welk besturingssysteem de computer gebruikt of in welke taal de functie is geprogrammeerd. Het revolutionaire van SOA is niet het concept zelf (dat is al oud), maar het feit dat het geïmplementeerd kan worden over het internet of internet-achtige netwerken, omdat de communicatie tussen services verloopt over internetprotocollen en in hoge mate gestandaardiseerd is. Ontwikkelaars bouwen applicaties door services met elkaar te laten communiceren of ‘diensten in een processtroom te orkestreren’. Deze processtroom kan dan zelf weer als een dienst worden gestructureerd. Het ontwerpen van zo’n service die een processtroom regelt, wordt Business Process Management genoemd; BPEL kan in deze vergelijking worden gezien als de taal die de dirigent gebruikt om met het orkest te communiceren. SOA-tools vereenvoudigen het bouwen van een service-orchestrationmodel dat lijkt op het maken van een flow chart voor een werkproces.
28
SOA: garantie voor nieuwe spaghetti?
Voordelen van SOA voor de business Algemeen worden de onderstaande drie voordelen van SOA voor de business onderkend. Agility Ten eerste het adaptief vermogen ofwel de ‘agility’ van de business. Dit is veruit het belangrijkste en dus doorslaggevende voordeel van SOA. Maar tegelijkertijd echter ook het moeilijkst te behalen voordeel. Nog maar weinig organisaties hebben dit niveau al kunnen bereiken, niet alleen omdat de techniek daarvoor nog te weinig is ontwikkeld, maar vooral ook omdat het realiseren van de architectuur in de organisatie zelf een grote uitdaging is zoals verderop duidelijk wordt. Hergebruik Het tweede voordeel is hergebruik van ontwikkelde software. Overigens is het beter om te spreken van gedeeld gebruik in plaats van hergebruik: services dienen zó te worden ontworpen dat ze vanuit meerdere 29
programma’s aangeroepen kunnen worden. Overigens vindt alleen hergebruik plaats als daar ook echt op gestuurd wordt. SOA vraagt om een sterke sturing (governance), veel meer dan de klassieke eilandautomatisering. Ketenautomatisering, organisatie overstijgende automatisering Een derde voordeel van de op web services gebaseerde SOA is de mogelijkheid om bedrijfsprocessen over de grenzen van organisaties heen te kunnen uitbreiden. Daardoor ontstaan bijvoorbeeld mogelijkheden om informatiesystemen van organisaties in een keten te koppelen. Daarnaast zullen web services naar verwachting een katalysator worden voor Application Service Provisioning, het ter beschikking stellen van applicaties via Internet. In plaats van hele applicaties kunnen voortaan delen van applicaties via ASP worden afgenomen en flexibel worden geïntegreerd in bestaande applicaties.
Voorwaarden voor succes Een service oriented architecture gecombineerd met business process management biedt de mogelijkheid om IT beter te laten aansluiten bij de behoeften van de business. Probleem is echter dat er nog weinig begrip is van SOA in het business domein. ‘SOA’ is nog vooral een IT begrip: veel organisaties zijn vooral gefocust op de techniek en pas daarna op de eisen en behoeften van de business. Aanschaf en implementatie van een enterprise service bus is voor veel IT managers veel aantrekkelijker dan het analyseren van de eisen die vanuit de business worden gesteld. David Linthicum7 stelt in zijn ‘12 Steps to Implementing a Service Oriented Architecture’ dat bij het implementeren van een SOA, de technologie pas bij stap 10 komt, onder meer na een grondige analyse van processen, van de gehanteerde ‘applicatie-semantiek’ (de meta-data) en van al bestaande services. Als er dan toch besloten wordt om SOA/BPM te omarmen is het nuttig om een aantal van de onderstaande voorwaarden te onderkennen en te realiseren. Daarbij kan men gebruik maken van ervaringen die elders zijn opgedaan. Programmeren met behulp van bibliotheken was een grote stap voorwaarts. Ook object oriëntatie heeft een grote invloed gehad. Beide zijn
7
12 Steps to Implementing a Service Oriented Architecture, door David S. Linthicum http://www.integrationconsortium.org/docs/12_steps_to_SOA.pdf
30
nu zo gewoon dat je er niemand meer over hoort. Zal service oriëntatie die zelfde weg volgen? Dat is nog maar de vraag. Organisaties zullen bepaalde randvoorwaarden moeten invullen. De belangrijkste daarvan zijn: De services worden goed beheerd en er ontstaat geen wildgroei (binnen een organisatie of binnen een keten). Hiervoor moeten handzame hulpmiddelen worden ingezet om te voorkomen dat er een wildgroei aan services ontstaat, dat voor iedere nieuwe behoefte een nieuwe service wordt gemaakt, ook als er al bestaande services zijn die (veel van) de benodigde functionaliteit bieden. De services hebben de juiste granulariteit, dat wil zeggen niet te veel en ook niet te weinig functies (het probleem van granulariteit deed zich ook voor bij het ontwerp van bibliotheken en objecten). Als de services ‘te klein’ zijn resulteert dat in een woud aan services die moeilijk te beheren zijn (zie vorige punt) en veel ‘orkestratie’ vereisen (in feite worden applicaties dan gedeeltelijk nagebouwd in de orkestratie); bij te ‘grote’ services is de toegevoegde waarde van SOA in feite gering. De communicatie tussen services is volledig gestandaardiseerd. De communicatie tussen services wordt gestandaardiseerd door de afspraken en protocollen die web services gebruiken. Het vervelende is dat er zoveel standaarden zijn, mede omdat leveranciers of conglomeraties van leveranciers in de strijd om het marktaandeel hun eigen standaarden verzinnen. Toch lijken XML, SOAP, WSDL en UDDI redelijk uitgekristalliseerd en steunen grote aanbieders deze standaarden. Een SOA kan met nieuw ontwikkelde services, maar ook met oude toepassingen (legacy systemen) en combinaties van oud en nieuw worden gerealiseerd. Er zijn inmiddels diverse technieken om oude systemen te laten communiceren op basis van de webservice-standaarden. Applicaties oud en nieuw kunnen via een enterprise service bus (ESB) met elkaar worden gekoppeld tot een organisatiebrede of zelfs organisatieoverstijgende integrale infrastructuur.
Conclusies Alhoewel het SOA-concept met verschillende technologieën kan worden geïmplementeerd, zijn het web services en bijbehorende substandaarden die SOA in de afgelopen periode breed in de belangstelling hebben geplaatst. De voornaamste toegevoegde waarde van web services is vooral dat heterogene informatiesystemen zowel intern-, als extern, via internet gekoppeld kunnen worden. Alleen al hierdoor is SOA voor de 31
business van grote betekenis ondanks het feit dat de techniek rond web services en de systemen nog volop in ontwikkeling zijn. Er zal pas sprake zijn van een werkelijke doorbraak van SOA indien ‘architectuur’ veel meer dan nu het geval is, een business aangelegenheid wordt, met techniek als één van de aandachtsgebieden. De combinatie van SOA en BPM biedt daarbij zeker op termijn veel perspectief.
32
deel B
Organisatie (inkoop, verandermanagement)
33
34
Hoofdstuk 3 inkoop Het succes of falen van projecten op het gebied van bedrijfsvoeringsystemen wordt vaak al heel vroeg in het proces bepaald: bij de definitie van het project, bij het bepalen van de behoefte, bij de inkoop van diensten van leveranciers. Stappen die vaak routineus, zonder speciale managementaandacht worden doorlopen, blijken achteraf cruciaal voor het resultaat. In het inkoopproces zijn vaak veel meer vrijheidsgraden, veel meer mogelijkheden dan menigeen denkt, en moeten belangrijke managementbeslissingen worden genomen. In dit hoofdstuk worden verschillende aspecten hiervan nader toegelicht.
3.1 inkoop bedrijfsvoeringsystemen te complex voor inkoopafdeling Joop Schuilenburg8 De vervanging van bedrijfsvoeringsystemen is een complexe en kostbare aangelegenheid. Dergelijke vervangingen worden in de regel door een multidisciplinair team projectmatig uitgevoerd en is er ook op inkoopgebied veel kennis en ervaring nodig. Vaak wordt hier te lichtzinnig over gedacht en ontbreekt bij inkoopafdelingen de noodzakelijk kennis en ervaring op dit specifieke terrein. Het inkopen van bedrijfsvoeringsystemen is echter specialistisch werk, en vaak te complex voor de meeste inkoopafdelingen. In het proces van inkoop moeten op vier verschillende gebieden duidelijke en bewuste keuzes worden gemaakt die van cruciaal belang zijn voor het succes van het gehele project: de pakketkeuze, het al dan niet separaat aanbesteden van pakket en implementatiepartner, de methode van Europees aanbesteden, en de scope van het onderhoud.
Pakketkeuze In eerste instantie moet er een keuze worden gemaakt voor een softwarepakket. De markt biedt geïntegreerde oplossingen. Grote fabrikanten bieden zogenaamde ‘software suites’ aan, bestaande uit modules die
8
Joop Schuilenburg was tot eind 2007 werkzaam bij M&I/Partners en heeft toen Emtio, een zusterbedrijf van M&I/Partners, opgericht (zie www.emtio.nl). Dit hoofdstuk is eerder gepubliceerd in de Automatiseringsgids van 17 november 2006
35
meerdere functionaliteiten in het bedrijfsvoeringproces kunnen ondersteunen, zoals bijvoorbeeld Financiën, Inkoop en HRM. Daarnaast worden zogenaamde ‘best of breed’ oplossingen aangeboden. Dit zijn oplossingen die zijn gespecialiseerd in één functionaliteit, zoals bijvoorbeeld Inkoop. ‘Best of breed’ oplossingen veronderstellen beter te zijn toegespitst op de functionaliteit waarvoor ze zijn ontworpen, terwijl geïntegreerde oplossingen over het algemeen zonder koppeling (interface) gegevens met andere functionaliteiten uit het bedrijfsproces kunnen uitwisselen. Er lijkt dan een keuze te moeten worden gemaakt tussen een probleemloze koppeling of optimale functionaliteit. Deze keuze is zeer moeilijk te maken, te meer omdat enerzijds ‘best of breed’ oplossingen tegenwoordig vaak zijn voorzien van standaardkoppelingen ten behoeve van andere systemen, waarvan het voor de hand ligt dat ze daarmee samen moeten werken. Anderzijds hebben modules van geïntegreerde oplossingen tegenwoordig voldoende diepgang om alle gewenste functionaliteit te kunnen invullen. Nog lastiger wordt het als een tussenvorm wordt aangeboden. Dit zijn de gevallen waarin softwarefabrikanten andere partijen overnemen om daarmee een geïntegreerde oplossing te kunnen aanbieden. Een voorbeeld van deze laatste is de overname van Peoplesoft (dat kort daarvoor JD Edwards had overgenomen) door Oracle. De afweging is complex en van strategische aard. Alle varianten komen voor en er bestaan aan de vraagzijde voor elke variant voor– en tegenstanders. Tenslotte bestaat er ook nog de variant van een maatwerkoplossing, hoewel deze de laatste jaren steeds minder wordt gekozen. Beslispunt Overweging
Geïntegreerde oplossing
Best of Breed
- aanwezigheid van aanpalende systemen
- aankoop van één soort functionaliteit
- aanpalende systemen worden in de nabije toekomst ook vervangen
- weinig koppelingen of standaardkoppelingen
- veel koppelingen
Pakketkeuze en implementatie al of niet gecombineerd Als opdrachtgevers de hiervoor beschreven strategische keuze min of meer overwogen hebben gemaakt, worden ze direct voor een volgende strategische afweging geplaatst. Het bedrijfsvoeringsysteem moet namelijk worden geïmplementeerd in de organisatie (waarbij het interne 36
veranderingsproces hier buiten beschouwing wordt gelaten). Wordt er nu separaat gekozen voor een pakketleverancier én voor een implementatiepartij, waarbij er dus twee inkoopprocessen worden uitgevoerd? Of wordt gekozen voor één marktpartij die zowel het pakket levert als de implementatie verzorgt en wordt er dus één inkoopproces uitgevoerd? Beide keuzes hebben voor- en nadelen. De eerste variant heeft als voordeel dat er in beide situaties de meest optimale keuze kan worden gemaakt, omdat er zowel voor de pakketkeuze als voor de keuze van de implementatiepartij concurrentiestelling mogelijk is. Een nadeel is dat optimale concurrentiestelling alleen mogelijk is indien de twee inkoopprocessen ná elkaar worden uitgevoerd en dat kost tijd. Indien deze variant wordt overwogen moet men het inkoopproces daarom zorgvuldig plannen. Een tweede nadeel is dat er een risico ontstaat dat partijen elkaar de schuld van missers bij de implementatie gaan geven (het zogenaamde ‘finger pointen’). Beide nadelen zijn echter met maatregelen te ondervangen. De tweede variant heeft als voordeel dat één partij in zijn totaliteit verantwoordelijk is voor zowel pakketfunctionaliteit als implementatie. Een ander voordeel is dat er met één inkoopprocedure kan worden volstaan. De nadelen zijn echter groot. In de regel zal namelijk de implementatiepartner de ‘lead’ nemen bij het offreren en het pakket als het ware ‘meenemen’. Een opdrachtgever heeft daarmee veel minder invloed op de pakketkeuze. De implementatiepartner kiest zelf een oplossing, die weliswaar aan een door opdrachtgever opgesteld programma van eisen zal voldoen, maar die over het algemeen vooral vanuit commercieel oogpunt voor hemzelf de meest voordelige is. Zo kunnen er financiële afspraken tussen pakketfabrikanten en implementatiepartijen bestaan die de pakketkeuze van de implementatiepartner bepalen. Dit kan betekenen dat niet per se de functioneel meest optimale oplossing wordt aangeboden en dan wordt een opdrachtgever niet optimaal bediend. Ook deze afweging is complex en strategisch van aard. Om de keuze te ondersteunen is inzicht in de markt van bedrijfsvoeringsystemen onontbeerlijk. Zo kan er niet altijd een gescheiden keuze worden gemaakt omdat bepaalde fabrikanten alleen zelf de implementatie van hun eigen pakket verzorgen.
37
Beslispunt
Overweging
Eén partij die zowel pakket levert als implementatie verzorgt - Men is bekend met de bestaande combinaties pakketleverancier / implementatiepartner - Men wil de resultaatverantwoordelijkheid in één hand leggen
Eén partij voor pakketleverantie en één partij voor implementatie - er bestaan meerdere implementatiepartijen voor een bepaald pakket - er bestaan veel pakketten die potentieel kunnen worden aangeboden - de implementatiepartners hebben ook een vorm van certificering of een anderszins, voor wat betreft toegang tot kennis, een geborgde relatie met de pakketfabrikant - het risico van finger pointing kan worden gemanaged - de keuze van het pakket zelf is belangrijk je wilt veel invloed hierop uitoefenen - de (project)organisatie is voldoende ingericht om twee marktpartijen te managen
Methode van Europees aanbesteden Het inkoopproces moet veelal via een Europese aanbesteding worden uitgevoerd. Dit is op zich een tactisch proces maar de implicaties bij een onjuiste keuze zijn van strategische aard. Stel dat er wordt besloten om de pakketkeuze en de implementatie daarvan in één aanbesteding op de markt te zetten. Als er nu voor een ‘openbare procedure’ wordt gekozen dan loopt een opdrachtgever het risico dat hij nauwelijks of geen keuze zal krijgen voor pakketten. Dit heeft alles te maken met het hiervoor vermelde gegeven dat implementatiepartners vaak de leiding nemen bij het offreren. Theoretisch is het zelfs mogelijk dat alle implementatiepartijen hetzelfde pakket aanbieden. De keuze van een ‘niet openbare procedure’ kan echter hetzelfde effect hebben. Dit hangt samen met een juridische eigenschap van een ‘niet openbare procedure’. Er wordt namelijk eerst een voorselectie van aanbieders gemaakt, mede op basis van hun kennis en ervaring. Het probleem is nu dat zij weliswaar met het opnoemen van allerlei door hen geïmplementeerde pakketten hun vaardigheden aangeven, maar 38
niet verplicht zijn om ook daadwerkelijk het genoemde pakket aan te bieden in de tweede fase. Een hierbij veel gebruikt en te rechtvaardigen argument is immers: “Hoe kunt u mij verplichten nu al het pakket te noemen dat ik in de tweede fase zal aanbieden als ik de keuze uit meerdere oplossingen heb én uw bestek nog niet heb gezien?” Ook hier geldt dus: ken uw markt!
Beslispunt Overweging
Openbaar aanbesteden
Niet openbaar aanbesteden
- de pakketkeuze is van groot belang
- de implementatie is belangrijker dan de pakketkeuze
- er bestaan veel pakketten die potentieel kunnen worden aangeboden
- Wil men de kwaliteit en ervaring van de aanbieders van te voren onderzoeken alvorens offerte te vragen
Scope van het onderhoud Een opdrachtgever moet zich goed realiseren waar hij onderhoud op vraagt en krijgt. Er zijn twee aspecten: het pakket én de implementatie. Het is noodzakelijk om onderhoud op het pakket te kopen (zie ook de volgende paragraaf). Men betaalt in de regel een jaarlijks percentage van de prijs (let op: koopprijs of lijstprijs!). In ruil daarvoor krijgt men het recht op nieuwe versies, patches, etc, maar ook toegang tot een service desk. Maar, hoe om te gaan met de opgeleverde implementatiewerkzaamheden? Immers, zowel bij een gecombineerde als bij een gescheiden inkoop van pakket en implementatiedienst zal de implementatiepartner in de regel verantwoordelijk zijn voor een geslaagde oplevering van zijn werkzaamheden. Maar houdt het daar dan mee op of is het wenselijk dat ook in de periode daarna deze verantwoordelijkheid blijft bestaan? Als dat laatste de bedoeling is zal er een vorm van onderhoud moeten worden geregeld (in de regel door middel van een service level agreement) dat bovendien ingaat na afloop van een overeengekomen garantieperiode. Het aspect van onderhoud wordt nog al eens ‘vergeten’ in offerteaanvragen. Onderhoud dient dan ook een vast punt op de checklist te zijn van een opdrachtgever. Alle vier hier boven beschreven keuzes zijn dus vaak strategisch van aard omdat ze een grote impact hebben op de kwaliteit van de bedrijfsvoering. Deze keuzes dienen dan ook op hoger managementniveau te worden gemaakt en kunnen niet zonder meer worden overgelaten 39
aan inkoopafdelingen. Inkoopafdelingen moeten echter wel in staat zijn om met hun interne opdrachtgevers mee te denken, aan te geven waar keuzes moeten worden gemaakt en hun kennis van de markt inbrengen. Veel inkoopafdelingen zijn hier echter helaas niet toe in staat en beperken zich ten onrechte te veel tot het puur procesmatig uitvoeren van het aanbestedingsproces. Met als gevolg dat bovenstaande strategische aspecten niet, of alleen impliciet, aan de orde komen. Beslispunt Overweging
Onderhoud alleen op pakket
Onderhoud op geïmplementeerd resultaat
- het maatwerk wordt standaard onderhouden
- de implementatie wordt als complex ervaren
- het resultaat van de implementatie valt automatisch onder het onderhoud
- er is veel maatwerk nodig
- er is sprake van standaardkoppelingen - er worden niet veel wijzigingen in het systeem of hardware (bijv. ander OS) voorzien
40
- er moeten veel releases per jaar worden geïmplementeerd - er is sprake van een sterke groei in de belasting van het systeem
3.2
Softwareaanbieders rekenen te veel voor onderhoud
Joop Schuilenburg9 Aanbieders van software zijn sinds jaar en dag gewend onderhoud op hun producten te leveren en daar ook een vergoeding aan de gebruikers voor te rekenen. We zien deze vergoedingen de laatste jaren sterk stijgen. Tot voor enkele jaren was het zeer gebruikelijk om op jaarbasis percentages van 15 tot 18% te betalen, soms van de bruto prijslijst, maar meestal van de netto aankoopwaarde. De laatste jaren zien we echter steeds vaker percentages die tussen de 20 en 25% liggen, veelal van de bruto lijstprijs. Is daar een logische verklaring voor en mogen aanbieders eigenlijk wel geld voor onderhoud rekenen? Of verstoppen zij hun garantieverplichting in allerlei andere vormen van betaalde diensten zodat een gebruiker niet meer ziet dat hij ook voor iets betaalt waar hij kosteloos recht op heeft?
Onderhoudsdiensten Op basis van onderhoudsregelingen leveren de aanbieders meestal een aantal verschillende diensten aan de gebruikers. Door het betalen van een onderhoudsvergoeding hebben gebruikers meestal recht op de levering van versies waarin technische verbeteringen zijn doorgevoerd of zogenaamde bugs zijn verholpen. Dit zijn over het algemeen versies die aan iedere betalende gebruiker van de software worden verstrekt, dus los van de vraag of de individuele afnemer in kwestie last had van gebreken aan de software of niet. Gebruikers hebben door het betalen van een onderhoudsvergoeding ook recht op individuele hulp bij het verhelpen van gebreken aan de software. In zijn algemeenheid kunnen zij daartoe bij een helpdesk terecht. Een aantal aanbieders levert tegen betaling van een onderhoudsvergoeding ook zogenaamde nieuwe releases of versies van software (ook wel: upgrades) uit. Dit zijn versies waarbij de nadruk ligt op nieuwe functionaliteit of aanpassing aan nieuwe wetgeving en minder op het verhelpen van gebreken in de software (al wordt dit laatste uiteraard wel gelijk meegenomen).
9
dit hoofdstuk is eerder gepubliceerd in de Automatiseringsgids in juni 2006
41
Wettelijke kaders In Nederland zijn in ieder geval twee wettelijke regelingen van toepassing op de levering van software. Ten eerste de Auteurswet 1912 die, in tegenstelling tot wat zijn leeftijd doet vermoeden, uitdrukkelijk aandacht besteed aan het toegestane gebruik van software. Ten tweede zijn de algemene bepalingen van boek 7 van het Burgerlijk Wetboek ter zake van koop en ruil van toepassing. Daarbij gaat het om het zogenaamde ‘conformiteitsvereiste’ dat in artikel 17 van boek 7 is verwoord: ‘de afgeleverde zaak moet aan de overeenkomst beantwoorden’. Aangezien de Auteurswet 1912 hier ten opzichte van software geen uitzondering maakt, kan worden geconcludeerd dat geleverde software ook aan de overeenkomst dient te beantwoorden. Dit impliceert dat een gebruiker ook zonder betaling van een onderhoudsvergoeding recht heeft op herstel van gebreken aan de software. Een gebruiker heeft dus recht op garantie!
Vergoeding Waarom worden er dan toch vergoedingen gerekend door aanbieders? Zij willen een vergoeding voor de hoge kosten die zij moeten maken voor ontwikkeling en herstel van producten die nauwelijks geheel foutloos lijken te kúnnen werken. We zouden kunnen zeggen dat het herstel van gebreken, of dit nu door het produceren van individuele patches of in zijn algemeenheid door de levering van verbeterde versies geschiedt, kosteloos dient te geschieden. Er zijn aanbieders op de markt, waaronder Microsoft, die inderdaad kosteloos verbeterde versies beschikbaar stellen. Helaas behoort dit voorbeeld tot de uitzonderingen. De meeste aanbieders bundelen hun garantieverplichtingen met andere vormen van dienstverlening waardoor een gebruiker niet meer kan zien waar hij nu precies voor betaalt. In feite is hier sprake van een ongeoorloofde koppelverkoop. Aanbieders als Oracle rekenen bijvoorbeeld maar liefst 20-22% voor onderhoud per jaar. Aangezien Oracle tegen betaling van deze vergoeding ook nieuwe versies van hun producten levert zou betaling van enige kosten verdedigbaar kunnen zijn, maar lang niet iedereen heeft behoefte aan een nieuwe versie. Een gebruiker zou kunnen besluiten dat hij geen onderhoud aanschaft. Als hij dat doet heeft hij echter contractueel geen recht meer op reparatie van zijn gebreken. Dat laatste is dus precies iets wat strijdig kan zijn met de wetgeving.
42
Een ander argument dat aanbieders stellen als grondslag voor hun recht betaling te vragen voor het herstel van gebreken is dat volgens hen gebreken binnen een bepaalde hersteltijd worden verholpen, terwijl je op basis van de wet geen aanspraak kan doen op een bepaalde hersteltijd. De wet gaat namelijk uit van het stellen van een redelijke termijn en die kan van geval tot geval variëren, afhankelijk van de aangetroffen problematiek. Sterker nog, net als bij een consument zou een aanbieder kunnen zeggen: ‘lever je product maar in, dan zal ik het binnen een redelijke termijn repareren’, hetgeen bij geïmplementeerde software natuurlijk niet goed voorstelbaar is. De aanbieders bieden een min of meer gegarandeerde responstijd in contracten en hanteren dus het uitgangspunt dat een gebrek altijd binnen een vooraf overeengekomen termijn wordt verholpen. De aanbieders hebben geen gelijk. Ten eerste bieden ze over het algemeen geen enkele garantie in hun voorwaarden dat er binnen een bepaalde periode herstel zal plaatsvinden en nemen ze daarmee een door hen zelf vastgestelde en redelijk geachte termijn in acht. Ten tweede dienen aanbieders ‘geëigende maatregelen’ voor herstel te treffen, zodat ze een reparatiewijze moeten aanbieden die voor een gebruiker de minste verstoring oplevert. De gebruiker hoeft zijn software dus niet ter reparatie in te leveren (wel ter reparatie aan te bieden).
43
Aanbieders zijn niet verplicht een helpdesk in te richten, is dat dan een argument om geld te vragen voor herstel van gebreken? Ook het antwoord op deze vraag is ontkennend. Het inrichten van een helpdesk is voor aanbieders de meest efficiënte en effectieve methode om de vele meldingen van storingen in ontvangst te nemen. De conclusie kan dan ook niet anders luiden dan dat aanbieders van software ten onrechte geld vragen voor het repareren van gebreken en dat zij dit aspect soms ‘verstoppen’ in de betaling van jaarlijkse lumpsumbedragen voor onderhoudsdiensten waarin ook andere, meer verklaarbare diensten als het leveren van nieuwe versies, zijn opgenomen (althans, voor zover je die zou willen hebben). In de meeste gevallen menen de aanbieders gewoon het recht te hebben om geld voor herstel van gebreken te vragen – en dat hebben ze niet.
Gebreken In software contracten komt vaak de term ‘gebreken’ voor. Vanuit juridische optiek is een product ‘gebrekkig’ geleverd indien dit product niet aan de overeenkomst beantwoord. Dit houdt vervolgens in dat gebreken ook een functionele achtergrond kunnen hebben. Immers, grote software-implementaties worden vaak vooraf gegaan door een offerteaanvraag. Deze offerteaanvraag verwoordt een functionele en/of technische behoeftestelling. Met andere woorden, een aanbieder biedt zijn softwareproduct aan als oplossing voor deze behoeftestelling. Je zou nu kunnen redeneren dat er gedurende de looptijd van de overeenkomst een garantie door deze aanbieder moet worden gegeven op juiste werking van zijn softwareproduct. In de praktijk stellen vooral de accountmanagers van internationals dat zij op lokaal niveau nu eenmaal geen invloed op policies van hun concerndirecties kunnen uitoefenen. Dit moge zo zijn, maar dat is nog geen reden om je als gebruiker dan maar bij neer te leggen. Vooral het instrument van Europese aanbestedingen kan een belangrijk middel zijn om dit gedrag van grote aanbieders om te buigen. In de regel hebben we bij Europese aanbestedingen namelijk met grotere opdrachtgevers te maken die op lokaal niveau in ieder geval een vuist kunnen maken. Aanbestedende diensten voegen in toenemende mate dwingend voorgeschreven contractteksten toe, waardoor grote softwareaanbieders zich wel moeten aanpassen indien zij geen orders willen verliezen. Hierbij moet echter wel worden gewaakt dat de eenzijdigheid van contracten niet de andere kant op slaat.
44
De Auteurswet 1912 kent een bijzondere term die enigszins is gelieerd aan het beginsel dat een product moet beantwoorden aan de overeenkomst. Deze term luidt: ‘beoogd gebruik’. Dit begrip is eigenlijk uitsluitend relevant bij een functionele behoeftestelling. Als een consument in de winkel een softwarepakket koopt zonder daarbij in de richting van de winkelier aan te geven voor welk doel het product wordt gebruikt zal het beoogde gebruik zoals dat is beschreven in de softwaredocumentatie leidend zijn bij de uitleg. Dit betekent dat een consument pech heeft gehad als hij tot de conclusie komt dat het product niet voldoet aan zijn wensen. Dit eenvoudige voorbeeld geldt echter ook voor bedrijven en overheidsinstellingen die software aankopen. Maar, ook voor hen geldt dat zij wel garantieaanspraken hebben indien zij een functionele behoeftestelling hebben gedaan. Deze functionele behoeftestelling vormt dan het ‘beoogde gebruik’. Het is daarom van belang zo veel mogelijk de context van een aankoop aan een aanbieder bekend te maken.
45
3.3
Richtlijn maakt dialoog bij aanbestedingen mogelijk
Joop Schuilenburg10 Per 1 december 2005 is het ‘Besluit aanbestedingsregels voor overheidsopdrachten’ in werking getreden. Vanaf deze datum worden er naast de tot dan toe gehanteerde procedures nieuwe aanbestedingsprocedures gehanteerd. Basis voor het Besluit is de EG-Richtlijn 2004/18/EG van 31 maart 2004. Met de implementatie van de Richtlijn in de Nederlandse wetgeving zijn de Richtlijnen voor Leveringen, Diensten en Werken geïntegreerd in één regeling. De nieuwe Richtlijn biedt een paar mogelijkheden die vooral op het terrein van ICT-opdrachten zeer waardevol kunnen zijn
Starre procedures Wie kent niet de gebruikelijk gehanteerde ‘openbare’ en ‘niet openbare’ procedures? Deze procedures worden zowel door ICT-dienstverleners als opdrachtgevers als star ervaren en beide partijen worstelen met de toepassing ervan. Het komt vaak voor dat onderhandelingen met door de aanbestedende diensten zelf gekozen dienstverleners plaatsvinden. Dit komt doordat er vaak vanuit bestaande overeenkomsten wordt onderhandeld. Het komt ook voor dat er op basis van de in het verleden aangekochte producten opgebouwde dienstverlening en beheeromgevingen wordt onderhandeld met allerlei leveranciers. Men past dus al of niet terecht uitzonderingsbepalingen uit de richtlijnen toe om rechtstreeks met een bepaalde dienstverleners in gesprek te kunnen raken. Het is begrijpelijk, maar het neemt niet weg dat er vanuit juridisch perspectief vaak op of over de rand wordt gehandeld. Immers, bij het toepassen van een aanbestedingsprocedure mogen dienstverleners niet onderhands worden uitgenodigd tot het voeren van ‘overleg’, maar melden ze zichzelf aan op basis van een aankondiging. Bij outsourcingsopdrachten is de problematiek vergelijkbaar. Bij dit soort trajecten is veelvuldig overleg met de zakelijke ICT-dienstverlener eigenlijk een noodzaak om te komen tot een goede business case. Beide partijen ervaren het moeten handelen overeenkomstig openbare en niet openbare procedures als onwenselijk omdat er nauwe-
10
dit hoofdstuk is eerder gepubliceerd in de Automatiseringsgids van 28 oktober 2005
46
lijks of geen overleg mag worden gevoerd in het voortraject van een aanbesteding.
Nieuwe mogelijkheden De nieuwe aanbestedingsrichtlijn biedt nieuwe en meer flexibiliteit voor zowel opdrachtgevers als ICT-dienstverleners. Een deel van de aanbestedingsproblematiek kan hiermee worden opgelost. Er worden in de nieuwe Richtlijn mogelijkheden beschreven om zogenaamde ‘Dynamische Aankoopsystemen’ in het leven te roepen en het is mogelijk om een zogenaamde ‘concurrentiegerichte dialoog’ met potentiële aanbieders te houden. De Richtlijn geeft ook meer duidelijkheid over het begrip raamovereenkomsten. Wat houden deze mogelijkheden nu in en wat kunnen zij voor de ICT-aanbieders én opdrachtgevers betekenen? Dynamische Aankoopsystemen Nieuw is de mogelijkheid tot het gebruik van ‘Dnamische Aankoopsystemen. Helaas werkt het niet zoals bedoeld en is het door een ‘ontwerpfout’ niet bijzonder geschikt voor de inhuur van ICT-personeel – iets waar het toch speciaal voor was bedoeld (zie volgende paragraaf). Concurrentiegerichte dialoog Ook nieuw is het gebruik van de zogenaamde ‘concurrentiegerichte dialoog’. Dit is een procedure die slechts bij uitzondering mag worden toegepast, maar juist op het terrein van ICT zal een beroep op deze uitzondering vaak aan de orde zijn. Waar het om gaat is dat opdrachtgevers van complexe ICT-opdrachten vaak niet weten hoe ze hun aankoopbehoefte op papier moeten zetten. Vaak worden externe adviseurs ingehuurd om daarmee te helpen. De concurrentiegerichte dialoog biedt een mogelijkheid om potentiële aanbieders in te schakelen voor het preciseren van de behoeftestelling. Vervolgens wordt aan dezelfde aanbieders een offerte gevraagd. De keuze van de aanbieders kan op basis van een selectieleidraad plaatsvinden, maar in ieder geval op basis van een objectieve en transparante kwalificatie en ná een openbare aankondiging. Er dient ten opzichte van elke aanbieder vertrouwelijkheid in acht te worden genomen en daarom mag de verstrekte informatie niet zonder meer aan concurrenten worden getoond. Ook mag het uiteindelijk programma van eisen dat als resultaat van de besprekingen zal ontstaan niet worden toegeschreven naar één van de partijen. Wel is het mogelijk het overleg in een aantal fasen te laten plaatsvinden en zodoende het aantal aanbieders terug te dringen. Dit kan bijvoorbeeld een logisch gevolg zijn 47
van het groeien van bepaalde specificaties waar sommige dienstverleners niet (meer) aan kunnen voldoen. Er geldt geen minimumaantal, wel is het zo dat er in beginsel voldoende concurrentie moet zijn. De concurrentiegerichte dialoog lijkt daarmee een uitstekend middel voor zowel opdrachtgevers als ICT-aanbieders om vraag en aanbod goed op elkaar af te stemmen alvorens een offerte te vragen. Opdrachtgevers én ICT-aanbieders moeten er daarbij wel voor waken dat de dialoog niet een verkapte vorm van advies oplevert dat eigenlijk betaald moet worden (tenzij men natuurlijk besluit hiervoor te betalen). Verder moeten opdrachtgevers er voor waken dat zij een goede balans tussen onafhankelijkheid en leveranciersbelangen in stand houden. Daarbij kan de hulp van een onafhankelijke adviseur nuttig zijn. De concurrentiegerichte dialoog lijkt vooral goed toepasbaar bij complexe ICT-trajecten. Te denken valt aan de productkeuze en inrichting van bedrijfsvoeringsystemen zoals HRM-systemen, financiële systemen, logistieke systemen, etc., maar ook op het terrein van outsourcing. Daarbij is het van belang om in het voortraject expliciet de doelstellingen te bepalen (b.v. het reduceren van kosten, flexibiliseren van dienstverlening, focus op core business, etc.). En om van tevoren hefboomeffecten als kwaliteitsverbetering in de organisatie en het versterken van interne concurrentie in te schatten. De doelstellingen leiden 48
dan tot een business case die mede met ICT-dienstverleners tot stand is gekomen en daarmee ook reëel kan zijn. Dat vormt ook een goede basis voor het latere contractmanagement.
Raamovereenkomsten Voor het eerst wordt ook het begrip raamovereenkomsten uitdrukkelijk geregeld. Het begrip raamovereenkomst is uiteraard niet nieuw in aanbestedingsland. Raamovereenkomsten mogen met meerdere ICTaanbieders tegelijk worden aangegaan. Als dit gebeurt dienen dat er minimaal drie te zijn (mits er voldoende aanbieders geschikt zijn). Voor het gunnen van concrete opdrachten moeten de aanbestedingsstukken voldoende duidelijkheid geven. Zo kan het zijn dat de raamovereenkomsten complementair ten opzichte van elkaar zijn en dan mogen concrete opdrachten zonder nadere concurrentiestelling worden verstrekt. Als de raamovereenkomsten echter onderling concurrerend zijn dan dient er voor concrete opdrachten steeds een offerteronde plaats te vinden tussen de raamcontractanten Vooral bij raamovereenkomsten voor ICT-dienstverlening lijkt het gebruik van meerdere overeenkomsten naast elkaar voor de hand te liggen. Al liggen uurtarieven vaak contractueel vast, zij het met een bepaalde bandbreedte, voor opdrachten waarbij een bepaald resultaat moet worden opgeleverd is het vooral het aantal uren en de inschatting van het benodigde kwaliteitsniveau door de ICT-dienstverlener die uiteindelijk bepalend kan zijn voor het verstrekken van de opdracht. Bij reguliere inhuur van functieprofielen zal vaak de op enig moment beschikbare kwaliteit de doorslag geven. Het gebruik van meerdere raamovereenkomsten naast elkaar lijkt eenvoudiger toepasbaar bij ICTdienstverlening dan bij levering van apparatuur.
49
3.4
Dynamisch aankoopsysteem werkt niet zoals bedoeld
Joop Schuilenburg11 De Europese wetgever heeft de afgelopen jaren verwoedde pogingen ondernomen om het starre stelsel van aanbestedingsrichtlijnen te moderniseren. Daarbij is getracht een instrument te ontwikkelen voor ‘gangbare aankopen, met algemeen op de markt beschikbare kenmerken’. Dit instrument is bekend onder de naam ‘Dynamisch Aankoopsysteem’ en zou vooral geschikt moeten zijn als alternatief voor het aloude systeem van raamovereenkomsten. De Europese wetgever is er echter door onvoldoende gevoel voor de dagelijkse praktijk van het inkoopproces wederom niet in geslaagd een op zich uitstekend aanbestedingsinstrument tot een goed werkbare procedure ontwikkelen. Een gemiste kans.
die raamovereenkomsten... Het gebruik van raamovereenkomsten is binnen de centrale en lagere overheid wijdverbreid. Vooral voor de inhuur van externe expertise op het terrein van ICT. De raamovereenkomsten komen in de regel tot stand via Europese aanbestedingen en hebben een looptijd van maximaal vier jaar. Een nadeel is dat ze erg star zijn. Dat komt doordat eenmalig een behoeftestelling wordt geformuleerd die vooral uit functieprofielen bestaat. Daarnaast is het verplicht een kwantitatieve en kwalitatieve beschrijving van de ICT-projecten of –omgevingen te geven die aanbestedende diensten op dat moment voorzien. De beschreven functieprofielen dienen dan op de genoemde projecten en omgevingen te worden ingezet. Het is niet goed denkbaar dat aanbestedende diensten daadwerkelijk vier jaar lang gebruik kunnen maken van dezelfde behoeftestelling en we zien de laatste jaren dan ook een trend waarbij de looptijd van raamovereenkomsten wordt teruggebracht naar drie en soms zelfs naar twee jaar. Aanbestedende diensten zijn echter, om te voorkomen dat er voor inhuur steeds weer een omvangrijk aanbestedingsproject moet worden opgestart, geneigd zo veel mogelijk opdrachten via deze raamovereenkomsten te gunnen. Omdat de aard van en de hoeveelheid ICT-omgevingen en –projecten nauwelijks voor twee en zeker niet voor vier jaar kan worden overzien (nog los van het gegeven
11
dit hoofdstuk is eerder gepubliceerd in de Automatiseringsgids van 2 februari 2007
50
dat er binnen het vakgebied van ICT snel nieuwe functieprofielen ontstaan), ontstaat er voor aanbestedende diensten het juridisch risico dat opdrachten buiten de scope van de gehouden aanbestedingsprocedure worden geplaatst. Voor de ICT-aanbieders betekent dit dat zij ten onrechte naast opdrachten grijpen, domweg omdat ze niet in de gelegenheid worden gesteld om offertes uit te brengen.
Dynamisch Aankoopsysteem Het Dynamisch Aankoopsysteem, dat sinds december 2005 van toepassing is, zou hiervoor een oplossing moeten bieden. Een Dynamisch Aankoopsysteem is een vorm van elektronisch aanbesteden dat mogelijkheden moet bieden om de wijze waarop overeenkomsten op dit moment worden gebruikt sterk te flexibiliseren. Omdat het een vorm van Europees aanbesteden is start de aanbesteding met een aankondiging op de EG-website: http://ted.europa.eu. In deze aankondiging wordt de aan te besteden opdracht globaal beschreven en wordt het internetadres vermeld waar het zogenaamde Beschrijvende Document valt te downloaden. In dit Beschrijvende Document wordt de opdracht zo nauwkeurig mogelijk geduid. Tevens worden de vereisten beschreven waaraan ICT-aanbieders moeten voldoen om te kunnen worden toegelaten in het Dynamische Aankoopsysteem. Op basis van het Beschrijvende Document kan de ICT-aanbieder een indicatieve aanbieding doen. Het komt er op neer dan een aanbieder wordt geacht zijn uurtarieven en functieprofielen aan te bieden en daarnaast aan te tonen dat hij aan bepaalde gestelde selectie-eisen voldoet. Iedere aanbieder die aan de gestelde selectie-eisen voldoet moet in het Dynamische Aankoopsysteem worden toegelaten. Dit betekent voor de aanbieder dat hij gegarandeerd gedurende de looptijd van het Dynamische Aankoopsysteem offerteaanvragen zal krijgen voor het onderwerp van de aanbesteding. Het bijzondere van een Dynamisch Aankoopsysteem is dat dit systeem gedurende maximaal vier jaar open mag blijven staan – al is deze periode om de hierboven genoemde redenen voor ICT-inhuur te lang. Partijen kunnen zich gedurende de gestelde looptijd blijven aanmelden. Als het Dynamische Aankoopsysteem dus voor bijvoorbeeld een jaar wordt opengesteld dan kunnen zich gedurende dit jaar partijen blijven aanmelden. Op het moment dat zich nu een concrete opdracht voordoet is een opdrachtgever verplicht nog een keer een zogenaamde miniaankondiging te doen op http://ted.europa.eu. Dit moet on line gebeuren en is, in tegenstelling tot een ‘echte’ EG-aankondiging een documentje van slechts enkele regels waarin nog eens wordt herinnerd aan het bestaan van het betreffende Dynamische Aankoopsysteem. ‘Slapen51
de’ leveranciers kunnen zich alsnog voor het systeem aanmelden. Dit biedt de aanbestedende dienst de gelegenheid eventueel zelf aanbieders attent te maken dat er een opdracht aan komt. Vervolgens kan er onderhands offerte worden gevraagd bij de deelnemers (het afroepen) en behoeft er voor opdrachten niet meer te worden aanbesteed tijdens de looptijd van het dynamische aankoopsysteem. Het gegeven dat het systeem open blijft voor nieuwe deelnemers is zowel voor opdrachtgever als voor ICT-aanbieders een belangrijk voordeel ten opzichte van raamovereenkomsten. Tegelijkertijd vormt het een risico dat het systeem onbeheersbaar wordt. Een belangrijk aandachtspunt is er voor te waken dat het systeem niet te veel aanbieders heeft. Immers, iedere aanbieder die aan de gestelde eisen voldoet moet worden toegelaten. En als er voor elke opdracht twintig offertes moeten worden gevraagd ontstaat er een onwerkbare situatie. Er is een aantal maatregelen te nemen waardoor het aantal aanbieders beperkt blijft: Zo kunnen er scherpe eisen voor deelname worden geformuleerd. Niet de veel gevraagde hoge omzetten en grote hoeveelheden personeel (waar kleinere bedrijven terecht vaak over klagen), maar wel de kwaliteit en bestendigheid van personeel en het bedrijf waar ze werkzaam zijn. Er kan ook een performancegarantie aan de deelname worden verbonden. Zo kan er een afscheidreglement worden opgenomen waardoor aanbieders weer verdwijnen uit het systeem indien ze onvoldoende performen bij de uitvoering van opdrachten, maar ook indien ze te vaak ‘nee’ verkopen bij offerteaanvragen of indien ze te vaak offertes verliezen. Dit laatste heeft een uitdrukkelijk kwaliteitsverhogend effect. De looptijd van het systeem kan worden beperkt. De looptijd kan het beste ongeveer een jaar te bedragen in de gevallen dat er veel aanbod is. Bij weinig aanbod kan een langere periode worden gehanteerd. Het aardige is dat dit Dynamische Aankoopsysteem zelfs ook voor eenmalige projecten kan worden gehanteerd waarbij het voor de hand ligt om meerdere offerterondes in te lassen. De looptijd zal in dat geval dan samenvallen met de projectplanning.
Ei van Columbus? Al met al lijkt het gebruik van een Dynamisch aankoopsysteem hét ei van Columbus dat alle partijen maximale flexibiliteit geeft. Waarom zien we dan dat er zo weinig gebruik wordt gemaakt van een Dynamisch Aankoopsysteem voor inhuur van externe ICT-expertise? Zowel de aanbestedende diensten als de ICT-aanbiedersmarkt zaten hier toch echt 52
op te wachten. Er is een belangrijke verklaring voor. De opstellers van de EG-richtlijn 2004/18/EG, dat is de richtlijn waar het BAO op is gebaseerd, hebben niet goed nagedacht over het proces van het plaatsen van nadere orders (het afroepen). Bij het publiceren van een miniaankondiging moet er namelijk een verplichte wachttermijn van 15 dagen worden gehanteerd en daarna mag er pas onderhands offerte worden gevraagd waar dan uiteraard ook nog een redelijke termijn moet worden gehanteerd. Daar zit natuurlijk geen enkele opdrachtgever en aanbieder op te wachten. De Europese wetgever had de verplichting tot het plaatsen van een mini-aankondiging beter achterwege kunnen laten. De mini-aankondiging moet nu voor iedere nadere opdracht worden geplaatst en dat is ten opzichte van de soms lage waarde daarvan disproportioneel. Het kost veel te veel tijd. Waarom heeft de Europese wetgever dit systeem niet zodanig geregeld dat er periodiek een algemene herhalingspublicatie kan plaatsvinden? Dat levert namelijk een veel beter evenwicht op tussen de wens om concurrentie te stellen en een efficiënt inkoopproces. Aanbestedende diensten kiezen daarom voor klassieke aanbestedingsprocedures die in de aloude raamovereenkomsten resulteren en vrijwel niemand is daar blij mee. De Europese wetgever heeft door dit gebrek aan inzicht een misschien wel unieke kans laten liggen om aan veel van de door ICT-aanbieders en aanbestedende diensten geuite bezwaren tegen rigide aanbestedingsregels tegemoet te komen.
53
Raamovereenkomsten en Dynamisch aankoopsysteem, een korte vergelijking: Raamovereenkomsten
Dynamisch Aankoopsysteem
Gelden maximaal vier jaar
Staat maximaal vier jaar open
Kunnen zowel elektronisch als ‘op papier’ worden aanbesteed
Kunnen alleen elektronisch worden aanbesteed
Komen tot stand op basis van diverse aanbestedingsprocedurevormen
Komt uitsluitend tot stand op basis van een openbare procedure
Er kunnen gedurende de looptijd geen additionele leveranciers worden gecontracteerd
Er kunnen gedurende de looptijd additionele leveranciers worden gecontracteerd
Gunning op basis van gunningscriteria (bijvoorbeeld op basis van lage prijs en/of functionele geschiktheid van het aanbod)
Opname in het systeem op basis van het voldoen aan selectiecriteria (bijvoorbeeld door het voldoen aan ervaringseisen en/of technische bekwaamheid)
Zijn bedoeld om de hoeveelheid aanbieders te beperken
Is bedoeld om hoeveelheid aanbieders uit te breiden gedurende de looptijd van het systeem
Geen publicatie van een individuele opdracht verplicht
Publicatie van een individuele opdracht is verplicht
54
Hoofdstuk 4 Nieuwe bedrijfsvoeringsystemen zijn een breekijzer voor verandering Jaap de Mare12 Iedere organisatie komt vroeg of laat op het punt dat de bedrijfsvoeringsystemen op de schop moeten. Als gevolg van een fusie, een koerswijziging, of gewoon omdat de bestaande systemen niet meer voldoen. Moeilijke projecten, waar veel overhoop wordt gehaald. Maar tegelijk ook projecten waarbij de organisatie in beweging komt, waar veranderingsprocessen in gang worden gezet die een veel grotere reikwijdte kunnen hebben dan alleen systeemveranderingen.
Kansen.. Veranderprojecten hebben zeer verschillende slagingspercentages. Pure cultuurveranderingen, waarbij er niets concreets veranderd wordt, hebben in het algemeen een slechte score. Veel van dergelijke projecten mislukken geheel of bewerkstelligen slechts kortstondige verande12 dit hoofdstuk is gebaseerd op een artikel in de Overheid Innovatief van oktober 2006
55
ring. Reorganisaties, het type projecten waarbij het ‘organisatieharkje’ anders wordt getrokken maar de processen in principe hetzelfde blijven, hebben ook een vrij slechte reputatie. Uiteindelijk beklijven ze wel, maar het kost vaak veel moeite en tijd – en in die tijd is de organisatie vooral aan het navelstaren, met zichzelf bezig en niet met z’n klanten of met het verbeteren van de bedrijfsvoering. De invoering van nieuwe bedrijfsvoeringsystemen (welke meestal gepaard gaan met het stroomlijnen van processen) heeft meer blijvend succes omdat het iets tastbaars is: het nieuwe systeem dwingt een nieuwe manier van werken af, belichaamt een nieuwe taakverdeling, nieuwe verantwoordelijkheden. De implementatie van een nieuw bedrijfsvoeringsysteem maakt het makkelijker om deze veranderingen te realiseren, en de kans op terugval naar de oude situatie is gering. Een goed voorbeeld is het integratieproces dat de (relatief zelfstandige) arbeidsbureaus doormaakten nadat ze werden samengevoegd in het CWI. Die integratie kreeg een enorme impuls toen de bestaande primaire bedrijfsvoeringsystemen werden vervangen door een nieuw systeem (Sonar) doordat het een uniforme werkwijze en een uniforme verantwoordelijkheidsverdeling afdwong. Ook vervanging van ondersteunende bedrijfsvoeringsystemen kent een soortgelijke dynamiek. Met name bij organisaties bestaande uit verschillende werkmaatschappijen met grote mate van autonomie die eigen ondersteunende afdelingen hebben met op hun beurt eigen systemen (financieel, HR, facilitair, et cetera). Het is logisch dat er dan initiatieven ontstaan om deze verschillende systemen te vervangen door één centraal systeem dat alle werkmaatschappijen kan faciliteren – een pure ICT-integratie dus. In de dynamiek die dan vaak ontstaat kan het inzicht, dat decentrale uitvoering van al die ondersteunende processen niet efficiënt is, leiden tot een verdergaande samenwerking. Bijvoorbeeld in de vorm van een centrale afdeling of een shared service centrum (SSC). Een goed voorbeeld hiervan is het proces dat de gemeente Rotterdam doormaakte bij het vervangen van enkele financiële (dienst)systemen (zie ook hoofdstuk 6). Wat in eerste instantie begon als initiatief voor een gezamenlijke aanbesteding (en niet meer dan dat), ontwikkelde zich tot een project waarbij niet alleen dezelfde software werd aangeschaft, maar waarbij voor een concernbrede inrichting werd gekozen met een uniform ‘template’ (functionaliteiten en processtandaarden voor onder andere grootboek, projecten en tijdschrijven, begroten etc.). Dat het beheer van dit systeem vervolgens centraal belegd werd ligt voor de hand. Maar het creëert ook de moge-
56
lijkheid om de financiële administratie zelf in een SSC onder te brengen – een stap die Rotterdam inmiddels overweegt.
… en risico’s Een dergelijke dynamiek roept ook tegenkrachten op. Als een bedrijfsvoeringsysteem in een onderneming wordt gecentraliseerd, moeten mensen en werkmaatschappijen afstand doen van hun huidige systeem en daarnaast hun werkwijze aanpassen. Bovendien zijn er niet te onderschatten aspecten van vrijheid, van verantwoordelijkheid en van macht. Centralisatie van een systeem kan opgevat worden als een poging de autonomie van een werkmaatschappij te verkleinen en deze meer in het gareel te laten lopen. Dit kan de nodige tegenkrachten oproepen die de dynamiek van het project compliceren.
Een ander risico bij het vernieuwen van bedrijfsvoeringsystemen is het fenomeen van ‘scope creep’. Het blijkt heel moeilijk om de grenzen van dergelijke projecten scherp te trekken en te voorkomen dat ze gaan schuiven. Dit komt in de eerste plaats doordat bedrijfsvoeringsystemen veel relaties met andere systemen en processen hebben. Als die niet goed op orde zijn worden ze vaak onderdeel van het project. Het is 57
soms net een kluwen spaghetti die in zijn geheel mee komt als je aan één sliertje trekt. Een tweede oorzaak is het feit dat de introductie van een bedrijfsvoeringsysteem een goede aanleiding is om de processen op de schop te nemen. Beter eerst de processen verbeteren in plaats van krakkemikkige processen te ondersteunen met nieuwe systemen, nietwaar? En deze procesverbeteringen zijn natuurlijk ook een belangrijke bate van dit soort projecten. Maar het kost wel tijd en geld. Al met al is het optuigen en introduceren van nieuwe bedrijfsvoeringsystemen vaak een veel grotere klus is dan in eerste instantie lijkt. Vooral ERP-systemen, die de pretentie hebben om bijna alle processen in een organisatie aan elkaar te knopen, hebben wat dat betreft een slechte reputatie.
Licht, hoop en uitzicht Het kan ook goed gaan. Tientallen geslaagde implementaties, vooral in het bedrijfsleven maar ook bij overheidsorganisaties, laten zien dat nieuwe bedrijfsvoeringsystemen een organisatie een grote stap voorwaarts kunnen brengen. Het inrichten en uitrollen van Sonar, het nieuwe systeem van het CWI, had heel wat voeten in de aarde, maar het heeft de organisatie wel in een positie gebracht voor tal van verdere verbeteringen. In Rotterdam is er heel wat bloed gevloeid rond het nieuwe financiële systeem, maar het maakt wel een kanteling van de organisatie mogelijk die nodig is om de focus op de burger te kunnen leggen. En nieuwe technologische mogelijkheden om systemen met elkaar te laten interacteren, b.v. op basis van een Service Oriented Architecture (zie hoofdstuk 2), maken het steeds beter mogelijk om op één plaats verbeteringen door te voeren zonder het gehele systeemcomplex op de schop te nemen. Om één sliertje spaghetti uit de kluwen te trekken zogezegd. Bij veel overheidsorganisaties is de laatste jaren nadruk komen te liggen op klantgerichtheid en een efficiënte uitvoering van de taken. Dit stelt hoge eisen aan het verandervermogen van organisaties en de ondersteuning van de processen. Hoogwaardige, flexibele bedrijfsvoeringsystemen zijn daarvoor onmisbaar; de invoering ervan kan, voor wie het goed doet, een organisatie in beweging brengen. Een beetje durf is daarbij wel nodig.
58
Hoofdstuk 5 ICT-projecten niet geschikt voor control freaks en hokjesdenkers Jaap de Mare13 Weinig onderwerpen zijn zo ‘uitgekauwd’ als het verandermanagement: hoe krijg je het voor elkaar om veranderingen te realiseren, te laten beklijven? Ook over verandermanagement in het kader van ICTprojecten zijn boekenkasten vol geschreven. Wat valt daar nu nog voor nieuws over te bedenken? Welnu, heel wat. Want de ervaring laat zien dat alle theoretische inzichten, hoe geavanceerd en goed onderbouwd wellicht ook, er niet toe hebben geleid dat in de praktijk veranderingen met behulp van ICT goed worden doorgevoerd. Veranderen is een kunst, geen wetenschap. En ICT is een veelkoppig monster, veel minder grijpbaar dan managers graag zouden willen. Grote ICT-projecten hebben een slechte reputatie: ze worden niet op tijd afgerond, kosten meer dan begroot en brengen uiteindelijk niet de verbeteringen waarop vooraf gerekend was. Waar ligt dat aan? Aan de technologie, die onvoldoende begrepen werd of niet ‘mature’ was? Aan de projectorganisatie, die klaarblijkelijk de risico’s onvoldoende in de greep kreeg? Aan het lijnmanagement, dat z’n opdrachtgeverschap onvoldoende inhoud gaf? Of aan de organisatie, die onvoldoende in staat bleek de benodigde veranderingen door te voeren? Al deze oorzaken kunnen ongetwijfeld een rol spelen om mislukkingen te verklaren. Maar wat kun je er dan verder mee? Een paar bespiegelingen en statements over veranderen en ICT: Eerst een open deur: ICT en veranderingen zijn onlosmakelijk met elkaar verbonden. Er zijn geen grote veranderprogramma’s zonder een (veelal belangrijke) ICT component. En de meeste ICT-projecten (kleine technische projecten uitgezonderd) brengen een organisatorische verandering met zich mee. Soms klein, soms groot. ‘Veranderen’ is een beweging, geen transitie tussen stabiele situaties. Wie verandering wil realiseren moet leven met onzekerheid, met opwervelend stof. En bij bewegingen is het belangrijker dat ze gecreëerd worden dan dat ze gecontroleerd worden. Onzekerheid hoort erbij, en
13
dit hoofdstuk is gebaseerd op een artikel in de TIEM van maart 2006
59
moet ook geaccepteerd worden. Het willen definiëren van precieze doelstelling en concrete stappenplannen om daar te komen is vaak niet mogelijk, en het toch proberen is vaak contra-productief. Geen doelstellingen maar richtingen, geen stappenplannen maar improvisaties geen lukrake improvisaties, maar het naar bevind van zaken flexibel inspelen op kansen en bedreigingen, met de gewenste richting voortdurend voor ogen. Veranderen met ICT is nog eens extra moeilijk, omdat de ICT niet objectief, eenduidig is, maar vele gezichten heeft. Wie hoopt in ICTprojecten altijd op ‘objectieve’ gronden beslissingen te kunnen nemen, komt bedrogen uit. In hoofdstuk 7 van dit boek wordt het voorbeeld genoemd van een organisatie waar over een bepaalde applicatie allerlei verhalen in omloop waren die later absoluut niet bleken te kloppen. ICT verandert ook nog onder de invloed van de omgeving. ICT is niet hard en onveranderlijk, het is een speler in het spel die zich aanpast aan de omgeving – niet bewust, zoals de menselijke spelers, maar niet minder significant. In hoofdstuk 9 van dit boek wordt het voorbeeld genoemd van een groot HR-systeem, dat onder invloed van de organisatorische dynamiek belangrijk veranderde en een heel andere rol ging spelen dan oorspronkelijk voorzien. ICT-projecten stellen dan ook hoge eisen aan de projectleider en de leverancier. Hoedt u voor projectleiders die ‘een kunstje uithalen’, die menen dat je projecten kunt sturen zonder gevoel te hebben voor de inhoud, de technologie en de omgeving. Die sturen op deadlines en deliverables zonder gevoel te hebben voor weerstanden in de organisatie, uithollend draagvlak of prioriteitsverschuivingen bij het management. Of die zich niet interesseren voor de technische aspecten, die menen dat je een groot ICT-project tot een goed einde kunt brengen zonder je in de technische details te hoeven verdiepen. ICT-projecten stellen ook hoge eisen aan de opdrachtgever. Er zijn slechts beperkt zekerheden – veel minder dan waar opdrachtgevers zich vaak prettig bij voelen. Opdrachtgevers doen er goed aan zich intern niet volledig op te hangen aan een planning, maar om wat ruimte in te bouwen. Ook enige budgettaire ruimte is handig, zowel om tegenvallers op te kunnen vangen als om extra functionaliteiten te kunnen laten bouwen. Vooral extra functionaliteiten die handig zijn voor de eindgebruiker kunnen enorm helpen om het draagvlak te verbreden. Maar minstens zo belangrijk als bovenstaande flexibiliteit is het vermogen van de opdrachtgever om de grenzen van het project te begrijpen, en te herkennen wanneer projecten over de grenzen van het eigen 60
mandaat heen gaan. Want bij organisatorische veranderingen is vaak een breder draagvlak nodig dan alleen de opdrachtgever en zijn ‘span of control’. In het boek ‘De kracht van toewijding’ staat een voorbeeld van een branche-organisatie die, naar aanleiding van een project om content via het internet ter beschikking te stellen, ontdekte dat haar hele bestaansrecht aan het schuiven was, dat een kanteling nodig was van een aanbod- naar een vraaggerichte organisatie. Het moge duidelijk zijn dat het mandaat van de oorspronkelijke opdrachtgever onvoldoende was om de uiteindelijke uitkomst te realiseren. Kort gezegd zijn ICT-projecten niet geschikt voor control freaks en hokjesdenkers. Voelt u zich aangesproken?
61
62
deel C
Cases
63
64
Hoofdstuk 6 Nieuw HRM-elan in Rotterdam Bob Hotho, Willem-Jan Herckenrath en Jaap de Mare14
Mensen met pit De invoering van nieuwe bedrijfsvoeringsystemen creëert vaak een moeilijk te voorziene dynamiek. Wat begint als een simpele vervanging van een bestaand systeem ontwikkelt zich vaak tot een belangrijk verandertraject. De organisatorische setting verandert omdat het duidelijk wordt dat het oorspronkelijke vertrekpunt niet handig meer is. Extra functionaliteiten die de organisatie wil maken het traject complexer – of ze worden onderdrukt, maar daarbij wordt het draagvlak voor het nieuwe systeem uitgehold. Mensen met pit schikken zich niet gedwee in een oorspronkelijk plan maar grijpen de kans om verbeteringen te realiseren. Het HRM-systeem is het hart van de administratieve ondersteuning van het personeelswerk. Alle reden om bij de implementatie of vervanging ervan zorgvuldig te werk te gaan. Bij de gemeente Rotterdam is begin 2006 het project ‘Mensen met Pit’, de vervanging van het concernbrede HRM-systeem, afgerond. Het is een project dat laat zien hoe iets dat puur binnen de HRM-kolom begint snel kan veranderen in iets dat ook andere kolommen raakt. En dat betekent dat er een dynamiek ontstaat waar slechts beperkt grip op kan worden gekregen. Tot die tijd gebruikte de gemeente Rotterdam een in de jaren tachtig zelf ontwikkeld HRM-systeem dat door alle diensten, deelgemeentes en bedrijven werd gebruikt. Het einde van de levenscyclus van het systeem kwam in zicht toen de leverancier (die het van de gemeente Rotterdam had gekocht) aangaf het onderhoud te gaan beëindigen. Tegelijkertijd was er behoefte aan meer functionaliteit op HRM-gebied dan waarin het systeem voorzag. in 2003 startte een aanbestedingstraject voor een nieuw HRM-systeem, een salarisverwerkingdienst, een inrichtingspartner en een exploitatiepartner. Er bestond vooraf geen expliciete voorkeur voor een specifiek HRM-systeem of een module van een ERP-systeem, maar het bleek dat
14
dit hoofdstuk is gebaseerd op een artikel in de Gids voor Personeelsmanagement van januari 2007
65
de HRM modules van de ERP-systemen op functionaliteit beter scoorden dan de specifieke HRM-systemen, vooral op de gebieden werving en selectie, opleidingen en rapportages. De keuze viel uiteindelijk op de HRM module van de Oracle E-business suite, in combinatie met de op PASO gebaseerde salarisverwerking van LogicaCMG. Ondertussen waren er in Rotterdam ontwikkelingen op het gebied van de financiële systemen. Die waren een decentrale verantwoordelijkheid, en van de 14 verschillende systemen waren er vijf aan vervanging toe. Er werd besloten gezamenlijk aan te besteden met als doel te komen tot een selectie van drie systemen, waaruit deze vijf diensten zelf een keuze konden maken. Ook de andere diensten zouden in de toekomst uit deze drie systemen moeten kiezen om zo de variatie aan financiële systemen binnen de gemeente terug te brengen. In termen van uniformering en integratie waren de ambities dus erg bescheiden.
Gemeente Rotterdam De gemeente Rotterdam kent een concernorganisatie: de gemeentelijke diensten, deelgemeenten en bedrijven zijn afzonderlijke, (groten)deels autonome organisaties. Gemeentelijke diensten hebben de beleidsvoorbereiding en beleidsuitvoering tot taak. De Bestuursdienst ondersteunt het college met beleidscoördinatie en de controlfunctie. Bij de 36 diensten, deelgemeenten en bedrijven werken zo’n 16.000 ambtenaren. Het liep anders. Een reorganisatie binnen de Bestuursdienst leidde ertoe dat de directies P&O en Financiën samen kwamen in de directie Middelen en Control (DMC). De stuurgroepen van de vervangingstrajecten kwamen onder leiding van één directeur. Bovendien was de visie op bedrijfsvoering binnen het College en de Bestuursdienst aan het verschuiven in de richting van een sterkere rol voor het concern. Dit mede als gevolg van de verkiezingsoverwinning van Leefbaar Rotterdam en de daarop volgende focus op doelmatige uitvoering. Op ICT gebied kwam het adagium “We doen het als concern, tenzij...” opzetten. Alhoewel dit nog geen vastgesteld beleid was, sprak de stuurgroep de voorkeur uit om te komen tot de selectie van één financieel pakket, dat voor iedere dienst separaat zou worden geïmplementeerd. Dat de keuze op Oracle E-business suite viel kwam goed uit gezien de ontwikkelingen op HRM-gebied. Eén van de vijf betrokken diensten onttrok zich aan deze algemene keuze en koos voor een ander financieel pakket. Het vooruitzicht van vijf afzonderlijke implementaties van hetzelfde systeem (één keer HRM en vier keer FIN) riep bij DMC de vraag op of het 66
eerdere uitgangspunt van separate implementatie en exploitatie van het (financiële) systeem per dienst wel doelmatig was. Dit lijkt misschien voor de hand liggend, maar het alleen al ter discussie stellen van dit uitgangspunt lag zeer gevoelig binnen gemeente Rotterdam. Maar het bleek dat zowel de vier betrokken diensten als DMC meer voordelen dan nadelen zagen in het onderbrengen van HRM en Financiën in één gemeenschappelijk ingericht en geëxploiteerd systeem. Er werd besloten een concernbrede inrichting te ontwikkelen die bruikbaar zou zijn voor alle diensten.
“een standaardpakket is nooit standaard”
Top-down Voor de HRM implementatie gold dat de aangeschafte functionaliteit breder was dan de in gebruik zijnde functionaliteit. Door de scope te beperken tot een vervangingsvraag (“nieuw voor oud”) konden inrichtingsvraagstukken snel ‘top down’ worden opgelost vanuit de bestaande organisatie en vanuit bestaand beleid. Dit beperkte het risico dat inrichtingsvragen en vooral de daarmee samenhangende organisatie- en beleidswijzigingen de voortgang zouden belemmeren. Door de uitrol te 67
faseren (zeven diensten en ca.7500 medewerkers live per 1-1-2005, de overige diensten per 1-1-2006) werden de risico’s van live gaan beperkt doordat het enerzijds maar een deel van het werknemersbestand betrof en anderzijds fall back mogelijk zou zijn op een nog operationeel systeem. Deze opzet bracht ook belangrijke nadelen met zich mee. De extra mogelijkheden van de nieuwe applicatie werden nauwelijks gebruikt. Dit was vooral vervelend voor de diensten die per 1-1-2005 live gingen met het nieuwe systeem: ze hadden allerlei gerechtvaardigde wensen die vrij eenvoudig gerealiseerd konden worden, maar de functionaliteit bleef een jaar lang bevroren totdat ook de overige diensten per 1-12006 over gingen. Dat kweekte een hoop weerstand en deed het draagvlak voor het project geen goed. Een separaat project dat de mogelijke verbeteringen zou realiseren kwam vervolgens niet van de grond omdat er te weinig ‘common ground’ was tussen de verschillende diensten. Het gevolg was dat veel laaghangend fruit bleef hangen.
ERP en HRM ERP systemen omvatten verschillende disciplines binnen een organisatie (financieel, HRM, commercieel, logistiek) en zijn dan ook uiterst complex. Echter, het aantal raakpunten tussen HRM en de andere onderdelen is beperkt. Het is mogelijk ERP-pakketten te implementeren zonder HRM-module, en de HRM-software van een andere leverancier te gebruiken. Maar de belangrijkste ERP-pakketten (SAP, Oracle/PeopleSoft) hebben goede HRM-modules, dus in de praktijk gebeurt dat niet zo vaak. In Rotterdam was de keuze voor één ERP-systeem in feite een toeval. Als uit de selectie voor het HRM-systeem een gespecialiseerd HRMpakket als beste uit de bus was gekomen, was er nooit een overkoepelend ERP-systeem gekomen. En ook de keuze voor Oracle als financieel systeem werd onafhankelijk gemaakt – hoewel het daar denkbaar is dat er bij een andere uitkomst een nieuw aanbestedingstraject zou zijn gestart.
Organisatieveranderingen Rotterdam verandert van een instelling die georganiseerd is rond gemeentelijke diensten naar een instelling die dienstverlening aan burgers en bedrijven centraal stelt. Deze kanteling is een autonome trend die vanuit de politiek is ingezet, waarbij de invoering van centrale bedrijfs68
voeringsystemen een faciliterende rol speelt. De inrichting van een Shared Service Centrum voor het beheer van de centrale systemen is in dit kader een voor de hand liggende stap, net als het onderbrengen van de HRM-administratie in één Shared Service Centrum,
Logisch Achteraf gezien zijn de keuzes die door Rotterdam zijn gemaakt niet meer dan logisch. Maar wie in 2003 had gezegd dat dit zou gebeuren zou ongelovig worden aangekeken. Het introduceren van nieuwe bedrijfsvoeringsystemen (in dit geval HRM en financiën) bracht een dynamiek op gang die tot onverwachtse uitkomsten leidde. Uitkomsten waarmee de efficiency in de uitvoering, speerpunt van de politiek, zeer is gediend. HRM’ers die hun systemen op de schop willen nemen doen er goed aan met deze dynamiek rekening te houden. Het voorstel om het HRMsysteem te vervangen kan een hoop andere zaken in beweging brengen. Anticipeer daarop en plan dus niet te scherp.
Implementatie van HRM-systemen: 1 januari is belangrijk HRM-systemen zijn behoorlijk complex, met name vanwege vaak ingewikkelde arbeidsvoorwaardenregelingen, en implementaties luisteren derhalve nauw. Het feit dat salarissystemen met grote voorkeur per 1 januari moeten worden geïmplementeerd legt behoorlijke druk op de planning en uitvoering van implementatietrajecten. Het uitlopen in de planning met meer dan een maand heeft veelal tot gevolg dat de implementatie een jaar moet worden uitgesteld. Daarnaast is er vaak extra aandacht nodig voor de juistheid van de salarisbetalingen in de eerste maanden dat een nieuw salarissysteem operationeel is. Zelfs geringe afwijkingen in de salarissen tussen het oude en nieuwe systeem leiden vrijwel gegarandeerd tot een stormloop van (geïrriteerde) vragen, laat staan een door de overgang vertraagde betaling van salarissen oproept. Een implementatie van enige omvang verdient daarom grondige voorbereiding, waarbij het enkele maanden ‘schaduwdraaien’ van de salarisberekeningen cruciaal is.
69
Hoofdstuk 7 Procesbesturing in de sociale zekerheid Jaap de Mare15
Vernieuwen of vervangen? “Wij worstelen als organisatie nu al zo lang met onze procesbesturing. Een van de problemen is het houtje-touwtjesysteem dat we daarvoor gebruiken en dat ieder moment om schijnt te kunnen vallen. Dan zijn we pas echt ver van huis. Wat wij nodig hebben is een modern, uniform systeem dat het management 'met een druk op de knop' inzicht geeft in de stand van zaken.We moeten ons huidige systeem vervangen door een modern workflow management systeem.”
Casus Een uitkeringsinstantie in de sociale zekerheid hecht grote waarde aan operationele efficiëntie. De politiek oefent druk uit om sneller en tegen lagere kosten uitkeringen te verstrekken. Dat betekent dat de procesbesturing moet verbeteren. Weten we waar processen efficiënt verlopen en waar niet? Weten we waar het beter zou kunnen? En zo nee, waarom weten we dat niet? En, als we het op afdelingsniveau wel weten, waarom weten we het dan niet op directieniveau? Deze vragen zijn niet nieuw voor de organisatie. Sterker nog, men worstelt er al jaren mee. De processen zijn nauwkeurig beschreven en door de gehele organisatie geüniformeerd, er zijn prestatie-indicatoren benoemd waar trouw over wordt gerapporteerd. En toch heeft het management niet het gevoel grip te hebben. Al jaren is men van plan een goede oplossing te implementeren, een systeem dat de processen ondersteunt en tegelijk ook managementinformatie op verschillende niveaus kan genereren. Maar er is altijd wel een reden om het niet te doen: een uitbreiding die moet worden verwerkt, een plotselinge bezuinigingsmaatregel, onduidelijkheid over de toekomst… Uiteindelijk wordt steeds een kortetermijnoplossing gekozen om de meest urgente problemen op te lossen, maar die de organisatie niet dichter bij een structurele oplossing brengt. Op een gegeven moment is toch de tijd rijp om de problemen structureel aan te pakken. De kortetermijnoplossing (die technologisch verou-
15
dit hoofdstuk is eerder verschenen in het boek ‘De Kracht van Toewijding’, 2005
70
Valkuil 1: kortetermijndenken Kiezen voor kortetermijnoplossingen die de onmiddellijke problemen oplossen en daarmee de business case voor een andere oplossing wegnemen, maar niet bijdragen aan een structurele oplossing en daardoor de organisatie uiteindelijk niet vooruit helpen. derd is en een risico voor het netwerk van de betrokken organisatie betekent) zal worden vervangen door een state-of-the-art workflowpakket dat een hoop extra functionaliteiten kan bieden ten opzichte van het huidige provisorische systeem. Het zal perfect passen in de architectuur van de organisatie, waar dit workflowpakket een uniforme procesbesturingslaag moet gaan vormen over alle primaire systemen heen. Vol enthousiasme gaat een projectgroep aan de slag om een en ander te realiseren. Geheel volgens de normen van de organisatie wordt een strak projectplan gemaakt, worden milestones en deliverables gepland en de benodigde kosten geschat. Iedere maand wordt een voortgangsrapportage gemaakt die, samen met de voortgangsrapportages van de andere projecten, het management in een oogopslag de stand van zaken geeft. Maar een nieuwe bezuinigingsronde zorgt ervoor dat alleen de meest urgente projecten overeind blijven, en daar hoort dit project niet bij. Het project wordt afgeserveerd: niet urgent, niet cruciaal. De korte termijn wint het weer van de lange termijn. De organisatie is de verliezer.
Valkuil 2: groot denken Organisaties die moeite hebben met veranderen kunnen niet vertrouwen niet op initiatieven van onderop om zich aan te passen aan nieuwe situaties. Daarom worden vaak top-down grootschalige veranderprogramma's opgezet om toch de nodige aanpassingen door te voeren. Dit heeft echter vaak tot gevolg dat er onvoldoende ruimte is voor kleine verbeteracties, voor het type verbeteringen dat niet indrukwekkend klinkt en niet een plekje binnen het grote veranderprogramma weet te veroveren, maar dat de mensen op de werkvloer wel concreet helpt in hun dagelijkse werkzaamheden. Het gevolg is dat het autonome verandervermogen van de organisatie nog verder afneemt omdat er een mentaliteit ontstaat van 'we zien wel wat er gaat gebeuren'.
71
Of toch niet? Is het wel zoals hierboven beschreven? Want de projectgroep die het nieuwe systeem van de grond moet trekken, twijfelt al snel aan de noodzaak ervan. De veelbekritiseerde houtje-touwtje oplossing blijkt helemaal niet zo slecht te zijn. Het is wel technologisch verouderd maar nog lang niet op z'n eind. En veel van de voorgestelde verbeteringen blijken ook met het bestaande systeem te kunnen worden gerealiseerd. Het blijkt dat door sommigen al jaren negatief over het bestaande systeem wordt gedacht, negatiever dan het wellicht verdient. De informatie over het systeem blijkt gekleurd en moet gezien worden in relatie tot degene die de informatie verstrekt. De vele verhalen, die de besluitvorming sterk beïnvloeden, blijken deels niet te kloppen en maken het moeilijk een objectief beeld te vormen. Technologie (het huidige systeem met z'n voor- en nadelen) is toch niet zo waardevrij als gedacht. Er is nog meer aan de hand. De architectuur waarvan het nieuwe systeem een onderdeel vormt, blijkt niet goed doordacht. Het idee was een kant-en-klaar workflowpakket als een integrale besturingslaag over de bestaande legacysystemen heen te leggen, als een soort 'schil'. Voor de eindgebruiker is het legacysysteem dan in feite onzichtbaar. Deze architectuurvisie blijkt niet haalbaar. In de legacysystemen zijn allerlei 'triggers' gedefinieerd die acties initiëren van de gebruikers. Als de besturing wordt losgekoppeld van de legacysystemen, dan moeten deze triggers in het workflowpakket worden nagebouwd , of moet er een uitgebreide interface komen. De toegevoegde waarde hiervan is echter gering omdat het om kortcyclische activiteiten gaat die snel uitgevoerd kunnen worden en weinig besturing behoeven. De procesbesturing waar de organisatie zo'n behoefte aan heeft blijkt het overzicht van openstaande acties en rapportages over hoe ze zijn uitgevoerd te betreffen – niet het inzicht in de voortgang van de individuele acties. En dan heeft workflow niet zo veel toegevoegde waarde. Een architectuur die er op papier prima uitziet, blijkt in de praktijk toch niet de juiste. De toekomstige architectuur is jaren lang een reden geweest om allerlei kleinschalige verbeteracties uit te stellen. Diverse initiatieven om de rapportage uit de legacysystemen te verbeteren zijn tegengehouden met als reden: 'straks hebben we een integraal workflowpakket waar we allerlei rapportage-faciliteiten aan koppelen, dus we gaan nu niet investeren in dit soort kleine verbeteringen’. De frustratie op de werkvloer is aanzienlijk nu blijkt dat het project (dat sowieso niet door gaat) geen oplossing zou hebben geboden voor de problemen in de uitvoering.
72
Legacysystemen Legacysystemen zijn oudere systemen die niet voldoen aan 'moderne' inzichten over hoe applicaties opgebouwd moeten zijn. Vaak zijn het maatwerkoplossingen, gebouwd in de jaren tachtig en negentig van de vorige eeuw, op basis van technologieën die nu verouderd zijn. Iedere organisatie worstelt met de vraag deze oude systemen te vervangen of ermee verder te gaan, eventueel na een vernieuwing (een 'mid-life revival').
Legacysystemen ondersteunen meestal de primaire processen van een organisatie en die zijn vaak redelijk uniek. In deze systemen is veel knowhow van de organisatie verwerkt. Het is vaak niet eenvoudig om dezelfde functionaliteit na te bouwen, ook niet op basis van een standaardpakket. Daarom zijn deze systemen vaak een lang leven beschoren. Bij de keuze tussen vervangen of vernieuwen speelt de vraag of het legacysysteem, ondanks de verouderde technologie, toch een moderne architectuur heeft of kan krijgen een belangrijke rol. ICT-architecten 73
zijn dol op het onderscheiden van verschillende 'lagen' in een applicatie, zoals een gegevenslaag, een 'business logic' laag en een presentatielaag. Legacysystemen die ook zo zijn opgebouwd of zo kunnen worden aangepast, kunnen meestal goed geïntegreerd worden met andere, nieuwere systemen. Het kan ook zo zijn dat ze niet worden vervangen, maar dat hun rol wordt teruggedrongen. Als het legacysysteem echter een kluwen spaghetti is waarbij de hele hoop meekomt als je aan één sliertje trekt, dan is het onvermijdelijk het op enig moment te vervangen.
Deze frustratie kan momentum genereren om de zaken in beweging te krijgen. Als de langetermijnoplossing verder weg is dan ooit, als de van bovenaf opgelegde prioriteiten de werkvloer niet helpen in hun dagelijkse werkzaamheden, dan zijn er wellicht mogelijkheden om (al dan niet formeel geaccordeerd) kleine initiatieven te ontwikkelen die 'onder de radar' van de grote programma's blijven. Het management hoeft alleen wat ruimte te bieden, wellicht hier en daar wat te masseren. Veranderen is bewegen en uiteindelijk moet die beweging op de werkvloer plaatsvinden. Waarom zou de beweging dan niet daar beginnen?
Valkuil 3: perfectie is de vijand van het goede Kortetermijnverbeteringen worden vaak niet doorgevoerd omdat ze niet in het langetermijnplaatje zouden passen.
Analyse Vernieuwen of vervangen? Het voorbeeld van de sociale verzekeringsinstelling laat een probleem zien dat in veel organisaties speelt: moet een bestaand systeem worden vernieuwd, of moet het worden vervangen door een geheel ander systeem? Het bijzondere in dit geval was dat deze vraag in feite helemaal niet gesteld werd. De vervanging van het huidige systeem was het vertrekpunt omdat het bestaande systeem volledig verouderd en niet in staat zou zijn om de benodigde managementinformatie op directieniveau op te leveren en niet passend in het architectuurmodel van de organisatie. De business case voor vervanging leek glashelder. En toch bleek dat uiteindelijk niet zo te zijn. De argumenten voor vervanging bleken gebaseerd te zijn op een onjuiste beoordeling van het bestaande systeem. En de overkoepelende architectuur waar het nieu74
we systeem zo goed in paste bleek niet goed doordacht. Het vertrekpunt was dus niet goed gekozen. Als dat niet wordt herkend en onderkend lossen ICT-projecten problemen op die ook met minder inspanning en minder impact opgelost hadden kunnen worden. De technologische ontwikkeling verdient separate aandacht. De voortdurende ontwikkeling op het gebied van ICT en van het type applicaties die de sociale verzekeringsinstelling gebruikt in het bijzonder, is een belangrijke impuls voor vernieuwing. Er kan steeds meer en wie blijft vasthouden aan verouderde technologie kan minder inspelen op deze nieuwe mogelijkheden. Daarom wordt wel eens gesteld dat een systeem slechts een levensduur van zo'n vijf jaar heeft. De technologische ontwikkeling heeft nog een ander aspect, namelijk dat van toenemende mogelijkheden om systemen met elkaar te laten communiceren - ook als ze daar oorspronkelijk niet voor gebouwd zijn. (zie ook de ontwikkelingen die in hoofdstuk 1 en 2 van dit boek worden beschreven). Juist op dit gebied is de vooruitgang de laatste tien jaar enorm geweest, waardoor 'verouderde' systemen een tweede jeugd kunnen krijgen. Tenslotte speelt ook een rol dat in iedere organisatie een ingebakken (en niet per se onterechte) weerstand bestaat tegen het vervangen van bestaande systemen. Vooral als deze de behoeften van de gebruikers redelijk vervullen. Systemen belichamen vaak de kennis en expertise van organisatie, vooral de systemen die de primaire processen ondersteunen. Vervanging ervan is een majeure operatie die veel overhoop haalt en een gerede kans op mislukking heeft. Daarom kiezen veel organisaties er toch hun legacysystemen in stand te houden en aan te passen aan nieuwe omstandigheden. Groeien of ontwerpen? Een tweede 'richtingenstrijd' die het voorbeeld van de sociale verzekeringsinstelling laat zien, is die tussen de ontwerpers en de groeiers. De ontwerpers willen veranderen door een blauwdruk van de toekomstige situatie te maken en daar gericht naartoe te werken. De groeiers laten verandering het liefst van onderaf komen door ruimte te geven aan nieuwe initiatieven om daar vervolgens zo veel mogelijk van te leren. Het bestaande systeem was uit nood geboren; omdat de centrale systemen onvoldoende functionaliteit voor procesbesturing boden werd er lokaal een systeem gebouwd om deze lacune te vullen. En aangezien er weinig afstand was tussen de ontwikkelaars en de gebruikers, maakte
75
dit systeem vervolgens een grote ontwikkeling door waarbij gebruikerswensen snel gerealiseerd konden worden. Uit oogpunt van verandermanagement is dit een krachtig model. Het genereren van beweging 'aan de basis' geldt als één van de noodzakelijke voorwaarden waaraan voldaan moet zijn om veranderingen te kunnen laten slagen. Het ruimte geven voor initiatieven van onderop is iets dat bijvoorbeeld door de Japanners in hun kwaliteitsdenken (met de nadruk op kwaliteitskringen) enorm wordt gestimuleerd. ICT'ers staan in het algemeen vrij huiverig tegenover een bottom-up model. Om een strakke applicatie te krijgen met lage beheerkosten is het nodig om vanuit een heldere architectuur te ontwikkelen en de flexibiliteit te beperken. Bottom-up modellen hebben dat meestal niet. Wat dat betreft was de situatie bij de sociale verzekeringsinstelling vrij uniek: het lokaal ontwikkelde systeem bleek geschikt voor een organisatiebrede uitrol. Meestal worden lokaal (Excel-)modellen gebouwd die steeds ingewikkelder en moeilijker te beheren worden tot ze worden vervangen door een centraal ontwikkeld systeem. Voor dat ontwikkelmodel is veel te zeggen: door het werken met een lokale applicatie, hoe beperkt ook, worden de functionele behoeften duidelijker en kan helder worden gedefinieerd wat het centraal te ontwikkelen systeem moet kunnen. De objectieve en enige waarheid? Ook ICT is mensenwerk. Mensen maken systemen, mensen identificeren zich met systemen en verbinden hun lot eraan. Tegelijk zijn er allerlei invloeden die juist weer tegenkrachten oproepen, zoals technologische ontwikkelingen die nieuwe mogelijkheden bieden. De discussie over het vernieuwen of vervangen van systemen wordt weliswaar gevoerd met zakelijke, waardevrije argumenten, maar daarachter ligt vaak een wereld van emoties en belangen. Vanuit een verschillend perspectief ziet men heel verschillende dingen als men naar hetzelfde kijkt. Het blijkt vaak moeilijk te zijn om een gedeeld beeld te krijgen, of om je bewust te zijn van de verschillende beelden en langs die weg met elkaar in gesprek te komen. Bij de sociale verzekeringsinstelling was het bestaande systeem decentraal in een van de districten ontwikkeld, buiten de ICT-afdeling van het concern om. Die afdeling had al vaak aangegeven dat dit systeem niet toekomstvast was en dat het verstandig was om een modern systeem te bouwen en dat vervolgens landelijk uit te rollen. Om allerlei praktische en kortetermijn redenen was dat echter nooit gebeurd. Toen 76
de nood aan de man kwam en er urgent een besturingssysteem landelijk uitgerold moest worden was het lokale systeem het enige dat beschikbaar was. Vanuit de visie van de ICT-afdeling werd een probleem dat klein begon zo steeds groter. Met wat goede wil zou er wel mee te leven zijn, maar die goede wil ontbrak goeddeels. De organisatorische context beïnvloedde de visie op de technologie. Voortschrijdend inzicht Wat het voorbeeld van de sociale verzekeringsinstelling ook laat zien (en ook diverse andere casussen in dit boek), is het inzicht dat het van vitaal belang is om ruimte te bieden de projectdoelen aan te passen op basis van voortschrijdend inzicht. Standaardmethodieken van projectmanagement benadrukken vrijwel allemaal het belang van een gedetailleerd plan van aanpak aan het begin van het project en een strikte indeling in verschillende fases met duidelijke beslismomenten. Het terugkomen op eerdere besluiten of het kiezen van andere richtingen door nieuwe inzichten is vaak onmogelijk, of in ieder geval heel moeilijk. En het wordt ook als erg risicovol beschouwd om laat in een project een nieuwe koers te varen. Maar het niet openstaan voor nieuwe inzichten is ook riskant en levert vaak resultaten op in de categorie 'operatie geslaagd, patiënt overleden'. Het is de uitdaging om hiertussen te laveren, om een heldere koers te varen maar ook de moed te hebben hier van af te wijken als de overtuiging groeit dat dat beter is. Kortom, improviseren op het snijvlak van organisatie en ICT.
77
Hoofdstuk 8 Regionalisering brandweer vraagt keuzes in bedrijfsvoering Arend de Jong16
Regionalisering: het wiel opnieuw gebruiken Regionalisering noopt de brandweer tot keuzes voor gemeenschappelijke bedrijfsvoeringsystemen: de informatievoorziening voor primaire en ondersteunende processen. Daarbij kan de brandweer ervaringen van andere organisaties benutten die soortgelijke veranderingen hebben doorgemaakt. Om de veiligheid te verbeteren werken inmiddels17 15 van de 25 veiligheidsregio’s aan de regionalisering van voorheen lokale brandweerkorpsen. Dit sluit aan op de doelstelling van de minister van Binnenlandse Zaken: het versterken van de rampenbestrijding. Eén van de pijlers van dit beleid is die regionalisering van de brandweerkorpsen. Bestuur en de directie van korpsen en regio’s moet nu keuzes gaan maken over het ontvlechten en recombineren van de bedrijfsvoering en bijbehorende informatievoorziening: hoe ondersteunen we maximaal het redden, blussen en de rampenbestrijding? Hoe sturen we dit aan? Hoe werken we samen met partners? Hoe gebruiken we landelijke administraties? Herinrichten van de informatievoorziening is een grote uitdaging, maar ook één waar andere organisaties, zoals gemeenten, al de nodige ervaring mee hebben opgedaan. Brandweerregio’s kunnen daarvan profiteren.
Achtergrond: van lokaal naar regionaal De brandweer, die wettelijk verantwoordelijk is voor de rampenbestrijding, is momenteel sterk gedecentraliseerd en qua informatievoorziening versnipperd. Dat staat effectieve samenwerking en operationeel optreden bij grote calamiteiten in de weg. Daarom is de wet op de Veiligheidsregio opgesteld die er voor moet zorgen dat er op regionale schaal een organisatie komt die voorbereiding en uitvoering van het veiligheidswerk voor alle gemeenten in de regio coördineert en groten-
16 17
dit hoofdstuk verschijnt eind 2008 als artikel Zomer 2008
78
deels ook verzorgt: de veiligheidsregio. En hoewel de wet nog in behandeling is worden inmiddels in 15 regio’s al stappen ondernomen om de lokale krachten te bundelen.
Eisen aan de professionele organisatie De brandweer heeft al jaren geleden onderkend dat een professionele organisatie een noodzakelijke voorwaarde is om effectief te kunnen opereren. Dat geldt niet alleen voor de brandweerlieden en hun leidinggevenden maar ook voor de bedrijfsvoering. Zo is in het kader van kwaliteitszorg op basis van INK, het landelijke normenboek in 2006 vernieuwd. Het normenboek biedt concrete kaders, onder meer voor bedrijfsvoering en informatievoorziening. Het maakt qua bedrijfsprocessen onderscheid in: Extern gerichte primaire processen: preventie, respons/repressie, pro-actie en grootschalig gezamenlijk optreden; Intern gerichte primaire processen: preparatie/opleiden, trainen en oefenen, nazorg, evalueren/leren; Ondersteunende processen: HRM, financiën, huisvesting, materieel, ICT, administratie, juridisch, … Verder is er op gebied van bedrijfsvoering een raamwerk ontwikkeld voor sturing op basis van prestaties en kwaliteit (project Aristoteles). Dit sturen gebeurt met een landelijk Model Productbegroting en Kwaliteitszorg als instrument. Daarin zijn de hoofdonderdelen: personen, materiaal, geoefendheid en processen. Deze onderdelen zijn te relateren aan de elementen uit het normenboek. De informatiehuishouding is de rode draad die de primaire processen met elkaar verbindt. De regionalisering vereist daarom het herijken van die informatiehuishouding. Ook de wet op de veiligheidsregio benoemt de taak om te zorgen voor een goede informatiehuishouding in de regio: “Het inrichten en in stand houden van de informatievoorziening binnen de diensten van de veiligheidsregio en tussen deze diensten en de andere diensten en organisaties die betrokken zijn.” Bron: BZK, wetsvoorstel Veiligheidsregio, 2007, artikel 9, lid i
Dit betekent dat de regionale informatiehuishouding op niveau gebracht moet worden om hierin te voorzien. Dus verdere professionalisering op dit punt, bijvoorbeeld in het kader van project Aristoteles. Maar daarmee begint het pas… 79
Want zo mogelijk nog belangrijker is dat de regionale bundeling tot gevolg heeft dat de bedrijfsvoering van de (gemeentelijke) korpsen moet worden ontvlochten en opnieuw gecombineerd in een regionaal verband. “Alleen een brandweerorganisatie die haar eigen huis op orde heeft, is in staat om op multidisciplinair niveau mee te draaien” Bron: NVBR, reactie op wetsvoorstel Veiligheidsregio, 2007
Dit levert voor de directies van de veiligheidsregio’s stevige vragen op over hoe deze bedrijfsvoering in te richten. Uit ervaringen bij organisaties zoals gemeenten, blijkt dat bij het herijken van de bedrijfsvoering zich vijf thema’s aandienen waarop brandweerregio’s keuzes moeten maken voordat ze aan de slag gaan. Dit wiel is al eens uitgevonden. Regio’s kunnen hiervan profiteren door bewust stil te staan bij de volgende keuzes.
Keuze 1: doen we het of doen we het niet? Het bestuur heeft het besluit tot regionaliseren genomen. De eerste vraag die men zich moet stellen is of men daadwerkelijk de bedrijfsvoering wil integreren of dat men liever op de huidige manier doorgaat. In principe is het denkbaar om, in ieder geval voor een overgangsperiode, ‘door te modderen’ met de huidige procedures en de huidige systemen en alleen een soort financiële verrekening op te zetten. Vanuit ervaringen bij onder meer gemeenten en andere overheidsorganisaties, blijkt echter dat dit laatste niet wenselijk is. Zonder gezamenlijke bedrijfsvoering is het vrijwel onmogelijk om beleid te voeren en verzandt ieder initiatief in uitvoeringsproblemen. Er moeten wel duidelijke keuzes gemaakt worden, om te beginnen door het vaststellen van de uitgangspunten: waartoe dient de (gezamenlijke) bedrijfsvoering en waar ligt de nadruk: verlagen van kosten, vergroten van stuurbaarheid of kwaliteit van verantwoording/transparantie. “Door samenwerking zijn we beter in staat om de continuïteit van dienstverlening te garanderen. Daarnaast is lastenverlichting eenvoudiger te realiseren.” J. Marcic, kwartiermaker shared service center gemeente Oosterhout en omgeving
80
Er is dan ook winst te behalen. Om het maar eens scherp te stellen: er wordt nu teveel (onnodig) handmatig administratief werk verricht. Bijvoorbeeld: gegevens van meldingen uit meldkamer en van operationele eenheden worden veelal nog handmatig ingevoerd. Dat is tijdrovend, vergroot de kans op fouten en is ook niet erg motiverend werk. De regionalisering is hét moment om processen en informatie te stroomlijnen. Of denk aan registratie van gebouwen: bij één op de zeven inspecties blijkt dat een pand gesloten is of van eigenaar veranderd is. En willen we alleen gebouwen administreren met vergunningen of zijn juist ook de slooppanden interessant in het kader van de veiligheid? Of denk aan informatie van personeel dat in drie of meer systemen tegelijk wordt bijgehouden, met alle gevolgen van dien. Op gebieden waar wel verbanden tussen systemen zijn gelegd, functioneren die lang niet altijd foutloos en zonder haperen. Kortom: er is een wereld te winnen door de informatiehuishouding beter te organiseren en de regionale heroriëntatie is daarvoor een prima moment.
Keuze 2: bepalen scope Hoewel het perspectief er mogelijk eenvoudig uitziet, is het vormen van een gemeenschappelijke bedrijfsvoering verre van eenvoudig. Immers, in de huidige situatie zijn er verschillende administraties, werkprocessen, afspraken en systemen, en die passen nooit ‘zomaar’ op elkaar. We gaan er daarbij van uit dat de bereidheid tot samenwerking er is en dat daarvoor ook de middelen beschikbaar zijn; als dat niet het geval is dan zijn er nog veel meer potentiële struikelblokken… Bij de brandweer kunnen een drietal domeinen worden onderscheiden in de bedrijfsvoering: financiën, personeel en materieel & logistiek, met daarbinnen weer specifieke onderdelen. Voor de veiligheidsregio geldt dat naast de Regionale Brandweer vaak nog twee andere begrotingsprogramma’s spelen, te weten: Meldkamer Ambulancezorg/RAV en GHOR. Ook die onderdelen kennen hun eigen specifieke domeinen.
81
Ieder domein heeft z’n eigen karakteristieken, z’n eigen uitdagingen: Verschillen in grondslagen van de administraties. Zo wordt de basis van de financiële administratie gevormd door het rekeningschema en de kostenplaatsstructuur, en deze verschillen vaak tussen organisaties; Verschillende inrichting van de werkprocessen. Bedrijfsvoeringsystemen zijn (per definitie) procesondersteunende systemen; als deze sterk verschillen is het vaak moeilijk ze uniform te ondersteunen; Verschillende financieringsbronnen hebben ook hun eigen kenmerken: gemeenten, het ministerie van BZK, verzekeraars… Verschillende applicaties die worden ingezet, en als er al eenzelfde applicatie wordt gebruikt is de inrichting vaak zeer verschillend. Zo gebruikten diverse stadsdelen in Amsterdam SAP als financieel systeem maar met een zodanig verschillende inrichting dat er toch geen synergie was; De samenhang tussen delen van de administratie is niet duidelijk. De verschillende ‘silo’s’ binnen de bedrijfsvoering (financiën, personeel en materieel & logistiek) vormen verschillende afdelingen binnen de organisatie en worden ook vaak in isolement geautomatiseerd; het is vaak moeilijk om de samenhang helder te krijgen en ervoor te zorgen dat de processen en de ondersteunende systemen goed op elkaar aansluiten (zie hiervoor ook hoofdstuk 10 van dit boek over de applicatie-architectuur van het ROC van Amsterdam); Koppelingen tussen applicaties moeten opnieuw worden gebouwd, of herzien; Licenties van software zijn onduidelijk, zowel wat er is als wat er zou moeten zijn, contracten en financiële verrekenmodellen zijn vaak onbegrijpelijk;
82
De ‘harde’ techniek is niet inzichtelijk. Het is onduidelijk wat er nu is en wat de impact van consolidatie is op werkplekken, servers en netwerken. De complexiteit is groot en wordt mede veroorzaakt door: Onderdelen van de bedrijfsvoering die door processen en informatievoorziening onderling afhankelijk zijn maar niet zijn afgestemd; Onderdelen van de administratie die bij de verschillende korpsen op een andere manier zijn ingevuld en daardoor niet zomaar zijn te combineren. Complexiteit is kostbaar, werkt vertragend en veroorzaakt fouten. Alle reden dus om een opschoningslag te plegen. Bij de regionalisering is het zaak een duidelijke lijn voor de inrichting uit te zetten.
Keuze 3: organisatorische inrichting en criteria Waar wordt de bedrijfsvoering organisatorisch belegd in de nieuwe situatie? De gangbare varianten hiervoor zijn: Kleine staf centraal, uitvoering decentraal; Staforganisatie voor uitvoering centraal; Beleid centraal, Shared service center voor de uitvoering (voor één of meerdere regio’s). De ervaring in andere organisaties leert dat diverse tussenvarianten denkbaar zijn, er kan zelfs per onderdeel een keuze gemaakt worden. In het kader van het al uitgevonden wiel: de regio doet er goed aan de inrichting zo eenvoudig en transparant mogelijk te houden. De benodigde tijd en moeite voor het managen en onderling afstemmen van een heel palet aan deeloplossingen wordt vaak onderschat. Voor zo’n duidelijke keuze is een goed gedefinieerde doelstelling nodig: wat moet de nieuwe inrichting opleveren? Ook hier is al ervaring opgedaan: het najagen van uitsluitend kostenreductie leidt vaak tot teleurstelling: de reductie valt tegen (of er is zelfs sprake van kostenstijging) en de bedrijfsvoering lijdt eronder. Immers: streven naar zo laag mogelijke kosten gaat ten koste van flexibiliteit en de mogelijkheden om op de specifieke situatie in te spelen. Effectieve criteria voor het vergelijken van varianten voor de inrichting blijken te zijn: enerzijds de bijdrage aan de doelstelling (de effectiviteit) en anderzijds de eenvoud van invoering (hierbij speelt ondermeer de betrokkenheid van het personeel). Een keuzematrix kan er dan als volgt uit zien: 83
In dit voorbeeld blijkt dat het handhaven van de bestaande situatie weliswaar op korte termijn het eenvoudigst is te realiseren maar dat het nauwelijks bijdraagt aan de doelen van de regio. De andere varianten dragen veel meer bij, daar zien we dat juist eenvoud van implementatie een belangrijke factor is. Goed gedefinieerde doelstellingen maken het mogelijk om een afgewogen keuze te maken. Voorbeelden van doelstellingen zijn in dit kader: Kunnen voldoen aan de behoefte voor management- en stuurinformatie; Verbetering van kwaliteit van dienstverlening aan de diensten; Bijdrage leveren aan de ‘strategische fit’ van bedrijfsvoering met de primaire doelstellingen van de regio. Bovenstaande geldt overigens voor zowel de bedrijfsvoering zelf als voor de informatiesystemen: het is goed mogelijk om bijvoorbeeld te werken met een interne centrale organisatie voor bedrijfsvoering, die gebruik maakt van volledig uitbestede informatiesystemen. Een aspect dat daarbij ook een belangrijke rol speelt, is de sturing op deze gezamenlijke voorzieningen: wie vraagt, wie beslist, wie regisseert, wie gebruikt en wie betaalt? Ook hierin zijn verschillende varianten denkbaar. Vanuit de praktijk is het advies om de sturing op de informatievoorziening in lijn te brengen met de financiële sturing, gekoppeld aan de Planning & Control cyclus.
84
Keuze 4: systeemtransitie: van A naar Brandweer Het perspectief van een gezamenlijke soepel lopende en kosteneffectieve bedrijfsvoering is aanlokkelijk. Het vraagt wel een duidelijke aanpak om zo ver te komen. Zoals geschetst zijn er de nodige barrières te overwinnen. Duidelijke doelstellingen dragen bij aan de transitie. De overgang vraagt om een integrale, dus afgestemde, aanpak op de volgende sporen: 1. Processen: afstemmen en opschonen van werkprocessen; 2. Organisatie: toewijzen van taken uit die processen aan onderdelen van de organisatie; 3. Personeel: zorgen dat de juiste mensen op de juiste plaats zitten, goed gekwalificeerd, ondersteund door opleiding, instructie en support; 4. Informatie/administratie: inrichten van de administraties en informatiehuishouding zo dat de delen op elkaar aansluiten en goed samenwerken; 5. Techniek: garanderen dat het werkt, volgens afgesproken servicenormen. De meeste regio’s komen uit een startsituatie waarbij korpsen de lokale administratie bij de gemeente laten meelopen of zelf daarvoor iets hebben aangeschaft/ingericht. Bij de regionalisering is de startsituatie dus een lappendeken. Naast de eerder genoemde complexiteit en directe kosten zijn er nog andere argumenten om die deken zo snel mogelijk op te ruimen: uit oogpunt van transparentie, eenduidig gebruik en uitwisseling van informatie is het onverstandig om meerdere systemen naast elkaar te laten bestaan. Zeker als die grotendeels functioneel vergelijkbaar zijn. Het is dus noodzakelijk de transitie te maken naar één of enkele systemen. Zo’n transitietraject voor de informatiesystemen kan op een aantal manieren worden aangevlogen:
1. Eén van de systemen leidend maken en de andere één voor één overhevelen
Vergunning-1
Vergunning-1
Vergunning-2
Vergunning-2
Vergunning-3
Vergunning-3
Scenario 1
85
Vergunning-2
2. Eerst bestaande systemen grotendeels gelijktrekken, dan migreren;
Personeel-1
Personeel-1/2
Personeel-2
Personeel-2
Personeel-3
Personeel-3/2
Personeel-2
Scenario 2
3. Een totaal nieuw systeem inrichten en de andere afbouwen.
Financieel-1
Financieel-1 Financieel-3
Financieel-2
Financieel-3
Financieel-2
Scenario 3
De keuze voor bovenstaande scenario’s is afhankelijk van diverse factoren. Belangrijk zijn: Geschiktheid van één van de bestaande systemen: als een bekend systeem geschikt is of met redelijke inspanning geschikt gemaakt kan worden, heeft dat de voorkeur (scenario 1 of 2). Het risico is namelijk laag en vrij goed in te schatten. Ook is de ondersteuning door de leverancier een bekende factor. Die geschiktheid blijkt met name uit: o wat er bij de gemeentes wordt gebruikt. Gemeentes gaan niet op verzoek van de regio veranderen, de regio moet zo goed mogelijk aansluiten bij de realiteit en die is divers; o welke functionaliteit wordt het meest gebruikt en kunnen we dat samen doen; o welke aanvullende aspecten gelden bij deze keuze, zoals open standaarden/open source. Gewenst tempo en omvang van de mismatch: als er naast het goede bestaande systeem nog één grote belangrijke administratie is die zo snel mogelijk geïntegreerd moet worden, dan heeft scenario 1 de beste papieren. Maar als juist de bedoeling is om zo snel mogelijk met geconsolideerde cijfers te komen, dan is scenario 2 te overwegen. Mits dat met relatief weinig inspanning mogelijk is want de aanpassingen zijn maar tijdelijk bruikbaar. De rest is weggegooid geld. Een andere reden om versneld afscheid te willen nemen van één systeem, is het vervallen van de ondersteuning, of aanhoudende technische problemen door veroudering. In scenario 1 kan dan zo
86
snel mogelijk dat bewuste onderdeel overgehaald worden, om daarna het oude systeem af te stoten. Het inrichten van een nieuw systeem is alleen maar zinvol als de eisen en wensen niet door een van de bestaande systemen kunnen worden opgelost, als alle bestaande systemen aan het eind van hun levensduur zijn, of als alle bestaande systemen onderdeel zijn van bijvoorbeeld gemeentelijke systemen, waar niet de hele brandweeradministratie op kan gaan draaien. Kan één en ander worden gerealiseerd binnen de bestaande contractuele kaders, of is een Europese aanbesteding nodig? Dit heeft grote invloed op het mogelijke tempo van de veranderingen, hoewel de mogelijkheden voor vlotte, interactieve aankoopprocessen tegenwoordig vaak groter zijn dan menigeen denkt (zie ook hoofdstuk 3 in dit boek over inkoop-aspecten van bedrijfsvoeringsystemen).
Keuze 5: de financiën. Gedeelde smart, halve smart? Een essentiële vraag is de financiering van deze ontwikkeling en van de exploitatie die daar uit volgt. Daarbij zijn drie punten van belang. Allereerst is het goed te bedenken dat 80% van de kosten van een informatiesysteem in de exploitatiefase van de levenscyclus vallen. Het kan dus heel interessant zijn om initieel extra te investeren als daarmee de exploitatie lager uitvalt. In die exploitatie moeten daarom álle kosten worden meegenomen om een goede vergelijking te kunnen maken. (Total Cost of Qwnership – TCO). Identificeren In de exploitatiefase zullen in principe ook de verwachte baten gerealiseerd worden. Dat beteEvalueren Legitimeren kent dat die baten vooraf realistisch gecalculeerd moeten zijn. De ervaring leert dat het nuttig en noodzakelijk is om bovenExploiteren Realiseren staande keuzes nog eens in dit licht te bekijken en een business case op te laten stellen, al is het maar op hoofdlijnen. het Cost Benefit Management Framework
Het tweede punt is de toerekening van de kosten aan de verschillende afnemers / diensten. Een van de belangrijkste struikelblokken bij samenwerking is dat de ene partij relatief meer baten incasseert terwijl 87
een andere partij vooral voor de kosten opdraait. Het is een gegeven dat die verhouding scheef ligt en daar zijn dus maatregelen voor nodig. Als niet van het begin af aan een gezonde grondslag met elkaar is afgesproken, gaat het mis op het moment dat de kosten expliciet worden en valt de beoogde samenwerking alsnog uit elkaar. Dit pleit voor transparantie aan de kostenkant (ook noodzakelijk voor verantwoording) voor een verrekensystematiek en voor een eenvoudig en herkenbaar tariefstelsel. Op termijn zou dit met de systematiek van de productbegroting van Aristoteles opgezet kunnen worden. Het derde aandachtspunt is de financiering van klein onderhoud, groot onderhoud / nieuwe releases en van vervanging. Dit wordt vaak vergeten. En zeker in overheidsorganisaties vraagt dit bijzondere aandacht. Immers: afschrijven en reserveren voor (3-jaarlijks) groot onderhoud vraagt extra aandacht. Bovendien is de vraag wie dat dan betaalt. Een handreiking: Klein onderhoud en ‘fixes’ komen ten laste van de jaarlijkse exploitatierekening; Groot onderhoud financieren uit een reservering die gevuld wordt uit een jaarlijkse bijdrage ten laste van exploitatie. We gaan er daarbij van uit dat het groot onderhoud gaat over noodzakelijke aanpassingen; Voor belangrijke wijzigingen/uitbreiding een (mini)businesscase opstellen. Daaruit blijkt namelijk wat nodig is, wie daar baat bij heeft, en zodoende kan bekeken worden wie deze extra’s gaat betalen. Aandachtspunt is ook hier weer: het geld voor een belangrijk uitbreidingsproject zal relatief eenvoudig te vinden zijn maar let op: elke verbouwing betekent ook een verandering van de exploitatiekosten. En vaak is dat een verhoging. Er moet dan ook heel goed bekeken worden hoe die meerkosten gedekt worden en of het verrekeningsmodel daarvoor mogelijk moet worden aangepast.
Conclusie Directeuren van veiligheidsregio’s en de managers bedrijfsvoering/IT staan voor een forse uitdaging: bestaande processen en administraties moeten omgevormd worden tot één gemeenschappelijke werkwijze met ondersteunende administratie, hiaten moeten ingevuld worden, werkprocessen en informatiesystemen moeten worden ingericht en aangepast, gegevens moeten overgezet worden. Dit is een tijdrovende en kostbare aangelegenheid. Andere organisaties hebben, door schade en schande, het wiel van samenwerking en gemeenschappelijke processen 88
en informatiesystemen uitgevonden. Het loont voor bestuur en directie van de veiligheidsregio dan ook zeker de moeite om vóóraf de hier beschreven vijf keuzes na te lopen en gezamenlijk een duidelijke lijn uit te zetten voor het traject in de regio. Dit voorkomt onnodige verrassingen en tegenvallers onderweg en biedt handvatten om het traject goed aan te sturen. De ervaringen van andere organisaties die op dit pad zijn voorgegaan, kunnen daarbij zeker helpen.
89
Hoofdstuk 9 Implementatie van een centraal HRMsysteem Jan Houben18
Strijd tussen divisies In de vergadering van de Raad van Bestuur van een grote onderneming is een conflict uitgebroken. Het gaat over de implementatie van een uniform HRM-systeem voor de personeels- en salarisadministratie. De directeur HRM en de directeur van de divisie Food (de op één na grootste divisie van de onderneming) liggen met elkaar overhoop over de wijze waarop het project verloopt en over de achterliggende keuzes. De directeur Food verwijt de directeur HRM dat hij een systeem doordrukt waar de grootste divisie (Non-Food) baat bij heeft, maar zijn divisie niet. Ook gelooft de directeur Food niet in de gebruikte projectmethodiek. De directeur HRM verwijt de directeur Food op zijn beurt dat deze niet voor het concern gaat, dat hij niet kan denken in het algemeen belang en dat hij onverantwoorde risico's neemt met betrekking tot de invoering door veel te weinig te willen testen.
Casus In veel grote ondernemingen wordt gecentraliseerd, zeker op het gebied van de ondersteunende taken. Vaak zijn die ondernemingen in het verleden tot stand gekomen via overnames en fusies. De verschillende divisies van zo'n onderneming hebben ieder hun eigen ondersteunende afdelingen en informatiesystemen, die op hun beurt vaak verschillende gegevensdefinities gebruiken. Het gevolg is dat de leiding van de totale onderneming (veelal de Raad van Bestuur) het in veel gevallen moet stellen met onbetrouwbare of moeilijk vergelijkbare gegevens. Zo is vaak niet duidelijk hoeveel medewerkers er nu precies bij de totale onderneming werken: in het ene personeelsinformatiesysteem worden de tijdelijke arbeidskrachten wel in het totale aantal medewerkers meegenomen, in het andere systeem juist niet. Dit maakt het onmogelijk de gegevens goed en snel te vergaren, laat staan te interpreteren. Onderhandelingen met de vakbond over CAO's bijvoorbeeld zijn moeilijk
18
dit hoofdstuk is eerder verschenen in het boek ‘De Kracht van Toewijding’, 2005
90
op hun gevolgen te beoordelen als niet eens exact bekend is hoeveel personeelsleden binnen de onderneming aan het werk zijn. Ook deze onderneming was ontstaan door een fusie van meerdere bedrijven, die ieder een eigen holding hadden met daaronder diverse werkmaatschappijen. In totaal ging het om meer dan vijftig werkmaatschappijen met meer dan tien verschillende informatiesystemen op personeels- en salarisgebied. Na de samenvoeging van de bedrijven blijkt het in de praktijk bijzonder moeilijk om goede gegevens over het personeelsbestand te leveren. Dit was de centrale afdeling P&O en de directeur HRM een doorn in het oog. Dat is goed te begrijpen omdat er belangrijke beslissingen van deze gegevens afhangen, zoals bijvoorbeeld de bijdrage van de verschillende bedrijven aan een noodzakelijke inkrimping van het aantal personeelsleden. Het beschikken over de juiste gegevens is dan van cruciaal belang. Een bekende en logische reactie van Raden van Bestuur in dergelijke situaties is de teugels aan te halen en zich te verzekeren van een centrale staf die hen de gevraagde gegevens wél kan leveren. Zo ook in dit geval. De centrale staf dient uiteindelijk een voorstel in voor een nieuw centraal HRM-systeem voor de divisie Non-Food, de grootste divisie van de onderneming. Na een uitgebreid selectietraject wordt een HRM-systeem gekozen dat het beste past bij de combinatie van ambitie en portemonnee. Er wordt een externe projectleider aangesteld die wordt ondersteund door de centrale ICT-afdeling en P&O-afdeling, en het project gaat van start. Er wordt een standaard projectaanpak gebruikt en er wordt een projectorganisatie ingericht met een stuurgroep, een projectgroep en een aantal werkgroepen. Tijdens het project worden diverse belangrijke hobbels genomen. Zo blijkt er in de loop van de jaren een wildgroei te zijn ontstaan aan diverse soorten regelingen voor o.a. overwerk en aanvullende salariscomponenten. In diverse werkmaatschappijen is daar maatwerk voor gebouwd op de bestaande informatiesystemen. Nu alle systemen worden vervangen door één nieuw systeem wordt duidelijk dat het nodig is de wildgroei te saneren; het totaal aan regelingen past niet in het nieuwe centrale systeem. De harmonisatie vindt in goed overleg plaats, en het aantal loononderdelen wordt teruggebracht tot een derde.
91
Human Resource Management-systemen HRM-systemen zijn informatiesystemen die het management ondersteunen om zo effectief en efficiënt met het menselijk kapitaal van de onderneming om te gaan. De oorsprong van de huidige generatie HRM– systemen ligt in de salarissystemen van de jaren zeventig en tachtig van de vorige eeuw, die tot doel hadden ervoor te zorgen dat het personeel tijdig en juist zou worden betaald. Daarvoor werd in die salarissystemen ook beknopte personeelsinformatie vastgelegd. Juist dat personeelsinformatiedeel is in de loop van de afgelopen dertig jaar uitgebreid met allerlei nieuwe mogelijkheden en toepassingen. Denk daarbij aan: ziekte- en verlofregistratie, formatieplaatsenbeheer, organisatieschema's, werving en selectie, competentiemanagement, opleidingen, beoordelings- en functioneringsgesprekken, vacaturebanken etc. Ook het salarisdeel heeft zich ontwikkeld. Vaak worden er in de arbeidsvoorwaarden zogenaamde cafetariamodellen toegepast, waarmee bijvoorbeeld vakantiedagen geruild kunnen worden tegen salaris en omgekeerd. De laatste jaren gaat het vooral om de toevoeging van e-HRM functionaliteit. Dat is functionaliteit die medewerkers in staat stelt om zelf rechtstreeks inzage te krijgen in delen van het persoonlijk dossier. Ook kan de medewerker daarmee een deel van de eigen gegevens beheren zoals zijn adres en bankrekeningnummer, maar ook het maken van een POP (persoonlijk ontwikkelplan) behoort tot de mogelijkheden. De huidige tendens om Shared Service Centra (SSC's) voor HRM in te richten is een belangrijke motor voor de verdere ontwikkeling van eHRM. E-HRM is voor SSC's een belangrijk hulpmiddel om het aantal contactmomenten te verminderen. Ook blijkt het bouwen van de resterende delen van het informatiesysteem langer te duren dan was afgesproken en moet het technische concept op een paar punten aanzienlijk worden bijgesteld. Er was weliswaar voor een standaardsysteem gekozen, maar dit bleek nog niet goed uitontwikkeld en de implementatiepartner had er weinig ervaring mee. Even ontstaat de dreiging dat het traject zal worden gestopt en de afwikkeling een vervelende juridische wending krijgt; in gezamenlijk overleg wordt echter besloten vooral op zoek te gaan naar de oplossing in plaats van een 'zwartepietenspel'. Dit draagt bij aan het nemen van deze hobbel en nadat een aantal keren is geschaduwdraaid, kan de divisie Non-Food inderdaad met het nieuwe systeem aan de slag. Binnen een jaar ontstaat de discussie of het niet raadzaam is de overige divisies (met andere productieprocessen en gewoonten) ook op te laten 92
gaan in het centrale systeem. Dat zal kostenvoordeel opleveren, betere managementinformatie en meer uniforme beloningsystematieken. Na veel discussie gaan de overige divisiedirecteuren akkoord, waarbij de directeur Food wel reserves heeft. Het vervolgproject start, maar het loopt niet echt vlotjes. Er ontstaan allerlei misverstanden zoals over de gevraagde bijdrage vanuit de lijnorganisatie van de divisie Food, de wijze waarop het project wordt aangestuurd, de prioriteitstelling, de oplevering van tussenproducten et cetera. Door de misverstanden ontstaat een enigszins geladen negatieve sfeer waarin de oorspronkelijke keuze ter discussie wordt gesteld. Het systeem zou te duur zijn voor de divisie Food, niet voldoende toegesneden op de functionele eisen van die divisie en niet flexibel genoeg. Bovendien zou de projectmatige aanpak veel te zwaar zijn en daardoor niet aansluiten bij de operationele, van-dag-tot-dag-mentaliteit van de divisie. Er ontstaat een impasse; er is een conflict aan de tafel van de Raad van Bestuur en de vraag luidt: hoe nu verder?
HRM-systemen en managementinformatie Managementinformatie kan zo eenvoudig en zo ingewikkeld gemaakt worden als de organisatie maar wil. Goede personeelsinformatie maakt daar altijd deel van uit. Informatie over ziekteverzuim, formatieplaatsen en personeelskosten zijn voor de organisatie van groot belang, al was het maar uit het oogpunt van kostenbeheersing. Ziekteverzuim is aan veel ingewikkelde regels onderhevig, wat nogal eens tot complexe overzichten leidt. Het lastige van informatie over de personeelskosten is dat die gebaseerd is op de combinatie van informatie uit minimaal twee systemen, namelijk het HRM-systeem en het financiële informatiesysteem. In de praktijk gaan de benodige personeels- en salarisgegevens maandelijks door de 'salarismolen' voor het berekenen en betalen van het juiste salaris, waarna de informatie over de gedane betalingen naar het financiële systeem gaat. De informatie over de personeelskosten wordt dan ook deels vergaard vanuit het financiële systeem. Het realiseren van de benodigde managementinformatie-overzichten vraagt niet alleen goed inzicht in de samenhang van de systemen, maar ook een stevige regie over de totstandkoming van de overzichten. Ook goede spelregels voor correcte en gedisciplineerde invoer van gegevens zijn onontbeerlijk.
93
Allereerst wordt er een bijeenkomst geregeld tussen de directeur HRM en de directeur Food met de externe adviseur die tot dan toe de rol van projectleider had vervuld. In die bijeenkomst wordt op het scherpst van de snede onderhandeld over het traject. Ten aanzien van het informatiesysteem wordt besloten dat divisie Food geen alternatief meer heeft en door moet gaan met de implementatie. Ten aanzien van het projectmatig werken wordt het project voor divisie Food losgemaakt van de overige divisies, waardoor de directeur Food beter de rol van opdrachtgever en verantwoordelijk manager kan vervullen. Bovendien is de divisie daardoor ook vrijer om meer risico's te nemen bij de implementatie dan door de centrale projectleiding wenselijk wordt geacht. Het projectbureau verleent nog wel ad hoc ondersteuning aan de implementatie, maar is niet meer primair verantwoordelijk. Zo gezegd, zo gedaan: het traject wordt uiteindelijk afgesloten met een succesvolle implementatie waarbij binnen de divisie Food nog wel geruime tijd enige weerstand tegen het systeem blijft bestaan. In de jaren daarna wordt de centralisatie van de salarisadministratie doorgezet, in belangrijke mate gefaciliteerd door het centrale informatiesysteem. Uiteindelijk doet een centrale administratie van beperkte omvang het werk voor alle divisies.
Analyse HRM-systemen zijn knooppunten van belangen en macht Raden van Bestuur van ondernemingen willen de beschikking hebben over juiste informatie omdat dat de enige weg is om een onderneming goed te kunnen besturen. Organisaties en hun informatievoorziening zijn echter van oorsprong vaak anders ingericht, wat de invulling van deze wens kan tegenwerken. De implementatie van een centraal HRM-systeem kent veel complicerende aspecten en zo'n systeem kent veel lagen. Het is ‘veranderen’ in de volle betekenis van het woord, waarbij verschillende thema’s een rol spelen. Een standaardsysteem dat nog niet uitontwikkeld was De keuze voor een standaardsysteem is inmiddels zo'n normaal uitgangspunt geworden voor bedrijven, dat het hier geen verdere toelichting behoeft. De aanschaf van een standaardsysteem dat nog niet volledig ontwikkeld is, is ook een klassiek verschijnsel, maar dan in negatieve zin. HRM-systemen hebben wat dit betreft een dubieuze reputatie; een voorbeeld is de vervanging van het IPA-systeem van de overheid en 94
de moeilijkheden die zich daarbij hebben voorgedaan. HRM-systemen zijn behoorlijk complex, de samenhang is groot en de gevolgen van foutieve salarisbetalingen zijn groot. Dat betekent dat er alle reden is bij de selectie van een HRM-systeem te kiezen voor bewezen performance. Toegesneden op de grootste divisie Het systeem was oorspronkelijk gekozen voor ondersteuning van het HRM-proces van de grootste divisie, de divisie Non-Food. Pas in een later stadium werd besloten dit systeem ook bij de andere divisies en werkmaatschappijen te gebruiken. Hier schuilt een belangrijke adder onder het gras omdat de keuze plaatsvond vanuit de eisen en wensen van één divisie. De Raad van Bestuur wil graag naar een centraal systeem en hoeveel ruimte is er dan nog voor de overige divisies om met eigen eisen en wensen te komen? Dat vraagstuk heeft veel te maken met de spelers in het spel en de aangehangen veranderstrategie.
`
“Invoering van een nieuw ERP-systeem: crisis verzekerd!”
95
Gaat het erom om veel draagvlak te verwezenlijken, dan zal rekening moeten worden gehouden met de wensen en eisen van de overige belanghebbende partijen. Anderzijds is beperking van de kosten een belangrijke reden om niet te veel aan 'kerstboombuilding' te doen. Speelt draagvlak geen dominante rol, dan is er meer ruimte om gebruik van een centraal informatiesysteem eenvoudigweg af te dwingen. Soms leidt dat tot willekeur of tot keuzes die vooral vanuit de techniek gedreven zijn, soms ook is het een prima middel om paal en perk te stellen aan onnodige wensen vanuit de organisatie. Het 'not invented here'-syndroom speelt nogal eens mee, als eerder geselecteerde systemen in een latere fase gebruikt moeten worden door andere divisies. Zeker als er tussen divisies in een onderneming een competitieve sfeer bestaat. In een dergelijke setting heeft de keuze van een informatiesysteem niet louter een inhoudelijke, maar ook relationele betekenis. Soms moét een dergelijk traject wel mislukken, als alle krachten tegen het project werken. Verdere ontwikkeling van de onderneming De verdere ontwikkeling van de onderneming compliceerde overduidelijk het project. In de casus doet zich het interessante feit voor dat er een wijziging van de organisatie werd uitgevoerd tijdens het totale ontwikkel- en implementatietraject. Daardoor veranderden de stakeholders ten opzichte van het informatiesysteem. Aanvankelijk was de onderneming geografisch opgedeeld en waren de managers van de oorspronkelijke bedrijven integraal verantwoordelijk voor alle productsoorten. Daarna vond er binnen de onderneming een kanteling plaats van geografische oriëntatie naar productoriëntatie. De daarbij ontstane divisie Food was bij de selectie van het HRM-systeem geen partij geweest. Na de kanteling keken managers meer vanuit de producten naar de selectie van informatiesystemen. En verdween de invalshoek van de integrale managers uit het interne belangenspel. De balans tussen de stakeholders veranderde dus wezenlijk, terwijl de uitgangspunten van het implementatietraject niet opnieuw ter discussie werden gesteld. Achteraf gezien kan worden gesteld dat dit de implementatie bij de overige divisies aanzienlijk compliceerde. Projectmatige aanpak Adviseurs en IT-ers zijn eraan gewend om projecten met behulp van standaard projectmethodieken te managen. Wie dat dagelijks doet realiseert zich daardoor vaak onvoldoende dat iedere methodiek waarden met zich meebrengt die niet voor iedereen vanzelfsprekend zijn. Ook dat wordt natuurlijk sterker in een project waarin competitieve ele96
menten tussen divisies een rol spelen. Keuzes voor of tegen een methodiek spelen dan een rol in het relationele machtsspel tussen de divisies. Ook los daarvan is het goed voorstelbaar dat een bepaalde projectmethodiek beter aansluit bij bepaalde bedrijfsculturen en minder bij andere. Een keuze voor een bepaalde methodiek is daarmee niet neutraal, maar roept reacties op. Het maakt verschil of de methodiek door de organisatie zelf is bedacht en voorgeschreven of dat deze met het project meegekomen is en nieuw is voor de organisatie. In de casus was de cultuur in de bedrijven die recent in de divisie Food waren samengevoegd gekleurd door de markt waarin werd gewerkt. Deze was gericht op de korte termijn met kleine marges, waardoor het niet gebruikelijk was structureel te investeren in de ondersteunende processen en systemen. De projectmatige aanpak hield in dat het werk dat gedaan moest worden zoveel mogelijk van te voren gepland werd. Dit sloot niet aan bij de gebruikelijke werkwijze van de divisie Food, waar men gewend was projecten in tijdspannes van weken uit te voeren en niet van maanden. En dat was wel het uitgangspunt van het HRMtraject. De werkzaamheden die voor de divisie Food gepland stonden, werden door de divisiemedewerkers niet of onvoldoende uitgevoerd. Er was immers nog tijd genoeg. Het gevolg was dat er een stuwmeer ontstond van activiteiten die in de laatste maand nog moesten worden uitgevoerd. Het gevolg was spanning in het project, wat uitliep op het conflict in de Raad van Bestuur. Centralisatie van de gegevensvoorziening Het implementeren van een centraal en uniform HRM-systeem impliceerde een centralisatie van gegevens en informatie die de Raad van Bestuur in staat zou stellen de 'control'-taken beter uit te voeren. De veelgehoorde opvatting is dat een dergelijke centralisatie de taak van de afzonderlijke divisies uit holt. Directies van divisies zijn meestal geen enthousiaste supporters van deze systemen. Een HRM-informatiesysteem is te bezien als een infrastructurele voorziening van de onderneming. Het stelt de organisatie in staat haar ondersteunende proces op ordentelijke wijze uit te voeren en de salarissen uit te betalen. Op het moment dat deze systemen in een grote onderneming worden gecentraliseerd moeten mensen en werkmaatschappijen afstand doen van hun bestaande systemen en een aantal zaken net even anders gaan doen. Vaak levert dat voordeel op voor het geheel en niet zozeer voor de afzonderlijke werkmaatschappijen, afhankelijk van de kwaliteit van het selectieproces en de discipline waarmee de 97
invoering ter hand wordt genomen. Dat werkmaatschappijen randvoorwaarden stellen aan centralisatie van informatiesystemen is dus voorstelbaar. Centralisatie van een HRM-systeem kan opgevat worden als een poging de autonomie van een werkmaatschappij te verkleinen en deze meer 'in het gareel' te zetten. Het spreekt voor zich dat een dergelijke beleving de nodige tegenkrachten zal oproepen, met complicaties voor de dynamiek van het project. (On)mogelijkheden van het informatiesysteem De beperking van het totale aantal loononderdelen dat kon worden geregistreerd in het systeem had veel invloed had op het project. Het bracht een reeks van gebeurtenissen op gang, waaronder een groot harmonisatietraject. Dit harmonisatietraject leidde tot vereenvoudiging van de verloning en had daarmee positieve invloed op de beheersbaarheid van het salaristraject. De regels voor het toekennen van loononderdelen werden strakker en de vrijheidsgraden om uitzonderingen toe te kennen namen evenredig af. De rechtmatigheid van de uitkeringen nam daarmee toe. Een nieuw centraal systeem had ook gevolgen voor de werkprocessen. Elke divisie had tot dat moment haar eigen werkprocessen, ontstaan in de afstemming met het divisionele informatiesysteem. Een nieuw centraal systeem kon per definitie niet de werkprocessen van alle afzonderlijke divisies ondersteunen, dus er moesten keuzes worden gemaakt. Soms kan dat ook expliciet de doelstelling zijn. Inkrimping van het personeelsbestand is dan een belangrijke doelstelling en het spreekt voor zich dat medewerkers heel anders tegen verandering van werkprocessen aankijken als daarmee hun eigen werkzaamheden aanzienlijk afnemen en er zicht is op opheffing van hun arbeidsplaats. Anderzijds kan aanpassing van de werkprocessen ook leiden tot hoogwaardiger en interessanter werk, omdat administratieve handelingen automatisch gaan plaatsvinden en er ruimte is de kwaliteit van de dienstverlening te verbeteren. De mogelijkheden van het informatiesysteem zijn hierbij van grote invloed.
De invloed van technologie Wat deze casus duidelijk aantoont, is dat technologie en menselijke interventie nauw verweven zijn. Technologie en sociale interactie kunnen worden beschouwd als één: technologie werd gebruikt om centralisatie door te voeren en had daarmee een actieve rol in het aanwezige 98
krachtenspel. De implementatie van het nieuwe HRM-systeem was dus niet alleen een technische oefening, maar had betekenis in de sociale interactie tussen actoren. Soms is die betekenis expliciet en makkelijk in te schatten, soms gaat het om impliciete waarden die pas in de loop van een project zichtbaar worden. In de casus is dat het geval met de impliciete waarden van de gehanteerde projectmethodiek. Door de centralisatie van het HRM-systeem werden die waarden binnengebracht in een divisie waar dat niet meteen paste. Geen wonder dat er wrijving ontstond. De eigenschappen van het informatiesysteem (onder meer als gevolg van technische beperkingen) hadden een enorme invloed op de beschikbaarheid van loononderdelen. Deze eigenschappen veroorzaakten een traject van harmonisatie dat anders nooit ingezet zou zijn. Daarbij bepaalde de omvang van de beschikbare loononderdelen direct de mate van benodigde harmonisatie. Het dwong alle betrokkenen om samen te werken, bij elkaar 'in de keuken te kijken' en samen te beoordelen welke loononderdelen gehandhaafd moesten worden. Het bracht daarmee een prachtig samenwerkingsproject op gang, dat gedurende het traject op uitvoeringsniveau veel praktische verbindingen tussen mensen opleverde.
99
Hoofdstuk 10 Applicatie-architectuur bij het ROC van Amsterdam Hans Doffegnies (ROC van Amsterdam) en Jaap de Mare19
Ambities ROCvA De maatschappelijke uitdagingen in het MBO (Middelbaar Beroeps Onderwijs) zijn groot, en de ambities van het ROC van Amsterdam sluiten daarop aan. De uitval moet worden teruggedrongen en de leerroute moet worden geïndividualiseerd. Dat vereist een goed zicht op studievoortgang en aanwezigheid en verzuim enerzijds en een flexibele onderwijslogistiek en goede begeleiding anderzijds (waarbij de coach of mentor gemakkelijk toegang moet krijgen tot de relevante gegevens). De introductie van Domeinen als organisatieprincipe dwars over de huidige werkmaatschappijen heen vereist een grote uniformiteit in manier van werken en administreren. De overheid (ministerie, inspectie, gemeente) stelt steeds hogere eisen aan de verantwoording en tegelijk is het streven meer ‘handen voor de klas’ te krijgen. En ouders en studenten worden steeds veeleisender en verwachten realtime toegang via internet tot relevante informatie. Allemaal uitdagingen die een hoogwaardige ICT-ondersteuning vereisen van zowel de onderwijs processen als de ondersteunende processen. Een overkoepelende architectuur waarin applicaties ‘hun plekje hebben’ en goed met elkaar worden geïntegreerd is hierbij van cruciaal belang. Het ROC van Amsterdam (ROCvA) is, zoals de meeste ROCs, eind jaren negentig ontstaan uit een veelheid van bestaande beroepsopleidingen (zie kader) In de jaren na de fusies gold binnen het ROCvA het adagium ‘decentraal, tenzij …’. De vergelijking van de organisatie was (en is nog steeds) die met een van vloot schepen die elk zelfstandig varen, maar wel in dezelfde richting. Deze strategie werkte die op organisatorisch gebied goed, maar maakte het moeilijk om op ICT-gebied – en vooral op het gebied van de bedrijfsvoeringsystemen - vergaande verbeteringen door te voeren. Want onder ICT’ers geldt het adagium ‘wie verantwoordelijkheden wil decentraliseren én synergie wil bereiken moet systemen centraliseren’. En dat gebeurde niet voldoende.
19
dit hoofdstuk is gebaseerd op een artikel in de Profiel van november 2007. Jaap de Mare is adviseur bij M&I/Partners en is ad-interim Informatiemanager van het ROC van Amsterdam. Hans Doffegnies is directeur ICT van het ROC van Amsterdam
100
Voor sommige zaken werden centrale systemen ingericht, bijvoorbeeld voor de studentenadministratie (PeopleSoft - voor de bekostingsgerelateerde gegevens), de financiële administratie (Exact), de salarisadministratie (Edukaat) en een elektronische leeromgeving (Blackboard). Op de overige terreinen lag het primaat bij de onderwijsteams en werd er niet of nauwelijks geüniformeerd. Onderwijsondersteunende processen als resultaatbeheer, aanwezigheidsregistratie, roostering, stages, relatiebeheer et cetera, werden in verschillende organisatie-onderdelen door verschillende applicaties ondersteund. Belangrijke functionele gebieden werden niet of nauwelijks ondersteund: studentvolgsysteem, studentportal, docentenportal, deelnemer self-service, etc.. Ook waren de verschillende processen slechts in beperkte mate geüniformeerd – hetgeen een belemmering vormt voor het effectief gebruik van centrale systemen. En ook de integratie van systemen liet te wensen over: sowieso waren weinig applicaties aan elkaar gekoppeld (ook waar dat wenselijk was), en áls ze geïntegreerd waren dan was dat op een wijze waarmee de integriteit van de data slechts met moeite gewaarborgd kon worden.
Nieuw beleid De organisatie onderkende dat deze situatie een rem vormde op de verdere ontwikkeling van het ROCvA. Nieuw beleid werd ontwikkeld en medio 2006 werd een informatiemanager aangesteld. Zijn belangrijkste opdracht was structuur aan te brengen in het applicatielandschap, vooral wat betreft de bedrijfsvoeringsystemen. Dit heeft tot de nodige beweging geleid: er is een applicatie-architectuur gedefinieerd, er is een proces afgesproken om nieuwe applicaties aan te schaffen, er zijn op tal van onderdelen projecten gestart die een grotere uniformiteit moeten realiseren, en er wordt gewerkt aan een andere manier om applicaties met elkaar te integreren.
Applicatiearchitectuur Wat is eigenlijk een architectuur? In de situatie van het ROCvA is het een serie principes die belichaamd worden in een plaatje dat het ‘applicatielandschap’ weergeeft. Deze principes zijn: 1. Verschillende onderdelen kunnen, als ze sterk van elkaar verschillen, met een verschillende architectuur werken. VMBO, MBO en Educatie (volwassenenonderwijs) verschillen dermate van elkaar dat het niet zinvol is ze allemaal in precies hetzelfde keurslijf te dwingen. Maar er is ook veel overlap!
101
2. Eén functioneel gebied moet liefst maar door één applicatie worden ‘afgedekt’. 3. Er worden enkele basisregistraties gedefinieerd: voor studenten (in PeopleSoft), voor medewerkers (in HR Access) en voor bedrijven & relaties (in Microsoft CRM). Deze basisregistraties moeten de ‘bron’ zijn van gegevens over deze entiteiten – dus in andere systemen mogen geen nieuwe deelnemers, medewerkers of relaties worden opgevoerd! 4. Er wordt niet gestreefd naar één allesomvattende omnipotente applicatie, maar naar verschillende applicaties voor verschillende functionele gebieden (‘best of breed’ strategie). Dat vereist wel dat applicaties goed met elkaar geïntegreerd moeten kunnen worden, en dat stelt eisen aan iedere applicatie die wordt ingezet. Hoewel dit vrij algemene principes zijn, blijken ze een hoop richting te geven aan de organisatie. Het resulteerde in elk geval in bijgaand overzicht, waarin de belangrijkste functionele gebieden staan weergegeven die Personen (studenten, medewerkers, relaties) betreffen.
Applicatie-architectuur ROCvA MBO (soll-situatie) Persoon-gerelateerde functionaliteiten Werving Bevat medewerkers
Gegevensuitwisseling met externe partijen
Bevat studenten
Medewerkeradministratie
Intake
Student-administratie
Relatie management
deelnemers
bedrijven
Medewerkers
Salarisverwerking
Studentvolgsysteem / Portal
CMS
Kantoor automatisering
Bibliotheek / Mediatheek
Elektronisch toetsen
Resultaatbeheer
Stage registratie
Aanbod stages
Elektronische leeromgeving
Portfolio
Aanw/verzuim registratie
Planning & Roostering
Communicatie
Begeleiding & zorg
Alumni relaties
102
Toegang
ROC van Amsterdam Het ROC van Amsterdam is met 36.000 studenten (waarvan 10.000 volwassenenonderwijs en 1.800 VMBO-leerlingen) het grootste ROC van Nederland. Het ROCvA is in 1997 ontstaan uit ongeveer 50 rechtsvoorgangers en biedt een brede waaier aan opleidingen aan die sterk van elkaar verschillen op zo’n 50 locaties in de regio Amsterdam/Gooi.
Verleiden Wat betekent deze architectuur nu? Is het iets dat kan worden ‘uitgerold’ of ‘geïmplementeerd’? Is het iets dat in de loop van een jaar gerealiseerd moet zijn? Nee, dat is het niet. Het is een kompas dat een richting aanwijst, een stip aan de horizon, een referentiekader voor allerlei beslissingen die moeten worden genomen. Op basis van de architectuur is een serie projecten in gang gezet en zijn lopende projecten bijgestuurd: op het gebied van aanwezigheidsregistratie, resultaatbeheer, CRM, aanmelding en intake, digitaal dossier, roostering, ondersteuning Competentie Gericht Leren, et cetera. Deze projecten zorgen er voor dat er op de betreffende gebieden centrale applicaties komen die het onderwijs beter ondersteunen, en die goed geïntegreerd zijn met andere applicaties.
‘Best of breed’ versus omnipotente applicaties In het primair en voortgezet onderwijs wordt veel gebruik gemaakt van applicaties die alle aspecten van het onderwijs ondersteunen: leerlingadministratie, leerlingvolgsysteem, resultaatbeheer, et cetera. Omnipotente applicaties waarmee een school in één klap klaar is. In het MBO (en ook in het hoger onderwijs) zijn dergelijke applicaties er nooit gelomen. De opleidingen zijn dermate divers en stellen dermate verschillende eisen aan de ondersteuning dat applicaties die de volle breedte willen ondersteunen op een gegeven moment onder hun eigen gewicht in elkaar zakken. Dat gebeurde b.v. met Noise, dat ooit de pretentie had het onderwijs volledig te ondersteunen en nu hoofdzakelijk wordt gebruikt voor de bekostigingsgerelateerde studentadministratie. Daarom de keuze voor ‘best of breed’ applicaties: gespecialiseerde applicaties die een beperkt functioneel gebied afdekken.
103
Daarbij wordt de ‘techniek van de verleiding’ gevolgd: er wordt gezorgd voor één centrale applicatie die goed ontwikkeld en geïntegreerd is, zodat werkmaatschappijen en opleidingen deze applicatie wíllen gebruiken. Ze worden er niet (of nauwelijks) toe gedwongen. Alleen applicaties die nodig zijn voor de integratie worden verplicht gesteld, zoals bijvoorbeeld het CRM-systeem omdat dat een basisregistratie is. Al met al heeft het ROCvA hiermee belangrijke stappen gezet om tot een betere ICT-ondersteuning van het onderwijs te komen en zijn ambities te kunnen realiseren.
104
Over M&I/Partners M&I/Partners acteert op het snijvlak van organisatie-inrichting en informatievoorziening. We brengen de logische samenhang in beeld tussen mensen, processen en systemen, geven aan hoe informatieprocessen optimaal ingericht kunnen worden en zorgen voor een vlekkeloze transitie van oud naar nieuw. M&I/Partners is een onafhankelijk adviesbureau met ruim zestig adviseurs.
M&I/Partners helpt bij het verbeteren van de bedrijfsvoering M&I/Partners heeft veel ervaring in het vormgeven, sturen en richting geven van projecten ter verbetering van de bedrijfsvoering, o.a. op de volgende gebieden: • bij de beleidsvorming, het formuleren van een uitdagende maar ook haalbare strategie, • bij de kaderstelling van projecten: wat willen we bereiken en wat is daarvoor nodig? • bij de selectie en aanschaf van de benodigde ICT-middelen (zowel technisch, functioneel als juridisch), • bij de projectvoering, implementatie, het verandermanagement, • bij het informatiemanagement: hoe zorgen we ervoor dat al die verschillende initiatieven samen een geheel vormen? • outsourcing en insourcing: het begeleiden van organisaties op een weg vol valkuilen. Voor meer informatie kunt u contact opnemen met dr. Bert Melief, (033) 4.220.220,
[email protected], of kijk op www.mxi.nl.
Dit betekent dat bedrijfsvoeringsystemen weer helemaal ‘hot’ zijn. Deze werkpaarden van de automatisering waarmee de processen worden ondersteund waren enkele decennia geleden zo’n beetje de eerste toepassingen van ICT die brede invoering vonden. En nu staan ze weer helemaal in het centrum van de belangstelling om het organisaties mogelijk te maken het internet-tijdperk te betreden. M&I/Partners heeft veel ervaring met bedrijfsvoeringsystemen. Hierover hebben wij de afgelopen jaren gepubliceerd in diverse tijdschriften, en deze publicaties zijn de basis van dit boek.
Voorbeelden uit de gemeentelijke overheid, sociale zekerheid, de industrie, het onderwijs en de openbare orde en veiligheid laten zien wat er zoal goed en fout kan gaan bij pogingen om met ICT de operatie te verbeteren, waar de kansen liggen en welke valkuilen er zijn. Het pad naar operational excellence is kronkelig en leidt langs diepe ravijnen, maar voert uiteindelijk naar grote hoogte. Wandelaars doen er goed aan eerst deze gids te raadplegen.
M & I PA R T N E R S
Verschillende aspecten komen daarbij aan de orde. ICT is techniek, en de technologische ontwikkelingen zijn onstuimig geweest (en zijn dat nog steeds). Maar niet alle hypes beklijven, en het is nodig om kritisch te zijn ten aanzien van de gouden bergen die soms worden beloofd. ICT is ook veranderen, organiseren, managen, en ook dat is een belangrijke dimensie van ICT-projecten, zeker bij bedrijfsvoeringsystemen. En ICT is ook inkoop – een aspect dat vaak niet de aandacht krijgt die nodig is waardoor veel initiatieven een ‘valse start’ maken.
O P E R AT I O N A L E X C E L L E N C E V E R E I S T E X C E L L E N T E P R O C E S O N D E R S T E U N I N G
Operational Excellence is de norm. Steeds meer organisaties, ook in de publieke sector, willen hun dienstverlening via het internet aanbieden, en dat kan alleen als alles intern goed op orde is. Want om zaken te kunnen doen via internet moet de back-office naar de voorkant worden gehaald: de processen moeten worden geautomatiseerd (al dan niet met behulp van self-service door de klant) en de systemen moeten worden ontsloten.
Operational Excellence vereist excellente procesondersteuning De eisen aan bedrijfsvoeringsystemen worden steeds hoger
M&I/Partners is een onafhankelijk adviesbureau op het snijvlak van organisatie-inrichting en informatievoorziening. Zie www.mxi.nl.
Eindredactie: Jaap de Mare
De kracht van toewijding
H200 Omslag Boekje_OpExcll_ONT.indd 1
08-08-2008 15:48:38
