BLOG

この広告は30日以上更新がないブログに表示されております。
新規記事の投稿を行うことで、非表示にすることが可能です。

ABAP（Advanced Business Application Programming）はSAP製品を構成するプログラミング言語です。
２０２５年に向けて、SAPの新規導入やS4/HANAへのリプレイス案件が盛んな今、ABAPスキルを持つ人の単価は右肩上がりで上昇しています。

このページは、初めてABAPを学ぶ人、もう一度ABAPを１から勉強したい人のために、ABAPの知識を１から解説していきます。
このページを読み終わるころには、簡単な機能であれば一人で実装できるようになるレベルまで到達できるように解説します。

１　ABAPプログラム開発の前提

ABAPプログラムを開発する際に、まずは前提として覚えておきたい内容から学習していきましょう。

２　ABAPの基本ルール

ここから本題―。
ABAPの基本的な書き方について解説します。基本的な書き方を覚えれば、なんとなくABAPをコーディングしていくことのイメージが掴めるようになります。

以下の記事では、ABAPをコーディングしていく上で重要な9つの構文ルールについて解説しています。

この記事の内容が、様々なABAP命令を学んでいく上での基礎になります。

３　ABAPでのデータ定義・構造

ABAPの基本構文を理解した上で、データ定義・構造について学習します。

データ定義の章では、変数/定数の定義方法、内部テーブルや構造といったABAP特有の概念について学んでいきます。
データ定義を理解せずにABAPのコーディングをすることはほぼ不可能といっても過言ではありません。

４　計算(算術式/論理式)

この章では、ABAPで用いる基本的な計算方法（算術式）と、論理式について学習します。
どちらも、使用頻度が高く基本的な内容であるため、しっかり理解しておきましょう。

５　プログラムフローの制御

この章では、ABAPのプログラムフロー（処理の流れ）制御について学習します。
条件分岐（IF文/CASE文）などの基本知識から、DO/WHILE文まで処理の制御方法を分かりやすく説明します。

６　イベント/選択画面

ABAPはイベントドリブン言語に分類されます。
イベントとは何か？
この章では、イベントブロックの意味・使い方と合わせて、選択画面の作り方についても合わせて解説していきます。

７　構造化

ABAPにおけるプログラムの構造化について学習します。
構造化とは、プログラムのコードを整理されたブロックの組み合わせで構成する方法です。

ABAPを何となく読んだことがある方や、SAPの現場にいる方であれば、サブルーチンや汎用モジュールといった単語を聞いたことがあるかもしれません。
本章では、ABAPにおける構造化手法について解説します。

８　内部テーブルの操作

ABAPプログラミングで最重要といっても過言ではないのが、内部テーブルの操作方法です。

この章では、ABAPの大きな特徴の一つである内部テーブルの操作方法を解説します。
内部テーブルの操作をマスターできると、プログラミングの幅がぐっと広がります。

９　データベース操作

この章では、データベース（DB）操作について学習します。
データベース操作においては、基本的な命令文を学習する前に、ABAPにおけるデータベースがどのように構成されているかを押さえておく必要があります。

１０　文字列操作

ABAPにおける文字列操作命令について学習します。

文字列操作は、画面の作成や帳票機能を実装する際の重要知識です。

１１　その他（Tips）

最後の章では、ABAPプログラミングにおける特殊なテクニックについて学習します。
この章の内容を理解できれば、今までに学習した内容との組み合わせで多くの機能のプログラミングが可能になります。

システムエンジニアになりたての人や、会社でシステムを利用する業務に携わる人にとって、いまいちイメージしづらいのが「ERP」です。

ERPを一言で言ってしまうと「 Enterprise（企業）Resource（資源） Planning（計画）」の略です。

Enterprise（企業）Resource（資源） Planning（計画） とは、ヒト・モノ・カネ・情報という経営資源を会社全体で有効活用する観点から、企業の基幹業務（調達、生産、物流、販売、会計、人事）の情報を統合的に管理し経営の効率化を図るための手法、概念のことを指します。


と、言われてもよくわかりませんよね・・・


このページでは、ERPって実際何なの？というのをできるだけ「専門用語を使わずに」解説します。

ゴールは、ERPという言葉のイメージを自力で思い描けるようになること、そしてそれを人に語れるようになることです。

それでは解説を始めます。

１　ERPの言葉の意味

まずは、ERPという本来の言葉の意味から解説していきます。

本来の「ERP」の意味は、企業資源計画という概念を表します。
決して、システムを指す言葉ではありませんでした。

企業資源計画というのは、それまでの企業が資源を有効に活用できていない現状の中で提唱され始めた言葉であり、企業全体で資源を有効に活用していきましょう！という概念です。

一体どういうことなのか、企業の情報管理（≒システム開発）の歴史を一昔前まで遡って考えてみましょう。

２　部門単位システムの時代：部分最適

従前の企業システムは、基本的に部門単位で開発・導入されていました。

一つの会社内に複数のシステムが存在している状況です。

経理部門なら「経理システム」、製造部門であれば「製造管理システム」という形で部門ごとに独自のシステムを導入しておりました。

２．１　部門単位システムのデメリット

部門単独システムはそれまでIT化されていなかった各種業務を迅速に遂行できるにした点で大きな功績があります。
ただし、情報管理・業務観点から大きく３つのデメリットが存在する仕組みでした。

リアルタイムの情報把握が困難

１つが、リアルタイムで「企業全体」のヒト・モノ・カネの情報を把握できない、ということです。

部門単位のシステムでは、システムごとにデータを保持しているため、データの連携に時間がかかります。
（1時間に1回、1日に1回というようにデータ連携タイミングをスケジューリングしていました。）

例えば、今すぐに「売掛金（会社としての売り上げ状況）」を知りたいとなった場合は、
�@経理システムの仕訳情報から売掛金データを集計し
�A販売管理システムの売り上げ情報を集計する
という2段階の処理を行う必要が出てきます。

どれだけ売れているのか？という分析がリアルタイムにできないと、どれだけ製品を作れば最適なのか？という情報が分かりません。

多く作りすぎてしまうかもしれませんし、品切れを起こしてしまうかもしれません。
製造部門は頑張ってデータを集めるか、勘と経験に頼るしかありません。

リアルタイムにデータを把握できないというのは多くの企業にとって実に致命的なのです。

システム間のデータ不整合

2つ目は、システム間のデータ不整合が起こりやすいということです。

販売管理システムと、製造管理システムは別々のシステムなので、データの持ち方が異なります。

販売管理システムが「1,000円」、製造管理システムは「\1,000」という風にお金を管理しているとしましょう。

この場合、データ連携の前に「データの加工」が必要になりますよね。
データの加工はシステム的に処理を行うのですが、この処理のバグで「1,000円」が「10,000円」になってしまったり、文字化けしてしまったりすることが多々あります。

そうすると、本当は1000円なの？10000円なの？というのが分からなくなってしまい、その真偽を確かめるために大変な労力が必要となってくるのです。
これが部門単位システムの二つ目の不具合です。

データの二重・三重入力が必要になってくる

最後が、システムユーザが一番嫌がるものです。
それが、同じデータを複数の箇所に入力する必要がある、ということです。

商品が10個売れた―。

この場合、販売管理システムに「商品10個の売り上げ」情報を入力しますが、同時に経理システムにも「売掛金（商品10個の売り上げ）」を入力する必要が出てきます。

また、例えば販売管理をするために必要となる「得意先」に代表される「マスタデータ管理」も2つのシステムで同時に行う必要があります。

同じ情報を2つのシステムにそれぞれ別に入力する。
これめんどくさいですよね。
2つが正しく入力されていれば良いですが、どっちかが違っていたら・・・？

このように、部門単独システムは部門単位での業務最適化に成功する一方で、企業全体で見た時に多くの弊害を抱えていたのでした。

企業全体でヒト・モノ・カネの情報管理を最適化する必要がある！

その概念が「ERP」です。

次の章では、ERPパッケージの概念と、ERPシステムの構成とメリットを解説していきます。

３　ERPパッケージとは：全体最適

パッケージとは「標準的な機能を持つ出来合いのシステム」です。

パッケージはサーバーにインストールをすれば最小限の設定だけで使えるようにしてあるシステム製品であり、これは様々なソフトウェアベンダ―によって製作・販売されています。

ERPパッケージというのは、企業全体でのヒト・モノ・カネの管理（ERP）ができるシステムのことを表します。

代表的なのが、SAP社が開発・販売するSAPであり、Oracle社が開発・販売するOracle EBSです。

それらをERPシステムと呼んだり、単にERPと呼んだりしているのです。

３．１　ERPパッケージの構成

部門単位システムと比較して、ERPパッケージの構成はどのようになっているのか？

もうお分かりですね。企業内の全てのシステムを一つにまとめたような構成をしています。

３．２　ERPパッケージのメリット

システムとデータを企業で１つに集約し、全ての業務に対応しており、各種マスタも1つに集約されています。

経理部門も販売部門も全て同じマスタデータを参照できるよに調整されているのがお分かりいただけるかと思います。

ERPシステムのメリットは、部門単位システムのデメリットの裏返しになります。

リアルタイムに情報を把握できる

経理システム、販売管理システム・・・のようにシステムが分離していないため、情報が一元管理されています。

そのため、企業内のあらゆる情報を即時に把握することができます。

在庫、販売量、売上金額など、相互に情報が連携されていくので、企業全体での業務量の調整や、今後のアクションプランを描きやすくなります。

作りすぎたり、在庫切れになったり、、、ということを防ぐことに役立ちます。

データ不整合が起きない

データ連携が不要になるので、ERPパッケージ内でのデータ不整合が起きません。

データの複数入力が不要

業務処理ごとにデータがERPパッケージ内で連動します。

そのため、１つの売り上げデータに対し、販売管理システムと経理システムへの重複入力が不要です。
販売部門で売り上げデータを入力すれば、自動的にデータ処理が連動し経理側でもデータを即時に参照することができます。

４　まとめ

ERPは、こういう仕組みだ！と一言では説明できません。

それはERPという言葉が概念的なものであるためです。

ERPと一口に言っても、パッケージ（SAPやOracleEBS）ごとに、基本思想が異なるため、具体的にどんな設計がされているかを説明するのは難しいのです。

ただし、ERPという概念を知っておけば、「ERPシステムが〜」というような話についていけるようになるはずです。

ERPは「こういう感じのモノだ」という理解をこのページでしていただけていれば幸いです。

本ページではSAP導入のメリット・デメリットを解説していきます。

何故、世界中の大企業がこぞってSAPを使っているのか？

ここでは、一般的に言われているSAPを使うことのメリットとデメリットを解説していきたいと思います。

それでは早速解説を始めていきます。

１　SAP導入のメリット

SAP導入のメリットは、大きく分けて3つに分類できます。

１つが、標準化ー。

業務プロセスやデータ体系を、世界の優良企業のスタンダードに合わせることが可能です。

2つ目が、透明性の確保です。

権限管理や、履歴管理が最強なので一般ユーザの不正を防ぐことができます。

最後が、データの連続性です。

ERPパッケージ全体に共通する話ですが、１ユーザが入力したデータは、すぐに全社で確認することができるため、迅速な意思決定に貢献します。

上記３つのメリットについて具体例を交えながら一歩踏み込んで解説していきます。

まずは、1つ目の「標準化」です。

１．１　標準化

標準化は、自社の業務プロセスを世界スタンダードに合致させることを言います。

SAPは「世界の優良企業のベストプラクティス」業務を基に設計されているため、世界基準の業務プロセスを採用することが必須となります。

各社独自の複雑な業務プロセスにより無理が生じている作業や、無駄なタスクにまみれ効率性が悪化しているのが日本の企業の特徴です。
無駄な二重、三重の承認プロセスや、独自の帳票など。

SAP導入するには、この独自の無駄な業務を改革しなければならないのです。

いくらERPパッケージと言っても、ガラパゴス化した業務プロセスのままで適用できません。

したがって、SAP導入の際には大規模なBPR※と必要最低限のアドオン開発が必要となります。

※BPR・・・業務プロセスを改善すること。 Business Process Re-engineering の略。

アドオン開発の罠

SAPを新規導入する際に必要となるBPRとアドオン開発。

BPRで変えきれない部分はとりあえずアドオン開発しよう、という流れになるのですがアドオン開発には罠があります。

それは、この「標準化」という概念に反するということです。

そもそもSAP導入することの１つのメリットが、グローバルスタンダードなベストプラクティス業務に合わせることができる、というものでした。

したがって、業務に合わせることができない部分をアドオンで開発しよう！というのは、標準化のメリットを放棄することと同意である、ということです。

要件定義の際にSAPで実現できない業務であることが判明した際には

SAPに合わせて業務を変えましょう！

が正解であり

業務に合わせてアドオン開発しましょう！

は不正解なのです。

SAPのベストプラクティスに合わせる観点から、アドオン開発は基本間違いである最終手段である、ということを理解すべきです。

アドオン開発した場合、開発費用が上がるだけではなく、保守性も格段に落ちます。
SAPを導入している企業で「バグ」と言ったら90％はアドオンのバグなのです。

このバグを減らすには、プログラミングスキルとか、設計スキルではなく、第1に考えるべきは「アドオンの削減」です。

SAP導入プロジェクトが、炎上しがちなのはここに大きな原因があると言えるでしょう。

１．２　透明性の確保

SAP導入の2つ目のメリット―。

2つ目の「透明性確保」というのは、誰がいつ何をしたのか、ということを把握できる、ということです。

SAPは、履歴管理に優れており、伝票入力などデータの変更を伴う作業は全てユーザIDと紐づく形で履歴が残ります。
プログラムの改訂履歴や変更箇所などを確認する機能も搭載されているのです。

履歴管理が適切になされているため、不正なデータ入力や不正なデータ改ざんを見抜くことができます
（＝システム監査をクリアできます）。
SAP標準機能をそのまま利用する場合、いわゆる粉飾決算は不可能です。

このことにより、企業が法的に説明責任を持つ「財務諸表」の正当性が保たれるため、透明性の確保はそのまま企業評価に直結します。

１．３　データの連続性

これはSAPにとどまらず、そのほかのERP製品全般にも言えることです。

データの連続性とは、1つのトランザクションデータを複数の業務で利用可能になるということです。

従来の部分最適化された部門単位のシステムでは、調達した際に「調達しましたよ」というデータを入力し、同時に買掛金のデータを入力する必要がありました。

SAPでは、この2段階のステップを踏む必要がありません。
調達データを入力したら、そのデータがリアルタイムに「買掛金」データになります。
データが調達側と会計側で重複するのではなく、1つのデータとしてSAP内で連携されます。

データが連続することで、SAP内でのデータ不整合はありませんし、データの複数入力もなくなります。
同時に、社内全体のデータ集計も迅速にできるようになります。

SAPを導入することは、システム的な観点から大きなメリットがあるのです。

２　「SAP」であること自体への評価

ここからは、あくまでも個人的な意見ですが、SAP導入の最大のメリットは「SAPを導入する」ということ自体への評価です。

SAPは全世界の最優良企業が多く採用・導入しており、ERPベンダーの中でも最大の評価を得ています。

そのため

SAPを導入する　≒　優良企業である

であるという図式が現状一般の世間的な評価になりつつあるため、SAP導入による様々な実利的なメリットに加えて、評判なメリットも非常に大きいのです。

例えば、過去に粉飾決算をした企業がSAPを新規導入する―。
これは、会社自体が変わろうとしている、という姿勢を会社内外に示すことにつながります。

砕けて言えば会社の「胡散臭さ」を解消する力があるということです。

特にIT関係に従事する人間からすると、SAP＝大企業・優良企業である、という実感は強いのではないでしょうか。

SAPを導入することは、標準化・透明性確保・データの連続性、という実利的なメリットに加えて、SAPを導入できていることの評判的なメリットがあると言えます。

３　SAP導入のデメリット

メリットだらけのSAPですが、デメリットがあるがゆえに採用しない会社があるわけです。

SAPを採用しない会社のSAPを導入しない理由を見ていきましょう。

３．１　ライセンス費用が高い

SAPは、ライセンス費用が高額です。
このライセンスはユーザ数に応じた従量課金制であるため、ユーザ数が大きければ大きいほど、SAP社に払う金額は大きくなります。

自前で１からシステムを作れば、ライセンス費用は０となるので、その分コスト削減につながるので、金額面でSAP導入を断念する会社は多いでしょう。

システムの規模が大きくなりすぎて、ライセンス費用を払ったとしても全体としてコスト削減につながるような企業がSAP導入に踏み切ることが多いです。

３．２　開発者が少ない

SAPを導入する際に、開発コストが高くなる原因―。
これは開発者の不足です。

企業システムの多くは「java」や「C」「C+」などで書かれることが多いのですが、SAPはSAPでしか使えない「ABAP」という言語を用います。

「ABAP」という言語は、通常のプログラミングスクールで教えている話を聞いたことはありませんし、資料も乏しいです。
このため、ABAPを書くことができる「ABAPer」は非常に少ないのが現状です。

「ABAP　転職」でググってみてください。
需要過多により、給料がぐんぐん上がってしまっていることがわかるでしょう。
ABAPer側からしたらうれしい限りなのですが、企業側からしたら年々徐々にハードルがあがっていると言えます。

４　まとめ

SAPは金額面にデメリットが見られます。

一方で、金額面さえクリアすればメリットだらけのSAPでもあります。

SAP導入によるメリットと、金額面のデメリット。SAP導入の判断は、この費用対効果の分析次第と言えそうです。

このページは

「SAPって何？」

「SAPはどんなシステムで何が出来るの？」

という疑問をお持ちの方向けに「SAPとは何か」を解説していきます。
（専門用語は出来るだけ使いません！）

入社・転職したばかりで、急にSAPを知る必要が出てきた人や、初めてSAPを触る人でも
「５分で理解」出来るように要点を絞って解説します。


このページで学べる内容

• SAPとは何か？
• ERP（Enterprise Resources Planning）とは何か？
• ERPパッケージの誕生
• SAPは何ができるのか？SAPが導入されるまで

SAPが何なのか知りたい人であれば、絶対に役立つ内容ばかりですので是非最後までご覧ください。

１　SAPとは何か？

「SAP」を簡潔に一言で説明すると

「SAP社」が製造する「ERP」製品のこと

となります。

こう説明されてしまうと分かり辛いんですよね。
これが、SAPを難しく感じてしまう最初の壁です。

この最初の壁を超えるために、まずはSAPを正しく理解する前提となる知識から整理していきましょう。

まずは最初の前提知識ーーー。
「ERP」という用語の意味から解説します。

２　前提：「ERP」とは何か？

ERP（Enterprise Resource Planning）は何か？

「全部門共通システム」のことを指しています。

では「全部門共通システム」とは何かを、
企業におけるシステム利用の歴史を辿りながら解説していきます。

２．１　ERP誕生前：個別最適化の時代

システム黎明期の昔は今とは違い、会社全体で1つのシステム開発を行うというわけではありませんでした。

経理部門であれば経理部門単独の「経理システム」を持ち、人事部門であれば人事部門独自の「人事給与システム」を持ち、また調達部門は調達部門独自の「調達管理システム」を持つなど、各部門単独で業務を最適化することに努めていたというのがシステム開発の歴史です。

システム開発の黎明期は部門単位でのシステム開発・運用が主流でした。

システムの力を部門単位の業務最適化に利用することで、各部門の業務効率の向上を目指し一定の成果を上げました。

２．２　部門単独システムの限界：全体最適化へ

しかしながら、部門最適化したシステムでは、会社全体で見た時には非効率な側面も存在していました。

その最たる例が、部門間の情報・データ共有です。

嘘のような本当の話ですが、調達システムで購入した物品の金額を「印刷して経理部門に手渡す―。」「USBメモリに入れて渡す―。」「メールで送付する―。」それらのデータを受け取った経理部門は「手入力で経理システムに打ち込みなおしたり」「独自の取り込みツールを作ったり」ということがありました。

部門単独で完結する業務は多くはありませんので、結果として効率化されない業務が多分に存在していました。言い方を変えれば、部門内では最適化された業務を遂行している一方で、部門をまたがって業務を行う必要がある場合は、完全に最適化しきれていなかったのです。

そんな欠点を補うために考え出されたのが「ERP」という概念です。

「調達システムと経理システムを一緒にして、自動的に転記できるようにしよう！」

「調達システムに在庫管理システムをくっつけで、いつでもを在庫量をみれるようにしよう！」

というような、システムを統合することのメリットを強く意識して生み出されたのが「ERP」という概念なのです。個別に機能していたシステムを、会社全体で１つのシステムに統合する考えです。

「ERP　＝　全体最適化したシステム」であると理解しておきましょう。

２．３　ERP = 企業全体で資源を管理するシステム

先ほど、ERPシステムを「全部門共通システム」と説明しましたが、より丁寧に説明するのであれば

「企業全体の資源（人・もの・金・情報）を管理するシステム」

となります。
企業内で発生するありとあらゆるデータを一元的に管理することによって、業務の最適化につなげていくという考えです。

３　ERPパッケージの誕生

考えてみると当然なのですが、企業全体のシステムを作るのは決して簡単ではありません。一からERPを作るのは非常に難しいことです。部門ごとではなく、全社一斉にシステム開発を開始する、という時点で足並みをそろえるだけでも困難ですので、 システム開発の時間はかなり長期化する傾向にあります。

その困難に目を向けビジネスの商機を見出した企業が今でいう「ERPベンダー」です。

「ERPシステムをパッケージ化すればよいのではないか・・・？」

ERPをパッケージとして（つまりERPを１つのソフトウェア・アプリケーションとして）各社に展開できるようにしておけば、いろんな企業が買ってくれるのではないか？

会社にとっても、無駄に一から開発するのではなく、１つの製品としてサーバにインストールするだけでERPシステムの導入ができたほうがはるかに楽です。

そうした流れの中で生み出されたERPのパッケージ製品が、SAP（SAP社）であり、Oracle EBS（オラクル社）なのです。

これで最初の解説の意味が分かるようになります。

SAPとは「SAP社」が製造する「ERP」製品のことなのです。

４　更にSAPをわかりやすく説明すると

SAPをさらに具体的にイメージできるように、モジュールという概念を解説します。

簡単に言えばモジュールとは「機能の集まり」です。

先ほど説明したように、ERPは「企業全体システム」ですが、分解していけば１つ１つの部門単位の機能に分けられます。

会計システム + 調達システム + 在庫管理システム + ・・・・ = ERP

みたいな感じでしょうか。
この「会計システム」とか「調達システム」みたいな部分をSAP用語では「モジュール」と呼んでいます。

SAPを導入する際には、このモジュール単位で使うか使わないかを決めることができるので、ここからはSAPの代表的なモジュールについていくつか解説していきます。




いわゆる「会計システム」です。
そしてSAPの花形（だと理解する人が多い）です。

FIが花形だといわれるのは、企業の最終的な業務データは全てこのFIモジュールに流れてくるためです。
（すなわち、すべての業務に対するある程度の理解が必要となり、難易度が高くなります。）

調達したらお金を払いますし、ものが売れればお金をもらいます。
人を雇えば、給料が発生します。
それらのデータがリアルタイムにFIモジュールに流れてくることになります。

なので、SAPを導入する際にFIモジュールを利用しない企業はほぼない、と言えることができます。

経理部、財務部などが主な利用想定ユーザです。

４．２　CO（ Controling ）：管理会計

管理会計をつかさどるモジュールです。

FIモジュールが財務諸表などの外部向けの報告書を作成することを目的とするのに対して、COは「内部向けの報告書」を作ることを目的とします。

すなわち部門単位の業績管理や、間接費の管理などを主な目的とします。

COモジュールも他のモジュールと同様、リアルタイムに全業務のデータが連携されてきます。

４．３　SD（ Sales and Distribution ）：販売管理

いわゆる「販売管理システム」です。

注文を受けてから、商品を出荷するまでを管理するのが主な目的です。

どの会社・人に注文を受けて、何を出荷するのか？

その出荷製品はいくらで、請求書はどこにどんなフォーマットで送れば良いのか？

などを管理するモジュールです。

もちろんモノを売れば代金を受け取りますが、SAPはERPシステムなので、売り上げのデータがFIモジュールに自動的に流れていきます。

４．４　MM（ Material Management ）： 在庫購買管理

いわゆる「在庫管理システム」「調達管理システム」です。

SDモジュールが「売る側」だとすれば、MMモジュールは「買う側」です。

どこに何を発注したのか？

どれぐらいの値段で発注するのか？

今在庫はどれぐらいあるのか？

などを管理します。

発注金額や、在庫量データは財務諸表に関わってくるのでこれも自動的にFIモジュールに流れていきます。

５　SAPを導入するには？

さて、ここまでで何となくSAPが何者であるかが分かってきたのではないでしょうか？
SAPはSAP社が製造しているERP製品であり、複数のモジュールから成り立っていることを説明してきました。

そしてこの最後の章では、SAPを導入する際の流れを解説しておきます。

「え、SAPってパッケージなんだからすぐ利用できるんじゃないの？」

ここまでの解説ではこんな疑問を抱いてしまうかもしれませんが、それは誤解です。
SAPはインストールするだけでは利用できません。
簡潔に言えば「導入する企業に合わせた設定」が必要になってきます。
この設定のイメージまで付けばSAPという製品の全体像が見えてきます。

「導入する企業に合わせた設定」 は次の2ステップで行われます。

�@コンフィグ（カスタマイズ）

�AABAP開発（アドオン開発）

以下、それぞれの具体的な作業イメージを説明していきます。




コンフィグとは、コンフィグレーションの略で、別名カスタマイズとも呼ばれます。
もしくは「パラメータ設定」とも呼ばれます。

この作業では、SAPが事前に用意している設定項目を一つずつ設定していくことになります。

コンフィグの代表的なものを挙げるだけでも、「会社名」や「所在地」といった基本的なものから「消費税の設定」「伝票の項目」など実際の業務に密に関連してくるものまで幅広く存在します。

SAPのすごいところは「そんなものまで設定できるの？」というほど、設定項目が充実しているところです。この幅広さが、世界中の企業に採用されている大きな理由の１つになっています。
逆に言えば、この設定が難解なものになってくるため、SAPコンサルなどの専門職が必要になってきます。

この設定を隅々まで知り尽くしているSAPエンジニアが、導入時に活躍することになります。

５．２　ABAP開発（アドオン開発）

コンフィグ（SAPの設定）だけではどうしても実現できない機能を追加する作業です。SAP専用のABAP（Advanced Business Application Programming）と呼ばれるプログラミング言語を用いて、独自の機能を追加していきます。

SAP導入時に一番大変な作業がこの工程です。

なぜなら、ABAP開発がなければ「バグ」がほとんど生まれないからです。SAPを導入している企業で、もし不具合やバグが起きているとすればそれは９５％はこのABAP開発が原因といえます。（例外はあります。）

ABAP開発では、SAPの標準仕様に加えてABAPの知識が必要になるため、開発費用がかさみます。

６　FAQ：SAPとERPの違い

よくある質問の１つ「SAPとERPは何が違うのか？」というものがあります。たぶん、どちらも英語３文字で似たような概念のため混乱してしまう人が多いものと推測されます。

ただ、ここまでお読みになった方なら答えは簡単にわかりますね。答えは、

「SAP　⇒　SAP社のERPパッケージの製品名称」

「ERP　⇒　企業全体システムのこと」

です。「SAP」と「ERP」は似ているものの、概念は異なりますので正確に理解しておくことが重要です。

そのうえで、SAPはERPパッケージの製品名称であるので、その意味では

SAP　≒　ERP

である、ということも可能です。あくまでも、SAPは会社名・製品名であり、ERPは全社システムの総称であることを理解しておきましょう。