ユーザー サポート: 継続的な本番ソリューションのサポート
次のセクションでは、アプリ、フロー、チャット ボットなどの Microsoft Power Platform ソリューションのユーザーをサポートする公式およびカジュアルな方法について説明します。
この図は、組織が成功している共通のサポートと卒業の枠組みを示しています:
| 型 | 内容 |
|---|---|
 |
セルフサポート (内部)メーカーが独自のソリューションをサポートしている場合に発生します。 ユーザーはメーカーのサポートを受けることを分かっていますが、メーカーが提供するサポートのレベルについては、IT部門 やチームには見えていない場合が多く見られます。 |
 |
チーム支援サポート (内部) は、チームメンバーがお互いに学び合いながら、Power Platform のソリューションを開発する際に発生します。 チーム メンバーは、チームのアプリ、フロー、チャットボットの共同所有者となります。 共同所有者は、ユーザーからの問い合わせをサポートし、小さなバグ修正や変更を行うことができます。 チームによるサポートは非公式に行われることもありますが、採用と成長が進むにつれて、このプロセスを公式化することをお勧めします。 |
 |
ヘルプ デスク サポート (内部)は、正式なサポートの問題やリクエストを処理します。 ヘルプデスクでは、モバイル デバイス上のアプリへのアクセス方法や、バックエンドのデータソースへのアクセスを要求する方法などの質問に対応することができます。 ソリューション関連の質問は、ソリューションをサポートするチャネルにリダイレクトされます。 |
 |
専用 Power Platform サポート (内部) ヘルプデスクによってエスカレーションされた複雑な問題の処理が含まれます。 重要性の高いアプリケーションはこのチームに引き渡され、バグ修正を展開できます。 |
 |
パートナー サポート (外部) は、重要なアプリケーションをサポートしたり、特定の部署と協力してアプリケーションをサポートしたりすることで、社内のサポートサービスを補完することができます。 詳細情報: Power Apps パートナーから専門家のヘルプを得る |
 |
Microsoft サポート (外部) プラットフォーム関連の技術的な問題を提起するために使用できます。 ご利用のサポート プランに応じて、さまざまなテクニカル サポートやアドバイザリー サービスをご利用いただけます。 詳細情報: Microsoft Power Platform のサポート |
組織の規模や、ロー コードやプロ コード技術の既存の提供方法に応じて、サポートを公式化する方法を選択することができます。 Power Platform の採用方法が分散型であれば、組織全体で自律的なチームが Power Platform のソリューションを提供し、管理することになります。 このモデルでは、サポートが委譲されることもあり、チームによるサポートがユーザーやメーカーにとって最も適切なサービスとなることもあります。
Power Platform 採用のアプローチが一元化されているものであれば、組織の部門の各部門のソリューションをローコードで提供するプロダクトオーナーの中央チームがあります。 このモデルでは、サポートも一元化され、中央のサポート チームが問い合わせや質問に答えます。
ほとんどの組織では、複数の配信モデルを組み合わせて使用するのが最適です。分散したチームが各メーカーのソリューションをサポートした場合でも、技術的な問題やエンドユーザーからの問い合わせ、第一階層のサポートのために、ヘルプデスクや中央のサポートチームが必要となる場合があります。
アプリケーションの層を定義する
サポート プロセスとエスカレーション パスを定義する際には、重要度に基づいて構築されたソリューションを分類することが重要です。これにより、重要なアプリケーションをサポートするために必要なガードレールを確保すると同時に、生産性向上のためのイノベーションを阻害しないようなプロセスを検討することができます。
| 特徴とプロセス | 生産性 | 重要 | 重大 |
|---|---|---|---|
| ユース ケース | 既存のデータを使用する可能性のある個人の生産性と小規模なチームのユース ケース。 | 単純なビジネス アプリケーションまたはチーム イニシアチブ。 小規模なスタンドアロンのコラボレーション プロセス | 複雑なビジネス アプリケーション、全社的な取り組み、またはミッションクリティカルなワークロードで、ダウンタイム時にビジネスに大きな影響を与えるもの。 |
| 複雑性 | シンプルなプロセス。 | 中程度の複雑さ。 | 非常に複雑。 |
| ユーザー ベース | 小規模なユーザー ベース – 個人ユーザー、直接の同僚、または小規模なチーム。 | 部署へのスコープ。 | 大規模なユーザーベース、または企業全体での使用。 |
| 開発ライフサイクル | 高レベルの反復。 | 開発期間は通常 3 ヶ月以内。 | より長い開発サイクル。 |
| 影響 | ビジネスへの影響度が低い。 | 重要だがビジネス クリティカルではない (中程度の影響)。 | ビジネスへの影響度が高い。 |
| ALM | ALM 必要なし。 | ALM が必要です – 手動のソリューションのインポート/エクスポートによって実現できます。 | 堅牢な ALM プロセスが必要 - ALM は、Azure DevOps や GitHub のパイプラインを使って実現しています。 |
| 環境戦略 | ソリューションは、既定または共有の生産性環境に組み込まれています。 | 専用の開発環境、および共有のテスト環境と本番環境 (部署別など、他のソリューションと共有)。 環境は、部署 (分散型) または中央 IT (一元管理) によって管理されます。 | 専用の開発/テスト/製品環境。 環境は中央 IT によって管理されます。 |
| 作成者のアクセス許可 | 作成者は環境作成者のセキュリティ ロールを持っています。 | 作成者は、開発環境では環境作成者、またはシステム カスタマイザーのセキュリティ ロールを持ちますが、テスト環境や本番環境ではエンド ユーザーのセキュリティ ロールしかありません。 ソリューションの所有者は、テストおよび本番環境では、サービス アカウントまたは環境管理者となります。 | メーカーは、開発環境では環境作成者、またはシステム カスタマイザーのセキュリティ ロールを持ちますが、テスト環境や本番環境ではユーザーのセキュリティ ロールしかありません。 ソリューションの展開は自動的に行われ、ソリューションはテストおよび本番環境においてサービス プリンシパルによって所有されます。 |
| IT の関与 | リアクティブ ガバナンス – IT は、構築されているソリューションを可視化し、使用状況を監視します。 | ソリューションやユーザー レベルでの IT の恩恵。 メーカーは、潜在的な回避策や使用したデータソースなど、ソリューションの詳細を提供します。 | 運用環境は IT によって管理されます。 |
| サポート モデル | セルフサポート。 | チーム支援サポート。 | 正式サポート。 |
最初は生産性レベルのサポートしか必要としないソリューションでも、機能やユーザー数が増えれば重要なレベルのサポートが必要になるなど、サポートモデルを定義する際には、卒業パスについても検討してください。 作成者がより正式なサポートを要求し、ソリューションをサポートされる環境に移行する方法を定義します。
上記で紹介した各タイプのユーザー サポートについては、この記事でさらに詳しく説明します。
メーカー サポート (セルフサポート)
メーカーサポートとは、メーカーが自分や自分のチーム、同僚のために作ったアプリやフローをサポートすることです。 これは、ユーザーからの問い合わせに答えたり、バグを修正したり、変更要求をしたりすることを意味します。 これは非公式なサポート方法で、多くのユーザーはメーカーが誰であるかを知っていて、彼らに直接連絡を取ることになります。
重要
新しい作成者を迎え入れる際には、作成者がサポート、卒業、エスカレーション パスを認識していることを確認してください。ビジネスに重要なソリューションのサポートに圧倒された作成者は、新しいソリューションを革新して作成することができなくなります。 作成者がどのようにして自社のソリューションを卒業し、次のレベルのサポートを受けることができるのか、それはどのようなものなのかを明確に定義します。
このように、メーカーにプロセスを伝えるプロアクティブな方法に加えて、リアクティブなガバナンスを導入して、ビジネスにとって重要と思われる共有率の高いソリューションや使用率の高いソリューションを特定し、メーカーに連絡して、必要なサポートのガードレールがあるかどうかを確認します。 テナントレベルの分析を使用してアプリケーションの使用状況を確認したり、テレメトリを独自のデータ ストレージ アカウントにエクスポートして独自の拡張レポートを作成したり、 CoE スターター キット出発点として使用したりすることができます。
チーム支援サポート
チーム支援型サポートとは、チームのメンバーが、自分のチームのために作られた/自分のチームが使用するアプリやフローの共同オーナーシップを持ち、日常業務の中でソリューションのサポートを行うことを指します。 これは、ユーザーからの問い合わせに答えたり、バグを修正したり、変更要求をしたりすることを意味します。 擁護を得た作成者は、このような非公式なサポートを自発的に行う傾向があり、これは、助けたいという本質的な欲求があるためです。
最初は非公式なプロセスとして始まることが多いですが、多くの組織では、Power Platform の取り組みを拡大するために、チームによるサポートを正式に行っています。 これは、部署が専用の環境を所有し、環境管理者の役割を担い、それらの環境でソリューションをサポートすることを意味します。 大企業では、部署ごとに専任の Power Platform チームがこの役割を担っています。
ヘルプ デスク サポート
ヘルプデスクは、IT 部門の共有サービスとして運営されています。
ヘルプ デスク サポートでできること:
- IT 部門が関与しないと解決できない技術的な問題をサポートします。たとえば、Power Platform サービスの問題では、管理者がPower Platform 管理センターでサポートチケットを上げる必要があります。
- アプリケーションへのアクセスをどのように要求するか、どこにアプリケーションがあるかなど、ユーザーやガバナンスに関連する質問に回答します。
- 重要なアプリケーションの問題を、適切なサポートチームに転送します。
専用 Power Platform サポート チーム
お客様の導入が進み、作成者がよりビジネスに重要で重要なソリューションを開発するようになると、専用の Power Platform サポートチームが必要になるかもしれません。
このチームは、複雑な問題をサポートできる Power Platform の技術専門家で構成する必要があります。 このチームをサポート プロセスに参加させるには、サポート チケットを介して定義されたパスを通る必要があります。
このチームは、中央でサポートされている専用環境に展開されるミッション クリティカルな Power Platform リューションをサポートします。
組織構造が分散している場合は、チームによるサポートを正式なものにして、ローカルの地域や部署に合わせ、中央の Power Platform サポートチームは複雑な問い合わせや DLP ポリシーなどの中央構成のみを支援することを検討するとよいでしょう。
顧客によっては、このレベルのサポートをパートナーに委託する場合もあります。
ヘルプデスクからの純粋なエスカレーション パスとしてリクエストを管理することは、これらの Power Platform 技術専門家がしばしばビジネス ユーザーに知られているため、実施することは困難です。 適切なチャネルを経由する習慣をつけるために、このチームはユーザーにヘルプデスクのチケットを提出するように指示する必要があります。 また、ヘルプデスクのリクエストを分析するためのデータの質も向上します。
パートナー サポート
多くの顧客は、サポートを含めた Power Platform の導入をパートナーと一緒に行うことを選択されます。 これには、作成者向けの開発支援、CoE や技術サポート手順の確立の支援、重要なアプリケーションに対する 24 時間 365 日のテクニカル サポートなどが含まれます。
Microsoft サポート
プラットフォームに関する技術的な問題については、Microsoft サポートを利用しています。 サポートプランに応じて、さまざまなテクニカル サポートやアドバイザリー サービスをご利用いただけます。
チップ
サポートチケットを発行する前に、すべての顧客に広く影響する優先度の高い問題については、Power Apps サポート、Power Automate サポート、Power Virtual Agents サポートも確認してください。
検討事項と主要なアクション
自分自身やチームでサポートするソリューションを向上させるための考察と重要なアクション:
- 作成者に認識と評価を提供します。
- 作成者は、ソリューションを卒業してより正式なサポートチャネルに移行するための卒業プロセスを認識していることを確認します。
- メーカーが継続的にスキルアップできるように、オフィスアワー、メンターの機会、トレーニング セッションを提供します。
- 行き詰った作成者が、Power Platform の技術者に連絡するためのエスカレーションパスを提供します。
- ユーザーがヘルプデスクに問い合わせをするためのフォームなど、メーカーがアプリに組み込むためのテンプレートのコンポーネントを作成します。
- 特定のビジネス領域でサポートを必要とするワークロードとソリューションの数に基づいて、チームによる支援を正式に行うことを評価します。
内部のヘルプデスクサポートを改善するための検討事項と重要なアクション:
- ヘルプデスクが扱う Power Platform トピックの初期範囲を決定します。
- ヘルプデスクがサポートに対応できるレベルを評価する。
- ヘルプデスクのスタッフの準備状況に応じて、より多くのトレーニングを受けることができます。
- ヘルプデスクが直接対応できないリクエストに対して、どのようなエスカレーション パスを設定するかを決定します。
- ヘルプデスクの知識ベースに、既知の Power Platform トピックを更新します。 新機能や拡張機能を反映したナレッジベースの定期的な更新に責任を持つ人を確保する。 Power Apps ブログ、Power Automate ブログPower Virtual Agents ブログ RSS フィードを購読して最新情報を入手してください。
- 優れた問題追跡システムが導入されていることを確認します。 多くの場合、優先度を管理できるチケットシステムです。
- Power Platform に関する問題が発生した場合、誰がオンコールで対応するかを決定します。 必要に応じて、24 時間 365 日のサポートに対する期待が明確であることを確認してください。
- どのような SLA が存在するかを決定し、応答と解決に対する期待が明確に伝えられていることを確認します。
- 特定の一般的な問題に素早く対処できるように準備しておく。 たとえば、新しいコネクターを使いたいという要望には、迅速に対応する必要があります。 サポートの対応が遅いため、ユーザーが回避策を見つけてしまう可能性がある。
- ヘルプデスクが マイクロソフトのサポートチケットを発行できるセキュリティ ロールを持っていることを確認してください。 ヘルプデスクまたは専任のサポートチームがこれらの問題を優先順位付けするかどうかを決定します。
社内の Power Platform 専用サポートを改善するための検討事項と重要なアクション:
- ヘルプデスクの担当範囲と、専任サポートの担当範囲を明確に定義します。
- Power Platform 専門のサポートチームが Microsoft 365 と Azure のグローバル管理者に直接届くエスカレーション パスを持っていることを確認します。 Power Platform の範囲を超えた広範な問題が発生したときには重要です。 このような問題は、ユーザー アカウントや権限、ネットワーク構成、Power Platform ソリューションで使用されているデータソースなどに関連している可能性があります。
- 専任のサポートチームからヘルプデスクへのフィードバック ループを作り、IT ナレッジベースを更新できるようにします。 目標は、プライマリー ヘルプデスクが、将来的にはより多くの問題に対応できるよう、継続的に能力を高めていくことです。
- ヘルプデスクから専任のサポートチームへのフィードバック ループを作成します。 サポート担当者が冗長性や非効率性を発見した場合、その情報を専任のサポートチームに伝えることができ、サポートチームは内部プロセスの変更や改善を選択することができます。 例: ヘルプデスクが作成者の新しい Power Platform 環境の作成と設定に追われている場合、専任チームは CoE Starter Kit の環境要求管理コンポーネント を使ってこのプロセスを自動化することを検討するかもしれません。
- ソリューションをサポートする個人やチームから専任のサポート チームへのエスカレーション パスを作成し、自分たちで解決できない問題に直面したときにブロックを解除できるようにします。
- 重要なアプリケーションが移行できるように、ソリューションをサポートしている個人やチームから専任のサポートチームへの引き継ぎパスを作成します。
- ソリューションを専任チームに移行するための全体的な戦略を決定します。重要なソリューションやクリティカルなソリューションの数が増えるにともなって、専任のサポートチームの人員を増やしますか、それともビジネスユニットがそれぞれのエリアのサポートチームの人員を確保しますか？