しかし、すべてが一度初めて起こります。 今、これは他人に不平を言って批判する理由を与える私のチャンスです。 カットの下-ボーナスよりも非難するのが好きな理由を説明しようとしています。
実際のタスク：
実部門の小規模企業の2つのIT指向部門のボーナスシステムを開発します。
ディビジョン1-条件付きで2番目のテクニカルサポートライン。 同社には適切なシステムの動物園があり、従業員は非常にユニークです。 すなわち ほとんどの場合、従業員Aは従業員Bの仕事を完了できません。
部門2-プロジェクトオフィス。 最初から作成。 ITプロジェクトの実装のためのユニバーサルRPの存在を前提としています。 実装自体はコンサルティング会社が実施する必要があります。
友人の助けを求める試みは、多くの結果を生みませんでした。 一杯のコーヒーに関するすべての会話は、原則として、2つの結論で終了しました。
a）既知の評価パラメータのほとんどは、無意味であるか、主観的であるか、測定が困難であるか、評価者または評価者が操作する能力を持っています。
b）特定の従業員の真に傑出した（ほとんどの場合単一の）結果は、企業で利用可能なKPIの範囲に「移行」することが不可能なことがよくあります。 適切な基準はありません。 そして、マネージャーはそのような従業員のために「ボーナスに対するプレミアム」を打ち負かさなければなりません。 そして、これはリーダーシップが正義の鋭い感覚を持ち、彼らの愛する人のためではなく報酬を組織することに時間を費やすことを怠らない場合のみです。
私のITでのキャリアでは、KPIシステムにまだ出会っていません。これは主観的なものではないと言えます。 これに対する見返りとして、私の先導者は常に先入観なく、報酬の問題を解決しました。 私は同僚のために話をしませんが、私は間違いなく苦情ではありません。 しかし、誰もがそれほど幸運ではないのではないかと思います。 したがって、リーダーの道徳的安定性のテストではなく、従業員の仕事を可能な限り客観的に評価するものを開発したいと思います。
残念ながら、タスクのコンテキストでは、KPIで使用できる適切なパラメーターを見つけることができませんでした。
- 終了したタスクの数は？ 私の経験では、この種の組織の場合、リクエストの数は密集しているか空です。 さらに、ITスペシャリストがユーザーと直接連絡を取ると、このパラメーターを操作するリスクがあります。
- タスクを完了するための締め切り？ パラメータ自体は非常に主観的であり、ユニークな専門家の大部分でこの主観性が増加します。
- ユーザー満足度？ 小さな会社では、これは多くの場合、個人的な関係の問題であり、それ以上のものではありません。
したがって、この質問をまったく異なる視点から見ることをお勧めします。 この場合、「従業員に報酬を与えるのはなぜですか？」という質問は、「従業員を罰するのはなぜですか？」に変わります。
以下は、金銭的処罰に値する不快な状況の簡単なリストです。これは、私の実務と同僚の実務にありました。
- 重大なアーキテクチャエラー（たとえば、サーバー上ではなくローカルマシン上で実行されるビジネス向けサービスの開発、関連システムの専門家との調整のないソリューションの開発）。
- 情報を隠蔽し、企業で不可欠になりたいという欲求（たとえば、実行可能モジュールでのユーザーパスワードの使用、不十分な品質のドキュメント）。
- 退屈な日常業務の実施の失敗（例：プロトコル、指示、文書の一般的な作成、日常的なメンテナンスの実施）;
- バックアップとデータ損失を伴うショール。
- 適切なテストなしの製品での不正な計算、ユーザーとの調整なしの計算。
- 意思決定や一般的なコミュニケーションの問題についてユーザーに通知しません。
私の意見では、TCの枠組みにおける減価償却は、次のように編成することができます。
- 雇用契約の下では、従業員の報酬は給与と賞与の2つの部分で構成されます。
- 起こりうる「間違い」とその「コスト」のリストは事前にまとめられています。
- デフォルトでは、従業員に100％のボーナスが付与されます。
- 従業員が推定期間内にミスを犯した場合、それに応じてボーナス部分の額が減額されます。
私が見るKPIテーマと比較したこのアプローチの利点は何ですか：
- 大きな開発時間は必要ありません-パラメーターのバランスを取る必要はありません。 私たちの正義の例によれば、ボーナス部分の月額の範囲内で吸収と追加の原則を使用できます。 もちろん、特に血に飢えている人は、結果として生じる量を完全に追加し、「スミアリング」するアメリカのアプローチをより長い期間使用することができます。
- 状況の変化に容易に適応できる、より柔軟なシステム。 うつ病のリストは、新しい問題が特定されると拡張できます。 報告期間中に従業員が「価格」でリストにない何かをした場合、私たちは彼が幸運であり、罰金を課さないと信じています。 同時に、新しい段落を追加してリストを更新します。 仕事は人からお金を奪うことではなく、将来同じ間違いを避けようとすることです。 差別化されたスケールを使用することができます-エラーの「価格」を繰り返すと増加します。
- 必要に応じて、このスキームにKPIで使用されるすべてのパラメーターを「裏返し」で入力できます：閉じられていないタスクの割合が100-Xを超える場合、少なくともXの閉じられたタスクの割合に対するボーナス->非難など
- 評価にパラメータを適用する機能。測定には非常に時間がかかり、これにスポットチェックを使用します。 たとえば、技術規制のコードコンプライアンス。 スポットチェックでKPIを作成するのはどういうわけか公平ではありませんが、場合によっては非推奨にすることもできます。
- 問題のある領域へのユニットのヘッドの焦点のシフト。 ユニットで同じタイプのエラーが繰り返し発生する場合-これは、プロセスの編成の有効性について考える機会です。
さらに、品質が優先される領域のKPIには個人的な嫌悪感があります。 最初は、このシステムのメッセージはまったく正しくありません。 私にとって、KPIに結び付けられたボーナスシステムは、雇用主から従業員への次のメッセージのように見えます。
私たちはあなたが平凡な仕事をすると仮定しています。 KPIの助けを借りて、あなたはこれがそうではないことを証明する機会があり、あなたは仕事を効率的に行っています。 それを証明してください！
プレミアムパーツがデフォルトで全額計上され、その後マイナスになった場合、同じ入力で意味がわずかに変わります。
私たちはあなたが仕事を効率的に行っていると仮定します。 それにもかかわらず、私たちはあなたをテストします、これに備えてください。 がっかりさせないで！
無実の推定のそのような問題が判明しました。
そして、そのようなトピックに直接触れる場合、そのようなトピックにどのように反応しますか？