Onderzoek naar de asymmetrie van informatie bij het afsluiten en uitvoeren van softwareonderhoudscontracten Studiegebied Industriële Wetenschappen en Technologie Opleiding Elektronica Optie Multimedia en Informatietechnologie Academiejaar 2005-2006 Pieterjan Donck Dries Vanderhaeghen
Voorwoord Als laatstejaarsstudenten Industrieel Ingenieur, Master Elektronica-ICT afstudeerrichting MIT (Multimedia- en Informatietechnologie) worden we verwacht een eindwerk te maken. Tussen de voorstellen van de beschikbare eindwerken zat het onderzoek naar de adequaatheid van de prijszetting van onderhoudscontracten. Door onze voorgeschiedenis als afgestudeerd student Bachelor Multimedia en Communicatie technologie vonden we dit een interessant onderwerp. Dit omdat we zelf al meerdere softwareprogramma s hebben ontworpen. De titel van ons eindwerk is naderhand gewijzigd naar het onderzoek naar de asymmetrie van informatie bij het afsluiten en uitvoeren van softwareonderhoudscontracten. Bij deze willen we onze interne promotor Jan Devos bedanken voor de goede begeleiding en steun die hij ons gedurende het jaar gegeven heeft. Alsook iedereen die ons geholpen heeft dit eindwerk tot een goed einde te brengen. Pieterjan Donck & Dries Vanderhaeghen I
Inhoudsopgave Voorwoord... I Inhoudsopgave...II Gebruikte symbolen en afkortingen... V Lijst van afbeeldingen en figuren... VI 1 Inleiding... 7 2 Het onderhoudscontract... 8 2.1 Betekenis... 8 2.2 Situering...10 2.2.1 Hardwareonderhoudscontracten...10 2.2.2 Softwarelicenties...10 2.2.3 Softwareontwikkelingcontracten...11 2.2.4 Consultingcontracten...11 2.2.5 Softwareonderhoudscontracten...11 2.3 Classificatie van software...12 2.3.1 Maatwerk versus pakketten...12 2.3.2 Soorten software...14 2.4 Soorten onderhoud...15 2.4.1 Correctief of curatief onderhoud...15 2.4.2 Adaptief of aanpassingsonderhoud...15 2.4.3 Evolutief of perfectief onderhoud...16 3 Informaticarecht...17 3.1 Levering en garantie...17 3.1.1 Leveringsfase...17 3.1.2 Garantiefase...18 3.1.3 Onderhoudscontractfase...18 3.2 Industriële eigendomsrechten...19 3.2.1 Belgische octrooiwet (wet van 28 maart 1984 op de uitvindingoctrooien)19 3.2.2 Het auteursrecht...19 3.2.3 Het vermogensrecht...19 3.2.4 De softwarewet...20 3.3 De informatieplicht...21 4 Probleemstelling...22 4.1 A market for lemons...22 Pieterjan Donck & Dries Vanderhaeghen II
4.2 Principaal-agent probleem...22 4.3 Conclusie...26 5 Bestaande studies...27 5.1 UKSMA & ISBSG Maintenance en Support Measurement Manual (United Kingdom Software Metrics Association & International Software Benchmarking Standards Group)...27 5.1.1 Inleiding...27 5.1.2 De benadering...28 5.1.3 Te verwachten resultaten...30 5.1.4 Metingen in detail...30 5.1.5 Afgeleide metingen...48 5.1.6 Definities...55 5.2 PricewaterhouseCoopers: Webster Patterns in IT Litigation - systems Failure...57 5.3 SEI - Software Engineering Institute...62 5.3.1 Wat is het SEI...62 5.3.2 CMM (Capability Maturity Model)...63 5.3.3 CMMI (Capability Maturity Model Integration)...68 6 Praktisch onderzoek contracten...75 6.1 Doel...75 6.2 Werkwijze...75 6.2.1 Bedrijven contacteren...75 6.2.2 Analyseren onderhoudscontracten...76 6.2.3 Resultaat...79 6.3 Conclusie...81 7 Conflictenanalyse...82 7.1 De verschillende luiken van het onderhoudscontract...82 7.1.1 Luiken enkel belangrijk voor de klant...82 7.1.2 Luiken enkel belangrijk voor de leverancier...83 7.1.3 Luiken voor beide partijen even belangrijk...83 7.2 Aanvangstijdstip...84 7.3 Duur en verlenging...85 7.4 Rollenspel klant-leverancier...86 7.5 Courante conflictoorzaken...90 7.5.1 Wie is uiteindelijk eigenaar van de software?...90 7.5.2 Hoe worden updates toegepast?...90 Pieterjan Donck & Dries Vanderhaeghen III
7.5.3 Prioriteiten...90 7.5.4 Prijswijzigingen...90 7.5.5 Conflicten met andere software...91 7.6 Evaluatiemethode: flowchart...92 8 Besluit Pieterjan...104 9 Besluit Dries...106 Literatuurlijst... VI Bijlage... 1 Projectfiche... 1 Brief aan de bedrijven... 4 Bedrijvencontactdagen... 5 Logboek... 8 Pieterjan Donck & Dries Vanderhaeghen IV
Gebruikte symbolen en afkortingen IT ICT KMO ERP PIH Informatietechnologie Informatie- en Communicatietechnologie Kleine en middelgrote onderneming Enterprise Resource Planning Provinciale Industriële Hogeschool Pieterjan Donck & Dries Vanderhaeghen V
Lijst van afbeeldingen en figuren Figuur 1: Het ISBSG model van ondersteuning en onderhoud op activiteiten gebaseerd. 28 Figuur 2: Het UKSMA model van onderhoud en ondersteuning...29 Figuur 3: Het metrisch model van onderhoud en ondersteuning...30 Figuur 4: Strategie van het SEI...63 Figuur 5: Maturity levels van het CMM in stijgende volgorde...66 Figuur 6: Maturity Levels van het CMMI in oplopende volgorde...69 Figuur 7: Capability levels van het CMMI...70 Figuur 8: Aanvang softwareonderhoudscontract...85 Figuur 9: Beoordeelde contracten...103 Figuur 10: Bedrijvencontactdagen 2005... 5 Pieterjan Donck & Dries Vanderhaeghen VI
1 Inleiding Ons eindwerk is een intern eindwerk uitgevoerd aan de hogeschool West-Vlaanderen departement PIH. We hebben onderzoek gedaan naar de prijszetting van ICT-contracten en in het bijzonder naar softwareonderhoudscontracten. Het is gebleken dat vele bedrijven vaak geen correcte kijk hebben op dergelijke overeenkomsten. Wat kunnen ze verwachten van hun ICT-leverancier? Vallen alle problemen op te lossen onder het contract? Zal er niet extra moeten betaald worden voor bepaalde diensten? Zeer terechte vragen die helaas vaak leiden tot onnodige spanningen en geschillen tussen klant en ICT-leverancier. De doelstelling van ons eindwerk is te onderzoeken of de prijzen van een onderhoudscontract in balans zijn met de geleverde diensten. Bestaande wetenschappelijke methodes voor het evalueren van softwarecontracten worden van naderbij bekeken. Er wordt ook nagegaan in welke situaties en door welke oorzaken er conflicten ontstaan tussen de softwareleverancier en de klant. Om alles tot een goed einde te kunnen brengen hadden we nood aan bestaande ICTonderhoudscontracten. Om deze te kunnen bemachtigen hebben we verschillende methodes gebruikt om de aandacht van verschillende KMO s te verkrijgen. Aan de hand van e-mails en/of brieven hebben we meerdere bedrijven gecontacteerd. Alsook via ons bezoek aan de bedrijvencontactdagen hebben we meerdere bedrijven gecontacteerd om zo verscheidene onderhoudscontracten te bemachtigen. Daarna hebben we ons toegespitst op de oorzaken die conflicten tussen leverancier en klant teweeg brengen. Aan de hand van de verkregen contracten konden we de verschillende punten, die volgens ons van belang waren in een contract, uitfilteren. Aan de hand van een checklist opgebouwd als een flowchart met conflictpunten hebben we de verkregen contracten doorgelicht. Door middel van een scoringssysteem trachten we gefundeerde conclusies te trekken nopens het feit of een contract conflictgevoelig is. Hierdoor hebben we toen besloten om de titel van ons eindwerk aan te passen naar onderzoek naar de asymmetrie van informatie bij het afsluiten en uitvoeren van onderhoudscontracten. Pieterjan Donck & Dries Vanderhaeghen 7
2 Het onderhoudscontract 2.1 Betekenis Een informaticaonderhoudscontract kan zowel betrekking hebben op hardware als op software. Het is evident dat hardware (computer en randapparatuur zoals printers, backupapparatuur, schermen, communicatiemateriaal, ) zoals elk ander materiaal onderhoud nodig heeft. Dergelijke onderhoudscontracten verschillen dan ook niet vaak van onderhoudscontracten uit andere sectoren. Onderhoudscontracten hebben tot doel het materiaal in goede staat te houden gedurende een bepaalde overeengekomen periode. In goede staat kan men omschrijven als een behoud van het normale prestatieniveau. Het begrip onderhoud zelf is echter bijzonder vaag en kan verschillende betekenissen hebben naargelang het te onderhouden voorwerp. In tegenstelling tot hardwareonderhoudscontracten zijn onderhoudscontracten voor software helemaal niet evident. Het nut en de noodzaak ervan wordt vaak moeilijk begrepen of aanvaard door de klant. De klant verwacht veelal dat een software foutloos is en eist impliciet van zijn softwareleverancier 100% zekerheid dat er geen enkele bug meer aanwezig is in de software. Deze eis is echter weinig zinvol. Wij weten intussen dat software nooit foutloos kan zijn [17]. Hoe zeer men ook zijn best doet om te testen en te evalueren, het kan nog steeds mislopen door een opeenvolging van bepaalde handelingen, de aard van de ingevoerde gegevens, de samenwerking met software van derden bij de klant, enz Dit zijn zaken die soms niet getest kunnen worden door de softwareleverancier. Elke software zal dus in min of meerdere mate fouten bevatten. Het is dan ook realistischer om het bestaan van fouten te aanvaarden en hiervoor een onderhoudscontract af te sluiten. De klant zou kunnen eisen dat fouten onder de garantie moeten vallen, maar de wettelijke garantie wordt meestal onvoldoende geacht voor software gelet op de bijzondere natuur ervan. Er is bovendien meer. Stel dat softwarefouten onder de wettelijke garantie zouden vallen, dan heeft de klant nog geen enkele zekerheid dat de fouten onder bepaalde voorwaarden en binnen bepaalde termijn opgelost worden. Deze eisen zijn zeer aannemelijk voor bedrijfskritische software. Een onderhoudscontract afsluiten om enkel maar de softwarefouten op te lossen is een te enge toepassing. Het onderhoudscontract moet ook gezien worden als een verzekering voor de verdere toekomst van de software. Het kan een zekerheid bieden voor de snel Pieterjan Donck & Dries Vanderhaeghen 8
evoluerende economie en IT-infrastructuur. Er bestaan daarom verschillende soorten onderhoud. Naast het bestgekende en hoger vermelde correctief onderhoud, bestaat er ook evolutief en adaptief onderhoud. Deze laatste onderhoudsvormen kunnen een oplossing bieden voor noodzakelijke wijzigingen aan de software als gevolg van veranderde wetgeving of aanpassingen aan bedrijfsprocessen. Het is wellicht een goede zaak voor zowel klant als softwareleverancier om een onderhoudscontract op software af te sluiten. Beide partijen hebben wel tegenstrijdige belangen en beschikken meestal over ongelijke informatie met betrekking tot de materie. De softwareleverancier beschikt meestal omwille van zijn deskundigheid over de meeste informatie met betrekking tot het onderhoud. Deze informatie wordt meestal privaat gehouden en komt dus niet ter kennis van de klant. De softwareleverancier ziet in een onderhoudscontract een continue bron van inkomsten. Inkomsten die noodzakelijk zijn voor de verdere ontwikkeling van software en het herstellen van softwarefouten. Voor de klant is het onderhoudscontract een verzekering voor een zo foutloos mogelijk gebruik van de software over een bepaalde periode. Onderhoudscontracten worden door de leverancier vaak ook verplicht gesteld. Dit is een recht van de leverancier krachtens de auteurswet waaronder software ressorteert. Als gevolg van de tegenstrijdige belangen bij softwareonderhoudscontracten is dan ook aangeraden dat beide partijen zich actief inlaten bij het opstellen van het contract. Alles wordt best zo gedetailleerd mogelijk beschreven, gaande van de definities tot de escalatieprocedures. Het onderhoudscontract mag geen verzameling zijn van dubbelzinnige omschrijvingen door advocaten opgesteld, waar tijdens een gerechtsprocedure gretig gebruik kan van gemaakt worden. Het moet een praktisch en werkbaar document zijn. Slechts op deze manier kunnen betrokken partijen op beide oren slapen en komt het belang van een onderhoudscontract tot uiting. Pieterjan Donck & Dries Vanderhaeghen 9
2.2 Situering 2.2.1 Hardwareonderhoudscontracten Een dienstverlener zal bij een hardwareonderhoudscontract zekere verplichtingen op zich nemen tegen een bepaalde vergoeding. De dienstverlener wordt door de klant zelf gekozen en hoeft niet noodzakelijk de oorspronkelijke verkoper van de hardware te zijn. De klant kiest een dienstverlener op basis van zijn technische kennis en bekwaamheden. In tegenstelling tot software kan bij hardware gemakkelijker een dienstverlener gekozen worden. Hardware is immers een geheel van universeel gefabriceerde onderdelen. De kennis van onderhoudsprocedures is voor iedereen toegankelijk. Het wil echter niet zeggen dat een dienstverlener voor onderhoud op hardware gelijk wie mag zijn, de oorspronkelijke hardwareleverancier zal nog steeds het meest op de hoogte zijn van de systemen en hiermee een voordeel hebben tegenover anderen. Software daarentegen is een uniek vervaardigd werk, waarbij meestal enkel de oorspronkelijke softwarebouwer wijzigingen kan aanbrengen. Uniek aan hardwareonderhoud is dat men ook preventief onderhoud kan uitvoeren. Onder preventief onderhoud verstaan we een geheel van reguliere controles die ervoor moet waken dat het systeem correct blijft functioneren. Een onderhoudscontract op hardware is misschien minder noodzakelijk bij bedrijven met een beperkte ICT-infrastructuur en met minder kritische bedrijfsprocessen. In een dergelijk geval kan dan eventueel geopteerd worden voor case-by-case vergoedingen. Bij tussenkomst van technisch personeel kan deze formule gecombineerd worden met een tarifering op uurbasis. Een contract daarentegen biedt dan weer het grote voordeel dat kan vastgelegd worden dat interventies verplicht moeten uitgevoerd worden en dit binnen afgesproken termijn. 2.2.2 Softwarelicenties Software is een creatief werk dat beschermd wordt door de auteurswet, zoals alle andere creatieve werken. Een softwarelicentie of gebruiksrecht biedt de gebruiker rechten, maar ook plichten bij het gebruik van software op één of meerdere computers. Een softwarelicentie omvat meestal een definitie van het product, een aantal bepalingen die door de gebruiker dienen geaccepteerd te worden en bepaalde vormen van garantie. Softwarelicenties verbieden meestal het verder verspreiden en kopiëren van de software. Pieterjan Donck & Dries Vanderhaeghen 10
2.2.3 Softwareontwikkelingcontracten Deze contracten zullen de ontwikkeling van maatwerksoftware regelen. De klant neemt zelf initiatief om software te laten ontwikkelen door een softwarebouwer. Hij zal dan ook goed weten wat er moet bereikt worden en zal niet veel afwijken van zijn doel. De businessfunctionaliteiten worden dan ook al op voorhand vastgelegd door de klant zelf en/of met de softwarebouwer. Ontwikkelen van maatwerksoftware is een niet te onderschatten project en zal hoofdzakelijk besteed zijn aan grote bedrijven en organisaties. Overdracht van rechten is hier evenwel ook mogelijk. De klant kan eigenaar worden van de software door overdracht van de vermogensrechten. Een knelpunt kan dan wel zijn dat de softwarebouwer tijdens de ontwikkeling in opdracht van de klant, ideeën en concepten opdoet die hij zou kunnen gebruiken bij eigen toekomstige software, die hem voordelen bieden om bijvoorbeeld software tegen lagere prijs aan te bieden. 2.2.4 Consultingcontracten Onder consulting wordt begrepen advies en raadgeving, taken die de informaticawereld meer dan welkom zijn. Een consultingcontract kan worden aangegaan bij de selectie, aankoop en implementatie of conversie van een informaticasysteem. De klant vraagt hierbij de diensten van een derde partij om met een onpartijdig deskundig advies zekerheid te hebben dat de juiste beslissingen genomen worden. 2.2.5 Softwareonderhoudscontracten Softwareonderhoudscontracten worden wellicht nog vaker afgesloten dan hardwareonderhoudscontracten omwille van de specialistische kennis van de dienstverlener. Wegens het niet-tastbare en meestal voor de klant onzichtbare werk dat de leverancier uitvoert, kunnen al eens misverstanden ontstaan. Conflicten zijn dan ook niet ver weg. Het belang van dergelijke softwareonderhoudscontracten wordt soms wel eens onderschat, daarom spitsen we ons in deze thesis enkel toe op softwareonderhoudscontracten. Pieterjan Donck & Dries Vanderhaeghen 11
2.3 Classificatie van software 2.3.1 Maatwerk versus pakketten We kunnen toepassingssoftware in twee grote categorieën onderverdelen: Softwarepakketten Software op maat Om een duidelijk onderscheid te maken stellen we ons eerst de vraag wat software is. Software is niet echt een product zoals alle andere producten. Het is een manier om kennis op te slaan. Die kennis wordt opgedaan door jaren ervaring en optimalisatie in een organisatie. Organisaties die pakketsoftware aanschaffen, kopen in feite kennis over bedrijfsprocessen die andere organisaties in hun plaats verzameld hebben. Dit is ideaal als die kennis er nog niet of in onvoldoende mate was. Maar stel dat die kennis al wel bij de medewerkers van de organisatie aanwezig was, dan zal pakketsoftware die bestaande kennis verdringen, ten gunste van een confectieoplossing die ook voor alle concurrenten beschikbaar is. Dit kan echter wel een bewuste keuze zijn als maatwerk slechts weinig meerwaarde levert. Maatwerk is immers veel duurder in aanschaf en in onderhoud. Als de aanwezige kennis van de organisatie vertaald wordt in maatwerksoftware, dan kan dat leiden tot een niet te onderschatten concurrentievoordeel. De kennis die aanwezig was bij individuen in de organisatie, wordt immers vastgelegd en voor iedereen in de organisatie beschikbaar gemaakt. Om dat concurrentievoordeel te behouden is het enorm belangrijk om de software continu aan te passen. De organisatie evolueert namelijk door te leren over zichzelf, de concurrentie, de klanten en de markt. De kennis wordt dus voortdurend uitgebreid en aangepast, en dit moet dan ook aangepast worden in de software. Bij pakketsoftware zit men hier weer vast, men is gebonden aan de aanpassingen van de softwareleverancier. Die zal ook wel in beperkte mate aanpassingen kunnen doorvoeren (eventueel op aanvraag van de klant) en een evolutief onderhoud kunnen aanbieden, maar dit zal nooit zo flexibel zijn als maatwerksoftware. De implementatie van aanpassingen bij pakketsoftware wordt meestal ook uitgevoerd door mensen van binnen de organisatie van de klant zelf, die niet altijd over voldoende technische kennis en opleiding beschikken om dat voor elkaar te krijgen. Pieterjan Donck & Dries Vanderhaeghen 12
Het lijkt erop dat maatwerksoftware een veel duurdere oplossing is dan pakketsoftware. Maar men dient ook op te letten met de onzichtbare kosten van pakketsoftware. De installatie zal waarschijnlijk wel vlotter verlopen dan maatwerk, maar omdat pakketten nooit 100% zullen overeenkomen met de bestaande werkmethodes, zal het personeel zijn werkwijzen aan de software moeten aanpassen. Dit kan tijdrovend, risicovol en kostbaar zijn. Maatwerk daarentegen zal op deze manier sneller geïmplementeerd kunnen worden omdat het net de bestaande werkwijzen zal ondersteunen en optimaliseren. Het is minder ingrijpend, en is op dat vlak eigenlijk goedkoper wanneer een grote organisatie met unieke bedrijfsprocessen voor pakketsoftware kiest. Een combinatie van pakketsoftware met maatwerk is evenwel ook mogelijk. De basis is dan een pakket waarbij er nog enkele ontbrekende functies moeten toegevoegd worden, of er kan gekozen worden uit een lijst van opties die voor het bedrijf het best van toepassing zijn. Bij de aanschaf van een pakket zijn er een aantal vuistregels die best in acht genomen worden: [15] Er dient op voorhand goed geïnformeerd te worden over de werking van de software. Eventueel demo s door de leverancier kunnen hier duidelijkheid brengen. De implementatie moet voorbereid worden, zowel in de vorm van technische testen als in de vorm van trainingen of instructiescenario s bij het personeel. De software wordt best getest met reële bedrijfsgegevens zodat men achteraf voor geen verrassingen komt te staan als de comptabiliteit, de performantie of de gebruiksvriendelijkheid niet aan de verwachtingen voldoet. Kies voor openheid tegenover de leverancier. Informatie zoals de import- en exportmogelijkheden, de externe programmeermogelijkheden, enz Die kunnen later altijd van pas komen bij integraties met andere software. Een softwarepakket dat nog maar net op de markt is (versie 1.0) houdt altijd meer risico s in dan een volwassen programma die zijn werking reeds bewezen heeft. De keuze van de leverancier is belangrijk. Dit moet een gezonde onderneming zijn die bovendien de klant centraal stelt. Om dit na te gaan kunnen er een paar referenties bezocht worden. Pieterjan Donck & Dries Vanderhaeghen 13
Indien voor maatwerk gekozen wordt, wordt er best op de volgende zaken gelet: Er wordt best een persoon aangesteld die dienst doet als buffer tussen de ontwikkelaars en de gebruiker. Dit kan een persoon van binnen eigen bedrijf zijn of een derde partij. Het ontwikkeltraject wordt zo in eigen belang op de voet gevolgd om onnodige kosten te vermijden die kunnen ontstaan door overbodige toeters en bellen in de software. Het project wordt best in blokken verdeeld om incrementeel te kunnen werken. Een te groot project heeft meer kans op fouten en falen. 2.3.2 Soorten software Niet elke soort software is even erg onderhevig aan veranderingen. We overlopen de belangrijkste soorten. Boekhoudsoftware is eigenlijk vrij statische software, maar is vaak onderhevig aan reglementaire wijzigingen. Dubbel boekhouden is een werkwijze die zeer algemeen is en zelfs deels wettelijk wordt vastgelegd. Optimalisatie kan eruit bestaan het efficiënter maken van bepaalde handelingen waardoor er tijdswinst ontstaat of foutieve ingaven verhinderd worden. De belangrijkste wijzigingen zullen evenwel meestal het gevolg zijn van wetswijzigingen zoals nieuwe BTW-aangifte, wettelijke documenten, verandering van RSZ-bijdragen, enz Software voor personeelsadministratie zal hoofdzakelijk in pakketten aangeboden worden. Machinesturing door software zal meestal via embedded systemen gebeuren. Hier zullen eventuele bugs nog gevoeliger liggen. De software zal ofwel aangeboden worden door de leverancier van de machines, ofwel op maat geschreven worden als de machines intern ontwikkeld en geoptimaliseerd worden. ERP-software ofwel Enterprise Resource Planning Software is een totaalpakket waar zo goed als alle bedrijfsprocessen in ondersteund worden. Het wordt meestal aangeboden in de vorm van een basispakket met de keuze uit een lijst voorgedefinieerde optionele modules. Deze software wordt talrijk aangeboden in de vorm van pakketsoftware. ERP als maatwerk zal ook wel mogelijk zijn maar zal zeer duur uitkomen wegens zijn complexiteit. Dan hebben we nog de software die door iedereen gebruikt wordt en meestal door grotere softwareleveranciers wordt gebouwd, zoals Adobe, Macromedia, Microsoft, enz Dit zijn gevestigde waarden. Er is een massale publieksafname en voorstellen tot Pieterjan Donck & Dries Vanderhaeghen 14
wijzigingen zullen meestal enkel en alleen door de leverancier genomen worden. Die heeft alle macht in handen. Software die onder deze categorie valt is: ontwikkelingssoftware, kantoorsoftware, veiligheidssoftware, educatieve software, 2.4 Soorten onderhoud 2.4.1 Correctief of curatief onderhoud Software is nooit 100% foutloos en bevat dus zogenaamde bugs. Die kunnen de software desgevallend ongeschikt maken voor correct gebruik. Om de klant in staat te stellen zijn software in de beste omstandigheden te gebruiken is het nodig bugs tijdig en snel te herstellen. Het herstel kan bestaan uit een daadwerkelijke oplossing van een gebrek (zoals een rekenfout), maar ook bestaan uit een workaround. In het laatste geval wordt de fout vermeden of wordt een omzeiling van het probleem uitgevoerd (b.v. berekeningen die teveel tijd vragen door slechte programmering). Eén van de moeilijkheden waarmee de contractpartijen geconfronteerd worden is de correcte definitie van deze gebreken. Door gebreken te restrictief definiëren (b.v. door te verwijzen naar een afwijking van de technische specificaties) ontstaat het risico dat de klant geblokkeerd geraakt wanneer een gebrek optreedt dat niet beantwoordt aan de beperkte definitie opgenomen in het contract. Vaak is het niet duidelijk of een functionele tekortkoming al dan niet als een gebrek moet worden aanzien. Het is daarom aan te bevelen om een definitie van een gebrek op te nemen in de aard van elke afwijking die verhindert dat het programma resultaten oplevert conform aan de contractueel voorziene functies. De partijen zullen vooraf de functies moeten definiëren voor het programma. 2.4.2 Adaptief of aanpassingsonderhoud Het adaptief onderhoud heeft tot doel de software aan te passen aan nieuwe vereisten van externe oorsprong, met andere woorden niet door de klant zelf veroorzaakt. De nieuwe vereisten die een aanpassing van de software nodig maken kunnen zowel van technische aard zijn (evolutie van de gebruikte technologie, wijzigingen aan de hardware, ), als van reglementaire aard (evolutie van de fiscale, sociale of boekhoudwetgeving, BTW, ). Dit onderhoud is voornamelijk een noodzaak in een sector die gevoelig is voor dergelijke veranderingen. (zoals boekhoudkantoren, sociale secretariaten, ). Die klanten moeten praktisch onmiddellijk over up-to-date software kunnen beschikken. Voor klanten Pieterjan Donck & Dries Vanderhaeghen 15
in sectoren die minder onderhevig zijn aan zulke aanpassingen, is het eerder een sporadische noodzaak. Gebeuren die aanpassingen regelmatig, dan wordt dit best op voorhand afgesproken. Dit kan als aanvulling op het standaardcontract in functie van regelmatig verwachte aanpassingen. 2.4.3 Evolutief of perfectief onderhoud Een derde soort onderhoud is het evolutief onderhoud. In tegenstelling tot het aanpassingsonderhoud, behelst dit type onderhoud wijzigingen die ontstaan als gevolg van nieuwe noden van de klant, andere dan (externe) van technische of reglementaire aard. Deze wijzigingen kunnen zeer uiteenlopend zijn, over het algemeen zijn dit wijzigingen in bedrijfsprocessen zoals nieuwe manier van stockbeheer, leveringen, databases, De wijzigingen worden meestal gevraagd door de klant. Voor de klant die afhankelijk is van zijn softwareleverancier is het belangrijk dat er in het onderhoudscontract opgenomen wordt dat de softwareleverancier dergelijke gevraagde aanpassingen zal doorvoeren. Aangezien de gevraagde aanpassingen zowel minieme ingrepen kunnen zijn als zware inspanningen, is het aangeraden om een prijszetting te voorzien die flexibel genoeg is elke situatie op een positieve manier te kunnen opvangen. Pieterjan Donck & Dries Vanderhaeghen 16
3 Informaticarecht Beheer van softwareonderhoudscontracten is een onderdeel van het IT beleid dat de laatste decennia in complexiteit sterk is toegenomen. Vaak worden daarbij Engelse termen gehanteerd die onduidelijkheid veroorzaken en conflicten tussen partijen kunnen veroorzaken. In principe bestaat er niet zoiets als informaticarecht. Toch is er in het laatste decennium heel wat wetgeving ontstaan die specifiek slaat op IT. Daarvoor had men geen andere keuze dan beroep te doen op bestaande wetgeving, meestal burgerrecht. Door het eigen karakter van de informatietechnologie is dit niet altijd vanzelfsprekend en soms zelfs onvoldoende. 3.1 Levering en garantie 3.1.1 Leveringsfase Bij de verkoop, verhuur of leasing van software komt er steeds een moment van levering. Levering is de terbeschikkingstelling van het voorwerp aan de klant, zodat gebruik mogelijk wordt overeenkomstig het doel ervan. Naast de levering als hoofdverplichting, kan men aanvullende verbintenissen in het contract opnemen zoals installatie, in werking stellen, integratie, documentatie, De geleverde software dient conform te zijn aan de overeengekomen specificaties onder andere over de prestatiekenmerken om zo de klant te geven wat hij verwachtte. De conformiteit wordt nagegaan door te testen en vervolgens te aanvaarden. Men spreekt in die zin dan ook over acceptatietesten. Er wordt een onderscheid gemaakt tussen: de voorlopige aanvaarding, en de definitieve aanvaarding. Via deze praktijk, die duidelijk uit de bouwwereld afkomstig is, tracht men zichtbare gebreken vast te stellen door te testen. Pieterjan Donck & Dries Vanderhaeghen 17
3.1.2 Garantiefase Wanneer de leveringsfase voorbij is, gaat men over naar de garantiefase. Men maakt onderscheid tussen twee soorten garantie: De wettelijke garantie De conventionele garantie De wettelijke garantie in een contract van verkoop en aanneming van een goed, is een vrijwaring voor verborgen gebreken. Burgerlijk wetboek art.1641 e.v. : De verkoper moet het goed vrijwaren tegen verborgen gebreken, die het ongeschikt maken voor het gebruik waartoe men ze bestemt, of het gebruik ervan zodanig zou verminderen dat men het goed aan een lagere prijs of totaal niet zou gekocht hebben. Een duidelijke wettelijke garantie bestaat slechts voor een contract van verkoop en aanneming. Voor alle andere contracten, waaronder IT-contracten, waarvoor wettelijke garantie meestal als onvoldoende geacht wordt, kunnen de partijen een conventionele garantie overeenkomen. De conventionele garantie biedt de mogelijkheid tot beperking van de wettelijke garantie. Hier wordt handig gebruik van gemaakt door de softwareleverancier, bijvoorbeeld door bepaalde wijzen van herstel voor te schrijven en andere uit te sluiten, of de verplichting om binnen een bepaalde termijn klacht in te dienen, enz De conventionele garantie dekt normaalgezien slechts de periode tussen de definitieve aanvaarding en de inwerkingtreding van het onderhoudscontract. Daarom is het zeer belangrijk dat de partijen het aanvangstijdstip en de duur van de conventionele garantie vastleggen. 3.1.3 Onderhoudscontractfase Vanaf het moment dat de afgesproken garantietermijn vervalt, kan een onderhoudscontract verdere verzekering bieden. Het onderhoudscontract kan echter ook al aangegaan worden terwijl de garantieperiode nog loopt. Dit om mogelijke problemen op te lossen die niet onder de garantie vallen. De garantie kan namelijk conventioneel beperkt worden tot welbepaalde problemen. Pieterjan Donck & Dries Vanderhaeghen 18
Als de garantie inderdaad beperkt wordt kan het aanbevolen zijn om reeds een onderhoudscontract aan te gaan tijdens de garantieperiode. Er kan echter ook onderhandeld worden over het bereik van de conventionele garantie. 3.2 Industriële eigendomsrechten 3.2.1 Belgische octrooiwet (wet van 28 maart 1984 op de uitvindingoctrooien) De octrooiwet zorgt voor een tijdelijk monopolierecht van exploitatie. De belangrijkste voorwaarde is dat het moet gaan over iets nieuws. Een octrooi beschermt oorspronkelijk enkel technische uitvindingen. Software kan sinds 1985 ook beschermd worden, mits het een technisch karakter heeft. Dit zijn echter uitzonderingen. Software wordt in principe beschermd door het auteursrecht. 3.2.2 Het auteursrecht Het auteursrecht geldt als het werk oorspronkelijk is en in een bepaalde vorm is gegoten. Oorspronkelijk moet hier bekeken worden als de vrucht van een intellectuele inspanning. Het werk bestond nog niet. In een bepaalde vorm gegoten betekent de materialisatie van het werk. Voor een boek zijn dat de gedrukte bladzijden, voor software zijn dat de regels code. Dit staat los van het idee dat aan de oorsprong ligt van het werk. Een idee alleen kan dus niet beschermd worden. Het auteursrecht beschermt enkel de vormgeving of de uitdrukkingswijze van het werk, dus geen nieuwe uitvinding of ideeën. De softwarebouwer wordt beschouwd de auteur en eigenaar te zijn van de ontwikkelde software. Als een opdrachtgever eigenaar wil worden van software dat hij heeft laten ontwikkelen, bijvoorbeeld bij een softwareontwikkelingcontract, is er een mogelijkheid om het vermogensrecht over te dragen. 3.2.3 Het vermogensrecht Vermogensrechten zijn in geld waardeerbaar, in tegenstelling tot morele rechten. We kunnen een onderscheid maken tussen exclusieve rechten: reproductierecht en recht op mededeling aan het publiek. Pieterjan Donck & Dries Vanderhaeghen 19