SAP HCM実装プロジェクトの準備

このメモは、SAPでも非SAPでも、新しいシステムの導入を検討し始めている企業、顧客を対象としています。 私は、SAPだけでなくコンサルティングの部分で、顧客側で何とか仕事をすることができました。これにより、双方の問題を少し広く理解できます。 また、問題、またはタスクと呼びましょうが、どの国でも同じです。 アメリカ、ノルウェー、ハンガリー、ロシアでのプロジェクトの仕事で判断できます。 専ら私の経験。



ほとんどすべての顧客は、プロセス、ワークフロー、および方法論を統一するシステムを導入するという主要なタスクを宣言しています。 外部インセンティブはコンサルタントの形でプロジェクトのフレームワークに表示され、プロジェクトの予算が限られているため、迅速に変更して統一する必要がある場合、システムの実装は統一の問題を解決する必要があります。 デフォルトでは、顧客はコンサルタントには存在しないベストプラクティスを期待しています。 正直に言うと、ベストプラクティスは、ビジネスが現在の状態にどのように成長したかです。 ある会社のプラクティスを別の会社に移すことはできません。これらはベストプラクティスではなく、その会社または他の会社のプラクティスです。 しかし、これは便利である。なぜなら、それはあなたが見ることができるか、むしろ覗くことができるからであるが、他の人によってどのように行われるのか。 人間の好奇心。自分で思いつかないときは、隣人にアイデアを求めて自分で改善してください。



プロジェクトの枠組みでは、コンサルタントはプロジェクトの目的に依存しており、ビジネスの統合を要求しています。 ビジネスは、自分自身で落ち着いて、それのために見知らぬ人にお金を与えるように自らを求めていることがわかります。 また、一度ジムに行きたいと思ったときもありました。支払いが済んだら、「noona to go」。 統一自体もあまり明確なプロセスではありません。 多くの企業、異なる機能、異なる管理階層を持つ大企業を想像してください。 簡単な例：数万人の従業員がいる大きな工場と、輸出用の製品の売り手がいる小さな会社。 そして、これはすべて、1つのプロジェクトボリュームのフレームワーク内にあり、統一されたプロセス、ドキュメント、およびテクニックが必要です。 一部の人にとっては、数、資金、期間を閉じることの有効性において最も小さな変化が戻ってくる一方で、まったく気付かない人もいます。 そして、前者の賞のいずれかの廃止は、異なる種類の発生で単純に行われますが、後者は売り手の動機を埋める可能性があります。 統一のため。



報告、特に内部報告は、庭の両側にある別の石です。 ビジネスでは、通常確立された形式でレポートが必要であり、コンサルタントが「曲がった形式でシステムから奇妙なダウンロードを行う」と言っています。 基盤と進歩の矛盾があり、通常、企業での文書管理の一般的な慣行が勝ちます。 物理ボリュームの証明書が毎朝テーブルのワークショップのヘッドにある場合、ヘッドが午前中にシステムを開き始めるまでシステムは役に立ちません。 欧米では、顧客が紙のレポートを作成する必要がある場合、この方法はあまり一般的ではありません。 人々はますます最新の技術で作業しているため、ペーパーレスワークフローが開発され、プロジェクトがより簡単に立ち上げられます。 もちろん、これは立法報告には適用されません。



方法論は、プロジェクトの最大量の作業です。 プロセスを統一する必要性についてよく話しますが、実際には、プロセスは統一に関する実際の作業の10％を占めています。 主なものは紙片と計算であり、多くの場合、これは法律の要件に関連していますが、プロセスは実際には法律によって規制されていません。 方法論により、さまざまな数量を計算するためのアルゴリズム、レポートおよび出力フォームに記入するためのルールを理解しています。 プロジェクトの入り口で、顧客は数字80 / 20、70 / 30、または統合の結果を測定する他の特定の数量で動作することを好みます。 一方で、これは単なるガイドであるため、支払いの種類がいくつになるかという違いは何ですか？ 一方、あらゆるレベルで、賃金基金とは何か、人件費とは何かを理解する必要があります（この概念は通常、賃金基金よりも広いです）。 私の理解では、理想的な統一はゼロになる傾向があり、法律とビジネスの目標に矛盾しない最大レベルに簡素化されます。



プロジェクトのフレームワーク内で、方法論の統一に関しては、税務会計、企業経済学、会計、および法務の分野から多くのHR関連の問題が発生します。 多くの場合、これらの領域には、高さから均一性を決定できる単一の所有者がいません。 各ユニットは独自のジュースで醸造され、同じ種類のウェイジタイプの議論で明らかになります（平凡な例はおforびしますが、これはすべてのSAP HCMプロジェクトで最も苦痛な場所です）。



西洋の実践では、このアプローチに出くわしました。 給与の主な部分-給与または関税があります。 その形成は、会計方法や仕事の性質に関係なく、従業員のすべてのカテゴリーに対して単一のアルゴリズムによって確立されます。 すべての部門は、この基本的な部分を同じように理解しています。 動機付けの部分（ボーナス、手当、追加料金）は、一般的な言葉（たとえば、「結果に対するボーナス」、「品質に対するボーナス」、「労働条件に対するボーナス」など）で呼ばれるいくつかの主なタイプの料金と、これらの内部の内容から形成されます発生額は各ユニットに残されています。 そのため、売り手の間の「結果の賞」には、労働者の間、トップの間の3分の1の意味が含まれています。 そして、この値がどのように考慮されても関係ありません。 人事管理の観点から見ると、これは責任部門が計算して提供しなければならない1つの金額です。 このユニットがこの発生をどのように計算し管理するかは、同じユニットの責任者の直接の責任であるため、誰も気にしません。 このようなソリューションは、統一の概念に完全に適合します：HRの注目領域のアルゴリズムの数は最小限であり、各グループの従業員の動機はそれぞれの企業またはユニットのゾーンで定義されます。基金の理解は誰にとっても同じです。 自動化の欠如？ まったくありません。 各ユニットまたは企業は独自のペース（独自のモチベーションシステム、独自の指標、独自の作業速度、結果の評価）で生活しているため、各ユニットはこの機能を効果的に実装するためのツールに専念しています。 Excelは年に1度は十分ですが、実稼働システムとのオンライン統合が必要な人もいます。 しかし、これらのタスクはこのユニットの責任領域に渡され、このタスクを効果的に実行する方法をHRよりもよく知っています。



SAP HCM実装計画



休憩して構築します。 このアプローチは、システム間の統合を構築するタスクでよく使用されます。 1つのシステムの電源を切り、何が起こるかを確認します。 何も起こらない場合、このシステムまたは接続は必要ありません。 実際には、これは、あるユニットから別のユニットにレポートを転送するための手順の体系的なシャットダウン（廃棄）を意味し、特定のディレクトリ（支払いの種類、スケジュール、一時データ、NSI）の使用を減らします。 多くの場合、システムの新しい実装では、企業はすべてを転送したいと考えています。 しかし、誰もその理由を言うことはできません。 多くのアナリティクスは、何らかの理由で、もう何年も前に、関連性がなくなった特定のケースのために実装されましたが、このアナリティクスはいまだに慣性によって満たされています。 この分析に基づいて、今日どのような経営判断が下されていますか？



レポートとドキュメントの形成は多くの場合、これらのドキュメントを受け取る人々がワークステーションを備えていないという事実に関連しています 。 最も典型的な例は、パスオフィスとセキュリティサービスです。 責任者によって署名された書類上の永遠の申請書。 たぶん、PCでソリティアをプレイする機会を彼らに与えるべきでしょうか？ ワークステーションのコストは、紙のワークフローよりも安い場合があります。



プロセス おそらく、これは実装で最も人気のある言葉です。 誰もがプロセスを簡素化し、統一したいと考えています。 SAPの導入後とその前のプロセスを見ると、周囲のノイズほど多くの違いはありません。 システムに縛られることなくプロセスを統合することは非常に簡単です。 プロセスの最も単純なバージョンと最も複雑なバージョンを採用します（上記のプラントと売り手の例）。 それらがどのように異なるかを見て（高い確率で、通信と出力フォームの数に違いがあります）、すべての企業にとってプロセスを最も困難にします。 そして、「ブレークトゥビルド」の最初の原則に従って手順を実行します。 美しい図や詩を作成する必要はありません-実際の日常生活では、誰もこれらのマルチボリュームを調べません。 Excelのシンプルなプレートが役立ちます。



論文 方法論後の2番目の痛みポイント。 法律が必要としないのは書類だけです。 ある会社は、プリンターの取り外しに関する実験を実施しました。 人々は物理的に文書を印刷できませんでした。 6か月後、電子メールによる文書の数は大幅に削減されました。 「報告書はどこにありますか？」の代わりに、「どこを見るべきですか？」という質問が起こり始めました。 統一できない文書があると思います。 たとえば、雇用契約への追加契約。 最も一般的なケースのドキュメントを処理し、それらを統合して自動化するだけで十分です。 残りをプロジェクトの範囲から外し、状況に応じて統一し、結果にボーナスを付けます。 小売業での大規模な選択と雇用により、文書は簡単に統合および自動化されますが、なぜこれを産業の巨人に行うのですか？



人とプロジェクト 。 これは最もデリケートなトピックです。 すべてのマネージャーは、人々が変化に敏感であることを知っています。 オフィスでのテーブルの再配置でさえ、宣戦布告と見なすことができ、企業に与えられた人生の最高の年を軽視します。 このようなシステムを導入するプロジェクトを開始しますが、これは大規模なプロジェクトであり、ビジネス側からの各参加者は、これが一時的であり、反対していると道徳的に感じています。 プロジェクトマネージャーでさえ、プロジェクトの後、彼の役割が終了し、企業にとって不要になるのではないかと心配しています。 プロジェクトを開始する前に、プロジェクトの完了後に何が起こるかを明確に理解しておく必要があります。 すべてのプロジェクトはストレスであり、通常のプロジェクトとは異なる追加作業です。 多くのプロジェクト参加者は、これを追加の負荷と見なしていますが、それはいかなる形でも補償されません。 プロジェクトで効率的に作業するための動機について事前に考えることは価値があります。そうでない場合は、スティックの下から「解雇します」ではありません。



コミュニケーションまたは「しかし、話します。 」 多くのリーダーがリーダーになったのは、彼らが話し始めた、または話すことができたからです。 考えを正しく策定し、対談者に伝えます。 プロジェクトが始まると、彼らはそれを忘れます。 このプロジェクトは、私たちが毎日見ていたよりも多くの人々を巻き込みます。 結果を達成するために克服する必要がある新しい障壁が表示されます。 しかし不運-動機はありません。 個人的に何も得られないのに、なぜ誰かと話をするのですか。 インセンティブが明確であるため、上司または部下と一緒に-常に歓迎します。 そして、ここには完全に異なる人々（ビジネスコンサルタントと外部コンサルタントの両方）がいます。彼らとのコミュニケーションの結果は、動機付けを予見しません。 その結果、すべてのレベルのすべてのプロジェクト参加者からの情報が常に不足していることがわかります。 通信による潜在的なリスクを減らすには、プロジェクトの前であっても、通信ルールを作成する必要があります。 誰が、どこで、なぜ、いつ、正式な規制ではなく、何か他のもの。 実際には、これは、戦略計画において、参加者自身が新しいシステムの必要性を理解するように導くプロジェクトイニシアチブの組織である場合があります。 以前は、企業には「ラツ」などの合理化提案がありました。合理化の提案は、その実装により、企業またはプロセスがより良いものになります。 これは、プロジェクトを発表せずに多数の人々を巻き込むことができるプロジェクトイニシアチブであり、それによってチームとビジネスの両方に変更の準備をさせます。



私の観点から、 最も重要なことは、他の記事で繰り返し指摘されているように、実装の目標を可能な限り正確に社内の多くの人々に伝えることです。