例外の申請
この申請は承認なしで進められますか?
いいえ。ルールの出典を示し、承認の手続きに回します。
確認すること: 例外の申請
回答に条件が含まれ、参照先が案内を裏付けていること。申請を承認済みとして扱っていないこと。
運用・改善
回答を改善し、使いやすくし、投資の方向を定める。
情報源が変わる。チームが回答を修正する。コストが増える。Gaulettは原因を調べ、合意した調整を行い、利用前に変更を検証します。次の一歩を判断するための根拠をそろえます。
貴社にお渡しするもの
5つの成果物を通じて、継続的な確認をソリューションに関する判断につなげます。
支援の対象範囲、頻度、対応条件は、提案書で定めます。
対象のソリューションと環境、指標、基準、アクセス、連絡経路、責任者。業務にとって重要な点を確認するための手順を定めます。
利用できる指標と利用者の意見を確認します。同等の期間と条件で比較し、変化や、効果の評価に不足する情報を特定します。利用が増えたことだけでは、価値が生まれた証拠にはなりません。
影響の記録、原因の調査、契約範囲に応じた対応。合意した変更は、元に戻す条件も定め、公開前に確認と承認を行います。
有用性、リスク、労力、依存関係を考慮し、責任者と改善の優先順位を決めます。変更ごとに、目標と効果を評価する基準を定めます。
確認した状況、修正した内容、検証した結果をまとめます。文書を更新し、チームと次のステップを話し合います。
チームの修正を、問い合わせの改善へ
例外の申請についての問い合わせを考えてみましょう。ルールでは承認が必要でも、回答には以前の案内が使われています。Gaulettが原因に対応し、ほかの状況でも修正が機能するかを確かめる流れを示します。
チームが指摘した回答
例外の申請は承認なしで進められます。
責任者が確認した情報源
例外の申請を進めるには、事前の承認が必要です。
不一致が解消されるまでは、影響を受ける申請を人による確認に回します。
質問、回答、出典、背景情報を保存します。この例では、問い合わせで以前の案内を参照していました。文章だけを直しても、原因は残ります。
責任者がルールを確認します。Gaulettは合意した範囲で、情報源の選択と問い合わせの仕組みに与える指示を修正します。
例外を含む同じ質問で、変更前と変更後の版を比較します。満たさない基準があれば、再調整します。
修正を検証する方法
この例のカードは、承認に必要な期待結果を示しています。貴社との業務では、実際に得られた回答と各テストの評価も記録します。
例外の申請
いいえ。ルールの出典を示し、承認の手続きに回します。
回答に条件が含まれ、参照先が案内を裏付けていること。申請を承認済みとして扱っていないこと。
通常の申請
一律に適用せず、通常の申請に該当する手順を確認します。
例外への修正によって、手順に根拠のない要件をほかの申請に加えていないこと。
情報源を利用できない
制約を伝え、責任者に引き継ぎます。
ルールを作り上げず、置き換えられた案内に戻らず、申請を許可していないこと。
変更の判断に必要な情報をそろえる
チームからの報告をきっかけに分析を始めます。変更を利用するのは、レビューと合意した検証を終えてからです。
適用可能な情報源で裏付けられた回答と、繰り返し発生する不具合。
人による確認や修正を含め、申請を完了するまでにかかる合計時間。
作業の完了1件あたりのリソース消費とチームの負担。
同等の期間、申請の種類、条件で比較します。テストの合格は変更を利用するための条件です。事業への効果は、実際の利用を通じて確かめる必要があります。
次のサイクルに向けた判断
基準は引き続き満たされています。基準を維持し、状況の確認を続けます。
原因や改善の機会が見つかった段階で、変更内容と確認方法を決めます。
継続するための条件が不足しています。責任者が人による対応と再開の基準を定めます。
情報が足りない場合は、結論を出す前に何を確認すべきかを示します。
支援の進め方
貴社のチームは日常業務の状況を伝え、優先順位を決めます。Gaulettは状況を分析し、合意した変更を実施して、確認した内容を記録します。
始める前に
ご相談ください
ソリューションと、チームが日々気付いていることをお聞かせください。最初に注目すべき点を一緒に見つけましょう。