Onderzoek naar de asymmetrie van informatie bij het afsluiten en uitvoeren van softwareonderhoudscontracten

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


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


IV

Gebruikte symbolen en afkortingen IT

Informatietechnologie

ICT

Informatie- en Communicatietechnologie

KMO

Kleine en middelgrote onderneming

ERP

Enterprise Resource Planning

PIH

Provinciale Industriële Hogeschool


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


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”.


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. dubbelzinnige

Het

onderhoudscontract

omschrijvingen

door

mag

advocaten

geen

verzameling

zijn

van

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.


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

hardwareonderhoudscontracten

omwille

wellicht van

de

nog

vaker

specialistische

afgesloten kennis

van

dan 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.


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.


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


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.


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.


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 Vanaf

Onderhoudscontractfase het

moment

onderhoudscontract

dat

de

afgesproken verdere

garantietermijn

vervalt,

kan

verzekering

een

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.


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.


19

vergoedingsrechten: vergoeding indien het werk gereproduceerd wordt zonder de toestemming van de auteur

Overdracht van vermogensrechten is mogelijk volgens 6 principes: 1. De overdracht moet vastgelegd worden in een schriftelijke overeenkomst. 2. Er moeten vermeldingen voorkomen die de overeenkomst nietig kunnen maken. 3. De overeenkomst wordt restrictief in het voordeel van de auteur geïnterpreteerd. 4. De exploitatie van de overgedragen rechten is onderworpen aan de vereiste van naleving van de eerlijke beroepsgebruiker. 5. Er mag geen overdracht geschieden voor toekomstige, nog onbekende exploitatievormen. 6. De overdracht van de rechten betreffende toekomstige werken wordt beperkt. De auteur kan niet alle rechten op al zijn toekomstige werken overdragen.

3.2.4

De softwarewet

Aangezien de originele auteurswet moeilijk toepasbaar bleek op software, werd door Europa

de

softwarerichtlijn

goedgekeurd

op

14

mei

1991.

In art.10 moesten de Lidstaten uiterlijk op 31 december 1992 de nodige wettelijke en administratieve bepalingen in werking doen treden om aan deze richtlijn te voldoen. Hieruit volgde de Belgische wet van 30 juni 1994 betreffende de bescherming van computerprogramma’s, ook de softwarewet genoemd. Artikel 5 van de softwarewet: Het distributierecht Controle

van

distributie

is

slechts

mogelijk

voor

de

eerste

publieke

kopie.

Vanaf dan kan de auteurshebbende enkel nog controle uitoefenen op de verdere verhuring van die kopie. Een verhuring betekent een licentie van beperkte tijdsduur en tegen vergoeding. Artikel 6 van de softwarewet: Het recht van de gebruiker om zonder toestemming van de auteur het programma te reproduceren en aan te passen. Dit recht is echter enkel toegestaan in zoverre het noodzakelijk is om het beoogde doel van de software te bereiken, maar hier kan contractueel van afgeweken worden! Het recht is weliswaar ook beperkt tot handelingen noodzakelijk voor het beoogde gebruik van de software.


20

3.3 De informatieplicht De informatieplicht is beschreven in artikel 30 van de wet van 14 juli 1991 betreffende de handelspraktijken.

Ten laatste op het ogenblik van het sluiten van de verkoop moet de verkoper te goeder trouw aan de consument de behoorlijke en nuttige voorlichting geven betreffende de kenmerken van het product of de dienst en betreffende de verkoopsvoorwaarden, rekening houdend met de door de consument uitgedrukte behoefte aan voorlichting en rekening houdend met het door de consument meegedeelde of redelijkerwijze voorzienbare gebruik. De verplichting tot het geven van informatie ligt dus bij de verkoper, terwijl de consument schuldeiser is van de informatie. Een contract komt tot stand bij het formuleren van een aanbod en een aanvaarding hiervan. Deze acties mogen mondeling of schriftelijk gebeuren om door de wet als “contract” beschouwd te worden, maar bij informatietechnologie zijn contracten te uitgebreid om mondeling te gebeuren. Bij onjuiste of een gebrek aan informatie bij het formuleren van het aanbod kan de handelaar aansprakelijk gesteld worden voor geleden schade. Er moet dan wel aangetoond worden dat men met correcte informatie geen contract zou aangegaan zijn of op zijn minst het contract zou overeengekomen zijn met andere voorwaarden. De handelaar kan in verschillende vormen onderhevig zijn aan de informatieplicht. Enerzijds is er, zoals net besproken, de plicht om de juiste informatie te verwerven in overeenstemming met zijn product. Anderzijds is de handelaar ook verplicht om een werk te weigeren of een ander voorstel te doen indien hij weet dat het werk onvoldoende zou zijn, geen soelaas zouden bieden of voor moeilijkheden zou zorgen bij de klant.


21

4 Probleemstelling 4.1 A market for lemons “The market for lemons” is een paper in 1970 geschreven door George Akerlof [18]. Daarin worden de fundamenten van de asymmetrische informatietheorie beschreven. Akerlof, professor aan de Universiteit van Californië, won hiervoor de Nobelprijs voor Economie in 2001. De paper beschrijft hoe het verband tussen verscheidenheid in kwaliteit en asymmetrische informatie kan leiden tot het ineenstorten van een markt. In dit model veronderstelt men dat de kwaliteit van het product onbekend is bij de koper te wijten aan asymmetrische informatie. Dit is een stimulans voor de verkoper om een product van lage kwaliteit (citroenen in plaats van appelen) te verkopen in plaats van een hoger kwaliteitsproduct. De rationele koper echter gaat de kwaliteit gemiddeld inschatten, waardoor de producten die boven de gemiddelde kwaliteit zitten, uit de markt gedreven worden. Hierdoor ontstaat een nog lager gemiddelde kwaliteit. Dit mechanisme kan zich herhalen tot de markt ophoudt te bestaan. De softwaremarkt met bijhorende serviceverlening via onderhoudscontracten is een typisch voorbeeld van een markt met asymmetrische informatie. De klant, in het bijzonder de KMO, heeft dikwijls onvoldoende technische kennis om de kwaliteit van een softwarepakket met contract in te schatten. De softwareleverancier beseft dit maar al te goed, hij zit namelijk op een hoger maturiteitsniveau. Klanten durven vaak geen wijzigingen in het contract vragen omdat ze eenvoudigweg niet op de hoogte zijn van de mogelijkheden in hun voordeel.

4.2 Principaal-agent probleem Het Principaal-agent probleem is een economische theorie over de verhoudingen en transacties tussen economische partners in een omgeving van onvolledige en asymmetrische informatie. We beschouwen twee partijen (vb. leverancier-klant) met ongelijke macht en verschillende interesses of doelstellingen.


22

De principaal (=opdrachtgever, klant) wil een doel bereiken en sluit hiervoor een contract af met één of meerdere agenten (=opdrachtnemer, leverancier) om tegen een bepaalde vergoeding een opdracht uit te voeren. Deze theorie lijkt een waardevol raamwerk te geven in situaties van vele KMO’s die zich vaak noodgedwongen moeten beroepen op outsourcing voor de implementatie van hun informatiesysteem.

KMO’s

worden,

in

tegenstelling

tot

grote

bedrijven,

vaak

geconfronteerd met hoge kosten om het verloop van IT-projecten te monitoren. IToplossingen zijn immers zeer moeilijk te observeren in kwantificeerbare eenheden. De oorzaak van het feit dat KMO’s vaak minder onderlegd zijn op het vlak van IT, is omdat het management ook meestal weinig prioriteit geeft aan IT. KMO’s zijn hierdoor slecht geïnformeerd over IT-oplossingen en zijn aanbieders. Prijsaanbiedingen van IToplossingen kunnen sterk variëren en kunnen tot zelfs een tienvoud uiteenlopen voor dezelfde diensten. Het basisprincipe van de principaal-agent theorie is dat de principaal zich niet op hetzelfde kennisniveau bevindt als de agent. Die verscheidenheid van kennisniveau is immers de reden van outsourcing. Het is precies omdat de agent iets weet of kan, dat er beroep gedaan wordt op hem door de principaal. Voorbeelden van principaal-agent situaties:

Verzekeringsmaatschappijen en verzekerden: de verzekeringsmaatschappij kan niet controleren hoeveel zorg de verzekerde uitgeoefend heeft.

Banken en leners: De bank kan niet controleren of het geld wel besteed wordt aan het beoogde doel ervan.

Fabrikant en verdelers: De fabrikant is niet in staat om de marktcondities te observeren die de distributeur waarneemt.

Automecanicien en klant: De klant heeft geen idee hoe lang de reparatie van de wagen geduurd heeft, de mecanicien kan meer werkloon aanrekenen.

Softwareonderhoud: De klant weet niet of hij de juiste prijs betaalt voor het onderhoud. Hoe foutloos is de software? Vallen alle problemen onder het onderhoudscontract? Zal er niet extra moeten betaald worden?

We nemen drie hypothesen aan: Hypothese 1: Partijen hebben meestal tegengestelde belangen. De principaal en de agent streven daarom naar verschillende doelstellingen en beschikken bovendien niet Pieterjan Donck & Dries Vanderhaeghen

23

over dezelfde informatie. De principaal weet niet altijd hoe de agent zal beslissen in bepaalde situaties. De agent zal eerder beslissingen nemen in eigen voordeel. Hypothese 2: De partijen handelen rationeel. In de economie betekent dit dat elke partij zijn eigen kosten zo laag mogelijk en de opbrengsten zo hoog mogelijk zal houden. Hypothese 3: Het resultaat dat de principaal wil bereiken door toedoen van de agent zal steeds medeafhankelijk zijn van toeval. Omdat het succes van IT-projecten niet objectief kan bepaald worden zijn er dus onzekere factoren die meespelen. We veronderstellen daarbij dat de principaal risiconeutraal is (de risico’s zijn gekend en er wordt rekening mee gehouden) en de agent risico-avers is (risico’s worden vermeden). Tussen de principaal en agent wordt nu een contract afgesloten. Het probleem dat zich hier voordoet is dat elke partij streeft naar een optimaal contract in eigen belang. De principaal wil juist genoeg betalen om te bekomen wat hij wil van de agent. Met een optimaal contract wordt bedoeld dat beide partijen hun belangen maximaliseren en er geen ongewenste neveneffecten ontstaan. Met behulp van econometrie kan men nu aantonen dat een optimaal contract slechts mogelijk is in de situatie waarbij principaal en agent volledig en gelijk geïnformeerd zijn over de uitvoering van de opdracht. KMO’s bevinden zich jammer genoeg niet in deze situatie. Er is onvolledige informatie tussen de partijen en hierdoor kan geen optimaal contract afgesloten worden. In een dergelijk geval van onvolledige en asymmetrische informatie ontstaat er opportunistisch gedrag of moreel risico (moral hazard). In de principaal-agent relatie met asymmetrische informatie kunnen zich nu twee fundamentele problemen voordoen: 1. Verborgen informatie Ook gekend als tegenovergestelde keuze of adverse selection. (ex ante) Wanneer de principaal onvoldoende informatie heeft over de kwaliteit van het geleverde of te leveren werk van de agent, zal die misschien een goedkopere agent kiezen. Mogelijks bevinden we ons dan op een markt van citroenen (zie hoger). In een dergelijke markt zien we dat de slechte leveranciers de goede uit de markt duwen. Bovendien zal als de compensatie van de agent door de principaal niet hoog genoeg is, de agent mogelijks andere dingen doen waar meer mee te verdienen valt. De principaal zit dan opgezadeld met een ondermaats presterende agent. Pieterjan Donck & Dries Vanderhaeghen

24

Verborgen informatie is de basis van de “Market For Lemons” (G. Akerlof). In een dergelijk geval is het aangeraden voor de eerlijke leverancier om zich uit die markt terug te trekken. Aanbiedingen met faire maar mogelijks hoge prijzen, die overeenkomen met hoge kwaliteit, maken niet veel kans op succes. De klant of principaal is zich vaak niet bewust dat hij zich op een citroenenmarkt begeeft. 2. Verborgen acties Dit is gekend als morele risico’s of moral hazard. (ex post) De principaal kan door het gebrek aan informatie niet controleren hoe hard de agent werkt. Hij is beperkt in controlemogelijkheden en zal enkel maar de directe output kunnen meten. Hij is ook niet zeker of de agent zich wel optimaal inzet voor het werk waarvoor hij betaald wordt. Omdat de agent weet dat hij niet kan geobserveerd worden, zal hij misschien andere keuzes maken die meer in zijn eigen voordeel gaan dan in het belang van de principaal. Het contract zal dus niet de exacte acties kunnen beschrijven met de daaraan gekoppelde compensaties. De principaal kan immers niet controleren of die acties daadwerkelijk wel verricht werden. Daarom moet het contract zo opgesteld worden zodat de agent aangespoord wordt om de correcte acties uit te voeren. De principaal heeft nu twee mogelijkheden om het resultaat van de agent bij te sturen of morele risico’s tegen te gaan. 1. Behavior-based contract De principaal kan het gedrag van de agent laten monitoren en belonen op basis van geleverde prestaties. Er zal een derde persoon moeten ingehuurd worden, de monitor of supervisor die de principaal rapporteert over het gedrag van de agent. De rapporteringen van de monitor zijn wel gekend bij beide partijen. 2. Outcome-based contract De principaal kan de agent belonen op basis van het behaalde resultaat. Maar omdat de principaal onvoldoende kennis heeft om het resultaat objectief te evalueren, zal er opnieuw beroep moeten gedaan worden op een derde partij.


25

Beide contracten vereisen dat de principaal in de kosten gaat. Deze kost wordt de monitoring kost genoemd.

4.3 Conclusie De principaal-agent theorie toont aan dat er een noodzaak is om een goed contract op te stellen. Specifiek in het geval van onderhoudscontracten en KMO’s kunnen we concluderen dat we met asymmetrie van de informatie te maken hebben. De principaal zal dan ook een prijs behoren te betalen om een goed contract te kunnen afsluiten. Om deze kosten te drukken willen we middels dit werk wat meer inzicht verschaffen aan de principaal nopens de natuur van softwareonderhoudscontracten.


26

5 Bestaande studies 5.1 UKSMA & ISBSG Maintenance en Support Measurement Manual (United Kingdom Software Metrics Association & International Software Benchmarking Standards Group) 5.1.1

Inleiding

UKSMA [9] is een organisatie die als doel heeft het correcte gebruik van softwaremetingen in een organisatie te bevorderen. Om deze doelstelling tot een goed einde te brengen publiceert UKSMA standaarden voor het meten van diverse aspecten van softwareactiviteiten. In de naleving van de doelstelling heeft het comité voor het meten in de praktijk de behoefte aan standaardmaatregelen, geassocieerd aan onderhoud en ondersteuning van operationele software, erkend. Namens de raad van UKSMA heeft het comité voor het meten in de praktijk de opdracht gekregen deze standaard te ontwikkelen. ISBSG is een non-profit organisatie. Een van hun doelstellingen is het verbeteren van softwareontwikkeling door gestandaardiseerde en relevante gegevens te verstrekken aan de industrie. Om dit doel te ondersteunen werd beslist om het toepassingsgebied van de gegevens uit te breiden. Om aan deze behoefte te voldoen heeft het bestuur van ISBSG beslist een databank te ontwerpen en te onderhouden betreffende onderhouds- en ondersteuningsactiviteiten. De huidige situatie is dat het meten van onderhouds- en ondersteuningsprestaties een zwak punt is in IT. Er bestaat geen eensgezindheid omtrent welke prestatiemetingen er verzameld moeten worden. Alsook is het weinig gegarandeerd dat de verzamelde metingen overeenstemmen met andere organisaties. Hieruit blijkt dat het moeilijk, al dan niet onmogelijk, wordt om een vergelijking te maken tussen prestaties van organisaties. Daarnaast hebben de managers nood aan begeleiding omtrent welke prestaties er moeten gemeten worden om hen toe te staan hun afdelingen te controleren.


27

5.1.2

De benadering

De huidige benadering is gebaseerd op een model van onderhoud en ondersteuning die onderscheid maakt tussen ontwikkeling, onderhoud, ondersteuning en computer verrichtingen. Onderhoud en ondersteuning zijn de gebieden die volgens het model moeten bewaard worden. Deze bevatten zowel kleine aanpassingen als oplossingen voor fouten en dagelijkse aanpassingen. Het onderscheid tussen kleine en grote aanpassingen varieert van organisatie tot organisatie. De auteurs zijn hun ervan bewust dat in de ene organisatie 80 werkdagen gezien wordt als onderhoud terwijl daarvoor maar 5 werkdagen voorzien is in een andere organisatie. Aanvankelijk wordt door het UKSMA en ISBSG vooropgesteld dat 5 dagen of minder zal gezien worden als onderhoud. Deze veronderstelling zal getest worden in bespreking met de industrie en andere geïnteresseerde partijen.

Figuur 1: Het ISBSG model van ondersteuning en onderhoud op activiteiten gebaseerd.


28

Figuur 2: Het UKSMA model van onderhoud en ondersteuning

Aan de hand van voorgaande figuren zien we dat er een overeenkomst is tussen beide figuren. Dit heeft het UKSMA en ISBSG aangezet om hun inspanningen te bundelen. De volgende stap was het ontwerpen van een onderhouden ondersteuningsmodel dat vragen omtrent basismaatregelen, zoals aantal personeelsleden dat wordt toegewezen aan een applicatie, zou kunnen beantwoorden.

Kosten à

Kosten voor error resolution

à

Kosten per onderhouden en ondersteund functiepunt

Efficiëntie à

Onderhouden en ondersteunde functiepunten per persoon

à

Vaste tekorten door strengheid per persoon per jaar

à

Ondersteuningsvragen per persoon per jaar

à

Aantal ondersteunde applicaties per persoon per jaar

Klantendienst à

Klantentevredenheid


29

à

Systeem beschikbaarheid

à

Turn around time: Tijd nodig om te herstellen

à

Occurrence rate: Tijd tot mislukking

Figuur 3: Het metrisch model van onderhoud en ondersteuning

5.1.3

Te verwachten resultaten

Als resultaat van de verzamelde metingen zullen ISBSG-databasegebruikers de onderstaande vragen kunnen beantwoorden:

Zijn we te duur?

Zijn we snel genoeg?

Zijn de processen efficiënt?

Houden we de klanten tevreden met onze service?

Verbeteren we deze factoren in de tijd?

De mogelijkheid om op deze vragen te beantwoorden geeft de IT-manager de mogelijkheid hun onderhouden ondersteuningsfuncties te beheren. In vele organisaties waar het onderhouden en ondersteunen uitgegeven wordt, krijgen ze de mogelijkheid om hun onderhouden ondersteuningsprestaties te vergelijken en zo zeker te zijn of ze waar krijgen voor hun geld.

5.1.4

Metingen in detail

Onderstaande lijst bevat de vooropgestelde metingen die jaarlijks verzameld zullen worden bij de bijdragende bedrijven om de gegevensreeks op te stellen. De metingen worden opgedeeld in volgende secties:

De voorpagina

Eens per organisatie

Eens per aanvraag die wordt ingediend


30

De voorpagina De eerste metingen die moeten worden vermeld zijn deze die als deel van de voorpagina worden verzameld. Dit zal worden verwijderd om de vertrouwelijkheid van de organisatie te bewaren. Dataveld:

Naam organisatie

Dataveld:

Contactnaam

Dataveld:

Adres

Dataveld:

Telefoonnummer of contactnummer

Dataveld:

Faxnummer

Dataveld:

Emailadres

Dataveld:

Datum voorgelegd

Hieronder bevindt zich de data die opgenomen wordt in de ISBSG gegevensbank. Een deel van die gegevens wordt gebruikt om toegang te verlenen tot de verstrekte data. Ieder dataveld wordt begeleid met een definitie en een invloedsverklaring. De invloedsverklaring is een indicatie van welke invloed dat verwacht wordt bij het lezen van een onderhoudsinspanning en de kosten ervan. Eens per organisatie De volgende gegevens worden maar eens per organisatie verzameld. UKSMA en ISBSG voorziet dat veel organisaties hun onderhouden ondersteuningsfunctie wensen te benchmarken. Hoe dan ook kan de database ook gebenchmarkte “single” applicaties aanvaarden. In het laatstgenoemde kan het zijn dat organisaties geen brede gegevens willen verstrekken niettemin worden de organisaties aangemoedigd dit wel te doen. Dataveld:

Startdatum van benchmarkperiode

Dataveld:

Einddatum van benchmarkperiode

Dataveld:

Totale inspanning besteed aan perfectief onderhoud.

Definitie: Perfectief onderhoud zijn de activiteiten zoals gedefinieerd in de verklarende woordenlijst. De inspanning is normaal uitgedrukt in voltijds equivalente personeelsjaren. Impact:

Geen


31

Dataveld:

Totale inspanning besteed aan preventief onderhoud.

Definitie: Preventief onderhoud zijn de activiteiten zoals gedefinieerd in de verklarende woordenlijst. Men erkent dat het bundelen van deze activiteiten goed is voor regressie, integratie en het testen of gebruikers dit accepteren. Impact: Dataveld:

Geen Totale inspanning besteed aan correctief onderhoud.

Definitie: Correctief onderhoud zijn de activiteiten die fouten oplossen. In de verklarende woordenlijst vindt je een volledige definitie. Impact: Dataveld:

Geen Totale inspanning besteed aan adaptief onderhoud.

Definitie: Adaptief onderhoud zijn de activiteiten die de functionaliteit van de applicatie beïnvloeden. Impact: Dataveld:

Geen Totale inspanning voor het onderhoud van de organisatie.

Definitie: Dit is de som van de vier voorgaande velden en is bedoeld om organisaties toe te staan hun inspanningen te registreren waar geen onderscheid

gemaakt

wordt

tussen

de

verschillende

onderhoudsactiviteiten. Impact: Dataveld:

Geen Inspanning besteed aan probleemonderzoek voor de organisatie.

Definitie: Dit is de steunactiviteit van probleemonderzoek die wordt uitgevoerd om te bepalen of een gemeld probleem in feite een toepassingsfout, een fout in de gebruikersdocumentatie, een fout in de opleiding of


32

een gebruikersfout is. Impact: Dataveld:

Geen Inspanning besteed in het geven van advies en hulp aan gebruikers.

Definitie: Dit is de steunactiviteit in het voorzien van hulp en advies aan gebruikers. Impact: Dataveld:

Geen Inspanning besteed aan vragen en snelle diensten.

Definitie: Dit is het beantwoorden van simpele ad hoc vragen en het verstrekken van diensten. Impact: Dataveld:

Geen Totale inspanning voor het geven van steun aan de afdeling.

Definitie: Dit is de som van de twee voorgaande velden en is bedoeld om organisaties toe te staan hun inspanningen te registreren waar geen onderscheid gemaakt wordt tussen de verschillende steunactiviteiten. Impact: Dataveld:

Geen Totale inspanning voor onderhoud en steun aan de afdeling.

Definitie: Dit is de som van dataveld 5 en 8 en is bedoeld om organisaties toe te staan hun inspanningen te registreren waar geen onderscheid gemaakt

wordt

tussen

de

verschillende

steun-

en


Geen Volledige grootte van het steunen onderhoudsteam.

Definitie: Het aantal fulltime personeelsleden opgesteld voor de steunen


33

onderhoudsactiviteiten in het gemeten deel van de organisatie. Impact: Dataveld:

Geen Totaal aantal applicaties in hun portfolio.

Definitie: Dit is het totaal aantal van alle applicaties uit de portfolio van de afdeling of organisatie die de gegevens voorlegt. Impact:

Hoe hoger het aantal applicaties, hoe hoger de verwachte kosten en hoe lager de verwachte onderhoudsproductiviteit kan zijn.

Dataveld:

Grootte van hun portfolio.

Definitie: De totale grootte van alle toepassingen in de organisatie die gemeten wordt. De grootte zou moeten uitgedrukt worden in één van de gedefinieerde methodes geaccepteerd door het ISBSG. Impact:

Hoe hoger het aantal applicaties, hoe hoger men de kosten verwacht. Dit zal één van de metingen zijn die gebruikt worden om vergelijkingen te trekken. Aldus zal het mogelijk zijn om conclusies te trekken

betreffende

het

aantal

personeelsleden

per

1000

functiepunten, de onderhoudsinspanning per 1000 functiepunten, enz. Dataveld:

Aantal gewerkte uren per voltijds personeelsjaar.

Definitie: Dit is het aantal uren dat een fulltime personeelslid uit de onderhouds- en ondersteuningdienst werkt in een compleet jaar. Deze meting zal men gebruiken om gegevens te normaliseren en zo vergelijkingen te maken. Impact: Dataveld:

Geen Aantal gebreken per jaar.

Definitie: Het totaal aantal gebreken in elke categorie, per jaar per organisatie, van de verzamelde gegevens. De categorieën zijn deze die erkend Pieterjan Donck & Dries Vanderhaeghen

34

zijn door het ISBSG en gedefinieerd zijn in het UKSMA Defect Reporting Standard. Impact:

Hoe hoger deze meting, hoe hoger de verwachte onderhoudskost zal zijn. Dit is een andere meting die zal toestaan om een vergelijking te maken zoals het aantal gebreken per 1000 functiepunten, het aantal gebreken per werkuur, enz.

Dataveld:

Aantal oproepen.

Definitie: Dit is het aantal oproepen naar de helpdesk gedurende het jaar. Impact:

Hoe hoger het aantal oproepen, hoe hoger de verwachte en vereiste inspanning en kost zal zijn.

Dataveld:

Klanten tevredenheid.

Definitie: We zoeken een ja of nee om te bevestigen of een onderzoek wordt gebruikt. Impact:

De impact van deze meting is niet zo duidelijk. Men zou kunnen verwachten

dat

een

hoge

gebruikerstevredenheid

op

een

probleemvrije omgeving zou duiden. Dataveld:

Bedrijfssector.

Definitie: De bedrijfssector waarin de organisatie hoofdzakelijk betrokken is. Impact:

Er is geen duidelijke impact, nochtans is er in de ISBSG database een onderlinge

samenhang

tussen

de

bedrijfssector

en

de

ontwikkelkosten. Dit zou een gelijkaardige verhouding tevoorschijn kunnen brengen bij voldoende gegevens.


35

Eens per applicatie die wordt voorgelegd De volgende gegevens zullen verzameld worden uit iedere applicatie in de portfolio die voorgelegd wordt. In een grote organisatie is het aantal applicaties enorm. Bijgevolg adviseert het ISBSG dat slechts tien applicaties zouden gemeten worden. De applicaties zouden zo gekozen moeten worden dat er een representatief voorbeeld van het type applicaties van de organisatie gegeven wordt. Dataveld:

Naam van de applicatie

Dataveld:

Type applicatie

Definitie: Dit

identificeert

het

type

applicatie

waarop

de

steun-

en

onderhoudsactiviteiten zijn gericht. Voorbeeld: informatiesystemen, procescontrole, enz. Impact:

Er is geen merkbare impact, nochtans lijkt het er op dat complexe applicaties meer onderhoudsinspanning vergt.

Dataveld:

Leeftijd van de applicatie.

Definitie: De leeftijd van de applicatie is het aantal jaar sinds de lancering van de applicatie. Impact:

In het algemeen blijkt dat hoe ouder een applicatie hoe groter de onderhoudsinspanning is om het draaiende te houden.

Dataveld:

Bedrijfssector.

Definitie: Dit wordt gebruikt als indicator van de bedrijfssector waarin de software werkt. Impact: Dataveld:

Geen Grootte van de applicatie

Definitie: De grootte zou moeten uitgedrukt worden in één van de gedefinieerde methodes geaccepteerd door het ISBSG.


36

Impact:

De

applicatiegrootte

is

een

belangrijke

factor

in

de

onderhoudsinspanning, hoe groter de applicatie, hoe groter de onderhoudskost. Dataveld:

Totale inspanning besteed aan perfectieve onderhoudsactiviteiten

Definitie: Perfectieve

onderhoudsactiviteiten

zijn

deze

activiteiten

zoals

gedefinieerd in de verklarende woordenlijst. De inspanning is normaal uitgedrukt in voltijds equivalente personeelsjaren. Impact: Dataveld:

Geen Totale inspanning besteed aan preventieve onderhoudsactiviteiten

Definitie: Preventieve

onderhoudsactiviteiten

zijn

deze

activiteiten

zoals

gedefinieerd in de verklarende woordenlijst. Men erkent dat het bundelen van deze activiteiten goed is voor regressie, integratie en het testen of gebruikers dit accepteren. Impact: Dataveld:

Geen Totale inspanning besteed aan correctieve onderhoudsactiviteiten .

Definitie: Correctief onderhoud zijn de activiteiten die fouten oplossen. In de verklarende woordenlijst vindt je een volledige definitie. Impact: Dataveld:

Geen Totale inspanning besteed aan adaptieve onderhoudsactiviteiten.

Definitie: Adaptief onderhoud zijn de activiteiten die de functionaliteit van de applicatie beïnvloeden. Impact:

Geen


37

Dataveld:

Totale inspanning voor het onderhoud van de organisatie.

Definitie: Dit is de som van de vier voorgaande velden en is bedoeld om organisaties toe te staan hun inspanningen te registreren waar geen onderscheid

gemaakt

wordt

tussen

de

verschillende


Geen Inspanning besteed aan probleemonderzoek voor de organisatie.

Definitie: Dit is de steunactiviteit van probleemonderzoek die wordt uitgevoerd om te bepalen of een gemeld probleem in feite een toepassingsfout, een fout in de gebruikersdocumentatie, een fout in de opleiding of een gebruikersfout is. Impact: Dataveld:

Geen Inspanning besteed in het geven van advies en hulp aan gebruikers.

Definitie: Dit is de steunactiviteit in het voorzien van hulp en advies aan gebruikers. Impact: Dataveld:

Geen Totale inspanning voor het geven van steun aan de applicatie.

Definitie: Dit is de som van de twee voorgaande velden en is bedoeld om organisaties toe te staan hun inspanningen te registreren waar geen onderscheid gemaakt wordt tussen de verschillende steunactiviteiten. Impact: Dataveld:

Geen Totale inspanning voor onderhoud en steun aan de applicatie.

Definitie: Dit is de som van dataveld J en M en is bedoeld om organisaties toe te staan hun inspanningen te registreren waar geen onderscheid gemaakt

wordt


tussen

de

verschillende

steun-

en 38


Geen Aantal gebreken per jaar

Definitie: Het totaal aantal gebreken in elke categorie, per jaar, van de verzamelde gegevens. De categorieën zijn deze die erkend zijn door het ISBSG en gedefinieerd zijn in het UKSMA Defect Reporting Standard. Impact:

De inspanning nodig om het oplossen van een defect kan, overeenkomstig het aantal fouten gevonden in het operationele systeem, toe nemen.

Dataveld:

Tijd nodig om te herstellen.

Definitie: Dit veld bevat een gemiddelde tijd tussen het melden van een fout en het oplossen van deze fout. Impact: Dataveld:

Geen Applicatiegrootte per duizend lijnen softwarecode.

Definitie: Dit is het totaal aantal duizend lijnen softwarecode doorheen alle programmeertalen in de applicatie. Impact:

Hoe hoger het aantal opgestelde code, hoe hoger de verwachte onderhoudsinspanning zou zijn.

Dataveld:

Primaire programmeertaal.

Definitie: De programmeertaal gebruikt om het grootste deel van de applicatie te programmeren. Impact:

Er

is

speculatie

omtrent

de

mogelijke

impact

voor

onderhoudsinspanning. Aangezien er een welomlijnd verband is tussen de primaire programmeertaal en ontwikkelingsinspanning. Het Pieterjan Donck & Dries Vanderhaeghen

39

lijkt er op dat een gelijkaardige verhouding zal bestaan voor onderhoudsinspanning, maar om het even welke vaste verklaring moet wachten op de analyse van de gegevens. Dataveld:

Hoeveelheid code in de primaire programmeertaal.

Definitie: Dit is het aantal duizend lijnen softwarecode in de primaire programmeertaal. Nochtans kan het geschikter als percentagecijfer worden uitgedrukt. Impact:

Het is moeilijk een verband te voorspellen tussen de verschillende talen en de resulterende impact op onderhoudskosten.

Dataveld:

Secondaire programmeertaal.

Definitie: De tweede programmeertaal gebruikt om een deel van de applicatie te programmeren. Impact:

Er

is

speculatie

omtrent

de

mogelijke

impact

voor

onderhoudsinspanning. Aangezien er een welomlijnd verband is tussen de secondaire programmeertaal en ontwikkelingsinspanning. Het lijkt er op dat een gelijkaardige verhouding zal bestaan voor onderhoudsinspanning, maar om het even welke vaste verklaring moet wachten op de analyse van de gegevens. Dataveld:

Hoeveelheid code in de primaire programmeertaal.

Definitie: Dit is het aantal duizend lijnen softwarecode in de secondaire programmeertaal. Nochtans kan het geschikter als percentagecijfer worden uitgedrukt. Impact:


Dataveld:

Tertiaire programmeertaal.

Definitie: De derde programmeertaal gebruikt om een deel van de applicatie te


40

programmeren. Impact:

Er

is

speculatie

omtrent

de

mogelijke

impact

voor

onderhoudsinspanning. Aangezien er een welomlijnd verband is tussen de tertiaire programmeertaal en ontwikkelingsinspanning. Het lijkt er op dat een gelijkaardige verhouding zal bestaan voor onderhoudsinspanning, maar om het even welke vaste verklaring moet wachten op de analyse van de gegevens. Dataveld:

Hoeveelheid code in de tertiaire programmeertaal.

Definitie: Dit is het aantal duizend lijnen softwarecode in de tertiaire programmeertaal. Nochtans kan het geschikter als percentagecijfer worden uitgedrukt. Impact:


Dataveld:

Overheersende code structuur.

Definitie: Deze meting probeert om de stijl van de code te vangen. Voorbeeld: Well Organised Structured code, Parameterized code, enz… Impact:

De verwachting is hoe eenvoudiger de code is om te lezen en te onderhouden, hoe lager de onderhoudskost.

Dataveld:

Overheersende logische structuur.

Definitie: De meting is bedoeld om de ingewikkeldheid van de logica binnen de toepassing te meten. Impact:

De verwachting is hoe eenvoudiger de logische structuren, hoe lager de kosten voor onderhoud en ondersteuning.

Dataveld:

Vereisten voor overheersende prestatie/uitvoering frequentie.

Definitie: Deze meting meet het operationele regime van het softwareproduct


41

geclassificeerd zoals: Onbeduidende prestatie en uitvoeringsfrequentie, functioneert

niet dagelijks. Gemiddelde prestatie en uitvoeringsfrequentie, functioneert

dagelijks minder dan twaalf uur per dag. Aanzienlijke prestatie en uitvoeringsfrequentie, functioneert

dagelijks meer dan twaalf uur per dag. Impact:

De verwachting is dat hoge prestatie/uitvoering frequentie, hogere onderhoudskosten met zich te weeg brengt.

Dataveld:

De grootte van de database in MBytes.

Definitie: De grootte van de database dat door de toepassing gebruikt wordt in MBytes. Impact:

Het is aannemelijk dat hoe groter de database hoe groter de onderhoudskost zal zijn.

Dataveld:

Beschikbare documentatie.

Definitie: Dit

is

een

lijst

van

beschikbare

documentatie

voor

het

onderhoudsteam. Deze zou volgende items moeten bevatten: functionele specificaties, technische beschrijvingen, enz. Impact:

Het

is

aannemelijk

dat

de

beschikbaarheid

van

relevante

documentatie de onderhoudskost zal doen dalen. Dataveld:

Standaard documentatie.

Definitie: Zou moeten wijzen op de norm van documentatie voor bovenstaande lijst. Dit zou een objectieve beoordeling moeten zijn. Impact:

De kwaliteit van de documentatie zou een beduidende factor in de onderhoudskost moeten zijn.


42

Dataveld:

Datum documentatie.

Definitie: Dit is de datum van het uitbrengen van de documentatie. Impact:

De mate waarin de documentatie verouderd is zal de kosten beïnvloeden.

Dataveld:

Aantal gebruikersplaatsen.

Definitie: Dit is een totaal aantal geografisch gescheiden plaatsen waar er steun moet geleverd worden. Impact:

Uit ervaring weet men dat hoe groter het aantal plaatsen, hoe hoger de kosten voor onderhoud en ondersteuning zullen zijn.

Dataveld:

Maximum aantal gebruikers.

Definitie: Het totaal aantal gebruikers die toegang hebben tot het systeem. Impact:

Hoe groter het aantal gebruikers, hoe hoger de kosten voor onderhoud en ondersteuning zullen zijn.

Dataveld:

Maximum aantal gezamenlijke gebruikers.

Definitie: Het maximum aantal gebruikers die tegelijkertijd het systeem mogen gebruiken. Impact:

Hoe groter het aantal gezamenlijke gebruikers, hoe hoger de kosten voor onderhoud en ondersteuning zijn.

Dataveld:

Aantal installaties.

Definitie: Het aantal installaties waarvoor onderhoud en ondersteuning moet voorzien zijn. Impact:

Het is aannemelijk dat hoe hoger het aantal installaties, hoe hoger de onderhoudskost zal zijn.


43

Dataveld:

Primaire hardware platform

Definitie: Het platform waar het grootste deel van de applicaties staat. Impact:

Geen merkbare impact. Nochtans is er een verhouding tussen platform en ontwikkelingsinspanning.

Dataveld:

Rol van het platform.

Definitie: Hier wordt beschreven welke rol het platform speelt. Voorbeeld: server, cliënt, enz. Impact: Dataveld:

Geen Primaire besturingssysteem

Definitie: Dit is het besturingssysteem waarop de meeste applicaties gehuisvest zijn. Impact: Dataveld:

Geen Database management systeem.

Definitie: Bovenstaande velden zullen gepresenteerd worden in een tabel. Impact: Dataveld:

Geen Systeem beschikbaarheid.

Definitie: Dit is de vereiste beschikbaarheid van het systeem. Voorbeeld: 7 uren per dag gedurende 6 dagen per week, enz. Impact:

Hoe hoger de beschikbaarheid van een systeem, hoe hoger de kosten voor onderhoud en ondersteuning zullen zijn. Zowel in termen van inspanning als in termen van ondersteuningsinfrastructuur die moet worden verstrekt.


44

Dataveld:

Veranderingen.

Definitie: Dit is het aantal softwarewijzigingen die tijdens een kalenderjaar zijn toegepast. Impact:

De kosten voor onderhoud en ondersteuning stijgen met de hoeveelheid softwarewijzigingen.

Dataveld:

Grootte van de wijzigingen.

Definitie: Dit is de grootte van alle softwarewijzingen die tijdens een kalenderjaar zijn toegepast. Impact:

Afhangende van de veranderingen heeft dit tot gevolg dat hoe groter de softwarewijzigingen hoe hoger de kosten zal zijn.

Dataveld:

Ervaring van de gebruikers.

Definitie: Dit veld meet de ervaring waarin gebruikers zelfstandig zouden kunnen werken en zet dit om in termen van ervaring: Ervaren, regelmatige, occasionele en publieke gebruikers. Impact:

Hoe groter het aantal ervaren gebruikers hoe lager de kost voor ondersteuning en onderhoud.

Dataveld:

Kennis van de applicatie.

Definitie: De kennis van de applicatie is een groep gegevensonderdelen die het kennisniveau

van

het

onderhoud

en

ondersteuningspersoneel

aangeven. Impact:

De waarschijnlijke verhouding van de kosten is dat hoe hoger het kennisniveau hoe lager de kosten zullen zijn.

Dataveld:

Beschikbaarheid van een ontwikkelomgeving.

Definitie: Dit veld is een tijdsmeting dat het onderhoud en ondersteuningsteam kan wijden aan het verbeteren van fouten en het verhogen van de Pieterjan Donck & Dries Vanderhaeghen

45

activiteiten. Het veld zou geregistreerd moeten worden als een beschikbaarheidpercentage per dag. Impact:

De verwachte impact op de inspanning zal zijn dat hoe hoger de beschikbaarheid,

hoe

lager

de

onderhouds-

en

ondersteuningsinspanning zal zijn. Nochtans zal het resultaat op de kost gemengd zijn aangezien er een kost is voor het leveren van een hoog beschikbaarheidniveau. Dataveld:

Producten van derden.

Definitie: Dit is de bijdrage geleverd door producten van derden. Impact:

Men verwacht dat pakketten met parameters gemakkelijker aan te passen zijn dan besproken applicaties.

Dataveld:

Omkeertarief als percentage van een totaal team.

Definitie: Dit

wordt

gedefinieerd

als

het

aantal

ongeplande

personeelsbewegingen in een kalenderjaar. Het wordt aangenomen dat geplande bewegingen deel zijn van kennisoverdracht en geen overmatige belemmering geeft op de ondersteuningsinformatie. Impact:

Het is waarschijnlijk dat hoe hoger de vluchtigheid van de teamleden, hoe hoger de kosten zullen zijn voor onderhoud.

Dataveld:

Configuratie management.

Definitie: Configuratie wordt al dan niet uitgevoerd in de organisatie. Impact:

De impact op de kosten voor onderhoud en ondersteuning is onduidelijk.

Dataveld:

Testomgeving.

Definitie: Dit veld wordt uitgedrukt als de dekkingspercentage van de functionaliteit van de operationele applicatie door de testomgeving.


46

Impact:

Het bestaan van een testomgeving en zijn courantheid zijn beduidende factors in de kosten van onderhoud en ondersteuning. Ervaringen tonen aan dat kosten lager zijn bij de aanwezigheid van een up-to-date test omgeving.

Dataveld:

Testmiddelen.

Definitie: Deze meting noteert het gebruik van testmiddelen tijdens het testen van applicaties. Impact:

Het gebruik van testmiddelen zou het aantal gebreken in een operationele omgeving verlagen en zo de kosten van onderhoud en ondersteuning verlagen.

Dataveld:

Service Level Agreements (ja/nee)

Indien ja, het aantal service level agreements en beschrijf deze. Definitie: De meting noteert de complexiteit van de interface bij gebruikers. Impact:

De impact die de details van de service level agreement zullen hebben op de complexiteit van het systeem.

Dataveld:

Interface agreement (ja/nee)

Indien ja, het aantal interface agreements. Definitie: Deze meting noteert het aantal interfaces met andere systemen. Impact:

Aangezien het aantal interfaces groeit, neemt de ingewikkeldheid van het systeem toe.


47

5.1.5

Afgeleide metingen

De bovenstaande metingen maken het mogelijk om enkele verdere metingen te berekenen. Deze zijn gekend als afgeleide metingen. Overall Productivity Afkomst:

Grootte van de portfolio / Onderhoud en ondersteuningsinspanning uitgedrukt in functiepunten / totale inspanning personeel per jaar.

Definitie: Dit is een meting van de kostendoeltreffendheid van de steun en onderhoudsfunctie. Impact:

Geen

Maintenance Proportion Afkomst:

Onderhoudsinspanning / Onderhoud en ondersteuningsinspanning uitgedrukt in procent.

Definitie: Dit is de personeelsinspanning toegewijd aan onderhoudsactiviteiten. Impact:

Niet gekend.

Minor Enhancement Proportion Afkomst:

Adaptieve + Perfectieve onderhoudsinspanning / Onderhoud en ondersteuningsinspanning uitgedrukt in procent.

Definitie: De ondersteuning en onderhoudsinspanning toegewijd aan minder belangrijke verhogingen. Impact:

Niet gekend.

Staff Capacity Afkomst:

Grootte

team

*

Uren

per

personeelsjaar

/

Onderhoud

en

ondersteuninginspanning


48

Definitie: Deze meting duidt op een personeelscapaciteit die door een onderhoud en ondersteuningsorganisatie tewerk gesteld wordt, maar die voor andere doelen gebruikt worden. Impact:

Als dit cijfer te groot is, zullen de kosten hoger zijn dan noodzakelijk.

Organisation Defect Density Afkomst:

Aantal gebreken per jaar / Portfoliogrootte uitgedrukt in gebreken per duizend functiepunten.

Definitie: Het aantal gebreken per duizend functiepunten die binnen de portfolio ontdekt zijn. Impact:

Hoe hoger de foutendichtheid, hoe hoger de inspanning en bijgevolg de kosten nodig voor onderhoud en ondersteuning.

Organisation Call Rate Afkomst:

Aantal oproepen / Portfoliogrootte uitgedrukt in aantal oproepen per duizend functiepunten.

Definitie: Het aantal behandelde oproepen gerelateerd aan de grootte van de portfolio. Impact:

Men verwacht dat hoe hoger het aantal oproepen, hoe hoger de inspanning

vereist

is

voor

de

onderhouds-

en

ondersteuningactiviteiten. Application Productivity Afkomst:

Grootte van de applicatie / Inspanning voor de applicatie uitgedrukt in duizend functiepunten per fulltime personeelslid.

Definitie: Dit

veld

bevat

de

productiviteit

van

de

onderhouds-

en

ondersteuningsfuncties geassocieerd met een bepaalde applicatie.


49

Impact:

Hoe lager de productiviteit, hoe hoger de kost.

Application Maintenance Proportion Afkomst:

Onderhoudsinspanning / Inspanning voor de applicatie uitgedrukt in procent.

Definitie: Dit veld drukt het percentage uit van de onderhoudsinspanning. Impact:

Niet gekend.

Application Minor Enhancement Proportion Afkomst:

Adaptieve + Perfectieve onderhoudsinspanning / onderhoud en ondersteuningsinspanning uitgedrukt in procent.

Definitie: Dit veld drukt het inspanningsaandeel op minder belangrijke applicatieverhogingen uit. Impact:

Niet gekend.

Application Defect Density Afkomst:

Gedetecteerde gebreken per jaar / Applicatiegrootte uitgedrukt in gebreken per duizend functiepunten.

Definitie: Het aantal fouten in elke categorie gerelateerd aan de grootte van de applicatie. Impact:

Hoe hoger de gebrekendichtheid, hoe hoger de kosten van onderhoud en ondersteuningsactiviteiten.

Efforts per Defect Afkomst:

Correctief onderhoud / Gedetecteerde gebreken per jaar

Definitie: Dit veld onthult de gemiddelde inspanning om de gebreken in een applicatie recht te zetten. Pieterjan Donck & Dries Vanderhaeghen

50

Impact:

Dit veld is waarschijnlijk een veelbetekende punt van de algemene kosten voor onderhoud en ondersteuning.

Primary Language Code Proportion Afkomst:

Primaire programmeertaal / Applicatiegrootte uitgedrukt in procent.

Definitie: Een

eenvoudige

meting

die

het

aandeel

van

de

primaire

programmeertaal in de applicatie aantoont. Impact:

Niet gekend.

Secondary Language Code Proportion Afkomst:

Secondaire

programmeertaal

/

Applicatiegrootte

uitgedrukt

in

procent. Definitie: Een eenvoudige meting die het aandeel van de secondaire programmeertaal in de applicatie aantoont. Impact:

Niet gekend.

Tertiary Language Code Proportion Afkomst:

Tertiaire programmeertaal / Applicatiegrootte uitgedrukt in procent.

Definitie: Een

eenvoudige

meting

die

het

aandeel

van

de

tertiaire

programmeertaal in de applicatie aantoont. Impact:

Niet gekend.

Database proportion Afkomst:

Databasegrootte / Applicatiegrootte uitgedrukt in procent.

Definitie: Dit veld in softwarelijnen variant is hetzelfde als het veld gegevens gedefinieerd in het “COnstructive COst Model”.


51

Impact:

Het ziet er naar uit dat het aandeel aan datagegevens een veelbetekenend

punt

is

voor

de

kosten

van

onderhoud

en

ondersteuningsfuncties. Effort per Location Afkomst:

Applicatie-inspanning / Aantal gebruikerslocaties

Definitie: Dit

veld

drukt

de

gemiddelde

kost

per

locatie

aan

welke

ondersteuning moet worden geleverd. Impact:

Geen

Effort per User Afkomst:

Applicatie-inspanning / Aantal afzonderlijke gebruikers uitgedrukt in uren per gebruiker

Definitie: De gemiddelde inspanning die geleverd wordt om iedere gebruiker te steunen. Impact:

Geen

Effort per Concurrent User Afkomst:

Applicatie-inspanning / Aantal gezamenlijke gebruikers uitgedrukt in uren per gebruiker

Definitie: De gemiddelde inspanning die geleverd moet worden om iedere gezamenlijke gebruiker te steunen. Impact:

Geen

Effort per Installation Afkomst:

Applicatie-inspanning / Aantal afzonderlijke installaties

Definitie: De gemiddelde inspanning die per installatie moet onderhouden Pieterjan Donck & Dries Vanderhaeghen

52

worden. Impact:

Geen

Effort per Available Hour Afkomst:

Applicatie-inspanning / Systeembeschikbaarheid

Definitie: Dit is een meting om de inspanning en vandaar de kost toegewijd aan het handhaven van het systeem als gemiddeld aantal uren van beschikbaarheid. Impact:

Geen

Effort per Change Afkomst:

Wijzigingsgrootte / Applicatie-inspanning uitgedrukt in gewijzigde functiepunten per fulltime personeelslid.

Definitie: Deze meting duidt de gemiddelde kost aan voor de wijzigingen aan de applicatie. Impact:

Geen

Effort per Available Hour of Development Afkomst:

Applicatie-inspanning / Beschikbaarheid van een ontwikkelomgeving uitgedrukt in uren per uur.

Definitie: Dit

is

de

meting

van

de

inspanning

voor

onderhoud

en

ondersteuningsactiviteiten gerelateerd aan de beschikbaarheid van een ontwikkelomgeving. Impact:

Niet gekend.


53

Effort per Staff Volatility Afkomst:

Applicatie-inspanning / Team Turnover Rate uitgedrukt fulltime personeelslid / stap.

Definitie: Deze

meting

meet

ondersteuningsfunctie

de voor

inspanning de

van

applicatie

het

onderhoud

gerelateerd

aan

en de

vluchtigheid van het team. Impact:

Geen


54

5.1.6

Definities Adaptief onderhoud:

Het werk uitgevoerd om de verwerking of dataomgeving van een applicatie aan te passen. Als voornemen van het onderhoud en ondersteuningstandaard is het adaptief onderhoud te omvatten als onbeduidende verhogingen, en vereist het onderhoud minder dan vijf personeelsdagen inspanning.

Belangrijk defect:

Een ernstig defect dat een of andere bedrijfsfunctie heeft gedegradeerd maar niet onbruikbaar heeft gemaakt. De bedrijfsfunctie kan doorgaan op een lagere activiteit of slechts een gedeelte van de bedrijfsfunctie is onbruikbaar. Het

Correctief onderhoud: werk

uitgevoerd

om

de

verwerking

of

prestaties,

gegevens

of

implementatiemislukkingen te verbeteren.

Cosmetisch defect:

Een gebrek van of verwant met de lay-out of presentatie van data maar die niet resulteert in corrupte gegevens en verkeerde waarden.

Gedetecteerd defect:

Een waargenomen overgebleven defect is een softwaregebrek dat geleverd wordt in de operationele installatie.

Inspanningsuren:

Het aantal uren gewijd aan een taak.

Kritisch defect:

Een zeer ernstig defect dat een systeem onuitvoerbaar kan maken. Dit betekent dat een of andere bedrijfsfunctie niet langer mogelijk is. Als er manuele procedures bestaan, moeten deze nu in werking worden gesteld.

Onderhoud:

Dit is het werk dat wordt vereist om activiteiten zoals adaptief onderhoud, perfectief onderhoud, preventief onderhoud en correctief onderhoud te ondernemen.


55

Onbeduidend defect:

Een defect dat kan resulteren in een verstoring van de bedrijfsfuncties zoals gebruikers ondoeltreffendheid. De software lijdt aan een mankement, maar is nog steeds uitvoerbaar.

Onbeduidende verhoging:

1. Herontwerp en ontwikkeling van kleine gedeelten van een bestaand softwareproduct. 2. Ontwerp en ontwikkeling van kleine overeenkomstige

software-items

die

enig

herontwerp van het softwareproduct vereisen. 3. Aanpassingen van de softwarecode, documentatie of databasestructuur.

Perfectief onderhoud:

Het werk uitgevoerd om prestaties en onderhoudbaarheid te verbeteren.

Preventief onderhoud:

Het werk dat wordt uitgevoerd om mogelijke toekomstige problemen te verminderen.

Software defect:

Een software defect is een afwijking van de verwachte eigenschappen in een softwareproduct .


56

5.2 PricewaterhouseCoopers: Webster Patterns in IT Litigation - systems Failure Bruce F. Webster, een Amerikaans directeur binnen PricewaterhouseCoopers, het internationale dienstenbedrijf dat advies en oplossingen biedt aan bedrijven inzake accountancy, public relations, risicomanagement, IT-processen enz..., onderzocht 120 cases gedurende 25 jaar over gefaalde IT-projecten [19]. Een kleine set van overlappende patronen bleek telkens weer de gebeurtenissen te kunnen beschrijven. Organisaties die informatietechnologie ontwikkelen of verwerven, kunnen het risico op falen reduceren door deze patronen te herkennen en te vermijden. Het merendeel gaat het over het leveren van software en de mogelijke conflicten tussen softwareleverancier en klant die opduiken. Vooral dan wanneer de ontwikkelde softwaresystemen niet volgens de verwachtingen werken of gewoonweg niet werken. Het onderzoek richt zich op de zaken waarbij de klant vond dat de beloofde functionaliteit, prestaties en/of betrouwbaarheid niet bereikt werden bij het geleverde systeem van de leverancier, als het systeem weliswaar geleverd werd. Analyse van de gebeurtenissen en oorzaken achter deze “system failures” brengt een kleine set van consistente, wederkerende patronen op. Partijen die contracten aangaan betreffende het aankopen of ontwikkelen van informatietechnologie zouden deze patronen moeten gebruiken als wegwijzers en waarschuwingsignalen om zo de verspilde tijd en kost van mislukkingen tegen te gaan. Het succes van een ontwikkeld of geleverd systeem kan uitgedrukt worden in kwaliteit, maar wat is kwaliteit voor een informaticaproduct?

Betrouwbaarheid: Het systeem moet de functies kunnen vervullen zonder fouten te veroorzaken of onaanvaardbare wachttijden te veroorzaken.

Prestaties: Het systeem moet zijn opdrachten uitvoeren binnen aanvaardbare termijn voor de gebruiker.

Functionaliteit: Het systeem moet voldoende bruikbare functies bezitten om de behoeftes van de gebruiker in te vullen.

Comptabiliteit: Het systeem moet zonder problemen kunnen samenwerken met de bestaande IT-systemen.


57

Levensduur: Het systeem moet binnen een bepaalde tijdspanne voldoende betrouwbaarheid, prestaties en functionaliteit kunnen bieden, om zo de kosten van de klant te kunnen rechtvaardigen.

Installatie: De leverancier moet het systeem leveren en installeren, en de klant moet zijn baten (betrouwbaarheid, prestaties en functionaliteit) binnen een acceptabele tijdspanne ontvangen.

Ondersteuning: Het systeem moet de mogelijkheid hebben om aangepast en hersteld te worden.

Kostprijs: De cumulatieve prijs van het ontwikkelen, installeren, upgraden en onderhouden van het systeem moet rechtvaardig lijken in de ogen van de klant.

Men vond 6 steeds wederkerende patronen en die zijn beschreven met hun oorzaak en aanbevelingen. Een patroon is echter niet uniek voor één case. Sommige cases vertoonden zelfs 2 tot 3 patronen. De patronen zijn in volgorde van frequentie van voorkomen gerangschikt. 1. Patroon 1: Defecte torens De klant koopt een systeem van de leverancier. Het systeem werkt niet naar behoren, er doen zich voortdurend errors en crashes voor. De leverancier doet pogingen tot reparatie maar slaagt daar onvolledig of totaal niet in. In sommige gevallen beslist de klant van het systeem te weigeren en eventueel één van een andere leverancier aan te schaffen. Oorzaken: Kwaliteitsstandaarden van IT-systemen variëren enorm. Leveranciers ontwikkelen en leveren soms systemen die fouten bevatten die zelfs niet aanvaardbaar zouden zijn voor kleine huishoudtoepassingen, laat staan voor bedrijfsprocessen die onbetaalbaar zijn. Maar het is nu eenmaal de natuur van software, dat defecten en hun oorzaken soms onzichtbaar zijn, zelfs voor IT-professionals. Aanbeveling: Alle partijen van het IT project moeten op voorhand de kwaliteit van het

systeem

vastleggen,

en

niet

enkel

de

functionaliteit.

Ook

is

een

acceptatieperiode aangeraden voor het in gebruik nemen van het systeem. Dan test de klant mee de kwaliteit, er kan onmiddellijk ingegrepen worden bij defecten en dit alles is inbegrepen in de ontwikkeling van de software. Als echter één partij weigert op deze manier tewerk te gaan, is dit al een signaal dat er conflicten kunnen volgen.


58

2. Patroon 2: Irrationele uitbundigheid De leverancier belooft functionaliteit en prestaties die na installatie bij de klant echter in onvoldoende mate of niet aanwezig blijken. In sommige gevallen gaat de klant een ander softwarepakket bij een andere leverancier aanschaffen. Oorzaken: Sommige verkopers hebben onvoldoende technische kennis en ervaring van het product dat zijn beloften geven die niet overeenstemmen met de realiteit, dit kan zowel bewust als onbewust gebeuren. De verkopers handelen natuurlijk uit eigen belang, het enige dat telt is verkopen en daarbij blijkt overdrijven over het product voor hen eerder normaal. Ook blijken sommige termen uit de IT-wereld nogal vaag voor de klant en dit kan ook tot verkeerde verwachtingen leiden. Nog een oorzaak is de “wishful thinking” mentaliteit van de klant. Ze hebben het systeem succesvol zien draaien en denken daarom dat gewoon door dit systeem aan te schaffen, alle problemen verleden tijd zullen zijn. Ze onderschatten dikwijls de moeilijkheid om nieuwe IT-systemen te installeren en in gebruik te nemen. De schuld wordt in dergelijke gevallen dan ook dikwijls onterecht in de schoenen van de leverancier geschoven. Aanbeveling: Verkeerde en asymmetrische informatie is altijd al een grote factor geweest in informatietechnologie. De meeste conflicten kunnen echter voorkomen worden door in het contract zo uitgebreid en gedetailleerd mogelijk definities en specificaties te beschrijven. Als het tot conflicten komt, kunnen beide partijen verwijzen naar het contract. 3. Patroon 3: Een derde betrokken partij is het slachtoffer Geval 1: De klant koopt een IT-systeem in de vorm van leasing bij een leasingfirma. De klant is niet tevreden van de software en stopt de betaling. De leasingfirma is slachtoffer door de schuld van de softwareleverancier, en zal de klant aanklagen. Geval 2: De klant huurt een consultant in om waarde toe te voegen aan een systeem. Bij problemen zal de klant de consultant beschuldigen, maar de consultant zal vervolgens de softwareleverancier beschuldigen voor het slecht werkend, mogelijk al aangepast, systeem. Oorzaken: De klant tekent vaak een leasingcontract dat geen rekening houdt met het al dan niet slecht werken van het systeem. De klant is dan verbonden aan de verplichting om de lease te voltooien.


59

Bij de consultant situatie komt het gewoon neer op het klassieke vingerwijzen. Elke partij zal de andere de schuld willen geven. Aanbeveling: Het leasingcontract moet in het voordeel spreken van zowel de leasingmaatschappij

als

de

klant.

De

softwareleverancier

moet

volledig

aansprakelijk gesteld worden als het systeem onaanvaardbaar is voor de klant. In de situatie van consultants is het noodzakelijk om duidelijk te communiceren tussen alle partijen en de consultant moet vertrouwen hebben in de systemen die hij gebruikt, aanschaft of aanraadt. 4. Patroon 4: Er komt geen einde aan het project. De klant en leverancier sluiten een contract om een systeem te ontwikkelen en installeren. Er blijkt maar geen einde te komen aan het project. De deadline wordt telkens weer uitgesteld. Ofwel gaat de softwareleverancier het project verlaten, ofwel gaan de klant het project stopzetten, ofwel levert de softwareleverancier een systeem dat totaal onjuist en onaanvaardbaar is. Er is enorm veel geld gespendeerd. Oorzaken: Een belangrijke oorzaak is gebrek aan duidelijke, stabiele en gedwongen requirements van de klant. Een andere oorzaak is een gebrek aan kwalificaties bij het personeel van de softwareleverancier. Beide oorzaken kunnen zich ook voordien, dan kan men elkaar de schuld geven. Aanbeveling: Onderschat de moeilijkheid niet om grote complexe systemen van nul te beginnen ontwerpen. Ontwerp liever meerdere kleine systemen die goed werken. Bepaal risico’s van in het begin van het project en neem stappen om deze te reduceren. (bijvoorbeeld de scope, haalbaarheid, stabiliteit van de requirements, kwalificaties van de ontwikkelaar, …) 5. Patroon 5: Ongeplande buitenwerkinstelling De klant koopt een systeem bij de leverancier. Een tijd later ontdekt de klant dat het systeem niet langer aan zijn behoeften voldoet, of dat de leverancier het systeem niet langer ondersteunt. Oorzaken: De softwareleverancier stopt plotseling met de verdere ondersteuning van een versie omdat een onvoorziene en grote fout (bijvoorbeeld Y2K) financieel zwaar kan doorwegen. Aanbeveling: Als het zover komt bieden de meeste leveranciers een doorlooppad met een oplossing voor de huidige gebruikers. Een onderhoudsplan (contract) kan Pieterjan Donck & Dries Vanderhaeghen

60

oplossing bieden voor gebruikers die met oudere versies willen blijven werken. Ondersteuning

van

oude

versies

kan

echter

wel

duur

uitkomen.

Het risico op plotse stopzetting van ondersteuning is te verminderen door producten aan te schaffen bij grote internationale leveranciers. Hoe kleiner de leverancier, hoe groter het risico. 6. Patroon 6: Onopzettelijke gevolgen De leverancier maakt enkele wijzigingen in de functionaliteit of configuratie van het systeem, dat reeds in gebruik is. De veranderingen resulteren in onaangename gevolgen voor één of meerdere klanten. Oorzaken: De leverancier verandert iets aan de functionaliteit zonder zich te vergewissen van de impact op bestaande systemen of zonder te testen. Aanbeveling: Ga voorzichtig om met wijzigingen in functionaliteit. Test uitgebreid in beperkt aantal en reageer snel bij problemen. Men trekt 4 lessen uit het hele onderzoek:

Zorg voor wettelijke expertise en IT-aanbevelingen vooraleer iets te tekenen.

Specificeer kritische elementen en zorg voor bescherming vooraleer akkoord te gaan met een verkoop van goederen of diensten.

Reageer snel als problemen zich voordoen.

Een nieuwe technologie houdt risico’s in.

Besluit De meeste oorzaken komen uiteindelijk neer op menselijke fouten, van naïviteit tot oneerlijkheid. Veel conflicten kunnen echter vermeden worden door de asymmetrie in informatie bij IT-zaken tegen te gaan. Beide partijen zouden nog voor het tekenen van het contract flexibel moeten overleggen en zoveel mogelijk informatie en gedetailleerde voorwaarden in het contract opnemen. De klant zou bij onzekerheid beroep moeten doen op expertise, zij het bij een advocaat, een IT-consultant of beide, eventueel gecombineerd in een IT-adviesbureau. Hierdoor zal het risico op conflicten sterk verminderd worden. Daar halen tenslotte beide partijen voordeel uit.


61

5.3 SEI - Software Engineering Institute 5.3.1

Wat is het SEI

Al meer dan 20 jaar heeft het SEI [6] de opdracht gehad om de staat van softwaretechnologie in de praktijk vooruit te gaan en te dienen als nationaal middel in softwaretechnologie. SEI gaat softwaretechnologie en verwante disciplines verbeteren om de ontwikkeling en de verrichting te verzekeren van systemen met voorspelbare en betere kosten, programma en kwaliteit. Hun strategie om hun opdracht te bereiken is het opzetten van een gevarieerde gemeenschap met een focus om de effecten van software in de wereld te verbeteren. Ze ontwikkelen bruikbare technologieën, passen deze toe op echte problemen en vergroten hun effect door een brede goedkeuring.

Creëren: Het SEI werkt samen met onderzoekers voor het helpen ontwikkelen en identificeren van nieuwe en verbeterde uitvoeringen. Het SEI creëert en identificeert

opkomende

en

ongebruikte

oplossingen

aan

significante

en

doordringende softwareontwikkelingsproblemen en ontwikkelt deze zodat ze kunnen worden toegepast om hun softwaretechnologie te verbeteren. Het SEI gaat overeenkomsten aan met de industrie en academies om hun oplossingen te testen.

Toepassen: Het SEI werkt met professionele softwareontwikkelaars om de nieuwe en verbeterde uitvoeringen toe te passen en te bevestigen. De personeelsleden helpen specifieke software- en aanwinstproblemen op te lossen door deze uitvoeringen toe te passen. Het SEI wordt gesteund door taken van de overheid.

Vergroten: Het SEI werkt via de globale gemeenschap van software-ingenieurs om de goedkeuring te vergroten door hun nieuwe en verbeterde uitvoeringen aan te moedigen en te steunen. Bovendien biedt het SEI cursussen aan die gebaseerd zijn op mature, bevestigde en gedocumenteerde oplossingen alsook de vergunning op de verpakking en levering van nieuwe en verbeterde technologieën.


62

Figuur 4: Strategie van het SEI

5.3.2

CMM (Capability Maturity Model)

Capability Maturity Model is een verzameling van activiteiten die worden voorgesteld door een

aantal

key

process

areas.

Deze

activiteiten

worden

ingezet

om

het

softwareontwikkelingsproces te verbeteren. Het Capability Maturity Model® Integration is gebaseerd op kennis die wordt verworven uit de beoordelingen van software ontwikkelingen en door ondersteuning en feedback van de industrie en de overheid. Door gebruik te maken van het Capability Maturity Model® Integration moet een software organisatie controle krijgen over haar processen tijdens het ontwerpen en onderhouden van software om zo te evolueren naar een steeds beter ontwikkelingsproces. Het begeleidt de organisatie bij het uitzetten van strategieën om de processen te verbeteren. Hiervoor moet men eerst de zwakke plekken uit het huidige ontwikkelproces halen door de volwassenheid van dit proces te bepalen. Volwassen en onvolwassen organisaties Voor men de doelstellingen bepaalt om een proces te verbeteren is er inzicht noodzakelijk tussen volwassen en onvolwassen organisaties. In een onvolwassen organisatie worden de ontwikkelingsprocessen geïmproviseerd en beheerd door de ontwikkelaars. Zelfs al is een project gespecificeerd, wordt dit niet correct opgevolgd. Het is pas wanneer er crisissen optreden dat de managers ingeschakeld worden. Door het niet correct inschatten van de planning en het budget Pieterjan Donck & Dries Vanderhaeghen

63

zullen deze regelmatig overschreden worden. Het naderen van een deadline zal vaak de kwaliteit

en

de

functionaliteit

van

de

applicatie

geen

goed

doen.

In een onvolwassen organisatie zijn er geen middelen aanwezig om de kwaliteit van de applicatie te beoordelen alsook geen structuur om problemen op te lossen. Dit heeft als gevolg dat de kwaliteit van de applicatie moeilijk voorspelbaar zal zijn. Wanneer men niet meer op schema zit zal men de kwaliteitstesten achterwege laten. Een volwassen organisatie daarentegen zal bekwaam zijn om alle processen te managen en te onderhouden. Alle ontwikkelprocessen worden nauwkeurig meegedeeld aan zowel bestaande als nieuwe werknemers. Alles wordt uitgevoerd via geplande en vaststaande processen. Wanneer noodzakelijk worden deze processen bijgewerkt en verbeterd. Het gebruik van deze aanpassingen worden voorafgegaan door testperiodes en analyses. Binnen de organisatie zijn de rollen en verantwoordelijkheden in processen duidelijk afgelijnd en de processen worden opgevolgd door managers. Zij controleren de kwaliteit en het ontwikkelingsproces van de software. Ze beschikken over een goede basis om de productkwaliteit te beoordelen en de problemen te analyseren. Planningen en budgetten zijn gebaseerd op vorige projecten en zijn realistisch. De verwachte resultaten voor uitgaven, planning, functionaliteit en kwaliteit van het product worden dan ook meestal bereikt. We kunnen besluiten dat bij een volwassen organisatie een proces continu opgevolgd wordt en dat iedereen bewust is van de waarde ervan. Basisconcepten van het volwassenheidsmodel

Softwareontwikkelingsproces Een softwareontwikkelingsproces kan als een reeks activiteiten, methodes, praktijken en transformaties worden gedefinieerd die de mensen gebruiken om software en de bijhorende producten te ontwikkelen en te handhaven. Naarmate de volwassenheid van een organisatie stijgt zal het ontwikkelingsproces beter gedefinieerd zijn alsook meer gestructureerd uitgevoerd worden.

Software process capability De software process capability beschrijft de mogelijke resultaten die kunnen behaald worden bij het volgen van een ontwikkelingsproces. Via de software process capability zal er voor volgende projecten een juist ontwikkelingsproces gekozen kunnen worden.


64

Software process performance De software process performance beschrijft de resultaten die behaald worden bij het volgen van een ontwikkelingsproces.

Software process maturity De volwassenheid van de applicatie is de mate waarin een specifiek proces wordt bepaald, gemanaged, gemeten en gecontroleerd. De volwassenheid impliceert een mogelijke groei in capaciteit en geeft de waarde van een ontwikkelingsproces weer.

De 5 levels van CMM Continue procesverbetering is gebaseerd op vele kleine evoluerende stappen en niet op revolutionaire innovaties. CMM verstrekt een framework om deze evoluerende stappen in vijf volwassenheidsniveaus te organiseren die opeenvolgende fundamenten leggen voor continue procesverbetering. De volwassenheid van een softwareontwikkelingsproces in een organisatie kan worden ondergebracht in één van de vijf volwassenheidsniveaus. Aan de hand van deze niveaus kan een organisatie ook concluderen welke systemen aandacht verdienen om het ontwikkelingsproces te verbeteren. Ieder volwassenheidsniveau is een duidelijk omlijnd evolutief plateau om tot een volwassen ontwikkelingsproces te komen. Elk niveau bestaat uit een reeks doelstellingen die een onderdeel van het ontwikkelingsproces stabiliseren. In volgende figuur ziet u de CMM niveaus in stijgende volgorde.


65

Figuur 5: Maturity levels van het CMM in stijgende volgorde

1. Niveau 1: Initieel Het eerste niveau, het initiële niveau, vormt geen stabiele omgeving voor het ontwikkelen van software. Deze organisaties vallen niet terug op eerder ontwikkelde systemen en gebruikte technieken tijdens het ontwikkelen van hun software, wat resulteert in crisissen. Het succes van organisaties in niveau 1 hangt af van de individuele bekwaamheid van de werknemers en kan worden herhaald telkens dezelfde werknemers aan het volgend project werken. De kwaliteit wordt dus bepaald door individuen en niet door de organisatie. 2. Niveau 2: Herhaalbaar Op het herhaalbaar niveau wordt het beleid uitgezet om softwareontwikkelingen te managen. Er worden procedures opgesteld om te gebruiken in het ontwikkelingsproces.

Het

plannen

en

managen

van

nieuwe

softwareontwikkelingen gebeurt op basis van eerder ontwikkelde projecten. De managers volgen de kosten, planningen en functionaliteiten nauwkeurig op. Zo kunnen problemen onmiddellijk ontdekt worden wanneer deze optreden. De vereiste om niveau 2 te halen is dat er regels worden gevolgd om het project te managen. Een softwareontwikkelingsproces in organisaties op niveau 2 kan omschreven worden als gedisciplineerd omdat het project gepland en opgevolgd wordt. Pieterjan Donck & Dries Vanderhaeghen

66

3. Niveau 3: Gedefinieerd Het ontwikkelen en onderhouden van software op het gedefinieerd niveau is gedocumenteerd, dit zowel in ontwikkelingsprocessen als managementprocessen. De processen op niveau 3 helpen de managers en ontwikkelaars effectiever presteren. Het ontwikkelingsproces van organisaties op niveau 3 wordt gekenmerkt door een standaard

en

consistent

proces

waarbij

het

ontwikkelingsproces

en

de

managementactiviteiten stabiel en herhaalbaar zijn. In dit proces worden kosten, planning, functionaliteit en softwarekwaliteit grondig opgevolgd. 4. Niveau 4: Bestuurd Op

het

bestuursniveau

bepaalt

de

organisatie

de

kwantitatieve

kwaliteitsdoelstellingen. Dit voor zowel de ontwikkelingsprocessen als voor de opgeleverde softwareproducten. De organisatie beschikt over een programma om de productiviteit en de kwaliteit te meten van de belangrijke activiteiten in een ontwikkelproces. Het ontwikkelingsproces op niveau 4 is kwantificeerbaar en voorspelbaar omdat het

proces

continu

gemeten

wordt.

Zo

zullen

afwijkingen

onmiddellijk

geïdentificeerd worden. Wanneer vooropgestelde grenzen worden overschreden, wordt

er

onmiddellijk

actie

ondernomen

om

dit

recht

te

zetten.

De

softwareproducten zijn van een hoge kwaliteit. 5. Niveau 5: Optimaliserend Wanneer een organisatie zich op het optimaliserende niveau bevindt dan concentreert deze zich op ononderbroken procesverbetering. De organisatie probeert continu de zwakheden te identificeren en deze proactief te verbeteren om te voorkomen dat deze het ontwikkelingsproces zouden verstoren. Succesvolle ontwikkelingsprocessen worden geïdentificeerd en verspreid over heel de organisatie om deze te implementeren in andere ontwikkelingsprocessen. Het softwareontwikkelingsproces op niveau 5 kan worden gekenmerkt als continu verbeterend. Dit betekent het onophoudelijk streven om de kwaliteit van producten en processen te optimaliseren.


67

5.3.3

CMMI® (Capability Maturity Model® Integration)

Na het uitbrengen van versie 1.1 van het SW-CMM was het SEI van plan een nieuwe, sterk verbeterde versie 2.0 uit te brengen. Dit plan werd doorkruist door de wens tot integratie van de modellen voor de verschillende disciplines. Toen zij het SWSW-CMM versie 2.0 als draft in 1997 op het Internet gepubliceerd had, kreeg het SEI van zijn belangrijkste sponsor, het Department of Defence (DoD), de opdracht de verdere ontwikkeling van het SW-CMM stop te zetten en over te gaan tot de ontwikkeling van een geïntegreerd model voor Software Engineering, Systems Engineering, Integrated Product and Process Development en Software Acquisition. Het CMMI project was hiermee een feit. De kennis en ervaring die de basis vormden voor het ontstaan van versie 2.0 van het SW-CMM zijn hierdoor gelukkig niet verloren gegaan, omdat deze nieuwe versie samen met het CMM model voor geïntegreerde productontwikkeling (IPD CMM versie 0.98) en de interim standaard voor systeem engineering (EIA/IS 731) als basis hebben gediend voor de ontwikkeling van het CMMI. Verkenning van het CMMI In de afgelopen jaren is er veel ervaring opgedaan met de toepassing van het CMM. Veel organisaties hebben zich intussen opgewerkt naar CMM level 2 of hoger. Deze ervaringen zijn middels een lang reviewproces meegenomen in het CMMI. Daardoor ontstond een groot aantal verschillen tussen het SW-CMM Versie 1.1 en het CMMI Versie 1.1 zoals dat eind 2001 beschikbaar is gekomen. Deze verschillen worden hieronder puntsgewijs behandeld.

De “Staged” en “Continuous” representaties In tegenstelling tot het SW-CMM, dat een model is in de zogenaamde “Staged” representatie, kent het CMMI twee verschillende representaties, de “Staged” en de “Continuous” representatie. In de “Staged” representatie kent het CMMI net als het SWCMM vijf “Maturity Levels”. Zoals uit tabel 1 blijkt, zijn in de naamgeving van deze levels enkele kleine wijzigingen aangebracht. De kracht van de “Staged” representatie is dat een organisatie met het CMMI in de hand een routebeschrijving heeft om te verbeteren. Er wordt immers stap voor stap aangegeven welke processen verbeterd moeten worden en aan welke eisen deze processen moeten voldoen. Het verbetertraject voor een organisatie wordt daarmee expliciet duidelijk gemaakt.


68

Maturity Level

SW-CMM, Version 1.1

CMMI-SE/SW, Version 1.1

1

Initial

Initial

2

Repeatable

Managed

3

Defined

Defined

4

Managed

Managed Quantitatively

5

Optimizing

Optimizing

Tabel 1: Maturity Levels in CMM en de “Staged” representatie van het CMMI

Figuur 6: Maturity Levels van het CMMI in oplopende volgorde

De “Continuous” representatie is gezien vanuit het SW-CMM een nieuw fenomeen. De “Continuous” representatie van het CMMI kent per “Process Area” (procesgebied) zes verschillende zogenaamde “Capability Levels” (vergelijkbaar met de “Maturity Levels” van de “Staged” representatie). Een organisatie kan in de “Continuous” representatie dus zelf bepalen welke procesgebieden zij op welk Level wenst in te vullen.


69

In tabel 2 is een overzicht van deze “Capability Levels” weergegeven. Capability Level

CMMI-SE/SW, Version 1.1

0

Incomplete

1

Performed

2

Managed

3

Defined

4

Quantitatively Managed

5

Optimizing

Tabel 2: Capability Levels van de “Continues” representatie van het CMMI

Figuur 7: Capability levels van het CMMI

Van “Common Features” naar “Generic Goals” Voor de institutionalisering van de processen kent het SW-CMM zogenaamde “Common Features”, groepen van activiteiten die zich bezig houden met de policy, de input van de processen, het beleggen van de verantwoordelijkheden, het voorzien in de noodzakelijke resources (zowel mensen als tools), het trainen van de mensen, het verzamelen van meetbaarheden en het verifiëren van de juiste toepassing van de processen. In het CMMI zijn deze “Common Features” verdwenen en vervangen door generieke doelen (“Generic Goals”) die voor elk procesgebied gelden. Deze generieke doelen zijn op hun beurt gekoppeld aan de “Maturity” of de “Capability” Levels.


70

Tabel 3 geeft een overzicht van deze generieke doelen. Naast de generieke doelen kent elk procesgebied ook specifieke doelen (“Specific Goals”). Deze komen overeen met de “Goals”, zoals we die kenden uit het SW-CMM. Maturity Level

Capability Level

Generieke doelstelling

0

Geen

1

1

Behaal de specifieke doelen (geldt alleen voor het capability level!)

2

2

Institutionaliseer een gemanaged proces

3

3

Institutionaliseer een gedefinieerd proces

4

4

Institutionaliseer een kwantitatief gemanaged proces

5

5

Institutionaliseer een optimaliserend proces Tabel 3: De generieke doelen van het CMMi

Van “Key Process Areas” naar “Process Areas” De term KPA (“Key Process Area”) is in het CMMI verdwenen en vervangen door de term PA (“Process Area”). In het nieuwe model vinden we met betrekking tot deze procesgebieden de grootste verschuivingen. Op alle Levels zijn er procesgebieden verdwenen, radicaal veranderd of erbij gekomen. De opvallendste veranderingen op het PA niveau zijn:

Het expliciet maken van een meet “process area”.

Het toevoegen van een risicomanagement “process area”.

Het opsplitsen van de KPA’s Software Product Engineering en Peer Review in vijf afzonderlijke PA’s die de volledige productontwikkeling afdekken.


71

Tabel 4 toont een vergelijking tussen het SW-CMM en de “Staged” representatie van het CMMI-SE/SW. Maturity Level

CMM for Software, version 1.1 (KPA’s)

CMMI-SE/SW, Version 1.1 (PA’s)

1

Geen

Geen

2

Requirement Management Software Project Planning Software Project Tracking en Oversight Software Subcontact Management Software Quality Assurance Software Configuration Management

Requirements Management Project Planning Project Monitoring en Control Supplier Agreement Management Process en Product Quality Assurance Configuration Management Measurement en Analisys

3

Organization Process Focus Organization Process Definition Training Program Integrated Software Management Software Product Engineering Intergroup Coordination Peer Reviews

Risk Management Organizational Process Focus Organizational Process Definition Organizational Training Program Integrated Project Management Requirements Development Technical Solution Product Integration Decision Analysis and Resolution Verification Validation

4

Quantitative Process Management Software Quality Managent

Organizational Process Performance Quantitative Project Management

5

Defect Prevention Technology Change Management Process Change Management

Causal Analysis and Resolution Organizational Innovation and Deployment

Tabel 4: (Key) Process Areas per "Maturity Level"


72

In de “Continuous” representatie kennen we geen “Maturity Levels” meer. In dit model zijn de PA’s verdeeld over vier procescategorieën: Process Management, Project Management, Engineering en Support. Tabel 5 toont hoe deze verdeling eruit ziet. Proces catagorie

CMMI-SE/SW procesgebied (PA)

Process Management

Organizational Organizational Organizational Organizational Organizational

Project Management

Project Planning Project Monitoring and Control Supplier Agreement Management Intergrated Project Management Risk Management Quantitative Project Management

Engineering

Requirements Management Requirements Development Technical Solution Product Intergration Verification Validation

Support

Configuration Management Process and Product Quality Assurance Measurement and Analysis Decision Analysis and Resolution Causal Analysis and Resolution

Process Focus Process Definition Training Process Performance Innovation and Deployment

Tabel 5: Procesgebieden per procescategorie

Lezen van het model Om een eenvoudige interpretatie van het model mogelijk te maken hebben de makers een onderscheid gemaakt tussen drie verschillende categorieën van modelcomponenten: De verplichte (“Required”), verwachte (“Expected”) en informatieve (“Informative”) materialen. Wat onder welke soort van componenten valt is eenduidig gedefinieerd in het model. Deze categorieën bepalen in hoge mate welke rol de modelcomponent speelt in een beoordeling. Om een snel beeld te krijgen van de opbouw van het model is het voldoende alleen te kijken naar de verplichte en verwachte componenten van een te beschouwen procesgebied, die in een aparte bijlage bij de modelbeschrijvingen zijn opgenomen. Is men echter geïnteresseerd in het inrichten van een bepaald deel van het model, dan geven de informatieve materialen zeer waardevolle achtergrondinformatie om tot een werkende implementatie te komen. Pieterjan Donck & Dries Vanderhaeghen

73

Voor- en nadelen CMMI Het nieuwe CMMI model biedt een goed uitgangspunt voor een geïntegreerde aanpak van de procesverbetering. De ervaringen van zeven jaar softwareprocesverbetering (SPI = Software Process Improvement) met behulp van het SW-CMM heeft tot veel verbeteringen ten opzichte van het oorspronkelijke model geleid. Door het toevoegen van de informatieve materialen is men er tevens in geslaagd een beschrijving van het model te maken die begrijpelijk en goed leesbaar is. Een bijkomend voordeel is dat op Level 3 nu het complete productontwikkelingsproces beschreven is, te beginnen met de specificatie van de producteisen (“Requirements Development”) tot en met de integratie (“Product Integration”) en test (“Verification” en “Validation”) van het eindproduct. Ondanks deze voordelen is er ook een nadeel te noemen. De nieuwe modellen zijn namelijk erg complex en uitgebreid geworden en de boekwerken die de modellen beschrijven (zes in totaal met een grootte van 643 tot 729 pagina’s) nodigen niet bepaald tot lezen uit. Conclusies Het CMM(I) is niet meer dan een hulpmiddel om de softwareontwikkelingprocessen te verbeteren of aan te vullen. Neem dus activiteiten uit het model nooit klakkeloos over maar beoordeel ze op het nut voor de eigen organisatie. Alleen dit geeft medewerkers en organisatie de motivatie om een procesverbeteringstraject tot een goed einde te brengen. Wanneer we op basis van deze gedachte overstappen van het SW-CMM naar het CMMI zal het nieuwe model ons zeker helpen aan nieuwe kansen voor verdere verbetering.


74

6

Praktisch onderzoek contracten

6.1 Doel Omdat het ene contract het andere niet is, wilden we een zo groot mogelijk aantal onderhoudscontracten verzamelen. We willen immers een voldoende grote steekproef verrichten om met statistisch relevante resultaten op de proppen te komen. Als we in kaart kunnen brengen wat de inhoud is van elk contract en welke prijs daaraan gekoppeld is, dan is het mogelijk om elk contract te gaan evalueren met de verzamelde informatie. De contracten met opvallend verschillende resultaten kunnen we hierdoor uithalen en vinden waar de gewenste of ongewenste verschillen zitten. Reële softwareonderhoudscontracten zijn dus ons studiemateriaal. Dergelijke contracten zijn hoofdzakelijk te vinden bij bedrijven en organisaties. Daarom hangt deze steekproef dus sterk af van de medewerking van de bedrijven. We vertrekken met een richtaantal van ongeveer 200 bedrijven en zullen dan evalueren of er voldoende diversiteit in de bedrijven zit. Hebben we teveel boekhoudkantoren en te weinig banken dan kunnen we bijsturen. Naargelang we resultaten verkrijgen, kunnen we ook parallel de statistische relevantie controleren (bijvoorbeeld met de Chi-toets) om zo na te gaan in hoeverre onze resultaten al representatief zijn.

6.2 Werkwijze 6.2.1

Bedrijven contacteren

Om te beginnen verzamelen we adressen van bedrijven uit de streek (Oost- en WestVlaanderen) en daarbuiten zoals banken en telecommunicatiebedrijven met als hoofdfiliaal Brussel. Bedrijven die we kennen en adressen uit de Gouden Gids brengen ons op een hoeveelheid van +/- 400. Die contacteerden we via:

e-mail

persoonlijke brief (zie bijlage)

contact in het bedrijf ter plaatse

de 2-daagse beurs Bedrijvencontactdagen in Kortrijk. (zie bijlage)


75

6.2.2

Analyseren onderhoudscontracten

Telkens we een contract ontvingen hebben we de inhoud ervan samengevat met de bedoeling om een efficiënte vergelijking te maken. Zo konden we overzichtelijk zien in welke contracten essentiële onderwerpen ontbreken of uniek zijn. Om de privacy van de leverancier en de klant te behouden wordt er in de volgende analyses gesproken van “klant” en “leverancier”. Enkele voorbeelden van contracten die we geanalyseerd hebben. Contract 1:

Onderhoud software: à

Verbetering van fouten.

à

Nieuwe versies.

à

Helpdesk.

Wanneer functie essentieel is en de werking ernstig verhinderd wordt, zal de leverancier met spoed tussenkomen.

Niet in het onderhoudscontract: à

Onoordeelkundig gebruik.

à

Wijziging aan software aangebracht door anderen.

à

Toevoeging van andere software aan software van de leverancier.

à

Invloed van de werking door andere software.

à

Wanneer fout niet reproduceerbaar is.

à

Problemen software waarvan de versie 3 maanden ouder is dan de laatst geleverde versie.

Betalen bij prestaties buiten het onderhoudscontract na bevestiging.

Nieuwe versie: à

Bestaat uit noodzakelijke aanpassingen en functionele aanpassingen.

à

Alvorens aflevering, werking controleren door de klant.

à

Bij verandering wetgeving zal de leverancier een nieuwe versie leveren in regie.

Helpdesk: à

Tijdens uren vermeld in contract.

à

Beperkt tot aantal kredieturen, bijkomende uren zijn betalend na verwittiging van de klant hierover.

Verplichtingen van de klant: De klant moet over een recente back-up beschikken.


76

Tarieven: à

Jaarlijks aangepast.

à

Onderhoudsvergoeding:

80%

gekoppeld

aan

de

nationale

referentie

loonkosten. Contract 2:

Algemeen à

Dekt alle kopieën die een geldige onderhoudsovereenkomst hebben.

à

De geldigheid van dit contract is 1 jaar.

à

Zonder enige vorm van verwittiging wordt deze automatisch 1 jaar verlengd.

à

Afzeggen gebeurt per brief 30 dagen voor einddatum.

à

De prijzen kunnen jaarlijks gewijzigd worden.

Onderhoud à

Bevat alle upgrades en documenten die gedurende deze periode gemaakt is.

à

Ze zijn downloadbaar.

à

Iedere

upgrade

kan

correcties

van

fouten

bevatten,

functionele

en

performante verbeteringen en verbetering van het programma. à

Er is geen garantie op het aantal upgrades.

Klant ondersteuning à

Gratis fax en email ondersteuning op reguliere uren en gedurende reguliere werkdagen.

à

Er wordt 1 contactpersoon aangeduid waarmee alles wordt afgehandeld.

à

De manier hoe ondersteuning wordt gegeven wordt case-by-case bekeken. Er is geen garantie voor de beschikbaarheid en levering van upgrades.

Wordt niet ondersteund: à

Wanneer niet volledig betaald is.

à

Wanneer het geen origineel of legaal product is.

à

Wanneer fouten ontstaan door het niet correct gebruiken van de software.

à

Als de rechten van het product overtreden zijn.

à

Wanneer de fout ontstaan is door het slecht functioneren van de hardware.

Betalingen: Bij niet betalen wordt er 1,5% intrest per maand aangerekend of de hoogst toegelaten tarief door de wet.


77

Contract 3:

Ondersteunt volgende punten à

Voorzien van correcties op gekende fouten per levering of online.

à

Voorzien van kleine updates (meerdere verbeterde fouten) online.

à

Voorzien van medio upgrade (extra functies) online.

à

Voorzien van grote upgrade (grote hoeveelheid extra functies)

à

Informatie via email wanneer één van de upgrades/updates beschikbaar is.

Ondersteuning via telefoon en email à

Vragen over technische problemen en tekortkomingen zijn op ieder ogenblik mogelijk.

à

à

Error levels:

Level A: systeem werkt niet meer.

Level B: Systeem werkt nog maar niet alle functies.

Level C: Systeem werkt maar juist errors met specifieke functies.

Verbetertijden:

Level A: De volgende werkdag.

Level B: De volgende werkdag.

Level C: De dag op de volgende werkdag.

Installaties en andere ondersteuning op verplaatsing zijn niet inbegrepen in het onderhoudscontract.

De betaling gebeurt jaarlijks.

De leverancier kan niet instaan om een succesvolle oplossing te vinden voor een fout.

De leverancier verwacht dat de klant het probleem perfect kan beschrijven.

De basis is een contract van één jaar. Opzeggen gebeurt drie maanden voor einddatum per brief.

Dit contract valt onder de Duitse wetgeving.

Contract 4:

Assisteert de gebruiker bij het stellen van een diagnose van fouten, slechte werking en mankementen via telefoon, email of remote access.

Voorziet technische service naar de gebruiker om deze mankementen te verhelpen.


78

Voorziet voor aanpassing/integratie ondersteuning met behulp

van open

Exchange, email, telefoon en remote access.

De eerste twee punten zijn gelimiteerd tot vier uur ondersteuning per maand.

Punt drie is gelimiteerd tot drie uur ondersteuning gedurende de duur van het contract.

Het stellen van de diagnose en de aanpassing ervan gebeurt gedurende de werkdag. De leverancier verzekert hierop een responstijd van één werkdag.

De klant zal de leverancier bijstaan in het voorzien van informatie wanneer de leverancier hier om vraagt.

De leverancier geeft onbeperkte toegang tot de “Trouble Ticketing Service” en de “Knowledge Base” op de website van de leverancier.

Bij niet betalen wordt er 1,5% intrest per maand aangerekend of de hoogst toegelaten tarief door de wet.

De leverancier geeft een garantie van één jaar.

6.2.3

Resultaat

We ontvingen in totaal 14 contracten van de ongeveer 400 aanvragen, dit is 3.5 % respons. Vanzelfsprekend is het kleine aantal onvoldoende om een statistisch onderzoek uit te werken. We vergewisten ons wel van het risico dat bedrijven mogelijk weerhoudend kunnen zijn om dergelijke documenten vrij te geven. Een contract is immers een verbintenis tussen twee partijen en een derde partij heeft er over het algemeen geen zaken mee. Er zal wel beroep gedaan worden op een derde partij voor inzage van het contract als er zich een conflict

voordoet,

maar

dan

is

het

al

te

laat,

het

kwaad

is

al

geschied.

Wij, studenten, met de bedoeling om als derde partij een preventief onderzoek te verrichten, worden jammer genoeg ook met argusogen bekeken als het gaat om delicate documenten van naderbij te bekijken in het kader van academische doeleinden. Argumenten die bedrijven gaven voor het niet-meewerken aan ons project zijn:

Geen onderhoudscontracten aanwezig: à

De ontwikkeling van software gebeurt intern op de eigen IT-afdeling Æ Meestal multinationals, banken, ...

à

Er wordt een kant-en-klaar softwarepakket gekocht voor het beheren van klanten, leveranciers, facturen, offertes, … Het enige wat men hiervan heeft is


79

een

kasticket

of

factuur.

Æ Kleine KMO’s met weinig IT aanwezig in het bedrijf à

Sommige bedrijven eisen dat hun geleverde software foutloos is. Er wordt van de softwareleverancier geëist dat er preventief uitgebreid getest wordt. Om wettelijke of infrastructurele updates maakt men zich geen zorgen. Als dit ooit nodig is, zal dit zogezegd slechts een kleine supplementaire kost teweeg brengen. Æ KMO’s met een weinig ervaren IT-verantwoordelijke.

Weigeren mee te werken à

Bedrijven hebben schrik voor de softwareleverancier, die eist in het contract zelf dat dit niet mag ingekeken worden door derden.

à

Softwareleveranciers staan sceptisch tegenover het project, met als reden omdat

wij

eerder

de

belangen

hun

klanten

verdedigen.

Dit is een bewijs van hun overmacht en asymmetrische informatie. Sommigen houden dit liever zo en hebben schrik voor een te kritische klant.

Andere redenen: à

Geen tijd

à

Geen interesse

à

Hechten “Wat

geen

belang

kan

aan er

een

softwarecontract:

nu

mislopen?”

Dit kan betekenen dat men geen rekening houdt met risico’s. Wat we ook ontdekt hebben door het praktisch onderzoek, is dat zelfs klanten een onderhoudscontract kunnen opstellen. Ze zoeken dan een softwareleverancier die met die voorwaarden akkoord kan gaan. Deze klanten zijn dan wel grote organisaties zoals banken. We ontvingen twee zulke contracten van bekende banken in België. Hieruit leren we dat niet noodzakelijk de leverancier de macht in handen heeft om zijn eisen te stellen, maar

als

de

klant

groot

genoeg

is

kan

hij

zich

dit

zelf

veroorloven.

Een bijkomende voorwaarde is dat die klant degelijke kennis moet hebben van IT. Banken werken bijna uitsluitend op IT en bevinden zich hierdoor in een verdere kennisfase dan KMO’s. Dergelijke contracten zijn op sommige punten echter wel flexibel voor de leverancier, bijvoorbeeld tijd van tussenkomst, bereikbaarheid in uren, enz… Bij deze manier van contracten opstellen zal er veel onderhandeling zijn tussen beide partijen. Dit kunnen we alleen maar toejuichen.


80

6.3 Conclusie Uiteindelijk hebben we veel energie gestopt in de praktische voorbereiding, in verhouding met de feedback die we maar ontvingen. Misschien waren we iets te naïef over de bereidwilligheid van medewerking van bedrijven. Is het een teken dat nog steeds te weinig

belang

gehecht

wordt

aan

IT

en

in

het

bijzonder

de

softwareonderhoudscontracten? Hier en daar kregen we redenen, de ene wat meer gegrond dan den andere, wij kunnen als buitenstaander alleen maar luisteren en toezien. Wij zijn hiermee alleszins een ervaring rijker.


81

7 Conflictenanalyse 7.1 De verschillende luiken van het onderhoudscontract 7.1.1

Luiken enkel belangrijk voor de klant

Als de klant niet geneigd is van te onderhandelen over de voorwaarden van het contract, bestaat het risico dat sommige van zijn rechten niet gedefinieerd zullen worden. De leverancier zal voor de veiligheid sommige eigen verantwoordelijkheden niet vermelden. De meeste leveranciers zijn hierin echter wel eerlijk. Trouwens kunnen sommige luiken gebruikt worden om de klant te overtuigen de software aan te schaffen. Ondersteuningsperiode Dit is een belofte van de leverancier waarmee hij de klant zekerheid geeft dat het contract onmogelijk zal kunnen beëindigd worden gedurende die periode. De software blijft dan ondersteund en aanpassingen blijven mogelijk. Je zou wel kunnen veronderstellen dat dit ook belangrijk is voor de leverancier, dat hij hiermee zijn ondersteuning kan beperken. Maar vermeldt hij daarentegen niets over de periode, dan kan hij in principe het onderhoudscontract en ondersteuning gelijk wanneer beëindigen. Beschikbaarheid leverancier Staat hierover niets vermeld, dan kan de leverancier zijn eigen (in het ergste geval variabele) uren hanteren en moet de klant zich aanpassen. De klant zal hierbij maar alle belang hebben dat hij de leverancier op vooraf afgesproken tijdstippen kan bereiken voor melding van fouten en snelle tussenkomst. Dossier Met het dossier wordt een informatiebundel bedoeld met de detailgegevens van de software. In welke taal is de software geprogrammeerd, welke bronnen worden aangesproken, wat is de onderliggende structuur (installatiemappen, databases, …)? Dit kan nuttig zijn voor de klant bij installatie van software van derden, bij de keuze van zijn hardware, bij back-ups en dergelijke. Wetswijzigingen Als er noodzakelijke aanpassingen nodig zijn in de software door wijzigingen van een wet of een algemeen reglement. Zal de leverancier dit in algemeen belang van alle klanten op Pieterjan Donck & Dries Vanderhaeghen

82

eigen initiatief aanpassen en aanbieden? Of zullen zulke wijzigingen gewoon onder evolutief onderhoud van eigen contract vallen? Geplafonneerde prijzen De meeste leveranciers vermelden in het contract dat de prijzen van de meest recente prijslijst van toepassing zijn op het moment van contractvernieuwing. Maar zijn de prijzen gelimiteerd volgens een bepaalde formule die rekening houdt met de economie op dat ogenblik?

7.1.2

Luiken enkel belangrijk voor de leverancier

Contract niet door derden laten inkijken Hiermee beschermt de leverancier zich tegen concurrenten en potentiële klanten die de unieke voorwaarden te weten kunnen komen. Soms wordt er wel gewerkt met annexen of bijlagen.

Het

contract

bestaat

dan

uit

twee

delen.

Het

eerste

deel

is

het

gemeenschappelijke contract die voor alle klanten gebruikt wordt. Na onderhandeling zullen

in

bijlage

de

individuele

voorwaarden

en

prijzen

vermeld

worden.

De bijlagen hebben altijd prioriteit op de voorwaarden in het hoofdcontract. Er kan als supplementaire zekerheid een non-disclosure contract afgesloten worden tussen beide partijen, waarin vermeld wordt dat de gegevens uit het betreffend document strikt geheim gehouden worden. Contract verplicht Sommige leveranciers verplichten de klant om een onderhoudscontract aan te gaan. De redenen hiervoor kunnen zijn om zich van een vaste inkomstenstroom te voorzien en achteraf discussies te vermijden over het al dan aanpassen van de software en tegen welke prijs.

7.1.3

Luiken voor beide partijen even belangrijk

Definities Beide partijen hebben er alle belang bij om alle termen zo uitgebreid mogelijk in definities te omschrijven. Er is dan nadien ook geen discussie mogelijk. Iedereen zit van in het begin op dezelfde golflengte.


83

Betalingstermijn Eerder een klassieke vermelding, maar toch noodzakelijk. Het is onwaarschijnlijk dat er gediscussieerd kan worden over dat er bijvoorbeeld binnen 30 dagen moet betaald worden.

7.2 Aanvangstijdstip Het aanvangstijdstip van het onderhoudscontract moet gedefinieerd worden in functie van de conventionele garantie en de goede uitvoering van de verplichting tot levering. Wanneer de verwachte ondersteuning reeds aangeboden wordt onder de garantie of de algemene leveringsplicht, dan dient men uiteraard geen overlappend onderhoudscontract toe te passen. (wat eventueel zelfs zou betekenen dat de gebruiker in feite betaalt voor een garantie die gratis zou moeten zijn). Indien alle onderhoudsacties in feite gedekt zijn door de garantie, zou het onderhoudscontract dus maar moeten starten van zodra alle andere verbintenissen tot ondersteuning en herstel ophouden. Slaat de garantie echter niet op alle problemen die zich kunnen voordoen, dan kan die leemte ingevuld worden door een onderhoudscontract. Voor die periode die overlapt met de garantie zou dan een lagere prijs moeten betaald worden. De reden hiervoor is immers dat in het begin vooral correctieve updates zullen moeten toegepast worden, waar eerder de oorzaak bij de leverancier zal liggen. Indien er voldoende ondersteuning in de garantieperiode voorzien is, kan men overeenkomen om een onderhoudsperiode met lagere kostprijs te voorzien, met beperkte duur totdat de (conventionele) garantie verlopen is. Los daarvan is er nog de acceptatieperiode, die vrijwel bij elke software-implementatie aanwezig zal zijn. In deze periode zou eigenlijk een “super”onderhoudscontract van toepassing kunnen zijn waar zeer snel en flexibel op een fout kan gereageerd worden.


84

installatie

acceptatieperiode

onderhoudsperiode

flexibele aanpassingen

eventueel overlappend met garantieperiode

Figuur 8: Aanvang softwareonderhoudscontract

De leverancier zal eerder geneigd zijn om het onderhoudscontract vanaf ondertekening te laten starten. De inkomsten beginnen vanaf dan te lopen en elke aanpassing kan dan onder het contract vallen. De klant daarentegen zal het contract liever gestart zien vanaf ingebruikname van de software na installatie. En bovendien zal die graag een acceptatieperiode zien waarin aanpassingen veel flexibeler kunnen gebeuren en dit tegen zeker geen meerprijs, tenzij hij natuurlijk van plan is om hier en daar nog evolutieve aanpassingen te vragen. Tijdens de conventionele garantieperiode zal de klant ook nog graag een onderhoudscontract met grotere service zien. Pas na de garantieperiode zou een volwaardige onderhoudscontract tegen normale prijs van toepassing mogen zijn.

7.3 Duur en verlenging De duur van het onderhoudscontract kan van bepaalde of onbepaalde duur zijn. Veel contracten bevatten een bepaalde duurtijd, van bijvoorbeeld typisch één jaar, en voorzien van stilzwijgende verlenging van bijvoorbeeld een jaar tenzij het contract uitdrukkelijk wordt opgezegd met een opzegtermijn. Zo vermijdt men dat telkens een uitdrukkelijke verlenging tussen de partijen moet worden overeengekomen, wat vaak zou worden vergeten. Is het contract van onbepaalde duur, dan loopt het contract door zonder vaste datum van beëindiging, maar zal het steeds opzegbaar zijn mits toepassing van een overeengekomen opzegtermijn.


85

7.4 Rollenspel klant-leverancier Om het rollenspel te kunnen uitwerken hebben we ons verdeeld in twee groepen. Hierin was Pieterjan de klant en Dries de leverancier. Beiden stelden we een lijst op met wat we in eigen belang wensten in een onderhoudscontract. Hieruit ontstond onderstaande lijst. 1. Aanvangdatum: Klant

Leverancier

Vanaf de volledige oplevering zodat fouten die gebeuren tijdens de implementatie op kosten van de leverancier gebeuren en niet op kosten van het onderhoudscontract. Voorbeeld om implementatiefouten te corrigeren dat men al gebruik maakt van het beperkt aantal correctieve updates inbegrepen in het contract.

Verplicht: Vanaf contractdatum Niet verplicht: Kans dat klant geen onderhoudscontract nodig acht, omdat na implementatie alles er foutloos werkend uit ziet.

2. Definities: Klant

Leverancier

Vindt dat dit zeer gedetailleerd moet zijn zodat er geen conflict kan ontstaan door ondubbelzinnigheid.

Wegens de informatieplicht en om te vermijden van misverstanden.

3. Ondersteuningsperiode: Klant

Leverancier

Op voorhand vastgelegd, als een soort van verzekering van duurzame werking.

Gedurende de levensduur van het pakket (nader te bepalen en niet bindend)

Richtlijn voor doorsnee software: minstens 5 jaar.

4. Contractperiode / Opzegbaar: Klant

Leverancier

De software moet ondersteund worden op minimum een vooropgestelde termijn (rekening houdend met de

Een minimum aantal is het onderhoudscontract verplicht om inkomsten te verzekeren.


86

afschrijfperiode en aard van de software) Daartegenover moet het contract jaarlijks opzegbaar zijn, zelfs al vanaf het eerste jaar.

Daarna is het contract per jaar opzegbaar.

5. Manier om contact op te nemen: Klant

Leverancier

Op alle mogelijke manieren contact moet er mogelijkheid zijn om contact op te nemen. Bij voorkeur telefonisch.

Eerste contact bij voorkeur via e-mail.

6. Respons op foutmelding: Klant

Leverancier

De leverancier moet binnen vooropgestelde termijn laten weten of hij deze aanvraag goed ontvangen heeft en of er overeenkomst is welke prioriteit de fout heeft. De oplostijd begint vanaf dan te lopen.

De respons zal binnen een redelijke termijn gebeuren, afhankelijk van de omvang van de fout.

7. Tijd om te verbeteren: Klant

Leverancier

Zo snel mogelijk, vastgelegde termijnen, met sancties.

Afhankelijk van de prioriteiten wordt de verbetertijd zo ruim mogelijk vooropgesteld zodat er reserves voorzien worden. Prioriteit A: software is gedeeltelijk of volledig buiten werking. Prioriteit B: een fout die de werking volgens de documentatie niet meer garandeert.

8. Informatieplicht: Klant

Leverancier

Bij mogelijke overschrijding van de oplosperiode moet de leverancier dit tijdig laten weten en desnoods een tijdelijke oplossing vooropstellen.

Vermelding in het onderhoudscontract betreffende informatieplicht gedurende de oplosperiode is overbodig.

Verbeteringen en nieuwe functies moeten


Wanneer verbeteringen of nieuwe functies ontworpen worden op vraag van

87

gemeld worden zonder enig acceptatieplicht. Dit om toekomstige fouten of tekortkomingen te vermijden. Beter voorkomen dan genezen.

een klant, dan mogen die beschikbaar gesteld worden aan andere klanten. Een acceptatie van dergelijke verbeteringen vallen gewoon onder het onderhoudscontract, net of die klant zelf om een nieuwe verbetering zou gevraagd hebben.

9. Handleiding: Klant

Leverancier

Bij aankoop en iedere functionaliteitverandering moet een handleiding geleverd worden of de bestaande aangepast worden.

Bij aankoop wordt een handleiding voorzien.

Het kan ook een bescherming betekenen als de leverancier onterecht een correcte handeling als een verkeerde handeling zou beschouwen.

Dit kan een manier zijn om een beperking op te leggen van voorziene handelingen. Fouten, veroorzaakt door handelingen niet vermeld in de handleiding, kunnen een reden zijn om te weigeren deze fouten op te lossen onder het onderhoudscontract.

10. Beschikbaarheid leverancier: Klant

Leverancier

Indien de beschikbaarheid van de leverancier niet overeenkomt met de eigen kantooruren, dan moet er toch een meldpunt voorzien worden (desnoods extern) waar kritieke fouten gemeld kunnen worden.

Beschikbaar volgens eigen vastgelegde kantooruren. Het is onmogelijk om de eigen beschikbaarheid aan te passen aan al de klanten. Indien het eigen bedrijf daartoe in staat is, dan kan er een 24/24u helpdesk voorzien worden mits een grotere bijdrage.

11. Dossier: Klant

Leverancier

Een technische fiche met alle courante informatie van de software.

Een beperkte technische fiche kan aangeboden worden.

Gedetailleerde informatie is noodzakelijk om conflicten met andere en toekomstige softwarepakketten te vermijden.

Gedetailleerde ontwikkelingsinformatie blijft echter binnen het bedrijf en hoeft niet gedocumenteerd te worden. Dit brengt extra tijd/kosten met zich mee en heeft geen enkel nut voor het normale gebruik van de software.

Voor back-up kan dit ook noodzakelijk zijn.


88

12. Wetswijzigingen: Klant

Leverancier

De wetswijzigingen die een verandering als gevolg hebben op de werking van mijn programma moeten spontaan en zo snel mogelijk aangeboden worden.

Wetswijzigingen worden pas aangepast op vraag van de klant.

13. Non-Disclosure: Klant

Leverancier

Geen eisen hieromtrent.

Het onderhoudscontract mag niet ingekeken worden door derden om zo conflicten betreffende de prijsovereenkomst in te dekken. Individuele voorwaarden kunnen echter wel in bijlage vermeld worden, waarop een non-disclosure geldt. Het gemeenschappelijke deel is geen probleem.

14. Aansprakelijkheid: Klant

Leverancier

Fouten in het programma zijn te wijten aan foute programmering door de leverancier. De leverancier heeft volledige aansprakelijkheid.

Als de klant foutieve resultaten krijgt door fouten in het programma, dan moet hij dit binnen opgelegde termijn melden. Meldt hij dit niet of te laat, dan is hij zelf aansprakelijk hiervoor.


89

7.5 Courante conflictoorzaken 7.5.1

Wie is uiteindelijk eigenaar van de software?

Een veelvoorkomende misopvatting is dat de klant denkt dat als hij de software “aankoopt”, hij hierdoor eigenaar wordt van de software en ermee doen wat hij wil, zoals die aanpassen naar eigen behoeften. De auteur blijft echter eigenaar. De klant betaalt voor slechts het gebruik ervan via een gebruikslicentie of huurformule. De klant kan wel eigenaar worden door een overdracht van het vermogensrecht. Meer uitleg hierover is te vinden in het hoofdstuk “Informaticarecht”.

7.5.2

Hoe worden updates toegepast?

Als men spreekt van updates aanbieden, kan dit een ruime betekenis hebben. Worden ze gewoon door de leverancier ter beschikking gesteld op Internet of een ander medium? Zal de leverancier deze zelf installeren of op zijn minst helpen bij problemen bij het toepassen ervan? Is een niet voorziene tussenkomst wel inbegrepen in de prijs van het onderhoudscontract? Dit zijn vragen waar men bij het aangaan van een contract niet bij stilstaat. De updates worden aangeboden en men is tevreden. Dergelijke zaken kunnen niet gedetailleerd genoeg beschreven staan in het contract.

7.5.3

Prioriteiten

De definitie van soorten fouten kan ook voor verwarring zorgen. Een kritische fout zal een hogere prioriteit moeten krijgen, maar vanaf wanneer is die fout kritisch? De softwareleverancier kan dit moeilijk in de plaats van de klant beslissen. Die kent immers de bedrijfsprocessen niet zo goed. Daarom is het noodzakelijk dat er over zulke zaken onderhandeld kan worden tijdens het opstellen van het contract.

7.5.4

Prijswijzigingen

Veel contracten spreken over de geldigheid van de prijzen volgens de recentste prijslijst. Maar is er een methode waarmee de prijzen bepaald worden? Op wat is die methode gebaseerd? Zijn de prijzen geplafonneerd? Pieterjan Donck & Dries Vanderhaeghen

90

7.5.5

Conflicten met andere software

Als de software niet correct meer functioneert, kan de oorzaak misschien liggen bij software van derden. Hoe gaat de softwareleverancier daarmee om? Wie controleert waar de oorzaak ligt en wie betaalt dit?


91

7.6 Evaluatiemethode: flowchart Aan de hand van de kennis die verworven werd doorheen het eindwerk en de softwareonderhoudscontracten die onderzocht werden, kwam een evaluatiemethode tot stand in de vorm van een flowchart. De bedoeling is om van een bepaald softwareonderhoudscontract een idee te krijgen wat de waarde ervan is. De waarde is van morele aard. Dit wil zeggen dat het financiële aspect in deze flowchart buiten beschouwing gelaten wordt. De waarde wordt uitgedrukt in een score. Een contract met een hoge score zal misschien wel een hogere kostprijs hebben omdat die meer service kan inhouden, maar dit is geen enkele zekerheid. De

flowchart

is

een

verzameling

van

alle

mogelijke

onderdelen

die

in

een

softwareonderhoudscontract kunnen voorkomen en die, na studie, belangrijk geacht worden voor het vermijden van mogelijke conflicten. Elk onderdeel heeft een multiplicator (groen) die als doorwegingsfactor dienst doet. Een onderdeel met een hogere multiplicator zal dus belangrijker zijn en meer invloed hebben op de eindscore. Elk onderdeel bevat verschillende opties. Aan elke optie hangt een scorecijfer vast (blauw). Komt een onderdeel niet voor, dan is dat scorecijfer daarvan gewoonweg nul. Soms kan men meerdere opties aanduiden. Er zijn eveneens tips voorzien voor mocht een onderdeel niet aanwezig zijn, of mocht een minderwaardige optie van toepassing zijn. De verkregen score dient om de waarde van verschillende contracten te kunnen vergelijken. Heeft het ene contract een lagere score met een hogere kostprijs, dan kunnen daarbij bedenkingen gemaakt worden. Met deze flowchart is het dan ook mogelijk om

het

contract

bij

te

sturen

door

onderhandeling

met

de

andere

partij.

Hoe hoger de totale score, hoe completer het contract en dus hoe minder kans op conflicten.


92


93


94


95

17. Escalatie procedure

Wordt er in het contract een procedure uitgewerkt wat er moet gebeuren wanneer er een conflict is tussen beide partijen?

a.

x 0,5

Het klinkt misschien niet nodig maar wanneer het zover is kan dit u veel zorgen besparen.

Ja

Wordt er gesproken over een handleiding. Dit om zodoende verkeerd gebruik te vermijden.

18. Handleiding

1

x1

a.

Beperking handelingen

Bescherming van de leverancier tegen ongeoorloofd gebruik.

1

b.

Handleiding

Gedetailleerde handleiding van alle mogelijke handelingen.

3

c.

Opleiding

Gebruikers en/of administrators worden opgeleid.

4

d.

Aanpassingshandleiding

De handleiding wordt bij elke verandering van programmafunctie aangepast en geleverd. Desnoods op voorhand om over een nieuwe versie te beslissen.

3

Aan de hand van een dossier kan het gemakkelijk zijn om ITverantwoordelijken te helpen in het onderhouden van een programma.

19. Dossier a.

x 0,5

Wordt er een technische fiche meegegeven met alle info? Zowel programmeercode als plaats van installatie.

Technische fiche

1

Uitleg van de verschillende velden: Start onderhoudscontract: Vanaf

wanneer

start

maatwerksoftware

het

onderhoudscontract?

aangezien

men

werkt

Dit met

komt

vooral

verschillende

van

pas

bij

opleveringen.

Het onderhoudscontract gaat van kracht bij het ondertekenen van het aankoopcontract. Men betaalt voor onderhoud tijdens het ontwikkelen. Dit betekent dat men dus betaalt voor het ontwikkelen en dan nog eens voor onderhoud wanneer dit niet nodig is. Men betaalt

dus

dubbel

voor

eenzelfde

periode.

Het onderhoudscontract start bij de eerste oplevering. Men betaalt voor het oplossen van de fouten van een onvolledig programma. Dit is natuurlijk niet correct. De fouten die tijdens het opbouwen van de software verschijnen, moeten opgelost worden op kosten van

de

leverancier.

Het onderhoudscontract gaat van kracht na de definitieve opleiding. Dit is de correcte manier. Zowel de leverancier als de klant verwacht een goed afgewerkt product. De fouten die nu verschijnen, zijn fouten die men niet verwacht of verkreeg tijdens te testfase. Met behulp van het onderhoudscontract zorgt de leverancier om deze fouten op te lossen.


96

Ondersteuningsperiode: Wordt er gesproken omtrent hoe lang de leverancier de aangekochte software ondersteund? De leverancier biedt een ondersteuningsperiode van minder dan 5 jaar. Hier wordt er aangeraden om op te letten omdat de leverancier de ondersteuning kan stopzetten. De leverancier biedt een ondersteuning van minimum 5 jaar. Dit is een goede periode aangezien 5 jaar veelal gezien wordt als de terugverdien- of investeringsperiode. De leverancier biedt een ondersteuning van minimum 10 jaar. Dit is goed voor programma’s die sterk afhankelijk zijn van wettelijke wijzigingen. Contractduur: Hoe

lang

is

de

duur

van

het

onderhoudscontract?

De contractduur wordt jaar per jaar vernieuwd. Dit is de meest voorkomende vorm. Het is positief dat de klant zijn contract ieder jaar kan opzeggen. Dit komt zeker van pas als de klant

al

reeds

een

jaar

geen

fouten

meer

krijgt.

De contractduur heeft een periode van meerdere jaren. Leveranciers die contracten opstellen met meerdere jaren hebben meestal de intentie om hen zeker te stellen van inkomsten. Als klant is het natuurlijk niet aangenaam om meerdere jaren te moeten betalen als het blijkt dat het niet nodig geweest is. Contract verplicht: Is

het

onderhoudscontract

verplicht?

Wanneer het contract verplicht is, kan de klant dit zien als een nadeel, maar hij kan dit ook bekijken als een zekerheid dat de gevonden fouten voor een vaste prijs opgelost worden. Het is wel aangeraden dat de klanten proberen een contract te verkrijgen die maar

één

jaar

van

kracht

blijft.

Wanneer dit niet verplicht is, dan is het om dezelfde reden als hierboven aangeraden toch een onderhoudscontract van minimum één jaar aan te gaan. Melding / respons op fouten: Is er een manier waarop melding van een fout en/of de respons van de leverancier na het melden

van

een

fout

moet

afgehandeld

worden?

Het melden kan gebeuren via telefoon waardoor er dus directe respons is. In dit geval moet de leverancier geen bevestiging geven dat hij de melding van de fout heeft ontvangen. Pieterjan Donck & Dries Vanderhaeghen

97

Het melden kan gebeuren per fax. Het wordt aangeraden om afspraken te maken dat de leverancier laat weten dat ze de melding goed ontvangen hebben. Dit is van groot belang als

er

een

verbetertijd

afgesproken

is.

Het melden kan gebeuren per email. Het wordt aangeraden om afspraken te maken dat de leverancier laat weten dat ze de melding goed ontvangen hebben. Het melden via email kan men laten controleren door “het laten weten wanneer gelezen” aan te vinken. Dit is terug van groot belang als er een verbetertijd afgesproken is. Aantal verbeteringen: Wordt

het

aantal

verbeteringen

van

fouten

al

dan

niet

beperkt?

Een beperkt aantal verbeteringen kan voor de klant soms te weinig lijken. Maar het geeft wel een zekerheid dat de klant die aantal aanpassingen zal krijgen wanneer de klant deze nodig

heeft.

Een onbeperkt aantal verbeteringen betekent dat alle mogelijke fouten zonder enige kost zullen opgelost worden. Dit zal veelal toegepast worden in software die zijn diensten reeds bewezen heeft zoals pakketsoftware. Definities: Is er een verklarende woordenlijst aanwezig in het contract? Of zijn er definities gedefinieerd

in

het

onderhoudscontract?

Een verklarende woordenlijst in het onderhoudscontract is een positief punt. Dit zorgt dat er geen conflict kan ontstaan omtrent het anders begrijpen van een woord. Als er verschillende soorten fouten aanwezig zijn is het nuttig dat deze duidelijk omschreven zijn. Dit komt zeker van pas wanneer men gebruik maakt van prioriteiten in het

onderhoudscontract.

De omvang van een aanpassing is ook van belang. Zo kan een update verschillende fix’en bevatten, maar wanneer dit niet duidelijk gedefinieerd staat kan voor een leverancier een update

hetzelfde

bevatten

als

een

fix

of

omgekeerd.

Verbeteringen kunnen veel bevatten. Zo kan de ene aanpassing een verbetering van een fout zijn en de andere een aanpassing van het programma met extra functies zijn. Wanneer men in het onderhoudscontract spreekt over aantal verbeteringen is het zeker nodig dat deze verbeteringen duidelijk omschreven worden. Zo is er geen misverstand mogelijk wanneer de klant denkt dat de aanpassing ingerekend is terwijl het om een ander soort aanpassing gaat.


98

Verbeteringstijd: Is er een vastgelegde tijd in het onderhoudscontract vermeld en wordt er gebruik gemaakt

van

prioriteiten?

Met prioriteiten verwijst men of dat er een verschil gemaakt wordt tussen ernstige fouten en gewone gebruiksfouten. Zo kan er voor een ernstige fout een veel kortere verbeteringstijd

gegeven

worden

dan

voor

een

minder

ernstige

fout.

Zonder prioriteit betekent niet dat er geen verbeteringstijd afgesproken is. Hier zal een vastgelegde tijd voor alle fouten gelijk zijn. Enig minpunt kan zijn dat ernstige fouten soms niet zo snel als gewenst opgelost zullen worden. Nieuwe releases: Zijn

er

nieuwe

releases

ingecalculeerd

in

het

onderhoudscontract?

Als de nieuwe releases ingecalculeerd zijn kan dit een grote extra kost vermijden. Want een nieuwe versie is meestal een zo goed als nieuw programma. Als voorbeeld kan men kijken

naar

Microsoft.

Het kan ook zijn dat nieuwe releases niet ingecalculeerd zijn maar er kan in het onderhoudscontract wel vermeld zijn dat nieuwe releases kunnen verkregen worden aan een speciaal tarief. Ook hier kan men een voorbeeld halen bij Microsoft. Nieuwe functies: Ben

je

als

klant

verplicht

om

nieuwe

functies

te

implementeren?

Als de klant verplicht is om nieuwe functies te implementeren die hij niet nodig heeft dan kan dit voor een klant met een onderhoudscontract geen probleem zijn. Fouten die optreden

door

deze

implementatie

vallen

onder

het

onderhoudscontract.

Het niet verplichten van het implementeren van nieuwe functies is voor de klant positief zolang hij deze niet nodig heeft. Zorg er als klant wel voor dat het onderhoudscontract ook nog van kracht blijft als je deze functies niet implementeert. Change Management: Wordt er in het onderhoudscontact gesproken over de gevolgen in het gebruik door wijzigingen

van

het

programma?

Bij minor impact zijn de gevolgen zeer miniem. De wijzigingen kunnen zorgen voor een intuïtiever

en

vlotter

gebruik

of

kunnen

meer

helpteksten

zijn.

Bij moderate impact zijn de gevolgen iets groter. Er zijn handleidingen of extra uitleg via de

helpdesk

nodig

om

de


nieuwe

functies

te

kunnen

gebruiken. 99

Bij major impact zijn de gevolgen heel groot. Er zijn extra opleidingen nodig om de nieuwe functies te kunnen gebruiken. Dit zou dus een grote kost kunnen zijn voor een kleine organisatie. Informatieplicht: Staat er in het onderhoudscontract vermeld of de leverancier verplicht is van informatie te geven? Tijdens de oplosperiode kan het voor de klant positief overkomen als de leverancier op geregelde tijdstippen informatie geeft omtrent het oplossen van zijn fouten. Ook wanneer er enige problemen zijn tijdens het oplossen. De klant zal een tevreden klant zijn wanneer er

informatie

doorgespeeld

wordt.

De klant kan veel tijd uitsparen wanneer de leverancier meldt als er verbeteringen van gekende fouten aangeboden wordt. Moest dit niet het geval zijn dan zou de klant, wanneer er eenzelfde fout voordoet, veel tijd verliezen tijdens het melden van de fout en wachten van de verbetering. Beschikbaarheid leverancier: Op

welk

uren

kan

de

klant

de

diensten

van

de

leverancier

verkrijgen?

Helpdesk (24/24) betekent dat men via een helpdesk de leverancier gedurende de ganse dag kan bereiken. Dit komt zeker van pas in bedrijven die ook gedurende de ganse dag werken

of

nachtdiensten

leveren.

Als er tijdens de kantooruren diensten geleverd worden moet men opletten of deze uren overeenkomen met de werkuren van de klant. Meestal zullen deze overeenkomen maar toch

wordt

het

aangeraden

dit

eens

te

bekijken.

Het werken met een vaste contactpersoon is een extra punt dat toch belangrijk kan zijn. Als er tijdens de communicatie kan gecommuniceerd worden met een contactpersoon die uw situatie kent kan dit vele frustraties van de klant wegnemen. Want als klant kan het soms vervelend zijn om telkens opnieuw de situatie te moeten uitleggen. Wetswijzigingen: Wanneer het programma afhankelijk is van wetswijzigingen, worden de wijzigingen dan toegepast

op

vraag

van

de

klant

of

automatisch

door

de

leverancier?

Wanneer deze automatisch aangepast wordt moet de klant zich geen zorgen maken.


100

Prijzen geplafonneerd: Wordt er in het onderhoudscontract vermeld of de prijs van het onderhoudscontract geplafonneerd is? Dit is een groot voordeel zodat de klant niet verrast wordt door de prijs. Wanneer de prijs geplafonneerd is met een formule, gebeurt dit meestal met de loonkosten

gepubliceerd

door

Agoria

[10].

De prijzen kunnen ook afhankelijk zijn van de laatste prijslijst van de leverancier. De klant kan hieruit concluderen dat de prijs voor iedere klant hetzelfde is. Onkosten: Moet er extra betaald worden voor onkosten wanneer men een technicus moet sturen? Wanneer dit het geval is dan is het aangeraden om een vast uurtarief en kilometervergoeding af te spreken. Handleiding: Wordt er in het contract gesproken over eventuele documentatie en handleidingen voor het

gebruik

van

de

software?

Dit om het misbruik van het programma tegen te gaan, het gebruik van alle mogelijke handelingen te bespreken, te beslissen of het nodig zal zijn de gebruikers op te leiden en wordt er een handleiding geleverd bij levering van een nieuwe versie. Dossier: Wordt

er

een

dossier

meegegeven

aan

de

klant?

Dit dossier bevat alle gegevens voor de IT-verantwoordelijke bij de klant. Dit dossier bevat zowel de programmeercode, plaats van installatie, enz. Escalatieprocedure: Is

er

een

escalatieprocedure

uitgewerkt

in

het

onderhoudscontract?

De escalatieprocedure bespreekt wat er moet gebeuren wanneer er een conflict is tussen de klant en de leverancier. Dit zorgt dat er nog extra conflicten vermeden worden wanneer er een oplossing gezocht wordt.


101

Contract 1 1. Start onderhoudscontract 2. Ondersteuningsperiode 3. Contractduur 4. Contract verplicht? 5. Melding/Respons op fouten 6. Aantal verbeteringen 7. Definities 8. Verbeteringstijd 9. Nieuwe releases 10. Nieuwe functies 11. Change management 12. Informatieplicht 13. Beschikbaarheid leverancier 14. Wetswijzigingen 15. Prijzen geplafonneerd 16. Onkosten 17. Escalatieprocedure 18. Handleiding 19. Dossier


Contract 2

0 0 3 0 3 1 1,5 3 0 2 1 3 0 0,5 2 1 0

Contract 3

6 1,5 3 0 2 1 0 0 3 0 0 2 2 0 0 0 0

Contract 4

2 0 3 2 2 0 2,5 3 3 2 1 0 1 0 1 1 0

Contract 5

0 1,5 3 1 2 1 0 3 1,5 2 0 0 1 0 0 0 0

Contract 6

2 0 1,5 0 1 1 0,5 0 3 0 0 0 1 0 0 1 0

Contract 7

Contract 8

Contract 9

Contract 10

0 0 0 1 1 0 0,5 0 3 0 0 0 0 0

2 3 1,5 1 1 1 2,5 3 3 2 1 2 1 0

0 0 3 2 2 1 1 3 0 0 0 0 1 0

0 0 3 0 1 1 2 3 3 0 0 0 4 0

1 0

0 0

0 0

0 0

2 4,5 3 1 2 1 0 1,5 1,5 2 0 3 1 0 2 1 0

0

0

0

0

0

0

0

0

0

0

21

20,5

23,5

16

11

6,5

24

13

17

25,5

102

19. Dossier

beoordeelde contracten

18. Handleiding 17. Escalatieprocedure

30

16. Onkosten 15. Prijzen geplafonneerd

score

25

14. Wetswijzigingen 13. Beschikbaarheid leverancier

20

12. Informatieplicht

15

11. Change management 10. Nieuwe functies

10

9. Nieuwe releases 8. Verbeteringstijd 7. Definities

5

6. Aantal verbeteringen 5. Melding/Respons op fouten

0

4. Contract verplicht? 3. Contractduur

1

2

3

4

5

6

7

8

9

10

contract

Figuur 9: Beoordeelde contracten


103

2. Ondersteuningsperiode 1. Start onderhoudscontract

8 Besluit Pieterjan Toen men begin dit jaar een keuze verwachtte welk eindwerk je wou uitvoeren was mijn eerste keuze het maken van een theoretisch eindwerk. De reden hiertoe lag bij het doorlopen van de opleiding Multimedia & Communicatie Technologie (MCT). Tijdens het laatste jaar van deze opleiding moest er ook een eindwerk worden ontwikkeld. Het betrof een database gestuurde e-commerce site die samen ontwikkeld werd met een collega student. Door het reeds ontwikkeld hebben van een praktisch eindwerk was mijn beslissing

snel

gemaakt.

Een

theoretisch

eindwerk

genoot

mijn

voorkeur.

Tussen de vele voorstellen van de school zat een interessant eindwerk over de asymmetrie van informatie bij het afsluiten van onderhoudscontracten. Gezien mijn vorig eindwerk een software gebaseerd programma was leek de keuze voor de hand liggend. Er zijn weinig studies die onderzoek doen rond dit onderwerp. Velen denken dat software geen fouten meer bevat. Maar dit is een illusie. Iedereen heeft wel eens een foutmelding gekregen tijdens het gebruiken van een computer. Waarom zou dit dan niet voorkomen in een pakket- of maatwerksoftware? Door de mogelijke omvang van dit eindwerk werd er terecht gemeend dat dit een eindwerk was voor twee studenten. Het was de bedoeling een groot aantal onderhoudscontracten te ontleden. Het voordeel om met twee personen te werken is dat elk een eigen visie heeft op verschillende punten uit een onderhoudscontract. De

intentie

was

om

tal

van

bedrijven

te

contacteren

om

zo

bestaande

onderhoudscontracten in handen te krijgen. Deze zouden ontleed en samengevat worden om van daaruit een benchmark systeem te ontwikkelen voor het ontleden van bestaande en nieuwe onderhoudscontracten. Om dit systeem te kunnen staven hadden we een groot aantal onderhoudscontracten nodig. Door de eerder geringe reactie van de bedrijven waren we op een gegeven moment ten einde raad. Dankzij de steun en de kennis van onze promotor werd er toen beslist om aan de hand van verkregen onderhoudscontracten de mogelijke conflictpunten te verzamelen. We waren terug vertrokken en zijn tot dit resultaat gekomen. De samenwerking met Dries was een zeer aangename ervaring. We kenden elkaar reeds vanuit de groep maar het samenwerken heeft van ons een hecht team gemaakt. Soms liep onze mening wel eens uiteen maar door het aanhoren van ieder zijn argumenten kwamen we steeds tot een goede beslissing. Door deze samenwerking is er een goede Pieterjan Donck & Dries Vanderhaeghen

104

basis opgebouwd om het werken in team gedurende mijn carrière positief te laten verlopen. Uit dit eindwerk hebben we de conclusie kunnen maken dat veel kleine en middelgrote ondernemingen niet volwassen zijn in het beheren van hun informatica-infrastructuur. Door deze onvolwassenheid hebben deze organisaties niet de kennis

om te

onderhandelen bij het afsluiten van een correct onderhoudscontract. Als ze al het nut inzien van een onderhoudscontract. Met dit eindwerk hopen we deze organisaties de nodige kennis te laten verwerven en zich zo sterker op te stellen tijdens het onderhandelen tussen de partijen. Dit eindwerk heeft mij ook veel bijgebracht omtrent IT in het bedrijfsleven. Ik had nooit kunnen vermoeden dat organisaties soms de nodige kennis ontbreken om een solide onderhoudscontract te verkrijgen. De weinige respons heeft mij ook een idee gegeven van hoe veel organisaties omgaan met informatica. Ze hechten hier geen belang aan en zijn niet bereid om hun tijd te investeren in dergelijk onderzoek. Bij deze wil ik nogmaals onze promotor bedanken voor de vele steun die hij ons gegeven heeft. Zijn kennis van de bedrijfswereld en contracten hebben geholpen dit eindwerk tot een goed einde te brengen.


105

9 Besluit Dries De keuze van mijn eindwerk ging bewust naar iets niet-technisch omdat ik een gedetailleerd onderzoek naar technische zaken zoals USB, RS232, IPsec en andere nogal sterk tijdsgebonden vind wegens de snelle evolutie van dergelijke technieken. Ik wilde eerder iets onderzoeken wat op lange termijn nuttig kan zijn voor het management en voor een organisatie in het algemeen, maar waarvoor toch een technische onderbouw noodzakelijk is. Het eindwerkvoorstel omtrent een onderzoek naar de asymmetrie bij softwareonderhoudscontracten sprak mij daarom onmiddellijk aan. Dit thema heeft tot op heden nog maar weinig literatuur en er bestaat nog geen specifieke evaluatiemethode voor softwareonderhoudscontracten voor KMO’s. Daarom is het interessant om hierin een steentje bij te kunnen dragen. Onze promotor heeft gekozen om voor dit eindwerk twee studenten samen te laten werken. Voor dergelijk onderzoek is een visie uit verschillende hoeken namelijk veel efficiënter dan de mening van één persoon. Ook wegens de oorspronkelijke omvang en diepgang van het project was het beter om het werk te kunnen verdelen. Er werden namelijk een paar honderden bedrijven gecontacteerd en er zouden eveneens honderden contracten ontleed worden. Over de samenwerking tussen Pieterjan en mij ben ik erg tevreden. Een specifieke taakverdeling was er niet, maar we konden elkaar op elk moment aanvullen en bijstaan in diverse studies. Dit is iets wat bijdraagt tot de zelfzekerheid en efficiëntie om ons doel te bereiken. Projecten in het echte bedrijfsleven worden namelijk ook niet door één persoon uitgewerkt, maar wel door een goed georganiseerd team. Als voorbereiding tot het bedrijfsleven heeft dit eindwerk op dit vlak dus ook een meerwaarde geleverd. Desondanks de povere medewerking van de bedrijven hebben wij, dankzij de goede begeleiding van onze promotor, toch een zinvol onderzoek kunnen verrichten. Het werd ons duidelijk dat het probleem van asymmetrische informatie erg van toepassing is de ITwereld. Wij onderzochten daarvan enkel de softwareonderhoudscontracten omdat we hierdoor een diepgaander onderzoek konden verrichten en omdat dergelijke contracten nog eens extra onderhevig zijn aan deze problematiek. Dit is te verklaren door de ontastbaarheid van software, het nut van onderhoud die veelal over het hoofd gezien wordt, en de beperkte kennis inzake IT bij KMO’s. Zo goed als elke KMO heeft namelijk te


106

maken met softwareonderhoudscontracten die hij voor zijn neus voorgeschoteld krijgt en de waarde ervan niet kan inschatten. Het eindwerk heeft mij een duidelijk inzicht verworven in de wereld van de onderhoudscontracten. Voordien had ik er enkel eens over gehoord en beknopt in de lessen gezien. Daardoor zag ik misschien ook het nut niet volledig in van deze overeenkomsten. Dat is op dit moment volledig veranderd en we kunnen ons gerust experts noemen om onderhoudscontracten te ontleden en te beoordelen. Wij hopen dat deze thesis ook een leidraad kan betekenen voor KMO’s om over dit onderwerp meer kennis te verwerven en zich zo sterker tegenover andere partijen te kunnen opstellen. Ook gaan we vanaf nu meer aandacht besteden aan de asymmetrie van informatie en mensen hierop wijzen. Het is een fenomeen waar wij, informatici, veel mee te maken zullen krijgen. Dit eindwerk heeft mij op dit vlak een grote meerwaarde geleverd over deze problematiek, die zeer terecht werd aangekaart.


107

Literatuurlijst [1]

Devos J., Cursus ICT-Management, IT-Management, Hogeschool West-Vlaanderen

departement Provinciale Industriële Hogeschool, Kortrijk, Cursoa, 2004 [2]

Dumortier J., Informatica- en telecommunicatierecht, Leuven, Acco, 1999, 215p.,

ISBN 90-334-4334-1 [3]

De

Keyser

S.,

De

Vulder

K.

en

Van

Camp

S.,

Hoekstenen

van

informaticacontracten, Mechelen, Kluwer, 2004, 211p. [4]

De Muynck Harald, Informatica: juridische aspecten: een overzicht, Heverlee,

Lannoo Campus, 2004, 148 p., ISBN 90-209-5666-3 [5]

Keustermans J. A., Informatica en recht: Praktische juridische gids voor de

informaticaleverancier en –gebruiker, XVI, Diegem, Kluwer, 2002, 214p., ISBN 90-5928034-2 [6]

Software Engineering Institute, Capability Maturity Model® Integration, Pittsburgh,

2 februari 2006, Beschikbaar op het World Wide Web: http://www.sei.cmu.edu/cmmi, [2006] [7]

Federale Overheidsdienst Economie, KMO, Middenstand en Energie, De Belgische

Dienst voor de Intellectuele Eigendom: Auteursrecht en naburige rechten, Brussel, 16 maart

2004,

Beschikbaar

op

het

World

Wide

Web:

http://mineco.fgov.be/intellectual_property/patents/author_law_nl.htm#, [03-2006] [8]

Judirat, Het portaal van de Rechterlijke macht van België, België, Beschikbaar op

het World Wide Web: http://www.juridat.be, [03-2006] [9]

United

Kingdom

Software

Metrics

Association,

Standard Metrics for the

Assessment, Benchmarking, and Management of Software Maintenance and Support Activities, Manual met standaarden, Londen, 19 augustus 2005, 38p., Beschikbaar op het World Wide Web: http://www.uksma.co.uk/portal/dl.asp [12-2005] [10]

Agoria, Federatie van de technologische industrie, Brussel, Beschikbaar op het

World Wide Web: http://www.agoria.be, [04-2006] [11]

Katholieke Universiteit Leuven, Faculteit Rechtsgeleerdheid, Leuven, Beschikbaar

op het World Wide Web: http://www.law.kuleuven.ac.be [03-2006] Pieterjan Donck & Dries Vanderhaeghen

VI

[12]

Katholieke Universiteit Leuven, ICRI: Interdisciplinair Centrum voor Recht en ICT,

Leuven, Beschikbaar op het World Wide Web: http://www.icri.be, [03-2006] [13]

Pauwels

W.,

Roodhooft

F.,

De

principaal/agent-literatuur:

een

overzicht,

Economisch en sociaal tijdschrift 1, 1994, 29p., [05-2006] [14]

Software Improvement Group, Pakket of

Beschikbaar

op

het

World

maatwerksoftware?, Amsterdam,

Wide

Web:

http://www.software-

improvers.com/HOME/Topics/packsoft?lang=nl [25-05-2006] [15]

Digilinks, Pakket of maatwerk, De keuze voor eigen ontwikkeling is een

strategische

keuze,

Rotselaar,

Beschikbaar

op

het

World

Wide

Web:

http://www.digilinks.be/p/PAKKETMAATWERK [25-05-2006] [16] 1998,

Ecoline, De wereldwijze consument, Informatie: een consumentenrecht?, Brussel, Beschikbaar

op

het

World

Wide

Web:

http://www.ecoline.org/verde/publicaties/wwcons/fiche08.shtml [25-05-2006] [17]

Glass R.L., “Error-Free Software Remains Extremely Elusive”, IEEE Software,

jan/feb 2003, vol.20 , p. 103-104 [12-2005] [18]

Akerlof G.A., “The Market for 'Lemons': Quality Uncertainty and the Market

Mechanism”, Quarterly Journal of Economics, 1970, p. 488-500 [12-2005] [19]

Webster B.F., PricewaterhouseCoopers, “Patterns in IT Litigation: System Failure

(1976-2000)”, 2001, New York, 14p., Beschikbaar op het World Wide Web: http://www.webster.edu/ftleonardwood/COMP5940/Student_Files/Project_Failure/Project _Failure_Profiles.pdf [12-2005]


VII

Bijlage Projectfiche Projectfiche

versie 2.1

18/05/06

Projecttitel: Onderzoek naar de asymmetrie van informatie bij het afsluiten en uitvoeren van softwareonderhoudscontracten Projecttype: Studie / Onderzoek Bedrijf: Intern eindwerk Projectteam: Pieterjan Donck in functie van projectleider Dries Vanderhaeghen in functie van projectleider Jan Devos in functie van projecteigenaar & interne promotor Doelstelling: o o o o o

Verschillende contracten worden geanalyseerd en met elkaar vergeleken. Onderzoeken hoe kan de asymmetrie van informatie tussen klant en leverancier weggewerkt kan worden. Een juist evenwicht vinden tussen de technische parameters en de juridische vormgeving van het onderhoudscontract. Bestaande wetenschappelijke methodes voor het evalueren van softwarecontracten worden van naderbij bekeken. Nagaan in welke situaties en door welke oorzaken er conflicten ontstaan tussen de softwareleverancier en zijn klant.

Motivering: o

o o

Door de overmacht van de softwareleverancier kunnen KMO’s, met dikwijls onvoldoende kennis terzake, de waarde niet inschatten van het te tekenen contract. Advocaten zijn eveneens meestal onvoldoende technisch onderlegd. Asymmetrie van informatie leidt vroeg of laat tot conflicten.

Risico’s: o

Bedrijven die schrik hebben om mee te werken omwille van hun bedrijfsgeheimen, of eenvoudigweg door gebrek aan interesse.


1

Kwaliteitsvereisten: Er wordt rekening gehouden met het Belgisch Wettelijk Contract (Wettelijk vermeld). Wij houden ons aan de geheimhouding van de identiteit van de meewerkende bedrijven. De verkregen gegevens worden uitsluitend voor academische doeleinden gebruikt.

o o

Input:

Onderhoudscontracten uit bedrijven Bestaande studies in verband met onderhoudscontracten Lectuur over contracten algemeen, de Belgische wet, richtlijnen van ervaren organisaties en bedrijven.

Output: Besluiten Evaluatiemethode Hoe informatie asymmetrie wegwerken. Hoe conflictsituaties vermijden. Beoordelingsfactoren: o o o o o

Omvang van het werk Diepgang van de studie Theoretische en Statistische onderbouw Synthese Conclusie

Project beperkingen: o o o

Beperking van omvang van het aantal te onderzoeken contracten. Het gaat uitsluitend om onderhoudscontracten op software, dus geen hardware of andere contracten. Geen technische diepgang naar de kwaliteit van de softwareprogrammatie.


2

Goedgekeurd

door

Goedgekeurd

projecteigenaar:

projectleider:

Naam: Jan Devos

Naam:

Pieterjan

door

Donck

&

Datum:

Handtekening:

door

projectteamleden:

Dries Vanderhaeghen

Datum:

Goedgekeurd

Naam: Datum: Handtekening:

Handtekening:

Mijlpalen: 30/11/05

Een honderdtal bedrijven gecontacteerd hebben.

24/12/05

Groot deel van contracten bestudeerd hebben.

02/02/06

Opgedane kennis op papier hebben. Tussentijdse verdediging voorbereiden. Onderzoek naar wetenschappelijke methodes.

3/03/06

Nieuwe bedrijven gecontacteerd te hebben, argumentatie nagaan.

31/03/06

Alle deelprojecten afgerond.

13/04/06

Rollenspel uitwerken.

4/05/06

Evaluatiemethode klaar.

18/05/06

Contracten met evaluatiemethode doorlopen.

31/05/06

Thesis klaar.


3

Brief aan de bedrijven


4

Bedrijvencontactdagen Om op korte tijd een groot aantal bedrijven rechtstreeks te kunnen contacteren, raadde onze promotor aan om de Bedrijvencontactdagen in Kortrijk te bezoeken. Dit is een beurs waar meer dan 500 bedrijven aanwezig zijn, bedoeld om zakelijke contacten te leggen en de

relaties

te

verbeteren

met

klanten

en

leveranciers.

Wij zagen de kans om daar de interesse te peilen over ons eindwerk. Zo kregen we rechtstreeks argumenteringen en konden we misschien supplementaire contracten bemachtigen. Onze ervaring was dat men meestal wel geïnteresseerd was, maar toch eerst toelating nodig had van hun overste. Uiteindelijk kwam er weinig reactie uit de bus. Maar we hebben toch hier en daar interessante verhalen gehoord, over bedrijven die zelf al conflicten gehad hebben met hun softwareleverancier en die daaruit lessen getrokken hebben. Toch zijn we een ervaring rijker door veel uiteenlopende meningen te horen.

Figuur 10: Bedrijvencontactdagen 2005


5


6


7

Logboek Week

Omschrijving

1

Eindwerk definiëren in overleg met eindwerkpromotor

2

Projectfiche opstellen + taakverdeling

3

Statistische relevantie nagaan. Contactgegevens van bedrijven verzamelen

4

Bedrijven contacteren per e-mail

5

Contactgegevens van bedrijven verzamelen (totaal 315 bedrijven)

6

Bedrijven contacteren per briefpost en deur-tot-deur.

7

Onderhoudscontracten analyseren.

8

Onderhoudscontracten analyseren.

9

Onderhoudscontracten analyseren + informatie verzamelen in contractenlijst

10

Lectuur: Hoekstenen van informaticacontracten (S. De Keyser) Informatica: juridische aspecten: een overzicht (H. De Muynck) Informatica en recht: praktische juridische gids voor de informaticaleverancier en –gebruiker (J.A. Keustermans) UKSMA: Standard Metrics for the Assessment, Benchmarking and Management of Software Maintenance and Support Activities

11

Voorbereiding voor Bedrijvencontactdagen.


8

12

Bedrijvencontactdagen

expo

Kortrijk:

Interesse

peilen

bij

bedrijven:

argumenteringen en supplementaire contracten proberen krijgen. 13

Huidige status evalueren

14

Examenperiode

15

Examenperiode

16

Examenperiode

17

Examenperiode

18

Examenperiode

19

Tussentijdse evaluatie dmv presentatie en bijsturing

20

Vergadering over verderzetting en bijsturing

21

Bronnen zoeken en studie over asymmetrische informatie

22

Studie, informatie zoeken en analyseren.

23

(Kulak + sessie solliciteren)

24

Studie, informatie zoeken en analyseren.

25

(Studiereis China)

26

(Jobhappening PIH)

27

Lectuur en studie informaticarecht, SEI

28

Teksten schrijven voor thesis. (informaticarecht & SEI)

29

Rollenspel klant-leverancier

30

Flowchart opstellen over waardebepaling onderhoudscontracten


9

31

Flowchart opstellen over waardebepaling onderhoudscontracten

32

Structuur en inhoud thesis bepalen.

33

Schrijven thesis (bronvermeldingen)

34

Schrijven thesis

35

Schrijven thesis

36

Afwerken thesis (overleg, besluiten)


10

Onderzoek naar de asymmetrie van informatie bij het afsluiten en uitvoeren van softwareonderhoudscontracten

Recommend Documents