営業担当者が顧客の住所を更新します 後で経理部門が同じレコードを開いても古い住所のままですではどちらの住所が正しいのでしょうか長年これを修正するには誰かがデータをエクスポートしてスプレッドシートを編集し メールで送信して別のアプリに同じ更新を2度入力する必要がありましたダイナミクス365のデュアルライトがそれを変えます フィナンス&オペレーションズアプリとデータバースベースの顧客アプリを接続することで顧客や注文といった共有レコードが自動的に同期されます M365FMのミルコピーターズです この知識の断片でデュアルライトについてわかりやすく解説します何が移動しどう移動するのかデュアルライトが適している場所と適していない場所について説明します まずはこれが必要となったビジネス上の課題から見ていきましょうデュアルライトが解決する問題同じ顧客を担当しているのに毎日全く異なるアプリを使用している 2つのグループがあるビジネスを想像してくださいフィナンス&オペレーションズアプリはバックオフィスの業務を処理します つまり資金在庫製品注文購買そしてサプライチェーンですここでは会社が何を販売し何を提供でき何に負債があり顧客が何を支払う必要があるかを追跡します 顧客アプリは顧客に近い業務に焦点を当てています営業チームはリードを追い正規を構築します カスタマーサービスは質問やケースに対応しますフィールドサービスは業務を計画し現場に人を派遣します プロジェクトチームは顧客に約束した作業を追跡します異なる業務には異なる画面が必要です 営業担当者が電話の後に連絡先を更新するためだけに経理画面を掘り下げるべきではありませんしかし経理部門のユーザーは営業部門が見ているものと一致した顧客や注文の詳細を必要とします 請求書や配送はその情報に依存しているからです接続がないと一人の顧客が密かに2つのレコードになってしまいます 営業部門ではノースウィンドバイクスと記載されていても経理部門ではノースウィンドバイシクルカンパニーとなっているかもしれませんあちらのレコードには新しい住所がありこちらのレコードは古いオフィスに請求書を送ったまま になっていますどちらのレコードも単体で見れば妥当ですがもはや同じビジネス関係を表してはいません 最初は小さな問題が発生します別のアプリで名前が異なるため誰かが顧客を見つけられないという問題です 営業担当者が価格や在庫状況を伝えてもその情報が現場の運用側と一致しません経理部門は注文を処理する必要がありますが顧客詳細の確認のためにメールのやり取りや 手動での更新が必要になりますやがてそれらの小さな問題が積み重なっていきます 誰かが顧客データをスプレッドシートにエクスポートします別の人が数行を修正してどこか別の場所にインポートします また別の誰かがどちらのレコードが先に現れるかわからないため両方のアプリに新しい顧客を入力してしまいます すぐに重複や住所の不一致が発生しデータを使う時間よりも確認する時間の方が長くなってしまいますこうした問題が起きるのは決して人の不注意のせいではありません システムが人手を介して情報を連携するよう求めているからです人はデータをコピーしなければなりません どのアプリを先に使うべきか覚えておく必要があります他のチームに渡った後でミスに気づくこともあります 以前は業務システムが分断されていてもチームが遅延を受け入れていればそれで機能していましたしかし営業サービス財務運用部門が日中同じ顧客情報を必要とする今 スプレッドシートでの引き継ぎはもはや不十分です単純な注文のやり取りを考えてみましょう 顧客が営業担当に電話し来週届けてもらえると尋ねます企業はいくらと営業チームは回答するために製品価格在庫の詳細を把握する必要があります 顧客が合意したら財務や運用部門は販売を処理するために正確な顧客情報と注文情報が必要になります双方が同じ事実を必要としているのです 営業担当者は日常的に使っているアプリでその事実を確認する必要があります財務や運用担当者は注文や経理配送を管理するアプリでそれらを確認する必要があります 目標はすべてのチームを一つの巨大な画面に無理やり押し込むことではありません共有すべき記録を明確で合意されたルートに従わせることです そこで登場するのがデュアルライトですではデュアルライトとは一体何なのでしょうか最もシンプルな定義を説明しましょう デュアルライトはダイナミクス365フィナンス&オペレーションズアプリとデータバースの間で特定のデータを同期し続けるマイクロソフトの組み込み接続機能です データバースは多くのマイクロソフトビジネスアプリを支える共有データ基盤ですダイナミクス365セールスカスタマーサービスフィールドサービスそしてプロジェクト オペレーションズの一部はすべてこれを使用していますパワーアップスやパワーオートメイトでも使用可能です デュアルライトを理解するためにデータバースがどのように個々のレコードを保存しているかを知る必要はありません単にダイナミクス365の顧客向けアプリ側における共通データエリアと考えてください オフィスビルにフロントオフィスとバックオフィスがあると想像してくださいフロントオフィスは顧客とのやり取りを扱います 営業担当者やサービスエージェントフィールドワーカーなどです彼らは顧客と話し要求を追跡し業務を管理するための画面を必要としていますバックオフィスは会社を運営するための業務を扱います 財務記録在庫注文購買配送などですどちらも同じ会社のために働いていますが適切な連携がないと誰かが情報を手作業で運ばなければなりません 印刷した書類を運んだりメールを送ったり他のシステムにデータをコピーしたりします業務自体は進みますが時間がかかり途中で詳細が書き換わってしまう恐れもあります デュアルライトはこの2つのオフィスの間にある担当者が常駐する打ち扉のようなものです一方のそばで対応レコードが変更されるとデュアルライトはその変更を扉の向こう側へと自動的に伝達します すべてのアプリを一つの巨大なアプリに統合するわけではありません営業部門はこれまで通り営業用アプリで作業できます 財務部門はこれまで通り財務用アプリで作業できます各チームは業務専用の画面を維持しつつ選択された共有情報のみが裏側で連携されます サポートされているという言葉が重要ですデュアルライトは両システムのすべてのデータを無差別にコピーするわけではありません 関連するレコード間の定義された接続を通じて機能しますマイクロソフトはこれらの接続をテーブルマップと呼んでいます テーブルとはアプリがある種類のレコードを保持する単なる場所のことです顧客テーブルは顧客レコードを保持します 製品テーブルは製品レコードを保持します住所テーブルは住所の詳細を保持します テーブルマップはフィナンス&オペレーションズ側のどのテーブルがデータバース側のどのテーブルに接続されるかをデュアルライトに指示しますテーブルマップは合意に基づいた変換シートのようなものだと考えてください 一方の列で片側のレコードを特定しますもう一方の列でそれに対応する反対側のレコードを特定します 残りの部分はどのフィールド同士が対応しているかを示します名前電話番号住所などの項目です その合意によって接続ルールが定まりますそれがなければ2つのアプリで異なるラベルが使われたり 同じ詳細が異なる場所に保存されたりする可能性がありますマップはそうした詳細がどう関連しているかをデュアルライトに伝えます そのためその都度人が介在して解釈させる必要はありませんデュアルライトという名称からすべての変更が常に双方向に反映されると誤解されがちです その場合もありますサポートされた双方向マップではデータバースでの変更がフィナンス&オペレーションズの関連レコードを更新できますフィナンス&オペレーションズでのサポートされた変更もデータバースの関連レコードを更新できます双方が同じ共有レコードに関与できるのです それがデュアル20という部分の意味です更新はほぼリアルタイムで行われます 夜間のバッチ処理を待つのではなく作業に合わせて迅速に反映されますユーザーがサポート対象のレコードを更新すると作業中のその瞬間に接続を通じて更新が送信されますほぼリアルタイムとは魔法や遅延ゼロを意味するわけではありません1日1回のファイル交換ではなくライブのビジネス業務向けに構築された接続であることを意味します誰かが詳細を変更しても関連チームは翌朝まで待つ必要がありません それによってチームの働き方が変わりますフロントオフィスはバックオフィスからのデータを利用できるようになります バックオフィスは顧客向けアプリからのサポートされた更新を受け取れますデータバースが一方のデータ基盤となり フィナンス&オペレーションズがもう一方の業務基盤として残る中でデュアルライトが承認済みの共有レコードを連携し続けます それでも開かれた内部の扉にはルールが必要ですレコードを双方向に移動させる前にそのレコードの発生元変更権限者 そして2つのアプリで不一致が生じた際の優先順位を明確にする必要がありますどのデータを移動できどのシステムが所有するのでしょうか ではデュアルライトはどのレコードを接続し続けることができるのでしょうか一般的な例として多くの部門が日々共有しているレコードから見ていきましょう 顧客レコード住所連絡先製品ベンダー会社詳細そして財務や税務で使用される参照情報などです 顧客レコードについて少し考えてみましょう営業部門は顧客名主な連絡先電話番号配送先住所を必要とします 財務部門は法的な顧客レコード請求詳細および注文や請求書に必要な情報を必要とします 各部門が個別の顧客リストを保持していると会社は顧客への対応ではなくレコードの称号に時間を費やすことになります 適切なデュアルライトマップを設定すれば各チームは接続された顧客詳細に基づいて業務を行えます それは営業ユーザーが突然財務アプリを学ぶ必要があるという意味ではありませんつまりダイナミクス365セールスで顧客情報を扱う一方で 財務ユーザーは関連する顧客情報をファイナンスで扱えるということです顧客は両方の場所で同一の顧客として認識されます 住所も重要です顧客には請求先住所配送先住所そしてサービス担当者が訪問すべき現場などが存在することがあります 各住所には異なる役割があるためこれらの詳細を単なるテキストとして一つのボックスにコピーして扱うことはできません デュアルライトはその関係に必要な共有レコード構造をサポートします連絡先も同様のパターンに従います 一つの顧客企業に購買担当者買いかけ金担当者サービスマネージャーがいる場合があります営業担当者は誰が決定を下すかを知る必要があります 財務担当者は請求に関する質問をどこに送るべきかを知る必要がありますサービス担当者は現場で誰が待っているかを知る必要があります レコードを接続することで各チームはアプリごとに情報を再構築することなく顧客に関連する人物を把握できます製品も一般的な例の一つです 営業担当者は会社が何を販売し製品の価格がいくらで在庫があるかどうかを知る必要がありますそれらの答えは通常製品在庫購買フルフィルメントが管理されているビジネスの運用側から得られ ますそのため製品情報は財務及び運用部門から始まることが多いのです 運用チームはそこで製品を作成し準備しますその製品が顧客向けの作業に利用可能になるとデュアルライトは関連する製品詳細をデータバースに送信できます 営業ユーザーは製品リストを二重入力することなく自分のアプリで製品を選択し商談に利用できますこれにより営業担当者はビジネスが実際に提供可能な内容に基づいて商談を進める ことができます価格や在庫の詳細も接続されたアプリを通じて営業部門に届けられます金目の有無価格変更在庫が約束を裏付けられるかを推測する代わりに営業チームは運用側と 連携した情報に基づいて業務を行えますだからといって優れた営業判断が不要になるわけではありません 営業担当者が基本的な詳細を確認するためだけに倉庫へ電話するという回避可能な手間が一つ省けるのです仕入れ先情報もビジネスプロセスで必要とされる場所と連携させることができます 会社詳細組織構造財務参照データ税務参照データは顧客側と業務側の双方にとって重要になり得ます正確なレコードは企業が使用するアプリやプロセスによって異なりますがパターンは変わりません 双方で同じ意味を持つ必要があるレコードを共有しましょうただし全てのレコードが双方向に移動すべきだとは限りません 一部のアプリは双方向更新をサポートしていますデータバースで変更を開始してフィナンス&オペレーションズへ移動することもその逆も可能です このアプローチは両サイドに承認済み詳細を更新する正当なビジネス上の理由があるレコードに適しています一方で一方向にのみ動作するマップもあります 製品が良い例になります多くの企業では製品マスター在庫単位その他販売や配送に必要な詳細を運用側が管理しているためフィナンス&オペレーションズが製品作成を担います その後製品データはデータバースに送られ営業チームやサービスチームがそれを使用しますこれは明確なルールです製品に関して2つのチームが競合するバージョンを作成する必要はありません 一方が製品を作成管理しもう一方がそれを受け取って業務の一部として使用します共有されるすべてのレコードにはこうした決定が必要です このレコードはどこで生成されるのか誰が編集できるのか名前住所価格分類が間違っている場合どのチームが修正するのかこれらは単純な問いですが後の混乱を大きく防ぐことができます 接続によって変更は非常に迅速に伝達されます変更の責任者が合意されていなければ誤りも同じスピードで拡散してしまいます レコードの所有者を決め必要に応じてそのレコード内の個々の詳細の所有者も決めてください例えば顧客関係の詳細や主要な連絡先情報は営業部門が所有するかもしれません 財務部門が支払い関連の詳細を運用部門が製品や在庫の詳細を所有するといった具合です正確な分担はビジネスの仕組み次第ですがそれを文書化しアプリを使用する全員が理解しておく必要があります デュアルライトによってデータバースが拡張された後パーティーパーティーとカンパニー会社という2つの用語を目にするかもしれません パーティーとは人や組織を一貫した方法で扱うためのマイクロソフトの仕組みですこれによりあらゆる関係をバラバラで無関係なレコードとして扱うことなく 人組織連絡先住所を関連づけることができます会社カンパニーはフィナンス&オペレーションズで使用されるビジネス上の会社コンテキストをデータバースが理解するのに役立ちます 初日から両方の用語の専門家になる必要はありませんフィナンス&オペレーションズはレコードが両社間を移動する際に顧客アプリが認識する必要がある ビジネス構造を扱うためその存在を知っておいてくださいレコードが双方向に移動できるようになるとそのレコードを取り巻くプロセスはデータ そのものと同じくらい重要になります変更がアプリ間をどのように伝播するかシステムを通過する一つの変更を追いかけて 実際に何が起こるかを見てみましょう営業担当者が新しいオフィスに移転したばかりの顧客と電話で話しています 会話の最中に担当者はダイナミクス365セールスで顧客レコードを開き住所を更新しますとても簡単ですよねそしてレコードを保存します ここからが面白いところですセールスはその変更をデータバース顧客向けアプリのデータ基盤に保存します 次にデュアルライトがこのサイトとフィナンス&オペレーションズの間で顧客情報や住所情報をつなぐマッピングを確認しますそして対応する変更を自動的に送信します 共有フォルダーにエクスポートファイルが置かれ誰かが拾い上げるのを待つ必要はありませんこの住所を更新してくださいといったメールを財務部門に送る必要もありません マッピングがどのフィールドがリンクされているかを把握しておりサポートされている変更をフィナンス&オペレーションズの関連顧客レコードへ直接送信します そのため後から財務担当者が顧客レコードを開くと更新された住所が確認でき注文処理や請求書作成を滞りなく進められます これが実用的な結果でありシンプルそのものです2人は異なるアプリで作業を続けますがどちらも同じ顧客詳細を再入力する必要はありません 営業担当者は顧客との会話のために設計された画面で作業します財務担当者は財務作業のために構築された画面で作業します 各担当者は自分が必要とする顧客情報を必要な場所で確認できますそしてこの移動は逆方向でも機能します フィナンス&オペレーションズで財務部門がサポート対象の顧客情報を更新する場合を想像してください例えば財務担当者が運用上の顧客レコードに属する詳細情報を修正したとします デュアルライトは対応するマッピングを逆方向に使いその関連更新をデータバースに送信しますするとセールスや他のデータバースベースのアプリがその変更を取り込めます この接続は日常業務においては同期的に行われます同期的とはアプリが20分後に実行されるかもしれないバックグラウンドジョブに任せるのではなく 同じ作業の瞬間の一部として関連する更新を完了させようとすることを意味します接続が更新を完了できない場合その問題は誰かが不整合に気づくまで静かに隠しておくのではなく すぐに対処する必要がありますこの挙動は共有されるビジネスレコードにとって理にかなっています バッチジョブが未実行だからといって顧客の住所や製品の詳細その他の共有情報が何時間も食い違ったままになるのは避けたいはずです人は画面に今映っている情報に基づいて意思決定を行うのですから このように接続によって作業中も両サイドが密接に同期されます運用中であっても時には意図的に一時停止する必要があります デュアルライトには再生一時停止追いつきキャッチアップのオプションがあります再生とはマップが実行中でありサポートされている変更が通常通り反映される状態です 一時停止はチームが計画的な作業を行う問題を調査するあるいは変更を安全に管理する必要がある場合にマップを一時的に停止するものです ただし一時停止は永続的な待機場所ではありませんマップが一時停止している間変更は一定の期間及び容量まで急に蓄積されます マップを再開するとキャッチアップ機能が待機中の変更を処理しますこれによりチームは計画的な中断から復旧できるようになります ただし誰かがその一時停止を管理しいつマップを再開すべきかを把握しておく必要があります日常業務でこれらを開始する前にもう一つ初期動機というステップがあります 初期動機は両サイドの既存レコードを共通の開始地点に合わせるためのものですフィナンス&オペレーションズにすでに顧客が存在し データバースにも顧客レコードがある企業を考えてみてください接続をオンにしただけで既存のすべてのレコードが完全に一致していると想定することはできません スタートラインが必要なのです初期動機はユーザーがライブ更新に依存する前に既存データを移行するのに役立ちます 重複レコード不完全な住所古いテストデータなどは動機を開始したからといって魔法のように綺麗になるわけではないためこの作業には注意が必要です ルールに従っていないレコードがある場合かえって問題が迅速に発生する可能性がありますマップが実行されたらデュアルライトの管理者はその健全性を確認できる明確な場所を必要とします デュアルライトは統合されたアクティビティログとエラーログを提供するため管理者は接続が何を処理しどこで問題が発生したかを確認できます またアラートや指揮位置を設定することも可能ですこれによりユーザーが更新の失敗や欠落に気づく前に適切な担当者が問題を知ることができます 全てのエラーには原因があるためこのサポートビューは重要ですキスフィールドが欠落しているのかもしれません 関連レコードがまだ到着していないのかもしれません誰かがマップに適合しない方法でデータを変更したのかもしれません 根本的な原因を修正せずに失敗したレコードを再試行しても通常は同じエラーが繰り返されるだけです適切に運用されるデュアルライト設定は接続を監視しエラーの根本原因を修正し 本当に接続を維持する必要があるレコードにマップを集中させますデュアルライトが最も適している場面 デュアルライトはダイナミクス365ファイナンスやサプライチェーンマネジメントを営業顧客サービスフィールドサービスプロジェクト運用などの顧客向けアプリと併用する場合に最適です これらのアプリは一連のビジネス対話の異なる部分をそれぞれサポートしていますあるチームが顧客と対話し別のチームが配送計画 在庫管理コスト追跡請求書発行などを行います両方のグループが日々の業務で関連レコードを扱う必要がある場合 デュアルライトを使えば全員を同じアプリに強制することなくその作業をつなぐことができます見込み客から入金までのプロセスを例に挙げましょう 営業担当者はダイナミクス365セールスで潜在顧客とやり取りをします担当者は連絡先を追跡し製品について話し合い 見積書を作成して注文へと進めていきますその対話の中で営業担当者には顧客の詳細 製品情報価格そして会社の財務部門に関連する注文情報が必要となります販売が確定すると財務サプライチェーン管理部門が契約後の業務を引き継ぎます そこでは注文の履行請求財務記録が処理されますデュアルライトはこれら2つの領域を接続し続けるのに役立ちます 営業担当者は自分たちの仕事に適した顧客向けアプリで作業し財務運用担当者は自分たちの業務向けに構築されたアプリで取引を管理できます 顧客が営業部門が語るストーリーと財務部門が語るストーリーという2つの別々の存在になることはありませんフィールドサービスも良い例です 技術者を派遣して顧客の現場で機器の設置修理保守を行う企業を想像してみてください現場の担当者には顧客の詳細作業内容そして会社が設置またはサポートしている製品の顧客資産情報が必要です その裏側で会社は部品コスト購買そしてその作業に結びつく金銭を追跡する必要がありますフィールドサービスは訪問の計画と官僚に焦点を当てています 財務運用はその周囲の運用面や財務面の記録に焦点を当てていますこれらの記録が正しく接続されていれば技術者の作業が使用した部品作業コスト あるいは関連する顧客レコードから切り離されることはありませんプロジェクトオペレーションも同じパターンに当てはまります 特にプロジェクト単位で仕事を受注する企業には最適ですプロジェクトチームは顧客の作業担当者の時間計画コスト プロジェクトのマイルストーンを管理するかもしれません財務部門は購買コスト請求レポートといった財務面を確認する必要があります 接続がないとプロジェクトマネージャーは進捗確認のために財務部門を追いかけ財務部門はプロジェクトチームからの報告を待つという無駄な時間を過ごすことになります プロジェクトレコードが接続されていれば顧客との約束が財務活動へと移行する過程において双方のグループが作業をより明確に把握できるようになります これにはより広範なパワープラットフォームのメリットもあります顧客アプリ側はデータバースを使用しているため データバース内の承認済みデータがパワーアップスやパワーオートメートをサポートできるからです企業は内部チーム向けに小規模なアプリを構築したり ビジネスレコードが特定の段階に達した時に応答するフローを作成したりできますだからといって財務運用のすべての記録があらゆるパワーアップに含まれるべきだという意味ではありません つまり接続されたレコードは企業がその目的を慎重に選択しデータを適切に保護する限りより広範なビジネスツールのセットの一部となり得るのです 一つの境界線を明確にしておく必要がありますデュアルライトはダイナミクス365ビジネスセントラルをサポートしていません ビジネスセントラルは他の手法でマイクロソフト製品と接続できますがデュアルライトはダイナミクス365のフィナンス&オペレーションズ側と データバースベースの顧客アプリのためのものですまたこれは見つけたすべてのテーブルをコピーするためのツールでもありません レコードを移動すべきなのは両方の場所で同じ業務レコードが必要だからでありコピーした方が安全そうだからという理由ではありません デュアルライトはレポートフィードやサードパーティシステムとの連携あるいは大規模なデータ移行が必要な場合のより広範な統合計画の代わりにもなりません すべてのデータ接続を同じ仕事として扱うとすぐにトラブルが発生します制限事項準備そしてよくある間違い デュアルライトを2つのシステム間の握手による合意のようなものと考えてくださいこれらは特定の共有レコードを同期させることに合意しますがすべてのテーブルやレポート 外部システムのための魔法のパイプではありませんセットアップの前にすでにどのような統合が存在するかを確認してください 古い接続とデュアルライトの両方が同じ顧客レコードを更新するとすぐに競合が発生する可能性があります それは避けたい頭痛の種ですですからまずは基本事項で合意しましょう名前はどのように入力しますか各レコードはどの法人組織が所有しますか 誰が変更を行いますか各チームにはどのようなセキュリティロールが必要ですか最初の同期の前に重複や不完全なレコードを確認してください マイクロソフトの構築済マップから始めてくださいそれらはすでに一般的なレコードを接続済みです カスタムテーブルやフィールドは慎重なテストが必要ですまた関連テーブルとマップの依存関係を確認してください レコードが同期される前に別のレコードの存在が必要な場合があるからですデータの量に基づいて最初の同期を計画してください 昼食中にスイッチを切り替えるような感覚で扱わないでくださいそれは問題を引き起こします 一時停止中のマップにも所有者と再開計画が必要です急に入れられた変更や失敗したレコードはとはには保持されません アクティビティログエラーアラートおよび指揮位置を監視してください何かが失敗したときはその背後にある欠落フィールド不正なレコードまたは壊れたルールを見つけてください繰り返しの再試行では誤ったデータは修正されません デュアルライトを制御された橋として捉えれば全てがうまく噛み合います結論として一つの共有されたビジネスの対話が生まれます デュアルライトはサポート対象の共有レコードをフィナンス&オペレーションズとデータバースベースの顧客アプリの間で往来させ続けます そうすることでチームは接続されたビジネスデータに基づいて業務を行うことができます私のポッドキャストメートル365 fm で知識を深めるためにお気に入りのプラットフォームで購読してください そして未だにスプレッドシートで営業サービス財務をつないでいる誰かとこのエピソードを共有してください