SLAの哲学：エスカレーションとは何か、なぜそれが必要なのか

私の記事「良いSLAの書き方」で、SLAは単にエスカレーション手順を要求するだけだと述べました。 エスカレーションについて少し言いたいです。

私の意見では、ITのエスカレーションを理解している人はほとんどいません。 ITILでは、なんとなくぼんやりと定義されています。 したがって、さらに、それを導入しようとすると、濁度は増加するだけです。 GoogleもYandexも、わかりやすいものを見つけるのに役立ちません。 エスカレーションを簡単かつ明確に説明する代わりに（著者が行うように）、著者はいくつかの新しい用語を導入し始め、機能的エスカレーションと階層的エスカレーションの違いを示します（なぜですか？）説明と脇への移動なし。 また、コンテキストから、エスカレーションは、リクエストを別のエグゼキューターまたは別のユニットに転送すること、または追加のリソースを引き付けること、または優先順位を上げることの同義語であると想定できます。 そして、時々私は意味を理解するのに迷子になります。 これらすべてが私に個人的に「捻り回し、私は欺きたい」、または平凡な無能のどちらかの感覚を引き起こします。

現在のエグゼキューターがSLAで指定された時間内に時間がない場合、特に素晴らしい（この例を挙げずにはいられません）は、別のレベルのサポートへのリクエストの自動「エスカレーション」です。 つまり、エグゼキューターである私たちは、リクエストを受け入れて全力を尽くし、期限が切れるまで何もしません。 -自動「エスカレーション」がトリガーされ、リクエストが他の誰かに再割り当てされます。 利益！。主なことは、自分自身を制御し、何もしないことです。 心から笑うことは可能ですが、一部の地域では、ITのベストプラクティスを装って、「エスカレーション」のようなスキームが適用されます。

それでは、エスカレーションとは何ですか、誰がそれを必要とし、なぜですか？ 私の理解をお伝えします。その後、私と同じようにエスカレーションを愛することを願っています。 椅子をしっかり握ってください。

最初に、なぜこれがエスカレーションではないのか、上記のことを否定します。

エスカレーションは、リクエストの再割り当てではありません。 少なくとも単純な理由で、リクエストを別のアーティストに再割り当てすることを「リクエストを別のアーティストに再割り当てする」と呼びます。 エスカレーションではありません。 一般に、請負業者がすでに作業を開始している場合、リクエストの再割り当ては明確に不可能です。 私が知っているリクエストを送信する唯一の正しい方法は、新しい請負業者が自発的にリクエストを受け取り、現在の請負業者の事前の同意を得た場合のみです。 私はリクエストを受け取った（与えた）ので、最後まで決定します。 はい、そして再割り当て後の「その人のために」結果をかき集めることはまだ喜びです。 この出来事は、ありふれたものというよりは不可抗力です。 さらに、自動再割り当てもありません。 それ以外の場合、実行者は仕事から実行されます。

また、エスカレーションは優先順位の増加ではありません。 状況を所有していない（ただし、ロジックを所有している）人でもすぐに問題を提起するので、優先順位の最も高い要求をエスカレートする方法は？ また、1から4までの数字の優先度が4つしかない場合は、最大3回までエスカレートし、優先度を4から3、3から2、2から1に変更できます。 不審で非論理的に見えます。 そして、3番目の優先順位の実行者が休暇から私たちに応答しない場合、なぜ2番目の実行者が突然開始するのですか？

しかし、その後、エスカレーションとは何ですか？ 定義：

エスカレーションは、リクエストの作業の進捗が何かに満足していない場合に、個々のリクエストに注意を引く手順です。

そうです、そうでなければ。 注目を集めます。 肉眼では、優先度が増加する関係を見ることができます-他のそのような不条理なアクションのように、突然増加した優先度は注意を引き付けるので、この動作は部分的にエスカレーションのように見えます。 しかし、出演者が休暇に行かなかった場合のみ。 まあ、一方の不条理な行動は、他方が対称的に応答できることを忘れないでください。 ご質問、いわば私たちのarbitrary意的な答え。 そのため、エスカレーションが注目を集めていると理解する方が正しいです。 そして、すでに有能な人は、優先順位を上げるか、追加の専門知識を引き付けるか、または単に構成を完全に変更するまで必要な加速をパフォーマーに与えるかどうかを判断します。 つまり、以前にエスカレーションを判断しようとしても、この定義には一貫性があります。

ただし、この定義では、優先順位とサポートレベルの数が限られているにもかかわらず、必要な回数だけリクエストをエスカレーションできるため、すでに優れています。

続けましょう。 すべてのエスカレーションには理由が必要です。 言い換えれば、リクエストに何か問題があるため、何らかの理由でそれに注意を向ける必要がありました。 開始者は、エスカレーション中にこの理由を示す必要があります。 理由のないエスカレーションはありません。 エスカレートする理由の典型的な例を次に示します。

• 作業の進行に対する不満、正確に何を示す必要があります（例：1週間で重大な問題に対してアクションが取られなかった）
• 問題の新しい重要な状況が明らかになりました：解決される問題の用語、範囲、およびその他の特性が変更され、問題を新しい品質に変換します（例：データベース内の1つのレコードではなく、多くのレコード）
• VIPの1人が関与している（例：部門長が個人の管理下で決定を下した）
• その他の重要な状況。

エスカレーションの理由が期限である場合、これらの期限を示し、この期限が重要である理由と、期限に違反した場合にどうなるかを明確に述べる必要があります。

エスカレーションの理由は次のとおりではありません。

• ユーザーがリクエストをエスカレートしました（実際、どこに理由がありますか？）
• すぐに解決策が必要です（なぜ昨日ですか？それとも明日？）
• エスカレート（誰によって、どのような理由で？）

その他の同様の無意味なフレーズ。

イニシエーターがエスカレーションの明確な理由を示さなかった場合、エスカレーションを分析する際の最初の質問は、理由を示すリクエストである必要があります。 まあ、それは誰にでも起こります、人々は心配して、重要なことを見逃しました。 私は真剣に言って、エスカレーションはしばしば厳しいストレスの多い状況で行われます。 ただし、理由がまだ示されていない場合は、エスカレーションの理由がないため、エスカレーションを閉じる必要があります。 エスカレーションの明確な理由を定式化できない場合、これは考えるのに適した理由です。おそらく、あなたは本当に何もエスカレートする必要はないのでしょうか？

エスカレーションの理由は通常、専門用語ではなく、問題がビジネスを妨げる場所と理由を述べる必要があります。 これがいわゆるビジネス上の理由です。 マイナーな技術的な問題が実際にビジネスに多くのトラブルを引き起こす可能性があることに同意します。 比較する：

• tech。 、GL_JE_LINESテーブルのいくつかのエントリが破損しているため、毎月20日までに修正する必要があります。
• ビジネス 、民法への投稿が破損している、それは期間を閉じて、会計および税レポートを提供することは不可能であり、次の期間の操作を入力し、20日から税は利子と罰金を請求し始めます。

最初の理由は、技術専門家の狭いサークルだけが理解できます（多くの場合、長い分析の後にのみ）、2番目の理由は、ビジネス全体がすでに立ち上がっていることを皆に伝え、すぐにお金を得るでしょう。

エスカレーションの明確な理由を示すのは、本当に必要なときにすべてのケースをスキップし、ほとんどの不十分な部分をカットする優れたフィルターです。

誰かがリクエストをエスカレートした後はどうなりますか。 エスカレーションを考慮する必要があります。 リクエスターまたはより有能な誰かが現れ（特にエグゼキューターのアクションがエスカレーションの原因である場合）、明確に応答する必要があります。 一般的に、「明確に応答する」とは、エスカレーションの理由に照らしてリクエストで現在の状況を分析し、両側に適合し、エスカレーションの原因を排除するさらなるアクションの計画を開始者に提供することを意味します。 次に、この計画に基づいて行動します。 エスカレーションの検討は、迅速で避けられず、高品質でなければなりません。 ここではハッキングできません。

ところで、リクエスタは必ずしもエスカレーションする必要はなく、重要な情報が他の誰かから送られることもあります。 また、完全を期すために、エスカレーションは必ずしも優先順位の引き上げやアーティストの交代につながるわけではなく、通常はそうではないことに注意してください。 優先順位は、必要な場合にのみ適合になります。それ以前にそれらが見逃したか、状況が変わった場合です。 エスカレーションがそうでなかった場合、行動計画全体が「同じモードでさらに継続する」ことが判明したり、エスカレーションの一部として優先度が低下したりすることが判明する場合もあります。 もちろん、エスカレーション中はより頻繁に優先順位を上げる必要があります。このアクションには迅速性が必要であり、場合によってはリクエストに対する作業の他の調整が必要です。通常の手順で優先順位を下げることができます。 エスカレーションの主なものは、エスカレーションの原因を排除し、秩序を回復するための行動が注目され、それに伴っていたことです。 開始者と請負業者が同意できない場合、エスカレーションの検討は、多くの場合、プロジェクトの調停としても機能します。 イニシエーターは時々奇妙な何かを望み、時には不可能です。

そして、ここで私たちはすでに徐々に質問に近づいています。なぜエスカレーションが必要なのですか？

イニシエーターが多かれ少なかれ明確です。 要求のイニシエーターにとっては、不幸や不一致を表明する機会であり、偶発的な事態を解決する機会でもあります。 これは、「エスカレーション」という言葉の直感的な理解とよく一致します。これにより、ITシステムの一般ユーザーを含め、エスカレーションの使用が許可され、規制や指示を読まなくても適切にエスカレーションを使用できます。

しかし、なぜパフォーマーへのエスカレーションが必要なのでしょうか？ そして、それは必要ですか？ 演奏者はしばしばこれを理解していないため、エスカレーションが好きではありません。 しかし、無駄に。

一見、状況は非対称に見えます。 イニシエーターにとって、これは彼の拳とスキャンダルでテーブルをノックする機会であり、何らかの理由でパフォーマーはこれにジャンプして反応しなければなりません。 そして素早く跳ね返り、適切に対応します。 彼のためにこれ以上することはありませんか？

エスカレーションがない場合に何が起こるか見てみましょう。 イニシエーターに不満の理由がある場合、彼は待機し、待機し、忍耐が破裂するまで待機します。 そして、スキャンダル、宣誓、 腸の血 3番目の膝に想起できるすべての苦情、上司の関与、ストレス、神経、その他の生産恐怖。 そして、同時に不満の理由が実際にあり、過去に欠陥があった場合（ほとんどの場合、誰も完璧ではないために起こります）、それは誰にも見えません。 さらに、そのような対決の間、リクエスト自体で建設的な行動に戻ることは非常に困難になります。 イニシエーターは協力する準備ができておらず、妥協して何もあきらめたくありません。解決策が今、そして可能な限り最良の方法で、銀の大皿に必要です。 そして、問題は通常、些細なものではありません。些細な高さのために、問題は提起されません。 そのようなスキャンダルをクリアするのは簡単ではありません。

次に、適切に調整され、明確に機能するエスカレーションメカニズムがある場合、同じ状況で何が起こるかを検討します。 イニシエーターは、最後まで耐えるのではなく、何か問題が発生していることに気づくとすぐに要求をエスカレーションします。 エスカレーションの理由が調査され、状況が検討され、必要なアクションが計画されます。 それほど作業はありません。これは事実ですが、通常モードのままであり、相互作用は建設的なままです。 計画が良くない場合、別のエスカレーションが続く可能性があります。つまり、間違いは不快ですが、致命的ではありません。 改善する可能性は最大になります。 そして、たとえ何らかの理由でイニシエーターがエスカレーションを利用しなかったとしても、前の段落のすべての恐怖の代わりに、イニシエーター（そして、おそらく彼のリーダー）への1つの質問によって状況は解決されます。

したがって、作業エスカレーションメカニズムにより、請負業者は確実に自分の作業に関する苦情を回避することができます。 さらに、効率的かつ体系的に。 暗記を改善するためにもう一度繰り返し、フレームを取ります。

作業エスカレーションメカニズムにより、請負業者は作業に関する苦情を確実に回避できます。

足りない？ エスカレートするとき、 イニシエーター自身が、 どのリクエストをパフォーマーに特に注意を払うべきかを示します 。 そして、事前に、爆発する前、そして彼ら自身が建設的に仕事をする準備ができたその瞬間に。 自分自身。 事前に。 建設的に。 ある種の休日。

まだ足りない？ エスカレーションに参加しているプロジェクトの責任者（ユニット、部門、グループ）は、プロジェクトの現在の状況を理解し、部下の仕事を評価するための貴重な情報を提供します。 そのような状況で、パフォーマーの仕事の質がすべてよりも明るくなるのは明らかです。 そして、ヘッドは現在競合する可能性のあるすべてのリクエストを知っています。 それらは、彼自身がエスカレーションに参加するレベルで知られています。

したがって、実際には、イニシエーターよりもパフォーマーにとって、エスカレーターメカニズムがほぼ必要であることがわかります。 私の意見では、これのために、エスカレーションの迅速かつ高品質の考慮に苦しむ価値があります。

それでもエスカレートしませんか？ 無駄に...

PS記事のタイトルをよりわかりやすいものに変更しました