Slik skjer det
En mislykket Salesforce-implementering sjelden en dramatisk hendelse. Den begynner som en serie ubehagelige samtaler.
Leveransene tar lenger tid enn avtalt. Konsulenten forklarer at scope har utvidet seg. Du mottar et system ved go-live som ikke oppfører seg slik du forventet i presenteringene. Teamet bruker det motvillig og faller tilbake til egne Excel-ark etter noen uker. Noen måneder etterpå sitter du med en Salesforce-lisens du betaler for og et system som ikke brukes til noe vesentlig.
Det er det vanligste utfallet. Ikke et fullstendig havari, men en gradvis kollaps av forventningene som ender med et halvbrukt system og en dyr erfaring.
Det andre utfallet er raskere: prosjektet stopper før go-live. Konsulenten og klienten er uenige om scope. Endringsordrer har doblet budsjettet og det er fortsatt ikke ferdig. En eller begge parter avslutter forholdet. Du sitter med delvis konfigurert system og ingen klar vei videre.
Typiske feilårsaker
De fleste mislykkede implementeringer sporer tilbake til ett eller flere av de samme grunnproblemene.
| Årsak | Hvordan det manifesterer seg |
|---|---|
| Uklart scope ved oppstart | Prosjektet starter uten at alle parter er enige om hva som er inne og ute. Forventningsgapet vokser gjennom prosjektet og koker over ved leveranse. |
| Manglende intern eier | Ingen på klientsiden tar ansvar for beslutninger og godkjenninger. Prosjektet venter på avklaringer. Timer faktureres mens fremdrift stopper. |
| Konsulenten er for junior | Ustrukturerte problemer eskaleres sakte og løses med løsninger som skaper nye problemer. Prosjektet tar lenger tid enn estimert uten å gi bedre resultat. |
| Brukeradopsjon ble ikke planlagt | Systemet er teknisk ferdig ved go-live men teamet er ikke klart til å bruke det. Opplæring ble ikke budsjettet, endringsledelse ble ikke gjort. Bruken faller innen to måneder. |
| Integrasjonskompleksitet var undervurdert | Estimatet antok at integrasjoner mot andre systemer var enkle. De var det ikke. Integrasjonsetappen forsinket resten av prosjektet og sprengte budsjettet. |
| Kommunikasjonsbrudd | Konsulenten og klienten snakker ikke regelmessig nok om fremdrift og problemer. Overraskelser ved leveransen burde vært diskutert for tre måneder siden. |
Legg merke til at tekniske årsaker er i mindretall. De fleste mislykkede implementeringer feiler ikke fordi Salesforce er for komplisert. De feiler fordi prosessene rundt prosjektet var dårlige: uklart scope, dårlig kommunikasjon, manglende eierskap internt.
Hva du gjør midt i et feilende prosjekt
Det er tegn på at et prosjekt er i ferd med å spore av. Å handle på dem tidlig er vesentlig billigere enn å vente til go-live.
Etter havariet: hva som kan repareres
Et mislykket implementeringsprosjekt etterlater deg i én av to situasjoner. Enten har du et delvis konfigurert system som aldri ble ferdigstilt, eller du har et ferdig system som ikke brukes.
Begge situasjoner er reparerbare, men de krever ulik tilnærming.
Et delvis ferdig system trenger en revisjonsgjennomgang: hva er faktisk konfigurert, er det konsistent nok til å brukes, og hva mangler for å nå et brukbart minimumsnivå. Det er ikke alltid riktig å bygge videre på eksisterende konfigurasjon, særlig om den er inkonsistent eller inneholder designvalg som ikke fungerer. Noen ganger er det billigere å starte med en ren konfigurasjon basert på lærdom fra det forrige forsøket.
Et ubrukt system er et annet problem. Den tekniske konfigurasjonen kan være fin. Problemet er at teamet ikke stoler på den, ikke vet hvordan de bruker den, eller har lært seg å jobbe rundt den. Det er et adopsjonsproblem, og løsningen er ikke mer teknisk konfigurasjon men opplæring, endringsledelse og tett oppfølging i den første bruksperioden.
Når vi overtar et prosjekt etter et havari, er den vanligste tilstanden en blanding av de to: et system som er delvis ferdig på noen areas og ubrukt på andre, med teamet i ulike stadier av frustrasjon. Det første som trengs er en klar kartlegging av hva som faktisk finnes og hva som faktisk brukes, før noe nytt besluttes. Mer om hvordan den fasen ser ut i artikkelen om hva en Salesforce-implementering egentlig koster.
Hva dette lærer oss
Den vanligste årsaken til at bedrifter tar kontakt etter en mislykket implementering er at de har lært hva de burde ha spurt om i forkant.
De vet nå at hvem som utfører arbeidet er viktigere enn firma-størrelsen. De vet at et vagt scope er en garantert kostnadsfelle. De vet at brukeradopsjon ikke er noe som skjer av seg selv ved go-live. Og de vet at et lavt tilbud sjelden er det det ser ut til å være.
Den beste forsikringen mot et mislykket Salesforce-prosjekt er å velge riktig partner fra start. Mer om hva det krever i artikkelen om hvordan du velger riktig Salesforce-partner i Norge.
Hos Valon tar vi over prosjekter etter mislykkede implementeringer. Det første vi gjør er å kartlegge hva som faktisk eksisterer og gi deg et ærlig bilde av hva som trengs, uten å selge inn mer enn situasjonen krever.
Sitter du med et Salesforce-prosjekt som ikke gikk som planlagt?
Vi ser på hva som er der, hva som kan brukes, og hva den raskeste veien til et fungerende system ser ut. Ingen forpliktelser.
