Hvad har du egentligt købt?

Jeg havde for nylig en af de samtaler med en kunde, som bliver hængende bagefter. Hvad køber en kunde egentlig, når de køber en Dynamics 365 Customer Engagement-applikation?

Vi talte om Dynamics 365 Sales, og et sted i forklaringen blev det tydeligt, at der er to meget forskellige ting, en kunde kan ende med. Den ene er den standardapplikation fra Microsoft, som de troede, de havde købt. Den anden er en custom applikation, bygget på samme platform, med nogle af de samme tabeller, nogle af de samme idéer og måske endda samme navn i daglig tale.

Den forskel gjorde kunden bekymret. Ikke fordi tilpasning automatisk er forkert, men fordi det rejste et meget praktisk spørgsmål: havde de fået leveret det, som de troede, de havde købt, og hvad er konsekvensen fremadrettet?

På papiret kan de to ting lyde tæt på hinanden. I praksis er de meget forskellige. For når en kunde køber fx Dynamics 365 Sales, hvad køber de så egentlig? Køber de et SaaS-produkt fra Microsoft med en stor mængde standardfunktionaliteter, et roadmap, release waves, forbedringer, funktioner og features? Eller køber de en custom CRM-applikation, som er afhængig af en partner til at fortolke, genopbygge, eksponere og vedligeholde det, Microsoft allerede leverer?

Det er ikke en lille og uskyldig forskel. Det er to vidt forskellige produkter, hvor kunden ofte ikke ved de køber noget og får noget andet.

Produktet kan forsvinde stille og roligt

De fleste kunder køber ikke Dynamics 365, fordi de ønsker, at nogen starter fra et blankt stykke papir. Hvis ambitionen er et blankt stykke papir, er Power Platform ofte det rigtige sted at starte. Det er en stærk platform til at bygge forretningsapplikationer. Men det er noget helt andet end at købe et produkt, der allerede er bygget, testet og dokumenteret.

Dynamics 365 er nemmere at købe og nemmere at sælge, fordi det er et færdigt produkt, der løser et kendt forretningsproblem. Salg, kundeservice, field service, marketing, finance, supply chain. Det er ikke et blankt kanvas. Det er standardfunktionalitet, standardprocesser og et produkt-roadmap.

Kunden køber det, fordi det allerede er et produkt. Det har salgsprocesser, account og contact management, leads, opportunities, aktiviteter, forecasting, dashboards, Copilot-funktionalitet, integrationsmuligheder, sikkerhed, mobil adgang og meget andet, som er udviklet, testet, dokumenteret og forbedret over tid.

Selvfølgelig skal produktet tilpasses. Ingen seriøs implementering er bare "tænd for det og håb det virker." Der er virksomhedsspecifikke processer, begreber, datamodeller, integrationer, roller, rapporteringsbehov og ikke mindst adoption.

Men der er forskel på at tilpasse produktet og erstatte det og den forskel kan meget hurtigt blive uklar.

• En konsulent siger måske: "Vi gør brugeroplevelsen mere simpel."
• En anden siger måske: "Standardappen har for meget i sig."
• En tredje siger måske: "Det er nemmere, hvis vi bygger vores egen app."

Nogle gange har de ret. Nogle gange er en fokuseret custom app præcis det, forretningen har brug for. Men nogle gange forsvinder standardproduktet, før kunden overhovedet har set, hvad det kan. Så har kunden reelt ikke fået Dynamics 365 Sales. De har fået partnerens version af, hvad Dynamics 365 Sales kan være.

Standard først betyder ikke standard altid

Jeg mener ikke man skal have standard bare for at have standard, men det er min klare overbevisning, at der er værdi i at tilpasse sig til standard så vidt muligt.

En forretningsapplikation skal dog understøtte den måde, mennesker faktisk arbejder på. Hvis systemet tvinger organisationen ind i en proces, der ikke passer til forretningen, har vi ikke skabt værdi. Så har vi bare leveret en "død" applikation der ikke hjælper med det organisationen efterspurgte.

Men den modsatte fejl er lige så reel. Hvis vi tvinger applikationen til at blive noget, den ikke er, mister vi også værdi. En standardapplikation har en intern logik. Den har funktioner, antagelser og mønstre, som er der af en grund. Pointen er ikke blindt at underkaste sig produktet, men at forstå det godt nok til at bruge dets styrker, før vi bygger udenom dem. 

Jeg tror på standard først. Standard først betyder, at applikationen er udgangspunktet. Det betyder, at kunden får mulighed for at forstå, hvad produktet allerede indeholder, før vi beslutter at skjule, ændre, udvide eller erstatte dele af det.

Det betyder, at vi spørger:

• Hvad kan standardappen allerede som passer til jer? 
• Hvad kan konfigureres uden at ødelægge produktmodellen?
• Hvilke krav er reelle forretningsbehov?
• Hvilke krav er gamle vaner fra det tidligere system?
• Hvor skaber tilpasning værdi?
• Hvor skaber tilpasning afhængighed?

Det sidste spørgsmål er ofte det vigtigste. For tilpasning er ikke kun en leverancebeslutning. Det er en ejerskabsbeslutning.

Den skjulte afhængighed

Den synlige pris for custom udvikling er nem at forstå. Nogen skal designe det, bygge det, teste det, dokumentere det og supportere det. Den skjulte pris viser sig senere.

Microsoft frigiver nye funktioner. Produktet udvikler sig. En capability dukker op, som kan hjælpe sælgere, ledere, kundeservice, rapportering, forecasting eller samarbejde. I en normal SaaS-tankegang bør kunden kunne spørge: "Er det her relevant for os, og skal vi slå det til?" Men i en tungt customiseret app bliver spørgsmålet et andet.

Det bliver:

• Vises denne feature overhovedet i vores app?
• Virker den med de formularer og den navigation, vi har bygget?
• Skaber den konflikter med vores custom proces?
• Skal vi bruge en partner for at gøre den tilgængelig?
• Bliver aktivering af den et lille projekt?

Det er her, den kommercielle virkelighed ændrer sig. Kunden betaler stadig for et SaaS-produkt. Men vejen til ny værdi går nu gennem custom levering. I stedet for at Microsoft løbende forbedrer den applikation, kunden bruger, forbedrer Microsoft standardproduktet et sted i nærheden, og kunden må spørge, om deres custom version kan følge med. Det er en helt anden aftale, end mange kunder tror, de indgår.

Hvad du som kunde bør spørge om

Kunder behøver ikke blive solution architects for at beskytte sig selv. Men de bør stille bedre spørgsmål tidligt.
Spørgsmål som:

• Starter vi fra standard Dynamics 365 Sales-appen?
• Hvilke standardfeatures bruger vi, skjuler vi eller undlader vi at konfigurere?
• Hvilke dele af løsningen er standardkonfiguration, og hvilke dele er custom?
• Hvad sker der, når Microsoft frigiver nye Sales-features?
• Dukker de features naturligt op, eller kræver de partnerarbejde?
• Forenkler vi standardappen, eller genopbygger vi den?
• Hvilken afhængighed skaber vi for fremtidige ændringer?

Det er ikke fjendtlige spørgsmål. Det er sunde governance-spørgsmål. De hjælper alle med at træffe bedre beslutninger. Vi som partner får også noget ud af det, fordi samtalen bliver mere ærlig. En custom app kan være den rigtige anbefaling, men så skal den anbefales som et bevidst arkitekturvalg, ikke som en standard leverancevane.

Hvordan skulle kunden vide det?

Der er en ubekvem del af denne diskussion: mange kunder ved ikke, at de bør stille de spørgsmål og hvordan skulle de også vide det?

De er ikke Dynamics 365-specialister. De kender ikke nødvendigvis forskellen på Sales Hub-appen, en model-driven app, Dataverse-konfiguration, custom tabeller, custom formularer, command changes eller custom sikkerhedslogik. De ved bare, at de har købt Dynamics 365 Sales og forventer, at hvem end de vælger som partner leverer Dynamics 365 Sales.
Derfor kan ansvaret ikke kun ligge hos kunden.

Partnere bør gøre forskellen synlig. De bør forklare, hvornår implementeringen bruger standardappen, hvornår den tilpasser standardappen, og hvornår den bevæger sig over i en custom applikation. Den forklaring bør være en del af solution design, scope, governance og handover.

Kunden bør ikke opdage den forskel ved et tilfælde i en workshop som min kunde gjorde.

Hvad god rådgivning kræver

For mig handler god Dynamics 365-rådgivning ikke om at bygge mest muligt. Det handler om at vide, hvornår man ikke skal bygge. Det handler om at forstå produktet godt nok til at bruge det, der allerede findes, og forstå forretningen godt nok til at vide, hvornår standardproduktet ikke er nok. Det kræver mere disciplin end at starte fra bunden. Man skal kende standardappen. Man skal kunne forklare trade-offs. Man skal kunne udfordre krav uden at affeje de mennesker, der har rejst dem. Man skal kunne skelne mellem reel forretningsdifferentiering og historisk systemadfærd.

Og man skal være villig til at sige: "Ja, vi kan godt tilpasse det. Men bør vi?" Det spørgsmål kan spare en kunde for flere års unødvendig afhængighed.

Saas-værdi før projektbekvemmelighed

Alle implementeringer foregår under praktiske begrænsninger. Der er tidsplaner, workshops, budgetter, holdninger, legacy-processer, dataproblemer, integrationer og mennesker, der har brug for, at systemet virker mandag morgen. Når alt det skal balanceres, kan det føles praktisk at bygge en custom app, der kun viser det, projektet har brug for lige nu. Men som kunde har du ikke kun købt en go-live. Du har købt et produkt, som bør blive ved med at blive bedre, efter projektteamet er gået.
Det er SaaS-værdien. Ikke at alt er perfekt out of the box, men at produktet bevæger sig videre, og at du som kunde kan bevæge dig med.

Fra mit perspektiv er det simpelt: Giv kunden produktet først. Tilpas med omtanke og inkluder kunden i beslutningen. Målet er ikke at undgå tilpasning. Målet er at sikre, at tilpasning understøtter produktet i stedet for at erstatte det. For hvis en kunde køber Dynamics 365 Sales, bør de ikke senere opdage, at det, de reelt fik, var en custom CRM-applikation med et Dynamics-logo i nærheden. 

De bør få det, de har købt.