責任の不合理な配分のような現象にしばしば出くわしましたか？ 1人の「すべての取引のジャック」が5人で仕事をする方法を何回観察しなければなりませんでしたか？ そして、いわゆる「何を理解していない専門家」はおなじみですか？ このようなオプションは、同様のオプションと同様に、しばしば国内の現実において以前に見られなければなりませんでした。 多くの人々はこの「スクープ」を観察する必要があり、さらに悪いことに、多くの政府機関で今日までそれを自分の肌で感じています。
「権力の分離」などの巧妙なフレーズがしばしば語られます。 しかし、誰もがそれを実践する方法を知っており、誰がそれを実際に活用することができますか？ よく見てみると、この現象は概して民間企業、特に外国のクライアントと仕事をしている企業にあると結論付けています。
「ヒロック」が原因で、RACIと呼ばれる奇妙な略語が私たちに届いたのです。 同時に、彼女の前ではしばしば「マトリックス」または「モデル」のようなさまざまな種類の賢さを観察できます。 それは何で、何で食べられるのか、読者にさらに説明しようと思います。 おそらく誰もが誰もが自分の責任と責任範囲を知っているチームで働くことはすでに幸運です-あなたはそのような人々のためにのみ幸せになることができます。 同時に、力の分離の分野ですべての人が理想的にすべてを持っているわけではないと個人的に信じています。 そのような人々にとって、この記事は役に立つかもしれません。
それでは、RACIマトリックスとは何ですか？ この頭字語は、4つの特定の役割に分類されます。
- 責任者（マトリックスに文字Rでマーク）-作業を直接担当
- 説明責任（ A ）-説明責任、1つのタスクの1人だけがそのような役割を担うことができます
- 相談（ C ）-タスクに関して相談を受けた1人の従業員またはグループ、およびその意見を考慮に入れる必要がある
- 通知（ I ）-特定のタスクを通知された従業員。
また、モデルには2つの高度なバージョンがあります。
RACI-VS 、2つの役割がここに追加されます。
- 検証（ V ）-タスクの結果が合意された事前基準と一致していることを検証する1人の従業員またはグループ
- サインオフ（ S ）-製品の顧客への配送を承認します（タスクの完了）。 この役割は、説明可能な役割と組み合わせることができます。
RASCIモデルバリアントを使用すると、1つの新しい役割が表示されます。
サポート（ S ）-たとえば、製品実装のサポートなど、作業を実行するための追加リソースを提供します。
一方で-「多くの文字」と何も明確ではありません。 一方、より明確にするために、RACIマトリックス自体がどのように見えるかを例で示したいと思います。
表の見出しに特定のタスクを担当する、または決定に直接参加する機能的役割のリストが表示されることを理解するために、「キャップ」である必要はありません。 項目「アクティビティ1〜5」は、実際には上記の役割の肩に当たる機能です。
そのようなプレートをどのような原理で描くべきか、また実際のプロジェクトでそれを実際に使用する方法を理解するために、マトリックスを構築するための次の手順に十分な注意を払うことをお勧めします：
- タスク（プロジェクト）で必要なアクティビティ/プロセスのリストを決定します
- 機能的役割（何らかの方法でこのタスクに興味を持っているか影響を受けている人々）を定義し、示します
- 集会を集め、RACIコード（実際には文字）を特定の役割に割り当て、責任を直接区別します
- 矛盾を特定します（たとえば、責任が多すぎる、または不足している）
- テーブルについて説明し、レビューを収集します
- 割り当てられた役割の実行を制御します
誰かがラテン文字をそれらが意味する機能と関連付けることは容易ではないことを認めます。 それでも、ロシア語版を使用することはお勧めしません。混乱が生じる可能性があり、何が何であるかを把握するのがさらに難しくなります。
そして最後に、RACIモデルの開発を終えた後、結果を分析することは害になりません。
機能的な役割によって、次の質問に答えて分析できます。
- 多くの「A」 -責任は正しく割り当てられていますか？ ボトルネックはありますか？
- 多くの "R" -1つの役割に私たちの責任がかかりすぎていませんか？
- テーブルに空のセルがない -この役割は本当に多くのタスクに関与する必要がありますか？
また、実行されたアクティビティを分析することを忘れないでください。
- 複数のA-説明責任が必要な役割は1つのみ
- 「A」の欠如 -説明責任者を見つける必要がある
- 複数の「R」またはその欠如 -誰かが責任を負う必要がありますが、広く分散する責任は必要ありません-タスクが完了しないリスクがあります
- 多くの「C」 -多くの役割と相談する必要があり、それは効果的ですか？
- 「C」と「I」の欠如 -コミュニケーションは正しく確立されていますか？
読者を飽きさせないように、これについて詳しく説明したいと思います。 関数の分布はどの程度適切か、そのようなモデルをどのように使用するかはあなた次第です。 ソビエト後の現実で機能するかどうかは、論点です。 ただし、外国の顧客と協力することで、RACIマトリックスは不要になるだけでなく、プロジェクトの活動とそれを実行する人々について誰もが明確に理解できるようになります。 そして、ご存知のように、顧客はほとんどの場合、自分に割り当てられたタスクの担当者と担当者を明確に知りたいと考えています。
また、RACIマトリックスはスケープゴートを決定するためのツールではありません。コンパイルに時間を費やすことに同意した人々がその目的と目的を先験的に理解しなければならないからです。
PSこのような機能を配布する手段を使用する可能性について読者の意見を聞いたり、個人的な経験を共有したりすることは、コメントで興味深いでしょう。
UPD。 Sibaritユーザーのリクエストに応じて、特定のタスクにモデルを使用する簡単な例を紹介します。
ウェブサイトにオンラインチェックインシステムを導入する航空会社があるとします。 タスクのコンテキストで実行する必要があるグローバルアクティビティは、ほぼ次のとおりです。システム要件の収集。 ソリューション設計; ソリューションの直接開発。 実装; 実際には-「生産」の段階。 ソリューションの最適化。
次に、機能的役割のリストを決定します;このタスクでは、次のオプションが可能です： 内部サービスプロバイダー（航空IT部門）または外部サービスプロバイダーが存在しない場合。 ISP-航空会社のウェブサイトのホスティングを提供する会社。 航空会社の事業単位（顧客の利益を表します）; 財務部（会計）; サービスマネージャー（組織の規模に応じて、内部IT部門の一部である場合があります）; 開発チーム（組織の規模に応じて、内部IT部門の一部となる場合があります）。
役割と彼らが実行する活動に応じてRACIコードを整理してみましょう（このプロセスはすべての関係者の参加によって行われることは明らかです）。
したがって、このタスクの役割と機能は分散されます。 このプロジェクトおよび他のプロジェクトでは、さまざまな企業の特定のニーズに応じて、マトリックスオプションが異なる可能性があることにすぐに注意します。 このような例の後、読者がRACIマトリックスを使用する可能性についてより完全な全体像を持つかどうかはわかりません。