【SAP基礎知識】SAPとは何か?基礎と概要の解説(SAPコンサルタントによる入門解説)

SAP 共通・マスタ・組織

SAP ERP基礎解説―はじめに―

SAPにかかわる基本的な知識を解説します。

【こんな方に読んで頂きたい】
SAPに関する基礎知識がなく、日本語での情報も少ないためとっかかりに困っている方。
・SIerの新入社員でSAP案件にアサインされた
・SAPシステムのユーザヘルプデスク業務に参画した
・IT部門社員だがSAPについて知識がなく、概要を知りたい

SAPを勉強するのであれば、システムの理解も大事ですが、同時にビジネスや経営、会計に関する理解をすることも非常に大事です。それらを両立できる場合、SAPコンサルタントとして、SAP導入のプロジェクトにおいて上流工程を担当できます。

【解説対象】
・SAP R/3
・SAP ERP(ECC6.0)
・S/4 HANA

SAP ERPとは

SAPはERPパッケージソフトです。
ERPとは経営資源計画(Enterprise Resource Plannning)の略です。
販売・生産・購買・会計・人事といった企業活動全般を支援管理し、経営資源(ヒト・モノ・カネ)を効率的に計画し運用するためのソフトがSAPです。
SAPを導入したことで企業全体の数値化・指標化が可能となり、収益率や経営効率が向上した企業も多数あります。

「パッケージソフト」とは

簡単に言うと、既製品のソフトの事です。

基本的な機能群がすでに開発実装されており、適用する顧客企業により細かいカスタマイズを行います。基本的な機能群(標準機能)ではどうしてもカバーできないものについては追加開発機能(アドオン)によりカバーします。
ERPパッケージの導入は大手SIer(システムインテグレータ)が受注し顧客企業への導入を担当し、数か月~数年の単位で導入プロジェクトを展開します。

主なERPパッケージは、世界シェア最大のSAPをはじめ、Oracle ERP Cloud、Microsoft Dynamics 365など海外勢が強いですが、OBIC7など純国産のものもあります。

パッケージソフトの対になる概念が「スクラッチ開発」と呼ばれるもので、顧客企業の要望に合わせて1からシステムを構築していくアプローチのことです。一般的なシステム開発のイメージはこっちだと思われます。

「パッケージ導入」と「スクラッチ開発」の比較

コストメリット

パッケージソフトは出来合いのソフトである分、一般的にコストメリットはスクラッチ開発よりも大きいと考えられます。SAP ERPの規模のソフトを一から作るとすると、莫大なコストがかかります。SAP ERPは比較的高いソフトであり、導入の際の技術者の単価も高いものですが、企業全体の業務をカバーするような基幹システム導入を目指す場合は、SAPは有力候補の一角となります

「部分最適」と「全体最適」

スクラッチ開発では個々の企業の業務に合わせて、それに最適化する形で顧客要望への完全適合を目指してシステム構築を行います。個々の業務に合わせたシステム構築に陥りやすく、そのような状態を「部分最適」と呼びます
部分最適が集まった時、全体としてちゃんと機能するかというと、実はそうではない場合があります。データ構造があまりにも違いすぎて、受注と生産システム間で連携が取れない、連携しているけどバッチ処理なので一日遅れ、ということもよくあります。企業の長い歴史の中で、順次各業務に対し管理システムを構築していった末に、そのような状態になっている企業が多いです。

一方、ERPパッケージというのは、最初から「全体最適」を目指してデザインされています。各業務の細かい要求には応えられないが、データ構造が共通化されており、全体としてデータの整合性があり、かつリアルタイムに連携できるため、企業全体・経営者視点で見ると、企業活動にフィットし情報を素早く活用できるシステムとなります。

また、「ベストプラクティス」という概念に基づきパッケージソフトは設計されています。ベストプラクティスとは、ある種の業務が効率的に遂行されるためのビジネス上の仕組みや手順のことであり、その業務シナリオに適合するシステムデザインを目指しています。よって、ERPパッケージを導入して、業務の流れをシステムに合わせることで、業務が効率化されベストプラクティスに近づく、という考え方となります。
現在の業務に合わせてスクラッチ開発でシステムを作ることとは対極にある考え方です。

システム導入などに際して業務の流れを見直し再定義することを「ビジネスリエンジニアリング」と呼びます。

SAP ERPの機能概要

モジュール

販売・生産・購買・会計・人事などの企業活動の分野に分かれて、機能群(モジュール)が用意されています。企業活動に必要な機能群があらかじめ用意されています。主なモジュールは下記のとおりです。

販売管理 SDモジュール
購買管理 MMモジュール
生産管理 PPモジュール
財務会計 FIモジュール
管理会計 COモジュール
人事管理 HRモジュール

SD、MM、PPはロジスティクス、FI、COは会計として分類されます。
SAPは特に会計機能を強みとしており、堅牢性への定評があります。

モジュール間の連携(統合されたデータベース)

モジュール間でリアルタイムにデータ連携を行うことを前提として、データ構造がデザインされています。モジュールが分かれているからと言って、それぞれ別機能・別システムとして独立しているわけではありません。

モジュール間のデータ連携とは、例えば下記のようなことです。

【データ連携の流れ】
販売機能から受注入力を行うと、受注した製品の所要が発生します。在庫数量はリアルタイムに確認でき、十分に在庫があればそのまま在庫を引き当てて出荷します。
一方、もしその製品の在庫が現在不足していた場合、不足分が生産機能の方に計画手配として製造依頼が伝わります。MRP(資材所要量計画)を実行することにより、製品の不足分、さらにその製品を製造するために必要な原料の不足分などがブレークダウンされ計算されます。原料は自社生産していないものであれば外部から調達しなければならないため、購買機能に発注のための依頼(購買依頼)が連携され、発注伝票を起票して実際に仕入先への発注を行います。
原料を調達、入庫し、製造に原料が使用され、製造完了により製品が補充されると、改めて販売機能から出荷処理が行われます。
こうした処理が、モジュールの垣根を意識させず、シームレスかつリアルタイムに連携されていきます。
さらに、こうした処理に伴い会計モジュールにもデータが連携されます。財の増減に際しては会計仕訳を起こして財務上の帳簿にそれを記録する必要があります。財の増減というのは、原料の調達、原料の入庫、製品の製造に伴う原料の消費と製品の入庫、販売に伴う製品の出庫、および製品の売上といったものです。これらを会計上記録するために「仕訳」のデータがロジスティクス上の動きと同時に会計データが登録されるというわけです。
※仕訳記述は売上原価対立法による。

各モジュールの機能

かなりざっくりした機能説明です。モジュールごとの説明は別途記事にします。

販売管理 受注伝票、出荷伝票、請求伝票の登録
購買管理 発注伝票、仕入先請求伝票の登録、在庫管理
生産管理 製造指図、製造実績計上、MRP
財務会計 会計仕訳伝票の計上、財務諸表の作成、固定資産管理など
管理会計 原価管理、部門費管理、配賦

※在庫管理やMRP機能は複数モジュールの中間的な位置にありますが、ここでは分かりやすさ重視でざっくりと切り分けました。

SAPは特に財務会計機能が強く、会計モジュールだけの利用目的でSAPを導入する企業も多数存在します。この場合は、ロジスティクスは独自構築あるいは別のロジスティクス特化のパッケージを導入し、SAPに会計情報だけ連携するというようなシステムランドスケープを築くことになります。

カスタマイズ

SAP ERPはパッケージソフトですが、それをそのまま導入しても即日使用できるわけではありません。顧客企業ごとの調整が必要で、それを「カスタマイズ」と呼びます
SAPには膨大なカスタマイズ項目があり、どのパラメータを変えたらどのような効果があるのかは、専門の技術者(SAPコンサルタント)の知見が必要となります。

【カスタマイズについての具体的イメージ】
例えば顧客企業の購買プロセスに大きく2通りの方法があったとします。仮に、それらは「原料購買」と「サービス購買」であったとします。購買時の手続きあるいは承認ルートなどの違いによって、2プロセスに分かれているのです。
こうした場合、それぞれのプロセスを処理するために最適な発注伝票の機能は異なってきます。原料は物質的な存在で、在庫管理を行う必要があるものですが、サービスは不定形なものなので在庫管理は必要がなく、会計処理も両者の間では異なります。
なので、まず「発注伝票タイプ」を二種類定義し、発注を起票するときに原料を買うときであればタイプA、サービスを買うときはタイプBを選ぶ、というルールにしておくわけです。タイプA(原料)のときは原料を購入するのに最適な伝票フローや伝票項目を定義しておき、同様にタイプB(サービス)のときはサービスを購入するのに最適な設定を定義しておくわけです。
これがカスタマイズです。2種類の発注タイプを作ったことにより、その企業の購買プロセスに適合させたシステムデザインを行ったわけです。

カスタマイズは多数存在します。組織を定義するカスタマイズ(会社コード、プラント、購買組織、販売組織)や伝票機能を定義するカスタマイズ(伝票タイプ、項目レイアウト)、より細かい動作を制御する多数のカスタマイズなどです。まさに膨大なパラメータ群が存在します。

アドオン

標準機能内でのカスタマイズを行っても、どうしてもその企業に適合できない部分が出てきます。
例えばその企業の単価決定プロセスが非常に複雑であり、単純な数量×単価で合計金額を算出するプロセスに割り込み処理を入れないといけない場合や、標準での一覧機能では業務担当の欲しい情報が全て出てこないので新規の一覧(レポート)機能を作成する必要がある場合です。
全てを「ベストプラクティス」に適用できない場合があり、必要と認められる場合はアドオンを作ります。場合によってはかなり大規模なアドオンを作成することもありえます。

アドオン作成は、当然ながらコストがかかるので、SAP導入する企業は最初は「標準機能のみ」で導入を実現することにこだわる場合もありますが、基本的には多少のアドオンは必ず必要となります。標準にこだわるのではなく、アドオンの厳選はしつつも、必要なところは必要なコストをかけるという姿勢であるほうが、導入プロジェクトが上手くいく可能性が高まります。

日本企業は独自発展させた業務プロセスや商習慣が多く、外国企業に比べてアドオンの数がかなり多くなる傾向があります。

アドオンを開発するか、カスタマイズでどこまで実現できるかの検討フェーズは「適合性分析(Fit & GAP)」と呼ばれ、パッケージソフト導入における要件定義フェースの段階にあたります。

マスタデータ

SAPに限りませんが、得意先、仕入先、品目といった、属性情報が定まったものをマスタデータとして登録します。SAPでは得意先、仕入先、品目が「三大マスタ」と呼ばれることもあります。
たとえば仕入先であれば、仕入先の名称、住所、振込先の銀行、支払い条件、インコタームズといった情報をマスタとして保持しておけば、取引の都度仕入先の属性情報を入力する手間が省けます。マスタ登録を行うと「仕入先コード」というものが発行されます。

他にも、仕入先・品目ごとの単価情報を保持する購買情報マスタ、生産に使用する部品構成表を登録しておくBOMマスタ(Bill of Material)、作業工程を登録しておくための作業手順マスタ、会計の勘定コードを定義しておくGL勘定マスタなどがあり、紹介しきれない程度には多数存在します。

トランザクションデータ

伝票など都度都度作成されるデータをトランザクションデータと言います
マスタと違い、そのつどの注文内容に応じて入力情報が変わります。

トランザクションコード

SAPの画面機能は「トランザクションコード」が付与されており、SAPの画面機能を呼び出すには、メニューから機能をクリックするか、トランザクションコードで直接呼び出すことが出来ます
トランザクションコードは概ね4文字の英数字となっていますが、5文字以上あるものもあります。
例えばこんな感じです。

トランザクションの例①
MM01 品目マスタ登録
MM02 品目マスタ変更
MM03 品目マスタ照会

新しい品目を登録したり、既存の品目の情報に変更が生じた場合は、品目マスタを編集する必要があります。その際に使うのがMM01やMM02といったコードで呼び出し可能な画面です。この画面を通じて編集作業を行うこととなります。
MM03は照会機能となっており、ただ参照したいときに使うものです。

トランザクションの例②
VA01 受注伝票登録
VA02 受注伝票変更
VA03 受注伝票照会

得意先から引き合いがあり、自社製品を販売する際には、受注の事実を登録するために受注伝票を作成します。そのときに使用するのがVA01から呼び出される画面です。あるいは既存の受注で、変更や入力間違いが判明した時はVA02を使用して受注伝票の修正を行います。

上記の例をみて気付かれた方もいるかと思いますが、登録は1、変更は2、照会は3という末尾の番号が振られることが多いです。ただし、この体系が必ずしも適用されない場合もあります。

このように、SAPにはデータ処理を行う様々な画面機能があり、各画面を通じて業務データ(発注や受注)をまわしつつ、リアルタイムな在庫や生産状況を考慮しつつ、業務を処理していくこととなります。

環境

開発機、検証機、本番機

SAPは通常、3インスタンスで構成されます。

・開発機
・検証機
・本番機

それぞれが別サーバで、開発機はプログラム開発やカスタマイズ変更を行うための環境、検証機はプログラムやカスタマイズの動作を確認する環境、本番機は実際の業務データが運用されている環境です。
稼働中のシステムでも、システムの修正や拡張は日々行われます。まず変更修正を行う際は開発機にて実行します。開発機で行った変更を、次に検証機に反映させます。検証機で十分なテストを実施し、OKであった場合のみ、本番機に反映を行います。
本番機は稼働中システムなので、ヘタなシステム変更は致命傷を招きますので、検証は網羅的に、高品質に行う必要があります。

これらの環境同士で、変更した内容(プログラム変更、カスタマイズ変更)をやり取りするための仕組みが「移送」というものです。

移送

プログラムやカスタマイズ変更を行うと都度、「移送番号」が登録されます。
移送番号には、移送するオブジェクトの変更内容が紐づいています。
この「変更箇所」が登録された移送を、検証機、そして本番機に持っていくことで、反映させます。
SAPの移送ボタンはトラックのような形のアイコンですが、もちろん物理的に運ぶのではなく、サーバー間をつなぐネットワークでデータを移送して移送先システムに反映させるのです。

クライアント

SAP GUIのログイン画面の上部に、3桁のコードを入れる「クライアント」という項目があります。これがクライアントIDです。
クライアントが一つのSAPシステムの単位だと思っていただければ良いです。クライアントはサーバ内(本番機なら本番機の中に)複数作ることが出来ます。例えばクライアント100、200、300など。

クライアントで仕切りを作ると、SAPシステム内の世界を仕切ることが出来ます。例えば、クライアント100で作った伝票は、200からは見えませんし、お互いに操作することも出来ません。言うなればパラレルワールド。互いに独立した環境として運用することが出来るのです。

クライアント分けにはいくつかの目的があります。本番環境下では、例えばSAPを関連会社ごとに環境を仕切って使いたい場合、会社ごとにクライアントを割り当てるなどします。検証環境下では複数クライアントを作るのは、よくあることです。検証をしたいときに、あまりゴミデータがない環境を使いたい、あるいは環境内で一度きりしかできないような検証があるとき、クライアントが複数あれば、互いに独立しているのでクライアント数だけ検証を繰り返すことが出来ます。これは、構築や保守をする上で結構有効で、一度きりしか検証データを取れないとプレッシャーがある以上に失敗を回避するために膨大な準備時間を要しますが、複数クライアントによりトライ&エラーができるとなれば、作業負荷は大きく軽減します。

クライアント依存/非依存

クライアント事に環境が仕切られると記載しましたが、実はすべてのデータが仕切られるわけではありません。
プログラムやアドオンは、クライアント非依存のオブジェクトです。つまり、プログラムはクライアント間で共通ですので、クライアント分けをしてもシステムのベースの動作は同じになります。
一方、カスタマイズはクライアント依存です。伝票などのトランザクションデータも、クライアントの中だけのものです。

次世代のSAP(S/4 HANA)と2025年問題

SAPの現行バージョンはSAP ERP6.0です。前バージョンはSAP R/3と呼ばれます。
すでに次世代バージョンであるS/4 HANAが登場しており、すでに各企業で次世代の導入もしくは既存のERP6.0からの更新が進んでいます。

S/4 HANAでは、高速で強力なHANA DBを用いた大量データのリアルタイム処理や、ビジネスプロセスのシンプル化、Fiori(HTML5上で動作する画面機能)によるマルチデバイス対応など、迅速な経営判断に有効となるメリットを多く打ち出しています。
データ構造を見直し、DBテーブルの構成をシンプル化するなど大量データ処理への対応も行っており、ERP6.0の仕組みのいくつかは、次世代バージョンでは変革されることになります。
ただし、すべてが変わるわけではないので、既存の枠組みが踏襲される部分も当然残ります。

現在、SAP ERP6.0あるいはそれ以前のソフトを使用しているユーザ企業は、S/4 HANAへのアップグレードを推進しています。SAPの「2025年問題」といわれ、2025年末にERP6.0に対するSAP社公式のサポートが切れるためです。詳しくは下記の記事にまとめています。

【2025年問題】SAPエンジニアの今後の稼ぎ方
2025年問題とは、簡単に言うとSAPの現行バージョンである【SAP ERP6.0】を含むいくつかの製品について、SAP社が2025年にサポート提供を終了すると言われており、SAPを導入している各企業は次世代SAPである【S/4 HANA】への移行を迫られているということだ。それには大量の人材が必要となるので、SAPエンジニアは引く手あまたとなる。

ただし、最近SAP社が2025年までのサポートを2027年まで延長すると発表したため、2025年問題は2027年問題となりました。ただ、システム導入のタイムスパン(数か月~数年)を考えると、2年の延長は多少ユーザ企業に余裕を与えますが、それでも安心してシステム投資を先延ばしできるほどの期間延長ではありません。
ブログランキング・にほんブログ村へにほんブログ村

タイトルとURLをコピーしました