Microsoft Dynamics 365 CRM-udvikling bliver sjældent kaldt udvikling, når projektet starter. Det hedder “opsætning” eller “tilpasning”, og det er netop dér, budgetterne skrider: grænsen mellem konfiguration og reel udvikling er uklar, indtil nogen har krydset den.
Kort sagt
- Konfigurér alt, hvad der kan konfigureres. Hver linje kode er noget, I skal vedligeholde gennem hver opdatering.
- Dynamics 365 er flere produkter. Afklar om I taler om Sales, Customer Service, Field Service eller Finance.
- Den største risiko er ikke CRM’et. Det er integrationen til ERP, web og e-mail.
- Datakvalitet afgør, om systemet bliver brugt. Dubletter dræber tilliden hurtigere end manglende funktioner.
- Microsoft opdaterer to gange om året. Tilpasninger skal kunne overleve det.
- Uden en ejer i forretningen bliver CRM’et et dyrt kartotek.
Hvad “Dynamics 365” dækker over
Dynamics 365 er ikke ét system. Sales håndterer pipeline og tilbud. Customer Service håndterer sager og SLA’er. Field Service håndterer teknikere og planlægning. Finance og Supply Chain er ERP. De licenseres hver for sig og kan tages i brug hver for sig.
Når nogen siger “vi skal have Dynamics CRM”, mener de næsten altid Sales, Customer Service eller begge. Få det afklaret først — det ændrer både pris og projektets form.
Konfiguration, udvidelse eller kode
Konfiguration er felter, formularer, visninger, business rules og flows. Det klarer en dygtig konsulent uden kode, og det overlever opdateringer uden arbejde.
Lav-kode udvidelser er Power Automate og Power Apps. Passer til arbejdsgange på tværs af systemer og til små brugerflader oven på data, I allerede har.
Kode er plugins og custom API’er. Nødvendigt når logikken skal køre serverside, hver gang, uanset hvem der gemmer posten. Det er også dét, der skal testes igen ved hver opdatering.
Reglen vi arbejder efter: skriv kun kode, når reglen skal gælde altid og ikke kan brydes af en bruger. Alt andet konfigureres.
Integrationer er den reelle opgave
Et CRM alene er sjældent værdifuldt. Værdien opstår, når det kender ordrerne fra ERP, henvendelserne fra hjemmesiden og korrespondancen fra Outlook.
Beslut for hver integration, hvem der ejer posten, om opdateringen er realtid eller batch, og hvad der sker ved fejl. Skal CRM’et tale med Business Central, er det et projekt for sig — se Business Central-udvikling — og selve grænsefladen hører under API-udvikling.
Data afgør, om systemet bliver brugt
Den hyppigste årsag til, at et CRM bliver forladt, er ikke manglende funktioner. Det er, at sælgeren søger en kunde og får tre resultater, hvoraf ingen er opdaterede.
Ryd op i data inden migrering, ikke efter. Definér hvad en dublet er, hvem der må oprette kunder, og hvilke felter der er obligatoriske. Det er kedeligt arbejde og det vigtigste i hele projektet.
Opdateringer to gange om året
Microsoft udsender større opdateringer i april og oktober. Tilpasninger, der bygger på udokumenterede detaljer, går i stykker her. Aftal hvem der tester i sandkassen inden hver bølge, og hold en liste over jeres tilpasninger, så I ved hvad der skal testes.
Har I arvet et system med tilpasninger, ingen kan forklare, er en kodeaudit den hurtigste vej til et overblik.
Sådan arbejder vi
Vi leverer Microsoft CRM-udviklingstjenester fra konfiguration til plugins og integrationer, og kan stille Dynamics 365-udviklere til rådighed enkeltvis, hvis I allerede har et team og mangler bestemte kompetencer.
Ofte stillede spørgsmål
Otte til sekstende uger for Sales eller Customer Service med et par integrationer. Datamigrering og oprydning er den faktor, der oftest flytter tidsplanen.
Ja, og det er som regel den rigtige rækkefølge. Tag standard i brug, lad brugerne arbejde i det i et kvartal, og tilpas så det, der reelt generer — ikke det, nogen troede ville genere.
Licens per bruger per måned varierer med app og niveau. Tæl brugerne per rolle, ikke samlet — mange organisationer har få, der skal have fuld adgang, og mange, der kun skal læse.
Til arbejdsgange, ofte ja. Til regler der skal gælde hver gang og ikke må kunne omgås, nej. Brug det til det første og kode til det andet.
Det korte svar
Afklar hvilket Dynamics-produkt I taler om, konfigurér frem for at kode, behandl hver integration som sit eget projekt, og ryd op i data inden migrering. Så bliver opdateringerne to gange om året en rutine frem for en risiko.
Skal vi se på jeres opsætning? Skriv til os eller book et møde.
