Enterprise CRM med Dynamics 365: når CRM blir en virksomhetsplattform

Det er ofte da vi blir hentet inn: Systemet fungerer, men endringene tar for lang tid. I denne artikkelen ser vi på hva som må være på plass for å beholde kontrollen. Vi bruker ordet styring om ansvar, beslutninger og rutinene som sørger for at de følges opp.

Når blir CRM en virksomhetsplattform?

Det er ikke antall brukere som avgjør. En stor salgsavdeling der alle arbeider likt, kan ha mindre behov for samordning enn et lite konsern med to selskaper. Behovet for felles styring øker når flere av disse forholdene er til stede:

• Flere divisjoner eller juridiske enheter deler løsningen.
• Tilgangen må avgrenses etter rolle, enhet eller land.
• Endringer kan ikke lenger gjøres direkte i produksjon.
• Løsningen er koblet til ERP og en dataplattform.
• En feil kan påvirke flere avdelinger og viktige arbeidsprosesser.

Dette gjelder like mye for en medlemsorganisasjon med regionledd og sentral administrasjon som for et konsern med flere selskaper. Det gjelder også selskaper med virksomhet i flere land, der personvernkravene i tillegg kan variere.

Hva god styring gir virksomheten

Styring handler ikke bare om å hindre feil. Like viktig er hva den gjør mulig:

• Raskere innføring i nye divisjoner. Dere kan gjenbruke arbeidsprosesser og oppsett som allerede er prøvd ut.
• Kundeopplysninger dere kan stole på. Divisjonene bruker de samme kundeopplysningene, og det er tydelig hvem som har ansvar for å holde dem oppdatert.
• Kortere tid fra behov til endring. Endringsønsker vurderes samlet, prioriteres og følges opp gjennom en avtalt prosess.
• Mindre personavhengighet. Beslutninger og oppsett dokumenteres, slik at flere kan forvalte og videreutvikle løsningen.

Det er disse gevinstene som skal forsvare investeringen. Hvordan dere regner på dem, står i Gevinstrealisering i CRM.

Hvem bestemmer hva?

Styringen fungerer bare når ansvaret er tydelig. Når flere divisjoner deler løsningen, er det særlig seks områder der ansvaret må være avklart:

Virksomheten bør selv ha ansvaret for plattformen. Plattformeieren har mandat til å prioritere videreutviklingen og sørger for at beslutningene blir tatt. En partner kan forberede beslutningene, men ikke ta dem. Et kort, fast prioriteringsmøte og en felles oversikt over endringsønsker er ofte nok til å komme i gang. Skillet mellom dataeierskap og systemeierskap er utdypet i hvorfor eierskap til data blir viktigere enn eierskap til systemet, og styring av Power Platform i Power Platform-governance for mellomstore virksomheter.

Avklar hvem som skal se og endre hvilke opplysninger

I Dynamics 365 styres tilgang med forretningsenheter (business units), team og sikkerhetsroller. Forretningsenhet er et begrep i Dynamics 365 og brukes til å avgrense tilgang til data. Forretningsenhetene kan følge organisasjonskartet, men trenger ikke å gjøre det. Microsoft støtter også en matrisemodell, der en bruker får sikkerhetsroller fra flere forretningsenheter og dermed tilgang til data på tvers av dem.

Utgangspunktet bør derfor være hvem som trenger å se og endre hvilke opplysninger, ikke hvordan organisasjonen er tegnet. To divisjoner med de samme kundene og de samme tilgangsbehovene trenger ikke hver sin forretningsenhet bare fordi de har hver sin direktør.

En vanlig utfordring vi møter, er at tilgangene blir for brede. De gis tidlig for å unngå friksjon og strammes aldri inn. Tilgangene fra brukerens sikkerhetsroller og team gjelder samlet, og en snevrere rolle opphever ikke bred tilgang fra en annen. Når rollene overlapper, blir det derfor vanskelig å se hva en endring i én rolle egentlig betyr. Microsoft anbefaler dessuten å dele enkeltposter bare som unntak. Kilde: Microsoft Learn om sikkerhet i Dataverse.

Sammensatt eksempel fra flere leveranser: Et konsern med flere divisjoner deler én Dynamics 365-løsning. I løpet av noen år har hver divisjon bedt om «bare én justering til» i sikkerhetsrollene. Nå overlapper rollene, og ingen kan lenger si sikkert hvilke tilganger de gir. Før nye justeringer gjøres, må virksomheten kartlegge tilgangsbehovene og vurdere rollene samlet. Målet er en tydeligere rollemodell som er enklere å forvalte.

Miljøer og ALM: slik kommer endringer trygt i produksjon

Når flere divisjoner deler løsningen, kan en endring som er riktig for én avdeling, skape problemer for en annen. Separate miljøer for utvikling, test og produksjon reduserer den risikoen. Leveransen fra utvikling til produksjon er en del av det som kalles application lifecycle management (ALM). ALM omfatter i tillegg blant annet krav, testing, drift og vedlikehold. Kilde: Microsofts oversikt over ALM. Slik fungerer leveransen:

• Endringer utvikles i et eget utviklingsmiljø, som unmanaged solutions.
• Løsningen eksporteres som en managed solution og installeres i test og produksjon. Endringer gjøres i utviklingsmiljøet og leveres videre derfra, ikke direkte i test eller produksjon.
• Den eksporterte unmanaged-versjonen lagres i versjonskontroll, slik at alle endringer kan spores.
• Power Platform Pipelines leverer løsningen til miljøene i fast rekkefølge. Før hver utrulling kontrolleres blant annet om nødvendige komponenter finnes i målmiljøet.

Pipelines sikrer at det som er testet, er det som havner i produksjon. De avdekker ikke om løsningen oppfører seg riktig. Derfor må dere også teste hvordan endringene påvirker de viktigste arbeidsprosessene. Managed Environments gir i tillegg administratorene mulighet til å begrense deling, fastsette datapolicyer og følge bruken på tvers av miljøene. Kilder: Microsoft Learn om managed og unmanaged solutions og Microsoft Learn om pipelines.

Scenario: Salgsdivisjonen endrer et skjema som kundeservice også bruker. Gjøres endringen direkte i produksjon, kan en regel som kundeservice er avhengig av, slutte å virke, og feilen oppdages kanskje først når en kunde klager. Med en kontrollert leveranse samordnes endringen og testes mot behovene i både salg og kundeservice før den settes i produksjon.

Én datamodell for flere divisjoner og selskaper

Store virksomheter kan bestå av flere divisjoner og selskaper med ulike arbeidsprosesser. De kan også operere i flere land og bruke ulike valutaer. Ofte har de likevel de samme kundene. Det vanskelige spørsmålet er hva som skal deles, og hva som skal holdes atskilt. Skal en kunde registreres én gang på tvers av divisjonene, eller én gang per divisjon? Skal rapporteringen være felles?

Valgene påvirker datamodellen og kan være kostbare å gjøre om senere. Når flere divisjoner arbeider med de samme kundene, og kundedata finnes i både CRM og ERP, må det også være avklart hvilket system som er hovedkilden for de ulike kundeopplysningene. CRM bør ikke bli det uten at noen har bestemt det. Se CRM er ikke et masterregister.

Integrasjoner og dataplattform

Når flere deler av virksomheten deler CRM-løsningen, er den som regel koblet til ERP, økonomi og ofte en dataplattform. Integrasjonene bør planlegges som en helhet, ikke som enkeltstående koblinger. Se artiklene om å koble ERP og CRM og om Microsoft Fabric for Dynamics 365.

Når mange skal ta løsningen i bruk

Med flere hundre brukere i ulike regioner og roller krever innføringen en felles plan for forankring i ledelsen, opplæring, støtte og oppfølging av faktisk bruk. Superbrukere i hver divisjon er ofte til god hjelp. Et teknisk godt CRM-system er lite verdt hvis brukerne velger regneark fremfor systemet. Se Endringsledelse for CRM.

AI og agenter gjør styringen viktigere

Her er det nyttig å skille mellom to ting. Når Copilot i Dynamics 365 Sales oppsummerer informasjon om en kunde eller foreslår en e-post, henter den ifølge Microsoft bare informasjon fra poster brukeren selv har tilgang til (Microsoft Learn om Copilot i Sales). Er tilgangene for brede, blir problemet mer synlig, fordi informasjonen blir lettere å finne.

Agenter som utfører handlinger, reiser et annet spørsmål: Hvilken konto bruker agenten, og hvilke tilganger har den? I Copilot Studio kan et verktøy i en agent kobles til med kontoen til den som har satt opp verktøyet. Da kan brukerne av agenten hente informasjon eller utføre handlinger som bare den kontoen har tilgang til. Administratorer kan kreve at verktøyene i stedet bruker sluttbrukerens egen pålogging, per miljø eller miljøgruppe. Med den innstillingen fungerer ikke agenter som kjører i bakgrunnen uten en bruker. Hvilken konto hvert verktøy skal bruke, må derfor avklares når agenten settes opp. Kilde: Microsoft Learn om pålogging for agentverktøy.