WEBVTT 00:00:00.000 --> 00:00:05.820 マイクロソフトナレッジナゲッツへようこそ もうピータースです今日のトピックはよく混乱を招くものです 00:00:05.820 --> 00:00:13.100 データバースとは一体何でしょうか データベースなのかアプリなのかそれとも it 担当者だけが理解すればいいダイナミクス365の隠れたサービスなのか 00:00:13.100 --> 00:00:19.180 最もシンプルな定義はこうです データバースは多くのダイナミクス365エクスペリエンスを支える共通のデータ基盤です 00:00:19.180 --> 00:00:26.040 ダイナミクス365オフィスビルだと考えてみてください 営業カスタマーサービスその他のアプリは人々が働く部屋であり 00:00:26.040 --> 00:00:32.640 データバースはその裏側にあるファイリングシステムとルールです このエピソードの終わりにはダイナミクスのデータがどこに存在し一つの顧客情報 00:00:32.640 --> 00:00:39.700 更新がどのように営業活動自動化レポートに反映されるかがわかります しかし製品名の話に入る前にまずはビジネス上の混乱から始めましょう 00:00:39.700 --> 00:00:46.820 これは一つの共有場所によって解決されます 別々のコピーを持つ代わりに営業チームサポートチーム経理チームがある会社を 00:00:46.820 --> 00:00:50.380 創造してみてください 営業部門は顧客の詳細をスプレッドシートで管理しています 00:00:50.380 --> 00:00:58.000 サポート部門は別の案件管理ツールで作業しています 経理部門は独自のシステムに顧客名を保持していますまたある人はメールスレッドを共有メールボックスに保存し 00:00:58.000 --> 00:01:04.880 別の人は誰も見つけられないフォルダーにメモを保管しています 同じ顧客が今や5つの場所に存在していることになります各チームが目の前の仕事しか見えていないため 00:01:04.880 --> 00:01:12.520 最初はこのような設定が普通に感じられます しかし問題はここです顧客が電話番号住所会社名または主要な連絡先を変更した途端問題が発生します 00:01:12.520 --> 00:01:19.700 営業がスプレッドシートを更新しますサポートにはそれが反映されません 経理は依然として古い住所に書類を送ってしまいますすると誰かがリストをエクスポートし 00:01:19.700 --> 00:01:27.440 手作業で整理してメールで回覧するため突然3人がそれぞれ自分のコピーこそが正しいと 信じるようになりますどのリストを信頼すべきでしょうかその疑問は皆さんが思う以上に 00:01:27.440 --> 00:01:33.040 時間を無駄にしますスタッフは記録を照合するために手を止めます 管理者はなぜレポートが営業システムと一致しないのかを問い詰めます 00:01:33.040 --> 00:01:39.480 サポート担当者は別の場所には少し異なる詳細情報が存在している顧客のために 案件を開いてしまいます誰も混乱を生み出そうとしているわけではありません 00:01:39.480 --> 00:01:47.320 混乱はコピーから生じるのです20年前はシステムが別々であればサーバーもデータベースも別々であり 各チームが独自の情報を保持していましたそれらを接続するにはカスタム作業 00:01:47.320 --> 00:01:54.280 スケジュールされたインポートそして多くの手作業による確認が必要でした ある場所での変更が別のシステムに反映されるのは明日か来週かあるいは永遠に反映されないこともありました 00:01:54.280 --> 00:02:02.540 データバースはビジネスアプリにこの種の情報のための共有の場所を提供します 簡単に言えばデータバースはビジネス情報のためのマイクロソフトのクラウドデータプラットフォームです 00:02:02.540 --> 00:02:10.400 情報を構造化されたテーブルに保存するためデータはバラバラのメモや未整理のファイル 断絶されたスプレッドシートのタブとしてではなく明確な形で存在します 00:02:10.400 --> 00:02:15.400 これは会社のファイリングキャビネットのようなものですが承認された複数のツールが同時に利用できる点が特徴です 00:02:15.400 --> 00:02:22.140 顧客はデータバースに一度だけ登録されます その顧客は営業担当者が商談を進める際にダイナミクス365セールスに表示されます 00:02:22.140 --> 00:02:27.800 同じ顧客の詳細はサポート担当者が依頼を処理する際にダイナミクス365カスタマーサービスにも表示されます 00:02:27.800 --> 00:02:34.080 パワーアップスを使えばデータを新しいアプリにコピーしなくても現場作業員やアカウントマネージャーが同じ顧客情報を利用できます 00:02:34.080 --> 00:02:39.540 一つの顧客行き一つの共有参照ポイントです これはあらゆるチームがすべての情報をすぐに見られるようになるという意味ではありません 00:02:45.400 --> 00:02:51.420 はなく同じビジネス情報を機に連携できるということです これがダイナミクス365とデータバースが非常に自然に適合する理由です 00:02:51.420 --> 00:02:56.200 ダイナミクス365セールスやカスタマーサービスなどのアプリはデータバースを使用してデータを保存保護しています 00:02:56.200 --> 00:03:03.340 しかしここが重要な点です ダイナミクス365とデータバースの統合について語る際多くの人はコネクタが必要な2つの別々の製品を 00:03:03.340 --> 00:03:07.280 想像しがちです しかし多くのダイナミクス365アプリにおいてその認識は誤りです 00:03:07.280 --> 00:03:15.800 データはすでにデータバースの中に存在しているからです ダイナミクス365から顧客リストを抜き出して別のデータベースにコピーし両方の同期を祈る必要はありません 00:03:15.800 --> 00:03:23.100 ダイナミクス365がすでに使用している同じビジネス情報に基づき同じ基盤の上に構築できるのです これによって議論の焦点が変わります 00:03:23.100 --> 00:03:31.420 どうすれば2つの顧客リストを同期できるかと問う代わりにどの担当者やアプリがこの顧客レコードを扱う必要があり それぞれに何を許可すべきかを問いかけることができます 00:03:31.420 --> 00:03:41.960 さてデータバースは企業が所有するすべてのシステムを置き換えるわけではありません 企業は依然として会計ソフト業界特化ツール倉庫システムウェブサイトあるいは独自のデータを持つ古いアプリケーションを使用する場合があります 00:03:41.960 --> 00:03:50.780 データバースは外部システムを一晩ですべて排除する魔法の接着剤ではないのです 提供されるのは接続されたアプリ間で共有する必要があるビジネスデータの共通の場所です 00:03:50.780 --> 00:03:58.880 顧客の詳細営業活動サポート業務タスクフォローアップなどが含まれます これらのレコードは一つのソースとして共存し承認されたツールが読み取りや更新を行えるようになります 00:03:58.880 --> 00:04:06.560 では私と一緒にそのファイリングキャビネットを開けてみましょう データバースがどのように情報を整理しているかがわかればダイナミクス365の接続全体における 00:04:06.560 --> 00:04:13.580 テーブル業列そしてリレーションシップというファイリングキャビネットの概念が理解しやすくなります そのファイリングキャビネットを開いてみましょう 00:04:13.580 --> 00:04:20.980 データバースでは情報はテーブルの中に格納されています 実際のキャビネットの引き出しを想像してみてください一つの引き出しには企業情報別の引き出しには個人情報 00:04:20.980 --> 00:04:26.540 3つ目の引き出しにはサポート依頼が入っています すべての書類を一つの巨大な引き出しに放り込んで後で誰かが整理してくれることを願うようなことはしません 00:04:26.540 --> 00:04:30.900 それぞれの引き出しには役割があります データバースにおいてテーブルは一種類のビジネス情報を保持するものです 00:04:30.900 --> 00:04:39.100 取引先テーブルには通常関わりのある企業の情報が入ります 連絡先テーブルには個人の情報が入りますリードテーブルには顧客になる前の見込み客の情報が入ります 00:04:39.100 --> 00:04:50.280 サポート依頼はケーステーブルで管理し通話やメール予定タスクといった作業はアクティビティテーブルで追跡できます これらが標準テーブルですほとんどの企業で顧客や担当者業務やり取りの管理が必要となるため 00:04:50.280 --> 00:04:56.020 マイクロソフトがこれらを用意しています 標準テーブルで対応できる一般的な業務に対してわざわざ新しいテーブルを作成する必要はありません 00:04:56.020 --> 00:05:01.380 しかしどの企業にも独自の業務というものがあります 研修会社であればコースや修了証の管理が必要かもしれません 00:05:01.380 --> 00:05:08.000 不動産業であれば建物やユニット点検記録が必要になるでしょう 製造業であれば機器の点検や訪問修理の記録が必要かもしれません 00:05:08.000 --> 00:05:16.400 そのような場合には自社の実際の業務に合わせたカスタムテーブルを作成できます カスタムテーブルはキャビネットに新しい引き出しを追加してわかりやすいラベルを貼るようなものだと考えてください 00:05:16.400 --> 00:05:20.680 テーブルに派行が含まれます 業とはその引き出しの中にある一つのアイテムのことです 00:05:21.080 --> 00:05:29.560 例えば連絡先テーブルの一行は顧客企業の担当者であるマリアゴメスさんを表すことができます その業にはシステム内の他のすべての連絡先とは区別された彼女の個別の詳細情報が保持されます 00:05:29.560 --> 00:05:39.300 列は各業に対して保持したい詳細情報を定義します マリアさんの連絡先行には名、姓、メールアドレス、電話番号、役職、会社、レコード所有者、ステータスなどの列が含まれます 00:05:39.300 --> 00:05:46.840 列はその場所にどのような種類の情報を入力するかを決定します つまりメール列にはメールアドレスが入りステータス列には承認済みのステータス選択肢が入るといった具合です 00:05:46.840 --> 00:05:57.040 このようにしてビジネス情報は確実な形式へと整えられます 列がなければ電話番号をメモ欄に入力する人もいれば名前のフィールドに追加する人も現れ入力すらしない人も出てくるでしょう 00:05:57.040 --> 00:06:04.280 明確な連絡先テーブルがあれば全員が同じ場所にある同じ詳細情報を使って作業できます その構造はアプリがデータを理解する助けにもなります 00:06:04.280 --> 00:06:12.160 フォームは適切な入力欄を表示できレポートはステータス別に連絡先を集計でき所有者が変われば自動化機能が反応します 情報はただ蓄積されるだけではありません 00:06:12.160 --> 00:06:23.480 各項目が何を意味するのかを接続されたツールに伝えるラベルがついているのです まずは業務ニーズに合う標準テーブルから使い始めてください企業相手のビジネスなら取引先や連絡先といった誰もが理解できるパターンがすでに用意されています 00:06:23.480 --> 00:06:31.720 顧客サポートを行っているならケーステーブルが出発点となります そして組み込みのパターンでは収まらない情報がある場合にのみカスタムテーブルを追加しましょう 00:06:31.720 --> 00:06:41.600 これにより顧客を意味するテーブルを5つも作成してしまうというよくある問題を回避できます あるチームはクライアント別のチームは顧客マスター3つ目のチームはパートナー連絡先と呼ぶかもしれません 00:06:41.600 --> 00:06:49.560 すぐにどのテーブルを使うべきか誰も判断できなくなります 標準テーブルを明確にしカスタムテーブルに慎重に名前をつけることで多くの人が利用しても整理された状態を保てます 00:06:49.560 --> 00:06:54.520 次にそれらの引き出しを連携させる仕組みについて説明します 連絡先はアカウントに属しています 00:06:54.520 --> 00:07:03.860 マリアはコントソ社で働いています マリアの業にコントソ社の住所や電話番号会社詳細を何度も入力する代わりにデータバースでは連絡先テーブルとアカウントテーブルの間にリレーションシップを作成できます 00:07:03.860 --> 00:07:11.620 マリアはコントソとリンクされており会社情報は会社側に保持されるためこのリンクが重要になります コントソのオフィス住所が変わった場合誰かがアカウント業を一度更新するだけで済みます 00:07:11.620 --> 00:07:19.500 関連するすべての連絡先は古い情報を個別に保持することなく常に同じ会社を参照できます リレーションシップはサポートケースをそれを提起した顧客と結びつけることもできます 00:07:19.500 --> 00:07:30.240 また販売案件をその取引に関連する通話メール会議パスクと結びつけることも可能です 営業担当者が案件を開くと無関係なメモやカレンダーを探し回ることなく関連する活動をすべて確認できます 00:07:30.240 --> 00:07:36.580 情報にコンテキスト文脈が生まれるのです 単にケース番号を見るだけではありませんどの顧客に属しているのかを確認できます 00:07:36.580 --> 00:07:45.660 連絡先を表示するだけでもありませんその人物に関連付けられた会社を確認できます これらのリンクのおかげで同じ事実をあちこちに入力し直すことなくデータを有効活用できます 00:07:45.660 --> 00:07:52.160 古いガイドや動画を見る前に用語に関する小さな注意点があります エンティティフィールドレコードという言葉を耳にするかもしれません 00:07:52.160 --> 00:07:59.160 これらはデータバースの古い用語です マイクロソフトは現在エンティティをテーブルフィールドを列レコードを行と呼んでいます 00:07:59.160 --> 00:08:05.580 意味は変わっていません つまりエンティティを作成するように指示する古いガイドはテーブルの作成を意味しています 00:08:05.580 --> 00:08:12.040 フィールドは列でありレコード派行です 両方の用語を知っておけば別の製品だと勘違いせずに済みます 00:08:12.040 --> 00:08:18.080 このようにテーブルは情報とそれらのリレーションシップを整理します しかし整理されたキャビネットには管理が必要です 00:08:18.080 --> 00:08:24.420 誰が何を入力し変更し安全にアクセスできるかを誰かが決定しなければなりません データにはルールと受付窓口が必要です 00:08:24.420 --> 00:08:29.380 共有データは適切な人が安全に作業できる場合にのみ機能します 営業担当者には顧客詳細が必要です 00:08:29.380 --> 00:08:36.360 サポート担当者にはケース履歴が必要です マネージャーにはより広い視野が必要です そして外部パートナーにはプロセスの一部へのアクセス権のみが必要かもしれません 00:08:36.360 --> 00:08:43.480 全員が同じ情報を見るべきではありません 非公開の連絡メモ交渉価格進行中のサポートケースを含む顧客レコードを想像してみてください 00:08:43.480 --> 00:08:50.160 すべてのユーザーにフルアクセス権を与えるとすぐにリスクが生じます 全員を厳しく制限しすぎると仕事ができなくなり別の問題が発生します 00:08:50.160 --> 00:08:58.120 データバースならこれらを制御できます 最初の制御はIDから始まります 会社のアカウントでサインインするとマイクロソフトエントラーIDがユーザーを識別します 00:08:58.120 --> 00:09:05.220 エントラーIDはオフィスの入り口にある受付だと考えてください 到着してバッジを見せると受付係が本人確認を行ってから入室を許可します 00:09:05.220 --> 00:09:11.400 データバースはそのIDを使用してどのユーザーがデータにアクセスしているかを把握します 単に入室を許可するだけではありません 00:09:11.400 --> 00:09:16.780 入室後にその人物に何を許可するかも決定します そこで役立つのがセキュリティロールです 00:09:16.780 --> 00:09:25.160 セキュリティロールとは業務や責任に紐づいた一連の権限のことです 営業担当者カスタマーサービス担当者マネージャーごとにロールを作成できます 00:09:25.160 --> 00:09:30.260 各ロールはテーブルへのアクセスを制御できます 例えば営業担当者は取引先企業取引先担当者 00:09:30.260 --> 00:09:35.680 見込み顧客案件の読み取り作成更新が許可されます しかし重要な顧客情報の削除は許可されない場合があります 00:09:35.680 --> 00:09:43.580 サポート担当者はケースの作成と更新はできますが営業案件を変更することはできません 権限には業の読み取り作成変更削除が含まれます 00:09:43.580 --> 00:09:49.280 つまりアプリごとにどのボタンを非表示にするかを覚えている必要はありません 権限はデータ自体に付随します 00:09:49.280 --> 00:09:55.140 そのためデータバースのデータがどこに表示されても同じガードレールが適用されます さらにアクセス権を細かく絞り込むことも可能です 00:09:55.140 --> 00:10:01.340 業レベルのセキュリティはどの業を操作できるかを決定します 営業担当者は自分が担当する顧客のみを見ることができますが 00:10:05.680 --> 00:10:12.440 を使用しますただしアクセスできるデータ範囲が異なります この設定によりスタッフは自分の作業に集中できマネージャーは必要な情報を把握できます 00:10:12.440 --> 00:10:19.140 またアクセス権のない顧客情報を誰かが開いてしまうリスクも軽減されます さらに厳重な保護が必要な情報もあります 00:10:19.140 --> 00:10:28.360 列レベルのセキュリティではテーブル内の個々の列を保護できます 例えば顧客業は開けても個人識別し給与銀行口座情報個人的な財務メモは見られないように 00:10:28.360 --> 00:10:31.880 できます 顧客業自体は業務に必要な範囲で利用可能です 00:10:31.880 --> 00:10:38.200 保護された列だけが制限されます 大規模な企業ではビジネスユニットを使用して組織間に境界を作成できます 00:10:38.200 --> 00:10:46.260 企業は異なる顧客グループを担当する地域部門子会社を分離できます ビジネスユニットはそれらの境界を超えたアクセス権の仕組みを形作るのに役立ちます 00:10:46.260 --> 00:10:51.760 これはすべてのビジネスに複雑なセキュリティマップが必要だという意味ではありません 小さなチームであれば明確なロールがいくつかあれば十分です 00:10:51.760 --> 00:10:59.560 規模の大きな企業ではチーム地域責任範囲が異なるためより多くの階層が必要になる場合があります 要点はデータバースならビジネスの実際の仕組みに合わせてアクセス権を設定できるということです 00:10:59.560 --> 00:11:08.260 アクセス制御は誰がデータにアクセスできるかを保護しますがルールはデータそのものの品質を保護します ビジネスルールを使用すれば新しい連絡先を保存する前に電話番号の入力を必須にすることができます 00:11:08.260 --> 00:11:15.200 またケースをクローズする際に理由の入力を求めるなど条件のチェックも可能です 入力された情報に基づいてユーザーに表示される内容を変更することもできます 00:11:15.200 --> 00:11:22.660 同じルールがそのテーブルを使用するすべてのアプリに適用されます これはあるアプリでは不完全なデータが受け入れられ別のアプリでは拒否されるといった事態を避けるために重要です 00:11:22.660 --> 00:11:30.860 ルールは特定の画面ではなくビジネス情報そのものに紐付けられるべきだからです データバースはバックグラウンドでロジックを実行しビジネスプロセスの一貫性を保つのにも役立ちます 00:11:30.860 --> 00:11:41.620 覚えておくべき詳細はシンプルです データは単なるストレージではなくルールを伴うということです つまり基盤には情報それを扱う権限を持つ人々そしてデータを活用可能にするルールが含まれています 00:11:41.620 --> 00:11:47.960 ダイナミクス365がその同じ基盤上で動作すれば自社のビジネスデータにアクセスするために従来のようなブリッジは不要になります 00:11:47.960 --> 00:11:57.280 ダイナミクス365の統合が実際に意味することですが多くの人はダイナミクス365とデータバースの統合と聞くとコネクタで結ばれた2つの別々のシステムを思い浮かべます 00:11:57.280 --> 00:12:05.340 一方のシステムが顧客データを保持しもう一方のシステムがそのコピーを必要とするため 同期を設定し実行を待ち途中で失敗しないことを祈るという流れです 00:12:05.340 --> 00:12:13.080 多くのビジネスツールにとってそのイメージは理にかなっています しかしダイナミクス365セールスとダイナミクス365カスタマーサービスの場合 00:12:13.080 --> 00:12:18.940 接続はそれよりもはるかに緊密です これらのアプリはデータバースを共有データ基盤として使用しています 00:12:18.940 --> 00:12:27.140 互いを理解するために顧客情報の業をやり取りする別々のデータベースではありません 最初から同じビジネス情報に基づいて動作しますこれは 00:12:27.140 --> 00:12:37.250 営業担当者がダイナミクス365セールスで新しい会社を作成する場合の例です 主な連絡先を追加し商談への取り組みを開始します 00:12:37.250 --> 00:12:43.210 それらの詳細は即座にアプリが使用する共有データの一部となります その後その顧客がサポートに連絡したとします 00:12:43.210 --> 00:12:51.630 サポート担当者は全く同じ会社情報と連絡先詳細を扱うことができます 営業からリストをエクスポートしたり別のサポートツールで顧客情報を再作成したりする必要はありません 00:12:51.630 --> 00:12:58.490 担当者はサポートケースをその顧客に紐付けるだけで状況を理解するための履歴を確認できます 営業チームは商談を確認します 00:12:58.490 --> 00:13:06.510 サポートチームはケースを確認し両チームが同じ顧客を中心に取り組むのです もちろんこれはすべての画面が同一になることやすべてのチームが同じプロセスに従うことを意味するわけではありません 00:13:06.510 --> 00:13:13.030 営業にはリード案件通話会議が必要です カスタマーサービスにはケース9サービス履歴が必要です 00:13:13.030 --> 00:13:20.210 ダイナミクス365の各アプリは業務に最適なツールを提供します 基盤となるビジネス情報は必要な場所であればどこにでも接続できます 00:13:20.210 --> 00:13:29.150 この共通の基盤こそがダイナミクス365とデータバースの統合が意味するところです 単にデータをA地点からB地点へ移動させるだけではありません 00:13:29.150 --> 00:13:36.270 アプリが同じ業関係性ルールアクセス制御を共有することなのです まずオフィスでのシンプルな販売プロセスを 00:13:36.270 --> 00:13:40.070 たどってみましょう ウェブサイトやイベントからリード見込み客が発生します 00:13:40.070 --> 00:13:49.890 営業担当者がそのリードに対応し人物について理解を深めリードを顧客関係や商談へと転換します 電話メール予定タスクのすべてをその一連の業務に紐付けることができます 00:13:49.890 --> 00:13:58.010 そのためチームが個別のツールを探し回って状況をつなぎ合わせる必要はありません その後顧客がサポートを必要とした場合サポートケースを同じ顧客に紐付けることができます 00:13:58.010 --> 00:14:05.610 サポート担当者は名前とメールアドレスだけを確認するようなことはしません すでに特定された顧客関係に基づき状況を把握しながら対応できます 00:14:05.610 --> 00:14:12.010 一方営業チームは顧客に未解決のサービス課題があることを把握できるため 問題を把握せずに更新の商談へ進む事態を防げます 00:14:12.010 --> 00:14:19.010 一つの顧客関係が様々な種類の業務を支えることができます これは単に2つのシステムで顧客名を一致させることよりもはるかに有用です 00:14:19.010 --> 00:14:26.390 コモンデータモデル略して cdm という言葉を耳にすることもあるでしょう その名前から必要以上に複雑なものだと考える必要はありません 00:14:26.390 --> 00:14:33.550 単に多くの企業が追跡する取引先担当者 活動ケースなどの共通のビジネス用テーブルパターンをマイクロソフトが提供しているということです 00:14:33.550 --> 00:14:41.430 これらのパターンによりダイナミクス365とデータバースベースのアプリは共通の言語で始動できます 取引先とは企業を意味します担当者とは個人を意味します 00:14:41.430 --> 00:14:50.250 活動とはビジネス関係における業務を記録するものです 自社に合わせて設定を調整し必要なテーブルを追加できます毎回白紙の状態から始める必要はありません 00:14:50.250 --> 00:14:56.650 あるアプリが取引先テーブルを理解し別のアプリも同じテーブルを使用すれば 両方のアプリが同じ種類のビジネス情報を参照できます 00:14:56.650 --> 00:15:04.310 これにより構築できる内容も変わってきます 例えばフィールドチームが顧客を検索し訪問を確認し面談後にメモを残すためのシンプルなアプリが必要だとします 00:15:04.310 --> 00:15:12.730 ダイナミクス365ですでに使用されているデータバーステーブルを利用してパワーアップスを構築できます そのアプリのためだけに顧客データを新しいリストへエクスポートする必要はありません 00:15:12.730 --> 00:15:23.930 フィールド作業員はアプリを開き顧客を見つけて訪問情報を更新するだけです データは以前説明したセキュリティルールの対象となり営業やカスタマーサービスがすでに使用している顧客関係と接続されたままになります 00:15:23.930 --> 00:15:29.730 より構造化された業務にはモデル駆動型アプリを構築できます モデル駆動型アプリはデータモデルから始まります 00:15:34.310 --> 00:15:42.230 パワーアップスはその構造を使用して実用的なビジネスアプリのエクスペリエンスを作成します チームが実際に使用するツールや素材に合わせて作業台を整理するようなものだと考えてください 00:15:42.230 --> 00:15:48.810 テーブルが作業内容を記述しますリレーションシップが各要素を結びつけます ホームは詳細を入力及び確認するための場所をユーザーに提供します 00:15:48.810 --> 00:15:54.270 リューは注意が必要な業を見つけるのに役立ちます セキュリティは各ユーザーが何を開いたり変更したりできるかを決定します 00:15:54.270 --> 00:15:58.730 モデル駆動型アプリはどちらもデータバースを基盤としているため ダイナミクス365と並行して機能させることができます 00:15:58.730 --> 00:16:05.470 例えばダイナミクス365セールスが販売プロセス全体を処理し 小規模なモデル駆動型アプリが契約マネージャーに顧客との合意事項を追跡するための専用の場所を提供する 00:16:05.470 --> 00:16:10.670 といった使い方が可能です どちらも2つ目の顧客データベースを作成することなく関連する顧客データを使用できます 00:16:10.670 --> 00:16:17.730 もちろんそのアクセスには依然として注意が必要です アプリがデータバーステーブルを使用できるからといって全てのユーザーが全ての行を編集したり 00:16:17.730 --> 00:16:23.510 全ての列を表示したりできるべきではありません ロールベースの行アクセス制御とビジネスルールが引き続き操作を制限します 00:16:23.510 --> 00:16:30.050 現場向けアプリであれば会社の他のデータやtmsデータを公開することなく その担当者に必要な顧客詳細とアクションだけを提供できます 00:16:30.050 --> 00:16:41.250 つまりダイナミクス365とデータバースの統合はもはや遠く離れた2つの部屋をつなぐ単なるケーブルではありません ダイナミクス365アプリカスタムアプリおよびビジネスプロセスはすべて同じ共有基盤の上で機能します 00:16:41.250 --> 00:16:49.590 それがわかると次の疑問が明確になります マイクロソフトの接続プラットフォーム全体でその同じ顧客更新情報を他に何が利用できるでしょうか 00:16:49.590 --> 00:16:56.670 この接続プラットフォームは実際の業務でどのように機能するのでしょうか 共有された顧客更新情報は周囲のツールがそれに対応できる場合に役立ちます 00:16:56.670 --> 00:17:02.390 パワーオートメートはデータバースの業の変更を監視し変更が発生した時にアクションを開始することで 後続の作業を処理します 00:17:02.390 --> 00:17:10.970 例えば新しいリードがダイナミクス365セールスに入力されたとします フローによって担当営業への通知チームへのメッセージ投稿またはフォローアップタスクの作成が可能になります 00:17:10.970 --> 00:17:17.150 誰も共有受信トレイを1日中監視する必要はありません リードが変更されると次のステップが自動的に開始されます 00:17:17.150 --> 00:17:27.070 パワーオートメートはその作業を行うためだけにリードの個別のコピーを必要としません 営業アプリが使用しているのと同じ顧客情報や所有者詳細を使ってデータバースの業に反応できるため 00:17:27.070 --> 00:17:32.630 ファイルをエクスポートして手動でメールをやり取りすることに頼らず ビジネスプロセスに密接した自動化が可能になります 00:17:32.630 --> 00:17:37.410 次はパワーBIです セールスマネージャーは現在のパイプラインを確認したいと思うかもしれません 00:17:37.410 --> 00:17:44.730 カスタマーサービスマネージャーは今週何件の問い合わせがあったか どの案件が未解決かあるいはどの顧客からのサポート依頼が多いかを把握する必要があります 00:17:44.730 --> 00:17:52.430 パワーBIはデータバースのビジネスデータをレポートできるため 各チームは毎週金曜日の午後にスプレッドシートをエクスポートする手間をかけずに進行中の業務を可視化できます 00:17:52.430 --> 00:17:59.010 このレポートは日常的に使用されているビジネスデータから作成されます つまり案件が進行するにつれてパイプラインのグラフも動的に変化します 00:17:59.010 --> 00:18:06.970 担当者がケースを更新すればケースダッシュボードで現在の作業負荷を確認できます ここで重要なのはダッシュボードが個別に詳細を確認する作業を置き換えるということです 00:18:06.970 --> 00:18:11.390 ダッシュボードによって何に注目すべきかを判断する前に業務の全体像をより明確に把握できる ようになります 00:18:11.390 --> 00:18:17.430 パワーアップスは同じプロセスへの別の入り口を提供します 現場の作業員が顧客の現場に到着した場面を想像してみてください 00:18:17.430 --> 00:18:26.910 彼らにダイナミクス365セールスの全機能は必要ありません 必要なのは顧客を見つけ訪問の詳細を確認し状況を報告しメモや写真を残すことだけかもしれません 00:18:26.910 --> 00:18:33.550 目的を絞ったパワーアップならこうした簡潔な操作感を提供できます アカウントチームには顧客との契約内容を確認するためのアプリが必要かもしれません 00:18:33.550 --> 00:18:41.010 マネージャーには申請を承認するためのシンプルなアプリが必要かもしれません 各アプリは特定の業務に集中しながらバックエンドでは一元管理された同一のデータバース情報を使用します 00:18:41.010 --> 00:18:48.410 ユーザーは自分の業務に最適なツールを使用できます 企業は一貫した情報を保持し続けることができます時には情報がデータバースの外部で発生することもあります 00:18:48.410 --> 00:18:55.910 企業がオンラインソースから得たリストをビジネスデータの一部として組み込む必要がある場合などがそうです パワークエリを使えばサポートされているオンラインソースからデータを取り込み 00:18:55.910 --> 00:19:04.830 インポート中にクレンジングを行い適切なデータバーステーブルに読み込むことができます これは外部ソースにダイナミクスやパワープラットフォームのツールで必要な情報が含まれている場合に役立ちます 00:19:04.830 --> 00:19:13.470 それでも何がデータバースに属するのか既存のテーブルとどう連携させるべきかを検討する必要があります 検討せずにデータをインポートしても混乱の場所が変わるだけです 00:19:13.470 --> 00:19:23.130 ではこれらの要素を日常的なフローに当てはめてみましょう 新しいリードがダイナミクス365に入力されます割り当てルールによって地域や製品に基づいて誰がそのリードを担当すべきかが判断されます 00:19:23.130 --> 00:19:34.230 担当者はパワーオートメートフローを通じてチームメッセージを受け取り作業が待機していることを知ります 営業担当者がリードを更新して販売プロセスを進めるとパワーBIダッシュボードが更新されチームの現在のパイプラインが反映されます 00:19:34.230 --> 00:19:42.050 たった一つの更新が様々な場所で有用なアクションを引き起こします パワーオートメートはタスクを次のステップへと進めますパワーBIは業務の状況を可視化します 00:19:42.050 --> 00:19:49.670 パワーアップスは特定のチームが業務に関与するための専用のインターフェースを提供します データバースはこれらのツールが動作する間ビジネス情報を整理し安全に保ちます 00:19:49.670 --> 00:19:55.670 その違いが重要なのです 自動化ツールはファイリングシステムではなくダッシュボードは顧客データベースそのものではありません 00:19:55.670 --> 00:20:03.690 それぞれのツールには役割がありますがすべて同じソースから連携できます それを理解すればスプレッドシートや単純なリストで業務プロセス全体を回そうとするのではなく 00:20:03.690 --> 00:20:09.310 適切なツールを選べるようになります データバースが適している場面と何にとって変わるわけではないのかを解説します 00:20:09.310 --> 00:20:14.570 ここからが本題です 複数のユーザーやアプリが相互に関連するビジネスデータを扱う必要があるならデータバースを選びましょう 00:20:14.570 --> 00:20:20.170 明確なアクセスルールや反復可能なプロセスが必要な場合です データバースはそれを実現しますが他のすべてを置き換えるわけではありません 00:20:20.170 --> 00:20:26.210 個人的な分析や素早いリスト作成には依然としてエクセルが最適です チーム内での簡単な追跡にはシェアポイントリストが適しています 00:20:26.210 --> 00:20:32.450 また詳細な制御を必要とする開発者にとってはSQLが依然として強力な選択肢です ではデータバースはいつ進化を発揮するのでしょうか 00:20:32.450 --> 00:20:37.650 データのコピーを作成することなくダイナミクス365アプリ自動化レポートの間でデータを接続する必要がある場合です 00:20:44.570 --> 00:20:51.750 ダイナミクス365とデータバースはすべてのデータルールセキュリティアプリ自動化 レポートが共通の基盤を共有するときに最も力を発揮します 00:20:51.750 --> 00:20:59.650 m365fmでマイクロソフトのウルジナゲッツを公読し ダイナミクス365パワープラットフォームマイクロソフト365のわかりやすいガイドをご覧ください 00:20:59.650 --> 00:21:05.470 次はモデル駆動型アプリの回を見てデータバースのテーブルがどのように実用的なビジネスアプリに変わるのかを確認してください