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

SAP HR Connect Autumn 2020

2020年10月26日(月)~10月30日(金)で開催されるオンラインイベント「SAP HR Connect Autumn 2020」に協賛しております。

COVID-19渦で人事制度の見直しをお考えの皆様、是非ご参加下さい。

公式サイト

http://sap.expoline.jp/hra20/

イベント告知用DM(ご自由にダウンロード下さい)

You Tube

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

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

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

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 ジョブ型人事制度 移行サービス

カテゴリー
DX

デジタル化の考え方

JSUG の 「S/4への移行を考える会」へリモート参加しました。既にSAP S/4HANA®に移行を実施されたユーザー企業(トラスコ中山株式会社 様)の成果を共有頂きました。

チームビルディング、ベンダーコントロールと全てにおいて参考となる事例でしたので、SAP S/4HANA®への移行をお考えのユーザーには大変有意義な時間だったと思います。

また、SAP S/4HANA®への移行予算を通すための大きな課題も明らかになりました。

SAP S/4HANA®がどうDXの足掛かりになるのか?

予算を通すためにも、目的とするDXの例があると説得力が増します。DXと言っても新たな売上を産むのか、コスト削減を達成するのか、二つの視点からのアプローチがあると思います。

DX 対象主幹
新たな売上を産み出す新規ビジネス 立上げチーム
コスト削減を達成するIT部門
DX 二つのアプローチ

「新たな売上を産み出すDX」は、既存システムのお守りをしながら、IT部門が主導して進める事は難しいでしょう。そもそも新しいビジネスを立ち上げるのですから、別の能力要件が必要とされます。

ただ、SAP S/4HANA®へ移行する理由付けとして、「こういったDXの例がある」と紹介できれば、「新たな売上を産み出すDX」と「コスト削減を達成するDX」の双方から説得できる材料となるはずです。

売上を産み出すDX

では事例の少ない中、どうやってアイディアを出すのか。このアイディア出しを外部のコンサル会社へ丸投げするのは、あまりお勧めしません。彼らは貴社のビジネスについて学ぶ時間が必要ですし、商習慣についても詳しくないかもしれません。

もう20年ほど前になりますが、私が2000年に手掛けたコンサルティング案件で「業務の電子(デジタル)化」というのがありました。その際に定義した「電子化が可能か否か」という考え方(一部)をご紹介します。

例は2000年当時の記載のままです。既に実現されている事ばかりなので、「考え方」の視点でご覧ください。

分類電子(デジタル)化の可否
デジタル化が可能な物品やサービスである(例:CD)デジタルコンテンツ化で配信可能。
デジタル化が不可能な物品やサービスで、人が移動しないと享受できない。(例:ヘアカット)予約は電子化可能。
デジタル化が不可能な物品やサービスで、人が移動しなくとも享受できる。(例:食品)注文から配達依頼まで電子化可能。
業務の電子化(考え方)

営業部門やマーケティング部門を主幹として、貴社のビジネスのうち、何がデジタル化されれば合理的・効率的で、顧客(ユーザー)にメリットがあるのかの視点で考えると、割と簡単に答えが出てくると思います。貴社の強みを活かした、競争力のあるDXを考え出して下さい。

コスト削減を達成するDX

これはコンピューターシステムの歴史を紐解くと答えは解ります。一つ目は「単純で繰り返し行う仕事をコンピューターに実行させる事」すなわち自動化です。ERPの導入時に行えなかった自動化を進めるだけです。「データをダウンロードして、Excelで加工してレポートを作成する」業務を自動化するだけで、コスト削減を達成する立派なDXです。

意思決定をアシストするAI

そして二つ目が20世紀からの目標であり、課題でもあるAI化です。AIの定義が古今東西定かではないのですが、解りやすい例を挙げると、映画ターミネーターに出てきた「スカイネット」や、映画アベンジャーズに出てくる「ジャービス」や「フライデー」「カレン」です。

前者はAIが主体で物事を判断して決定し実行に移します。

後者は主である人間に最終決定を求めますが、人間がやらなくてよい事は、AIが担当して制御します。

いずれにせよ、チャットボットではやや物足りない側面があるので、スマホのような音声インターフェース(音声入力、音声出力)が実装されると、さらにAI感が高まります。

ビッグドライブ株式会社は起業した2社目ですが、1社目の合資会社フロンティアワークス時代に、AIが生成したアウトプットを音声出力できないかという発想のもと、文字を音声に変換する実験を2001年に行い、2002年に発話しょうがい者向けソフトを開発し、沖縄社会福祉協議会にお買い上げ頂きました。

Nirai Kanai Voice(ニライカナイボイス)

http://www.fukushi.com/news/2002/05/020507-a.html

人間が求めるニーズに基づきシミュレーションを行い、何を高めれば求める結果が得られるか提案する事もAIの領域でしょう。

2013年に弊社は、ゴルファーの身長、体重、ウイングスパンを入力すると、ヘッドスピード別、打出し角度別にボールの弾道と飛距離を算出するサービスを開発しました。これは気温毎に異なる空気摩擦、ボールの質量、ディンプルの数による回転数を予測して軌道とキャリーを計算しています。

ビッグドライブアナライザー

https://news.golfdigest.co.jp/news/gear/article/47085/1/

※2013年当時マーケットの一部の方にはご理解頂きましたが、まだ時期が早いという判断の元、サービスは停止中です。

アイディア次第でDXの領域は無限に広がります。SAP S/4HANA®への移行をきっかけに、貴社独自のDXが見つかると思います。

横並びでどこかの成功事例を真似るのではなく、貴社の強味を知っている方と、会社をより良くしたいと考えている方と一緒にDXを検討して下さい。

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

ベンダーのミスリード

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

ネット上で見かける 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担当者レベル機能知識に乏しい既存システムと同じシステムが出来上がる。
導入時の失敗要因