CRM implementatie: fasen en doorlooptijd voor het MKB

Het eerlijke antwoord: de CRM-scope bepaalt de doorlooptijd

Een CRM met één pipeline, een klein team en een schone contactenlijst is een ander implementatieproject dan een systeem met meerdere afdelingen, rechten, historische data, offertes, agenda’s en boekhoudkoppelingen. Daarom is een vaste belofte van een aantal weken zonder uitgewerkte scope weinig waard. De planning wordt pas bruikbaar wanneer duidelijk is wat de eerste versie moet ondersteunen en wat bewust later komt.

Begin met de dagelijkse kernroute: hoe komt een aanvraag binnen, wie beoordeelt hem, welke status volgt, welke gegevens zijn nodig en welke volgende actie mag nooit ontbreken? Koppel daar gebruikers, databronnen, rechten, rapportages en noodzakelijke integraties aan. Een leverancier kan daarna fasen, afhankelijkheden en acceptatiemomenten plannen. Onzekerheden verdwijnen niet, maar worden zichtbaar voordat ze de livegang blokkeren.

Beslis wat gereed moet zijn voordat de implementatieklok start

Veel vertraging die aan techniek wordt toegeschreven, begint vóór de bouw. Er is geen proceseigenaar, verschillende teams gebruiken andere statusnamen of niemand kan beslissen welke velden verplicht zijn. Leg daarom vooraf het bedrijfsdoel, de eerste gebruikersgroep, de kernpipeline, de minimale rapportage en de beslissers vast. Beschrijf ook welke bestaande werkwijze na livegang stopt; anders blijft het oude spreadsheet stilletjes het echte systeem.

Maak daarnaast een lijst van aannames en open vragen. Welke bron bevat de betrouwbaarste klantdata? Moet e-mailhistorie mee? Welke koppeling is noodzakelijk voor de eerste werkdag en welke is alleen handig? Wie mag records verwijderen of financiële informatie zien? Plan onbekende technische punten als korte proef of discovery. Dat is beter dan ze als vanzelfsprekend in een einddatum te verstoppen.

Fase 1: inventariseer processen en baken de eerste release af

In de eerste fase wordt geen lange wensenlijst verzameld, maar worden echte werksituaties gevolgd. Neem bijvoorbeeld een nieuwe lead, een terugbelafspraak, een offerte die wacht op reactie en een bestaande klant met een vervolgvraag. Noteer per situatie de trigger, eigenaar, benodigde informatie, beslissing en volgende actie. Zo ontstaat een procesmodel dat medewerkers herkennen en dat getest kan worden.

Vertaal dit model naar een eerste release met duidelijke grenzen. De kern kan bestaan uit klantkaart, pipeline, taken, notities, rollen en één essentiële koppeling. Zet overige dashboards, portalen en automatiseringen op een latere lijst. De uitgang van deze fase is geen vrijblijvende workshop, maar een goedgekeurde scope met acceptatiescenario’s, eigenaren en expliciete uitsluitingen.

Fase 2: ontwerp en configureer in korte controleerbare stappen

Laat de proceseigenaar en enkele sleutelgebruikers vroeg een werkend prototype zien. Controleer namen van fases, verplichte velden, zichtbaarheid per rol, taakmomenten en uitzonderingen voordat veel details zijn gebouwd. Een scherm kan technisch correct zijn en toch niet aansluiten op het moment waarop een medewerker een beslissing neemt. Vroege feedback voorkomt dat dit pas tijdens training wordt ontdekt.

Werk vervolgens per afgebakend onderdeel: pipeline en klantkaart, taken en signalen, rechten, rapportage en koppelingen. Iedere stap krijgt een demo en een besluit. Nieuwe wensen worden apart beoordeeld op noodzaak, impact en planning; ze schuiven niet ongemerkt de eerste release in. Daarmee blijft de doorlooptijd bestuurbaar zonder relevante feedback te negeren.

Fase 3: behandel data en koppelingen als kritieke route

Datamigratie bestaat niet alleen uit exporteren en importeren. Bronnen moeten worden geïnventariseerd, velden gemapt, dubbele records herkend en onbruikbare historie afgebakend. Voer eerst een proefmigratie uit met herkenbare records. Vergelijk aantallen, controleer belangrijke velden en laat gebruikers zoeken naar klanten die zij goed kennen. Pas na goedkeuring volgt de definitieve migratie.

Koppelingen hebben dezelfde discipline nodig. Leg vast welk systeem voor elk gegeven leidend is, wanneer synchronisatie plaatsvindt en wat er gebeurt bij een ontbrekend of afgekeurd record. Test normale routes én fouten, zoals een dubbel e-mailadres, ongeldige status of tijdelijke storing. Een integratie die in een demo één record doorstuurt is nog geen beheerste productiekoppeling.

Fase 4: test per rol en laat het interne team echt accepteren

Acceptatie is meer dan controleren of knoppen werken. Een verkoper moet een lead kunnen verwerken, een manager moet betrouwbare voortgang zien en een beheerder moet een fout kunnen herkennen en herstellen. Gebruik vooraf beschreven scenario’s met verwachte uitkomsten. Noteer per bevinding of het een defect, onduidelijke afspraak of nieuwe wens is; die drie vragen om een andere beslissing.

De interne proceseigenaar geeft uiteindelijk akkoord op de werkwijze en data, niet alleen de leverancier. Reserveer daar echte tijd voor. Wanneer sleutelgebruikers alleen aan het einde een drukke testmiddag krijgen, wordt de planning afhankelijk van haast en aannames. Verspreide controles na iedere fase maken het eindbesluit kleiner en beter onderbouwd.

Fase 5: ga gefaseerd live en bewaak de eerste werkweken

Start waar mogelijk met een representatieve maar beheersbare gebruikersgroep. Controleer of nieuwe aanvragen aankomen, taken ontstaan, gegevens compleet blijven en medewerkers de afgesproken route volgen. Houd een duidelijk kanaal voor vragen en problemen aan. Niet iedere vraag vereist direct een wijziging; soms ontbreekt een werkinstructie of moet een bestaande afspraak scherper worden gemaakt.

Schaal pas op wanneer de kernscenario’s stabiel zijn en de verantwoordelijken weten hoe zij afwijkingen behandelen. Leg ook een terugvalbesluit vast voor de migratie of een cruciale koppeling. Dat is geen belofte van een storingsvrije livegang, maar een voorbereiding op het moment dat een controle onverwacht rood wordt.

Verdeel de verantwoordelijkheden vóórdat de planning vaststaat

De leverancier kan procesvragen stellen, ontwerpen, configureren, bouwen en technische tests uitvoeren. Het bedrijf zelf blijft nodig voor prioriteiten, betekenis van data, toegang tot bronsystemen, gebruikersfeedback en acceptatie. Benoem minimaal een proceseigenaar met beslissingsruimte, sleutelgebruikers per rol en een eigenaar voor data en koppelingen. Eén persoon kan meerdere rollen hebben, zolang de benodigde tijd en beslissingen maar expliciet zijn.

Plan vaste momenten voor scopebesluiten, prototypefeedback, proefmigratie, acceptatie en livegang. Noteer wie informatie aanlevert en binnen welke termijn een besluit nodig is. “Wachten op klant” en “wachten op leverancier” zijn te vaag om te sturen. Een concreet open punt heeft een eigenaar, gewenste uitkomst en datum waarop de planning opnieuw wordt beoordeeld.

Maak een realistische CRM-planning met beslispoorten

Bouw de planning van resultaten in plaats van alleen activiteiten. Een fase is klaar wanneer de kernflow is goedgekeurd, het prototype de gekozen scenario’s ondersteunt, de proefmigratie controleerbaar klopt of de pilotgroep de dagelijkse route kan uitvoeren. Zet na ieder resultaat een beslispoort: doorgaan, herstellen, scope aanpassen of een onderdeel uitstellen.

Neem ruimte op voor feedback, toegang tot externe systemen en herstel na tests. Toon daarnaast welke onderdelen parallel kunnen en welke elkaar blokkeren. Training kan bijvoorbeeld worden voorbereid terwijl de laatste rapportage wordt afgerond, maar een definitieve migratie kan niet verantwoord vóór de mapping en proefimport zijn geaccepteerd. Zo ontstaat een planning die uitlegbaar is zonder een gegarandeerde einddatum te suggereren.

Microsoft beschrijft in de Dynamics 365 Implementation Guide hetzelfde principe: bepaal de testscope vroeg, laat gebruikers de oplossing in een acceptatietest beoordelen, oefen de overstap met een proefrun en neem de livegang pas als expliciet go/no-go-besluit. Die handleiding gaat over één pakket, maar de les geldt voor ieder CRM: de einddatum volgt uit afgeronde controles, niet andersom.

Welk planningssjabloon kun je direct invullen?

Gebruik per fase vier vaste vragen. Wat is het zichtbare resultaat? Wie is intern eigenaar? Welk bewijs ligt op tafel bij de beslispoort? En wat vertraagt deze fase in de praktijk het vaakst? Als één van de vier leeg blijft, is de fase nog niet planbaar. Hieronder staat het sjabloon ingevuld voor een voorbeeldsituatie: een verkoopteam van vijf mensen dat van een gedeeld spreadsheet en losse mailboxen naar één CRM wil, met één koppeling naar het websiteformulier.

Fase 1, inventarisatie. Resultaat: vier uitgeschreven werksituaties (nieuwe aanvraag, terugbelafspraak, offerte zonder reactie, bestaande klant met vervolgvraag) en een lijst met wat bewust buiten de eerste release valt. Eigenaar: de commercieel verantwoordelijke. Bewijs: twee verkopers herkennen hun eigen werkdag in de scenario’s. Typische vertraging: niemand durft te beslissen welke statusnamen blijven.

Fase 2, ontwerp en inrichting. Resultaat: een werkend prototype met pipeline, klantkaart, taken en rollen. Eigenaar: dezelfde proceseigenaar, met één sleutelgebruiker. Bewijs: de vier scenario’s zijn in het prototype doorlopen en de afwijkingen staan genoteerd als defect, afspraak of nieuwe wens. Typische vertraging: nieuwe wensen die ongemerkt in de eerste release schuiven.

Fase 3, data en koppeling. Resultaat: een proefimport van het spreadsheet en een werkende formulierkoppeling met een vastgelegde aanpak voor dubbele contacten. Eigenaar: de medewerker die de klantdata het best kent. Bewijs: aantallen kloppen, tien bekende klanten zijn correct terug te vinden en een testaanvraag komt met bron en eigenaar binnen. Typische vertraging: onduidelijk welke bron leidend is als het spreadsheet en een mailbox elkaar tegenspreken.

Fase 4, acceptatie. Resultaat: alle scenario’s per rol getest, inclusief een dubbel record en een gebruiker zonder rechten. Eigenaar: de proceseigenaar geeft akkoord. Bewijs: een lijst met openstaande bevindingen waarvan geen enkele de dagelijkse route blokkeert. Typische vertraging: sleutelgebruikers krijgen pas aan het einde één drukke testmiddag.

Fase 5, livegang en nazorg. Resultaat: het team werkt in het CRM en het spreadsheet is alleen-lezen gemaakt. Eigenaar: de proceseigenaar, met een vast aanspreekpunt bij de leverancier. Bewijs: na de eerste werkweek heeft iedere nieuwe aanvraag een eigenaar en volgende actie. Typische vertraging: het oude bestand blijft stilletjes in gebruik omdat niemand het afsluiten heeft gepland.

Kijk daarna naar de kritieke route. In dit voorbeeld kunnen training en rapportage parallel aan fase 3 worden voorbereid, maar de definitieve import kan pas na een geaccepteerde proefimport en de livegang pas na fase 4. Zet die afhankelijkheden zichtbaar in de planning. Dan zie je ook direct wat een week vertraging in de datafase betekent voor de rest, zonder dat iemand een einddatum hoeft te raden.

Gebruik het scopegesprek om de haalbaarheid te toetsen

Vraag een CRM-leverancier niet alleen wanneer het systeem klaar is. Vraag welke scope daarbij hoort, welke interne inzet is aangenomen, welke afhankelijkheden op de kritieke route liggen en welke resultaten per fase worden geaccepteerd. Controleer ook wat na de eerste livegang gebeurt: begeleiding, herstel van defects, beheer, wijzigingen en uitbreiding naar andere teams.

Softora kan in een scopegesprek voor bedrijfssoftware op maat de kernflow, databronnen, rollen, koppelingen en een beheersbare eerste release zichtbaar maken. Daarna kan een planning op concrete aannames worden gebaseerd. Dat garandeert geen vaste doorlooptijd, foutloze migratie of gebruik door iedere medewerker, maar maakt wel duidelijk welke beslissingen nodig zijn om verantwoord vooruit te gaan.