ケース管理
適用: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012
注意
このトピックには、Microsoft Dynamics AX 2012 R2 累積更新プログラム 7 以降で追加または変更された機能に関する情報が含まれています。この情報は、AX 2012 R3 にも適用されます。詳細については、このトピックで後のセクションを参照してください。
Microsoft Dynamics Ax および Microsoft Dynamics Ax エンタープライズ ポータルのケース管理を使用して、顧客、仕入先、または作業者によって引き起こされる問題を、あるいは監査プロセスを通して発生する問題を記録、更新、追跡、フォローアップ、および解決することができます。ケースの計画、追跡、および分析を行うことで、同様の問題に使用できる効率的な解決策を作成できます。
たとえば、顧客サービス担当者または一般人事担当者がケースを作成することで、より効率的なケースの対処方法または解決方法に関する情報をナレッジ記事で検索できるようになります。ナレッジ記事の詳細については、「ナレッジ記事の保管」を参照してください。
顧客、仕入先、および作業者の問題に対してケース管理を使用できるようにするため、[ケース] フォームが、Microsoft Dynamics Ax の [ホーム] にあります。監査ケースは、他のモジュールで作成されたドキュメントに関連する場合でも、常に [コンプライアンス コントロールと内部コントロール] で管理します。
Microsoft Dynamics AX 2012 R2 の累積更新プログラム 7 の製造用の追加のケース管理機能
Microsoft Dynamics AX 2012 R2 の累積更新プログラム 7 の追加のケース管理機能は、製造会社が製品変更を文書化する役に立ちます。製品の変更に、部品表、式、および工順の変更を含むことができます。詳細については、「製品変更ケースについて」を参照してください。
セットアップ
Fabrikam 社の業務担当マネージャの Vince の要望は、顧客サービス担当者および一般人事担当者が顧客、仕入先、および従業員に関するケースを作成できるようにすることです。これらのケースのいずれかの作成を可能するには、Vince は、ケース カテゴリとケース プロセスを事前に設定しておく必要があります。
Fabrikam 社の内部監査担当者の Cassie の要望は、監査ポリシーが経費精算書に対して実行された場合に、監査ケースが自動的に生成されることです。各監査ケースには、監査ポリシー違反のグループが含まれています。
また、監査ケースの手動作成オプションも Cassie の要望です。これらのケースには、監査ポリシーの実行時に作成されたカテゴリを使用できるほか、手動で作成したケース用に特別なカテゴリを作成することもできます。
ケース プロセスとカテゴリの作成方法の詳細については、「ケース プロセスとカテゴリの作成」を参照してください。
ケースのグループ化とカテゴリ
Cassie が最初に行うことは、監査違反をケースにグループ化する方法を決めることです。既定では、特定のドキュメント タイプおよび監査ポリシー ルールに対して作成された監査違反が、個々の監査ケースにすべて含まれます。Cassie は、必要に応じて、ケースのグループ化に使用する別の基準を指定できます。監査ケースのグループ化の詳細については、「キー タスク : 監査ポリシー」を参照してください。
Vince が最初に行うべきことは、ケースに対してカテゴリを作成することです。ケース カテゴリには、同じようなケースのタイプをまとめます。たとえば、Vince が、販売、従業員の福利厚生、および配送に関するカテゴリを作成するとします。また、より詳細なレベルでケースをグループ化する子カテゴリも作成するとします。たとえば、販売カテゴリの下に、販売前の問題と販売後の問題に対する子カテゴリを追加できます。
Cassie は、手動で作成されたケースに対してカテゴリを作成するかどうかを判断できます。自動的に作成された監査ケースには、カテゴリを作成する必要はありません。
個々のケースは、1 つのケース カテゴリに割り当てる必要があります。
ケースをカテゴリ別にグループ化すると、類似問題が将来発生した際に、Fabrikam 社の従業員が、ナレッジ記事といった既知の解決策を見つけやすくなります。
プロセス
Vince と Cassie は、ケース グループとカテゴリ グループを作成した後、すべてのケースで問題の発生から解決に至るまで従う必要のあるプロセスを作成できます。たとえば、ケースの作成後 24 時間内に Fabrikam 社の従業員にケース問題を割り当てるようなプロセスを作成できます。
ケースへの対応
設定完了後、適切なアクセス許可を持つ Fabrikam 社の従業員は、問題提起と同時にケースを作成できます。ケースは、Microsoft Dynamics Ax およびエンタープライズ ポータルで作成できます。
次の表に、ケース管理の使用時に Fabrikam 社の従業員が実行できるタスクを示します。
タスク |
説明 |
---|---|
顧客、仕入先、従業員、またはビジネス ドキュメントの監査結果に対し、新しいケース レコードを作成します。 |
|
ケースに対する活動などの詳細情報を追加します。 |
|
問題が解決されたことが分かるように、未解決のケースのステータスを [クローズ済] に変更します。 |
|
問題に関するヒント、解決策、およびそのほかの重要な情報を含むナレッジ記事を作成して保存します。 |
|
ケースの解決に役立ったかどうかが分かるように、ナレッジ記事を評価します。 |
例: Fabrikam 社における民間部門の顧客に対するケース管理の使用方法
Fabrikam 社の顧客サービス担当者の Lisa が、Fabrikam 社の顧客の Lionel から電話連絡を受けます。Lionel は、Fabrikam 社が Lionel の楽器店に設置した新しいサウンド システムの音量レベルを正しく設定できずに困っています。Lisa は、Lionel に関するケースを作成し、音量というカテゴリを割り当てます。Lionel の楽器店にとっては音楽が欠かせないことを知っている Lisa は、優先順位を上げ、当日対応のサービス レベル契約 (SLA) をケースに割り当てます。また、ケース ログにケースの詳細を入力します。Lisa は、音量カテゴリに関連付けられているナレッジ記事がいくつかあり、その内の 3 件がケースの解決に役立ったとマークされていることに気づきます。
リサは、それぞれの記事を開き、解決策を Lionel と相談しますが、新しいサウンド システムで Lionel が直面している問題には、どの解決策でも対応できません。Lisa は、音響技術者が24 時間内に Lionel に電話して問題の解決に当たることを Lionel に伝えます。Lisa は、ケースを有効化して一連の活動内容を作成します。さらに、音響開発チームのメンバーの Terrence に、その活動を割り当てます。
Terrence は、新しい活動が自分に割り当てられたことを発見します。Terrence は、そのケースを開き、ケース ログでケースに関する情報に目を通します。Terrence は、前日も同じ問題に対応し、その解決策を作成しています。Terrence は、Lionel に連絡して問題の解決策を伝えます。また、ケース詳細に解決策を入力します。Terrence は、自分の解決策で問題に対処できたため、他の人が同じ問題に直面した際に使用できるよう、解決策を文書化することにします。Terrence は、ドキュメントを"ナレッジ記事" フォームに追加して音量カテゴリに割り当て、有効な解決策であることを他の Fabrikam 社の従業員が分かるように、手動でランク付けを上げます。
次に、Terrence はケースを次のレベルに引き上げます。ケースを引き上げると、顧客サービス部門の品質保証の担当者である Marie に対して、新しい活動が作成されます。Marie は、新しい活動が自分に割り当てらたことを発見し、その活動に関連付けられているケースを開きます。Marie は、ケースとケースの詳細に目を通して、ケースに対して正しいプロセスが実行されたことを確認します。Marie は、実際のケース対応時間が SLA で見積もられた時間を上回らなかったことを確認します。さらに、Terrence が顧客に連絡したこと、および問題点が解決されたことをメモします。Marie は、顧客への対応とケースの解決に満足します。また、決済済としてケースを終了します。Marie がケースを終了すると、自分に割り当てられていた未解決活動も終了します。
例: City Power and Light 社における公共部門の顧客に対するケース管理の使用方法
City Power and Light 社の顧客サービス担当者の Annie は、City Power and Light 社が管轄する市の住民から電話連絡を受けます。Annie は、電話連絡を活動として記録し、通話内容をメモします。
住人は、自分の家に電気がきていないことを Annie に伝えます。Annie は、問題の調査、特定、および解決を City Power and Light 社ができるだけ速く行うことを、住人に伝えます。次に、ケースの作成と、電話連絡とケースの関連付けを行い、サービス注文を作成します。
Annie には、他の住民からも停電の報告を受けるだろうということが分かっています。顧客サービスのセンターの混乱を回避し、時間を節約するため、Annie は、問題が発生したこと、およびケースとサービス注文を作成したことを、顧客サービス担当者にグループ インスタント メッセージで報告します。インスタント メッセージには、ケース番号とサービス注文番号も記載します。City Power and Light 社が停電に関する電話連絡をさらに受けた場合、顧客サービス担当者は、個々の電話連絡に対して活動を作成し、既存のケースに割り当てることができます。
例: Fabrikam 社における従業員に対するケース管理の使用方法
次のシナリオは、異なる場所で働く Fabrikam 社の一般人事担当者が、従業員の問題を処理する際に使用できるケース管理の方法を示しています。
米国での事例
Fabrikam 社の米国部門を担当する一般人事担当者の Luke が、Fabrikam 社の従業員の Shannon から電子メールを受け取ります。Shannon は、6 か月前に仕事で怪我をした機械オペレータです。Shannon は、事故以降、医療費の支払を求めて Humongous Insurance 社とやりとりを行っています。
Shannon は、この問題について、4 週間前に Luke に連絡しています。したがって、ケースは既に作成されています。Shannon の電子メール メッセージには、Humongous Insurance 社からまだ電話連絡がないことが記載されています。Luke は、既存のケースを開いて Shannon の電子メール メッセージをドキュメントとして追加し、ケース ログに目を通します。
Luke は、このケースを作成した際に、保険というケース カテゴリに割り当てています。Luke は、保険カテゴリに関連付けられている新しいナレッジ記事があることを発見します。Luke は、ナレッジ記事を読み、Humongous Insurance 社の電話システムが更新中で、すべての電話が使えないことを知ります。記事には、保険に加入している顧客全員に電子メール メッセージを送信したものの、会社の電子メール システムの障害によって数人の顧客にメッセージが届かなかったことが記載されています。また、Humongous Insurance 社は、保険金を請求中のすべての顧客に対し、電子メールまたは郵便で連絡するよう要請しています。
Luke は、保険金請求を解決する方法を記載した電子メール メッセージを Shannon に送ります。また、ナレッジ記事を役立つ情報としてランク付けします。
Luke は、保険金請求が解決するのを見届けるため、Shannon とHumongous Insurance 社の両方を今後 4 週間フォローアップする別の活動を自分に対して作成します。4 週間後、Luke は Shannon に連絡し、Humongous Insurance 社が保険金を支払い、彼女が満足していることを知ります。Luke が、ケースのステータスを解決済みに変更します。
英国での事例
Fabrikam 社の英国部門を担当する一般人事担当者の Cristine が、Fabrikam 社の従業員の Claus から電話連絡を受けます。Claus は、息子が生まれてすぐの 9 週間前に、源泉徴収税の被扶養者の数を変更したことを Cristine に伝えます。Claus の目的は、変更内容がまだ有効になっていない理由を問い合わせることです。
Cristine は Claus に関するケースを作成します。また、Claus の税金情報を確認し、Claus が被扶養者情報を入力したものの、新しい源泉徴収税の開始日を選択していないことを発見します。Cristine は、開始日を選択して変更を再提出する旨の電子メール メッセージを Claus に送ります。Claus は、Cristine のメッセージに対し、開始日を選択して変更を再提出したことを返信します。Cristine は、Claus からの電子メール メッセージをケース レコードに添付し、変更が適切に行われて再提出されことを確認してからケースを終了します。