カテゴリー
アフターコロナ

ジョブ型人事制度とタレントマネジメント

「制度設計が先でツール選定は後」この当然の順番が逆になっていませんか?

COVID-19渦のなか、投資対効果を考えず常に新しいツールを提案してくるコンサルティングファームやベンダーがいませんか?

ソフトウェアを売る必要のあるベンダーが提案するならまだしも、環境変化や経営課題を鑑みた人財マネージメントの在り方を語らず、「新しいタレントマネージメントツールを導入しませんか?」と訴えてくるコンサルティングファームは危険かもしれません。

メンバーシップ型のままであれば、ジョブローテーションを前提とした情報管理が必要となりますが、これがジョブ型となった場合は、そもそもジョブローテーションが不要となる事が多いと思います。

そうなれば、ポジション毎の要件となっている能力を深化させる運用が前提となり、後任者が社内で見つからない場合は、応募者プールの中から選別し、中途採用のオファーを出すという運用に変移するでしょう。

人口も労働力も少ないニュージーランドに見るSAP® SuccessFactors®の用途

太平洋の南に位置するニュージーランド。日本の約2/3の国土に約500万人が暮らしています。当然ながら労働人口も少ないため海外からの労働力に頼らざるを得ません。そのため雇用は極めてシンプルな「ジョブ型」です。

ニュージーランド経済の中心地オークランド(評議会)も SAP® ERP のユーザーで、評議会内で候補者の見つからないポジションについては、SAP® SuccessFactors® で外部から(国内外問わず)人材を募って応募者プールに登録し、能力要件がマッチした方へジョブオファーを出します。

ポジションは「Permanent」「Contract」と大きく2つに分類され、「Permanent」は日本と同様に週40時間労働となります。(世界で初めて1日8時間労働を定義したのは、実はニュージーランドです)

SAP® SuccessFactors® は評議会と応募者を繋ぐ入口であり、決してシステムありきの制度設計ではありません。

幹となる人事制度が「ニュージーランドという労働人口の少ない国の環境と経営課題」に応じて設計され、投資対効果を考えたサービスが構想され、少ない人員で運用できるサービス(システム)が構築されています。

日本でもBPRや成果主義が叫ばれ少しずつ変化してきましたが、COVID-19が人事制度の見直しを加速させるという事は、避けられない現実です。

ジョブ型人事制度の導入をお考えであれば、順番は概ね以下の流れになると思います。

  1. ジョブ型人事制度の設計:ジョブローテーションの廃止、ジョブポスティング制度の導入、ポジション毎の能力要件定義、ジョブグレードと報酬制度設計、ジョブ型人事制度導入初年度の人員配置など。
  2. 既存人事システムの調査:未使用機能が活用できるか、追加ライセンスの要否、不足する機能の洗い出し。
  3. 追加サービスの選定:オンプレミスで開発するのか、クラウドのサービスを活用するのか、費用対効果の測定。
  4. ジョブ型人事制度の実装:既存システムと追加サービスでジョブ型人事制度が運用できるシステムに。
  5. ジョブ型人事制度とシステムの運用:追加サービスの実装、制度の変更対応など、運用に即した保守。

弊社は 1 ~ 5 全てのフェーズでサービスを提供致します。

SAP® ERP HCM ジョブ型人事制度 移行サービスの詳細はこちらをご覧下さい。

SAP® ERP HCM ジョブ型人事制度 移行サービス

カテゴリー
アフターコロナ

COVID-19と保守期限延長

世界が激変した2020年

COVID-19の影響で、SAP® ERP HCMユーザー企業も、多大なダメージを受けたかと思います。売上の大幅な減少に伴い、システム開発予算は優先順位を下げられ、SAP S/4HANA®への移行をベンダーへ全てお任せする予算を確保するのも難しい時期でしょう。しかし、SAP® ERP の保守期限が2027年12月に延長になった事は少しだけ明るい材料です。

加えてSAP S/4HANA® 版のHCMも、2022年7月~9月(SAP®の第3四半期)にリリース(*1)されます。SAP® ERP HCMユーザーは、追加したインフォタイプや、これまでの運用実績の中で開発してきた評価機能や賃金改定機能を捨てる事なく、ユニコード対応とEhP8の適用という最小限度のコストで、サポート期限切れを回避する事が可能となりました。

(*1)ソース記事:英文 https://blogs.sap.com/2019/09/25/sap-human-capital-management-for-sap-s4hana-on-premise-edition-updates-available-in-2022-with-a-technical-co-deployment-in-sap-s4hana/

人員削減と人材育成

サプライチェーンの崩壊を招いたCOVID-19。経済産業省は、生産拠点の国内移転支援を目的とした、「国内投資促進事業費補助金」を発表しました。中小企業で2/3、大企業で1/2、いずれも補助金上限は150億円という大型事業です。事業期間(原則3年)の間に、生産拠点を日本に戻すとともに、これまで海外に頼っていた労働力を国内で賄わないといけません。

製造業を例に挙げて補助金の話を書きましたが、事業を継続的に行うためには、日本国内の全ての産業において、労働人口のボリュームゾーンであり、人件費を圧迫する団塊ジュニアの賃金を抑制、または人員削減しながら、若年層を業務の中心に据えるために育成する。これが、COVID-19後の人事に求められる最優先課題である事は間違いありません。

2019年に経団連は「終身雇用の継続は難しい」と発しましたが、経営者は今回のCOVID-19で正社員を雇用するリスクを更に痛感した事でしょう。これからも徐々に正社員の数を減らし、今回のような有事に備えて行く事になるでしょう。

SAP® ERP HCMユーザーは、上記のような賃金抑制、人員削減、人材育成にシステムを対応させながら、2027年12月末のサポート期限切れまでに、出来る事を少しずつ進めていくしかありません。

不足するSAP®技術者 特にHCMは絶対数が少ない

HCMの技術者はもともと少数です。需要が会計・ロジに劣るので当然と言えば当然です。ただでさえ少ないHCMの技術者で、HCMの機能を熟知し、給与管理と会計転記まで対応できる技術者は日本に数人程度です。

給与仕訳すらできない方がほとんどですが、私達にはその数少ない技術者の中でも、大手コンサルティングファームが手掛けたプロジェクトのトラブルシューティングや、SAP®社のコンサルタントに指導実績のある者がおります。

最低限のコストで移行する

首都圏ならば、そこまで技術者不足に悩まなくても良いかもしれません。しかし、首都圏以外のSAP® ERP HCMユーザーは、東京から技術者を呼び寄せるにしても、サービス料金に加え出張旅費も負担せざるを得ないため、なかなか予算取りが難しく、SAP S/4HANA®への移行に二の足を踏んでいる状況だと思います。

最低限のコストで移行するために必要な事、それはユニコード対応やEhP8の適用を、お客様の保守担当で実施頂く事です。もちろんプロジェクトマネージメントもお客様のシステム部門の方に実施頂く事が最安です。

ただ、どうしても社内の人員だけだと不安だという場合は、弊社にご依頼下さい。

弊社はHCMの機能を熟知し、給与計算から会計転記まで理解したコンサルタントを大阪の拠点に置き、日本全国のSAP® ERP HCMユーザーへ、リモートで移行支援サービスを提供致します。制度変更対応を加味した移行までのロードマップ作成や、弊社の環境(EhP8適用済みのSAP® ERP HCM)を用いて、ユニコード対応の技術支援、SAP S/4HANA®がリリースされた場合は、いち早く弊社環境で移行のテストを行い、問題点や課題を提供致します。

また、SAP® ERP HCMの機能を使いこなせているか心配なユーザーには、アセスメントサービスも提供いたします。今ある資産を有効活用し、人材育成に役立たせる事ができるかもしれません。

賃金抑制、人員削減、人材育成に対応するシステム改修支援もリモートで請けたまわります。まずはご相談下さい。

カテゴリー
SAP® ERP HCM / Payroll リモートサポート

HCM / Payroll リモートサポート

LinkedInでお問合せが増えてきましたので、改めてのご案内です。

クラウドで運用のお客様

弊社は SAP® GUI インストール済みの開発・サポート用PCを用意しております。 AWS, Azure, Google Cloud Platform で SAP® ERP HCM / Payroll を運用されているお客様の開発機へ接続(*1)する事が可能です。

制度変更に伴うプログラムの修正、新規開発で技術者が必要な場合は弊社にご連絡下さい。

(*1) 各クラウド環境のファイヤウォールに弊社の固定グローバルIPアドレスを設定頂きます。

オンプレミスで運用のお客様

貴社のセキュリティポリシーに依存しますが、弊社のテスト/デモ環境からリモート接続(*2)が可能な場合があります。貴社のベーシス担当にリモート接続が可能かご確認頂き、可能であれば接続テストを行いますので、弊社までご連絡下さい。

(*2) 貴社ネットワークのファイヤウォール等に弊社の固定グローバルIPアドレスを設定頂きます。

リモートサポート料金

リモートサポート料金は、オンサイト訪問料金から10%~20%OFFで提供させて頂いております。

また、弊社は人月単位の発注ではなく、4時間単位での発注が可能ですので、「予算の都合上40時間だけ手伝って欲しい」といった短期間の案件も大歓迎です!

タイトル訪問時間単価(税別)(*1)リモート割引時間単価(税別)(*2)
プリンシパルコンサルタント20,000円18,000円
アプリケーションコンサルタント10,000円8,000円
ソフトウェアエンジニア6,500円 (*1)5,200円
タイトル別時間単価:発注は4時間単位です。
(*1) 大阪市内の交通費込の料金です。大阪市外、宿泊を伴う遠方の場合は旅費交通費を別途請求させて頂きます。
(*2) リモート割引時間単価は訪問時間単価の10%~20%OFF

リモートサポートの進め方

  1. 要件が確定しましたら、弊社へ作業を依頼下さい。フォームはこちら https://bigdrivellc.com/job-offer/
  2. 弊社の固定グローバルIPアドレスをお伝えしますので、ファイヤウォールの設定をお願致します。
  3. リモート接続のテストを行いますので、貴社 SAP® ERP開発機のIPアドレスをご連絡下さい。またユーザーIDの発行もお願い致します。
  4. 貴社開発環境にログイン後、無料見積もりを実施します。
  5. 見積書(PDF)を送付致しますので、発注頂ける場合は弊社とリモートサポートの準委任契約(*1)を締結して頂きます。(*1) 弊社のリーガルチェックは大阪バディ法律事務所が行います。
  6. 準委任契約書(PDF)をご送付頂くと、作業の開始となります。
  7. 作業開始時、作業終了時、中間報告等は貴社指定のWeb会議ツールにて実施致します。
  8. ドキュメントの共有は貴社指定のオンラインストレージサービスを利用致します。
  9. 作業指示は全て書面(メール・仕様書)にて承ります。
  10. 要件が定かではないと判断された場合は、要件定義のコンサルティングサービスとなり、1時間毎の報酬(*2)を請求させて頂きますのでご了承下さい。(*2)プリンシパルコンサルタントの時間単価となりますので、お客様で要件を確定するとコスト削減につながります。
  11. 仕様変更も全て書面(メール・仕様書)にて承ります。
  12. 毎月末に作業時間分の料金を請求致します。請求書(PDF)を発送致しますので、30日以内に指定口座にお支払い下さい。
カテゴリー
成功するプロジェクト・失敗するプロジェクト

ベンダーのミスリード

残念ながら、全てのベンダーが「正しい情報をユーザーに伝えている」訳ではない事を、改めて記しておきます。

ネット上で見かける SAP S/4HANA® 移行サービスでも、担当者の誤解なのか、意図的にミスリードを誘っているのか不明ですが、ユーザー企業の知識不足を狙った感のある記述があったので、これを例に挙げて解説と補足説明を残しておきます。

(ミスリードを誘う記載例1)修正するAdd-On量で単純移行か再構築かを提案します。

(解説1)「少し言葉が足りないだけ」なのかもしれませんが、ユーザー企業側から見れば、判断基準は以下の2点に絞られるはずです。

  • 「保守期限が迫っているので、とにかく現状の業務を変えずに、最低限のコストで乗り換えたい」→ 単純移行
  • 「DXを見据えて業務を見直す(見直せる従業員が存在する)ので、これまで投資してきたAdd-Onも捨てて、一から業務とシステムを見直したい」→ 再構築

(ミスリードを誘う記載例2)Add-Onはバージョンアップの弊害になる場合があるため、なるべく標準機能の利用をお勧めします。

(解説2)SAP®は2通りの拡張方法を提示しています。一つ目は従来のAdd-On開発等でお馴染みの「In-App 拡張」です。二つ目は、SAP®以外のクラウドサービスやシステムとの連携機能や、不足する機能をSAP® Cloud Platformで開発する「Side-by-Side 拡張」です。SAP®のメッセージを纏めると以下の2点に集約されます。

  • 従来のAdd-On(In-App 拡張)はECCのバージョンアップ時、検証コスト増となる可能性があるので、影響を見極めて、必要であれば Side-by-Side 拡張で移管して下さい。
  • 新たにAdd-Onする場合は Side-by-Side 拡張で実装して下さい。ECCのバージョンアップによる影響はありません。(標準機能の利用を強く勧めている訳ではない)

(ミスリードを誘う記載例3)SAP S/4HANA® はクラウド時代の設計で、SAP®のクラウド製品との連携が容易です。

(解説3)❝ SAP S/4HANA® はインメモリデータベースであるHANAの能力を最大限に発揮できるような設計になっている ❞ が正しい伝達の仕方でしょうか。SAP®のクラウド製品との連携が容易である事に間違いはありませんが、他社のクラウドサービスとの連携アダプタも、世界中のパートナーが開発し販売していますので、❝ 他のクラウドサービス連携も容易です ❞ が正しい情報です。

いかがでしょうか。ベンダーからの提案が「ベンダー都合の提案」なのか、「ユーザー企業の目線に立った提案」なのか、こうやって見ると、とても分かりやすい例だと思います。

ベンダー選定の一助となれば幸いです。

カテゴリー
運用面でのコスト削減

運用時の失敗要因

導入時の失敗要因では、導入時の失敗原因を分析しましたが、システム稼働後の運用現場でも緩い失敗(コストに見合わない運用)が見受けられます。通常、 SAP® R/3®を導入したベンダーの何名かが保守メンバーとして残り、システムの運用を行います。保守マネージャーがユーザー業務を理解し、あらゆる方面との交渉力を持っている現場は、何も心配ありません。

では緩い失敗が起こる要因とは何でしょうか。導入時の成否がそのまま引きずられる事になります。

No.ユーザー側ベンダー側結果
1リーダークラス機能熟知成功
2リーダークラス機能知識に乏しい要求された機能をAdd-Onや手作業で逃げる。
3担当者レベル機能熟知現状維持を求められ、ベンダーの提案が通らない。
4担当者レベル機能知識に乏しい既存システムと同じシステムが出来上がる。
導入時の失敗要因

これを運用場面に当てはめるとこうなります。

No.保守マネージャー保守メンバー結果
1リーダークラス固定・熟練度UP熟練度が上がり機能知識が深まる事で、コストパフォーマンスの高い保守が可能。
2リーダークラス頻繁に入れ替え熟練度が上がらず、単純なAdd-Onや手作業ばかりが増える。
3担当者レベル固定・熟練度UP何度も拒否され続けると改善意欲も失せ、単純なAdd-Onや手作業ばかり増える。
4担当者レベル頻繁に入れ替え効率化や自動化とは程遠く、体力と根性で運用するシステムと化す。
運用時の失敗要因

保守メンバーの熟練度を高めながら、保守マネージャーも業務知識を深め、ユーザー側との交渉能力を高める事が重要です。

どちらか一方だけが秀でても上手く回りません。今後は労働人口が減少するため、No.4のように「体力と根性で運用する」形からは脱却して、テスト自動化ツール等を積極的に導入する等、少人数で、さらには有事でも事業を止めないシステム運用にシフトする事が望まれます。

タイミングとしては、SAP S/4HANA®への移行と同時期に、または移行後に少しずつ自動化を取り入れて行く事をお勧めします。クラウドに移行するのは、災害対策としても非常に有効です。

カテゴリー
成功するプロジェクト・失敗するプロジェクト

導入時の失敗要因

2020年6月でビッグドライブ株式会社は、創業から10期目を迎える事ができました。私は1996年からSAP®のAdd-On開発者としてキャリアをスタートさせ、今年で25年目を迎えました。

これから将来を担う技術者のためにも、そしてSAP S/4HANA®を導入して運用していくユーザーのためにも、これまでERPの導入現場で何が起こってきたのか、時代背景を踏まえて記そうかと思います。

1990年代後半。ホストコンピューターからのダウンサイジングニーズ、そして2000年問題の対応手段としてSAP® R/3® は飛ぶように売れました。当時はBPR(ビジネス プロセス リエンジニアリング)という言葉も流行り、「R/3® に業務を合わせて下さい!極力 Add-Onを減らしましょう!」を合言葉に導入プロジェクトが進められました。しかし、導入する側もプロフェッショナルは少ない訳です。

SAP® R/3® に精通していない人達が導入するわけですから、あちらこちらで「これがSAP®の標準ですから。Add-Onしましょう!」となってしまいました。

標準プログラムやパラメータ設定、Exitでどうにかなる範囲でも、Add-On開発が増えれば増えるほど、システム導入会社の儲けは大きくなるため、「標準機能では実現できないと説明してAdd-Onにしちゃえ!」というベンダーもいました。

そうして「SAP® vs ユーザー企業」という一番望ましくない対立構図が、皮肉にも「SAP®のパートナー企業」の手によって作り上げられていったのです。

プロジェクトメンバーに導入企業の業務担当者を据えた事も、Add-Onが増えた材料の一つでした。何故なら業務を担当している方は「今の業務をこなす」のが仕事であり、「新しい業務を作りだすのは自分の仕事では無い」と感じている方が多いからです。

業務改善を考え、責任を負う覚悟のある各業務のリーダークラス、SAP® R/3®の機能を熟知しシステム稼働後の運用まで考えていたベンダーが揃った「幸運なるプロジェクト」だけが成功を収めていました。下記表のNo.1は大成功と言ってもいいでしょう。No.2は保守メンバーの熟練度が上がり、稼働後にシステムの改善余地があるので、小成功といったところでしょうか。No.3はベンダー側(システム稼働後に残る保守メンバー含む)が疲弊している場合が多いので、運用フェーズでの改善提案は望みにくいケースです。No.4にいたっては、残念ながら既存システムを使い続けていた方が良かったレベルです。

No.ユーザー側ベンダー側結果
1リーダークラス機能熟知成功
2リーダークラス機能知識に乏しい要求された機能をAdd-Onや手作業で逃げる。
3担当者レベル機能熟知現状維持を求められ、ベンダーの提案が通らない。
4担当者レベル機能知識に乏しい既存システムと同じシステムが出来上がる。
導入時の失敗要因