Managed hosting door True

Stappenplan voor succesvol selectie- en implementatieproject

Houd regie in eigen hand

Slechts een minderheid van de selectie- en implementatieprojecten voor een nieuw (erp-)systeem zou tot een goed einde komen. Vaak wijst de beschuldigende vinger richting opdrachtgever of leverancier, en wordt de consultant ten onrechte gespaard.Waar wringt de schoen en hoe is een succesvolle implementatie te realiseren? De visie van een management CONSULTANT.

Niet gelijkgestemd
Ik ben een groot voorstander van een standaard erp-pakket. Hiervoor zijn veel reële argumenten aanwezig. Belangrijke voordelen zijn onder andere de kenmerken van normale standaardproducten. Hierdoor is een bedrijf niet afhankelijk van de nukken van een IT-consulent. Een bestaand, werkend automatiseringssysteem is direct beschikbaar, en de functionaliteit en bruikbaarheid binnen de organisatie zijn meteen aantoonbaar. Helaas maakt een groot deel van de bedrijven hiervan weinig gebruik, zo laat de praktijk zien.
De standaard erp-systemen zijn na jaren van R & D volwaardige producten geworden waarin veelal het type bedrijfsmodel voor de jaren 2000 ligt verankerd. Alle functionaliteiten zijn ruimschoots aanwezig om de bedrijfsvoering in een turbulente 24 uurs-economie te ondersteunen.
Tussen de verkopende en kopende partij van een erp-pakket, in het geval van het bewuste artikel respectievelijk SAP en Tabeshold, doet zich een probleem voor: de communicatie. De verkopende partij is vaak te veel bezig met het aanprijzen van zijn koopwaar en de kopende partij met een probleem dat hij wil laten oplossen door 'het nieuwe systeem'. Er wordt veel over en weer gepraat en weinig concreets op papier gezet. Onbewust zijn beide partijen dan al begonnen met het onderhandelingstraject, terwijl daaraan nog een essentieel traject vooraf hoort te gaan.
Voor de verkopende partij - de erp-softwareleverancier - is een transactie een van de vele dagelijkse handelingen. Voor de aankopende partij heeft de deal een nadrukkelijke lading, waarbij de levensvatbaarheid van het bedrijf op het spel komt te staan. Want niet alleen is er sprake van grote kosten - de projectkosten, inzet van extra personeel en tijdelijk verlies van omzetten -, maar de organisatie maakt ook een periode van een grote onzekerheid door.
Bij een dergelijke grote transactie gaat het dan ook niet om gelijk gestemde partijen. De verkopende partij heeft een leidende rol in het welslagen of mislukken van de projectdoelstelling. Zij beschikt immers over voorinformatie met betrekking tot een dergelijk implementatieproject.
Tegelijkertijd gaat de aankopende partij ook niet geheel vrij uit, althans het verantwoordelijke management dat moet beslissen over de aanschaf van het erp-pakket. Al te vaak geeft het de regie van het implementatieproject om duistere redenen uit handen, het liefst bij een 'consultant'.
De ervaring leert dat verantwoordelijkheid niet buiten de deur kan worden gekocht.

'Onafhankelijke' consultant

Tabeshold was niet te spreken over de werkwijze van de consultant. De consultant doet zich in het algemeen voor als de onschuldige onafhankelijke deskundige. Hier begint eigenlijk al het zaad te ontkiemen van een mislukt project. De vergelijking dringt zich op met de 'leadmanager', die een bedrijf naar de beurs brengt. De leadmanager ontvangt zijn commissie los van het feit of deze emissie geslaagd of mislukt is. Wel bewandelt de leadmanager de voorgeschreven procedures van het 'Due Diligence'-onderzoek.
De consultant komt nagenoeg altijd ongeschonden uit de strijd. Want mislukkingen worden vaak in de schoenen van de erp-softwareleverancier geschoven, of eerder nog in de schoenen van de opdrachtgever. Duidelijke omschreven opdrachten tussen bedrijf en consultants ontbreken helaas al te vaak, zo wijst de praktijk uit. De kwaliteit van de consultants staat wel degelijk ter discussie, de goede uitgezonderd, want die zorgen gelukkig nog voor geslaagde projecten. Vaak worden consultants ingeschakeld bij de voorfase, de verkenning, van het selectie- en implementatieproject, omdat de bedrijven die deskundigheid niet in huis hebben. Een selectie op kwalificaties is dan nauwelijks mogelijk. De tarieven zijn niet mis: bedragen tussen de 2000 en 3800 gulden per dag behoren niet tot de uitzonderingen. Waarschijnlijk moeten deze tarieven de kwaliteit garanderen. De prijzen van erp-software zijn daarentegen in de loop der jaren flink gedaald in verband met de grootschalige toepassing. Tot mijn verbazing worden dezelfde consultants ingezet voor de implementatie van het systeem, want in het opgestelde plan van aanpak heeft de consultant zichzelf uitgenodigd voor het implementatieproject. Hierdoor wordt het voor de consultant alsnog mogelijk om het geadviseerde systeem op rekening van de klant te leren kennen. Het is dezelfde 'onafhankelijke' consultant die ervoor zorgt dat het managementteam van het bedrijf een beslissing neemt over de aankoop van het geadviseerde erp-pakket. De zuiverheid van het consultancy-vak lijkt in het geding te komen door commerciële belangen.
Om een systeem te adviseren zul je alle ins- en outs ervan moeten kennen. Pas dan is het mogelijk om te beoordelen of het voldoet aan de opgestelde eisen en wensen van het bedrijf. Gedetailleerde kennis van het erp-pakket is dan ook een must om het prototype van een bedrijf te kunnen modelleren.

Onderschatting

Bij het management van het bedrijf is vaak sprake van onderschatting of onverschilligheid. Het laat zich onder meer leiden door de vele vakbladen waarin de erp-softwareleverancier zich tracht te profileren. En het realiseert zich niet dat vooraf nog veel zaken moeten worden voorbereid. Soms wordt de mening beïnvloed doordat een soortgelijk bedrijf net een erp-project heeft laten uitvoeren.
Alle genoemde elementen tezamen zorgen ervoor dat de missie van het project niet gerealiseerd wordt. De commerciële belangen van erp-leverancier en consultant gaan ten koste van de bedrijven, waarvan de levensvatbaarheid in groot gevaar komt, en die dit avontuur uiteindelijk moeten betalen.
Om een selectie- en implementatie project te doen slagen adviseer ik het volgende stappenplan.
Houd de regie in eigen handen, want dan verliest u de controle over het project niet. Tenslotte kent u uw onderneming als geen ander.

Stappenplan

1. Maak een plan van aanpak. Hierin staan de uit te voeren activiteiten in volgorde van belangrijkheid, wie ze moeten uitvoeren, de planning en de benodigde capaciteit. Een belangrijk aspect is het opzetten en bijhouden van de project-documentatie en de verslagen.

2. Begin met het installeren van een projectteam. Stel een plan van aanpak beschikbaar en laat deze toetsen op de haalbaarheid.
Het team dient te bestaan uit een projectleider en leden. De leden moeten hoofden van de afdelingen te zijn. De projectleider rapporteert wekelijks over de voortgang van het project.
 
3. Het project-team begint met het benoemen van de knelpunten van de huidige organisatie. De inventarisatie gebeurt per bedrijfsonderdeel: bijvoorbeeld de financiële administratie, de afdeling inkoop, de afdeling verkoop, het magazijn, de service-administratie, de afdelingen logistiek en marketing. De inventarisaties vinden zo mogelijk simultaan plaats. Stel hier een bepaalde tijd voor vast.
 
4. Stel aan de hand van de knelpunten per bedrijfsonderdeel oplossingen voor met mogelijke alternatieven. Bepaal bij de oplossingen de uitgangspunten. De oplossingen dienen te worden gezien in samenhang met alle bedrijfsonderdelen. Zorg ook hier dat de leden niet te veel afdwalen.
 
5. Aan de hand van de oplossingen volgt een vertaling naar wensen en eisen van het nieuwe systeem. De wensen en eisen worden samengevat per bedrijfsonderdeel, bijvoorbeeld: algemeen, financieel, inkoop, verkoop, voorraad, logistiek, enzovoort. Deze wensen en eisen dienen te worden genummerd; later worden daaraan toegevoegd rfi (request for information) voor fase 1 en rfp (request for proposal) voor fase 2.
 
6. Het opstellen van de wensen en eisen van het nieuwe systeem kost meestal de meeste tijd. Hulp van een externe consultant is meestal geen overbodige luxe. U kunt deze inbreng beperken tot het minimum.
Als uw onderneming importeert en exporteert zal een eis aan het systeem zijn dat het in meerdere valuta's kan factureren en in meerdere talen. Heeft uw onderneming meerdere vestigingen, dan zal consolidatie over de verschillende vestigingen mogelijk moeten zijn.
 
7. Kandidaat systeemleveranciers dienen aan een aantal criteria te voldoen. De volgende vragen kunnen daarbij als richtsnoer dienen.

  • Sinds wanneer bestaat de software-leverancier?
  • Wat is het aantal vaste medewerkers, wat zijn de kwalificaties en ervaringen?
  • Hoeveel implementaties zijn verzorgd?
  • Is men in het bezit van een ISO-certificatie?
  • Heeft men de beschikking over een helpdesk?
  • Is het mogelijkheid te informeren bij referenties ?
  • Is reeds eerder geleverd aan een referentie binnen dezelfde branche met hetzelfde wensen- of eisenpakket?
  • Geeft de leverancier trainingen en opleidingen?
  • Worden standaard-procedures gehanteerd bij de implementatie?
  • Wordt een onderhoudscontract aangeboden voor nieuwe versies?
Indien het antwoord op een aantal vragen negatief is, kan dat al reden zijn om de betreffende leverancier niet verder bij de selectie te betrekken.
 
8. Algemene eisen en wensen met betrekking tot de software (rfi).
  • Functioneert het pakket op alle mogelijke computersystemen, dus systeem onafhankelijk?
  • Beschikt het over Windows-faciliteiten?
  • Functioneert het pakket op een relationele data-base en is het via andere SQL-talen toegankelijk?
  • Is koppeling naar andere standaardpakketten mogelijk: tekstverwerker, spreadsheet, elektronische post?
  • Beschikt het systeem over een import- en exportfunctie voor de conversie van de data-base van het huidige systeem en van toekomstige systemen?
  • Is er sprake van een client/server-architectuur en object-oriëntatie?
  • Beschikt het over het onderdeel systeembeheer?
  • Kan het systeem specifiek op uw behoefte worden toegesneden zonder tussenkomst van een programmeur (functie voor customizing)?
  • Is het systeem parametergestuurd?
  • Is er een rapportgenerator voor de vervaardiging van eigen documenten?
  • Heeft het autorisatie- en beveiligingsmogelijkheden.
  • Is het modulair opgezet? Modules kunnen onafhankelijk werken en als geïntegreerd systeem.
  • Heeft het een SQL-opvraagtaal?
  • Is het millennium- en eurobestendig?
Die hier gestelde technische pakketeisen zijn minimum-eisen. De laatste zes punten zijn van essentieel belang. Hiermee kunt u snel zaken zelf aanpassen aan externe ontwikkelingen, waar u als bedrijf geen grip op hebt.
 
9. Aan de hand van de opgestelde eisen en wensen zoals genoemd onder de punten 7 en 8 ten aanzien van het rfi, nodigt u geheel vrijblijvend tien tot vijftien erp-leveranciers uit voor fase 1, van welke u denkt dat die hiervoor in aanmerking komen. Deze procedure verzoekt om een request for information, maar is wel bindend en vormt een onderdeel van een eventueel te sluiten overeenkomst. Dat dient u bij de uitnodiging te vermelden.
 
10. Uiteindelijk houdt u drie potentiële leveranciers over. De overige leveranciers schrijft u af en u bedankt hen voor de geleverde inzet. Hierna stuurt u het gedetailleerde eisen- en wensenpakket op (request for proposal, rfp) aan de drie geselecteerde leveranciers. U nodigt deze uit om mee te doen aan het rfp. In het rfp dient de software-leverancier op alle vragen antwoord te geven en aan te geven op welke wijze het pakket voorziet in de eisen. Indien het pakket aan een eis niet voldoet, moet de leverancier aangeven of er een eenvoudige oplossing is. Daarbij moet ook een projectvoorstel (plan van aanpak) geleverd worden en een opgave van de uiteindelijke kosten. De software-leverancier zal zich moeten committeren aan de antwoorden in het rfp, omdat het rfp een onderdeel vormt van het contract. Wanneer bij oplevering of implementatie niet de toegezegde functionaliteiten wordt geboden, verplicht de leverancier zich kosteloos de zaken te repareren. Als ondernemer heeft u het recht om de software te retourneren.
 
11. In een workshop nodigt u wederom geheel vrijblijvend de overgehouden leverancier uit. Belangrijke punten uit het beantwoorde rfp laat u de software-leverancier demonstreren. Al heel snel krijgt u een indruk over de leverancier en het software-pakket. U krijgt steeds meer duidelijkheid inzake de oplossing van uw eisen- en wensenpakket in het nieuwe systeem.
 
12. Na zorgvuldige afweging selecteert u de beste kandidaat.
Aan de overige twee leveranciers bericht u dat deze voorlopig niet zijn geselecteerd. Dit in afwachting van de verder nog te houden 'prototyping-sessie' met de geselecteerde software leverancier. Bij de uiteindelijke selectie heeft u als selectie-criteria gehanteerd:
  • de organisatie van de leverancier aan de hand van het rfi;
  • de algemene functionaliteit van het pakket aan de hand van het rfp;
  • de functionaliteit van het pakket met betrekking tot de gestelde wensen en eisen;
  • het projectplan voor implementatie;
  • het uit de workshop verkregen inzicht in de verrichtingen;
  • de kosten.
13. Met de geselecteerde leverancier maakt u een afspraak dat het voorlopig contract wordt getekend, onder voorbehoud van de punten zoals beantwoord in het rfi en het rfp en na de te houden 'prototyping'-sessie. In dit 'prototyping-traject' wordt uw bedrijf 'opgezet' in het software-pakket (proefbedrijf). Alle operationele zaken en administratieve procedures worden gesimuleerd. Lopen de zaken voorspoedig, dan is de deal gesloten en kunt u beginnen met de implementatie, het volgende traject. Hiervoor heeft u indirect de leverancier geselecteerd.
 
14. In dit stadium zijn beide partijen het erover eens wat er geleverd gaat worden. Over de prijs van het pakket moet nog onderhandeld worden. U heeft nu tot in detail inzicht gekregen in de prestatie van het software-pakket en de software leverancier. De software-leverancier zal u een licentie-overeenkomst bieden met betrekking tot het gebruik van de software. Hieraan zijn eenmalige kosten verbonden. Terugkerende kosten - betreffende het onderhoudscontract - variëren van 12 tot 18 procent van de aanschafprijs van de software. Om de software te implementeren worden de kosten van dienstverlening in rekening gebracht. Bij het tekenen van het contract is uw offerte-aanvraag (rfi/rfp) bepalend; de transactie-overeenkomst met de leverancier onder verwijzing naar uw opdracht vormt hiervan een onderdeel. Daarbij dient u het project op basis van 'fixed-price' te laten uitvoeren. Betalingstermijnen conform het project, bijvoorbeeld: bij opdracht 30 procent, bij levering 20 procent, bij installatie 10 procent, na implementatie 20 procent en na acceptatie 20 procent.
 
15. U schrijft de overige leveranciers dat uiteindelijk de keuze op een andere leverancier is gevallen en bedankt hen voor hun inzet en medewerking. Hier geldt de achterliggende gedachte dat deze leveranciers u over een paar jaar wel van dienst kunnen zijn.
 
16. Ieder project moet worden geëvalueerd. Ongetwijfeld is een aantal zaken niet goed gegaan. Het is belangrijk om deze zaken mee te nemen in de evaluatie. Deze evaluatie is van belang bij het bepalen van de wensen en eisen aan uw toekomstige systeem. De evaluatie dient om bij een volgend project de fouten van dit project niet nogmaals te maken.
 
Een dergelijk project kent drie fasen of trajecten: verkenningsfase (1) ofwel implementatievoorbereiding, selectie van het informatiesysteem (2) en de uiteindelijke implementatie (3). Worden de eerste twee trajecten overgeslagen, dan resulteert dit in een verkeerde implementatie. De problemen tussen SAP en Tabeshold hadden betrekking op de implementatie. Mij is niet bekend of fase 1 is doorlopen, voorafgaand aan de fasen 2 en 3. Dan was de schade beperkt gebleven doordat niet was gekozen voor SAP, maar voor een andere erp-softwareleverancier. Uiteraard is bij dergelijke projecten een goed projectmanangement een nadrukkelijk vereiste.
 
Ferry Schwab, management consultant te Harderwijk

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/1429571). © Jaarbeurs IT Media.
?

 

Reacties

Doet mij deugt dat het artikel nog bestaat, en uiteraard hebben velen hiermee hun voordeel kunnen doen!

Auteur van het artikel en de methodiek succesvol-implementeren.

Netjes. Als student kan ik hier goed gebruik van maken!

Het doet mij goed dat vele professionals de kreet "succesvol implementeren" hanteren als publiekstrekker. Dat ze vergeten dat deze Methodiek en naam gepatenteerd is.

Desalniettemin:

Succesvol Implementeren:
Methodiek volledig gedigitaliseerd op CD. Bevat drie parktijkhanboeken voor verkenning, selectie en implementatie plus algemeen bedrijfsmodel en databank met geslecteerde softwareleveranciers / automatseringsbedrijven. Methodiek bevat standaard documenten ter ondersteuning van implementatieprojecten oa. communicatieplan, pva, rfi, rfp, crp en modelcontracten.

Prachtig te zien hoe succesvol implemeneteren als uithangbord wordt gezet bij vele websites. Echte ze realiseren zich niet dat de auteur/schrijver van deze methodiek vervat in praktijkhandboeken, modeldocumenten met een database aanbieders destijds het predicaat droeg naar aanleiding van 400 implementaties;
Hierdoor o.a. door buitenlandse aanbieders van Enterprice Resoures Planning werd verkozen/geselecteerd om ERP in 1991 uit te rollen in de Benelux.
Prachtig te zien hoe Nederlandse aanbieders ook hun software nu ERP noemen.

Wij zien er nog niet!
Fastware & Advisering die in 1983 deze naam droeg nu overal op het internet verschijnt.

Als al de naamgebruikers nu een donnatie gaven alleen maar voor het gebruik. Het predicaat moeten ze nog verdienen.

Uiteindelijk heeft Fastware & Advisering het merk succesvol implementeren, met nadruk op succesvol als One liner in de media gebracht naast het merk ERP.

Toch zuur voor de naamdragers!

Onlangs nog hebben bedrijven deze methodiek nog gebruikt en dit anno 2011. Alhoewel de databank met aanbieders niet meer actueel is.

Een onderwerp wat ik onder punt 8 nog mis is: Is het pakket ontworpen voor de schaalgrootte waarop het bedrijf opereert?
Ik zie helaas in de markt dat leveranciers optimistische geluiden laten horen over de schaalbaarheid, maar dat dat een veelvoud aan hardware (en energie) kost, wordt niet altijd even duidelijk gezegd.
De oorzaak van beperket schaalbaarheid bij pakket software zit besloten in het belang van de leverancier. Hij wil graag optimale flexibiliteit, zowel in functionaliteit, maar ook voor de harware/OS omgeving waar het pakket moet draaien. Dit leidt dan ook tot een beperkt/gestandaardiseerd gebruik van oa DBMS-en, waarbij niet altijd gebruik gemaakt wordt van de specifieke kracht van deze produkten. De keerzijde van deze (flexibiliteits) keuzes is duidelijk de performance penalty hiervoor. Een systeem voor 1000 transacties per dag ziet er anders uit dan een systeem voor 10 milj transacties per dag.
Vooral de wat grotere bedrijven moeten hier terdege rekening mee houden.

Op uw vraag van 28/11-2011.

Ik begrijp wat U bedoelt, ben betrokken geweest in 1981 bij de ontwikkeling van Electronische toepassingen bij de Rabobank voor Bankpas met strip en Pincode voor de applicaties ATM, POS en Telebankieren. Met de achterliggende systemen IBM in batchachtige omgeving met Real time Tandem NON-Stop systemen die de transacties van de POS, Geldautomaten en telebankieren ondersteunen als Front-end gebeuren. Hiervoor werd een speciale database ontwerp gemaakt om de performence tijden fors te reduceren plus de opslag; bewust is gekozen toen voor Tandem, die transcatiegewjs werkt.

Wij dwalen af, maar om uw vraag in een praktijksituatie te brengen

Volgens mij staat dit in punt 8 verwoord;

•Functioneert het pakket op alle mogelijke computersystemen, dus systeem onafhankelijk?
Wellict met toevoeging of het pakket de daarbijhorende database management ondersteund.

Overigens wel een zeer essentiele opmerking!




Lees meer over:
Vacatures ERP

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×