WEBVTT

00:00:00.000 --> 00:00:07.520
営業担当者が顧客の住所を更新します 後で経理部門が同じレコードを開いても古い住所のままですではどちらの住所が正しいのでしょうか

00:00:07.520 --> 00:00:13.320
長年これを修正するには誰かがデータをエクスポートしてスプレッドシートを編集し メールで送信して別のアプリに同じ更新を2度入力する必要がありました

00:00:13.320 --> 00:00:19.860
ダイナミクス365のデュアルライトがそれを変えます フィナンス&オペレーションズアプリとデータバースベースの顧客アプリを接続することで

00:00:19.860 --> 00:00:28.800
顧客や注文といった共有レコードが自動的に同期されます M365FMのミルコピーターズです この知識の断片でデュアルライトについてわかりやすく解説します

00:00:28.800 --> 00:00:37.280
何が移動しどう移動するのかデュアルライトが適している場所と適していない場所について説明します まずはこれが必要となったビジネス上の課題から見ていきましょう

00:00:37.280 --> 00:00:45.740
デュアルライトが解決する問題同じ顧客を担当しているのに毎日全く異なるアプリを使用している 2つのグループがあるビジネスを想像してください

00:00:45.740 --> 00:00:52.220
フィナンス&オペレーションズアプリはバックオフィスの業務を処理します つまり資金在庫製品注文購買そしてサプライチェーンです

00:00:52.220 --> 00:00:59.940
ここでは会社が何を販売し何を提供でき何に負債があり顧客が何を支払う必要があるかを追跡します 顧客アプリは顧客に近い業務に焦点を当てています

00:00:59.940 --> 00:01:04.780
営業チームはリードを追い正規を構築します カスタマーサービスは質問やケースに対応します

00:01:04.780 --> 00:01:10.020
フィールドサービスは業務を計画し現場に人を派遣します プロジェクトチームは顧客に約束した作業を追跡します

00:01:10.020 --> 00:01:16.540
異なる業務には異なる画面が必要です 営業担当者が電話の後に連絡先を更新するためだけに経理画面を掘り下げるべきではありません

00:01:16.540 --> 00:01:23.980
しかし経理部門のユーザーは営業部門が見ているものと一致した顧客や注文の詳細を必要とします 請求書や配送はその情報に依存しているからです

00:01:23.980 --> 00:01:31.960
接続がないと一人の顧客が密かに2つのレコードになってしまいます 営業部門ではノースウィンドバイクスと記載されていても経理部門ではノースウィンドバイシクルカンパニーとなっているかもしれません

00:01:31.960 --> 00:01:36.220
あちらのレコードには新しい住所がありこちらのレコードは古いオフィスに請求書を送ったまま になっています

00:01:36.220 --> 00:01:42.460
どちらのレコードも単体で見れば妥当ですがもはや同じビジネス関係を表してはいません 最初は小さな問題が発生します

00:01:42.460 --> 00:01:49.960
別のアプリで名前が異なるため誰かが顧客を見つけられないという問題です 営業担当者が価格や在庫状況を伝えてもその情報が現場の運用側と一致しません

00:01:49.960 --> 00:01:54.560
経理部門は注文を処理する必要がありますが顧客詳細の確認のためにメールのやり取りや 手動での更新が必要になります

00:01:54.560 --> 00:01:59.280
やがてそれらの小さな問題が積み重なっていきます 誰かが顧客データをスプレッドシートにエクスポートします

00:01:59.280 --> 00:02:06.300
別の人が数行を修正してどこか別の場所にインポートします また別の誰かがどちらのレコードが先に現れるかわからないため両方のアプリに新しい顧客を入力して

00:02:06.300 --> 00:02:11.000
しまいます すぐに重複や住所の不一致が発生しデータを使う時間よりも確認する時間の方が長くなってしまいます

00:02:11.000 --> 00:02:15.980
こうした問題が起きるのは決して人の不注意のせいではありません システムが人手を介して情報を連携するよう求めているからです

00:02:15.980 --> 00:02:19.600
人はデータをコピーしなければなりません どのアプリを先に使うべきか覚えておく必要があります

00:02:19.600 --> 00:02:25.800
他のチームに渡った後でミスに気づくこともあります 以前は業務システムが分断されていてもチームが遅延を受け入れていればそれで機能していました

00:02:25.800 --> 00:02:32.000
しかし営業サービス財務運用部門が日中同じ顧客情報を必要とする今 スプレッドシートでの引き継ぎはもはや不十分です

00:02:32.000 --> 00:02:37.500
単純な注文のやり取りを考えてみましょう 顧客が営業担当に電話し来週届けてもらえると尋ねます

00:02:37.500 --> 00:02:48.080
企業はいくらと営業チームは回答するために製品価格在庫の詳細を把握する必要があります 顧客が合意したら財務や運用部門は販売を処理するために正確な顧客情報と注文情報が必要になります

00:02:48.080 --> 00:02:53.300
双方が同じ事実を必要としているのです 営業担当者は日常的に使っているアプリでその事実を確認する必要があります

00:02:53.300 --> 00:03:01.220
財務や運用担当者は注文や経理配送を管理するアプリでそれらを確認する必要があります 目標はすべてのチームを一つの巨大な画面に無理やり押し込むことではありません

00:03:01.220 --> 00:03:10.100
共有すべき記録を明確で合意されたルートに従わせることです そこで登場するのがデュアルライトですではデュアルライトとは一体何なのでしょうか

00:03:10.100 --> 00:03:17.160
最もシンプルな定義を説明しましょう デュアルライトはダイナミクス365フィナンス&オペレーションズアプリとデータバースの間で特定の

00:03:17.160 --> 00:03:23.340
データを同期し続けるマイクロソフトの組み込み接続機能です データバースは多くのマイクロソフトビジネスアプリを支える共有データ基盤です

00:03:23.340 --> 00:03:28.380
ダイナミクス365セールスカスタマーサービスフィールドサービスそしてプロジェクト オペレーションズの一部はすべてこれを使用しています

00:03:28.380 --> 00:03:34.520
パワーアップスやパワーオートメイトでも使用可能です デュアルライトを理解するためにデータバースがどのように個々のレコードを保存しているかを知る必要はありません

00:03:34.520 --> 00:03:41.680
単にダイナミクス365の顧客向けアプリ側における共通データエリアと考えてください オフィスビルにフロントオフィスとバックオフィスがあると想像してください

00:03:41.680 --> 00:03:52.000
フロントオフィスは顧客とのやり取りを扱います 営業担当者やサービスエージェントフィールドワーカーなどです彼らは顧客と話し要求を追跡し業務を管理するための画面を必要としています

00:03:52.000 --> 00:03:58.480
バックオフィスは会社を運営するための業務を扱います 財務記録在庫注文購買配送などです

00:03:58.480 --> 00:04:08.300
どちらも同じ会社のために働いていますが適切な連携がないと誰かが情報を手作業で運ばなければなりません 印刷した書類を運んだりメールを送ったり他のシステムにデータをコピーしたりします

00:04:08.300 --> 00:04:15.880
業務自体は進みますが時間がかかり途中で詳細が書き換わってしまう恐れもあります デュアルライトはこの2つのオフィスの間にある担当者が常駐する打ち扉のようなものです

00:04:15.880 --> 00:04:22.980
一方のそばで対応レコードが変更されるとデュアルライトはその変更を扉の向こう側へと自動的に伝達します すべてのアプリを一つの巨大なアプリに統合するわけではありません

00:04:22.980 --> 00:04:27.000
営業部門はこれまで通り営業用アプリで作業できます 財務部門はこれまで通り財務用アプリで作業できます

00:04:27.000 --> 00:04:33.060
各チームは業務専用の画面を維持しつつ選択された共有情報のみが裏側で連携されます サポートされているという言葉が重要です

00:04:33.060 --> 00:04:39.520
デュアルライトは両システムのすべてのデータを無差別にコピーするわけではありません 関連するレコード間の定義された接続を通じて機能します

00:04:39.520 --> 00:04:45.700
マイクロソフトはこれらの接続をテーブルマップと呼んでいます テーブルとはアプリがある種類のレコードを保持する単なる場所のことです

00:04:45.700 --> 00:04:49.680
顧客テーブルは顧客レコードを保持します 製品テーブルは製品レコードを保持します

00:04:49.680 --> 00:04:56.560
住所テーブルは住所の詳細を保持します テーブルマップはフィナンス&オペレーションズ側のどのテーブルがデータバース側のどのテーブルに接続されるかをデュアルライトに指示します

00:04:56.560 --> 00:05:01.580
テーブルマップは合意に基づいた変換シートのようなものだと考えてください 一方の列で片側のレコードを特定します

00:05:01.580 --> 00:05:07.420
もう一方の列でそれに対応する反対側のレコードを特定します 残りの部分はどのフィールド同士が対応しているかを示します

00:05:07.420 --> 00:05:11.880
名前電話番号住所などの項目です その合意によって接続ルールが定まります

00:05:11.880 --> 00:05:16.020
それがなければ2つのアプリで異なるラベルが使われたり 同じ詳細が異なる場所に保存されたりする可能性があります

00:05:16.020 --> 00:05:21.680
マップはそうした詳細がどう関連しているかをデュアルライトに伝えます そのためその都度人が介在して解釈させる必要はありません

00:05:21.680 --> 00:05:27.600
デュアルライトという名称からすべての変更が常に双方向に反映されると誤解されがちです その場合もあります

00:05:27.600 --> 00:05:32.600
サポートされた双方向マップではデータバースでの変更がフィナンス&オペレーションズの関連レコードを更新できます

00:05:32.600 --> 00:05:36.740
フィナンス&オペレーションズでのサポートされた変更もデータバースの関連レコードを更新できます

00:05:36.740 --> 00:05:41.240
双方が同じ共有レコードに関与できるのです それがデュアル20という部分の意味です

00:05:41.240 --> 00:05:46.800
更新はほぼリアルタイムで行われます 夜間のバッチ処理を待つのではなく作業に合わせて迅速に反映されます

00:05:46.800 --> 00:05:52.060
ユーザーがサポート対象のレコードを更新すると作業中のその瞬間に接続を通じて更新が送信されます

00:05:52.060 --> 00:05:55.060
ほぼリアルタイムとは魔法や遅延ゼロを意味するわけではありません

00:05:55.060 --> 00:05:59.400
1日1回のファイル交換ではなくライブのビジネス業務向けに構築された接続であることを意味します

00:05:59.400 --> 00:06:05.100
誰かが詳細を変更しても関連チームは翌朝まで待つ必要がありません それによってチームの働き方が変わります

00:06:05.100 --> 00:06:11.180
フロントオフィスはバックオフィスからのデータを利用できるようになります バックオフィスは顧客向けアプリからのサポートされた更新を受け取れます

00:06:11.180 --> 00:06:15.980
データバースが一方のデータ基盤となり フィナンス&オペレーションズがもう一方の業務基盤として残る中で

00:06:15.980 --> 00:06:21.560
デュアルライトが承認済みの共有レコードを連携し続けます それでも開かれた内部の扉にはルールが必要です

00:06:21.560 --> 00:06:29.540
レコードを双方向に移動させる前にそのレコードの発生元変更権限者 そして2つのアプリで不一致が生じた際の優先順位を明確にする必要があります

00:06:29.540 --> 00:06:35.840
どのデータを移動できどのシステムが所有するのでしょうか ではデュアルライトはどのレコードを接続し続けることができるのでしょうか

00:06:35.840 --> 00:06:43.980
一般的な例として多くの部門が日々共有しているレコードから見ていきましょう 顧客レコード住所連絡先製品ベンダー会社詳細

00:06:43.980 --> 00:06:49.160
そして財務や税務で使用される参照情報などです 顧客レコードについて少し考えてみましょう

00:06:49.160 --> 00:06:56.760
営業部門は顧客名主な連絡先電話番号配送先住所を必要とします 財務部門は法的な顧客レコード請求詳細

00:06:56.760 --> 00:07:02.700
および注文や請求書に必要な情報を必要とします 各部門が個別の顧客リストを保持していると会社は顧客への対応ではなく

00:07:02.780 --> 00:07:08.760
レコードの称号に時間を費やすことになります 適切なデュアルライトマップを設定すれば各チームは接続された顧客詳細に基づいて業務を行え

00:07:08.760 --> 00:07:12.440
ます それは営業ユーザーが突然財務アプリを学ぶ必要があるという意味ではありません

00:07:12.440 --> 00:07:19.780
つまりダイナミクス365セールスで顧客情報を扱う一方で 財務ユーザーは関連する顧客情報をファイナンスで扱えるということです

00:07:19.780 --> 00:07:24.640
顧客は両方の場所で同一の顧客として認識されます 住所も重要です

00:07:24.640 --> 00:07:31.440
顧客には請求先住所配送先住所そしてサービス担当者が訪問すべき現場などが存在することがあります 各住所には異なる役割があるため

00:07:31.440 --> 00:07:38.160
これらの詳細を単なるテキストとして一つのボックスにコピーして扱うことはできません デュアルライトはその関係に必要な共有レコード構造をサポートします

00:07:38.160 --> 00:07:43.880
連絡先も同様のパターンに従います 一つの顧客企業に購買担当者買いかけ金担当者サービスマネージャーがいる場合があります

00:07:43.880 --> 00:07:49.200
営業担当者は誰が決定を下すかを知る必要があります 財務担当者は請求に関する質問をどこに送るべきかを知る必要があります

00:07:49.200 --> 00:07:56.160
サービス担当者は現場で誰が待っているかを知る必要があります レコードを接続することで各チームはアプリごとに情報を再構築することなく顧客に関連する人物を把握できます

00:07:56.160 --> 00:08:03.040
製品も一般的な例の一つです 営業担当者は会社が何を販売し製品の価格がいくらで在庫があるかどうかを知る必要があります

00:08:03.040 --> 00:08:08.460
それらの答えは通常製品在庫購買フルフィルメントが管理されているビジネスの運用側から得られ ます

00:08:08.460 --> 00:08:17.840
そのため製品情報は財務及び運用部門から始まることが多いのです 運用チームはそこで製品を作成し準備しますその製品が顧客向けの作業に利用可能になると

00:08:17.840 --> 00:08:27.000
デュアルライトは関連する製品詳細をデータバースに送信できます 営業ユーザーは製品リストを二重入力することなく自分のアプリで製品を選択し商談に利用できます

00:08:27.000 --> 00:08:35.760
これにより営業担当者はビジネスが実際に提供可能な内容に基づいて商談を進める ことができます価格や在庫の詳細も接続されたアプリを通じて営業部門に届けられます

00:08:35.760 --> 00:08:43.700
金目の有無価格変更在庫が約束を裏付けられるかを推測する代わりに営業チームは運用側と 連携した情報に基づいて業務を行えます

00:08:43.700 --> 00:08:51.220
だからといって優れた営業判断が不要になるわけではありません 営業担当者が基本的な詳細を確認するためだけに倉庫へ電話するという回避可能な手間が一つ省けるの

00:08:51.220 --> 00:09:02.000
です仕入れ先情報もビジネスプロセスで必要とされる場所と連携させることができます 会社詳細組織構造財務参照データ税務参照データは顧客側と業務側の双方にとって重要になり得ます

00:09:02.000 --> 00:09:10.040
正確なレコードは企業が使用するアプリやプロセスによって異なりますがパターンは変わりません 双方で同じ意味を持つ必要があるレコードを共有しましょう

00:09:10.040 --> 00:09:15.820
ただし全てのレコードが双方向に移動すべきだとは限りません 一部のアプリは双方向更新をサポートしています

00:09:15.820 --> 00:09:25.200
データバースで変更を開始してフィナンス&オペレーションズへ移動することもその逆も可能です このアプローチは両サイドに承認済み詳細を更新する正当なビジネス上の理由があるレコードに適しています

00:09:25.200 --> 00:09:35.180
一方で一方向にのみ動作するマップもあります 製品が良い例になります多くの企業では製品マスター在庫単位その他販売や配送に必要な詳細を運用側が管理している

00:09:35.180 --> 00:09:41.940
ためフィナンス&オペレーションズが製品作成を担います その後製品データはデータバースに送られ営業チームやサービスチームがそれを使用します

00:09:41.940 --> 00:09:50.720
これは明確なルールです製品に関して2つのチームが競合するバージョンを作成する必要はありません 一方が製品を作成管理しもう一方がそれを受け取って業務の一部として使用します

00:09:50.720 --> 00:09:59.780
共有されるすべてのレコードにはこうした決定が必要です このレコードはどこで生成されるのか誰が編集できるのか名前住所価格分類が間違っている場合どのチームが修正するのか

00:09:59.780 --> 00:10:05.240
これらは単純な問いですが後の混乱を大きく防ぐことができます 接続によって変更は非常に迅速に伝達されます

00:10:05.240 --> 00:10:12.700
変更の責任者が合意されていなければ誤りも同じスピードで拡散してしまいます レコードの所有者を決め必要に応じてそのレコード内の個々の詳細の所有者も決めてください

00:10:12.700 --> 00:10:21.340
例えば顧客関係の詳細や主要な連絡先情報は営業部門が所有するかもしれません 財務部門が支払い関連の詳細を運用部門が製品や在庫の詳細を所有するといった具合です

00:10:21.340 --> 00:10:30.060
正確な分担はビジネスの仕組み次第ですがそれを文書化しアプリを使用する全員が理解しておく必要があります デュアルライトによってデータバースが拡張された後パーティーパーティーと

00:10:30.060 --> 00:10:37.020
カンパニー会社という2つの用語を目にするかもしれません パーティーとは人や組織を一貫した方法で扱うためのマイクロソフトの仕組みです

00:10:37.020 --> 00:10:44.280
これによりあらゆる関係をバラバラで無関係なレコードとして扱うことなく 人組織連絡先住所を関連づけることができます

00:10:44.280 --> 00:10:52.140
会社カンパニーはフィナンス&オペレーションズで使用されるビジネス上の会社コンテキストをデータバースが理解するのに役立ちます 初日から両方の用語の専門家になる必要はありません

00:10:52.140 --> 00:10:59.040
フィナンス&オペレーションズはレコードが両社間を移動する際に顧客アプリが認識する必要がある ビジネス構造を扱うためその存在を知っておいてください

00:10:59.040 --> 00:11:04.380
レコードが双方向に移動できるようになるとそのレコードを取り巻くプロセスはデータ そのものと同じくらい重要になります

00:11:04.380 --> 00:11:10.520
変更がアプリ間をどのように伝播するかシステムを通過する一つの変更を追いかけて 実際に何が起こるかを見てみましょう

00:11:10.520 --> 00:11:19.580
営業担当者が新しいオフィスに移転したばかりの顧客と電話で話しています 会話の最中に担当者はダイナミクス365セールスで顧客レコードを開き住所を更新します

00:11:19.580 --> 00:11:24.340
とても簡単ですよねそしてレコードを保存します ここからが面白いところです

00:11:24.340 --> 00:11:33.620
セールスはその変更をデータバース顧客向けアプリのデータ基盤に保存します 次にデュアルライトがこのサイトとフィナンス&オペレーションズの間で顧客情報や住所情報をつなぐマッピングを確認します

00:11:33.620 --> 00:11:39.800
そして対応する変更を自動的に送信します 共有フォルダーにエクスポートファイルが置かれ誰かが拾い上げるのを待つ必要はありません

00:11:39.800 --> 00:11:47.420
この住所を更新してくださいといったメールを財務部門に送る必要もありません マッピングがどのフィールドがリンクされているかを把握しておりサポートされている変更を

00:11:47.420 --> 00:11:54.140
フィナンス&オペレーションズの関連顧客レコードへ直接送信します そのため後から財務担当者が顧客レコードを開くと更新された住所が確認でき

00:11:54.140 --> 00:11:59.220
注文処理や請求書作成を滞りなく進められます これが実用的な結果でありシンプルそのものです

00:11:59.220 --> 00:12:07.060
2人は異なるアプリで作業を続けますがどちらも同じ顧客詳細を再入力する必要はありません 営業担当者は顧客との会話のために設計された画面で作業します

00:12:07.060 --> 00:12:14.240
財務担当者は財務作業のために構築された画面で作業します 各担当者は自分が必要とする顧客情報を必要な場所で確認できます

00:12:14.600 --> 00:12:20.760
そしてこの移動は逆方向でも機能します フィナンス&オペレーションズで財務部門がサポート対象の顧客情報を更新する場合を想像してください

00:12:20.760 --> 00:12:29.800
例えば財務担当者が運用上の顧客レコードに属する詳細情報を修正したとします デュアルライトは対応するマッピングを逆方向に使いその関連更新をデータバースに送信します

00:12:29.800 --> 00:12:36.980
するとセールスや他のデータバースベースのアプリがその変更を取り込めます この接続は日常業務においては同期的に行われます

00:12:37.000 --> 00:12:44.340
同期的とはアプリが20分後に実行されるかもしれないバックグラウンドジョブに任せるのではなく 同じ作業の瞬間の一部として関連する更新を完了させようとすることを意味します

00:12:44.340 --> 00:12:50.980
接続が更新を完了できない場合その問題は誰かが不整合に気づくまで静かに隠しておくのではなく すぐに対処する必要があります

00:12:50.980 --> 00:12:59.260
この挙動は共有されるビジネスレコードにとって理にかなっています バッチジョブが未実行だからといって顧客の住所や製品の詳細その他の共有情報が何時間も食い違ったままになるのは避けたいはずです

00:12:59.260 --> 00:13:05.440
人は画面に今映っている情報に基づいて意思決定を行うのですから このように接続によって作業中も両サイドが密接に同期されます

00:13:05.440 --> 00:13:11.500
運用中であっても時には意図的に一時停止する必要があります デュアルライトには再生一時停止追いつきキャッチアップのオプションがあります

00:13:11.500 --> 00:13:18.780
再生とはマップが実行中でありサポートされている変更が通常通り反映される状態です 一時停止はチームが計画的な作業を行う問題を調査するあるいは変更を安全に

00:13:18.780 --> 00:13:22.980
管理する必要がある場合にマップを一時的に停止するものです ただし一時停止は永続的な待機場所ではありません

00:13:22.980 --> 00:13:29.720
マップが一時停止している間変更は一定の期間及び容量まで急に蓄積されます マップを再開するとキャッチアップ機能が待機中の変更を処理します

00:13:29.720 --> 00:13:36.980
これによりチームは計画的な中断から復旧できるようになります ただし誰かがその一時停止を管理しいつマップを再開すべきかを把握しておく必要があります

00:13:36.980 --> 00:13:44.760
日常業務でこれらを開始する前にもう一つ初期動機というステップがあります 初期動機は両サイドの既存レコードを共通の開始地点に合わせるためのものです

00:13:44.760 --> 00:13:49.360
フィナンス&オペレーションズにすでに顧客が存在し データバースにも顧客レコードがある企業を考えてみてください

00:13:49.360 --> 00:13:55.240
接続をオンにしただけで既存のすべてのレコードが完全に一致していると想定することはできません スタートラインが必要なのです

00:13:55.240 --> 00:14:04.360
初期動機はユーザーがライブ更新に依存する前に既存データを移行するのに役立ちます 重複レコード不完全な住所古いテストデータなどは動機を開始したからといって

00:14:04.360 --> 00:14:11.640
魔法のように綺麗になるわけではないためこの作業には注意が必要です ルールに従っていないレコードがある場合かえって問題が迅速に発生する可能性があります

00:14:11.640 --> 00:14:19.000
マップが実行されたらデュアルライトの管理者はその健全性を確認できる明確な場所を必要とします デュアルライトは統合されたアクティビティログとエラーログを提供するため

00:14:19.000 --> 00:14:25.160
管理者は接続が何を処理しどこで問題が発生したかを確認できます またアラートや指揮位置を設定することも可能です

00:14:25.160 --> 00:14:33.460
これによりユーザーが更新の失敗や欠落に気づく前に適切な担当者が問題を知ることができます 全てのエラーには原因があるためこのサポートビューは重要です

00:14:33.460 --> 00:14:37.520
キスフィールドが欠落しているのかもしれません 関連レコードがまだ到着していないのかもしれません

00:14:37.520 --> 00:14:44.760
誰かがマップに適合しない方法でデータを変更したのかもしれません 根本的な原因を修正せずに失敗したレコードを再試行しても通常は同じエラーが繰り返されるだけです

00:14:44.760 --> 00:14:52.860
適切に運用されるデュアルライト設定は接続を監視しエラーの根本原因を修正し 本当に接続を維持する必要があるレコードにマップを集中させます

00:14:52.860 --> 00:14:58.520
デュアルライトが最も適している場面 デュアルライトはダイナミクス365ファイナンスやサプライチェーンマネジメントを

00:14:58.520 --> 00:15:07.600
営業顧客サービスフィールドサービスプロジェクト運用などの顧客向けアプリと併用する場合に最適です これらのアプリは一連のビジネス対話の異なる部分をそれぞれサポートしています

00:15:07.600 --> 00:15:13.760
あるチームが顧客と対話し別のチームが配送計画 在庫管理コスト追跡請求書発行などを行います

00:15:13.760 --> 00:15:20.980
両方のグループが日々の業務で関連レコードを扱う必要がある場合 デュアルライトを使えば全員を同じアプリに強制することなくその作業をつなぐことができます

00:15:20.980 --> 00:15:27.220
見込み客から入金までのプロセスを例に挙げましょう 営業担当者はダイナミクス365セールスで潜在顧客とやり取りをします

00:15:27.220 --> 00:15:31.820
担当者は連絡先を追跡し製品について話し合い 見積書を作成して注文へと進めていきます

00:15:31.820 --> 00:15:39.380
その対話の中で営業担当者には顧客の詳細 製品情報価格そして会社の財務部門に関連する注文情報が必要となります

00:15:39.380 --> 00:15:48.280
販売が確定すると財務サプライチェーン管理部門が契約後の業務を引き継ぎます そこでは注文の履行請求財務記録が処理されます

00:15:48.280 --> 00:15:56.440
デュアルライトはこれら2つの領域を接続し続けるのに役立ちます 営業担当者は自分たちの仕事に適した顧客向けアプリで作業し財務運用担当者は自分たちの業務向けに

00:15:56.440 --> 00:16:02.700
構築されたアプリで取引を管理できます 顧客が営業部門が語るストーリーと財務部門が語るストーリーという2つの別々の存在になることはありません

00:16:02.700 --> 00:16:09.180
フィールドサービスも良い例です 技術者を派遣して顧客の現場で機器の設置修理保守を行う企業を想像してみてください

00:16:09.180 --> 00:16:20.640
現場の担当者には顧客の詳細作業内容そして会社が設置またはサポートしている製品の顧客資産情報が必要です その裏側で会社は部品コスト購買そしてその作業に結びつく金銭を追跡する必要があります

00:16:20.640 --> 00:16:27.520
フィールドサービスは訪問の計画と官僚に焦点を当てています 財務運用はその周囲の運用面や財務面の記録に焦点を当てています

00:16:27.520 --> 00:16:34.360
これらの記録が正しく接続されていれば技術者の作業が使用した部品作業コスト あるいは関連する顧客レコードから切り離されることはありません

00:16:34.360 --> 00:16:39.580
プロジェクトオペレーションも同じパターンに当てはまります 特にプロジェクト単位で仕事を受注する企業には最適です

00:16:39.580 --> 00:16:44.260
プロジェクトチームは顧客の作業担当者の時間計画コスト プロジェクトのマイルストーンを管理するかもしれません

00:16:44.260 --> 00:16:52.740
財務部門は購買コスト請求レポートといった財務面を確認する必要があります 接続がないとプロジェクトマネージャーは進捗確認のために財務部門を追いかけ

00:16:52.740 --> 00:17:00.240
財務部門はプロジェクトチームからの報告を待つという無駄な時間を過ごすことになります プロジェクトレコードが接続されていれば顧客との約束が財務活動へと移行する過程において

00:17:00.240 --> 00:17:05.460
双方のグループが作業をより明確に把握できるようになります これにはより広範なパワープラットフォームのメリットもあります

00:17:05.460 --> 00:17:11.040
顧客アプリ側はデータバースを使用しているため データバース内の承認済みデータがパワーアップスやパワーオートメートをサポートできるからです

00:17:11.040 --> 00:17:16.920
企業は内部チーム向けに小規模なアプリを構築したり ビジネスレコードが特定の段階に達した時に応答するフローを作成したりできます

00:17:16.920 --> 00:17:25.660
だからといって財務運用のすべての記録があらゆるパワーアップに含まれるべきだという意味ではありません つまり接続されたレコードは企業がその目的を慎重に選択しデータを適切に保護する限り

00:17:25.660 --> 00:17:29.900
より広範なビジネスツールのセットの一部となり得るのです 一つの境界線を明確にしておく必要があります

00:17:29.900 --> 00:17:36.460
デュアルライトはダイナミクス365ビジネスセントラルをサポートしていません ビジネスセントラルは他の手法でマイクロソフト製品と接続できますが

00:17:36.460 --> 00:17:42.060
デュアルライトはダイナミクス365のフィナンス&オペレーションズ側と データバースベースの顧客アプリのためのものです

00:17:42.060 --> 00:17:49.140
またこれは見つけたすべてのテーブルをコピーするためのツールでもありません レコードを移動すべきなのは両方の場所で同じ業務レコードが必要だからであり

00:17:49.140 --> 00:17:54.040
コピーした方が安全そうだからという理由ではありません デュアルライトはレポートフィードやサードパーティシステムとの連携

00:17:54.040 --> 00:18:02.360
あるいは大規模なデータ移行が必要な場合のより広範な統合計画の代わりにもなりません すべてのデータ接続を同じ仕事として扱うとすぐにトラブルが発生します

00:18:02.360 --> 00:18:09.120
制限事項準備そしてよくある間違い デュアルライトを2つのシステム間の握手による合意のようなものと考えてください

00:18:09.120 --> 00:18:14.600
これらは特定の共有レコードを同期させることに合意しますがすべてのテーブルやレポート 外部システムのための魔法のパイプではありません

00:18:14.600 --> 00:18:22.180
セットアップの前にすでにどのような統合が存在するかを確認してください 古い接続とデュアルライトの両方が同じ顧客レコードを更新するとすぐに競合が発生する

00:18:22.180 --> 00:18:26.340
可能性があります それは避けたい頭痛の種ですですからまずは基本事項で合意しましょう

00:18:26.340 --> 00:18:33.100
名前はどのように入力しますか各レコードはどの法人組織が所有しますか 誰が変更を行いますか各チームにはどのようなセキュリティロールが必要ですか

00:18:33.100 --> 00:18:37.580
最初の同期の前に重複や不完全なレコードを確認してください マイクロソフトの構築済マップから始めてください

00:18:37.580 --> 00:18:41.860
それらはすでに一般的なレコードを接続済みです カスタムテーブルやフィールドは慎重なテストが必要です

00:18:41.860 --> 00:18:47.580
また関連テーブルとマップの依存関係を確認してください レコードが同期される前に別のレコードの存在が必要な場合があるからです

00:18:47.580 --> 00:18:52.400
データの量に基づいて最初の同期を計画してください 昼食中にスイッチを切り替えるような感覚で扱わないでください

00:18:52.400 --> 00:18:56.620
それは問題を引き起こします 一時停止中のマップにも所有者と再開計画が必要です

00:18:56.620 --> 00:19:02.460
急に入れられた変更や失敗したレコードはとはには保持されません アクティビティログエラーアラートおよび指揮位置を監視してください

00:19:02.460 --> 00:19:06.540
何かが失敗したときはその背後にある欠落フィールド不正なレコードまたは壊れたルールを見つけてください

00:19:06.540 --> 00:19:12.680
繰り返しの再試行では誤ったデータは修正されません デュアルライトを制御された橋として捉えれば全てがうまく噛み合います

00:19:12.680 --> 00:19:18.300
結論として一つの共有されたビジネスの対話が生まれます デュアルライトはサポート対象の共有レコードを

00:19:18.300 --> 00:19:25.360
フィナンス&オペレーションズとデータバースベースの顧客アプリの間で往来させ続けます そうすることでチームは接続されたビジネスデータに基づいて業務を行うことができます

00:19:25.360 --> 00:19:37.980
私のポッドキャストメートル365 fm で知識を深めるためにお気に入りのプラットフォームで購読してください そして未だにスプレッドシートで営業サービス財務をつないでいる誰かとこのエピソードを共有してください