SAP専門家が分析「日本企業がERP導入にてこずる5つの理由」:ERPの本質を知る
本連載では、SAPのコンサルタントが企業の基幹システム・ERPシステムに絞って課題と取りうる対策を明確化します。連載1回目は、日本企業がERPで成功するために解決すべき5つの課題を整理します。
コロナ禍で明るみに出た「日本のIT化の決定的な遅れ」に伴い、「日本の競争力低下」や「日本企業の生産性の低さ」が問題提起されるようになりました。一体、何が原因なのでしょうか。
ただ、あまり総論や一般論ばかりの具体性の無い話をしても進展がありません。そこで本連載では、企業の基幹システムおよびERPシステムに絞って、日本企業の課題や取りうる対策を明確にします。
基幹システムやERPは同じ価格で購入しても、取り組み方の違いで価値に大きな差が出ます。しかし、効果が出なくても一朝一夕で入れ替えられません。生産性や時価総額といった企業価値に深く関連するテーマですので、本連載が日本企業のグローバル競争力向上の一助になればと思います。
最初に、日本におけるERPがグローバルと比べて特徴的な点を述べます。そして本稿のテーマである、日本企業がERPで成功するために解決すべき5つの課題を整理します。
著者プロフィール:木下史朗(SAPジャパン カスタマーサクセスパートナー)
日系製メーカー・外資系メーカーを経て2000年にSAP入社。SAPジャパンでコンサルタント、プロジェクトマネージャー、新規事業開発に携わる。2011年よりSAPグローバルチームに異動し、オンプレミス顧客のアップグレード&サポートプログラム推進役。2016年よりSAPアジアパシフィックジャパンチームに異動し、SAP顧客のクラウド移行プログラムの推進役として現在に至る。
Twitter : @shirohpossible
本質に気付かず進んだ日本のERP
1990年代後半、「ホストシステムからクライアント・サーバ型システムへの軽量化」「YYMMDD日付表示システムの西暦2000年表示への移行」などをきっかけに、日本でERPの採用事例が増え始めました。また、スクラッチシステムの積み重ねでスパゲティ化し、変革の障害になっているシステムを刷新する動きが相次ぎ、ERPに取り組む企業が増えました。
この時、ERPの本質に気が付いていた日本のIT関係者や経営者は少なかったでしょう。当時ERPの意義として語られた「全体最適化」「ビジネスプロセス・リエンジニアリング」なども、IT改革や業務改革目線で語られる事が多かったかも知れません。
一方、一部の日本の経営者は欧州のビジネスの現場で、ERPが経営に与える威力を実感し本質に気が付いた上で導入を進めました。「日々の経営判断に必要な情報がなぜこれだけすぐ手に入るのか」と、何度も質問を繰り返した先にERPがあったそうです。ERPの本質に早く気付き、今までのシステム導入とは違う、トップダウン・アプローチでプロジェクトを成功させたITトップもいます。ERPは「経営を変える」「企業の競争力を変える」という本質に早く気付いたユーザー企業ほど、SAPのシステムで成功をおさめ成果を出すのが早かったように見えます。
さまざまな角度からERPの浸透が始まったものの、「ERPの本質」「経営へのパラダイムシフト」に気付くのに時間がかかったのが日本の特徴だと思います。2000年を超えて徐々に経営効果がユーザー企業で語られるようになり、初めてその威力を実感したのだと思います。
グランドデザインから進んだ欧米のERP
SAPジャパンは1992年に日本で設立されましたが、少し早い1980年代にはERPの土壌はできつつあったように思います。SAPは1980年代、クライアント・サーバ型ではなくホストで動くERP「SAP R/2」をリリースしました。
2000年代になると、名だたる欧米企業がグローバルオペレーションでERPの統一化・標準化を進め始め、いかにシンプルなITランドスケープを実現するかどうかを競いました。韓国や中国、インドなど日本より後にERPが普及し始めた国でも、日本の事例ではなく欧米モデルへの追随が始まりました。
欧米人は日本人と比べてコンセプトやグランドデザインの話を好みます。「日本人は具体的な話や詳細な話が好きですね」と、私もよく欧米人には言われました。延々とコンセプトの議論をしても飽きない欧米人を見て、外資系企業に就職した当初の私は文化の違いを感じたものです。ERPのようなグランドデザインが重要なテーマは、欧米人がいち早く本質に気が付いたため、日本とはスタートから差が出たのかも知れません。
日本企業がERPで成功するため解決すべき5つの課題
日本と欧米のERPの捉え方の違いについての長い前置きから入りました。以降は、これらの影響により生まれた問題が、今の日本企業の前にどういった形で横たわっているのか、5つの課題に分けて整理します。
課題1:複雑なシステムランドスケープ
グローバルの名だたる企業が「グローバルインスタンス化」や「ERPの集約化」「最適配置」を終えています。しかし、日本企業はまだERPの複雑なランドスケープに悩まされており、集約化や全体最適化が立ち遅れています。それを理由にSAPの運用負荷が高くなっているのは日本企業の課題と言えるでしょう。
北米のSAPユーザー会を中心に開発したIT成熟度ベンチマークでは、2003〜2004年の時点で既に重要な1つの指標として「システムの複雑さ(基幹システムの個数)」を取り入れました。集約化するために「社内の最適プロセス」や「組織の在り方」をいくつも定義しています。
ERPの集約化・最適化が進むと、SAPはグローバルインスタンスが次々と増え、計画ダウンタイムや計画外ダウンタイムへの要求が極めて厳しい“絶対止められない重要基幹システム”が続々と登場しました。可用性要件の厳しくなった重要システムの増加に対応するため、SAPは2008年に危険の芽を察知して対策する「SAP Enterprise Support」という予防保全型のサポートメニューを打ち出しました。
従来の「インシデントが起きた事後に対応する」という方法では、インシデントによるダウンタイムが企業の業績に影響を与える可能性があるため、「重大インシデントの芽を早くつみダウンタイムを極力起こさない」という考えに切り替えたのです。この考えには、後述の課題3で述べる「ITIL」(Information Technology Infrastructure Library)も大きな影響を及ぼしました。
しかし当時、日本企業でERPの最適配置が進んでおらず、ダウンタイムに対する切迫感もなかったため、日本が一番SAP Enterprise Supportの受入れに時間がかかりました。
この様に、2000年代や2010年代には既に多くの欧米企業が複雑なランドスケープを解消してシンプルなERP環境を実現しました。しかし日本の多くの大手企業は、複雑なERPランドスケープが課題なだけでなく、いまだERPを本格導入している、今からERPを採用しようとしているのが実情です。日本企業は最適な形でERPを使うまでにだいぶ時間がかかってしまった実感があります。
課題2:継続的なシステム改善が苦手
SAPのグローバルやアジアパシフィックの顧客と接点を持つことで、日本の顧客との大きな差異に気が付きました。例えば、顧客のメンバーの中に優秀なエースがいたとします。日本の場合は、例外なくその方は新しいシステムの「導入」を担当しており、「導入後」の保守運用・継続的改善(オペレーション)という仕事にはアサインされません(保守運用・継続的改善に当たる日本語が無いため、以降は「オペレーション」を使います)。
日本企業はオペレーションに力を入れず、「導入〜塩漬け」を繰り返すケースが多いです。欧米企業は全く違っており、「導入」と「オペレーション」に同程度の比重が置かれ、両方の仕事にそれぞれエースが配置されています。「カイゼン」は日本のお家芸かと思ったら、ことITに関してはそうでない事が分かりました。より進んだ日本の企業では、導入段階で既に導入後のオペレーション設計にもメンバーを参加させています。
原因を調べたところ、ITのビジネスへの最適活用に対して、より継続的に価値を高めるという思想であるITILの浸透度に、日本と欧米で結構な差がある事が分かりました。
ITILは1980年代にイギリスで発祥した、「ビジネスの最適解になるITの導入・オペレーションのノウハウ集」で、SAPも大いに取り入れている方法論です。日本におけるITILは、正しい取り組み方をしている一部企業以外に、ベンダーのビジネス道具として使われたり、部分的なプロセスだけが参考にされたり、どうも欧米と違った使われ方をしているようです。
日本のSAPユーザーやパートナー、SAPジャパンの3者が中心になって、2019年に編さんした「日本企業のためのERP導入の羅針盤〜ニッポンのERPを再定義する〜」でもその点は大きく取り上げました。プロジェクトは導入で終わるものではなく、効果を出し続けるために「導入後の活用」の再定義が必要であると提言しています。また、経済産業省の「DXレポート 〜ITシステム『2025年の崖』克服とDXの本格的な展開〜」でも、日本企業のITレガシー化が競争力を阻害することへの警告が出ました。将来に希望の持てるコンテンツが日本にも出回り始めましたと思います。
欧米や日本の企業問わず、最初からERP導入がうまくいく企業は少ないです。オペレーションの一部である「分散ERPの統合」や「横断的標準化」でも、導入と同じかそれ以上の知恵と労力が必要です。ERPの継続的改善というのは重要であり、導入後のオペレーションに力を入れてこなかった負債にようやく気付く方が増えてきたと実感します。
課題3:技術者の7割がベンダーに在籍しユーザーの力が弱い
「日本はIT技術者の7割がベンダーに所属しておりユーザー企業の技術力が不足している」と投げかけられたことがあります。恐らくその通りだと私も実感しています。
ベンダーと企業のIT部門およびDX(デジタルトランスフォーメーション)部門技術者では、相当目線が違います。ベンダー側だと「ベンダーのビジネスになるかどうか」という目線になり、顧客の成功はどこか人ごとになってしまいます。日本全体の7割の技術者が、ユーザー企業の成功はどこか人ごとだと思っているのはあまり構造的によろしくないと危惧しています。
「ITを自分達の手に取り戻したい」と言う何名ものCIOと接しました。グローバルやアジアパシフィックの情報とも接して感じましたが、日本のユーザー企業の自社リソース不足は特徴的な課題です。
課題4:言語の問題
英語圏ではITサービスの調達先は自国だけでなく、いろいろな国からリモートで最適なサービスを探して調達するのが常識です。これはCOVID-19のまん延のずっと以前からです。一方日本語圏では、ITサービスの調達先は基本的に国内に限られるでしょう。
英語圏以外の国で旅行をしている際に書店に入ると、日常生活や娯楽関連は母国語でも、専門書籍やIT書籍はほとんど英語で書かれている国が多いことに気が付かれると思います。これらの国におけるITサービスは、英語圏のものを中心に探さざるを得ないのです。
例えば電子帳簿化というテーマに取り組もうとして、欲しいユーザー目線の情報が数多くの英語のブログ・コミュニティーなどで出回っているのに対し、日本語の情報はほとんど国税庁やベンダー発信のものばかりで、欲しい情報がなかなか無いという経験はありませんか。
英語圏だけでなく、ほとんどの国でも英語がITの標準言語となっているため、英語による情報量は日本語とは桁違いです。そのため、日本語の情報だけに接しているとどうしても視野が狭まってしまう課題は、IT業界全体でもSAPコミュニティーでもあります。
また、ERPベンダーが日本語圏でビジネスをしようとすると、業界毎のノウハウや技術者数、パートナー社数含め、整備するには膨大な時間と労力がかかります(SAPではこれらをエコシステムと呼んでいます)。そのため、日本のユーザー企業にとって選択肢がSAPか国産パッケージに限られるのが、日本語圏の特徴でしょう。言語の問題は考え出すと際限がありません。
「母国語(日本語)で専門書があり、母国語で専門的な深い考察ができるのは日本語の大きなメリットだ」とインド系の知人に言われた事があります。インドでは専門的な深い考察は、馴染んだ現地語ではなく英語でする必要があります。そのため彼らは英語が母国語の人に専門的な部分でどうしてもかなわないのだと。ただ、ITの世界は英語での専門文書が圧倒的なため、日本語だけのコンテンツではどうしても視野が狭まります。
課題5:脆弱性
オンプレミスシステムならではの脆弱(ぜいじゃく)性も問題でしょう。運用の負荷が高く、なかなか最新セキュリティパッチ対策に手が回らないオンプレシステムやIaaSシステムが増えています。脆弱性をつかれハッキングされると経営レベルの重大な問題にさらされます。オンプレシステムSAPの被害も時々耳にするようになりました。
本来は経営レベルの重要事項にもかかわらず、IT担当者で抱え込んでいたり、ベンダーにお任せ状況だったりする事案が多いのが日本の課題です。SAPジャパンブログに日本企業がSAPシステムに抱える脆弱性の課題についてまとめていますのでご覧ください。
以上、日本企業がERPで成功するため、解決すべき5つの課題を整理しました。次回は、ERPのクラウドシフトが日本のユーザー企業にどういう変化をもたらすか、課題ごとに考察します。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 基礎から学ぶ「RISE with SAP」 BTP活用事例3選とクラウドシフトを徹底解説
2021年にSAPが発表した「RISE with SAP」は、クラウドシフトを加速させる。ここで改めてERPの現状と未来、トレンドを分析し、RISE with SAPや関連サービスBTPの活用事例を紹介する。 - ERPの利用状況(2022年)/前編
「導入に時間もコストもかかるERPは大企業が利用するもの」「中小企業は導入しづらい」というイメージを持たれがちだったERP。基幹系システムもクラウドシフトが進む中で、ERPの利用状況はどう変化したのだろうか。 - ERPの利用状況(2022年)/後編
後編となる本稿ではERPに対する「不満」と「課題」にフォーカスを当て、問題となるポイントを探る。使い勝手だけではなく、「製品の設計思想」も理解する必要があるとの声もあった。