ICT-leveranciers zijn meesters in het risicoloos ondernemen, meesters in het afschuiven van verantwoordelijkheden, en vaak hebben ze een sterke voorkeur voor uurtje-factuurtje. Als ze toch eens een project als project moeten aannemen, dan tuigen ze dit vaak zodanig op, dat hun risico’s gedekt zijn en dat het lijkt alsof u waar voor u geld krijgt. Als programma manager bij Cap Gemini heb ik dit spel mogen spelen aan de kant van de leverancier. In de 14 jaar als managing consultant van ZBC werk ik vaak namens de opdrachtgever. Vanuit deze ervaring presenteer ik u de belangrijkste tips voor het inkopen van ICT-projecten. Hierbij ga ik ervan uit, dat u zelf geen tientallen of zelfs honderden ICT’ers in uw organisatie hebt rondlopen, dat  informatieverwerking voor u geen core-business is, dat ICT voor u niets meer is dan een belangrijk en zeer bruikbaar bedrijfsmiddel en dat u behoefte heeft  aan een leverancier die zich als probleemeigenaar opstelt en daadwerkelijk garanties biedt.

Tip 1: Vraag geen offertes aan

Als u een product of een eenvoudige dienst koopt, dan vraagt u natuurlijk meerdere offertes aan. U weet dan exact wat u wilt hebben en uiteraard wilt u garanties. Voor ICT ligt dit vaak totaal anders. Een offerte van een ICT-leverancier beschrijft wat die leverancier  gaat leveren en het is aan u om vast te stellen of er een match is met uw behoefte. Als u met de leverancier in zee gaat en er is toch sprake van een mismatch, dan blijkt u vaak de probleemeigenaar te zijn, die voor de herstelkosten opdraait. De leverancier heeft immers geleverd wat hij zei te zullen leveren?
Probeer daarom uw behoefte zo goed mogelijk te omschrijven in termen van doelstellingen  (op ‘wat’-niveau) en leg dit vast in een Request for Proposal (RfP). Dat bespaart u om te beginnen al heel veel werk. Neem contact op met een aantal potentiële aanbieders, waarvan u inschat dat ze een oplossing kunnen realiseren, waarmee ze voldoen aan uw behoefte. Organiseer voor de kandidaten een uitgebreide informatiesessie en laat hierbij zien in wat voor omgeving de oplossing zal moeten werken. Vraag hierop om een reactie. Bepaal vervolgens de knock-out criteria en geef deze aan in uw RfP.

Tip 2: Nu selecteren op prijs kost later veel geld

Veel ICT-leveranciers zijn ervaren in het inschrijven op een RfP. Ze weten dat ze scherp moeten aanbieden en hun dienst goed moeten afbakenen. Verdienen gaan ze door de inzet van veel goedkopere juniormedewerkers, door meerwerk en door het aanbieden van diensten die voor hen geen kosten met zich meebrengen. U kunt in dit stadium dan ook meestal van alle aanbieders een voor u faire prijs verwachten. Geld wordt pas later belangrijk en dan kunt u nog enkele tientallen procenten besparen op uw kosten voor de dienstverlening. Nu gaat het erom de aanbieder te kiezen die daadwerkelijk aanbiedt wat u heeft gevraagd en op een manier waarin u gelooft. Verdiep u op dit moment niet in alle ingewikkelde verhalen uit de aanbieding. Vaak zijn deze bedoeld om iets te verbloemen, bijvoorbeeld een poging om op voorhand alvast een hoeveelheid meerwerk te genereren of om u weer tot probleemeigenaar te maken. Nodig de leveranciers van de twee of drie meest interessante offertes uit en stel ze dan gewoon de vraag welke toegevoegde waarde de ingewikkelde verhalen hebben voor uw doelstellingen. Meestal blijkt dan, dat ze ook geschrapt kunnen worden. Als dat zo is, hoeft u alleen nog de vraag te stellen wat hiervan de consequenties zijn  voor de prijs. Zorg dat de vragen en antwoorden worden genotuleerd.

Tip 3: Eis expertise en eis ‘proven technology’

U wilt niet de oplossing die u vraagt, maar de oplossing die u nodig heeft! Dat zijn doorgaans twee heel verschillende dingen. U wilt dus consultants van de leverancier die komen brengen en niet consultants die alleen maar halen. Het moeten dus ervaren consultants zijn. U voorkomt daarmee bovendien dat u weer probleemeigenaar wordt. Eis dus van de leverancier dat hij op basis van zijn expertise een voor u werkende oplossing realiseert. En als de leverancier komt met een oplossing die niet werkt, dan is de zaak duidelijk. Dan mag hij voor eigen rekening zorgen, dat hij zijn toezeggingen waarmaakt. Hij is tenslotte probleemeigenaar.

Tip 4: Eis assemblage om maatwerk te voorkomen

eel aanbieders willen het laten voorkomen dat uw RfP toch wel uniek is en dat daar dus ook een specifieke oplossing voor nodig is. Natuurlijk is dat onzin. Uw badkamer thuis is waarschijnlijk ook uniek. Maar toch is deze opgebouwd uit allemaal standaardcomponenten. En was het ontwerp van deze badkamer niet gewoon onderdeel van het offertetraject en dus voor u gratis? De ICT is tegenwoordig zo volwassen en gestandaardiseerd, dat u iets dergelijks ook van uw ICT-leverancier mag verwachten. Vraag daarom om een assemblagetraject. En voor alle onderdelen die de ICT-leverancier niet zelf kan leveren, trekt hij maar onderaannemers aan. De leverancier treedt op als hoofdaannemer voor de assemblage en blijft dus in alle gevallen probleemeigenaar. Zo hoort het.

Tip 5: Degradeer de algemene voorwaarden van de leverancier

Iedere insider in de ICT-business weet, dat de FENIT-voorwaarden of tegenwoordig de modelvoorwaarden van ICT-office een wurgcontract zijn voor de klant. Want in die algemene voorwaarden staat letterlijk vermeld, dat opgegeven levertijden de leverancier niet binden en steeds slechts een indicatief karakter hebben. De afgegeven ‘garantie’ komt er in het kort op neer, dat de leverancier er niet voor instaat dat de aan cliënt ter beschikking gestelde programmatuur geschikt is voor het feitelijke en/of beoogde gebruik door cliënt. Evenmin garandeert de leverancier volgens de voorwaarden dat de programmatuur zonder onderbreking, fouten of gebreken zal werken of dat steeds alle fouten en gebreken worden verbeterd.
Op basis hiervan een contract tekenen betekent, dat u dus als klant de probleemeigenaar bent. Waarschijnlijk heeft u zelf geen inkoopvoorwaarden voor ICT-diensten. Dat is ook niet nodig, wanneer u van de contractopbouw een hiërarchie maakt. Van onder naar boven is deze als volgt:

• de algemene voorwaarden van de leverancier;
• de offerte van de leverancier;
• de RfP;
• het service level agreement van de leverancier;
• de actuele service offerings  van de leverancier;
• een A4 waarop aanvullende afspraken staan.

Een dergelijke contractopbouw is fair voor u, maar ook voor de leverancier, en voorkomt dat uw project uiteindelijk mogelijk in de rechtszaal eindigt. Geef wel direct in uw RfP aan, dat u deze hiërarchie eist en controleer in de aanbieding van de leverancier, dat hij hiermee akkoord gaat. (Zie ook ‘Tips voor een begrijpelijk SLA of ICT-contract’.)

ip 6: Eis een standaardimplementatie

Elke methode voor de ontwikkeling van ICT-middelen start met een gebruikersonderzoek om alle eisen en wensen boven tafel te brengen. Dat klinkt zeer klantvriendelijk, maar is in feite een doeltreffende aanpak om u weer probleemeigenaar te maken. Want als al die geïnventariseerde eisen en wensen in kaart gebracht zijn, dan zult u meestal uitkomen op iets dat niet consistent is en vaak te ambitieus en doorgaans niet voldoet aan uw doelstellingen. Het betekent vaak een aanzienlijke hoeveelheid meerwerk. In die eisen en wensen zult u dan dus weer moeten snoeien. Illustratief voor deze  aanpak is het artikel ‘ERP selectie en implementatie: eerst van een muis een olifant maken en daarna omgekeerd’.
Eis dus een standaardimplementatie voor de oplossing die de leverancier heeft aangeboden. U heeft hem niet voor niets probleemeigenaar gemaakt voor de werking van deze oplossing. Wijs daarom 1 tot 3 mensen aan, die namens uw organisatie de input verzorgen en regel hun beschikbaarheid. En zie er nauwlettend op toe, dat uw muis niet uitgroeit tot een olifant.
Nadat uw organisatie een aantal maanden met de nieuwe oplossing heeft gewerkt, zijn medewerkers eraan gewend en hoeft u alleen de echte fouten nog te verbeteren. Natuurlijk is dat meerwerk, maar het kost aanzienlijk minder dan de exercitie van de muis en de olifant.

Tip 7: Schrap zoveel mogelijk projectmanagement

In de meeste aanbiedingen zit nogal wat overhead verwerkt, die u niet nodig heeft. Denkt u hierbij vooral aan projectmanagement. He is zeker het geval als er ook nog trots wordt vermeld, dat er een projectaanpak is volgens Prince2. Prince2 gaat ervan uit, dat de opdrachtgever de probleemeigenaar is en dat dit vooral zo moet blijven. De aanpak helpt tips zoals in dit document vermeld, vaak om zeep. Het werk van een projectleider houdt doorgaans weinig meer in dan het werk van een gemiddelde secretaresse en omvat: aanspreekpunt zijn , overleg voeren, relatiebeheer, agendabeheer en administratieve afhandeling. Grotendeels zijn dit interne processen van de leverancier zelf. U hoeft die natuurlijk niet dubbel te betalen. U betaalt tenslotte al mee aan de overhead van de leverancier via zijn marge op de opdracht. Bovendien zal een projectleider er vooral voor zorgen, dat zijn organisatie niet de probleemeigenaar wordt. Gelukkig heeft u dat goed geregeld,  maar desondanks zal de projectleider steeds weer proberen het probleem terug te schuiven naar u. Dat u voor deze acties niet wilt betalen, is evident.
Natuurlijk is het dan wel nodig, dat u zelf uw inkoper als uw projectleider op het project zet. Die zorgt, dat u krijgt wat afgesproken is en dat onnodig meerwerk wordt voorkomen. Het moet iemand zijn, die zich vooral bewust is van allerlei onvolwassenheden die binnen de ICT-dienstverlening normaal gevonden worden en die er voor zorgt, dat u daar niet de dupe van wordt. Verder moet hij inhoudelijke genoeg verstand van zaken hebben om snel te zien dat de ICT-leverancier bezig is te verdwalen en dit signaleren. En bovenal moet hij ervoor zorgen, dat u geen probleemeigenaar wordt.

Wat leveren deze tips u op?

Uiteraard zijn deze tips altijd bruikbaar voor u als opdrachtgever, ook als u weinig afweet van ICT. U kunt er al snel 10-20% mee besparen op de aangeboden dienstverlening. Het naar voren schuiven van een professionele inkoper, die snapt hoe de ICT-business in elkaar zit, heeft pas zin, als het om een project gaat van € 75.000,- of meer. Zo iemand moet dan in staat zijn om besparingen van 30-40% te realiseren. Want juist zo’n professionele inkoper kan ervoor zorgen, dat u niet minder krijgt dan wat u wilt, maar vooral ook niet meer en dat u dus ook niet meer betaalt dan nodig is. Ook zorgt hij voor een goede relatie met de ICT-leverancier. Hij schrapt in het aanbod, maar niet in de marge van de leverancier. De leverancier kan dus nog steeds aan het project verdienen, tenzij hij een wanprestatie levert. Want de kosten om dat te reparen kunnen niet aan u worden doorbelast, wanneer u niet de probleemeigenaar bent. En dat is, waarop die inkoper altijd verdacht is, ook al maakt de leverancier gebruik van zijn trukendoos.

Download:       

No related posts.

Laten we het eens vergelijken met uw auto. Die is niet specifiek voor u gemaakt, maar u kunt wel zelf bepalen hoe hard u ermee rijdt en wat u in uw handschoenenkastje stopt. Hetzelfde geldt voor de CD-speler die u misschien in uw auto heeft. Welke CD’s en dus welke muziek u daarmee beluistert, kiest u ook zelf. Waarschijnlijk hebt u een standaardrouteplanner, maar uw bestemming bepaalt u zelf. Ook de spiegels zijn natuurlijk standaard, maar ze kunnen voor iedere bestuurder versteld worden. Tenslotte zijn er de motor en de carrosserie. Die zijn ook standaard, maar die moeten vooral degelijk en betrouwbaar en vooral niet flexibel zijn.

Wanneer wel en wanneer geen ERP?

Ook in uw organisatie zijn er onveranderlijke, stabiele processen en informatieverzamelingen die betrouwbaar en voorspelbaar moeten zijn. Meestal bevinden deze processen zich in de backoffice. Een voorbeeld is het financiële proces. Processen in de frontoffice moeten beweeglijker zijn. U bent immers klantgericht en u wilt uw klant graag bedienen. En natuurlijk wilt u ook efficiënt zijn. U biedt dus een standaardbasisproces aan, dat flexibel aangepast kan worden aan de behoeften van de klant. Vergelijk het met die spiegels, routeplanner enzovoort van uw auto, die steeds aan de bestuurder aangepast kunnen worden.
Veel bedrijven proberen echter ook flexibele processen en informatieverzamelingen in hun ERP te stoppen. Ze komen er dan achter dat het ERP-systeem toch echt van graniet is. Leveranciers en consultants denken misschien dat ze als een kunstenaar kunnen omgaan met graniet. Maar dat blijkt meestal een illusie. (Zie ook ‘ERP selectie en implementatie: eerst van een muis een olifant maken en daarna omgekeerd’.) Als u flexibiliteit in uw ERP wilt stoppen is het alsof u de buitenspiegel van uw auto, die toch flexibel moet zijn, in een stand dwingt die u zelf niet meer kunt veranderen zodra u eenmaal voor die stand heeft gekozen. Vanaf dan moet u met die bepaalde stand verder leven. De spiegel met veel kracht bijstellen leidt er toe, dat deze gewoon afbreekt. Gevolg: frustratie en nog meer extra kosten. Alleen de leverancier kan er nog voor zorgen dat uw buitenspiegel anders wordt ingesteld.

Bedrijfssoftware: geen ERP maar een platform

Veel ERP-leveranciers pretenderen een bedrijfsoplossing te bieden. Hoewel de functionaliteit van hun oplossing dan misschien wel toereikend is, is deze totaal onbruikbaar voor processen die flexibel moeten worden ingericht. Veel ERP-systemen hebben bijvoorbeeld een projectenmodule. Er is echter geen projectleider die er soepel mee kan omgaan. Zo’n module moet u dus niet willen.
Kies daarom niet voor een ERP-systeem, maar voor een platform waar verschillende soorten software moeiteloos geïntegreerd kunnen worden. En niet het ERP-systeem maar het platform dient centraal te staan. Voorbeelden van zulke platforms zijn Oracle, Microsoft en Google Apps. In het artikel ‘Architectuur rondom ERP-software’ wordt dit verder uitgewerkt. Binnen dit platform kiest u de specialistische tools die tegemoetkomen aan uw wensen en eisen, ook met betrekking tot flexibiliteit en aanpassingsgemak. ICT is er tenslotte voor de gebruikers en niet voor de ontwerpers en de beheerders. Die horen op de achtergrond te werken aan dit bedrijfsmiddel, dat gebruikers in staat moet stellen om topprestaties te leveren. (Zie ook ‘Wie verlost bedrijven van hun ICT-ers’.) Zo is het toch ook geregeld met bijvoorbeeld uw wagenpark?
ICT’ers moeten oplossingen brengen en niet specificaties halen. Zij zijn de specialisten in software en hardware en zij moeten weten, dat je geen bromfietsmotor in een vrachtauto moet stoppen en omgekeerd, als u dit mogelijk in uw onwetendheid zou vragen. U mag verwachten dat zij een standaardproduct zodanig assembleren, dat u het zelf flexibel kunt inregelen op uw behoeften. Net als die spiegels, die routeplanner en die CD-speler van uw auto.

Waarvoor gebruikt u uw ERP-systeem wel?

Laten we eens een redelijk doorsnee bedrijf in Nederland nemen met tussen de 5 en 200 medewerkers, dat produceert of engineert op order. Schrik niet, ik bedoel bouwbedrijven, ICT-bedrijven, overheden, veel zorginstellingen, zakelijke dienstverleners, notarissen, service-organisaties, cateringbedrijven, ingenieursbureaus, uitzendbureaus, badkamerwinkels, klusjesmannen. Hiervan kennen we vele duizenden in Nederland. Het primaire proces verloopt als volgt:

• maken van afspraken met de klant over prijs/prestatie (al dan niet vastgelegd in een formeel contract en al of niet voorafgegaan door een acquisitie- en offertetraject);
• uitvoeren planning en eventueel inkopen van materiaal/resources;
• verantwoorden bestedingen en eventueel bijsturen planning en hierover rapporteren aan de klant;
• consolidatie in de financiële administratie.

Strikt genomen zitten hier maar een paar punten in, die in graniet gebeiteld kunnen zijn:

• de klantorder; 
• de inkooporder;
• de financiële administratie;
• de debiteuren en crediteuren bewaking.

Voor deze punten kunt u heel goed een standaardoplossing gebruiken. Maar de rest van het proces moet eenvoudig aangepast kunnen worden onder meer aan de klant, aan de omvang en de aard van de opdracht, aan de benodigde materialen en aan het feit of er wel of niet projectmanagement uitgevoerd wordt. U moet dat niet proberen onder te brengen in het ERP-systeem. Dat past alleen met veel extra inspanningen en soms met trucs, waardoor het ERP-systeem nog minder doorzichtig wordt dan het al was. U kunt dan ook het aantal gebruikers beperken en dat is mooi, want ERP-systemen staan bepaald niet bekend om hun gebruikersgemak. Bovendien heeft u minder licenties nodig en de implementatiekosten zullen lager zijn.
De specialistische tools kunt u, zoals u verderop zult zien, onderbrengen in uw Sharepoint omgeving. De informatie uit deze tools deelt u eveneens via Sharepoint. Onderstaand wordt dit schematisch weergegeven:

Veel problemen met ERP-systemen zoals bijvoorbeeld bij overheden zijn terug te voeren tot de essentiële fout dat men flexibele processen in een ERP-systeem wil stoppen. Alleen een zuiver productiebedrijf zoals een bedrijf voor massaproductie of een pretpark kan zonder problemen meer zaken in zijn ERP-systeem stoppen.

Hoe omgaan met de processen buiten het ERP-systeem?

De processen die u niet in uw ERP-systeem stopt, wilt u natuurlijk ook ondersteunen met ICT. Bovendien wilt u ze aansluiten op het ERP-systeem. Om dit te realiseren is het nodig, dat u kiest voor een platform, waarbij gegarandeerd allerlei software behorend tot dat platform eenvoudig ingeplugd kan worden, zodat er geen functionaliteiten in het ERP-systeem gepropt hoeven worden.
Laten we voor het gemak uitgaan van Microsoft als platform. De meeste bedrijven in Nederland gebruiken dit toch al als belangrijk onderdeel van hun software architectuur. Uiteraard is onderstaande eenvoudig te vertalen naar andere platformen. Uitgaande van Microsoft wordt het ERP-systeem MS Dynamics AX dan wel NAV. Medewerkers in bedrijven die leveren op order hebben vaak behoefte aan informatie- en kennisuitwisseling, communicatie en afstemming, mogelijkheden tot eenvoudige registratie van gebeurtenissen en feiten. Denk hierbij aan commerciële medewerkers, baliemedewerkers, service medewerkers, projectleiders. MS office is hiervoor heel geschikt, maar dan is nog wel integratie nodig van het geheel. Binnen het Microsoftplatform is Sharepoint hiervoor het geschikte tool. Met Sharepoint kunnen informatie, processen en systemen geïntegreerd worden en u kunt er 7*24 en overal gebruik van maken. Ook biedt Sharepoint goede mogelijkheden om de data zelf te beveiligen. Meer hierover vindt u in het artikel ‘Architectuur rondom ERP-software’.
Sharepoint is op zich een lege doos waarin je verschrikkelijk veel spullen kunt stoppen. Dat is ook de belangrijkste valkuil. Het kan snel uitgroeien tot een Winkel van Sinkel. Daarom is het nodig om de processen die data uitwisselen met het ERP-systeem strak te trekken in Sharepoint door hiervoor een workflow in te richten. Dat betekent dat er inderdaad een klantorder wordt aangemaakt met een aantal verplichte velden, die ook in het ERP-systeem gebruikt worden. Voor zover beschikbaar worden deze velden door het ERP-systeem automatisch ingevuld. En de verplichte velden in Sharepoint worden na de noodzakelijke fiatteringen in de database van het ERP-systeem gezet (zonder dubbele invoer van gegevens). Alle niet verplichte documentatie rond de klantorder zoals de offerte aanvraag, de offerte, achtergrondinformatie en gesprekverslagen worden gewoon opgeslagen in Sharepoint en zijn altijd beschikbaar voor hergebruik. Ditzelfde geldt voor processen als inkooporders, urenverantwoording, verbruik van materialen en resources enzovoort.
Voor het snel en flexibel aanpassen van de workflows kan Nintex gebruikt worden, dat bovendien de status van iedere opdracht en iedere proces weergeeft en ervoor zorgt dat Sharepoint een notificatie stuurt naar de medewerker die de volgende stap in de workflow moet uitvoeren.

Wat betekent dit in de praktijk?

U ziet de bui natuurlijk al hangen. U heeft licenties nodig voor Dynamics, voor Sharepoint, voor Office, voor Nintex en vanzelfsprekend voor de laatste versies, omdat alleen die goed samenwerken. Dat gaat een vermogen kosten. Om nog maar te zwijgen over de kosten voor ICT-consultants, die dit geheel passend moeten maken voor uw organisatie. Vijf jaar geleden zou u gelijk gehad hebben. Maar de tijden zijn veranderd en ICT-diensten zijn meer volwassen geworden.
Laten we even terugkeren naar die auto. Met alles er-op-en-er-aan is die minstens zo complex als de hierboven beschreven oplossing. Toch laat u die auto niet specifiek voor uzelf bouwen. U gaat niet naar de fabriek om te kijken hoe de motor wordt gemaakt. U gaat gewoon naar de showroom en u zoekt een auto uit. U bepaalt eerst of u een vrachtauto, bestelbus, personenauto, boodschappenautootje of wat dan ook wilt hebben. U bekijkt merk en types en u kiest voor kleuren en accessoires. Dat alles in de auto samenwerkt, daar gaat u van uit. Als u de auto gekocht hebt, vult u uw handschoenenkastje met uw spullen, u stopt uw CD in de CD-speler, u zet uw bestemmingen in de routeplanner, u stelt de spiegel in op hoe u achter het stuur zit, u start de motor en rijdt weg met de door u gewenste snelheid.
Met een ICT-oplossing is het in feite net zo. Voor 95% of meer van uw bedrijfsprocessen geldt, dat deze in tig bedrijven voorkomen. Hiervoor zal dus ook vast een oplossing bestaan, zodat u proven technology kunt kopen. U kunt zelfs (deels) kiezen voor een lease-constructie via SaaS. Dan hoeft u zelfs niet te investeren en hoeft u zich niet druk te maken over allerlei facilitaire zaken. En als uw ‘auto’ een keer weigert, wordt snel ‘vervangend vervoer’ geregeld.
Het betekent wel dat uw ICT-inkoopproces totaal verandert. U koopt geen computers, software en allerlei andere spullen meer, die vervolgens specifiek voor u in elkaar gesleuteld moeten worden, maar u schaft gewoon een standaardoplossing met service aan, waarbij u leert om zelf de ‘routeplanner, de spiegels en de CD-speler’ te bedienen, zodat u die 5% die uw organisatie specifiek maakt, zelf kunt inregelen. (Zie ook ‘Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens’.)
Het betekent dat u ook verlost bent van al die consultants, die bij u de specificaties komen halen. De auto die u wilt, koopt u ook op een beeld dat u in uw hoofd heeft. Daar gaat u geen specificatie van 30 kantjes voor schrijven. De aanbieder vertelt u de eigenschappen van zijn oplossing en licht toe waarom zijn oplossing de beste is voor u. Dat verkoopverhaal neemt u natuurlijk met een korreltje zout en u laat het ook nog eens vertellen door een aantal andere aanbieders met soortgelijke oplossingen. En dan kiest u voor de beste prijs/prestatie met uiteraard de garantie dat onvolkomenheden worden opgelost door en voor rekening van de aanbieder. Alles wat u zelf moet doen is een stukje onderhoud, benzine tanken en het wassen van de auto.

Inkopen van ICT en ERP wordt belangrijk

Er zijn vele duizenden ICT-bedrijven in Nederland. Een aantal zijn volwassen, maar de meeste nog niet. Ook kunnen veel ICT-dienstverleners geen complete auto’s leveren. Ze zijn gespecialiseerd in spiegels, bumpers of de motor. Ze zijn ook niet bereid om garanties te geven, die verder gaan dan tot de deur. En voor lease-constructies zijn ze helemaal niet in. Ze willen liefst dat u betaalt voordat u in het dagelijks gebruik merkt, dat de gewenste prestatie toch niet helemaal geleverd is.
Bij de inkoop zijn er dus een aantal zaken van belang:

• een duidelijk beeld van de gewenste functionaliteit  in doelstellingen;
• inzicht in de volwassenheid van aanbieders en weten hoe dit eenvoudig getoetst kan worden;
• in staat zijn om meerdere offertes te krijgen, die vergelijkbaar zijn;
• voldoende inzicht in de markt om volwassen dienstverleners te vinden; reputaties van ICT-bedrijven zeggen zelden iets over hun volwassenheid (zie ook ‘Waarom tarieven van grote ICT-dienstverleners hoger zijn’);
• de offerte verlagen door maatwerkcomponenten te vervangen door de assemblage van flexibele standaardcomponenten;
• kennis van hoe een contract met een ICT-leverancier opgebouwd moet zijn (zie ook ‘Tips voor een begrijpelijk SLA of ICT-contract’);
• toezicht houden op de leverancier, of u inderdaad krijgt wat u afgesproken hebt.

Meestal begint inkoop met het opstellen van een korte en duidelijke RfP, die doelstellingen en knock-out criteria aangeeft en die ervoor zorgt dat ICT-aanbieders niet alleen onderling te vergelijken prijs/prestatie offreren, maar ook moeten aangeven of ze ‘proven technology’ aanbieden en ervaring hebben met de assemblage hiervan en verder dat ze voldoen aan alle gestelde eisen en wensen. In het artikel ‘Zeven tips voor het inkopen van ICT-projecten’ geven we meer best practices voor dit inkoopproces.
Een ERP systeem is dus niet meer de totaaloplossing voor uw bedrijfsautomatisering, maar wel de betrouwbare motor in het geheel. En natuurlijk moet die motor zoveel mogelijk onzichtbaar blijven onder de motorkap.

Download:       

No related posts.

In dit artikel geven we u een aantal tips hoe u een goede overeenkomst kunt sluiten met uw ICT-leverancier. We hanteren daarbij een aantal uitgangspunten die gelden voor 90% van alle contracten die afgesloten worden:

• U heeft geen uitgebreide inkoopvoorwaarden voor het inkopen van ICT-diensten.
• U heeft niet de inkoopmacht van een marktleider of de centrale overheid.
• U heeft er geen behoefte aan om geschillen voor de rechtbank uit te vechten.
• U wilt krijgen waaraan u behoefte heeft, tegen een faire prijs.
• ICT is voor u geen core-business is.

Hoewel deze uitgangspunten dus gelden voor verreweg de meeste contracten, is het toch zo dat u bij de inkoop van ICT-diensten gemakkelijk het kind van de rekening wordt, als u niet uitkijkt. We willen u met deze tips daarom helpen u juridisch de positie van klant te geven. Dit kan voorkomen dat u uitgebreid moet investeren in juridisch advies en ook dat de leverancier u toch weer tot de probleemeigenaar maakt die u niet wilt zijn. (Zie ook ‘Zeven tips voor het inkopen van ICT-projecten’.)

Koop geen product maar een dienst

U weet ongetwijfeld, dat de grootste kostenpost van uw ICT niet de investeringen zijn, maar dat dat juist het beheer is. Neemt u daarom bij voorkeur geen producten af, maar diensten. Die diensten zijn dan vaak SaaS-oplossingen, waarbij u slechts betaalt voor het gebruik. (Zie ook ‘SaaS is voor de gebruiker meer dan alleen stroom uit het stopcontact ’.) De leverancier blijft dan probleemeigenaar, mits u dit contractueel goed regelt. Meestal is dat niet zo complex. In de meeste gevallen echter, levert een leverancier zijn product (al dan niet inclusief de implementatie) en biedt daarbij het beheer aan als add-on. Hij noemt dat waarschijnlijk een managed service. Maar het komt erop neer dat u de probleemeigenaar wordt. Uiteraard moet u dat vermijden. Koop daarom een dienst die past op uw behoefte en stel de aanbieder verantwoordelijk voor de beschikbaarheid van deze functionaliteit met in begrip van uw vanzelfsprekende behoeften. Verrassend is, hoe weinig ICT-aanbieders na het sluiten van een deal de mening van hun klant delen over wat vanzelfsprekend is, laat staan dat hun SLA het weergeeft zoals de klant het had verwacht.

Een overeenkomst is een hiërarchie van contracten

Als u een dienst koopt, zult u zich goed moeten realiseren dat het vooral ook gaat om een dienst en niet alleen om een product. De overeenkomst met uw leverancier moet leiden tot een partnership. U besteedt tenslotte het beheer van een belangrijk bedrijfsmiddel uit aan een derde partij. Dit is overigens niet gek, want uw nutsvoorzieningen, uw infrastructurele voorzieningen en uw wagenpark koopt u immers ook op die manier in. Waarom dus ook niet uw ICT? (Zie ook ‘ICT en functioneel beheer steeds meer logistieke processen’.)
In de overeenkomst moeten dus in ieder geval twee zaken worden vastgelegd: de oplossing die u koopt en de wijze waarop deze oplossing na de implementatie beheerd gaat worden. De oplossing legt u vast middels drie reeds bestaande documenten:

• uw RfP;
• de definitieve offerte van de leverancier;
• de algemene voorwaarden van de leverancier.

Algemene voorwaarden

De algemene voorwaarden zijn onvermijdelijk en vormen een bescherming voor de leverancier. Deze algemene voorwaarden voor ICT-bedrijven zijn vaak afgeleid van het modelcontract van de branchevereniging. Dat is de reden dat u er nooit zonder meer mee akkoord moet gaan. Want plat gezegd staat in die voorwaarden dat de leverancier niet hoeft te leveren wat is afgesproken, dat dit ook niet op tijd hoeft te gebeuren en dat de klant altijd moet betalen, ook al is er sprake van een wanprestatie. Daarnaast staan er ook nog een groot aantal redelijke bepalingen in. Ga geen ingewikkeld juridisch proces in door artikelen te schrappen of te wijzigen in deze voorwaarden. In de RfP en de offerte staat immers de afgesloten deal weergegeven. Zet deze deal in de hiërarchie een niveau hoger. Voor alles wat niet in de RfP of de offerte is beschreven gelden dan de algemene voorwaarden.

Offerte

In de offerte staat beschreven wat de leverancier precies levert. Meestal in termen zoals de leverancier deze hanteert en redelijk onbegrijpelijk voor de klant. Dat is niet erg, zolang er in elk geval maar twee zaken goed geformuleerd zijn:

• de bevestiging dat met de offerte aan alle eisen en wensen uit de RfP van de klant wordt voldaan; eventueel mogen afgesproken uitzonderingen toegevoegd worden;
• een fixed-price aanbod; dit aanbod is inclusief het werk, dat eventueel uitbesteed wordt aan onderaannemers; de aanbieder is tenslotte uw single-point-of-contact voor de oplossing.

Natuurlijk is het mogelijk, dat via een wijzigingsprocedure afgeweken wordt van de offerte. Deze wijzigingen dienen dan wel te worden geaccordeerd door u als klant. Uitloop van werkzaamheden bij de leverancier die niet veroorzaakt worden door een aanpassing in de eisen en wensen, kunnen dus niet tot meerwerk leiden. Als de leverancier bewijst een goede partner te zijn en met u op de kosten let door vereenvoudigingsvoorstellen te doen en door zijn onderaannemers goed te managen, wees dan niet te kinderachtig als de leverancier aangeeft toch een overschrijding te hebben. In samenwerking kunt u tenslotte meer kosten besparen dan alleen. Bovendien komt dit de relatie ten goede. Leg wijzigingen echter wel vast.

Request for Proposal (RfP)

De RfP gaat vaak ten onder in het meestal door de leverancier gedomineerde traject van contracteren. Dat is echter geheel ten onrechte. In dit document liggen tenslotte uw behoeften vast in termen van eisen en wensen, meest op doelstellingen niveau. Ook liggen hierin de knock-out criteria vast. U eist van de leverancier dat hij in zijn offerte bevestigt, dat hij voldoet aan de eisen en wensen uit de RfP. de RfP hoort dus in de hiërarchie boven de offerte te staan.

Service level agreement (SLA)

In het service level agreement wordt de dienstverlening beschreven, nadat de implementatie heeft plaatsgevonden. Het SLA is dus het tweede deel van de overeenkomst. Ook het SLA is vaak een ellenlange opsomming van procedures en services die niet de moeite waard zijn om serieus te bekijken. In die zin is het document vergelijkbaar met de algemene voorwaarden. Ook het SLA is er weer op gericht, dat u probleemeigenaar wordt. Maar dat wilt u niet. Dus ook nu weer moet u niet trachten allerlei zaken te wijzigen. Eis echter, dat een hoger niveau in de overeenkomst een A4-tje betreft, waarin belangrijke afspraken zijn vastgelegd. U heeft dat uiteraard al gedaan in de Rf. Deze afspraken moeten nu geëffectueerd worden. In het A4-tje worden de afwijkende afspraken vastgelegd, die meestal betrekking hebben op een aantal aandachtspunten. We zullen deze met u doornemen.

Startdatum onderhoudscontract

Softwareleveranciers als Microsoft eisen, dat het onderhoudscontract ingaat zodra de software is aangeschaft. Daar kan uw leverancier weinig aan veranderen. Hij kan echter tijdens de ontwikkeling wel gebruik maken van eigen licenties. Pas na acceptatie van de oplossing schaft u dan formeel de software zelf aan. U hoeft dan dus niet een aantal maanden voor niets te betalen.

Incidentafhandeling

Er is sprake van een incident, als u constateert dat de dienstverlening niet voldoet aan de afspraken. Uiteraard is dat het geval als er storingen zijn. Maar ook wanneer nieuwe versies van de software worden geïmplementeerd. De kosten van de incidentafhandeling horen gedekt te worden door het onderhoudscontract of door de kosten van de dienst bijvoorbeeld bij outsourcing. Vaak worden er in het contract reactietijden genoemd. Daar heeft u echter niets aan. Het kan dan nog steeds dagen duren voordat de dienstverlening is hersteld. Waar het u om gaat, is de beschikbaarheid van de dienst. Een redelijk percentage hiervoor is 99,8% tijdens werkuren (dit betekent een dagdeel downtime per jaar tijdens werkuren) en een percentage van 99,0 tot 99,5 buiten werktijden (dit is 300-600 uur buiten werktijd). Eventueel kunnen er afwijkende afspraken gemaakt worden, als de aard van het incident wordt meegenomen, met bijvoorbeeld classificatie als:

• 50% of meer van de gebruikers is aanzienlijk minder productief;
• 5-50% of van de gebruikers is aanzienlijk minder productief;
• minder dan 5% van de gebruikers is aanzienlijk minder productief.

Additioneel voordeel van een beschikbaarheidsclausule is, dat u in geval van calamiteiten bij de leverancier zelf geen uitwijk hoeft te regelen. Dat is dan het probleem van de leverancier. Eis is wel dat de leverancier u te allen tijde binnen 24 uur over al uw data moet kunnen laten beschikken. (Zie ook ‘Outsourcing contracten dekken zelden de business continuity van de klant af ’.) Spreek dus wel tevoren een boeteclausule af. Ook hierbij geldt, dat deze zo moet worden ingeregeld, dat u er waarschijnlijk nooit gebruik van hoeft te maken.
Het is niet genoeg als de leverancier aangeeft, dat hij ITIL toepast. Juist de zaken die hierboven zijn beschreven, worden niet door ITIL afgedekt.
Als u verandering in de dienstverlening wenst, dan is er sprake van een wijzigingsvoorstel en dat komt uiteraard wel voor uw rekening. Vraag van te voren wel een wijzigingsvoorstel met een prijsopgave.

Service offerings

Als u een dienst afneemt in de vorm van outsourcing, dan is het vaak zinvol om boven het niveau van het statische SLA nog een niveau van dynamische service offerings te hangen. Voordelen hiervan zijn:

• Als de leverancier additionele diensten ontwikkelt, kunnen deze marktconform toegevoegd worden aan de dienst. Omgekeerd kan de klant per jaar diensten opzeggen, zodat de kosten van het SLA ook daadwerkelijk verminderen.
• Prijzen worden aangepast aan wat fair is.

A4 met afspraken

Het hoogste niveau in de overeenkomst wordt gevormd door het eerder genoemde A4-tje. Zorg dat dit altijd kort en bondig blijft. Op dit A4-tje staan in ieder geval vermeld:

• de eisen en wensen uit de RfP, die betrekking hebben op de service na implementatie;
• de bovengenoemde aanvullingen op het SLA;
• de geaccepteerde service offerings;
• de geaccordeerde wijzigingsvoorstellen

Partnership is meer dan een contract

Het genoemde  A4-tje is het belangrijkste document van de overeenkomst. Het is ook de basis voor partnership tussen klant en leverancier. Er kunnen ook afspraken in worden vastgelegd die juridisch niet kunnen, maar die tussen partners wel gemaakt kunnen worden. Want samenwerken betekent ‘met elkaar geld verdienen’ en niet ‘van elkaar geld verdienen’. Van te voren is nog niet alles te voorspellen. Daarom moet de overeenkomst flexibel zijn en fair naar beide partijen, en zodanig dat wederzijds geprofiteerd kan worden van voortschrijdend inzicht.
Waar het omgaat is het spel dat tijdens het inkoopproces wordt gespeeld. Misschien dat uw bedrijfsjuristen er anders over denken, maar dat is belangrijker dan het contract. In het SLA of het contract wordt het speelveld van de samenwerking beschreven, maar dat vormt maar een klein onderdeel daarvan. (Zie ook ‘Zeven tips voor het inkopen van ICT-projecten’.)

Download:       

No related posts.

1. De scope van uw Business Continuity Plan
2. Geen preventie maar repressie
3. De afbakening van het calamiteitenplan of BCP
4. Stappenplan voor het opstellen van een BCP
5. Resultaten van een Business Continuity Plan
6. Risicoacceptatie door de directie 

1. De scope van uw Business Continuity Plan

Het grootste probleem bij het opstellen van een Business Continuity Plan of calamiteitenplan is voor veel bedrijven: ‘How to get started?’. In feite kan bij een procesmatige benadering de totale bedrijfsvoering worden meegenomen in het plan en als men uitgaat van de mogelijke dreigingen, dan kan men ook weer het hele bedrijf tegenkomen. Maar dat moet worden voorkomen. Als het afdekken van een risico al is belegd in de organisatie, moet dat niet meer worden meegenomen in het Business Continuity Plan. (Zie ook: ‘Business Continuity of plan bedrijfscontinuïteit: Doe effe normaal’.) Zo vormen bijvoorbeeld de debiteuren het belangrijkste risico voor een faillissement van een bedrijf. Doorgaans echter is het debiteurenrisico al belegd. U zult daarom dus eerst keuzes moeten maken over wat wel en wat niet door uw Business Continuity Plan afgedekt moet worden. 

Laten we als eerste stap het begrip calamiteit of crisis maar eens definiëren. 

1.1 Definitie van een calamiteit of crisis

Wij hanteren de volgende definitie van een calamiteit of een crisis: 

Een calamiteit of crisis is een gebeurtenis die de bedrijfsvoering zodanig in gevaar kan brengen, dat daadoor de bedrijfscontinuïteit in gevaar komt. 

Het gaat bij business continuity dus niet om de calamiteit zelf, maar om het effect dat een calamiteit heeft op de bedrijfsvoering, met meestal als belangrijkste issues, dat een bedrijf zijn leveringsverplichtingen niet kan nakomen of een zodanige imagoschade oploopt, dat dit tot verlies van klanten en/of inkomsten leidt.
De directe schade van calamiteiten als bijvoorbeeld brand is vaak wel verzekerd, maar de indirecte schade als het niet meer kunnen leveren conform afspraak, waardoor inkomsten misgelopen worden, is meestal onverzekerbaar. Daarom kijken we naar de risico’s van de effecten van een calamiteit.
In het artikel ‘Inventarisatie diensten, dreigingen en processen in uw Business Continuity Plan BCP’ werken we uit hoe u de dreigingen voortvloeiend uit calamiteiten in kaart kunt brengen, zonder dat u daarbij genoodzaakt bent alle calamiteiten en de kans dat zij zullen optreden te analyseren.  

2. Geen preventie maar repressie

Het Business Continuity Plan richt zich, in tegenstelling tot informatiebeveiliging, niet op preventieve maar op repressieve maatregelen, en wel om twee redenen: 

• De kans dat een calamiteit niet optreedt is veel groter dan de kans dat die calamiteit wel optreedt. De investeringen in preventieve maatregelen zijn dan ook vrijwel altijd weggegooid geld.
• Een gebeurtenis die leidt tot een calamiteit kan zich op een bijna oneindig aantal manieren voordoen. Zo’n gebeurtenis voorkomen via preventieve maatregelen is dan ook nagenoeg onbegonnen werk. De effecten van zo’n gebeurtenis zijn daarentegen veel beter voorspelbaar. Een goede set aan repressieve maatregelen kan voorkomen, dat een ramp uitgroeit tot een bedreiging voor de bedrijfscontinuïteit.

Natuurlijk is het ‘einde oefening’ als er tijdens kantooruren een vliegtuig landt op uw bedrijfsgebouw. Helaas kunt u zoiets niet voorkomen. U moet zich daarover dan ook niet druk maken. De keerzijde van de medaille is, dat een Business Continuity Plan veel eenvoudiger is dan het op het eerste gezicht lijkt. In het artikel ‘Business continuity in de industrie, groothandel en distributie’ wordt hiervan een aantal voorbeelden gegeven.  

3. De afbakening van het calamiteitenplan of BCP

Voor de afbakening van een calamiteitenplan geldt over het algemeen de volgende vuistregel: 

Tot het BCP behoren alleen die zaken die gericht zijn op het adequaat kunnen reageren op een calamiteit. 

De dreiging van een hoge boete voor het niet tijdig rapporteren aan de belastingdienst of aan toezichthouders lost u niet op via een scenario voor wat u in een voorkomend geval moet doen. U zorgt voor preventieve maatregelen in de lijnorganisatie, waarmee te late rapportage wordt voorkomen. Hetzelfde geldt voor een service desk van een ICT-afdeling. Het oplossen van een incident, eventueel na escalatie naar de tweede- of derdelijns support, behoort tot de reguliere bedrijfsprocessen van de IT-afdeling. Pas als een tijdige oplossing van het incident niet mogelijk is, kan besloten worden dat er sprake is van een calamiteit. Op dat moment is de oplossing van het incident niet meer het issue, maar het herstel van de dienstverlening aan de klant volgens een noodscenario met uitwijk voor de functies die vanwege het incident zijn geblokkeerd,  waardoor dus de afgesproken dienstverlening onmogelijk is geworden. 

Figuur1: Onderscheid 'oorlogstijd' - 'vredestijd'

We maken daarom onderscheid tussen ‘oorlogstijd’ en ‘vredestijd, zoals in bovenstaand plaatje is weergegeven. Het rechter deel van het plaatje behoort inclusief escalaties tot het gewone bedrijfsproces en is van toepassing in ‘vredestijd’. Alleen het linker deel hoort thuis in het Business Continuity Plan en is van toepassing in ‘oorlogstijd’.
Op dit punt zijn regeringen van ons land geregeld de mist in gegaan. Vaak is  beleid in hoge mate gericht op preventie en ontbreekt het onderscheid tussen oorlogstijd en vredestijd. Het gevolg is dan, dat verantwoordelijkheden en bevoegdheden van allerlei instanties door elkaar lopen, daar deze in oorlogstijd anders geregeld zijn dan in vredestijd.  

4. Stappenplan voor het opstellen van een BCP

Grofweg kan het opstellen van een BCP uitgevoerd worden volgens de volgende fasen en stappen: 

Fase 1 

1. intake met een vertegenwoordiging van de directie of de stuurgroep om het ambitie niveau, de belangrijkste dreigingen, de risicoacceptatie en de voorkeuren voor oplossingsrichtingen vast te stellen;
2. het in kaart brengen van de hoofdlijnen voor wat betreft kritische diensten en processen, dreigingen (single points of failure) en uitwijkmogelijkheden;
3. presentatie van de plannen en de globale risicoanalyse in een kick-off meeting, waarbij een definitieve afbakening wordt vastgesteld.

Een toelichting op de uitvoering van deze fase 1 wordt gegeven in het artikel  ’Inventarisatie diensten, dreigingen en processen in uw Business Continuity Plan BCP’. 

Fase 2 

1. inventarisatie van kwetsbaarheden op afdelingsniveau, deels via interviews en deels via vragenlijsten;
2. analyse van relevante processen en procedures en het vaststellen en accorderen van maatregelen;
3. evalueren uitwijkplan ICT en het zo nodig aanvullen hiervan;
4. invullen draaiboek met bijlagen en opstellen implementatieplan en de inbedding van het proces in de organisatie;
5. presentatie concept BCP aan de directie of de stuurgroep.

Een toelichting op de uitvoering van deze fase 2 wordt gegeven in het artikel ‘Voorbeeld plan van aanpak fase 2 van uw Business Continuity Plan BCP of calamiteitenplan’.  

5. Resultaten van een Business Continuity Plan

Het Business Continuity Plan moet de volgende resultaten opleveren: 

Figuur2: Resultaten Business Continuity Plan

Dat wil dus zeggen:

• een draaiboek dat geldt in ‘oorlogstijd’ met diverse scenario’s;
• een implementatieplan waarin beschreven staat welke eenmalige en structurele acties er in ‘vredestijd’ nodig zijn om er voor te zorgen, dat het draaiboek in oorlogstijd werkt;
• een uitwijkplan voor de ICT-voorzieningen, ook wel calamiteitenplan of contingency plan genoemd.
  Vaak wordt dit plan apart opgesteld, omdat veel calamiteiten zich veelal uitsluitend beperken tot de dienstverlening van de ICT-afdeling. 

6. Risicoacceptatie door de directie

Nadat in fase 1 de risicogebieden en de diensten en processen in kaart gebracht zijn, wordt dit geheel gepresenteerd aan de directie. (Zie ook ‘Inventarisatie diensten, dreigingen en processen in uw Business Continuity Plan BCP’.)
Met betrekking tot de dreigingen wordt op twee punten de directie om goedkeuring dan wel aanpassing gevraagd: 

• de inschatting van de ernst;
• de beoordeling of er actie nodig is.

Als de directie de ernst van een dreiging laag inschat en zij bij ontbreken van een uitwijk oordeelt dat geen actie nodig is, dan betekent dit, dat zij dit risico accepteert.
Als het gaat om de diensten en de processen wordt vooral gekeken of het risicomanagement hiervan eventueel al in de organisatie is belegd of dat het een onderdeel van het Business Continuity Plan gaat vormen. Op deze manier kan worden voorkomen, dat straks in het kader van dit project alles binnen de organisatie onder de loep genomen wordt. Vervolgens kan dan gericht het onderzoek in de organisatie voortgezet worden. Een plan voor de uitvoering van deze fase 2 wordt gegeven in ‘Voorbeeld plan van aanpak fase 2 van uw Business Continuity Plan BCP of calamiteitenplan’.
De grootste valkuil is dus, dat u niet eerst de scope van het BCP bepaalt of dat u zich gaat richten op het voorkomen van een calamiteit. Dat kan ertoe leiden dat uw project een veelkoppig monster wordt, waarvoor hoge budgetten gealloceerd moeten worden, die waarschijnlijk weggegooid geld zijn. Natuurlijk heeft u wel een BCP nodig, bestaande uit een draaiboek en uit een implementatieplan dat er voor zorgt dat de draaiboeken up-to-date blijven. In de Cursus Business Continuity Management leggen we u uit, hoe u dit slim kunt aanpakken. 

Herziene versie: 29 april 2010

Download:       

No related posts.

1. Volwassenheid van de ICT
2. ICT als geldverslindend monster
3. De ICT als service center
4. Outsourcing als reddingsboei

1. Volwassenheid van de ICT

Al decennia lang houden ICT-goeroes zich bezig met modellen die de volwassenheid van de ICT beschrijven. Deze modellen zou u als ICT-organisatie als een soort TomTom kunnen gebruiken om uw toekomststrategie te bepalen. Maar  is dat zo? Wat doet een navigatiesysteem eigenlijk? Het leidt u alleen maar naar de bestemming die uzelf invoert. Daar komt bij dat volwassenheid van de ICT op zich geen doel kan zijn, en al helemaal niet de weg.
Als ICT-organisatie verleent u primair een dienst. Uw proces van dienstverlening kan wel volwassenheid bezitten. Maar de competenties, de processen en de middelen die u nodig heeft voor dit leveringsproces zijn hierbij niet het uitgangspunt. Uitgangspunt is de toegevoegde waarde die u levert aan uw afnemer. (Zie ook ‘De economische waarde van kennis daalt steeds sneller’.) Competenties vormen een grondstof voor uw dienstverlening. En u kunt kiezen of u deze grondstof in voorraad wilt hebben of dat u deze ‘just in time’ geleverd wilt krijgen op het moment waarop u er behoefte aan heeft. Opleiden van uw eigen medewerkers is vaak weggegooid geld. Certificatie van medewerkers verhoogt alleen hun persoonlijke waarde en dus de kosten voor de afnemer, als hij gebruik wil maken van een stuk kennis die bij iedere ICT’er standaard gewoon aanwezig hoort te zijn. Uw klant is ook helemaal niet geïnteresseerd in kennis of certificaten. Hij is geïnteresseerd in de toegevoegde waarde van uw diensten (de prijs/prestatie die hij koopt). Hij is ook niet geïnteresseerd in de wijze waarop u het leveringsproces inricht. Hij wil geen beheerdiensten kopen. Hij wil gewoon een bruikbaar ICT-landschap, dat werkt! (Zie ook ‘ICT-bedrijven zijn uitblinkers in het leveren van onprofessionele services’.)

2. ICT als geldverslindend monster

Voor de gebruiker is ICT niet meer dan een bedrijfsmiddel dat hij nodig heeft om zijn werk te doen. ICT moet hem adequate ondersteuning bieden tegen minimale kosten  en ICT is alles wat zich afspeelt achter het beeldscherm van zijn werkplek. Hij wil niet weten wat er nodig is voor de levering van een ICT-dienst. ICT moet een intelligente nutsvoorziening zijn, die hij naar behoefte kan gebruiken. (Zie ook ‘SaaS is voor de gebruiker meer dan alleen stroom uit het stopcontact’.)
In het verleden werd ICT echter nooit op deze manier aangeboden. Zoals in de zorg de patiënt alleen maar verrichtingen kan kopen en niet het gewenste product ‘gezondheid’, zo kon men op het gebied van de ICT alleen maar resources kopen of huren, maar geen ICT. Net als de zorg is de ICT-dienstverlening daardoor een geldverslindend monster geworden. De discussie in de zorg gaat alleen over kosten en inkomsten van de zorgaanbieder (het middel om gezondheid te behouden) en niet over de kosten en de toegevoegde waarde voor de patiënt. Klantgerichtheid bestaat niet. Er bestaat alleen klantvriendelijkheid voor patiënten die pijn hebben. (Zie ook ‘Klantgerichtheid fopspeen van veel non-profit organisaties en dienstverleners’.) Iets dergelijks geldt ook voor ICT-dienstverleners. Zij zijn ‘cost centers’, vaak nog zeer onprofessionele ook. Dit zonder gevolgen. Want in feite is er toch sprake van gedwongen winkelnering.

3. De ICT als service center

Als we het dus willen hebben over de volwassenheid van ICT-aanbieders, dan zullen we het perspectief van de gebruiker als afnemer moeten kiezen.
De stappen naar volwassenheid worden weergegeven in het volgende schema:

Voor de meeste interne en externe ICT-organisaties geldt, dat zij zich bevinden in het eerste stadium, waarbij ze hun best doen om door te groeien naar het tweede stadium. Er wordt vooral aandacht besteed aan interne zaken zoals onder andere ITIL, procedures, hulpmiddelen, doorbelasting, competentiemanagement, processen, enzovoort. Belangrijkste doelstelling daarvan is, dat de toegevoegde waarde voor de gebruiker als afnemer wordt vergroot.
De aanname echter, dat een ICT-dienstverlener een cost center is, dat zelf in staat moet zijn om ICT-diensten te leveren, is een grote misvatting. De genoemde verbeteringen zijn misschien wel verdedigbaar als een ICT-organisatie groot genoeg is en voldoende schaalgrootte heeft om de investeringen in deze interne processen terug te verdienen, maar de meeste ICT-organisaties hebben deze schaalgrootte niet. Per saldo betekent het dan voor de afnemer, dat voor hetzelfde service level de kosten hoger worden.
Waar gebruikers behoefte aan hebben is, dat de ICT-dienstverlener zijn diensten levert op basis van het derde stadium, waarbij geldt dat competenties en infrastructuur geen noodzakelijke assets (bezit) zijn van de ICT-organisatie, maar grondstoffen die op het goede moment op de goede plaats in de goede hoeveelheid en vorm beschikbaar zijn.
Kortom, het is een logistiek vraagstuk. In feite is een ICT-dienstverlener niet meer dan een logistieke dienstverlener, die zichzelf de vraag moet stellen of competenties en infrastructuur ‘op voorraad’ aanwezig moeten zijn dan wel ingekocht moeten worden, als er daadwerkelijk behoefte aan is. (Zie ook ‘Kennisoverdracht en leren zijn bedrijfseconomische blunders’.)
Het antwoord op deze vraag is, behalve voor de hele grote ICT-organisaties, evident. Het is meestal veel goedkoper om deze competenties en infrastructuur in te huren op het moment dat er behoefte aan is. Zij zijn geen noodzakelijke kostenpost. Daarom is een ICT-organisatie als ‘cost center’ in de tegenwoordige tijd eigenlijk geen zinvolle optie meer.

4. Outsourcing als reddingsboei

Waar het op neer komt, is dat voor veel organisaties outsourcing een uitkomst is. Alleen moet men zich daarbij wel realiseren, dat de kern van ‘outsourcing’ eigenlijk ‘insourcing’ is. Men wil ‘just in time’ kennis en infrastructuur beschikbaar hebben. Daarvoor moet natuurlijk wel geregeld worden, dat toeleveranciers inderdaad kunnen leveren op het moment dat deze sources nodig zijn. En dat is de essentie van een outsourcingscontract.
Voor de toeleverancier geldt, dat hij de noodzakelijke kennis en infrastructuur wel ‘op voorraad’ moet hebben liggen. Een goede outsourcingspartner is dus groot genoeg om de investeringen in deze voorraden terug te verdienen. Hij kan doorgroeien naar stadium 4 in het plaatje. Voor hem zijn de assets (de voorraden) van strategisch belang en dat maakt hem interessant als outsourcingpartner voor alle interne en externe ICT-organisaties, die hun klanten  tegen minimale kosten toegevoegde waarde willen leveren, zonder dat ze hoeven te investeren. 
Voor de eindafnemer betekent dit, dat hij professioneel moet inkopen om de regie te behouden en daadwerkelijk te profiteren van de ‘operational excellenece’ van de leverancier. Zaken als informatiebeveiliging, business continuity, capaciteitsbeheer, inkoopkracht en thuiswerken, die hij doorgaans zelf slechts met hoge investeringen kan realiseren, krijgt hij er dan bij cadeau.
Kortom, slim outsourcen gaat voor de meeste organisaties niet over het ontwikkelen van software maar over het inkopen van ICT-beheer. (Zie ook ‘Zeven tips voor het inkopen van ICT-projecten’.)

Herziene versie: 10 juni 2011

Download:       

No related posts.

1. Probleemstelling
2. Doel en afbakening van de blauwdruk
3. Architectuur van de blauwdruk
4. Toepassingen van deze blauwdruk

1.  Probleemstelling

Het is een bekend gegeven dat er vaak sprake is van miscommunicatie tussen de ICT-dienstverleners en de gebruikers die zij bedienen. Lang heeft men de oplossing gezocht in de invoering van methoden en technieken. In de meeste gevallen echter werd hierdoor de communicatie alleen maar stroperiger. (Zie ook ‘Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 2′.)  Zelfs met een SLA wordt miscommunicatie doorgaans niet voorkomen. Het probleem zit hem ook vaak niet in de methoden en de technieken. Het probleem  zit in de afspraken die gemaakt worden tussen partijen over de samenwerking en over de afbakening van verantwoordelijkheden. (Zie ook ‘BiSL maakt functioneel beheer wel erg ingewikkeld’.) Door daarover goede afspraken te maken wordt enerzijds voorkomen dat er een overlap van activiteiten plaatsvindt en anderzijds dat bepaalde activiteiten blijven liggen. Het gaat er tenslotte ook niet om wie welke activiteiten uitvoert in uw organisatie, maar dat activiteiten uitgevoerd worden.
In dit artikel wordt u een tweetal modellen aangereikt waarmee u het huidige functioneren van de samenwerking kunt evalueren (zie voor een voorbeeld hiervan ‘Review processen informatievoorziening praktijkvoorbeeld’) en waarmee u tevens de samenwerking kunt verbeteren. 

2.  Doel en afbakening van de blauwdruk

Deze blauwdruk beschrijft de inrichting van processen binnen een interne ICT-organisatie, met als doel een  flexibele  ontwikkeling en in stand houding van een betrouwbare en beheersbare informatievoorziening te borgen.

Uitgangspunten, die zijn gehanteerd bij de opzet van de blauwdruk zijn:

• De procesinrichting is zodanig, dat voor elk proces een klant en een leverancier is te onderscheiden en dat gestructureerd en klantgericht werken wordt gestimuleerd en deels wordt afgedwongen.
• Processen worden meetbaar en controleerbaar.
• Er worden zelfsturende mechanismen gebruikt.

 Deze blauwdruk is bruikbaar voor interne en externe ICT-organisaties, die diensten willen verlenen volgens afspraak.

3.   Architectuur van de blauwdruk

3.1 Inrichting van de overall informatievoorzieningsfunctie

Bij het inrichten van de processen zal de driedeling beleid, planning & control en uitvoering  bij zowel de gebruikersorganisatie als de ICT-organisatie belegd moeten zijn. Onderstaand wordt een situatie geschetst, die uitgaat van formele overeenkomsten. Omdat er meestal onvoldoende inzicht is in zowel de gekwantificeerde behoefte als de performance, zal het enige jaren vergen, voor dit gerealiseerd is.

Op het hoogste niveau bij de gebruikersorganisatie dienen de volgende zaken belegd te worden:

• informatiebeleid en projectenplan;
• informatiearchitectuur, gegevensarchitectuur, beveiligingsarchitectuur;
• normen en standaards m.b.t. processen en middelen;
• opdrachtenbeheer;
• contractbeheer;
• auditing.

Op het hoogste niveau bij de ICT-organisatie worden belegd:

• servicebeleid en de dienstenportfolio;
• een architectuur van de ICT-infrastructuur, waarmee adequaat behoeften van de klanten vervuld kunnen worden;
• relatiebeheer;
• service level management;
• opdrachtenbeheer.

De partijen op dit niveau stemmen met elkaar af over service level agreements, opdrachten en leveringsvoorwaarden. Voorts zijn behoeften op termijn en de kwaliteit van de dienstverlening onderwerp van gesprek.

Op het P&C-niveau binnen de gebruikersorganisatie worden o.a. belegd:

• projectenbeheer;
• financieel beheer;
• functioneel beheer (o.a. gegevensbeheer, applicatiebeheer etc.);
• toetsing;
• beveiligingsbeheer;
• kennisbeheer;
• accountbeheer;
• inkoop en afroepen diensten en producten.

Het P&C-niveau binnen de ICT-organisatie vormt de front office van de operationele dienstverlening aan de klanten en tevens de aansturing van de back office activiteiten. Hier worden o.a. belegd:

• incidentbeheer;
• wijzigingsbeheer;
• configuratie beheer;
• projectbeheer;
• service management;
• quality assurance;

Deze niveaus stemmen af over de besturing en bewaking van de uitvoerende activiteiten in het kader van de behoeften van de gebruikersorganisatie op basis van de op het hoogste niveau gesloten overeenkomsten.

Op het laagste niveau binnen beide organisatie zijn de uitvoerende en ondersteunende processen en activiteiten belegd. De focus op dit niveau is primair inhoudelijk gericht en afstemming vindt plaats over inhoudelijke zaken. Bij de gebruikersorganisatie zijn dit o.a.:

• gebruikersondersteuning;
• logistieke processen;
• afhandeling incidenten;
• documenteren;
• controle taken.

Bij de ICT-organisatie zijn dit o.a.:

• operationeel beheer automatiseringsmiddelen;
• uitvoeren project activiteiten;
• advisering;
• incident afhandeling;
• documenteren;
• controle taken.

3.2 Afbakening van de informatievoorzieningsfunctie

Om verantwoordelijkheden eenduidig te kunnen beleggen, maken we een onderscheid tussen enerzijds taken waarvoor de gebruikersorganisatie verantwoordelijk is en anderzijds taken waarvoor de ICT-organisatie verantwoordelijk  is.
Voorts wordt er onderscheid gemaakt tussen het in stand houden van de informatievoorziening (niet projectmatig), en het ontwikkelen en wijzigen (onderhoud) van de informatievoorziening (wel projectmatig). Belangrijk item hierin is het helder vastleggen van de koppelvlakken. Schematisch kunnen we dit als volgt illustreren:

Belangrijk verschil tussen de ontwikkeling en de in stand houding is dat het opdrachtbeheer, het project management en de uitvoering bij de ontwikkeling over de betrokken partijen sterk geïntegreerd dienen te worden, terwijl bij het in stand houden de koppeling zich met name op het middelste niveau afspeelt. Dat betekent, dat het in stand houden een andere set aan procedures kent dan de ontwikkeling.

3.3 Koppelvlakken 

Koppelvlak 1

Het ontwikkelen en wijzigen van informatiesystemen is een activiteit die projectmatig wordt uitgevoerd in een doorgaans multidisciplinair samenwerkingsverband. Beheer vindt plaats op drie niveaus t eweten opdrachtbeheer, projectmanagement en uitvoering. (Zie ook ‘Voorbeeld opzet handboek voor ICT-kwaliteit deel 3′.) Van belang met betrekkinng tot het koppelvlak zijn een aantal aspecten:

• de opdracht, waarin resultaatbeschrijvingen, verantwoordelijkheden, bevoegdheden, budgettering, capaciteitsbehoeften en kwaliteitscontroles zijn geregeld;
• het projectplan, waarin een fasering, mijlpalen, rollen, activiteiten in de tijd en procedures zijn beschreven;
• de uitvoering op basis van een maximale uitnutting van beschikbare expertises en skills;
• de toetsing van de onderling op te leveren resultaten op plannen, standaards en normen.

Om de klant-leverancierrelatie tussen de gebruikersorganisatie en de ICT-organisatie zuiver te houden, zal het budget voor ontwikkeling en wijziging toegewezen moeten worden aan de gebruikersorganisatie. Ook hierbij is het motto: ‘Wie betaalt, bepaalt en wie betaalt, bepaalt’. Uiteraard betekent dit wel, dat de kosten van de dienstverlening door de ICT-organisatie doorbelast dienen te worden. Indien de vraag van de gebruikersorganisatie de capaciteit van de ICT-organisatie te boven gaat, kan de ICT-organisatie aanvullende capaciteit inhuren.

Koppelvlak 2 en 3

Het projectresultaat dient na oplevering in stand gehouden te worden. Dat betekent dat vooraf de acceptatiecriteria gedefinieerd dienen te worden om zeker te stellen, dat het op te leveren resultaat voldoet aan de standaards en eisen (functioneel en technisch), die nodig zijn om een adequaat beheer in de productieomgeving mogelijk te maken. Uiteraard heeft dit ook betrekking op eisen ten aanzien van de beveiliging. Hiertoe participeren functioneel en technisch beheerders doorgaans tijdig in het project.
Voor de oplevering zal door de beheerders getest worden of het resultaat aan de acceptatiecriteria voldoet. Is dit niet het geval, dan kan dit resultaat niet in productie genomen worden. Na acceptatie wordt het product overgedragen naar de beheerorganisatie belast met het beheer. Na een afgesproken garantieperiode van bijvoorbeeld drie maanden (nazorg) worden de projectteams bij beide partijen gedechargeerd. Zij zijn dan ook niet meer aanspreekbaar op eventuele tekortkomingen.

Koppelvlak 4

Belangrijke voorwaarde voor het in stand houden van de informatievoorziening is een adequate ICT-infrastructuur. Op basis van het door de ICT-organisatie gespecificeerde dienstenportfolio wordt over de behoeften en eisen die door de gebruikersorganisatie gesteld worden aan deze ICT-services en over de kosten die hiermee gemoeid zijn voor de ICT-organisatie een service level agreement gesloten tussen de gebruikersorganisatie en de ICT-organisatie.
Meer over dit koppelvlak vindt u in het artikel ‘Inrichtingsmodel IT-beheer’. 

4.  Toepassingen van deze blauwdruk

Deze blauwdruk is bruikbaar om snel in kaart te brengen welke zaken wel en niet goed geregeld zijn tussen de gebruikersorganisatie en de ICT-organisatie. Een uitwerking van zo’n review uit de praktijk vindt u in het artikel ‘Review processen informatievoorziening praktijkvoorbeeld’.
Deze review kunt u zelf eenvoudig uitvoeren. Alleen als er sprake is van spanning tussen de gebruikers en de ICT-afdeling is het verstandig om dit uit te laten voeren door een externe partij, zoals bijvoorbeeld ZBC, die dan tevens in staat is beide partijen bewust te maken van de mogelijkheden en onmogelijkheden in de relatie.
Vaak is het verstandiger om niet direct te streven naar een SLA, maar om eerst te proberen de samenwerking te verbeteren. (Zie ook ‘ITIL: professionalisering of indekken?’.) Als deze samenwerking eenmaal loopt, dan zijn ‘lean and mean’ afspraken mogelijk om ICT tot een efficiënt bedrijfsmiddel te maken. Bij de verbetering kunt u het best zelf  de regie houden en uitgaan van uw eigen behoeften, want anders loopt u het risico dat u weer in een keurslijf geperst wordt, dat u niet past. ’Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer’ kan voor u dan een pragmatische invulling zijn om stapsgewijs verbeteringen door te voeren in het beheer en zelf de regie in handen te houden. Voorbeelden hiervan zijn uitgewerkt in:

• Casestudy Training functioneel beheer website
• Casestudy Training Outsourcing werkplekbeheer
• Selectie ERP-software voor het MKB in de industrie

Herziene versie: 25 november 2010

Download:       

No related posts.

1. De slangenkuil van ERP-selectie en -implementatie
2. De spelers in dit spel en hun belangen
3. Het spel zelf
4. Het ERP-pakket als de snoeptrommel
5. De muis die een olifant werd
6. Hoe van een olifant weer een muis maken?
7. Hoe voorkom je zo’n foutenfestival?
8. Uw ERP-selectie en -implementatie 

1. De slangenkuil van ERP-selectie en -implementatie

U heeft er vast wel over gehoord, over projecten voor de selectie en implementatie van ERP-software. Ze hebben een aantal dingen gemeenschappelijk:

• Het is de grootste ICT-investering voor een bedrijf ooit.
• De impact op de processen en werkwijze is aanzienlijk.
• De implementatiekosten bedragen een veelvoud van de kosten van de software.
• De overschrijding in tijd en kosten is aanzienlijk.
• Het resultaat is vaak verrassend (en dan niet in positieve zin).

Succesfactoren zouden zijn:

• management commitment;
• sterke betrokkenheid van de gebruikers;
• een uitgebreide inventarisatie van eisen en wensen;
• inhuren externe deskundigheid;
• een goede projectorganisatie;
• enzovoort.

Rationeel gezien zou dat moeten kloppen. Vaak echter wordt vergeten dat de belangen van de verschillende partijen een zeer grote impact hebben. Als men hieraan voorbijgaat, met andere woorden, als het belangenspel niet goed wordt gemanaged, dan is het project bij voorbaat gedoemd te mislukken. Dan wordt het een ‘game’ en zal de handigste en meestal meest ervaren speler er letterlijk met de hoofdprijs vandoorgaan. Dat is vaak niet de klant, want die speelt dit spel gewoonlijk maar eens in zijn leven. En alle vormen van vals spelen zijn toegestaan, want een scheidsrechter is doorgaans niet aanwezig.  
Aan de hand van een tweetal parallellen willen we in dit artikel ingaan op een aantal belangrijke valkuilen en u een handreiking geven om een ‘horror-scenario’ te vermijden. 

2. De spelers in dit spel en hun belangen

We zullen  alle spelers die deelnemen aan het spel één voor één de revue laten passeren.

2.1 Het businessmanagement

In feite wil het businessmanagement met het spelen van het spel een aantal doelen bereiken. Het heeft er belang bij dat de  uitslag van het spel zodanig is, dat de inspanningen van alle spelers een optimaal resultaat opleveren, in termen van:

• beter in staat zijn klanten te bedienen;
• verminderen van de productiekosten;
• flexibiliteit om als bedrijf beter in te spelen op omgevingseisen.

Het businessmanagement is dus probleemeigenaar en zet in het project de koers uit, maakt de belangrijke keuzes en bepaalt de spelregels. Alle andere spelers in het veld moeten zich hieraan onderwerpen en het spel spelen zoals het management bepaalt.
Helaas zien we vaak, dat het businessmanagement zichzelf onvoldoende competent vindt. Het speelt immers zo’n spel niet dagelijks. Het verklaart daarom graag  de democratische beginselen op het spel van toepassing, of anders gezegd het snoeptrommelprincipe (zie hoofdstuk 4). Hiermee is het businessmanagement dan niet meer de probleemeigenaar en dus ook niet meer de aansprakelijke als er iets misgaat. Het eigenaarschap wordt gedeeld. Dat betekent, dat een ieder zich tijdelijk als probleemeigenaar kan opwerpen, al naar gelang het uitkomt, maar dat niemand daadwerkelijk de eindverantwoordelijkheid heeft.

2.2 De gebruikers

De gebruikers kunnen in feite worden in gedeeld in twee groepen:

• productiemedewerkers, die invulling geven aan het primaire proces;
• stafmedewerkers, die over het algemeen specialistische, kennisintensieve taken vervullen.

De productiemedewerkers hebben meestal geen gerichte bezwaren tegen de komst van een nieuw systeem. Bij hen is er vaak meer sprake van onzekerheid, zoals bijvoorbeeld over inkrimping van het aantal medewerkers, over verlies van kwaliteit van arbeid, over meer administratieve rompslomp enzovoort. Omdat ze hiermee niet echt een vuist kunnen maken vertaalt zich dit in vertragende acties als:

• inschakelen van de OR of zelfs de vakbonden;
• fuzzy informatie geven over werkzaamheden;
• een uitgebreid (en vaak onrealistisch) pakket aan eisen en wensen neerleggen, waaraan het systeem moet voldoen om daadwerkelijk bij te dragen aan de verbetering van de productieprocessen.

Hiermee wordt in elk geval uitstel van executie verkregen.

Voor de stafmedewerkers is het probleem veelal groter. Ze genieten aanzien vanwege hun informatiemacht. Er dreigt nu echter een systeem te komen, dat in wezen hun kennis bezit. Hierdoor lopen ze het risico om aanzienlijk te kelderen op de informele hiërarchische ladder:

• Verkopers zijn niet langer kunstenaars, maar worden uitvoerders van een verkoopproces met wat relatiebeheer.
• Planners zijn niet langer tovenaars, maar worden baliemedewerker van het planningssysteem.
• Administratieve krachten zijn niet langer leveranciers van managementinformatie, maar worden vaak eenvoudige tikpoezen.

Nog meer dan de productiemedewerkers zullen stafmedewerkers hun taak complexer voordoen dan zij in werkelijkheid is en eisen, dat het nieuwe systeem alle uitzonderingen aankan, die zijzelf aankunnen.

2.3 De consultants

De consultants hebben vaak de meest ervaring in het spelen van het spel. Zij zijn de profs voor wie dit soort complexe trajecten dagelijks werk is.
Het belang van het consultancy bureau is ook duidelijk. Het verdient geld met het draaien van uren. Over hoe meer productieve uren de overheadkosten van het bureau kunnen worden uitgesmeerd, des te hoger wordt de marge. Bovendien betekenen langlopende en steeds complexer wordende trajecten, dat er gemakkelijker bankzitters of junior consultants ingezet kunnen worden, zodat het bureau zijn productiemiddelen (de consultants) optimaal kan inzetten. (Zie ook ‘De verpakking van een onsje kennis is het echte probleem’.)
De werkwijze is dan simpel. Verwijzend naar de ervaring van de consultants met dergelijke complexe projecten, zal het bureau het snoeptrommelprincipe van harte ondersteunen en de medewerkers helpen om al hun eisen en wensen in kaart te brengen, ook de onrealistische, en hierop de software te selecteren. Dat betekent tenslotte dat er veel consultancy capaciteit nodig zal zijn.

2.4 De ERP-software leverancier

Het belang van  de ERP-leveranciers is, dat er zoveel mogelijk software verkocht wordt. Daarom bouwen ze steeds meer functionaliteit in de software in. Als dan de consultants hun werk goed doen en met ellenlange lijsten van eisen en wensen komen, is de kans groot dat  zij het beste scoren.
Dat eisen en wensen niet één op één vertaald kunnen worden in software functionaliteiten, zal hun een zorg zijn. Zij zijn tenslotte alleen maar de leverancier van de bouwstenen en hebben er geen grip op hoe met die bouwstenen wordt omgegaan . 

3. Het spel zelf

Het spel begint meestal met de constatering van het businessmanagement, dat er iets in het bedrijf moet veranderen om beter aan de wensen van klanten te voldoen of om kostenreductie mogelijk te maken. Het businessmanagement laat zich informeren door consultants, die redelijk eensluidend zijn in hun aanbeveling: Er moet een ERP-systeem komen om de gewenste verbeteringen te realiseren. Het ERP-systeem is het fundament waarop het bouwwerk van de verbeteringen kan worden gerealiseerd.
Het spel wordt vastgelegd in plannen en een contract, waarbij vooral de keuzevrijheid van het bedrijfsmanagement wordt benadrukt (anders gezegd: het bedrijfsmanagement blijft probleemeigenaar) en waarbij verder de consultants de spelregels aanleveren, volgens welke het spel gespeeld gaat worden en tevens zorgen voor de coaching van alle spelers. (Zie ook ‘Klantgerichtheid fopspeen van veel non-profit organisaties en dienstverleners’.)
Aan het businessmanagement vervolgens de eer om voor het spel de feestelijke aftrap (Kick off) te doen, waarna alle spelers onwennig hun weg zoeken onder de bezielende leiding van hun coaches, en aangemoedigd worden een zo groot mogelijk invloed op het spel uit te uitoefenen, waardoor iedere ploegentactiek op de achtergrond raakt en al gauw een rijstebrijberg van individuele wensen ontstaat. En zo gaat men op naar de eerste mijlpaal: het ERP-pakket. 

4. Het ERP-pakket als de snoeptrommel

De selectie van een ERP-pakket lijkt ook vaak op een feestje dat een ouder geeft voor een groep kinderen, waarbij die ouder om de feestvreugde te verhogen een goed gevulde snoeptrommel op tafel wil zetten.

4.1 De ERP-selectie

Die snoeptrommel moet natuurlijk gevuld worden met een verscheidenheid aan snoepjes, zodat iedereen de snoepjes kan krijgen, die hij het lekkerst vindt. De ouder begeeft zich naar een snoepverkoper die, om de behoefte aan nog meer snoepjes in allerlei kleuren en smaken te stimuleren, gratis een aantal snoepjes toevoegt, zodat de kinderen die ook eens kunnen proeven.
De snoepverkoper constateert echter, dat de snoeptrommel te klein is voor alle snoepjes. Hij adviseert een grotere snoeptrommel te kopen om tegemoet te kunnen komen aan de wensen van de jengelende kinderen. Intussen belt hij met de snoepjesfabriek om nog meer snoepjes in nog meer smaken, om zijn klant tevreden te stellen.
Waar de liefhebbende ouder bij de snoepverkoper binnenkwam met een snoeptrommel onder zijn arm, heeft hij een vrachtwagen nodig om de snoeptrommel thuis te krijgen. En natuurlijk krijgt hij van de snoepverkoper de rekening gepresenteerd voor de grotere snoeptrommel en de extra snoepjes.

4.2 De ERP-implementatie

Thuisgekomen hijst de ouder de snoeptrommel op tafel en zegt tegen de kinderen, dat ze hun snoepjes mogen pakken. Gelukkig weet de meegekomen snoepverkoper, dat je snoepjes soms in een bepaalde volgorde moet eten om te voorkomen, dat je er misselijk van wordt. De kinderen duiken echter met elkaar op de snoeptrommel en beginnen te graaien, waarbij de snoepverkoper al snel niet meer boven het tumult uit kan komen. En het tumult neemt natuurlijk nog toe als blijkt, dat kinderen elkaars snoepjes opeten. De zorgzame ouder vraagt aan de snoepverkoper om snel een aantal collega’s aan te laten rukken om het proces in goede banen te leiden en om dan tegelijkertijd ook nog wat extra snoepjes te halen bij de fabriek, om de verhitte gemoederen over de gepikte snoepjes te sussen. En dat gebeurt.
Het eind van het liedje is, dat de kinderen zich zwak ziek en misselijk terugtrekken op hun kamer of hun stoel en graag even alleen willen zijn. Een feestelijke gevoel werd met deze snoeptrommel in elk geval niet gecreëerd. Iedere van te voren verwachte blijdschap bleef achterwege. 

5. De muis die een olifant werd

Tot zover het verhaal over het feestje, dat ongeveer weergeeft hoe een ERP-selectie en -implementatietraject vaak verloopt.
Natuurlijk zult u zeggen, dat de ouder zijn verantwoordelijkheid niet heeft genomen, niet de grenzen heeft bepaald, waardoor de kinderen en de snoepverkoper de gelegenheid zouden hebben gekregen om beide hun belangen zoveel mogelijk te behartigen. De ouder is ervan uitgegaan, dat alle partijen integer zouden handelen en wilden bijdragen aan een leuk feestje, dat men met elkaar zou kunnen bouwen.
Waar het fout ging, was natuurlijk bij de start van het project. Ook bij een ERP-selectie worden meestal niet de essentiële keuzes gemaakt en slaat het businessmanagement vaak niet de paaltjes. Want het businessmanagement gaat er meestal vanuit, dat het in eerste instantie gaat om een ICT-oplossing en die moet je overlaten aan de professionals en de gebruikers.
Een ERP-traject echter heeft nauwelijks iets te maken met de software. ERP-software is er in alle soorten en maten en als je eerst bepaalt wat de belangrijkste businessdoelen zijn en wat er daartoe in de processen van de medewerkers moet veranderen, dan valt meestal al 90% van de mogelijke ERP-oplossingen af en heb je in elk geval een goed uitgangspunt. (Zie ook ‘Selectie ERP-pakket begint bij de keuze voor het goede type ERP-software’.)
Als je te snel naar de operationele details gaat kijken, dan ontstaat ongeveer het volgende proces:

• Het dier dat het management oorspronkelijk wilde, was een muis.
  Navraag bij de gebruikers over hoe het dier er uit zou moeten zien, levert allerlei specificaties op zoals o.a.:
  • Hij moet grijs zijn met een spitse snuit, vier poten en een staart.
  • Hij moet de functies hebben (spijsvertering) om van input output te maken, en liefst veel output.
  • Hij moet robuust zijn en een lange levensduur hebben.
  • Hij moet monkey-proof zijn.
  • Hij moet ook nog herbivoor zijn, aldus de bijdrage van een vegetariër.
  • Enzovoort.

Daar het management niet vooraf duidelijk heeft gemaakt welk dier het wilde en ook niet waarom, komt als resultaat van het selectieproces de olifant als beste uit de bus. Hiermee is een breed gedragen keuze tot stand gekomen. En draagvlak is natuurlijk van onschatbare waarde, zoals de consultants in hun toelichting het management geduldig vertellen. Het management gaat daarom zuchtend akkoord met de budgetoverschrijding. 

6. Hoe van een olifant weer een muis maken?

De olifant wordt dus aangeschaft met alles erop en eraan. Dan kan de implementatie beginnen met vraagstukken als:

• De olifant past niet onder het bureau.
• Eigenlijk gaat het niet om veel output, maar meer om bepaalde soorten output.

Kortom, het proces begint, dat van de olifant weer een muis moet maken. En dat gaat verder dan alleen het laten krimpen van de huid. Operatief moeten ook alle organen verkleind worden en de output moet uiteen gerafeld worden, zodat iedereen de juiste output krijgt. Dankzij ondersteuning door diverse collega’s slagen de consultants er uiteindelijk in deze klus te klaren en de olifant gemakkelijk onder het bureau te laten passen en van het mini-olifantje klonen te maken, zodat iedere gebruiker in feite zijn eigen mini-olifant krijgt. Die mini-olifantjes lijken allemaal precies op muizen, maar zijn toch net even anders.
Het kost natuurlijk een paar centen, maar dan heb je ook wat, want:

• De leverancier van de olifant heeft goede zaken gedaan.
• De consultants hebben goede zaken gedaan.
• De gebruikers hebben allemaal hun eigen muis gekregen.

Het management mag dit alles betalen en is nu eindelijk zover, dat het een begin kan maken met de realisatie van de businessdoelen. Al snel blijkt echter, dat dit niet zo gemakkelijk gaat:

• Een mini-olifant is toch geen muis.
• De sterk gemodificeerde olifant blijkt een sta-in-de-weg voor gewenste veranderingen.
• De organisatie is veranderingsmoe.

En dat is de echte reden, dat ERP-trajecten meestal niet opleveren, wat er van verwacht wordt, met dikwijls zeer grote overschrijdingen van budget en doorlooptijd.
Uiteindelijk krijgt natuurlijk niemand de schuld, want:

• Het management heeft zich gecommitteerd en heeft ervoor gezorgd, dat draagvlak is verkregen.
• De consultants hebben met al hun ervaring de organisatie toch door deze moeilijke periode geloodst en uiteindelijk alle problemen opgelost.
• De gebruikers hebben sterk bijgedragen om de oplossing te verkrijgen, die precies bij het bedrijf past.
• De leverancier van de olifant is intussen al weer druk bezig om zijn olifant uit te breiden, zodat er aan nog meer gebruikerseisen en -wensen voldaan kan worden. Juist die steeds groter wordende olifanten zijn tenslotte de reden voor consultants om deze leverancier aan te bevelen. Dat houdt hen immers van de straat. 

7. Hoe voorkom je zo’n foutenfestival?

De grootste fout ligt natuurlijk al voor de Kick-off. Voor de Kick-off moeten de keuzes gemaakt worden over het doel van het spel, de spelregels, de tactiek en de rolverdeling. Aandachtspunten zijn:

• Het moet volstrekt duidelijk zijn voor het businessmanagement, dat het hier niet gaat over een ICT-vraagstuk, maar over bedrijfsdoelstellingen, strategie en procesinrichting, zodat doelen bereikt worden. Alleen als u niets wilt veranderen in uw processen en bedrijfsstrategie, dan kan er sprake zijn van een ICT-vraagstuk, maar dan moet u zich afvragen of de investering in ERP zich ooit terug zal verdienen.
• Verbeteren is een proces en geen project. Die ene grote sprong voorwaarts is vrijwel nog nooit iemand gelukt.
• Wees u er van bewust dat de consultants niet van het hele traject (van de business tot en met de inrichting van het ERP-traject) verstand hebben.
• Schets een fasering, waarbij per fase duidelijk is wie probleemeigenaar is en wie dus de regie voert en wie vanuit die regiefunctie ook budgetverantwoordelijk is.
• Het is een fabeltje dat een pakket met meer functionaliteit meer mogelijkheden biedt aan een specifiek bedrijf .

7.1 De fasering van dit traject

Het traject bestaat in feite uit een aantal fasen:

1. opstellen middellange termijn business plan met betrekking tot klantgerichtheid, kosten, positie in relevante ketens en omgevingsfactoren (concurrentie, wet- en regelgeving) en het vaststellen van knock-out criteria voor de ERP-selectie;
2. opstellen shortlist ERP-pakketten en -leveranciers op basis van deze knock-out criteria;
3. beoordelen pakketten en leveranciers shorlist en het maken van  de keuze;
4. implementatie van de ERP-software op basis van sjablonen van de leverancier op basis van fixed price:
   • installatie van de software;
   • inrichting functioneel beheer;
   • inrichting software;
   • acceptatietest, conversie en opleidingen.
5. gebruik van de software met eventueel finetuning, zolang dit niet leidt tot maatwerk;
6. evaluatie van stap 5, inventarisatie van de wijzigingsvoorstellen (gebruikers en management) en opstellen plan eerste verbetercyclus;
7. realisatie en implementatie verbeteringen;
8. periodiek herhalen van de stappen 6 en 7 tot het businessplan is gerealiseerd.

7.2 Externe ondersteuning

Vaak is externe ondersteuning in dit traject gewenst. Omdat geen toeleverancier de verantwoordelijkheid voor het gehele traject op zich wil nemen, moet per fase bekeken worden of externe ondersteuning mogelijk en nuttig is.
Voor de fasen 1 en 2 kan een business consultant ingeschakeld worden, die zicht heeft op hoe de ogenschijnlijke tegenstellingen van klantgerichtheid en kostenbesparing met elkaar gematcht kunnen worden, die zicht heeft op ketenprocessen, op de markt van de organisatie, op ontwikkelingen in de omgeving en op de aanbiedersmarkt van ERP. In fase 1 moet deze consultant sparren met het management om te komen tot een concreet businessplan en de knock-out criteria. Vervolgens kan hij in fase 2 het bekende RfI omzeilen door leveranciers te dwingen om duidelijke antwoorden te geven op de knock-out criteria. Dit bespaart veel tijd en geld.
Voor fase 3 wordt een team samengesteld uit management en medewerkers van de organisatie om tijdens een demo de pakketten, leveranciers en sjablonen te beoordelen. Vaak is coaching door een ERP-consultant gewenst om het team te wijzen op mogelijke valkuilen tijdens de implementatie. Ook kan de business consultant uit de fasen 1 en 2 nog meelopen om het belang van het management te bewaken. Dit geldt in feite voor het hele traject, maar wel uitsluitend op afroep van het management.
Met deze opzet van het traject kan van de leverancier van het ERP-pakket gevraagd worden fase 4, de implementatie, op basis van fixed price uit te voeren. Dat deze leverancier hiervoor ook weer externe specialisten inschakelt, is zijn keuze, maar hij is en blijft probleemeigenaar en overschrijdingen zijn voor zijn rekening.
Tijdens fase 5 is geen externe ondersteuning nodig, maar mogelijk wel meer geavanceerde opleiding van gebruikers.
Bij fase 6 en 7 kan het best een procesconsultant ingeschakeld worden om tot een goed cyclisch verbeterproces te komen en de verbeteringen ook vast te leggen in een procesmodel en ze voortdurend te borgen. Als er aanpassingen in de software nodig zijn, kan aan de ERP-leverancier gevraagd worden deze op fixed price basis te realiseren en te implementeren.

7.3 De belangrijke eerste stap

De eerste stap in het traject is de vaststelling van bedrijfsdoelstellingen, strategie en ambities voor de komende jaren.

• Dit betekent de vaststelling van product-marktcombinaties en de kritische succesfactoren voor de levering hiervan.
• Dit betekent ook het herkennen van de leveringsketen per product-marktcombinaties, zowel binnen het bedrijf als daarbuiten, met externe ketenpartners. (Zie ook ‘Principes en mechanismen bij ketenintegratie SCM’.) Van belang hierbij is de vaststelling van de plaats van het gewenste klantorderontkoppelpunt voor iedere keten, want dit bepaalt of processen ingericht worden op efficiency dan wel effectiviteit en welke processen mogelijk in aanmerking komen om uitbesteed te worden. (Zie ook ‘Plaats klantorderontkoppelpunt (KOOP) is basis voor optimale klantgerichtheid en kosten’.) Op dit moment hoeft u zich nog niet druk te maken, hoe u dit in uw bedrijf kan realiseren, maar het is wel van belang, dat u op grond hiervan de knock-out criteria bepaalt voor de selectie van het pakket. Veel ERP-pakketten zijn ontwikkeld voor intern gebruik binnen één bedrijf en zijn totaal ongeschikt voor ketenmanagement of voor uw type bedrijfsprocessen. (Zie ook ‘Selectie ERP-pakket begint bij de keuze voor het goede type ERP-software’.)
• Voorts worden bepaald de marsroute voor de volgende fasen, de regievoering, de policy en de spelregels naar interne medewerkers en externe partijen. Ook dit leidt weer tot knock-out criteria. 

8. Uw ERP-selectie en -implementatie

Silver bullet oplossingen bestaan niet. Begin daarom met te kijken naar uw eigen behoeften. Die moeten afgedekt worden. Dit is niet mogelijk via alleen ERP-software. Deels zal dat ook moeten gebeuren door andere software, die daar specifiek voor ontwikkeld is. Alles in een ERP-pakket proppen, daarvan wordt een organisatie zelden gelukkig. (Zie ‘Hoeveel ERP wilt u hebben?”) Vervolgens bepaalt u dan volgens welke regels het spel gespeeld wordt. U koopt uiteindelijk immers een dienst in, waarmee u voorziet in uw behoeften en waarmee u tevens voorkomt dat u het spel van muizen en olifanten moet meespelen. Een aanpak hiervoor vind u in het artikel ‘Zeven tips voor het inkopen van ICT-projecten’

Herziene versies: 18 juni 2010, 3 mei 2011

Download:       

No related posts.

1. Is projectmatig werken wel ingeburgerd?
2. Projectmatig werken ‘back to the basics’
3. Afspraak is afspraak
4. PINO
5. Waar dienen procedures voor?
6. Kunnen we zonder procedures?
7. Projectmatig werken is primair een cultuur 

1. Is projectmatig werken wel ingeburgerd?

Projectmatig werken is routine geworden binnen veel organisaties. Of moeten we misschien zeggen, dat het sleur is geworden? Als men in een organisatie wat wil, wordt er een project gedefinieerd om het te realiseren. Natuurlijk wordt er een plan van aanpak gemaakt met, in een Prince 2 omgeving, waarschijnlijk ook nog een bijbehorende businesscase. Zodra het project is goedgekeurd, wordt er van start gegaan, van start met de ellende die al jaren speelt rond projecten: bureaucratie die troef is, procedures die heilig zijn.
De tijd waarin de projectmanager verantwoordelijk was voor het projectresultaat ligt al weer jaren achter ons. Tegenwoordig heeft de projectmanager een inspanningsverplichting.  En zolang hij administratief maar kan verantwoorden, dat tekortkomingen niet zijn schuld zijn, is hij gedekt. (Zie ook ‘Prince 2 geeft de projectmanager vooraf al decharge’.) De grootste fout die een projectleider tegenwoordig kan maken, is tevoorschijn komen vanachter de zorgvuldig opgebouwde beschermingswal van methoden en procedures om zijn nek uit te steken, teneinde, ‘links om of rechts om’, het afgesproken resultaat te realiseren. Dat maakt hem ineens kwetsbaar.  Hij loopt dan het risico, dat hij alle zwarte pieten toegespeeld krijgt, die nu nog bij anderen geparkeerd zijn.
Kortom, projectmatig werken is ingeburgerd in veel organisaties, maar nog allerminst geïntegreerd. (Zie ook ‘Waarom veel organisaties niet met projecten kunnen omgaan’).

2. Projectmatig werken ‘back to the basics’

Lang geleden werd een project als volgt gedefinieerd:

‘Een project is een geheel van activiteiten met een bepaald doel, buiten de gewone bedrijfsvoering om, waarbij het gaat om het realiseren van iets nieuws door een team van meerdere verschillende specialisten’.

In diet tijd was het zo, dat als men een project opstartte, het erom ging iets bijzonders te realiseren, iets buiten de normale bedrijfsvoering en dus buiten de bestaande routine om. De logge lijnorganisatie was daarvoor ongeschikt. Een project werd in die tijd geleid door de projectmanager, die vaak moest managen zonder macht. Kortom, de taak van projectmanager was een taak voor doordouwers die goed konden samenwerken, goed konden motiveren en voor de duivel niet bang waren. Tegenwoordig kampen projecten met een overmaat aan regels en procedures en is een projectorganisatie minstens zo log als de lijnorganisatie. De ideale projectmanager is getransformeerd tot boekhouder.
Waar gaat het in essentie om bij een project? Het gaat om het bereiken van een specifiek doel dat is afgesproken. Belangrijk is dat alle partijen zich vervolgens inspannen om dit doel te realiseren. Mensen kunnen heel veel, mits ze maar niet worden gehinderd. Het kenmerkende van projectmatig werken is dat er geïmproviseerd kan worden. In organisaties vormen procedures vaak de belangrijkste hindernis om doelen te bereiken. Juist omdat deze hindernis onderkend wordt, wordt een project opgestart, waarin de normale bedrijfsvoering niet van toepassing is. Dat biedt de mogelijkheid om nieuwe wegen te zoeken, te vinden en deze te bewandelen, zonder de gebruikelijke rapportage en besluitvorming en zonder lobby om consensus te bereiken. 

3. Afspraak is afspraak

Een project heeft de gebruikelijke overhead dus niet. Het loopt daardoor wel eerder het risico om te ontsporen. Vaak valt dat echter erg mee, doordat mensen zich committeren aan de afspraak. Ze kunnen zich tenslotte niet verschuilen. Om nu te voorkomen dat te gemakkelijk ingebroken kan worden op deze afspraak, zijn er een beperkt aantal procedures. Als alles goed gaat, dan zijn ze overbodig en worden ze niet gebruikt. Dan telt gewoon de afspraak en kunnen doelen bereikt worden met een minimum aan overhead.
Toch kennen we ze allemaal, de projectmanagementmethodieken met bijbehorende procedures. We leren ze op allerlei cursussen en trainingen en proberen ze na terugkomst van de training toe te passen in de praktijk. Maar wat een frustratie! Wat een bureaucratie! Wat een administratieve rompslomp! Iedereen wordt “gedegradeerd” tot een administratieve kracht, die minstens de helft van zijn tijd rapporten zit te maken en de andere helft van zijn tijd rapporten zit te lezen.
Wetenschappelijk is door Teun van Aken “bewezen”, dat projectsucces vooral afhankelijk is van de werkstijl van een projectmanager en dat allerlei procedures en technieken vaak alleen maar storende factoren zijn. Instrumentgebruik is vooral intern gericht, terwijl de projectmanager zich met name extern zou moeten richten. 

4. PINO

Wat betekent PINO? Het acronym PINO staat voor Prince (of Projectmanagement) In Name Only. Wanneer organisaties beweren dat ze projectmatig werken of Prince2 hanteren als projectmanagementmethodiek, blijkt vaak dat de methodiek als volgt is geïmplementeerd: de templates van de op te leveren (management)producten, zoals voorgeschreven door de betreffende methodiek, staan netjes op een algemeen toegankelijke directory en dat is het dan wel zo’n beetje. Richtlijnen waarin staat aangegeven in welke situaties managementproducten toegevoegde waarde leveren, of een uitleg over de daadwerkelijke doelstelling die een organisatie ermee wil bereiken, zijn er meestal niet. Het gevolg is dat de organisatie braaf altijd, voor alle projecten en in alle situaties, alle gedefinieerde (management)producten oplevert. Vaak is het zelfs zo dat, om welk willekeurig projectplan het in de organisatie ook gaat, hoofdstukken op dezelfde generieke manier zijn ingevuld (gekopieerd, bedoelen we eigenlijk). De toegevoegde waarde van een methodiek is in dit soort gevallen nul. Weer een reden waarom projectmanagementmethodieken vaak het stempel “administratieve rompslomp” krijgen, en door de organisatie worden beschouwd als een blok aan het been. Terecht natuurlijk, als ze op deze manier worden gebruikt! 

5. Waar dienen procedures voor?

Reden om binnen projecten procedures te hanteren, die we steeds weer zien terugkomen zijn:

• Het geeft een gevoel van zekerheid voor de opdrachtgever.
• Het geeft een gevoel van beheersbaarheid voor de projectmanager.
• Het geeft een gevoel van kwaliteit voor de afnemer/gebruiker.
• Het geeft een gevoel van veiligheid voor de leverancier.

Iedere partij heeft dus zo zijn eigen reden om sterk de nadruk te leggen op het hanteren van (standaard)procedures bij het uitvoeren van een project. De redenen hebben allemaal te maken met eigenbelang en met angst van de betreffende partij: “Als we maar procedures hebben, zullen onze belangen zeker gewaarborgd zijn.” Maar is dit ook zo?
In de praktijk zien we dat men procedures vooral gebruikt om zich aan vast te klampen als dingen niet gaan zoals ze zouden moeten gaan. Wanneer projecten niet meer volgens het oorspronkelijk uitgestippelde plan verlopen, hebben alle partijen de neiging meteen naar de (standaard)procedures te wijzen en vooral aan te geven waaraan de andere partij zich niet heeft gehouden. Er ontstaan oeverloze discussies of men zich nu wel of niet heeft gehouden aan de beschreven en afgesproken procedures. Men zou zich echter beter kunnen richten op het probleem zelf en dit oplossen. Maar juist in dit soort situaties richt men zich vaak overdreven op de afgesproken procedures. Onwerkbare situaties zijn meestal het gevolg. En dat is dan meteen het bewijs dat procedures zoals beschreven dus niet werken!
Procedures moeten ondersteunen, een hulpmiddel zijn, en mogen nooit de oorzaak zijn dat men zijn energie gaat verplaatsen van het echte probleem naar datgene wat ondersteunend zou moeten zijn. Hoeveel discussies binnen projecten gaan er niet over de vraag of de procedures wel goed zijn gevolgd? Hoeveel tijd is men niet bezig met indekken en met vastleggen van van alles en nog wat, voor “als het fout gaat, kan ik in ieder geval aantonen dat ik de procedures heb gevolgd”? Hoeveel tijd gaat er niet verloren om procedures op te stellen die men vervolgens gewoon aan zijn  laars lapt? Hoeveel tijd kost het niet om iedereen uit te leggen hoe de procedures moeten worden gebruikt? Kortom, het opstellen van procedures enkel en alleen om zich er aan te kunnen vastklampen zal zeker niet leiden tot het gewenste projectsucces. Dat werkt eerder blokkerend dan ondersteunend. 

6. Kunnen we zonder procedures?

Voor het organisch laten ontstaan, groeien en afsterven van een project, kortom voor het doorslaan naar de andere kant (er zijn stromingen die hiervoor pleiten), krijgen we in onze Nederlandse bedrijfssituatie de handen (nog) niet op elkaar. Maar denkt u zich eens in, een project kunnen uitvoeren zonder allerlei regeltjes en afspraken over hoe de projectactiviteiten moeten worden uitgevoerd, wat een winst in tijd en wat een vermindering van frustratie zou dat geven.
Er zijn voorbeelden van projecten die op deze wijze succesvol zijn afgerond. Uit onderzoek blijkt dat vooral de teamspirit en de leiderschapsstijl van zowel de opdrachtgever als de projectmanager hierbij doorslaggevende factoren zijn. Het is echter ook een feit dat dit projecten waren met weinig tot geen betrokken externe partijen. Het betrof interne projecten binnen innovatieve bedrijven met een hoge betrokkenheid van alle medewerkers. Wellicht niet een representatief beeld van de gemiddelde Nederlandse bedrijfscultuur. 

7. Projectmatig werken is primair een cultuur

Blijkbaar hangt het vermogen om succesvol projectmatig te werken af van de cultuur van een organisatie, van het hebben van lef om onbegaande wegen te bewandelen, van commitment aan gemaakte afspraken en van het bestaan van een ‘gezonde foutencultuur’, waarbij mensen niet worden afgerekend op hun fouten, maar op hun successen. Dat vereist echter ook een adequate managementstijl.
Misschien is het voor veel organisaties verstandig om weer eens te beginnen bij de basis ‘afspraak is afspraak’. Managers maken afspraken met hun medewerkers, medewerkers maken onderling afspraken. En als afspraken nagekomen worden, dan wordt daar uiteraard waardering voor uitgesproken. Als medewerkers ‘beren op de weg’ tegenkomen, dan wordt hun de vraag gestel: ‘Onder welke condities kun je wel je afspraak nakomen?’ Vervolgens wordt gekeken of aan die voorwaarden voldaan kan worden. Hoogst waarschijnlijk zullen veel overbodige procedures dan begraven worden. Dat is niet erg. Ze zijn immers alleen van belang als niet geldt: ‘Afspraak is afspraak’.
Het belangrijkste is, dat managers en medewerkers weer leren om afspraken na te komen, weer leren dit te waarderen, dat ze weer gaan nadenken over oplossingen, dat ze hindernissen uit de weg ruimen, dat ze simpele actielijstjes maken in plaats van ellenlange projectplannen en dat ze een risico als een uitdaging zien en niet als iets waarvoor ze zich moeten indekken.
Als deze cultuur weer omarmd wordt door managers en medewerkers, dan kunnen ook grotere projecten opgepakt worden. Dan is ook invoering van pragmatische best practices mogelijk zoals beschreven staat in ‘Projectinrichting en opdrachtbeheer’ en ‘Opdrachttypen voor projecten’.Tot die tijd moeten projecten opgeknipt worden in simpele hapklare brokjes, waarbij zowel voor de manager als de medewerker volstrekt duidelijk is welk resultaat, wanneer en tegen welke inspanning is afgesproken. Dat is immers de kern van projectmatig werken. Helaas wordt dat vaak vergeten.

Herziene versie: 28 mei 2010

Download:       

No related posts.

1. Bent u het kind van de rekening?
2. De VOC vond het verzekeren al uit
3. Wat wel en wat niet verzekeren
4. Afdekken risico calamiteiten is een keuze

1. Bent u het kind van de rekening?

De recessie wordt door bestuurders soms dankbaar als excuus omarmd: het is evident dat het ook nu niet aan de bestuurders of het management ligt, dat de resultaten tegenvallen. Het ligt aan de uitval van klanten of van financiering of het ligt aan het faillissement van toeleveranciers. Zelfs bij banken, die toch bevolkt zijn met jongens die ervoor hebben doorgeleerd, vallen de resultaten tegen. Kortom, bestuurders en managers kunnen hun handen in onschuld wassen, hen valt niets te verwijten. Of is dit misschien de managersziekte van deze tijd? (Zie ook ‘Business Continuity steeds meer aandachtspunt voor controllers’.)
Vroeger was zeker niet alles beter, maar wel vooral veel duidelijker. En er werden minder smoezen verzonnen. Als een boer een slechte oogst had, dan klaagde hij wel over het weer, maar hij ging er extra hard tegenaan om te voorkomen dat het volgende jaar weer een slecht jaar zou worden. Aankloppen bij de overheid was geen issue. Die lachte je uit. En terecht. Je was tenslotte ondernemer en daarmee was je zelf verantwoordelijk voor je risicobeheersing, ook bij calamiteiten. Je verzekeren tegen risico’s als extreme weersomstandigheden was onmogelijk en ook niet lucratief, want daarmee zou je de winst van je bedrijf zodanig afromen, dat je rendement negatief zou zijn. En wie anders dan de ondernemer zelf kan het beste inschatten welke risico’s wel en niet acceptabel zijn. De ondernemer kan dat zelf beter en slimmer dan de gemiddelde verzekeraar.
Risicomanagement is voor ondernemers en voor managers core-business. Falend risicomanagement betekent, dat bestuurders gefaald hebben. Want natuurlijk wordt een calamiteit veroorzaakt door iets in de omgeving. Dat was al zo tijdens de zondvloed en de ijstijden in de verre oudheid en dat is nu niet anders. Wijzen naar een falend systeem voor risicomanagement is weglopen voor je verantwoordelijkheid.

2. De VOC vond het verzekeren al uit

De VOC was destijds in feite de eerste organisatie die gericht was op verzekeren en het afdekken van onbeheersbare risico’s, in dit geval van de deelnemende reders. In die tijd was de kans aanzienlijk, dat een schip met lading zou vergaan met veelal als gevolg dat de reder direct failliet was. De VOC was in feite een organisatie waarin risicospreiding plaats vond. Zo werkten bijvoorbeeld tien reders samen, die allemaal een schip wilden laten bouwen. Die tien schepen bouwden ze gezamenlijk en elke reder werd voor een tiende eigenaar van ieder schip. Als er van die 10 schepen 3 of 4 vergingen tijdens de reis naar Oost Indië, dan brachten de 6 of 7 schepen die wel terugkeerden met een kostbare lading voldoende op, om iedere reder een behoorlijke winst op te leveren.
De VOC-mentaliteit is momenteel echter ver te zoeken. En daarmee wordt niet bedoeld dat we in Nederland niet meer ondernemend genoeg zijn (zoals Balkenende suggereert), maar juist dat we het risico van een calamiteit uit onze bedrijfsvoering geschrapt hebben. Verspilling is voor bestuurders zo’n doodzonde, dat iedere redundantie vaak uit een bedrijf wordt wegbezuinigd. Als een bedrijf meer kwantumkorting krijgt als het zich afhankelijk maakt van één toeleverancier, is dat bedrijfseconomisch tenslotte gunstig. Dat het bedrijf daarmee een probleem heeft, als deze leverancier omvalt, is dan een geaccepteerd risico. De VOC wist juist dat soort risico’s te vermijden. Risico’s die aanzienlijk zijn en die men niet in de hand heeft, moeten worden afgedekt.

3. Wat wel en wat niet verzekeren

Dus ook tegenwoordig moeten bestuurders zich verzekeren tegen onacceptabele risico’s. Als een bedrijf afbrandt en het pand en de inboedel zijn niet verzekerd, dan is de kans zeer aanzienlijk dat het bedrijf failliet gaat. Daarom moet de directe schade worden verzekerd. De premie hiervoor is best acceptabel, want de kans dat er brand uitbreekt is zeer klein.
De gevolgschade bij een calamiteit is echter een ander verhaal. Als uw bedrijf na een calamiteit stil komt te liggen, dan willen uw klanten nog steeds geleverd krijgen. Als dit niet gebeurt, lopen ze weg. Uw personeel wil nog steeds salaris ontvangen. De kosten die hiermee zijn gemoeid, zijn veelal niet verzekerd. Een verzekeraar rekent hiervoor een zeer hoge premie, omdat hij zulke risico’s niet kan managen.
U als ondernemer kunt dat wel. Maar u kunt na een calamiteit niet rustig achterover in uw stoel gaan zitten tot uw bedrijf opnieuw is opgebouwd en ingericht. Zodra de brand geblust is of de calamiteit voorbij is, moet u slim improviseren, zodat uw klanten geleverd krijgen (en dus blijven) en uw medewerkers productief kunnen worden in de tijd, dat u ze betaalt. Als u op dat moment helemaal moet improviseren, dan zult u hoogstwaarschijnlijk tegen een aantal show-stoppers aanlopen, waardoor dit niet volledig lukt. U zult hiervoor dus als ondernemer uw plannen moeten hebben. Ook dat is onderdeel van het op orde hebben van uw risico management.
Als u hierover heeft nagedacht, dan ligt uw draaiboek klaar om de essentie van uw bedrijfsvoering voort te zetten in geval van brand, overstroming of langdurige uitval van elektriciteit. Het gaat om uw bedrijf en u weet het beste welke risico’s u af moet dekken en welke risico’s u beter kunt accepteren. Het risico op lawines hoef u in Nederland niet af te dekken en ook een ijstijd is niet erg waarschijnlijk. Dus een draaiboek daarvoor is overbodig. Voor diverse calamiteiten als brand of overstroming heeft u vast wel een BHV-plan, dat u kan helpen om directe schade te reduceren. (Zie ook ‘Inventarisatie diensten, dreigingen en processen in uw Business Continuity Plan BCP’). Maar dan rest nog wel de indirecte schade. En daarbij spelen vragen als:

• Wordt binnen een kwartier de inkomende vaste telefoonlijn opgenomen van uw centrale nummer?
• Bevatten uw leveringsvoorwaarden een overmachtclausule?
• Ligt er een draaiboek voor crisiscommunicatie om imagoschade te vermijden?
• Kunnen uw medewerkers ook op een andere locatie werken?

De rek die u vroeger had in uw bedrijf, heeft u waarschijnlijk wegbezuinigd. De kans dat dat terecht is, is groot. Maar dat betekent niet, dat u de risico’s van een calamiteit ook maar moet accepteren. Dat blijft nog steeds uw verantwoordelijkheid.

4. Afdekken risico calamiteiten is een keuze

In veel bedrijven is dus, zoals gezegd, het risico op gevolgschade toegenomen. Een logische ontwikkeling. Het is immers niet uit te leggen aan aandeelhouders of commissarissen, dat jaar in jaar uit risico’s worden afgedekt van calamiteiten die weer niet zijn voorgekomen. Ook voor de huidige kredietcrisis geldt iets dergelijks. Jarenlang was aan te zien komen, dat de crisis ooit zou ontstaan. Als een financiële instelling niet de risico’s zou hebben genomen, die alle andere financiële instellingen wel namen, dan zou die financiële instelling meer dan een decennium lang een performance hebben laten zien, die onder gemiddeld zou zijn geweest. Ook zoiets is aan bestuurders te verwijten.
Wat nu verwijtbaar is, is dat bestuurders verrast werden door de kredietcrisis. Er lag hiervoor geen draaiboek klaar. Misschien was dit wel een bewuste keuze. Maar het risicomanagement was hoe dan ook niet op orde. Notabene overheden moesten inspringen om veel banken en verzekeraars van de ondergang te redden. Voor de meeste bedrijven geldt echter, dat de overheid niet bijspringt. Zij worden wel degelijk getroffen door gevolgschade. Als bedrijven onvoldoende flexibel zijn, dan overleven zij dit niet.
Helaas hebben wij moeten constateren, dat net als bij de banken ook in de meeste andere bedrijven geen draaiboeken klaarliggen voor calamiteiten. Denkt u eens aan gevolgschade als reputatieschade of aan bedrijfsschade door een energiecrisis. Is het voor u een bewuste keuze dergelijke risico’s te accepteren of is het falend risicomanagement? (Zie ook ‘Keuzes en aanpak voor uw Business Continuity Plan BCP of calamiteitenplan’.)

Herziene versie: 14 februari 2011

Download:       

No related posts.

1. Definitiebrij
2. De toegevoegde waarde van een normatieve auditor
3. Praktijkvoorbeeld
4. Auditing: een vak of wetenschap? 

1. Definitiebrij

Het vak van auditor heeft zich in de afgelopen jaren sterk ontwikkeld. De man of vrouw met het rode potlood is in veel gevallen uitgegroeid tot een waardevol klankbord voor het management.
Omdat veel auditors van oorsprong normatieve denkers zijn, behoeven de definities met betrekking tot auditing nu wel een bijstelling, om er vervolgens opnieuw een sticker op te kunnen plakken en natuurlijk om de beroepsgroep te beschermen.
Maar stickers of niet, een opdrachtgever zit vanwege de uitgebreide keuzemogelijkheden die hij heeft met betrekking tot auditing met de keuzestress. Zo kunt u bijvoorbeeld kiezen voor:

• een business consultant die uw bedrijf al goed kent en die eerder tot volle tevredenheid heeft geadviseerd; risico is, dat hij nu moet oordelen over zijn eigen adviezen;
• een gestickerde auditor; deze komt ongetwijfeld tot een objectief oordeel, maar vaak op een te operationeel niveau;
• een gerenommeerd bureau; uiteraard betekent dit dan nog niet, dat u een voor u goede auditor krijgt en u loopt het risico van interne koppelverkoop (Zie bijvoorbeeld ‘ERP-selectie en -implementatie: eerst van een muis een olifant maken en daarna omgekeerd’.);
• een buitenstaander wiens ideeën over het oplossen van voor u relevante probleemstellingen sterk overeenkomen met uw eigen ideeën; natuurlijk kunt u mogelijk deze ideeën gewoon zelf toepassen, maar in de praktijk ontbrekenvaak de ervaring en de routine om dit te doen. (Zie ook ‘Wat mogen bedrijven tegenwoordig van hun adviseurs verwachten?’.)

Bij uw keuze is het met name van belang wat u eigenlijk wilt bereiken.

1.1 Wil de opdrachtgever eigenlijk een audit?

De audit wordt in de praktijk vaak gebruikt. Maar waartoe nu precies? Volgens definities van Kocks (2003) heeft de audit de functie de blauwdruk van een organisatie te beoordelen, welke bestaat uit zaken als voorschriften, procedures en draaiboeken. In dit artikel willen we de functie van de audit tegen het licht houden. Daar de financial audit normatief moet zijn, laten we deze hier buiten beschouwing.
Om in een audit tot een oordeel te kunnen komen is volgens Kocks een toetsingsnorm of een set van normen nodig, waaraan de feitelijke situatie kan worden getoetst. De norm is dus nodig om er de werkelijkheid aan te spiegelen. Dit betekent dat voor iedere audit een model gemaakt moet worden waarin het auditobject, de organisatie dus, normatief beschreven is. Hiermee wordt verondersteld dat ieder auditobject uitputtend beschreven kan worden en dat deze beschrijving kan dienen als blauwdruk voor de inrichting. Een afwijking van de norm leidt tot een bevinding en moet gerapporteerd worden als verbeterpunt. Een normatieve benadering en het idee dat effectiviteit bereikt wordt door exact te voldoen aan een voorschrijvend model zijn dus de uitgangspunten.
Voor de manager ontstaat hiermee het volgende probleem: het beschikbaar hebben van zo’n model. Vaak wordt dit probleem opgelost door eenvoudigweg een bestaand model te pakken zoals een ISO-model (zie ‘ISO 27002, de Code voor Informatiebeveiliging nader toegelicht’), een INK-model (zie ‘Samenvatting INK-model’), de Code Tabaksblat ( zie ‘Corporate governance Tabaksblat en Sox: hemel of hel’) of regelgeving van toezichthouders enzovoort. Iedere manager echter weet, dat zijn werkelijkheid veel complexer is, dat hij met een generiek model nooit onderscheidend en dus concurrerend vermogen opbouwt en dat de zachte kant van de bedrijfsvoering met zo’n model niet in beeld wordt gebracht.
Elke manager zal ook de volgende situatie herkennen en zich daar geregeld in bevinden: ‘Het is niet volgens de regels en ik snap niet waarom het werkt, maar ik constateer in elk geval dat het resultaat boven verwachting is’. In zo’n situatie moet je natuurlijk niet proberen om personen of processen binnen de regeltjes te kneden, maar moet je zo mogelijk de regels verbeteren.
Dus zal de manager bij de keuze voor een auditor scherp op zijn netvlies moeten hebben wat hij wil:

• toetsing of het bestaande besturingsmodel van de organisatie (de blauwdruk in de vorm van voorschriften, procedures en draaiboeken) efficiënt en effectief is in het licht van de bedrijfsdoelen;
• inzicht krijgen in verbetermogelijkheden binnen de organisatie om ambities te kunnen realiseren, door eerst de haalbaarheid, de samenhang en de volledigheid van deze ambities te onderzoeken en hierop gebaseerde aanbevelingen.
• voorstellen krijgen voor een oplossing voor problemen of knelpunten binnen de organisatie, die met de huidige stuurmiddelen en competenties niet oplosbaar zijn; vaak is er dan sprake van een projectaudit, waarbij snel en effectief opgetreden moet worden.

In het eerste geval wil de manager zekerheid krijgen en in de laatste twee gevallen wil hij onzekerheid wegnemen. In het eerste geval verwacht een opdrachtgever een normatieve attitude bij de auditor. In de laatste twee gevallen is een klant- en oplossingsgerichte attitude noodzakelijk, waarbij de norm uit weinig meer bestaat dan een stipje aan de horizon.
Juist de attitude van de auditor is de grootste succesfactor om de opdrachtgever tevreden te stellen, en vele malen belangrijker dan kennis, vaardigheden en reputatie van de auditor of zijn bureau.
Het verschil in definitie tussen een auditor en een consultant stellen we hier niet aan de orde. In feite zouden beiden hetzelfde moeten doen: analyse en advies. Het verschil zit vaak in de attitude. Zo zal de beroepsgroep van auditors mij bijvoorbeeld adviseur noemen en zeker niet auditor. Maar dit artikel is niet geschreven voor auditors (die ik vanwege hun deskundigheid zeer hoog acht), maar voor opdrachtgevers, die bewust een auditor willen inzetten om hun doel te bereiken. (Zie ook ‘De moderne consultant: van pleaser naar teaser’.) 

2. De toegevoegde waarde van een normatieve auditor

Even terug naar de definitie van Kocks (2003). Hij stelt dat de audit de functie heeft de blauwdruk van een organisatie te beoordelen, welke bestaat uit zaken als voorschriften, procedures en draaiboeken. Gezien vanuit het normatieve denken is het essentieel dat het organisatiemodel juist en volledig wordt geïmplementeerd door de voltallige organisatie. De audit geeft het management hierover zekerheid. De auditor levert met deze zekerheid zijn grootst mogelijke toegevoegde waarde. Daar waar (een deel van) de organisatie zich niet houdt aan het model moet verandering van sturing plaatsvinden, zodat men zich er wel aan houdt. Een andere optie is het vervangen van het subsysteem door een beter subsysteem. Zo blijft de organisatie in control en zal er niets mis gaan. Zo zal de organisatie volgens het management haar doelen halen.

2.1 Pas toe of leg uit

Traditioneel gezien is dit juist. Maar zelfs de opstellers van normen zoals de ISO-normen zien de betrekkelijkheid van hun norm. Daarom zien we in deze normen steeds vaker in de titel verschijnen: ‘Code of practice for ……..’ en zien we in het voorwoord zinsnedes als: ‘Niet alle maatregelen die in dit document zijn beschreven, zijn van toepassing op elke willekeurige situatie. De norm dient dan ook niet te worden geciteerd als ware het een specificatie.’
Ook steeds vaker komen we tegenwoordig de vuistregel ‘Pas toe of leg uit’ tegen. Dat wil zeggen dat je een maatregel toepast, tenzij er redenen zijn om ervan af te wijken. In dat geval dient gemotiveerd te worden, waarom de regel niet wordt toegepast. Dat betekent, dat de organisatie nog steeds systematisch beoordeeld kan worden, maar dat zij kan besluiten om maatregelen niet of anders te implementeren. Vaak liggen hieraan bedrijfseconomische redenen ten grondslag (men besluit om maatregelen niet te implementeren) of samenhang met andere projecten of plannen (men besluit dan meestal om maatregelen later te implementeren). (Zie ook ‘Hoe 400 maatregelen terugbrengen naar hooguit 20′.)

2.2 Riskdriven benadering

Niet de maatregelen of een baseline vormen dus het uitgangspunt voor de eerste stap in het auditproces: het vaststellen van de eisen, maar de behoefte van de organisatie. (Zie ook ‘Informatiebeveiliging: geen verantwoordelijkheid maar aansprakelijkheid!’.) ISO noemt een aantal bronnen waaruit geput kan worden:

• risicobeoordeling binnen de organisatie;
• wet- en regelgeving en contractuele eisen;
• eigen stelsel van uitgangspunten, doelstellingen en eisen.

Zo nodig moeten beleidsdocumenten aangepast en weer formeel goedgekeurd worden, om te voorkomen dat later op maatregelniveau het principe van ‘pas toe of leg uit’ moet worden uitgewerkt. Bovendien draagt dit bij een latere audit bij aan een positieve beoordeling van de noodzakelijke managementbetrokkenheid.
Tijdens de tweede stap worden de behoeften en eisen op wenselijkheid en haalbaarheid beoordeeld.
De derde stap is dan het matchen van de behoeften met de maatregelen, waarbij in de praktijk per maatregel wordt bekeken:

• de wenselijkheid;
• of de maatregel al geïmplementeerd en werkend is;
• de kosten en baten van de maatregel;
• de timing van de invoeringsdatum.

2.3 De rol van de auditor

Al voordat het besluit genomen wordt om een norm in te voeren, is er voor de auditor een rol weggelegd. Zeker als er een norm wordt opgelegd, zou de auditor in dit stadium een belangrijke rol moeten spelen. Hij kan namens het management beoordelen of de norm in zijn geheel nuttig is en op welke wijze omgegaan moeten worden met het invoeringstraject. Hierbij gaat het dan niet om de inhoud van de norm, maar om de impact van de norm op de organisatie en het te verwachten nut. Juist dat is voor een normatief denkende auditor vanzelfsprekend moeilijk te beoordelen.
Het spreekt vanzelf, dat de beoogde auditor zelf niet verantwoordelijk is voor het opstellen van de norm. Wel moet hij beschikken over kennis van normen. Want hoewel er vanuit de businessdoelstellingen gezien, geen overbodige maatregelen moeten worden geïmplementeerd, is het vaak wel verstandig om de conclusies waarop de maatregelen zijn gekozen, te laten valideren door een auditor. De auditor kan in dit stadium dan optreden als klankbord voor het management, met name om zijn feedback te geven, daar waar afgeweken wordt van de maatregelen in de norm en om te beoordelen of dat voldoende wordt gestaafd met een uitleg. Om iedere vermoeden van belangenverstrengeling te voorkomen, zal een normatief denkende auditor hier waarschijnlijk niet aan mee willen werken. Dat zo’n auditor dan wel de opdrachtgever in de kou laat staan, wordt meestal niet beseft.
Tenslotte zal een auditor ingeschakeld worden voor het beoordelen van de norm en haar werking. Een normatief denkende auditor begint doorgaans bij de voorgestelde maatregelen en zal proberen de uitleg voor de afwijkingen te ondergraven. Dit echter wordt hij niet geacht te doen. De beslissing van en de redenen voor de opdrachtgever om dit traject in te gaan inclusief de hierbij gehanteerde uitgangspunten behoren zijn norm te zijn. Normatieve auditors hebben hiermee echter vaak grote moeite. Het is dan ook niet vreemd, dat auditors veelal nog steeds gezien worden als die man of vrouw met dat rode potlood en niet als volwaardig klankbord met een hoge toegevoegde waarde voor het management. 

3. Praktijkvoorbeeld

Als praktijkvoorbeeld nemen we een organisatie die in de situatie verkeert, dat de continuïteit in gevaar is vanwege onvrede bij klanten, die nu nog vallen onder een gedwongen winkelnering. Tegelijkertijd heeft de overheid of een toezichthouder bepaald, dat deze organisatie gecertificeerd moet zijn volgens ISO-norm 27002 (=17799). Vanuit bedrijfsperspectief liggen dan de volgende uitgangspunten voor de hand:

• De implementatie mag vrijwel niets kosten, om de interne kosten en dus de tarieven voor de klanten niet te laten stijgen.
• Maximale informatievoorziening aan de klanten is noodzaak.
• Beveiligingsincidenten met als gevolg imagoschade moeten voorkomen dan wel goed gemanaged worden.

Een gegeven is, dat zich in de afgelopen tien jaar geen beveiligingsincident heeft voorgedaan, met aanzienlijke schade als gevolg.
Het bedrijf heeft gekozen voor de policy het huidige stelsel van maatregelen als de norm te definiëren. Alleen daar waar sprake is van veranderde omstandigheden of waar het risico bestaat op aanzienlijke imagoschade, wordt ingezoomd. Uiteraard worden bovengenoemde uitgangspunten verwerkt in het statuut informatiebeveiliging.
De adviseur voert de exercitie conform deze uitgangspunten uit. Dus niet de maatregelen van ISO 27002 zijn de norm, maar de genoemde bedrijfsuitgangspunten. (Zie ook ‘ISO 27001 of 27002 ‘lean en mean’ implementeren als security management systeem’.)
De eerste stap is het inventariseren van de risico’s en de impact van de risico’s. Vervolgens wordt een risico analyse uitgevoerd volgens een geaccepteerde methodiek, gebaseerd op business impacts. (Zie voor de uitwerking hiervan ‘Voorbeeld Rapport Risico Analyse Informatiebeveiliging’.) Hierna wordt de behoefte gematcht met de maatregelen in een gap-analyse, waarbij niet alleen gekeken wordt naar de gaps maar ook naar de toegevoegde waarde van de maatregelen. (Zie ook: ‘Voorbeeld vaststellen norm en basisbeveiligingsniveau op grond van ISO 27002 (=17799)’.)
De uitkomst van deze exercitie ten opzichte van de huidige situatie was, dat een zestal maatregelen geïmplementeerd moesten worden en dat een vijftal risico’s gezien hun business impact door de directie werden geaccepteerd.
Dat intensief overleg met de interne auditor nodig was, spreekt voor zich. Maar nadat hij zijn normatieve benadering had afgelegd, kwam het tot een goede en vruchtbare samenwerking tussen de consultant en de auditor, zonder dat de auditor hierbij genoodzaakt werd om een rol te vervullen, die zijn onafhankelijkheid zou schaden. 

4. Auditing: een vak of wetenschap?

Wil een auditor tegenwoordig goed kunnen functioneren en voldoende toegevoegde waarde kunnen leveren, dan zal hij moeten opschuiven naar de opdrachtgever. Niet de norm is zijn baas, maar de opdrachtgever, of beter gezegd: de opdrachtgever bepaalt de norm, veelal op basis van een bestaande set van ‘best practices’. Pas als deze zijn vertaald tot de normenset van de opdrachtgever, dan kan deze normatief gehanteerd worden. Tot die tijd is normatief denken uit den boze. Normatief denkende auditors zullen dan ook in hoog tempo terrein verliezen aan de klantgericht denkende auditors of adviseurs.
Iedere opdrachtgever krijgt natuurlijk de auditor die hij verdient. Als de opdrachtgever weigert om zelf de norm vast te stellen, dan heeft de auditor geen andere keuze dan normatief te handelen. Helaas zien we in zo’n situatie vaak, dat de chemie ontbreekt en de toegevoegde waarde van de auditor niet of nauwelijks opweegt tegen zijn kosten.

Download:       

No related posts.