Sprzedawca aktualizuje adres klienta. Później dział finansowy otwiera ten sam rekord i wciąż widzi stary adres. Który adres jest więc poprawny? Przez lata naprawa tego oznaczała eksportowanie danych, edycję arkusza, wysyłkę e-mailem i dwukrotne wpisywanie tej samej zmiany w drugiej aplikacji. Dual Write w Dynamics 365 to zmienia. Łączy aplikacje finansowo-operacyjne z aplikacjami dla klientów opartymi na datavers, dzięki czemu współdzielone rekordy jak klienci i zamówienia są synchronizowane automatycznie. Witajcie, jestem Milko Peters z M365FM, a ta pigułka wiedzy wyjaśnia funkcję Dual Write prostym językiem. Omówimy, co jest przesyłane, jak, gdzie Dual Write pasuje, a gdzie nie znajduje zastosowania. Zacznijmy od problemu biznesowego, który stworzył potrzebę jego istnienia. Problem, który rozwiązuje Dual Write Wyobraź sobie firmę, w której dwa zespoły pracują z tym samym klientem, ale używają zupełnie innych aplikacji na co dzień.

Aplikacje finansowo-operacyjne obsługują zaplecze administracyjne. To finanse, zapasy, produkty, zamówienia, zakupy i łańcuch dostaw. To tutaj firma śledzi, co sprzedaje, co może dostarczyć, co jest winna i co klient musi zapłacić. Aplikacje dla klientów skupiają się na pracy bliżej klienta. Zespoły sprzedaży śledzą LIDI i budują szansę sprzedaży. Obsługa klienta zajmuje się pytaniami i zgłoszeniami. Serwis terenowy planuje zadania i wysyła pracowników do klientów. Zespoły projektowe śledzą pracę obiecaną klientowi. Różna praca wymaga różnych ekranów. Sprzedawca nie powinien musieć przekopywać się przez ekran finansowy tylko po to, by zaktualizować kontakt po rozmowie. Ale użytkownik finansowy potrzebuje danych klienta i zamówienia zgodnych z tym, co widzi sprzedaż, bo faktury i dostawy zależą od tych informacji. Bez połączenia jeden klient po cichu staje się dwoma rekordami. Dział sprzedaży może mieć Norwind Bikes, a dział finansowy Norwind Bicycle Company.

Jeden rekord ma nowy adres, drugi wciąż wysyła faktury do starego biura. Oba rekordy wyglądają poprawnie, ale nie opisują już tej samej relacji biznesowej. Najpierw pojawiają się małe problemy. Ktoś nie może znaleźć klienta, ponieważ nazwa w innej aplikacji jest inna. Handlowiec obiecuje cenę lub sprawdza zapasy, ale informacje nie zgadzają się z częścią operacyjną. Dział finansowy musi przetworzyć zamówienie, ale dane klienta wymagają sprawdzenia e-maila i kolejnej ręcznej aktualizacji. Wtedy te małe problemy narastają. Ktoś eksportuje dane klienta do arkusza kalkulacyjnego. Ktoś inny poprawia kilka wierszy i importuje je gdzie indziej. Ktoś jeszcze wprowadza nowego klienta w obu aplikacjach, bo nikt nie wie, który rekord pojawi się pierwszy. Wkrótce pojawiają się duplikaty, różne adresy i więcej czasu spędza się na sprawdzaniu danych niż na ich używaniu. Nic z tego nie dzieje się dlatego, że ludzie są nieostrożni.

Dzieje się tak, ponieważ systemy wymagają od ludzi bycia łącznikami. Ludzie kopiują dane. Ludzie muszą pamiętać, która aplikacja jest pierwsza. Ludzie dostrzegają błędy dopiero wtedy, gdy trafią one do innego zespołu. Takie podejście sprawdzało się, gdy systemy biznesowe były oddzielne, a zespoły godziły się na opóźnienia. Jednak gdy sprzedaż, serwis, finanse i operacje potrzebują tych samych informacji o kliencie w ciągu dnia, arkusz kalkulacyjny staje się słabym narzędziem przekazu. Pomyśl o prostej rozmowie dotyczącej zamówienia. Klient dzwoni do działu sprzedaży i pyta, czy możecie dostarczyć towar w przyszłym tygodniu? I ile to będzie kosztować? Zespół sprzedaży potrzebuje szczegółów dotyczących produktu, ceny i stanu magazynowego, aby odpowiedzieć. Gdy klient wyrazi zgodę, działy finansów i operacji potrzebują odpowiednich informacji o kliencie i zamówieniu, aby sfinalizować sprzedaż.

Obie strony potrzebują tych samych faktów. Dział sprzedaży potrzebuje tych faktów w aplikacji, w której pracują sprzedawcy. Działy finansów i operacji potrzebują ich w aplikacji, w której zarządzają zamówieniami, pieniędzmi i dostawami. Celem nie jest zmuszanie każdego zespołu do korzystania z jednego wielkiego ekranu. Celem jest to, aby udostępnione rekordy podążały jasną, uzgodnioną ścieżką. W tym momencie do gry wkracza Dual Write. Czym właściwie jest Dual Write? Oto najprostsza definicja. Dual Write to wbudowane połączenie Microsoft, które utrzymuje wybrane dane w synchronizacji między aplikacjami Dynamics 365, Finance & Operations, a Dataverse. Dataverse to wspólny fundament danych dla wielu aplikacji biznesowych Microsoft. Korzystają z niego Dynamics 365 Sales, Customer Service, Field Service oraz części Project Operations. Mogą z niego korzystać również Power Apps i Power Automate.

Nie musisz wiedzieć, jak Dataverse przechowuje każdy rekord, aby zrozumieć Dual Write. Po prostu myśl o nim jak o wspólnym obszarze danych po stronie aplikacji klienckich Dynamics 365. Wyobraź sobie budynek biurowy z front office i back office. Front office obsługuje rozmowy z klientami, sprzedawcy, agenci serwisu, pracownicy terenowi. Wszyscy potrzebują ekranów, które pomagają im rozmawiać z ludźmi, śledzić zgłoszenia i zarządzać pracą. Back office obsługuje pracę, która utrzymuje firmę w ruchu. Nasze rejestry finansowe, stany magazynowe, zamówienia, zakupy, dostawy. Oba biura pracują dla tej samej firmy, ale bez odpowiedniego połączenia między nimi, ktoś musi przenosić informacje z jednej strony na drugą. Przynoszą wydrukowany formularz, wysyłają e-mail lub kopiują dane do innego systemu. Praca zostaje wykonana, ale zajmuje to więcej czasu, a szczegóły mogą zmienić się po drodze. Dual Write jest jak strzeżone wewnętrzne przejście między tymi dwoma biurami.

Gdy obsługiwany rekord zmienia się po jednej stronie, Dual Write przekazuje powiązaną zmianę przez to przejście na drugą stronę. Nie łączy to wszystkich aplikacji w jeden gigantyczny program. Dział sprzedaży nadal pracuje w swoim środowisku. Dział finansów nadal pracuje w swoim środowisku. Każdy zespół zachowuje ekrany stworzone do swojej pracy, podczas gdy wybrane współdzielone informacje pozostają połączone w tle. To słowo obsługiwane ma znaczenie. Dual Write nie kopiuje bezmyślnie każdego fragmentu danych w obu systemach. Działa poprzez zdefiniowane powiązania między rekordami, które do siebie pasują. Microsoft nazywa te połączenia mapami tabel. Tabela to po prostu miejsce, w którym aplikacja przechowuje jeden typ rekordu. Tabela klientów przechowuje rekordy klientów. Tabela produktów przechowuje rekordy produktów. Tabela adresów przechowuje szczegóły adresowe. Mapa tabeli informuje Dual Write, która tabela po stronie finansów i operacji łączy się z którą tabelą w Dataverse.

Pomyśl o mapie tabeli jak o uzgodnionym arkuszu tłumaczeń. Jedna kolumna identyfikuje rekord po jednej stronie. Druga kolumna identyfikuje odpowiadający mu rekord po drugiej stronie. Reszta arkusza wyjaśnia, które pola do siebie pasują. Nazwa, numer telefonu, linia adresu. To porozumienie określa zasady połączenia. Bez tego dwie aplikacje mogłyby używać różnych etykiet lub przechowywać te same dane w różnych miejscach. Mapa mówi systemowi Dual Write, jak te szczegóły są ze sobą powiązane. Dzięki temu aplikacje nie wymagają za każdym razem interpretacji przez człowieka. Często słysząc nazwę Dual Write ludzie zakładają, że oznacza ona, iż każda zmiana zawsze odbywa się w obie strony. Czasami tak jest. W przypadku obsługiwanej mapy dwukierunkowej zmiana w Dataverse może zaktualizować powiązany rekord w Finance and Operations. Obsługiwana zmiana w Finance and Operations może również zaktualizować powiązany rekord w Dataverse.

Obie strony mogą brać udział w tym samym współdzielonym rekordzie. To jest właśnie część Dual. Aktualizacja odbywa się w czasie niemal rzeczywistym. Dzieje się to szybko w trakcie pracy, zamiast czekać na zaplanowane zadanie uruchamiane w nocy. Użytkownik aktualizuje obsługiwany rekord, a połączenie przesyła tę aktualizację, gdy praca jest jeszcze bieżąca. Czas niemal rzeczywisty nie oznacza magii ani braku opóźnień. Oznacza to, że połączenie jest stworzone do bieżącej pracy biznesowej, a nie do wymiany plików raz dziennie. Jeśli ktoś zmieni jakiś szczegół, powiązany zespół nie musi czekać do jutra rana, aby go zobaczyć. To zmienia sposób, w jaki zespoły mogą pracować. Dział front office może korzystać z danych pochodzących z zaplecza. Zaplecze może otrzymywać obsługiwane aktualizacje z aplikacji skierowanych do klientów. Dataverse staje się fundamentem danych po jednej stronie, Finance and Operations pozostaje fundamentem operacyjnym po drugiej, a Dual Ride utrzymuje zatwierdzone współdzielone rekordy w połączeniu.

Mimo to, aktywne wewnętrzne przejście wymaga zasad. Zanim pozwolisz rekordowi podróżować w obu kierunkach, musisz wiedzieć, gdzie powinien się zacząć, kto może go zmieniać i która strona powinna mieć pierwszeństwo, gdy aplikacje się różnią. Jakie dane mogą być przesyłane i który system jest ich właścicielem? Jakie rekordy może synchronizować funkcja Dual Ride? Typowe przykłady obejmują rekordy, z których wiele działów korzysta na co dzień. Rekordy klientów, adresy, kontakty, produkty, dostawcy, dane firmy oraz informacje referencyjne używane w finansach i podatkach. Zastanówmy się przez chwilę nad rekordem klienta. Dział sprzedaży potrzebuje nazwy klienta, głównego kontaktu, numeru telefonu i adresu dostawy. Dział finansowy potrzebuje prawnego rekordu klienta, danych do rozliczeń oraz informacji niezbędnych do obsługi zamówień i faktur. Jeśli każdy dział prowadzi własną, oddzielną listę klientów, firma traci czas na porównywanie rekordów zamiast na obsługę klienta.

Dzięki odpowiednim mapowaniom Dual Ride zespoły te mogą pracować na połączonych danych klientów. Nie oznacza to, że użytkownicy działu sprzedaży muszą nagle uczyć się obsługi aplikacji finansowej. Oznacza to, że mogą pracować z informacjami o kliencie w Dynamics 365 Sales, podczas gdy dział finansowy pracuje z powiązanymi danymi w systemie finansowym. Klient pozostaje rozpoznawalny jako ten sam podmiot w obu miejscach. Adresy również mają znaczenie. Klient może mieć adres do rozliczeń, adres dostawy oraz ewentualnie lokalizację, którą musi odwiedzić pracownik serwisu. Tych szczegółów nie można traktować jako zwykłego tekstu skopiowanego do jednego pola, ponieważ każdy adres pełni inną funkcję. Dual Ride wspiera wspólną strukturę rekordów wymaganą dla tej relacji. Kontakty działają w ten sam sposób. Jedna firma kliencka może mieć kupca kontakt w dziale zobowiązań oraz kierownika serwisu. Dział sprzedaży musi wiedzieć, kto podejmuje decyzję.

Dział finansowy musi wiedzieć, do kogo kierować pytania dotyczące rozliczeń. Dział serwisu musi wiedzieć, kto czeka na miejscu. Połączone rekordy pomagają każdemu zespołowi widzieć osoby przypisane do klienta bez konieczności wprowadzania tych informacji w każdej aplikacji z osobna. Kolejnym częstym przykładem są produkty. Przedstawiciel handlowy musi wiedzieć, co firma sprzedaje, jaki jest koszt produktu i czy jest on dostępny w magazynie. Odpowiedzi na te pytania zazwyczaj pochodzą z operacyjnej strony biznesu, ponieważ tam zarządzane są produkty, stany magazynowe, zakupy i realizacja zamówień. Dlatego informacje o produkcie często powstają w module finansowo-operacyjnym. Zespół operacyjny tworzy tam i przygotowuje produkt. Gdy produkt jest gotowy do oferty dla klienta, Dual Ride może wysłać powiązane szczegóły produktu do Dataverse. Użytkownicy sprzedaży mogą następnie wybrać i omówić produkt w swojej aplikacji bez konieczności ponownego wprowadzania listy produktów.

Pomaga to utrzymać rozmowy sprzedażowe w oparciu o to, co firma faktycznie może dostarczyć. Szczegóły dotyczące cen i zapasów również mogą trafiać do działu sprzedaży za pośrednictwem połączonych aplikacji. Zamiast zgadywać, czy dany towar istnieje, czy cena się zmieniła lub czy stan magazynowy pozwoli na realizację obietnicy, zespół sprzedaży może polegać na informacjach powiązanych ze stroną operacyjną. To nie eliminuje potrzeby dobrego osądu w sprzedaży. Eliminuje to jeden z możliwych do uniknięcia powodów, dla których przedstawiciel handlowy dzwoni do magazynu tylko po to, by potwierdzić podstawowe szczegóły. Informacje o dostawcach mogą również łączyć się tam, gdzie wymaga tego proces biznesowy. Dane firmy, struktury organizacyjne, finansowe dane referencyjne oraz podatkowe dane referencyjne mogą mieć znaczenie zarówno po stronie klienta, jak i operacji. Dokładne rekordy zależą od aplikacji i procesów używanych przez firmę, ale wzorzec pozostaje ten sam.

Udostępniaj te rekordy, które muszą oznaczać to samo w obu miejscach. Pamiętaj jednak, że nie każdy rekord powinien być przesyłany w obu kierunkach. Niektóre aplikacje obsługują dwukierunkowe aktualizacje. Zmiana może rozpocząć się w Dataverse i przejść do finansów i operacji lub rozpocząć się w finansach i operacjach i przejść do Dataverse. Takie podejście sprawdza się w przypadku rekordów, w których obie strony mają uzasadniony powód biznesowy, by aktualizować zatwierdzone dane. Inne mapowania działają tylko w jedną stronę. Produkty stanowią przydatny przykład. W wielu firmach to finanse i operacje odpowiadają za tworzenie produktów, ponieważ kontrolują one kartotekę produktów, stany magazynowe, jednostki i inne szczegóły potrzebne do sprzedaży i dostaw. Produkt następnie trafia do Dataverse, gdzie zespoły sprzedaży i serwisu mogą go używać. To jasna zasada. Produkt nie potrzebuje dwóch zespołów tworzących konkurencyjne wersje.

Jedna strona tworzy i zarządza produktem, druga strona otrzymuje go i wykorzystuje w swojej pracy. Każdy współdzielony rekord wymaga takiej decyzji. Gdzie ten rekord ma swój początek? Kto może go edytować? Jeśli nazwa, adres, cena lub klasyfikacja wydają się błędne, który zespół to naprawia? Te pytania brzmią prosto, ale zapobiegają wielu nieporozumieniom w przyszłości. Połączenie może bardzo szybko przenieść zmianę. Jeśli nikt nie ustalił, kto odpowiada za tę zmianę, równie szybko może przenieść błąd. Wybierz właściciela dla rekordu, a w razie potrzeby, dla poszczególnych szczegółów wewnątrz tego rekordu. Na przykład dział sprzedaży może odpowiadać za dane o relacjach z klientem i główne informacje kontaktowe. Dział finansów może zarządzać danymi płatności, a operacje danymi o produktach i zapasach. Dokładny podział zależy od sposobu działania Twojej firmy, ale musi być on spisany i zrozumiały dla osób korzystających z aplikacji.

Istnieją również dwa terminy, które możesz zobaczyć po rozszerzeniu Dataverse przez Dual Write, Party, strona i Company, firma. Party to sposób Microsoftu na spójne traktowanie osoby lub organizacji. Pomaga łączyć ludzi organizacje, kontakty i adresy bez konieczności traktowania każdej relacji jako osobnego, niepowiązanego rekordu. Company pomaga Dataverse zrozumieć kontekst firmy biznesowej używany w finansach i operacjach. Nie musisz zostać ekspertem od żadnego z tych terminów pierwszego dnia. Wystarczy wiedzieć, że istnieją, ponieważ moduł finansowo-operacyjny obsługuje struktury biznesowe, które aplikacje klienckie muszą rozpoznawać, gdy rekordy przenoszone są między tymi dwoma obszarami. Gdy rekordy mogą przemieszczać się w obu kierunkach, proces związany z tymi rekordami jest równie ważny, co same dane. Jak zmiany przesyłane są między aplikacjami? Śledźmy jedną zmianę w systemie i zobaczmy, co właściwie się dzieje.

Przedstawiciel handlowy rozmawia z klientem, który właśnie przeniósł się do nowego biura. Podczas tej rozmowy przedstawiciel otwiera rekord klienta w Dynamics 365 Sales i aktualizuje adres ulicy. Proste, prawda? Następnie zapisuje rekord. I tutaj zaczyna się najciekawsza część. Moduł Sales zapisuje te zmiany w Dataverse, czyli stronie danych dla aplikacji obsługujących klientów. Następnie funkcja Dual Write sprawdza mapę łączącą informacje o kliencie i adresie między tą witryną a modułem finansowo-operacyjnym. Automatycznie przesyła odpowiednią zmianę, bez plików eksportu zalegających w udostępnionym folderze i czekających na odbiór. Nikt nie musi pisać do działu finansów, hej, proszę, zaktualizujcie ten adres. Mapa już wie, które pola są powiązane i przesyła obsługiwaną zmianę bezpośrednio do powiązanego rekordu klienta w module finansowo-operacyjnym. Dzięki temu użytkownik działu finansów może później otworzyć rekord klienta, zobaczyć zaktualizowany adres i przetworzyć zamówienie lub przygotować fakturę bez żadnych opóźnień.

To praktyczny rezultat, po prostu. Dwie osoby pracują w różnych aplikacjach, ale żadna nie musi ponownie wpisywać tych samych danych klienta. Przedstawiciel handlowy pracuje na ekranie zaprojektowanym do rozmów z klientami. Użytkownik z działu finansów pracuje na ekranie stworzonym do pracy finansowej. Każda osoba widzi dokładnie te informacje o kliencie, których potrzebuje, dokładnie tam, gdzie ich potrzebuje. Ta droga działa również w drugą stronę. Wyobraźmy sobie, że dział finansów aktualizuje obsługiwane informacje o kliencie w module finansowo-operacyjnym. Załóżmy, że użytkownik finansowy poprawia szczegół dotyczący operacyjnego rekordu klienta. Funkcja DualRide wykorzystuje pasującą mapę w odwrotnym kierunku i przesyła te aktualizacje do Dataverse. Następnie aplikacja Sales, Customer lub dowolna inna aplikacja oparta na Dataverse może ją pobrać. To połączenie jest synchroniczne w przypadku standardowej codziennej pracy.

Synchroniczność oznacza, że aplikacje starają się ukończyć powiązaną aktualizację w tym samym momencie pracy, zamiast przerzucać ją do zadania w tle, które może uruchomić się dopiero za 20 minut. Jeśli połączenie nie może ukończyć aktualizacji, problem wymaga natychmiastowej uwagi, a nie ukrywania się, dopóki ktoś nie zauważy niespójności. Takie zachowanie ma sens w przypadku współdzielonych rekordów biznesowych. Nie chcesz, aby adres klienta, szczegóły produktu lub inne wspólne informacje rozbiegły się na godziny tylko dlatego, że zadanie wsadowe jeszcze się nie uruchomiło. Ludzie podejmują decyzję w oparciu o to, co widzą na swoich ekranach w danej chwili. Połączenie utrzymuje obie strony w ścisłej synchronizacji podczas pracy. Nawet aktywna praca wymaga czasem kontrolowanej przerwy. Funkcja podwójnego zapisu obejmuje opcje odtwarzania, wstrzymywania i nadrabiania zaległości. Odtwarzanie oznacza, że mapa działa, a obsługiwane zmiany są przesyłane normalnie.

Wstrzymanie tymczasowo zatrzymuje mapę, gdy zespół musi wykonać planowane prace, zbadać problem lub bezpiecznie zarządzić zmianą. Jednak wstrzymanie nie jest miejscem na stałe. Gdy mapa jest wstrzymana, zmiany mogą być kolejkowane przez ograniczony czas i miejsce. Po wznowieniu działania mapy, funkcja nadrabiania przetwarza oczekujące zmiany. Pomaga to zespołom odzyskać sprawność po planowanej przerwie. Ktoś musi jednak zarządzać tą pauzą i wiedzieć, kiedy mapa powinna zacząć działać ponownie. Zanim to wszystko zacznie się w codziennej pracy, istnieje inny krok – synchronizacja początkowa. Synchronizacja początkowa sprowadza istniejące rekordy z obu stron do wspólnego punktu wyjścia. Pomyśl o firmie, która ma już klientów w module finansowo-operacyjnym oraz rekordy klientów w Dataverse. Połączenie nie może po prostu się włączyć i zakładać, że każdy istniejący rekord już idealnie pasuje. Wymaga linii startowej.

Synchronizacja początkowa pomaga przenieść istniejące dane, zanim użytkownicy zaczną polegać na aktualizacjach na żywo. Ta praca wymaga staranności, ponieważ zduplikowane rekordy, niekompletne adresy i stare dane testowe nie czyszczą się magicznie tylko dlatego, że uruchomiono synchronizację. Mogą one wręcz szybciej tworzyć problemy, jeśli rekordy nie przestrzegają ustalonych zasad. Gdy mapy już działają, osoby zarządzające podwójnym zapisem potrzebują przejrzystego miejsca do sprawdzania jego stanu. Podwójny zapis zapewnia połączone dzienniki aktywności i błędów, dzięki czemu administratorzy widzą, co połączenie przetworzyło i gdzie wystąpiły problemy. Mogą oni również ustawiać alerty i progi. Oznacza to, że odpowiednie osoby dowiedzą się o problemach, zanim użytkownicy odkryją je poprzez brakującą lub nieudaną aktualizację. Ten widok wsparcia jest ważny, ponieważ każdy błąd ma swoją przyczynę.

Może brakuje wymaganego pola? Może powiązany rekord jeszcze nie dotarł? Może ktoś zmienił dane w sposób, który nie pasuje do mapy? Ponowienie próby zapisu nieudanego rekordu bez naprawienia przyczyny zazwyczaj prowadzi do tej samej awarii. Dobrze prowadzona konfiguracja podwójnego zapisu monitoruje połączenie, usuwa przyczyny błędów i utrzymuje mapy skupione na rekordach, które naprawdę muszą pozostać połączone. Gdzie podwójny zapis sprawdza się najlepiej? Podwójny zapis sprawdza się najlepiej, gdy firma używa Dynamics 365 Finance lub Supply Chain Management wraz z aplikacjami dla klientów, takimi jak sprzedaż obsługa klienta, serwis terenowy lub operacje projektowe. Aplikacje te wspierają różne części tej samej konwersacji biznesowej. Jeden zespół rozmawia z klientem, inny planuje dostawę, zarządza zapasami, śledzi koszty lub wysyła fakturę. Gdy obie grupy muszą w ciągu dnia pracować na powiązanych rekordach, funkcja Dual Ride może połączyć te prace bez zmuszania wszystkich do korzystania z tej samej aplikacji.

Weźmy za przykład proces od potencjalnego klienta do gotówki. Sprzedawca pracuje z potencjalnym klientem w Dynamics 365 Sales. Śledzi kontakt, omawia produkty, tworzy ofertę i dąży do złożenia zamówienia. Podczas tej rozmowy sprzedawca potrzebuje danych klienta, informacji o produktach, cen i informacji o zamówieniach, które dotyczą finansowej strony firmy. Gdy sprzedaż staje się faktem, moduł finansów i zarządzania łańcuchem dostaw przejmuje pracę, która następuje po złożeniu obietnicy. Obsługuje on realizację zamówienia, rozliczanie zapasów i dokumentację finansową. Dual Ride pomaga utrzymać te dwie części w połączeniu. Sprzedawcy mogą pracować w aplikacji dostosowanej do ich zadań, podczas gdy dział finansowy i operacyjny zarządza transakcją w aplikacji stworzonej do ich pracy. Klient nie staje się dwiema oddzielnymi historiami, jedną opowiadaną przez sprzedaż, a drugą przez finanse. Field Service stanowi kolejny dobry przykład.

Wyobraźmy sobie firmę, która wysyła techników do instalacji, naprawy lub konserwacji sprzętu w siedzibach klientów. Pracownik terenowy potrzebuje danych klienta, szczegółów pracy oraz informacji o zasobie klienta, czyli przedmiocie zainstalowanym lub serwisowanym przez firmę. Za kulisami firma musi również śledzić części, koszty, zakupy i środki pieniężne powiązane z tą pracą. Field Service koncentruje się na planowaniu i realizacji wizyty. Dział finansowo-operacyjny koncentruje się na powiązanej z tym ewidencji operacyjnej i finansowej. Gdy te rekordy są odpowiednio połączone, praca technika nie jest oddzielona od użytych części, kosztów pracy czy powiązanego rekordu klienta. Project Operations wpisuje się w ten sam wzorzec, zwłaszcza w firmach sprzedających pracę w ramach projektów. Zespół projektowy może zarządzać pracą dla klienta, czasem pracowników, planowanymi kosztami i kamieniami milowymi projektu.

Dział finansowy musi widzieć finansową stronę zakupów, kosztów, rozliczeń i raportowania. Bez połączenia kierownicy projektów mogą tracić zbyt wiele czasu na ściganie finansów o aktualizację, podczas gdy finanse czekają na potwierdzenie zdarzeń przez zespoły projektowe. Połączone rekordy projektowe zapewniają obu grupom lepszy wgląd w pracę, gdy przechodzi ona od obietnicy klienta do aktywności finansowej. Istnieje tu również szersza korzyść z Power Platform, ponieważ strona aplikacji klienckiej korzysta z Dataverse, a zatwierdzone dane w Dataverse mogą wspierać Power Apps i Power Automate. Firma może zbudować małą aplikację dla zespołu wewnętrznego lub utworzyć przepływ, który zareaguje, gdy rekord biznesowy osiągnie określony punkt. Nie oznacza to, że każdy rekord finansowy i operacyjny nagle musi znajdować się w każdej aplikacji Power App. Oznacza to, że połączone rekordy mogą stać się częścią szerszego zestawu narzędzi biznesowych, o ile firma starannie wybierze ten cel i odpowiednio zabezpieczy dane.

Jedna granica musi pozostać wyraźna. Dual Lite nie obsługuje Dynamics 365 Business Central. Business Central może łączyć się z innymi produktami Microsoftu za pomocą innych metod, ale Dual Lite jest przeznaczony dla finansów i operacji w Dynamics 365 oraz aplikacji klienckich opartych na Dataverse. Nie jest to również narzędzie do kopiowania każdej napotkanej tabeli. Rekord powinien być przenoszony, ponieważ ludzie potrzebują tego samego zapisu operacyjnego w obu miejscach, a nie dlatego, że kopiowanie danych wydaje się bezpieczniejsze. Dual Lite nie zastępuje też szerszego planu integracji, gdy firma potrzebuje kanałów raportowania, połączeń z systemami zewnętrznymi lub dużej migracji danych. Traktowanie każdego połączenia danych jak tego samego zadania szybko prowadzi do problemów. Ograniczenia, przygotowanie i typowe błędy. Pomyśl o Dual Lite jak o umowie zawartej przez uścisk dłoni między dwoma systemami.

Zgadzają się one utrzymywać pewne współdzielone rekordy w synchronizacji, ale nie jest to magiczny kanał dla każdej tabeli, raportu czy systemu zewnętrznego. Zanim go skonfigurujesz, sprawdź, jakie integracje już istnieją. Jeśli stare połączenie i Dual Lite aktualizują ten sam rekord klienta, możesz szybko stworzyć konflikty. To ból głowy, którego nie chcesz. Więc najpierw ustalcie podstawy. Jak będziecie wprowadzać nazwy? Która firma prawna jest właścicielem każdego rekordu? Kto może wprowadzać zmiany? Jakich ról zabezpieczeń potrzebuje każdy zespół? Duplikaty i niekompletne rekordy przed pierwszą synchronizacją. Zacznij od gotowych map przygotowanych przez Microsoft. Łączą one już typowe rekordy. Niestandardowe tabele i pola wymagają starannego przetestowania. Sprawdź też powiązane tabele i zależności map, ponieważ czasami jeden rekord wymaga istnienia drugiego, aby mógł zostać zsynchronizowany.

Zaplanuj pierwszą synchronizację w oparciu o ilość posiadanych danych. Nie traktuj tego jak włącznika światła, który pstrykasz podczas przerwy na lunch. To spowoduje problemy. Wstrzymana mapa nadal potrzebuje właściciela i planu restartu. Kolejkowane zmiany i nieudane rekordy nie pozostają w systemie na zawsze. Obserwuj logi aktywności, błędy, alerty i progi. Gdy coś zawiedzie, znajdź brakujące pole, błędny rekord lub stojącą za tym złamaną regułę. Ciągłe ponawianie prób nie naprawi błędnych danych. Kiedy postrzegasz DualRide jako kontrolowany most, wszystko wskakuje na swoje miejsce. Podsumowanie. Jedna wspólna konwersacja biznesowa. DualRide utrzymuje obsługiwane współdzielone rekordy w ruchu między finansami i operacjami, a Twoimi aplikacjami klienckimi opartymi na Dataverse. W ten sposób zespoły mogą pracować na połączonych danych biznesowych. Zasubskrybuj na swojej ulubionej platformie podcastowej, aby uzyskać więcej porcji wiedzy ze mną Mirko Petersem na m365.fm i udostępnij ten odcinek komuś, kto wciąż łączy sprzedaż, serwis i finanse za pomocą kolejnego arkusza kalkulacyjnego.