しかし、今は彼らについてではありません。 これはツールに関するものではなく、完全に特定の状況、つまり社内のテクニカルサポートサービスの活動を分析する場合にそれらを使用する方法に関するものです。
大規模な組織では、集中型サービスの運用が重要になることがよくあります。
あなたが10人で構成されるサポートサービスの責任者であり、あなたのチームが200チームのチームにサービスを提供していると想像してください。各チームには7〜10人がいます。 これは、毎日仕事であなたを攻撃する最低1,400人です。
ここでさらに現実を追加して、チームが結果を出すことができない特定の集中機能（たとえば、何かを設定する）を実行していることを想像してください。
すべてがあなたに結びついており、チームがより速く、より良い仕事をすればするほど、社内の他のすべてのチームが結果を出すのが速くなります。
そして、ここでリクエストの処理が遅いという苦情が始まります...
当然、この状況では、マネージャーは言葉ではなく、事実データを必要とします。
コホート分析が助けになります。
最初にコホート分析に出くわすと、自然な拒絶感と拒絶反応を引き起こします。なぜなら、 従来のグラフや指標とは異なります。
しかし実際には、複雑なことは何もありません。 本質的に、コホート分析は季節性のようなものです。
季節性とは、年や週など、同様の期間が取られ、測定値の動作のグラフがそれらから作成される場合です。
温度グラフを想像してください。 コホート分析を使用して分析する場合、年をコホートとして取得し、年の初めから終わりまで温度グラフを作成できます。
異なる年のグラフを比較すると、年ごとに同じ温度の挙動が繰り返されます。
誰もが通常の解釈でグラフを測定することに慣れています。 グラフの作成について話している場合、最初に頭に浮かぶのは、合計額、平均額、または額の計算です。
しかし、問題があります。多くの場合、そのような量は「洞察」を与えません。 彼らの助けを借りても、問題の本質を理解するために必要なデータを見つけることはできません。
コホート分析は、通常の測定基準とは対照的に、真実を突き止めることができる結果をもたらします。
そのため、彼らの活動の実態を把握するために、新興企業や企業がますます使用するようになっています（AARRR指標はコホート分析によって正確に分析されます）。
コホート分析とは何か、そして大企業でテクニカルサポートサービスを最適化するためにどのようにそれを使用できるかについての具体例を見てみましょう。
記事を読んだ後、通常のExcelと標準の関数セットのみを使用して、コホート分析を自分で行う方法を学習します。
イヴァンに会う...
技術サポートサービスの責任者である彼をIvanと呼びましょう。彼のサービスへのリクエストに本当に長い時間がかかったかどうかを確認することにしました。
幸いなことに、すべての呼び出しはJiraを介して登録され、必要なことはすべてのチケットとその履歴をExcelにアップロードすることだけです。
合計約3300レコード。
Ivanが最初に思いついたのは、アプリケーションの処理にかかる平均時間を調べることでした。
関数= NET（）は、アプリケーションが作成されてから「解決済み」ステータスに移行するまでの稼働日数の計算に役立ちました。
Excelの「ピボットテーブル」を使用して、Ivanはアプリケーションを処理するための平均時間を受け取りました。
（営業日）
「これは恐ろしいです！」Ivanは、16日ではなくチケットを作成するために2日間がSLAに費やされたため、叫びました。
グラフはさらにひどい画像を示しました。
（平均労働時間、就業日）
（1日あたりの解決済みリクエストの数）
リクエストはどこかから送信され、平均作業時間は200営業日（！）です。
問題は明らかでしたが、グラフからは、それがどこから発生し、その本質が何であるかを正確に完全に明確にすることはできませんでした。 チャートは沈黙していました。
イワンは絶望に陥り、何をすべきか分からなかった。 それから怒りが来ました。
しばらく考えた後、彼はうまく働かない部下の人々を罰することにしました。
これを行うために、彼は処理アプリケーションの平均期間のグラフを作成しました。
（X軸-アプリケーションのエグゼキューターの名前、非表示、Y-このユーザーによるアプリケーションの平均実行時間、就業日）
犯人が特定されました。
しかし、イヴァンの友人であるボリスは、彼に罰を急がないように頼みましたが、最初はコホート分析を適用しようとしました。
コホートの選択方法
Jiraからアップロードされたチケットの場合、チケットのクローズ中にExcelピボットテーブルが作成されました（すべてのデータを選択/挿入/ピボットテーブル）。
まず、データ配列全体をコホートに分割する必要がありました。 これは通常、オブジェクトの生年月日までに行われます。
コホートを選択するために、ピボットテーブルはチケットが作成された日付ごとに週間隔でグループ化され、稼働時間（チケットが作成されてから実行されるまでの稼働日数）がメトリックとして計算されました。
次に、それらの上に要約図が作成されます。
各コホートは、グラフ上に独自の色で表示されます。
そして、lo！ 現実は異なってきました。
チケットの52％はまだSLAに適合しています。 そして、はい、チケットの47％は長時間-最大200日間閉じられます（おそらく忘れられたタスクがあるだけですか？）。
しかし、以前に計算された平均労働時間はどうですか？ ご覧のとおり、これは現実とは関係なく、特定の不可解な数を示しています。 そのため、平均を使用することは非常に有害です。
世界の本当の姿を受け取ったイヴァンは、最初に200営業日で実行されるチケットの種類を理解することにしました。
ピボットテーブルでは、これは非常に簡単です。ピボットテーブルのセルをダブルクリックすると、Excelはこのセルを構成するチケットのリストを表示します。
これらは本当に忘れられたチケットであり、明らかに「クリーニング」中にクローズされたことが判明しました。
残念ながら、そのような「外れ値」は平均の値に非常に強く影響し、不適切な方向に大きく損ないます。これは、分析での使用に対する別の議論です。
コホートチャートを調べる
チャートを詳しく見ると、イヴァンはピークを見ました...
最も可能性が高いのは、SLAで規定されているよりも多くの時間を必要とする特別な種類のタスクがあることだとIvanは考えていました。
「23」をダブルクリックすると、実行時間が23営業日のチケットのリストが表示されました。
Ivanが予想したように、ほとんどのチケットは同じタイプで、スタンドの作成を要求しました。
同様に、Ivanはグラフ上のすべてのピークを分析し、結果に応じて、選択した種類のタスクのSLAを変更し、一部のタスクを加速して、減速がどこに隠れているかを把握しました。
Ivanの2番目の洞察は、実際にはチャート上のテールがまったくあってはならないということでした。
このようなもの：
結局のところ、実際、右側の尾はSLAに違反し、チケットの実行時間を遅らせることを意味します。
当然、異なるタイプのタスクは実装に異なる時間を必要とするため、実際にはテールとピークがありますが、ゼロになる傾向が非常に望ましいです。
しかし、「ダブルス」はどうですか？
実際、タスクを完了するのに「卓越した」平均時間を持つ従業員はどうでしょうか。
予想どおり、最悪の従業員のいる状況は実際にはそれほど悪くはありません（同じコホートチャートですが、便宜のために棒グラフの形で表示されています）。
彼は明らかにほとんどのリクエストを時間通りに実行し、平均時間は170日間のチケットのクローズという形で「外れ値」によって損なわれます。 ちなみに、ここで遅刻したのはこちらです！
そして、これは最も多くのタスクを実行した従業員がどのように働くかです：
彼が標準の実装に順守していることも明らかです。
しかし、コホート分析が提供するのはこれだけではありません。
実行時間が2日を超えるタスクの最大数を正確に把握できるようになりました。
（Y-実行時間> 2日のタスクの数、X軸-エグゼキューターの名前）
連携するものがありますか？
そして、もちろん、「ダブルス」のリストは少し異なり、完全に異なる姓が登場しました。
これらすべての結果はありますか？
タスクの作業を開始したIvanは、最初の週にすでに重要な結果を達成しました。
グラフは2018年1月の3つのコホートを示しています。
行を左にゼロにシフトする形での状況の顕著な改善。
最後のコホートの緑色の線は、結果が大幅に改善され、すべてのチケットが1営業日以内にクローズされることを示しています。
チャートのビューを円柱状に変更すると、ほとんどのチケットが同じ日または翌日に閉じられていることがはっきりとわかります。
グループを変更すると、データが確認されます。
Ivanは受け取ったツールがどれほど強力であるかを理解し、その瞬間から自分の部門で何が起こっているかを実際に把握するために常に使用していました。
おわりに
世界には多くの美しくて異なるメトリックがありますが、それらすべてが実際にプロセスを掘り下げ、その「ボトルネック」を見つけて排除する機会を与えるわけではありません。
コホート分析は間違いなくこれに非常に適しています。
コホート分析を実施するには：
- すべてのイベント（たとえば、Jiraからのチケット）をExcelにアップロードします。
- ターゲットメトリック、たとえば、チケットの実行期間を決定します。
- チケットが作成された日付とその実行期間によってピボットテーブルを作成します。
- 作成日を週ごとにグループ化すると、より便利になります。
- テーブルに基づいてピボットチャートを作成します。 週ごとに異なる行を使用します。
- フィルタを使用して変更をグループ化し、人、プロジェクト、リリースなど別のセクションにデータを表示します。
- チャート上のピーク（外れ値）を分析します-それらの下に隠れているチケットを見て、それらが発生した理由を確認します。 詳細または何か他のもののために？ 必要に応じてSLAを変更します。
- 可能であれば、「テール」を削除します（これがあなたに関連する場合）。
- アクションの結果を測定します。
コホート分析は本当に役立つものであると確信しています。
試してみて、このツールを使用して、部門、部門、または会社を整理します。
頑張ってください！
PSコホート分析に関する私の記事をさらに3つ読んでください。