Field Service i Power BI: servicemargin på tværs af to systemer

Field Service i Power BI bliver først interessant, når arbejdsordrerne i Dynamics 365 Field Service står ved siden af kost og faktura i Business Central. Field Service ved, hvor lang tid teknikeren brugte og kørte. Business Central ved, hvad reservedelene kostede, og hvad kunden betalte. Servicemarginen pr. kontrakt kræver begge dele i én semantisk model.

Resumé og konklusion

• Business Central Service Management og Field Service er to forskellige ting. Serviceordrer, serviceartikler og servicekontrakter i Business Central er allerede i oneBC365. Field Service ligger i Dataverse og skal hentes som en ny kilde.
• Integrationen flytter pengene, ikke driftsdata. Med Field Service-integrationen bogføres forbrug og faktureres i Business Central. Bookinger, kørselstid og fejltyper bliver i Field Service.
• Kost skal komme fra Business Central. Microsofts opsætning slår kostberegning fra i Field Service, så reservedelenes kost hentes fra vareposterne i Business Central.
• Førstegangsløsning er en definition, ikke et felt. Der findes ingen standardkolonne for det. Den skal beregnes i Curated-laget og skrives ned.
• Ressourcen er den fælles dimension, der oftest mangler. Ressourcer i Business Central kobles til bookable resources i Field Service, og den kobling bærer timer og kørsel.

Business Central Service Management og Field Service i Power BI

Mange Business Central-kunder bruger Service Management i Business Central. Her ligger serviceordrer, serviceartikler, servicekontrakter og serviceposter i samme database som resten af økonomien. oneBC365 har dem allerede i modellen som tabellerne Service Ledger, Service Order, Service Item, Service Contract og Resource Ledger, og rapportsiden Service viser åbne serviceordrer, serviceomsætning og kontraktdækning.

Dynamics 365 Field Service er et andet produkt. Det ligger i Dataverse og er bygget til planlægning og udførelse ude hos kunden: arbejdsordrer, bookinger på en planlægningstavle, kundeaktiver, aftaler og fejltyper. Vælger en virksomhed Field Service til teknikerne, flytter driftsdata ud af Business Central. Pengene gør ikke nødvendigvis.

Grafikken herunder sammenligner, hvor de samme begreber bor i de to løsninger.

Hvad integrationen mellem Field Service og Business Central synkroniserer

Business Central kan integreres med Dynamics 365 Field Service. Det kræver en Dataverse-forbindelse, at integrationen med Dynamics 365 Sales er slået til, og appen Field Service Integration. Ifølge Microsofts vejledning findes der to niveauer:

• Projektintegration. Forbrugte produkter og services på arbejdsordren synkroniseres til projektkladdelinjer i Business Central. Ressourcer kobles til bookable resources (RESOURCE-BOOKABLERSC), og lokationer til lagre.
• Projekt- og serviceintegration. Kræver Premium. Serviceordrer kobles til arbejdsordrer (SRVORDER), serviceartikler til kundeaktiver (SVCITEM-CUSTASSET), serviceartikellinjer til work order incidents og ressourcelinjer til bookinger.

To indstillinger er vigtige for analysen. I Field Service slås Calculate Price og Calculate Cost fra, og Work Order Invoice Creation sættes til Never. Prisen, kosten og fakturaen hører altså hjemme i Business Central. Bruger I integrationen, lander pengesiden i Job Ledger eller Service Ledger, som oneBC365 allerede henter. Det, der mangler, er driftssiden.

Den fælles ressourcedimension

Ressourcen er den dimension, der binder timer, kørsel og kost sammen. Integrationen kobler ressourcer af typen Person i Business Central til bookable resources af typen User i Field Service. Det kræver, at ressourcen har en bruger i feltet Time Sheet Owner User ID på ressourcekortet, og at brugerens e-mail i User Setup svarer til brugeren i Dataverse. Er den kobling ufuldstændig, lander bookinger på unknown member -1, og timerne kan ikke sættes pris på. Tjek den først.

Field Service-tabellerne i Dataverse

Field Service-tabellerne har logiske navne med præfikset msdyn_, mens planlægningstabellerne deles med andre Dynamics 365-apps. Til servicemargin og førstegangsløsning skal I bruge:

• msdyn_workorder: msdyn_serviceaccount, msdyn_agreement, msdyn_primaryincidenttype, msdyn_customerasset, msdyn_completedon og msdyn_systemstatus med værdierne Unscheduled, Scheduled, In Progress, Completed, Posted og Canceled. Den fulde liste står i tabelreferencen for msdyn_workorder.
• bookableresourcebooking: starttime, endtime, duration, msdyn_actualtravelduration og msdyn_workorder. Her ligger tid og kørsel.
• bookableresource: teknikeren eller udstyret, der bookes.
• msdyn_workorderproduct: msdyn_product, msdyn_quantity og msdyn_linestatus, hvor kun Used er forbrug.
• msdyn_workorderincident: msdyn_incidenttype, msdyn_customerasset og msdyn_incidentresolved.
• msdyn_agreement: aftalen med msdyn_startdate, msdyn_enddate og status Estimate, Active, Expired eller Canceled.
• msdyn_customerasset og msdyn_incidenttype: kundens anlæg og fejltypen.

De hentes med Dataverse-connectoren i Power BI på samme vilkår som Sales-data: TDS-endpointet skal være slået til, et forespørgselsresultat må højst fylde 80 MB, og hver forespørgsel har fem minutters timeout. Det er beskrevet i CRM-data i Power BI.

Servicemargin pr. kontrakt med Field Service i Power BI

Servicemargin er indtægt minus kost på en kontrakt. I en virksomhed med Field Service kommer tallene fra to steder. Indtægten og kosten på reservedele kommer fra Business Central. Timerne kommer fra Business Central, hvis de bogføres via integrationen. Kørselstiden ligger i Field Service og bliver ofte aldrig bogført.

Tag en tænkt servicekontrakt over 12 måneder med en indtægt på 240.000 kr. Teknikerne har bogført 118 timer til en kostpris på 520 kr., altså 61.360 kr. Reservedelene har kostet 52.400 kr. efter vareposterne. Så er marginen 126.240 kr. eller 52,6 %.

Lægger I de 41 timers kørsel fra msdyn_actualtravelduration til med samme kostpris, koster det 21.320 kr. mere, og marginen falder til 104.920 kr. eller 43,7 %. Det er næsten ni procentpoint, som ingen af systemerne viser alene.

Bemærk, hvor kontrakten bor. Er kontrakten en servicekontrakt i Business Central, er den nøglen. Er den en msdyn_agreement i Field Service, er der ingen standardmapping til Business Central, og så går vejen gennem arbejdsordren og den koblede serviceordre. Mere om, hvad marginen skal bruges til ved fornyelse, står i servicemargin og kontraktfornyelse.

Grafikken herunder viser regnestykket og hvilket system hver linje kommer fra.

Førstegangsløsning og reservedele

Førstegangsløsning findes ikke som felt. msdyn_workorderincident har msdyn_incidentresolved, men den siger kun, at fejlen blev løst, ikke at det skete ved første besøg. En brugbar definition er: arbejdsordren er Completed med én booking, og der er ingen ny arbejdsordre på samme kundeaktiv og fejltype inden for 30 dage. I eksemplet er 28 ud af 36 arbejdsordrer løst første gang, altså 78 %.

Reservedele hænger sammen med førstegangsløsning. Manglede delen i bilen, kommer der et besøg mere. Vareposterne i Business Central viser, hvad der blev brugt og fra hvilket lager, og det kan kobles til de arbejdsordrer, der krævede et ekstra besøg. Brug kun linjer med msdyn_linestatus Used. Linjer med Estimated er et skøn fra planlægningen og ikke forbrug.

Omvendt koster et fyldt servicelager i bilerne kapital. Det er den afvejning, lagerstyring og likviditet handler om, og med førstegangsløsning pr. vare kan den tages på et tal i stedet for en fornemmelse.

Sådan sætter du det op i Power BI

1. Byg en Base-kæde for Field Service. Én forespørgsel pr. tabel med erklærede kolonner. Filtrér bookinger og arbejdsordrer på dato fra første dag.
2. Beregn i Enriched. Oversæt msdyn_systemstatus til tekst, omregn duration og msdyn_actualtravelduration fra minutter til timer, tilføj CalendarDateID, surrogatnøgler og unknown member -1.
3. Saml dimensionerne i Curated. Resource får bookableresourceid fra koblingen, Service Item får msdyn_customerassetid, og Customer får accountid. Førstegangsløsning beregnes her som et flag pr. arbejdsordre.
4. Hent koblingerne. Koblingerne ligger i Business Centrals tabel CRM Integration Record og skal eksponeres på en API-side, før Power Query kan bruge dem.
5. Skriv definitionerne i modellen. Servicemargin med og uden kørsel og førstegangsløsning skal have en beskrivelse, så Copilot og andre agenter svarer ud fra samme definition.

Hvad Field Service i Power BI ikke løser

Modellen er ikke en planlægningstavle. Data er så friske som seneste opdatering, og på Power BI Pro er det op til otte planlagte opdateringer om dagen. Dispatch og status i dag hører hjemme i Field Service.

Kørselstid er kun så god som registreringen. Er msdyn_actualtravelduration tom på halvdelen af bookingerne, er marginen med kørsel et skøn. Mål udfyldningsgraden, før tallet vises til ledelsen, som beskrevet i datakvalitet målt i Power BI.

Og licenserne følger med. Projekt- og serviceintegrationen kræver Premium i Business Central, og Field Service kræver sine egne licenser. Store mængder bookinger og tidsregistreringer over mange år kan ramme grænserne i Dataverse-connectoren, og så er Link to Microsoft Fabric med en kapacitet det næste skridt.

Sådan understøtter oneBC365 det

oneBC365 har service med som et af ni moduler: Service Ledger, Service Order, Service Item, Service Contract og Resource Ledger er i modellen, og bruger I ikke service, slås området fra i RefreshConfig. Field Service er ikke med som standard, men oneBC365 kan lægge den ind som en udvidelse af modellen, aftalt og estimeret pr. kilde (se services). Bruger I integrationen, er pengesiden allerede i Job Ledger eller Service Ledger, og Field Service tilføjes som en ny kæde af Base, Enriched og Curated med ressource, kunde, aktiv og dato som fælles dimensioner. Hvordan de fire lag hænger sammen, står i semantisk lag i Power BI.

Det er samme mønster, som dataplatform-leverandørerne bygger i en lakehouse. Her ligger det i Power BI’s semantiske lag, kører på Pro-licenser og kræver ingen Fabric-kapacitet til rapporteringen. Løsningen ligger som PBIP i Git med kommenteret M-kode, I ejer koden, og jeres BC-partner kan vedligeholde den. Kræver volumen eller realtid mere, kan lagene flyttes til Dataflows Gen2 eller en Fabric Lakehouse, mens rapporterne bliver stående.

Sådan kommer du i gang

1. Afklar, hvor kontrakten bor. Servicekontrakt i Business Central eller aftale i Field Service. Svaret bestemmer nøglen for hele servicemarginen.
2. Tjek integrationsniveauet. Kun projektintegration eller også serviceintegration? Se, hvilke integrationstabeller der er aktive i Business Central.
3. Mål kørselsregistreringen. Tæl, hvor stor en andel af bookingerne de seneste tre måneder der har msdyn_actualtravelduration udfyldt.
4. Skriv definitionen af førstegangsløsning. Én sætning med antal besøg og antal dage. Få servicechefen til at godkende den, før den bygges.

Relaterede artikler

• CRM-data i Power BI: Dynamics 365 Sales og Business Central i én model
• Semantisk lag i Power BI: 4 lag med samme struktur som en dataplatform
• Planlægningsdata i Power BI: plan mod faktisk på tværs af systemer
• Servicemargin og kontraktfornyelse: 3 tal der gør service til et forretningsområde
• Kundeservice nøgletal: 3 tal der gør reklamationer til kundefastholdelse

Vil I se, hvordan servicemarginen ser ud på jeres egne tal fra Business Central? Book en demo, så viser vi det live på 30 minutter.