Goede afspraken maken goede vrienden (onbekend) Hoofdstuk 20. Contractmanagement

Goede afspraken maken goede vrienden (onbekend) Hoofdstuk 20 Contractmanagement V1.4 / 01 februari 2017

MCTL 20. v1.4 Auteur: Ton van den Hoogen Met dank aan alle bedrijven en personen die in de afgelopen jaren bewust en onbewust een bijdrage aan MCTL hebben geleverd. Geen copyright! MCTL is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie. Gebaseerd op een werk van www.mctl.nl. MCTL is geheel Public Domain, er rusten dus geen copyrights of auteursrechten op. U mag MCTL (ook commercieel) gebruiken, verwerken, bewerken wat u maar wilt. Wanneer iets echter Public Domain is, blijft het Public Domain. Wat u dus niet mag doen is over (delen van) MCTL copyright of auteursrechten claimen, u maakt zich dan schuldig aan copyfraud en bent strafbaar. Indien u zelf overtredingen constateert, vragen wij u dit via www.mctl.nl aan ons te melden. Wat wij van u vragen is om bij elk gebruik een verwijzing naar de bron: www.mctl.nl op te nemen. De reden hiervan is dat op deze wijze iedereen de oorspronkelijke versie(s) kan vinden. V1.4 01-02-2017 Pagina 20-2

MCTL 20. v1.4 Hoofdstuk 20... 4 Plaats in het MCTL-framework... 4 Achtergrond... 4 Doel van dit taakgebied... 6 Hoe weet je dat het doel is bereikt?... 8 Taken 8 1. Beheer leverancierscriteria... 9 2. Evalueren... 11 3. Vaststellen benodigde afspraken komend jaar... 11 4. Contractafspraken maken/aanpassen... 12 5. Doen uitvoeren van contracten, bewaken en (tussentijds) bijstellen... 16 Relaties met andere onderdelen van MCTL... 16 Opmerkingen... 17 1. Dekkingsgraad PDC versus alle interne taken + contracten/sla s... 18 2. Resultaat- versus inspanningsverplichtingen... 18 3. Verboden termen en zinsconstructies in contracten... 18 4. Het maximaal uitnutten van bestaande contracten... 19 Certificering/proefexamenvragen... 19 1. MCTL Foundation - proefexamenvragen... 19 2. MCTL Foundation proefexamenvragen met antwoorden en feedback... 21 3. MCTL Advanced-basis - proefexamenvragen... 23 Nuttige websites en boeken... 23 V1.4 01-02-2017 Pagina 20-3

MCTL 20. v1.4 HOOFDSTUK 20 TAAKGEBIED CONTRACTMANAGEMENT Er bestaat geen organisatie die alles zelf kan of wil doen. Daarom wordt altijd een kleiner of groter deel van het werk, eventueel ook op het vlak van functionele ondersteuning, uitgevoerd door externe leveranciers. Deze extern uit te voeren werkzaamheden worden vastgelegd in contracten. Daarbij is het noodzaak dat elk contract eens in de zoveel tijd wordt bezien op relevantie (is het contract nog nodig of moet dit inhoudelijk worden aangepast) en bovendien dient aangetoond te kunnen worden dat alle contractuele afspraken zijn nagekomen. PLAATS IN HET MCTL-FRAMEWORK Het taakgebied Contractmanagement maakt onderdeel uit van het taakcluster Tactisch support: ACHTERGROND Contracten, op allerlei vlakken, zijn binnen organisaties geen zeldzaamheid. Het gebied van computertechnologie kent een zeer lange historie van pogingen om tussen diverse partijen afspraken te maken. Deze pogingen hebben tot zeer uiteenlopende resultaten geleid. Gebrekkige contracten ontstonden omdat niet duidelijk was wat met V1.4 01-02-2017 Pagina 20-4

MCTL 20. v1.4 computertechnologie allemaal kon worden bereikt en hoe dit moest worden vormgegeven. Aan zowel de leveranciers- als aan de klantzijde was het kennisniveau niet hoog. Tot slot hebben klanten en leveranciers niet altijd dezelfde belangen. Reeds vele jaren is met behulp van ITIL getracht dit met het proces Service Level Management op een hoger niveau te brengen. De hieruit voort gevloeide contracten zijn de afgelopen decennia steeds beter geworden. Toch wordt bij MCTL voor een andere insteek gekozen. Traditioneel worden afspraken onderscheiden tussen interne gebruikersgroepen en interne IT aan de ene en tussen interne IT en externe leveranciers aan de andere kant. Of, zoals bijvoorbeeld in FSM wordt voorgestaan: tussen gebruikersgroepen en Functioneel support enerzijds en tussen Functioneel support en de in- en externe IT-leveranciers anderzijds (zie hoofdstuk 2, paragraaf Vergelijking MCTL met BiSL en FSM ): Afspraken conform BiSL, zie voor de FSM variant hoofdstuk 2. Binnen MCTL worden expliciet geen interne afspraken in de vorm van SLA s of ISA s (Information Service Agreement, term afkomstig uit FSM) gemaakt. Dergelijke afspraken tussen interne groepen medewerkers zijn overbodig indien voor ogen wordt gehouden dat een organisatie gefocust moet zijn op de extern te behalen doelen. Daaraan draagt elke groep medewerkers zijn steentje bij, of het nu eindgebruikers zijn, mensen van Operationeel support of de medewerkers die de computertechnologie beheren (systeemen netwerkbeheer, applicatiebeheer, testers, ontwikkelaars etc). Ook bij die gezamenlijke focus blijft het van belang te weten wie wat doet, maar intern contractuele afspraken met elkaar maken en elkaar daar op afrekenen is er niet meer bij. Een externe focus leidt tot impliciete interne afspraken Het mag toch eigenlijk helemaal niet verwonderlijk zijn dat zonder expliciete afspraken toch goed wordt samengewerkt. In de wereld van computertechnologie moet dit soms toch nog eens worden benadrukt. Laten we eens een voorbeeld nemen uit een andere wereld, de wereld van de Formule 1, het racen met zeer snelle auto s. Daarbij gaat het uiteindelijk uitsluitend om het winnen van de race. Met andere woorden, bij al het werk, op welke plaats en door wie ook uitgevoerd, V1.4 01-02-2017 Pagina 20-5

MCTL 20. v1.4 kan uiteindelijk een van de volgende simpele vragen worden gesteld: Gaan we hierdoor winnen?, of Draagt dit bij tot het winnen van de race? of Wordt de auto hier sneller van?. Zo is dat ook eenvoudig te vertalen naar ziekenhuizen ( Wordt de patiënt hier beter van? ), gemeenten ( Wat levert dit op voor onze burgers? ), of commerciële bedrijven ( Wat voor voordeel biedt dit onze klanten? ). Op die manier krijgen alle interne medewerkers eenzelfde focus, de neuzen gaan op natuurlijke wijze allemaal dezelfde kant op staan. Waar ze ook werken, hoe ze ook met elkaar samen moeten werken, juist door die gezamenlijke focus zijn er geen interne contracten, SLA s of wat dan ook meer nodig. De impliciete onderlinge afspraken die op deze wijze ontstaan ( als jij dit doet, dan doe ik dat ) zijn voldoende om de externe doelen te behalen. Binnen MCTL wordt wel aanbevolen om een PDC te maken waarin Functioneel support (zo mogelijk samen met Applicatie support en Infrasupport) beschrijft wat ze voor de rest van de organisatie kan betekenen. De enige afspraken die in dit taakgebied ter sprake komen zijn van daarom van externe aard: vanuit de organisatie naar de buitenwereld. Schematisch gezien is dit als volgt weer te geven: DOEL VAN DIT TAAKGEBIED Het doel van dit taakgebied is het met externe partijen maken van afspraken in de vorm van contracten over het komend jaar. In deze contracten zijn opgenomen de te leveren producten en diensten, het (kwaliteits)niveau waarop deze producten en diensten worden geleverd, de kwantiteit, alsmede de wijze waarop het nakomen van deze afspraken zal worden gemeten. In principe is het mogelijk, soms wenselijk en soms onontkoombaar, om contracten voor meerdere jaren af te sluiten. Echter, gezien de dynamiek van het vakgebied is het buitengewoon onverstandig dergelijke contracten zo op te stellen dat er niet op zijn minst tussentijdse bijstellingen plaats kunnen vinden. Vandaar dat in dit taakgebied een V1.4 01-02-2017 Pagina 20-6

MCTL 20. v1.4 jaarcyclus is opgenomen waarin nieuwe contracten kunnen worden afgesloten en waar nodig bestaande worden bijgesteld of beëindigd. Er zijn drie verschillende typen contractrelaties te definiëren: 1. Levering computertechnologie en bijbehorende diensten Vanuit de eindgebruikersorganisatie of vanuit Functioneel support worden contracten afgesloten met externe partijen die computertechnologie en bijbehorende diensten leveren. Voorbeelden hiervan zijn bijv. apparatuur en/of software, maar ook cloud-computing waarbij geen technologie meer wordt geleverd maar een werkende functionaliteit. De technologische component in dergelijke overeenkomsten is vaak groot. 2. Levering Functioneel support Vanuit de eindgebruikersorganisatie of vanuit Functioneel support worden contracten afgesloten met externe partijen die (aanvullend) Functioneel support leveren. Niet alleen computertechnologie kan worden geoutsourcet, maar ook de functionele ondersteuning. Indien dit geheel wordt uitbesteed, is de eindgebruikersorganisatie de interne contractpartner. Indien slechts een gedeelte van de functionele ondersteuning wordt uitbesteed, is de interne contractpartner veelal de interne groep Functioneel support. 3. Datalevering c.q. -uitwisseling Vanuit de eindgebruikersorganisatie of vanuit Functioneel support worden contracten afgesloten met externe partijen waarmee data worden uitgewisseld, ook wel ketenpartners genoemd. Steeds vaker worden datastromen in een hele keten van organisaties (de productieketen) geheel digitaal afgehandeld. In die keten is elke organisatie een zelfstandige eenheid met eigen taken, bevoegdheden en verantwoordelijkheden. Hiermee is de noodzaak ontstaan om tussen dergelijke zelfstandige organisaties goede afspraken te maken. Het kan in deze sfeer bijvoorbeeld gaan over welke data de bron is, welke data worden uitgewisseld, het eigenaarschap van de data, de noodzakelijke beveiliging, het gezamenlijk gebruik van computertechnologie (software, hardware en databases) en de begrenzing van de verantwoordelijkheden (koppelvlakken). Ad 3: Terugmeldprocedure BRP Stel, u heeft een organisatie en u heeft een koppeling met het BRP (Basisregistratie Personen, vroeger bekend onder de naam GBA). Hierdoor kunt u in uw eigen systemen gebruik maken van de adresdata die bij de overheid bekend zijn. De bron van deze data blijft echter bij de overheid liggen. Mocht er dus op een of andere manier twijfel zijn over de juistheid van de data, u komt er bijvoorbeeld achter dat iemand verhuisd is, maar dat is kennelijk niet aan de gemeente heeft doorgegeven, dan is het logischerwijs niet zo slim deze adresdata in uw eigen systeem te wijzigen. Bij de eerstvolgende update zullen vanuit de BRP uw data weer worden overschreven. Daarom is er een terugmeldprocedure bedacht; indien u vermoed dat data afkomstig uit het BRP niet juist zijn dan kunt u dit melden waarna aan de V1.4 01-02-2017 Pagina 20-7

MCTL 20. v1.4 bron wordt uitgezocht wat er aan de hand is. Indien nodig worden dan de brondata aangepast die dan via de koppeling vanzelf weer in uw systeem terecht komen. Het wordt overigens nog wat lastiger als u data verrijkt; met andere woorden, data aanvult. Bijv. persoons- en adresdata worden intern aangevuld met betaaldata en betaalgedrag. Indien systemen volledig zijn geïntegreerd kan het op die wijze heel ingewikkeld worden wie eigenaar van welke data(elementen) is. Ook de koppelingen tussen de brondata en uw eigen aanvullende data zijn op dat moment een aandachtspunt. Veel gebruikte data zoals namen, geboortedata en -plaatsen kunnen zeker wijzigen waardoor de koppeling verloren gaat; namen vanwege huwelijk of scheiding, naamswijziging op eigen verzoek, het is buiten Nederland zeker niet uitzonderlijk dat iemand zijn eigen geboortedatum niet kent en die in de loop van de tijd steeds anders inschat en de naam van de oorspronkelijke geboorteplaats kan in de loop van de tijd de nodige wijzigingen ondergaan of zelfs geheel verdwijnen. Daardoor kunnen bijvoorbeeld betaalgegevens die zijn gekoppeld aan een naam, na naamswijziging, opeens in de lucht komen te hangen. HOE WEET JE DAT HET DOEL IS BEREIKT? De volgende indicatoren zijn te benoemen om te weten of bovenstaande doel wordt bereikt: De contractuele afspraken zijn aantoonbaar nagekomen De intermenselijke verhoudingen tussen leveranciers en klant zijn zodanig dat ook op lange termijn een goede werkwijze mogelijk is (zijn elkaar dus niet in de haren gevlogen, geen verziekte sfeer etc.) Vanuit de eindgebruikersorganisatie gezien is sprake van een naadloze support: er is geen merkbaar verschil tussen de intern en extern geleverde support en er zijn ook geen merkbare effecten van overgangen tussen in- en extern Het geïntegreerde eindresultaat zoals de eindgebruikersorganisatie dat ervaart, is op het juiste niveau TAKEN De taken in dit taakgebied kennen een jaarcyclus die als volgt schematisch zijn weer te geven: V1.4 01-02-2017 Pagina 20-8

MCTL 20. v1.4 Input De input van dit taakgebied wordt gevormd door: 1. De lopende contracten 2. Data over de werkelijke performance van de huidige leveranciers 3. Het actuele aanbod van producten en diensten van huidige en potentiele leveranciers 4. Het behoefteplan, waarin de totale behoefte van het komende jaar is beschreven 5. De huidige PDC met daarin een beschrijving van het gehele aanbod richting de gebruikersorganisatie Taken De volgende los van elkaar staande taken zijn op functioneel vlak te onderkennen: 1. Beheer leverancierscriteria 2. Evalueren 3. Vaststellen benodigde afspraken komend jaar 4. Contractafspraken maken/aanpassen 5. Doen uitvoeren van de contracten, bewaken en (tussentijds) bijstellen Deze activiteiten worden in de paragrafen hierna verder uitgewerkt. Output De output van dit taakgebied wordt gevormd door precies de juiste afspraken met precies de juiste leveranciers, vastgelegd in contracten die aantoonbaar juist worden uitgevoerd. 1. BEHEER LEVERANCIERSCRITERIA Leverancierscriteria zijn criteria aan de hand waarvan leveranciers kunnen worden beoordeeld en geselecteerd. Met name in het geval een nieuwe leverancier moet worden geselecteerd zijn deze bruikbaar. Vanzelfsprekend zullen er in dat geval eisen worden gesteld aan het gewenste systeem, maar ook aan de bijbehorende leverancier kunnen de nodige eisen worden gesteld. Leverancierscriteria zijn als volgt in te delen: V1.4 01-02-2017 Pagina 20-9

MCTL 20. v1.4 Toelichting (van beneden naar boven): 1. Ten eerste bestaan er criteria die voor de hele organisatie gelden. Bijv. bij de overheid is een bekend criterium het voldoen aan de Wet Bibob, terwijl bijv. in de voedselindustrie algemene richtlijnen rondom voedselveiligheid gelden. 2. Ten tweede bestaan er criteria die specifiek gelden in het gebied van (toepassing van) computertechnologie, bijv. rondom continuïteit, (open) standaarden, architectuur en sourcing 3. Ten derde moeten de criteria rondom specifieke domeinen worden benoemd. Bijv. op financieel gebied, maar ook bijv. in geval van medische informatie van patiënten, kunnen extra (strengere) criteria gelden 4. Tot slot kunnen criteria gelden die specifiek zijn voor een bepaalde situatie. Bijv. ondersteuning van apparatuur die op bepaalde locaties wordt gebruikt. Deze criteria kunnen vervolgens nog worden verdeeld in: 1. Knock-out criteria, waaraan dus moet worden voldaan, anders valt de leverancier sowieso af 2. Overige criteria. Deze criteria kunnen indien gewenst van weegfactoren worden voorzien zodat het ene criterium vanzelf zwaarder weegt dan het andere. Daarna kan de lijst van criteria worden gebruikt om leveranciers te scoren en aan de hand van deze score objectief te beoordelen. In het volgende schema staan voorbeelden van leverancierscriteria: Voorbeelden van leverancierscriteria 1. Aantal jaar van bestaan, stabiliteit, financiële gezondheid (solvabiliteit) 2. Breedte en diepte van producten- en dienstenaanbod (is het een superspecialist of een meer generieke leverancier) 3. Omvang (leveranciers met ongeveer dezelfde omvang als de eigen organisatie matchen vaak beter, minimale vereiste omvang bij bijv. leverancier van software) V1.4 01-02-2017 Pagina 20-10

MCTL 20. v1.4 4. Vestigingsplaats (een leverancier gevestigd in de nabije omgeving in plaats van Tsjechië of India heeft ook in het huidige tijdsgewricht vaak voordelen) 5. Marktaandeel (niet te klein, maar ook niet te groot) 6. Ervaring met eigen producten en diensten (indien producten/diensten heel innovatief zijn heeft het bedrijf er zelf dus ook nog niet veel ervaring mee) 7. Kennis en ervaring in het vakgebied waarin de eigen organisatie opereert (indien u zelf in de sector gezondheidszorg werkzaam bent en de leverancier geen enkele kennis of ervaring in deze sector heeft, kunnen de producten en diensten van deze leverancier nog zo goed zijn, maar ) 8. Het (aantoonbaar) proactieve gehalte van de dienstverlening (dus niet alleen U vraagt, wij draaien ) 9. Referenties (aantoonbaar vermogen om producten/diensten te kunnen leveren) 10. Duurzaamheidseisen (auto s personeel rijden energiezuinig, kantoor energiezuinig, datacenter met goede PUE Power Usage Effectiveness) Het opstellen en bijhouden van leverancierscriteria is geen al te omvangrijke taak. Doorgaans volstaat om bij de concrete selectie van leveranciers een dergelijk lijstje voorhanden te hebben. Mocht op enig moment (in een van de hierna beschreven activiteiten) het lijstje tekort schieten, dan kan dit op dat moment zelf eenvoudigweg worden uitgebreid/aangepast. Op deze wijze wordt tegen zeer geringe inspanning houvast in het selectieproces verkregen. In het selectieproces kan overigens ook nog gekeken worden naar bijvoorbeeld gunning op basis van EMVI (Economisch meest voordelige inschrijving = kwaliteit + prijs), Laagste prijs (= bij voldoen aan alle criteria wordt alleen op basis van prijs besloten) of een andere basis. Afhankelijk van de omvang van het contract zal een langer of korter besluitvormingsproces moeten worden doorlopen. In de overheidssector wordt soms als extra eis Social return meegenomen. Hierbij wordt van de leverancier een inspanning verwacht om bijvoorbeeld mensen met een afstand tot de arbeidsmarkt extra kansen te bieden. 2. EVALUEREN De lopende contracten worden in deze eerste stap geëvalueerd. Aan de hand van rapportages kan worden vastgesteld of de contracten op het juiste niveau zijn nagekomen. Ook kan worden bekeken of een positieve of negatieve trend in het nakomen van de afspraken is te ontdekken. Immers, wanneer afspraken worden nagekomen maar er is sprake van een langlopende negatieve trend, dan mag worden verwacht dat zonder ingrijpen binnen afzienbare tijd de afspraken niet meer zullen worden nagekomen. Andersom is vanzelfsprekend ook mogelijk; een langlopende positieve trend kan ervoor zorgen dat huidige onderprestaties vanzelf verdwijnen. 3. VASTSTELLEN BENODIGDE AFSPRAKEN KOMEND JAAR V1.4 01-02-2017 Pagina 20-11

MCTL 20. v1.4 Aan de hand van het behoefteplan dat is vastgesteld in het taakgebied Behoeftemanagement is de totale behoefte voor de organisatie voor het komend jaar in beeld. Vervolgens wordt deze behoefte voor het komend jaar gesplitst in behoeften die intern zullen worden gerealiseerd en behoeften die door externe partijen zullen worden ingevuld. Deze afweging wordt in nauw overleg met het taakgebied Capaciteitsmanagement uit het taakcluster Management support gemaakt. Logischerwijs is het intern uitvoeren van taken gebonden aan de beschikbare capaciteit. Er is hier echter een wisselwerking met de buitenwereld: indien met leveranciers slechts contracten zijn aan te gaan tegen zeer hoge kosten of is het simpelweg onmogelijk om bepaalde activiteiten uit te besteden, dan zal via Capaciteitsmanagement interne capaciteit moeten worden geregeld om de taken alsnog uitgevoerd te krijgen. 4. CONTRACTAFSPRAKEN MAKEN/AANPASSEN Indien eenmaal is besloten welke activiteiten komend jaar door externe leveranciers zullen worden uitgevoerd, moeten daarover afspraken worden gemaakt. Over het algemeen zijn daarbij in eerste instantie reeds bestaande leveranciers in beeld; vaak bestaan relaties met leveranciers lange tijd. Toch verdient het aanpassen van afspraken de nodige aandacht. Juist bij afspraken die al langere tijd lopen en zijn ingesleten in de eigen en de leveranciersorganisatie kan het moeite kosten deze aan te passen en vervolgens op gewenste wijze uitgevoerd te krijgen. Voorbeeld inhoudsopgave SLA/contract 1. Afspraken rondom beheer op de overeenkomst 2. Betrokken partijen 3. Onderwerp/context 4. Definitielijst 5. Gerelateerde documenten 6. Scope 7. Beschrijving producten/diensten a. Te leveren producten/diensten (functionaliteit) b. Koppelingen, uitsluitingen (op systeemniveau) c. Onderhoud/releases (frequentie, inhoud) d. Doorontwikkeling/innovatie e. Security, f. Eigendom, broncode, escrow g. Inzet derde partijen h. Overmachtsbepalingen en -regelingen 8. Beschrijving dienstenniveaus (incl. KPI s) a. Response- en oplostijden b. Beschikbaarheid, betrouwbaarheid, c. Service windows 9. Processen/procedures 10. Taken en verantwoordelijkheden/verplichtingen 11. Aansprakelijkheid, beperkingen en uitsluitingen 12. Overlegstructuren, evaluatie en rapportage V1.4 01-02-2017 Pagina 20-12

MCTL 20. v1.4 13. Escalaties, geschillenprocedure 14. Afspraken bij (niet) nakomen afspraken (bonus/malus) 15. Exit-afspraken, overdracht, ontbindingscondities 16. Kosten, facturatie, meerwerk, prijsgaranties 17. Looptijd, verlenging De concrete realisatie van de afspraken kunnen apart in een DAP worden vastgelegd. Bij een dergelijke splitsing concentreert de SLA/het contract zich op het wat en de DAP op het hoe. Voorbeeld inhoudsopgave DAP (Dossier afspraken procedures) 1. Afspraken rondom beheer op de overeenkomst 2. Onderwerp/doel 3. Doelgroep 4. Definitielijst 5. Gerelateerde documenten a. Bijbehorende contract(en) b. Bijbehorende SLA( s) 6. Scope 7. Werkgebied a. Beheerprocessen (evt. per product/dienst/werkproces) b. Beheertaken, bevoegdheden, verantwoordelijkheden 8. Communicatie a. Contactpersonen b. Procedures (flow) c. Templates, formulieren d. Overlegvormen (operationeel, tactisch, strategisch) e. Rapportages (voorbeelden) f. Escalatiepaden 9. Tools & integratie a. Gezamenlijk gebruik tools b. Koppelingen tussen tools c. Afspraken rondom gebruik d. 10. Bijlagen a. Functies/rollen b. Contactpersonen (afdeling, rol, naam, tel, e-mail, ) In het geval nieuwe activiteiten moeten worden uitgevoerd waarvoor bestaande leveranciers niet in aanmerking komen, dan moet uiteraard worden gezocht naar andere leveranciers. Ook bij bestaande activiteiten met bestaande leveranciers is het geen vanzelfsprekendheid (of dat zou het in ieder geval niet moeten zijn) dat deze leveranciers voor het komend jaar het contract krijgen. Periodiek moet binnen het aanbod van V1.4 01-02-2017 Pagina 20-13

MCTL 20. v1.4 leveranciers opnieuw worden bekeken wat voor het komende jaar de beste set leveranciers is. Leverancierscriteria zijn onontbeerlijk om een zo objectief mogelijke keuze te kunnen maken. Deze zijn reeds eerder beschreven. Uiteindelijk moet er tijdig, vanzelfsprekend voor de start van het nieuwe jaar, een volledige set contracten zijn waarmee de totale behoefte aan door leveranciers te leveren producten en diensten voor het komende jaar is afgedekt. Hoewel dit een enorme open deur is, blijkt dit in veel organisatie niet op orde te zijn. De voornaamste oorzaak hiervoor is eenvoudigweg een gebrek aan aandacht. Enkele schema s die kunnen helpen bij het afsluiten, aanpassen en beëindigen van contracten: V1.4 01-02-2017 Pagina 20-14

MCTL 20. v1.4 V1.4 01-02-2017 Pagina 20-15

MCTL 20. v1.4 Deze schema s spreken voor zichzelf en worden daarom niet verder toegelicht. 5. DOEN UITVOEREN VAN CONTRACTEN, BEWAKEN EN (TUSSENTIJDS) BIJSTELLEN Bewaking van levering van producten en diensten wordt over het algemeen door leveranciers zelf uitgevoerd. Hierbij is sprake van de slager die zijn eigen vlees keurt. Het is daarom niet afdoende voor de eigen organisatie. Binnen de eigen organisatie zal een eigen bewaking moeten worden uitgevoerd op het daadwerkelijk nakomen van contracten door leveranciers. Bovendien speelt mee dat feitelijk geen behoefte is aan individuele producten en diensten, maar aan optimaal functionerende, geïntegreerde bedrijfsprocessen. Vanuit klantperspectief moet daarom voor een andere invalshoek worden gekozen en daarmee komt vaak een samenstelsel van (deel-)activiteiten van diverse leveranciers in beeld. Het is in de praktijk een bekend verschijnsel: een bepaald bedrijfsproces verloopt niet goed, maar de leveranciers van de onderliggende individuele componenten (software, hardware) blijven elkaar de schuld geven van de problemen. Oorzaak kan zijn dat de contracten niet goed (genoeg) zijn, maar de coördinatie om dit soort situaties op te lossen ligt over het algemeen in de eigen interne organisatie. Ook deze integratie is uit te besteden aan een system integrator, maar dit is meer uitzondering dan regel. Het bewaken van bedrijfsprocessen en rapporteren hierover kan dus het beste vanuit gebruikersperspectief worden gedaan: eerst aangeven hoe vaak een bedrijfsproces problemen heeft ondervonden, dan kijken naar de onderliggende oorzaken en vervolgens naar de daarvoor relevante contractuele afspraken. Op deze wijze kunnen contractuele afspraken in een breder perspectief worden gezien. Een leverancier moet natuurlijk altijd worden aangesproken op de contractuele afspraken, maar het is verstandig het eigen belang van de business in het oog te houden. Te vaak worden alle, dus ook niet zulke ingrijpende, issues bij leveranciers hoog opgespeeld waardoor alle krediet verspeeld is op het moment dat er werkelijk brand is. Ook indien alle contractuele verplichtingen keurig zijn nagekomen maar er tussentijdse wensen zijn ontstaan die niet contractueel worden afgedekt moet hier actie worden ondernomen. Tussentijdse afspraken, afwijkend van de lopende contracten, zijn in het algemeen voor leveranciers geen probleem. Voor de eigen organisatie kan dat wel zo zijn: indien het geheel (te) star is ingericht, dan zijn de mogelijkheden voor aanpassing klein. Vaak is het verstandig niet meteen contracten open te breken maar in eerste instantie een losse aanvulling op dat contract af te spreken. Indien blijkt dat het geen eenmalige maar structurele wijziging in behoeften is kan het in de jaarlijkse update ronde worden meegenomen om een contract te creëren dat deze behoeften geheel dekt. RELATIES MET ANDERE ONDERDELEN VAN MCTL V1.4 01-02-2017 Pagina 20-16

MCTL 20. v1.4 Dit taakgebied kent de volgende belangrijke relaties: Ten eerste is er een duidelijke relatie met Behoeftemanagement. De voor het komend jaar gedefinieerde behoeften hebben consequenties voor de inzet van externe leveranciers. Andersom kan het voorkomen dat door gebrek aan leveranciers of een bepaald productdienstportfolio van de leveranciers het gedefinieerde behoefteplan moet worden aangepast. Daarnaast is er een belangrijke relatie met de taakclusters Operationeel support en Change support. In deze twee taakclusters zullen taken, deels intern en deels extern, worden uitgevoerd. De externe uitvoering van taken is gebaseerd op de afgesloten contracten. Andersom zal vanuit de dagelijkse gang van zaken een terugkoppeling plaatsvinden waardoor contracten stapsgewijs verder kunnen worden verbeterd. Tot slot kan de relatie met Management support worden gelegd omdat contracten uit de aard van de zaak een financiële, capaciteits- en kwaliteitscomponent hebben. Deze relatie is tweezijdig; vanuit Management support worden kaders gesteld maar vanuit Contractmanagement wordt op basis van concrete contracten een terugkoppeling gegeven. OPMERKINGEN De volgende opmerkingen zijn te maken in het kader van contractmanagement: V1.4 01-02-2017 Pagina 20-17

MCTL 20. v1.4 1. DEKKINGSGRAAD PDC VERSUS ALLE INTERNE TAKEN + CONTRACTEN/SLA S Om een overall controle uit te oefenen op de dekkingsgraad van alle contracten/sla s tezamen kan de volgende formule worden gebruikt: Realisatie PDC = totaal(contracten/sla s) + totaal(intern uitgevoerde werkzaamheden) Ofwel: Totaal(contracten/SLA s) = Realisatie PDC totaal(intern uitgevoerde werkzaamheden) Op deze wijze kunnen vrij snel gaten in de totale dienstverlening aan de gebruikers versus contracten/sla s worden opgespoord. 2. RESULTAAT- VERSUS INSPANNINGSVERPLICHTINGEN Een punt waarin afnemers lijnrecht tegenover leveranciers terecht kunnen komen is in de vorm waarin verplichtingen worden afgesproken. Een leverancier zal geneigd zijn verplichtingen in de vorm van inspanningsverplichtingen te gieten. Een afnemer heeft goed beschouwd echter niet zoveel aan inspanningen; een afnemer wil concreet resultaat! Het verschil tussen inspannings- en resultaatverplichtingen Een leverancier zal in het geval van ernstige storingen in de door haar geleverde hard- of software doorgaans aanbieden daar een oplossing voor te bieden. Afspraken hebben dan al snel de vorm van we zullen er binnen twee uur naar kijken of er zal binnen één uur aan gewerkt worden of er zal binnen één uur na melding worden gereageerd. Vanuit het perspectief van de afnemer moeten afspraken echter de vorm hebben van binnen twee uur na melding is de storing verholpen. Hoewel vanuit leveranciersperspectief het alleszins begrijpelijk is dat zij aankoersen op inspanningsverplichtingen, zal het toch duidelijk zijn dat vanuit gebruikersperspectief resultaatverplichtingen noodzakelijk zijn. Alleen in zeer uitzonderlijke omstandigheden kan daarvan worden afgeweken, bijv. in innovatieve omgevingen waarin van beide zijden wordt geaccepteerd dat onverwachte gebeurtenissen ook een onvoorspelbaar oplostraject teweegbrengt waarvan niet op voorhand de doorlooptijden en dergelijke zijn af te spreken. Bovendien is het toch wel zo dat een afnemer uiteindelijk betaald voor hetgeen wordt afgesproken, en wie betaalt, bepaald is ook hier geen verkeerd uitgangspunt. 3. VERBODEN TERMEN EN ZINSCONSTRUCTIES IN CONTRACTEN V1.4 01-02-2017 Pagina 20-18

MCTL 20. v1.4 Het is helemaal geen gek idee om een lijst aan te leggen van termen en zinsconstructies de in principe niet in een contract voor zouden mogen komen. Het geeft een interne trigger om afspraken te maken die SMART zijn. Voorbeelden van dergelijke verboden termen/zinsconstructies zijn: Zo min mogelijk Zoveel mogelijk Zal zich maximaal inspannen Best effort Zo spoedig mogelijk Streven naar In onderling overleg Zal binnen x tijd reageren op U kunt dit lijstje ongetwijfeld zonder enige moeite uitbreiden. Een dergelijk lijstje kan bij het inhoudelijk checken van contracten van dienst zijn en in de loop van de tijd verder compleet gemaakt. 4. HET MAXIMAAL UITNUTTEN VAN BESTAANDE CONTRACTEN Het is bepaald geen uitzondering dat in contracten producten en diensten worden beschreven die in de praktijk in het geheel niet worden uitgevoerd. Dat kan worden veroorzaakt door gebruikers die eenvoudigweg niet vragen om de betreffende producten of diensten. Het komt ook voor dat gebruikers zelf werkzaamheden verrichten omdat niet bekend is dat er een contract is waarin deze werkzaamheden met een leverancier zijn afgesproken. Tot slot komt het voor dat werkzaamheden intern worden verricht omdat de leverancier meermalen heeft verzaakt. In dat laatste geval wordt de leverancier feitelijk beloond voor slecht werk. Op lange termijn is het vanzelfsprekend zaak dat contracten precies de behoefte afdekken, maar op kortere termijn is het in ieder geval geen verkeerde zaak om contracten maximaal uit te nutten; op alles wat in de contracten is opgenomen moet de leverancier actief worden aangesproken. Ook indien een leverancier in gebreke blijft, moet niet de reflex zijn om het dan maar zelf te gaan doen. De leverancier moet in dat geval net zo lang aangesproken blijven worden tot het werk volledig en op voldoende niveau wordt uitgevoerd, ofwel moet het contract uiteindelijk worden aangepast of beëindigd. CERTIFICERING/PROEFEXAMENVRAGEN Voor MCTL kunt u zich certificeren op foundation, advanced en expert level. Het foundation niveau toetst uw kennis van MCTL. Het advanced en expert level toetsen uw vaardigheid in het toepassen van MCTL. In hoofdstuk 35 vindt u alle informatie over de drie levels. Hierna vindt u proefexamenvragen op foundationniveau. Aansluitend treft u een aantal vragen aan op advanced basisniveau. 1. MCTL FOUNDATION - PROEFEXAMENVRAGEN V1.4 01-02-2017 Pagina 20-19

MCTL 20. v1.4 Voor dit hoofdstuk zijn de volgende proefexamenvragen beschikbaar. Maak deze zonder terug te bladeren. De feedback vindt u direct hierna. 20-1. Het doel van Contractmanagement is: a. Het maken van duidelijke, meetbare afspraken met in- en externe partijen betreffende de levering en ondersteuning van informatiesystemen b. Het maken van afspraken met externe partijen in de vorm van contracten over het komend jaar c. Het opstellen en afsluiten van contracten voor de komende 3-5 jaar d. Het opstellen van afspraken met de interne gebruikersorganisatie zodat helder is waar zij op mogen rekenen in het komende jaar 20-2. Als in Contractmanagement geen contracten/sla s met de gebruikersorganisatie worden gemaakt, hoe kan de gebruikersorganisatie er dan op rekenen dat er toch gebeurt wat gewenst is? a. Er worden wel afspraken gemaakt, maar deze worden ISA s genoemd: Information Service Agreements b. Er worden wel afspraken gemaakt, maar die heten anders c. Informeel is in een organisatie altijd alles te regelen wat nodig is. Indien nodig kan ook het lijnmanagement op elk moment sturen en bijsturen d. Door een gezamenlijke externe focus (op de te leveren producten en diensten) ontstaat ook een interne focus. Daarnaast bestaat er een PDC 20-3. Contracten in Contractmanagement kunnen de volgende gebieden omvatten: a. Levering van computertechnologie (hardware, software, databasetechnologie) met bijbehorende diensten b. Datalevering c.q. -uitwisseling c. Levering van computertechnologie (hardware, software, databasetechnologie) en functioneel support en alle hierbij bijbehorende diensten d. Levering van computertechnologie, functioneel support en datalevering c.q. -uitwisseling 20-4. Worden in Contractmanagement ook leverancierscriteria opgesteld? a. Nee, in Contractmanagement worden ze alleen beheerd b. Nee, Leverancierscriteria horen bij het taakgebied Kwaliteitsmanagement c. Ja, dat vindt (indien nodig) ook plaats als onderdeel van de activiteit Beheer leverancierscriteria d. Ja, maar alleen specifieke criteria. Generieke criteria komen bij bijv. afd. Inkoop verder aan bod en blijven hier buiten beschouwing 20-5. Contracten zijn er om na te leven. Is het mogelijk om tussentijds contracten aan te passen in Contractmanagement, of moet dat, indien van toepassing, per individueel geval in Operationeel support worden gedaan? a. Ja, contracten kunnen indien nodig tussentijds worden bijgesteld. Beperking hiervan wordt aanbevolen, doorgaans is een losse aanvullende afspraak afdoende. Maar het kan dus wel b. Ja, contracten kunnen worden bijgesteld, maar alleen indien daar vooraf met de leverancier afspraken over zijn gemaakt V1.4 01-02-2017 Pagina 20-20

MCTL 20. v1.4 c. Nee, contract is contract, dus dat wordt precies zoals het is afgesproken nagekomen. Natuurlijk kunnen andere producten/diensten worden geleverd door een leverancier, maar dat wordt dan in een nieuw, aanvullend, contract geregeld d. Nee, leveranciers zijn hier niet op ingericht dus een jaarlijkse update is al een heel hoge frequentie. Tussentijds zijn aanpassingen onmogelijk 2. MCTL FOUNDATION PROEFEXAMENVRAGEN MET ANTWOORDEN EN FEEDBACK Hierna vindt u de proefexamenvragen direct daarachter de antwoorden en feedback. 20-1. Het doel van Contractmanagement is: a. Het maken van duidelijke, meetbare afspraken met in- en externe partijen betreffende de levering en ondersteuning van informatiesystemen b. Het maken van afspraken met externe partijen in de vorm van contracten over het komend jaar c. Het opstellen en afsluiten van contracten voor de komende 3-5 jaar d. Het opstellen van afspraken met de interne gebruikersorganisatie zodat helder is waar zij op mogen rekenen in het komende jaar a. Onjuist. Het maken van afspraken met interne partijen (m.n. gebruikersorganisatie) is conform MCTL helemaal niet nodig en het gaat in MCTL niet (alleen maar) over informatiesystemen. b. Juist. Dit is precies de definitie die in MCTL wordt gebruikt. Zie hoofdstuk 20. c. Onjuist. De termijn die in Contractmanagement wordt gehanteerd is 1 jaar. Natuurlijk kunnen contracten een langere looptijd hebben, maar ze moeten dan elk jaar worden herzien zodat ze actueel blijven. d. Onjuist. In MCTL worden juist geen (contractuele) afspraken gemaakt met de interne organisatie, maar alleen met externe partijen. 20-2. Als in Contractmanagement geen contracten/sla s met de gebruikersorganisatie worden gemaakt, hoe kan de gebruikersorganisatie er dan op rekenen dat er toch gebeurt wat gewenst is? a. Er worden wel afspraken gemaakt, maar deze worden ISA s genoemd: Information Service Agreements b. Er worden wel afspraken gemaakt, maar die heten anders c. Informeel is in een organisatie altijd alles te regelen wat nodig is. Indien nodig kan ook het lijnmanagement op elk moment sturen en bijsturen d. Door een gezamenlijke externe focus (op de te leveren producten en diensten) ontstaat ook een interne focus. Daarnaast bestaat er een PDC a. Onjuist. ISA s worden benoemd in FSM, een procesmodel met daarin processen voor het functionele domein. b. Onjuist. Er worden geen afspraken gemaakt in de vorm van contracten, SLA s of wat dan ook. c. Onjuist. Het is zeker zo dat binnen een organisatie ook informeel veel is te regelen, Vaak is dit de smeerolie van de organisatie. Er mag echter niet volledig op worden vertrouwd/gebouwd. V1.4 01-02-2017 Pagina 20-21

MCTL 20. v1.4 d. Juist. Een externe focus (op klanten, patiënten, burgers, cliënten, andere bedrijven etc. met de daaraan te leveren producten/diensten) geeft ook intern focus. Een interne PDC geeft daarbij extra houvast. Zie hoofdstuk 20. 20-3. Contracten in Contractmanagement kunnen de volgende gebieden omvatten: a. Levering van computertechnologie (hardware, software, databasetechnologie) met bijbehorende diensten b. Datalevering c.q. -uitwisseling c. Levering van computertechnologie (hardware, software, databasetechnologie) en functioneel support en alle hierbij bijbehorende diensten d. Levering van computertechnologie, functioneel support en datalevering c.q. -uitwisseling a. Onjuist. Dit is een van de gebieden, maar antwoord d is vollediger. b. Onjuist. Dit is een van de gebieden, maar antwoord d is vollediger. c. Onjuist. Dit zijn twee van de gebieden, maar antwoord d is vollediger. d. Juist. Deze drie elementen kunnen allemaal aan bod komen in contracten binnen Contractmanagement. Zie hoofdstuk 20. 20-4. Worden in Contractmanagement ook leverancierscriteria opgesteld? a. Nee, in Contractmanagement worden ze alleen beheerd b. Nee, Leverancierscriteria horen bij het taakgebied Kwaliteitsmanagement c. Ja, dat vindt (indien nodig) ook plaats als onderdeel van de activiteit Beheer leverancierscriteria d. Ja, maar alleen specifieke criteria. Generieke criteria komen bij bijv. afd. Inkoop verder aan bod en blijven hier buiten beschouwing a. Onjuist. Naast het beheer worden leverancierscriteria hier indien nodig ook opgesteld. b. Onjuist. Het is onderdeel van het taakgebied Contractmanagement. c. Juist. Het opstellen en actueel houden van leverancierscriteria valt onder de activiteit Beheer leverancierscriteria in het taakgebied Contractmanagement. d. Onjuist. Het kan zeker zo zijn dat bepaalde criteria op ander plaatsen in de organisatie ontstaan, maar in Contractmanagement wordt er één geheel van gemaakt. 20-5. Contracten zijn er om na te leven. Is het mogelijk om tussentijds contracten aan te passen in Contractmanagement, of moet dat, indien van toepassing, per individueel geval in Operationeel support worden gedaan? a. Ja, contracten kunnen indien nodig tussentijds worden bijgesteld. Beperking hiervan wordt aanbevolen, doorgaans is een losse aanvullende afspraak afdoende. Maar het kan dus wel b. Ja, contracten kunnen worden bijgesteld, maar alleen indien daar vooraf met de leverancier afspraken over zijn gemaakt c. Nee, contract is contract, dus dat wordt precies zoals het is afgesproken nagekomen. Natuurlijk kunnen andere producten/diensten worden geleverd door een leverancier, maar dat wordt dan in een nieuw, aanvullend, contract geregeld d. Nee, leveranciers zijn hier niet op ingericht dus een jaarlijkse update is al een heel hoge frequentie. Tussentijds zijn aanpassingen onmogelijk a. Juist. Het is mogelijk, hoewel het aan te bevelen is dit te beperken. V1.4 01-02-2017 Pagina 20-22

MCTL 20. v1.4 b. Onjuist. Het is natuurlijk verstandig om vooraf met leveranciers af te spreken hoe er wordt omgegaan met tussentijdse aanpassingen, maar dat is niet noodzakelijk. c. Onjuist. Contracten kunnen wel degelijk tussentijds worden bijgesteld, er hoeft niet steeds een nieuw contract te worden opgesteld. d. Onjuist. Leveranciers zijn doorgaans absoluut genegen hun klanten ter wille te zijn en tussentijdse aanpassingen horen daarbij. 3. MCTL ADVANCED-BASIS - PROEFEXAMENVRAGEN Voor dit hoofdstuk zijn de volgende proefexamenvragen op advanced-basisniveau beschikbaar. Het zijn open vragen waarop u de antwoorden in de tekst van dit hoofdstuk kunt terugvinden. Om veel herhaling te voorkomen is daarom hier geen aparte uitleg per vraag opgenomen. Vraag 1 (5 punten): Leg in eigen bewoordingen uit hoe het mogelijk is dat zonder interne afspraken tussen intern applicatie en infrasupport en de gebruikersorganisatie toch precies wordt gedaan wat moet worden gedaan door die supportgroepen. Vraag 2 (5 punten): Beschrijf het nut van leverancierscriteria. Vraag 3 (5 punten): In SLA s/contracten worden vaak afspraken gemaakt over de te leveren producten en diensten. Ook levering van data kan via een SLA/contract worden geregeld. Geef minstens twee aandachtspunten die specifiek geleden voor dat soort diensten. Vraag 4 (5 punten): Bewaking op uitvoering van contracten wordt doorgaans door leveranciers zelf uitgevoerd. Beschrijf in eigen woorden waarom ook de klant de levering van producten en diensten moet bewaken. Vraag 5 (5 punten): Het komt voor dat in contracten producten en diensten zijn beschreven die in werkelijkheid in het geheel niet worden geleverd. Noem twee oorzaken van dit fenomeen. NUTTIGE WEBSITES EN BOEKEN De volgende websites zijn voor taakgebied Contractmanagement (vanuit functioneel oogpunt gezien) interessant: www.mctl.nl MCTL.nl Website met alle informatie over MCTL; de achtergrond, een beschrijving van het model, video s, artikelen, etc. etc. Alle documenten, waaronder dit document, zijn vanaf deze website te downloaden. www.bisl.nl V1.4 01-02-2017 Pagina 20-23

MCTL 20. v1.4 BiSL.nl Website met alle informatie over BiSL. BiSL is, als voorganger van MCTL, interessant vanwege de verzameling Best Practices, whitepapers en artikelen die op deze website zijn te vinden. www.ismportal.nl/nl/fsm-procesmodel FSM Website met alle informatie over FSM. FSM is een compacte out-of-the-box versie van BiSL. De praktische vertaling in dit model is absoluut de moeite waard. De volgende boeken zijn voor taakgebied Contractmanagement (vanuit functioneel oogpunt gezien) interessant: Beckum, J. van & Vlasveld, G. J. (2014). CATS CM. Zaltbommel: Van Haren Publishing. Benyon, R. & Johnston, R. (2006). Service Agreements A Management Guide. Zaltbommel: Van Haren Publishing. Best, B. de (2014). SLA. Lierderholthuis: Leonon Media. Pols, R. van der (2009). Modern leveranciersmanagement. Den Haag: Sdu. Wit, M. de (2013). Het kan ook goed gaan. Reeuwijk: Double IT. Sieders, R., Pols, R. van der (2016), Leverancierssturing. Amsterdam: Academic Service. V1.4 01-02-2017 Pagina 20-24