BiSL Scenario s. Leverancierssturing. Bijlage E Achtergronden. René Sieders, Remko van der Pols

BiSL Scenario’s

Leverancierssturing Bijlage E – Achtergronden

René Sieders , Remko van der Pols

Inhoud Bijlage E Achtergronden ..................................................................................................................... 1 E.1 Beheerdomeinen ......................................................................................................... 1 E.2 BiSL (Business information Services Library) ............................................................. 2 E.3 ASL (Application Services Library) .............................................................................. 3 E.4 ITIL (IT Infrastructure Library) ..................................................................................... 3 E.5 Specificeren ................................................................................................................. 5 E.6 Rollen en competenties ............................................................................................... 7 E.7 Openbaar aanbesteden en Prestatie-inkoop ............................................................ 12 E.8 De consequenties van outsourcing voor business informatiemanagement .............. 14

© 2015 René Sieders, erven Remko van der Pols Academic Service is een imprint van Boom uitgevers Amsterdam. Alle rechten voorbehouden. Alle intellectuele eigendomsrechten, zoals auteurs- en databankrechten, ten aanzien van deze uitgave worden uitdrukkelijk voorbehouden. Deze rechten berusten bij Boom uitgevers Amsterdam en de auteur. Behoudens de in of krachtens de Auteurswet gestelde uitzonderingen, mag niets uit deze uitgave worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand of openbaar gemaakt in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopieën, opnamen of enige andere manier, zonder voorafgaande schriftelijke toestemming van de uitgever. Voor zover het maken van reprografische verveelvoudigingen uit deze uitgave is toegestaan op grond van artikel 16 h Auteurswet, dient men de daarvoor wettelijk verschuldigde vergoedingen te voldoen aan de Stichting Reprorecht (Postbus 3051, 2130 KB Hoofddorp, www.reprorecht.nl). Voor het overnemen van gedeelte(n) uit deze uitgave in bloemlezingen, readers en andere compilatiewerken (artikel 16 Auteurswet) dient men zich te wenden tot de Stichting PRO (Stichting Publicatie- en Reproductierechten Organisatie, Postbus 3060, 2130 KB Hoofddorp, www.cedar.nl). Voor het overnemen van een gedeelte van deze uitgave ten behoeve van commerciële doeleinden dient men zich te wenden tot de uitgever. Hoewel aan de totstandkoming van deze uitgave de uiterste zorg is besteed, kan voor de afwezigheid van eventuele (druk)fouten en onvolledigheden niet worden ingestaan en aanvaarden de auteur(s), redacteur(en) en uitgever deswege geen aansprakelijkheid voor de gevolgen van eventueel voorkomende fouten en onvolledigheden. Application Services Library ASL® and BiSL® are registered trademarks of the ASL BiSL Foundation.

ii

BiSL Scenario’s – Leverancierssturing

Bijlage E

Bijlage E Achtergronden E.1

Beheerdomeinen

Afgeleid van het model van Looijen (figuur 1), onderscheiden we drie beheerdomeinen (figuur 2).

Figuur 1 Het model van Looijen

Figuur 2 De drie beheerdomeinen

Business informatiemanagement Business informatiemanagement (Functioneel beheer en Informatiemanagement) is namens de gebruikersorganisatie verantwoordelijk voor het in standhouden en aansturen van de informatievoorziening van een organisatie. Vanuit het perspectief van de gebruikersorganisatie en het bedrijfsproces richt men zich daarbij op de informatievoorziening die de organisatie en het bedrijfsproces ondersteunt Het framework voor dit domein is BiSL: Business information Services Library. IT-infrastructuurmanagement IT-infrastructuurmanagement (technisch beheer) is verantwoordelijk voor de instandhouding, het beheer en het onderhoud van de technische infrastructuur. Deze infrastructuur bestaat uit alle te gebruiken automatiseringsmiddelen voor het kunnen opslaan, verwerken en transporteren van gegevens en het voorzien van informatie. Het bestaat uit de technische componenten van het geautomatiseerd informatiesysteem, de apparatuur, basisprogrammatuur en communicatievoorzieningen, inclusief van toepassing zijnde procedures en documentatie. Bovendien is IT-infrastructuurmanagement verantwoordelijk voor de installatie en exploitatie van e productiebestanden en productiesoftware (exploitatie en beschikbaarstelling). Het gaat hierbij dus om het aandachtsgebied van het rekencentrum of IT-centrum. Een veel gebruikt framework voor de inrichting van het technisch beheer is ITIL: Information Technology Infrastructure Library.

© 2015 Academic Service

1


Bijlage E

Applicatiemanagement Applicatiemanagement (applicatiebeheer) houdt zich bezig met de instandhouding van de toepassingsprogrammatuur en de gegevensverzamelingen. Applicatiebeheer komt overeen met de functie van een softwarehuis: het maken, onderhouden en aanpassen van applicatieontwerpen en programmatuur. Voor het inrichten van het applicatiebeheer is ASL de standaard: Application Services Library.

E.2

BiSL (Business information Services Library)

BiSL is het public domain model voor business informatiemanagement (functioneel beheer en informatiemanagement). BiSL is ontwikkeld in Nederland en daar inmiddels gemeengoed. De spreiding buiten Nederland is erg klein, maar wel groeiende. Grote organisaties in Nederland die BiSL gebruiken zijn o.a. Politie, Defensie, Achmea, ASR, Heijmans, UWV, de Ministeries van Financiën (inclusief Belastingdienst), Infrastructuur en Milieu (inclusief ILT), Onderwijs (inclusief DUO) en VWS, universiteiten en hogescholen. Het BiSL-model en gedachtegoed is in boekvorm in 2005 verschenen. Vanaf dat moment zijn ook veel best practices op het gebied van business informatiemanagement verzameld en verspreid. In het BiSL-model zijn alle processen benoemd voor business informatiemanagement: zowel op richtinggevend niveau als op sturend en uitvoerend niveau. De organisatie die BiSL beheert en het gedachtegoed en de best practices verzamelt en verspreidt is de ASL BiSL Foundation. Voor meer informatie zie: www.aslbislfoundation.org. Het model ziet er als volgt uit:

Figuur 3 Het BiSL-model


2


E.3

Bijlage E

ASL (Application Services Library)

ASL is het public domain model voor Applicatie Management (applicatiebeheer en onderhoud). ASL is ontwikkeld in Nederland en daar gemeengoed. De spreiding buiten Nederland is op wereldschaal klein, maar wel groeiende. Grote organisaties in Nederland die ASL gebruiken zijn o.a. Ordina, CapGemini, Politie, Defensie, Achmea, ASR, Heijmans, UWV en het Ministerie van Financiën. Gerelateerd aan het ASL-model is een NEN-norm voor applicatiemanagement ontwikkeld: de NEN 3434. Sinds 2008 loopt er een traject om de NEN 3434 “op te waarderen” tot een internationale ISOnorm: de ISO/IEC 16350. Deze verschijnt naar verwachting in de loop van 2015. Het ASL-model en gedachtegoed is in boekvorm in 2001 verschenen. Vanaf dat moment zijn ook veel best practices op het gebied van ASL verzameld. In 2008 is het model enigszins, maar de theoretische beschrijving in hogere mate, vernieuwd: ASL2. In het ASL-model zijn alle processen benoemd voor Applicatiemanagement: zowel op richtinggevend niveau als op sturend en uitvoerend niveau. Het ASL2 model ziet er als volgt uit:

Figuur 4 Het ASL2-model

De organisatie die ASL beheert en het gedachtengoed en de best practices verspreidt is de ASL BiSL Foundation. Voor meer informatie zie: www.aslbislfoundation.org.

E.4

ITIL (IT Infrastructure Library)

ITIL is het wereldwijde public domain model voor IT-servicemanagement. ITIL was het acroniem voor IT Infrastucture Library, maar thans wordt ITIL nooit meer als zodanig uitgeschreven. ITIL is ontwikkeld in Engeland en gemeengoed in vrijwel de hele wereld. De spreiding is in Engeland en Nederland het grootst maar ook in diverse andere landen in en buiten het Engelse taalgebied wordt


3


Bijlage E

ITIL gebruikt. Vrijwel alle organisaties in Nederland die iets op het gebied van IT doen kennen en gebruiken ITIL, al is het vaak alleen maar in naam. ITIL is ontstaan als een verzameling best practices op het gebied van IT infrastructuurbeheer die zijn gebundeld in de ITIL-bibliotheek. ITIL en gedachtegoed is in boekvorm in Nederland begin negentiger jaren van de vorige eeuw verschenen. In 2007 is het model radicaal vernieuwd: ITIL v3. In ITIL v3 zijn grotendeels dezelfde processen opgenomen als in ITIL v2, maar er zijn ook enkele processen verder uitgesplitst en aan toegevoegd en de benadering is anders: ITIL v3 gaat uit van de levenscyclus van diensten: ontwerp, transitie en operatie. Inmiddels is er een upgrade op ITIL v3: ITIL 2011. Hoewel de beheerder van ITIL zegt dat er weinig veranderd is t.o.v. ITIL v3, verschillende de meningen daarover. Veel schema’s zijn veranderd, er zijn weer 4 processen bijgekomen (afgesplitst) en er zitten meer voorbeelden in. Voor organisaties met weinig ervaring met ITIL blijkt dat ITIL v3 zeer lastig in te voeren is en minder herkenbaar dan ITIL v2. Veel organisaties hebben er (voorlopig?) voor gekozen om niet over te stappen naar ITIL v3. Voor ITIL 2011 zien we hetzelfde beeld. In het ITIL-model zijn alle processen benoemd voor IT Servicemanagement, dus ook voor het domein applicatiemanagement. Gerelateerd aan het ITIL-model is een internationale ISO-norm ontwikkeld: de ISO/IEC 20000. Het bekende ITIL v3 plaatje:

Figuur 5 Het ITIL v3-model

Meer inhoudelijk ziet het er als volgt uit:


4


Bijlage E

Figuur 6 Processen in ITIL v3

De organisatie die ITIL beheert is OGC (voorheen: CCTA), de organisatie die o.a. ook Prince2 beheert. Verder worden het gedachtegoed en de best practices verspreid door ITSMF. In Nederland: ITSMF Nederland. Voor meer informatie zie: www.itsmf.nl.

E.5

Specificeren

Specificeren betreft het beschrijven van de gewenste (veranderingen in) de informatievoorziening zowel in termen van inhoudelijk/functionaliteiten als in termen van eisen en randvoorwaarden. Daarbij kan de gevraagde oplossing kan zowel betrekking hebben op de geautomatiseerde als op de niet geautomatiseerde informatievoorziening. Door middel van specificeren geeft business informatiemanagement aan wat de gewenste functionaliteit moet zijn, wat de behoeften zijn, waarmee aan de leverancier duidelijk wordt gemaakt wat gevraagd wordt en wat dus ‘geleverd’ moet worden. Een specificatie is een samenhangende beschrijving van wat het informatiesysteem, zowel het te automatiseren deel als de niet te automatiseren delen, van het systeem moet doen, welke gegevens het moet bevatten en wat de functionaliteiten moeten zijn, aangevuld met eisen en randvoorwaarden en dus geen verzameling losse eisen waar eisen aan toegevoegd kunnen worden. Een specificatie beschrijft het "wat", en is dus geen ontwerp waarin eenduidig en ontwerptechnisch correct de relaties tussen gegevens/objecten, de processen en de functies van een systeem worden vastgelegd: het "hoe". Een specificatie vormt de basis voor een ontwerp. In een ontwerp gaat het wel om het "hoe" (en vervolgens om het "waarmee"). Het doel van een specificatie is om te beschrijven hoe die informatievoorziening er vanuit bedrijfsoogpunt uit moet zien. Een specificatie levert vervolgens de volgende resultaten op:  Het geeft een samenhangend beeld van die gewenste wereld.  Het dwingt business informatiemanagement om vooraf na te denken over welke functionaliteiten men zoekt, welke objecten en informatie relevant zijn, in hoeverre de


5


 

Bijlage E

beschrijving compleet is, etc. Het dwingt business informatiemanagement om na te denken over wat de vraag. Het biedt een duidelijk grens tussen de IT-leverancier en business informatiemanagement. Het geeft een goed vertrekpunt op basis waarvan een ontwerper efficiënt een ontwerp kan maken. Het is de basis om vervolgens een acceptatietraject in gang te zetten: krijg ik nu wat ik nodig heb/gewenst heb/besteld heb?

Essentieel hierbij zijn kennis van het bedrijfsproces en het gebruik van de informatievoorziening en van de informatie in de bedrijfsprocessen, politiek besef en kennis van de politieke en bestuurlijke situatie, stokpaardjes van gebruikers, managers, domeineigenaren en andere spelverdelers en kennis van wat een enigszins haalbaar is met IT en wat enigszins haalbaar is in de organisatie. Specificeren is in de regel een niet lineair verlopend zoekproces, zeker bij nieuwe systemen, bij omvangrijke wijzigingen en in langere trajecten: men komt herhaaldelijk terug op oorspronkelijk geformuleerde uitgangspunten, het vereist meerdere oplossingsrichtingen en alternatieven teneinde een goed besluit en een goede invulling te kunnen geven. Er zijn meerdere aanpakken om specificaties te maken. In figuur 1 zien we er vier.

Sprake van vervanging en maatwerk

Vervangingsaanpak

∆

Wat moet anders en hoe?

Nieuwe situatie en maatwerk

Ontwerp-aanpak Hoe moet het eruit zien?

Nieuwe situatie en pakket

Selectie-aanpak Wat kiezen we?

Zoekend in nieuwe situatie

Incrementeel/terugkoppelend Hoe gaat het proces eruit zien?

Figuur 7 Aanpakken bij het maken van specificaties

In een specificatie zullen altijd drie inhoudelijke onderwerpen terugkomen die elk een verschillende invalshoek van de gewenste functionaliteit beschrijven  processen: de processen die door de organisatie gaan en die door het systeem moeten worden uitgevoerd of worden ondersteund.  gegevens: een beschrijving van de gegevens, die in het systeem worden opgeslagen.  functies: de bewerkingen en mogelijkheden, die het systeem moet realiseren. Naast de inhoudelijke onderwerpen bevat een specificatie ook eisen en randvoorwaarden. Het onderwerp te bestellen functionaliteit wordt in het methodes boek deel 3 Specificeren nader uitgewerkt.


6


E.6

Bijlage E

Rollen en competenties

(Deze bijlage is gebaseerd op input van Franc Flutsch.) Introductie Geen twee organisaties zijn gelijk: klein of groot, één locatie om meerdere, plat of veel managementlagen, directieve gestuurd of sterk gedelegeerd etc., etc. Hoe de taken zijn belegd en hoe de rollen zijn verdeeld is sterk organisatieafhankelijk en daarnaast ook nog eens persoonsafhankelijk: de ene manager zal veel taken van business informatiemanagement bij zich houden en de ander zal juist een stevige business informatiemanager aanstellen. In dit boek spreken we daarom niet over functies en ook vrijwel niet over rollen. Eén van de uitzonderingen vormt de rol van de business informatiemanager. Logisch want business informatiemanagement vormt de doelgroep van de reeks waar dit boek deel vanuit maakt. Toch lichten we in deze bijlage een aantal rollen op het gebied van contractmanagement toe, rollen die we in praktijk veel tegenkomen als het over contracten gaat. Omdat dit boek handelt over contractmanagement vanuit de verantwoordelijkheid van business informatiemanagement beschouwen we ook primair de rollen aan de zijde van de business, de vraag- of opdrachtgeverkant. We hebben het dan over de contracteigenaar op richtinggevend niveau, over de contractmanager op sturend niveau en over de contractbeheerder op uitvoerend niveau. Per organisatie kunnen de rollen anders zijn en soms moeten ze dat ook zijn, omdat IT, contracten, leveranciers en managers heel erg anders kunnen zijn. Het is is dus aan u als lezer om een vertaling kan maken naar uw eigen organisatie en uw eigen situatie. In ieder geval is het voor een organisatie belangrijk om helder te definiëren wat men intern onder welke rol verstaat. Voor we de rollen beschrijven kijken we eerst naar de levenscyclus van een contract. Voordat er een contract is vinden er voorbereidende activiteiten plaats: vaststelling van de behoefte, specificatie, uitvraging, offertebeoordeling, besluitvorming en contractering (zie par. 10.2 ). Vervolgens start een soort Plan-Do-Check-Act cyclus waarin het contract wordt gevolgd, gemonitord en eventueel bijgesteld (zie ook figuur 79, par. 10.2). Dit gebeurt op drie niveaus:  Op richtinggevend niveau, met een horizon van een jaar of verder, wordt er gekeken of de leverancier nog past binnen de kaders zoals die binnen leveranciersmanagement zijn gedefinieerd: sluit een en ander nog aan op de bedrijfsdoelstellingen, de sourcing/ contractering strategie, geldt de reden van uitbesteding/inkoop nog en is de dienstverlening überhaupt nog benodigd.  Op sturend niveau, met een horizon van meestal een kwartaal, wordt bekeken of het ‘hoe’ van de dienstverlening nog voldoet. Dit betreft onder andere de wijze waarop de dienstverlening wordt verleend en of, op de wat langere termijn, de afgesproken servicelevels worden gehaald. De vraag hier luidt: zijn we goed bezig of is bijsturing en eventueel contractaanpassing noodzakelijk.  Op uitvoerend niveau wordt de directe contract-uitvoering gemonitord. Verstoringen en de afhandeling daarvan worden gevolgd en besproken en op dagelijkse, wekelijkse of maandelijkse basis wordt gekeken of de afgesproken dienstenniveaus worden gehaald en of directe afstemming of zelf ingrijpen noodzakelijk is. Ook de facturering wordt gevolgd. Rollen Aan de zijde van de business onderscheiden we op het gebied van contractmanagement vier rollen:  de contracteigenaar;  de contractmanager;


7


Bijlage E

 de contractbeheerder;  de inkoper. Zoals dat met rollen gaat, kunnen deze rollen bij verschillende personen (functionarissen) liggen, maar één persoon kan ook meerdere rollen vervullen. In de precontractuele fase ligt de bal vooral bij de contracteigenaar. Contracteigenaar De contracteigenaar is degene in de organisatie die op management niveau de "klant" is: diegene die het contract initieert en die direct belang en baat heeft bij de te realiseren dienstverlening, het te leveren product of de dienst. Dit is dus een manager uit de business (of de ondersteunende bedrijfsvoering), maar omdat we het hier hebben over dienstverlening op het gebied van IT en informatievoorziening wordt dit "eigendom" vaak gedelegeerd naar de business informatiemanager op richtinggevend en sturend niveau. Je zou kunnen zeggen: de contracteigenaar vormt de schakel tussen de business en het contract. In sommige organisaties wordt het hoofd van de afdeling Inkoop ook vaak betiteld als Contracteigenaar. In onze visie is dat echter een onjuiste betiteling. Het hoofd Inkoop is de organisatorisch leidinggevende van de rol inkoper.

Vanaf het moment dat het contract getekend is komt de verantwoordelijkheid grotendeels bij de contractmanager te liggen. Contractmanager De contractmanager is diegene die zorgt dat het concrete contract er komt en dat het contract voldoet en blijft voldoen aan de eisen en wensen van de contracteigenaar (service delivery beheer). De contractmanager is daarnaast verantwoordelijk voor het behoud van een goede leveranciersrelatie, effectieve communicatie en tevredenheid van alle partijen (relatiebeheer). De contractmanager dient te zorgen voor een balans tussen enerzijds de business dynamiek, de veranderende vraag en gewenste flexibiliteit en anderzijds het gecontracteerde dienstverleningsportfolio gedurende de looptijd van het contract. Je zou kunnen zeggen: de contractmanager vormt de schakel tussen het contract en de leverancier

Hoewel de contractmanager degene is die "hem heeft" in de fase van contractuitvoering, is de contractmanager uiteraard ook nauw betrokken bij de precontractuele fase. Doel in deze fase is om ervoor te zorgen dat er (op tijd) een goed contract komt. Dit houdt onder andere in dat er in het contract stuurparameters zijn opgenomen die het mogelijk maken dat de dienstverlening gemeten kan worden. Uiteraard is het is uiteindelijk de contracteigenaar die de stuurparameters bepaalt. Voor de dagelijkse operationele contractbewaking of contractmonitoring zou er nog sprake kunnen zijn van een contractbeheerder. Contractbeheerder De contractbeheerder is diegene die het contract bewaart en bewaakt. De contractbeheerder zorgt dat er een definitieve versie is )ondertekend), dat deze op een veilige plek wordt bewaard en dat tijdig


8


Bijlage E

wordt gesignaleerd dat het contract verlengd of beëindigd dient te worden. Verder bewaakt de contractbeheerder de facturering overeenkomt met de afgesproken tarieven en de geleverde diensten en producten en dat de leveringen overeenkomen met hetgeen is overeengekomen. Dit is dus een vrij administratieve rol.

Tijdens de contractonderhandeling, bij het aangaan of verlengen van het contract, kan er ook betrokkenheid zijn van een inkoper. Inkoper De inkoper is verantwoordelijk voor de inkoop-technische aspecten. Dit houdt in: het zorgen voor een marktconforme tariefstelling, het opstellen en bewaken van de inkoopvoorwaarden en het bewaken van financiële en juridische aspecten tijdens de contractering. Het verleden heeft uitgewezen dat inkopen (en verkopen) een ander vak is dan contract management. Inkopers zijn anders getraind en opgeleid en worden op andere zaken afgerekend dan contractmanagers. Inkopers zijn verantwoordelijk voor de meest economische deal. Voor een inkoper kan het daarom enerzijds interessant zijn om zaken te doen met enkele huisleveranciers, zodat het omzetvolume groter wordt en de prijs weer onderhandelbaar wordt, terwijl men anderzijds per keer wellicht de beste deal in de markt wil zoeken om zo de concurrentiedruk te verhogen en daarmee ook de prijs wellicht te drukken. Dit laatste vergt dan wel weer meer tijd en aandacht. Het zal duidelijk zijn dat voor de contracteigenaar deze zaken wellicht een rol spelen, maar dat andere aspecten belangrijker zijn, zoals kwaliteit, continuïteit en partnership. Zie als voorbeeld ook de casus in paragraaf 4.1.

Tenslotte kan er behoefte zijn aan betrokkenheid van een jurist. De aanbodzijde Hoewel dit boek over de vraagzijde gaat, staan we toch kort stil bij de vraagzijde. Aan de vraagzijde kunnen we in eerste instantie enkele rollen onderscheiden die de spiegeling vormen van de rollen aan de vraagzijde:  contracteigenaar  contractmanager  contractbeheerder  verkoper Ook aan de aanbodzijde is er iemand die het achterliggende belang vertegenwoordigt: de eigenaar. En een samenwerking tussen klant en leverancier (nog) passend is afhankelijk van de doelstellingen van beide partijen: ook aan de zijde van een leverancier dient iemand het contract te managen. De werkzaamheden van de contractmanager van de leverancier zijn dan ook nagenoeg gelijk aan die vanuit de vraagkant. Tijdens de precontractuele fases zijn in praktijk de verkoper (aanbod) en de contracteigenaar van de klantkant (vraag) aan de bal ondersteund door de inkoper (vraag). Om de nieuwe overeenkomst goed te kunnen besturen is het een vereiste dat de contractmanagers van beide zijden ook aan tafel zitten. In de praktijk kunnen dit ook de inkoper en de verkoper zijn. Daarnaast kennen we aan de aanbodzijde echter nog een rol: de servicemanager. De servicemanager is verantwoordelijk voor de realisatie van de te leveren diensten en producten conform afspraken: voor de dagelijkse sturing van zowel de vaste beheer- en onderhoudsdiensten als de projectmatige diensten. Tenslotte kan er nog een projectmanager in het spel zijn, die verantwoordelijk is voor de aansturing en risicobeheersing van het afzonderlijke project en de specifieke afspraken die voor een project gemaakt zijn.


9


Bijlage E

Organisatorische inbedding Of alle rollen echt benoemd zijn en of er al of niet afdeling en Contractmanagement en Inkoop zijn is onder meer afhankelijk van de omvang van de organisatie, de omvang en strategisch belang van het contract en het doel waarvoor er een contract afgesloten wordt. Een commodity zoals ‘plastic’ software (standaard pakketjes of apps) of licenties zijn anders en eenvoudiger te managen dan inkoop of uitbesteding van applicatie managed services. In kleinere en middelgrote organisaties komt het ook voor rollen gecombineerd worden. De business informatiemanager kan ook de rol van inkoper en contractbeheerder vervullen. Bij grote(re) organisaties komt het steeds vaker voor dat er dedicated contractmanagers aangesteld worden. In veel gevallen is dit echter nog niet zo. Hiervoor zijn verschillende oorzaken aan te wijzen:  de organisatie ziet het belang (nog) niet;  de omvang van de organisatie biedt hier geen mogelijkheid toe, vaak vanuit een personeel budgettair oogpunt;  de organisatie heeft voornamelijk operationele commodity en/of licentieafname-contracten. Als contractmanagement niet als centrale functie(afdeling) is ingericht, dan worden de taken en verantwoordelijkheden vaak wel expliciet maar nog meer impliciet bij verschillende medewerkers van verschillende afdelingen ondergebracht. Taken kunnen en worden vaak verdeeld over medewerkers van de inkoop, logistieke, financiële afdeling of administratie, bij de IT-afdeling of in de echte business. Het spreekt voor zich dat samenhang en samenwerking cruciaal is voor een succesvol contract. Verantwoordelijk voelen of verantwoordelijk zijn Als contractmanagement-taken over verschillende medewerkers verdeeld zijn, dan kan dit alleen goed werken als de bijbehorende verantwoordelijkheden en bevoegdheden op dezelfde wijze verdeeld zijn. De kans op wrijving met de leverancier en mogelijk tegen elkaar uitgespeelde medewerkers is groot als de verantwoordelijkheden niet overeenkomen met de bevoegdheden. Een administratief medewerker die verantwoordelijk is voor bestellingen en leveringen maar geen goedkeuring kan geven voor betalingen boven een bepaald bedrag krijgt niet wat hij verwacht als de leverancier zijn geld niet krijgt. Maar belangrijk er nog dan verantwoordelijk gesteld worden is verantwoordelijk voelen. De contracteigenaar (de business informatiemanager) moet zich verantwoordelijk voelen. Uiteindelijk wordt de dienstverlening ingekocht en geleverd voor hem, zijn informatiedomein of zijn business manager. Om een leverancier succesvol te kunnen laten zijn is er aan de zijde van de afnemer iemand nodig die met zekere regelmaat aangeeft wat belangrijk is en wat de beleving over de dienstverlening is. Met andere woorden: regelmatige toetsing op richtinggevend niveau aan beide kanten is essentieel voor de doelmatigheid van de overeenkomst. Competenties van de contractmanager1 Omdat we de contractmanager als spin in het web zien ten aanzien van contracten gaan we hier dieper in op de vereiste competenties van de contractmanager. Er wordt nogal wat verwacht een contractmanager, maar wat maakt iemand nu een goede contractmanager, welke competenties zijn belangrijk? Niemand wordt geboren als contractmanager en dus betreft het een te leren vak. Maar het heeft ook te maken met drijfveren. Tot op heden wordt de rol van contractmanager vaak ingevuld door personen die begaan zijn met de organisatie (de business) en de gebruikers en ontstaat en groeit vaak uit onvrede en onmacht ten aanzien van de geleverde diensten door de leverancier die niet of 1

Zie voor competenties ook het document De Competente Contractmanager van NBCM. In dt document worden ook vaardigehden en gedragskenmerken benoemd.


10


Bijlage E

niet meer stroken met de gemaakte of gepercipieerde afspraken. De als goed bestempelde contractmanager weet op zijn eigen wijze sturing en richting te geven aan de afspraken en aanpassingen zodat de contracteigenaar en de gebruikers krijgen wat zij verwachten met begrip voor de leverancier. Competenties vormen verder een mooie verzamelnaam voor kennis en vaardigheden. Dus daar gaan we nu eerst op in, en daarna bespreken we de drijfveren: houding, gedrag en affiniteit Kennis De meeste contractmanagers zijn gegroeid in het vak, door hun manager aangewezen, voor de leeuwen geworpen of hebben zich voor de rol gemeld uit zorg over gebrek aan contractmanagement binnen de organisatie. De achtergrond van de huidige contractmanagers is dan ook divers, vanuit de techniek, projectleiding, inkoop of de financiële afdeling, soms ook de juridische afdeling, echter nog (te) weinig vanuit business informatiemanagement. Een in Nederland geaccrediteerde opleiding voor contractmanagers bestaat (nog) niet. Wel zijn er trainingen en cursussen op de markt: uiteenlopend in breedte, diepgang en niveau hoewel veelal junior en medior-gericht. Hoe dan ook, als basiskennis zien we de bedrijfskundige-, financiële- en juridische grondbeginselen op HBO of WO-niveau als onontbeerlijk. Daarnaast kan het nuttig zijn om enige kennis te hebben van IT en informatievoorziening, software, systeemontwikkeling en bijbehorende procesmodellen als ASL, BiSL en ITIL. Vanzelfsprekend dient er kennis te zijn van de bedrijfsprocessen en de producten en diensten van de eigen organisatie die de contractmanager in zijn rol moet vertegenwoordigen. Al met al zijn dit nogal wat eisen die aan de contractmanager gesteld worden. Dit betekent ook dat contractmanagers door de bank genomen een flink aantal jaren werkervaring hebben in andere rollen voordat zij deze rol krijgen. Voor de contracteigenaar betekent dit dat die een contractmanager nodig heeft die begrijpt wat vraagsturing is en dan ook nog vanuit een continu proces hetgeen beter nog te onderkennen als een benodigde houding. Kunde Vaardigheden is een optelsom van verschillende kwaliteiten, waarbij, afhankelijk van onder andere het doel, de complexiteit en de levensfase van het contract, de samenstelling en het gewicht van de vereiste kwaliteitselementen verschillend zal zijn. Voor alle contractsituaties zijn de volgende vaardigheden cruciaal:  Pro-activiteit Hoewel het een attitude-element is, is pro-activiteit het sleutelwoord voor de contractmanager. Zoals al eerder aangegeven, is het speelveld tussen verwachte-, geleverde en gecontracteerde diensten continu in beweging. Dit betekent dat de contractmanager steeds toetst of de gemaakte afspraken nog voldoen of dat er aanpassingen nodig zijn. Indien dit zo is, zal hij in samenwerking met de contracteigenaar waar nodig voorstellen voor aanpassingen maken en deze bespreken en uitonderhandelen met de leverancier. Dit betekent niet altijd dat contractuele aanpassingen nodig zijn: vaak kan er volstaan worden met een aanpassing van diensten uit de Producten & Diensten Catalogus (PDC) en/of gekoppelde tarieven en/of het Dossier Afspraken en Procedures (DAP) waarin de operationele werkwijzen en procedures aangepast worden.  Luisteren Pro-activiteit begint met kunnen luisteren naar wat de behoefte van de contracteigenaar is, maar ook kunnen luisteren naar de leverancier en een terug vertaling naar de contracteigenaar kunnen maken als een leverancier nieuwe mogelijkheden/diensten ziet en aanbiedt of problemen signaleert.  Verkopen Maar al te vaak wordt de contractmanager geassocieerd met of het verlengstuk van de inkoper. De contractmanagers zijn zelf de beste apostelen om dit misverstand de wereld uit te helpen. Vanuit zijn pro-activiteit moet de contractmanager de veranderde verwachting van de te leveren


11


Bijlage E

diensten binnen de contouren van het contract zo goed mogelijke zien te verkopen aan de leverancier. Aan de andere kant moet hij ook de door de leverancier gewenste aanpassingen intern verkocht zien te krijgen, mits deze ook in lijn zijn met de behoeften en met de doelstellingen van het contract. Want het contract is niets anders dan een samenwerkingsovereenkomst tussen twee partijen, die alleen succesvol kan zijn als beide partijen succesvol zijn. Onderhandelingsvaardigheden zijn dan ook gewenst. Het ‘old-school’ afdwingen is dan ook absoluut niet meer op zijn plaats, leidt alleen maar tot initiële ‘win-lose’ en dus tot ‘lose-lose’ situaties. Tenslotte dient een contractmanager commercieel vaardig en financieel bewust te zijn. Met deze drie essentiële vaardigheden komt de contractmanager al een heel eind. Aanvullend kunnen van pas komen:  vertalen/beïnvloeden;  samenwerken;  opbouwen en onderhouden van relaties;  analyseren;  rapporteren;  plannen en organiseren. Houding en gedrag Kennis kun je tot je nemen, vaardigheden zijn tot op zekere hoogte aan te leren en te veranderen maar houding en gedrag zijn vooral zaken die van binnenuit komen en met eigen normen en waarden samenhangen.  Pro-activiteit Pro-activiteit en in het verlengde hiervan nieuwsgierigheid, is als absolute basisvoorwaarde en dus noodzakelijke basishouding al vermeld onder de noemer kunde.  Integriteit Een open deur, maar een contractmanager dient absoluut integer moet zijn, anders is het onmogelijk een goede meerjarige relatie met de leverancier op te bouwen en te behouden.  Commitment De noodzakelijke pro-activiteit wordt alleen bereikt als je als contractmanager bevlogen en gecommitteerd bent.  Oplossingsgerichtheid Vaak wordt ook een beroep gedaan op oplossingsgerichtheid en dat dikwijls buiten gebaande paden en vereist dus creativiteit en bereidheid om hulp te zoekt om het contract blijvend passend te laten zijn. Affiniteit Dit laatste competentie element dat zegt iets over het gevoel met de business waarin de organisatie zich beweegt. De een heeft meer affiniteit met tastbare diensten zoals bij productiebedrijven en logistiek, de ander heeft meet meer financiële of administratieve processen. De dynamiek van een krantenbedrijf (een dagelijkse cyclus met absolute deadline) is heel anders dan die van een pensioenverzekeraar of salarisverwerker. Met andere woorden: waar voel je je als persoon het best bij thuis. Het is evident dat je ‘harder loopt’ daar waar je hart ligt. En hiermee zijn we weer terug bij het begin: pro-activiteit. Pro-activiteit is het gevolg van de drijfveren van de contractmanager.

E.7

Openbaar aanbesteden en Prestatie-inkoop

Overheidsdiensten hebben te maken met de Europese regelgeving rond openbare aanbesteding. Het doel is om het bevorderen van concurrentie door het transparant aanbesteden. In theorie gaat het om concurrentie op prijs/prestatie, maar vrijwel vanzelf ligt hierbij veelal de nadruk op


12


Bijlage E

prijsconcurrentie, waardoor kwaliteit en effectiviteit snel naar achteren schuiven. Een Europese aanbesteding kent 3 fasen: 1. Initiële fase: opstellen bestek en publicatie op de aanbestedingskalender 2. Selectie- en gunningsfase, met daarin de te publiceren Nota van Inlichtingen 3. Uitnuttingsfase: leveren, wijzigen, verlengen, beëindigen. Leidend principe bij een traditionele aanbesteding is het Programma van Eisen (PvE), waarbij de aanbestedende partij alle eisen vooraf formuleert, zodat alle leveranciers op basis van dezelfde informatie een voorstel mogen doen. Het zal duidelijk zijn dat dit voor veel organisaties tot problemen leidt omdat we de eisen niet allemaal volledig van tevoren weten. Wellicht wilden we daarom juist aanbesteden: omdat we zelf de kennis niet volledig in huis hebben. Bovendien: als we, als vragende partij, er een of meer essentiële eisen over het hoofd hebben gezien dan komt dat als een boemerang terug in de vorm van meerwerk of afwijkende dienstverlening. En ook staat de wereld niet stil en duurt een leveringstraject vaak lang. Dat betekent dat tijdens of na de aanbesteding de eisen gemakkelijk kunnen veranderen, bijvoorbeeld doordat de wetgever andere eisen stelt. Een optie om met deze problemen om te gaan is een vorm van aanbesteding die prestatie-inkoop wordt genoemd, een concept dat uit de VS afkomstig is. Hierbij wordt niet naar de goedkoopste leverancier gezocht voor een door de opdrachtgever geformuleerde "oplossing" in de vorm van een PvE, maar naar een leverancier die voor een acceptabel bedrag de meest effectieve oplossing kan realiseren. Vooral bij minder rechtlijnige trajecten waar de vraag niet zeer concreet is en waar de oplossing dus ook niet op voorhand bekend is. Overigens is het de vraag of deze vorm van aanbesteding formeel is toegestaan. In de Gids Proportionaliteit van de Nederlandse Aanbestedingswet 2012 wordt niet gerept over prestatieinkoop. Probleem is dat wellicht niet wordt voldaan aan de eis dat alle aanbieders kunnen beschikken over dezelfde informatie, omdat na de initiële aanbiedingen in de concretiseringsfase nog maar met één aanbieder wordt gepraat. Maar deze vorm van aanbesteding komt steeds meer voor en tot nu toe heeft dat amper tot juridische problemen geleid. Bron: Automatiseringsgids 2014-10 (5 juni), 2014-11 (19 juni) en 2014-12 (17 juli) Ook is er een niet-openbare procedure. Dit is een procedure waaraan ondernemers mogen verzoeken deel te nemen, maar waarbij alleen de door de aanbestedende dienst aangezochte ondernemers mogen inschrijven. Dit houdt in dat iedere ondernemer zich mag aanmelden voor de eerste fase, de selectiefase en dat vervolgens de aanbestedende dienst een vooraf bekend gemaakt aantal ondernemers selecteert die zich mogen inschrijven (een offerte mogen indienen) voor de tweede fase. Kenmerken: 1. Een beperking van het aantal inschrijvers is mogelijk met een minimum van 5 inschrijvers. Verder is bepaald dat het aantal uitgenodigde gegadigden in ieder geval moet volstaan om daadwerkelijke mededinging te waarborgen. 2. De procedure kent twee rondes: a. selectiefase, waarin de geschiktheid van het bedrijf wordt beoordeeld; b. gunningfase, waarin de offerte zelf, hetgeen aangeboden wordt, wordt beoordeeld. Dit betekent dat je twee documenten moet opstellen en twee beoordelingsrondes moet houden. 3. Er zijn langere doorlooptijden dan bij de openbare procedure: a. voor indienen aanmelding minimaal 37 dagen of minimaal 30 dagen ingeval van elektronisch ter beschikking stellen van het aanmeldingsdocument b. voor indienen inschrijving minimaal 40 dagen of minimaal 35 dagen ingeval van elektronisch ter beschikking stellen


13


Bijlage E

De aanbestedende dienst heeft altijd de vrije keuze uit de openbare en niet-openbare procedure. In de praktijk blijkt dat een niet-openbare procedure met name wordt gebruikt voor hefboomproducten en knelpuntproducten. Hefboomproducten kan men bij meerdere leveranciers kopen, maar de kosten zijn hoog. Denk hierbij aan bijv. ziekenhuisbedden, treinen, accountancy, juridische dienstverlening. Knelpuntproducten vertegenwoordigen in geld uitgedrukt een relatief lage waarde, maar zijn door de monopolypositie kwetsbaar wat betreft de levering. Bron: www.europeseaanbestedingen.eu

Dan is er nog een concurrentiegerichte dialoog. In de concurrentiegerichte dialoog start men met een vraag waarvoor geen (eenduidige) oplossing bekend is. Op basis van oplossingen die de gegadigden aandragen voert de aanbestedende dienst een dialoog die leidt tot optimalisatie tussen vraag en aanbod. De concurrentiegerichte dialoogprocedure verschilt hiermee wezenlijk van een ‘gewone’ openbare of niet-openbare procedure. Het grootste verschil zit hem in de wijze van uitvragen. Een goed gevoerde dialoog resulteert in inschrijvingen die voor de aanbestedende dienst een optimale oplossing bieden tegen een redelijke prijs en die voor de inschrijvende partij een aantrekkelijke klus met voldoende economisch perspectief oplevert. Een optimale oplossing is dus afhankelijk van de kwaliteit van de dialoog tussen aanbestedende dienst en inschrijvende partijen. Bron: De concurrentiegerichte dialoog. Een handreiking op basis van de ervaringen tot nu toe van de Rijksgebouwendienst, Rijkswaterstaat en Defensie. Te downloaden via: www.europeseaanbestedingen.eu

E.8 De consequenties van outsourcing voor business informatiemanagement Outsourcing van diensten/activiteiten is niet een tijdelijke activiteit. Als de diensten eenmaal zijn uitbesteed dan zal het contract ook 'gemanaged' moeten worden, zowel inhoudelijk als op contractniveau. Dat betekent dat de opdrachtgevende organisatie haar zaakjes wel op orde moet hebben en dat een zekere mate van zakelijkheid optreedt. Waar je een interne afdeling nog wel met een halve opdracht op pad kunt sturen en ondertussen bijsturen is dat met een externe partij lastiger. Ten eerste heeft de externe partij van nature minder kennis van de organisatie (en kan dus lastiger bepalen “ze zullen dat wel bedoelen”) maar ten tweede gaat op moment één de teller lopen. Mogelijke knelpunten bij outsourcing zijn:  outsourcing introduceert afhankelijkheid van derden;  outsourcing introduceert extra ketenmanagement: – aanbieders; – contracten; – monitoring; – aansturing;  outsourcing vraagt concrete kwaliteitseisen (willen alle afnemende organisatiedelen hetzelfde?);  outsourcing vermindert flexibiliteit, reactietijden en directe invloed. Outsourcing vraagt ook na de transitie permanente aandacht en sturing. Het is dus niet klaar na de overdracht. Enkele consequenties:  men moet planmatig werken (tijdig wensen en eisen aangeven);


14


    

Bijlage E

de specificaties van opdrachten moeten helder, volledig en definitief (afgestemd met de business) zijn; er moet sprake zijn van heldere acceptatie van diensten en producten; men dient zelf ook tijdig zaken op te leveren en te doen (bijvoorbeeld accepteren ontwerp, uitvoeren test); er dient monitoring van prestaties en contract plaats te vinden; men zal zich in zekere mate moeten aanpassen aan de eisen en processen van de leverancier.

Dit vereist dus een zekere volwassenheid van de opdrachtgevende, uitbestedende partij.


15

BiSL Scenario s. Leverancierssturing. Bijlage E Achtergronden. René Sieders, Remko van der Pols

Recommend Documents