Auteur. Onderwerp. Datum

Auteur Bart Lieben

Onderwerp Juridische aandachtspunten bij outsourcing van IT-activiteiten

Datum Mei 2001

Copyright and disclaimer Gelieve er nota van te nemen dat de inhoud van dit document onderworpen kan zijn aan rechten van intellectuele eigendom, die toebehoren aan bepaalde betrokkenen, en dat er u geen recht wordt verleend op die desbetreffende rechten. M&D Seminars wil u met dit document de nodige informatie verstrekken, zonder dat de in dit document vervatte informatie bedoeld kan worden als een advies. Bijgevolg geeft M& D Seminars geen garanties dat de informatie die dit document bevat, foutloos is, zodat u dit document en de inhoud ervan op eigen risico gebruikt. M&D Seminars, noch enige van haar directieleden, aandeelhouders of bedienden zijn aansprakelijk voor bijzondere, indirecte, bijkomstige, afgeleide of bestraffende schade, noch voor enig ander nadeel van welke aard ook betreffende het gebruik van dit document en van haar inhoud.

© M&D Seminars - 1 september 2001

M&D CONSULT BVBA HUBERT-FRERE-ORBANLAAN 47 – 9000 GENT TEL 09/224 31 46 – FAX 09/225 32 17 – E-mail: [email protected] – www.mdseminars.be

INHOUDSTABEL JURIDISCHE AANDACHTSPUNTEN BIJ DE UITBESTEDING VAN IT ........................................... 2 I.

INLEIDING ............................................................................................................................................. 2 Wat wordt verstaan onder IT outsourcing?.................................................................................. 2 Organisatie................................................................................................................................... 4 Evoluties ....................................................................................................................................... 5 II. OVEREENKOMST TUSSEN DE UITBESTEDER EN DE LEVERANCIER .......................................................... 6 1. Totstandkoming van de overeenkomst .............................................................................................. 6 1. 2. 3.

A. B.

2.

Informatieplicht en précontractuele aansprakelijkheid.................................................................................. 6 Letters of intent, beginselakkoorden en voorovereenkomsten ...................................................................... 8 (i) letter of intent....................................................................................................................................... 8 (ii) beginselakkoord ................................................................................................................................... 9 (iii) voorovereenkomst .............................................................................................................................. 10

Overeenkomst tussen leverancier en uitbesteder............................................................................ 10 A. B. C.

Contractuele behandeling van de précontractuele fase................................................................................ 10 Voorwerp van de overeenkomst.................................................................................................................. 11 Resultaats- of inspanningsverbintenis – kwaliteitseisen en service levels .................................................. 11 (i) Principe en voorwerp van de verbintenis ........................................................................................... 11 (ii) Resultaats- of inspanningsverbintenis ................................................................................................ 12 (iii) Contractuele aansprakelijkheid – gemeenrechtelijke principes .......................................................... 12 (iv) Contractueel mechanisme .................................................................................................................. 14 D. Criteria ........................................................................................................................................................ 14 (i) Performantie (performance) ............................................................................................................... 15 (ii) Betrouwbaarheid van het systeem (reliability) ................................................................................... 15 F. Sanctiemechanisme..................................................................................................................................... 18 G. “Best practices” voor de ASP-industrie ...................................................................................................... 18 (i) infrastructure planning en management ............................................................................................. 18 (ii) connectivity planning en management ............................................................................................... 19 (iii) security planning en management ...................................................................................................... 20 (iv) application management..................................................................................................................... 22 (v) implementation planning en management.......................................................................................... 24 (vi) Support planning en management ...................................................................................................... 25 H. Service Level Management en Reporting ................................................................................................... 26

III.

CONCLUSIE...................................................................................................................................... 28

JURIDISCHE AANDACHTSPUNTEN BIJ DE UITBESTEDING VAN IT1

I.

Inleiding

De toenemende complexiteit van de hedendaagse informatietechnologie en de dikwijls hoge investeringskosten die hiermee gepaard gaan, tezamen met een toenemend vraag naar continuïteit en kwaliteit in de dienstverlening hebben als gevolg dat een verhoogd aantal ondernemingen, overheden en organisaties meer en meer componenten van hun automatiserings- en informatiseringsproject gaan uitbesteden aan gespecialiseerde ondernemingen. Kenmerkend in dit verband is de toenemende vraag van de markt naar, zowel op technologisch als – zoals zal blijken – juridisch vlak ingewikkelde totaaloplossingen, waardoor een structurele en geïntegreerde samenwerking tussen verschillende ondernemingen aan de aanbodzijde eerder een noodzaak dan een opportuniteit geworden is. Het is dan ook niet verwonderlijk dat het juridisch documenteren van de verschillende rechten en verplichtingen die worden toegeschreven aan de respectieve contractspartijen allerminst een sinecure kan worden genoemd. Gezien het feit dat verschillende van deze automatiserings- en informatiseringsprocessen dikwijls dermate cruciaal worden geacht voor het (goed) functioneren van een onderneming, is het zelfs onontbeerlijk voor alle betrokken partijen om aan de verschillende processen en aspecten van de operationele relaties een adequaat juridisch draagvlak te bieden. Bij gebrek aan een specifiek juridisch kader in dit verband, is het aan de partijen om in een duidelijke omkadering en contractuele grondslag van hun samenwerking te voorzien. Ons inziens kan het schetsen van het juridisch kader niet los worden gezien van de hedendaagse realiteit waarmee de verschillende partijen, zowel langs de vraag- als de aanbodzijde worden geconfronteerd. Alvorens dieper in te gaan op de juridische aandachtspunten, wordt dit kader kort toegelicht, waarbij duidelijk zal worden dat het voorwerp van de studie bijzonder complex genoemd kan worden en bijgevolg een veelvoud van vragen opwerpt. 1.

Wat wordt verstaan onder IT outsourcing?

IT outsourcing in de meest ruime zin van het woord behelst de uitbesteding door een onderneming van een gedeelte of het geheel van haar automatiserings- en informatiseringsproject aan één of meerdere gespecialiseerde ondernemingen. In het verleden had outsourcing van IT voornamelijk betrekking op IT management; vandaag de dag is IT outsourcing meer en meer geëvolueerd naar een contractueel model voor het verwerven van nieuwe diensten, zoals front-end consulting, ontwerp van oplossingen, 1

Bart Lieben is advocaat bij Bogaert & Vandemeulebroeke, dat lid is van Landwell, een internationaal netwerk van advocatenkantoren en is als wetenschappelijk medewerker verbonden aan het Departement Rechten van de Universiteit van Antwerpen (U.I.A.). Standpunten die in onderhavig document naar voren worden geschoven zijn evenwel louter persoonlijk. 2

application development en management, in de meeste gevallen neergeschreven in een lange-termijnovereenkomst met de klant2. Daarenboven vormt de toenemende convergentie van IT en ondernemingsstrategieën een belangrijke bepalende factor voor het aannemen van een ondernemingsgerichte houding ten opzichte van IT en, bijgevolg, van outsourcingprocessen. IT outsourcing heeft bijgevolg, sinds het gebruik van informatie- en communicatietechnologie in het algemeen en het internet in het bijzonder doorheen de industrie een haast onmisbare plaats heeft opgeëist in verschillende bedrijfsprocessen, een evolutie ondergaan van een louter technische oplossing die door ondernemingen werd aangewend voor het beheren en optimaliseren van IT-activa en –infrastructuur, naar een verhoogde integratie in de dagdagelijkse bedrijfsprocessen binnen verschillende organisaties. In sommige van deze ondernemingen worden overigens aldus niet alleen bepaalde bedrijfsprocessen uitbesteed, zelfs – en dan denken we voornamelijk aan de zogenaamde dot.com’s – het operationeel beheer van de onderneming wordt op deze manier dikwijls overgelaten aan gespecialiseerde bedrijven die zorg kunnen dragen voor geïntegreerde (totaal)oplossingen op dit vlak3. Dergelijke verhoogde vraag, alsmede de toenemende technische complexiteit, heeft ontegensprekelijk tot gevolg dat de meeste ondernemingen die actief zijn op het gebied van IT outsourcing hun eigen strategieën zullen moeten herzien. Vermits hierbij, en dit is voornamelijk het geval voor de gevestigde waarden in deze industrie, nooit over één nacht ijs wordt gegaan, profiteren nieuwe bedrijven van deze koersverandering door nieuwe, additionele en inventieve diensten op dit terrein aan te bieden. IT outsourcing kan bijgevolg vandaag de dag moeilijk onder één enkele noemer worden geplaatst. Gartner Group, Inc. onderscheidt volgende types:

Bron : Gartner Dataquest, december 2000

2

BROWN, R.A. en YOUNG, A., “Scenarios for the Future of Outsourcing”, 12 december 2000, Gartner Group, Inc. (www.gartner.com). 3 idem. 3

De kwadranten “management” en “optimization” hebben voornamelijk betrekking op de meer gebruikelijke dienstverlening waarbij een oplossing geboden wordt voor de meer traditionele vragen; de kwadranten “access” en “creation” hebben dan weer meer betrekking op nieuwe, op het internet gerichte diensten die minder matuur zijn, maar niettemin essentieel zijn voor ondernemingen die zich hoe langer hoe meer gaan concentreren op hun e-business-activiteiten. “Management” en “access” leveren de infrastructuur die erop gericht is de waarde van de diensten die zich binnen de kwadranten “optimization” en “creation” naar een hoger niveau te tillen. 2.

Organisatie

De toenemende vraag naar almaar complexere oplossingen, nopen hooggespecialiseerde ondernemingen aan de aanbodzijde ertoe met elkaar unieke relaties, en bijgevolg specifieke engagementstructuren op te zetten voor de verschillende types van dienstverlening die zij bieden. Volgende structuren worden hierbij onderscheiden :

Bron : Gartner Dataquest, december 2000

In een “management”-strategie worden er voornamelijk, one-to-one, klant-specifieke engagementen gesloten, waarbij een prime contractor een overeenkomst afsluit met de klant, en vervolgens bepaalde aspecten van de dienstverlening naar anderen uitbesteedt. De “access”-strategie is voornamelijk gericht op het one-to-many-model, waarbij er voornamelijk gestandaardiseerde diensten worden aangeboden. In deze strategie zijn zowel prime contractors als consortia aanwezig aan de aanbodzijde. Het “optimization”-model biedt tevens een one-to-one oplossing die erg specifiek is voor de afnemer van de dienst, maar hier zal de prime contractor eerder de rol spelen van “hoofdaannemer”, die rekenschap en verantwoording dient af te leggen met betrekking tot de dienstverlening. De “creation”-strategie is de minst duidelijk gedefinieerde strategie, vermits er zowel one-to-many als many-to-many diensten worden verstrekt en er tevens verschillende organisatiemodellen aan de aanbodzijde vallen terug te vinden. Bij de opzet en het beheer van marketplaces en meta-marketplaces zijn er voornamelijk (industrie)consortia betrokken. 4

3.

Evoluties

De huidige malaise in de informatie- en telecommunicatiesector, gekarakteriseerd door hoge schuldenlasten en lage beurskoersen, noodzaakt dergelijke ondernemingen om geïntegreerd samen te werken. Een consolidatiebeweging binnen deze bedrijven is onvermijdelijk : technologiereuzen Compaq en Hewlett-Packard kondigden op 4 september 2001 een fusie tussen de twee multinationals aan, samen goed voor 87 miljard USD. Op basis van een analyse van de resultaten bij genoemde IT-giganten blijkt overigens duidelijk dat tijdens de laatste jaren het omzetaandeel van de respectieve “services”afdelingen gestaag terrein won op het aandeel gerelateerd aan de verkoop van producten (servers, PC’s, e.d.m.).

5

II.

Overeenkomst tussen de uitbesteder en de leverancier

1.

Totstandkoming van de overeenkomst

Afgezien van de vrij courante praktijk, waarbij standaardcontracten en algemene voorwaarden gehanteerd worden, worden er, gezien de dikwijls erg specifieke vraag van de uitbesteder en afhankelijk van het al dan niet bedrijfskritische karakter van de opdracht, meer en meer ad hoc-overeenkomsten gesloten tussen uitbesteder en leverancier. Alvorens over te gaan tot de realisatie van een concreet project, voeren partijen dikwijls een langdurig en moeizaam onderhandelingsproces, waarbij de verschillende partijen in het project (niet noodzakelijk aan de onderhandelingstafel) een erg cruciale rol spelen (de zogenaamde pré-contractuele fase) 4. Gezien, zoals hoger reeds vermeld, de toenemende vraag naar een “one stop shopping”-situatie, waarbij de uitbesteder enkel wenst te contracteren met een prime of een general contractor, lijkt het opportuun om de verschillende rechten en verplichtingen van alle betrokkenen in het project duidelijk op een rij te zetten, rekening houdend met de courante praktijk bij de uitbesteding van IT. A. Informatieplicht en précontractuele aansprakelijkheid Algemeen wordt aangenomen dat er zelfs in de fase voor het sluiten van de overeenkomst tussen de onderhandelingspartners een door de goede trouw beheerste vertrouwensrelatie bestaat, dewelke geconcretiseerd wordt in de verplichting om elkaar de inlichtingen te geven die van belang zijn voor de totstandkoming of voor de uitvoering van het contract 5. De juridische grondslag voor deze regel dient te worden gezocht in de leer van de précontractuele aansprakelijkheid, gebaseerd op de artikelen 1382-1383 B.W. 6 Op basis van de rechtspraak moeten onderhandelingspartners elkaar tijdens de onderhandelingen juiste informatie verschaffen; begaat een culpa in contrahendo, de onderhandelingspartij die misleidende, leugenachtige of onnauwkeurige gegevens mededeelt. Dit is onder meer het geval wanneer de leverancier bepaalde uitlatingen doet

4

SCHRANS, G., “De progressieve totstandkoming der contracten”, T.P.R., 1984, nr. 1-2, p. 1; ‘T KINT, F., “Négociation et conclusion du contrat”, in Les obligations contractuelles, Brussel, Ed. Du Jeune Barreau, 1984, (7à, p. 9, nr. 1; MARCHANDISE, P., “La libre négociation – Droits et obligations des négociateurs”, J.T., 1987p. 621, 3; VAN OEVELEN, A., “Juridische verhoudingen en aansprakelijkheid bij onderhandelingen over (commerciële) contracten”, DAOR, 1990, 14, p. 43. 5 Zie o.m. WILMS, W., “Het recht op informatie in het verbintenissenrecht. Een grondslagenonderzoek"” R.W., 1980-81, (489), kol. 499-500; SCHRANS, G., “De progressieve totstandkoming van contracten”, p. 10, nr. 7; VAN OEVELEN, A., o.c., p. 52. 6 SCHRANS, G., “Praecontractuele verhoudingen naar Belgisch recht”, in Vereniging voor de Vergelijkende Studie van het Recht van België en Nederland – Jaarboek 1967-68, Zwolle, Tjeenk Willink, 1968, 257-258; KRUITHOF, R., “Overzicht van rechtspraak 1974-1980. Verbintenissen”, T.P.R., 1983, p. 607, nr. 103; VANDENBERGHE, G., “De computer in het verbintenissenrecht”, T.P.R., p. 468-469, nr. 14; VAN OEVELEN, A., o.c., p. 52; VANDENBERGHE, G., VAN HOOF, D. en TAEYMANS, M., “Computercontracten”, OBO, december 1990, afl. 16, p. 10-11; zie evenwel, a contrario, WILMS, W., o.c., kol. 500, nr. 6 en POULLET, Y. en ULLMANN, PH., “Jurisprudence belge récente relative aux contrats informatiques”, T.B.H., 1983, p. 491, nr. 10 die de opvatting verdedigen dat de grondslag van dit principe terug moet worden gevonden in artikel 1134, derde lid B.W., krachtens hetwelk verbintenissen niet alleen te goeder trouw zouden moeten worden uitgevoerd, maar dat deze goede trouw tevens aanwezig dient te zijn bij het aangaan van de overeenkomst. 6

over de technische kwalificatie en specialisatie van één of meerdere van zijn onderaannemers. In de tweede plaats wordt gesteld dat de informatieverplichting zich uitstrekt tot alle bestanddelen van de overeenkomst waarvan de informatieverstrekker wist of behoorde te weten dat ze voor de medecontractant een substantieel karakter hebben. In vele gevallen, waarop later uitvoerig wordt teruggekomen, stelt dit in de praktijk een probleem wanneer gesproken wordt over de veiligheid van de omgeving, het platform en de configuratie van software (firewalls) die ervoor moet zorgen dat ongeautoriseerd gebruik van bijvoorbeeld de applicaties en de gegevens die in een data center worden bewaard onmogelijk of bemoeilijkt wordt. Zo ook bij het gebruik van cryptografie bij bepaalde applicaties, zoals e-mail. In dergelijk geval kunnen sommige leveranciers terughoudend reageren wanneer hen gevraagd wordt om meer informatie te verstrekken met betrekking tot deze omgeving, vermits dit gevolgen kan hebben met betrekking tot de veiligheid van de totale omgeving. In sommige gevallen kan het zelfs raadzaam zijn om in bepaalde gevallen in een beginselakkoord of voorovereenkomst tussen partijen te voorzien in een exoneratieregeling met betrekking tot het verstrekken van onjuiste, onvolledige of onnauwkeurige informatie. Dergelijke regeling wordt geldig geacht voor zover zij (a) geen exoneratie bevat voor de persoonlijke opzettelijke fout van de schuldenaar; (b) niet iedere zin of betekenis ontnemen aan de aard van het contract dat de partijen beoogden tot stand te komen, en; (c) zij geen inbreuk plegen op bijzondere wetsbepalingen. Dergelijk exoneratiebeding is voor de partijen evenwel slechts verbindend indien ze daarmee, uitdrukkelijk of stilzwijgend, hun instemming hebben bevestigd 7. Wanneer een leverancier geconfronteerd wordt met een klant die niet vertrouwd is met informatietechnologie in het algemeen en/of met nieuwe ontwikkelingen op dit vlak in het bijzonder, geldt in de onderhandelingsfase een verhoogde informatieverplichting van de kant van de leverancier. Soms wordt deze informatieplicht tevens afgeleid uit de theorie van de verscherpte informatieplicht inzake gevaarlijke activiteiten, waartoe informatica zou behoren 8. Of dit daadwerkelijk het geval is, blijft evenwel nog steeds een feitenkwestie. De leverancier heeft evenwel niet alleen de verplichting om informatie te verstrekken; hij dient zich net zo goed te informeren bij de klant met betrekking tot de behoeften van deze laatste. Zoals terecht opgemerkt in de rechtsleer, kan het niet voldoen aan genoemde verplichting tot gevolg hebben dat er achteraf aan “overselling” of “underselling” wordt gedaan 9. Om dergelijk risico te vermijden, zullen er aan de onderhandelingsfase dikwijls een aantal activiteiten vooraf gaan waarbij in sommige gevallen zelfs de medewerking van hetzij een derde-expert, de toekomstige leverancier of de verschillende mogelijke leveranciers wordt gevraagd. Worden onderscheiden : 1. het opstellen van een behoeften-analyse op basis van een technische due diligence; 2. het uitvoeren van een opportuniteitsstudie naar de uitvoerbaarheid, de wenselijkheid en de rentabiliteit van de geplande uitbesteding; 7

VAN OEVELEN, A., o.c., p. 54-55. VANDENBERGHE, G., VAN HOOF, D. en TAEYMANS, M., o.c., p. 11 en de verwijzingen aldaar. 9 VANDENBERGHE, G., VAN HOOF, D. en TAEYMANS, M., o.c., p. 12 en de verwijzingen aldaar. 8

7

3. het opstellen van een functionele en technische analyse van het op te zetten systeem; 4. het opstellen van een lastenkohier dat een beschrijving van de organisatie en de concreet uit te besteden activiteiten bevat; 5. de offerte-aanvraag, [waarbij het lastenkohier aan (geselecteerde) leveranciers wordt toegestuurd]; 6. [het vergelijkend onderzoek van de aanbiedingen]; en 7. de onderhandelingen tot het sluiten van de finale overeenkomst met een leverancier 10. Het opstellen van het lastenkohier is in hogergenoemde opeenvolging van activiteiten allicht één van de belangrijkste, zoniet de belangrijkste taak. Hoewel ze niet kan worden afgedaan als een algemene verplichting die wordt opgelegd aan de uitbesteder, toch wijst de praktijk uit dat dergelijk lastenkohier meestal wordt opgesteld, al dan niet met medewerking van de leverancier, hetgeen belangrijke gevolgen met zich kan meebrengen. Indien er namelijk bij één of meerdere bovengenoemde activiteiten reeds één of meerdere (potentiële) leverancier(s) betrokken zijn, kunnen er desgevallend belangrijke juridische gevolgen worden gehecht aan hun aanwezigheid, medewerking en verklaringen. Zo kunnen onder meer de (behoeften-)analyses, studies en lastenkohier met behulp van of door een potentiële leverancier dermate worden gesteld of zelfs gemanipuleerd dat de keuzemogelijkheid van de uitbesteder beperkt ofwel helemaal uitgesloten wordt. Afhankelijk van de concrete omstandigheden, zal dergelijke handelswijze dienen te worden beoordeeld in het licht van hetzij de contractuele, hetzij de buitencontractuele aansprakelijkheid in hoofde van dergelijke leverancier. B. Letters of intent, beginselakkoorden en voorovereenkomsten Naarmate onderhandelingen met het oog op het sluiten van een contract worden aangevat of worden voortgezet, kan het gebeuren dat partijen het gebied van de vrijblijvende voorstellen en tegenvoorstellen als het ware “geruisloos” verlaten om een (zekere) contractuele binding tot stand te brengen, zonder dat zij dit noodzakelijk bedoelen of bedoeld hebben 11. Gezien de courante praktijk waarin toekomstige contractspartijen reeds in het begin van de précontractuele fase met elkaar samenwerken, o.m. bij het opstellen van de behoeften-analyse of het lastenkohier, maken zij dikwijls een onontbeerlijk instrument uit. Voor afspraken en documenten die door partijen in de précontractuele fase worden gehanteerd, worden dikwijls uiteenlopende benamingen gebruikt. Hieronder belichten we er een drietal, namelijk (1) de letter of intent, (2) het beginselakkoord, en (3) de voorovereenkomst. (i)

letter of intent

Een letter of intent of “intentieverklaring” kan worden omschreven als een één- of tweezijdig, veelal in briefvorm opgesteld document, dat ter voorbereiding van de 10

Zie ook VANDENBERGHE, G., VAN HOOF, D. en TAEYMANS, M., o.c., p. 8. VAN OEVELEN, A., o.c., p. 56; het begrip “geruisloos tot stand komen van contracten” werd geïntroduceerd in SCHRANS, G., “De progressieve totstandkoming van contracten”, T.P.R., 1984. 11

8

totstandkoming van een definitieve overeenkomst, het voorlopig resultaat van de onderhandelingen weergeeft in het stadium waarin deze zich op dat ogenblik bevinden. Veelal wordt ook gebruik gemaakt van een letter of intent om onderhandelingen en activiteiten die worden uitgevoerd tijdens de onderhandelingsfase enige contractuele grondslag te bieden. De juridische betekenis van dergelijke intentieverklaringen hangt af van de bedoeling van de partijen, de gebruikte bewoordingen en de concrete omstandigheden. Naargelang hun inhoud kunnen deze documenten dan ook variëren van vrijblijvende, onverbindende intentieverklaringen tot verbindende afspraken, met in het uiterste geval zelfs een volledige overeenkomst 12. (ii)

beginselakkoord

Een beginselakkoord kan worden omschreven als een overeenkomst waarbij de partijen vaststellen over welke elementen er reeds wilsovereenstemming bestaat, en waarbij ze zich ertoe verbinden de onderhandelingen voort te zetten over de modaliteiten die nog nader moeten worden uitgewerkt. De definitieve overeenkomst zal evenwel pas tot stand komen wanneer tussen de partijen ook wilsovereenstemming is bereikt over de bestanddelen waarover na het beginselakkoord nog moet worden onderhandeld. Een variant op dit thema betreft de dikwijls gehanteerde praktijk waarbij de uitbesteder reeds enkele belangrijke modaliteiten van de definitieve overeenkomst unilateraal op voorhand vastlegt, deze rondstuurt aan verschillende leveranciers met de duidelijke vermelding dat de onderhandelingen enkel worden aangevat of voortgezet rekening houdend met deze modaliteiten. In dergelijk geval kan er enkel van een beginselovereenkomst sprake zijn wanneer de kandidaat-leverancier zich met deze modaliteiten akkoord verklaart. Modaliteiten die in dergelijke beginselovereenkomst in concreto naar voren worden geschoven zijn o.m. de behandeling van bestaande en toekomstige intellectuele eigendomsrechten, source code escrow, garanties met betrekking tot bepaalde aspecten van de dienstverlening (service levels), timing (milestone-planning), aansprakelijkheid, enz. In ieder geval is het een courante praktijk om in een beginselovereenkomst een duidelijke regeling op te nemen met betrekking tot de door voorinformatie of tijdens onderhandelingen verkregen know-how en bedrijfsgeheimen die werden uitgewisseld. Dergelijke regeling dient niet enkel het eventuele verspreiden aan het publiek door de verkrijger van dergelijke know-how en bedrijfsgeheimen te sanctioneren; tevens dient te worden voorzien in een regeling met betrekking tot het eigen, bedrijfsintern gebruik van dergelijke informatie door de verkrijger ervan. In beide gevallen kan zodanig gebruik of misbruik worden beschouwd als een onrechtmatige daad en, meer bepaald, als een gedraging in strijd met de in het handelsverkeer gebruikelijke zorgvuldigheid, die kan worden gesanctioneerd op grond van de artikelen 1382-1383 B.W. in de mate waarin daaruit schade is voortgevloeid voor de “eigenaar” of “houder” van deze informatie. Bovendien kan deze gedraging worden bestempeld als een daad die strijdig is met de eerlijke handelsgebruiken, zodat op grond 12

VAN OEVELEN, A., o.c., p. 48 en de verwijzingen aldaar. 9

van artikel 95 van de Wet betreffende de handelspraktijken en de voorlichting en bescherming van de consument de stopzetting ervan kan worden gevorderd bij de voorzitter van de rechtbank van koophandel 13. (iii)

voorovereenkomst

Ook een voorovereenkomst kan verschillende gezichten vertonen; worden onderscheiden : de wederkerige contractbelofte, de eenzijdige contractbelofte of het optiecontract, en het voorkeurscontract. Een voorovereenkomst sensu stricto kan worden omschreven als een rechtens verbindende overeenkomst waarbij één of beide partijen zich ertoe verbinden om op een later tijdstip een andere (hoofd)overeenkomst aan te gaan waarvan de hoofdbestanddelen reeds zijn vastgelegd of toch voldoende bepaalbaar zijn 14. Een voorovereenkomst in de strikte zin van het woord wordt ook wel contractbelofte genoemd. In complexe uitbestedingsrelaties tussen een general contractor en een uitbesteder wordt wel eens gebruik gemaakt van voorovereenkomsten onder de opschortende voorwaarde dat de verschillende onderaannemers, die tijdens het onderhandelingsproces door de general contractor of door beide onderhandelingspartijen werden geselecteerd en al dan niet werden betrokken bij de onderhandelingen, een overeenkomst sluiten met de general contractor. Afhankelijk van het tijdstip, de concrete situatie en het al dan niet aanwezig zijn van een (geschreven) akkoord tussen partijen en de inhoud ervan, kan het afbreken van onderhandelingen een contractuele of een buitencontractuele fout uitmaken, waardoor de andere partij gerechtigd is op hetzij een vergoeding voor de opgelopen schade, hetzij een eventuele forfaitaire vergoeding die tussen de onderhandelingspartners werd overeengekomen. 2.

Overeenkomst tussen leverancier en uitbesteder

A. Contractuele behandeling van de précontractuele fase In de definitieve overeenkomst tussen de uitbesteder en de leverancier worden dikwijls bepalingen opgenomen die de activiteiten en de eventueel door partijen ondertekende documenten uit de précontractuele fase regelen. Afhankelijk van de waarde die de partijen aan deze fase hechten, zullen bepaalde documenten (o.m. lastenkohier, voorstel van de leverancier) deel uitmaken van de definitieve overeenkomst, andere (o.m. notulen van vergaderingen en technische specificaties van soft- en hardware) worden uit het finale contract worden geweerd. Om iedere discussie achteraf uit te sluiten, kan er gebruik gemaakt worden van het zogenaamde vierhoekenbeding, waarbij het voorwerp van het definitieve contract wordt beperkt tot de contractuele bepalingen, en alle andere afspraken uit te sluiten. Ook een 13

Zie o.m. SCHRANS, G., “Praecontractuele verhoudingen naar Belgisch recht”, p. 251-252; SCHRANS, G., “De progressieve totstandkoming van contracten”, p. 15-16, nr. 9. 14 VAN OEVELEN, A., o.c., p. 60 en de verwijzingen aldaar. 10

beding van adequate voorlichting kan de aansprakelijkheid van de leverancier voor de door hem in de précontractuele fase gemaakte fouten beperken, voor zover rekening gehouden wordt met de wettelijke beperkingen ter zake 15. Het is ontegensprekelijk in het voordeel van de uitbesteder om dergelijke clausules, of op zijn minst de impact ervan, zoveel als mogelijk te vermijden. Een beding waarin onder meer gesteld wordt dat de uitbesteder bij de ondertekening van de definitieve overeenkomst uitgaat van de assumptie dat de verklaringen van de leverancier, de tussen partijen uitgewisselde documenten en de door de leverancier verstrekte technische specificaties correct waren, biedt een stok achter de deur voor wat betreft de (eventuele) précontractuele aansprakelijkheid van de leverancier. B. Voorwerp van de overeenkomst Het correct definiëren van het voorwerp van de overeenkomst is, voornamelijk in complexe outsourcingcontracten, geen sinecure. Worden onder meer onderscheiden : 1. 2. 3. 4. 5. 6. 7. 8. 9.

softwarecontracten (ontwikkeling, licenties, application service provision); hardwarecontracten (huur, lease, …); hosting-overeenkomsten onderhoud en support source code escrow consultancy helpdesk connectiviteit …

C. Resultaats- of inspanningsverbintenis – kwaliteitseisen en service levels (i)

Principe en voorwerp van de verbintenis

Indien een onderneming beslist om (een gedeelte van) haar IT-infrastructuur en/of – dienstverlening uit te besteden aan één of meerdere derden, zullen allicht duidelijke eisen worden gesteld met betrekking tot de kwaliteit van de aangeboden diensten en/of afzonderlijke verplichtingen van de dienstverlener. De contractuele vertaling van deze kwaliteitseisen wordt veelal bestempeld met de term “service level agreement” of, afgekort, “SLA”. Afhankelijk van het voorwerp van de overeenkomst, wordt in dergelijke service level agreements enerzijds de verschillende diensten en/of verplichtingen gedefinieerd en geïsoleerd en, anderzijds, bepaalde kwaliteitsparameters of –niveaus vastgelegd met betrekking tot iedere respectieve dienst en/of verplichting die werd geïdentificeerd. Afhankelijk van de concrete invulling die de partijen aan de specifieke, geïdentificeerde en geïndividualiseerde verbintenissen geven, komt het contractueel vastleggen van deze zogenaamde “service levels” neer op het aangaan in hoofde van de leverancier van hetzij een resultaatsverbintenis met bepaalde modaliteiten, hetzij een inspanningsverbintenis. 15

Zie hoger, p. [XXX]. 11

(ii)

Resultaats- of inspanningsverbintenis

Verbintenisrechtelijk houdt een resultaatsverbintenis in dat de schuldenaar van een dergelijke verbintenis zich ertoe verplicht een welbepaald resultaat te bereiken. Een inspanningsverbintenis daarentegen legt aan de schuldenaar enkel de verplichting op een bepaalde inspanning te leveren of bepaalde middelen aan te wenden om een resultaat te bereiken, maar de debiteur belooft niet dat hij erin zal slagen dat resultaat ook te verwezenlijken. De draagwijdte van het genoemde onderscheid is om drie redenen van belang. Op de eerste plaats biedt het de mogelijkheid om de inhoud en de draagwijdte van de door de schuldenaar aangegane verbintenis nader te bepalen, hetgeen van wezenlijke betekenis is om uit te maken of deze debiteur zijn verbintenis al dan niet is nagekomen. Op de tweede plaats is het onderscheid van belang inzake de bewijslastverdeling : indien de debiteur een resultaatsverbintenis is aangegaan, zal de schuldeiser bij wanuitvoering het bewijs moeten leveren van (i) het bestaan van de verbintenis en (ii) het uitblijven van het beloofde resultaat; op de debiteur rust dan de plicht het bewijs te leveren van overmacht of toeval 16. In het geval de debiteur een inspanningsverbintenis dient te leveren, dan rust de bewijslast nagenoeg volledig op de schuldeiser, die zowel (i) het bestaan van de verbintenis als (ii) de wanuitvoering door een gebrek aan zorg in hoofde van de schuldenaar dient te bewijzen 17. Het onderscheid is in de derde plaats belangrijk op het vlak van de overmachtsleer. Alleen voor de resultaatsverbintenissen dienen de strenge vereisten van deze leer in acht te worden genomen; voor inspanningsverbintenissen geldt enkel het zorgvuldigheidscriterium van de goede schuldenaar. Gezien de belangrijke gevolgen van het onderscheid tussen resultaats- en inspanningsverbintenis, dienen partijen bij het vastleggen van hogergenoemde parameters, het bepalen van de aard van de verbintenis alsmede bij het documenteren van hun respectieve rechten en verplichtingen in geval van niet-nakoming door de schuldenaar uiterst nauwgezet tewerk te gaan. (iii)

Contractuele aansprakelijkheid – gemeenrechtelijke principes

Zoals hierboven bepaald, is het onderscheid tussen de inspannings- en resultaatsverbintenis van belang op het vlak van de aansprakelijkheid van de schuldenaar in geval van niet-nakoming van diens verbintenissen. Met betrekking tot inspanningsverbintenissen is iedereen het er over eens dat terzake het foutcriterium geldt 18. Begaat in dit verband een fout de schuldenaar die niet de

16

Art. 1315 B.W.; Cass., 10 december 1953, Pas., 1954, I, 290; Cass., 26 november 1954, Pas., 1955, I, 271. 17 Cass, 26 februari 1962, Pas., 1962, I, 723. 18 Zie hoger, p. 10. 12

zorgvuldigheid in acht heeft genomen waaraan een goede schuldeiser van dezelfde categorie geplaatst in dezelfde externe omstandigheden zich zou gehouden hebben. Op de vraag of de schuldenaar een culpa levis in abstracto of een culpa levis in concreto moet hebben begaan om zijn eventuele fout in de niet-nakoming van zijn verbintenissen te beoordelen, heeft het Hof van Cassatie in een interessant arrest van 27 januari 1977 geoordeeld dat artikel 1137, eerste lid B.W. de algemene regel vastlegt dat de contractuele fout in abstracto moet worden beoordeeld, maar dat het tweede lid van deze wetsbepaling uitzonderingen voor bepaalde contracten mogelijk maakt 19. Voor wat resultaatsverbintenissen aangaat, wordt in België – overigens net als in Frankrijk – de leer van de ontoereikende onmogelijkheid gehanteerd 20. Volgens deze opvatting kan er slechts sprake zijn van overmacht wanneer de omstandigheid die als vreemde oorzaak ter bevrijding wordt geroepen, de nakoming van de verbintenis onmogelijk maakt en de schuldenaar ter zake geen enkele fout treft. Voor de toepassing van deze leer bestaan dus twee vereisten : (1) de onmogelijkheid om de verbintenis na te komen, en (2) de niet-toerekenbaarheid daarvan aan de schuldenaar. Voor wat de eerste vereiste betreft, de onmogelijkheid om de verbintenis na te komen, dient de overmacht een “onverkomelijk beletsel” te onderstellen 21. Maakt derhalve geen overmacht uit, de omstandigheid die de uitvoering van het contract niet volkomen onmogelijk maakt, maar slechts moeilijker of kostelijker 22. Omtrent de vraag of er sprake dient te zijn van een absolute onmogelijkheid of van een normale, menselijke of praktische onmogelijkheid, waarbij vandaag de dag quasi unaniem voor het laatste gekozen wordt. Hoe ver men hierin mag gaan, is evenwel niet duidelijk. Het tweede vereiste – de niet-toerekenbaarheid van de verhindering aan de schuldenaar – houdt in dat de schuldenaar niet bevrijd zal zijn van zijn verbintenis, zelfs indien de nakoming van de verbintenis absoluut of praktisch onmogelijk blijkt te zijn, indien de omstandigheid die de nakoming verhindert, te wijten is of gepaard gaat met een fout in zijn hoofde en zonder dewelke de uitvoering van de verbintenis geheel of gedeeltelijk toch mogelijk zou zijn geweest. Hierop steunen de regels dat de vreemde oorzaak onvoorzienbaar en onvermijdbaar moet zijn geweest en dat de schuldenaar zich niet kon beroepen op een omstandigheid die aan zijn eigen nalatigheid of onvoorzichtigheid is te wijten. Opvallend is evenwel dat in de rechtspraak en rechtsleer vaak de stelling verdedigd wordt dat de debiteur niet de minste schuld, zijnde een culpa levissima mag treffen, vermits algemeen aanvaard wordt dat de contractuele aansprakelijkheid steunt op de culpa levis in abstracto. Volgens een tweede theorie – die voornamelijk in Nederland wordt verdedigd – is de nietnakoming van de verbintenis aan overmacht te wijten, wanneer de schuldenaar ter bereiking van het door de overeenkomst beoogde resultaat alles heeft gedaan wat een 19

Cass., 27 januari 1977, Arr. Cass., 1977, 595; Pas., 1977, I, 575, met conclusie Proc. Gen. Delange; zie ook RUTSAERT, J., “La responsabilité civile contractuelle du prestataire de service en droit privé”, De Verz., 1977, 221. 20 Cass, 9 december 1976, Arr. Cass., 404. 21 Idem. 22 Cass., 23 februari 1967, Arr. Cass., 1967, 797. 13

zorgvuldig debiteur in de gegeven omstandigheden zou hebben gedaan (de zgn. “schuldleer”). Volgens deze leer steunt de contractuele aansprakelijkheid dus uitsluitend op de fout; overmacht begint bijgevolg waar schuld ophoudt. Een derde theorie, waarbij de schuldleer of de traditionele overmachtsleer wordt aangevuld met het risicobeginsel, kent evenwel een groeiend aantal aanhangers. Hierbij dient evenwel de vraag te worden gesteld welke gevallen onderworpen dienen te worden aan de risicoaansprakelijkheidsregeling. Hieromtrent bestaat er onenigheid: een eerste strekking hanteert hierbij het begrip “vreemde oorzaak”, volgens een tweede strekking dient deze kwalificatie op pragmatische wijze te geschieden. Naar Belgisch recht wordt deze theorie vrijwel unaniem verworpen, vermits, voor wat de eerste strekking betreft, de oorzaak van de verhindering aan de schuldenaar enkel “vreemd” kan zijn, wanneer deze omstandigheid op generlei wijze aan zijn fout is toe te wijzen. De strikte toepassing van de tweede strekking zou dan weer aanleiding kunnen geven tot arbitraire toestanden. (iv)

Contractueel mechanisme

In principe zal aan iedere geïdentificeerde dienst en/of verplichting een bepaald kwaliteitsniveau gealloceerd worden waaraan deze dienst en/of verplichting binnen een bepaalde periode in principe dient te voldoen (het zogenaamde target service level). Indien dit target service level door de leverancier wordt behaald, zal hij de met betrekking tot deze dienst en/of verplichting contractueel afgesproken vergoeding geheel mogen factureren aan de klant. In sommige gevallen – meestal in de gevallen waarbij de IT-oplossing voor de klant bedrijfskritisch is – kan er, voor specifieke diensten en/of verplichtingen van de leverancier – een contractueel bonificatiesysteem worden voorzien indien de graad van kwaliteit aangaande de dienstverlening en/of de door de leverancier aangegane verplichtingen uitstijgen boven het vastgelegde target service level. Indien de kwaliteit van de dienstverlening van de leverancier dit contractueel bepaalde niveau niet bereikt, zal de leverancier bepaalde kortingen toestaan aan de uitbesteder zie verder, punt 3). D. Criteria Om alle onduidelijkheid tegen te gaan, is het voor de uitbesteder van het grootste belang om zijn objectieven zo duidelijk mogelijk te definiëren en te onderscheiden, dit om het effect van de resultaatsverbintenis vanwege de leverancier te verkrijgen 23. Het is daarbij van belang om tegen de diverse meetbare criteria bepaalde parameters te plaatsen waaraan de dienstverlening in verband met het gedefinieerde criterium moeten voldoen. Algemeen worden twee belangrijke criteria aangewend : enerzijds performantie (performance), gemeten vanuit het eindgebruikersperspectief, en anderzijds betrouwbaarheid (reliability) van het systeem.

23

VANDENBERGHE, G., VAN HOOF, D. en TAEYMANS, M., o.c., p. 11 en de verwijzingen aldaar. 14

(i)

Performantie (performance)

De performantie van het systeem kan gemeten worden op basis van een aantal sub-criteria, namelijk : (a) packet loss : het internet is een zogenaamd packet switched network waarbij data wordt opgedeeld in verschillende pakketjes van dezelfde lengte, welke vervolgens over het netwerk worden verstuurd. Eén van de maatstaven betreft het aantal datapakketten die tussen bepaalde punten in het netwerk worden verstuurd en niet ontvangen werden; wanneer tussen verschillende knooppunten in het netwerk teveel datapakketten verloren gaan, dient het systeem net zolang data over het netwerk te verzenden totdat de eindgebruiker het volledige antwoord heeft ontvangen. (b) round trip delay, waarbij de tijdsduur wordt gemeten tussen het ogenblik waarop een pakket werd verzonden en ontvangen door de bestemmeling ervan, waarbij rekening wordt gehouden met opstoppingen (queing delays) aan de eindpunten; (c) throughput, waarbij zowel de hoeveelheid data als de snelheid waarop deze wordt verstuurd wordt gemeten; (d) jitter metrics, waarbij onder meer verschillen in de aankomsttijden van datapakketten en, bijgevolg, synchronisatieproblemen gemeten worden. (ii)

Betrouwbaarheid van het systeem (reliability)

Zijn in dit verband relevant : (a) beschikbaarheid (availability) De kosten die bedrijven oplopen wegens het onbeschikbaar zijn van het systeem (downtime) worden dikwijls onderschat. Een studie binnen 400 ondernemingen in de Verenigde Staten wees uit dat de kosten waarmee bedrijven worden geconfronteerd in geval van downtime oplopen tot USD 1.400 per minuut of USD 85.000 per uur. Indien een systeem op jaarbasis slechts voor 1% onbeschikbaar is, bedraagt de financiële weerslag hiervan ongeveer USD 7,5 miljoen.24 Het opleggen van een resultaatsverbintenis met betrekking tot de beschikbaarheid is in de meeste gevallen cruciaal. Om de beschikbaarheid of het operationeel zijn van, naargelang het geval, de hardware en/of de applicatie(s), hetgeen duidelijk uit het contract moet blijken. Om de beschikbaarheid hiervan te bepalen, dienen de fouten en de niet-operationaliteit ervan te worden bepaald aan de hand van verschillende formules. Indien bepaalde hardware en/of software niet beschikbaar is, dient de leverancier een interventie te doen. Hieromtrent dienen duidelijk afspraken te worden 24

STURM, R., MORRIS, W., en JANDER, M., Foundations of Service Level Management, SAMS Publishing, Indianapolis, USA, 2000, p. 127. 15

gemaakt met betrekking tot de interventietijd (termijn binnen dewelke de leverancier de interventie dient te verrichten) de wijze van interventie (mogelijkheid tot het op afstand connecteren met het netwerk van de klant, interventie on site) en de interventieduur (de tijd die de leverancier nodig heeft om de interventie uit te voeren). In sommige gevallen, voornamelijk wanneer de beschikbaarheid van de applicatie cruciaal is voor de uitbesteder, worden er afspraken gemaakt met betrekking tot het opzetten van een tweede (reserve- of back-up) systeem dat, bij gebrek aan beschikbaarheid van het hoofdsysteem, de taken van het eerste systeem overneemt, desgevallend met beperkte functionaliteiten. Een volledig vertrouwen in dergelijk reserve- of back-upsysteem is evenwel niet altijd mogelijk, zeker wanneer de nietbeschikbaarheid van het eerste systeem veroorzaakt werd door een fout die desgevallend repetitief kan zijn, waardoor het risico bestaat dat het tweede systeem ook zal uitvallen. Gezien het grote belang van de beschikbaarheid van het systeem en de (verschillende) applicatie(s), wordt er dikwijls een uitvoerige beschrijving opgenomen van de procedures die worden gevolgd in geval van elektriciteitspannes, onderhoudswerkzaamheden aan het systeem en de applicaties, e.d.m. Data centers zijn in de meeste gevallen uitgerust met een systeem dat elektriciteitsvoorziening garandeert in geval er een stroompanne optreedt. In dit verband kan gespecifieerd worden binnen en voor welke termijn een backupbatterij voor stroomvoorziening kan zorgen, de autonomie van de stroomgenerator en zelfs de termijn binnen dewelke nieuwe brandstof voor zulke generator kan worden aangeleverd. Bij het opstellen van een service level agreement dat betrekking heeft op de beschikbaarheid van het systeem, is het van het grootste belang om duidelijke afspraken te maken met betrekking tot geplande niet-beschikbaarheid van het systeem. Zo dient er meer bepaald te worden gespecifieerd wanneer er onderhoudswerkzaamheden aan het systeem kunnen worden verricht (dikwijls heeft dit als gevolg dat de applicatie voor een bepaalde duur off line wordt gezet), hoe dikwijls dit gebeurt en voor welke tijd de applicatie niet beschikbaar zal zijn. (b) antwoordtijden (response time) Zowel voor de leverancier als voor de uitbesteder is het belangrijk om uiterst gedetailleerd tewerk te gaan bij het vastleggen van de antwoordtijden van het systeem, zijnde de tijd die het systeem nodig heeft om resultaten te geven. Dit punt is meestal voor de uitbesteder en de gebruikers cruciaal omdat dit een rechtstreekse invloed heeft op de bruikbaarheid en de rentabiliteit van het systeem. Alleszins dient in dergelijk geval duidelijk te worden gespecificeerd onder welke omstandigheden, met welke apparatuur en met welke (netwerk)verbindingen een bepaalde antwoordtijd kan worden gegarandeerd.

16

Moeilijker wordt het evenwel wanneer de uitbesteder garanties met betrekking tot antwoordtijden vraagt binnen een omgeving die niet of niet volledig onder controle staat van de leverancier, hetgeen meestal in een internet-omgeving het geval is. Indien de internet service provider van de gebruiker niet dezelfde is als de leverancier van de dienstverlening kunnen er – voor zover er geen peering agreements bestaan tussen de verschillende internet service providers – meestal geen garanties worden geboden voor wat de responstijd betreft wegens de aanwezigheid van externe factoren die door de leverancier moeilijk kunnen worden beïnvloed. Vandaar de noodzaak om duidelijk vast te leggen vanaf welk momenten de (desgevallend verschillende) responstijden worden gemeten : het ogenblik waarop de gebruiker zijn vraag aan het systeem richt of het ogenblik waarop de centrale server de vraag verkrijgt of verwerkt. Anderzijds dient ook het eindmoment duidelijk te worden vastgelegd : het ogenblik waarop de centrale server de gegevens van de applicatieserver verkrijgt, deze gegevens verwerkt of doorzendt, het ogenblik waarop de gebruiker het antwoord ontvangt of volledig gepresenteerd krijgt. E. Uitwerking van de service levels Het is van het grootste belang voor de partijen om de verschillende criteria en de respectieve parameters vast te leggen bij de aanvang van de overeenkomst, om eventuele discussies achteraf te vermijden. Doorgaans worden drie verschillende fasen onderscheiden : (a) transition in : de applicatie wordt (gradueel) overgeplaatst naar het data center van de leverancier en aldaar in productie gezet. Vermits de applicatie nog niet volledig is, is het dikwijls onmogelijk om tijdens deze overgangsfase stringente service level-verplichtingen op te leggen aan de leverancier; afhankelijk van de specificiteit en complexiteit van de hosting-opdracht, dienen er desgevallend contractuele mechanismen te worden ingebouwd die voorzien in het gradueel optrekken van de service levels tot op het tijdstip waarop de applicatie onder volledige controle van de leverancier wordt geplaatst of dit geacht wordt te zijn. (b) productie : indien de applicatie geheel of gedeeltelijk in productie staat, kunnen de tussen partijen overeengekomen garanties ten volle hun uitwerking krijgen; (c) transition out : wanneer de overeenkomst tussen de klant en de leverancier wordt stopgezet, dient de applicatie uit het data center van de leverancier te worden verwijderd en te worden overgeplaatst naar hetzij de klant zelf, hetzij een derde-leverancier van hosting-diensten. Indien deze overplaatsing geen (grote) invloed mag hebben op de beschikbaarheid en de performantie van het systeem, worden er vanop voorhand duidelijke afspraken gemaakt met betrekking tot de service levels die tussen partijen zullen gelden van zodra het contract wordt beëindigd. 17

F. Sanctiemechanisme Het niet-behalen van de afgesproken service levels, heeft als gevolg dat de leverancier hiervoor een bepaalde schadevergoeding dient te betalen. Deze betaling kan verschillende vormen aannemen. De meest gehanteerde techniek is deze waarbij zogenaamde service credits worden uitgereikt van zodra de dienstverlening van de leverancier lager was dan de afgesproken waarde. Concreet komt dit erop neer dat aan de uitbesteder een korting zal worden gegeven op de volgende factuur die door de leverancier zal worden uitgestuurd. Indien de dienstverlening vanwege de leverancier een bepaald kritisch niveau niet bereikt, kan er desgevallend voorzien worden in additionele sanctioneringsmechanismen, zoals het doorbreken van exclusiviteit of het stopzetten van bepaalde elementen van de dienstverlening. In het ergste geval zal het contract, indien het kritisch niveau niet bereikt wordt, worden opgezegd. G. “Best practices” voor de ASP-industrie De World Intellectual Property Organization (WIPO) 25 en het Application Service Provider Industry Consortium (ASPIC) 26 hebben, specifiek voor de ASP-industrie, enkele operationele best practices opgesteld, waarbij enkele industrie-specifieke thema’s nader worden uitgewerkt teneinde een goede relatie tussen de leverancier(s) en de uitbesteder te garanderen en geschillen te vermijden. Deze operationele best practices bestrijken volgende domeinen : (i) (ii) (iii) (iv) (v) (vi)

infrastucture planning en management; connectivity planning en management; security planning en management; applications planning en management; implementation planning en management; support planning en management

Hieronder wordt kort ingegaan op bovenstaande modellen. (i)

infrastructure planning en management

Infrastructure planning en het management ervan heeft voornamelijk betrekking op het operationeel in stand houden van het data center, de configuratie van de servers en de planning en het beheer van de beschikbaarheid van het systeem. Voor wat het data center aangaat, dienen er best practices te worden gehanteerd met betrekking tot de controle van de omgeving en bescherming tegen kritische problemen. 25 26

http://www.wipo.int. http://www.allaboutasp.org. 18

De toegang tot het systeem (voornamelijk shared cabinets of rack infrastructuren) dient enerzijds te worden verzekerd en anderzijds continu van dichtbij te worden gecontroleerd en geëvalueerd; hieromtrent dienen duidelijke richtlijnen te worden uitgeschreven die in gezamenlijk overleg op regelmatige tijdstippen te worden herzien. Met betrekking tot de configuratie van de servers dienen aandachtspunten vast te stellen aangaande aan een specifieke klant toegewezen (dedicated) hardware-omgevingen en door verschillende klanten gedeelde (shared) hardware-omgevingen. Tevens dient er, in het kader van de planning en het beheer van de beschikbaarheid van het systeem, een duidelijke opgave te worden gemaakt van de load-balancing, de clustering en de geografische redundancy van het systeem. Bij load balancing, tezamen met zogenaamde fail-over capabilities wordt de reactie gemeten van een aantal lokale servers met het oog op het doorverwijzen en alloceren van clients aan de snelst of best reagerende server in die set. Op grotere schaal, teneinde de problematiek van beperkte bandbreedte weg te werken, kan tevens de mogelijkheid geboden worden om zogenaamde mirror-servers op te zetten, desgevallend met een beperktere capaciteit, die sommige of meerdere specifieke taken op zich nemen. Een algemene methode van clustering heeft betrekking op het met elkaar verbinden van verschillende computers, waarbij connecties worden aangewend om data tussen verschillende servers te versturen en software-applicaties met elkaar gelinkt worden, hetgeen als voordeel heeft dat de eindgebruiker geen of weinig problemen ondervindt indien één van de servers buiten werking is. Geografische redundancy verzekert de beschikbaarheid van systemen en applicaties in geval een volledig local area network of zelfs een data center niet meer of niet meer naar behoren functioneren omwille van een lokaal probleem. Door geografische redundancy te voorzien, wordt de impact van dergelijk lokaal probleem omzeild, vermits andere systemen op een andere geografische locatie overnemen. Het spreekt voor zich dat geografische redundancy enkel en alleen aangeboden kan worden door meer mature dienstverleners op dit vlak, vermits de kosten voor het operationeel houden van dergelijk back-up systeem aanzienlijk zijn. (ii)

connectivity planning en management

Een gedegen ontwerp van de netwerkinfrastructuur is van cruciaal belang, voornamelijk wanneer er applicaties ter beschikking worden gesteld waarvoor een grotere capaciteit is vereist of ingezet worden voor complexe berekeningen. Zijn in dit verband relevant : (a) vermindering van de vertraging op de datatransmissie en packet loss, hetgeen hogere wachttijden veroorzaakt aan de kant van de eindgebruiker, (b) onmogelijk maken van zogenaamde single point failures, waarbij het netwerk op dergelijke manier geconfigureerd dient te worden dat het dataverkeer onmiddellijk moet worden afgeleid in geval van fouten, met het oog op het vermijden van onderbrekingen van de dienstverlening. Ook omtrent schaalbaarheid moeten er bepaalde garanties worden gegeven, waarbij rekening dient te worden gehouden met een hoger of lager aantal gebruikers en een hogere 19

of lagere transmissie van data via het netwerk, desgevallend gerelateerd aan piek- en daluren. Tevens dienen uitbesteders niet alleen gedegen te worden geïnformeerd met betrekking tot toekomstige investeringen in connectiviteit, waarbij desgevallend bijkomende mogelijkheden worden geboden, maar tevens met betrekking tot de beperkingen van het systeem, hoe de leverancier met deze beperkingen zal omgaan en wat desgevallend aanvullende opties zijn voor de cliënt. (iii)

security planning en management

Eén van de belangrijkste bekommernissen en – zo blijkt uit de praktijk – tevens succesfactoren van een uitbestedingsproject betreft de beveiliging die er met betrekking tot het systeem en de verschillende applicaties wordt geboden. Veel leveranciers reageren – om begrijpelijke redenen – nogal terughoudend wanneer er garanties worden geëist met betrekking tot beveiliging. Echte garanties kunnen hieromtrent meestal niet worden gegeven, hetgeen evenwel niet wegneemt dat het uiterst belangrijk is om duidelijke afspraken te maken met betrekking tot beveiliging. Een eerste aandachtspunt betreft de authenticatie. Hieromtrent dient de leverancier op gedetailleerde wijze weer te geven welke procedures en systemen er worden gebruikt voor de verificatie, niet alleen van de gebruikers van het systeem, maar ook van de geldigheid van interagerende applicaties en netwerkbronnen. Vervolgens dienen zorgvuldig de procedures te worden gedocumenteerd die dienen te worden gevolgd om fysiek toegang te krijgen tot het data center : wordt er voorzien in (permanente) bewaking van het gebouw, welke toegangsprotocollen dienen te worden gevolgd om toegang te krijgen tot de verschillende ruimtes, o.m. door gebruik te maken van een kaartlezer, irisscan, stemherkenning, paswoord of -code, e.d.m. Voor wat het gebruik van paswoorden betreft, dient er tevens te worden gespecifieerd voor welke termijn deze paswoorden geldig zijn, hoe deze periodiek dienen te worden gewijzigd en welke procedure hiervoor dient te worden gerespecteerd. Tevens dient de integriteit van het systeem zoveel als mogelijk te worden gewaarborgd : (a) applicaties en data moeten beveiligd worden tegen niet-geautoriseerde wijzigingen; (b) het minimaliseren van onderbrekingen in de dienstverlening naar aanleiding van hardware-problemen door voldoende wisselstukken ter beschikking te hebben in het data center; (c) het instellen van verschillende connecties of fysische mogelijkheden om te voorzien in data-overdracht door gebruik te maken van verschillende dragers (LAN, tape back-ups, etc.); (d) instellen van voldoende tests op netwerk- en applicatieniveau, zowel tijdens de ontwerpfase als in de productiefase teneinde tijdig bugs en errors te detecteren en te verhelpen; (e) het opstellen, bij voorkeur geval per geval, van een disaster recovery plan en een business continuity plan, waarbij er rekening dient te worden gehouden met een maximaal aantal problemen die mogelijkerwijze kunnen opduiken, met het oog op het verhelpen van onvoorzienbare onderbrekingen in de dienstverlening. Een aandachtspunt waaraan een groot aantal sectoren – denken we maar aan magistraten, advocaten, bedrijfsrevisoren, dokters, research-ondernemingen, e.d.m. – zeer veel belang 20

aan hechten is het vrijwaren van de confidentialiteit van de inhoud van de verstuurde data. In dit verband dient de leverancier ondubbelzinnig inzage te geven in de bescherming, zowel op netwerk-, applicatie en desktop-niveau, tegen niet-geautoriseerde toegang tot het systeem, de applicaties, data en het gebruik ervan. Dit kan gedaan worden door (a) een continue en intensieve controle van het netwerk (o.m. tegen port-scans, pings, toegang tot dedicated cabinets, e.d.m.); (b) het beperken van de visibiliteit van verschillende systeemfuncties door gebruik te maken van beveiligde kanalen (multi-layer, VPN, e.d.m.); en (c) het verwijderen van alle sporen van data van harde schijven, geheugen en andere media die voorzien in een tijdelijke opslag vooraleer deze media hergebruikt worden, zodat eerder verwijderde data niet kan worden teruggezet. Non-repudiation, of de onmogelijkheid tot het ontkennen van bepaalde handelingen kan door gebruik te maken van adequate logging-systemen en authenticatieprocedures, dient zoveel als mogelijk te worden gegarandeerd, maar is onlosmakelijk verbonden met het correct functioneren van de controle op de toegang tot het netwerk en correcte authenticatie. Verantwoording en audit. Het systeem en/of de applicatie dient op dergelijke manier geconfigureerd te zijn dat er een te allen tijde door het systeem een complete opgave kan worden gegenerereerd van de systeem- en gebruikersactiviteit, hetgeen de leverancier en de uitbesteder moet toelaten om eventuele fouten en moeilijkheden op te sporen. Dergelijke opgave bepaalt meer bepaald hoe, wanneer en waarom het systeem op een bepaalde manier gegevens genereert, abnormaal gebruik van systeembronnen of bepaalde evenementen detecteert buiten het kader van de gewone werkzaamheid en/of beschikbaarheid van zulk systeem. Wat de beschikbaarheid en de continuïteit van de systeembronnen aangaat, moet de ASP tevens bepaalde procedures ontwerpen, plannen en implementeren om de continuïteit van de activiteiten te verzekeren, ongeacht het opduiken van hard- en softwareproblemen in het systeem en/of in één of meerdere applicaties, overmacht (met, zoveel als mogelijk, een duidelijke opgave van gevallen die al dan niet als overmacht kwalificeren en in acht genomen de mogelijkheid om de aansprakelijkheid van de dienstverlener(s) op dit vlak te beperken) door het maken van een impact van dergelijke evenementen op de bedrijfsvoering van de onderneming, het plannen van de continuïteit van de onderneming, risicobeheer en –vermijding, reactie- en herstelplanning. Beveiliging houdt bijgevolg tevens in dat er duidelijke procedures moeten worden vastgelegd met betrekking tot onvoorziene of onvoorzienbare omstandigheden. Voor bedrijfskritische omgevingen wordt dikwijls opgave gedaan van de opvolging van gebeurtenissen bij brand, uitvallen van elektriciteit en het volledige verlies, om welke reden dan ook, van het data center. Wat brandpreventie en –remediëring betreft, wordt in eerste instantie een beschrijving gegeven van de omgeving waarbinnen de applicatie zich bevindt, namelijk welke brandvertragende en brandwerende materialen en –gassen er worden gebruikt in het gedeelte van het gebouw waar het data center is ondergebracht. Anderzijds worden dikwijls ook het alarmsysteem en de –procedure omschreven. Procedurele beveiliging. Een ASP en de dienstverleners waarop een beroep dient te worden dienen ervoor te zorgen dat het personeel waarop zij een beroep doen voor het 21

verzekeren van hun dienstverlening voldoende op de hoogte zijn en gehouden worden van risico’s die verband houden met de beveiliging van de omgeving en de applicatie. De security policies die dienen te worden ontwikkeld of ontwikkeld zijn dienen op regelmatige tijdstippen onderworpen te worden aan diepgaande controles, geëvalueerd en desgevallend aangepast. Daarenboven dienen klanten duidelijk te worden geïnformeerd met betrekking tot de acties die er door de leverancier(s) wordt/worden ondernomen ingeval de beveiliging in het systeem doorbroken wordt en hoe daarmee intern wordt omgegaan. (iv)

application management

Intellectuele eigendomsrechten. Het is vanzelfsprekend van het grootste belang om duidelijk te stellen wie over het (intellectueel) eigendomsrecht van de applicatie beschikt. In gemengde omgevingen – waarover in de meeste gevallen althans gesproken wordt – is een dergelijke aflijning geen sinecure, zeker wanneer er bepaalde (standaard)software van (onafhankelijke) derden wordt betrokken. Consultancy-ondernemingen gaan vervolgens dergelijke software gebruiken, configureren, van bepaalde interfaces voorzien, aanpassen en er bepaalde applicaties, waarvan zij al dan niet zelf eigenaar zijn, aan toevoegen. Wanneer de uitbesteder hieraan zelf dan nog programma’s en bedrijfsinterne applicaties gaat toevoegen, wordt het intellectueel eigendomsrecht over “het systeem” of “de applicatie” al vlug geen sinecure. Al te dikwijls wordt in IT-uitbestedingscontracten bepaald dat het intellectueel eigendomsrecht over “de applicatie” wordt overgedragen aan de uitbesteder, en worden er zelfs garanties geboden aangaande deze rechten, hetgeen leveranciers mogelijkerwijze in een erg moeilijk parket kan brengen. Vandaar de noodzaak om, op grond van een gedetailleerde due diligence duidelijk te bepalen wie over welke rechten beschikt met betrekking tot welk deel van de applicatie. Indien software van derden wordt betrokken, geldt hetzelfde aandachtspunt. Zowel uitbesteder als leverancier dienen met de grootste zorg afspraken te maken omtrent het gebruiksrecht van de software, meer bepaald met betrekking tot de duur van het gebruiksrecht, het aantal gebruikers dat op het systeem wordt toegelaten, de door de producent/leverancier van de software verstrekte garanties en assistentie bij de implementatie van de software, het al dan niet voorhanden zijn van een helpdesk en/of trainingfaciliteiten, waar gebruikers terecht kunnen voor vragen en/of opleiding, mogelijkheden om het systeem uit te breiden, upgrades en patches te voorzien, het bepalen van een termijn tussen twee verschillende releases, enz. Prijspolitiek. Een erg belangrijk aandachtspunt, hetwelk rechtstreeks verbonden is met het bepalen van service levels, betreft het voeren door de leverancier van een duidelijke en transparante prijspolitiek. Het ligt voor de hand dat het hanteren van een veelvoud van service levels een rechtstreekse impact heeft op deze transparantie, waardoor het voeren van een adequate politiek op dit vlak dikwijls een uitdaging zal betekenen voor de leverancier. Application readiness. ASP’s dienen een duidelijk beleid te voeren met betrekking tot de applicatie die zij beheren en waartoe zij toegang verschaffen aan de klant. Hierbij dienen zij voldoende aandacht te verschaffen aan de definitie van de vereisten van de klant met 22

betrekking tot de bandbreedte die hem ter beschikking wordt gesteld voor het toegankelijk maken van zijn applicatie, alsmede de hypotheses waarin deze bandbreedte desgevallend kan worden beperkt (of uitgebreid). Dikwijls worden klanten ook geïnformeerd over de totale hoeveelheid bandbreedte die ter beschikking staat van de service provider en bij welke telecommunicatie-bedrijven deze bandbreedte betrokken wordt, welk gedeelte van het intern netwerk deze bandbreedte gebruikt en de mogelijkheden voor de klant om desgevallend combinaties te maken van verschillende elementen in deze verschillende spectra. De (on)mogelijkheid van ontwikkeling, aanpassing, upgrading en de overdracht of het verstrekken van gebruiksrechten op de interface waarlangs het systeem en de applicaties toegankelijk moeten worden gemaakt dient tevens aan een klant duidelijk te worden gemaakt, teneinde een optimaal gebruiksgemak te verzekeren. In dit verband moet de klant de mogelijkheid hebben om zijn eisen aangaande lay-out, en inhoud duidelijk te maken aan de leverancier(s). Een belangrijke factor in het aangaan van verplichtingen rond het hanteren van bepaalde service levels aan de kant van de leverancier betreft het voeren van een efficiënte en transparante politiek aangaande capaciteitsplanning en –beheer van de applicatie, hetgeen strikt genomen losstaat van de connectiviteit met het netwerk (zie hoger). Het gaat hier meer bepaald om de datacapaciteit en berekeningssnelheid van de applicatie zelf, hetgeen veelal afhangt van de interoperabiliteit van andere toepassingen, zoals bijvoorbeeld databanken, en van de gebruikte hardware. Rechtstreeks hiermee gerelateerd is de schaalbaarheid van de applicatie. Wordt de mogelijkheid geboden om gebruikers en/of content toe te voegen aan de applicatie en, zo ja, in welke mate ? Wat zijn de consequenties indien er meerdere gebruikers worden toegevoegd ? Vandaag de dag is er bepaalde software op de markt verkrijgbaar waardoor dagdagelijkse applicaties (tekstverwerkers, spreadsheets, edm.) die nog niet aangepast zijn aan een ASP-omgeving toch “ASP-enabled” worden, al is de capaciteit van deze software eerder beperkt te noemen. Procedures dienen tevens duidelijk te maken in welke fase van de dienstverlening en op regelmatige tijdstippen in de productie-fase de applicatie zal worden onderworpen aan een gedetaillerde en diepgaande test. Dergelijke tests zijn en blijven in ieder geval nodig in het geval er voortdurend nieuwe ontwikkelingen zullen worden gedaan op het geïnstalleerde platform. In sommige gevallen zullen voor bepaalde cruciale onderdelen van de verschillende applicaties, teneinde de continuïteit van het systeem en de dienstverlening te verzekeren, aanhoudend tests worden gedaan. Operationeel rechtstreeks verband houdend met de schaalbaarheid van de applicatie, de connectiviteit en de beschikbaarheid van het netwerk is de beschikbaarheid van de applicatie op zich. Toch moet de beschikbaarheid van de applicatie in de berekening van de service levels als een apart onderdeel worden beschouwd, vermits een applicatie omwillen van een soft- of hardwareprobleem niet beschikbaar kan zijn, ofschoon zowel hardware als connectiviteit gegarandeerd zijn. Procedures dienen te voorzien hoe en binnen welke termijn de leverancier dient op te treden indien de applicatie onbeschikbaar blijkt te zijn, welke handelingen hij dient te ondernemen om beschikbaarheid te garanderen en te meten welke impact deze niet-beschikbaarheid had op de algemene beschikbaarheid. Indien de problemen die zich manifesteerden een repititief karakter 23

kunnen hebben, dient desgevallend op andere vlakken te worden ingegrepen teneinde algemene beschikbaarheid te verzekeren. Niet alleen de gebruiksinterfaces, maar ook de gehele of gedeeltelijke applicatie moet in zekere mate aan te passen zijn. De leverancier dient hierbij in te gaan op change requests van de klant, aan de hand van een gedetailleerde analyse de klant op de hoogte te brengen van zijn antwoord op dergelijke vraag tot wijziging van de applicatie en, zo de gevraagde aanpassingen aan de applicatie kunnen worden doorgevoerd, hieromtrent een duidelijke planning en prijsofferte aan de klant te overhandigen. Afbakening van aansprakelijkheid. Het is ontegensprekelijk in het voordeel van de dienstverlener om aan zijn klanten duidelijk te maken waar zijn aansprakelijkheid voor het systeem en haar verschillende applicaties begint en waar deze ophoudt. De toegang tot het systeem kan niet alleen afhankelijk worden gemaakt van een aantal hardware-vereisten, ook bepaalde infrastructuurproblemen (zoals onder meer connectiviteit) kunnen niet onder alle omstandigheden worden gegarandeerd. De virtuele globale aanwezigheid van een ASP impliceert bijgevolg niet dat de dienstverlening overal vlekkeloos zal verlopen. Beheer. Het moet duidelijk zijn welke administratieve taken er kunnen worden opgenomen door de ASP en door de klant zelf en hoe de beveiliging van de applicatie dient te worden beheerd en in stand gehouden. Support : de klant dient op diens verzoek een duidelijke opgave te krijgen van de mogelijkheden die er geboden worden om de applicatie te ondersteunen, welke procedures en methodes er in dit verband worden gehanteerd, alsmede de systemen die worden opgezet om deze ondersteuning binnen bepaalde tijdsintervallen te verzekeren. (v)

implementation planning en management

Hetzij op basis van informatie verkregen van de uitbesteder, hetzij op basis van een in samenspraak met de klant opgestelde behoefteanalyse, dient duidelijk te blijken welk soort applicatie geschikt is voor de klant, rekening houdend met het gebruik dat hij van de applicatie wenst te maken, de beoogde doelstellingen van de organisatie en – in al dan niet belangrijke mate – rekening houdend met de schaalbaarheid ervan. Grosso modo kunnen volgende verschillende activiteiten worden onderscheiden : 1. keuze van het hardwareplatform op grond van de behoeftenanalyse die werd uitgevoerd, rekening houdend met de omvang van de data en het gebruik dat ervan zal worden gemaakt. Dit platform dient te worden geïnstalleerd en voorbereid op de installatie van de basissoftware; 2. installatie van de hardware bij de ASP; 3. installatie van client hardware en voorbereiding ervan op de installatie van de software; 4. configuratie van de hardware en software; afstemmen van het systeem op de behoeften van de gebruiker; 24

5. conversie van de data van de uitbesteder en migratie ervan naar het nieuwe platform; 6. rapportering; 7. testen van de omgeving en kwaliteitscontrole; 8. integratie van het systeem in het data center van de ASP; 9. training van de eindgebruikers. (vi)

Support planning en management

Support van de applicatie. Aan de gebruikerszijde van de applicatie, dient er desgewenst assistentie te worden verleend bij het beheer van de eigen werkomgeving (zgn. desktop management), waarbij de klemtoon dient te liggen op het gebruik van de nieuwe omgeving en de applicaties vanuit client-perspectief. Dit houdt tevens in dat er connectiviteit verzekerd dient te worden voor o.m. thuiswerkers, handelsreizigers, e.d.m. Vervolgens kan er toegang worden verleend tot en gebruik worden gemaakt van nieuwe versies of nieuwe releases van software-toepassingen of hardware-onderdelen; de best practices dienen in dit verband te specifiëren hoe een klant hiertoe toegang kan krijgen, waarbij deze laatste voldoende geïnformeerd dient te worden aangaande de implicaties die dergelijke overgang met zich mee kunnen brengen. Rechtstreeks verband hiermee houdend, betreft de implementatie van nieuwe applicaties op het platform (aanvankelijk in een testomgeving, later desgevallend in een productieomgeving) en de behandeling van eventuele upgrades van het systeem. Ook hier dient de klant voldoende informatie te verkrijgen aangaande de implicaties die dergelijke ingrepen kunnen betekenen voor het systeem, het gebruik van de applicatie en – in het algemeen – de gehele omgeving. Tevens dient de leverancier de klant voldoende op de hoogte te houden met betrekking tot fouten die in het systeem werden geconstateerd. Deze rapportering gebeurt bij voorkeur op regelmatige tijdstippen (voor zover de impact van het probleem op het systeem en/of de applicatie minimaal gebeurt), hetzij in het kader van het in werking treden van het disaster recovery plan. Indien de software-leverancier herstelmodules of zogenaamde “patches” ter beschikking stelt, dienen er ondubbelzinnige afspraken te worden gemaakt met betrekking tot de implementatie van deze “patches” en de (tijdelijke) impact van deze implementatie op de werking van het systeem en/of de applicatie. Voor grotere ondernemingen of voor ondernemingen die veel gegevens verwerken is het beheer van de databases dikwijls van cruciaal belang. Vermits een goed beheer van een database impliceert dat er duidelijke afspraken worden gemaakt met betrekking tot het onderhoud ervan door gekwalificeerd personeel, dienen er door de leverancier hetzij garanties geboden op dit vlak, hetzij aan dit gekwalificeerd personeel toegang verleend.

25

Cruciaal in het kader van de disaster recovery is het nemen van back-ups, waarvoor veelal resultaatsverbintenissen worden opgenomen (zie ook hoger); hetzelfde geldt voor het restoren en opnieuw toegankelijk maken van deze data. Tevens kan het archiveren van data in sommige gevallen erg belangrijk zijn, afhankelijk van de activiteit van de klant. Archivering dient los te worden gezien van back-ups, hetgeen in de praktijk niet altijd het geval blijkt te zijn. Een ASP zal in de meeste gevallen tevens voorzien in het onderhoud van het systeem, al kan het aangewezen zijn om het onderhoud van bepaalde applicaties in eigen beheer te houden of aan een derde uit te besteden. De ASP dient in dergelijk geval voldoende flexibiliteit aan de dag te leggen met betrekking tot de toegankelijkheid en het gebruik van het systeem voor onderhoudsdoeleinden. Bijstand mbt. het systeem : bijstand en upgrades van het operating system dienen toegankelijk te worden gemaakt, teneinde maximaal gebruik te kunnen maken van de applicaties en desgevallend de implementatie van nieuwe toepassingen mogelijk te maken. Tevens moet er werk worden gemaakt van procedures omtrent het oplossen van problemen, zowel op soft- als hardwareniveau, met het oog op het minimaliseren van onderbrekingen in de dienstverlening. Het beheer van de inventaris blijft tevens een belangrijk aandachtspunt, zeker wanneer de relatie tussen de (verschillende) leverancier(s) onderling of tussen de leverancier(s) en de klant spaak loopt. In dergelijk geval dient het onmiddellijk duidelijk te zijn voor de betrokken partijen wie over welke (eigendoms)rechten beschikt. Network support. Hierbij dient voornamelijk rekening te worden gehouden met hogervermelde latency issues, beveiliging van het netwerk, beheer van bandbreedte en van netwerkonderbrekingen. Controleprocedures dienen te worden ingesteld en dient er op regelmatige tijdstippen een adequate rapportering te worden overgemaakt aan de klant, bij voorkeur in een voor hem begrijpelijke taal en gesteld in een begrijpelijk jargon. Helpdesk. De overgang van het in eigen beheer houden van een applicatie naar het uitbesteden ervan kan een belangrijke impact hebben, niet alleen op de applicatie op zich, maar tevens op de gebruikers ervan. Het zijn voornamelijk deze eindgebruikers die – meestal voornamelijk in de beginfase – zullen worden geconfronteerd met een aantal problemen of vragen met betrekking tot de nieuwe of gewijzigde omgeving, nieuwe interfaces, nieuwe functionaliteiten, e.d.m. Teneinde hun voldoende vertrouwd te maken met deze aanpassingen en nieuwigheden, dienen zij voldoende bijstand te krijgen van hetzij de uitbesteder, hetzij de ASP, hetzij een gespecialiseerde onderneming. In dit kader dienen dan desgevallend ook – binnen bepaalde tijdspannes – helpdesks ter beschikking van dergelijke gebruikers. H.

Service Level Management en Reporting

Een gedetailleerd service level agreement heeft vanzelfsprekend maar nut wanneer de meting en het al dan niet bereiken van de verschillende service levels voldoende wordt 26

opgevolgd, hetzij door (één van) de partijen, hetzij – bij voorkeur – door een onafhankelijke onderneming. Contractueel dient te worden vastgelegd dat de verantwoordelijke voor service level management op periodieke basis dient te rapporteren over de stand van zaken en de performantie van het systeem. Het spreekt voor zich dat dergelijke rapportering haast uitsluitend gebaseerd is op het cijfermateriaal dat door het systeem of (bij voorkeur) door een onafhankelijke derde wordt gegenereerd. Bij voorkeur dient de overeenkomst tevens de partijen in staat te stellen om de vooropgestelde service levels te evalueren (review and revision) en, waar nodig – gezien de concrete omstandigheden, bij te sturen, voornamelijk op deze punten die aanzienlijke meerkosten met zich meebrengen (bijvoorbeeld 24/7 stand-by, onderhoud tijdens het weekend, enz.). Review heeft voornamelijk als doel om na te gaan of de service level objectives nog steeds geldig zijn en dat de processen naar behoren werken. Beide partijen dienen op reguliere basis samen te komen teneinde dergelijke controle uit te voeren. De eerste review vindt bij voorkeur plaats drie maanden tot een half jaar nadat de service level objectives in werking zijn getreden. Beide partijen dienen tevens over de mogelijkheid te beschikken om de service level objectives te herzien. Dergelijk recht wordt veelal gebruikt wanneer multinationale ondernemingen bepaalde facetten van hun IT gradueel gaan uitbesteden (op verschillende tijdstippen worden grote aantallen gebruikers toegevoegd, met dikwijls exponentiële verhogingen van de data-trafiek als gevolg), maar ook voor kleine of middelgrote ondernemingen kan dit belangrijk zijn. Het bijkomend aanwerven van twee administratieve bedienden op een dienst waar zes personen tewerkgesteld zijn kan namelijk een aanzienlijke invloed hebben op het systeem. Het herzien van service level objectives kadert dikwijls in een change request-procedure, waarbij door de (verschillende) leverancier(s) een analyse wordt gemaakt van de behoeften van de gebruikers en de impact op de bestaande infrastructuur. De resultaten van de metingen tijdens de transition in-fase, hierboven besproken, kan desgevallend als (eerste) adequate maatstaf fungeren. De taak van de Service Level Manager bestaat evenwel niet louter uit het rapporteren van het al dan niet halen van de service levels

27

III.

Conclusie

Zoals blijkt uit het bovenstaande, dient er bij het uitbesteden van bepaalde al dan niet bedrijfskritische IT-activiteiten vanaf het ogenblik waarop gesprekken worden aangeknoopt tussen de verschillende partijen de grootste aandacht te worden besteed aan het duidelijk documenteren van de afspraken die er worden gemaakt, niet alleen bij de organisatie van de aanbodzijde, maar tevens bij het opstellen van de definitieve overeenkomst tussen enerzijds de leverancier en anderzijds de uitbesteder. Deze afspraken dienen in de précontractuele fase betrekking te hebben op de aard van de informatie die er wordt uitgewisseld (juiste informatie, behouden van confidentialiteit), alsmede in geval er reeds diensten verstrekt worden in deze précontractuele fase. Bij de onderhandeling van de definitieve overeenkomst, dienen duidelijke afspraken te worden gemaakt met betrekking tot de aard van de verbintenissen die er worden aangegaan, alsmede de resultaten die van de leverancier worden verwacht. In ieder geval is het raadzaam om te zorgen voor transparante mechanismen die in staat zijn de kwaliteit van de dienstverlening op een adequate wijze te meten en tevens de nodige flexibiliteit in te bouwen in de overeenkomsten, teneinde zoveel als mogelijk wijzigingen in de omgeving mogelijk te maken.

28