Automatisering van de informatievoorziening

Download de illustraties behorende bij het college: 141 KB

Inleiding

We bevinden ons in een tijd van snel veranderende organisaties. Dit veroorzaakt ook veel veranderingen in de informatiesystemen die binnen deze organisaties gebruikt worden. Voor de gebruikers van deze systemen is het van belang dat deze aanpassingen zo snel en zo efficiënt mogelijk worden uitgevoerd. Deze aanpassingen worden vaak door professionele externe organisaties uitgevoerd. Het gevolg hiervan is intensieve samenwerking tussen de opdrachtgever en -nemer totdat de opdracht is afgerond. In dit hoofdstuk laten we zien hoe dit proces verloopt en gestructureerd kan worden. Let wel dat we "nieuwbouw" ook als een aanpassing van de informatievoorziening beschouwen

Leerdoelen

Na het bestuderen van dit hoofdstuk wordt verwacht dat u weet:

• Uit welke fasen een aanpassing aan de informatievoorziening bestaat.
• Wat een leveringenplan is, en waarvoor het dient.

Opdrachtmanagement en projectmanagement

De relatie tussen een opdrachtgever en opdrachtnemer begint normaal gesproken op het moment dat de opdrachtgever een verzoek doet aan één of meerdere aanbieders om een dienst of product te leveren. Nadat dit allereerste contact heeft plaatsgevonden, stellen de aanbieders offertes op, waaruit door de opdrachtgever een keuze wordt gemaakt. Een offerte beschrijft hoe de aanbieder de opdracht uit zou willen voeren, zowel op het technische vlak als het organisatorische vlak.

Als beide partijen besluiten om met elkaar in zee te gaan, wordt er een contract gesloten waarin de opdracht wordt vastgelegd. Vanaf dat moment begint de opdrachtnemer aan het uitvoeren van de opdracht. Dit gebeurt meestal in projectvorm en zoals u al in hoofdstuk 10 kunt lezen, speelt projectmanagement daar een cruciale rol in.

Het ligt voor de hand, dat na oplevering van de gewenste producten en diensten, de relatie tussen de opdrachtgever en de opdrachtnemer beëindigd is, maar dat is niet juist. Met het opleveren van het product is de opdracht nog niet netjes afgesloten. Hiervoor is nog een aantal administratieve transacties nodig waarbij wordt vastgesteld of alle technische, management- en financiële aspecten van het contract juist zijn afgewikkeld. Ook zou u kunnen denken aan een klanttevredenheidsonderzoek dat de opdrachtnemer uitvoert. Ofwel : het einde van het project betekent nog niet het einde van de opdracht.

De gehele levenscyclus vanaf het verkrijgen van de opdracht tot aan het juist afronden ervan, wordt opdrachtmanagement genoemd. Uit onderstaande figuur blijken het onderscheid en de samenhang tussen opdrachtmanagement en projectmanagement.

Communicatieproblemen

Het contact tussen opdrachtgever en opdrachtnemer blijft niet beperkt tot het tekenen van een contract. Ook tijdens het uitvoeren van de opdracht zal er veelvuldig contact zijn. In de praktijk blijken er tussen opdrachtnemers en opdrachtgevers regelmatig communicatieproblemen op te treden. Soms valt dat beide partijen tijdens het uitvoeren van de opdracht niet eens op, maar is de opdrachtgever na oplevering ontevreden over dat wat hij gekregen heeft. Ondanks een maandenlange samenwerking blijkt vaak dat het resultaat niet helemaal overeenkomt met de eisen en verwachtingen die de opdrachtgever had toen hij het contract ondertekende. Om deze communicatieproblemen, veroorzaakt door het feit dat opdrachtnemers en opdrachtgevers vaak elkaars taal niet spreken, op te lossen heeft de Europese Commissie is in het begin van de jaren 90 een verzameling van richtlijnen opgesteld. Hierin is de contractuele opdrachtgever-opdrachtnemer-relatie bij uitbestedingen van aanpassingen aan informatiesystemen beschreven. Deze verzameling van richtlijnen is opgesteld vanuit een aantal primaire doelstellingen (uit Euromethod [Euromethod, Deventer, 1995]):

• Het vergroten van de vergelijkbaarheid van producten die worden opgeleverd bij de verschillende in Europa gebruikte ontwikkelmethoden voor informatiesystemen.
• Het verbeteren van de relatie tussen klanten en leveranciers van informatiesystemen, (waarbij met name aandacht wordt besteed aan contractonderhandelingen bij uitbesteding).
• Het bieden van handvaten bij de planning en inrichting van het project, waardoor projecten beter toe te spitsen zijn op de voor hen geldende specifieke omstandigheden.

Als deze doelstellingen worden gehaald, dan levert dat grote voordelen op voor zowel de opdrachtgever als de opdrachtnemer. In feite spreken de opdrachtgever en de opdrachtnemer dan dezelfde taal.

Fasen in een opdracht

Binnen een opdracht zijn, zoals uit onderstaande figuur blijkt, drie belangrijke processen te onderkennen:

• Het tenderproces, waarin de eisen aan het (toekomstige) informatiesysteem worden beschreven, en het proces dat systeem te realiseren wordt gedefinieerd en aan een opdrachtnemer worden uitbesteed.
• Het productieproces, waarin de feitelijke productie van de op te leveren producten en diensten plaatsvindt en de gewenste organisatorische veranderingen bij de opdrachtgever ten behoeve van de inbedding van een aangepast systeem in de organisatie wordt bereikt.
• Het voltooiingsproces, waarin de opdracht technisch en commercieel wordt afgerond.

Als een contract is gesloten, bevinden het informatiesysteem en de beschikbare documentatie zich in een bepaalde toestand. Dit wordt de begintoestand genoemd : het is de start van de uitvoeringsfase van het project. Het resultaat van het aanpassingsproces noemen we de eindtoestand van de uitvoeringsfase van het project. Uiteraard kunnen er verscheidene aanpassingen bij één informatiesysteem plaatsvinden, ieder met een bepaalde begin- en eindtoestand. De opdrachtgever kan iedere opdracht aan een andere opdrachtnemer uitbesteden, dit kan zelfs parallel.

Het tenderproces

Uitgangspunt voor het tenderproces is dat het voor de opdrachtgever helder is wat hij eigenlijk met de aanpassing wil bereiken en dat de beslissing genomen is om uitvoering van die aanpassing aan een opdrachtnemer uit te besteden.

Tijdens het tenderproces is er een viertal momenten waarop er in ieder geval contact plaats vindt tussen opdrachtgever en de aanbieder, deze momenten worden transacties genoemd, omdat er op deze momenten producten en/of diensten worden opgeleverd door de opdrachtgever en/of de aanbieder.

• De offerte-aanvraag wordt gestart nadat de klantorganisatie besloten heeft dat de informatiesystemen aangepast dienen te worden. De opdrachtgever moet bij het voorbereiden van de offerte-aanvraag een cruciale beslissing nemen, namelijk of het te bereiken doel in één enkele aanpassing zal worden bereikt, of in een reeks van aanpassingen. De vraag bij hierbij is: "is het risico dat het project onbeheersbaar zal blijken te zijn reëel?". Om eventuele risico’s bij een beoogde aanpassing te analyseren en voor de aanbieders inzichtelijk te maken, moet de opdrachtgever een extra document opleveren, dat een beschrijving biedt van de situatie en de aanpassing aan het informatiesysteem. Tevens dient de opdrachtgever zelf een voorlopig leveringenplan op te leveren, waarop de aanbieders hun offertes kunnen baseren. Verderop in dit hoofdstuk kunt u lezen wat wij onder een leveringenplan verstaan.
• In een offerte, wordt een voorstel voor de technische uitvoering door de aanbieder aan de opdrachtgever opgeleverd. In dit voorstel worden de volgende zaken door de aanbieder behandeld:
  • Begrip van de situatie bij de opdrachtgever.
  • Producten die samen oplossingen voorstellen.
  • Voorstellen voor veranderingen in de organisatie van de opdrachtgever die nodig zijn voor succesvolle invoering van het systeem.
  • Een aantal beslispunten in de productie- en voltooiingsprocessen.
  • Voorstellen voor de producten die bij ieder van de beslispunten moeten worden opgeleverd om een goed besluit te kunnen nemen.
• De offerteaanvraag van de klantorganisatie, bevat altijd een sluitingsdatum voor de ontvangst van de offerte. Deze datum correspondeert met de start van de offerte-evaluatie. De interne evaluatie leidt tot de beslissing welk voorstel voor de technische uitvoering gekozen wordt. Meer gedetailleerd zal de opdrachtgever in de leveranciersselectie in ieder geval drie activiteiten uitvoeren, namelijk het samenstellen van een offerte-evaluatieteam, het herbeoordelen van de probleemsituatie en de eindtoestand naar aanleiding van de ontvangen offertes, en het beoordelen van de geschiktheid van de voorstellen voor technische uitvoering.
• Een contracttoewijzing wordt gekenmerkt door onderhandelingen tussen de opdrachtgever en de gekozen opdrachtnemer over de uiteindelijke vorm van de technische inhoud en wordt afgesloten met het formeel ondertekenen van het contract of met het terugtrekken van één van beide partijen uit het contractproces.

In het productieproces levert de opdrachtnemer een aantal producten op. Dit kunnen inhoudelijke producten (het systeemontwerp, het systeem zelf, handleidingen), of leveringen van bestuurlijke informatie zijn (bijvoorbeeld plannen en rapportages). In beide gevallen vindt een beoordeling van de producten door de opdrachtgever plaats. Verder kan onder omstandigheden ook contractwijziging van toepassing zijn.

Een beoordeling van inhoudelijke producten komt normaal gesproken een aantal keren voor in het productieproces. Hierbij beslist de opdrachtnemer of de leveringen conform de eisen in het contract zijn en of ze klaar zijn voor levering aan de opdrachtgever.

De volgende activiteiten worden bij bovengenoemd proces uitgevoerd:

• Beoordelen van de producten door de opdrachtnemer, voordat ze aan de opdrachtgever geleverd worden.
• Leveren aan de opdrachtgever.
• Het beschikbaar stellen van middelen om de leveringen te beoordelen door de opdrachtgever.
• Validatie van de leveringen.
• Beslissen: oftewel de leveringen goedkeuren, accepteren, een deel van het werk van de eindleveringen over laten doen, de leveringen afwijzen en een contractwijziging starten.
• Correctie van leveringen door de opdrachtnemer, indien de opdrachtgever de leveringen niet heeft goedgekeurd.
• Acceptatie van correcties door de opdrachtgever.

de beoordeling van bestuurlijke producten is onder meer gericht op rapportage aan het management, beoordeling van projectrisico’s, beoordeling van haalbaarheid en kwaliteit van en voorstellen voor risico-oplossing, herplanning en middelentoewijzing. Zowel voor de opdrachtgever als de opdrachtnemer is het doel de haalbaarheid van de opdracht te verzekeren door risico’s bloot te leggen en preventieve acties te definiëren.

Bij een contractwijziging worden veranderingen op de inhoud van het contract geïdentificeerd en doorgevoerd.

Het voltooiingsproces

Het voltooiingsproces kent twee transacties, namelijk de beoordeling van eindleveringen en de contractvoltooiing.

Tijdens de beoordeling van eindleveringen ontvangt en beoordeelt de opdrachtgever de leveringen die tezamen de afgesproken eindtoestand vormen. Alle producten die in het contract overeengekomen zijn, moeten in hun uiteindelijke ontwikkel- en kwaliteitstoestand zijn. Dit begint met de beoordeling door de opdrachtnemer zelf of de eindleveringen overeenkomen met de eisen uit het contract en daarmee klaar zijn voor levering aan de klant. Vervolgens vindt de daadwerkelijke levering plaats van de leveringen door de leverancier. De opdrachtgever evalueert vervolgens de beschrijvingen of voert een acceptatietest van de systemen uit.

Contractvoltooiing is een administratieve transactie, waarbij wordt vastgesteld of de opdracht naar bevrediging voltooid is. Contractvoltooiing vindt plaats door de opdrachtgever en de opdrachtnemer gezamenlijk. Het bevat de activiteiten die nodig zijn om alle technische, management- en financiële aspecten van de opdracht af te wikkelen.

Relaties op contractniveau en projectniveau

Zoals u kunt zien in bovenstaand figuur worden er in een opdracht twee niveaus van relaties tussen opdrachtgever en opdrachtnemer onderscheiden, namelijk een relatie op contractniveau en een relatie op projectniveau. Het contractniveau betreft de belangrijkste beslissingen die de opdrachtgever moet nemen, de transacties tussen opdrachtgever en opdrachtnemer en de strategie die men kiest voor een succesvolle uitvoering van het project. Op projectniveau liggen een aantal werkvelden, waarover op contractniveau afspraken moeten worden gemaakt:

• Informatiesysteemontwikkeling: alle activiteiten gericht op de ontwikkeling van de producten en diensten in die gezamenlijk de aanpassing in het informatiesysteem vormen.
• Kwaliteitsborging: alle activiteiten die nodig zijn om het vertrouwen te bereiken dat een product of dienst aan zijn kwaliteitseisen voldoet.
• Configuratiemanagement: van de diverse onderdelen die samen de eindoplossing vormen, dienen versie- en status netjes beheerd te worden, om ervoor te zorgen dat de eindoplossing inderdaad samen is gesteld uit de juiste onderdelen. Alle activiteiten die in dit kader worden uitgevoerd worden gezamenlijk configuratiemanagement genoemd.

In zowel de organisatie van de opdrachtgever als de organisatie van de opdrachtnemer worden twee sleutelrollen onderscheiden die relevant zijn bij iedere formeel contact tussen opdrachtgever en opdrachtnemer. Dit zijn de contract- en de projectautoriteit.

• Contractautoriteit: de persoon of de groep van personen die de macht heeft om beslissingen te nemen met betrekking tot een specifiek contract
• Projectautoriteit: een persoon of een groep van personen die bij open issues in een specifiek project beslissingen kan nemen

Vanuit de klantorganisatie, de overheid of een andere externe partij, worden voorwaarden aan de aanpassingen in de informatiesystemen gesteld. Denk hierbij aan regelgeving door de overheid of standaards binnen de bedrijfstak. De autoriteiten zullen vaak ondersteuning van hun achterban nodig hebben om alle aspecten van de leveringen van producten of bestuurlijke informatie te goed te kunnen beoordelen. We onderscheiden daarbij de extra rollen van ‘organisatie-autoriteit’ en van operationele experts. Organisatie-autoriteiten zijn betrokken vanuit de organisatie die vanuit een strategisch oogpunt eisen en beperkingen stellen aan de systemen, bijvoorbeeld het financiële management of de juridische staf. Operationele experts geven adviezen vanuit hun kennis van het vak.

Het leveringenplan

Zoals bijvoorbeeld in Euromethod ([Euromethod, 1995]) te zien is, onderscheiden we drie categorieën leveringen, namelijk doeldomeinleveringen (dit zijn inhoudelijke leveringen, zoals genoemd in paragraaf 5.2), projectdomeinleveringen (dit zijn leveringen van producten voor de besturing van het project, zoals genoemd in paragraaf 5.2) en het leveringenplan, zie onderstaand figuur voor een overzicht.

Doeldomeinleveringen zijn leveringen aan de opdrachtgever, die direct met het informatiesysteem zelf te maken hebben. Doeldomeinleveringen zijn te verdelen in operationele delen van het informatiesysteem en beschrijvingen van het informatiesysteem.

Er zijn drie manieren om informatiesystemen te beschrijven:

• Een beschrijving van eisen: definieert een essentiële voorwaarde waaraan het informatiesysteem moet voldoen.
• Een specificatie: geeft een duidelijke en precieze beschrijving van een informatiesysteem met het doel het informatiesysteem te ontwikkelen of te valideren.
• Een prototype: is een operationeel proefmodel dat helpt bij het evalueren van een IS-specificatie of bij het beter begrijpen of het vaststellen van eisen. Een prototype geeft een beter beeld van het systeem dan een specificatie.

Projectdomeinleveringen zijn leveringen die ondersteuning bieden bij het nemen van beslissingen. Ze verschaffen de opdrachtgever inzicht in de richting en de voortgang van het interne productieproces van de opdrachtnemer.

Er zijn twee typen projectdomeinleveringen:

• Projectplannen: de eisen aan het interne productieproces van een project worden in projectplannen gedefinieerd, om te verzekeren dat de doelen van een opdracht bereikt worden. Daarnaast is een projectplan een middel om de noodzakelijk kwaliteit van de doeldomeinleveringen te bepalen.
• Projectrapporten: documenteren hoe de projectplannen waargemaakt zijn en dus in hoeverre aan de planningscriteria is tegemoet gekomen.

Projectplannen en projectrapporten worden verder verdeeld naar drie werkvelden:

• ontwikkelplannen en -rapporten
• kwaliteitsplannen en -rapporten,
• configuratiemanagementplannen en -rapporten.

Tenslotte onderkennen we het projectstatus- rapport. Dit rapport beschrijft de toestand van het project in relatie tot het leveringenplan. Het rapport ondersteunt de beoordeling van projectrisico’s en de verbeteracties die nodig zijn om in deze situatie het projectplan toch succesvol uit te kunnen voeren.

Naast doeldomeinleveringen en projectdomeinleveringen is er nog een derde categorie van leveringen, namelijk het leveringenplan zelf. Het leveringenplan wordt onafhankelijk van de specifieke systeemontwikkelmethode van de opdrachtnemer opgesteld. In de volgende paragraaf bekijken we het leveringenplan in wat meer detail.

Het opstellen van een leveringenplan

Het opstellen van een leveringenplan kent drie belangrijke activiteiten, namelijk het beoordelen van de probleemsituatie, het vaststellen van een strategie en het definiëren van beslispunten. Deze activiteiten zullen hier onder in nader detail worden besproken. Zie ook onderstaande figuur.

Het waarderen van de probleemsituatie

Bij het beoordelen van de probleemsituatie vindt een aantal activiteiten plaats:

• Vastleggen van het de begin- en eindtoestand van het systeem. Hierop gaan we verderop dieper in.
• Het beoordelen van de probleemsituatie aan de hand van een lijst van situatiefactoren. Situatiefactoren zijn eigenschappen van een situatie die gebruikt kunnen worden om de meest geschikte strategie te bepalen en om risico’s te voorspellen. Denk bijvoorbeeld aan zaken als onervarenheid van het projectteam of snelle veranderingen in de omgeving.
• Het identificeren van risico’s, in het bijzonder het identificeren van cruciale risico’s. Cruciale risico’s zijn risico’s met een grote kans van optreden die een bijzonder nadelige uitwerking hebben op de opdracht.

Om tot een vastlegging van de begin- en eindtoestand van het systeem te komen, moeten een aantal activiteiten worden uitgevoerd, die in de praktijk vaak parallel zullen plaatsvinden. Voor het definiëren van de begintoestand is het in ieder geval nodig om vast te stellen of de bestaande documentatie voldoende is om de probleemsituatie te begrijpen

Verder moet bekeken worden of het nodig is het (toekomstige) informatiesysteem te decomponeren. Het opdelen van het informatiesysteem in deelsystemen vermindert namelijk de complexiteit van het bouwen ervan. Dit betekent dat bepaald moet worden wat er aan documentatie over het huidige informatiesysteem relevant is voor deze opdracht, en wat daar volgens de specifieke systeemontwikkelingsmethode mee moet gebeuren en aan toegevoegd dient te worden om de eindtoestand te beschrijven. Denk hierbij aan de volgende zaken

• handleidingen en werkinstructies
• te converteren gegevens
• conversieprogrammatuur
• testprogrammatuur
• de interfaces die nodig zijn tussen de al in gebruik zijnde delen van het informatiesysteem en de te installeren nieuwe delen.
• systeemdocumentatie die nodig is om het informatiesysteem te kunnen onderhouden en te kunnen uitbreiden (ontwerpen, technische gegevens)

Het is na deze stap voor beide partijen duidelijk waar ze staan, waar ze naar toe moeten, en welke gevaren ze onderweg tegen kunnen komen.

Het vaststellen van een strategie

Om te zorgen dat de eindsituatie bereikt wordt, dient er een geschikte strategie te worden bepaald waarin aan een aantal zaken aandacht wordt geschonken:

• Belangrijk is het opstellen van een geschikte aanpak voor ontwikkeling en projectbeheersing. Als de situatie en de risico’s bekend zijn, is het mogelijk om de strategie hiervan af te leiden. Er bestaan heuristieken die aangeven welke aanpak in welke situatie het meest succesvol is.
• Ook is het mogelijk om te proberen de startsituatie te verbeteren. Er wordt dan gekeken welke factoren het realisatietraject kunnen verstoren. Deze worden dan al aangepakt voor de ontwikkeling van het systeem begint. Hierbij is het wel nodig dat ook tijdens de ontwikkeling de risico’s periodiek beoordeeld en aangepakt worden.

Een ontwikkelaanpak is een combinatie van een installatie-aanpak, een bouwaanpak en een beschrijvingsaanpak. In hoofdstuk 9 gaan we hier dieper op in, maar denk bijvoorbeeld aan een evolutionaire aanpak vs. een Big Bang aanpak. Er bestaan heuristieken voor de keuze van een ontwikkelaanpak. Deze hebben vaak de vorm: "wanneer situatiefactor x leidt tot onzekerheid en/of complexiteit, kies dan strategieoptie y".

Projectbeheersing is de verzameling processen gericht op het bijhouden van de voortgang van het project ten opzichte van de projectplannen. Projectbeheersing kan worden uitgesplitst naar de drie werkvelden: Systeemontwikkeling, kwaliteitsborging en configuratiemanagement:

• Ontwikkelbeheersing: het management dat nodig is om de projecttaken te beheersen die uitgevoerd worden in het werkveld Systeemontwikkeling. Deze vorm van beheersing heeft als doel dat het afgesproken werk ook gedaan zal worden.
• Kwaliteitsbeheersing: de technieken en activiteiten die ingezet worden om aan de kwaliteitseisen te voldoen. Deze vorm van beheersing heeft als doel ervoor te zorgen dat het uitgevoerde werk ook goed wordt uitgevoerd.
• Configuratiebeheersing: een element uit het werkveld configuratiemanagement, dat bestaat uit het evalueren en coördineren, het goed- of afkeuren en het implementeren van veranderingen aan configuratie-items. Deze vorm van beheersing heeft als doel dat het werk op de juiste (versies van) componenten wordt uitgevoerd.

• Frequentie: frequent en zelden.
• Formaliteit: formeel en informeel.
• Klantverantwoordelijkheid.

Het is na deze stap voor beide partijen duidelijk op wat voor wijze ze van het beginpunt naar het eindpunt willen gaan.

Het definiëren van beslispunten

Zoals bovenstaand plaatje laat zien, is het belangrijk om voorafgaand aan het opstellen van het leveringenplan te beslissen wanneer er welke beslissingen genomen moeten worden en wanneer er welke leveringen worden uitgewisseld tussen de opdrachtnemer en de opdrachtgever. Op deze manier ontstaat er duidelijkheid voor zowel de opdrachtgever als de opdrachtnemer wie, wanneer, waar voor verantwoordelijk is. Zonder deze expliciete beslispunten wordt het voor de opdrachtgever onmogelijk om zijn misschien steeds veranderende eisen over het eindproduct duidelijk te maken aan de opdrachtnemer. Tegelijkertijd is het voor de opdrachtnemer moeilijker na te gaan of de opdrachtgever met het eindproduct tevreden zal zijn.

Bij het definiëren van beslispunten zijn twee activiteiten van belang:

• het definiëren van een bepaalde volgorde van beslispunten
• het definiëren van leveringsprofielen bij beslissingen (dat wil zeggen: wat moet er bekend zijn om de beslissing te kunnen nemen?)

Tijdens de opdracht kunnen verscheidene typen beslissingen genomen worden. In één beslispunt kunnen verschillende beslissingen van verschillende typen worden genomen. Als basisregel bij het vaststellen van de benodigde leveringen voor een beslissing geldt, dat de leveringen de juiste informatie moeten bevatten om de beslissing te kunnen nemen, maar niet meer dan dat: te veel informatie kost geld. Er zijn twee beslissingstypen. Inhoudelijke beslissingen over het systeem zelf, en beslissingen over de voortgang van de opdracht.

Na deze stap is het voor beide partijen duidelijk wanneer welke leveringen (van inhoudelijke en bestuurlijke producten) opgeleverd worden zodat een zinvol besluitvormingsproces mogelijk is.

Het daadwerkelijk opstellen van een leveringenplan
 

Zoals in het begin van deze paragraaf werd vermeld, kent het opstellen van een leveringenplan drie belangrijke activiteiten, namelijk het beoordelen van de probleemsituatie, het vaststellen van een strategie en het definiëren van beslispunten. Deze drie activiteiten zijn hierboven afzonderlijk beschreven en op basis hiervan kan het plan daadwerkelijk worden opgesteld. Belangrijke randvoorwaarden hierbij zijn nog :

• de kwaliteit van de probleemsituatiebeschrijving moet voldoende zijn.
• de strategie moet toepasbaar zijn
• de beslispunten moeten toepasbaar zijn

Het is van groot belang, dat de opdrachtgever en de opdrachtnemer in staat zijn om precieze afspraken over inhoud, niveaus van detail, kwaliteitstoestand en begrenzing van een levering te maken. Gedurende het tenderproces vindt de definitie plaats van het gewenste resultaat van de opdracht en van de verder benodigde transacties tussen opdrachtgever en opdrachtnemer in de productie- en voltooiingsprocessen. Gedurende het productieproces worden de gedefinieerde leveringen geproduceerd.

De stuurgroep

In de vorige paragrafen is duidelijk geworden, hoe het communicatieproces tussen opdrachtgever en opdrachtnemer gestructureerd kan worden. In deze paragraaf laten wij u zien, welke rollen bij dat communicatieproces aanwezig zijn.

Uit bovenstaand plaatje komen de volgende rollen naar voren:

• de rol van de accountmanager.
• de rol van de contractmanager
• de rol van de projectmanager
• de rol van de klantvertegenwoordiger
• en de rol van de stuurgroep
  
  

De accountmanager is de persoon die namens de potentiële opdrachtnemer de opdracht probeert binnen te halen, die de opdrachtgever heeft uitgezet.

Vanaf het moment dat het contract daadwerkelijk getekend gaat worden, speelt de accountmanager in feite geen rol meer. Vanaf dat moment is de contractmanager verantwoordelijk voor het bewaken van het project waarin de opdracht wordt uitgevoerd. De contractmanager kijkt eenvoudig gezegd of de projectmanager, die namens de opdrachtnemer belast is met uitvoering van de opdracht, zich aan de afspraken houdt, zoals die in het contract zijn vastgelegd. Bij niet al te grote projecten is het ook de contractmanager die in een overleg met de klantvertegenwoordiger de voortgang bespreekt van het project.

Als het project groter van omvang is, is het vaak de klant die een stuurgroep in het leven roept. De stuurgroep die bestaat uit de klantvertegenwoordiger(s) en de projectmanager(s) en de contractmanager(s), heeft een taak die bestaat uit een initiërende, coördinerende, signalerende en bijsturende rol ten aanzien van het project. De stuurgroep is een forum, dat op het hoogste niveau de linking pin vormt met de organisatie van de opdrachtgever, zie onderstaand figuur.

De samenstelling van een goede stuurgroep kenmerkt zich door:

• voldoende bevoegdheid om alle noodzakelijke beslissingen zonder vertraging te kunnen nemen.
• een beperkte omvang: alleen personen die belang hebben bij het project zijn opgenomen, dit verhoogt de doelgerichtheid.
• een zo breed mogelijk draagvlak voor de acceptatie van het project en het resultaat binnen de organisatie, tijdens en na afloop van het project.

Opdrachttypen

 

Zoals u uit bovenstaand figuur kunt aflezen, onderscheiden we verschillende opdrachttypen.

Trends

• Het blijkt dat de opdrachtgevers steeds mondiger worden ten opzichte van vroeger. Vroeger kon je het je als opdrachtnemer nog permitteren om zonder al te veel inspraak van de klant een systeem te bouwen. Tegenwoordig is dat niet meer mogelijk en ook zeer onverstandig om dat wel te doen, klanten blijken vaak erg goed te weten wat ze willen.
• De verantwoordelijkheden van opdrachten verschuiven steeds meer naar de grenzen : Er wordt ofwel alleen assistentie gevraagd ter aanvulling op de eigen automatiseringsafdeling ofwel volledig uitbesteed.
• Als de eindtoestand bij de offerteaanvraag nog niet voldoende beschreven is wordt er steeds minder in het wilde weg gebouwd en steeds vaker een apart "scoping" project uitgevoerd om de eindtoestand te bepalen. Door schade en schande is men wijzer geworden.

Statements

• De meeste projecten mislukken nog steeds in de contractfase; het verkeerde wordt afgesproken.
• Opdrachtgevers dragen ook verantwoordelijkheid voor het project. Klanten die denken altijd koning te moet zijn komen van een koude kermis als ze hun verantwoordelijkheden ontlopen.
• Softwarehuizen die hun klanten niet op hun verantwoordelijkheden wijzen zijn nut schuldig maar wel medeplichtig aan het falen van het project.
• Softwarehuizen die geen verantwoordelijkheid willen dragen voor realisatie van hun adviezen verraden daarmee hun gebrek aan vakmanschap.
• De belangrijkste kiem van het mislukken van automatiseringsprojecten ligt in de contractfase. De tweede "misdadiger" is slecht projectmanagement.
• De projectleider staat voor het belang van het project en dient daarom de inherente belangentegenstelling tussen opdrachtgever en opdrachtnemer te overstijgen.
• Over het algemeen is het tarief voor vakbekwame automatiseringsdeskundigen veel te laag.
• Dure ( = goed opgeleide ) automatiseringsdeskundigen zijn vaak goedkoper ( meer doeltreffend en doelmatig ) dan goedkope ( = zwak geschoolde ) automatiseringsdeskundigen.
• De echte core competence en de concurrentiekracht van een opdrachtnemer in de software industrie ligt in het selecteren van de beste mensen en deze op de juiste manier opleiden en coachen.

 Oefeningen

• Welke voorbeelden van risico’s in het tenderproces, waardoor het productieproces niet kan worden gepland, kunt u noemen?
• Geen enkele opdrachtnemer reageert op de offerte-aanvraag omdat de leveranciers de opdracht onhaalbaar of financieel te riskant vinden.
• De kosten vermeld in de offertes zijn erg hoog, omdat de leveranciers veel onvoorziene kosten hebben moeten inbouwen om de geschatte financiële risico’s af te dekken.
• Het productieproces zal geen succes worden omdat de informatiesysteemaanpassing onhaalbaar bleek.
• De kosten van de informatiesysteemaanpassing zullen onbeheersbaar blijken te zijn.

Vragen

• Waarom zit de accountmanager niet in de stuurgroep?
• Welke (kwaliteits)voorwaarden kunnen aan de opdrachtgever gesteld worden?
• Projecten kennen risico’s. Wat is het projectrisico voor de opdrachtgever en wat is het projectrisico voor de opdrachtnemer?
• Waarom wordt er onderscheid gemaakt tussen de contract- en projectautoriteit?

Definities

accountmanager
De accountmanager is degene die namens de aanbieder probeert een contract met een opdrachtgever af te sluiten.

beslispunt
Een beslispunt is een ‘punt’ in de tijd waar de klant, eventueel samen met de leverancier, beslissingen neemt over de opdracht. Een beslispunt wordt gekarakteriseerd door de transacties die plaatsvinden, de leveringen die worden uitgewisseld, de beslissingen die genomen worden en de rollen die bij die beslissingen betrokken zijn.

contractmanager
De contractmanager is de persoon aan de kant van de opdrachtnemer, die verantwoordelijk is voor een afgesloten contract, en daarover contact met de opdrachtgever onderhoudt.

leveringenplan
Een leveringenplan definieert de beslispunten en transacties tussen opdrachtgever en opdrachtnemer. Hierin staan de begintoestand en de eindtoestand van een aanpassing aan de informatievoorziening beschreven, alsmede de gekozen strategie voor de aanpassing. Daarnaast bevat het leveringenplan een lijst met leveringen en bijbehorende beslispunten, samen met tijdschema’s wanneer deze plaatsvinden.

stuurgroep
Een stuurgroep bestaat uit vertegenwoordigers van de opdrachtgever en opdrachtnemer en ze verzorgt de coördinatie van de projectgroepen die onder haar verantwoordelijkheid opereren.

transactie
Een transactie wordt gezien als de uitwisseling van producten tussen de opdrachtgever en de opdrachtnemer om een bepaald doel te bereiken.

Literatuurverwijzingen

Voor meer informatie over de relatie tussen opdrachtgever en opdrachtnemer:

• Denis Verhoef en Victor van Swede, Euromethod, Deventer, Kluwer Bedrijfswetenschappen, eerste druk, 1995.