Moving forward - planlegg veksten

Bygge eller kjøpe CRM | Kostnad, risiko og eierskap

Skrevet av Hallgeir Gustavsen | 1. jan. 1970, 00:00:00

Et hjemmelaget CRM kan se billig ut fordi lisensen allerede står på Microsoft 365-fakturaen. Et ferdig CRM kan se dyrt ut fordi kostnaden har en egen linje.

Begge inntrykk kan være feil. Sammenlign hva løsningen koster å bruke, forvalte og endre over tid.

Hva koster et ferdig CRM?

Kort svar: Kostnaden består av lisenser, implementering, datarydding, integrasjoner, opplæring og løpende forvaltning. Produktnivå og brukerbehov betyr mer enn leverandørens laveste startpris.

Ta med:

  • nødvendige bruker- og produktlisenser
  • oppsett av felter, pipelines og rettigheter
  • import og datakvalitet
  • e-post-, kalender- og nettsideintegrasjoner
  • rapporter og dashboards
  • opplæring og intern systemeier
  • senere forbedringer

Et dyrt CRM med lav bruk er fortsatt dyrt. Det samme er et billig CRM som ikke fanger aktivitetene ledelsen trenger.

Hva koster intern utvikling?

Kort svar: Intern utvikling koster analyse, bygging, testing, dokumentasjon og vedlikehold. Kostnaden finnes selv når arbeidet gjøres av en ansatt som allerede er på lønningslisten.

For et SharePoint-oppsett kan arbeidet omfatte lister, relasjoner, visninger, Power Automate, Power Apps, Power BI, tilgangsmodell og integrasjoner. Hver komponent trenger test og eierskap.

Regn også på ventetid. Hvis løsningen tar seks måneder å få stabil, har virksomheten seks måneder med fortsatt manuelt arbeid og ufullstendige data.

Hvem eier integrasjoner og feil?

Kort svar: Den som bygger en integrasjon, oppretter et varig driftsansvar. Noen må overvåke feil, håndtere endrede API-er, rotere tilganger og rette poster som havner feil.

En flyt som kopierer e-post eller skjemadata kan fungere fint helt til et felt endres, en bruker slutter eller en tillatelse trekkes tilbake. Hvis feilen oppdages tre måneder senere, er kostnaden større enn tiden det tar å reparere flyten.

Ferdige CRM-er fjerner ikke integrasjonsansvaret, men de leverer flere standardkoblinger og produktfunksjoner som virksomheten ellers måtte bygge.

Hva skjer når personen som bygget løsningen slutter?

Kort svar: Løsningen må kunne overtas uten muntlig arkeologi. Dokumentasjon, test, navngitte eiere og kontrollert tilgang er en del av kostnaden.

Sjekk om en ny systemeier kan svare på:

  • Hvilket system eier hvert felt?
  • Hvilke flyter skriver data?
  • Hvor ligger hemmeligheter og tilganger?
  • Hvordan testes endringer?
  • Hvordan gjenopprettes feil?
  • Hvilke rapporter er beslutningskritiske?

Hvis svarene bare finnes i hodet til én person, har dere en nøkkelpersonrisiko, ikke et enkelt system.

Hvordan regner du på 24 måneder?

Kort svar: Lag to realistiske scenarier med samme behov og periode. Inkluder både synlige kostnader og tiden som brukes på manuell registrering, feil og manglende oppfølging.

Kostnad Bygge selv Kjøpe CRM
Lisenser Microsoft/Power Platform og eventuelle tillegg CRM-produkt og brukere
Oppsett Datamodell, app, flyter og rapporter Konfigurasjon, import og integrasjoner
Drift Feilretting, tilgang og endringer Systemforvaltning og planendringer
Bruk Manuell logging og lokale rutiner Adopsjon, opplæring og CRM-rutiner
Risiko Nøkkelperson, teknisk gjeld og migrering Leverandørbinding, prisvekst og overkjøp

Sett en intern timekostnad på forvaltningsarbeidet. Legg til konsekvensen av glemte aktiviteter og manglende kildedata uten å late som tallet er mer presist enn underlaget.

Les SharePoint som CRM og SharePoint vs HubSpot for den praktiske sammenligningen.

Få et avgrenset beslutningsgrunnlag

Vanlige spørsmål

Er egenutvikling alltid billigere når vi allerede har Microsoft 365? Nei. Eksisterende lisenser reduserer inngangskostnaden, men fjerner ikke arbeid med datamodell, automasjon, integrasjoner, forvaltning og brukeradopsjon.

Hva bør med i kostnadsregnestykket? Ta med lisenser, oppsett, datarydding, integrasjoner, opplæring, intern tid, feilretting, rapportering og eventuell migrering. Bruk samme kravsett for begge alternativer.

Når lønner standardprogramvare seg? Standardprogramvare blir mer attraktiv når behovene er vanlige, flere brukere trenger samme arbeidsflyt og virksomheten vil konfigurere fremfor å utvikle grunnfunksjonene.