MBA INFORMATION MANAGEMENT THESIS RESEARCH PROJECT                         

Search for:

Home Newport Onderzoeksvoorstel online_survey ProcessControl Links news and progress Personal info Feedback form site index Thesis DOCUMENTS Literatuur overview Results involved Company's Press Support DSS rightchoice software Concept thesis    Please Use the online survey.

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

 

 

 

5.1 Business case garanties van de leverancier

 

Doordat een business case een voorspellend karakter heeft, is de kans groot dat het rooskleurig wordt ingeschat, zeggen veel experts. ‘Er wordt met aannames gewerkt wat betreft de mogelijke opbrengsten van het eindresultaat’, zegt Kalsbeek[1].‘Zeker bij complexere projecten is het voor een actor nauwelijks te overzien hoe realistisch de aannames zijn’, zegt Plas[2]. Van Dalen[3] denkt dat het te maken heeft met de roze bril die initiatiefnemers ophebben. ‘Zij zijn vaak zeer enthousiast over vernieuwing en kiezen een rooskleurig scenario’. Vooral bij nieuwe zaken is het lastig een goede business case op te stellen, zegt Maas[4]. ‘Men heeft geen referenties waarmee een en ander kan worden vergeleken’. Volgens Van den Berk[5] zal een ICT-leverancier alles aangrijpen om de offerteprijs te verlagen om een aanbesteding te kunnen winnen. ‘Wie op de helft van de reële prijs en de helft van de reële levertijd gaat zitten, doet tenminste nog mee. Want ja, het gaat om de verkoop, dan is de bonus binnen en mogen de ‘technici' het onmogelijke proberen voor elkaar te krijgen. ‘Geen wonder dat rooskleurige business cases schering en inslag zijn’, zegt Van der Vlugt[6]. Het heeft overigens niet alleen te maken met geld, volgens Maas[7]. ‘Wil men het project toch graag starten, dan is het natuurlijk goed om deze rooskleuriger voor te doen dan men daadwerkelijk denkt dat hij is. Gedurende het traject komt men er achter dat de oorspronkelijke business case te rooskleurig was, dan heeft de opdrachtgever vaak al zoveel geld uitgegeven dat het afblazen van het project een dusdanige destructie van investering vergt dat men het project toch maar afmaakt’. Hoogendoorn[8] geeft aan dat de project-requirements tijdens projecten ongeveer twintig tot 25 procent wijzigen’. Dit heeft uiteraard een invloed op kosten en resultaat. Welschen[9] (Siemens DCS-accountmanager) noemt als voorbeeld dat plantmanagement de mond vol heeft van TCO en EVA maar dat in de praktijk blijkt dat de inkoper/projectleiders TCO verlagende maatregelen wegbezuinigen doordat de beloningsstructuur van deze functionarissen hier niet bij past. Zij worden op de directe projectkosten afgerekend en niet op de TCO zoals dit uitgebreid beschreven is in paragraaf 4.22.3 ‘Inter-persoonlijke en individuele factoren’.

De algemene Rekenkamer[10] stelt in haar 2007 rapport naar ICT investeringen: ‘Wanneer een minister zich bij zijn besluitvorming onvoldoende laat ondersteunen door deskundigen met voldoende kennis van ICT en organisatie, neemt het risico op te ambitieuze projecten toe. De consequentie is dat het project organisatorisch en technisch niet realistisch is en dat er dus geen sprake is van een project met SMART-C (specifiek, meetbaar, acceptabel, realistisch, tijdgebonden en consistent) geformuleerde doelen. Zonder een zakelijke rechtvaardiging (business case) kan het project leiden tot veel teleurstelling’.

Dekker[11] stelt dat volgens ICT-deskundigen de Nederlandse overheid jaarlijks vier tot vijf miljard euro uitgeeft aan geheel of gedeeltelijke mislukte ICT-projecten. Dit bedrag is gebaseerd op slagingspercentages van ICT-projecten uit een Amerikaanse enquête (Standish Group, 1995) waarvan de resultaten zijn toegepast op de Nederlandse ICT-uitgaven. Dat onderzoek geeft een 30:50:20 verhouding aan: 30% van alle ICT-projecten zou tot geen enkel resultaat leiden, 50% valt in een grijs middengebied, te duur, te laat of van onvoldoende kwaliteit – en slechts 20% zou als helemaal geslaagd te beschouwen zijn. Dit heeft men afgezet tegen 18,5 miljard euro aan Nederlandse ICT-uitgaven in 2004 en dan komt men op een bedrag van circa zes euro miljard aan compleet mislukte projecten en nog eens  negen miljard euro aan automatisering met kleine tot grote problemen voor projecten bij de overheid en het bedrijfsleven samen. De overheid zou hierbij ongeveer de helft van alle ICT-investeringen (en mislukkingen) voor haar rekening nemen. In paragraaf 5.7.11 Projectrisico management wordt dit in detail beschreven. Volgens Berghout[12] worden ICT-business cases te snel goedgekeurd terwijl de directie geen duidelijk beeld heeft van de meerwaarde die ICT bijdraagt aan de organisatie. Sneller[13] voegt daaraan toe dat een ICT-project niet per definitie mislukt is als de business case niet wordt gehaald. Zij benadrukt dat er tijdens de uitvoer van een project voldoende ruimte moet zijn voor aanpassingen. Den Boer[14] stelt dat het venijn in de startfase van het project zit. ‘Het begint met het opstellen van een business case. Morley[15] stelt dat tijdens de verkoopgesprekken van een systeem wordt er gesproken over DCS als een ‘voordeel’ of een ‘oplossing’ en wanneer het systeem wordt geleverd spreekt men alleen over een stuklijst met goederen. Driedger[16] stelt ‘dat een bepaalde applicatie een bepaalde ROI kunnen opleveren maar hij stelt dat het niet redelijk is, om te stellen dat leverancier A ten opzichte van leverancier B een betere ROI kan afgeven voor een nieuwe plant bij de aanschaf van een DCS systeem. Voor een specifieke applicatie zoals niche markten zoals kwaliteitssystemen voor de papierindustrie is het eenvoudiger om een onderbouwing op te stellen’.

Anderzijds kunnen we stellen dat de garantie die de leverancier afgeeft afhankelijk is van een aantal factoren:

  1. Hoe dringend heeft hij het project nodig?
  2. Hoe goed is de applicatie en systeem van de leverancier om aan de gestelde eisen te kunnen voldoen?
  3. Hoe goed is het implementatieteam van de leverancier om de applicatie en het systeem optimaal aan de gestelde eisen van de eindgebruiker aan te kunnen passen?
  4. Hoeveel risico mag de DCS-leverancier lopen volgens zijn eigen interne corporate richtlijnen? Dit wordt meestal bepaald door de financiële afdeling en de cultuur binnen de leveranciersorganisatie;
  5. Hoeveel risico wil de leverancier lopen bij deze klant, markt of regio?

 

Een voorbeeld uit de papierindustrie (De eendracht Karton) was een garantie om 5.000 ton meer verkoopbaar product te leveren of 40% minder 2e soort productie te genereren. Een voorbeeld uit de publieke sector binnen een EU lidstaat, waarbij een risico analyse uitwees dat de deadline van het project, zeg 15 januari 2008, gezien moest worden als het meest kritische risico. Zou de leverancier één dag te laat opleveren, dan zou de opdrachtgever één jaar geen data kunnen verwerken. Ofwel: één dag uitstel was één jaar uitstel. Het gunningsmodel werd in dit voorbeeld zo ingericht dat de leveranciers 40% van maximale 100 puntenscore voor hun offerte kon verdienen met hun afgegeven deadline. Dit leek simpel: voor iedere maand die de leveranciers bereid waren het systeem eerder op te leveren dan de kritische deadline kregen ze 10 punten, met een maximum van vier maanden. Dit model leek, in eerste aanleg, de kat op het spek binden. Opportunistische leveranciers leken eenvoudig een deadline van 40% binnen te hebben. Maar hier had de opdrachtgever een aardige spanningsboog ingebouwd. Welke deadline de opdrachtgever ook aangaf tussen 15 september en 15 januari) als de leverancier één dag te laat zou opleveren dan de door hem zelf afgegeven deadline, dan stond hem een boete van 5 miljoen euro te wachten. Een fors bedrag, overigens wel in proportie in relatie met de totale opdrachtsom. Hier deed de marktwerking vervolgens haar werk. De afgegeven offertes koersten gemiddeld genomen op de tweede helft van november. Geen enkele leverancier bood de verleidelijke 15 september aan. Alle leveranciers hadden veel tijd gestoken in kritische pad analyses, in het vrijhouden van de beste mensen, in opleidingen, kortom: alle leveranciers hadden zich beijverd om het meest kritieke risico van de opdrachtgever te helpen beteugelen. Ze kregen de opdracht graag gegund, maar niet ten koste van vijf miljoen euro. Dit is professioneel opdrachtgeverschap[17].

 

5.1.1 Risico van nieuwe technologie en gevolgen voor de business case

 

Herb[18] stelt dat er goede reden zijn waarom een nieuwe technologie verdacht is op het eerste moment dat deze technologie beschikbaar komt. Waren het in het verleden begrippen als de transistor, glasvezelverbindingen, kathodebuis, insteekmodules, computers, software en alles waar Microsoft op stond, op dit moment zijn het de begrippen: Foundation Fieldbus, Wireless en open systemen met relatie tot beveiligingsrisico’s de zorgpunten bij veel eindgebruikers. De verantwoordelijke procesbesturing engineers en plant management zijn verantwoordelijk voor een stabiele en continue operatie. Een onderbreking voor zelfs een zeer korte periode is extreem kostbaar (tussen 100.000 euro en 10 miljoen euro). Veiligheid van personeel, apparatuur, milieu en productie zijn allemaal even belangrijk in deze afweging. Om deze reden zijn de engineers en het plant management voorzichtig bij het kiezen van nieuwe technologie ondanks de beloftes die deze technologie in zich heeft.

5.1.2Besluiteloosheid

Novarica geeft in onderstaande figuur 104 de relatie weer tussen de business case, de toekomstige werkwijze en het selectieproces weer.

Fig. 104 Besluiteloosheidcyclus[19]

In de besluiteloosheidcyclus ‘The Insurance Technology Indecision Cycle’, wordt gesteld dat ieder slecht proces of slechte beslissing een gevolg heeft voor de volgende stap. Het eindresultaat is of een falend project, een project die zijn ondersteuning van de directie verliest en nooit zal starten of in het beste geval wel succesvol wordt geïmplementeerd maar de gestelde ROI niet kan halen door onrealistische bedrijfsverwachtingen en kosten.

5.1.3 Samenvatting van business case ‘problemen’

Samenvattend kunnen we de volgende waarnemingen doen ten aanzien van een business case:

·        De business case garantie gaat niet om de laagste prijs maar om de zekerstelling van het bereiken van de afgesproken toegevoegde waarde voor de opdrachtgever;

·        Een slechte business case blijft je het hele project achtervolgen, dus doe het in één keer goed;

·        De leverancier heeft een belang bij een positieve business case, dan is hij in staat om een systeem te verkopen;

·        De business case van de klant is vaak met een roze bril geschreven. De opbrengsten worden overschat, de tijdsduur en de kosten onderschat;

·        Reële risico-inschatting en planning zijn van vitaal belang bij een realistische business case;

·        Dat persoonlijke bonus beloningen van project managers of inkopers haaks staan op lange termijn besparingen voor de eindgebruiker;

·        Er is onvoldoende kennis aanwezig om een goede business case op te bouwen;

·        De functionele eisen en omvang van het project veranderen tijdens het project wat een ‘vaak negatief’ effect heeft op de business case.

·        Als een project eenmaal goedgekeurd is wordt het vaak niet gestopt als blijkt dat de kosten veel hoger worden, met als argument ‘er is al zoveel geld in geïnvesteerd’.

 

Om bovenstaande redenen is het dus belangrijk dat er goed naar de business case wordt gekeken, eventueel door een derde partij, waarna beide contractpartners de uitgangspunten en afgesproken resultaten vastleggen in een performance contract en hier harde financiële garantie afspraken over te maken om een en ander te garanderen.

5.1.4 Vormen van business case garanties

 

Nadat er samen met een DCS-leverancier een business case is ontwikkeld, moet bepaald worden hoe deze besparing werkelijk wordt gerealiseerd en gegarandeerd. Een potentiële besparing van 500.000 euro zonder garantie zou dan ook lager beoordeeld moeten worden dan een besparing van 200.000 euro met garantie. Een garantie kan de volgende vormen aannemen:

1.      Een boete clausule als de afgesproken besparing niet wordt gehaald;

2.      Een bonus voor de projectleider als bepaalde resultaten voor een afgesproken tijdstip worden gehaald (heeft echter bepaalde lange termijn risico’s);

3.      Een variabel deel in de koopprijs. Bijvoorbeeld hardware wordt verrekend en de engineeringinspanning wordt pas betaald nadat het garantiebedrag wordt gehaald;

4.      Engineers blijven zo lang on-site tot dat de besparing is gerealiseerd;

5.      Er kunnen bepalingen zijn over welke personen van de leverancier de uitvoering van het project doen (ervaringseisen);

6.      Direct bij de aankoop van het systeem een servicecontract af te sluiten voor een lange termijn. Hierbij moet men minimaal denken aan contracten van vijf jaar maar een langer contract gedurende de gehele levensduur van 17-20 jaar is nog een betere optie om een heel goed beeld te krijgen van de levenscycluskosten (LCC).

 

De voorkeur van de onderzoeker zijn de punten drie, vier en zes daar deze de beste lange termijn winsten garanderen en het hoogste commitment van de leverancier.


 

5.1.5 Garantie zorgt voor snellere projectgoedkeuring

 

Bij een afgegeven garantie van de leverancier, is de eindgebruiker sneller bereid om het project door te laten gaan. Een RIO analyse van de kostenverantwoording, samen met een business case, verhoogt de waarschijnlijkheid op een project goedkeuring met 60% en reduceert de doorlooptijd van het verkoopproces met 30-40% volgens het onderzoeksbureau IDC[20]. Strategisch gesproken geeft deze ROI analyse de interne DCS-project manager de analyse die hij nodig heeft om samen met de DCS-leverancier (als partner) de beloofde toegevoegde waarde te gaan realiseren. Dit leidt tot risicoreductie en tot het verhogen van de bedrijfsresultaten. Het is dus ook voor de DCS-leverancier aantrekkelijk om een garantie af te geven dan hij heeft lagere verkoopkosten en een verhoogde kans dat het project doorgaat.

Het is verstandig om het contract te schrijven in op te leveren resultaten dan in uit te voeren werkzaamheden. Tenslotte wil de eindgebruiker bepaalde doelen met het nieuwe systeem bereiken.


 

[1] Kalsbeek Jaap, ‘Project wordt vaak te positief ingeschat’, interview by Van Heur Rian (2009), Computable (10 april 2009), http://www.computable.nl/artikel/ict_topics/beleid/2924361/2379250/project-wordt-vaak-te-positief-ingeschat.html. (accessed 12 juli, 2009).

[2] Plas Marco, ‘Project wordt vaak te positief ingeschat,’ interview by Van Heur Rian (2009), Computable (10 april 2009), http://www.computable.nl/artikel/ict_topics/beleid/2924361/2379250/project-wordt-vaak-te-positief-ingeschat.html. (accessed 12 juli, 2009).

[3] Van Dalen André, ‘'Project wordt vaak te positief ingeschat',’ interview by Van Heur Rian (2009), Computable (10 april 2009), http://www.computable.nl/artikel/ict_topics/beleid/2924361/2379250/project-wordt-vaak-te-positief-ingeschat.html. (accessed 12 juli, 2009).

[4] Maas Mat, ‘Project wordt vaak te positief ingeschat,’ interview by Van Heur Rian (2009), Computable (10 april 2009 2009), http://www.computable.nl/artikel/ict_topics/beleid/2924361/2379250/project-wordt-vaak-te-positief-ingeschat.html. (accessed 12 juli, 2009).

[5] Van den Berg Fred, ‘Te positieve business case komt door eigenbelang,’ interview by Van Heur Rian (2009), Computable (14 april 2009), http://www.computable.nl/artikel/ict_topics/beleid/2927113/2379250/te-positieve-business-case-komt-door-belangen.html. (accessed 12 juli, 2009).

[6] van der Vlugt Jurgen, ‘Te positieve business case komt door eigenbelang,’ interview by Van Heur Rian (2009), Computable (14 april 2009), http://www.computable.nl/artikel/ict_topics/beleid/2927113/2379250/te-positieve-business-case-komt-door-belangen.html. (accessed 12 juli, 2009).

[7] Maas Mat, ‘Te positieve business case komt door eigenbelang,’ interview by Van Heur Rian (2009), Computable (14 april 2009), http://www.computable.nl/artikel/ict_topics/beleid/2927113/2379250/te-positieve-business-case-komt-door-belangen.html. (accessed 12 juli, 2009).

[8] Hoogendoorn Sander, ‘Project wordt vaak te positief ingeschat,’ interview by Van Heur Rian Computable (10 april 2009), http://www.computable.nl/artikel/ict_topics/beleid/2924361/2379250/project-wordt-vaak-te-positief-ingeschat.html#reacties/ (accessed 11 april, 2009).

[9] Welschen Ruud, RE: Verzoek om medewerking MBA thesis ‘Selectie en besluitvormingscriteria bij Process Control Systemen in de procesindustie, e-mail message to author, 9 augustus, 2007.

[10] Algemene Rekenkamer, Lessen uit ICT-projecten bij de overheid Deel A (Den Haag: Algemene Rekenkamer), Algemene Rekenkamer, 15, http://www.rekenkamer.nl/dsresource?objectid=68210&type=org/ (accessed 12 juli, 2009).

[11] Dekker V., ‘Automatisering slokt miljarden euro’s op; Overheid smijt met geld voor gebrekkige software,’ Trouw, 4 juni 2007.

[12] Berghout Egon, ‘Directie geeft ICT-manager te veel vrijheid,’ interview by Van der Beek Pim (2008), Computable (17 november 2008), http://www.computable.nl/artikel/ict_topics/beleid/2774609/2379250/directie-geeft-ICTmanager-te-veel-vrijheid.html. (accessed 12 juni, 2009).

[13] Sneller Lineke, ‘Directie geeft ICT-manager te veel vrijheid,’ interview by Van der Beek Pim (2008), Computable (17 november 2008), http://www.computable.nl/artikel/ict_topics/beleid/2774609/2379250/directie-geeft-ictmanager-te-veel-vrijheid.html. (accessed 12 juli, 2009).

[14] Den Boer Frank, ‘Murphy Bijt ICT'er flink in de staart,’ interview by Van Lonkhuyzer Peter (2006), Managementteam (8 september 2006): 52.

[15] Morley Richard E., ‘Control Needs of the Nineties,’ in distributed control system: Selection, Implementation, and Maximization, ed. McMillan Gregory K (New York: Instrument Society of America, 1991), 83-84.

[16] Driedger Walter, [controls] RE: DCS selection business case garanty, e-mail message to author en Controls Manufacturing Community List, 3 juli 4:51, 2008.

[17] Van Heur Rian, ‘Kader Maak van je kritieke risico’s je sterke,’ Computable (10 april 2009), 16.

[18] Herb Samuel, ‘Hybrid Control Identity Crisis,’ Intech, September, 2007, http://www.isa.org/InTechTemplate.cfm?Section=Article_Index1&template=/ContentManagement/ContentDisplay.cfm&ContentID=63834/ (accessed 01 maart, 2009).

[19] Hersh Chad en Josefowicz Matthew, ‘The Indecision Cycle™: Avoiding Roi Erosion Before The Project Starts Research Report,’ Novarica, April, 2008, www.novarica.com/report_indecision_cycle.shtml/ (accessed 18 maart, 2009).

[20] Steve Krause, ‘Develop A Winning Business Case,’ Capitalgroup, http://www.capitalhgroup.com/pdf/newsletter/CapitalH_Sep05.pdf.(accessed 11 october, 2007).

 

 

When you need specific information please send my a e-mail.

 

Willem.Hazenberg@dcsselect.eu

 

 

18-10-2009            Hit Counter

 

View Willem Hazenberg EUR ING RI's profile on LinkedIn