MBA INFORMATION MANAGEMENT THESIS RESEARCH PROJECT                          Willem Hazenberg

Selection and decision-making criteria for a Distributed Control Systems in the process industry”.

5.7 Implementatieproces

Het begrip implementeren betekent in algemene zin: Het uitvoeren, vervullen, verwezenlijken, effectueren, in praktijk brengen van een overeenkomst, verdrag of plan. In de informatica heeft implementeren een meer specifieke betekenis: Het realiseren van een ontwerp van een deel van de informatievoorziening van een organisatie. Dit kan dus bijvoorbeeld de invoering van het softwarepakket zijn zoals bijvoorbeeld SAP of een DCS-systeem om de plant te automatiseren. Implementatie heeft betrekking op alle activiteiten die nodig zijn om een succesvol gebruik van een informatiesysteem te garanderen. Daarom begint implementatie met het in het voortraject inzichtelijk maken van de informatiebehoefte van de organisatie en eindigt het pas als het informatiesysteem succesvol in gebruik is genomen en het beheer overgedragen is aan de organisatie[1]. 

Het implementatieproces wordt onderverdeeld in:

• Ontwerp, bouw en installatie van het systeem;
• Projectmanagement;
• Validatie (GAMP) testen van het resultaat.

5.7.1 Implementatiemodellen

In de literatuur worden meerdere implementatiemodellen genoemd met allen hun eigen eigenschappen. We kunnen de volgende modellen onderscheiden:

1.      SIM³-kubus, de implementatiemethode;

a.       De vijf fasen van de implementatie van de SIM³-kubus;

b.      De vijf SIM³-kubus besturingsfuncties;

2.      Het vijf fasen model van Ross en Vitale;

3.      Het vijf fasen model van Markus en Tanis;

4.      Het projectfase model;

5.      Systeem integratie projectfaseringsmodel;

6.      Het SAP R/3 implementatieproces;

7.      Fasen in totstandkoming van een softwaresysteem;

8.      PricewaterhouseCoopers SmartClose stappenplan;

9.      Shell Implementatiemodel;

10.  Het ADDIE model;

11.  Projectlevenscyclus;

12.  Implementatiemodel Van Vermeersch.

5.7.1.1 SIM³-kubus, de implementatiemethode

Fig. 152 SIM³-kubus De implementatiemethode[2]

In de bovenstaande SIM³-kubus vertegenwoordigt ieder blokje een combinatie van een object van verandering plus een fase in het implementatieproject plus een managementaspect. Zo heeft iedere combinatie een set van activiteiten, die bij elkaar genomen het gehele implementatieproject uitmaken. Hoewel alle aspecten belangrijk zijn voor een goede DCS-implementatie wordt er binnen deze thesis alleen aandacht besteed aan de aspecten die we dienen te controleren bij een leverancier als implementatiepartner.

5.7.1.1.1 Het vijf fasen implementatiemodel

Fig. 153 De vijf fasen van de implementatie

De vijf fasen[3] implementatiemodel bestaat uit hierna genoemde fasen:

1.      Voorbereiden:

• De voorbereiding moet dusdanig zijn, dat op basis hiervan het informatiesysteem succesvol geïmplementeerd kan worden. Dit houdt in dat de context, doelen en randvoorwaarden gedefinieerd moeten worden, de risico’s geïnventariseerd moeten zijn, het project gepland en ingericht moet zijn en het projectplan vastgesteld moet worden.

2.      Ontwerpen:

·        In de ontwerp fase worden de standaard applicaties op papier ontwikkeld en aangepast aan de organisatie en vice versa en wordt het maatwerk voor de DCS configuratie uitgewerkt. Hiervoor moeten detail procesbeschrijvingen, een detail procesanalyse, een uitwerking van het procesontwerp, een detailontwerp van de organisatorische componenten, een parameterontwerp en een conversieplan (in het geval van een migratie of vervanging) gemaakt worden en moet het detailontwerp van het besturingssysteem vastgesteld worden.

3.      Inrichten:

·        De kern van het inrichten van een besturingssysteem wordt gevormd door het omzetten van het ontwerp in een ingericht en getest systeem. Hiervoor moet de apparatuur en programmatuur geïnstalleerd worden, de parameterinstellingen en basistabellen ingevoerd en getest zijn, een proefconversie worden uitgevoerd, de organisatorische componenten ontwikkeld en getest zijn en de optimale integratie worden getest. Special als er meerdere systemen gekocht zijn zoals PLC, DCS en/of ESD is een integratietest nodig op één locatie niet zijnde de plant.

4.      Invoeren:

·        Deze fase is het spannendst: Het systeem gaat ‘live on-proces’ in twee fasen. Dat betekent dat de knop wordt ingedrukt en het systeem ‘ter wereld komt en live is’. Hiertoe moeten de eindgebruikers opgeleid en getraind worden, de beheerorganisatie moet worden doorgevoerd, het ‘go-live’-plan tot in detail uitgewerkt is, de migraties uitgevoerd zijn, het systeem aan een laatste controle onderworpen is, het systeem in gebruik genomen wordt en wordt overgedragen aan de beheerders. Deze dragen het systeem dan over aan het functionele testteam die alle ingangen en uitgangen gaat testen op goede werking. Als ook deze fase is afgerond gaat het systeem ‘on-proces’.

5.      Integreren:

·        Dit is de fase na ingebruikname, waarbij we de implementatie niet loslaten, maar de touwtjes nog even vasthouden zodat het systeem een stevige inbedding krijgt in de organisatie. Om dit te bewerkstelligen moeten er audits en controles worden uitgevoerd, werkplekondersteuning worden geven, incidenten worden beoordeeld en geregistreerd, problemen oplossen, wijzigingsvoorstellen betreffende het systeem behandelen en specificeren en het systeem overdragen aan de plant eigenaar.

5.7.1.1.2 De vijf SIM³-kubus besturingsfuncties

Deze vijf uitvoerende processen worden bestuurd door vijf besturende functies: Projectmanagement, kwaliteitsmanagement, contractmanagement, verandermanagement en kennismanagement.

Fig. 154 Besturingsparadigma implementatieproject[4]

Bovenstaand figuur 154 laat het takenspectrum zien, zoals dit ook voor een DCS-project geldt. Er is een externe- en een interne projectmanager, waarbij de externe projectmanager zich vooral moet richten op de levering van het systeem met de afgesproken resultaten en de interne projectmanager zich meer moet richten op de interne aanpassingen die nodig zijn om het project succesvol te kunnen afronden. Uiteraard ligt hier ook een spanningsveld en is het dus belangrijk dat de twee projectmanagers goed met elkaar kunnen samenwerken en het opleveren van het project als een gezamenlijk doel zien.

5.7.1.2 Het vijf fasen model van Ross en Vitale

Fig. 155 Het vijf fasen model van Ross en Vitale

Het vijf fasen model van Ross en Vitale[5] wordt vooral gekenmerkt door een gebrek aan detail. Het omschrijft vrij vaag de verschillende stadia van een implementatieproces, die eigenlijk in elk model voorkomen. Bovendien zijn de grenzen tussen de verschillende fasen vrij onduidelijk en zijn de uitkomsten, laat staan optimale uitkomsten, van elke fase niet beschreven. Het model is wel nuttig om een eerste beeld te krijgen van hoe een implementatie globaal verloopt. Ross en Vitale vergelijken de fasen in het implementatieproces van een ERP-systeem met de ontsnapping van een gevangene uit een op een eiland gelegen gevangenis. Eerst zal de gevangene een ontsnappingsplan maken met daarin de route die hij zal nemen. Vervolgens zal hij van de rots moeten springen en naar de bodem van de zee zinken. Daarna zal hij proberen terug aan het wateroppervlak te geraken zonder in ademnood te belanden en erop hopend dat hij niet neergeschoten wordt als hij eenmaal opnieuw zichtbaar is. In de vierde fase bereikt hij het wateroppervlak en kan hij beginnen te zwemmen naar zijn vrijheid. Ten slotte, als de ontsnapping een succes is, zal de gevangene de kust bereiken en een vrij man zijn. De vergelijkbare fasen tijdens het implementatieproces van een ERP-systeem zijn: Ontwerp, implementatie, stabilisatie, continue verbetering en transformatie.

De meest interessante en afwijkende fase in het Ross en Vitale model is de ‘stabilisation’ fase. Tijdens deze fase, waarin de gevangene opnieuw aan het oppervlak verschijnt, zal de onderneming proberen zich aan te passen aan de nieuwe situatie. In het begin zullen de prestaties, bijvoorbeeld de efficiëntie, het opnieuw inregelen een dipje kennen (Ross en Vitale) [6]. Deze mindere periode duurt gewoonlijk vier tot twaalf maanden. Typische activiteiten zijn tuning, inregelen, additionele training voor de operators, onderhoud en engineers en de laatste softwarebugs weg te werken, eventueel met de hulp van de leverancier of consultants. Bij een DCS-migratie of vervanging is de dip periode waarschijnlijk ook de belangrijkste reden dat bedrijven niet snel besluiten om een systeem te migreren of te vervangen. Zowel de duur van de verstoring als de impact van de verstoring is niet van de voren in te schatten voor de eindgebruikers.

5.7.1.3 Het vier fasen model van Markus en Tanis

Fig. 156 Het vier fasen model van Markus en Tanis

Het implementatiemodel dat Markus en Tanis[7] ontwikkelden is wellicht het meest uitgebreide en gedetailleerde dat in de literatuur te vinden is. Het omvat een viertal fasen: De project chartering fase; de project fase, de shakedown fase en de onward en upward fase. De verschillende stadia zijn duidelijk afgebakend en na elke fase wordt een optimale uitkomst gegeven. Eindgebruikers die al over een DCS-systeem beschikken, maar een belangrijke update van hun systeem doen, doorlopen eveneens deze vier fasen.

Markus en Tanis wijzen op drie belangrijke aandachtspunten:

1. Ten eerste stelt men dat de aanwezigheid van noodzakelijke voorwaarden niet steeds voldoende zijn voor een succesvolle implementatie. Er kunnen zich steeds externe gebeurtenissen voordoen die er voor zorgen dat de implementatie niet loopt zoals verwacht. Bijvoorbeeld een plotse recessie of andere marktcondities en/of regelgeving;
2. Het tweede punt waarop gewezen wordt, is dat de uitkomst van een fase de startvoorwaarde voor een volgende fase betekend. Beslissingen en acties in eerdere fase beïnvloeden het potentiële succes in de daaropvolgende fase(n). Bovendien werken in de verschillende fasen ook verschillende groepen van mensen aan het project dat een bijkomende moeilijkheid oplevert qua communicatie;
3. Het derde punt is dat de uitkomst van een fase bepaald wordt door zowel bedoelde acties en beslissingen als door de eerder vermelde externe gebeurtenissen die oncontroleerbaar zijn. Daarnaast kunnen beslissingen ook een vertraagd effect hebben op de implementatie.

Voor de beoordeling bij een DCS-project zijn op deze plaats vooral de eerste twee fasen belangrijk omdat daar belangrijke aanvullende lessen zijn te leren:

5.7.1.3.1 De project chartering fase

De chartering fase bestaat uit alle beslissingen die uiteindelijk leiden tot de goedkeuring van de business case om te investeren in een DCS-systeem. Eerst en vooral ontstaat het idee om een DCS-systeem te implementeren. Vandaar ook de bijnaam voor deze fase: ‘Ideas to dollars’. Belangrijkste activiteiten die tijdens deze fase plaatsvinden zijn het maken van een bedrijfsvisie en plan met betrekking tot het DCS-systeem, de selectie van het systeem, het zoeken van een ervaren projectmanager en het opstellen van een tijdschema en budget. De belangrijkste personen in deze fase zijn uiteraard de bestuurders van de onderneming, de procesbesturing specialisten, eventuele consultants en de DCS-accountmanagers. Het adequaat omschrijven van de functionele eisen is een vaak voorkomend probleem tijdens deze fase. De uiteindelijke uitkomst van deze fase is de beslissing om al dan niet te investeren in een DCS-systeem. Indien beslist wordt om verder te investeren in een bepaald DCS-systeem, bestaat de mogelijkheid dat deze beslissing foutief is. Dit zal zijn gevolgen hebben later in het implementatieproces (Markus en Tanis[8]). In deze fase ligt een spanningsveld dan enerzijds voor de contractsluiting met de DCS-leverancier is de accountmanager de leidende persoon en op dat moment kan ‘er veel’, maar anderzijds na contractsluiting kost alles wat extra is ten opzichte van de afgesproken scope, extra tijd, geld of mankracht en veroorzaakt dit zowel een probleem voor de projectmanager van de DCS-leverancier als ook voor de interne projectmanager. De volgende acties zouden dit soort problemen kunnen verminderen:

• Maak de functionele eisen zo helder als mogelijk (SMART);
• Betrek de toekomstige DCS-projectmanager al voor contractsluiting bij het project en laat hem al een projectcharter opstellen en tekenen voor de contractsluiting.

5.7.1.3.2 De project fase

De project fase omvat alle activiteiten die er voor zorgen dat het systeem werkt in één of meerdere units van de plant. Deze fase wordt ook wel eens de ‘dollars to assets’ fase genoemd. De monetaire investering wordt als het ware omgezet in een activa voor de onderneming (Markus en Tanis). Eerst en vooral wordt de projectplanning opgesteld. Daarna start men met het selecteren van een projectteam dat de implementatie tot een goed einde moet brengen. Nadat het team is samengesteld moet het worden opgeleid en getraind. Er moet ook beslist worden of men het systeem zal aanpassen aan de bestaande operaties, of omgekeerd de operaties zal aanpassen aan het systeem. De projectfasering wordt in paragraaf 5.7.6 bij project tijdmanagement en paragraaf 5.7.6.1 project doorlooptijd in detail beschreven.

5.7.1.4 Het project fase model

Fig. 157 Het Project fase model Bron Parr en Shanks[9]

5.7.1.4.1 Fase 1 Planning fase

Tijdens de planning fase wordt een DCS -systeem geselecteerd. Er wordt ook bepaald in welke mate men de implementatie zal doorvoeren. Daarmee wordt bijvoorbeeld bedoeld dat beslist wordt welke onderdelen (HMI, Controllers, I/O) en/of in welke procesunits. Daarnaast wordt een projectmanager aangesteld en ten slotte dient vastgelegd te worden met welke middelen dit alles gefinancierd zal worden (Shanks en Parr).

5.7.1.4.2 Fase 2 Project fase

Het tweede en meest belangrijke stadium is de projectfase. Omdat de focus eigenlijk op deze fase ligt, is ze dan ook onderverdeeld in vijf subfasen.

1.      In de set-up fase wordt het implementatieteam samengesteld. Dit team moet zowel uit mensen bestaan met technische kennis, als uit mensen met kennis over de onderneming en de bedrijfsprocessen. Dit team moet goed geïntegreerd zijn zodat de communicatie vlot verloopt. Rapporteringregels worden eveneens vastgelegd;

2.      Tijdens het re-engineering stadium gaat men de huidige bedrijfsprocessen analyseren om te kijken waar aanpassingen van werkwijzen nodig zijn. Het DCS-systeem wordt geïnstalleerd en werkwijzen worden dan ook aangepast aan de functionaliteiten van het DCS-systeem;

3.      De ontwerp subfase legt dan weer de laatste hand aan het aanpassen van zowel de werkwijzen als het systeem zodat deze optimaal op elkaar afgestemd zijn. Belangrijk tijdens deze fase is dat er communicatie bestaat tussen het implementatieteam en de uiteindelijke eindgebruikers. De eindgebruikers moeten weten waar ze straks aan toe zijn als eenmaal het systeem volledig operationeel is;

4.      Een van de belangrijkste activiteiten tijdens de configuratie en testfase is de ontwikkeling van een uitgebreide configuratie. In het systeem wordt reële data ingevoerd. De verschillende interfaces, beveiligingen, vergrendelingen en regelingen dienen grondig getest te worden;

5.      De laatste subfase is de installatie. Daarin worden de nodige hardware geïnstalleerd en wordt het netwerk opgebouwd. Heel belangrijk tijdens deze fase is het opleiden en trainen van de eindgebruikers. Bovendien moeten ze ook later nog ergens terecht kunnen met al hun problemen (Parr en Shanks[10]).

5.7.1.4.3 Fase 3 Enhancement fase

Ten slotte is er nog de enhancement fase. Deze fase kan meerdere jaren duren en omvat allerlei zaken als het herstellen van het systeem na eventuele problemen, verdere uitbreiding of het updaten met nieuwere versies. Deze fase is vergelijkbaar met de ‘continuous improvement’ en ‘stabilization’ fasen bij Ross en Vitale en ‘de onward en upwards’ fase bij (Markus en Tanis) en (Parr en Shanks).

5.7.1.5 Systeem integratie: Project faseringsmodel

Fig. 158 Systeemintegratie projectfasering[11]

 Het voordeel van dit systeemintegratie project faseringsmodel is dat het specifiek voor de DCS-SCADA markt is ontwikkelend en is daardoor zeer specifiek toepasbaar. Het rood gemarkeerde gebied zal dan ook hier in meer detail worden beschreven terwijl het bovenste deel wordt beschreven in paragraaf 5.7.5 bij het scope management deel.

5.7.1.5.1 Control systeem specificatie

De eerste projectstap is het opstellen van de I/O lijsten want in de algemene fase zal er wel gesproken zijn over I/O aantallen en applicaties maar niet over specifieke details.

5.7.1.5.2 Productie van een single line diagram

De single line diagram is over het algemeen al geproduceerd tijdens de aanbiedingsfase. Dit schema laat de hoofdcomponenten zien en de interfaces naar andere systemen.

5.7.1.5.3 Softwareontwikkeling

In deze fase wordt de software ontwikkeld zoals de operator interface, de basisregelingen en I/O tags, logische diagrammen, schermafbeeldingen en operator- en onderhoudhandboeken. In tegenstelling tot ERP- en CRM systemen moet de software vaak vanaf de basis worden opgebouwd omdat nagenoeg ieder proces uniek is. Soms bestaan er wel voor bepaalde onderdelen ‘typicals’ en hiermee kan een DCS-leverancier zich onderscheiden. Om bedrijfseconomische redenen wordt een steeds groter deel van dit configuratie werk uitgevoerd in lage lonen landen zoals India. Het gevolg is dan ook dat de afstand tussen de ontwikkelaar en de toekomstige service engineer een stuk groter is en ze elkaar waarschijnlijk niet eens kennen wat soms tot problemen leidt tijdens de serviceperiode.

5.7.1.5.4 Schrijven Factory Acceptance Testplan en uitvoering

Een Factory Acceptance Test (FAT) wordt uitgevoerd bij de leverancier van de software. De eindgebruiker kan offsite in een gecontroleerde omgeving testen of het systeem voldoet aan de in de scope gestelde functionaliteit en eisen. Het is belangrijk om al tijdens de selectiefase van het systeem afspraken te maken over de formele FAT procedure. In paragraaf 5.7.14 wordt uitgebreid ingegaan op het testen van de systemen.

5.7.1.5.5 Trainingen

Het verzorgen van trainingshandleidingen en het verzorgen van trainingen. In paragraaf 7.8 wordt uitgebreid ingegaan op de trainingen.

5.7.1.5.6 Site Acceptance Test

De Site Acceptance Test (SAT) wordt on-site uitgevoerd na de levering van het systeem en voordat het aangesloten wordt aan het proces. Hier wordt getest of alle hardware goed werkt en de interfaces met de interne systemen werken. Na deze SAT wordt er begonnen met de commissioning fase. Voor meer info over de SAT zie paragraaf 5.7.14.4 testen.

5.7.1.5.7 Commissioning fase

In de commissioning fase wordt alle procesapparatuur aangesloten en getest. Dit kan een zeer lange test zijn. Bij nieuwe installaties kan dit maanden duren. Dit valt echter buiten de scope van een DCS-selectie. De rol van de DCS-leverancier is erg verschillend per project, bij sommige projecten leveren ze alleen de software op, bij andere projecten geven ze maandenlange optimalisatie services. Het is belangrijk in de projectscope fase al te bepalen, hoe het systeem wordt opgeleverd en welke diensten hierbij zitten.

5.7.1.6 Het SAP R/3 implementatieproces

Het SAP R/3 implementatieproces kent vier hoofdfasen^[12]:

1.      Organisatie en conceptueel ontwerp;

2.      Gedetailleerd ontwerp en systeem set-up;

3.      Voorbereiding voor going life;

4.      Gebruik en beheer.

5.7.1.7 Fasen in totstandkoming van een softwaresysteem

De totstandkoming van een softwaresysteem kent de volgende onderverdeling[13]:

1. Functioneel ontwerp:

a.       De functionele- en bedrijf eisen waaraan het systeem moet voldoen.

2. Technisch ontwerp:

a.       Het functionele ontwerp wordt nader gedetailleerd en vertaald naar technische eisen, zodat de ontwikkelaar in de volgende stap precies weet wat er moet worden gebouwd.

3. Programmeren:

a.       De programma’s van het systeem worden beschreven volgens de technische specificaties zoals die in de vorige fase zijn vastgelegd.

4. Testen:

a.       De ontwikkelde (deel)programma’s worden in samenhang getest.

5. Conversie en invoering:

a.       De gegevens van het oude systeem worden omgezet en geschikt gemaakt voor het nieuwe systeem.

6. Gebruik en beheer van het systeem:

a.       De beheersorganisatie neemt het systeem in gebruik en beheert het.

5.7.1.8 PricewaterhouseCoopers SmartClose

Het PricewaterhouseCoopers model is primair ontwikkeld voor het snel afsluiten van financiële administraties anderzijds geeft het een mooi overzicht van de verschillende fasen zoals strategie (uitgangspunten) analyse, testen en invoeren en continue verbetering. Daarom heen de indirecte projectrollen van de organisatie, mensen, systemen en technologie en processen. Als laatste twee lagen zien we projectmanagement en kwaliteitscontrole aan de ene zijde en wijzigingsbeheer aan de andere zijde. Het is dan ook al weer meer een projectmanagement model dan een puur implementatiemodel.

Fig.  SEQ Fig. 159 PricewaterhouseCoopers SmartClose stappenplan

4.7.1.9 Shell Implementatiemodel

 Het Shell Implementatiemodel laat zien welke stappen de onderneming doorloopt, waar er een goedkeuring moet worden gegeven en welk document het resultaat is van een positief besluit.

Fig. 160 Shell Implementatiemodel

4.7.1.10 Het ADDIE model

Het ADDIE-model[14], is een bekend implementatiemodel dat zijn oorsprong kent in de wereld van Instructional Systems Design (ISD). ADDIE is een acroniem voor de vijf fasen uit het model, te weten:

1.      Analysis                 - Analyse van het probleem;

2.      Design                   - Ontwerp van de oplossing;

3.      Development         - Ontwikkeling van de oplossing;

4.      Implementation      - Implementatie van de oplossing in de praktijk;

5.      Evaluation - Evaluatie van de geïmplementeerde oplossing.

Het ADDIE-model is een zogenaamd watervalmodel, waar de ene fase als een soort van waterval naar de volgende fase gaat. Het model wordt onder andere gebruikt bij softwareontwikkelingtrajecten. De precieze oorsprong van het model is niet bekend, ook wordt er getwijfeld aan de wetenschappelijke onderbouwing van het model: Soms wordt de term ADDIE gebruikt als een label.

5.7.1.11 Project levenscyclus

Fig. 161 Typische volgorde van fasen van een Project Levenscyclus

De meeste DCS-projecten hebben een relatie met het lopende werk van de betrokken organisatie. Sommige organisaties hebben een formeel goedkeuringsproces en alleen na uitvoering van een haalbaarheidsstudie, een voorlopige planning of een gelijksoortig equivalent in de vorm van een analyse worden de volgende stappen gezet. In deze gevallen zijn het opstellen van de voorlopige planning en/of het maken van een haalbaarheidsanalyse afzonderlijke (voor)projecten. Sommige projecten, vooral de interne service of uitbreidingsprojecten kunnen informeel worden geïnitieerd zonder dat er een formele goedkeuring van de afzonderlijke fasen of activiteiten plaatsvindt.

5.7.1.12 Implementatiemodel Van Vermeersch

Het samengestelde model voor ERP-systemen van Vermeersch mede gebaseerd op

Al-Mudimigh et. al.[15] waarin zowel het fasemodel als de voorgaande KPI’s worden genoemd. Dit model is met wat kleine aanpassingen ook te gebruiken voor een DCS-systeem.

Fig. 162 Kritieke succesfactoren tijdens het samenvattende model.

Bij een DCS-systeem wordt niet gesproken over een ERP-pakket maar een DCS-systeem, daarnaast zal de Business Process Re-engineering (BPR) fase bij een DCS-systeem van veel minder belang zijn dan bij een ERP-implementatie.

5.7.2 Onderdelen Implementatieproces

Onderdelen implementatieproces:

1.      Projectmanagement methoden;

2.      Integratiemanagement;

3.      Scope management, wat is er nodig om het afgesproken resultaat te bereiken;

4.      Project tijd management zoals planning, fasering en mijlpalen;

5.      Project budget management;

6.      Project kwaliteitsmanagement en uitwerking van de beheerssituatie;

7.      Project organisatie zoals project teamsamenstelling, taken en verantwoordelijkheden[16], Projecthiërarchie;

8.      Projectcommunicatie management;

9.      Project risicomanagement;

10.  Project inkoopmanagement;

11.  Uitwerken testplan en inrichting test omgeving;

12.  Bouwen;

13.  Valideren en testen;

14.  Inbedrijfstelling;

15.  Oplevering.

5.7.3 Projectmanagementmethoden

Projectmanagement omvat meerdere onderdelen, volwassenheidsmodellen zoals Organizational Project Management Maturity Model (OPM3)[17] en project- managementmethoden. Enkele bekende methoden zijn[18]:

1.      Watervalmethode;

2.      Incrementele methode;

3.      Projectmatig creëren;

4.      PRINCE2;

5.      Body Of Knowlegde (BOK).

5.7.3.1 Watervalmethode

Projectmanagementmethoden van het eerste uur hanteerden als voornaamste kenmerk de standaard fasering. Ieder project had een initiatiefase, definitiefase, ontwerpfase, (werk)voorbereidingsfase, realisatiefase en beheer- of nazorgfase. Fase na fase werden doorlopen waarbij de output van de ene fase de input vormde voor de andere fase. Vandaar de naam ‘watervalmethode’. Deze methoden zijn gebaseerd op de beheercyclus van kwaliteitsgoeroe Deming (Plan-Do-Check-Act) en leggen sterk de nadruk op het faseren, beheersen en beslissen over tijd, geld en kwaliteit. Men spreekt ook wel over het beheersen van de MOSQUITO-aspecten: MOney, Safety, QUality, Information, Time & resources en Organization. Door de strakke fasering zijn er ook duidelijke meet- en beslispunten.

5.7.3.2 Incrementele methode

De watervalmethode had in de praktijk nogal wat nadelen, vooral zoals die binnen de ICT-wereld door System Development Methodology (SDM) werd voorgeschreven. Het was een formele, min of meer bureaucratische methode dat veel papierwerk genereerde. Daarnaast moet eerst het gehele informatiesysteem ontworpen, gebouwd en getest worden voordat het in gebruik genomen kon worden. Tegen de tijd dat het zo ver was waren de eindgebruikers wensen al weer veranderd en voldeed het systeem niet (meer) aan de verwachtingen. Als antwoord hierop werd begin jaren negentig de incrementele methode populair. Andere namen zijn bijvoorbeeld RAD (Rapid Application Development) of EVO (Evolutionaire systeemontwikkeling). Ook werd SDM getransformeerd tot een ‘Dynamic System Development Methodology’, DSDM dus. Al deze methoden hebben dezelfde kenmerken: Een cyclisch proces met incrementele (stapsgewijze) oplevering, een klein projectteam met ontwikkelaars en eindgebruikers die nauw samenwerken, sterke betrokkenheid van eindgebruikers bij het ontwerp (via bijvoorbeeld prototyping), flexibiliteit in projectuitvoering en volgorde van op te leveren incrementen en projectbeheersing via ‘timeboxing’ (hierbij staat de doorlooptijd vast en bepaalt dat, mede met het beschikbare budget, de maximaal te realiseren aantal softwarefuncties). Binnen een increment wordt op kleinere schaal wel weer gebruik gemaakt van de standaard fasering uit de watervalmethode. De ervaringen met de incrementele methode zijn, zeker op het gebied van systeemontwikkeling, positief te noemen[19].

5.7.3.3 Projectmatig creëren

De hiervoor beschreven projectmanagementmethoden leggen vooral de nadruk op de strakke beheersing van projecten en dan met name op de aspecten tijd (time controle), geld (cost control) en kwaliteit (quality control). Nieuwe methoden die de afgelopen jaren ontwikkeld werden, zoals beschreven in het boek ‘Projectmatig Creëren[20]’, leggen vooral de nadruk op het managen van chaos, energie, creativiteit en het scheppend vermogen van het projectteam (‘als je het wilt, dan lukt het ook’). Dit vanuit de filosofie dat een eenzijdige focus op ‘harde’ projectmanagement aspecten ook geen garantie is voor succes.

5.7.3.4 PRINCE2

De bekendste en belangrijkste projectmanagementmethode is PRINCE[21] (Projects In Controlled Environments). Deze methode is in 1989 opgesteld door het Britse Central Computer and Telecommunications Agency (CCTA). In 1996 is een verbeterde versie uitgebracht met de naam ‘PRINCE2’. PRINCE2 is geschikt voor alle typen projecten, van klein tot groot. De methode is gebaseerd op praktijkervaringen met verschillende projectmanagementmethoden en praktijkvoorbeelden. PRINCE2 heeft duidelijke relaties met programmamanagement en de ISO 9001 kwaliteitsnorm. PRINCE2 is een proces georiënteerde methode in tegenstelling tot bijvoorbeeld lineaire methoden als de watervalmethode. PRINCE2 onderkent verschillende processen van ‘Starting up a project’ (SU) tot ‘Closing a Project’ (CP). Daarnaast kent men acht componenten van ‘Organisatie’ tot ‘Risicobeheer’. Binnen PRINCE2 zijn ieder proces en iedere component uitgewerkt in activiteiten, tips, trucs, do’s en dont’s. PRINCE2 besteedt veel aandacht aan de ‘business case’ (de economische rechtvaardiging van het project) en mogelijke veranderingen in de projectomgeving tijdens de projectuitvoering. Deze focus zorgt ervoor dat er alleen energie gestopt wordt in projecten die bijdragen aan de doelstellingen van de organisatie en het zorgt er voor dat er snel bijgestuurd kan worden als de omstandigheden wijzigen[22]. Bij PRINCE2 zijn een aantal aspecten van groot belang[23]:

• Eigenaarschap van projecten en beslissingen en mandateringen;
• Communicatie en overdracht;
• Preproject en initiatie fase:
  • Het doel van de initiatieffase is het verkrijgen van helderheid over de vraag, overeenstemming over het probleem en afspraken over de wijze waarop een project gedefinieerd kan worden in een projectopdracht.[24]

5.7.3.5 Body Of Knowlegde (BOK)

Doordat projectmanagement een eigen vakgebied is hebben de beroepsorganisaties in binnen- en buitenland sinds enkele jaren de kennis van projectmanagement gebundeld in de zogenaamde ‘Body Of Knowledge’ (BOK). Zo is er de PM-BOK van de Internationale Project Management Association (IPMA)[25] en is het Nederlandse Project Management Instituut (PMI) bezig met het opstellen van de Nederlandse PM-BOK. In dat kader is de Nederlandse Competence Baseline (NCB) verschenen. Deze ‘Body of Knowledges’ worden gebruikt voor opleiding en training, voor het toetsen van de kennis van projectmanagers en voor het certificeren van projectmanagers.

Fig. 163 ICT-Projectmanagement verandering[26]

Voor de verdere uitwerking van het projectmanagement tijdens de implementatie is gekozen voor de Project Management Body of Knowledge. Een eerste overzicht wordt weergeven in figuur 162 welke daarna op de opvolgende paragrafen worden beschreven.

Fig. 164 Overzicht van projectmanagement werk- en kennisgebieden[27].

De tabel hierboven geeft de hoofdgroepen van projectmanagement aan die hierna in meer detail worden beschreven.

Tabel 89 Proces groepen en de kennisgebieden[28]

5.7.4 Project integratie management

Binnen project integratie management zijn er drie belangrijke documenten en hun onderverdeling[29]:

• Project charter is de formele autorisatie voor het project via de business case;
• Project scope document geeft aan welke werkzaamheden moeten worden opgeleverd en welke zaken dienen te worden geleverd;
• Project management plan geeft aan hoe het werk wordt uitgevoerd zoals:
  • Scope management plan;
  • Planning management plan;
  • Kosten en budget management plan;
  • Kwaliteit management plan;
  • Teambezetting management plan;
  • Communicatie management plan;
  • Risico management plan;
  • Inkoop management plan.

Voor een eindgebruiker geeft vooral het projectmanagement document een goed inzicht hoe de leverancier de implementatie gaat uitvoeren. Mogelijk is dit ook tijdens het selectieproces in te zien van een andere installatie om hier een indruk van te krijgen.

Fig. 165 Noodzakelijke componenten en hun onderlinge relaties

Bovenstaande figuur 164 geeft goed aan de spagaat waar en projectleider zich in bevindt. Vooral dat omvang (scope) meestal tijdens het project gemiddeld groeit met 25% volgens Kalsbeek[30]. De projecttijd meestal korter moet, de beschikbare mensen niet altijd beschikbaar zijn en de kosten steeds groter worden.

5.7.5 Scope management

Project scope management omvat de vereiste processen die nodig zijn om het project inclusief alle vereiste taken en alleen de vereiste taken om het project succesvol af te ronden[31].

Scope management is onder te verdelen in de volgende subonderwerpen:

• Scope planning:
  • De voorbereiding van een gedetailleerde scope planning is kritisch voor het project succes en wordt opgesteld op basis van de op te leveren project gedeelten, aannames en beperkingen zoals die gedocumenteerd zijn in de initiële projectfase en in het voorlopige projectdocument.
• Scope definitie;
• Opstellen Work Breakdown Structure (WBS):
  • Het project wordt in sub werkbare delen opgesplitst.
• Scope verificatie:
  • De formele acceptatie van de op te leveren onderdelen.
• Scope beheersing:
  • Op een gecontroleerde manier omgaan met wijzigingen in de projectscope, dit is van vitaal belang zoals ook bij risicomanagement is beschreven is er een relatie tussen aantal wijzigingen en hogere kosten en een lagere kwaliteit van het eindproduct.

Jaarsma en Meijer[32] geven aan dat projectmanagement en speciaal scope management heel veel verschillende aspecten kent zoals hieronder is aangegeven in figuur 160.

Fig. 166 Omgeving van een automatiseringsimplementatie

De hoeveelheid werk die tijdens een implementatie uitgevoerd moet wordt bepaald door de scope maal de vereiste flexibiliteit maal de organisatorische complexiteit, dus is te bepalen door:

• Hoeveel dingen moeten er gedaan worden;
• Hoeveel keuze mogelijkheden zijn er voor elk?
• Met hoeveel mensen moet ik het over iedere keuze eens worden?[33]

5.7.5.1 Scope definitie en afbakening

Een belangrijk onderdeel van scope management is de afbakening. Tijdens de afbakening fase moeten de volgende doelen worden bereikt[34]:

• Er achterkomen wat de opdrachtgever wil;
• Het projectresultaat te definiëren;
• Daaruit activiteiten af te leiden en die te bundelen tot fasen;
• Met de opdrachtgever afspraken maken over de acceptatieprocedure voor de producten;
• Het configuratiebeheer te regelen over de materiële producten.

De eerste activiteit is aan te geven waarom de opdrachtgever het project heeft geïnitieerd en wat de business case is door onderstaande vragen te beantwoorden.

• Beschrijf de redenen waarom het project door de opdrachtgever is geïnitieerd.
  • Geef weer wat de opdrachtgever vraagt:
    • Welke problemen wil hij oplossen?
    • Welke doelen wil hij bereiken?
    • Vanuit welke specifieke eisen en wensen?
    • Met welke organisatorische en technische raakvlakken?
  • Maak de doelstellingen SMART (zie paragraaf 5.4 functionaliteit);
  • Leg alles vast met bronvermelding (naspeurbaarheid!);
  • Vraag goedkeuring aan de opdrachtgever.
• Beschrijf aan welke oplossing de opdrachtgever denkt:
  • In welke richting zoekt hij?
  • Welke randvoorwaarden en beperkingen laat hij daarbij gelden?

Taken ten aanzien van de afbakening zijn[35]:

• Leid uit de gegevens over wat de opdrachtgever vraagt af wat de projectdoelstellingen moeten zijn. Maak ze SMART, zodra u het projectresultaat er aan kan toetsen;
• Controleer de juistheid en de actualiteit van de uitgangspunten en aannames;
• Ontwerp oplossingsalternatieven:
  • Controleer of ze voldoen aan de eisen, wensen, randvoorwaarden en beperkingen;
  • Volg de oplossingsrichting waaraan de opdrachtgever denkt;
  • Overleg met de opdrachtgever en kies één of meer alternatieven voor verdere uitwerking.
• Stel een lijst op van de te leveren materiële en immateriële producten en deel producten.

5.7.5.2 Problemen rond scope management

De zwakte van elk systeemontwerp is dat men het geaccepteerd moet krijgen voor men met de bouw aan de slag kan. Een welbeschouwd bedrijfspolitiek, organisatiepolitiek of gewoon politiek element. Dit leidt ertoe dan men het aantal actoren zal proberen te beperken en elementen waarover onzekerheden zouden kunnen ontstaan zal buitensluiten. Ergo het ontwerp wordt in ieder geval een vereenvoudigde weergave van wat er feitelijk gevraagd wordt, terwijl het alsnog zo gecompliceerd is dat elke beslissing voor de doorsnee actor (die geen zwemles heeft gehad) een sprong in het diepe is[36].

Fig. 167 Dilemma: Management attentie en invloed tijdens een project[37]

Het tweede grote probleem is dat in de begin fase er te weinig management aandacht is voor het project terwijl men op dat moment nog maximale invloed kan uitoefenen tegen minimale kosten.

5.7.6 Project tijdmanagement

Project tijdmanagement omvat de processen die nodig zijn om het project op tijd af te ronden. Processen die onderdeel uitmaken van tijdmanagement bij een project zijn[38]:

1.      Activiteiten definitie:

a.       Bepaal de specifieke te plannen activiteiten die uitgevoerd moeten worden om de verschillende projectresultaten te halen;

2.      Volgorde van activiteiten:

a.       Bepaal en documenteer afhankelijkheden van bovenstaande activiteiten;

3.      Bepaal de middelen om de activiteit uit te voeren:

a.       Bepaal type en hoeveelheden van middelen die nodig zijn om iedere taak uit te voeren;

4.      Bepaal de tijdsduur om de afzonderlijke activiteiten uit te voeren;

5.      Projectplan ontwikkeling:

a.       Analyse van volgorde activiteiten, duur, benodigde middelen, planning en beperkingen om het projectplan te ontwerpen;

6.      Beheers en controleer de projectplanning.

Bovenstaande processen hebben een interactie met elkaar als wel met andere processen binnen het project.

5.7.6.1 Project doorlooptijd

Skrokov[39] heeft onderstaande tabel opstelt in 1991 wat hij de minimum tijd noemde om een taak te volbrengen. Sinds 1991 is er wel wat veranderd. Hard- en software kunnen nu voor het grootste onafhankelijk van elkaar worden ontwikkeld. Wat de software levering ongeveer met 4 maanden versnelt. Anderzijds kosten de specificatiefase meer tijd evenals de FAT test en de veld commissioning fase. De totale tijd blijft dus ongeveer gelijk.

Tabel 90 Project mijlpalen in de verstreken tijd na de start van het project

5.7.6.2 Kritische planningsmomenten

De belangrijkste tijdsbeperkingen die er gelden bij DCS-projecten is de ‘turnaround’ periode.

De turnaround periode is onder te verdelen in drie hoofdgroepen:

1.      Zijn alle voorbereidingen gereed bij de start van de turnaround?

2.      Hoe lang moet het productieproces stil liggen om het DCS-systeem op de procesapparatuur zoals zenders, kleppen, PLC’s en motoren aan te sluiten en correct te laten werken;

3.      Hoeveel tijd kost het om weer 1^e soort productie te maken, met andere woorden een probleemloze opstart[40].

Het eerste punt is kritisch want een turnaround is een megaproject van soms meer dan 50 miljoen euro aan werkzaamheden in vier tot zes weken tijd. Als het DCS-implementatieteam dit tijdvenster mist dan is de volgende turnaround mogelijk pas over vier of zes jaar.

Het tweede punt wordt bepaald door:

·        Vrije ruimte is er in rackrooms;

·        Hoeveel mensen kunnen er gelijktijdig werken;

·        Zijn er snelkoppelingen beschikbaar op ‘backplanes’ van andere hardwareleveranciers zodat de afzonderlijke kabeladers niet los hoeven, aantal werkuren per dag 8 uur/dag of 24 uur/dag en de ervaring van het implementatieteam.

Het derde punt wordt bepaald door de kwaliteit van de commissioning testen, de kwaliteit van de software en de inbedrijfstellingsvaardigheden van de engineers.

Anderson[41] van Catalyst Paper stelt dat niet de leverancier maar de implementatiemethode en standaarden de belangrijkste beslisparameter zijn. Zij kiezen die leverancier met de beste implementatiemethode waarbij minimale proces downtime zal optreden. Slechts een beperkt aantal ICT-projecten worden succesvol afgesloten (tijd, geld, kwaliteit) en Daudey en Tullemans[42] stellen dat zowel de opdrachtgevers, projectmanagers als ICT-specialisten vrijwel altijd de omvang en complexiteit van het werk onderschatten, mede door interne- en externe tijdsdruk. Projecten worden niet te laat opgeleverd maar te vroeg beloofd.

5.7.6.3 Implementatiestrategieën

De implementatie is op verschillende manieren mogelijk. Er kan sprake zijn van een proefsituatie met een mogelijke terugval. Voor de uitrol moet de organisatie onderstaande keuze maken:

• Ingebruikname:
  • Gefaseerd;
  • Big bang;
  • Parallel;
  • Gecombineerd.
• Organisatorisch:
  • Per business unit;
  • Afdeling;
  • Team.
• Functioneel:
  • Verlading;
  • Productie;
  • Inpakafdeling.
• Procesmatig:
  • Basisbesturing;
  • Advanced control;
  • Externe verbindingen (remote operatie).
• Combinatie hiervan.

Een DCS-systeem kan op drie manieren worden uitgerold: Stap voor stap, big bang en uitrollen per site. Een combinatie van deze drie werkwijzen is uiteraard steeds mogelijk.

5.7.6.3.1 Gefaseerde - stap voor stap implementatie

Bij een gefaseerde - stap voor stap implementatie wordt de software of systemen in verschillende stappen geïnstalleerd. Voorbeelden kunnen zijn migratietrajecten zoals eerst HMI en later controllers en nog eens later de I/O. Het risico op mislukken is vrij laag doordat het project minder complex wordt om te coördineren, controleren en organiseren. Daarnaast is er een geleidelijke overgang in de onderneming waardoor de medewerkers de kans krijgen om zich aan te passen aan de veranderingen in hun werkomgeving. Een groot nadeel is dat er tijdelijke voorzieningen zoals interfaces gebouwd moeten worden tussen het nieuwe en de oude systemen. Het aanmaken van deze interfaces kost heel wat tijd en geld en draagt bovendien niet bij aan de kwaliteit van het uiteindelijke resultaat. Een ander nadeel is dat de implementatie vrij lang zal duren en de motivatie bij het implementatieteam wel eens kan dalen naarmate het project vordert (Welti[43]).

5.7.6.3.2 Big bang

Bij een big bang implementatie wordt de bestaande installatie in één enkele operatie vervangen door een nieuw DCS-systemen. Vooraf moet het systeem uiteraard intensief getest worden. Voordeel bij deze implementatie wijze is dat geen tijdelijke interfaces gecreëerd moeten worden. Bovendien kan het systeem na de implementatie dadelijk in gebruik genomen worden. Natuurlijk heeft deze manier van werken ook zijn nadelen, zo zal er een verhoogde behoefte zijn aan coördinatie en integratie. Medewerkers (operators) krijgen niet de mogelijkheid om zich rustig aan te passen aan het nieuwe systeem. Om die reden mag de organisatorische en procestechnische veranderingen bij een big bang implementatie niet al te groot zijn om de medewerkers niet te overweldigen. De kwaliteit van de configuratie en interfaces na de verandering moet bovendien perfect zijn om grote problemen te vermijden. Het is duidelijk dat de systeemstructuur niet al te complex mag zijn om een DCS-systeem via een big bang methode te implementeren.

5.7.6.3.3 Uitrollen

De derde mogelijkheid is dat in één site van de onderneming een volledige implementatie gedaan wordt, waarna deze dan uitgerold wordt naar de andere sites. Dat uitrollen kan dan opnieuw stap voor stap of via de big bang methode. Het voordeel bij deze werkwijze is dat men na de eerste implementatie deze ervaring kan gebruiken in de volgende implementaties. Bijgevolg daalt het risico op falen. Een ander gevolg is dat de verschillende sites heel goed met elkaar geïntegreerd zullen zijn via een uniform systeem. Gevaar bij deze manier van implementeren, is dat specifieke processen van bepaalde sites verwaarloosd worden en als normale processen behandeld worden (Welti)[44]. Deze methode is vooral geschikt als er meerdere locaties zijn (zoals bij Waterschappen) of erg grote proces units en dat er te weinig tijd is om in één turnaround om het alles in één keer te doen.

In de praktijk zien we twee hoofdwerkwijzen:

1.      Bij een nieuwe plant zal voor de big bang methode kiezen;

2.      Bij een migratie wordt vaak gekozen voor een uitrol met als onderverdeling de stap bij stap methode.

5.7.7 Projectkosten en budget management

Projectkosten management omvat de processen die te maken hebben met planning, schattingen, budgetteren en het controleren van kosten zodat het project binnen het afgesproken budget kan worden afgerond. De hoofdonderdelen zijn[45]:

1.      Kostenbegroting;

• Bepaal de waarschijnlijke kosten van de middelen die nodig zijn om het project compleet af te ronden.

2.      Budgetbepaling:

• Sommeer de begrote kosten van alle afzonderlijke activiteiten en/of werkpakketten om de basiskosten te bepalen.

3.      Kostenbeheersing en bewaking:

• Beïnvloeden van factoren die kostenvariaties kunnen creëren en bewaken van afwijkingen in de bestedingen ten opzichte van het projectbudget.

Project kosten- en budget management is een primaire functie en een aandachtspunt binnen een DCS-project. Het is belangrijk om er rekening mee te houden dat besluiten betreffende projectkosten een effect kunnen hebben op de gebruik en/of de onderhoudskosten. Bijvoorbeeld door minder ontwerpreviews te houden zullen de projectkosten dalen maar de operationele kosten stijgen. Het begrip ‘Life Cycle Cost’ zoals in paragraaf ‘5.12 kosten’ is beschreven speelt hierbij een belangrijke rol.

5.7.7.1 Budgetbepaling

Het budget wordt al bepaald voordat er met het project wordt begonnen en dit wordt door de leverancier gedaan in samenspraak met de eindgebruiker. Er is meestal eerst sprake van een budgetprijs deze budgetprijs wordt dan opgenomen in het financiële management budgetjaarplan. Pas als dit jaarbudget is goedgekeurd zal er begonnen worden met een meer in detail opgebouwde begroting. Jaarsma^[46] (Projectmanager DCS-leverancier) geeft aan dat in deze fase opdrachtgevers vaak veel tijd en geld besteden aan het schrijven van dikke, algemeen georiënteerde projectspecificaties. Deze worden vervolgens door de inschrijvers/ leveranciers weer vertaald naar de mogelijkheden en de onmogelijkheden van hun apparatuur en systemen. Het probleem is dat de beschikbare apparatuur en systemen op de markt zich niet eenvoudig meer laten onderbrengen in een dergelijke algemene specificaties. Een direct op het doel gerichte aanpak heeft in deze projectfase de voorkeur. De betrokkenheid van een DCS-leverancier in deze fase van een project heeft als eerste voordeel dat de door de opdrachtgever vervaardigde algemene specificaties en de daaraan verbonden kosten achterwege kunnen blijven. Het tweede en zeker niet minder belangrijke voordeel is tijdbesparing! Vele maanden eerder kan hierdoor de interne budgetaanvraag worden ingediend en kan het project worden gerealiseerd. Jaarsma^[47] noemde in 2006 dat dit zeker voor grotere projecten (> 10 miljoen dollar) nu de gangbare werkwijze is. Tevens worden diensten van systeemintegrators toegepast doordat die onafhankelijker zijn dan de DCS-leveranciers.

De traditionele kosten begrotingsmethodiek waar eenvoudig alle kostenelementen worden opgeteld zal niet resulteren in de meest waarschijnlijke projectkosten. De traditionele methodes zijn niet in staat om de volgende vragen te kunnen beantwoorden[48]:

1.       Hoe groot is de kans dat er een projectbudget overschrijding is?

2.       Wat zijn de risico’s ten aanzien van dit project?

3.       Waar zijn de risico’s in dit project?

De Monte Carlo simulatiemethode is wel in staat om antwoorden op deze vragen te geven.

5.7.7.2 Risicomanagement ten aanzien van kosten

Zoals uit de inleiding al bleek komen tijd en kostenoverschrijdingen meestal voor bij ICT projecten. De kans op een kostenoverschrijding is zelfs groter als de kans dat het project binnen de afgesproken financiële kaders blijft. Hulett geeft aan dat voor een goede risicoanalyse aanvullende data nodig is en niet iedereen voelt zich even comfortabel bij het beantwoorden van deze vragen. De vragen kunnen voor sommige personen zelfs bedreigend overkomen. Er zal tijdens de vragensessie voor ieder kostencomponent drie waarden bepaald moeten worden:

1.      Het meest pessimistische scenario voor de kostenbepaling. In dat geval gaat alles fout en zal het project over gedaan moeten worden. De kans dat dit gebeurt is kleiner dan 1%.

2.      Het optimistische scenario voor de kostenbepaling, in dit geval gaat alles goed en zijn de kosten lager dan verwacht. De kans dat dit gebeurt is kleiner dan 1%.

3.      Het meest waarschijnlijke scenario voor de kostenbepaling, dit is niet hetzelfde document als de baseline begroting. Deze baseline begroting is meestal een politiek document dat samengesteld is om indruk op de eindgebruiker of intern management te maken. Iedere inschatting is zo optimistisch dat dit niet kan worden bereikt zonder veel geluk en veel niet betaalde overuren.

Fig. 168 Kosten verdeling met risico inschatting

We kunnen de verwachte kosten met onderstaande formule beschrijven:

Naast de hiervoor genoemde methode zijn er ook meer geavanceerde mogelijkheden waarbij iedere afzonderlijke mogelijkheid wordt uitgetest via een iteratief proces. Hieronder staat in figuur 169 een voorbeeld verdeling van een Monte Carlo simulatie. In paragraaf 4.25.15 wordt de Monte Carlo methodisch beschreven.

Fig. 169 Monte Carlo resultaat voor project kostenverdeling

In bovenstaand voorbeeld was de afgegeven prijs 25.200 euro en de simulatie laat zien dat de kans dat dit of een lager bedrag ook de echte kosten zijn maar 13,46% zijn en er een kans van 86,5% dat er een kosten overschrijding zal zijn. Het gewogen gemiddelde is 26.250 euro.

Fig. 170 Cumulatief projectresultaat kansverdeling

Door het toepassen van een cumulatieve grafiek (zie figuur 170) is te bepalen wat de kans op een kosten overschrijding. Deze techniek kan ook gebruikt worden om de kans te bepalen dat de doelstellingen van de business case worden gehaald.

5.7.7.3 Interne- of externe projectkosten

De strijd over welke kosten nu wel onder het projectbudget vallen en welke niet is een terugkerend probleem bij veel implementaties. Het is dan ook belangrijk om hier tijdens de scope bepaling duidelijke afspraken over te maken. Hieronder staan een aantal voorbeeld statements van zaken die in de praktijk voorkomen:

• Een turnkey project bij een DCS-leverancier betekend niet dat de eindgebruiker niets hoeft te doen. Bijvoorbeeld kennis inbrengen van bestaande E/I installaties en proceskennis;
• De meest optimale projectplanning past niet altijd met de actuele productieplanning. Dit leidt tot extra reiskosten en tijd voor de leverancier, voor wie zijn die kosten?
• De leverancier rekent op de werkzaamheden overdag uit te voeren maar door productiedruk moet er rond de klok gewekt worden, voor wie zijn deze kosten?
• Wie haalt de oude tuning configuratie uit de bestaande regelaars (eindgebruiker of leverancier)?
• Eindgebruiker wil een deel van de installatie (bijvoorbeeld stoom of luchtsystemen bij een greenfield plant) eerder in bedrijf nemen dan is afgesproken, het gevolg hiervan is dat de leverancier minder eenvoudig een reboot kan uitvoeren of de elektrische spanning van het systeem kan halen. Daarnaast zijn nu installatiedelen die onder spanning staan wat gevolgen heeft voor het werktempo dan de installateurs. Deze moeten nu voorzichtiger zijn om geen spanningvoerende delen te raken of kabels los te trekken in het geval zij er nieuwe kabels bij trekken. Het gevolg hiervan is weer dat ze minder aansluitingen per tijdsperiode kunnen uitvoeren als in het oorspronkelijke plan.

5.7.8 Project kwaliteitsmanagement

Project kwaliteitsmanagement omvat alle activiteiten van de uitvoerende organisatie betreffende kwaliteitsbeleid, doelstellingen en verantwoordelijkheden zodat het project voldoet aan de gestelde eisen. Het kwaliteitsmanagement programma omvat de volgende onderdelen[49]:

1.      Kwaliteitsplan:

·        Bepaald welke kwaliteitsnormen relevant zijn voor het project en hoe je er aan kunt voldoen.

2.      Uitvoeren van kwaliteitsborging programma:

·        Pas de geplande systematische kwaliteits activiteiten toe om er zeker van te zijn dat alle benodigde projectprocedures worden toegepast.

3.      Uitvoeren van kwaliteitscontrole:

·         Bewaak specifieke projectresultaten en vergelijk of deze voldoen aan de relevante kwaliteitsnormen en bepaal de methoden om de oorzaken van negatieve projectprestaties weg te nemen.

Fig. 171 Oorzaak- en gevolg diagram ten aanzien van de kwaliteit.

5.7.8.1 Het DeLone en McLean Informatiesysteem succesmodel

Het model van DeLone en McLean[50] bepaald de mate van succes waarmee een informatiesysteem is geïmplementeerd. Succes omvat volgens DeLone en McLean zes dimensies:

1.      Kwaliteit van het informatiesysteem;

2.      Kwaliteit van de informatie gegenereerd door het systeem;

3.      Gebruik, zowel van het systeem als de gegenereerde informatie;

4.      Gebruikerstevredenheid;

5.      Individuele impact: Het effect dat de informatie op het gedrag van de eindgebruikers heeft;

6.      Organisatorische impact: Het effect dat de informatie op de prestaties van de onderneming heeft.

Fig. 172 De zes dimensies van succes. Bron DeLone en McLean

Fig. 173 Het IS succesmodel van DeLone en McLean[52]

Doordat het gebruik van een DCS-systeem verplicht is zal de operator het systeem moeten gebruiken om de plant te besturen. Wat wel een meetwaarde voor goed gebruik is, is het aantal regelingen die op hun voorgeschreven mode draaien (auto of cascade) en dus niet op handbediening. Dit geld zowel voor basis als geavanceerde besturingsregelingen. We kunnen dus stellen dat afhankelijk van de kwaliteit van de data (veldinformatie) en het DCS-systeem het gebruik wordt beïnvloed. Uiteraard zal een systeem waar de operator veel regelingen op handbediening heeft niet bijdragen aan de gebruikerstevredenheid en dus ook niet bijdragen tot de verwachte projectvoordelen. Slechts als alle dimensies (en zeker deze laatste drie) positief geëvalueerd worden, kan er gesproken worden over een succesvolle implementatie. Worden gebruikerstevredenheid, individuele impact en organisatorische impact negatief beoordeeld, dan is de implementatie zeker niet succesvol. Zijn enkele dimensies positief, terwijl andere negatief zijn, dan is het moeilijk te beoordelen of het al dan niet een succes geworden is (Zhang et al.^[51]). Er was wat kritiek op het eerste model Van DeLone en McLean wat leidde tot onderstaand model, waar gebruik vervangen is door intentie tot gebruik (denk aan het voorbeeld van de regelaar) en de mate van ondersteuning en onderhoud zoals bijvoorbeeld het tunen van de besturingsregelaar of het geven van trainingen.

5.7.8.2 Maatstaven voor een projectsucces

Er zijn al heel wat studies verricht naar de factoren die bijdragen tot het succes van de implementatie van ICT-systemen. Wat exact bedoeld wordt met succes, is echter veel moeilijker te definiëren. Uit een ERP-implementatie onderzoek van KPMG Management Consulting blijkt dat van alle ondernemingen 89% beweerde dat hun implementatie succesvol was[53]. Slechts een kwart van hen had echter alle vooropgestelde voordelen gekwantificeerd en behaald (Markus en Tanis[54]). Dit toont duidelijk aan dat men in de praktijk zelden termen als succes en mislukken, definieert en kwantificeert. Nochtans zijn er voldoende maatstaven voorhanden. Verrassend genoeg wordt succes in de praktijk meestal bepaald door slechts twee factoren: Op tijd en binnen budget (Rosemann en Wiese)[55].

Wanneer is er sprake van een succesvol project? Hierover bestaan verschillende inzichten van Baccarini[56], Vartiainen en Pirhonen^[57] en Rosemann en Wiese[58].

Hieronder staan een aantal mogelijke definities en maatstaven:

• De eindgebruiker is tevreden (met het proces en het product);
• Opleveren van het geen is afgesproken, conform specificatie;
• Voldoet aan de vooraf vastgelegde ondernemingsdoelstellingen en verwachtingen van de eindgebruiker;
• Geplande efficiëntieverbeteringen van de onderneming behalen;
• Op tijd – volgens planning;
• Binnen budget;
• De mate waarin het systeem benut wordt door de eindgebruikers;
• Het systeem (door het project geleverd) draagt bij aan het succes van de onderneming;
• Het systeem biedt (door het project geleverd) nieuwe kansen voor de onderneming.

De mate waarin het systeem benut wordt door de eindgebruikers kan evenmin als maatstaf voor succes gebruikt worden. Als het DCS-systeem eenmaal volledig geïnstalleerd en geïmplementeerd is, zal het gebruik, bij gebrek aan een alternatief, verplicht worden. Zelfs als een implementatie niet op tijd of binnen het budget klaar raakt, kan ze door de betrokken onderneming nog steeds als een succes gezien worden, bijvoorbeeld indien op lange termijnde baten van het DCS-systeem toch nog groter zijn dan de kosten (Zhang et al.[59]). Bijgevolg blijven er maar drie criteria over om het succes van een DCS-implementatie te meten: Gebruikerstevredenheid, geplande efficiëntieverbeteringen van de plant en vooraf vastgelegde projectdoelstellingen. Bovendien kunnen deze laatste twee samengenomen worden als de mate waarin aan de doelstellingen van het management voldaan wordt.

5.7.8.3 Kwaliteitseigenschappen requirements

Het bepalen van de kwaliteitseisen is iets dat in de praktijk weinig gebeurt. Het specificeren van kwaliteitseisen is dan ook een onderontwikkeld gebied. Door de kwaliteitseisen te koppelen aan eindgebruiker requirements kunnen we een preciezere beschrijving maken van de gewenste kwaliteit. Zo dragen we zorg voor een volledige en effectieve requirements-analyse. Wanneer de eindgebruiker van een DCS-leverancier beschrijft wat de eisen zijn voor het systeem, blijven de impliciete wensen achterwege. Vaak wordt pas na oplevering van het systeem ontdekt dat het toch niet de kwaliteit heeft die de eindgebruiker ervan verwachtte: Functioneel voldoet het systeem weliswaar, de gebruikersvriendelijkheid en de tijd die nodig is om met het systeem te leren werken is teleurstellend. Tijdens de productspecificatie heeft de eindgebruiker benadrukt dat het een gebruikersvriendelijk systeem moet zijn en dat zijn medewerkers er snel mee moeten kunnen werken. Helaas heeft dit niet geresulteerd in het gewenste systeem. Impliciete eisen en verwachtingen van het systeem zijn adders onder het gras. Het probleem in de bovenstaande situatie is dat eindgebruiker en leverancier een verschillende interpretatie van de kwaliteit van het eindproduct hebben. Het vastleggen van de kwaliteitseisen op een uniforme manier helpt de moeizame discussie tijdens de FAT en na systeem oplevering te voorkomen. De internationale standaard ISO 9126 vormt een basis voor de beschrijving van de externe eigenschappen van producten. Het QUINT model dat een uitbreiding is van de ISO 9126 standaard voor software productkwaliteit biedt hiervoor de juiste gereedschappen.

 
5.7.8.4 ISO /IEC 9126 model

In het ISO /IEC 9126 model komt: ‘Quality in Use’ overeen met de manier waarop de eindgebruiker de kwaliteit in zijn dagelijkse werk ervaart. Deze kwaliteit wordt gedefinieerd door vier karakteristieken.

Fig.  SEQ Fig. 174 Quality in Use model[60]

De vier onderverdelingen en definities uit ISO 9126-1 ‘Quality of Use’ zijn:

• Effectiviteit:
  • Het vermogen van het softwareproduct om eindgebruikers in staat te stellen om specificeerde doelstellingen, nauwkeurigheid en volledigheid binnen de gespecificeerde gebruikersomgeving te bereiken.
• Productiviteit:
  • Het vermogen van het softwareproduct om eindgebruikers in staat te stellen om de benodigde hoeveelheden middelen efficiënt te gebruiken binnen de gespecificeerde gebruikersomgeving.
• Veiligheid:
  • Het vermogen om het softwareproduct te gebruiken binnen aanvaardbare niveaus van risico ten aanzien van gezondheid voor mensen, veiligheid, uitrusting, financieel of het milieu binnen de gespecificeerde gebruikersomgeving.
• Tevredenheid:
  • De mogelijkheden van het software product stellen de eindgebruiker binnen een gespecificeerde gebruikersomgeving tevreden.

5.7.8.5 Extended ISO Model

QUINT (Quality in Information Technology) is een begrippenkader voor de specificatie en toetsing van de kwaliteit bij een softwareproduct ontwikkeling. Daarin worden definities gegeven van kwaliteitseigenschappen met bijbehorende indicatoren, metrieken en beoordelingsvoorschriften. Dit begrippenkader sluit direct aan op de karakteristieken van softwareproducten zoals die gedefinieerd worden in de ISO standaard voor softwareproducten: ISO 9126. Het Extended ISO-model is volledig in overeenstemming met deze standaard maar vormt daar in twee opzichten een uitbreiding op.

1.      Het model bevat meer kwaliteitseigenschappen doordat een aantal in de praktijk gebruikte eigenschappen zijn toegevoegd;

2.      Het model biedt een uitbreiding door de toevoeging van indicatoren, meetschalen en beoordelingsvoorschriften. Deze blijken in de praktijk de handvatten te vormen waarmee specificatie en validatie van software eigenschappen mogelijk wordt[61].

Om kwaliteit te definiëren is een eenduidig begrippenkader nodig. Het extended ISO model helpt hierbij door onderstaande deelgebieden:

1.      Functionaliteit;

2.      Betrouwbaarheid;

3.      Bruikbaarheid;

4.      Effectiviteit;

5.      Onderhoudbaarheid;

6.      Portabiliteit.

Fig. 175 Overzicht Extended ISO model-kwaliteitseigenschappen van softwareproducten[62]

In het QUINT model zijn de belangrijkste elementen[63]:

• Ontwerpprincipes;
• Subgroepen hierin zijn:
  • Aantrekkelijkheid;
  • Bestuurbaarheid;
  • Consistentie;
  • Eenvoud;
  • Flexibiliteit;
  • Herkenbaarheid;
  • Taakgeschiktheid;
  • Terugkoppeling;
  • Tolerantie;
• Indicatoren;
• Beoordelingsvoorschriften;
• Streefwaarden.

5.7.8.6 Project Quality Assurance ProQA model

ProQA staat voor Project Quality Assurance en is een geïntegreerde methode voor kwaliteitszorg in ICT-projecten. ProQA is gebaseerd op een aantal uitgangspunten.

• Ten eerste dienen eind- en tussenproducten evenals de processen aan de hand waarvan deze producten worden gemaakt, helder te worden gedefinieerd;
• Ten tweede dienen kwaliteitsmaatregelen zo vroeg mogelijk in het traject te liggen en dienen eventuele fouten dan ook zo vroeg mogelijk gevonden en hersteld te worden;
• Ten derde dienen verschillende kwaliteitsmaatregelen met elkaar als één geheel te worden uitgevoerd. Allerlei losstaande kwaliteitsmaatregelen kunnen best nuttig zijn, maar dat is niet optimaal;
• Ten vierde dienen de kwaliteitsmaatregelen ook zo veel mogelijk geïntegreerd met andere systeemontwikkelingsactiviteiten te worden uitgevoerd.

Bij de ontwikkeling van ProQA is gebruikgemaakt van al bestaande en bewezen technieken zoals ISO 9126, inspecties, reviews, verbetercycli en gestructureerd testen. Van deze technieken en enkele aanvullingen is een geïntegreerde methode gemaakt.

ProQA bestaat uit vijf fasen[64]:

1.      Kwaliteitsdefinitie;

2.      Kwaliteitsborging;

3.      Kwaliteitsverbetering;

4.      Testen;

5.      Afronding.

Fig. 176 ProQA model Bron sysQA

 5.7.8.7 Andere kwaliteit- en ontwikkelmodellen

Er bestaan nog een aantal andere modellen die ondersteuning bieden aan het doen van kwaliteitszorg. We kunnen hierbij denken aan modellen zoals ISO 9000-3 en SPICE[65] (suite - Process Improvement and Process Capability dEtermination)[66]. Veel van deze modellen besteden vooral aandacht aan de procesmatige kant van softwareontwikkeling. Geen van deze modellen brengt software kwaliteit in verband met structuur en cultuur van de organisatie waar de software wordt ontwikkeld[67]. Het SQUARE ( software Product Quality Requirement and Evaluation) model geeft expliciete aandacht aan de elementaire (ontwerp)-metrieken en kwaliteitseisen. Het is voor de eindgebruiker dan ook verstandig om zich een beeld te vormen van de kwaliteitsbeheersing en ontwikkelingsmethode van de DCS-leverancier.

5.7.8.8 Kwaliteit en relatie met andere modellen

Fig. 177 Relatie ISO/IEC 15288

Er bestaan verschillende kwaliteitsnormen die allen een bepaald gebied afdekken. Zo is de ISO 9001/9000-3 vooral gefocust op de kwaliteit, De ISO/IEC 12.207 en 15.288 op de levenscyclus en de SPICE TE 15504 op het volwassenheidsniveau van de organisatie.

Fig. 178 Relatie tussen ISO/IEC 15288 en ISO/IEC 12207[68]

Figuur 178 laat zien hoe de software implementatie past in het GAMP 5 model samen met de projectmanagement aspecten.

5.7.8.9 Volwassenheidsmodel

Sommige leveranciers hebben een CMMI niveau, wat een indicatie is voor het volwassenheidsniveau van de organisatie. De implementatie bij een onderneming met een bepaald volwassenheidsmodel zoals CMMI hoeft niet per se te leiden tot snellere oplevering van projecten. De voorspelbaarheid van wanneer wat wordt opgeleverd, wordt echter wel vergroot. Daarnaast is het geen vereiste dat het project goedkoper wordt opgeleverd. De kwaliteit van wat wordt geleverd, is echter wel beter voorspelbaar. Een volwassenheidsmodel heeft de onderstaande totale lijst als doel[69]:

• Verbetering van planning en budgetvoorspellingen;
• Verbetering van cyclustijden;
• Verbetering van productiviteit;
• Verbetering van kwaliteit (minder fouten);
• Verbetering van eindgebruikertevredenheid;
• Verbetering van Return On Investment;
• Afname van kosten voor kwaliteit.

Tabel 91 CMMI niveaus[70]

Tabel 91 geeft een overzicht tussen het CMMI niveau en hoe de onderneming een project uitvoert. Voor een eindgebruiker is het van belang om te weten met welke kwaliteitsnorm de leverancier werkt en hoe hij zich hieraan houdt.

5.7.9 Project teamsamenstelling

Project HRM management heeft te maken met alle processen rond het organiseren en managen van het projectteam. Het projectteam is samengesteld met mensen die een bepaalde rol is toebedeeld en bepaalde verantwoordelijkheden hebben gekregen om het project succesvol af te ronden. Het is verstandig om projectleden zo vroeg mogelijk bij de besluitvorming en de planning van het project te betrekken om de kwaliteit en het commitment te vergroten. We kunnen dit onderverdelen in[71]:

·        HRM resources plannen:

o       Vaststellen en documenteren van projectrollen, verantwoordelijkheden, rapportagelijnen en ondersteunende functies.

·        Projectteam samenstellen:

o       De mensen vastleggen die nodig zijn om het project succesvol af te ronden.

·        Ontwikkelen van het projectteam:

o       Verbeteren van de competenties en interacties van de teamleden om de projectresultaten te verbeteren.

·        Managen van het projectteam:

o       Het bijhouden van de prestaties van de teamleden, het geven van feedback, het oplossen van problemen en het coördineren van veranderingen om project- prestaties te verbeteren.

5.7.9.1 Deeltaken en organisatorische bezetting

De DCS-project uitvoering is uit te splitsen in de volgende onderdelen die door één of meerdere ondernemingen kunnen worden uitgevoerd:

1. Hardware levering en basissysteem levering;
2. Implementatie van de functionele software;
3. Implementatie van de integratie software en systemen;
4. Electro- en instrumentatiediensten voor de inbedrijfstelling;
5. Service en ondersteunende diensten.

De eindgebruiker zal dan ook een keuze moeten maken of hij dit bij één partij als hoofdaannemer bijvoorbeeld een Main Automation Contractor onderbrengt of dit zelfs bij meerdere bedrijven laat uitvoeren. In de markt treden beide situaties op. Uiteindelijk draait het om een snelle implementatiefocus en de eindgebruiker dient een DCS-leverancier te kiezen die gebruikt maakt van ervaren engineers, consultants, projectmanagers en een bewezen methode die zorg draagt voor een snelle implementatie. ARC[72] stelt dat het bij implementatie toch vooral om mensen gaat en geeft er dan ook de voorkeur aan een softwareleverancier met een eigen implementatieteam dan aan één afzonderlijke softwareleverancier en implementatiepartner. De motivatie hierachter is:

• Dat de twee partijen over het algemeen niet in elkaars kennis- en ervaring delen;
• Dat een implementatiepartner minder kennis van de software heeft dan de producent van de software;
• De partners zijn vaak verantwoordelijk voor de eerste lijnondersteuning maar niet voor de tweede- of derde lijnondersteuning;
• De ondersteuning voor urgente vragen meer tijd kost;
• De softwareleverancier neemt vaak geen verantwoordelijkheid voor maatwerk-oplossingen die door hun partners zijn gemaakt.

O’Brien[73] (ARC) geeft aan dat er een trend is om minder automatiseringsdiensten van EPC firma’s af te nemen en meer van kleinere systeemintegrators. Daarnaast zijn eindgebruikers meer op zoek naar partijen die als centrale aanspreekpunt kunnen optreden voor de uitvoering van een DCS-project. Sommige leveranciers pakken deze verantwoording op en worden Main Automation Contractor (MAC) of Main Automation Vendor (MAV). Deze diensten worden dan door hun zelfs uitgevoerd dan wel uitbesteed aan systeemintegrators. Daarnaast geeft O’Brien aan dat er minder gekeken wordt naar de laagste prijs voor services maar meer naar de bevestiging van de relatie en de expertise van de serviceleveranciers zoals in figuur 179 is weer gegeven.

Fig. 179 ROI en prestatieregel Bron ARC

Jaarsma[74] noemt de onderstaande mogelijk samenwerkingsvormen tussen DCS-leverancier en installateur en/of opdrachtgever:

• DCS-leverancier als hoofdaannemer tegen vaste prijs (turnkey), met huisinstallateur of de opdrachtgever zelf als onderaannemer;
• DCS-leverancier als installatie toezichthouder tegen vaste prijs en installatie opdracht van opdrachtgever direct aan de huisinstallateur;
• DCS-leverancier als installatie adviseur op regiebasis.

Doordat de verschillende automatisering leveranciers steeds meer diensten aanbieden ontstaat de vraagstelling wie het beste het integratieproject kan uitvoeren tussen een DCS en een MES- of ERP-systemen. Doordat er verschillende systemen geïntegreerd worden zijn er natuurlijk ook verschillende partijen (leveranciers) die dit willen en kunnen uitvoeren, elk met hun eigen voor- en nadelen. De mogelijkheden zijn[75].

• ERP-leverancier met een top-down benadering;
• DCS-leveranciers down-top benadering;
• Systeemintegrators;
• Interne ontwikkeling door de eigen organisatie.

Het Frost en Sullivan ‘Fabrieksvloer naar directiekamer - implementatie strategie model’ (figuur 180) geeft een goed beeld tussen de complexiteit, projectomvang en het potentiële risico en welke partij dan een dergelijk project het beste zou kunnen uitvoeren.

Fig. 180 Fabrieksvloer naar directiekamer - implementatie strategie - model Frost en Sullivan[76]

Tabel 92 Voor- en nadelen uitvoerende partij voor implementatie integratietraject

5.7.9.2 Relatie eindgebruiker met DCS-leverancier

De relatie van een eindgebruiker met een DCS-leverancier is complex en varieert tussen een leverancier die in een concurrerende markt moet opereren tot een langdurige partner.

Vooral bij grotere projecten (10 miljoen) wordt er meer gewerkt met het interactieve model om zo de project leveringsomvang voor te bereiden[77]. Aurajo[78] geeft aan dat er tussen de leverancier en de eindgebruiker verschillende werkvormen bestaan zoals:

5.7.9.3 Stakeholders en projectmensen

De belangrijke stakeholders in een project zijn:

·        De projectstuurgroep – steering committee:

o       Team van managers die het project op hoofdlijnen bewaakt en indien nodig besluiten en acties nemen;

·        Projectsponsor:

o       De persoon of groep die de verantwoordelijk is voor het leveren van de financiële middelen als ook andere organisatorische middelen zoals mensen, machines et cetera;

·        Projectmanagement:

o       De persoon die verantwoordelijk is voor het project.

·        Project ondersteunende staf:

o       Medewerkers zoals archief, secretariaat, voortgang bewaking et cetera.

·        Project medewerkers:

o       De medewerkers die het eigenlijke project uitvoeren.

·        Eindgebruiker/Klant:

o       De persoon of organisatie die het opgeleverde systeem gaat gebruiken. Er zijn vaak meerdere personen c.q. niveaus binnen een organisatie zoals een operator, onderhoudstechnicus, engineer, administrator en management.

·        Beïnvloeders:

o       Dit zijn mensen die niet direct bij het project zijn betrokken maar wel op een positieve- of negatieve wijze het projectresultaat kunnen beïnvloeden.

Fig. 181 Relatie tussen stakeholders en het project

Onderstaande figuur 182 geeft aan welke verschillende vaardigheden noodzakelijk zijn voor een ‘DCS’ project. Het is dus ook belangrijk om te toetsen bij de leverancier of hij in staat is om al deze verschillende deelgebieden af te dekken en te bemannen. Sommige bedrijven vragen van potentiële projectteamleden CV op om zich op voorhand hierover een oordeel te kunnen vormen.

Fig. 182 Benodigde kennisgebieden van het projectteam[79]

Binnen het applicatiegebied is onderstaande verdeling te maken:

• Functionele afdelingen en ondersteunende disciplines zoals productie, magazijn, logistiek, personeel en organisatie;
• Technische elementen, zoals softwareontwikkeling of engineering, Electro en Instrumentatie en constructie engineering;
• Management specialisatie, zoals overheidsopdrachten en verandermanagement;
• Industriegroepen zoals: Olie en Gas, Batch, Papier en Karton, Chemie et cetera.

Iedere industriegroep heeft meestal een aantal geaccepteerde en vastgelegde standaarden en werkwijzen. ISO geeft de volgende definities van de begrippen standaard en wetten:

• Een standaard is een document die door consensus is voortgekomen en is geaccepteerd door een geaccepteerd orgaan die voor gemeenschappelijk en meervoudig gebruik, regels, richtlijnen en kenmerken voor activiteiten heeft vastgelegd met als doel om een optimaal resultaat te halen in een bepaald context;
• Een wet is een door de overheid opgelegde regel betreffende specifieke producten, processen, servicehandelingen inclusief de administratieve vastlegging van deze zaken.

Het is voor de eindgebruiker belangrijk dat er in het implementatieteam voldoende ervaring zit, zowel op het applicatiegebied als ook binnen de industrie branche. Daarnaast is er vaak externe ondersteuning aanwezig in de rol van een consultant. Jaarsma[80] stelt dat een projectteam zich moet focussen op functionaliteit in plaats van oplossingen.

5.7.9.4 Projectmanagement

De projectmanager is een belangrijke persoon in het project die naast inhoudelijke kennis vooral projectmanagement vaardigheden moet bezitten. Bij ERP-projecten is inadequaat projectmanagement zelfs de belangrijkste oorzaak voor het mislukken van dergelijke projecten[81]. Om dit laatste te toetsen is er een internationale standaard ontwikkeld voor projectmanagers. Afhankelijk van het ervaring- en kennisniveau kan een projectmanager hiervoor een examen afleggen. Voorbeelden van dit soort certificeringen bestaan er van PRINCE, PMI en IPMA. Hieronder staan de regels voor een International Projectmanagement Association IPMA (IPMA) certificering[82]:

·        IPMA-D, Gecertificeerd Projectmanagement Medewerker: De IPMA-D gecertificeerd medewerker kent alle projectmanagementelementen en –aspecten, weet hoe te opereren in projecten en kan de projectmanager ondersteunen bij zijn of haar werkzaamheden;

·        IPMA-C, Gecertificeerd Projectmanager: De IPMA-C gecertificeerd projectmanager is in staat projecten met een beperkte complexiteit zelfstandig te leiden en kan de projectmanager van een complex project ondersteunen bij alle projectmanagementelementen en -aspecten;

·        IPMA-B, Gecertificeerd Senior Projectmanager: De IPMA-B gecertificeerd projectmanager is in staat complexe projecten zelfstandig te leiden;

·        IPMA-A, Gecertificeerd Project Directeur: De IPMA-A gecertificeerd project- of programmamanager is in staat op strategisch niveau te opereren en alle projecten van een bedrijf, branche of programma te leiden.

5.7.9.4.1 Eisen aan projectmanager en -leider

Aan de projectmanager en -leider worden nogal wat eisen gesteld hierbij kan men denken aan:

1.      Leiderschapskwaliteiten (coachen, discipline (voorbeeld geven, verlangen van projectmedewerkers), diplomatie, stressbestendigheid, communicatieve vaardigheden en teambuilding);

2.      Managementkwaliteiten (doelen stellen, projecten plannen en sturen, kwaliteitsbeheer, verandermanagement, hoofd- en bijzaken van elkaar kan onderscheiden en de hoofdlijn van het project bewaken);

3.      Kennis van de business;

4.      Kennis van en ervaring met het implementeren van besturingssystemen in het algemeen en in het betreffende toepassingsgebied in het bijzonder;

5.      Geaccepteerd door alle belanghebbenden.

In de praktijk is gebleken dat een projectmanager uit de eigen organisatie het beste is. Het meest geschikt is een lijnmanager onder wiens verantwoordelijkheid het grootste deel van de processen vallen die ondersteund worden met het systeem[83]. Bij een DCS-systeem zou dit dus de productieleider of manager moeten zijn. Mocht deze persoon niet voldoende kennis hebben dan zou deze persoon zich kunnen laten bijstaan door projectleiders, assistenten of een externe projectconsultant.

5.7.9.5 Consultant

Bij grote projecten worden zowel aan de leverancierszijde als aan de eindgebruikerzijde consultants ingezet. Door de inzet van externe consultants met hun specifieke ervaring zal de implementatie vlotter verlopen en het implementatieteam beter worden begeleidt.

Er worden met deze consultants interviews gehouden en het is aan te bevelen om deze personen met naam en toenaam vast te leggen in het contract om te voorkomen dat ze gedurende het project vertrekken of er al helemaal niet aan beginnen en er minder ervaren consultants worden ingezet.

Fig. 183 Relatie consultant ten opzichte van het projectteam

 5.7.9.6 Senior management

Een leverancier die werkelijk het leveren van een goed product en dienst hoog in het vaandel heeft zal privé telefoon- en GSM nummers van het senior management aan de eindgebruiker ter beschikking stellen om in geval van ernstige problemen een probleem te kunnen escaleren.

5.7.9.7 Probleem van vertrekkende projectmedewerkers

Een van de problemen die bij een project kan ontstaan is dat projectmedewerkers lopende het project, het project verlaten. Dit risico wordt groter als de doorlooptijd van project langer wordt. Dit risico is bij een project van vijf jaar aanzienlijk groter dan bij een project van één jaar.

5.7.10 Project communicatiemanagement

Project communicatiemanagement is het taakgebied dat verantwoordelijk is voor de tijdige en passende generatie, verzamelen, verspreiden, opslaan, opzoeken en uiteindelijke opruiming en afvoer van projectinformatie. Dit deelgebied verzorgd de kritische relatie tussen mensen door informatie te verstrekken die noodzakelijk is voor een succesvolle communicatie.

Project communicatiemanagement omvat de onderstaande onderdelen[84]:

• Communicatieplanning:
  • Bepaal welke communicatie noodzakelijk is voor welke project stakeholder.
• Informatie verspreiding:
  • Maak noodzakelijke informatie tijdig beschikbaar voor de stakeholder.
• Prestatierapportage:
  • Verzamel en verspreidt de prestatierapportage, dit omvat de statusrapporten, voortgangsbeoordelingen en voorspellingen.
• Management van de stakeholders:
  • Manage de communicatie zodat de stakeholders tevreden zijn en los problemen op met de stakeholders.

Voor een opdrachtgever is het belangrijk om van te voren te bepalen welke vorm van communicatie met welke frequentie noodzakelijk is. Dit kan variëren van dagelijkse voortgangsrapportage tot een twee wekelijkse bijeenkomst of maandelijkse rapportage. Deze eisen kunnen tot aanzienlijk manuurbelasting leiden en dus ook tot aanzienlijke kosten puur voor het opstellen van de rapportage ten behoeve van de communicatie.

5.7.11 Project risicomanagement

Het uitvoeren van een DCS-project of het juist niet uitvoeren van een migratie- of vervangingsproject geeft bepaalde risico’s. De onderneming loopt continu risico´s en we kunnen bij een DCS de volgende onderverdeling maken.

1.      We doen geen vervanging- of migratieproject. De kans is dan aanwezig dat er onverwachte uitval van de installatie kan optreden door een gebrek aan onderdelen, falende onderdelen of ontbrekende services;

2.      Er vindt een vervanging of migratie plaats en er kunnen vele zaken fout gaan tijdens de implementatie van het project.

Hoe groot een risico is, is afhankelijk van de perceptie van diegene die het risico inschat (Murnighan  et al.[85]) en hoe groot het risico is dat de onderneming wil nemen op het gebied van toepassen van de nieuwste technologie. Het is dan ook goed om hier een formele beoordelingsmethode voor op te zetten. Risicomanagement gaat niet primair om het voldoen aan de regels maar om het voorkomen van risico’s. De regels kunnen opgesteld zijn door corporate governance codes, door vragen van onzeker geworden Raad van Bestuur leden, De Nederlandse code Tabaksblad die zegt ‘pas toe of leg uit’ en de Amerikaanse Sarbanex-Oxley Act die zegt ‘pas toe of ga naar de gevangenis[86]‘. Risicomanagement is dan ook een hulpmiddel om op een gestructureerde en expliciete manier risico’s in kaart te brengen, te evalueren en door er proactief mee om te gaan, ze beter te beheersen. Risicomanagement is gebaseerd op het maken van risicoanalyses waarbij de waarschijnlijkheid van enkele toekomstige gebeurtenissen die een potentiële bedreigingen voor het project zijn op haar impact worden geanalyseerd en in kaart worden gebracht. Daarna dienen er maatregelen te worden genomen om de risico’s te bewaken en maatregelen te nemen die de gevolgen beperken[87]. Ondernemingen die niet veranderen kan het overkomen dat zij niet in staat zal zijn om de ondernemingsdoelstellingen te behalen. Zij kunnen markt verliezen aan concurrenten en daarmee hun onderneming plaatsen in een toekomstig risico[88]. Ieder besluit moet een balans zijn tussen het risico om iets niet te doen tegen het risico om een nieuwe technologie in te zetten. ‘Zonder risico is er geen vooruitgang[89]’ is een bekende kreet anderzijds kunnen we stellen dat nieuwe technologie altijd een bepaald risico met zich meebrengt. Vanuit risicomanagement kan men echter stellen dat er ‘zonder risicobeheersing geen winst is (Gijs[90]). Kieboom[91] geeft aan dat projecten altijd een risico blijven, daarom moet risicomanagement een belangrijke plaats hebben in de organisatie. Raz e.a.[92] stellen dat risicomanagement vaak niet wordt toegepast in projecten. En als het wordt toegepast, dan is het vaak alleen risico identificatie wat wordt uitgevoerd; vervolgstappen blijven meestal achterwege. Wat we ons misschien minder realiseren is dat het tijdig opleveren van een project samenhangt met de mate waarin we in staat zijn en bereid zijn om risico’s zichtbaar en correct te registreren, de risicolijst (meestal een Microsoft Excel sheet) te onderhouden en risico’s toe te wijzen aan een eigenaar[93]. Verder geldt dat de basis voor problematische projecten vaak al wordt gelegd in de fase van de vaststelling van de business case^[94]; mensen zijn structureel te optimistisch bij het maken van schattingen en ze verdraaien bewust de werkelijkheid om hun project geaccepteerd te krijgen. Het huidige risicomanagement gaat uit van single-cause, single-effect, maar in de praktijk blijken risico’s en gevolgen elkaar te beïnvloeden; dat kan zijn versterken of verzwakken. Dit multi-cause, multi-effect model kan tot gevolg hebben dat het bewust managen van een risico leidt tot een verslechtering van de totale situatie. Niets doen is in een zodanig geval beter dan ingrijpen. Het mag duidelijk zijn dat het lastig is om in de praktijk te onderkennen wanneer een situatie zodanig is dat je beter niet kunt ingrijpen. Laat staan dat het mogelijk nog lastiger is om als manager te besluiten om in een zodanig geval niets te doen. De Bakker[95] geeft aan dat er weinig bekend is over het rendement van risicomanagement en de condities waaronder risicomanagement effectief is, welke mechanismen er aan het werk zijn die er voor zorgen dat risicomanagement werkzaam is binnen een project. Komt het omdat risicomanagement er voor zorgt dat we een beter inzicht krijgen in de planning van het project, of komt het misschien omdat projectmedewerkers zich meer verantwoordelijk gaan voelen en gedragen als ze weten wat de risico’s zijn en wat zij er aan kunnen doen? Rasmussen[96] geeft vier fasen aan hoe een organisatie met risico’s om kan gaan. Dat varieert van het ignoreren van risico’s (ijsberg idee) tot een continu programma van toekennen van Kritische Risico-Indicatoren (KRI) door experts en tot het besluiten die te meten door middel van Kritische Prestatie Indicatoren (KPI’s). Daarnaast geeft Flyvbjerg e.a.[97] vier instrumenten aan om megaprojecten beter te beheersen. Dit zijn:

1.      Transparantie;

2.      Prestatie-indicatoren;

3.      Heldere regelgeving;

4.      Deelname van risico kapitaal.

Fig. 184 De risico-ijsberg van Rasmussen

5.7.11.1 Redenen waarom projecten mislukken

In deze paragraaf worden een aantal onderzoeken beschreven zowel binnen de ICT-toepassingen in Nederland zowel in de zakelijke en overheidsdienst als in Australië.

Door kennis te nemen van deze fouten is het mogelijk om hier in het project rekening mee te houden en dit samen met de DCS-leverancier te borgen.

Voor de analyse is gebruik gemaakt van de volgende bronnen:

·        ERP in bedrijf 2001;

·        Management of risks in ICT-projecten Australië 2004;

·        ICT-Barometer van Ernst & Young 2007;

·        ICT-Barometer van Ernst & Young 2008;

·        Computable Service Guide 2008;

·        Succesvol afronden ICT-projecten Financieel Management 2007;

·        ICT-projecten bij de overheid – Algemene Rekenkamer 2007-2008;

·        NPS NIPO onderzoek 2008.

Bij het implementeren van ICT-systemen gaat het regelmatig fout. Een onderzoek naar faalfactoren bij ICT- en ERP-systemen liet het onderstaande beeld zien (zie tabel 93). Hoewel men dit patroon niet één op één kan en mag overnemen voor een DCS-systeem kunnen daar dezelfde soort problemen optreden. Specifieke data van DCS-installaties zijn niet beschikbaar maar er is geen reden om aan te nemen dat daar grote verschillen in zullen zitten.

Tabel 93 Faal- en succesfactoren bij ICT- en ERP-implementaties

Van Helder[101] geeft aan dat een aantal factoren van belang zijn voor een succesvol ICT-project. Essentieel is een duidelijke focus op het beoogde resultaat. Een ICT-project moet gericht zijn op de business case en hiermee op de beoogde bijdrage aan de ondernemingsdoelstellingen . Een juiste focus vergt een goede voorbereiding en aandacht gedurende alle projectfasen. Ondersteuning van het hogere management, het efficiënt regelen van noodzakelijke middelen, het stellen van prioriteiten en het omgaan met spanningsvelden in de organisatie is voor de projectmanager vaak alleen mogelijk als de top van de organisatie achter het ICT-project staat. Daarnaast geeft Van Helder aan dat nog steeds 60% van de ICT-projecten niet binnen tijd, binnen budget of helemaal niet worden afgerond. De volgende oorzaken worden hierbij genoemd:

• Geen focus;

• Onvoldoende commitment van het hoger management;
• Onvoldoende draagvlak;
• Onervaren projectmanager;
• Onduidelijke projectdoelstellingen;
• Onvoldoende kwaliteitsbewaking;
• Onduidelijke randvoorwaarden;
• Ongestructureerde projectinrichting;
• Geen resultaat gericht projectmanagement;
• Overkill aan projectmanagement en project controle;
• Veel te zwaar kwaliteitsbewaking programma[102].

 Daarnaast geeft Van Helden aan dat één van de aspecten die nogal onderbelicht wordt, is het belang van het uitvoeren van een goed voortraject tijdens de eventuele selectiefasen voor bijvoorbeeld een nieuw systeem. Vooral het procesgericht denken in plaats van functioneel gericht, het tijdig plannen van meerdere referentiebezoeken en het afsluiten van een goed contract zijn aspecten die vaak niet of nauwelijks uit de verf komen. Een goed uitgevoerd voortraject, eventueel met consultants, verdient zichzelf echter dubbel en dwars weer terug tijdens de uitvoering van het project. Van Ruben en Calleweg[103] geven aan dat bij ICT-projecten tussen 2001 en 2008 de helft van alle projecten slecht scoren waarbij de grote projecten de meeste kans hebben om te falen. Projectmanagement wordt als primaire reden aangehaald van het falen maar ook een viertal eindgebruikerfactoren te weten,

·        Problemen met doelbeschrijving;

·        De ondersteuning door het management;

·        Veranderende vereisten;

·        Problemen in de communicatie.

Een kleine enquête van Computable[104] in juli 2008 gaf de volgende procentuele verdeling:

·        Eindgebruiker weet niet wat hij wil (54%);

·        Onvoldoende management ondersteuning (25%);

·        Dienstverlener is verantwoordelijk voor het slagen (16%);

·        Anders (4%).

Het onderzoek van TNS NIPO in opdracht van Computable op de vraag ‘wat is de reden van het mislukken van ICT-projecten’ gaf onderstaande redenen[105]:

• 19% ‘Omdat de opdrachtgever niet duidelijk genoeg was’;
• 15% ‘Dat de dienstverlener te weinig communiceert met de opdrachtgever’;
• 12% ‘Omdat er te weinig rekening is gehouden met eindgebruikers’;
• ‘De opdrachtgever saboteert vaak haar eigen project door te weinig ruimte te geven aan de dienstverlener;
• Het contract weerspiegelt niet de business behoefte;
• Onzorgvuldige analyse aan het begin van het traject;
• Trojaanse paarden in het contract;
• Projectscope wordt niet voldoende vastgezet en bewaakt.

Buytendijk[106] stelt dat veel projecten in 2009 worden stopgezet in het verband met de kredietcrisis en dat dit helemaal niet erg is want ‘Vele daarvan zouden toch mislukken’.

5.7.11.1.1 ICT-projecten binnen de overheid

Het lukt de Nederlandse overheid maar niet om een aantal opgezette ICT-projecten tot een goed einde te brengen. De Algemene Rekenkamer doet verwoedde pogingen de problemen boven tafel te krijgen en oplossingen te bieden om verdere escalatie van deze problemen het hoofd te bieden. Volgens de rapportage van de Algemene Rekenkamer[107] besteedt de Nederlandse overheid jaarlijks vier tot vijf miljard euro aan geheel of gedeeltelijk mislukte ICT-projecten. In de analyse van de Rekenkamer komen de volgende oorzaken aan bod die leiden tot het mislukkingen van de ICT-projecten:

1.      De beslissers in het politieke veld geloven in ICT als ware het een wondermiddel voor het oplossen van allerlei beleidvraagstukken maar hebben vaak onvoldoende zicht op de mogelijkheden van ICT;

2.      Deadlines worden vaak niet vastgesteld op basis van een onderbouwde en realistische planning, maar op basis van politieke overwegingen;

3.      (Ook) bij ICT-projecten moet er een balans zijn tussen de ambities, beschikbare mensen, geld en tijd;

4.      Politiek is het vaak onwenselijk om (randvoorwaarden van) een project te heroverwegen. Signalen over problemen, risico’s of wijzigingen worden hierdoor onvoldoende opgepakt, dit geldt ook voor grip op ICT-projecten;

5.      Lopende ICT-projecten worden niet snel stopgezet als er geen zakelijke rechtvaardiging meer is. Genomen beslissingen zijn politiek gezien vaak moeilijk terug te draaien. Met andere woorden, belangrijke wijzigingen in eisen of randvoorwaarden zijn lang niet altijd aanleiding voor herbezinning op de uitgangspunten van het project;

6.      Bestuurders hebben vaak onvoldoende zicht op de mogelijkheden, maar vooral ook de onmogelijkheden van ICT en vaak zijn verschillende, autonome, organisaties bij ICT-projecten betrokken waardoor centrale regie of doorzettingsmacht ontbreekt;

7.      Projecten gaan vaak te snel van start zonder goede onderbouwing. Er wordt niet de tijd genomen om te onderzoeken of het project realistisch is;

8.      Vaak worden belangrijke beslissingen in een project genomen op basis van onvoldoende of onvolledige onderbouwing;

9.      Projectdoelen zijn vaak niet scherp gedefinieerd. Daardoor vormen externe ICT-leveranciers zich een incompleet en mogelijk zelfs onjuist beeld van wat de opdrachtgever verwacht;

10.  ICT-systemen staan vaak niet op zichzelf maar moeten worden aangesloten op andere, bestaande, systemen. Hiermee wordt vaak geen rekening gehouden;

11.  De ontwikkelingen op het gebied van ICT gaan razend snel.

Wat de analyse van de Rekenkamer siert is dat de hand in eigen - publieke - boezem wordt gestoken: Er zijn weinig onvertogen woorden over het onvermogen of de onkunde van de (vaak externe) ICT-leveranciers. De analyse is samen te vatten als: Het ontbreekt de overheid aan professioneel opdrachtgeverschap in dezen[108]. Oorzaak nummer negen (projectdoelen zijn vaak niet scherp gedefinieerd) springt er overigens met kop en schouders boven uit: Dit is mogelijk de belangrijkste oorzaak voor mislukkingen. Geregeld worden, onder het mom van ‘deuren open houden voor voortschrijdend inzicht’, doelen en resultaten onvoldoende helder geformuleerd. Wanneer een opdrachtgever echter niet precies zegt wat hij wil, moet hij ook niet verbaasd opkijken als hij niet krijgt wat hij wil.

Bij een onderzoek onder ICT-professionals in leidende bedrijven in West Australië zijn 27 ICT-risico’s op waarschijnlijkheid en gevolgen onderzocht om de meest belangrijke risico’s te identificeren. De top vijf risico’s in volgorde van belangrijkheid zijn:

1.      Personeelstekorten;

2.      Onrealistische projectplanning en budget;

3.      Onrealistische verwachtingen;

4.      Onvolledige requirements;

5.      Gemiste kans (window of opportunity) door te late levering van de software.

Salm et al.[109] geven aan dat dit vooral projectmanagement taken zijn en niet technische processen. Als belangrijkste opmerkingen is de conclusie: ‘Managing stakeholders expectations is a specific risk treatment that helps to manage several key ICT risks’.

Opvallend is dat hier expliciet personeelstekorten wordt genoemd wat ook in Europa een onderlinge interne oorzaak is maar daar niet expliciet wordt uitgesproken. Dit valt af te leiden uit het feit dat plants vaak niet voldoende in staat zijn op de requirements- documenten controle en validatie uit te kunnen voeren door gebrek aan tijd veroorzaakt door andere interne dagelijkse werkzaamheden.

5.7.11.1.2 Samenvatting meest voorkomende problemen

De belangrijkste problemen die uit voorgaande analyses naar voren komen zijn:

·        Onduidelijke doelstellingen, het waarom van het project is niet te beantwoorden;

·        Onduidelijke scope en onvolledige requirements;

·        Onvoldoende topmanagement commitment;

·        Doorlooptijd is te lang;

·        Niet voldoende inzet van capabele mensen;

·        Gebrekkige communicatie;

·        Tijd en budget problemen, dit zijn voor een deel afgeleide problemen);

De gevolgen hiervan worden in de paragraaf 5.7.11.2 beschreven.

De volgende aanbevelingen ter verbetering zijn te maken:

·        Zorg voor intern commitment en support vanuit het topmanagement;

·        We kunnen er vanuit gaan dat de leverancier aanzienlijk meer weet van het systeem en beter kan specificeren dan de eindgebruiker;

·        Zorg voor goede communicatie binnen het projectteam en met de stakeholders;

·        De eindgebruiker zou aanzienlijk meer ondersteuning moeten krijgen om goede functionele specificaties op te stellen, eventueel samen met een externe consultant die direct in opdracht voor de eindgebruiker werkt;

·        De eindgebruiker moet aanzienlijk meer tijd besteden aan het beoordelen van de functionele specificaties en de omzetting naar de applicatie;

·        De eindgebruiker moet de ‘echte’ eindgebruikers op een aanzienlijk eerder moment in het selectie- en implementatieproces betrekken;

·        Deze personen ook deels betrekken bij de functionele testen van de installatie voordat die in bedrijf wordt gesteld.

5.7.11.2 Gevolgen van mislukkende projecten

 Bij de uitvoering van migratie, uitbreiding- en vervangingsprojecten kunnen we de onderstaande risico’s onderscheiden:

·        Risico dat de technologie niet 100% aansluit bij de bestaande applicaties;

·        Dat de vervanging en daarmee de downtime van de plant (het niet kunnen produceren) langer duurt dan oorspronkelijk verwacht;

·        De bestaande applicaties niet 100% zijn vertaald naar de nieuwe situatie. Dit wordt nog mede verstrekt door het feit dat niet elk bedrijf zijn documentatie 100% correct voor elkaar heeft;

·        Er bepaalde eindgebruiker specifieke aanpassingen gemaakt zijn, welke niet met een automatische routine zijn te migreren, dan wel niet goed zijn gedocumenteerd.

Uit het CHAOS 2005 onderzoek kwamen onderstaande resultaten van falende ICT-projecten.

Fig. 185 Percentage falende ICT-projecten[110]

Fig. 186 1994-2004 Gemiddelde percentage van langere tijdsbesteding aan project[111]

Uit bovenstaande figuur 186 blijkt dan ook dat de kans dat een project op tijd, binnen de afgesproken begroting en met het verwachte resultaat wordt afgesloten aanzienlijk kleiner is dan het feit dat het project uitloopt, duurder wordt en niet het gewenste resultaten oplevert. Het CHAOS onderzoek in 2006[112] geeft aan dat de situatie iets beter wordt (35% van de projecten succesvol), maar dat er nog een lange weg is te gaan om tot 100% succesvolle projecten te krijgen. Ook financieel geeft het CHAOS rapport aan dat de werkelijke kosten van een project in 2004 gemiddeld 56% hoger liggen dan in de oorspronkelijke begroting. De ICT-barometer van Ernst & Young[113] geeft aan dat systeemmigraties in 78% van de gevallen goed gaan. Dat is ook het hoogste percentage van alle ICT-projecten. Schaminee[114] zegt dat ook anno 2009 DCS-projecten zeker nog een kostenoverschrijding hebben tussen de 50% en 100% van de oorspronkelijke projectprijs.

 

5.7.11.3 Fasen en stappen bij projectrisicomanagement

Projectrisicomanagement omvat alle processen die te maken hebben met risicomanagement planning, identificatie, analyse, opvolging, bewaking en beheersing binnen het project.

De doelstelling van risicomanagement is het verhogen van de waarschijnlijkheid dat er een positief event zal op treden en het verlagen van de waarschijnlijkheid dat er een negatief event zal optreden in het project[115]. Projectrisicomanagement omvat de volgende procedures en stappen[116] [117] [118]:

1.      Risicomanagement planning: (zie paragraaf 5.7.11.3.1 voor details)

a.       Bepaal hoe de benadering, het plan en de uitvoering van risicomanagement activiteiten binnen het project worden uitgevoerd;

b.      Bepaal de karakteristieken en doelstellingen van het te beoordelen systeem.

2.      Risico identificatie: (zie paragraaf 4.7.11.4 voor details)

a.       Identificatie van de risico’s op de verschillende risicogebieden;

b.      Analyse van de huidige beheersmaatregelen, te veel of juist te weinig maatregelen;

c.       Bepalen van de kwetsbaarheid als het risico optreedt;

d.      Waarschijnlijk bepalen dat het risico optreedt;

a.       Gevolgen analyseren als het risico optreedt;

b.      Bepalen welke risico’s een effect op het project kunnen hebben en documenteer hun eigenschappen.

3.      Kwalitatieve risicoanalyse: (zie paragraaf 4.7.11.7.3.2 voor details)

a.       De risico’s samenvoegen vanuit de verschillende bronnen en de verschillen vergelijken;

b.      Bepaal prioriteiten van de risico’s van een gebeurtenis in een volgorde dat er vervolgacties noodzakelijk zijn afhankelijk van de kans dat de gebeurtenis optreedt en de gevolgen van die gebeurtenis.

4.      Kwantitatieve risicoanalyse: (zie paragraaf 4.7.11.7.3.3 voor details)

a.       Bepaal of dit risico op andere plaatsen kan voorkomen door de omvang van de gegevens te aggregeren en correleren;

b.      Numerieke analyse van de effecten op de projectdoelstellingen van de geïdentificeerde risico’s;

5.      Risico response planning: Ontwikkel de opties en actieplannen om de kansen te vergroten en de negatieve effecten voor het project te verminderen volgens onderstaand schema:

a.       Voorkomen: Door procedures te wijzigen of om bepaalde zaken niet meer te doen;

b.      Verminderen: Het risico afdekken door een voorziening of verzekering;

c.       Overdragen: Taken door een andere partij laten uitvoeren en ook het risico laten nemen;

d.      Accepteren: Bovenstaande drie opties kunnen niet toegepast worden, dus zal de organisatie er mee moeten leven;

e.       Het benoemen van een verantwoordelijke voor dit risicopunt.

Fig. 187 Risicovermindering - maatregelen in vaste volgorde - Bron Stork[119]

(zie paragraaf 4.7.11.3.5 voor details)

6.      Risicobewaking en beheersing:

a.       Risico’s opsporen, volgen en signaleren als er een drempelwaarde wordt overschreden;

b.      Volg de geïdentificeerde risico’s, bewaak restrisico’s, identificeer nieuwe risico’s, voer risico beperkende maatregelen uit en evalueer de effectiviteit van de maatregelen gedurende de levensduur van het project;

c.       Meten, controleren en rapporteren met als doel om te kijken of de getroffen maatregelen ook effect hebben;

d.      Resultaten integreren in de besluitvormingsprocessen.

Fig. 188 Riskman Methode, Ned Robins 2000[120] [121]

De Riskman methode is de Europese basis voor risicomanagement.

5.7.11.3.1 Risicomanagement planning

Bij de risicoplanning wordt er bepaald hoe er omgegaan wordt met en de benadering van de risico’s. De risico’s zijn onder te verdelen op basis van complexiteit.

5.7.11.3.1.1 Simpele, operationele beslissingen over risico’s

Bij risicoproblemen met een geringe complexiteit en waar weinig onzekerheid in het geding zijn (vooral op het niveau van statistiek), voldoen de klassieke methoden van kwantitatieve risicoanalyse en -beheersing (management) uitstekend. Risico’s kunnen op klassieke wijze worden gekwantificeerd in termen van kans maal effect en zoveel mogelijk worden beoordeeld aan de hand van een standaard beoordelingskader. Op basis van kosteneffectiviteitanalyse kan worden vastgesteld of de risico-euro goed besteed is^[122]. Zijn complexiteit en onzekerheid gering of matig, maar zijn de kosten hoog en/of de belangen groot, dan lijkt ook een in eerste instantie op risicobepaling gebaseerde benadering het meest voor de hand te liggen. In de praktijk blijkt in deze gevallen de generieke aanpak echter te knellen. Het knelpunt is dan voornamelijk de ongunstige verhouding tussen kosten en opbrengsten in termen van risico vermindering (veiligheidswinst). Als het garanderen van een bepaalde, per definitie arbitrair beschermingsniveau een aanzienlijk bedrag zal gaan kosten, ligt het voor de hand om op zoek te gaan naar minder kostbare vormen van risico vermindering. De kosteneffectiviteit neemt in de praktijk snel toe als meer specifieke maatregelen worden genomen, toegespitst op die situaties waar de risico’s het hoogst zijn. Ook differentiëren tussen bestaande en nieuwe situaties verhoogt in veel gevallen de doelmatigheid van risico vermindering. Het is goed om in deze gevallen openlijk te discussiëren over de keuze tussen doelmatigheid en billijkheid.

5.7.11.3.1.2 Omstreden, tactische beslissingen over risico’s

Ook wanneer betrokken groepen zich door andere risicoaspecten dan waarschijnlijkheid en omvang van schade aangesproken voelen, verdient een afwijkende aanpak ten opzichte van de generieke aanpak de voorkeur. Door overleg te voeren met belanghebbende groepen, gericht op consensus over probleemdefinitie en procedure, over doelmatigheid, evenwichtigheid en billijkheid van maatregelen, kan de acceptatie van de uitkomst worden vergroot en kunnen relatief dure beheersmaatregelen mogelijk achterwege blijven[123].

5.7.11.3.1.3 Onzekerheid en complexiteit

In het klassieke model van omgaan met risico’s brengen engineers en/of wetenschappers kwantitatief en waardevrij de kansen op schade en verlies in kaart, waarna beleidsmakers in overleg met belanghebbenden vaststellen tot waar risico’s nog te aanvaarden zijn en waar en in welke risico’s teruggebracht moeten worden. Inmiddels is steeds duidelijker geworden dat onze kennis van de werkelijkheid en dus ook de manier waarop risico’s ontstaan, flinke beperkingen kent. Elke risicoanalyse is daardoor behept met onzekerheid. Soms gaat het slechts om inexactheid: We hebben maar beperkt metingen kunnen doen en weten niet precies de waarde of de variatie van een parameter in onze rekensom. Soms gaat het om onbetrouwbaarheid: We hebben de schaarse data wel gemodelleerd, maar zijn niet zeker van de oorzakelijkheid van relaties en dus of onze sommen werkelijk in alle gevallen valide (‘juist’) zijn. Omdat we het niet precies weten, zijn we maar voorzichtig. Kortom er zitten waarden verborgen in de berekeningen. Soms zijn we onwetend; we hebben geen flauw idee hoe het systeem in elkaar zit, waar het begint of eindigt; of we weten het slechts op een paar specifieke onderdelen. We tasten in het duister of het nu gaat om waarschijnlijkheden, om kans op of mate van blootstelling, of om aard of ernst van gevolgen. We weten eigenlijk niet eens wat we niet weten. Deze indeling naar mate van onzekerheid wordt aangeduid als technische, methodologische en epistemologische onzekerheid[124].

Als oplossing voor het omgaan met complexiteit wordt vaak gebruik gemaakt van modellen.

Fig. 189 Omgaan met verschillende type van onzekerheden vrij naar Stirling 2001[125]

Er zijn overigens goede methodieken om een deel van deze onzekerheden en waardegeladenheid inzichtelijk te maken (zie figuur 189). Onzekerheden op het niveau van de statistiek (variatie en meetfouten) kunnen met behulp van probabilistische controle technieken (zoals Monte Carlo analyse) inzichtelijk worden gemaakt. Door het uitvoeren van risico en simulaties analyses kan de eindgebruiker zich een beeld vormen van de verschillende scenario’s[126]. De uitkomst wordt dan niet als een getal gepresenteerd, maar als verdeling, of als minimale en maximale waarde (zie voorbeeld in paragraaf 5.7.7 ‘Projectkosten en budget management’). Hebben we te maken met onzekerheden op het niveau van modellen of constructen (onbetrouwbaarheid), kan gevoeligheids- of scenarioanalyse uitkomst bieden. We berekenen dan uitkomsten onder verschillende aannamen (of scenario’s) om toch gevoel te krijgen voor waarschijnlijkheid, aard en omvang van het risico. Zitten de onzekerheden meer in de vaagheid van de probleemdefinitie, onbepaaldheid of dubbelzinnigheid (ambiguïteit), dan kunnen redeneringen op basis van analogieën en formele logica, what-if scenario’s, ‘halfkwantitatieve’ denkkaders om met vaagheid en inexactheid om te gaan (‘fuzzy logic’) en reflectieve discussie met betrokken partijen uitkomst bieden. In geval van onwetendheid past ook de wetenschap enig deemoed. Risicobeheersing kan in deze gevallen niet anders dan ‘voorzorg’ zijn; het risico kan immers nauwelijks kwalitatief worden geduid, laat staan kwantitatief.

5.7.11.4 Risico identificatie op verschillende risicogebieden

De risico’s bij het project zijn in twee hoofdgroepen te onderscheiden:

1.      Strategische risico’s:

a.       Als de onderneming de nieuwe technologie niet adopteert, wat zal haar positie in de toekomst zijn[127]?

b.      Financiële risico’s;

                                                               i.      Kosten/Baten (kosten zitten wel in het project maar de baten vaak niet) dus maken deel uit van het project charter;

                                                             ii.      Return on Investment[128].

2.      Projectrisico’s:

a.       Bij het uitvoeren van een project kunnen er op een aantal gebieden risico’s optreden die invloed hebben op het uiteindelijke resultaat, dit zijn onder te verdelen in de volgende groepen:

                                                               i.      Technische en technologische;

                                                             ii.      Externe;

                                                            iii.      Organisatie;

                                                           iv.      Projectmanagement.

5.7.11.4.1 Strategische risico’s

Bij de evaluatie van de negatieve gevolgen (= risico’s) van een gemiste kans of nodeloze blunder zijn zes factoren van belang. Met het acroniem SMILES zijn de zes factoren aan te duiden, deze factoren kijken vooral naar de actor als persoon.

De risicofactoren volgens SMILES[129] zijn:

·        Sociaal risico:

o       Wat zullen anderen over mij denken. Schaadt of baat het mijn reputatie?

·        Monetair risico:

o       Hoe beïnvloedend de uitkomst mijn financiële en materiële situatie?

·        Informatie risico:

o       Hoeveel zal ik leren uit die ervaring?

·        Levensbedreigend gezondheidsrisico:

o       Bedreigt de uitkomst mijn gezondheid of mijn leven?

·        Ervaringsrisico:

o       Welke mate zal ik de ervaring haten of ervan genieten?

·        Schaderisico:

o       Creëert een verkeerde interventie het risico van onherstelbare schade, een catastrofaal en onherroepelijk verlies?

5.7.11.4.2 Projectrisico’s

De onderstaande figuur 190 is een voorbeeld van een Risk Breakdown Structure (RBS)[130].

Een aantal onderdelen uit deze figuur zoals de markt zijn deels project gerelateerd (niet op tijd aan vereisten voldoen) als ook strategisch zoals de lange termijn gevolgen die onder de strategische risico’s vallen.

Fig. 190 voorbeeld van een Risk Breakdown Structure (RBS) van een project

De bovenstaande figuur laat niet direct de ‘operationele risico’s’ zien, maar die zijn te vangen onder twee subonderdelen ‘de technische prestaties en betrouwbaarheid’ als onder extern ‘het niet kunnen voldoen aan afspraken’ en onder de organisatorisch prioriteiten.

De projectmanagement aspecten zijn beschreven in paragraaf 5.7.7. ‘Projectkosten en budget management’ en paragraaf 5.7.10 ‘Project communicatiemanagement’.

5.7.11.4.3 Projectrisico’s technisch

5.7.11.4.4 Requirements

Leffingwell[131] geeft aan dat tussen 41% en 56% van alle fouten terug te leiden zijn naar fouten die gemaakt zijn tijdens de specificatiefase. Het onderzoek van IAG Consulting naar het ‘succes’ van ICT-projecten blijkt dat veel projecten mislukken wegens het ondeskundig vaststellen van de projecteisen. Ongeveer 55% van de bedrijven geeft aan dat het project uit de hand is gelopen als het aan ten minstens twee van de onderstaande beweringen voldoet[132]:

• Het langer duurde dan 180% van de tijd die er voor was begroot;
• Er was een budget overschrijding van meer dan 160%;
• Het project minder dan 70% van de afgesproken functionaliteit levert.

Een goede analyse van de requirements kan de schade van een project minimaliseren. De schade was het grootst wanneer niet ICT-analisten het wat betreft de requirements voor het zeggen hadden. De kosten waren het dubbele van de oorspronkelijke budgetten en het duurde 245% van de gecalculeerde tijd. Met een ICT’er aan het roer waren de resultaten slecht een beetje beter resp. 163% (budget) en 172% (tijd). Bij een gemengd team, samengesteld vanuit de business en een ICT’er waren de resultaten het beste 143% (budget) en 159% (tijd). De overgrote meerderheid ziet het proces van het vaststellen van de requirements als inefficiënt. Bedrijven zouden een ‘center of excellence’ voor het verzamelen van de bedrijfsrequirements moeten instellen, dat bemand wordt door zowel ICT-ers als medewerkers uit de bedrijfsprocessen. Dit wordt ook bevestigd door De Vries[133] (directeur van SAP Nederland) dat het mislukken van SAP implementaties vaak te wijten zijn aan de eindgebruiker zelf, zij noemt de volgende argumenten:

1.      Bedrijven realiseren zich vaak onvoldoende wat het effect van de implementatie op hun bedrijfsvoering is;

2.      Iedere invoering van een ERP-systeem is ingrijpend voor de gebruikers;

3.      Onvoldoende aandacht en besef voor de invoering tijdens de testfase.

Deze oorzaak wordt door één eindgebruiker (Hans Breukhoven van Free Record shop) in hetzelfde artikel bevestigd en door een andere eindgebruiker de projectverantwoordelijke bij de Provincie Noord Holland volledig bij de leverancier gelegd.

Het probleem is dat sommige de functionele requirements als een document zien en anderen het meer ervaren als een proces waarbij wijzigingen kunnen optreden door nieuwere inzichten, onder het mom van ‘deuren open houden voor voortschrijdend inzicht’[134]. Terwijl Brooks[135] aangeeft dat een ‘zero change policy’ misschien vanuit management oogpunt er goed uitziet maar niet altijd leidt tot het beste resultaat. Een bepaalde mate van wijzigingen is dus gezond.

5.7.11.4.4.1 Requirements groei– Scope aanpassingen en groeiende eisen

‘Scope creep’ aanpassingen is de tendens om na de engineering fase tijdens de uitvoeringsfase nieuwe aanpassingen te doen die in het oorspronkelijke plan niet waren meegenomen en gepland en leidt tot risico ten aanzien van de kwaliteit of planning.

Deze requirements groei kan veroorzaakt worden door[136]:

• De eindgebruiker door een groeiende wensenlijst;
• Door de ontwikkelaars zelfs die kansen zien om het product te verbeteren.

Jones[137] stelt dat requirement groei zelfs een van de meest voorkomende risico’s is bij een software project. Verhoef en Jones geven aan dat er gemiddeld 1,1%[138] extra eisen iedere maand bij komen voor contract of uitbestede contractsoftware bij een proces waar een strak en formeel wijzigingsbeheer is. Terwijl dit voor systeemsoftware op 2% ligt met en maximum van 4,6%. In andere gevallen kan het de toename per maand aanzienlijk hoger zijn.

Verhoef[139] geeft aan dat requirement groei de onderstaande gevolgen veroorzaakt:

• Gevolgen voor de ontwikkelfase van het project;
• Toename aantal werkuren;
• Oplopende kosten van de ontwikkeling;
• Hogere operationele kosten;
• De levenscyclus;
• Verhoogd risico op falen;
• Risico op aanzienlijke tijdsoverschrijdingen van het project;
• Kan andere risico’s veroorzaken.

Fig. 191 Kennis versus risico model Bron ABB

Ryan e.a. [140] geven aan dat er een relatie bestaat tussen kennis en risico zoals hierboven is weergegeven in figuur 191, Het is dus belangrijk voordat er veel requirements op tafel worden gelegd dan wel worden uitgevoerd, het team voldoende kennis in huis heeft (eventueel met externe hulp) om het requirement pakket op te stellen.

5.7.11.5 Technologie risico’s

Technologische risico’s. (zijn bij de paragraaf 5.6.3 ‘Type eindgebruiker ten aanzien van technologie inzet’ beschreven). Met goede informatie is het voor het management mogelijk om te begrijpen wat er nodig is om de nieuwe technologie te laten werken, de volgende vragen helpen hierbij:

• Welk onderzoek ondersteunt de nieuwe technologie en verifieert de benoemde voordelen van die technologie bij invoering?
• Hebben andere ondernemingen deze technologie succesvol ingezet?
• Wat is er nodig om deze nieuwe technologie te ondersteunen en te onderhouden?
• Welke aard van ondersteuning is beschikbaar om te leren omgaan met deze nieuwe werkwijze of technologie?

Om te bepalen of een technologie in de missie en visie van de onderneming past, is het belangrijk om te weten waar de onderneming over vijf of tien jaar wil staan, belangrijke vragen hierbij zijn:

·        Ondersteunt de nieuwe technologie deze visie?

·        Helpt deze nieuwe technologie of werkwijze de onderneming in de gewenste strategische richting?

Het toepassen van een nieuw product of een nieuw proces vereist over het algemeen wat verandering. Maar een verandering kan niet plaatshebben als de eigenaars, de managers en de medewerkers het bestrijden eerder dan om het te omhelzen. Onderstaande vragen helpen bij dit inzicht:

·        Wat is noodzakelijk op de plant om de nieuwe werkwijze of het product toe te staan?

·        Gebaseerd op onderzoek,

o       Heeft de plant alle noodzakelijke kennis en ervaring,

o       Reserve- onderdelen;

o       Personeel;

o       Andere middelen op zijn plaats en behoorlijk werkend om rendement uit het nieuwe product of de nieuwe werkwijze te halen?

·        Zo niet, is de onderneming in dan staat om uit een nieuwe technologie voordeel te behalen?

ICT-projecten zijn bekend om hun hoge faalkansen[141] doordat DCS-projecten steeds meer op ICT-systemen gaan lijken moeten we het de kennis uit de ICT risicomanagement dan ook zeer serieus nemen. Risicomanagement is dan ook een essentieel proces voor een succesvolle uitrol van een DCS-project.

5.7.11.6 Prestaties en betrouwbaarheid

Om de prestaties en betrouwbaarheid van een systeem te kunnen beoordelen zijn hierna een drietal risico inschattingsmodellen geplaatst om de woorden en toezeggingen van de leverancier te kunnen toetsen en een waardeoordeel te geven. Onderstaande tabel 94 geeft aan wat voor een soort beoordeling kunnen toepassen op een stuk functionaliteit of technologie. Hoe meer aanpassingen er moeten plaatsvinden des te groter is het risico op het gebied van beheersbaarheid.

Tabel 94 Leverancier van de technologie of functionaliteit

De hieronder genoemde tabel 95 van de NASA helpt om de waarde (kredietwaardigheid) van bepaalde beloftes en toezeggingen ten behoeve te leveren functionaliteit en garanties te bepalen. Deze inschaling loopt van een waarde 0 ‘Nul’ tot 1 ‘één’[142].

Tabel 95 Kredietwaardigheid van functionele toezeggingen

Tabel 96 Het risico beoordelingsmodel[143]

5.7.11.7 Externe projectrisico’s

5.7.11.7.1 Leverancier technologie- en/of functionaliteit versus risico

 Een andere manier om het risico te bepalen is door te beoordelen wie de functionaliteit en de technologie gaat leveren. Functionaliteit of technologie van een ander hoeft niet slecht te zijn, het kan zelfs bepaalde voordelen hebben maar er zijn toch ook een aantal risico’s waar de eindgebruiker naar moet kijken dan wel met de DCS-leverancier moet overleggen.

Als er sprake is van een modificatie, een derde externe partij of aangepaste broncode wat zijn dan de gevolgen voor een systeem upgrade? Zie ook de hiervoor genoemde tabellen 95-96. Als er een derde partij bij betrokken is dan is het belangrijk om te weten wat voor een soort contract de twee ondernemingen hebben en voor hoelang. In dit soort samenwerkingsverbanden bestaan en een aantal risico’s zoals hier onder genoemd:

• De kleinere onderneming wordt overgenomen door een concurrent en daarom wordt de relatie afgebouwd;
• De grotere onderneming brengt de functionaliteit zelfs op de markt en stopt met de samenwerking met de andere onderneming dan wel stopt geen geld meer in de interface koppelingen bij een nieuwe release;

De kleinere onderneming brengt producten op de markt die concurreren met de producten van de hoofdonderneming en om deze reden wordt de relatie beëindigd.

De economische levensduur van de plant is onduidelijk. Denk hierbij aan kans op sluiting binnen een aantal jaren, verkoop installaties et cetera. Hiermee komt het mogelijke besparingspotentieel in het gedrang. Dit is strategisch risico maar beïnvloed de vervangingsscenario’s, bijvoorbeeld wel of geen migratie of vervanging.

5.7.11.7.2 Organisatorische risico

Onder de organisatorische risico’s kunnen we de volgende onderverdeling maken:

Afhankelijkheden met andere projecten:

o       Bij een DCS-project is dit het startmoment wanneer het implementatieteam aan het DCS-systeem mag werken, dit wordt nog wel eens uitgesteld i.v.m. leververplichtingen van de eindgebruiker, batch processen die niet zo maar gestopt kunnen worden et cetera.

·        Mensen en middelen:

o       Beschikbare kennis- en kunde binnen de organisatie;

o       Beschikbaarheid van zowel interne- als externe projectleden voor dit project;

o       Korte termijn (dagelijkse taken) versus lange termijn projecttaken;

o       De projectorganisatie zoals in paragraaf 5.7.9 ‘Project teamsamenstelling’ in meer detail beschreven.

·        Budgetten:

o       Er komen heel vaak extra wensen bij maar geen extra budget;

·        Prioriteiten:

o       De prioriteiten worden uiteindelijk door de plant bepaald maar kunnen beschikbaarheid van externe mensen soms verstoren zodat dit ook op die manier weer een effect heeft op de voortgang en planning.

5.7.11.7.3 Projectplanning risico

5.7.11.7.3.1 Requirement aanpassingen en kortere doorlooptijden

Verhoef[144] geeft aan dat naast de kosten en tijd overschrijdingen er nog een tweetal belangrijke aspecten zijn die een significante invloed hebben op de waarde van een ICT-investering. Dit zijn de steeds weer nieuwe eisen die gesteld worden (Requirement Creep) en de inkorting van de beschikbare projecttijd, (tijd compressie). Met andere woorden meer werk uitvoeren dan dat je normaal gesproken in een dergelijke periode zou doen.

De onderstaande formule van Verhoef geeft de relatie aan tussen de projectinspanning en de duur van het project waarbij:

Vergelijking 1 Relatie projectinspanning en duur

e          =          Inspanning uit te drukken in werkuren

d          =          Tijdsduur

Een DCS-project van 1.2 miljoen euro met een doorloop tijd van 12 maanden geeft

C = 9.600 * 12^^3.721 = 99.518.690

Door het project in te korten tot 11 maanden ontstaat de volgende situatie

e = 99.518.690 /11^^3.721 = 13.270 uur

Met andere woorden er zijn 13.270 – 9.600 = 3.670 uur extra nodig wat neerkomt, bij een tarief van 100 euro per uur, op een extra kostenpost van 367.000 euro.

Verhoef[145] stelt dat door de doorlooptijd te verkorten er:

• Hogere kosten ontstaan door extra werkuren en overuren;
• De kwaliteit achteruit gaat doordat er meer fouten per functiepunt ontstaan;
• De operationele- en onderhoudskosten hoger zullen uitvallen omdat een project onder verhoogde tijdsdruk lijdt tot een lager kwaliteitsniveau van het eindproduct.

5.7.11.7.3.2 Kwalitatieve risicoanalyse en scenario planning

Bij het nemen van besluiten onder onzekere toestanden wordt er vaak gewerkt met meerdere scenario’s. Over het algemeen worden onderstaande scenario’s uitgewerkt:

• Pessimistisch;
• Optimistisch;
• Middenweg;
• Niets doen.

Methoden zoals beslissingsbomen (zie paragraaf 4.24.6) en Monte Carlo simulaties (zie paragraaf 4.24.15) kunnen hierbij ondersteunen.

5.7.11.7.3.3 Kwantitatieve risicoanalyse

Onderstaande figuur 192 helpt de organisatie om zowel de kansen als de bedreigingen een plaats geven. Op de X-as staat de impact in procenten of zoals sommige andere modellen het noemen: ‘Erg laag 0-20%’, ‘Laag (21-40%)’, ‘Gemiddeld (41-60%)’, ‘Hoog (61-80%)’ en ‘extreem hoog (81-100%)’^[146].

Fig. 192 Waarschijnlijkheid en gevolgmatrix[147]

Een andere benadering is zoals weergeven in figuur 193. Dit is een voorbeeld van een weegmethode om negatieve effecten te kunnen beoordelen^[148]. Het is mogelijk om hier bedragen in te vullen, maar doordat er grote verschillen per plant bestaan zal dit dus ook per plant moeten worden opgesteld.

Fig.  SEQ Fig. 193 Relatie tussen risico effecten op de projectdoelstelling

5.7.11.7.4 Risico response planning

Een aantal risico beperkende maatregelen om grote risico’s te vermijden bij de aanschaf van een ICT-systeem zijn:

• Kies een leverancier die….
  • Zijn sporen reeds verdiend heeft (continuïteit);
  • Doet wat hij zegt (betrouwbaarheid);
  • Deskundig is op zijn terrein (vakman);
  • Weet waar u het over heeft (kennis van uw branche en uw bedrijfsprocessen);
  • Waar voor uw geld biedt (goede prijs/prestatie verhouding);
  • Zijn beloftes waar kan maken (voldoende kennis en capaciteit in huis);
  • Met u meedenkt (partnerschap);
  • Dit allemaal kan aantonen (referenties)[149].
• Kies een softwarepakket die….
  • Geschikt is voor het doel waarvoor u het aanschaft (‘fit for use’);
  • Al (veel) vaker geïmplementeerd is (proven technology);
  • Gebaseerd is op moderne technologie en ‘open’ industrie standaarden (toekomstvast);
  • Mee kan groeien met uw bedrijf (schaalbaar);
  • Eenvoudig te koppelen is aan andere systemen (flexibiliteit);
  • Belangrijk is voor zijn leverancier (continuïteit);
  • Uw medewerkers met plezier laten werken (gebruiksvriendelijk);
  • Dit allemaal kan aantonen (demonstraties, referenties).

Zorg er verder voor dat het management[150]:

·        Zelf nauw betrokken is bij het selectieproces (commitment);

·        Weet wat het wilt, nu en in de toekomst (visie);

·        De medewerkers bij het selectieproces betrekt (draagvlak);

·        Gestructureerd te werk gaat (projectmatige aanpak).

5.7.11.8 Risicobewaking en beheersing

Er zijn veel ICT gerelateerde beheerskader, normen en methodologieën in gebruik.

Geen van hen biedt een volledig bestuurkader voor ICT-operaties, maar zij vervullen allen een nuttige rol om de ICT binnen organisaties effectiever te beheren. Het Calder-Moir ICT Governance Framework is ontworpen om het maximale voordeel te behalen uit alle overlappende en elkaar beconcurrerend raamwerken en standaarden[151].

Fig. 194 Het ICT Governance Framework Model

Het Calder-Moir ICT Governance Framework gaat veel verder dan alleen ICT-governance en zet bekende ICT gerelateerde standaarden en methoden op hun plaats: Zoals PRINCE2, ITIL, CMMI maar ook de Sarbanes-Oxley wetgeving (Sox) voor deugdelijk ondernemingsbestuur, het COSO Enterprise Risk Management en de businessplannen van de onderneming. In het Calder-Moir ICT Governance Framework vinden we aan de onderzijde het noeste handwerk van ‘operatie, capaciteiten en verandering ‘. De beregeling daarvan staat in de drie segmenten er boven. Prominent geflankeerd door business en ICT-strategie zien we op de meest centrale plaats governance, compliance en risicomanagement. De versterkte aandacht voor governance, compliance en risicomanagement is vooral nodig om in een businesswereld die erg snel veranderd te kunnen garanderen dat het gewenste ook werkelijk gebeurt. Dus om concurrentievoordeel te genereren.

5.7.11.9 Samenvatting risicobeheersing

• Minimaliseer het verliesrisico van (productie, efficiency, et cetera) door een systematische benadering en uitvoering van het evaluatieproces;
• Risico te minimaliseren door de functionele requirements goed te wegen door middel van een goede data-analyse;
• Het proces is iteratief gebaseerd op kennis en gedetailleerdheid;
• Ontwikkel FMEA of FME(C)A modellen om de waarschijnlijkheid van een potentieel falen te kunnen modelleren, maak gebruik van testmogelijkheden zoals een pilot of een laboratoriumtest);
• Maak gebruik van Monte Carlo simulatie technieken om de verschillende waarschijnlijkheden door te rekenen;
• Er een groot projectrisico bestaat door een kortere project doorlooptijd en groeiende projecteisen tijdens de uitvoeringsfase;
• Besluiten zijn gebaseerd op een systematische, logische en goed gedocumenteerde methode.

5.7.12 Project inkoopmanagement

Project inkoopmanagement omvat alle processen die te maken hebben met het verkrijgen van producten, diensten of resultaten die van externe bronnen buiten het projectteam verworven moeten worden[152]. De volgende processen horen hierbij:

• Inkoop acquisitieplan:
  • Bepaal wat er gekocht of aangeschaft moet worden en bepaal wanneer en hoe dit gebeurd.
• Contractenplan:
  • Documenteer producten, diensten, resultaat vereisten en identificeer potentiële leveranciers.
• Verzoeken op leveranciersreactie:
  • Verzamel relevante informatie, aanbiedingen, offertes en voorstellen.
• Selecteer leverancier:
  • Vergelijk aanbiedingen, kies potentiële leveranciers, start onderhandelen en leg de afspraken vast in een schriftelijk contract met iedere leverancier.
• Contracten administratie:
  • Manage en documenteer hoe de leverancier zijn verplichtingen nakomt, of er correctieve acties nodig zijn en leg de basis voor een toekomstige verdere samenwerking.
• Contract afronding:

Afronden contract, afspraken maken c.q. afkopen van openstaande projectpunten.

5.7.13 Valideren Testen

5.7.13.1 GAMP

GAMP, Good Automated Manufacturing Practice. De methode is in 1994 opgesteld door het GAMP Forum, een Europese industriegroep en bevat ook richtlijnen voor het ontwerpen, testen en onderhouden van automatiseringssystemen. In 2000 werd GAMP als methode formeel opgenomen door de International Society for Pharmaceutical, ISPE en de voedingsmiddelen industrie. Inmiddels is GAMP wereldwijd bekend voor de validatie van geautomatiseerde systemen[153]. Om GAMP te begrijpen, is het van belang te weten wat er onder validatie wordt verstaan. Hoewel er verschillende definities te vinden zijn, ligt het gezien de verwevenheid met FDA-regels voor de hand de definitie te gebruiken die het FDA zelf hanteert. Deze is als volgt: ‘Validatie is het verzorgen van gedocumenteerd bewijs dat een hoge mate van zekerheid geeft dat een specifiek proces een consistent product produceert, volgens vooraf vastgestelde specificaties en kwaliteitseisen.’ In simpel Nederlands: Je moet bewijzen dat eruit komt wat je zegt dat eruit komt. Daarnaast is er het begrip Verificatie met als omschrijving ‘bouwen we het product goed’ dat wil zeggen bouwen we het conform de specificatie[154]. GAMP is opgebouwd rond het V-model waarbij er steeds bij een vereiste/specificaties aan de linkerkant van het model een kwalificatie/validatie aan de rechterzijde bij hoort. Er wordt dus per stap direct bekeken hoe één en ander in de toekomst getest moet gaan worden. Het V-model is een stappenplan dat de diverse fasen van planning tot en met eindrapportage definieert en elke stap koppelt aan een controle later in het traject: Heb ik gedaan wat ik zou doen? Het geheel wordt grafisch weergegeven in de vorm van een V, met in de punt de fase waarin de programmacode wordt geschreven. Het V-model zag het licht in 1986, toen Brook het toen populaire watervalmodel een facelift gaf.

5.7.13.1.1 V-Basismodel

Fig. 195 Het vereenvoudigd V-model

De basis van het V-model is dat er een plan is die gespecificeerd wordt, hier komt een document of een stuk softwarecode uit welke nadien weer wordt geverifieerd. Door dit al toe te passen vanaf de eerste start van het project (concept ontwerp, basis ontwerp, detailontwerp) is de kans aanzienlijk kleiner dat er:

• Functies onderweg verloren gaan;
• Functies verkeerd worden geïnterpreteerd.

Daarnaast levert dit een tijd- en kostenbesparing op omdat afwijkingen direct in de nabijheid van de bron worden ontdekt en herstel dus ook minder tijd en geld gaat kosten.

Fig. 196 Het V-model in meer detail [155]

Goede punten aan het V-model zijn:

• Het definieert meetbare fasen van het proces en geeft een aanbeveling voor een logische volgorde hoe de fasen benaderd moeten worden. Het definieert bovendien een logische relatie tussen de fasen;
• Het dwingt de opdrachtgever om SMART functionele requirements te stellen om een goede valideerbare test te kunnen uitvoeren;
• Het vereist dat testdocumenten zo snel als mogelijk worden geschreven,
  • Bijvoorbeeld de integratie tests zijn beschreven als het ontwerp op hoofdlijnen is afgerond. De unit tests zijn gereed als de detailspecificatie is afgerond;
• Het geeft hetzelfde belang aan de ontwikkeling als aan het testen;
• Het geeft een eenvoudig en gemakkelijk te volgen schema om het softwareontwikkelingsproces te kunnen volgen.

Een nadeel van dit simpele V-model is dat het geen rekening houdt met de complexiteit en kan daardoor misleidend zijn voor de projectmanager om er volledig op te vertrouwen. Inmiddels gaan er geluiden op dat ook het V-model mankementen vertoont. Zo stelt Liversidge in een artikel ‘Death of the V-model’[156] uit 2005 dat het V-model niet geschikt is voor complexe situaties en geen rekening houdt met verandering. Met de introductie van een vereenvoudigde versie GAMP 5 in 2008 is dit opgelost namelijk met het opnemen van een levenscyclus benadering in het kwaliteitsmanagementsysteem. GAMP is oorspronkelijk ontwikkeld voor de FDA-markt bedoeld maar is ook zeer goed bruikbaar voor de normale implementatiecyclus. Bij de nieuwe GAMP 5 bepaald de wetenschappelijk onderbouwde risicoanalyse de mate van functionele specificatie-eisen en de vereiste validatie. Hoewel de meeste bedrijven in de procesindustrie niet aan GAMP 5 hoeven te voldoen is het een mooie kapstok om de validatie tussen ontwerp en eindproduct te controleren en beheersen.

GAMP 5 geeft detailinformatie over een vijftal belangrijke concepten[157]:

1.      Beter begrip van producten- en productieprocessen om zo te kunnen bepalen of een systeem geschikt is voor het beoogde doel;

2.      Het opnemen van de complete levenscyclus van systemen in een kwaliteitssysteem of QMS (Quality Management Systeem);

3.      Het opschalen van activiteiten afhankelijk van de impact van systemen op veiligheid, productkwaliteit en data-integriteit;

4.      Toepassing van Quality Risk Management, ofwel een systematisch proces om risico’s te bepalen, beheersen en beoordelen. Hierbij verwijst GAMP naar de richtlijn van de International Council for Harmonisation (IHC) Guidance Q9. Deze IHC Q9 is een geaccepteerde standaard voor Risk Management;

5.      Betrek leveranciers er zoveel als mogelijk bij gedurende de levenscyclus van systemen. Hiermee wordt de kennis en ervaring van leveranciers gebruikt en kan al beschikbare documentatie en testresultaten worden hergebruikt.

Het V-model is onder GAMP dan ook meer naar een V-W model gegaan, waar ook rekening wordt gehouden met wijzigingen ‘onderhoud’ en de totale levenscyclus.

Fig. 197 V-W Model ten behoeve van GAMP[158]

Fig. 198 Richtlijnen en methodieken voor applicatie-engineering.

Figuur 184 laat mooi de verschillende groepen zien die bepaalde taken uitvoert. De eindgebruiker, de projectorganisatie of de leverancier.

Het valideren en testen is in twee delen te splitsen:

• Documenten review:
  • Concept ontwerp:
    • Gebruikersvereisten.
  • Basis ontwerp;
  • Detailontwerp:
    • Alarmmanagement uitgangspunten;
    • Beveiligingen – interlocks;
    • Displays;
    • I/O;
    • Regelingen;
    • Stappen programma’s.
• Systeem testen:
  • Interne systeemtest uitgevoerd door de DCS-leverancier;
  • FAT;
  • SAT;
  • Commissioningstest;
  • Performancetest.

5.7.13.1.2 Uitgangspunt ontwerp- en kwalificatiedocument

Fig. 199 V-model in relatie tot verantwoordelijkheid

In essentie is er steeds een plan- ontwerpdocument en op hetzelfde moment wordt ook bepaald hoe een en ander getest moet worden. De volgende documenten horen tussen de verschillende stappen:

Tabel 97 uitgangspunt ontwerp- en kwalificatiedocument

5.7.14 Het testen van het systeem

De vijf belangrijke systeem testperioden bij de aanschaf van een DCS-systeem zijn:

1.      De eerste test vindt plaats door de leverancier, bij de leverancier van alle hardware en software, als hij van mening is dat het ontwerpproces is afgerond[159];

2.      De tweede test vindt ook plaats bij de leverancier in een zogenaamde ‘staging area’ waar een testteam van de eindgebruiker de zogenaamde ‘Factory Acceptance Test’ (FAT) uitvoeren. Deze FAT test is de grootste en daarmee ook de belangrijkste test voor de eindgebruiker en de leverancier;

3.      De ‘Site Acceptance Test’ (SAT) test wordt on-site bij de eindgebruiker uitgevoerd als aan het systeem alle systeem componenten zijn aangesloten;

4.      De commissioningstest wordt na de SAT test uitgevoerd bij de eindgebruiker on-site als op het systeem alle ingangen en uitgangen zijn aangesloten;

5.      De performancetest, in deze fase wordt gekeken of de afgesproken performance garanties worden gehaald in een dynamische procesomgeving.

5.7.14.1 Kosten verdeling tijdens het testen

Figuur 200 hieronder laat de relatie zien van de kosten van de interne beheersmaatregel van de leverancier. Als de leverancier er weinig energie in steek onder het motto ‘het wordt toch door de eindgebruiker getest’ ontstaat er voor de leverancier een kostenbesparing. Het gevolg zal echter zijn dat bij een DCS waar de kwaliteitbeheersing minimaal is geweest de FAT test aanzienlijk langer zal duren dan men oorspronkelijk had verwacht. Een langere FAT leidt dus tot hogere kosten aan eindgebruikerzijde en tot beperkt meerkosten aan leverancierszijde. Door van de DCS-leverancier te eisen dat hij zich houdt aan zijn eigen QA documenten voorkomt de eindgebruiker dat hij tijdens de FAT, de eerste is die het systeem gaat testen.

Fig. 200 Hoeveel testen? Testen en kosten van kwaliteit Bron TU Wenen[160]

5.7.14.2 Interne test bij DCS-leverancier

De eerste test vindt plaats door de DCS-leverancier zelf en valt gedeeltelijk buiten het gezichtsveld van de eindgebruikers. Het is voor de eindgebruiker belangrijk dat deze test ook werkelijk plaats vindt en niet om kostenreden achterwege wordt gelaten omdat er toch nog een FAT komt. Een FAT test kan aanzienlijk uitlopen als de eerste testfase niet goed is afgerond. Een aantal hulpmiddelen kunnen daarbij helpen:

• Vraag de leverancier om hun QC/QA plan;
• Vraag om hun interne testplan;
• Vraag voordat de FAT test begint het foutenrapport van alle gevonden problemen in de eerste test. Het blijkt namelijk in de praktijk dat er wel een testplan is, maar dit testplan niet of onvoldoende wordt afgewerkt door de leverancier. Bovendien zegt het iets over het aantal gevonden fouten en de kwaliteit van de software en de eerste tests.

5.7.14.3 Factory Acceptance Test (FAT)

De duur van de FAT is afhankelijk van de omvang van een systeem maar als indicatie zal een FAT van een 1.500 I/O DCS-systeem tussen de drie en zeven weken duren.

Tijdens de FAT spelen onderstaande onderwerpen een rol:

·    Acceptatietesten voor- en na aflevering[161]:

• Testen volgens leveranciersstandaard;
• Testen volgens de eisen van de opdrachtgever;
• Hardware en systeemsoftware;
• Applicatiesoftware;
• Integratietesten met andere PLC, SIL apparatuur en andere interfaces;
• Bij een FAT zijn de testuitgangspunten van groot belang, Een belangrijke vraag is of het de doelstelling is dat 100% van het systeem te testen, of een bepaald deel van de I/O en applicatie te testen dan wel dat er een bepaalde vaste tijdsduur van de FAT afgesproken is. Met andere woorden de test duurt drie weken en de eindgebruiker heeft daarna een goed beeld van de kwaliteit van de software en configuratie;
• Testen op bekende of vaak voorkomende problemen (beschikbaarheid ‘bug’ -lijst?);
• Testen op basis van ‘benchmarks’
• Methode van I/O testen[162]:

1. Een 100% test van alle I/O signalen met behulp van een signaalgever voor de ingangssignalen en een multimeter voor de uitgangssignalen, daarnaast patch panelen met potentiometers en schakelaars;
2. Gedeeltelijke controle volgens de onder punt ‘a’ genoemde methode;
3. Toepassen van een eenvoudige simulatie die de uitgang- en ingang signalen met elkaar verbindt;
4. Toepassen van een processimulator die het externe proces simuleert.

Iedere methode van testen heeft zo haar voor- en nadelen, zo kost methode ‘a’ veel tijd, maar alles wordt wel getest, methode ‘b’ is een compromis maar delen worden niet getest (meest voorkomend). Methode ‘c’ geeft iets meer dynamiek aan het systeem maar er worden wijzigingen aangebracht ( die na de test weer voor 100% moeten worden verwijderd) aan de configuratie, dus testsysteem is niet 100% hetzelfde als het operationele systeem. Methode ‘d’ vereist speciale hardware maar is zeer realistisch. De belangrijkste onderdelen van een acceptatietest zijn beschreven in de Appendix E7 ‘Acceptatie testen’.

5.7.14.4 Site Acceptance Test (SAT)

De ‘Site Acceptance Test’ (SAT) test wordt on-site uitgevoerd bij de eindgebruiker als alle systeem componenten onderling en het totale systeem aan de grondaarde en aan de voedingsspanning zijn aangesloten. De SAT is een korte inspectie (minder dan 1 dag) en betreft een inspectie of alle DCS-componenten correct zijn aangesloten en er geen onverklaarbare foutmeldingen zijn. De hoofdreden voor een DCS-leveranciers van de SAT is dat de installatie wordt overgedragen aan de eindgebruiker. Met deze overdracht moet de laatste 10% van de aanneemsom worden betaald en is de verantwoordelijkheid overgedragen. Het is wel verstandig om nadien nog een formele performance test te hebben in het contract, mocht dit niet het geval zijn dan is het voor eindgebruikers beter om niet te snel de SAT af te tekenen, sommige bedrijven stellen de SAT afsluiting met een jaar uit.

5.7.14.5 Commissioningstest

De commissioningstest wordt na de SAT) test uitgevoerd bij de eindgebruiker on-site als het systeem alle ingangen en uitgangen zijn aangesloten. Dit is een erg lange test doordat alle losse I/O signalen, inclusief veldapparatuur (‘looptests’) en regelorganen (kleppen, motoren) getest worden. De DCS-leverancier is hier vaak niet of beperkt bij betrokken terwijl een systeemintegrator juist vaak wel in deze fase actief is. Het hoofdaccept is het testen van de externe verbindingen maar ook fouten in de software worden hier nog gevonden. Vooral op het gebied van logica en stappen programma’s. De commissioningstest bij een nieuwe installatie kan maanden in beslag nemen.

5.7.14.6 De performancetest

De performance testfase wordt gekeken of de afgesproken performance garanties worden gehaald in een dynamische procesomgeving. Dit is vooral een administratieve actie, waarbij applicatieondersteuning nodig is van de leverancier als de afgesproken prestaties niet worden gehaald. Deze test wordt maar beperkt door de ondernemingen uitgevoerd maar zou veel bijdragen aan een succesvolle operatie. Bij de bedrijven waar dit laatste van toepassing is is ook vaak sprake van een bepaalde mate van opstart assistentie die door de leverancier wordt geleverd. Deze performancetest zou moeten bewijzen, dat wat tijdens de business case garanties is afgesproken ook werkelijk wordt gehaald.

18-10-2009