2020年10月26日（月）～10月30日（金）で開催されるオンラインイベント「SAP HR Connect Autumn 2020」に協賛しております。
COVID-19渦で人事制度の見直しをお考えの皆様、是非ご参加下さい。
公式サイト
イベント告知用DM（ご自由にダウンロード下さい）
You Tube
タグ: SAP
カテゴリー
ジョブ型人事制度とタレントマネジメント
「制度設計が先でツール選定は後」この当然の順番が逆になっていませんか？
COVID-19渦のなか、投資対効果を考えず常に新しいツールを提案してくるコンサルティングファームやベンダーがいませんか？
ソフトウェアを売る必要のあるベンダーが提案するならまだしも、環境変化や経営課題を鑑みた人財マネージメントの在り方を語らず、「新しいタレントマネージメントツールを導入しませんか？」と訴えてくるコンサルティングファームは危険かもしれません。
メンバーシップ型のままであれば、ジョブローテーションを前提とした情報管理が必要となりますが、これがジョブ型となった場合は、そもそもジョブローテーションが不要となる事が多いと思います。
そうなれば、ポジション毎の要件となっている能力を深化させる運用が前提となり、後任者が社内で見つからない場合は、応募者プールの中から選別し、中途採用のオファーを出すという運用に変移するでしょう。
人口も労働力も少ないニュージーランドに見るSAP® SuccessFactors®の用途
太平洋の南に位置するニュージーランド。日本の約２／３の国土に約500万人が暮らしています。当然ながら労働人口も少ないため海外からの労働力に頼らざるを得ません。そのため雇用は極めてシンプルな「ジョブ型」です。
ニュージーランド経済の中心地オークランド（評議会）も SAP® ERP のユーザーで、評議会内で候補者の見つからないポジションについては、SAP® SuccessFactors® で外部から（国内外問わず）人材を募って応募者プールに登録し、能力要件がマッチした方へジョブオファーを出します。
ポジションは「Permanent」「Contract」と大きく2つに分類され、「Permanent」は日本と同様に週40時間労働となります。（世界で初めて1日8時間労働を定義したのは、実はニュージーランドです）
SAP® SuccessFactors® は評議会と応募者を繋ぐ入口であり、決してシステムありきの制度設計ではありません。
幹となる人事制度が「ニュージーランドという労働人口の少ない国の環境と経営課題」に応じて設計され、投資対効果を考えたサービスが構想され、少ない人員で運用できるサービス（システム）が構築されています。
日本でもBPRや成果主義が叫ばれ少しずつ変化してきましたが、COVID-19が人事制度の見直しを加速させるという事は、避けられない現実です。
ジョブ型人事制度の導入をお考えであれば、順番は概ね以下の流れになると思います。
- ジョブ型人事制度の設計：ジョブローテーションの廃止、ジョブポスティング制度の導入、ポジション毎の能力要件定義、ジョブグレードと報酬制度設計、ジョブ型人事制度導入初年度の人員配置など。
- 既存人事システムの調査：未使用機能が活用できるか、追加ライセンスの要否、不足する機能の洗い出し。
- 追加サービスの選定：オンプレミスで開発するのか、クラウドのサービスを活用するのか、費用対効果の測定。
- ジョブ型人事制度の実装：既存システムと追加サービスでジョブ型人事制度が運用できるシステムに。
- ジョブ型人事制度とシステムの運用：追加サービスの実装、制度の変更対応など、運用に即した保守。
弊社は 1 ～ 5 全てのフェーズでサービスを提供致します。
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の適用という最小限度のコストで、サポート期限切れを回避する事が可能となりました。
人員削減と人材育成
サプライチェーンの崩壊を招いた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の機能を使いこなせているか心配なユーザーには、アセスメントサービスも提供いたします。今ある資産を有効活用し、人材育成に役立たせる事ができるかもしれません。
賃金抑制、人員削減、人材育成に対応するシステム改修支援もリモートで請けたまわります。まずはご相談下さい。
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円 |
(*1) 大阪市内の交通費込の料金です。大阪市外、宿泊を伴う遠方の場合は旅費交通費を別途請求させて頂きます。
(*2) リモート割引時間単価は訪問時間単価の10%～20%OFF
リモートサポートの進め方
- 要件が確定しましたら、弊社へ作業を依頼下さい。フォームはこちら https://bigdrivellc.com/job-offer/
- 弊社の固定グローバルIPアドレスをお伝えしますので、ファイヤウォールの設定をお願致します。
- リモート接続のテストを行いますので、貴社 SAP® ERP開発機のIPアドレスをご連絡下さい。またユーザーIDの発行もお願い致します。
- 貴社開発環境にログイン後、無料見積もりを実施します。
- 見積書（PDF）を送付致しますので、発注頂ける場合は弊社とリモートサポートの準委任契約(*1)を締結して頂きます。（*1) 弊社のリーガルチェックは大阪バディ法律事務所が行います。
- 準委任契約書（PDF）をご送付頂くと、作業の開始となります。
- 作業開始時、作業終了時、中間報告等は貴社指定のWeb会議ツールにて実施致します。
- ドキュメントの共有は貴社指定のオンラインストレージサービスを利用致します。
- 作業指示は全て書面（メール・仕様書）にて承ります。
- 要件が定かではないと判断された場合は、要件定義のコンサルティングサービスとなり、1時間毎の報酬(*2)を請求させて頂きますのでご了承下さい。(*2)プリンシパルコンサルタントの時間単価となりますので、お客様で要件を確定するとコスト削減につながります。
- 仕様変更も全て書面（メール・仕様書）にて承ります。
- 毎月末に作業時間分の料金を請求致します。請求書（PDF）を発送致しますので、30日以内に指定口座にお支払い下さい。
JSUG の 「S/4への移行を考える会」へリモート参加しました。既にSAP S/4HANA®に移行を実施されたユーザー企業（トラスコ中山株式会社 様）の成果を共有頂きました。
チームビルディング、ベンダーコントロールと全てにおいて参考となる事例でしたので、SAP S/4HANA®への移行をお考えのユーザーには大変有意義な時間だったと思います。
また、SAP S/4HANA®への移行予算を通すための大きな課題も明らかになりました。
SAP S/4HANA®がどうDXの足掛かりになるのか？
予算を通すためにも、目的とするDXの例があると説得力が増します。DXと言っても新たな売上を産むのか、コスト削減を達成するのか、二つの視点からのアプローチがあると思います。
| DX 対象 | 主幹 |
|---|---|
| 新たな売上を産み出す | 新規ビジネス 立上げチーム |
| コスト削減を達成する | IT部門 |
「新たな売上を産み出す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感が高まります。
ビッグドライブ株式会社は起業した２社目ですが、１社目の合資会社フロンティアワークス時代に、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を検討して下さい。
最近 LinkedIn 経由で中途採用のオファーが増えてきました。全世界におけるITプロジェクトの成功率は3割と言われています。今回はプロジェクトの成功率を高める人財配置（採用）について記そうと思います。
20年以上 SAP® の導入現場を見ていると、プロジェクトが始まって1ヶ月も経過しないうちに「このプロジェクトは上手く進められそうだ！」とか「あっ、このプロジェクトは失敗するな。。」と勘が働き、そしてその通りの結果を迎える事が多くなりました。
開始直後からボトルネックになる人が見えてしまうのです。
成功率が高まるケース
これまで見てきた中で、最も成功確率の高いプロジェクトは、プロジェクト責任者やリーダーに、ある共通点がありました。
- やらされてる感がない。
- 火中の栗を拾う覚悟で、業務の見直しと説得に没頭する。
- プロジェクトの成功が会社の成功、そして自身の成功だと強い信念を持っている。
こういった方がプロジェクト責任者やリーダーとして存在していた場合は、グッと成功率が高まります。
また、自社の社員でもベンダー側の人間でも、自らの信念とプロジェクトの方針に従って評価できる方ですので、メンバー間の不満も少なく、非常に良い職場環境を育みます。
プロジェクト内部での意見交換も増え、ときには思いもよらない解決策が見つかるなど、良いループに入る事でプロジェクトを成功に導きます。
高確率で失敗するケース
名プレーヤーが名監督・名コーチになるとは限りません。優秀なプレーヤー（開発者）であった方を、プロジェクトマネージャーとして育てたい一心でプロジェクト責任者、またはリーダーとして配置している場合は、プロジェクトが暗転する確率が高まります。
技術が主軸で、業務要件を整理し、相手の心情にも配慮しながらプロジェクトを進められる方も稀にいらっしゃいますが、本当にごく少数です。見つけた場合は大事なご縁ですので、大切にして下さい。
テクニカルな事が得意（好き）な方の大きな特徴として挙げられるのは、以下の2点です。
- 自分の技術（知識）と、その存在価値が一番大事。
- プロジェクトの成功には、あまり興味がない。
まず、自分の技術（知識）が採用される事、これが最も重要だと考えています。こういった方がプロジェクト責任者やリーダーとなってしまった場合、時間がいくらあっても足らなくなる傾向があります。その理由は以下の2点に大切な時間を浪費してしまうからです。
- マッチポンプで自己満足。自分が最適解を持っていても敢えて言わず、メンバーの提案でやらせてみる。（もちろん失敗する方向に罠を仕掛けているので、必ず失敗させます。）失敗が露見したところで、自身の技術（知識）を見せつけてリカバリーし、自尊心を満たします。しかし、その間、プロジェクトの進捗は停滞しています。
- 脅威となる存在の排除。自分の存在価値を危うくする存在（知識も経験も相手の方が上）が現れると、体調が悪くなり休みがちになります。また、プロジェクトそっちのけで、その脅威となるメンバーの排除に全身全霊を捧げます。パワハラはもちろん、他のメンバーを巻き込んで無視させたり、不具合をでっち上げる等、ありとあらゆる手段で排斥に没頭するため、プロジェクトの進捗は当然滞ります。
こんな時間の無駄使いをするわけですから、フェーズ事のスケジュールもまともに出てきません。一番酷い例だと、フェーズが始まって3週間もスケジュールが無いケースがありました。
自尊心を持つのは大事な事ですが、行き過ぎた自己愛はプロジェクトのブレーキでしかありません。
内製化を目的とした採用の優先順位
社内にプロジェクトを任せられる人財が居れは最高です。該当する方が見つからなかった場合は、当然ながらそのポジションを担う方の採用が最優先となります。
候補者のバックグラウンドがとても重要となりますので、上記にあるような傾向が見られないか、よく話しを聞いて観察する事が重要です。
内製化を目的とした採用基準の一助となれば幸いです。
残念ながら、全てのベンダーが「正しい情報をユーザーに伝えている」訳ではない事を、改めて記しておきます。
ネット上で見かける SAP S/4HANA® 移行サービスでも、担当者の誤解なのか、意図的にミスリードを誘っているのか不明ですが、ユーザー企業の知識不足を狙った感のある記述があったので、これを例に挙げて解説と補足説明を残しておきます。
（ミスリードを誘う記載例１）修正するAdd-On量で単純移行か再構築かを提案します。
（解説１）「少し言葉が足りないだけ」なのかもしれませんが、ユーザー企業側から見れば、判断基準は以下の２点に絞られるはずです。
- 「保守期限が迫っているので、とにかく現状の業務を変えずに、最低限のコストで乗り換えたい」→ 単純移行
- 「DXを見据えて業務を見直す（見直せる従業員が存在する）ので、これまで投資してきたAdd-Onも捨てて、一から業務とシステムを見直したい」→ 再構築
（ミスリードを誘う記載例２）Add-Onはバージョンアップの弊害になる場合があるため、なるべく標準機能の利用をお勧めします。
（解説２）SAP®は２通りの拡張方法を提示しています。一つ目は従来のAdd-On開発等でお馴染みの「In-App 拡張」です。二つ目は、SAP®以外のクラウドサービスやシステムとの連携機能や、不足する機能をSAP® Cloud Platformで開発する「Side-by-Side 拡張」です。SAP®のメッセージを纏めると以下の２点に集約されます。
- 従来のAdd-On（In-App 拡張）はECCのバージョンアップ時、検証コスト増となる可能性があるので、影響を見極めて、必要であれば Side-by-Side 拡張で移管して下さい。
- 新たにAdd-Onする場合は Side-by-Side 拡張で実装して下さい。ECCのバージョンアップによる影響はありません。（標準機能の利用を強く勧めている訳ではない）
（ミスリードを誘う記載例３）SAP S/4HANA® はクラウド時代の設計で、SAP®のクラウド製品との連携が容易です。
（解説３）❝ 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 | 担当者レベル | 機能知識に乏しい | 既存システムと同じシステムが出来上がる。 |