Ein Vertriebsmitarbeiter aktualisiert die Adresse eines Kunden. Später eröffnet die Finanzabteilung denselben Datensatz und sieht immer noch die alte Adresse. Welche Adresse ist also die richtige? Jahrelang bedeutet die Korrektur, dass jemand Daten exportieren, eine Tabelle bearbeiten, diese per E-Mail versenden und dieselbe Aktualisierung ein zweites Mal in eine andere App eingeben muss. Dynamics 365 DualWrite ändert das. Es verbindet Finanz- und Betriebs-Apps mit Dataverse-basierten Kunden-Apps, sodass gemeinsame Datensätze wie Kunden und Aufträge automatisch synchron bleiben. Sie sind bei mir. Ich bin Milko Peters von M3355FM. Und dieses Wissenshäppchen erklärt DualWrite in einfacher Sprache. Wir werden behandeln, was übertragen wird, wie es übertragen wird, wo DualWrite passt und wo es nicht passt. Beginnen wir zunächst mit dem geschäftlichen Problem, das den Bedarf dafür geschaffen hat.

Das Problem, das DualWrite löst. Stellen Sie sich ein Unternehmen vor, in dem zwei Gruppen am selben Kunden arbeiten, aber täglich völlig unterschiedliche Apps verwenden. Finanz- und Betriebs-Apps übernehmen die Backoffice-Arbeit. Das umfasst Geld, Lagerbestand, Produkte, Aufträge, Einkauf und die Lieferkette. Hier verfolgt ein Unternehmen, was es verkauft, was es liefern kann, was es schuldet und was im Kunde bezahlen muss. Kunden-Apps konzentrieren sich auf die Arbeit in der Nähe am Kunden. Vertriebsteams verfolgen Leads und bauen Geschäftsmöglichkeiten auf. Der Kundenservice kümmert sich um Fragen und Supportfälle. Der Außendienst plant Aufträge und entsendet Mitarbeiter vor Ort. Projektteams verfolgen die dem Kunden versprochene Arbeit. Unterschiedliche Arbeit erfordert unterschiedliche Bildschirme. Ein Vertriebsmitarbeiter sollte sich nicht durch einen Finanzbildschirm wühlen müssen, nur um nach einem Anruf einen Kontakt zu aktualisieren.

Aber ein Finanzmitarbeiter benötigt Kunden und Auftragsdetails, die mit denen des Vertriebs übereinstimmen, da Rechnungen und Lieferungen von diesen Informationen abhängen. Ohne eine Verbindung wird ein Kunde still und leise zu zwei Datensätzen. Der Vertrieb listet vielleicht Northwind Bikes, die Finanzabteilung führt vielleicht Northwind Bicycle Company. Oh, ein Datensatz hat die neue Straßenadresse. Der andere sendet Rechnungen noch an das alte Büro. Beide Datensätze sehen für sich genommen plausibel aus, beschreiben aber nicht mehr dieselbe Geschäftsbeziehung. Zuerst tauchen kleine Probleme auf. Jemand findet einen Kunden nicht, weil der Name in einer anderen App anders ist. Ein Vertriebsmitarbeiter verspricht einen Preis oder prüft den Bestand, aber die Informationen stimmen nicht mit der operativen Seite überall. Die Finanzabteilung muss in Auftrag bearbeiten, aber die Kundendetails erfordern eine Prüfung, eine E-Mail und ein weiteres manuelles Update.

Dann häufen sich diese kleinen Probleme. Jemand exportiert Kundendaten in eine Tabelle. Eine andere Person korrigiert ein paar Zeilen und importiert sie woanders wieder. Wieder jemand anderes gibt einen neuen Kunden in beiden Apps ein, weil niemand weiß, welcher Datensatz zuerst erscheinen wird. Bald gibt es Duplikate, unterschiedliche Adressen und mehr Zeit wird mit der Datenprüfung verbracht als mit der Nutzung. Nichts davon passiert, weil Menschen unvorsichtig sind. Es passiert, weil die Systeme verlangen, dass Menschen die Verbindung herstellen. Menschen kopieren Daten. Menschen müssen sich merken, welche App zuerst kommt. Menschen bemerken Fehler erst, wenn sie bereits ein anderes Team erreicht haben. Dieser Ansatz funktionierte, als Geschäftssysteme getrennt blieben und Teams Verzögerung akzeptierten. Wenn aber Vertrieb, Service, Finanzen und Betrieb tagsüber dieselben Kundeninformationen benötigen, ist eine Tabelle ein unzureichendes Übergabewerkzeug.

Denken Sie an ein einfaches Gespräch über einen Auftrag. Ein Kunde ruft den Vertrieb an und fragt, wie können Sie nächste Woche liefern? Was wird das kosten? Das Vertriebsteam benötigt Produktpreis und Lagerdetails für eine Antwort. Sobald der Kunde zustimmt, benötigen Finanzen und Betrieb die richtigen Kunden und Auftragsinformationen, den Verkauf abzuwickeln. Beide Seiten benötigen dieselben Fakten. Benötigt diese Fakten in der App, mit der die Vertriebsmitarbeiter arbeiten. Finanzen und Betrieb benötigen Sie in der App, mit der Sie Aufträge, Finanzen und Lieferungen verwalten. Das Ziel ist es nicht, jedes Team in einen einzigen riesigen Bildschirm zu zwingen. Das Ziel ist, dass gemeinsame Datensätze einem klaren, vereinbarten Weg folgen. An dieser Stelle kommt DualWrite ins Spiel. Was ist DualWrite eigentlich genau? Hier ist die einfachste Definition. DualWrite ist die integrierte Microsoft-Verbindung, die ausgewählte Daten zwischen Dynamics 365 Finance & Operations Apps und Dataverse synchron hält.

Dataverse ist die gemeinsame Datengrundlage hinter vielen Microsoft-Geschäftsanwendungen. Dynamics 365 Sales, Customer Service, Field Service und Teile von Project Operations nutzen Sie alle. Power Apps und Power Automate können Sie ebenfalls nutzen. Sie müssen nicht wissen, wie Dataverse jeden einzelnen Datensatz speichert, um DualWrite zu verstehen. Stellen Sie es sich einfach als den gemeinsamen Datenbereich auf der Kunden-App-Seite von Dynamics 365 vor. Stellen Sie sich ein Bürogebäude mit einem Front-Office und einem Back-Office vor. Das Front-Office wickelt Gespräche mit Kunden ab. Vertriebsmitarbeiter, Service-Mitarbeiter, Ausdienstmitarbeiter. Sie alle benötigen Bildschirme, die Ihnen helfen, mit Menschen zu sprechen, Anfragen zu verfolgen und Arbeit zu verfolgen. Das Back-Office erledigt die Arbeit, die das Unternehmen am Laufen hält. Unsere Finanzunterlagen, Lagerbestände, Aufträge, Einkäufe, Lieferungen.

Beide Büros arbeiten für dasselbe Unternehmen. Aber ohne eine richtige Verbindung zwischen ihnen muss jemand Informationen von einer Seite zur anderen tragen. Sie tragen ein gedrucktes Formular, senden eine E-Mail oder kopieren Daten in ein anderes System. Die Arbeit wird zwar erledigt, aber sie dauert länger und Details können sich auf dem Weg ändern. DualWrite ist wie eine besetzte interne Tür zwischen diesen beiden Büros. Wenn sich ein unterstützter Datensatz auf einer Seite ändert, leitet DualWrite die entsprechende Änderung durch diese Tür auf die andere Seite weiter. Es fasst nicht jede App zu einer einzigen riesigen App zusammen. Der Vertrieb kann weiterhin im Vertrieb arbeiten. Das Finanzwesen kann weiterhin im Finanzwesen arbeiten. Jedes Team behält seine spezialisierten Arbeitsbereiche, während ausgewählte gemeinsame Informationen im Hintergrund verbunden bleibt. Das Wort unterstützt ist dabei entscheidend.

DualWrite kopiert nicht blindlings jedes Datenelement in beide Systeme. Es funktioniert über definierte Verbindungen zwischen zusammengehörigen Datensätzen. Microsoft nennt diese Verbindungen Tabellenzuordnung und TableMaps. Eine Tabelle ist einfach ein Ort, an dem eine App eine Art von Datensatz speichert. Eine Kundentabelle speichert Kundendatensätze. Eine Produkttabelle speichert Produktdaten. Eine Adresstabelle speichert Adressdetails. Eine Tabellenzuordnung teilt DualWrite mit, welche Tabelle auf der Finanz- und Betriebsseite mit welcher Tabelle in Dataverse verbunden ist. Betrachten Sie eine Tabellenzuordnung als ein vereinbartes Übersetzungsbild. Eine Spalte identifiziert einen Datensatz auf der einen. Eine weitere Spalte identifiziert den entsprechenden Datensatz auf der anderen. Der Rest des Blattes erklärt, welche Felder zusammengehören. Wie Name, Telefonnummer, Adresszeile. Diese Vereinbarung legt die Verbindungsregel fest.

Ohne sie könnten zwei Apps unterschiedliche Bezeichnungen verwenden oder dasselbe Detailen speichern. Eine Zuordnung teilt DualWrite mit, wie diese Details zueinander in Beziehung stehen. So müssen die Apps nicht jedes Mal von einer Person interpretiert werden. Oft hören Leute den Namen DualWrite und nehmen an, dass jede Änderung immer in beide Richtungen übertragen wird. Manchmal ist das der Fall. Bei einer unterstützten Zwei-Wege-Zuordnung kann eine Änderung in Dataverse den zugehörigen Datensatz in Finance und Operations atualisieren. Eine unterstützte Änderung in Finance und Operations kann auch den zugehörigen Datensatz in Dataverse aktualisieren. Beide Seiten können an demselben geteilten Datensatz mitwirken. Es ist Dualteil. Die Aktualisierung erfolgt nahezu in Echtzeit. Sie erfolgt schnell während der Arbeit, anstatt auf einen geplanten Job zu warten, der über Nacht läuft. Ein Benutzer aktualisiert einen unterstützten Datensatz und die Verbindung überträgt dieses Update, während die Arbeit noch aktuell ist.

Nahezu Echtzeit bedeutet keine Magie oder null Verzögerung. Es bedeutet, dass die Verbindung für die Live-Arbeit konzipiert ist, nicht für einen einmal täglichen Dateiaustausch. Wenn jemand ein Detail ändert, muss das zuständige Team nicht bis zum nächsten Morgen warten, um es zu sehen. Das verändert die Arbeitsweise der Teams. Das Front-Office kann Daten nutzen, die aus dem Back-Office stammen. Das Back-Office kann unterstützte Aktualisierungen von kundenorientierten Apps erhalten. Dataverse wird zur Datengrundlage auf der einen Seite, Finance und Operations bleibt die betriebliche Grundlage auf der anderen und Dual-Ride hält die freigegebenen Datensätze verbunden. Dennoch braucht eine lebendige interne Türregel. Bevor Sie zulassen, dass ein Datensatz in beide Richtungen wandert, müssen Sie wissen, wo er beginnen soll, wer ihn ändern darf und welche Seite Vorhang hat, wenn sich die Apps nicht einig sind.

Welche Daten können übertragen werden? Welches System ist der Eigentümer? Welche Datensätze kann Dual-Ride also miteinander verbinden? Gängige Beispiele beginnen mit den Datensätzen, die viele Abteilungen täglich gemeinsam nutzen. Kundendatensätze, Adressen, Kontakte, Produkte, Anbieter, Unternehmensdetails und Referenzinformationen für Finanz- und Steuerzwecke. Denken Sie einen Moment über einen Kundendatensatz nach. Der Vertrieb benötigt den Namen des Kunden, den Hauptansprechpartner, die Telefonnummer und die Lieferadresse. Die Finanzabteilung benötigt den rechtlichen Kundendatensatz, Abrechnungsdetails sowie Informationen für Aufträge und Rechnungen. Wenn jede Abteilung eine eigene, separate Kundenliste führt, verbringt das Unternehmen Zeit mit dem Abgleich von Datensätzen, anstatt den Kunden zu bedienen. Mit den richtigen Dual-Ride-Zuordnungen können diese Teams mit vernetzten Kundendetails arbeiten.

Das bedeutet nicht, dass Vertriebsmitarbeiter plötzlich die Finanz-App erlernen müssen. Es bedeutet, dass sie mit Kundeninformationen in Dynamics 365 Sales arbeiten können, während Finanzanwender mit den entsprechenden Kundeninformationen in Finance arbeiten. Der Kunde bleibt in beiden Systemen als derselbe Kunde erkennbar. Auch Adressen sind wichtig. Ein Kunde hat möglicherweise eine Rechnungsadresse, eine Lieferadresse und vielleicht einen Standort, den ein Service-Mitarbeiter aufsuchen muss. Diese Details können nicht einfach als Text in ein Feld kopiert werden, da jede Adresse eine andere Funktion hat, andere Funktionen. Dual-Ride unterstützt die für diese Beziehung erforderliche gemeinsame Datensatzstufe. Bei Kontakt mit demselben Muster. Ein Kundenunternehmen kann einen Einkäufer, einen Ansprechpartner für die Kreditoren, Buchhaltung und einen Service-Manager haben. Der Vertrieb muss wissen, wer Entscheidungen trifft.

Die Finanzabteilung muss wissen, an wen Abrechnungsrichtungen sind. Der Service muss wissen, wer vor Ort auf Hilfe wartet. Verbundene Datensätze helfen jedem Team, die mit dem Kunden verbundenen Personen zu sehen, ohne diese Informationen in jeder App neu anlegen zu müssen. Produkte sind ein weiteres Gängig-Spec. Ein Vertriebsmitarbeiter muss wissen, was das Unternehmen verkauft, was das Produkt kostet und ob es auf Lager ist. Und ob es auf Lager ist. Diese Antworten kommen normalerweise aus dem operativen Bereich, da dort Produkte, Lagerbestände, Einkauf und Erfüllung verwaltet werden. Deshalb beginnen Produktinformationen oft in Finance and Operations. Ein Betriebsteam erstellt und bereitet ein Produkt dort vor. Sobald das Produkt für die Kundenansprache bereit ist, kann DualWrite die zugehörigen Produktdetails an Dataverse senden. Vertriebsmitarbeiter können das Produkt dann in ihrer eigenen App auswählen und besprechen, ohne dass jemand die Produktliste ein zweites Mal eingeben muss.

Dies trägt dazu bei, das Verkaufsgespräch auf dem basieren, was das Unternehmen tatsächlich anbieten kann. Preis- und Bestandsdetails können den Vertrieb ebenfalls über die verbundenen Apps erreichen. Anstatt zu raten, ob ein Artikel existiert, ob sich der Preis geändert hat oder ob der Lagerbestand ein Versprechen stützen kann, kann das Vertriebsteam mit Informationen arbeiten, die mit dem operativen Bereich verknüpft sind. Das ersetzt nicht die Notwendigkeit für ein gutes Urteilsvermögenvertrieb. Es beseitigt einen vermeidbaren Grund dafür, dass ein Vertriebsmitarbeiter im Lager anruft, nur um grundlegende Details zu bestätigen. Anbieterinformationen können ebenfalls dort verknüpft werden, wo Geschäftsprozesse benötigen. Firmendetails, Organisationsstrukturen, Finanzstammdaten und Steuerstammdaten können sowohl für die Kundenseite als auch für den operativen Bereich von Bedeutung sein.

Die genauen Datensätze hängen von den Apps und Prozessen ab, die ein Unternehmen verwendet, aber das Muster bleibt gleich. Geben Sie die Datensätze frei, die an beiden Orten dasselbe bedeuten müssen. Gehen Sie nun nicht davon aus, dass jeder Datensatz in beide Richtungen übertragen werden soll. Einige Apps unterstützen bidirektionale Aktualisierung. Eine Änderung kann in Dataverse beginnen und zu Finance & Operations übertragen werden oder in Finance & Operations beginnen und zu Dataverse übertragen werden. Dieser Ansatz eignet sich für Datensätze, bei denen beide Seiten einen triftigen, geschäftlichen Grund haben, genehmigte Details zu haben. Andere Zuhörungen und Errichtung. Produkte liefern uns ein nützliches Beispiel. In vielen Unternehmen ist Finance & Operations für die Produktanlage zuständig, da der operative Bereich die Produktstammdaten, den Bestand, die Einheiten und andere Details kontrolliert, die für den Verkauf und die Lieferung erforderlich sind.

Das Produkt fließt dann in das Dataverse, wo Vertriebs- und Serviceteams es nutzen können. Das sind klare Regeln. Das Produkt benötigt nicht zwei Teams, die konkurrierende Version erstellen. Eine Seite erstellt und verwaltet das Produkt, die andere Seite empfängt und nutzt es als Teil ihrer Arbeit. Jeder gemeinsame Datensatz erfordert eine solche Entscheidung. Wo beginnt dieser Datensatz? Wer kann ihn bearbeiten? Wenn ein Name, eine Adresse, ein Preis oder eine Klassifizierung falsch aussieht, welches Team korrigiert das? Diese Fragen klingen einfach, verhindern aber später viel Verwirrung. Eine Verbindung kann eine Änderung sehr schnell übertragen. Wenn niemand vereinbart hat, wer für diese Änderung verantwortlich ist, kann sie genauso schnell eine Fehler verantworten. Wählen Sie einen Eigentümer für den Datensatz und bei Bedarf für einzelne Details innerhalb dieses Datensatzes. Zum Beispiel könnte der Vertrieb die Beziehungsdetails und primären Kontaktinformationen eines Kunden verwalten.

Die Finanzabteilung könnte zahlungsbezogen Details verwalten, der operative Bereich Produkt- und Bestandsdetail. Die genaue Aufteilung hängt von ihrer Arbeitsweise ab, muss aber schriftlich festgehalten und von den Anwendern der Apps verstanden werden. Es gibt auch zwei Begriffe, die Ihnen nach der Erweiterung von Dataverse durch DualWrite begegnen können, Partypartei und Company-Unternehmen. Eine Party ist Microsofts Art, eine Person oder Organisation konsistent zu handhaben. Sie hilft dabei, Personen, Organisationen, Kontakte und Adressen zu verbinden, ohne jede Beziehung als separaten, unabhängigen Datensatz zu behandeln. Ein Company-Objekt hilft Dataverse dabei, den geschäftlichen Unternehmenskontext zu verstehen, der von Finance und Operations verwendet wird. Sie müssen am ersten Tag kein Experte für diese Begriffe werden. Wissen Sie einfach, dass sie existieren, da Finance und Operations Unternehmensstrukturen verwaltet, die Kunden-Apps erkennen müssen, wenn Datensätze zwischen beiden Seiten ausgetauscht werden.

Sobald Datensätze in beide Richtungen übertragen werden können, sind die Prozesse um diese Datensätze herum genauso wichtig wie die Daten selbst, wie eine Änderung zwischen den Apps übertragen wird. Verfolgen wir eine Änderung durch das System und sehen wir, was tatsächlich passiert. Ein Vertriebsmitarbeiter telefoniert mit einem Kunden, der gerade in ein neues Büro umgezogen ist. Während dieses Gesprächs öffnet der Mitarbeiter den Kundendatensatz in Dynamics 365 Sales und aktualisiert die Straßenadresse. Ganz einfach, oder? Dann speichert er den Datensatz. Hier beginnt der interessante Teil. Sales speichert diese Änderung in Dataverse, das ist die Datenseite für kundenorientierte Apps. Dann prüft DualWrite die Zuordnung, die Kunden- und Adressinformationen zwischen dieser Seite und Finance und Operations verbindet. Die entsprechende Änderung wird automatisch übertragen. Keine Exportdatei liegt in einem freigegebenen Ordner und wartet darauf, dass jemand abholt.

Niemand muss eine E-Mail in die Finanzabteilung senden mit der Bitte, hey, bitte aktualisieren Sie diese Adresse. Die Zuordnung weiß bereits, welche Felder verknüpft sind und sendet die unterstützte Änderung direkt an den zugehörigen Kundendatensatz in Finance und Operations. So kann ein Finanzanwender später diesen Kundendatensatz öffnen, die aktualisierte Adresse sehen und einen Auftrag bearbeiten und eine Rechnung erstellen, ohne Zeit zu verlieren. Das ist das praktische Ergebnis schlicht und ein. Zwei Personen arbeiten in verschiedenen Apps weiter, aber niemand muss dieselben Kundendaten neu eingeben. Der Vertriebsmitarbeiter arbeitet auf einem Bildschirm, der für Kundengespräche optimiert ist. Der Finanzanwender arbeitet auf einem Bildschirm, der für Finanzaufgaben ausgelegt ist. Jede Person sieht die Kundeninformationen, die sie tatsächlich benötigt, genau dort, wo sie gebraucht werden.

Und der Weg funktioniert auch in die andere Richtung. Stellen Sie sich vor, die Finanzabteilung aktualisiert unterstützte Kundeninformationen in Finance und Operations. Angenommen, ein Finanzanwender korrigiert ein Detail, das zum operativen Kundendatensatz gehört. DualWrite verwendet die passende Zuordnung in umgekehrter Richtung und sendet dieses Update am Dataverse. Dann können Sales, Customer Service oder jede andere Dataverse-basierte App dies übernehmen. Diese Verbindung ist für die normale tägliche Arbeit synchron. Synchron bedeutet, dass die Apps versuchen, das zugehörige Update im selben Moment abzuschließen, anstatt es in einen Hintergrund Job zu verschieben, der vielleicht erst 20 Minuten später ausgeführt wird. Wenn die Verbindung das Update nicht abschließen kann, erfordert dieses Problem sofortige Aufmerksamkeit und darf sich nicht unbemerkt verstecken, bis jemand eine Abweichung bemerkt.

Dieses Verhalten ist bei gemeinsam genutzten Geschäftsdaten sitzend. Sie möchten nicht, dass eine Kundenadresse, ein Produktdetail oder andere gemeinsame Informationen über Stunden hinwegfallender Abweichen, aber ein Badstock noch nicht gestartet wird. Menschen treffen Entscheidungen basierend auf dem, was sie gerade auf ihrem Bildschirm sehen. Die Verbindung hält also beide Seiten eng zusammen, während die Arbeit läuft. Dennoch erfordert laufende Arbeit manchmal eine kontrollierte Pause. Dual Ride umfasst Optionen für Wiedergabe, Pause und Aufhol. Wiedergabe bedeutet, dass die Zuordnung läuft und unterstützte Änderungen normal übertragen. Pause stoppt die Zuordnung vorübergehend, wenn ein Team geplante Arbeiten durchführt, ein Problem untersucht oder eine Änderung sicher verwalten muss. Aber Pause ist kein dauerhafter Parkplan. Während eine Zuordnung pausiert ist, können sich Änderungen für begrenzte Zeit und Kapazität in Warteschlangen.

Wenn die Zuordnung fortgesetzt wird, verarbeitet die Aufholfunktion diese wartenden Änderungen. Das hilft Teams, sich nach einer geplanten Unterbrechung wieder zu erholen. Jemand muss jedoch für diese Pause verantwortlich sein und wissen, wann die Zuordnung wieder starten soll. Bevor dies im Arbeitsalltag beginnt, gibt es einen weiteren Schritt, die Erstsynchronisierung. Die Erstsynchronisierung bringt bestehende Datensätze von beiden Seiten auf einen gemeinsamen Startpunkt. Denken Sie an ein Unternehmen, das bereits Kunden in Finance und Operations und Kundendatensätze in Dataverse hat. Die Verbindung kann nicht einfach eingeschaltet werden in der Annahme, dass jeder bestehende Datensatz bereits perfekt übereinstimmt. Es braucht eine Startlinie. Die Erstsynchronisierung hilft dabei, bestehende Daten zu übertragen, bevor man sich auf Live-Updates verlässt. Diese Arbeit erfordert Sorgfalt, da sich doppelte Datensätze und vollständige Adressen und alte Testdaten nicht magisch von selbst bereinigen, nur weil eine Synchronisierung startet.

Sie können tatsächlich schneller Probleme verursachen, wenn die Datensätze nicht den vereinbarten Regeln folgen. Sobald die Zuordnungen laufen, benötigen die Verantwortlichen für DualRide einen klaren Ort, um deren Status zu überprüfen. DualRide bietet kombinierte Aktivitäts- und Fehlerprotokolle, damit Administratoren sehen können, was die Verbindung verarbeitet hat und wo Probleme auftraten. Sie können auch Warnungen und Schwellenwerte festlegen. Das bedeutet, dass die zuständigen Personen von Problemen erfahren, bevor Benutzer sie durch ein fehlendes oder fehlgeschlagenes Update bemerken. Diese Support-Ansicht ist wichtig, weil jeder Fehler eine Ursache hat. Vielleicht fehlt ein Pflichtfeld. Vielleicht ist ein verknüpfter Datensatz noch nicht angekommen. Vielleicht hat jemand Datenweise geändert, die nicht zur Zuordnung passt. Ein erneuter Versuch bei einem fehlgeschlagenen Datensatz ohne Behebung der Ursache führt meist nur zum selben Fehler.

Eine gut geführte DualRide-Einrichtung überwacht die Verbindung, behebt die Ursachen von Fehlern und konzentriert die Zuordnungen auf Datensätze, die wirklich verbunden bleiben müssen. Wo DualRide am besten passt. DualRide passt am besten, wenn Ihr Unternehmen Dynamics 365 Finance oder Supply Chain Management zusammen mit kundenorientierten Apps wie Sales, Customer Service, Field Service oder Project Operations nutzt. Diese Apps unterstützen verschiedene Teile des selben Geschäftsvorgangs. Ein Team spricht mit den Kunden. Ein anderes Team plant die Lieferung, verwaltet den Bestand, verfolgt Kosten oder versendet die Rechnung. Wenn beide Gruppen tagsüber mit zusammengehörigen Datensätzen arbeiten müssen, kann DualRide diese Arbeit verbinden, ohne alle in dieselbe App zu zwingen. Nehmen wir einen interessenten Zu-Bargeld-Prozess als Beispiel. Ein Vertriebsmitarbeiter arbeitet mit einem potenziellen Kunden Dynamics 365.

Er erfasst den Kontakt, bespricht Produkte, erstellt ein Angebot und arbeitet auf einen Auftrag hin. Während dieses Gesprächs benötigt der Vertriebsmitarbeiter Kundendetails, Produktinfos, Preise und Auftragsinformationen, die den Finanzbereich des Unternehmens betreffen. Sobald der Verkauf zustande kommt, benimmt das Finanz- und Supply Chain Management die Arbeit, die auf das Versprechen folgt, folgt. Es kümmert sich um die Auftragsabwicklung, Lagerfakturierung und Finanzunterlagen. DualRide hilft dabei, diese beiden Bereiche miteinander zu verbinden. Vertriebsmitarbeiter können in der für ihre Aufgabe passenden Kunden-App arbeiten, während Finanz und Betrieb die Transaktion in ihrer spezifischen App verwalten. Der Kunde wird so nicht zu zwei getrennten Geschichten einer vom Vertrieb und einer vom Finanzwesen erzählt. FieldService liefert ein weiteres gutes Beispiel. Stellen Sie sich ein Unternehmen vor, das Techniker zur Installation, Reparatur oder Wartung von Geräten bei Kunden vor Ort schickt.

Der Außendienstmitarbeiter benötigt Kundendetails, Informationen zur Arbeit und zum Kundenwert des Artikels, den das Unternehmen installiert oder betreut. Hinter den Kulissen muss das Unternehmen zudem Teile, Kosten, Einkauf und die mit dieser Arbeit verbundenen Gelder nachverfolgen. FieldService konzentriert sich auf die Planung und Durchführung des Besuchs. Finanz und Betrieb konzentrieren sich auf die damit verbundenen operativen und finanziellen Aufzeichnungen. Wenn diese Datensätze korrekt verknüpft sind, steht die Arbeit eines Technikers nicht losgelöst von den verwendeten Teilen, den Arbeitskosten oder dem verknüpften Kundendatensatz. Project Operations folgt dem gleichen Muster, insbesondere für Unternehmen, die arbeitprojektbezogen verkaufen. Ein Projektteam verwaltet möglicherweise Kundenarbeit, Zeitaufwand, geplante Kosten und Projektmeilensteine. Das Finanzwesen muss die finanzielle Seite von Einkauf, Kosten, Abrechnung und Berichterstattung sehen.

Ohne Verbindung verbringen Projektmanager zu viel Zeit damit, das Finanzwesen auf Updates zu drängen, während dieses auf Bestätigung der Projektteams wartet. Verknüpfte Projektdatensätze bieten beiden Gruppen einen klareren Überblick über die Arbeit, während sie vom Kunden versprechen, die die finanzielle Aktivität übergeht. Es gibt hier auch einen breiteren Nutzen der Power-Plattform, da die Kunden-App Dataverse nutzt und genehmigte Daten in Dataverse Power-Apps und Power Automate unterstützen können. Ein Unternehmen könnte eine kleine App für ein internes Team bauen oder einen Flow erstellen, der reagiert, wenn ein Geschäftsdatensatz einen bestimmten Punkt erreicht. Das bedeutet nicht, dass jeder Finanz- und Betriebsdatensatz plötzlich in jede Power-App gehört. Das bedeutet, dass verbundene Datensätze Teil einer breiteren Palette von Geschäftstools werden können, sofern das Unternehmen diesen Zweck sorgfältig wählt und die Daten ums gemäß schützt.

Eine Grenze muss dabei klar bleiben. DualWrite unterstützt kein Dynamics 365 Business Central. Business Central kann zwar über andere Methoden mit Microsoft-Produkten verbunden werden, aber DualWrite ist für den Finest-in-Operations-Teil von Dynamics 365 und Dataverse-basierte Kunden-Apps gedacht. Es ist auch kein Werkzeug, um jede beliebige Tabelle zu kopieren, die man finden kann. Ein Datensatz sollte nur verschoben werden, wenn Anwender denselben operativen Datensatz an beiden Stellen benötigen, nicht, weil sich Datenkopien sichere anfühlen. DualWrite ersetzt auch keinen umfassenderen Integrationsplan, wenn ein Unternehmen Reporting-Feeds, Anbindung an Drittsysteme oder eine große Datenmigration benötigt. Jede Datenverbindung als identische Aufgabe zu behandeln, führt schnell zu Problemen. Grenzen, Vorbereitung und häufige Fehler. Stellen Sie sich DualWrite wie eine per Handschlag besiegelte Vereinbarung zwischen zwei Seiten.

Sie vereinbaren, bestimmte gemeinsame Datensätze synchron zu halten, aber es ist keine magische Leitung für jede Tabelle, jeden Bericht oder jedes externe System. Bevor Sie es einrichten, prüfen Sie, welche Integrationen bereits existieren. Wenn eine alte Verbindung und DualWrite gleichzeitig denselben Kundendatensatz aktualisieren, können schnell Konflikte entstehen. Es sind Kopfschmerzen, die Sie nicht haben. Also vereinbaren Sie zuerst die Grundlage. Wie werden Sie Namen eingeben? Welches rechtliche Unternehmen besitzt welchen Datens? Wer darf Änderungen vornehmen? Welche Sicherheitsrollen benötigt jedes Team? Dubletten und unvollständige Datensätze vor der ersten Synchronisierung. Beginnen Sie mit den vorgefertigten Mappings von Microsoft. Diese verbinden bereits gängige Datensätze. Benutzerdefinierte Tabellen und Felder erfordern sorgfältige Tests. Prüfen Sie auch verwandte Tabellen und Mappingabhängigkeiten.

Da manchmal ein Datensatz die Existenz eines anderen voraussetzt, bevor er synchronisiert werden kann. Planen Sie Ihre erste Synchronisierung basierend auf der Menge Ihrer Daten. Behandeln Sie es nicht wie ein Lichtschalter, den man mit der Mittagspause umlegt. Das führt zu Problemen. Ein angehaltenes Mapping benötigt dennoch einen Verantwortlichen und einen Neustart. In der Warteschlange befindliche Änderungen und fehlgeschlagene Datensätze bleiben nicht ewig bestehen. Obachten Sie die Aktivitätsprotokolle, Fehler, Warnungen und Schwellenwerte. Wenn etwas fehlschlägt, finden Sie das fehlende Feld, den fehlerhaften Datensatz oder die verletzte Regel dahinter. Wiederholte Versuche beheben keine fehlerhaften Daten. Wenn Sie DualWrite als eine kontrollierte Brücke betrachten, fügt sich alles zusammen. Fazit, ein gemeinsamer geschäftlicher Dialog. DualWrite hält unterstützte gemeinsame Datensätze zwischen Finds & Operations und ihren Dataverse-basierten Kundenapps in Bewegung.

Auf diese Weise können Teams mit vernetzten Geschäftsdaten arbeiten. Abonnieren Sie auf Ihrer bevorzugten Podcast-Plattform für weitere Wissenshäppchen mit mir, Mirko Peters, unter M365-WMM. Und teilen Sie diese Folge mit jemandem, der Vertrieb, Service und Finanzen immer noch über eine weitere Tabellenkalkulation verbindet. Und dann, wenn Sie das mit einem neuen Datenkalkulationen haben, können Sie das mit einem neuen Datenkalkulation verbindet.