4.5 Garantie op beheer

H04

06-10-2004

09:46

4.5

Pagina 183

Garantie op beheer Een SLA is meer dan een beschikbaarheidsgarantie

Auteurs:

Mr. drs. Lesley C.P. Broos is werkzaam als informaticadeskundige en senior ITjuridisch adviseur bij IT-adviesbureau Mitopics; hij houdt zich onder andere bezig met ICT-contracten waaronder (out)sourcingsovereenkomsten en SLA’s. Mr. Natascha K. van Mullem is eveneens IT-juridisch adviseur bij Mitopics en houdt zich ook met alle vormen van ICTcontracten bezig. E-mail: [email protected] en [email protected].

Dit artikel beschrijft – vanuit klantperspectief – de details van garantiebepalingen in de context van IT-beheer. In de Service Level Agreement dus. Veel SLA’s lijken zich te beperken tot een beschrijving van veelvoorkomende kwaliteitsnormen, zoals beschikbaarheid en performance. Maar vaak zijn andere afspraken en garanties eigenlijk veel belangrijker. Het onderscheid tussen deugdelijkheidsgaranties en zekerheidsgaranties komt hierbij om de hoek kijken. En een verdeling van de verantwoordelijkheden, tussen opdrachtgever en leverancier. Het devies is dus: maak garanties in de SLA zo concreet en expliciet mogelijk. Daar is uiteindelijk zowel klant als leverancier het best mee gediend.

H04

06-10-2004

09:46

Pagina 184

Deel 4 Outsourcing

INLEIDING Dit artikel gaat in op garanties in een beheercontext. Contractuele garanties omvatten vaak juist beperkingen van garanties. Hoe werkt dat eigenlijk bij Service Level Agreements (SLA’s)? SLA’s specificeren primair het kwaliteitsniveau van de dienstverlening en zijn als zodanig op te vatten als contractuele garanties op die dienstverlening. Of moeten we hier ook spreken van garantiebeperkingen? Verder lijken veel SLA’s zich te beperken tot een beschrijving van enkele veelvoorkomende kwaliteitsnormen zoals beschikbaarheid en soms performance. Er is echter meer dan dat mogelijk. Vaak zijn andersoortige, meer op de specifieke dienstverlening en omstandigheden toegeschreven ‘garanties’ ook relevanter. Daarnaast worden bepaalde onderdelen uit de SLA vaak ten onrechte als ‘garantie’ gepresenteerd; het betreft dan slechts nadere beschrijvingen van de dienstverlening. Dit artikel is met name vanuit klantperspectief geschreven.1

WETTELIJKE GARANTIE Voor een goed begrip is het handig om even iets meer achtergrond van garantiebepalingen in ons rechtsstelsel te kennen. De stelling dat contractuele garanties veelal juist beperkingen van garanties omvatten, veronderstelt het volgende: als partijen geen garanties met elkaar overeenkomen, zou er toch sprake zijn van garantie. Tot op zekere hoogte is dit ook waar. We noemen dit de wettelijke garantie en deze vloeit voort uit de zogenaamde conformiteitseis uit art. 7:17 van het Burgerlijk Wetboek. Deze conformiteitseis stelt, kort gezegd, dat een geleverde prestatie moet voldoen aan datgene wat een opdrachtgever daar redelijkerwijs van had mogen verwachten. Deze redelijke verwachting wordt vervolgens gerelateerd aan de uitingen van de leverancier (offerte, gesprekken, et cetera) en hetgeen in de markt gebruikelijk is. Zo mag u, tenzij u anders overeengekomen bent met uw leve-

184

rancier, verwachten dat een pc minstens drie of vier jaar meegaat, gezien de gebruikelijke economische levensduur daarvan. Als u contractueel een ‘garantie’ van drie maanden overeenkomt, beperkt u derhalve de wettelijke garantie. Ook mag u, tenzij u anders overeenkomt, verwachten dat een softwarepakket dat stand-alone draait op een pc die voldoet aan de minimum-eisen die op de verpakking van dat softwarepakket stonden, bij normaal gebruik een redelijke performance geeft. Ook als u dus geen expliciete afspraak over de performance heeft gemaakt. Als u met uw leverancier, bijvoorbeeld in het contract, concrete responstijden afspreekt voor bepaalde programmafuncties, wijkt u gezamenlijk af van deze wettelijke garantie op dat punt. Stel: u mag bij een bepaald softwarepakket, gezien hetgeen in de markt gebruikelijk is en de aard van de programmafunctie, op een responstijd van ongeveer een seconde rekenen voor het opvragen van klantgegevens bij een telefonische helpdesk. Als dan in het contract met uw leverancier bij de garantiebepalingen staat dat de gemiddelde responstijd vijf seconden bedraagt, is dat dus een garantiebeperking. Als u echter een kortere responstijd zou zijn overeengekomen, levert dat een verruiming ten opzichte van de wettelijke garantie op. Het grote probleem met de wettelijke garantie is uiteraard de ellenlange discussie (en menigmaal de daaruit voortvloeiende geschillen) die ontstaat bij het terugvallen op die garantie. Men moet vaststellen wat dan precies de norm van de wettelijke garantie is in een concreet geval. Partijen doen er over het algemeen dan ook verstandig aan om in het contract de garantie te concretiseren, al dan niet middels verruiming of inperking.

GARANTIE VERSUS ONDERHOUD Door gebrek aan juridische kennis komt het nogal eens voor dat ICT-ondernemers garantie en onderhoud op één hoop gooien. Neem de situatie dat een softwarepakket eerst geïmplementeerd wordt en vervolgens het systeem IT Beheer Jaarboek 2004/2005

H04

06-10-2004

09:46

Pagina 185

4.5 Garantie op beheer

Wat zeggen de leveranciersvoorwaarden? Een mooi voorbeeld van een in de ICT-branche gangbare beperking van de wettelijke garantie betreft de verplichting van leverancier tot herstel van gebreken. De wettelijke conformiteitseis volgend, geldt als hoofdregel dat als een softwareprogramma niet voldoet aan de verwachting die de afnemer daarvan redelijkerwijs mocht hebben, de afnemer de leverancier in gebreke dient te stellen. De afnemer biedt de leverancier daarbij een redelijke termijn om alsnog het gebrek te herstellen. Gebeurt dat niet, dan ontstaat voor de afnemer een recht op ontbinding van de overeenkomst en eventueel een recht op schadevergoeding. In veel leveringsvoorwaarden van leveranciers, waaronder de in de ICT veelgebruikte maar uiterst leveranciersvriendelijke Fenit-voorwaarden, wordt de definitie van gebrek beperkt tot ‘afwijking van schriftelijke specificaties’ of zelfs ‘substantiële afwijking van schriftelijke specificaties’. De verwachting die de afnemer redelijkerwijs mag hebben, zal echter vaak veel meer gebaseerd zijn op de mooie presentaties van de leverancier in het voortraject of op de offerte, dan sec op de schriftelijke specificaties van de programmatuur. Dit terwijl in die presentaties en offertes doorgaans mooiere dingen worden beloofd dan in de schriftelijke specificaties na te lezen zijn. Ook is in veel voorwaarden geregeld dat als er al sprake zou zijn van een gebrek in enge zin, de leverancier dan de weg openhoudt om herstel van het gebrek uit te stellen tot de volgende release van de software. Dit moment kan veel verder weg liggen dan het einde van de redelijke termijn die de klant dient te stellen bij de ingebrekestelling. We zien hier dat de wettelijke garantie vergaand wordt beperkt, zowel qua toepassing (wanneer is er sprake van een gebrek waarbij een beroep op garantie openstaat?) als qua herstelverplichting.

door diezelfde leverancier in onderhoud wordt genomen. Er ontstaat discussie over garantie op de implementatie (bijvoorbeeld samenhangende werking standaardsoftware en maatwerk, juiste parametrisering ter realisatie van de overeengekomen functionaliteit, et cetera). Deze discussie wordt dan niet zelden afgedaan als irrelevant, omdat eventuele problemen ‘gedekt zouden zijn door het onderhoudscontract’. Nog los van de vraag of het onderhoudscontract inderdaad een verplichting bevat om bepaalde gebreken te herstellen, is de kern van deze gedachtegang niet juist. De implementatie en de onderhoudswerkzaamheden omvatten beide opzichzelfstaande verplichtingen die aan een zekere kwaliteit dienen te voldoen. En dus zal zowel de garantie op de implementatie als de garantie op het onderhoud beschreven moeten worden. Het is zaak deze discussie te onderscheiden van de meer commerciële discussie. Die behelst vragen als: vanaf wanneer moet er voor updates/onderhoudswerkzaamheden betaald worden, zodat er geen dubbele betaling plaatsvindt voor het oplossen van gebreken tijdens de garantieperiode op de implementaIT Beheer Jaarboek 2004/2005

tie? De garantie op de implementatie vertegenwoordigt immers een waarde waarvoor klant een vergoeding zal hebben betaald (als – doorgaans niet expliciet benoemd – onderdeel van de implementatiekosten), en voor het onderhoud wordt eveneens een vergoeding betaald. Deze twee vergoedingen kunnen echter betrekking hebben op dezelfde werkzaamheden, namelijk het herstellen van gebreken net na de implementatie.

VELE SOORTEN VAN BEHEER Beheer kent velerlei vormen en niveaus van intensiteit. Het kan het periodiek uitvoeren van bepaalde standaardwerkzaamheden omvatten (bijvoorbeeld eens in de maand tunen van een database), het kan sec reactief worden ingezet (incidenten onderzoeken nadat deze gemeld worden) en het kan veelomvattend en pro-actief zijn (het in de lucht houden van bepaalde functionaliteit). Hoewel al deze verschijningsvormen als gemeenschappelijk kenmerk hebben dat het om dienstverlening gaat, het verrichten van werkzaamheden, zal duidelijk zijn dat het karakter ervan zeer be-

185

H04

06-10-2004

09:46

Pagina 186

Deel 4 Outsourcing

palend is voor de soort garantie die daarbij past. Bij het periodiek uitvoeren van standaardwerkzaamheden kan een belangrijk kwaliteitskenmerk zijn dat de betreffende handeling het operationeel gebruik van het systeem niet verstoort. Bij het onderzoeken van incidenten kan de oplostijd een belangrijk kwaliteitskenmerk zijn, en bij het in de lucht houden van functionaliteit vormt de mate van beschikbaarheid mogelijk een belangrijke eigenschap om gegarandeerd te krijgen.

DEUGDELIJKHEIDSGARANTIES EN ZEKERHEIDSGARANTIES Deze drie voorbeelden laten zien dat er sprake is van verschillende soorten garanties. Dat het operationeel gebruik van het systeem niet verstoord wordt door de uitvoering van een bepaalde beheeractiviteit (het tunen van de database) zegt op zich nog niets over hoe goed de database getuned wordt. Het betreft hier een zogenaamde zekerheidsgarantie; er wordt ingestaan voor het al dan niet intreden van een bepaalde gebeurtenis op een bepaald tijdstip [Dunné 2001]. Het tweede garantievoorbeeld hierboven (oplostijd bij het onderzoeken van incidenten) betreft een deugdelijkheidsgarantie: er wordt ingestaan voor de kwaliteit of deugdelijkheid van de prestatie. Het derde voorbeeld (beschikbaarheidsgarantie) kan eveneens als deugdelijkheidsgarantie worden aangemerkt. Het onderscheiden van deugdelijkheidsgaranties en zekerheidsgaranties biedt in de praktijk vaak een handig hulpmiddel om tot een uitgebalanceerde set aan garanties te komen. Doorgaans is het goed om voor een prestatie zowel deugdelijkheidsgaranties als zekerheidsgaranties overeen te komen. Ter illustratie nog een keer onze garantievoorbeelden van hierboven: in het eerste voorbeeld had naast de zekerheidsgarantie (niet verstoren van operationeel gebruik van het systeem) bijvoorbeeld als kwaliteitsgarantie kunnen worden overeengekomen dat het tunen van de database door een ter zake kundig persoon dient te worden

186

uitgevoerd, met inachtneming van de geldende beveiligingsprocedures, et cetera. In het voorbeeld van de incidentanalyses zou naast de deugdelijkheidsgarantie kunnen worden afgesproken dat het percentage incidenten ieder jaar zal afnemen met x% (zekerheidsgarantie). In het voorbeeld van het in de lucht houden van bepaalde functionaliteit zou aanvullend op de beschikbaarheidsgarantie als zekerheidsgarantie overeengekomen kunnen worden dat er een bepaald minimaal efficiency-voordeel met die functionaliteit zal worden gerealiseerd.

Afnemers opgelet: de veelgebruikte Fenitvoorwaarden zijn wel érg leveranciersvriendelijk INSPANNING OF RESULTAAT? Het onderscheid tussen zekerheidsgaranties en deugdelijkheidsgaranties werkt vaak praktischer dan het veel vaker gehanteerde onderscheid tussen inspanning en resultaat. Er worden tijdens onderhandelingen vaak discussies gevoerd over de vraag of een bepaalde prestatieverplichting nu een inspannings- of een resultaatsverbintenis is. Het is echter maar net op welk niveau je naar een prestatie kijkt: in het voorbeeld van het tunen van de database kan men zeggen dat het om een inspanningsverplichting gaat om te komen tot een beter getunede database, maar evengoed kan men zeggen dat het een resultaatsverbintenis betreft. Het gaat er immers niet om dat iemand zijn best doet om elke maand te verschijnen om de database te tunen, maar om het resultaat: dat er elke maand daadwerkelijk iemand die database tunet. Ook kan nog gesteld worden dat het een resultaatsverbintenis is en dat het resultaat een beter getunede database moet zijn. Hoe dan ook, het kwalificeren in termen van inspannings- of resultaatverbintenis helpt partijen in dit geval niet veel verder in het verduidelijken van de te leveren prestatie. Het hanteren van de beschikbaarheidsgarantie lijkt duidelijker: het in de lucht houden IT Beheer Jaarboek 2004/2005

H04

06-10-2004

09:46

Pagina 187

4.5 Garantie op beheer

van bepaalde functionaliteit met een gegarandeerde beschikbaarheid wordt in de IT-markt doorgaans zonder discussie als een resultaatsverbintenis gekwalificeerd. Dezelfde prestatie kan echter net zo goed als inspanningsverbintenis worden aangemerkt, gericht op het realiseren van een zekere kostenbesparing. Dat daarvoor een applicatie wordt gebruikt die een zekere beschikbaarheid zal moeten hebben, is dan onderliggend. Kortom, het is niet altijd zonder meer te zeggen of een bepaalde prestatie een inspanning- of een resultaatsverbintenis is. Praten in temen van deugdelijkheids- en zekerheidsgaranties biedt dan vaak uitkomst.

SCHERP FORMULEREN VAN DE DIENSTVERLENING Een goed startpunt om op zinvolle wijze over garanties te praten is het glashelder formuleren van de dienstverlening. Belangrijk om hierbij vast te stellen is welke verantwoordelijkheid u aan de leverancier wenst over te dragen. Wij nemen als voorbeeld werkplekbeheer. U kunt een leverancier opdracht geven om werkplekken (hardware met bijbehorende licenties) te leveren en te installeren, en vervolgens gebruikersondersteuning te bieden en incidenten op uw werkplekken in behandeling te nemen. In dit geval zult u eisen stellen aan de te leveren werkplekken (processor, schijfruimte, geheugen, et cetera), aan de installatie (bijvoorbeeld de snelheid van de uitrol) en aan de ondersteuning (bijvoorbeeld hoe snel de telefoon wordt opgenomen en hoeveel procent van de gemelde incidenten direct telefonisch wordt opgelost). Op gedetailleerd niveau beschrijft u dan wat uw leverancier moet doen in het kader van werkplekbeheer. U houdt zelf de regie in handen, maar neemt daarmee ook een stevige verantwoordelijkheid op u. Immers, als de door u aan de leverancier opgedragen activiteiten niet leiden tot een voldoende performance op de werkplekken maar de leverancier wel keurig uw instructies heeft opgevolgd, valt uzelf misschien meer te verwijten dan uw leverancier. IT Beheer Jaarboek 2004/2005

Een goed alternatief kan dan zijn om op een hoger serviceniveau afspraken te maken. U komt bijvoorbeeld overeen dat de leverancier uw mensen in staat stelt vanaf de plek waar zij werken (op kantoor, thuis, elders) gebruik te maken van bepaalde – nader te beschrijven – functionaliteit. Vervolgens maakt u afspraken over bijvoorbeeld beschikbaarheid van die functionaliteit, de performance op de werkplek, et cetera. U hoeft zich nu in beginsel niet meer druk te maken over de specificaties van de apparatuur en de wijze waarop de leverancier met incidenten omgaat, omdat dergelijke keuzes onderliggend zijn aan het doel dat u de leverancier heeft meegegeven. De leverancier mag (oftwel: moet) deze keuzes maken en is daar ook verantwoordelijk voor, aangezien verkeerde keuzes (bijvoorbeeld te lichte werkplekken) niet zullen leiden tot de gestelde performance-eisen. U voorkomt hiermee dat u op de (ongemakkelijke) stoel van de leverancier komt te zitten, een stoel waarop beter een ter zake kundige van de leverancier kan plaatsnemen. Het zal duidelijk zijn dat de typen garanties die u overeenkomt in de twee zojuist geschetste alternatieven totaal verschillend zijn, ook al hebben beide betrekking op dezelfde dienst – namelijk werkplekbeheer – ja zelfs op nagenoeg dezelfde operationele activiteiten! Het verschil zit ‘m in het verantwoordelijkheidsniveau van de leverancier en dit uit zich onder meer in de garantiebepalingen.

DISCREPANTIE In de praktijk gebeurt het nogal eens dat het niveau waarop dienstverlening is beschreven niet aansluit bij het type garanties dat wordt overeengekomen. Bijvoorbeeld: de opdrachtgever uit het werkplekvoorbeeld hiervoor kiest voor de tweede variant, waarin de leverancier de opdracht krijgt functionaliteit te realiseren met een zekere beschikbaarheid en performance. Desondanks stelt de opdrachtgever eisen aan de hardwarespecificatie, schrijft hij voor hoe de leverancier zijn beheer moet uitvoeren, enzovoorts. Tenzij er bijzon-

187

H04

06-10-2004

09:46

Pagina 188

Deel 4 Outsourcing

dere omstandigheden zijn die dit gedrag rechtvaardigen (bijvoorbeeld als toezichthouders van de organisatie in kwestie dergelijke eisen stellen), moet dit zoveel mogelijk voorkomen worden. Als u de leverancier dergelijke verantwoordelijkheden geeft, zal hij ook over de noodzakelijke bevoegdheden moeten beschikken om bepaalde keuzes te maken. Bovendien riskeert u, als u zelf de regie in handen houdt, in geval van problemen dat de door u gegeven instructies debet worden gemaakt aan die problemen. Een eenduidige toerekening aan de leverancier wordt dan bemoeilijkt, waardoor het ook lastiger wordt om de ontstane schade op leverancier te verhalen.

SERVICE LEVEL AGREEMENTS In een beheercontext is de SLA bij uitstek de plaats in een dienstverleningsovereenkomst om aandacht te besteden aan garanties: in de SLA worden afspraken gemaakt tussen de leverancier en de afnemer van services, over de inhoud en de kwaliteit van de te leveren service, inclusief afspraken over het managen van de service. De kwaliteitsbeschrijvingen kunnen gezien worden als deugdelijkheidsgaranties en laten zich vaak opdelen in termen van beschikbaarheid, performance, integriteit, exclusiviteit en flexibiliteit. Deze kwaliteitsindicatoren kunnen op velerlei beheerwerkzaamheden worden toegepast. Hieronder worden ter illustratie enkele voorbeelden van parameters op deze kwaliteitsindicatoren genoemd, zowel voor een ‘kerndienst’ van het beheer (bijvoorbeeld het ter beschikking stellen van functionaliteit) als de ondersteuning daaromheen (bijvoorbeeld de helpdesk). • Beschikbaarheid • service: in uren, aantal storingen, maximale duur van een storing • ondersteuning: service window helpdesk • Performance • service: snelheid transactieverwerking, aantal gelijktijdige of totale gebruikers,

188

aantal transacties per tijdseenheid, omvang opslag • ondersteuning: snelheid beantwoording, aantal vragen • Integriteit • service: volledigheid, actualiteit en juistheid van resultaten • ondersteuning: juiste beantwoording vragen, juistheid informatie, volledigheid informatie • Exclusiviteit • service: toegang tot vertrouwelijke informatie en functionaliteit • ondersteuning: aan wie mag welke informatie worden verstrekt? • Flexibiliteit • service: maximale vermeerdering van het aantal onder de service te brengen werkplekken met behoud van overige garanties • ondersteuning: aantal ‘non-standard’ applicaties dat onder beheer mag worden gebracht Per beheersituatie moet worden vastgesteld welke kwaliteitsindicatoren het meest relevant zijn. Zo zou bijvoorbeeld bij een bancaire applicatie die betalingsverkeer ondersteunt de exclusiviteit en de integriteit van de verwerking belangrijker kunnen zijn dan bijvoorbeeld de beschikbaarheid; liever vijf minuten later geld overmaken dan dat het geld op een verkeerde bankrekening terechtkomt. Daarentegen is op een order-entry-afdeling performance uiterst belangrijk: elke systeemvertraging betekent onbenutte capaciteit van de medewerkers achter het beeldscherm. En voor publieke hulpdiensten zal beschikbaarheid van een applicatie cruciaal zijn; in een 112-situatie mag er geen vijf minuten vertraging optreden doordat er even geen informatie beschikbaar is over de locatie waar de brand woedt. Vaak wordt te snel gegrepen naar beschikbaarheid als kwaliteitscriterium terwijl andere criteria veel relevanter kunnen zijn. Het uitvoeren van een risicoanalyse is een geschikt instrument om vast te stellen wat voor soort garanties met name van belang zijn in een bepaalde context. IT Beheer Jaarboek 2004/2005

H04

06-10-2004

09:46

Pagina 189

4.5 Garantie op beheer

ANDERE BEHEERGARANTIES IN DE ICT Naast de deugdelijkheidsgaranties kunnen in een beheerovereenkomst nog talloze zekerheidsgaranties worden opgenomen. Enkele voorbeelden ter concretisering: • Geschiktheid voor het doel: hoe deugdelijk een leverancier zijn werk ook uitvoert, uiteindelijk gaat het erom dat hetgeen hij bewerkstelligt bijdraagt aan het doel dat zijn opdrachtgever voor ogen had bij de opdrachtverlening. Staat de leverancier hiervoor in? • Innovatiegarantie: garandeert de leverancier continu op zoek te zullen blijven naar mogelijkheden om zijn dienstverlening nog slimmer/efficiënter uit te voeren en deze mogelijkheden ten gunste van de opdrachtgever te implementeren? • Marktconformiteitsgarantie: zal de leverancier zijn prijzen en tarieven marktconform houden, ook als de markttendens een sterk neergaande lijn vertoont? • Continuïteitsgarantie: staat de leverancier ervoor in de afgenomen dienst de komende zeven jaar nog te blijven leveren, indien opdrachtgever dat wenst? • Privacy-clausule: verklaart de leverancier op correcte wijze om te zullen gaan met persoonsgegevens waartoe hij uit hoofde van zijn werkzaamheden toegang krijgt? Zal de leverancier die het werkplekbeheer voor zijn rekening neemt zijn medewerking verlenen aan verzoeken van een opdrachtgever die zijn medewerkers wil con-

troleren op privé-gebruik van e-mail- en internetvoorzieningen? Onder welke omstandigheden wel en onder welke niet? • 403-verklaring2: staat de moederorganisatie van de leverancier garant voor verplichtingen van de dochter? • Outsourcingsbeding: verklaring dat de leverancier in staat en bereid is zijn diensten op enig moment onverminderd in opdracht van een derde partij te verrichten in plaats van in opdracht van opdrachtgever, als de opdrachtgever het domein waarbinnen de leverancier zijn beheerwerkzaamheden verricht, uitbesteedt aan een daarin gespecialiseerde derde.

ONDERHANDELING OVER GARANTIES Uitgebreid onderhandelen over garantiebepalingen wordt door leveranciers nog wel eens zo opgevat dat de opdrachtgever hem niet vertrouwt. Wij betogen echter dat het goed expliciteren van wederzijdse verwachtingen tijdens de contractering, in termen van garantie – beperkend dan wel verruimend – de uitvoering van de overeenkomst ten goede komt. Het draagt juist bij aan het onderlinge vertrouwen tussen partijen en voorkomt uiteindelijk geschillen in een later stadium. Dooddoeners als ‘we vertrouwen elkaar toch, dus hier hoeven we toch allemaal geen afspraken over te maken’ zijn in veel gevallen vast goed bedoeld, maar dragen niet bij aan het succes van de samenwerking.

Context garantiebepalingen De garantiebepaling moet altijd in zijn context worden gelezen. Zoals voor de meeste contractbepalingen geldt, dient ervoor gewaakt te worden dat de garantiebepaling niet te veel als geïsoleerd onderwerp wordt gezien. Zij hangt bijvoorbeeld nauw samen met de exoneratieclausule (aansprakelijkheidsbeperkingen) en de overmachtsbepaling. Een garantiebepaling verliest haar effectiviteit als in de exoneratieclausule de negatieve consequenties voor de leverancier, op het moment dat hij een garantie niet waarmaakt, op alle mogelijke manieren tot een minimum beperkt zijn. Garantiebepalingen boeten ook aan kracht in als de leverancier een uiterst ruime definitie van overmacht hanteert. Kortom, alleen de resultante van al deze bepalingen geeft een goed beeld van de zekerheden die de leverancier de opdrachtgever biedt.

IT Beheer Jaarboek 2004/2005

189

H04

06-10-2004

09:46

Pagina 190

Deel 4 Outsourcing

190

PARTNERSHIPS?

LITERATUUR

Een andere klassieker aan de onderhandelingstafel is: ‘we gaan een partnership aan – een partnershipcontract – dus we hoeven contractueel niet zoveel vast te leggen’. Het gros van de contracten waarop ‘partnership agreement’ of iets van die strekking staat, behelst in juridische zin echter gewoon een traditionele klant-leverancierrelatie: de een levert en de ander betaalt. Over een partnership in juridische zin spreken we liever pas als partijen daadwerkelijk gaan delen in elkaars winst en verlies, bijvoorbeeld in een joint venture. Als dat niet aan de orde is, zullen partijen gewoon om de tafel moeten en heldere afspraken moeten maken over de verwachting die de afnemende partij mag hebben van de leverende partij.

[Dunné 2001] Dunné, J.M. van, Verbintenissenrecht deel 1: contractenrecht, Kluwer, 2001

WEBSITES www.mitopics.nl www.fenit.nl

NOTEN 1 Aanbieders van IT-beheerdiensten kunnen ook hun voordeel doen met de in dit artikel aangereikte suggesties, zij het dat hun belang op onderdelen andere keuzes en prioriteiten in een SLA rechtvaardigt. 2 De term 403-verklaring verwijst naar artikel 403 van boek 2 van ons Burgerlijk Wetboek, waarin gerefereerd wordt aan de situatie dat een moedervennootschap schriftelijk heeft verklaard zich hoofdelijk aansprakelijk te stellen voor de schulden die voortvloeien uit door haar dochtervennootschap verrichte rechtshandelingen.

IT Beheer Jaarboek 2004/2005