「SAPって何？」
「SAPとERPって何が違うの？」
「SAPはどんなシステムで何ができるの？」
「SAPを理解するには何をどのように勉強していけばいいの？」
上記のような素朴な疑問をお持ちの方向けに「SAPとは何か」を社会人歴 = SAPエンジニアがざっくり＆じっくり解説していきます。（専門用語は使わずに、できるだけわかりやすく解説します！）
このページではSAPとは何か？ SAPって何ができるシステムなの？ なぜSAPはシステム導入の費用もエンジニアの給料も高いの？ といった疑問に対して１からわかりやすく解説。ページ後半ではSAPエンジニアを目指す方向けのおすすめ参考書や、SAPエンジニアの仕事内容についても詳しくご紹介します。
ひとまずこのページを読んでおけばSAPの概要が見えてくる！ そんな記事になることを目指して頑張ってご説明します。
SAPとは何か？
結論から言うと、「SAP」とは「SAP社」が製造する「ERP」製品のことです。
・・・・。
と言われても、ピンと来ませんよね。
このような説明が、SAPを難しく感じてしまう最初の壁です。
ここで「ああ、難しいな・・・」と思ってしまうと、いつまでもSAPの正体をつかめなくなってしまいます。。。そのため、まずこのページではSAPとは何か？を正しく理解するために、SAP理解の土台となる前提知識――「ERP」という用語の意味から解説します。ERPが何者なのか？を理解することで、SAPとは何か？が徐々に明らかになっていくはずです。
前提：「ERP」とは何か？
ERP (Enterprise Resource Planning) とは、初心者向けに超ざっくり説明してしまうと「企業内のすべての業務を一元的に管理する共通システム」だと言えます。以下の図のように、経理部や調達部、人事部や総務部といった会社/組織内のあらゆる部署が共通的に利用するシステムで、人やモノ・お金や情報を一元的に管理するシステムをERP（ERPシステム）と呼びます。
ここではひとまず「ERP＝会社全体で利用するシステム」だと理解できればOKです。
ERPを例え話で説明するなら、ERPは「企業を運営するための指令センター」のようなもの。例えば、ある大きなレストランがあり、そのレストランには料理を作る厨房やお客様をもてなすホール、仕入れを担当する購買部、経理や人事など様々な部門が存在します。
ERPが存在しない世界を考えると、これらの組織は別々に動きます。人事は人事で異動の整理や給与の支払いを行い、厨房は厨房で料理を作ることに専念。システムで例えると部門ごとにそれぞれ別のシステムを持っているようなイメージ。
ERPはこれら全ての部門が１つの大きなシステム内で連携し合えるようにしたシステムやその考え方を指す言葉です。つまり、料理の注文が入れば、厨房で調理が始まり、同時に在庫が減るのを購買部が把握し、必要な食材の追加注文を行う。また、売上はリアルタイムで経理部に伝わり、人事部は従業員の勤務時間や業績を管理することができるようにするシステムをERPと呼びます。
と、ここまで読むと、もちろんすべての会社はERPを導入しているんだよね！と思いたくなりますが、実はそんなことはありません。ここから少しだけ寄り道して「ERP誕生～SAPの登場」までの歴史をご説明していきます。
SAP誕生の歴史：パート１「個別最適化」の時代
ERPという概念が生まれる以前のシステム開発における "黎明期" 。
当時は、会社全体で1つのシステム開発を行うというのは非常に珍しく各業務部門が独自にシステム開発を行うのが主流でした。
経理部門であれば経理部門単独の経理システムを持ち、人事部門であれば人事部門独自の人事給与システムを持ち、また調達部門は調達部門独自の調達管理システムを持っているということです。
これには、以下のような原因が考えられます。
参考 「ERPではなかった」と考えられる理由
- 技術的制約
- 昔のコンピューターは現在ほど高性能ではなく、一元的にデータを管理することや大規模な処理は技術的に難しかったため。
- 経営文化と組織構造
- 以前は企業内の組織が１つの「城」のような感じで各部門が自立していた（予算や人事を含め）ため、会社全体での改善活動を進めづらかった。
- コストとリソース
- 全部門共通システムは、導入コストが高かった（高度なテクノロジースキルが必要だった）。→より手軽で短期的に投資対効果が見込める部門単位でのシステム開発が主流だった。
ざっくり言えば、ERPのような全部門共通システムを開発するのは「かなり難しかった」と言えます。
いずれにせよ、各部門単独で業務を最適化することに努めていたというのがシステム開発の歴史の始まりです。
とは言え、システム/テクノロジーの力を部門単位の業務最適化に利用することで、各部門の業務効率化という観点で見た際には一定の成果をあげることに成功していたと言えるでしょう。
ERP誕生の歴史パート２：全体最適化へ
しかしながら、部門最適化したシステムでは企業全体で見ると非効率な側面が多く存在します。
その最たる例が部門間の情報・データ共有です。
嘘のような本当の話で、調達システムで購入した物品の金額を「印刷して経理部門に手渡す―。」「USBメモリに入れて渡す―。」「メールで送付する―。」それらのデータを受け取った経理部門は「手入力で経理システムに打ち込みなおしたり」「独自の取り込みツールを作ったり」と、非効率な業務遂行を余儀なくされていました。
要するに、部門単独で完結する業務の方が珍しいため、結果として効率化されない業務が多分に存在していたということ。
部門内では最適化された業務を遂行している一方で、部門をまたがって業務を行う必要がある場合は完全に最適化しきれていませんでした。
そんな欠点を補いつつ、企業の生き残りをかけて導入が必須となってきたのがERPです。
年々進むハードウェア性能の向上や経営戦略の高度化が進むにつれて、徐々にERP（＝全部門共通システム）導入のアドバンテージが大きくなっていきました。すると、個別最適化システムにコストを書けるのではなく、全社で１つのシステムを運用する方がはるかに効率的だと考えられるように。
（後述しますが）ERPが持つ様々なメリットを踏まえ、ERP開発は「コスト」ではなく「投資」である！という考え方も徐々に一般的になり、一定以上の規模の企業はこぞってERPシステムを導入することになりました。
ERP = 企業資源計画
ここで、「ERP」という単語の意味をより本質的に解説しておきます。
企業内で発生するありとあらゆるデータを一元的に管理。それにより企業全体の業務最適化・意思決定の早期化につなげていく。この考え方こそが「ERP」という言葉の本質です。
今では「ERP」というとシステム自体を表す言葉として定着してきましたが、本来は「企業全体の資源を一元管理する考え方」を指す用語です。
ERP（Enterprise Resource Planning）という単語はその名の通り「企業資源計画」を意味します。→この単語は本来、経営戦略におけるリソース（人、モノ、金、情報）を効率的に計画・管理するためのアプローチや考え方を指していました。
しかし転じて現在では「ERP」という単語は、その考え方を実現するITシステム自体を指すことが一般的になっています。
文脈により、どちらの意味でも利用されることがあるため、この点は十分に理解したうえで適切な意味で用いることが必要不可欠です。
ERPパッケージとは？
企業全体で１つの統一されたシステムを作るのは決して簡単なことではありません。１からERPを作るのは非常に難しいのが現実。
会社全体の業務がどのように行われているのか？会社全体で保持するデータはどのような形で保持すれば良いのか？等簡単に答えを出せないような課題がたくさん存在するためです。
ざっと「自社でERPを開発する難しさ」を羅列してみたいと思います。
- 複雑性と膨大なスコープ
- ERPは企業全体の多くの部門と業務内容を網羅的に考慮して設計する必要がある。
- 人的リソースの制限
- ERPを開発するには、データベースやネットワーク、またプログラミング知識はもちろん専門的な業務知識などが必要に。
→実際は、１つの企業内にそのすべてを網羅するようなエンジニアが結集していることは非常に稀なケース。
- ERPを開発するには、データベースやネットワーク、またプログラミング知識はもちろん専門的な業務知識などが必要に。
- 時間とコスト
- 自社開発は非常に時間とコストがかかる。かつ、開発中は進行中の業務を妨げないようにする必要があり、そのためにかかる調整コストなども考慮する必要がある
- 絡み合う企業内対立の調整
- 現行業務の変更や改善を必要とする場合がほとんどであるため、現場社員からの反発や、組織 vs 組織で妥協しあえない点などが発生し、その調整に時間がかかる。
要するに、ERPを自社で開発し、自社で運用していくことは莫大なコストを必要とするので、その意味や有用性を理解していても実際にその改革を行うのは非常に困難だったと言えます。
実はこの「難易度の高さ」に目をつけ、ビジネスの商機を見出した企業が今の「ERPベンダー」です。
→ERPをパッケージ化（＝各企業に展開可能なソフトウェア・アプリケーションにすること）して、少しのカスタマイズでどの企業でも利用できる製品を開発しておけば、いろんな企業が買ってくれるのではないか？
このように考えたわけです。
そうした流れの中で生み出されたERPのパッケージ製品が、SAP（by SAP社）であり、Oracle EBS（by Oracle社）なのです。
導入する会社にとっても、困難なERP開発を一から自社で行うのではなく、１つの製品としてサーバにインストール＆微調整するだけでERPの導入ができたほうがはるかに楽ですよね。
これで最初の解説の意味が分かるようになります。
SAPとは「SAP社」が製造する「ERP」製品のことです。
SAPを更にわかりやすく：モジュールとは？
SAPをさらに具体的にイメージできるように、ここからはさらに具体的な中身の解説にうつります。
SAPを理解するために重要な概念の１つが「モジュール」です。
モジュールとは、超・簡単に言えば機能の集まりのこと。先ほど説明したように、ERPは「企業全体システム」ですが、分解していけば１つ１つの部門単位の機能に分けられます。
会計システム + 調達システム + 在庫管理システム + ・・・・ = ERP
この会計システムとか調達システムみたいな部分をSAP用語では「モジュール」と呼んでいます。
SAPを導入する際には、このモジュール単位で各種の設定（＝パラメータ設定/カスタマイズ）を進めていきます。会社によっては「このモジュールは利用するけど、こっちのモジュールはいらない・・・。」なんてこともありますが、その場合は必要とするモジュールの設定だけ行います。
ちなみに、SAPエンジニアはモジュールごとに専門があります。例えば、会計系モジュールを得意とするSAPエンジニアや人事系モジュールを得意とするSAPエンジニア・・・というような形。
この専門が多ければ多いほど、エンジニアとしての価値は高ります（＝給料も上がります）。
SAPエンジニアはどのような仕事をしているのか？が気になった方は↓の記事をチェックしてみてください。
参考 SAPエンジニアとは？
本ページでは、SAPにおける代表的なモジュールを簡単にご紹介しておきます。
FI（Financial Accounting）：財務会計
FI（Financial Accounting） モジュールは財務会計に関する業務をカバーするモジュールです。
いわゆる会計システムの部分。
FIモジュールはSAPの花形と言われます。もっとも重要で、最も根本的なモジュールとなるので、SAPエンジニアにとってはFIモジュールを導入するのは非常にチャレンジングで面白い仕事の１つです。
調達したらお金を払いますし、ものが売れればお金をもらいます。また、人を雇えば給料が発生します。それらのデータがリアルタイムにFIモジュールに流れてくることになります。
なので、基本的にはSAPを導入する企業は必ずFIモジュールを利用すると思っていて大丈夫です。
CO（Controling）：管理会計
CO（Controling） は、管理会計領域の業務をカバーするモジュールです。
管理会計とは企業内部の細かなコストの発生状況を分析する業務のこと。
FIモジュールが財務諸表などの外部向けの報告書を作成することを目的とするのに対して、COは「内部向けの報告書」を作ることを目的とします。
すなわち部門単位の業績管理や、間接費の管理などを主な目的とします。
参考 CO（管理会計）とは？
COモジュールも他のモジュールと同様、リアルタイムに全業務のデータが連携されてきます。COモジュールを適切に運用することで、社内全体のコスト管理・コスト分析が可能となり、次なる業務改善を進めることが可能となります。
SAPを導入することで企業内におけるコスト管理・コスト分析が可能になるという点は、SAP導入における非常に大きなメリットの１つとなります。
SD（Sales and Distribution）：販売管理
SD（Sales and Distribution） モジュールは、いわゆる販売管理システムに該当します。
お客さんからの注文を受けてから商品を出荷するまでの一連の業務を管理するのが主な目的です。もちろんモノを売れば代金を受け取ることになるので、その売り上げのデータはFIモジュールに自動的に連携されていきます。
どの会社・どの人から「注文」を受けて、何を出荷するのか？その出荷製品はいくらで、請求書はどこにどんなフォーマットで送れば良いのか？などを管理するモジュールです。
モノを売る企業（メーカーなど）がこのSDモジュールを利用することになります。
MM（ Material Management ）： 在庫購買管理
MM（ Material Management ） モジュールは、いわゆる「在庫管理システム」「調達管理システム」に該当するモジュールです。
SDモジュールが「売る側」だとすれば、MMモジュールは「買う側」です。
どこに何を発注したのか？どれぐらいの値段で発注するのか？今在庫はどれぐらいあるのか？などを管理します。
発注金額や、在庫量データは財務諸表に関わってくるのでこれも自動的にFIモジュールに連携される仕組みです。
SDモジュールを利用して販売管理を行う企業は、製品販売のための製造管理も行っている場合はほとんどなので、MMモジュールとSDモジュールはセットで導入されることが多いです。
このように、企業の業種や業務内容に合わせてモジュール単位で設定を行っていくのがSAPの特徴です。
最後にSAPを導入する際は実際どのような手順を踏んでいくのか？を解説します。
SAPを導入するには？
ここまでの説明で何となくSAPが何者であるかが分かってきたのではないでしょうか？
この最後の章ではSAPを導入する際の流れを解説しておきます。
SAPはパッケージ製品なのでサーバーにインストールするだけで利用可能になる・・・？と想像しがちなのですが、実はそんなことはありません。
SAPはインストールするだけでは利用できません。インストールを行ったあとの設定作業や自社の業務内容に合わせた機能開発が必要となります。
SAP導入には基本的に以下の２つの作業が必要となります。
ここの作業内容を理解することでSAPのメリット/デメリットがさらによく分かるようになります。
またSAPエンジニアを目指す方にとっては知らないと恥ずかしい超・基本知識でもありますのでしっかり理解しておきましょう。
パラメータ設定（コンフィグレーション / カスタマイズ）
パラメータ設定とは、別名コンフィグレーション / カスタマイズとも呼ばれます。
SAPは全世界の全業種で利用可能なERPパッケージとなっているため、使う言語や画面上に表示する内容などはオプションで選択することが可能になっています。どのオプションを利用するのか？（＝どの言語にする？画面の項目はどうする？など）を１つ１つ設定していく作業がパラメータ設定です。
パラメータ設定の代表的なものを挙げると「会社名」の設定や「組織情報」の設定といった基本的なものから「利用する消費税」の設定「画面項目」の設定など実際の業務に密に関連してくるものまで幅広く存在します。
SAPのすごいところは「そんなものまで設定できるの？」というほど設定項目が充実しているところです。この幅広さが、世界中の企業に採用されている大きな理由の１つになっています。
逆に言えば、どのような設定が必要で、どのような手順で設定すれば良いの？というのは専門家でないと分かりません。専門家としてのスキルを保持し、企業へのSAP導入をサポートするのが、SAPエンジニア/SAPコンサルです。
この設定を隅々まで知り尽くしているSAPエンジニアによって、SAP導入時の初期パラメータ設定が行われます。
SAPエンジニアとは、読んで字のごとくSAPを導入・運用保守するエンジニアのこと。
SAPエンジニアの仕事内容や年収、勉強方法が気になる方は以下の記事をチェック！
ABAP開発（アドオン開発）
パラメータ設定（SAPの設定）だけではどうしても実現できない機能を追加する作業です。
日本の会社の場合は、他社との差別化のために独自の業務で効率化を行っているような場合が多く存在します。そのような業務はSAPの機能だけでは処理することができないため、SAP専用のABAP（Advanced Business Application Programming）と呼ばれるプログラミング言語を用いて、独自の機能を開発します。
SAP導入時に一番大変な作業がこの工程です。
なぜなら、ABAP開発がなければ「バグ」はほとんど生まれないからです。SAPを導入している企業で、もし不具合やバグが起きているとすればそれは99％はこのABAP開発が原因といえます。
ABAP開発では、SAPの標準仕様に加えてABAPの知識が必要になるため費用がかさみます。
逆に言えばこのABAP開発をできるだけ抑制し、SAPで実現できる業務体系に合わせていくことがSAP導入成功のカギとなります。
SAP / ABAPを１から学習したい初心者の方向けに、できるだけ網羅的にABAPが理解できるよう以下ページに知識体系を整理しています。
特に初心者のうちは、どこから学べばよいか？どう勉強すれば良いか？すらわからない状態になりがち。
ある程度の知識を持ったうえで、はじめて実践的な理解へとつながります。
是非、一度ご覧になってみてください。
おまけ：SAPとERPの違い
よくある質問の１つ「SAPとERPは何が違うのか？」というものがあります。たぶん、どちらも英語３文字で似たような概念のため混乱してしまう人が多いものと推測されます。
ただ、ここまでお読みになった方なら答えは簡単にわかりますね。
「SAP⇒SAP社のERPパッケージの製品名称」
「ERP⇒企業全体システムのこと」
となります。
「SAP」と「ERP」は似ているものの、概念は異なりますので正確に理解しておくことが重要です。
そのうえで、SAPはERPパッケージの製品名称であるので、その意味ではSAP≒ERPである、ということも可能です。あくまでも、SAPは会社名・製品名であり、ERPは全社システムの総称であることを理解しておきましょう。
SAPをもっと詳しく知りたい方は
本記事で、SAPの概要を理解できたところで、さらに一歩深くSAPが何者なのか？を知りたい方や、実際にSAPのプロジェクトに参画する方は、参考書での学習もおすすめします。
以下の記事で紹介している３つの書籍ですが、SAPエンジニアであれば知らない人はいない必読書です。これを知らずしてSAPエンジニアを名乗るのはちょっとだけ恥ずかしいかも？
また、以下のページではSAPエンジニアを目指す方のために、SAPの勉強方法を解説していますので、是非ご参考にしてみてください。
開発者の視点からSAP導入のメリット・デメリットについて解説しておりますので、お時間がある方は合わせてお読みください。
