mboの基本原則。 ターゲット管理システム（MBO、PM）

SCIMソリューション

構築する方法 制御システムビジネス関連の目標に焦点を当てています。 チームの調整を達成し、経営陣と一般の従業員からの結果に焦点を当てる方法。 ビジネスにおける計画および予測システムの効率を改善することはどういう意味ですか。

ビジネスソリューション全体の説明

想像：

会社「A」

ビジネスでは、経営の規範やルールのシステムはなく、経営上の意思決定を行い、結果が出るまでその実施を監視するという安定した文化はありません。 新たなタスクは十分に予測されておらず、緊急時に発生し不可抗力となることが多く、「問題」の定義により適しています。

安定したアルゴリズムや意思決定ルールはありません。 多くの場合、決定は準備されていません。「状況に応じて」、「時間の問題で」、「現時点で」入手可能な情報に基づいて決定する必要があります。 情報の収集は難しく、体系化されていません。 行われた決定の質は低いです。

意思決定の実行の監視は、マネージャーが特定の各タスクを個別に処理する「手動モード」で行われることがよくあります。 またはそうではなく、タスクのパフォーマンスが問題になります。

ビジネスのリーダーは常に人的要因に依存しています。 優秀な労働者が足りません。 そして、それらが存在する場合、彼らは常に賃金の水準と労働条件に不満を持っています。 会社でのタスクの実行とプロセスの機能は、許可された従業員の性格に直接依存しています。

ビジネスの各ユニット/機能には、仕事のルールについての独自のアイデアがあります。このため、緊張と対立が絶えず発生します。 多くの場合、これらの競合は破壊的です。 調整と全体的なパフォーマンスが低下します。

上記のすべては、ビジネスへのストレスの増大につながり、不確実性の絶え間ない状況で機能することを余儀なくされます。 全体的な結果はほとんど予測できません。

株主との取引において、マネージャーはより正当な立場を取り、現状を正当化しようとします。 株主は不満を持っています。

会社「B」

ビジネス管理システムはデバッグされ、その有効性に焦点が当てられています。 同社には、特定の結果を得るためのタスクとプロセスの目標設定と管理のためのアルゴリズム、規範、ルールの複合体があります。 対応する企業文化が形成されています。 すべての機能プロセスは形式化され、相互に調整されます。 ビジネスの不確実性の状況は最小限に抑えられます。

管理と意思決定の原則とアルゴリズムは、チームメンバーにとって明確で理解しやすいものです。 決定は合理的かつ便宜の原則に基づいて行われます。 意思決定に必要な情報の収集とその品質の評価は、システムで詳しく説明されています。

すべての従業員は結果指向のシステムの一部です。 チームメンバーは明確に調整されています。 対立や論争は建設的であり、より良い解決策をもたらします。

実行は必要な制御下にあります。 パフォーマンス低下のリスクを最小限に抑えるのに十分であると同時に、過剰なリソースを必要としません。

結果を計画し、予測します。

株主とのコミュニケーションは、計画とその実施について建設的に話し合う方法です。

もちろん、すべての事業主やトップマネージャーは自分の会社が会社「B」に似ていることを望んでいます。 しかし、これはどのように達成できますか？

B社は、ビジネス関連の目標に焦点を合わせた管理システムを構築し、チームの調整を達成し、経営陣と一般従業員からの結果に焦点を合わせ、次のおかげでビジネスにおける計画および予測システムの効率を高めました。

• 地方分権化制御システム、
• 普及しているタイプのコントロール- 出口制御,
• 方法論 MBO（目標管理）,
• 方法論 プロジェクト管理.

このソリューションが専念しているのは、これらの原則と管理方法、およびそれらの実装の実際的な側面です。

管理と制御の種類（極端なモデル）

ビジネスにおける権限の委任の問題は、意思決定システムの設定とその実装の監視に関連しています。 このタスクは繊細で複雑であり、各組織でそのソリューションは独自の進化の道をたどります。 当然のことながら、ビジネスが大きくなり、分岐が進むほど、タスクを設定および監視するためのシステムをセットアップするタスクが緊急になります。

中央集権化-地方分権化

権限の委任は、会社における権力の集中化の程度に直接関係しています。 「中央集権化」という用語は、意思決定が片手に集中している程度を指します。 ビジネスが若い間、マネージャー/所有者だけが何らかの方法でほとんどの決定を下します。 これは、権力の高度な集中化を意味します。 ビジネスが大きく/複雑になるほど、意思決定が難しくなり、ペースとコストが高くなります。 過度の中央集権化は事業開発の妨げとなり、リーダーは権力を共有し、中央集権化を希薄化する必要があります。 各組織には、地方分権化への独自の道があります。

一元化された組織上級管理職が重要な決定を下すために必要な権限のほとんどを保持している組織です。

分散型組織-これらは、権限がより低いレベルの管理で分散されている組織です。 高度に分散化された組織では、中間管理職は特定の活動分野で非常に大きな力を持っています。

利点 中央集権化:

1. 一元化により、管理の制御と調整が改善され、経験の浅いリーダーによる誤った決定の数と規模が減少します。
2. 一元化された管理は、最終的な責任は彼らにあるので、リーダーシップの経験と知識の広範な使用を意味します。

利点 地方分権化:

1. 大規模な組織では、意思決定の複雑さが増しています。 効果的な意思決定を行うには、大量の異種情報が必要です。 これは、権限の委任と地方分権化の結果としてのみ可能になります。
2. 地方分権化は、発生した問題に最も近く、したがってそれを最もよく知っているリーダーに決定を下す権利を与えます。
3. 地方分権化はイニシアチブを刺激し、個人が組織と同一視できるようにします。
4. 地方分権化は、若いリーダーがキャリアの早い段階で重要な決定を下せるようにすることで、若いリーダーがより高い地位に就く準備をするのに役立ちます。

一元化された組織の本質は、意思決定プロセスとその実装を分離することです。トップマネージャーが意思決定を行い、ミドルマネージャーがそれらを送信して合意し、従業員が実行します。 研究と管理理論の研究における比較分析は、集中化された組織は通常コストがかかることを示しています。 彼らは市場の変化に適応するのが遅く、変化する顧客のニーズにあまり反応せず、競争の激しい環境で効果的に運営するための創造性とイニシアチブに制限があります。

管理レベルが少ない組織は、一元化された階層構造よりも柔軟で動的です。 より専門的に訓練された管理者の活動のための条件が作成され、通信のネットワークが減少し、管理レベル間の管理上の距離が減少します。

分散型の構造には多くの支持者がいます。 ただし、地方分権化は、統制を廃止することを意味するものではありません。 分散型アクションを適切に評価できるように、制御は非常に効果的でなければなりません。

「入口」による制御-「出口」による制御

タスクの実行の設定と監視の詳細に従って、2つの極端なモデルを区別できます。「開始時」の制御と「終了時」の制御です。

「入り口で」コントロール-部下/実行者による割り当てられたタスクの実行の構造と性質に深く没頭する必要があります。 それは、一定の暫定的管理と、必要に応じて、頭の側での暫定的決定の採用への介入を前提としています。 極端なケースは、運用上の決定を含むすべての決定がマネージャーによって行われ、部下/実行者が手動で制御されている場合です。 この場合、リーダーは「マイクロマネジメント」に従事しているとよく言われます。 実行は、意思決定時にタスクを「入力」することから、それを達成する方法、管理者による特定の命令およびアクションまで制御されます。

出口制御-この場合のマネージャーの主なタスクは、請負業者に割り当てられたタスク（KPI）の達成の効果的で明確な測定可能な指標を開発することです。これは、目標の達成の成功の指標として機能します。 部下/パフォーマーの活動の監視は、実行の最後、つまり「出口」で彼らに設定された目標パフォーマンス指標の達成を監視することによって実行されます。 言い換えれば、この場合、マネージャーは部下の目標を策定し、部下自身がこれらの目標を達成する方法を決定します。 中間管理の介入は最小限です。

最初のケースは、マネージャーに実行エラーのリスクを最小限に抑える感覚を与えます（誤った決定を行う-タスクを完了する方法）。 このモデルの支持者は、「うまくやりたいのなら、自分でやりなさい」とよく言います。 ただし、このモデルには、個人的なリソースとリーダーの個人的な関与が必要です。 これが欠点です。 リーダーのリソースは常に限られているからです。

2番目のモデルは、パフォーマーに目標と運用スペースを達成する方法でより多くの自由を与えます。 マネージャーにとって、2つの最も重要なタスクがあります：1）タスクを正しく定式化し、パフォーマーのためにそれを達成するためのパラメーターを決定します。2）適切な資格を持つパフォーマーを選択します。

これらのモデルは極端/極端です。 実際には、ある方向または別の方向にシフトする「混合」モデルがより頻繁にあります。 また、タスクの優先度と重要性に応じて、何らかの形式を使用することもできます。優先度が高く、重要でリスクが高い-「入り口で」制御する-実行の注意と制御を強化し、リスクを軽減します。優先順位と重要性-むしろ「終了時」を制御します。

個人的にどのタイプのコントロールが私に適しているかを尋ねられたら、私は答えます-これは「途中」のコントロールに根本的なバイアスがある「混合」タイプのコントロールですが、コントロール（および調整）する機能もあります、必要に応じて）特定の結果を達成するために実行されるアクション。

目標管理（MBO）

目標による管理（eng。 目標管理、MBO）-高レベルの戦略から運用上の戦術まで、組織の相互に関連し、相互に依存するビジネス目標の階層（ツリー）の形成。 さらに、必要に応じて、目標の達成、目標の達成の監視と評価、調整の責任者の任命によるこれらの目標の管理。

MBOは、ビジネス管理の体系的かつ方法論的な原則です。 彼は、組織の管理が相互に関連し、相互に依存する目標のシステムに基づいていると想定しています。 通常、会社のこのようなルールは、計画期間（月、四半期、年）の開始時に、高次の戦略目標に直接関連する会社、部門、部門、およびマネージャーに特定の目標と目的が設定されていることを前提としています。 （そしてしばしばそれらから生じる）、ボーナス、ボーナスおよび他の動機付けの要素が依存するパフォーマンスに依存します。 広義のMBO手法とは、会社の主要な目標の定義と、トップダウンベースの目標ツリーを介した組織構造および組織の管理者間のそれらの分布です。

目標ツリーを構築する場合、下位レベルのすべての目標は、上位目標の達成に向けて機能します。 したがって、会社のすべての活動の戦略的目標への全体的な従属、会社の部門および事業領域の作業の一貫性が達成されます。

MBOシステムが解決しなければならないもう1つの重要なタスクは、ビジネス全体とそのすべての構成単位の両方の俊敏性と管理性を、階層全体から従業員に至るまで向上させることです。 目標を達成するための明確な基準を開発することで、全体的な調整が改善され、特定の結果に焦点を合わせると、組織と特定の各マネージャーの両方の有効性が高まります。

多くの教科書に記載されている古典的なバージョンでは、MBOを適用するときに、計画中の目標ツリーが署名され、組織の従業員のレベルまで詳細に記述されていると想定されています。 ただし、MBOを使用した私の経験では、そのようなシステムは煩雑になり、リソースを大量に消費し、管理が困難になることが示されています。 同時に、MBOシステムを使用するという主要な目標であるビジネスの俊敏性の向上は、達成されるだけでなく、非常に複雑です。

私たちの実践では、マネージャーと機能リーダーの戦術レベルまでの目標のツリーを構築しました。 同時に、一般の従業員の運用タスクのレベルはシステムから除外されず、彼らの計画は彼らの責任の領域に従ってマネージャーと機能リーダーに委任されます。 マネージャーと中堅幹部は目標を設定し、従業員がビジネス目標を達成するために彼らを関与させるように動機付けます。 彼らのレベルでは、組織の実行者/従業員の形でリソースが割り当て/合意された実行のために、目標を達成し、運用タスクに分解することを計画しています。

その結果、組織のビジネス目標ツリーの構造に従って単一の運用計画が作成され、組織内のすべての目標と目的の一貫性と相互接続がすべてのレベルで達成されます。 これにより、管理の柔軟性が高まり、ビジネスの俊敏性を高めるための前提条件が作成されます。

このアプローチによって開発されたビジネスユニットとしてのマネージャーの主な特徴は、ビジネスの戦略的目標への方向性です。 結果に焦点を当てる.

MBOシステムの利点/利点

• 組織内の計画システムを改善する。 MBOは、マネージャーが結果の観点から考えることを奨励しています。 アクションプランを作成し、目標を達成するためのリソースを提供し、不確実な領域について話し合い、ローカライズするには、明確な計画が必要です。
• 各リーダーが自分の目標と組織全体の目標の両方を明確に理解しているため、作業効率が向上します。
• このような状況では、誰もが目標を達成することに個人的な興味を感じるため、働く意欲を強化します。
• 最終結果を達成するための可視性。 その達成のための基準と時間枠は明確に定式化されています。
• 目標の透明性と整合性により、マネージャーと部下の関係を改善します。 通信システムの改善。
• 組織の各メンバーの作業を監視および評価するためのシステムを改善します（達成された結果に従って）。

MBOシステムのデメリット

• このプロセスにすべてのレベルのマネージャーを関与させずに、トップマネジメントのみが目標を設定するのが通例である組織の管理には適用されません。
• システムの開発と保守のための追加のリソースコスト。
• システムの不均衡：
  • 管理者は、不明確で非現実的な目標を解釈するのが難しいと感じることがあります。
  • 目標設定の問題：マネージャーは基準を引き上げる傾向があり、部下は過小評価する傾向があります。
  • 本当に意味のある目標よりも、測定しやすい目標の方が優先されます。

ビジネス目標の階層

MBOシステムでは、目標の垂直依存のシステム、つまり「目標のツリー」（「目標のピラミッド」）を構築することが重要です。 目標の垂直依存のアイデアを実装する主なタスクは、ビジネス目標とそれを達成するための計画プロセスを組織の階層レベルにリンクすることです。 組織のビジネス目標を達成するために、階層の個々のレベルのどの位置に、どのように、どのような順序で関与する必要があるかを見つける必要があります。

このような作業の結果は、いわゆる「目標ツリー」であり、組織内の階層のすべてのレベルの目標の明確な依存関係が表示されます。 クラシックバージョンの目標の「ツリー」には、次の必要な要素が含まれています。

• 戦略的目標;
• 戦術的な目標;
• 運用目標。

ダイアグラムを特定のビジネス構造の現実に近づけると、ゴールツリー（ゴールピラミッド）はほぼ次の形式になります（組織構造の複雑さとその中のビジネスレベルの数によって異なります）。

目的別の管理ツールとしてのプロジェクト管理

上で説明したように、MBO（Management by Objectives）は、会社の目標のツリーを上から下に作成し、これらの目標を達成するためのリソースを割り当て、管理し、調整するためのシステムです。 それぞれの目標は最終的で具体的です。 そして、それはプロジェクトの特徴を持っているので、プロジェクトと見なすことができます。 このようにして、プロジェクトは、目標による管理システムのコンポーネント、ツールと見なすことができるようになります。

「プロジェクトは、独自の製品、サービス、または成果を生み出すために設計された一時的なベンチャーです。 プロジェクトの一時的な性質は、どのプロジェクトにも明確な開始と終了があることを意味します。 プロジェクトの目的が達成されると、完了します。 または、プロジェクトの目的が達成されない、または達成できないことが認識されている。 または、プロジェクトの必要性がなくなった。」[プロジェクトマネジメント知識体系ガイド（PMBOKガイド）-第5版。 -プロジェクトマネジメント協会、2013年。]。

プロジェクトの特徴：

1. 特定の結果に焦点を合わせます。
2. 制限時間。 プロジェクトはいつか終了する必要があります。
3. リソース管理：人、財政、時間。
4. チームのモチベーション。

プロジェクト管理：プロジェクトの目的の効果的な達成を目的とした、プロジェクトの人的、財政的、物質的および技術的リソースの計画、編成、および管理。

プロジェクト管理については、プロジェクト計画、プロジェクト予算を作成し、プロジェクトリスク管理を実施します。

この簡単な説明から、プロジェクトは、「目標」-「プロジェクト/プロジェクトの目標」という同義語ペアの会社の目標ツリーの要素であるコンポーネントと見なすことができることがわかります。

PM（プロジェクト管理）システムとMBO（目標管理）システムの共通部分があります-重要なパラメーターで-特定の結果に焦点を当てています。 さらに、他のパラメータによる2つの管理システムの組み合わせは、計画、リソース管理、参加者のモチベーションという有機的に発生します。

循環プロセスが多い企業で、プロジェクト管理手法をどのように使用できるでしょうか。 プロジェクトとビジネスプロセスの主な違いは、プロジェクトが1回限りのアクティビティであり、周期的なアクティビティではないことです。 ただし、最近では、設計アプローチがプロセスにもますます適用されるようになっています。 特に、当社では、プロセス（財務管理、人事、リスク管理、コンプライアンス管理、経理など）をプロジェクトにまとめ、限られた期間（1年半）でプロセスの具体的な目標を指定しています。 1年）。 これは、説明されているビジネスプロセスや規制に代わるものではありませんが、それらを補足するものです。 プロジェクトの調整と管理は、ビジネスプロセスを含め、説明されているアクティビティを考慮して実行されます。 そして、規制、ビジネスプロセス、品質基準への準拠は、典型的な機能（プロセス）の目標になります。

したがって、私たちは会社の経営においていくつかの方法論の原則を組み合わせました。

会社経営の方法論的原則の組み合わせ

私たちの会社におけるいくつかの方法論の原則の組み合わせの実例を示します：

• MBO-「目標管理」;
• BPM- "業務工程管理";
• 午後- "プロジェクト管理"。

これらの原則の使用の合流点で、会社は管理システムの次の重要なコンポーネントを受け取ります

I. MBO-PM

• 会社の戦略的で高レベルの目標の決定。
• 上から下への「目標のツリー」の開発。 目標ごとの管理システムを使用して、会社は、会社の戦略的目標を達成するために、目標のツリーと、会社のすべての目標の従属/合意/調整のシステムを受け取ります。
• ツリーの各目標は、特定のプロジェクトの目標になります。
• 目標を達成する責任があります-対応するプロジェクトのマネージャーになります。
• ビジネス目標を達成するためのリソース（人的、財務的）の割り当て、それらの調整および管理は、プロジェクト管理手順のフレームワーク内で実行されます。

II。 MBO-BPM

• 目標ツリーの一部としてのビジネスプロセスの説明と開発。 典型的な反復プロセスは、会社にとって便利な表記法で説明されています。
• 規制の策定。 記述されたビジネスプロセスに基づいて、内部の地域の規制文書および規制が作成されます。

III。 PM-BPM

• リソース管理（財務、人）。 プロジェクト管理のイデオロギーにより、会社全体（会社のすべての目標とプロジェクト）で統一された財務および人的資源管理プロセスの説明、方法論、および実践のプロセス規制部分に組み込むことができます。
• プロジェクト管理におけるリスク管理は会社全体で統一され、会社の事業全体のリスクマップを作成することができます。

IV。 MBO-PM-BPM

• 目標の方向性、特定の結果。 戦略的目標の達成に対するすべてのレベルでの会社のすべての活動の従属。
• スタッフのモチベーション。 組織の階層の任意のレベルで各従業員の意識的な結果に焦点を当てることによる動機付け。 スタッフのインセンティブの機会と、ボーナスの支払いと給与の変動部分による支払いへの柔軟なアプローチ。 システムでのパフォーマンスを評価し、最も効果的な従業員を刺激することにより、各従業員の有効性を評価します。
• 会社の運営計画を作成します。 会社の「目標のツリー」のすべてのコンポーネントを達成するための計画の統合に基づいています。
• 予算の作成と承認。 すべての方法論の原則の合流点で、すべての活動と規制を考慮に入れて、目標（プロジェクト）を達成するためのすべての計画を作成した後、プロジェクトの予算計画を取得する機会があり、その結果、統合された企業予算が得られます。

MBOのやる気を起こさせるスタッフ

目標による管理の概念は、人々が自分に何が期待されているかを知っていて、自分の個人的な目標を会社の目標に関連付けることができれば、パフォーマンスが向上するという仮定に基づいています。 組織の目標は、指示や指示を配布することではなく、協力を確保し、業績に焦点を合わせて組織のビジネス目標を達成するためにすべての従業員を関与させることによって達成されます。

経営研究者は、特定の目標を持つ従業員は、単に職務記述書に従って働く従業員、目標が定義されていない従業員、または要約で「最善を尽くす」ように求められている従業員よりも生産性が高いと主張しています。 MBOシステムの存在そのものによるこの動機付け効果についてはすでに説明しました。 ただし、間接的な動機付け効果に加えて、MBOシステムには、会社の従業員に対する追加のインセンティブ措置と条件を追加する必要があります。

これらには以下が含まれます：

1. 設定された目標の達成に基づく直接インセンティブボーナスプログラム。 実行の目標を設定するとき、これらの目標を達成するためにボーナス支払いを割り当てることは論理的です。 目標の複雑さ、目標の重み、および実装の程度を考慮に入れます。 ボーナスなどの支払い、または賃金の変動部分の支払いに使用します。
2. 職員の認証/評価における管理者の有効性の評価。 したがって、明確な基準を備えた目標システムの存在により、目標の達成の結果によって管理者の有効性を評価することがすでに可能になっています。 そして、それに応じて、より効果的なマネージャーのためのより多くの好みを与えます。 このアプローチは、効率のスケールで会社のマネージャーの差別のない差別化を客観的に生み出します。 その結果、効果的なものが求められ、より多くを稼ぎ、キャリアラダーをより早く成長させます。
3. 会社の目標ツリーの実装に大きく貢献する従業員のための特別な条件。 たとえば、当社では、プロジェクトマネージャーは職場に立ち会う必要はありませんでした（必須の会議と報告イベントを除く）。 彼らは労働時間を追跡していませんでした。 彼らに必要なのは、彼らに割り当てられた目標/タスク/プロジェクトの遂行だけでした。 彼らがどのモードで行うかは彼ら自身のビジネスです。 管理者は、目標を達成する方法を決定し、リソースを選択し、それらを管理する上で、重要な自律性と行動の自由を持っていました。

ビジネスはMBOをハッキングします

このセクションでは、目標ベースの管理システムの実装と実装で発生した問題と、それらをどのように解決したかについて説明します。

機能活動をプロジェクト活動に移す方法

問題の説明。 N社が多様なプロジェクトのポートフォリオを維持していると想像してみてください。 それは、指針として、プロジェクト管理方法論を採用しました。 私たちが覚えているように、プロジェクトには普遍的な特性があり（上記を参照）、プロジェクトの時間的有限性などのパラメーターが含まれます。

同時に、プロジェクト指向の企業を含むほとんどの企業では、プロジェクトベースではなく、時間的に有限ではなく（周期的）、機能的であり、管理理論の用語で説明されている活動の重要な層がありますプロセスとして。

これらの機能領域の活動には最終的な目標はなく、社内で特定の機能を実行します。その実行のために、反復アルゴリズムに従って、活動が定期的、周期的に編成されます。 例えば：

• 会計-会計および税務報告;
• マーケティング-会社の製品とサービスを宣伝するためのシステムの組織。
• 財務部門-会社の財務管理、予算管理、財務計画;
• IT部門-会社の活動のITサポート。
• 人事部門-会社に人材を提供し、効率を高めます。
• NS。

管理（プロジェクト/プロセス）におけるこの方法論的および方法論的な不一致は、共通の管理アプローチを構築し、会社の共通の管理原則を開発するときにいくつかの不便を引き起こします。

だから質問！ この場合、機能的なプロセスアクティビティをどのように処理しますか？ 機能活動をプロジェクト活動に移す方法は？

回答：主なアイデアは、プロセスアクティビティを時間間隔に分割し、これらの時間間隔の目標を設定することです。

上で説明したように、プロジェクト管理の原則の使用は、目標方法論による管理のフレームワーク内で会社の活動を統合するための非常に便利なツールです。 説明されている問題の解決策は、特定の測定可能な目標を有限期間にわたって会社のプロセスに割り当てることです。

当社では、各機能プロジェクトカードの説明に3種類のプロジェクト目標が含まれていました。

1.典型的な機能目標。これは、この特定の機能の一般的な目標です。 目標は意味のある一定であり、すべての期間（毎年）の機能に対して繰り返されます。 このような目標を立てるには、この機能がビジネスにとってどのような目的であり、ビジネスにとってどのような価値を生み出すのかを考える必要があります。 これに基づいて、典型的な目標を策定します。

典型的な特殊目的機能の例：

1 ECコンプライアンスは、「コンプライアンスに関する専門家委員会」の合議体です。
2PC-合議体「プロジェクト委員会」

2.期間を目指します。いくつかの特定のタスクを実行するために、それは現在の期間ではありません（何か新しいものの開発または形成）。

機能の期間の目標の例：

1KM-クライアントマネージャー
2 KPFP-機能ユニットのプロジェクトのカード
3RMS-リスク管理システム

3.すべてのプロジェクトに共通の典型的な目標。これらは、すべての機能プロジェクトで同じであり、すべての期間で繰り返される目標です。

すべてのプロジェクトに共通する典型的な目標：

1コグ-eng。 売上原価または売上原価。 一般的な語彙：売上原価。 プロジェクトの費用。

目標とその達成基準を策定した結果、今後の全期間における機能ユニットの作業に関する管理文書（（機能）プロジェクトのカード）が得られます。 プロジェクトカードのすべての定式化と詳細は、研ぎ澄まされ、考え抜かれ、すべての利害関係者と合意されています。 原則として、このプロセスで最も興味があり、活発なのは、機能キュレーター（会社のトップマネージャーの中から）とFD（プロセスの所有者および将来のプロジェクトマネージャーとして）です。

すべての利害関係者によって合意された（機能的な）プロジェクトカードは、会社の共同執行機関であるプロジェクト委員会によって承認されます。

さらに、機能プロジェクトの目標の実装の制御は、通常のプロジェクトと同じアルゴリズムを使用してプロジェクト委員会によって実行されます。 現在のモードでは、プロジェクトの進捗状況についてプロジェクト委員会に定期的に報告します。 プロジェクトの終了時（選択された期間）に、開発された基準に従って目標の達成の評価が実行されます。

プロジェクトを使用してビジネス機能を作成する方法

会社は需要があるかもしれませんが、ビジネスの成功した機能のために重要な特定のプロセスをまだ確立していません。 タスクは、適切なシステム、つまりビジネス機能を確立して起動することです。 これを行うための最良の方法は何ですか？ これが別のプロジェクトを開始することは非常に便利であり、その結果が必要なシステムになるはずです。 いわゆる開発プロジェクト。

なぜ便利なのですか？ まず、必要なビジネスシステムを取得するという目標は時間的に有限です。 第二に、プロジェクトの目標を規定するとき、私たちは望ましい結果の構造を考えます。 第三に、このプロジェクトを管理することにより、実行中およびプロジェクトの特定の目標を管理する機会が得られます。

これは、次のようなプロセスと目標を持つそのような部門の形成方法です。

• 人事部門;
• リスク管理部門;
• プロジェクトオフィス;
• フロントオフィス;
• マーケティング部;
• コンプライアンス部門。

また、特定のビジネスプロセスとシステム手順の形成と最適化のために、プロジェクトを個別に開始することもできます。

• 文書管理システム。
• 別のプロジェクトとして、社内で機能プロジェクトを形成するシステム（CPサポート）も立ち上げました。一定の資格を持つ従業員の作業費と工数を固定します。 彼のLRによって要約されます。

このアプローチのポイントは、プロジェクトの最後に、会社が機能するシステムを受け取ることです。 最終的にはビジネスプロセス、または一連のビジネスプロセスと会社の規制になります。

そのようなプロジェクトの顧客は、会社の特定の活動分野の形成と発展に関心のある株主、会社の共同体、会社のトップマネージャーである可能性があります。

方法を示す

例。 機能的なプロジェクトを形成するためのプロジェクトカード。

ボーナスプール、ボーナスプールの予約と支払いは、非常に繊細で感情的な手順です。 この問題には、最初に、プロジェクト管理システムの最も重要な2人の参加者の潜在的な利益相反が含まれています。
-プロジェクトマネージャーは当然、より大きなボーナスを望んでいます
-プロジェクトの顧客（コスト削減にも関心のある株主またはその代表者）-より少ない支払いを望んでいます。

プロジェクトのボーナスを決定するための客観的な基準とアルゴリズムがない場合、体系的な利害の対立が発生します。 これは、ボーナスの不必要で非建設的な取引を引き起こします。 そのような紛争の結果は深刻であり、特に、彼の意見では、不当に小さいボーナスに腹を立てている国会議員の動機付けが含まれます。 さらに、この質問は、計画されたボーナスプールを割り当てる段階と、プロジェクトの終了時にそれを計算し、プロジェクトの結果に基づいて実際の支払いを割り当てるときの両方で敏感に発生します。

この問題の解決策は、ボーナスプールを割り当て、計算し、支払うための明確なルール/アルゴリズムと手順を開発することです。 そのような決定を行う際には、主観的な要素を可能な限り除外する必要があります。 ルールは事前に合意し、プロセスのすべての参加者が理解し、プロジェクトを開始する前に承認する必要があります。

質問を2つに分けます。

1. 計画されたプロジェクトボーナスの計算方法これは、プロジェクトの開始時に割り当てられます。 計画されたプロジェクトボーナスは、発売前にプロジェクトカードに割り当てられた最も重要なパラメータです。 計画されたボーナスは、プロジェクトマネージャーがその実装を引き受ける動機付けのインセンティブです。
2. 実際のプロジェクトボーナスの計算方法プロジェクト目標の実施結果に基づく。 実際のプロジェクトボーナスは、プロジェクト目標の実施結果に基づいて計算されたボーナス支払い額です。 すべてのプロジェクトの目的が守られ、閉じられた後に任命されます。 実際のボーナスプールは、完了時にプロジェクトチームに支払われる実際のボーナスです。

プロジェクトの計画されたボーナスプール

プロジェクトの現在の目標を達成するために計画されたボーナスプールは、会社にとってのプロジェクトの戦略的重要性、その実装の客観的な複雑さ、およびプロジェクトのリスクに基づいて確立されます。

私たちは開発しました 微積分の原理ボーナスプール。 まず、プロジェクトは7つの主要なパラメータに従って評価されます。

1. プロジェクトのコンポーネントの変換
2. プロジェクトの不確実性レベル
3. プロジェクトの目新しさ
4. 長期プロジェクト
5. プロジェクトの展望
6. プロジェクトが事業の業績に与える影響
7. プロジェクトのリスク

評価は、「なし」から「非常に高い」までの5段階で行われます。

方法を示す

リストされたパラメーターは、ボーナスプールを計算するときに異なる重みを持ちます。

方法を示す

これらのプロジェクト基準に基づいて、電子ボーナスプール計算機を開発しました。

計算機が与える一般的な設計要素は- 最初の要因これはボーナスプールのサイズに影響します。

GKVはプロジェクトマネージャーグレードシステムを使用しました。 MP（プロジェクトマネージャー）のグレードが高いほど、コストが高くなり、重要度/複雑度の比率が1つのプロジェクトのボーナスプールが大きくなります。 したがって、プロジェクトマネージャーのグレードは 2番目の要因これはプロジェクトボーナスのサイズに影響します。

そして、ボーナスを計算するときにもう1つのニュアンスが適用されました。 会社の機能的な従業員がプロジェクト管理を引き受け、その主な仕事がプロジェクトではなく機能的な責任である場合、彼にとってボーナス計算はプロジェクトオフィスのPMよりも低いレートで実行されます。 これは、MTと機能的な従業員をやる気にさせるという一般原則によるものです。 機能的な従業員の収入の給与では、変動部分はより小さな部分を占めます。 プロジェクトマネージャーの場合、主な収入はプロジェクトからのボーナスだけです。

したがって、プロジェクトマネージャーの役​​割を果たす従業員の機能プロファイル（プロジェクトオフィスまたは機能（プロセス）ユニットへの所属）は次のようになります。 第三の要因これはプロジェクトボーナスのサイズに影響します。

方法を示す

プロジェクトの実際のボーナスプール

実際のボーナスプール（プロジェクトマネージャーとプロジェクトチームがその実装の結果に基づいて実際に受け取る金額）は、次の原則と計算式に基づいて決定されます。

1. ボーナスプールは、プロジェクトの目標の実施結果に基づいて支払われます。
2. ボーナスプールは、プロジェクトの目標の重みに応じて、プロジェクトの目標に分配されます。
3. 実際のボーナスプールは、プロジェクト（プロジェクトカード）の全体的な実装の程度が80％以上に達した場合にのみ形成されます。
4. プロジェクトの実施の程度は、プロジェクトの目的の実施の程度の合計として計算され、プロジェクトの目的のスケールで重み付けされます。

   方法を示す

   例えば：

   オプション1：
   目標1：
   -プロジェクトの重量20％（VTs1）
   
   目標2：
   -プロジェクトの重量30％（VTs2）
   
   目標3：
   -プロジェクトの重量50％（VTs3）
   
   

   RP = VTs1 * SRTS1 + VTs2 * SRTS2 + VTs3 * SRTS3 = 20％* 120％+ 30％* 60％+ 50％* 95％= 89.5％RP = 89.5％-実際のボーナスプールが形成されます

   オプション2：
   目標1：
   -プロジェクトの重量20％（VTs1）
   -目標の実施度120％（СРЦ1）
   目標2：
   -プロジェクトの重量30％（VTs2）
   -目標実現度80％（СРЦ2）
   目標3：
   -プロジェクトの重量50％（VTs3）
   -目標実現度60％（СРЦ3）
   プロジェクト実施の推定程度（RP）：

   RP = VTs1 * SRTS1 + VTs2 * SRTS2 + VTs3 * SRTS3 = 20％* 120％+ 30％* 80％+ 50％* 60％= 78％RP = 78％-ボーナスプールは形成されません

5. 実際のプロジェクトボーナスプール（FBBP）は、プロジェクトのボーナスゴールプール（BPC）の合計として定義されます。

   FBPP = BPC1 + BPC2 + ... + BPCN

6. プロジェクト目標（BPC）のボーナスプールは、対応する目標（SRP）の実装の程度、プロジェクト内の目標の重み（CC）、およびプロジェクトの計画ボーナスの値（PBP）に応じて形成されます。そして、次のように決定されます。
   • СРЦ:)