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

導入時の失敗要因

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

作成者: 左 和紀(玉寄 和紀) Kazunori Hidari ( Kazunori Tamayose )

1973年沖縄県那覇市生まれ。10歳でBASICプログラミングを始める。1992年沖縄県立那覇高等学校卒業、1996年大阪学院大学商学部経営学科を卒業し、 SAP® R/3® Ver. 2.2D でABAP®開発者としてキャリアをスタート。

1997年SAP® R/3® HR(HCM)の日本向けローカライズを担当した師匠と出会い、HR コンサルタントとしてのキャリアをスタート。その後も デロイトトーマツコンサルティング、SAP ジャパン等でHCMコンサルタントとしてのキャリアを積み、2011年7月前身のビッグドライブ合同会社を設立。

SAP® ERP HCM の機能に精通し、独立後もSAP社や大手コンサルティング会社(ABeam社、PwC社、TCSJ社)のプロジェクトにて問題解決、現場のコンサルタント(マネージャー・シニアコンサルタント)への指導実績を持つ。また、デロイトOBで米国ニュージャージー州を拠点に活動する人事コンサルタント と交流があり、2000年代から日米の人事制度の違いについて学ぶ。

クラウドサービスはASPと呼ばれていた頃から知見があり、デロイト在籍時には、大手通信事業者向け戦略立案支援に携わった。

趣味はムエタイとボクシング。
SAP® Certified Application Associate – HCM with SAP® ERP 6.0 EhP6

【執筆:ASP ネットソーシング時代のIT戦略】
https://str.toyokeizai.net/books/9784492530849/