SAP S/4HANAの難しさについて考える

　前回のブログ「江崎グリコのシステム障害を考える」の中で、SAP S/4HANAにはシステム構築費用を大幅に低減できるメリットがありますが、デメリットも多くあるソフトウェアであるということを書きました。SAP S/4HANAについてもう少し詳しく書いてみようと思います。

　私は、会社員時代は、顧客向けのソフトウェアシステムには長く関わってきましたが、社内向けの基幹情報システムに携わる機会はさほど多くなかったので、SAPのERPについては多くを知っているわけではありませんでした。私が勤めていた会社でもSAPのERPは導入されていましたので、情シス部門の人などから、導入した時にとても大変だったとか、2027年問題というのがあって大変だとかいう話はよく聞きましたが、何でそんなに大変になるのかはよくわかっていませんでした。

　今回のグリコのシステム障害を機にSAPのERPについて少し掘り下げて調べてみたところ、色々な発見や考えさせられることが多々ありました。「実はSAPのERPはすごいソフトウェアなのだが、凄すぎて使う時に色々な問題が起きてしまう」という話です。

SAP のERPシステムとは

　ERPとは、Enterprise Resources Planning の略であり、元々経営資源（ヒト・モノ・カネ・情報）を適切に分配し有効活用する計画（考え方）を意味した言葉でした。現在では「（経営資源有効活用のための）基幹系情報システム」の意味で使われることが多くなっています。SAPは古くからERPシステムを提供している企業で、ERPシステムのシェアは世界トップであり、特に大企業向けのシェアは非常に高い企業です。

SAPの歴史

　SAPは1972年創業。翌年メインフレーム計算機用の財務会計ソフト製品がリリースしています。このソフトは、その後人事、生産管理などの業務プロセスも含むERPソフトウェア製品になっていきます。1992年には、クライアント・サーバアーキテクチャに対応したSAP R/3をリリースし、これがその後数多くの企業に採用され、ERPの主流のソフトとなっていきました。

　SAP R/3で確立されたERPシステムのアーキテクチャは2005年リリースのSAP ECC6.0まで継承されてきましたが、新しいアーキテクチャに刷新されたSAP S /4HANAが2015年に後継の製品としてリリースされました。さらに2022年はこれのクラウドバージョンが登場しています。

SAPの2027年問題とは

　SAP S/4HANAは、それまでのERPソフトとアーキテクチャが異なるため、各企業がSAPのERP上に作っていたアドオンソフトウェアはそのまでは動きません。S /4HANAに移行するためには、多くの作り直しの作業が発生してしまい、SAPを使ってきた企業にとっては大きな負担となってしまいます。SAP ECC6.0のサポートは2027年終了となっており、各企業はそれまでに何らかの対処をする必要があります。多くの企業が対応に苦慮しているこの状況は「2027年問題」と呼ばれています。

SAPのERPシステムの仕組み

　最新のSAP S /4HANAを使ったERPシステムは、主に、３つのパートから構成されています。

SAP S /4HANA

　SAP S/4HANAは、ERPアプリケーションソフトウェアです。会計・人事・生産・物流・販売などの業務分野ごとに20種類以上の「モジュール」と呼ばれる業務アプリケーションのセットとこれらに対応した「標準テーブル」が用意されています。

　この中の主要モジュールとしてよく出てくるのには、「FI 財務会計」、「CO 管理会計」、「HR 人事管理」、「MM 在庫・購入管理」、「SD 販売管理」、「PP 生産管理」あたりですが、他にも物流管理、倉庫管理、プラントメンテナンス、プロジェクト管理など多様な業務向けアプリケーションを取り揃えています。さらに、財務会計や人事管理などのモジュールでは、世界各国のルールや規制に個々に対応しています。グローバルに対応できる業務アプリケーションはその分野に関する専門知識や各国の制度・ルールの知識がないと作れません。SAPはこれだけ多くの業務向けの専門知識を有しているということであり、これはなかなか真似できないことのように思います。

ABAP Platform

　SAPのアプリケーションソフトは、主にSAPの独自言語であるABAP（Advanced Business Application Programming）言語によって記述されており、これらのアプリケーションを統合的に動作させるためのプラットフォームがABAP Platformです。データベースへのアクセス、ビジネスワークフロー、外部システムとの連携などの機能を提供しています。

SAP HANA

　SAP HANAはSAPによる独自のデータベースシステムで、2013年にリリースされています。従来のリレーショナルデータベースには無い、以下の特徴を持っています。

• インメモリデータベースによる処理の高速化 データをディスクに保存するのではなく、メモリに保存することでデータベースへの書き込み、読み込みを高速に処理できます。
• カラム型データベースによる集計・分析処理の高速化　データサイズの圧縮行単位で管理するのではなく、列ごとにデータを管理することで、特定の列の集計などの計算が高速に行えます。また、データを圧縮して保存するのも得意です。
• 非構造型データへの対応　メールや文書、画像、音声などのデータを取り扱うことができます。

　従来は、データの入力や出力を行うトランザクション用のデータベースと、その結果得られたデータを分析するためのデータウェアハウス用のデータベースは分けられることが多く、トランザクション用データベースからDWHにデータを移し替えて分析を行うことが多いかったのですが、SAP HANAは一つのデータベースで両方を実現し、タイムラグのないリアルタイムな分析を可能とすることを狙ったものになっています。

　なお、SAP ECC6.0までは、ERPシステムのデータベースにはOracleや、MS SQL Serverなど他ベンダーの製品が使われていましたが、SAP S/4 HANAの登場後、SAPのアプリケーションはこれを前提としたものになり、他社のデータベースはサポートしなくなりました。

SAPの凄さ

　グローバルに対応できる業務アプリケーションはその分野に関する専門知識や各国の制度・ルールの知識がないと作れません。SAPはこれだけ多くの業務向けの専門知識を有しているということであり、これはなかなか真似できない強みになっています。これに加え、データベースシステムも独自に提供していますし、これを元にした各種フレームワーク、プラットフォームなどのインフラ系のソフトも提供するようになってきています。

　アプリケーションの技術、情報インフラ技術の両方に強い会社というのは中々ありません。これができるSAPは総合的に非常に高い技術力がある会社なのだろうと思います。とは言うものの、SAPが手がけるERPなどの業務用アプリケーションパッケージには、SAPの技術力を持ってしても解決が難しい本質的な課題があります。

業務アプリケーションパッケージの難しさ

　　ユーザ企業にとって、業務用アプリケーションパッケージを使うことの一番のメリットは、「情報システム費用を大幅に削減できる」ことです。社内情報システムで一番高くつくのは、ソフトウェアを作ったり面倒を見たりする「人」にかかるお金です。パッケージを買ってきてこれがそのまま使えれば、ソフトウェアを作るための人は要らなくなるので、情報システム費用を大幅に削減することが可能です。

業務アプリケーションの柔軟性

　しかし、現実には、パッケージがそのまま使えるケースは多くありません。同じ種類の業務でも企業によってやり方は業務のやり方がちょっとずつ違ったり、おおむね同じでもいくつか「例外」があったりするためです。アプリケーションパッケージには、このような「ちょっとの違い」に対応するために柔軟性が必要です。柔軟性を確保する方法にはいくつかあります。

　一つ目は、「ちょっとの違い」も含めてパッケージベンダー側がアプリケーションに作り込んで提供するやり方です。ユーザはアプリケーションの設定で、機能を使うかなどを柔軟に選択します。ただ、このやり方はアプリケーションの規模を大きくなり、パッケージ提供者にとっては負担が大きくなります。また、ユーザ側にとっては、柔軟度が高くなるほど設定が複雑で難解になってしまうという問題が出てきます。

　もう一つは、フレームワークとライブラリを提供してこれを使ってユーザ側にプログラムを作ってもらう方法があります。アプリケーション提供型に比べるとユーザが作る量は増えてしまいますが、その分柔軟性は得られます。しかし、標準アプリケーションを含めた全体の一貫性・整合性をとるのが難しくなったり、フレームワークやライブラリの設計意図と異なる作り方をされると障害を引き起こす可能性があるなどの問題があります。

　多くのERPパッケージソフトウェアと同じように、SAPはこの両方のやり方をサポートしています。多数の業務用のアプリケーションを標準として提供する一方、ユーザがABAP言語を使って独自のプログラムを作ってシステムに組み入れることもできるようにしています。

SAPが取っている路線

　SAPは明らかにベンダーが標準アプリケーションを作って提供する方法に軸足を置いた路線を選択しているように見えます。独自のプログラムを作るよりは、できるだけ標準で提供するアプリケーションを使うことを推奨しています。

　おそらく、アプリケーションが扱う業務の特性上、このような選択になったのではないかと思います。会計、経理業務では帳票であるデータの整合性は非常に重要ですし、内部統制のためには業務の手順や権限が明確になっている必要があります。ユーザが作ったプログラムが、標準アプリケーションと整合して作られる保証はありませんし、業務の手順や権限が明確になっていることも保証されません。さらに、独自の機能のために作られた冗長なテーブルの影響でデータベースアクセス性能を劣化させてしまうこともあり得ます。SAPとしては、素人が作ったものを組み込まれてトラブルになるよりは、自分達が作った方がマシだと言う考えなのかもしれません。

問題点

　このため、SAPの標準アプリケーションは巨大になっています。SAP S /4HANAのソースコードの総ライン数は1.5億ラインあるのだそうです。（その前のECC6.0は4億ラインあって、そこからかなり減らしたとのこと）これだけの規模のソフトウェアを一つのシステムとして動かすのは並大抵のことではありません。巨大な規模のソフトウェアをテストし管理・維持できるているのは、SAPのソフトウェア技術力のなせる技ではありますが、それでも際限なくコード量を増やせるわけではなく限界があるような気がします。

　また、SAPのERPのパラメータ設定パラメータが非常に多く、なかなか理解するのが難しいという声をよく聞きますが、当然そうなるように思います。SAPは一つのモジュールに多くの機能を組み込み、これを使うかどうかをパラメータ設定で選択させるようにしているため、必然的に設定は多岐に渡り、複雑で難解になります。また、モジュールごとの設定には、そのモジュールの分野(会計や生産管理など)の知識がないとどう設定して良いのかわからないものも多く、パラメータ設定を正しく行うための学習コストはなかなか高そうです。

SAPのERPの導入で問題になること

　上記のように、SAPのERPはすごいソフトではありますが、これを使うために考えなければならない問題が色々あります。

Fit＆Gapの難しさ

　どのようなシステムでも、システム設計をする前に、どのようなシステムにするのかを決める「要件定義」と言う作業を行います。SAP　S/4HANAのような業務アプリケーションパッケージを使う場合には、パッケージが提供する標準アプリケーションでユーザ要件が実現できるのかを見極める作業を要件定義と併せて行います。この作業をFit & Gap Analysis もしくは単にFit & Gap と呼びます。

　Fit & Gapで得られる結果は、提供される標準機能が要件にFitしている場合は標準アプリケーションを使い、Gapがある場合はアドオン開発を行う二者一択のように思えますが、実はもう一つ選択肢があります。GapがあってもSAPが提供している機能に合わせて業務のやり方を変えると言うやり方です。前に書いたように、アドオンを作るのにはコストがかかってしまいますので「標準機能にあわせて業務のやり方を変える」ことで、これを避けようという考え方です。SAPは「Fit to Standard」という言い方でこれを推奨しています。

　要件定義作業は、一般的にユーザ企業の情報システム部門の人が、その業務を行う経理部門とか生産管理部門などの人にヒアリングを行いながら実施しますが、Fit＆Gapの作業を行うには、SAPアプリケーションで何ができるかがわかっている必要があるので、外部からSAPアプリケーションの知識を持つ専門のコンサルタントが加わることになります。

　ただ、これが中々うまくいかないことが多いようです。そもそもヒアリングをする側とされる側で話が噛み合わなかったり、業務の対象部門の人も自部門の全ての業務を知っているわけではないのでヒアリングが中々進まなかったり、「業務のやり方を変えよう」と言われても、変えて良いのかどうかの判断がつかなかったりします。結果として、この作業は長期化しがちで、最悪の場合要件定義不十分なまま見切り発車となり、これが原因で後で作り直しが発生したりシステム障害を起こし、大きなコストがかかってしまったりします。

SAPスペシャリスト確保の困難さ

　SAPのERPを導入するためには、多くのSAPの専門知識が必要になります。SAPに関連する知識は、技術的なものだけでなく、会計、調達、販売、生産管理に関するものなど多岐に渡っており、ちょっと勉強しただけで一朝一夕に得られるものではありません。そこで、大抵の場合、外部からSAPの専門家に参加してもらうことになります。一口にSAPの専門家と言っても、その種類は多岐に渡っています。大まかには以下の３つに分けられますが、SAPの認定資格を見るともっと細分化されており100以上の種類があります。

• アプリケーションの専門家　　財務会計、管理会計、販売管理など業務分野ごとの知識を有するコンサルタントで、Fit & Gapの作業のコンサルティングなどを行います。また、標準アプリケーションモジュールごとの設定パラメータの知見を持ち、標準アプリケーションをカスタマイズして使えるようにする作業も行います。
• アドオン開発の専門家　　ABAPプラットフォームなどを使った、SAPのアプリケーション開発の知見を持つスペシャリストで、アドオン開発や開発サポートを行います。
• インフラの専門家　　データベースや、各種フレームワークなどの専門家で、システム設計などのコンサルティングを行います。

　SAPの専門家を数人確保できれば良いわけではなく、導入するそれぞれの分野の専門家や開発技術者が必要になります。このためのコストがかさんでしまうことも問題ですが、2027年問題に対応している企業が多数ある現在では、SAPの専門家が不足しており、人の確保自体が危うくなっています。SAPスペシャリストの需要は高まっているため、SAPコンサルタント（と名乗る人）の数は増えてはいますが、経験豊かで優秀な人材はやはり少数です。高いお金を払って、経験不足で使えないコンサルタントに当たってしまうと言うことが起きがちです。

ベンダーロックイン

　ベンダーロックインとは、特定ベンダー（メーカー）の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる状態のことです。

　SAP S/4HANAの場合、アプリケーションだけでなくデータベースやフレームワークなどのインフラシステムもSAPの独自技術に依存していますので、導入するとベンダーロックインの状態になりやすくなります。しかし、SAP製品によるロックインは問題ではありますが、これを避けるためにSAPの製品を使わないというのもあまり現実的ではありません。他に乗り換えるにしても、SAP製品と同等以上のものは中々ありませんし、そのようなものが今後出てくるかも疑問だからです。

　SAP製品によるロックインよりももっと問題なのは、SAPを導入するために各企業が依存しているコンサルティング会社やSIerによるロックインではないかと思います。企業の情報システム部門だけで、多くの専門的な知識を必要とするSAPを導入するのは難しく、SAPコンサルタントを多く揃える大手コンサルタント会社やSIerに依存せざるを得ないのが現状ではないかと思います。しかし、SAP製品は必要だが自社内にSAPに関する知見がない状態では、SAPの知見を頼っている現行のコンサルタント会社やSIerから他に乗り換えるのは至難の業です。情報システム費用削減のためにSAPを導入したのに、システムの維持のために、高いお金を払い続けざるを得ないると言う本末転倒なことになりかねません。

終わりに

　こうして見ていくと、SAPのERPはすごいソフトウェアですが、SAPを使うのは中々に大変そうです。しかし、こういうことは世の中にはあまりはっきりと理解されていないような気がします。問題に直面し、周りからの理解不足に悩んでいるユーザ企業の情シス部門の方も多いのではないかと思います。次回は、ユーザ企業の情シス部門とその問題について書こうと思います。