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 | 担当者レベル | 機能知識に乏しい | 既存システムと同じシステムが出来上がる。 |
