WEBVTT

00:00:04.050 --> 00:00:10.790
マイクロソフトナレッジナゲットへようこそミルコピーターズです 今日のテーマはよく混同されがちなものです

00:00:10.790 --> 00:00:18.290
データバースとは一体何でしょうか データベースなのかアプリなのかあるいは it 担当者だけが知っていれば良いダイナミクス365の隠れたサービスなのでしょうか

00:00:18.290 --> 00:00:24.230
最もシンプルな定義はこうです データバースは多くのダイナミクス365エクスペリエンスを支える共通のデータ基盤です

00:00:24.230 --> 00:00:30.310
ダイナミクス365オフィスビルだと考えてみてください 営業やカスタマーサービスなどのアプリは人々が働く部屋であり

00:00:34.050 --> 00:00:41.270
ですこのエピソードの終わりにはダイナミクスのデータがどこに存在し 一人の顧客情報の更新がどのように営業活動自動化レポートに反映されるかがわかります

00:00:41.270 --> 00:00:52.130
しかし製品名に触れる前にまずはこれが解決するビジネス上の混乱から見ていきましょう 共通の場所別々のコピーを持つ代わりに営業チームサポートチーム経理チームがある会社を

00:00:52.130 --> 00:00:57.910
創造してください 営業は顧客の詳細をスプレッドシートで管理していますサポートは別のケース管理ツールで作業しています

00:00:57.910 --> 00:01:04.470
経理は独自のシステムに顧客名を持っています 誰かはメールのやり取りを共有メールボックスに保存しまた別の人は誰にも見つけられない

00:01:04.470 --> 00:01:10.290
ホルダーにメモを保管しています 同じ顧客が今や5つの場所に存在しています各チームは自分の目の前の作業しか見ていないため

00:01:10.290 --> 00:01:17.270
その設定は最初は普通に感じられます しかし問題はここからです顧客が電話番号住所会社名または主要な連絡先を変更した

00:01:17.270 --> 00:01:22.850
途端問題が始まります営業がスプレッドシートを更新してもサポートには反映されず 経理は古い住所に書類を送り続けてしまいます

00:01:22.850 --> 00:01:29.130
すると誰かがリストをエクスポートして手作業で修正しメールで共有した結果 突然3人がそれぞれ自分のコピーこそが正しいと信じ込むことになります

00:01:29.130 --> 00:01:33.250
どのリストを信頼すべきでしょうか その疑問が皆さんが考える以上に時間を無駄にしています

00:01:33.250 --> 00:01:37.930
スタッフは記録の称号のために作業を止めます 管理職はなぜレポートが営業システムと一致しないのかを尋ねます

00:01:37.930 --> 00:01:42.730
サポート担当者は別の場所にはすでに少し異なる詳細情報が存在している顧客のために新しい案件を作成してしまいます

00:01:42.730 --> 00:01:46.170
誰も混乱を起こそうとしているわけではありません 混乱の原因はコピーにあります

00:01:46.170 --> 00:01:51.270
20年前は別々のシステムは別々のサーバー別々のデータベース そして独自の情報を管理する別々のチームを意味していました

00:01:51.270 --> 00:01:55.030
それらを接続するにはカスタム作業や定期的なインポート そして多大な手作業によるチェックが必要でした

00:01:55.030 --> 00:01:59.330
ある場所での変更が別のシステムに反映されるのは明日か来週かあるいは永遠に反映されないこともありました

00:01:59.330 --> 00:02:02.930
データバースはビジネスアプリにこの種の情報のための共通の場所を提供します

00:02:02.930 --> 00:02:07.650
簡単に言えばデータバースはビジネス情報のためのマイクロソフトのクラウドデータプラットフォームです

00:02:07.650 --> 00:02:11.930
情報を構造化されたテーブルに保存するためデータは断片的なメモやバラバラのファイル

00:02:11.930 --> 00:02:15.570
分断されたスプレッドシートのタブとしてではなく明確な形で存在します

00:02:15.570 --> 00:02:20.510
これは会社のファイリングキャビネットのようなものですが承認された複数のツールが同時に利用できる点が違います

00:02:20.510 --> 00:02:22.790
顧客はデータバースに一度だけ登録されます

00:02:22.790 --> 00:02:27.270
営業担当者が商談を進める際その顧客はダイナミクス365セールスに表示されます

00:02:32.930 --> 00:02:39.270
パワーアップを使えば現場担当者やアカウントマネージャーもデータを新しいアプリにコピーすることなく同じ顧客情報を利用できます

00:02:39.270 --> 00:02:41.810
顧客データは一行参照先も一つです

00:02:41.810 --> 00:02:44.690
これはあらゆるチームが全ての情報を自由に見られるようになるという意味ではありません

00:02:44.690 --> 00:02:47.530
アクセスにはルールが必要でありそれについては後ほど説明します

00:02:47.530 --> 00:02:52.890
承認されたアプリは独自の競合するデータを作成するのではなく共通のビジネス情報を元に作業できるということです

00:02:52.890 --> 00:02:56.570
これがダイナミクス365とデータバースが非常に自然に適合する理由です

00:02:56.570 --> 00:03:01.930
ダイナミクス365のセールスやカスタマーサービスなどのアプリはデータバースを使用して業務データを保存保護しています

00:03:01.930 --> 00:03:05.470
しかしダイナミクス365とデータバースの統合について語る際

00:03:05.470 --> 00:03:09.210
多くの人は両者の間にコネクタが必要な別々の製品だと想像しがちです

00:03:09.210 --> 00:03:12.390
多くのダイナミクス365アプリにとってそれは当てはまりません

00:03:12.390 --> 00:03:14.790
データはすでにデータバース内に存在しているからです

00:03:14.790 --> 00:03:21.070
ダイナミクス365から顧客リストを抜き出し別のデータベースにコピーして両方の同期を維持するよう祈る必要はありません

00:03:21.070 --> 00:03:26.030
ダイナミクス365がすでに使用しているビジネス情報と同じ基盤の上に機能を構築できるのです

00:03:26.030 --> 00:03:28.190
これによって議論の焦点が変わります

00:03:28.190 --> 00:03:31.170
どうすれば2つの顧客リストを同期できるかと問うのではなく

00:03:31.170 --> 00:03:36.650
どのユーザーやアプリがこの顧客レコードを扱う必要がありそれぞれに何を許可すべきかを問いかけるようになります

00:03:36.650 --> 00:03:40.230
もちろんデータバースが企業内のすべてのシステムを置き換えるわけではありません

00:03:40.230 --> 00:03:47.210
企業は依然として会計ソフト業界特化ツール倉庫システムウェブサイトあるいは独自のデータを持つ旧来のアプリケーションを使用する可能性があります

00:03:47.210 --> 00:03:51.090
データバースは外部システムを一夜にして消し去る魔法の接着剤ではありません

00:03:51.090 --> 00:03:56.030
それが提供するのは接続されたアプリ間で共有が必要なビジネスデータのための共通の場所です

00:03:56.030 --> 00:04:00.150
顧客詳細販売活動サポート対応タスクフォローアップなど

00:04:00.150 --> 00:04:03.870
これらのレコードは承認されたツールが読み書きできる単一のソースとして共存できます

00:04:03.870 --> 00:04:06.650
では私と一緒にそのファイリングキャビネットを開いてみましょう

00:04:06.650 --> 00:04:09.650
データバースが内部で情報をどのように整理しているかを知れば

00:04:09.650 --> 00:04:12.790
ダイナミクス365との繋がりがぐっと理解しやすくなります

00:04:12.790 --> 00:04:16.810
ファイリングキャビネット、テーブル、行、列、そしてリレーションシップです

00:04:16.810 --> 00:04:18.590
そのキャビネットを開いてみましょう

00:04:18.590 --> 00:04:21.010
データバースでは情報はテーブルに格納されます

00:04:21.010 --> 00:04:23.310
引き出しが分かれた本物のキャビネットを想像してください

00:04:23.310 --> 00:04:23.810
おっと

00:04:23.810 --> 00:04:27.710
一つの引き出しには企業、もう一つには人物、三つ目にはサポート依頼が整理されています

00:04:27.710 --> 00:04:29.510
すべての書類を一つの巨大な引き出しに投げ込み

00:04:29.510 --> 00:04:31.630
後で誰かが整理してくれることを願うようなことはしないのです

00:04:31.630 --> 00:04:33.150
引き出しにはそれぞれ役割があります

00:04:33.150 --> 00:04:36.130
データバースにおいても同様にテーブルは特定の種類のビジネス情報を保持します

00:04:36.130 --> 00:04:38.930
取引先テーブルには通常取引のある企業の情報が入ります

00:04:38.930 --> 00:04:41.090
連絡先テーブルには個人の情報が入ります

00:04:41.090 --> 00:04:44.250
リードテーブルには顧客になる前の見込み客の情報が入ります

00:04:44.250 --> 00:04:50.590
ケーステーブルにはサポート依頼がアクティビティテーブルには通話、メール、予定、タスクなどの作業記録が保存されます

00:04:50.590 --> 00:04:52.110
これらが標準テーブルです

00:04:52.110 --> 00:04:56.610
多くの企業が顧客、個人、業務、対話の管理を必要とするためマイクロソフトはこれらを用意しています

00:04:56.610 --> 00:04:59.730
一般的な用途であれば最初から新しいテーブルを作成する必要はありません

00:04:59.730 --> 00:05:01.550
標準テーブルがすでに役立つからです

00:05:01.550 --> 00:05:03.590
しかしどの企業にも独自の業務があります

00:05:03.590 --> 00:05:06.490
研修会社であればコースや修了証の管理が必要かもしれません

00:05:06.490 --> 00:05:09.730
不動産会社であれば建物、物件、検査の記録が必要になるでしょう

00:05:09.730 --> 00:05:13.190
製造業であれば機器の点検やサービス訪問の記録が必要かもしれません

00:05:13.190 --> 00:05:17.130
そのような場合、自社の業務内容に合わせたカスタムテーブルを作成できます

00:05:17.130 --> 00:05:21.230
カスタムテーブルとはキャビネットに新しい引き出しを追加し、そこに分かりやすいラベルを貼るようなものです

00:05:21.230 --> 00:05:23.550
さて各テーブルに派行、レコードが含まれます

00:05:23.550 --> 00:05:25.830
行とはその引き出しの中にある一つの項目です

00:05:25.830 --> 00:05:30.670
例えば、連絡先テーブルの一つの行は、顧客企業の担当者であるマリアゴメスさんを表すことができます

00:05:30.670 --> 00:05:34.650
その行には、システム内の他の連絡先とは別に彼女自身の詳細情報が保持されます

00:05:34.650 --> 00:05:37.570
列は、各業に保持したい詳細情報を記述するものです

00:05:37.570 --> 00:05:44.810
マリアさんの連絡先行には、名、姓、メールアドレス、電話番号、役職、会社、レコード所有者、ステータスなどの列が含まれます

00:05:44.810 --> 00:05:51.850
列はそこに格納される情報の型を定義するため、メール列にはメールアドレスが、ステータス列には承認済みのステータス選択肢が格納されます

00:05:51.850 --> 00:05:54.890
こうしてビジネス情報は信頼できる形に整えられます

00:05:54.890 --> 00:06:02.270
列がなければ、電話番号をメモ欄に入力する人もいれば、名前欄に追加する人もいたり、あるいは全く入力しない人も出てくるでしょう

00:06:02.270 --> 00:06:06.650
明確な連絡先テーブルがあれば、全員が同じ場所で同じ詳細情報を扱うことができます

00:06:06.650 --> 00:06:09.470
この構造は、アプリがデータを理解する助けにもなります

00:06:09.470 --> 00:06:15.490
ホームは適切な入力ボックスを表示し、レポートはステータス別に連絡先をグループ化し、自動化機能は所有者の変更に反応できます

00:06:15.490 --> 00:06:20.550
情報は単に保存されるだけでなく、各部分が何を意味するのかを接続されたツールに伝えるラベルを持っています

00:06:20.550 --> 00:06:23.830
ビジネスニーズに合う場合は、まず標準テーブルから始めましょう

00:06:23.830 --> 00:06:28.650
企業向け販売であれば、取引先や連絡先の仕組みは多くの人がすでに理解しているパターンです

00:06:28.650 --> 00:06:31.870
カスタマーサポートを行うなら、ケースがスタート地点となります

00:06:31.870 --> 00:06:36.790
その上で、組み込みのパターンに収まらない情報がある場合にのみ、カスタムテーブルを追加してください

00:06:36.790 --> 00:06:41.450
これにより、顧客を意味するテーブルを5つも作成してしまうという、よくある問題を回避できます

00:06:41.450 --> 00:06:46.790
あるチームは、クライアント、別のチームは、顧客マスター、3つ目のチームは、パートナー連絡先IOと呼ぶといった具合です

00:06:46.790 --> 00:06:49.650
すぐに、どのテーブルを使うべきか誰もわからなくなってしまいます

00:06:49.650 --> 00:06:54.710
明確な標準テーブルと慎重に命名されたカスタムテーブルがあれば、利用者が増えてもキャビネットは理解しやすくなります

00:06:54.710 --> 00:06:57.430
次のステップでは、それらの引き出しを連携させていきます

00:06:57.430 --> 00:06:59.810
連絡先は取引先に属します

00:06:59.810 --> 00:07:01.570
マリアはコントソ社で働いています

00:07:01.570 --> 00:07:08.990
コントソの住所や電話番号、会社情報をマリアの業に何度も入力する代わりに、データバースを使って連絡先テーブルと取引先テーブルの間にリレーションシップを作成できます

00:07:08.990 --> 00:07:10.770
マリアとコントソがリンクされます

00:07:10.770 --> 00:07:13.870
会社情報は会社に紐づくため、このリンクが重要になります

00:07:13.870 --> 00:07:20.790
コントソがオフィスを移転した場合、取引先の業を一度更新するだけで、関連するすべての連絡先は古い情報を保持することなく、同じ会社情報を参照できます

00:07:20.790 --> 00:07:24.590
リレーションシップはサポート案件をそれを起票した顧客と結びつけることもできます

00:07:24.590 --> 00:07:29.630
また、営業案件とその商談に関する通話、メール、会議、タスクを紐づけることも可能です

00:07:29.630 --> 00:07:35.570
営業担当者が案件を開くと、無関係なメモやカレンダーを探し回ることなく、関連する活動をすべて確認できます

00:07:35.570 --> 00:07:38.110
情報にコンテキスト、文脈が生まれるのです

00:07:38.110 --> 00:07:41.870
単に案件番号を見るだけでなく、それがどの顧客に属しているのかがわかります

00:07:41.870 --> 00:07:45.930
単に連絡先を見るだけでなく、その人物に関連する会社も確認できます

00:07:45.930 --> 00:07:50.830
これらのリンクによって、同じ事実を何度もあちこちに入力しなくても、データが有用な状態にもたれます

00:07:50.830 --> 00:07:54.350
古いガイドや動画を見る前に、用語に関する小さな注意点があります

00:07:54.350 --> 00:07:57.330
エンティティ、フィールド、レコードという言葉を耳にするかもしれません

00:07:57.330 --> 00:07:59.130
これらはデータバースの古い用語です

00:07:59.130 --> 00:08:04.290
現在マイクロソフトでは、エンティティの代わりに、テーブル、フィールドの代わりに、列、レコードの代わりに、行という言葉を使用しています

00:08:04.290 --> 00:08:05.690
意味は何も変わっていません

00:08:05.690 --> 00:08:13.310
古いガイドで、エンティティを作成する、とあれば、テーブルの作成、フィールド、は、列、レコード、は、行、のことを指しています

00:08:13.310 --> 00:08:16.970
両方の用語を知っていれば、別の製品だと勘違いせずに済みます

00:08:16.970 --> 00:08:20.550
つまり、テーブルが情報を整理し、リレーションシップがそれをつなぐということです

00:08:20.550 --> 00:08:23.190
しかし、うまく整理されたキャビネットにも制御が必要です

00:08:23.190 --> 00:08:27.170
誰が情報を入力、変更、または安全にアクセスできるかを決定しなければなりません

00:08:27.170 --> 00:08:29.130
ルールと受付デスクの役割です

00:08:29.130 --> 00:08:33.250
データバースの背後にあるデータは、適切な人が安全に扱えるようになって初めて機能します

00:08:33.250 --> 00:08:41.150
営業担当者には顧客の詳細が、サポート担当者には案件履歴が、マネージャーには全体像が、そして外部パートナーにはプロセスの一部のみのアクセス権が必要になるかもしれません

00:08:41.150 --> 00:08:43.510
全員が同じ情報を見るべきではないのです

00:08:43.510 --> 00:08:48.590
非公開の連絡メモや交渉価格、進行中のサポート案件が含まれる顧客レコードを想像してみてください

00:08:48.590 --> 00:08:51.770
全てのユーザーにフルアクセス権を与えると、すぐにリスクが生じます

00:08:51.770 --> 00:08:55.070
全員を厳しく制限して業務に支障が出るのも、別の問題を引き起こします

00:08:55.070 --> 00:08:57.170
データバースは、そのための制御機能を提供します

00:08:57.170 --> 00:08:59.590
その最初の制御は、ID、アイデンティティから始まります

00:08:59.590 --> 00:09:03.250
会社のアカウントでサインインすると、マイクロソフトエントラーIDがあなたを識別します

00:09:03.250 --> 00:09:06.330
エントラーIDは、オフィスの入り口にある受付だと考えてください

00:09:06.330 --> 00:09:10.230
到着してバッジを見せると、受付係が本人確認を行い、入室を許可します

00:09:10.230 --> 00:09:13.670
データバースはそのIDを使って、どのユーザーがデータにアクセスしているかを把握します

00:09:13.670 --> 00:09:16.570
この人は入室してよいか?と問うだけではありません

00:09:16.570 --> 00:09:18.910
入室した後、この人に何ができるか?

00:09:19.050 --> 00:09:19.870
もう問いかけます

00:09:19.870 --> 00:09:22.110
そこで登場するのがセキュリティロールです

00:09:22.110 --> 00:09:25.950
セキュリティロールとは、業務や責任に紐づいた権限のセットです

00:09:25.950 --> 00:09:30.390
営業担当者用、カスタマーサービス担当者用、そして管理者用といったロールを作成できます

00:09:30.390 --> 00:09:32.830
各ロールで、テーブルへのアクセスを制御できます

00:09:32.830 --> 00:09:37.750
例えば、営業担当者には、アカウント、連絡先、リード、商談の閲覧、作成、更新を許可できます

00:09:37.750 --> 00:09:40.810
重要な顧客情報の削除は許可しない、といった設定も可能です

00:09:40.810 --> 00:09:44.970
サポート担当者はケースの作成や更新はできても、商談の変更はできないように設定できます

00:09:44.970 --> 00:09:48.730
権限には、行の読み取り、作成、変更、削除が含まれます

00:09:48.730 --> 00:09:52.370
つまり、アプリごとにどのボタンを隠すべきか覚えておく必要はありません

00:09:52.370 --> 00:09:54.570
権限はデータそのものに設定されるからです

00:09:54.570 --> 00:09:57.870
そのため、そのデータバースデータが表示される場所ならどこでも、同じガードレールが適用されます

00:09:57.870 --> 00:10:00.290
さらに、アクセスをより詳細に絞り込むことも可能です

00:10:00.290 --> 00:10:03.690
業レベルのセキュリティにより、どの個別の業を操作できるかを決定します

00:10:03.690 --> 00:10:09.190
営業担当者は自分が担当する顧客のみを見ることができますが、マネージャーはチーム全員の顧客業を見ることができます

00:10:09.190 --> 00:10:11.490
どちらも同じアカウントテーブルを使用しています

00:10:11.490 --> 00:10:13.390
単に見ている範囲が異なるだけです

00:10:13.390 --> 00:10:17.550
この仕組みにより、担当者は自分の業務に集中でき、管理者は必要な全体像を把握できます

00:10:17.550 --> 00:10:21.690
また、アクセス権のない顧客情報を誰かが開いてしまうリスクも軽減されます

00:10:21.690 --> 00:10:24.250
さらに厳重な保護が必要な情報もあります

00:10:24.250 --> 00:10:27.670
列レベルのセキュリティでは、テーブル内の個々の列を保護できます

00:10:27.670 --> 00:10:33.830
顧客業を開くことはできても、個人識別し、給与、銀行口座、財務メモなどは見せないといった制限が可能です

00:10:33.830 --> 00:10:36.730
顧客行きそのものは、必要な業務のために利用できます

00:10:36.730 --> 00:10:39.190
保護された列だけが制限された状態になります

00:10:39.190 --> 00:10:43.330
大規模な企業では、ビジネスユニットを使って組織間の境界線を作成できます

00:10:43.330 --> 00:10:47.930
企業は、異なる顧客グループを担当する地域、部門、子会社を分けることができます

00:10:47.930 --> 00:10:51.290
ビジネスユニットは、そうした境界を超えたアクセス権の管理に役立ちます

00:10:51.290 --> 00:10:54.330
だからといって、全てのビジネスに複雑なセキュリティマップが必要なわけではありません

00:10:54.330 --> 00:10:56.950
小さなチームであれば、明確な役割がいくつかあれば十分かもしれません

00:11:03.830 --> 00:11:09.130
アクセス制御は誰がデータにアクセスできるかを保護しますが、ルールはデータ自体の品質を保護します

00:11:09.130 --> 00:11:13.370
ビジネスルールを使用すれば、新しい連絡先を保存する前に電話番号の入力を必須にすることができます

00:11:13.370 --> 00:11:16.870
また、ケースをクローズする際に理由の入力を求めるなど、条件のチェックも可能です

00:11:16.870 --> 00:11:20.130
入力された情報に基づいて、ユーザーに表示される内容を変更することもできます

00:11:20.130 --> 00:11:23.070
同じルールが、そのテーブルを使用するすべてのアプリに適用されます

00:11:23.070 --> 00:11:24.210
これは重要です

00:11:24.210 --> 00:11:28.050
なぜなら、あるアプリでは不完全なデータを受け入れ、別のアプリでは拒否するといった事態は避けたいからです

00:11:28.050 --> 00:11:31.570
ルールは特定の画面ではなく、ビジネス情報そのものに付随するものです

00:11:31.570 --> 00:11:36.050
データバースはバックグラウンドでロジックを実行し、ビジネスプロセスの一貫性を保つのにも役立ちます

00:11:36.050 --> 00:11:38.030
覚えておくべきポイントは単純です

00:11:38.030 --> 00:11:41.330
データには単なる保存場所だけでなく、ルールも付随しているということです

00:11:41.330 --> 00:11:46.910
つまり、基盤には情報だけでなく、それを扱う権限を持つ人々、そしてデータを活用可能にするルールも含まれるのです

00:11:46.910 --> 00:11:52.750
ダイナミクス365が同じ基盤上で動作すれば、独自のビジネスデータにアクセスするために従来のブリッジは不要になります

00:11:52.750 --> 00:11:56.410
ダイナミクス365の統合、とは実際には何を意味するのか

00:11:56.410 --> 00:12:02.590
多くの人は、ダイナミクス365とデータバースの統合、と聞くと、コネクタで結ばれた2つの別々のシステムを想像します

00:12:02.590 --> 00:12:10.430
一方のシステムにある顧客データを他方のシステムでも必要とするため、同期を設定し、実行を待ち、途中でエラーが起きないことを祈る、というものです

00:12:10.430 --> 00:12:13.590
多くのビジネスツールにとって、そのイメージは理にかなっています

00:12:13.590 --> 00:12:20.510
しかし、ダイナミクス365セールスとダイナミクス365カスタマーサービスに関しては、その繋がりはもっと密接なものです

00:12:20.510 --> 00:12:23.990
これらのアプリは、データバースを共通のデータ基盤として使用しています

00:12:23.990 --> 00:12:28.670
互いを理解するために、顧客データをやり取りする別々のデータベースが2つ存在するわけではありません

00:12:28.670 --> 00:12:31.850
最初から同じビジネス情報に基づいて作業が行われます

00:12:31.850 --> 00:12:33.490
具体的に見てみましょう

00:12:33.490 --> 00:12:39.250
あなたが営業担当者で、ダイナミクス365セールスで新しい会社を作成したと想像してください

00:12:39.250 --> 00:12:42.270
メインの連絡先を追加し、商談を開始します

00:12:42.270 --> 00:12:45.770
それらの詳細は直ちに、アプリが使用する共有データの一部となります

00:12:45.770 --> 00:12:48.370
その後、その顧客からサポートに連絡が入ります

00:12:48.370 --> 00:12:52.070
サポートエージェントは、全く同じ会社と連絡先の詳細情報を使って対応できます

00:12:52.070 --> 00:12:56.790
営業からリストをエクスポートしたり、別のサポートツールで顧客を再度作成したりする必要はありません

00:12:56.790 --> 00:13:02.110
エージェントはサポートケースをその顧客に紐付けるだけで、状況を把握するために役立つ履歴を即座に確認できます

00:13:02.110 --> 00:13:06.730
営業担当は商談を、サポート担当は問い合わせ案件を確認し、両チームが同じ顧客を軸に業務を進めます

00:13:06.730 --> 00:13:11.530
もちろん、これは全ての画面が同じ見た目であることや、全てのチームが同じプロセスに従うことを意味するわけではありません

00:13:11.530 --> 00:13:14.810
営業には、リード、案件、通話、そして会議が必要です

00:13:14.810 --> 00:13:18.150
カスタマーサービスには、問い合わせ、Q、そしてサービス履歴が必要です

00:13:18.150 --> 00:13:22.090
ダイナミクス365の各アプリは、その人の職務に合わせて構築されたツールを提供します

00:13:22.090 --> 00:13:30.550
基盤となるビジネス情報は必要な場所で連携可能であり、この共有基盤こそが、ダイナミクス365とデータバースの連携について語る際に人々がしばしば意図するものです

00:13:30.550 --> 00:13:34.290
これは単にデータをA地点からB地点へ移動させることではありません

00:13:34.290 --> 00:13:39.730
全てのアプリが最初から同じ業、関係性、ルール、アクセス制御に基づいて機能することなのです

00:13:39.730 --> 00:13:42.390
シンプルな営業ジャーニーを例に見ていきましょう

00:13:42.390 --> 00:13:44.930
ウェブサイトやイベントからリードが取り込まれます

00:13:44.930 --> 00:13:51.030
営業担当者がそのリードに対応し、相手について理解を深め、リードを顧客関係や商談へと育てていきます

00:13:51.030 --> 00:13:55.010
通話、メール、予定、タスクといったすべてがその業務に関連付けられます

00:13:55.010 --> 00:13:58.850
そのため、チームはバラバラのツールを探し回って情報をつなぎ合わせる必要がありません

00:13:58.850 --> 00:14:03.090
顧客が後に助けを必要とした場合、サポート案件をその同じ顧客に紐付けることができます

00:14:03.090 --> 00:14:06.630
サポート担当者は、単なる名前やメールアドレスを確認するだけではありません

00:14:06.630 --> 00:14:10.750
すでに特定された顧客関係に基づき、状況を把握しながら対応できるのです

00:14:10.750 --> 00:14:17.570
その間、営業チームは顧客が現在サービス上の問題を抱えていることを把握できるため、問題を知らずに更新の交渉に臨む事態を避けられます

00:14:17.570 --> 00:14:23.830
単に2つのシステムで顧客名を一致させておくよりも、1つの顧客関係が様々な業務を支えることの方が遥かに有用です

00:14:23.830 --> 00:14:28.150
コモンデータモデル、略してCDMという言葉を耳にすることもあるでしょう

00:14:28.150 --> 00:14:31.430
その名前から、必要以上に難しく考えることはありません

00:14:31.430 --> 00:14:38.590
これは単に、企業が管理する取引先企業、取引先担当者、活動、問い合わせ案件といった項目について、マイクロソフトが標準的なテーブルパターンを提供していることを意味します

00:14:38.590 --> 00:14:42.990
これらのパターンにより、ダイナミクス365とデータバースベースのアプリは、共通の言語を最初から備えることになります

00:14:42.990 --> 00:14:44.750
取引先企業は、会社を意味します

00:14:44.750 --> 00:14:46.770
取引先担当者は、個人を意味します

00:14:46.770 --> 00:14:49.430
活動は、ビジネス関係における業務を記録します

00:14:49.430 --> 00:14:55.290
自社に合わせて設定を調整したり、必要に応じて独自のテーブルを追加したりすることは可能ですが、毎回ゼロから始める必要はありません

00:14:55.290 --> 00:15:01.630
あるアプリが取引先企業テーブルを理解し、別のアプリも同じテーブルを使用すれば、両方のアプリが同じ種類のビジネス情報を参照することになります

00:15:01.630 --> 00:15:04.110
これにより、構築できるものの可能性も広がります

00:15:04.110 --> 00:15:09.370
例えば、現場チームが顧客を検索し、訪問を確認し、面談後にメモを残すためのシンプルなアプリが必要だとしましょう

00:15:09.370 --> 00:15:14.150
ダイナミクス365が既に使用している同じデータバーステーブルを活用するパワーアップスアプリを構築できるのです

00:15:14.150 --> 00:15:18.050
そのアプリのためだけに、顧客データを新しいリストへエクスポートする必要はありません

00:15:18.050 --> 00:15:22.330
現場の作業員がアプリを開いて顧客を検索し、訪問情報を更新するだけです

00:15:22.330 --> 00:15:29.050
データは、前述したセキュリティ規則に従い、営業や顧客サービスが既に使用している顧客関係と接続されたままになります

00:15:29.050 --> 00:15:32.390
より構造化された業務には、モデル駆動型アプリを構築できます

00:15:32.390 --> 00:15:34.950
モデル駆動型アプリは、データモデルから始まります

00:15:34.950 --> 00:15:40.010
データバースのテーブルを選択し、その関係を定義して、フォームやビューを設定し、セキュリティロールを適用します

00:15:40.010 --> 00:15:43.890
するとパワーアップスがその構造を利用して、実用的なビジネスアプリ体験を作成します

00:15:43.890 --> 00:15:47.670
チームが実際に使用するツールや素材に合わせて、作業台を整理するようなものだと考えてください

00:15:47.670 --> 00:15:50.850
テーブルが作業内容を記述し、リレーションシップが各要素を結びつけます

00:15:50.850 --> 00:15:53.670
フォームにより、詳細情報の入力や確認が可能になります

00:15:53.670 --> 00:15:56.210
リューは、対応が必要な業を見つけるのに役立ちます

00:15:56.210 --> 00:15:59.170
セキュリティによって、各ユーザーが開けるデータや変更できる内容が決定されます

00:15:59.170 --> 00:16:01.950
モデル駆動型アプリは、ダイナミクス365と並行して利用できます

00:16:01.950 --> 00:16:03.970
どちらもデータバースで動作するためです

00:16:03.970 --> 00:16:11.630
例えば、ダイナミクス365セールスが販売プロセス全体を扱い、小規模なモデル駆動型アプリが契約マネージャー専用の顧客契約管理の場を提供する、といった形です

00:16:11.630 --> 00:16:15.850
どちらも、顧客データベースを二重に作成することなく、関連する顧客データを共有できます

00:16:15.850 --> 00:16:18.430
もちろん、アクセスには引き続き注意が必要です

00:16:18.430 --> 00:16:24.990
アプリがデータバースのテーブルを扱えるからといって、すべてのユーザーがすべての行を編集したり、すべての列を表示したりできるべきではありません

00:16:24.990 --> 00:16:28.770
ロール、行いのアクセス権、ビジネスルールによって操作できる範囲が制御されます

00:16:28.770 --> 00:16:35.170
現場用アプリを使えば、会社や他のデータの情報を公開することなく、必要な顧客詳細情報やアクションだけを適切に提供できます

00:16:35.170 --> 00:16:40.990
つまり、データバースとダイナミクス365の統合は、離れた2つの部屋をつなぐケーブルのような役割を果たすのです

00:16:40.990 --> 00:16:46.330
ダイナミクス365アプリ、カスタムアプリ、そしてビジネスプロセスはすべて、同じ共有基盤の上で動作します

00:16:46.330 --> 00:16:49.210
それが理解できれば、次の疑問が明確になります

00:16:49.210 --> 00:16:54.750
マイクロソフトの接続されたプラットフォーム全体で、その同じ顧客更新情報を他に何に活用できるでしょうか

00:16:54.750 --> 00:16:57.990
接続されたプラットフォームが実際の業務でどのように機能するかを見ていきましょう

00:16:57.990 --> 00:17:01.850
共有された顧客更新情報は、周囲のツールがそれに応答して初めて価値を発揮します

00:17:01.850 --> 00:17:07.430
パワーオートメイトは、データバースの業の変更を監視し、変化があった際にアクションを開始することで、後続の業務を処理します

00:17:07.430 --> 00:17:11.030
例えば、ダイナミクス365セールスに新しいリードが登録されたとします

00:17:11.030 --> 00:17:16.230
フローによって、担当営業担当者への通知、チームへのメッセージ投稿、フォローアップタスクの作成などが行えます

00:17:16.230 --> 00:17:18.890
もう共有トレイを1日中監視する必要はありません

00:17:18.890 --> 00:17:22.170
リードが変更されると、次のステップが自動的に開始されます

00:17:22.170 --> 00:17:26.930
パワーオートメイトは、その作業を行うためだけにリードのコピーを別途必要とすることはありません

00:17:26.930 --> 00:17:32.130
セールスアプリが使用するのと同じ顧客情報や所有権の詳細を利用して、データバースの業に直接反応できるからです

00:17:32.130 --> 00:17:37.910
これにより、誰かがファイルを出力して手作業でメールのやり取りを開始する代わりに、ビジネスプロセスに密着した自動化が維持されます

00:17:37.910 --> 00:17:39.450
次にパワーBIがあります

00:17:39.450 --> 00:17:42.570
営業マネージャーは、現在のパイプラインを確認したいと思うでしょう

00:17:42.570 --> 00:17:49.910
カスタマーサービスマネージャーは、今週届いた案件数、未解決の案件、または最も頻繁にサポートに連絡してくる顧客を確認する必要があるかもしれません

00:17:49.910 --> 00:17:57.430
パワーBIはデータバースのビジネスデータをレポートできるため、チームは毎週金曜の午後に新しいスプレッドシートを作成しなくても、進行中の業務を把握できます

00:17:57.430 --> 00:18:00.890
レポートは、すでに現場で使用されているビジネスデータに基づいて作成されます

00:18:00.890 --> 00:18:04.030
つまり、案件が進むにつれてパイプラインのグラフも変化するのです

00:18:04.030 --> 00:18:07.950
ケースダッシュボードでは、エージェントがケースを更新するたびに現在の負荷状況を表示できます

00:18:07.950 --> 00:18:12.150
重要なのは、ダッシュボードが人の手による詳細確認を代替するということです

00:18:12.150 --> 00:18:16.210
何に注目すべきかを判断する前に、作業の全体像がより明確になります

00:18:16.210 --> 00:18:19.250
パワーアップスは、同じプロセスへの別の入り口を提供します

00:18:19.250 --> 00:18:22.350
現場の作業員が顧客先に到着した場面を想像してみてください

00:18:22.350 --> 00:18:26.210
彼らには、ダイナミクス365の販売機能のすべては必要ありません

00:18:26.210 --> 00:18:31.990
顧客を検索し、訪問の詳細を確認し、何があったかを記録し、メモや写真を加えるだけでいいかもしれません

00:18:31.990 --> 00:18:35.370
目的に特化したパワーアップなら、そうした最小限の機能を提供できます

00:18:35.370 --> 00:18:38.610
アカウントチームには、顧客との契約を確認するためのアプリが必要かもしれません

00:18:38.610 --> 00:18:41.670
マネージャーには、申請を承認するためのシンプルなアプリが必要かもしれません

00:18:41.670 --> 00:18:46.030
各アプリは特定のタスクに集中しながら、裏側では同じ管理されたデータバースの情報と連携します

00:18:46.030 --> 00:18:48.510
担当者は、自分の1日に適したツールを使うことになります

00:18:48.510 --> 00:18:50.790
企業側は、接続された情報を一元管理できます

00:18:50.790 --> 00:18:53.510
時には、その情報がデータバースの外から始まることもあります

00:18:53.510 --> 00:18:57.670
企業がオンラインソースから得たリストを、ビジネスデータの一部として取り込む必要がある場合などがそうです

00:18:57.670 --> 00:19:04.730
パワークエリを使えば、サポートされているオンラインソースからデータを取り込み、インポート中に整理し、適切なデータバーステーブルに読み込むことができます

00:19:04.730 --> 00:19:10.070
これは、ダイナミクスやパワープラットフォームのツールで使用する必要がある情報が外部ソースにある場合に役立ちます

00:19:10.070 --> 00:19:14.450
何がデータバースに属し、既存のテーブルとどう関連付けるべきかを決める必要があります

00:19:14.450 --> 00:19:18.930
それを考えずにデータをインポートしても、混乱を新しい場所に移動させるだけです

00:19:18.930 --> 00:19:22.070
オータムが各ピースを日々のフローに組み込む様子を見てみましょう

00:19:22.070 --> 00:19:28.010
新しいリードがダイナミクス365に入ると、割り当てルールが地域や製品に基づいて担当者をチェックします

00:19:28.010 --> 00:19:32.590
担当者はパワーオートメイトフローを通じてチームメッセージを受け取り、作業が待機していることを知ります

00:19:32.590 --> 00:19:39.410
営業担当者がリードを更新し、販売プロセスを進めると、パワーBIダッシュボードが変化し、オータムチームの現在のパイプライン状況がチームに共有されます

00:19:39.410 --> 00:19:42.430
たった一つの更新が、複数の場所で有益な作業を開始させます

00:19:42.430 --> 00:19:44.810
パワーオートメイトは作業を次のステップへと進めます

00:19:44.810 --> 00:19:47.310
パワーBIは、人々の作業状況の可視化を助けます

00:19:47.310 --> 00:19:50.510
パワーアップスは、特定のチームが参加するための集中的な手段を提供します

00:19:50.510 --> 00:19:54.730
データバースは、そうしたツールが機能する間、ビジネス情報を整理し保護します

00:19:54.730 --> 00:19:56.490
その違いが重要なのです

00:19:56.490 --> 00:20:00.690
自動化はファイリングシステムではなく、ダッシュボードは顧客データベースではありません

00:20:00.690 --> 00:20:04.170
各ツールには個別の役割がありますが、すべて同じソースから機能できます

00:20:04.170 --> 00:20:10.790
それを知ることで、すべてのスプレッドシートやリストがビジネスプロセス全体を担うべきかのように扱うのではなく、適切なツールを選択できるようになります

00:20:10.790 --> 00:20:15.850
データバースが適している場面と、それが置き換えないものについて、重要なのは以下の点です

00:20:15.850 --> 00:20:19.710
複数のユーザーやアプリが、相互接続されたビジネスデータを操作する必要がある場合にデータバースを選びます

00:20:19.710 --> 00:20:22.290
明確なアクセスルールと反復可能なプロセスが必要です

00:20:22.290 --> 00:20:25.310
データバースはそれを処理しますが、他のすべてを置き換えるわけではありません

00:20:25.310 --> 00:20:28.430
Excelは依然として、個人的な分析や簡易リスト作成に適しています

00:20:28.430 --> 00:20:31.390
シェアポイントリストは、チーム内の単純な追跡にうまく機能します

00:20:31.390 --> 00:20:35.130
また、詳細な制御が必要な開発者であれば、SQLが強力な選択肢となります

00:20:35.130 --> 00:20:37.570
では、データバースはいつ進化を発揮するのでしょうか

00:20:37.570 --> 00:20:42.710
データのコピーを作成せずに、ダイナミクス365アプリ、自動化、レポート間でデータを接続する必要がある場合です

00:20:42.710 --> 00:20:44.290
そこが最大の強みです

00:20:44.290 --> 00:20:45.630
では、結論です

00:20:45.630 --> 00:20:47.970
一つの基盤、多数のビジネスツール

00:20:47.970 --> 00:20:49.710
つまり、結論はこうです

00:20:49.710 --> 00:20:56.910
ダイナミクス365とデータバースは、データ、ルール、セキュリティ、アプリ、自動化、レポートのすべてが共通の基盤を共有するときに最も効果を発揮します

00:20:56.910 --> 00:21:04.910
M365FMのMicrosoft Knowledge Nuggetsを公読して、Dynamics 365 Power Platform Microsoft 365に関するわかりやすいガイドをご覧ください

00:21:04.910 --> 00:21:09.950
続いて、データバースのテーブルがどのように実用的なビジネスアプリに変わるのか、モデル駆動型アプリのエピソードをご覧ください