メモ
Dynamics 365 Commerce の小売業界グループは、Yammer から Viva Engage に移行しました。 新しい Viva Engage コミュニティにアクセスできない場合は、このフォーム (https://aka.ms/JoinD365commerceVivaEngageCommunity) に入力して追加し、最新のディスカッションに参加してください。
この記事では、Microsoft Dynamics 365 Commerce 環境でのデバイス管理機能の概要について説明します。 実装を計画する際に考慮する必要がある実装上のヒントとガイダンスを示します。
デバイスは、販売時点管理 (POS) アプリケーションをインストール、構成、および使用して、そのデバイスを所有するビジネスで必要な操作を実行したり、支援したりするための機器です。 つまり、デバイスは、業務を実行するために POS アプリケーションを実行する 1 つのテクノロジです。 この業務は、専らコマース操作である必要はありません。 たとえば、病院にはギフト ショップがあり、倉庫は在庫を管理し、法律事務所が請求書を生成します。 重要なのは、デバイスが実行するアプリケーションによって、ビジネス操作がよりシンプルになり、効率的になり、管理と記録が向上することです。 使用されているシナリオに関係なく、デバイスは重要な要素です。 使用されるデバイスの数が増えるにつれて、それらのデバイスを追跡および管理するためのプロセスを配置する価値が高くなります。 これらのプロセスはまとめて デバイス管理 として知られています。
この記事で説明する POS アプリケーションは、Microsoft Dynamics 365 Commerce の Store Commerce アプリです。 ユーザーは Store Commerce アプリで、迅速、シンプル、効率的に業務の執行を完了できます。 また、組織が業務全体で Store Commerce アプリを実行する数多くのデバイスを管理するのにも役立ちます。 この記事では Store Commerce アプリ デバイスの多くの側面について説明しますが、2 つの重要な側面は、ビジネス指向の レジ と デバイス の物理的な概念です。
レジ ページは、Store Commerce アプリ インスタンスのビジネス指向の詳細に対する、仮想追跡メカニズムです。 これらの詳細には、レジスタが使用するビジュアル プロファイル、自動サインアウト時間、およびレジスタが含まれるストアが含まれます。 これらすべての詳細は仮想レジスターに格納されます。 レジスタを正しく設定して構成すると、それを仮想デバイスにリンクします。
デバイス ページは、デバイスの物理的な概念の仮想追跡メカニズムです。 ビジネス指向レジスタをリンクして構成を完了し、インストールの準備をします。 仮想デバイスには、検証状態、POS アプリケーションがアクティブ化されたとき、インストールしたバージョン、現在インストールされているバージョンなどの詳細が格納されます。
より多くのレジスタを生成し、適切なデバイスにリンクすると、物理と仮想の両方の管理が非常に重要になります。 たとえば、ビジネスには、Store Commerce アプリを実行する Microsoft Surface デバイスという 1 つの物理デバイスがあります。 ドメイン上にある場合や、そのビジネスに固有の追加ソフトウェアが必要な場合があるため、Surface を構成する必要があります。 また、ビジネスは、Surface デバイスに Store Commerce アプリをインストールしてアクティブ化する必要もあります。 時間の経過と共に、デバイスの修理または交換が必要になったり、盗難の可能性もあります。 企業がデバイスを 1 つだけ持っているのではなく、数十、数百、または数千もの場合、ビジネスはすべてのデバイスの状態を適切に監視、管理、検証するためにプロセスを配置する必要があります。 これらのデバイスには、現在使用されているデバイスと現在使用されていないデバイスの両方が含まれます。
コマースは既に、デバイス管理の基本要求を提供しています。 実装を計画するときは、痛みを最小限に抑え、利点を最大限に高めるために、すべての適切な考慮事項を必ず考慮してください。
実装の考慮事項
このセクションでは、小売店や配送場所でのデバイス管理に関連する機能を実装する際に考慮すべき事項について説明します。
物理的トポロジを生成します
計画は、エンタープライズ リソース プランニング (ERP) ソリューションの実装を成功させるために最も重要な要件です。 この計画の主な成果物の 1 つは、物理的なトポロジである必要があります。 物理トポロジは、最下位の POS デバイスから本社の最上位のネットワーク接続までの、会社の多くの詳細の視覚化です。 少なくとも、次の成果物を完了します。
店舗 テンプレート – 店舗テンプレートは、ブリック アンド モルタル店舗などの物理的な場所のレイアウトを示す 1 つ以上の図面で構成されています。 長期的には、これらの図は、将来の場所を簡単に実装し、検出された問題を修正または改善する方法をすばやく評価するのに役立ちます。 ストア テンプレートには、次の詳細が含まれている必要があります。
- 場所 – 場所の物理的な配置。 詳細には、その場所に存在するすべてのデバイスの位置が含まれます。
- ネットワーク – ネットワーク インフラストラクチャの内部レイアウトと、インターネット接続に関する詳細 (帯域幅の上下、スレッド数、本社またはその他の重要なインターネットの場所への待機時間など)。
- デバイス - 場所に存在するすべてのデバイスの詳細。 これらの詳細には、デバイスの仕様や、デバイスの詳細をすばやく見つけることができる関連タグのタイプが含まれます。
- 周辺機器 – デバイスに接続されているすべての周辺機器のリスト、周辺機器の数、すべての周辺機器の物理的な位置。 多くの場合、詳細をすばやく見つけることができる関連付けられたタグも必要です。
名前付け方法 – すべての実装について、すべてのデバイスで名前付け規則を維持します。 名前付け規則を決定するルールを生成し、これらの規則に従います。
メモ
名前付け方法を生成するときは、レジスタとデバイスに同じ名前または非常によく似た名前を使用します。 デバイスと、レジスタが動作する物理コンピューターのフレンドリ名と同じまたはよく似た名前を使用します。
手順計画 – ビジネスの成長に合わせて、ビジネスを効率的に実行できるように、十分な順序を維持するために手順を維持することが重要です。 計画は、頻繁に維持して追加する必要がある、生きたドキュメントと考えてください。 このプランでは、会社を構成する店舗で繰り返されるほぼすべてのアクションを実行する方法について説明する必要があります。
サービス計画 – ビジネスが継続するにつれて、サービスの重要性が増します。 デバイスを交換するタイミング、デバイスと周辺機器 (アプリケーションとオペレーティング システムの両方) を更新するタイミング、およびこれらのタスクを実行する方法を決定します。 回答はビジネスによって異なりますが、これらのタスクを計画します。
災害計画 – 問題が発生する可能性がある場合は、計画します。 計画が進行するにつれて、リスクと潜在的な軽減策を記録します。 疑わしい状態を修正する方法を説明する計画を生成します。
計画が完了し、すべての潜在的な詳細がわかったら、ストアの一覧と、各ストアに関連付けられているレジスタとデバイスの一覧が表示されます。 次に答える必要がある質問は、一覧表示されているすべてのデバイスを展開する方法です。
分散配置
デバイスの数が数百または数千にまで増えるにつれて、POS アプリケーションの手動構成、インストール、アクティブ化は、すぐに実用的になりません。 この問題を軽減し、大規模なデバイスを管理するには、次の概念を使用します。
- デバイス ページ - MPOS を使用すると、デバイスの詳細を示すページには、デバイス上で使用する必要がある POS クライアントに関する情報が含まれます。 レジスター パッケージ 小見出しの下には、4 つのフィールドがあります。 最初の 3 つのフィールド (パッケージ名、パッケージの説明、バージョン番号) は、現在または後でデバイスにインストールする必要がある MPOS パッケージのバージョンに関する情報を提供します。 4 番目のフィールドには、現在インストールされている MPOS のバージョンが表示されます。 したがって、どのデバイスでもこの情報を簡単に見つけることができます。
- チャンネル配置ワークスペース - このワークスペースを使用すると、大規模でフィルター設定可能な一連の店舗、レジスター、デバイスなどをすばやく表示できます。 このワークスペースには、大規模な展開のオプションも用意されています。 詳細については、「 Modern POS (MPOS) の顧客注文」を参照してください。 このワークスペースを使用すると、重要なページにすばやくアクセスでき、展開中に状態チェックを実行するときの検証時間を短縮し、デバイスの状態を効率的に管理できます。
- 一括配置 – MPOS およびその他のクライアント側コンポーネントを使用する Dynamics 365 の顧客は、インストール、コンフィギュレーション、およびサービスを支援するさまざまなアクションをサイレントで実行できます。 コマンド プロンプトで基本的なコマンドを実行すると、コマース コンポーネントを配置してサービスする (つまり、更新する) ことができます。 インストーラーの手動ユーザー インターフェイスをスキップするこの基本的な方法は、インストールおよびサービスに必要な時間を短縮できます。 ログ ファイルは同じままであり、インストールの詳細を表示することができます。
- スクリプティング – 一括展開機能に基づいて、スクリプトを生成し、Store Commerce アプリなどのコマース コンポーネントをインストールまたは更新するために自動的に実行されるように設定します。 これらの基本スクリプトを、デバイス上のスケジュールされたタスクとして入力します。 その後、タスクは所定の時間に実行され、ログと結果を所定の場所に返します。ここで、時間が許すとおりに表示できます。
- システム管理ソリューション – システム管理ソリューションは、使用されているデバイスに関する既知のデータ量を増やすのに役立ちます。 また、そのデータを取得するために必要な時間を短縮することもできます。 システム管理ソリューションの例には、Microsoft System Center および Microsoft InTune が含まれます。 一括配置とスクリプトと共にシステム管理ソリューションを使用することで、コンポーネントをより迅速に設定およびインストールすることができます。 さらに、配置または処理後のステータスをより効率的に検証できます。 Microsoft は、System Center Configuration Manager 経由でのデバイス管理に関する具体的なドキュメントである System Center Configuration Manager のデバイス管理ソリューションの選択を発行しました。
デバイスの保守
デプロイは多くの違いを持つ重要なプロセスですが、ビジネスの継続的な性質上、早期にサービスを検討し、計画する必要があります。 サービスを早期に検討することで、サービスが必要になるたびに効率と完了の速度を最大化できます。 サービスは、アプリケーションがサービスを必要とするだけでなく、オペレーティング システムと周辺機器にも更新プログラムが必要になる場合があることを理解すると、さらに重要になります。 前述のように、このプロセスは、デバイスの交換時にさらに困難になる可能性があります。 一般に、次の要素をすべて考慮してください。
デバイス – デバイスにサービスを提供するプロセスには、サービスが完了したかどうかを判断するだけではありません。 代わりに、個別に、またはデバイスのグループの一部として、同時にデバイスのさまざまな側面を確認して更新します。
- Dynamics 365 バックオフィスのデバイス ページ、またはチャンネル配置ワークスペースの情報は、Hardware Station または Commerce Scale Unit のような、MPOS または他のセルフサービス コンポーネントの現在のステータスとバージョンを検証するのに役立ちます。
- Microsoft Windows のバージョンがわかっている場合は非常に便利です。 システム管理ソリューションが使用されていないシナリオでは、コマンド プロンプト ウィンドウで winver コマンドを使用して現在インストールされている Windows の特定のバージョンをすぐに確認できます。 Windows のバージョン リストと照らしてバージョン番号を比較することにより、サービス パック レベルでコンピューターの更新に不足しているものが何かを容易に理解できます。
- 内部および周辺機器ドライバーもバージョンの更新を確認する必要があります。 この記事で前述したように、計画フェーズ中にストア テンプレートの一部として作成したデバイスと周辺機器の一覧に、この情報を含め、監視します。
- 常にコンピューターがサービス (保証またはサービス プラン) を停止した場合に追跡します。 この方法で、サービス(保証またはサービスプラン)に出さずに、いつコンピューターを交換する必要があるかをすばやく決めることができます。
周辺機器 – デバイスまたはネットワークに接続されている周辺機器を監視します。 このプロセスの一環として、ネットワーク デバイス自体も監視する必要があります。 (ルーター、スイッチ、ファイアウォール、およびその他のすべてのネットワーク デバイスには、セキュリティと互換性を維持し、サービス条件に準拠するために、時折更新が必要なファームウェアもあります)。適切な計画が発生した場合、サービスの日付を監視し、周辺機器を正しく更新するプロセスは、デバイス管理の大規模なサービス フロー内で簡略化されたタスクになる必要があります。
交換 – 最終的には、デバイスと周辺機器が失敗するか、サービスが十分ではないポイントに到達します。 一般に、この状況が発生する前に、交換システムを準備しておく必要があります。 計画フェーズ中に作成した手順とサービス計画に基づいて、このプロセスは非常に迅速かつ効率的に行うことができます。 Store Commerce アプリを実行するデバイスの場合、将来の使用に備えて交換用デバイスをあらかじめ準備し、ビジネスに最も適した方法に応じてStore Commerce アプリをインストールできます。デバイスを現場に送るか、現場で保管するかは、ビジネスのニーズに最も合った方法で選択することができます。 交換時に Store Commerce アプリは既に有効になっているデバイスを「再アクティブ化」できます。 したがって、システムが応答を停止し、修復できないため交換する必要がある特殊なケースを処理できます。 ただし、置換が正しく最新であること、および最近サービスが提供されたことを確認する必要があります。
システム管理ソリューション – システム管理ソリューションはサービスの方法やサービスが完了する時を大幅に向上します。 これらのソリューションには、使用されているすべてのシステムを監視する遠隔測定ツールが含まれています。 これらのテレメトリ ツールと常に保存され利用可能なデバイスの情報データにより、サービスはリアクティブではなくプロアクティブになります。 この最良のシナリオでは、適切なプランが手順およびサービスに対して存在し、システムに関する警告および既知のデータによって、問題が発生して重要なタスクになる前に間もなく稼働または交換が発生することを把握できます。
最悪のシナリオ
ただし、ときには問題が生じます。 最悪のシナリオを検討し、発生した問題の解決に役立つ (計画フェーズで作成したディザスター プランに従って) 軽減計画を設定します。 コマースでは、デバイス ページは少なくともデバイス管理に役立ちます。
- 紛失または盗難にあったデバイス – デバイスが紛失または盗難にあった場合、プライベート データが悪意のある人の手にかかってしまう可能性があるため、重大な問題になります。 最初の手順は、コマース本社の [デバイス ] ページで紛失または盗難にあったデバイスを非アクティブ化して、そのデバイスへのサインインをすぐに防ぐことです。 災害計画を作成した場合は、残りのガイドラインに従って、デバイスのタグ付けに必要なすべてのタスクを完了し、すべての重要なドキュメント (保険と警察のドキュメントを含む可能性があります) を提出し、デバイスの交換とビジネスの継続に取り組みます。 適切な手順が作成された場合は、交換用のデバイスの準備が完了している必要があります。
- インフラストラクチャの問題 – ネットワーク機器に不具合が発生したり、店舗レイアウトを変更する必要があるか、店舗アップデートの一環として、デバイスがデスクトップからタブレットに変更される可能性があります。 デバイスの管理に影響を与える可能性のある問題が発生した場合、適切に対応して問題を解決することが困難な場合があります。 最良のシナリオでは、これらの問題について既に説明し、手順、サービス、およびディザスター プランに記載しました。 少なくとも、ビジネスの場所のレイアウトに影響を与える変更を行う前に、新しいレイアウトを反映するようにストア レイアウト ドキュメントを更新して、発生する驚きを減らします。 前述のように、MPOS に特に影響する問題については、再アクティブ化機能がダウンタイムを軽減するのに役立ち、変更管理に役立つ必要があります。 ネットワーク装置の停止が懸念される場合、または停止が発生した場合、Store Commerce アプリ クライアントでオフライン データベースをサポートできます。 この機能は、障害が業務に与える影響を軽減するために役立ちます。
- 障害 - 障害が発生すると、すべてが影響を受けます。 災害が環境にある場合、従業員が常に最優先される必要があります。 ただし、最終的には、内部システムの管理を処理する必要があり、それらのシステムを修復する必要があります。 ただし、単純な通知または特定の考慮事項は表示されません。 代わりに、より一般的な形で早く計画する必要があります。 どのような災害が業務に影響を与える恐れがありますか。 水や電力などの公共事業は、設備に致命的な影響を与える可能性があります。 さまざまな災害下で従業員、場所、および設備への影響をどのように緩和できますか。 その場所に格納されているデータ、およびいつどのようにバックアップしてセキュリティで保護されたかなどに留意してください。