WEBVTT

00:00:00.000 --> 00:00:05.660
Een verkoper werkt een klantadres bij. Later opent financiën hetzelfde dossier en ziet nog steeds het oude adres.

00:00:05.880 --> 00:00:07.280
Dus, welk adres is het juiste?

00:00:07.480 --> 00:00:13.140
Jarenlang betekende dit dat iemand gegevens moest exporteren, een spreadsheet bewerken, e-mailen en dezelfde update twee keer in een tweede app moest typen.

00:00:13.320 --> 00:00:15.920
Dynamics 365 Jewelright verandert dat.

00:00:16.060 --> 00:00:23.020
Het verbindt financiële en operationele apps met klantapps op basis van dataversen, zodat gedeelde records zoals klanten en orders automatisch synchroon blijven.

00:00:23.180 --> 00:00:28.920
Je bent bij mij, ik ben Milko Peters van M365FM en dit kennisfragment legt Jewelright in begrijpelijke taal uit.

00:00:28.920 --> 00:00:33.220
We bespreken wat er verplaatst, hoe het verplaatst, waar Jewelright past en waar het niet past.

00:00:33.400 --> 00:00:37.080
Laten we eerst beginnen met het zakelijke probleem dat de behoefte hieraan creëerde.

00:00:38.300 --> 00:00:40.220
Het probleem dat Jewelright oplost.

00:00:40.760 --> 00:00:45.700
Stel je een bedrijf voor waar twee groepen aan dezelfde klant werken, maar dagelijks totaal verschillende apps gebruiken.

00:00:46.020 --> 00:00:48.600
Financiële en operationele apps verzorgen het backoffice werk.

00:00:48.800 --> 00:00:52.400
Dat gaat over geld, voorraad, producten, orders, inkoop en de toeleveringsketen.

00:00:52.600 --> 00:00:57.380
Dit is waar een bedrijf bijhoudt wat het verkoopt, wat het kan leveren, wat het verschuldigd is en wat een klant moet betalen.

00:00:57.380 --> 00:00:59.940
Klant apps richten zich op werk dichter bij de klant.

00:01:00.300 --> 00:01:02.440
Verkoopteams volgen leads en creëren kansen.

00:01:02.720 --> 00:01:04.540
Klantenservice behandelt vragen en cases.

00:01:04.880 --> 00:01:07.560
Vield service plant taken en stuurt mensen naar locaties.

00:01:07.800 --> 00:01:10.100
Projectteams volgen het werk dat aan een klant is beloofd.

00:01:10.240 --> 00:01:11.900
Ander werk vereist andere schermen.

00:01:12.020 --> 00:01:16.680
Een verkoper hoeft niet door een financieel scherm te spitten om enkel een contactpersoon bij te werken na een telefoontje.

00:01:16.840 --> 00:01:21.420
Maar een financiële gebruiker heeft klant- en ordergegevens nodig die overeenkomen met wat sales ziet,

00:01:21.560 --> 00:01:24.020
want facturen en leveringen hangen af van die informatie.

00:01:24.020 --> 00:01:26.960
Zonder verbinding wordt één klant stilletjes twee records.

00:01:27.200 --> 00:01:31.660
Sales noteert misschien Northwind Bike, terwijl financiën Northwind Bicycle Company noteert.

00:01:31.800 --> 00:01:36.200
Oh, het ene dossier heeft het nieuwe adres, het andere stuurt facturen nog naar het oude kantoor.

00:01:36.420 --> 00:01:40.680
Beide dossiers zien er op zichzelf logisch uit, maar ze beschrijven niet langer dezelfde zakelijke relatie.

00:01:40.860 --> 00:01:42.460
Eerst duiken kleine problemen op.

00:01:42.620 --> 00:01:45.440
Iemand kan een klant niet vinden omdat de naam in een andere app anders is.

00:01:45.620 --> 00:01:50.040
Een verkoper belooft een prijs of controleert de voorraad, maar de informatie komt niet overeen met de operationele kant.

00:01:50.040 --> 00:01:54.640
Financiën moet een order verwerken, maar de klantgegevens vereisen een check, een e-mail en nog een handmatige update.

00:01:54.900 --> 00:01:56.780
Vervolgens stapelen die kleine problemen zich op.

00:01:56.960 --> 00:01:59.120
Iemand exporteert klantgegevens naar een spreadsheet.

00:01:59.420 --> 00:02:02.180
Een ander corrigeert een paar rijen en importeert ze ergens anders.

00:02:02.440 --> 00:02:06.440
Weer iemand anders voert een nieuwe klant in beide apps in omdat niemand weet welk record als eerste verschijnt.

00:02:06.600 --> 00:02:11.340
Al snel zijn er duplicaten, verschillende adressen en wordt er meer tijd besteed aan het controleren van data dan aan het gebruiken ervan.

00:02:11.560 --> 00:02:13.260
Dit gebeurt niet omdat mensen slordig zijn.

00:02:13.440 --> 00:02:16.000
Het gebeurt omdat de systemen van mensen vragen om de verbinding te zijn.

00:02:16.220 --> 00:02:17.460
Mensen kopiëren gegevens.

00:02:17.460 --> 00:02:19.300
Mensen onthouden welke app eerst komt.

00:02:19.520 --> 00:02:21.860
Mensen zien fouten pas als ze al een ander team hebben bereikt.

00:02:22.060 --> 00:02:25.700
Die aanpak werkte toen bedrijfssystemen gescheiden bleven en teamsvertragingen accepteerden.

00:02:25.860 --> 00:02:32.180
Maar als verkoop, service, financiën en operations gedurende de dag allemaal dezelfde klantinformatie nodig hebben, is een spreadsheet een gebrekkig hulpmiddel voor overdracht.

00:02:32.380 --> 00:02:34.240
Denk aan een eenvoudig gesprek over een bestelling.

00:02:34.440 --> 00:02:38.100
Een klant belt de verkoopafdeling en vraagt, hoe kunnen jullie volgende week leveren en wat gaat dat kosten?

00:02:38.820 --> 00:02:39.180
Aanhalingsteken.

00:02:39.340 --> 00:02:42.740
Het verkoopteam heeft product, prijs en voorraadgegevens nodig om antwoord te geven.

00:02:42.740 --> 00:02:48.200
Zodra de klant akkoord gaat, hebben financiën en operations de juiste klant- en bestelgegevens nodig om de verkoop te verwerken.

00:02:48.420 --> 00:02:50.260
Beide kanten hebben dezelfde feiten nodig.

00:02:50.500 --> 00:02:53.140
Verkoop heeft die feiten nodig in de app waar verkopers werken.

00:02:53.460 --> 00:02:57.840
Financiën en operations hebben ze nodig in de app waar zij bestellingen, geld en levering beheren.

00:02:57.960 --> 00:03:00.980
Het doel is niet om elk team in één gigantisch scherm te dwingen.

00:03:01.140 --> 00:03:04.720
Het doel is dat gedeelde records een duidelijke, afgesproken route volgen.

00:03:04.960 --> 00:03:06.740
Dat is waar Jewelright in beeld komt.

00:03:07.120 --> 00:03:08.300
Wat is Jewelright eigenlijk?

00:03:08.640 --> 00:03:10.240
Dus, wat is Jewelright precies?

00:03:10.240 --> 00:03:12.120
Dit is de eenvoudigste definitie.

00:03:12.320 --> 00:03:19.480
Jewelright is de ingebouwde verbinding van Microsoft die geselecteerde gegevens synchroniseert tussen Dynamics 365 Finance & Operations apps en Dataverse.

00:03:19.820 --> 00:03:23.240
Dataverse is de gedeelde gegevensfundering achter veelzakelijke Microsoft apps.

00:03:23.480 --> 00:03:28.380
Dynamics 365 Sales, Customer Service, Field Service en delen van project operations maken er allemaal gebruik van.

00:03:28.540 --> 00:03:30.760
Power Apps en Power Automate kunnen het ook gebruiken.

00:03:30.920 --> 00:03:34.400
Je hoeft niet te weten hoe Dataverse elk afzonderlijk record opslaat om Jewelright te begrijpen.

00:03:34.620 --> 00:03:38.480
Zie het gewoon als het gemeenschappelijke gegevensgebied aan de kant van de klant-apps van Dynamics 365.

00:03:38.480 --> 00:03:41.820
Stel je een kantoorgebouw voor met een front-office en een back-office.

00:03:42.000 --> 00:03:47.480
De front-office regelt de gesprekken met klanten, verkopers, servicemedewerkers, buitendienstmedewerkers.

00:03:47.700 --> 00:03:52.080
Zij hebben allemaal schermen nodig die hen helpen met mensen te praten, verzoeken te volgen en werk te beheren.

00:03:52.200 --> 00:03:54.740
De back-office regelt het werk dat het bedrijf draaiende houdt.

00:03:54.860 --> 00:03:58.520
Onze financiële administratie, voorraad, bestellingen, inkoop, levering.

00:03:58.720 --> 00:04:04.340
Beide kantoren werken voor hetzelfde bedrijf, maar zonder een goede verbinding tussen hen moet iemand informatie van de ene naar de andere kant brengen.

00:04:04.340 --> 00:04:08.520
Ze nemen een geprint formulier mee, sturen een e-mail of kopiëren gegevens naar een ander systeem.

00:04:08.640 --> 00:04:12.360
Het werk wordt nog steeds gedaan, maar het duurt langer en details kunnen onderweg veranderen.

00:04:12.540 --> 00:04:15.360
Jewel Right is als een bemande binnendeur tussen die twee kantoren.

00:04:15.620 --> 00:04:20.680
Wanneer een ondersteund record aan de ene kant verandert, geeft Jewel Right de bijbehorende wijziging via die deur door aan de andere kant.

00:04:20.860 --> 00:04:23.220
Het combineert niet elke app tot één gigantische app.

00:04:23.360 --> 00:04:24.820
Sales kan nog steeds in sales werken.

00:04:25.020 --> 00:04:26.680
Finance kan nog steeds in finance werken.

00:04:26.880 --> 00:04:31.120
Elk team behoudt de schermen voor het eigen werk, terwijl geselecteerde gedeelde informatie achter de schermen verbonden blijft.

00:04:31.120 --> 00:04:32.880
Dat woord ondersteund is belangrijk.

00:04:33.140 --> 00:04:36.340
Jewel Right kopieert niet blindelings elk stukje data in beide systemen.

00:04:36.480 --> 00:04:39.840
Het werkt via gedefinieerde verbindingen tussen records die bij elkaar horen.

00:04:40.060 --> 00:04:42.300
Microsoft noemt deze verbindingen tabelmappings.

00:04:42.580 --> 00:04:45.560
Een tabel is simpelweg een plek waar een app één type record opslaat.

00:04:45.720 --> 00:04:47.580
Een klantentabel slaat klanten records op.

00:04:47.720 --> 00:04:49.600
Een producttabel slaat product records op.

00:04:49.700 --> 00:04:51.660
Een adreestabel slaat adresgegevens op.

00:04:51.800 --> 00:04:56.680
Een tabelmapping vertelt Jewel Right welke tabel in finance en operations gekoppeld is aan welke tabel in dataverse.

00:04:56.860 --> 00:04:59.200
Zie een tabelmapping als een overeengekomen vertaalblad.

00:04:59.200 --> 00:05:01.680
De ene kolom identificeert een record aan de ene kant.

00:05:01.860 --> 00:05:04.720
De andere kolom identificeert het bijbehorende record aan de andere kant.

00:05:04.900 --> 00:05:07.400
De rest van het blad legt uit welke velden bij elkaar horen.

00:05:07.580 --> 00:05:09.820
Onze naam, telefoonnummer, adresregel.

00:05:10.020 --> 00:05:11.200
Die afspraak levert de verbindingsregels.

00:05:12.080 --> 00:05:15.900
Zonder dat zouden twee apps verschillende labels kunnen gebruiken of dezelfde gegevens op verschillende plekken opslaan.

00:05:16.040 --> 00:05:18.740
Een mapping vertelt Jewel Right hoe die details zich tot elkaar verhouden.

00:05:18.960 --> 00:05:21.480
Zo hoeven de apps niet telkens door een persoon geïnterpreteerd te worden.

00:05:21.720 --> 00:05:26.440
Mensen horen de naam Jewel Right vaak en gaan ervan uit dat elke wijziging altijd beide kanten opgaat.

00:05:26.440 --> 00:05:32.620
Soms is dat ook zo. Bij een ondersteunde tweerichtingsmapping kan een wijziging in dataverse het gerelateerde record in finance en operations bijwerken.

00:05:32.760 --> 00:05:36.880
Een ondersteunde wijziging in finance en operations kan ook het gerelateerde record in dataverse bijwerken.

00:05:37.100 --> 00:05:39.400
Beide kanten kunnen deelnemen aan hetzelfde gedeelde record.

00:05:39.640 --> 00:05:40.900
Dat is het Jewel gedeelte.

00:05:41.080 --> 00:05:42.820
De update gebeurt bijna in realtime.

00:05:43.020 --> 00:05:46.920
Het gaat snel terwijl mensen werken in plaats van te wachten op een geplande taak die s'nachts draait.

00:05:47.100 --> 00:05:52.100
Een gebruiker werkt een ondersteund record bij en de verbinding verstuurt die update terwijl het werk nog actueel is.

00:05:52.360 --> 00:05:54.780
Bijna realtime betekent geen magie of nul vertraging.

00:05:54.780 --> 00:05:59.260
Het betekent dat de verbinding gebouwd is voor live zakelijk werk, niet voor een dagelijkse bestandsuitwisseling.

00:05:59.400 --> 00:06:03.200
Als iemand een detail wijzigt, hoeft het gerelateerde team niet tot morgenochtend te wachten om het te zien.

00:06:03.400 --> 00:06:05.200
Dat verandert de manier waarop teams kunnen werken.

00:06:05.380 --> 00:06:07.800
De frontoffice kan data gebruiken die uit de backoffice komt.

00:06:07.980 --> 00:06:10.920
De backoffice kan ondersteunde updates ontvangen van klantgerichte apps.

00:06:11.340 --> 00:06:16.620
Dataverse wordt de datafundering aan de ene kant, finance en operations blijft de operationele fundering aan de andere kant...

00:06:16.620 --> 00:06:18.860
...en Jewel Right houdt de goedgekeurde gedeelde records verbonden.

00:06:19.020 --> 00:06:21.260
Toch heeft een live interne deurregels nodig.

00:06:21.260 --> 00:06:26.040
Voordat je een record in beide richtingen laat reizen, moet je weten waar dat record moet beginnen...

00:06:26.040 --> 00:06:29.660
...wie het mag wijzigen en welke kant leidend moet zijn als de twee apps het niet is zijn.

00:06:29.920 --> 00:06:32.820
Welke gegevens kunnen worden verplaatst en welk systeem beheert ze?

00:06:33.020 --> 00:06:35.460
Dus, welke records kan Jewel Right verbonden houden?

00:06:35.680 --> 00:06:39.340
De algemene voorbeelden beginnen met de records die veel afdelingen dagelijks delen.

00:06:39.340 --> 00:06:46.920
Klantgegevens, adressen, contactpersonen, producten, leveranciers, bedrijfsgegevens en referentie informatie voor financiën en belastingen.

00:06:47.180 --> 00:06:48.920
Denk eens even na over een klantrecord.

00:06:49.220 --> 00:06:54.040
Sales heeft de naam van de klant, de hoofdcontactpersoon, het telefoonnummer en het afleveradres nodig.

00:06:54.300 --> 00:06:59.040
Finance heeft het juridische klantrecord, factuurgegevens en informatie voor orders en facturen nodig.

00:06:59.040 --> 00:07:04.980
Als elke afdeling een eigen aparte klantenlijst bijhoudt, besteedt het bedrijf tijd aan het vergelijken van records in plaats van het bedienen van de klant.

00:07:05.120 --> 00:07:08.800
Met de juiste Jewel Right Maps kunnen die teams werken met gekoppelde klantgegevens.

00:07:08.800 --> 00:07:12.140
Dat betekent niet dat salesgebruikers plotseling de finance-app moeten leren.

00:07:12.340 --> 00:07:19.860
Het betekent dat zij met klantinformatie in Dynamics 365 sales kunnen werken, terwijl financegebruikers met de gerelateerde klantinformatie in finance werken.

00:07:20.060 --> 00:07:23.140
De klant blijft op beide plaatsen herkenbaar als dezelfde klant.

00:07:23.320 --> 00:07:24.680
Adressen zijn ook belangrijk.

00:07:24.680 --> 00:07:29.660
Een klant kan een factuuradres, een afleveradres en misschien een locatie hebben waar een servicemedewerker langs moet gaan.

00:07:29.900 --> 00:07:34.800
Deze details kunnen niet zomaar als platte tekst in één vakje worden gekopieerd, omdat elk adres een andere functie heeft.

00:07:35.040 --> 00:07:38.200
Jewel Right ondersteunt de gedeelde recordstructuur die nodig is voor die relatie.

00:07:38.200 --> 00:07:40.260
Contactpersonen volgen hetzelfde patroon.

00:07:40.420 --> 00:07:44.440
Een klantbedrijf kan een inkoper, een contactpersoon voor crediteuren en een servicemanager hebben.

00:07:44.680 --> 00:07:46.460
Sales moet weten wie de beslissingen neemt.

00:07:46.640 --> 00:07:48.820
Finance moet weten waar factuurvragen naartoe moeten.

00:07:49.100 --> 00:07:50.920
Service moet weten wie er op locatie wacht.

00:07:51.120 --> 00:07:56.140
Gekoppelde records helpen elk team de mensen te zien die bij de klant horen, zonder die informatie in elke app opnieuw te hoeven invoeren.

00:07:56.340 --> 00:07:58.160
Producten zijn een ander algemeen voorbeeld.

00:07:58.160 --> 00:08:02.880
Een verkoper moet weten wat het bedrijf verkoopt, wat het product kost en of voor voorraad beschikbaar is.

00:08:03.060 --> 00:08:08.660
Die antwoorden komen meestal van de operationele kant van het bedrijf, omdat daar product, voorraad, inkoop en uitvoering worden beheerd.

00:08:08.900 --> 00:08:11.880
Daarom begint productinformatie vaak in finance en operations.

00:08:12.260 --> 00:08:14.960
Een operatieteam maakt en bereidt daar een product voor.

00:08:15.200 --> 00:08:20.960
Zodra dat product klaar is voor klantgericht werk, kan Jewel Right de gerelateerde productdetails naar dataverse sturen.

00:08:21.440 --> 00:08:27.240
Salesgebruikers kunnen vervolgens het product in hun eigen app selecteren en bespreken zonder dat iemand de productlijst een tweede keer hoeft in te voeren.

00:08:27.240 --> 00:08:31.380
Dat helpt verkoopgesprekken gebaseerd te houden op wat het bedrijf daadwerkelijk kan leveren.

00:08:31.520 --> 00:08:35.600
Prijs- en voorraadgegevens kunnen via de verbonden apps ook de verkoopafdeling bereiken.

00:08:35.820 --> 00:08:40.620
In plaats van te gokken of een item bestaat, of de prijs is veranderd, of dat de voorraad een belofte kan waarmaken,

00:08:40.760 --> 00:08:43.960
kan het salesteam werken met informatie die gekoppeld is aan de operationele kant.

00:08:44.180 --> 00:08:46.600
Dat neemt de noodzaak voor een goed verkopershef niet weg.

00:08:46.760 --> 00:08:51.240
Het neemt één vermijdbare reden weg voor een verkoper om het magazijn te bellen om basisgegevens te bevestigen.

00:08:52.160 --> 00:08:54.820
Leveranciersinformatie kan ook worden gekoppeld waar een bedrijfsproces dat vereist.

00:08:54.820 --> 00:09:02.000
Bedrijfsgegevens, organisatiestructuren, financiële referentiegegevens en belastinggegevens kunnen belangrijk zijn voor zowel de klantkant als de operationele kant.

00:09:02.160 --> 00:09:07.000
De exacte records hangen af van de apps en processen die een bedrijf gebruikt, maar het patroon blijft hetzelfde.

00:09:07.220 --> 00:09:10.080
Deel de records die op beide plaatsen hetzelfde moeten betekenen.

00:09:10.280 --> 00:09:13.100
Ga er nu niet vanuit dat elk record in beide richtingen moet reizen.

00:09:13.360 --> 00:09:15.380
Sommige apps ondersteunen twee RichTings updates.

00:09:15.640 --> 00:09:20.960
Een wijziging kan beginnen in dataverse en naar finance en operations gaan, of beginnen in finance en operations en naar dataverse gaan.

00:09:20.960 --> 00:09:25.560
Die aanpak past bij records waarbij beide partijen een geldige zakelijke reden hebben om goedgekeurde details bij te werken.

00:09:25.700 --> 00:09:27.200
Andere maps werken in één richting.

00:09:27.400 --> 00:09:29.140
Producten geven ons een nuttig voorbeeld.

00:09:29.360 --> 00:09:37.780
In veel bedrijven beheert finance en operations het aanmaken van producten omdat operations de productmaster, voorraad, eenheden en andere details beheert die nodig zijn voor verkoop en levering.

00:09:37.980 --> 00:09:41.980
Het product stroomt vervolgens naar dataverse, waar verkoop- en serviceteams het kunnen gebruiken.

00:09:42.180 --> 00:09:43.340
Dat is een duidelijke regel.

00:09:43.580 --> 00:09:46.460
Het product heeft geen twee teams nodig die concurrerende versies maken.

00:09:46.460 --> 00:09:51.060
Eén kant maakt en beheert het product, de andere kant ontvangt en gebruikt het als onderdeel van zijn werk.

00:09:51.240 --> 00:09:53.280
Elk gedeeld record heeft zo'n beslissing nodig.

00:09:53.520 --> 00:09:54.480
Waar begint dit record?

00:09:54.700 --> 00:09:55.560
Wie kan het bewerken?

00:09:55.720 --> 00:09:59.700
Als een naam, adres, prijs of klassificatie er verkeerd uitziet, welk team herstelt dit dan?

00:09:59.840 --> 00:10:02.740
Die vragen klinken eenvoudig, maar ze voorkomen later veel verwarring.

00:10:02.920 --> 00:10:04.940
Een verbinding kan een wijziging zeer snel doorvoeren.

00:10:05.120 --> 00:10:08.540
Als niemand heeft afgesproken wie verantwoordelijk is voor die wijziging, kan het net zo snel een fout doorvoeren.

00:10:08.740 --> 00:10:12.700
Kies een eigenaar voor het record en, indien nodig, voor individuele details binnen dat record.

00:10:12.700 --> 00:10:16.880
Verkoop kan bijvoorbeeld de relatiegegevens en primaire contactinformatie van een klant beheren.

00:10:17.040 --> 00:10:19.180
Finance kan betalingsgerelateerde details beheren.

00:10:19.360 --> 00:10:21.400
Operations kan product- en voorraatgegevens beheren.

00:10:21.540 --> 00:10:26.880
De exacte verdeling hangt af van hoe uw bedrijf werkt, maar het moet worden vastgelegd en begrepen door de mensen die de apps gebruiken.

00:10:27.040 --> 00:10:32.280
Er zijn ook twee termen die u mogelijk ziet nadat JewelWrite Dataverse uitbreidt, party en company.

00:10:32.500 --> 00:10:37.100
Een party is de manier van Microsoft om op consistente wijze met een persoon of organisatie om te gaan.

00:10:37.100 --> 00:10:44.240
Het helpt mensen, organisaties, contactpersonen en adressen te verbinden zonder elke relatie als een apart, niet gerelateerd record te behandelen.

00:10:44.420 --> 00:10:49.100
Een company helpt Dataverse de zakelijke bedrijfscontext te begrijpen die wordt gebruikt door Finance & Operations.

00:10:49.400 --> 00:10:52.080
U hoeft op de eerste dag nog geen expert te zijn in beide termen.

00:10:52.280 --> 00:10:59.040
Weet gewoon dat ze bestaan, want Finance & Operations beheert bedrijfstructuren die klantapps moeten herkennen wanneer gegevens tussen beide kanten worden uitgewisseld.

00:10:59.180 --> 00:11:04.660
Zodra gegevens in beide richtingen kunnen reizen, is het proces rondom die gegevens net zo belangrijk als de gegevens zelf.

00:11:04.660 --> 00:11:06.560
Hoe een wijziging tussen de apps reist

00:11:06.560 --> 00:11:10.240
Laten we één wijziging door het systeem volgen en kijken wat er daadwerkelijk gebeurt.

00:11:10.400 --> 00:11:14.280
Een verkoopmedewerker voert een telefoongesprek met een klant die net naar een nieuw kantoor is verhuisd.

00:11:14.420 --> 00:11:19.540
Tijdens dat gesprek opent de medewerker het klantrecord in Dynamics 365 Sales en werkt het straatadres bij.

00:11:19.780 --> 00:11:20.880
Vrij eenvoudig, toch?

00:11:21.140 --> 00:11:22.640
Vervolgens slaan ze het record op.

00:11:22.780 --> 00:11:24.420
Daar begint het interessante gedeelte.

00:11:24.660 --> 00:11:28.320
Sales slaat die wijziging op in Dataverse, de datakant voor klantgerichte apps.

00:11:28.540 --> 00:11:33.700
Vervolgens controleert JewelWrite de koppeling die klant en adresgegevens tussen deze site en Finance & Operations verbindt.

00:11:33.700 --> 00:11:36.280
Het verstuurt de bijbehorende wijziging automatisch door.

00:11:36.480 --> 00:11:39.580
Geen exportbestand in een gedeelde map dat wacht tot iemand het oppakt.

00:11:39.760 --> 00:11:41.820
Niemand hoeft Finance te e-mailen met een bericht als

00:11:41.820 --> 00:11:43.540
Hé, werk dit adres alsjeblieft bij.

00:11:43.720 --> 00:11:49.940
De koppeling weet al welke velden zijn verbonden en stuurt de ondersteunde wijziging direct door naar het gerelateerde klantrecord in Finance & Operations.

00:11:50.320 --> 00:11:52.860
Zo kan een gebruiker bij Finance dat klantrecord later openen,

00:11:53.060 --> 00:11:56.620
het bijgewerkte adres zien en een order verwerken of factuur voorbereiden zonder vertraging.

00:11:56.860 --> 00:11:59.160
Dat is het praktische resultaat, simpel en duidelijk.

00:11:59.160 --> 00:12:03.600
Twee mensen blijven in verschillende apps werken, maar niemand hoeft dezelfde klantgegevens opnieuw in te voeren.

00:12:03.760 --> 00:12:06.980
De verkoopmedewerker werkt in een scherm dat is ontworpen voor klantgesprekken.

00:12:07.120 --> 00:12:10.380
De Finance-gebruiker werkt in een scherm dat is gebouwd voor financiële werkzaamheden.

00:12:10.560 --> 00:12:14.460
Iedereen ziet de klantinformatie die zij daadwerkelijk nodig hebben, precies waar ze die nodig hebben.

00:12:14.600 --> 00:12:16.460
En de reis werkt ook in de andere richting.

00:12:16.700 --> 00:12:20.480
Stel je voor dat Finance ondersteunde klantinformatie bijwerkt in Finance & Operations.

00:12:20.880 --> 00:12:24.940
Stel dat een Finance-gebruiker een detail corrigeert dat bij het operationele klantrecord hoort.

00:12:24.940 --> 00:12:29.580
Jewel Right gebruikt de koppeling in omgekeerde richting en stuurt die gerelateerde update naar dataverse.

00:12:29.800 --> 00:12:34.000
Vervolgens kunnen Sales, Customer Service of elke andere dataverse gebaseerde app het oppikken.

00:12:34.200 --> 00:12:36.780
Deze verbinding is synchroon voor het normale dagelijkse werk.

00:12:37.020 --> 00:12:40.800
Synchroon betekent dat de apps de gerelateerde update proberen te voltooien op hetzelfde moment,

00:12:41.000 --> 00:12:44.360
in plaats van deze in een achtergrondtaak te plaatsen die pas 20 minuten later draait.

00:12:44.520 --> 00:12:48.320
Als de verbinding de update niet kan voltooien, moet dat probleem onmiddellijk aandacht krijgen,

00:12:48.560 --> 00:12:51.140
niet stilletjes verborgen blijven totdat iemand een mismatch opmerkt.

00:12:51.340 --> 00:12:53.740
Dat gedrag is logisch voor gedeelde bedrijfsgegevens.

00:12:53.740 --> 00:12:57.840
Je wilt niet dat een klantadres, productdetail of andere gedeelde informatie urenlang uit elkaar loopt

00:12:57.840 --> 00:12:59.280
omdat een bedstaak nog niet is uitgevoerd.

00:12:59.460 --> 00:13:02.400
Mensen nemen beslissingen op basis van wat ze op dat moment op hun scherm zien.

00:13:02.600 --> 00:13:05.680
De verbinding houdt beide kanten dus dicht bij elkaar terwijl er wordt gewerkt.

00:13:05.860 --> 00:13:08.420
Toch vereist live werk soms een gecontroleerde pauze.

00:13:08.660 --> 00:13:11.500
Jewel Right bevat opties voor afspelen, pauseren en inhalen.

00:13:11.660 --> 00:13:14.940
Afspelen betekent dat de mapping actief is en ondersteunde wijzigingen normaal worden verwerkt.

00:13:15.100 --> 00:13:17.980
Pauseren stopt de mapping tijdelijk wanneer een team gepland onderhoud moet uitvoeren,

00:13:18.140 --> 00:13:20.340
een probleem moet onderzoeken of een wijziging veilig wil doorvoeren.

00:13:20.340 --> 00:13:22.580
Maar pauseren is geen permanente parkeerplek.

00:13:22.660 --> 00:13:26.380
Terwijl een mapping is gepauseerd, kunnen wijzigingen in de wachtrij komen voor een beperkte tijd en ruimte.

00:13:26.560 --> 00:13:29.980
Wanneer de mapping wordt hervat, verwerkt de inhaalfunctionaliteit deze wachtende wijzigingen.

00:13:30.180 --> 00:13:32.740
Dit helpt teams om te herstellen na een geplande onderbreking.

00:13:32.940 --> 00:13:36.680
Iemand moet echter verantwoordelijk zijn voor die pauze en weten wanneer de mapping weer moet draaien.

00:13:36.920 --> 00:13:40.860
Voordat dit alles in het dagelijkse werk begint, is er nog een stap, de initiële synchronisatie.

00:13:41.020 --> 00:13:44.920
De initiële synchronisatie brengt bestaande records van beide kanten naar een gezamenlijk startpunt.

00:13:44.920 --> 00:13:49.100
Denk aan een bedrijf dat al klanten heeft in finance en operations en klant records in dataverse.

00:13:49.300 --> 00:13:53.660
De verbinding kan niet zomaar worden ingeschakeld in de veronderstelling dat elk bestaandrecord al perfect overeenkomt.

00:13:53.740 --> 00:13:54.920
Er is een startlijn nodig.

00:13:55.160 --> 00:14:00.060
De initiële synchronisatie helpt om bestaande gegevens over te zetten voordat gebruikers vertrouwen op live updates.

00:14:00.300 --> 00:14:07.400
Dat werk vereist zorgvuldigheid, omdat dubbele records, onvolledige adressen en oude testgegevens niet magisch verdwijnen zodra een synchronisatie start.

00:14:07.600 --> 00:14:11.540
Ze kunnen zelfs sneller problemen veroorzaken als de records niet voldoen aan de afgesproken regels.

00:14:11.540 --> 00:14:16.200
Zodra de mappings draaien, hebben de beheerders van Jewelright een duidelijk overzicht nodig om de status te controleren.

00:14:16.500 --> 00:14:22.560
Jewelright biedt gecombineerde activiteiten en foutenlogboeken, zodat beheerders kunnen zien wat de verbinding heeft verwerkt en waar problemen zijn opgetreden.

00:14:22.740 --> 00:14:24.960
Ze kunnen ook waarschuwingen en drempelwaarden instellen.

00:14:25.180 --> 00:14:30.240
Dat betekent dat de juiste personen op de hoogte zijn van problemen voordat gebruikers ze ontdekken door een ontbrekende of mislukte update.

00:14:30.440 --> 00:14:33.660
Dat ondersteuningsperspectief is belangrijk, want elke fout heeft een oorzaak.

00:14:33.800 --> 00:14:35.300
Misschien ontbreekt er een verplicht veld.

00:14:35.500 --> 00:14:37.420
Misschien is een gerelateerd record nog niet gearriveerd.

00:14:37.420 --> 00:14:40.220
Misschien heeft iemand gegevens gewijzigd op een manier die niet in de mapping past.

00:14:40.380 --> 00:14:44.760
Het opnieuw proberen van een misluktrecord zonder de oorzaak aan te pakken, leidt meestal tot dezelfde fout.

00:14:44.960 --> 00:14:52.800
Een goed beheerde Jewelright-opstelling bewaakt de verbinding, lost de oorzaak van fouten op en houdt de mappings gericht op records die echt verbonden moeten blijven.

00:14:53.020 --> 00:14:54.560
Waar Jewelright het beste past?

00:14:54.820 --> 00:14:59.420
Jewelright past het beste wanneer uw bedrijf Dynamics 365 Finance of Supply Chain Management gebruikt...

00:14:59.420 --> 00:15:03.920
...in combinatie met klantgerichte apps zoals Sales, Customer Service, Field Service of Project Operations.

00:15:04.200 --> 00:15:07.580
Deze apps ondersteunen verschillende onderdelen van hetzelfde zakelijke proces.

00:15:07.820 --> 00:15:13.700
Het ene team spreekt met de klant, het andere team plant leveringen, beheert voorraad, volgt kosten of verstuurd facturen.

00:15:13.940 --> 00:15:21.020
Wanneer beide groepen gedurende de dag met gerelateerde records moeten werken, kan Jewelright dat werk verbinden zonder dat iedereen dezelfde app hoeft te gebruiken.

00:15:21.260 --> 00:15:23.380
Neem als voorbeeld een prospect-to-cash-proces.

00:15:23.600 --> 00:15:27.360
Een verkoper werkt met een potentiële klant in Dynamics 365 Sales.

00:15:27.360 --> 00:15:31.620
Ze houden het contact bij, bespreken producten, maken een offerte en werken toe naar een order.

00:15:31.800 --> 00:15:39.240
Tijdens dat gesprek heeft de verkoper klantgegevens, productinformatie, prijzen en orderinformatie nodig die betrekking hebben op de financiële kant van het bedrijf.

00:15:39.420 --> 00:15:44.660
Zodra de verkoop definitief is, neemt Finance & Supply Chain Management het werk over dat na de toezegging volgt.

00:15:44.860 --> 00:15:48.560
Dit omvat de orderafhandeling, voorraad, facturering en financiële administratie.

00:15:48.800 --> 00:15:51.400
Jewelright helpt om die twee onderdelen verbonden te houden.

00:15:51.640 --> 00:15:53.980
Verkopers kunnen werken in de klantapp die bij hun baan past,

00:15:53.980 --> 00:15:57.920
terwijl Finance & Operations de transactie beheren in de app die voor hun werk is gebouwd.

00:15:58.100 --> 00:16:02.440
De klant wordt zo niet twee aparte verhalen, het ene verteld door Sales en het andere door Finance.

00:16:02.660 --> 00:16:04.380
Field Service is een ander goed voorbeeld.

00:16:04.640 --> 00:16:09.160
Stel je een bedrijf voor dat technici stuurt om apparatuur te installeren, repareren of onderhouden op klantlocaties.

00:16:09.340 --> 00:16:11.260
De buitendienstmedewerker heeft klantgegevens nodig,

00:16:11.440 --> 00:16:15.500
details over het werk en informatie over het klantasset van het item dat het bedrijf heeft geïnstalleerd of ondersteund.

00:16:15.500 --> 00:16:20.800
Achter de schermen moet het bedrijf ook onderdelen, kosten, inkoop en het geld dat aan dat werk is gekoppeld, bijhouden.

00:16:21.000 --> 00:16:23.520
Field Service richt zich op het plannen en afronden van het bezoek.

00:16:23.520 --> 00:16:27.520
Finance & Operations richt zich op de operationele en financiële administratie daaromheen.

00:16:27.740 --> 00:16:31.860
Wanneer die records goed verbonden zijn, staat het werk van een technicus niet los van de gebruikte onderdelen,

00:16:32.040 --> 00:16:34.520
de kosten van het werk of het klantrecord dat eraan is gekoppeld.

00:16:34.680 --> 00:16:39.160
Project Operations volgt hetzelfde patroon, vooral voor bedrijven die werk per project verkopen.

00:16:39.340 --> 00:16:44.160
Een projectteam kan klantwerk, tijd van medewerkers, geplande kosten en projectmijlpalen beheren.

00:16:44.360 --> 00:16:48.660
Finance moet de financiële kant zien van inkoop, kosten, facturering en rapportage.

00:16:48.660 --> 00:16:56.560
Zonder verbinding kunnen projectmanagers te veel tijd besteden aan het najagen van finance voor updates, terwijl finance wacht tot projectteams bevestigen wat er is gebeurd.

00:16:56.740 --> 00:17:02.700
Verbonden project records geven beide groepen een duidelijker beeld van het werk naarmate het verschuift van een klanttoezegging naar financiële activiteit.

00:17:02.880 --> 00:17:10.940
Er is hier ook een breder power platform voordeel, want aangezien de klant app dataverse gebruikt, kan goedgekeurde data in dataverse power apps en power automate ondersteunen.

00:17:10.940 --> 00:17:16.860
Een bedrijf kan een kleine app bouwen voor een intern team of een flow maken die reageert wanneer een bedrijfsrecord een bepaald punt bereikt.

00:17:17.080 --> 00:17:21.120
Dat betekent niet dat elk finance en operationsrecord plotseling in elke power app thuis hoort.

00:17:21.320 --> 00:17:27.920
Dit betekent dat gekoppelde records deel kunnen uitmaken van een bredere set zakelijke tools, zolang het bedrijf dat tool zorgvuldig kiest en de gegevens goed beveiligt.

00:17:28.080 --> 00:17:29.540
Eén grens moet duidelijk blijven.

00:17:29.780 --> 00:17:33.100
JewelWrite ondersteunt Dynamics 365 Business Central niet.

00:17:33.100 --> 00:17:42.080
Business Central kan via andere methoden verbinding maken met Microsoft producten, maar JewelWrite is bedoeld voor de finance en operations kant van Dynamics 365 en op dataverse gebaseerde klant apps.

00:17:42.280 --> 00:17:45.420
Het is ook geen tool om zomaar elke tabel te kopiëren die je kunt vinden.

00:17:45.600 --> 00:17:51.340
Een record moet worden verplaatst omdat mensen hetzelfde operationele record op beide plekken nodig hebben, niet omdat het kopiëren van data veiliger voelt.

00:17:51.560 --> 00:17:58.220
JewelWrite vervangt bovendien geen breder integratieplan wanneer een bedrijfrapportage feeds, koppelingen met systemen van derden of een grote datamigratie nodig heeft.

00:17:58.420 --> 00:18:02.120
Elke dataverbinding als dezelfde taak behandelen zorgt snel voor problemen.

00:18:02.120 --> 00:18:05.540
Limite, voorbereiding en veel voorkomende fouten

00:18:05.540 --> 00:18:08.860
Zie JewelWrite als een handelijke overeenkomst tussen twee systemen.

00:18:09.000 --> 00:18:14.840
Ze spreken af om bepaalde gedeelde records synchroon te houden, maar het is geen magische pijpleiding voor elke tabel, elk rapport of extern systeem.

00:18:15.020 --> 00:18:17.820
Controleer voordat je het instelt welke integraties er al bestaan.

00:18:18.040 --> 00:18:22.860
Als een oude verbinding en JewelWrite beide hetzelfde klantrecord bijwerken, kun je snel conflicten creëren.

00:18:23.060 --> 00:18:24.640
Dat is een hoofdpijndossier dat je niet wilt.

00:18:24.880 --> 00:18:26.340
Spreek daarom eerst de basis af.

00:18:26.340 --> 00:18:29.660
Hoe gaan jullie namen invoeren? Welke juridische entiteit is eigenaar van welk record?

00:18:29.800 --> 00:18:31.040
Wie mag wijzigingen aanbrengen?

00:18:31.040 --> 00:18:32.920
Welke beveiligingsrollen heeft elk team nodig?

00:18:33.120 --> 00:18:35.640
Verwijder dubbele en onvolledige records voor de eerste synchronisatie.

00:18:35.840 --> 00:18:37.580
Begin met de vooraf gebouwde maps van Microsoft.

00:18:37.880 --> 00:18:39.420
Deze verbinden al veel gebruikte records.

00:18:39.680 --> 00:18:42.040
Aangepaste tabellen en velden, die vereisen zorgvuldige tests.

00:18:42.260 --> 00:18:47.200
En controleer gerelateerde tabellen en mapafhankelijkheden, want soms moet een record eerst bestaan voordat een ander record kan synchroniseren.

00:18:47.340 --> 00:18:49.920
Plan je eerste synchronisatie op basis van de hoeveelheid data die je hebt.

00:18:50.120 --> 00:18:52.380
Behandel het niet als een lichtschakelaar die je even tijdens de lanche omzet.

00:18:52.540 --> 00:18:53.840
Dat zal problemen veroorzaken.

00:18:53.840 --> 00:18:56.540
Een gepauzeerde map heeft nog steeds een eigenaar en een herstartplan nodig.

00:18:56.720 --> 00:18:59.280
Wachtrijen met wijzigingen en mislukte records blijven niet eeuwig staan.

00:18:59.460 --> 00:19:02.480
Hou de activiteitslogboeken, fouten, waarschuwingen en drempelwaarden in de gaten.

00:19:02.720 --> 00:19:06.640
Wanneer iets mislukt, zoek dan naar het ontbrekende veld, het foutieve record of de gebroken regel erachter.

00:19:06.840 --> 00:19:09.080
Herhaaldelijk opnieuw proberen lost slechte data niet op.

00:19:09.260 --> 00:19:12.880
Wanneer je Jewel Ride ziet als een gecontroleerde brug, valt alles op zijn plek.

00:19:12.880 --> 00:19:15.580
Conclusie, één gedeeld zakelijk gesprek.

00:19:15.820 --> 00:19:21.780
Jewel Ride houdt ondersteunde gedeelde records in beweging tussen finance en operations en je op dataverse gebaseerde klantapps.

00:19:21.960 --> 00:19:25.120
Op die manier kunnen teams werken vanuit verbonden bedrijfsgegevens.

00:19:25.540 --> 00:19:29.140
Abonneer je op je favoriete podcastplatform voor meer kennis van mij,

00:19:29.140 --> 00:19:37.480
meer kopeters op m365.fm en deel deze aflevering met iemand die sales, service en finance nog steeds koppelt via weer een ander spreadsheet.