WEBVTT 00:00:00.000 --> 00:00:06.000 ビジネスセントラルで業務の大半を処理できてもビジネスの一部がうまく適合しない場合はどうすれば良いでしょうか 00:00:06.000 --> 00:00:14.440 特別な配送プロセスが必要だったり財務チームにローカルレポートが必要だったり あるいは同じデータを連携していない2つのシステムにスタッフが入力し続けている場合などがあるでしょう 00:00:14.440 --> 00:00:21.960 ビジネスセントラルはすでに多くの業務をカバーしています 財務販売在庫プロジェクト日々の業務を一箇所で管理するのに役立ちます 00:00:21.960 --> 00:00:33.460 しかし重要なのは同じやり方で運営されている会社は2つとしてないということです お手元のスマートフォンを思い浮かべてください通話メッセージカメラ基本的なツールが備わっており本体を分解することなく自分の生活に合ったアプリをインストールして使いますよね 00:00:33.460 --> 00:00:41.480 ビジネスセントラルの拡張機能エクステンションも同じ仕組みです このナレッジナゲットを終える頃にはそれらが何なのかどこで適合するのか追加する前に何を確認すべきかを理解できるようになります 00:00:41.480 --> 00:00:54.520 ではエクステンションとは一体何なのでしょうか エクステンションとはダイナミクス365ビジネスセントラル用のパッケージで標準設定にはない機能を追加したり標準機能の動作を自社に合わせて変更したりするものです 00:00:54.520 --> 00:01:03.760 配送希望を入力しないと顧客を作成できないように顧客カードに必須項目を一つ追加するような小さなものもあればビジネスプロセス全体をカバーするものもあります 00:01:03.760 --> 00:01:14.020 配送エクステンションなら配送ラベルの作成や配送サービスへの詳細送信 追跡情報の取得が可能ですし銀行エクステンションなら銀行明細を取り込んで記録済みの支払いと称号することもできます 00:01:14.020 --> 00:01:20.340 基本的な考え方を理解するのに開発者である必要はありません ビジネスセントラルをオフィスビルと考えてみてください 00:01:20.340 --> 00:01:28.580 標準アプリには財務販売購買在庫ジョブといった主要な部屋が用意されています ドアや壁配線共有サービスなどはすでに整っていますよね 00:01:28.580 --> 00:01:38.440 エクステンションは建物の主要な構造を壊すことなくその周囲に何かを追加するものです 新しい部屋を増やしたりすでにあるデスクにツールを置くように販売オーダーへのボタン追加 00:01:38.440 --> 00:01:47.720 リストへの列追加請求書のレイアウト変更外部サービスとの接続などが可能です 裏側ではエクステンションによってフィールドページレポートアクション 00:01:47.720 --> 00:01:53.420 ルールビジネスロジックを追加できます 最後の言葉は専門的に聞こえるのでわかりやすく説明しましょう 00:01:53.420 --> 00:02:01.760 ビジネスロジックとはビジネスセントラルに何をするかを指示するルールのことです 例えば発注番号が入力されるまで注文がリリースされないように制限するルールなどが挙げられます 00:02:01.760 --> 00:02:10.800 また別のルールでは金額が上限を超えた際にドキュメントを承認へ回すことも可能です この拡張機能がそのルールを処理するためチームが毎回覚えておく必要はありません 00:02:10.800 --> 00:02:17.020 クラウドアプリや拡張機能が標準となる前は企業はビジネスセントラルのもともとのコードを直接変更することがよくありました 00:02:17.020 --> 00:02:25.100 これはオフィスビル内の壁や配線を実際に作り変えるようなものです 最初はそれで問題が解決することもありますしかしマイクロソフトがアップデートを配信する際 00:02:25.100 --> 00:02:32.080 そのアップデートは標準的なビルを前提としているため独自の変更箇所と衝突することがあります そのためアップデートを安全に進めるには誰かがその変更を確認し 00:02:32.080 --> 00:02:38.860 競合を修正してシステムをテストする必要があります その作業には時間がかかります拡張機能はコードが標準アプリのコードと分離されているため 00:02:38.860 --> 00:02:44.560 こうしたトラブルの多くを回避できます つまりビルを作り直すのではなく丁寧に作られたアドオンを取り付けるのです 00:02:44.560 --> 00:02:53.400 拡張機能は個別のパッケージに持たれるためマイクロソフトはコアアプリケーションを更新できます とはいえすべてのアップデートに全く注意が必要ないというわけではありません 00:02:53.400 --> 00:03:00.640 拡張機能は別の拡張機能に依存することがあり ビジネスセントラルの変更に合わせて発行元が互換性のあるバージョンをリリースする必要があるかもしれません 00:03:00.640 --> 00:03:05.760 それでも拡張機能を標準コードから分離することでよりクリーンな出発点が得られます 00:03:05.760 --> 00:03:14.940 プラグインツールを専用のケースに入れておくようなものだと考えてください 必要な時にワークショップにツールを接続すればよくワークショップ自体を立て直す必要はありません 00:03:14.940 --> 00:03:25.600 ツールが不要になればビル全体を解体せずともそのアドオンを取り外せます これによりいかにして自社向けにビジネスセントラルを書き換えるかという議論がいかにして安全に不足部分を補うかという議論に変わります 00:03:25.600 --> 00:03:34.660 標準のビジネスセントラルはすでに膨大な通常の業務を処理しているためこれは非常に重要です ですから拡張機能は単に古いシステムと見た目が違うからといって全ての画面を作り直す口実にするのではなく 00:03:34.660 --> 00:03:39.780 実質的なギャップを埋めるものであるべきです 時には一つのフィールドと一つのチェック機能を追加するだけの拡張機能が最善であることもあります 00:03:39.780 --> 00:03:45.120 時には会社ですでに利用しているサービスとビジネスセントラルを接続することもあります いずれにせよ目標はシンプルです 00:03:45.120 --> 00:03:53.420 標準的な基盤を安定させつつ従業員が必要とするツールを追加することです 次に拡張機能はすべて同じ場所から提供されるわけではないため誰がこれらを作成しているのかを 00:03:53.420 --> 00:03:59.400 見ていく必要があります 拡張機能の主なタイプについてでは拡張機能は一体どこから来るのでしょうか 00:03:59.400 --> 00:04:08.520 提供元は一つではなくその違いを知ることはビジネスに最適なものを選ぶ助けとなります 最初のタイプはアプリ拡張機能と呼ばれますこれはビジネスセントラル内で特定の業務を 00:04:08.520 --> 00:04:13.640 処理するパッケージ化されたアドオンだと考えてください 例えば配送アプリを使えば注文データを運送業者と連携させることができます 00:04:13.640 --> 00:04:20.180 決済アプリはカード決済を受け付けたり詳細を決済サービスに送信したりできます レポーティングアプリはチームが毎月必要とするレポートを追加できます 00:04:20.180 --> 00:04:29.280 アプリ拡張機能とは必要な作業のために既製品のツールを購入するようなものです インストールして会社向けに設定すればユーザーはビジネスセントラル内で新しい機能を 00:04:29.280 --> 00:04:37.660 利用できます独自のページやフィールドを追加したり販売注文購買注文顧客カードなど ユーザーがすでに慣れ親しんでいるページにオプションを追加したりすることもあります 00:04:37.660 --> 00:04:44.620 一部のアプリ拡張機能はマイクロソフト自身が提供しています これらはすべての企業や国に適用されるわけではないニーズに対するアドオンを提供します 00:04:44.620 --> 00:04:50.800 現地の法規制に対応したレポートパックが良い例です 税務ルール請求書支払い公式文書は場所によって異なります 00:04:50.800 --> 00:04:58.740 そのためある国では必要でも他の国では全く使われない機能が存在します その切り分けにより標準製品の機能をシンプルに保ちつつ各社が現地のルールに対応できるようにしています 00:04:58.740 --> 00:05:03.400 次に isv 拡張機能があります isv は独立系ソフトウェアベンダーの略です 00:05:03.400 --> 00:05:09.520 難しそうな専門用語に聞こえますが実際には多くのビジネスセントラル顧客向けのアプリを 構築するソフトウェア会社を指します 00:05:09.520 --> 00:05:18.060 isv は倉庫業務小売製造文書管理給与システム連携電子請求書 または業界向けレポートなどに注力する場合があります 00:05:18.060 --> 00:05:24.200 顧客ごとに同じ機能をゼロから構築する代わりに多くの企業が購入やサブスクリプション で利用できるアプリを一つ作成します 00:05:24.200 --> 00:05:29.000 これらのアプリは通常マイクロソフトビジネスアプリのオンラインマーケットプレイスである マイクロソフトアップソースに掲載されます 00:05:29.000 --> 00:05:36.940 アップソースは一般的なニーズがある場合に役立ちます 多くの企業が同じ配送サービス銀行または決済プロバイダーにビジネスセントラルを接続したいと考えているかもしれません 00:05:36.940 --> 00:05:43.960 自社専用の接続機能を構築するために費用を支払う代わりにサポートやセットアップガイド 定期的なアップデートが提供される既存のアプリを見つけることができます 00:05:43.960 --> 00:05:49.540 それは多大な労力の節約になります とはいえアップソースにあるからといって必ずしもそのアプリが適切な選択肢とは限りません 00:05:49.540 --> 00:05:54.000 それが自社のプロセス国および使用しているビジネスセントラルのバージョンに適合しているかを確認する必要があります 00:05:54.000 --> 00:05:59.300 優れたアプリとは日常業務のあらゆる部分をアプリに合わせて変更させることなく明確な課題を解決するものです 00:05:59.300 --> 00:06:06.540 次のタイプはpteと略されることが多いテナント単位の拡張機能パーテナントエクステンションです テナントとは記者専用のビジネスセントラル環境のことです 00:06:06.540 --> 00:06:12.500 つまりテナント単位の拡張機能とは記者専用に構築されたアプリでありすべてのビジネスセントラル顧客がインストールできるように公開されるものではありません 00:06:12.500 --> 00:06:22.480 配送手数料の計算に非常に特殊な方法を用いている食品卸売業者を想像してみてください 価格は温度管理された輸送配送ゾーン回収可能なコンテナそして長年積み重ねられた顧客との取り決めによって決まるかもしれません 00:06:22.480 --> 00:06:29.640 そのようなプロセスは標準的な配送アプリにはおそらく特殊すぎます そのためビジネスセントラルのパートナーや開発者はそのプロセスに合わせてテナントごとの拡張機能 00:06:29.640 --> 00:06:36.120 テルテナンテキステンションを構築できます このアプリはその会社のビジネスセントラル環境内に泊まりその会社の業務に合わせて調整可能です 00:06:36.120 --> 00:06:41.640 古いシステムとの個別連携や特別な承認プロセスあるいはその企業特有の業務のための画面などが含まれる場合があります 00:06:41.640 --> 00:06:46.540 しかしカスタムメイドが必ずしも優れているとは限りません テナントごとの拡張機能は業務に密接にフィットします 00:06:46.540 --> 00:06:54.140 ただし誰かがそれを管理しなければなりません つまり記録の保持や変更のテストそして会社がプロセスを変更したりビジネスセントラルが更新されたりした際のサポート手配が必要になります 00:06:54.140 --> 00:07:00.800 もし他社でも同じ機能が使えるなら既存のisvアプリの方が長期的な手間は少なくて済むかもしれません ではどのように選べば良いのでしょうか 00:07:00.800 --> 00:07:09.220 拡張機能の種類ではなくビジネス上のニーズから始めましょう 銀行取引明細書のインポート配送ラベル電子請求書地域のレポートなどニーズが一般的である場合です 00:07:09.220 --> 00:07:16.640 まずはマイクロソフトまたはisvのアプリを探してください すでに適合する完成度の高いアプリが見つかるかもしれませんそのニーズが自社独自のプロセスに由来するものなら 00:07:16.640 --> 00:07:22.440 テナントごとの拡張機能の方が理にかなっている可能性があります 顧客や仕入れ先を保存する前に特定のフィールド入力を必須にするなど 00:07:22.440 --> 00:07:29.180 限定的なルールを扱うシンプルな拡張機能もあります これらは小規模ですが情報の欠落が後で大きな問題に発展するのを防ぐことができます 00:07:29.180 --> 00:07:36.160 誰がアプリを構築したかによってサポートや更新の依頼先が決まります アプリが何を変更するかによってユーザーが日常的に何に気づくかが決まります 00:07:36.160 --> 00:07:42.160 拡張機能がどのように日常業務を変えるかについてです では実際にどこで拡張機能に気づくのでしょうか 00:07:42.160 --> 00:07:49.580 通常は顧客カード受注電票品目カードまたは転記済み請求書など普段使用しているページで気づくはずです それは多くの場合ページ拡張機能によるものです 00:07:49.580 --> 00:07:57.060 使い慣れたページを置き換えることなく画面を変更します チームはそのままの場所で作業を続けながら拡張機能によってプロセスに必要な情報やアクションが追加されます 00:07:57.060 --> 00:08:05.860 営業チームがすべての顧客に対して配送の時間枠を必要としていると想像してみてください ページ拡張機能を使えば顧客カードに配送時間枠フィールドを追加しその詳細を受注電票にも表示できます 00:08:05.860 --> 00:08:12.480 別のスプレッドシートやメールに隠れたメモはもう必要ありません 注文を入力する担当者は必要な場所で配送ルールを確認できます 00:08:12.480 --> 00:08:21.180 変更がさらにシンプルな場合もあります支払いリマインダーの送信配送ラベルの作成 関連ドキュメントのオープン承認リクエストの開始などを行う新しいボタンが表示されるかもしれません 00:08:21.180 --> 00:08:28.140 ページの外観はビジネスセントラルのままですがチームが完了すべき業務をサポートするようになります これにより業務が記録のすぐ近くで完結します 00:08:28.140 --> 00:08:36.960 ユーザーに複数のツールをまたいで5つのステップを記憶させるのではなく拡張機能を使うことで現在表示している顧客 請求書注文アイテムのすぐ横に次のアクションを配置できます 00:08:36.960 --> 00:08:44.720 作業の引き継ぎが少なければそれだけ見落としも減ります レポートも同様に変化しますビジネスセントラルには標準レポートが含まれていますが企業によっては 00:08:44.720 --> 00:08:50.240 請求書に特別な参照番号追加の法的テキスト異なるロゴ または顧客が期待する情報の表示が必要になる場合があります 00:08:50.240 --> 00:08:57.240 レポート拡張機能を使用すれば元のレポートを残したままそうしたデータを追加したり別の レイアウトを提供したりできます販売請求書について考えてみましょう 00:08:57.240 --> 00:09:05.900 財務チームは国内顧客用と海外顧客用で異なるレイアウトを必要とするかもしれません 国内向けには現地の税詳細を表示し海外向けには別の文言や通貫参照情報が必要になる場合があります 00:09:05.900 --> 00:09:12.500 レポート拡張機能はそれらのレイアウトを追加し各ドキュメントに必要なフィールドを取り込むことができます 標準レポートが消えるわけではありません 00:09:12.500 --> 00:09:20.420 慣れ親しんだレポートを完全に別物と入れ替えるわけではないためこれは重要です 標準レポートをベースとして維持しながらビジネスに必要なものを追加できるのです 00:09:20.420 --> 00:09:28.760 レポートは社外に送るドキュメントのためだけのものではありません 拡張機能を使えば社内財務レポートに列を追加したり在庫計画のために詳細なアイテム情報を表示したり 00:09:28.760 --> 00:09:34.360 経営レポートに企業独自のフィールドを含めたりできます ビジネスセントラルにデータが存在していればレポートはそのデータを人々が意思決定に 00:09:34.360 --> 00:09:39.860 使うビューに取り込むことができます 次に権限セット拡張機能があります権限は各ユーザーが何を見たり変更したり 00:09:39.860 --> 00:09:44.760 転記したり削除したりできるかを決定します 初心者の方には会社の各部屋に入るためのアクセスカードのようなものだと考えると 00:09:44.760 --> 00:09:48.440 わかりやすいでしょう 財務担当ユーザーには新しい支払い画面へのアクセス権が必要になるかもしれません 00:09:48.440 --> 00:09:55.280 倉庫担当ユーザーには出荷アクションへのアクセス権が必要ですがその裏にある銀行口座情報への アクセスは不要かもしれません拡張機能が新しいページやプロセスを追加する際 00:09:55.280 --> 00:09:59.760 その新しい業務に必要な権限も合わせて追加できます これによりよくある問題を回避できます 00:09:59.760 --> 00:10:05.100 アプリをインストールしたものの新しいボタンは表示されているのに背後にある レコードへのアクセス権がないために使えないといった問題です 00:10:05.100 --> 00:10:11.440 権限セット拡張機能は新しい機能を適切な役割に結びつけるのに役立ちます そのためアクセス権はユーザーが実際に行う仕事に即したものになります 00:10:11.440 --> 00:10:18.420 誰にアクセス権を与えるべきかは依然として判断する必要があります 拡張機能は権限セットを提供できますがそれを使用する人やグループを選択するのは 00:10:18.420 --> 00:10:23.220 記者自身です 新しいツールが各ユーザーの役割を超えたアクセス権を自動的に付与してしまうようなことは避けるべきです 00:10:23.220 --> 00:10:28.520 多くの拡張機能はビジネスセントラルを他のオンラインサービスと接続する役割も果たします これらは統合アプリと呼ばれます 00:10:28.520 --> 00:10:34.620 これらはビジネスセントラルと銀行配送会社決済サービスオンラインショップ その他のビジネスシステムの間で情報をやり取りします 00:10:34.620 --> 00:10:42.860 毎日銀行の取引明細を受け取る財務チームの例を見てみましょう 接続がない場合銀行からファイルをダウンロードして手動でアップロードし銀行の明細と支払いを1件ずつ 00:10:42.860 --> 00:10:50.680 称号して一致しない項目を追跡しなければならないかもしれません 銀行機能の拡張機能があれば明細をビジネスセントラルに取り込み入出金と既存の記録をチームが 00:10:50.680 --> 00:10:55.900 称号するのを支援できます 担当者が例外を確認する必要はありますが日常的な称号に係る手作業は削減されます 00:10:55.900 --> 00:11:02.760 経理チームは人が直接調査する必要のある項目に集中できます これが拡張機能の実用的な使い方です判断を不要にするわけではありません 00:11:02.760 --> 00:11:09.120 繰り返しの作業を取り除くのです 配送アプリもほぼ同じ仕組みです販売注文から住所や小包の詳細を配送業者サービスに送信できます 00:11:09.120 --> 00:11:16.300 配送業者はラベルと追跡番号を返信できます 同じ住所を別のウェブサイトにコピーする代わりにチームは注文画面から直接配送作業を開始できます 00:11:16.300 --> 00:11:22.400 必要な時にこれらの機能を追加できます 配送業者の利用をやめたり決済プロバイダーを変更したりプロセスを廃止したりする場合 00:11:22.400 --> 00:11:29.240 関連する拡張機能は不要になるかもしれません このようなモジュール式のアプローチによりすべての外部接続を標準アプリケーションに組み込むよりも優れた制御が可能になります 00:11:29.240 --> 00:11:36.920 それでも追加したアプリは日々の業務の一部となります 次のステップはスタッフが頼りにしているプロセスに組み込む前に拡張機能を慎重に確認することです 00:11:36.920 --> 00:11:42.440 アプリの検索とインストールプロセスに改善が必要だとわかったとします どこを探せば良いでしょうか 00:11:42.440 --> 00:11:50.780 ほとんどの人はマイクロソフトアップソースかビジネスセントラル内の拡張機能管理ページから始めます アップソースはマイクロソフトや他のソフトウェア企業のアプリを閲覧できるマーケットプレースです 00:11:50.780 --> 00:11:58.660 拡張機能の管理は自身のビジネスセントラル環境にすでに接続されているアプリを表示 管理する場所ですここがポイントですアプリの名前ではなく問題から始めます 00:11:58.660 --> 00:12:06.940 チームが普段使っている言葉で検索してください配送銀行取り込み承認電子請求 倉庫スキャン支払い採測あるいはローカルレポートなどを試してみましょう 00:12:06.940 --> 00:12:12.420 単純な検索を行うことで誰かが進めた最初のアプリをそのまま選ぶのではなく複数の選択肢を見つけられる可能性が高まります 00:12:12.420 --> 00:12:20.100 倉庫チームが毎午後注文詳細を配送業者のウェブサイトにコピーする作業に時間を取られていると想像してください 特定のベンダーを検索することから始めないでください 00:12:20.100 --> 00:12:28.020 代わりに配送業者小包配送ラベル印刷または出荷追跡で検索しましょう そして表示されたアプリをチームが完了させる必要のある実際の業務と照らし合わせて比較します 00:12:28.020 --> 00:12:35.240 次に説明をゆっくりと読みますまず発行元を確認してください 誰がそのアプリを作成したのでしょうかそしてサポートの詳細はどこで確認できますか 00:12:35.240 --> 00:12:43.060 アプリは短い説明文だけでは完璧に見えるかもしれませんが出荷ラベルが印刷できなかったり アップデートによってチームが毎日使うプロセスが変わったりした時に誰が対応してくれるのかを知っておく必要があります 00:12:43.060 --> 00:12:51.100 次にそのアプリがどのバージョンのビジネスセントラルをサポートしているかを確認してください お使いの企業がビジネスセントラルのオンライン版を利用しているか自社サーバーで運用しているかを確認してください 00:12:51.100 --> 00:12:58.140 アプリがその環境に対応している必要があります すべてのアプリがどこでも動くと考えるのではなくアプリの説明や発行元のドキュメントを必ず確認してください 00:12:58.140 --> 00:13:05.900 価格設定も注意深く見る必要があります ユーザー数に応じて課金されるアプリもあります企業単位や取引単位あるいは月額サブスクリプションで課金されるものもあります 00:13:05.900 --> 00:13:13.940 インストールは無料でも有料の外部サービスに接続するものもあります 例えば銀行接続用アプリならアプリ発行元銀行あるいはその両方から料金が発生する場合があります 00:13:13.940 --> 00:13:20.780 無料であっても確認を怠らないでください 無料アプリでも特定の課題を非常にうまく解決できるものがありますその一方でサポートが少なかったり 00:13:20.780 --> 00:13:28.900 ドキュメントが不足していたり機能が限定的だったりすることもあります アプリに含まれる機能含まれない機能そしてアップデートやサポートの仕組みが説明されているかを確認してください 00:13:28.900 --> 00:13:37.560 インストール前にドキュメントを探してください 優れたドキュメントにはアプリの機能設定前の要件変更されるビジネスセントラルのページそしてユーザーの操作方法が説明されています 00:13:37.560 --> 00:13:47.340 教科書のように読みにくいものである必要はありません しかし注文請求書支払いに関わる業務プロセスの明確な設定手順が見つかる場合は立ち止まって確認してください 00:13:47.340 --> 00:13:55.360 レビューは参考になりますが慎重に読みましょう 他国の企業による欲しい5つのレビューが現地の報告規則に準拠しているかどうかを保証するとは限りません 00:13:55.360 --> 00:14:02.380 低評価のレビューは発行元がすでに修正済みの問題を指摘しているかもしれません レビューは最終的な結論ではなく調査すべき疑問点として扱いましょう 00:14:02.380 --> 00:14:08.860 候補を絞り込んだらサンドボックス環境でアプリをテストします サンドボックスとはテスト用に分離されたビジネスセントラル環境のことです 00:14:08.860 --> 00:14:15.280 チームが安全にアプリをインストールし設定を試し実際の業務データに影響を与えずに通常のビジネスフローを実行できます 00:14:15.280 --> 00:14:22.480 実際のケースを想定してテストしてください 顧客商品税ルール配送方法など普段トラブルになりやすい条件でサンプル注文を作成します 00:14:22.480 --> 00:14:30.940 実際にその業務を担当する人にアプリを試してもらってください 管理者が書類上で承認しても注文入力担当者は数分で入力項目の欠落や不要なステップに気づくものです 00:14:30.940 --> 00:14:36.400 面倒なケースもテストしてください 住所が不完全な場合はどうなりますか支払いに失敗した場合はどうなりますか 00:14:36.400 --> 00:14:42.180 ユーザーは開発者に連絡せずにミスを修正できますか 顧客から翌月にコピーが必要だと言われた際アプリは正しいレポートを作成できますか 00:14:42.180 --> 00:14:48.600 そうした問いかけの方が磨き上げられた製品ページよりも多くのことを教えてくれます アプリを日常業務に導入する前に誰がサポートを担当するかを決定してください 00:14:48.600 --> 00:14:54.020 社内のitチームが最初の問い合わせに対応すると良いでしょう ビジネスセントラルのパートナーがセットアップや修正を担当する場合があります 00:14:54.020 --> 00:15:00.680 アプリの公開元が自社コード内の問題を処理する場合があります サポート窓口やapowtmの目的とともにそれらを書き留めておいてください 00:15:00.680 --> 00:15:11.100 インストールされたアプリは業務プロセスの一部となります つまり次に検討すべき質問はそのアプリがアクセスできる情報その情報の移動先そしてビジネスセントラルやアプリが変更された時にどうなるかについてです 00:15:11.100 --> 00:15:16.680 セキュリティデータと更新に関する質問です 拡張機能を承認する前にシンプルな質問をしてみましょう 00:15:16.680 --> 00:15:26.300 このアプリはどのような情報を閲覧変更または他へ送信できるのでしょうか 拡張機能はチームが顧客注文請求書支払い在庫のために使用する業務フローの中に組み込まれる可能性があるためこの質問は重要です 00:15:26.300 --> 00:15:33.460 フィールドやレポートを追加するだけのアプリもあります 一方でビジネスセントラルを外部サービスに接続し業務の一環としてビジネスデータをやり取りするものもあります 00:15:33.460 --> 00:15:38.140 すべてのアプリがビジネスセントラルと同じですとコンプライアンスセキュリティ基準に従っているわけではありません 00:15:38.140 --> 00:15:43.900 マイクロソフトのドキュメントには他社提供アプリについて明記されています アプリが他のオンラインサービスに接続する可能性があります 00:15:43.900 --> 00:15:49.960 組織や選択した地理的リージョンコンプライアンス協会の外部でデータを処理または保存する可能性があります 00:15:49.960 --> 00:15:56.420 他社とデータを共有したり ai 機能を搭載したり自社のポリシーに合わないコンテンツを表示したりする場合があります 00:15:56.420 --> 00:16:05.840 そのためインストールボタンを押すことを小さな選択だと思わないでください 具体的な例を挙げます請求書データを外部のドキュメントサービスに送信するアプリを想像してください 00:16:05.840 --> 00:16:11.700 そのアプリはタスクを遂行するために顧客名住所商品詳細価格税データ 伝票番号を必要とするかもしれません 00:16:11.700 --> 00:16:17.560 プロセスには最適かもしれませんが財務責任者 it チームプライバシー管理担当者はデータがどこへ行き誰がそれを扱うのかを知っておく必要があります 00:16:17.560 --> 00:16:22.340 発行元に対しデータパスを平易な言葉で説明するよう求めてください どのデータがビジネスセントラルから外部へ送信されますか 00:16:22.340 --> 00:16:27.460 そのデータはどこへ行きますかどの国や地域に保存されますか アプリはコピーを保持しますかまたその期間はどれくらいですか 00:16:27.460 --> 00:16:35.120 発行元や他のサービスプロバイダーはそのデータにアクセスできますか アプリが ai を使用している場合どのような情報が ai サービスに送られますかそしてその情報はその後どうなりますか 00:16:35.120 --> 00:16:42.060 インストールする前にプライバシー詳細と規約を読んでください 弁護士になる必要はありませんが自社が扱うデータについては明確な回答を得る必要があります 00:16:42.060 --> 00:16:49.320 ベンダーがアプリによる情報処理について説明できない場合は顧客記録や財務データを扱う業務 プロセスにそのアプリを組み込まないでください 00:16:49.320 --> 00:16:57.400 権限の設定にも同様の注意が必要です アプリには販売注文の読み取り出荷の作成支払いの転記あるいは新機能で使用するレコードへのアクセスの権限が必要な場合があります 00:16:57.400 --> 00:17:02.640 業務に必要な最低限のアクセス権のみを付与してください 次にどのユーザーにアプリの権限セットを付与するかを確認してください 00:17:02.640 --> 00:17:09.640 便利な新機能であっても使用すべきでないユーザーにまで届いてしまうとセキュリティ問題を引き起こす可能性があるからです 独自の承認プロセスを必ず減るようにしてください 00:17:09.640 --> 00:17:18.580 ある部門が役立つアプリを見つけすぐに導入したいと考えるかもしれません そのアプリが機密性の高い業務を扱う場合まずはIT財務セキュリティコンプライアンスの担当者に確認させてください 00:17:18.580 --> 00:17:25.720 最初は時間がかかるように感じるかもしれませんが後になって顧客データが許可されていない場所に流出したと知るよりはるかにマシです アップデートにも注意が必要です 00:17:25.720 --> 00:17:37.340 拡張機能を使えばカスタムコードを標準のビジネスセントラルアプリから分離できるため 直接コードを変更する際のような修正作業を減らせますがそれでも拡張機能はビジネスセントラルの機能や他のアプリまたは外部サービスに依存している場合があります 00:17:37.340 --> 00:17:43.460 一部が変更されるとその接続部分のテストが必要になることがあります インストールされているすべての拡張機能の簡単な記録を保管してください 00:17:43.460 --> 00:17:54.900 名前発行元目的所有者サポート連絡先権限外部サービスおよび依存している他のアプリを書き留めておきましょう アップデートが近づいたときそのリストがあれば何をテストすべきかが分かりチームがどのプロセスが壊れるかを推測する必要がなくなります 00:17:54.900 --> 00:18:00.740 少ない方が良いことも多いです アプリのリストが長すぎると機能の重複や所有権の不明確さを招きテスト項目も増えてしまいます 00:18:00.740 --> 00:18:07.200 真のビジネスニーズを満たす拡張機能だけを残しましょう ニーズがなくなったら削除または廃止し実行前に何が変更されるかを記録してください 00:18:13.460 --> 00:18:22.520 ワークすることです皆さんこれは日々の作業です 結論適切なアドオンを選びましょうシンプルなルールを紹介しますビジネスセントラルの拡張機能は 00:18:22.520 --> 00:18:30.180 コアコードに触れることなく一つの特定の問題を解決するものであるべきです チームが直面している実際の課題から始めましょう実際の業務でアドオンをテストしてください 00:18:30.180 --> 00:18:39.860 誰が作成したかデータがどこへ行くかを確認しインストール後も誰かがサポートしてくれることを確実にしましょう チャンネル登録をしてデフォルト画面をすべて受け入れる必要があるとまだ信じている人にこの知識の欠片を共有してください