[ERPシステム概要]
受注を受けると在庫がある場合は出荷可能となります。しかし在庫が無い場合は物をつくらなければならないので、生産計画が立ち、製造時には製造指図が発行されます。製造を行うためには必要な原料や中間品が確保されているのが条件です。原料や中間品については在庫がある基準点を切ると自動的に購買発注の指示をしたり、中間品の製造指示をするような発注点管理を行っています。製造を行うための必要な原料は中間品は配合表（BOM)に登録されてます。
受注、購買の売掛金、買掛金のデータは経理のモジュールFIに流れていきます。また人事のモジュールの給与計算においても給与支給データは経理のモジュールFIに流します。原価計算は配合表（BOM)や作業手順（製造工程手順）と連携されています。もちろん移動平均価格のような在庫価格評価が可能です。
仕入先直送の場合の受注は購買依頼が発生し、購買モジュールに処理が引き継がれます。
基本的に在庫の管理と金の管理を統合させたものがERPです。
SAPのモジュールには機能別に経理FI、管理会計CO,受注出荷SD、生産PP、在庫管理MM、購買PR、人事HR・・・などがありますが、それらが連携されています。
事業部体制に対応するために人事領域、人事サブ領域、販売組織、製品部門、流通チャネルのようなバラメータがあり、そのパラメータを操作することに別体系の組織が構成できますが、一旦運用してからのパラメータ変更はやっかいなことが多いので、中小企業はそれらのパラメータをあまり積極的には使わないほうがよいかもしれません。
R/3は典型的な製造業の各部署の連携した業務機能をひとつのDBにしたモデルシステム（お手本）です。ERPをパッケージで実現するか作りこみで実現するかはその企業の自由ですが、構造的にはお手本といえるので勉強しといて損はないと思います。しかし、それはあくまでもシステム屋の美学的な満足であって、本当に使い勝手がよく、ユーザーに満足をあたえ、生産性を工場させるには、大金をかけてその企業の業務にあったADDON（追加プログラム）を作りこむしか仕方がないんじゃないでしょうか？
[R/3導入のメリット]
R/3では可能な限りリアルタイム処理を行い、日次のバッチ処理は比較的少ないです。そのためサービス時間が長くなります。
データが整備されているのでEXCELにダウンロードが容易で、ユーザーが自由に加工できます。
したがってエンドユーザー・コンピュータが普及している会社ではメリットがあっても、そうでない会社は導入に金がかかるだけです。サービス時間が長くなっても、そんなに残業したくないですよね。またメリットの効果はすぐ出てきません。ビッグバン方式でホストから全面移行した場合、導入直後は大混乱になります。これはシステムバグの問題だけではなく、マスター移行のもれ、ユーザーのオペレーションミス等のさまざまな要因が考えられます。この問題を防ぐために実践さながらの統合テスト検証に十分な時間をかけましょう。
すでに、既存のシステムで生産と原価計算、在庫管理が連携されているシステムを使っている企業はERPの効果はほどんど出ないと思います。マシンをリプレースすることで最新のハードやDB技術が使えるので理論的には処理速度が速くなりますが、企業独自の処理などはプログラムのアルゴリズムやインデックスを最適化しないと思ったように性能も出ないのです。
生産、出荷、所要量計算（MRP）、在庫管理、原価管理関連のデータを共通のDBテーブルを連携させたのがERPの核心の部分なので、これらの処理をしない企業、またはまったく独自のシステムでないと実現できない企業には、ERPパッケージを入れてもERPを導入した意味はないかもしれません。販売、仕入の売掛買掛管理、人事給与管理なら、他のいくらでも安く構築できる方法があって、いくらERPパッケージを入れたと言っても、は真の意味でのERPでなく、一般的に言う合理化で、笑っちゃうことですが、これらの業務に限定してERPパッケージを導入するケースは成功しやすいようです。
ですから、本気にERPを導入したくなったら、原価管理についのポリシーをある程度決めて、そのポリシー合ったパッケージがあるかどうかで、パッケージ利用の有無を検討したほうがいいかもしれません。
[BRPとERP]
グループウェア、イントラネット、ワークフローのような情報系システムは、どこからでも誰からでも情報の共有、情報の発信を機会均等に与えることができ、フラットな組織作りという点でBPRに効果的です。ERPについては部署ごとのマスタ管理ではなく、全社的なマスタの一元管理を実現するもので、データ整備という点では意味がありますが、フラットな組織作りということにはほとんど貢献しません。実際に、全社的にマスタの一元管理をやろうとすと誰がやるの？というやっかいな問題が浮上します。
[R/3の主要テーブル]
同じ業務、種類のテーブルは似たような名前がついています。SE11で適当なアルファベットに*をつけて検索すればわかります。ヘッダと明細がペアになっているテーブルが多いです。これ以外にもR/3には多数のテーブルがあります。全部のテーブルのER図を書くことは困難です。ADDON設計時に必要に応じてER図を書いて理解するのがいいと思います。SE11でチェックテーブルという項目がありますが、これが外部キーのテーブルで、他のマスターだったり、パラメータテーブルだったりします。
受注ヘッダVBAK、受注明細VBAP、納入日程VBEP、取引先機能VBPA
出荷ヘッダLIKP、出荷明細LIPS
請求ヘッダVBRK、請求書明細VBRP
購買ヘッダEKKO、購買明細EKPO、納入日程EKET、購買伝票勘定設定 EKKN
請求書受領RSEG 保留請求書RBKP_BLOCKED 購買情報 EINA,EINE
生産計画PLAF、製造指図ヘッダAFKO、製造指図明細AFPO、入出庫予定RESB、入出庫MSEG
在庫MARD、 ロット在庫LQUA,MCHB、 ロット製造日付有効期限MCH1
棚卸数量 IKPF,ISEG,LINK,LINV
原価 COSS
品名MAKT、品目マスタMARA、品目評価MBEW
得意先マスタKNA1、仕入先マスタLFA1、条件マスタ（価格設定)ヘッダKONV、条件マスタ明細KONP、 スケール価格KONM、作業手順PLPO、配合STPOとMAST
得意先仕入先補足情報 ADRC、運送TR*
経理BSEG、為替レートTCURR,人事社員 PA* 人事組織HR1001、ユーザーＩＤ USR01、活動グループ AGR_USERS AGR_DEFINE
ABAPプログラム名 D010SINF トランザクションコード名 TSTC
リポジトリオブジェクト全部 TADIR 汎用モジュール TFDIR
テーブル名 DD02L テーブル説明 DD02T テーブルフィールド名 DD03L テーブルフィールド説明 DD03T
ジョブ実行記録 TBTCO
在庫管理の要となるテーブルはMSEG入出庫で移動タイプごとに入出庫が記録されます。移動タイプは、原料入庫、原料出庫、生産入庫、製品出荷などの入出庫タイプを定義したものです。
受注を受けて在庫が確保できロットが決まったら受注伝票テーブルのデータをコピーして出荷伝票テーブルが生成されます。出荷されると売上が上がったことになり、請求伝票テーブルが生成されます。
生産で必要となる原料はRESB入出庫予定（所要量）に登録されます。
A（数値）というテーブルと条件マスタKON*の組み合わせにより価格設定されますが、A（数値）のどれを使うかは、各企業のカスタマイズによると思います。
BSEGのようなものはクラスタテーブルと呼ばれ、クラスタテーブルやプールテーブルはABAPプログラムやクエリでテーブル結合が使用できません。透過テーブルならばOKです。BSEGは実際はいくつかの透過テーブルBS*の寄せ集めです。
マスタ類はいろいろなモジュール、業務で共通に参照されます。これがERPやカレントな企業システムの利点ですが、システムの全体を把握してデータ定義することが困難で、導入に手間がかかる原因にもなります。
[システム構成]
クライアント（パソコンや端末の意味ではない！！！）は同じサーバーマシン上にいくつかのモデルを置くことができ、そのひとつのモデルをクライアントと呼んでいます。R/3のテーブルの第１キーはクライアントの識別番号なので、クライアントごとに別のデータを持てます。ほとんどのパラメータ設定はパラメータテーブルのデータ設定を利用しているので、クライアント依存（クライアントごとに設定を別にすることが可能だとういう意味）です。ABAPのプログラムについては、サーバーマシン上で各クライアントが共通に使用できるものなのでクライアント非依存です。
移送はあるクライアントやマシンの変更を他のクライアントやマシンに反映させることです。開発環境、テスト環境、本番環境を同一にしなければならないので、ほとんどのケースで、各クライアントの設定（パラメータ設定）や、各マシンのプログラムを同じにする必要があります。各クライアントを同一の設定にする（同期をとる）方法は、コピー元のクライアントをコピーして新しいクライアントを作り、新クライアントやコピー元のクライアントに変更が加えられると、その変更をお互いに移送し合うことです。ADDONプログラム開発やパラメータ設定は通常、開発機で行われ、プログラムや設定をテスト機や本番機に移送します。
※以前はパラメータ設定のことをカスタマイズと言っていましたが、最近ではADDON開発のことをカスタマイズと言うそうです。パラメータ設定とはy要するに一般的なアプリケーションの設定同様、プログラムは書く必要はありません（ただしR/3に精通しているアプリケーションコンサルクラスの知識が必要！）。R/3は可能な限り、システムをテーブルのデータ設定で実現しているMS ACCESSのお化けのようなものです。マスター以外のデータで、サービス開始前に事前に登録、設定するデータがパラメータです。パラメータ設定について運用後も変更が必要な、人事組織、原価センタの組織等は設計時に変更の方法をよくコンサルから教わっておく必要があります（ずっとコンサル契約を続ける金持ち企業なら別）。
パラメータ設定の例としては、流通チャネルやプラントは販売伝票のパラメータです。これらのパラメータにより、その販売に関する営業部署や販売品目の製造場所が識別できます。仕分け項目もパラメータです。システム設計の経験がある人なら、コード定義をしますよね。このコード定義がパラメータ設定に相当するものです。
[データ移行]
導入時には既存ホストからのデータ移行を行います。データ入力はCATTやバッチインプットを用います。もちろん在庫についてもデータ移行する必要はありますが、どのような方法を使うか不明です。CATTやバッチインプットは手動により画面入力を行った手順をそっくり自動化して行う手法です。移行対象となるのはマスタ類ですが、在庫データも必要です。受注残も移行時に自動インプットしたほうがいいです。R/3の入力データは前述のパラメータの値に依存するので、パラメータ設定の責任者（コンサル）とよく連絡を蜜にしてデータ移行作業を進めたほうがよいでしょう。またデータ移行は時間のかかる作業ですので、あらかじめ時間を見積もっておきましょう。 導入移行の時間見積や手順の確認のために、事前に本番さならがの移行リハーサルを行いましょう。
本番稼動時期ですが、理想的には、ゴールデンウィーク、夏季休業、年末などにデータ移行と稼動確認を行いたいところですが、どういしても経理部から４月にしろという強い要望が出てきます。3月31日と4月1日の間に休日がない場合はかなり深刻です。
[ABAP開発]
SAP標準のプログラムを修正、改造することは禁止されているので、ADDONという方法を使います。つまりSAP標準のテーブル、またはADDONのテーブルを読み出したり、バッチインプットプログラムによりデータを入力する手法で企業独自の拡張を行います。Dynproは画面エディタで、これを使ったものをDynproプログラム、それ以外をレポートプログラムと読んでます。
開発クラスは開発チームごとにADDONプログラム開発やパラメータ設定のような開発成果物をまとめるグルーピングのことで、あまり便宜がない場合はひとつの開発クラスでもOKです。
[ADDONプログラムの開発が必要とされるケース]
・帳票 R/3標準のもので出力項目が足りない場合
・納品書、請求書 得意先による消費税まるめ方法の違い 日本の商習慣によるもの
・販売実績、管理会計 企業独自の算出方法によるもの
・他のシステムとのインターフェイス
・データ登録作業を自動で行わせたい場合
・企業独自の生産方式、品質管理方式・・・・その他多数の要因によるもの
はっきりいってほとんどADDONだらけになってしまいます！！！R/3は所要量算出や売掛買掛金計上のようなバックに隠れた処理をするだけで、表向きのところは企業独自に開発せざるを得ないのが現状です。
このようなADDONの開発したら、当然カットオーバー直後は大量のバグがでます。またADDONによってはテーブルにインデックスをはらないと思うようにパフォーマンスがでません。データ量が大きいテーブルアクセスを何百回、何千回とループさせるような処理は重くなるので、なるべく一発のSQLリクエストで適切なデータ抽出を行い内部テーブルの保存してから処理したほうがいいです。入出庫や会計のテーブルはがんがんデータ量が増大するので、この手のテーブルのアクセス回数を減らすことがポイントです。
ユーザーEXITはR/3がFORM（サブルーチン関数）の枠だけ標準で装備されているものがあるので、その中にユーザーが自由にABAPコードを書けば、その処理が特定のトリガーにより起動される仕組みです。特定のデータ登録時に付加的な機能を追加したい場合などで使う手法です。
[NOTE修正]
マイナーなR/3本体のバグ修正は直接R/3の標準プログラムを修正します。これを（先行）NOTE修正と呼んでます。
[バリアント]
プログラムの選択条件に値を固定したり、日付の条件を本日や先月に設定できるバリアントという機能があります。バリアント名の先頭に「CUS&」をつけるとクライアント非依存でバリアントを設定できます。
[クエリ、 QUICK VIEWER]
クエリやQUICK VIEWERはABAPプログラムを自動合成するものです。SQL文も自動合成されます。QUICK VIEWERは手軽で便利ですが（ACCESSみたいなもの）動作が不安定だったりします。これらは集計ができないところが欠点です。結果をピボットテーブルで出して、それで集計してくれとくことでしょうか？クエリの結果データをEXCELに出したり、ピボットテーブルで集計することもできます。
[外部インターフェイス]
IDOC、BAPI、ALE、RFC等がありますが、いい解説本がないので詳細は不明です。BAPIやRFCは汎用モジュールというABAPの関数を外部システムから使えるようにしたものという話です。
[バージョンアップ]
標準の機能に修正をせずにADDONのみで機能拡張を行った場合はバージョンアップの影響は少ないそうですが、実際はABAPのシンタックスタックの違いや、汎用モジュールの違い、バッチインプットのADDONでバージョンによる画面の違いから動作不良が起こったりするそうです から、事前にある程度のADDON修正が必要となります。Uptimizerと呼ばれるADDONの修正必要となる個所を検出するツールもあるので利用してみてはいかがでしょうか？標準テーブルにインデックスを付加した場合は、DBによっては、バージョンアップ時にインデックスをつけ直す必要があるかもしれません。
バージョンアップはR/3のバージョンアップだけでなく、ハードのリプレース、OS,DBのバージョンアップを行なうよい機会です。R/3のバージョンアップにより、DBも必然的にバージョンアップしなければならないケースがあるので注意が必要です。ですから、バージョンアップ計画は、R/3だけではなく、DB、OS、ハードのリプレースを意識してスケジュール作成しましょう。バージョンアップ作業中では、他の開発、ADDON修正は極力控えるように。
[トランザクションコード]
メニューに出てくる機能にはトランザクションコードというアルファベットと数字がつけられています。SAPでは機能をこのトランザクションコードで呼ぶことが習慣になっています。ADDONプログラムもSE93でトランザクションコードをつけれれます。
[活動グループ]
R/３ではたくさんのメニューがあり血迷う可能性もあるので、特定の業務で特定の機能しか使わないときは、一部のメニューに絞ることができます。
[ABAP LIST VIEWER：ALV]
クエリの後続処理オプションで対話式一覧というものがありますが、この表形式の表示方式です。ABAPプログラムでもこの機能を使うことができ、サンプルプログラム、BCALV_GRID_DEMO（基本的なALVプログラム）、BCALV_GRID_03（行をクリックすると詳細画面が出てくる）、BCALV_GRID_09（バリアントを保存できる）あたりを参考にすればALVを使ったABAPプログラムができます。
[ラインセンス]
使用方法によりカテゴリ分けし、カテゴリごとに何人使用するかで価格が決まります｡ 実際はADDON開発をした業者により多くの保守費用を払うはめになります。
[保守サポート]
OSSというSAP専用のメールツールみたいなもので問い合わせをします。アプリケーションの障害が発生したために本番機がとまったような緊急の場合だけ電話でサポート依頼ができます。ただし、ADDONの部分についてSAPのサポート範囲外です。GoingLiveCheckというパフォーマンス測定のサービスも行っています。ADDON開発を業者委託した場合は、その業者にカットオーバー後の保守をどうするのか事前に相談しといてください。
保守サービス上、SAP社からリモート接続しR/3サーバーの状態を見ることがたびたびあります。SAPルーターという専用のゲートウェイを設置する必要があります。
[サーバー、DB]
SAPが認定したものしか動作を保証していません。プログラムを動かすアプリケーションサーバーとDBサーバーは別々のサーバーでも同一のサーバーでもOKです。負荷が大きいならば、アプリケーションサーバーを複数立てることもできます。コンサルティング業者にスペックや構成の見積をしてもらうこともできますが、実際に動かしてみないとサーバーのスペックや構成が十分であるかほんとうのことはわかりません。特に新規に作るADDONのプログラムは実績がないわけですから、完成してみないとレスポンスがわかりません。その点で多くのモジュールを導入するビッグバン方式はバクチをするようなもんです。
DBはオラクル、MS SQL、インフォミックス、DB2などが使用できます。
[SAPGUI]
R/3のクライアントソフトです。Windows98や95では画面をたくさん立ち上げるとフリーズします。最近ではWEB画面のほうが主流になりつつあるのでしょうか？
[アーカイブ]
何ヶ月も運用していればデータがたまり、レスポンスの低下やバックアップ時間の増加をもたらします。古いデータをシステム外部に退避させることをアーカイブと呼んでます。アーカイブの対象になるのはデータ量が多いトランザクションデータです。マスタのアーカイブはなかなか困難です。トランザクションコードDB02でデータ量の多いテーブルは把握できますので、それらを中心に業務要件からアーカイブできるか否かを判断します。データを退避させるアーカイブサーバーはIXOS社のものが一番実績があるそうです。 さらにDVDチェンジャーに退避データを保存するのが一般的な構成となっています。
アーカイブする対象のデータのまとまりをアーカイブオブジェクトと呼んでいます。アーカイブオブジェクトの名前はSD_VBAKのようにテーブル名から派生していますが、メインテーブルとそれに関連するテーブルのデータをまとめたものがアーカイブオブジェクトという認識でよいと思います。
アーカイブの設定はトランザクションコードSARAで行ないます。あるデータをアーカイブしたいときには、事前に他のデータもアーカイブしとかないと、そのデータのアーカイブもできないような、順序依存関係があるので、ネットワークグラフィックで、アーカイブの順序を確認する必要があります。
対象アーカイブオブジェクトについて、伝票タイプごとに、何日以上まえのデータをアーカイブするような設定をします。そして、そのアーカイブの処理をジョブ登録することにより、定期的にアーカイブが自動実行されます。
[SAP連携ツール]
HAHTSite WEBアプリケーションサーバー、WEB Method EDI連携、翼システムSuper Visual Formade 帳票作成 ・・・等があります。
Suprer Visual Formade は、R/3からCSVファイルを出力させるADDONを作成し、そのファイルを帳票のフォーマットに紙で出力させるものです。フォーマットの作成はビジュアルなツールが使えます。
[書籍]
ABAPでは、「SAP ABAP プログラミング」ですが、肝心のDynproについての作成方法は詳しくのってません。「SAP R/3 システム管理」はバージョンが古いころの話なのであまり役に立つかどうかわかりません。 よい書籍がないので業務サイドも開発サイドも現状ではSAPの講習に行くかコンサルに教えてもらうしかないです。「SAP R/3 プロセス指向型のERP導入」は読まないほうがいいかもしれません。
[R/3 Enterprise]
現在ベーシスと呼ばれている部分は今後WEBアプリケーションサーバーと呼ばれるそうです。今のバージョンではITSという外付けのサーバーが必要ですが、今後はいらなくなるみたいです。言語はJ2EE(JAVA2 Enterprise Edition)が使えるようになり、ABAPからJAVAを呼び出したり、JAVAからABAPを呼び出すことも可能になるそうです。