10 STAPPEN VOOR EEN GOEIE VOORBEREIDING VOOR EEN NIEUW SOFTWARE PAKKET

Maanden, dikwijls jaren aan voorbereiding gaan vooraf aan de implementatie van een nieuw software pakket. De verwachtingen zijn dan ook hoog gespannen of met deze implementatie alle problemen die je organisatie had met het oude systeem, zullen verholpen zijn. Een belangrijk ICT-systeem kiezen, bijvoorbeeld voor ERP of de financiële administratie, is geen dagelijks werk. Om de juiste afweging te maken bij de pakketkeuze is het belangrijk om hoofd- en bijzaken te scheiden.

Uitsluitend afgaan op wat  een leverancier vertelt, is niet voldoende; die geeft vaak een eenzijdige visie en is primair gefocussed om je te begeleiden … doorheen het verkoopproces! De sterke punten van een pakket worden erg belicht, en als de verkoper goed naar je luistert, zal hij die punten noemen die voordelen bieden voor jouw organisatie. Je wil echter een correct en realistisch beeld krijgen van het pakket en dus ook van de punten die voor jouw belangrijk zijn, maar door de leverancier misschien minder belicht worden!

Worden die punten toevallig enkel minder belicht, of zijn het punten waarop het systeem minder presteert? Dat laatste is van belang, omdat na ingebruikname van een systeem de initiële voordelen snel ‘gewoon’ worden en dan gaan de mindere punten opvallen. Als deze punten daarna gaan storen wordt de adoptie van het systeem beïnvloed en brokkelt het draagvlak binnen je organisatie af en zit je met een systeem dat maar beperkt gebruikt zal worden.

En dat is niet echt de bedoeling als je een nieuw ERP pakket aangeschaft hebt, toch?

 

10 stappen voor een geslaagde implementatie
  1. Projectdefinitie en scope:
    Een goede voorbereiding is ook hier heel belangrijk. Denk eerst goed na en bepaal wat je wilt bereiken. Waar schiet het je huidige systeem concreet in tekort en welk probleem wil je oplossen?  Is het een echt probleem of eerder een frustratie? Richten je je op de grond van de zaak of toch weer op de symptomen? Welke vereisten stel  je dan aan het nieuwe systeem? Functioneel, Technisch, Gebruikerservaring, Onderhoudsgemak, etc.
    Je bent ook best zelfkritisch en bepaalt de eigen beperkingen van je organisatie. Hoeveel mensen en middelen heeft je organisatie beschikbaar?  Wat is onze je bestedingsvork in best- en worst case, en verhoudt zich dat ten opzichte van het minimum viable product (ofte de minimale, maar werkbare scope)? Wil je het nieuwe pakket met een big bang of eerder gefaseerd implementeren? Hoe zwaar wil/kan je de organisatie belasten? Ga je je processen conformeren aan het pakket of hou je vast aan je werkmethode?
    Zeker niet vergeten:
  • Welke verwachtingen hebben we je ten opzichte van de leverancier? Kennisdomein, beschikbaarheid, snelheid, continuïteit van kennis en technologie, etc.
  • Heb je je basisdata en -architectuur onder controle of ligt hierin een verhoogd implementatie- en migratierisico?
  • Beschik je over een eigen IT-infrastructuur of kan je de ‘cloud’ in? En waarom zou je het ene of het andere doen?

Dit en andere vragen zijn de vragen, die je jezelf moet stellen vooraleer je de markt gaat wakker maken. Zodra je samen met je organisatie hierover een 80/20 beeld gevormd hebt, kan je gericht partijen betrekken.

  1. Het koopproces:
    Je wil liefst zelf controle en sturing op dit proces. Jij loodst de aanbieder doorheen jouw koopproces en geeft hem afgelijnde ‘opdrachten’. Opdrachten om dingen voor te bereiden en uit te zoeken, die hen in staat stellen hun product gericht en to the point te presenteren aan ‘alle betrokkenen binnen alle lagen’ van je organisatie. Je gaat zelf bepalen wat primair toegelicht of getoond wordt en je gaat zelf stilstaan bij concrete uitdagingen waar je vandaag mee worstelt. Je legt deze voor aan de verkoper met de vraag hoe zijn pakket hiermee omgaat.
    Zoals gezegd, je wil vooral NIET in het verkoopsproces van de aanbieder terecht komen. Jij blijft baas over de case en jij bepaalt hoever de aanbieder gaat. Wat niet wil zeggen dat je de aanbieder moet beletten de zaken iets breder te bekijken en zodoende jouw case kan challengen. Ook dat kan je helpen om met voortschrijdend inzicht jouw case te verdiepen en te verbeteren.
  2. Functionele fit en features:
    Je mag ervan uitgaan dat vandaag alle pakketten, die in dezelfde rayon liggen, functioneel grosso-modo hetzelfde kunnen. Het verschil zit ‘m vaak in specifieke features of details, die al dan niet in jouw case belangrijk zijn. Daar moet je naar op zoek.
    Laat je ook niet van de wijs brengen door de toeters en de bellen, maar hou focus op de bal. Je business case uit punt 1! Denk in termen als ‘must have’, ‘should have’,’nice to have’ en ook ‘will not have”. Koop niet meteen die collosale Rolls-Royce, maar kijk eerst naar wat je nodig hebt.
  3. Technische fit:
    Ook wordt al te vaak gesteld dat “men technisch alles kan oplossen”. Stel dat je die “men” in je project kan krijgen, sta je onvoldoende stil bij de risico’s, omdat we je verblind bent door de functionele glans van het pakket. Laat ons wel wezen; je wilt bij voorkeur geen maatwerk in je pakket. Een zuivere core zal je voordeel zijn bij uitbreidingen en updates. Maatwerk hypothekeert vaak ook vernieuwing en onderhoud van het softwarepakket.
    De technische fit met je eigen omgeving moet er zijn, om te vermijden dat je door extra ontwikkeling, interfacing en datamappings geconfronteerd wordt met een ondoorzichtig en vooral sterkt verhoogd kostenplaatje. En je mag ervan uitgaan dat dit maar het begin is, want een verhoogde complexiteit van je set-up draag je levenslang mee in onderhoud en foutgevoeligheid.
  4. Kosten: Er zijn natuurlijk verschillende soorten kosten in je project. Breng alles goed in kaart.
  • Licentiekosten (voor het gebruik van de software)
  • Implementatie en migratiekosten (inrichten van het pakket, interfacing met andere software en migratie van historische data).
  • Onderhoudskosten (Denk aan updates en upgrades, bugfixes en kleine functionele aanpassingen).
  • Opleiding bij go live, maar ook achteraf voor opfrissing en voor de nieuwe mensen
  • Tijd van de interne gebruikers en specialisten, die je zonder enige twijfel in voldoende mate zal moeten vrijmaken, wil je dat je project slaagt! Afhankelijk van de situatie kan het zomaar zijn dat je tijdelijk (zoals het project loopt) interimkrachten binnen haalt om je eigen mensen dedicated op het project te laten werken!
  1. Leverancierskeuze:
    Na de initiële afspraken en globale demo’s is het zaak om te gaan focussen. Met welke leverancier en met welke oplossing heb je de beste match? De bedoeling is dat je een relatie voor meerdere jaren gaat opbouwen met de leverancier. Dan kan die relatie maar beter goed zijn. De leverancier moet dus een partner worden. De angst voor ‘uurtje-factuurtje’ is vaak ingegeven door een ervaring uit het verleden. Als de relatie tussen beide partijen goed is en de leverancier zich een partner voelt, zal die vaak juist niet alles in rekening brengen en meer doen dan gevraagd om de relatie goed te houden. Behandel je jouw leverancier als ‘leverancier’ dan wordt alles facturabel.
  2. Het komt er dus op aan om duidelijkheid te krijgen over punten zoals:
  • Stabiliteit: Tegenwoordig is het belangrijk om te toetsen of je leverancier financieel gezond is en je morgen nog steeds kan ondersteunen.
  • Materie-kennis: Heeft de leverancier veel domeinkennis? Een ervaren partij zal de juiste vragen stellen, goede inschattingen maken en daardoor (meer kans hebben om te kunnen) waarmaken wat ze beloven. 
  • Flexibiliteit en klantgerichtheid: Is de leverancier vooral sterk op technologisch vlak en voert hij een strategie van product leadership of is hij georganiseerd om jou de nodige service te geven. Hoe is de ondersteuning georganiseerd? (helpdesk) En wat kost die hulp precies? 
  • Referenties: Check referenties en organiseer site-bezoeken bij gelijkaardige organisaties, die met het pakket én de leverancier gewerkt hebben.
  • Draagvlak: Een van de grootse valkuilen, waar elke onder-/beslissingsnemer telkens intrapt is … zelf, met eigen inzicht en grondige onderbouwing de beslissing nemen! Klinkt contradictorisch, maar je mag dan nog het beste systeem aankopen en uitrollen; als je mensen er niets mee kunnen of willen kan je het project bijschrijven in het register van onzinnige en mislukte projecten. Je begint met het creëren van draagvlak en dus goesting voor een nieuw pakket vanop de werkvloer, en niet de aan directietafel.
  1. Project governance/beheer:
    Engageer alle betrokkenen en alle lagen van de organisatie bij het sturen en het opvolgen van de pakketselectie én de implementatie. Werk hier niet met grote groepen, maar met groepen waarin de betrokkenheid van de verschillende niveaus binnen het bedrijf, is vertegenwoordigd.
    Wij adviseren ook om de aanbieder(s) structureel te laten zetelen in de diverse governanceorganen. Zo ben je verzekerd van hun engagementen en beloftes, die in de koopfase zijn gegeven én houd je directe lijnen open naar de specialisten, architecten en beslissingsnemers van de leverancier.
    Zeker in de werkgroepen kan het nuttig zijn dat je deze zelf faciliteert. Je zal zien dat wanneer je specialisten van verschillend pluimage samenbrengt, dit  interessante debatten kan opleveren. Ze doorprikken elkaars “BS-verhalen” en plooien terug op de echte sterktes van hun oplossing. En jij leert van hetgeen je ziet gebeuren!
  2. Extern advies:
    Er komt heel wat kijken bij het aankopen van een pakket en voor wie dit geen dagelijkse praktijk is, is een neutraal advies zeker een voordeel. Een onafhankelijke organisatie of adviseur kijkt naar je bedrijf en processen en vertaalt die naar een plan van eisen. Pas daarna kijkt die naar de meest passende oplossing, zonder enige voorkeur of binding met de gekozen oplossing.
    Hij blijft ook vaak tijdens de uitrol een vertrouwenspersoon, die vanuit zijn expertise en ervaring kan schakelen en vertalen tussen jouw belangen en die van de implementator. Hij is de projectwaakhond en zorgt ervoor dat iedereen zich aan zijn uitspraken en beloftes houdt. Hij houdt alle partijen scherp ten behoeve van een succesvolle oplevering en vooral adoptie van het pakket.
  3. Maak je eigen huiswerk!
    Denk goed na, neem je tijd, kijk waarom je het doet en neem dat als leidraad om je keuze te maken. Tenslotte is het jouw beslissing en moet er een hele tijd mee leven. Een foute beslissing heeft verregaande gevolgen voor je bedrijf. Een organisatie die stilvalt o.w.v. een mislukte implementatie van een nieuw softwarepakket, kost (veel) geld. Vertrouw daarom niet blindelings op  interne of externe adviezen, maar maak zelf een gefundeerde beslissing.

Een goed plan van aanpak is dus goud waard. Laat je zo nodig begeleiden in de selectie- en koopfase, maar ook bij het opstellen van een aanvalsplan.

Leave a Reply

nl_NLDutch