Dynamics AX開発チームへのエスカレーションに関して

  • Article

ある現象に関して、製品の不具合の可能性が有る場合や、開発者による詳細な調査が必要な場合は、サポートチームから開発チームにエスカレーションを行います。
エスカレーションの種類や、エスカレーションが開発チームに承認される基準等、エスカレーションに関する情報を纏めさせて頂きました。

  1. エスカレーションの種類
  2. Hotfixリクエストが承認される基準
  3. Hotfixリクエストが承認されてから、Hotfixが提供されるまでの流れ
  4. その他

a. PriorityとHotfixが提供されるまでの日数

b. Collaboration request回答期間の目安

c. Get Help

d.ビジネスインパクト

 

１．エスカレーションの種類

以下は、どのような場合にCollaboration Request, Request for Hotfix, Code Defect, Design Change Requestを使用するかのガイドラインです。

    a. Design Change Request (DCR)

デザインチェンジは、新規、拡張等、まだ製品に実装されていない機能です。

それに加えて、DCRはワークフローの変更や、既に提供済みの振る舞いの変更の場合もあります。

それは1つ期待される動作を別の期待される動作に変更したり、そのシナリオの範囲を拡大するような機能の拡張を対象とします。

DCRが機能拡張をターゲットとする場合は、特定のデータ群や構成の変更に及びます。

期待される動作はビジネスシナリオと共に技術的な実装方法、範囲、視点によって決まります。

上記２つに該当する場合は、リクエストはDCR(Design change request)と考えられます。

DCRは不具合ではなく、機能拡張です。このため、DCRは大規模のプロジェクトになり、大変時間を要します。

DCRは月単位のプロセスとなりますので、DCRのSLAはございません。

    b. Request for Hotfix (RFH)

Request for hotfixは、1つの問題を修正する目的のため一部分の修正です。

Hotfixはお客様からのリクエストが有る場合のみ提供されます。

RFHは予期せぬ結果や誤った結果を生むような、製品不具合をターゲットとしています。

お客様がHotfixをお待ちですので、RFHにはSLAを設定して解決までの日数を記録しています。

c. Collaboration Request (CR)

Collaboration Request (CR)はお客様、パートナー様又はサポートチームが開発チームからのガイダンスを得る場合に使用します。

また、CRは現象が標準デモデータで再現しない場合にもオープンされます。

根本原因が判明してCRがクローズされた後は、RFHやDCRをオープンする流れとなります。

CRにはSLAを設定して解決までの日数を記録しています。

    d. Code Defect (CD)

Code Defectsは1つの問題を修正する目的のため一部分の修正です。

Code Defectsは基本的には、Microsoftの内部テストで見つかった問題や、お客様環境でも発生する可能性が高い現象が対象となります。

Code Defectsの場合、基本的には修正を待っているお客様がいませんので、SLAは無く、解決までの日数も記録されていません。

AX2012 R2,R3の場合、Code defectの修正はCU(Cumulative hotfix)として提供されます。

AX2009, AX2012 R1の場合は、Code defectの修正は通常のHotfixと同様の形式で提供されます。

 

２．Hotfixリクエストが承認される基準 

パートナー様から「製品不具合なのに何故Hotfixが提供されないのか？」というご意見を頂くことがございます。

基本的に、製品不具合は次期CU(Cumulative hotfix)で対策されます。

ビジネスインパクトが非常に高く、CUリリース前に対策されないとお客様のビジネスに甚大な影響を及ぼす場合は、特別にHotfixとして修正を提供します。

つまり、製品の不具合であっても、必ずしもHotfixが提供される訳ではございません。

以下の[製品不具合か御要望][ビジネスインパクト] [影響範囲及びリスク]を元に開発チームで慎重に検討した結果、より重大な不具合から優先的に対応します。

中でも[ビジネスインパクト] が重要な判断基準となりますので、お手数ですが、詳細かつ具体的なビジネスインパクトを御連絡頂きたいと思います。

(判断基準)

[製品不具合か御要望]

  1. 製品不具合か、お客様固有の御要望か
  2. 現象が発生する手順及び、その機能の使用方法が適切か

[ビジネスインパクト]

  1. インパクト - 問題がどれだけお客様のビジネスに悪影響を与えるか
  2. 影響範囲 - どれだけ多くのお客様がバグの影響を受ける可能性があるか
  3. 回避策 – 問題を回避したり軽減する回避策の有無
  4. 機会 – お客様にとって重要なビジネス上のメリットの有無

[影響範囲及びリスク] は以下の基準で決定されます

  1. 影響範囲- 設計変更の必要性、変更対象オブジェクト数
  2. 他機能への悪影響 – コードを変更することによる他の機能及び既存顧客への影響

過去の例では、特定のお客様のみで発生する問題で、適用可能な容易な回避策が有る場合は、Hotfixリクエストが承認されていません。

(Hotfixリクエストが承認されなかった例)

(例１) LedgerJournalTransテーブルにレコードレベルセキュリティを設定すると、売掛金管理＞仕訳帳＞支払＞支払仕訳帳画面で、「顧客支払の入力」ボタンを押下した後、顧客を選択したタイミングでエラーが発生する。

<理由>ledgerJournalTrans.dimensionフィールドのデフォルトの値を変更することで、他の既存のお客様が影響を受けるため。また、LedgerJournalTransテーブルにレコードレベルセキュリティを設定した場合にのみ発生して、回避策も有るため。

<解決策>サポートチームから提示させて頂いた回避策で回避頂きました。

(例２)[売掛金管理] > [定期処理] > [販売の更新] > [ピッキングリスト] または [梱包明細]から選択する転記処理について、クエリ条件に「注文明細行 : 行ステータス : オープン注文」が含まれていない。

<理由>行ステータスが オープン注文以外の場合も転記できる必要が有ります。クエリ条件にデフォルトで「注文明細行 : 行ステータス : オープン注文」を設定するのは、お客様固有の御要望であり、製品標準機能として組み込むことは適切では無いと判断しました。

<解決策>サポートチームから提示させて頂いた回避策で回避頂きました。

また、製品不具合ではなく、将来バージョンで特定の機能の追加することを希望される場合は、以下のサイトから開発チームに御要望を連絡頂くことが可能ですので、ご活用ください。

(Product suggestion site)

https://connect.microsoft.com/dynamicssuggestions

 

３．Hotfixリクエストが承認されてから、Hotfixが提供されるまでの流れ

Hotfixリクエストが承認されてから、Hotfixが提供されるまでの、一般的な開発側での作業の流れは以下の通りです。

1.Triage(開発側で詳細な調査を開始するか、ビジネスインパクト等を元に決定)

2.Repro(再現確認)

3.Investigate(調査)

4.Investigation Review(調査結果のレビュー)

5.Fixing(修正コードの作成)

6.Code Review(コードのレビュー)

7.Private Test(単体テスト)

8.Test Spec Review(Official Testのテスト項目のレビュー)

9.Checkin and Build(Hotfixの作成)

10.Official Test(Hotfixのテスト)

11.Released(HotfixファイルをHotfixサーバにアップロード)

 

４．その他

　 a. PriorityとHotfixが提供されるまでの日数

開発チームでHotfixリクエストの調査を行うとの判断になってから、Hotfixが提供されるまでの日数は、開発が設定したプライオリティにより凡そ以下の通りとなっています。

プライオリティはサービスリクエスト登録時にお客様が設定された値ではなく、開発側でビジネスインパクトや現象から判断した優先度です。

Priority 1     7営業日

Priority 2     14営業日

Priority 3     30営業日

 

　b. Collaboration request回答期間の目安

Collaboration requestもHotfixリクエストなどと同様に正式なエスカレーションプロセスを通しますので、回答まで２週間程度かかることをご理解頂きたいと思います。

サポートチームでは、できる限り回答をお待たせしないように、Collaboration request前に、海外のサポートチームや開発チームにメールベースで問い合わせを行いますが、そこで回答が得られなかった場合に、Collaboration requestを使用して正式に開発に調査依頼致します。

Collaboration requestも正式なエスカレーションプロセスですので、Triage(開発側で詳細な調査を開始するか、ビジネスインパクト等を元に決定)を行いますので、ビジネスインパクトが必要です。

 

c. Get Help

Hotfixリクエスト等のエスカレーションが開発チームに承認されなかった場合、より詳細なビジネスインパクトと共に、再度開発チームに検討を依頼することは可能です。

２度目のエスカレーションでも、開発側で承認されなかった場合は、通常のエスカレーションプロセスではなく、Get Helpというプロセスを使って再度リクエストすることも可能です。

Get Helpをご希望の場合は、プレミアサポートを御契約頂いているお客様は担当TAM(technical account manager)、Partner advantage契約をご使用の場合はRelationship　manager経由でGetHelpを御利用頂くことが可能です。

GetHelpを利用するのは以下の場合です。

  1. 通常のプロセスで解決しなかった問題の支援

通常のプロセスで解決しなかった・進捗がない場合の問題解決を支援。

例えば、一度承認されなかった修正リクエストに対する再チャレンジに対する支援。

※無理無茶を例外的に認めさせるプロセスではありません。

  1. 将来的な、製品・プロセスに対する改善要望

複数のお客様に影響がある(または将来あると思われる)問題。社内の不適切なプロセスやポリシーなどで発生している問題。

※直近での解決は難しい場合が多いです。

 

　d.ビジネスインパクト

通常エスカレーション時にはビジネスインパクトとして以下の情報を頂いています。

１．お客様名

２．運用開始時期（又は問題の機能の使用を開始する時期）

３．製品バージョン（カーネル/アプリケーション）　＜頂いていない場合＞

４．問題の機能を使用しているユーザ数

５．問題の機能を使用する頻度

６．回避策の有無

７．回避策が有る場合、回避策を適用頂けない理由

８．お客様が問題の機能を使用されている経緯（Business Focused Problem Descriptions）

９．問題の機能が、お客様のビジネスに与えている具体的なビジネスインパクト

１０．他に開発チームにお伝えになりたい事がございましたら御連絡頂けますでしょうか。

（８，９の例）

８．お客様が問題の機能を使用されている経緯

毎週末、お客様は、問題の機能を使用して、小切手を印刷して、従業員に給料を支払う必要が有ります。お客様は既に会社の住所が印刷されている用紙を使用しています。

９．問題の機能が、お客様のビジネスに与えている具体的なビジネスインパクト

この問題により、毎週の給与支払いが止まり、後４日以内に問題が解決しない場合、数千人の従業員が給与を受け取れなくなります。