皆さん、こんにちは。本投稿では、最近日本企業の中で盛り上がりを見せているSAP導入プロジェクトの基本について解説します。
SAPとは、言わずと知れた基幹業務システムのシェアNo.1のERPパッケージシステムのことで、多くの日本企業においても既に導入されています。
SAPのERPパッケージの最新バージョンはSAP S/4 HANAとなるのですが、ひとつ前のモデルであるSAP ECCは2025年にサポート対応が終了するため、2022年現在、多くの日本企業がすでに導入済みのSAP ECCをS/4 HANAへ移行しようとプロジェクトを企画しています。
SAP導入プロジェクトの必要性が高まっている一方で、過去にSAP ECCを自社企業に導入した人材はすでに定年退職済みというケースも多く、SAPに関する知見を持つ人材が相対的に少ない状況であり、この問題をSAP業界では2025年問題と呼ばれています。
そうした状況下において、事業会社、SIer、コンサルティングファームなどではSAPの知見を持つ方を広く募集しており、SAPの知見を持つ人にとっては高い市場価値を発揮するチャンスとなっています。さらに、現時点ではSAPの知見がなかったとしても業界としては深刻な人材不足であるため、勇気をもってこの領域でキャリア形成を図ろうとする方は大歓迎される状況です。
私の周りでも多くのSAP導入未経験の元エンジニアの方がコンサルティングファームに転職され、SAP導入プロジェクトに関与するようになってきています。
本投稿では、そうしたSAP導入プロジェクトにこれから関わっていくという方向けに、SAPの機能を調べてみたいとなったとき、勉強したいとなったときにどうすればいいのか、具体的な方法を提供したいと思います。
Agenda
想定読者
- SAP導入プロジェクトに初めて参加することになった事業会社、SIer、コンサルティングファームの方
- SAP導入プロジェクトを担当するSIer、コンサルティングファームのポジションへの転職を考えている方
SAP初心者向けの投稿記事まとめはこちら
先にこちらのブログで取り扱っているSAP初心者向けの投稿記事のまとめをこちらでご紹介しておきます。もしご興味がある投稿がありましたら、ぜひ見て頂ければと思います。
SAPの学習方法、機能の調査方法≒独学で1人前になる勉強方法
それではSAPの機能を自分自身で調べる方法、独学で1人前になるための勉強方法を解説します。
まず、SAP導入において、勉強すべきものとは何でしょうか。
以下に書き出してみます。
- 業務オペレーションの流れ、実行手順、トランザクションコード
- マスターデータとその項目
- トランザクションデータとその項目
- マスターデータとトランザクションデータの関係性
- テーブル構造
- カスタマイズ/Configurationの方法
これ等を効率よく学んでいくために皆さんにぜひ覚えて頂きたい方法は、以下に集約されます。
- SAPのBest Practice Explorerを活用する
- 過去データを参考に実際にオペレーションを実行してみる
- TCode Searchを活用する
- SAP Communityを活用する
- SAP Help Portalを活用する
それでは、一つずつ解説していきましょう。
SAPのBest Practice Explorerを活用する
SAP Best Practice Explorer、ご存じでしょうか？
Best Practiceというのは、SAPが提供する機能を用いた、多くの業界にあてはまる業務オペレーション、およびそのオペレーションを支えるデータ、カスタマイズ/Configurationの総称のことです。
要するに、Best Practiceと呼ばれているデータの持ち方、カスタマイズ/Configurationをしておけば、よく使われる業務オペレーションが実行できるようになる、一番いい状態にセットアップできるということです。
このBest Practiceとして定義されるものを検索することが出来るのは、SAPのユーザーであれば利用できる、SAP Best Practice Explorerというわけです。
SAPのユーザーであれば、S-User IDというものを発行することが出来ます。こちらのIDですが、会社によって管理の方法は異なりますが、従業員に対して個別に発行していたりすることが多いため、まだお持ちでない方でしたら会社の情報システム部門の方や、一緒に働いているチームメンバーの方に確認してください。
S-User IDとPasswordがあれば、誰でもSAP Best Practice Explorerが利用できます。
まずSAP Best Practice Explorerにアクセスしてみましょう。
こちらがSAP Best Practice Explorerの画面となっています。
このExplorer上で勉強したいと思っている業務に関係するSolutionや、モジュール名などにたどり着ければ、そこからBest Practiceを勉強することが出来ます。
今回は、S/4 HANAの購買管理プロセスを勉強してみたいということにしましょう。
SAP Best Practices for SAP S/4HANA (on premise)をクリックします。
そうすると、画面がこのように変わります。
Languageを変更することで、英語を日本語に変更することも出来ます。
今回は、英語のままで進めさせて頂きます。
ちなみに、SAP導入に関しては後程解説するSAP Communityの使用の際にも基本的に英語でSAPの用語を検索したりすることになるのでプロジェクト内の言語が日本語であるか英語であるかによらず、英語でSAPの用語は知っておいたほうが便利です。
Google翻訳を使いながらで十分に対応できますので、英語でSAP用語に触れるようにしましょう。
業務フローを確認してみよう
それでは、まずは業務フローを見ていきましょう。
業務フローを見る方法は2つあり、Solution Scopeから見つける方法と、Best Practice Content Libraryから見つける方法の2つがあります。
Solution Scopeから見つける方法
SAP Best Practice ExplorerからSolution Scopeをクリックして、このBest Practiceに含まれる機能にはどんなものがあるのか、見ていきましょう。
以下のように、Scopeに含まれる要素が表示されます。さらに各要素をクリックしていくと、詳細が確認できます。
今回は購買管理を学んでいきたいので、購買に相当する言葉を探します。
購買は英語ではProcurementまたはPurchaseなので、Sourcing and Procurementをクリックします。
そうすると、さらに細分化されたカテゴリーが出てきます。
ここでは、購買管理の一連の流れを知りたいので、Operational Procurementをクリックしてみましょう。
さらにさらに細分化されたものが表示されました。
これが一番細かなレベルとなります。この中で、自分が勉強したいものを選択しましょう。
SAPは様々な機能を提供しているため、それらの解説をするBest Practiceも多岐にわたります。したがって、ここでも様々なケースとそれに対応する機能について羅列されていますが、まずは一番基本的な業務として理解しておきたいものを選択しましょう。
今回は、まずは物を買う、という業務について知りたいので、そうした機能が説明されていそうなものを探します。
ここでは、Direct Procurement with Inbound Deliveryを選択します。
英語で表示していることもありますが、「Direct Procurementって何？」、「Inbound Deliveryって何？」という疑問は出てくることかと思います。
今回は、説明文の中にある、「発注書の作成から請求書の管理までの全てのステップを効率よく行うことを可能とします」という記載に目を付けました。
“It ensures an efficient process including all steps from the initial creation of a purchase order to the invoice management.”
こちらをクリックすると、また画面が変わります。
それでは次に、Key Process Flowsの箇所を確認しましょう。
ここに、このBest Practiceに含まれる業務フローが記載されています。
Manage purchase orders、Manage goods receiptという記載がありますね。
発注書の管理、受領品の管理、ということなので、物を買って、受け取るというところまでが業務フローに含まれているということになります。
それでは、実際に業務フローを見ていきましょう。
Detailsのセクションにある、Process Flowをクリックします。
そうすると、画面が切り替わり、このように誰が、何をする、という業務の流れがわかります。
列としてPurchaser, Receiving Specialist, Accounts Payable Accountantと3つに分かれていますが、これが「誰がその業務を実施するのか？」という点を説明してくれます。
そして、各ボックスが作業の一つ一つを示しており、下に流れることで業務を実行していくことになります。
これが、業務の流れです。
各ボックスの左上に人型のマークがあるものは、人がSAPの画面を見て処理を行うというステップであることを示しています。
各ボックスの左上に歯車マークがあるものは、人ではなくシステムが自動で実施する処理であることが表現されています。
ひし形のマークは分岐を示しています。矢印が入ってきたら、そのあと出ていく矢印のどれかに進むということが表現されています。
ここでは、その分期の条件については明記されていませんが、業務フローを見て勉強する間は、あらかじめ決められた条件に従って分岐する、というよりもむしろ、分岐先のどれかを選ぶことが出来る、実装したいものはどれにするか選ぶことが出来る、という風に複数のオプションがある、と考えておきましょう。
Best Practice Content Libraryから見つける方法
業務フローを確認するためのもう一つの方法として、Best Practice Content Libraryをご紹介します。
SAP Best Practices for SAP S/4HANA (on premise)の画面から、Acceleratorsをクリックし、SAP Best Practice Content Libraryをクリックしましょう。
そうすると、画面が以下のように切り替わります。
ここから、Filter Scopeで確認したいScopeを絞り込むと、Scope Itemsが列挙されるので、その中から確認したいプロセスについてProcess Flowをクリックしましょう。
Process Flow （BPMN2）をクリックすると、BPMN2で開くことのできるファイルがダウンロードされますが、これが入っていない場合はこちらのリンクではなく、「Process flow」と書いてあるリンクをクリックしましょう。
Solution Scopeの時とは異なり、各プロセスの概要説明はなく、Scope Itemのタイトルだけが書かれていますが、一覧で確認できるので、好みに合わせて使い分けてください。
ここまでで、自分が興味を持っている業務フローを見るということが出来るようになりました。
業務フローを見るときはCreate、Post、Approveに注目
まずは、SAPを理解するために業務フローを確認する様にしましょう。
細かな所は良いので、まずは大まかに流れを理解することが重要です。重要なのは、「Create＝何かを作成する」、「Post＝何かを転記する、記録する」、「Approve＝何かを承認する」というステップに注目することです。
「Create」とあると、その後ろには必ずと言っていいほど作成する対象であるTransaction Data、またはMaster Dataの名前が記載されます。
同様に、「Post」とあると、その後ろには帳簿に記録しなくてはいけないTransaction Dataが記載され、「Approve」とあると承認行為の対象となるトランザクションデータが記載されます。
したがって、Create, Post, Approveという文字に注目することで業務の手順として、どんなデータを作っていく必要があるのか、という点を理解できます。
今回の例では、大まかに以下の流れであることがわかります。
- Create Purchase Order
- Create Inbound delivery
- Post Goods Receipt
- Create Supplier Invoice
- Post Supplier Invoice
- Approve Supplier Invoice
Supplier Invoiceについては、作成した後に、転記をしていることがわかりますね。したがって、作成した時点ではまだ転記されていないのだな、ということもわかります。
こうした確認を通じて、業務の流れが大まかに理解出来たら、次はSAPの画面上では何をする必要があるのか、という手順を理解しましょう。
Test Scriptを見てみよう
それでは次に、Test Scriptを見てみて、実際にSAPの中で処理を行うときの手順を確認しましょう。
前提として、既に皆さんはSAPへのアクセスが出来るGUIをインストールしている状況とします。もし、GUIの設定がまだ済んでいないという方がいらっしゃいましたら、情報システム部門の方やプロジェクト内の関係者に確認をしてみてください。
GUIがインストールされていれば、SAPにログインし、SAPの機能をテストすることが出来ます。
Test Scriptは、SAPのBest Practiceを実際に動かしてみるときのカスタマイズやマスターデータなどの前提事項と、実際に処理を行う際の手順とそうした手順を取ったときに何が起こるのか、という内容を記載しています。
きちんとBest Practiceが動くようになっているかを検証する（テストする）ための文書、という意味合いになります。
例として、Direct Procurement with Inbound Deliveryの「Test Script」をクリックします。
そうすると、Wordファイルがダウンロードされます。
あとは、このファイルを読みながら、業務プロセスを実際にSAP内で実行してみて、業務オペレーションを学んでいきましょう。
こちらのWordファイル、内容は色々含まれていますが、まず見ておくべきセクションを以下に記載します。
- Purpose
Purpose
こちらの業務プロセスの目的が書かれています。
これまで、業務プロセスの内容はタイトルや、概要などで簡単に説明がある程度でしたが、このセクションで何を行うプロセスなのか、という点の解説がされています。
Master Data, Organizational Data, and Other Data
こちらのTest Scriptで実施していく業務プロセスの実行において、必要になるマスターデータ、組織情報などが羅列されています。
最初は初めて見る単語が多いかと思いますが、眺めているうちにこんなマスターデータや組織情報がSAPの中にはあるのだな、と段々と理解が進んでいくことになります。
Overview Table
こちらのセクションでは、実際にテストする内容の一覧が記載されています。
こちらのセクションを見て、特に興味があるプロセスについて、実際に手順を確認する様にしましょう。
Test Procedures
こちらのセクションで、SAPで実施する処理がステップバイステップで記載されています。
処理を進めるために必要なデータ、入力する項目などの記載もあるので、こちらを見ながら実際にSAPを動かしてみることをおすすめします。
最近はどのSAP導入プロジェクトでもBest Practiceで利用するデータをそのまま入れておくことが一般的なので、データはあらかじめ準備されている状況でテストを進めていくことが出来るはずです。
こちらがTest Procedureの例ですが、「Instruction」の列に何をするのか、「Expected Result」の列にそうすると何が起こるのか、という点が説明されています。
ただ処理を進めるだけではなく各ステップの意味を理解しよう
Test Procedureに記載されている手順に従って処理を進めていくと、当然ながら処理は完了できます。しかし、それだけではSAPを理解したことにはなりません。
大事なのは、業務の流れとSAPの中で行われる各ステップがリンクすることです。
したがって、業務フローとTest Procedureの各ステップの間を行き来しながら、各ステップの意味合いを理解するように心がけましょう。
過去データを参考に実際にオペレーションを実行してみる
ここまでで、SAPのBest Practiceを使用して、業務オペレーションを実行してみる、ということが少しずつ出来るようになってきました。
しかしながら、最終的にはSAP導入プロジェクトに関わる皆さんは、自分たちのプロジェクトにおける業務プロセスの理解をしていかなくてはなりません。
そこで、ある程度Best Practiceを通じて業務の流れ、SAPで実行する手順がわかってきたら、自分たちが関わるプロジェクトではどういったデータを活用して、どういった手順を踏んで処理を進めていくのか、という点を確かめるようにしましょう。
その際、過去データがSAP環境の中にあるかどうかによって、取れる選択肢が変わってきます。
フェーズごとの勉強方法
Planning、Designフェーズの場合
構想策定中、または要件定義/設計の段階では、まだSAP環境の中にデータが十分に存在しないケースが一般的です。したがって、参考にできる過去データというものは存在しません。
そのため、この段階ではBest PracticeのTest Scriptで解説されている手順を自分でやってみる、ということをしておきましょう。
Buildフェーズの場合
開発が進んでいる状況では、プロジェクト内の各チームがカスタマイズ/ConfigurationやWRICEFオブジェクトの開発に着手しています。
そうすると、各チームは自分たちの行ったカスタマイズ/Configurationや開発プログラムがきちんと動くかどうかを確認するために、実際にデータをSAPに投入して業務オペレーションを実行し、確認をすることになります。
したがって、この段階になると過去データが作成されている状況になります。
ここでおすすめしたい勉強方法は、過去データを確認してみて、作成されているトランザクションデータを見つけ、それと同じものが作れるかを試してみる、というものです。
ここまでで、業務フローについて皆さんは大まかに理解をされている状況と思います。そして、Create、Post、Approveという言葉に注目しながら業務フローを確認してきたことで、何をトランザクションデータまたはマスターデータとして作ることになるのか、という点も理解が及んでいると思います。
そういったデータを作るための方法を確認し、実際に試してみることを通じて、理解を深めていこう、というアプローチとなります。
SAP導入プロジェクトの流れについての解説の中で、単体テストというものを行うということを解説しました。単体テストには2種類あり、カスタマイズテストと単体機能テストの2つです。
それぞれがどういったものだったかはすでに解説していますので、復習されたい方は前の章に戻って頂ければと思います。
これ等の単体テストを実施する際、プロセス/Processチームは単体テスト結果を文書に記録しています。これらの文書を閲覧すると、テストステップとしてSAPで実際にどのような手順を取ったのか、という点がまとめられているので、これらを活用することで皆さんご自身の手でSAPの業務オペレーションを再実行することが出来るのです。
カスタマイズテスト結果を参考に業務オペレーションを実行してみる
Buildフェーズでは、カスタマイズを実施した結果をカスタマイズテスト結果にまとめています。その際、実際にテストを行う際にとった手順がテストステップとしてまとめられています。
カスタマイズテストを活用して勉強する方法ですが、手順は以下の通りです。
- カスタマイズ一覧を確認し、自分が確認したいカスタマイズの内容を決める
- 自分が所属しているチームの担当するカスタマイズを確認し、そこから着手するのもOK
- カスタマイズテスト結果を確認し、テストステップを実行してみる
- 出来るだけ多くのトランザクションデータの番号が記載されているものを選ぶ
カスタマイズは内容によってはとある項目の選択肢を増やす、程度の軽微なものも含まれているので、そうしたカスタマイズのテストステップを再実行してみても、あまりSAPへの理解は深まりません。
「SAPの学習をすること≒業務オペレーションを理解すること」ですので、テストステップを実行するときは出来るだけ業務オペレーションの実行に近いものを選択する様にしましょう。出来るだけ業務オペレーションの実行に近いテスト内容を選ぶコツは、テストステップの実行結果に、ステップの実行によって作成されたトランザクションデータの番号が多く記載されているものを見つけることです。
トランザクションデータというのは、SAP内で生成された発注伝票、入荷伝票、などの文書のことを指し、これらが作成されることで業務が進むため、トランザクションデータが作成されているということは業務オペレーションが実行されているということを意味します。
そしてテストステップを実行したときにこうしたトランザクションデータが生成されている場合、そうしたトランザクションデータに発行された番号はテストを実行した証拠として記録されていることになります。
よって、こうした番号がテストの実行結果に多く記録されていれば、そのテストは業務オペレーションを実行しているテストですので、再実行してみるとSAPの業務オペレーションを理解するために良い教科書になってくれます。
単体機能テスト結果を参考に業務オペレーションを実行してみる
カスタマイズテストを活用して勉強する方法と同様に、WRICEFについてはWRICEFオブジェクトの単体機能テストを活用して勉強する方法があります。手順は以下の通りです。
- WRICEF一覧を確認し、自分が確認したいWRICEFの内容を決める
- 自分が所属しているチームの担当するWRICEFを確認し、そこから着手するのもOK
- 単体機能テスト結果を確認し、テストステップを実行してみる
- 出来るだけ多くのトランザクションデータの番号が記載されているものを選ぶ
WRICEFの単体機能テスト結果を用いて勉強を進めるときも基本的な方法はカスタマイズテストのときと一緒です。出来るだけ、多くのトランザクションデータを生成しているテストステップを選んで実行する様にしましょう。
注意したいのは、WRICEFのテストステップ実行はSAP標準の機能ではなく、追加開発を行った機能のテストをしているということです。したがって、WRICEFの単体機能テストを実行するときは、どこまでのステップはSAP標準機能の範囲で、どこから先がWRICEFの機能なのか、という点をきちんと区別しておく必要があります。
この部分を理解しながらテストをするためには、WRICEFの機能設計図書を確認するようにしましょう。すべてのセクションを詳細に確認する必要はありません。WRICEFの機能設計図書には概要、目的を記述するセクションがありますので、それを確認することで、どの機能が追加開発しているものなのかを把握することが出来ます。
なお、WRICEFの単体機能テストのステップの方がカスタマイズテストに比べてステップ数が多くなることが一般的です。まずはカスタマイズの方から始めて、慣れてきたらWRICEFの方も着手するとよいでしょう。
Testフェーズの場合
既にTest フェーズに突入しているのであれば、Best Practiceが提供しているTest Scriptに近い形態で、結合テスト、統合テストといったテスト用のテストステップをプロジェクト内で作成している可能性があります。
そうした資料が既にあれば、そちらを探し出して、業務オペレーションを実行してみると理解が早いでしょう。
カスタマイズテスト、単体機能テストの時とは違い、業務の開始から終了までのEnd to Endのステップが事細かに書かれているので、非常に参考になります。
使用するデータはすでに整っており、カスタマイズなども住んでいる状況なので、問題なく処理を進めていくことが出来るはずです。
過去データを見つける方法
さて、それではSAP Best Practice Explorerで見つけた業務プロセスや、プロジェクト内部で見つけたカスタマイズテスト結果、単体機能テスト結果、あるいは結合、統合テストのテストステップを基にSAPで業務オペレーションを実行してみよう、となったとします。
このとき、SAPにアクセスして文書に記載されている手順通りに実行する前に、過去データがシステム内に存在するかどうかをチェックすることをおススメします。
過去に既にデータが作成されているということは、そのデータを実際に参考にしながら業務オペレーションを実行してみると、成功率が高いと考えられるからです。
前提として、既に皆さんはSAPへのアクセスが出来るGUIをインストールしている状況とします。もし、GUIの設定がまだ済んでいないという方がいらっしゃいましたら、情報システム部門の方やプロジェクト内の関係者に確認をしてみてください。
GUIがインストールされていれば、SAPにログインし、SAPの機能をテストすることが出来ますので、早速ログインしてください。
まずは過去データを見つける方法を解説します。第一に、今から何を見たいのか、という点を決めましょう。
今回は、例としてSAP Best Practice Explorerを用いて、勉強を進めてみることにしますので、Direct Procurement with Inbound Deliveryという業務フローの中で出てきた、Purchase Orderを探してみたいと思います。
もし、皆さんが単体機能テスト結果、カスタマイズテスト結果、結合/統合テストのテストステップを既にお持ちであれば、トランザクションデータが生成されている実行結果を確認してみて、そこでは何を作成したのか、という点を確認してみてください。そのなかから、自分が実際に作ってみたいデータをえらぶようにしましょう。
それではまず、Google検索を行います。検索キーワードは、「Purchase Order Table Name SAP」です。皆さんが探したいものの後ろに、「Table Name SAP」と付けて検索を行いましょう。
そうすると、以下のように検索結果が表示されました。
ここでは何をしているのかというと、SAP内でデータを格納しているテーブルの名前を確認しています。
SAPでは、マスターデータもトランザクションデータもテーブル上に格納されており、そのテーブル名がわかれば、過去にどんなデータが作られてきたのか、という点がテーブルを見ることで理解できるのです。
Purchase Orderを検索すると、なんだか4つほど、テーブル名がヒットしました。
EKKO、EKPO、EKBE、EKKNの4つです。
SAPのデータは、同じPurchase Orderというデータでも、ヘッダーとアイテム、といった単位で別々のテーブルに格納されているケースがよくあります。
まずは概要を知りたいのであれば、Headerと書かれているものに注目して確認する様にしましょう。
ちなみに、テーブル名は覚えなくて構いません。必要になったら、都度Googleで検索しましょう。
それでは、今回はテーブル名：EKKOを確認してみます。
まずはSAPにログインしてください。
ログインするときは、開発環境がおすすめです。開発環境のクライアント番号を確認し、その番号をログイン画面で指定して、あとはユーザー、パスワード情報を入力します。
開発環境は単体テスト等を行う環境であるため、過去にテスト用のデータが作成されている可能性が非常に高いため、参考にできる過去データが見つかる可能性が高いです。
もし、既にテストフェーズに入っているのであれば、単体テストではなく結合テストや統合テストなどを検証用の環境で実施している可能性も高いため、検証環境を確認するのも良いでしょう。
復習：開発環境、検証環境とは？
開発環境、検証環境という言葉がよくわからない、という方向けの復習解説です。すでに解説している内容が含まれますので、お分かりの方はスキップしてください。
SAP導入プロジェクトでは、環境は用途別に分けて構築し、段階を経て開発やカスタマイズなどの導入を進めていくというコンセプトがあります。このとき、開発環境、検証環境、そして本番環境という3種類の環境を構築するのですが、これを3 Landscapeと呼びます。
3 Landscapeの考えでは、まずは開発環境と呼ばれる環境で機能の開発や、カスタマイズ/Configurationを実施します。その後機能をテスト（単体テスト）し、問題が見つかった場合は修正を行い再度テストを行いますが、問題なければ検証環境という環境にも同様の開発、カスタマイズ/Configurationを移します。
その後、検証環境でもテストを行います。
なぜ開発環境でテストしたものをもう一度検証環境でもテストするのかというと、それは開発環境で実施したテストの内容は、開発あるいはカスタマイズ/Configurationを行った機能だけのテストであるため、一連の業務がきちんと実行できるかどうか、という点でもテストを実施する必要があるからです。
SAP上では複数の業務プロセスが同時に動きます。そのため、例えば購買管理のために導入した機能が、生産管理のために導入された機能とバッティングし、双方のプロセスがうまく進まなくなってしまう、というバグが発生する可能性があります。
そのため、こうした業務同士のつながりをテストする必要性があるのですが、日々の開発やカスタマイズの業務をしながら何か変更が加わったらそのたびに一連の業務を初めから終わりまで実施してみてテストをするのは非常に工数がかかります。
したがって、開発環境ではどんどん開発作業やカスタマイズの作業を進めるということにしておいて、テスト（単体テスト）が終わったものについては、そのまま一連の業務のつながりのテスト（結合テスト）や、一連の業務全体の整合性の確認テスト（統合テスト）を実施するのではなく、ある程度の期間は温めておいて、複数のチームが開発あるいはカスタマイズ/Configurationをひと段落させた後にまとめて検証環境でテストをする、という方式がとられます。
こうした方法をとるために、開発用と検証用に環境を分けておくのです。また同様に、検証用の環境でテストを行い、バグなどが修正された後で、本番環境、つまり実際に業務ユーザーが使用する環境へ開発やカスタマイズが移されます。
なお、SAPでは、開発したものやカスタマイズ/Configurationの内容を一つずつ、またはまとめて環境から環境へ移すことが出来るのですが、これを移送/Transportと表現します。
この移送については、何時何分に誰がどこからどの環境へ行ったのか、という点が情報として持たれているので、問題が見つかった場合にはこの移送の履歴を確認することで何が原因だったのかを探ることも出来ます。
復習：単体テスト、結合テスト、統合テストとは？
単体テスト、結合テスト、統合テストが何かわからない、という方向けの解説です。お分かりの方はスキップしてください。
単体テストは、開発した、またはカスタマイズした機能そのもの、つまり機能単体に絞ってテストを行うものです。
例えば、SAPの顧客マスター上に重要顧客であることを示す項目を設定したとしましょう。
単体でストでは、設定した通りに顧客マスター上に新たに項目が追加されているかどうか、を確認します。
結合テストは、機能単体を見るのではなく、業務が流れるかを見ます。業務同士のつながりがうまくいくかをチェックするというテストになるのですが、同じシステムの中でのつながりをテストするものを特に内部結合テスト、システム同士の間のつながりのテストを外部結合テストと言います。
例えば、SAPの顧客マスター上に重要顧客であることがわかるフラグが設定されていたとして、それが受注伝票や出荷伝票上にも引き継がれることが要件であった場合、SAPで実際に受注伝票や出荷伝票も作ってみて、重要顧客のフラグが引き継がれるかをテストするのは内部結合テストです。
また、出荷完了後にSAPと接続しているSalesforceなどで、重要顧客への販売がされたことがわかるようにダッシュボードが更新されることが要件であった場合は、こちらをテストするのは異なるシステム同士の結合をテストしているので外部結合テストに相当します。
最後に統合テストですが、これは部門や責任範囲を横断する一連の業務を、初めから終わりまで実行するというテストです。複数のチームが関係するため最も工数がかかるテストとなります。
例えば、Salesforceで引き合い登録を行い、商談情報が更新されてきたら受注し、その受注情報をSAPに伝達し、自動で受注伝票を作成する。このとき、重要顧客フラグを顧客マスターから取得した状態とし、以降の出荷伝票や請求伝票まで作成し、SAPからSalesforceへ重要顧客への販売実績を送り返す。
請求伝票作成後は、売掛金の計上を行い、ここでも重要顧客のフラグを用いて重要顧客からの支払いがあとどの程度存在するのか、というレポートが確認できるようにしておく。
そして、支払いが行われたら売掛金を消込、重要顧客からの支払い確認レポートも更新が入ることを確認する。
このような一連の部門横断の業務プロセス全体をテストします。
テストフェーズに入っているのであれば、こうした統合テストの手順書がTest Scriptとしてまとめられていることが多いので、それを読みながらSAPのオペレーションを行うと、SAPの機能や動き、そして業務の流れについての理解が非常に深まります。
ログインしたら、トランザクションコード：SE16Nを入力します。
トランザクションコードとは、SAPの機能を呼び出すための英数字で構成された短いコードのことを指します。
画面左上のボックスに、SE16Nと打ち込んでEnterを押しましょう。
ツリー構造で整理されているフォルダーをたどっていくことで機能を動かすことももちろんできますが、トランザクションコードを入力したほうが圧倒的に早いので是非こちらの方法を利用するようにしてください。
トランザクションコード：SE16Nを入力すると、テーブルを検索する機能を呼び出すことが出来ます。そうしたら、テーブル名という欄に先ほど確認したテーブル名を入力します。
後は、実行ボタンをクリックします。
こうすると、テーブル情報を画面に出力することが出来ます。
なお、調べたいテーブル名を入力した後に一度Enterキーを押すと、画面下の領域がテーブル名に応じて変化します。EKKOを入力すると、Purchase OrderのHeader情報が表示されるので、ここから特定の条件に合致するデータだけに絞り込みをかけていくことが出来ます。
今回は、とりあえずそのまま実行ボタンをクリックするか、F8を押してください。F8を押すと実行ボタンをクリックしたのと同じ結果になります。
こうして表示されたものが、過去に作成されたデータの一覧となります。
したがって、これらを参考にしてみて、実際に同じデータを作る、ということを試すことで、現在のシステムの状況を確かめることが出来るようになります。
ここでは、一番左上にあるPurchasing Document Numberを後で使うことになるので、メモ帳などにコピーしておきます。
トランザクションコードを見つける方法
ここまでで、参考にしたいトランザクションデータが見つかりました。
Purchase Orderの番号を覚えておき、これを実際にSAPの画面上で表示してみましょう。
それでは、またGoogle検索を使用して、表示するための方法を見つけます
「Purchaser Order Transaction Code SAP」と入力して検索してください。
皆さんが探したいものの後ろに、「Transaction Code SAP」と付けて検索を行いましょう。
TCode Searchというものがヒットしました。これをクリックしてみます。
クリックすると、このように、Transaction CodeとDescriptionがセットで表示されます。
ここでは何をしているのかというと、トランザクションデータを表示したり、作成したりするためのトランザクションコードを探しています。
Purchase Orderについては、Create、Change、Displayの3つが見つかりました。
まずは表示してみたいのでDisplayを使いますが、Createの画面からDisplayに切り替えることが出来るので、ME21Nを使用します。
ちなみに、Best PracticeのTest Scriptをよく読んでいる方であれば、そのTest Scriptの中で既にトランザクションコードが記載されているということに気づいたでしょう。
同様に、カスタマイズテスト結果、単体機能テスト結果、結合、統合テストのテストステップにもトランザクションコードが記載されています。
もちろん、Test Scriptやテストステップに記載のあるトランザクションコードを使用する、という方法でもいいのですが、何かあったときにはGoogle で検索することで簡単に見つけることが出来るという点も覚えておいてください。
それでは、使用するトランザクションコードがわかったので、ME21Nを入力します。
画面が切り替わりました。
現状、この画面は新規にPurchaser Orderを作成するための画面になっているので、表示してみたいPurchaser Orderの番号を入力してみたいと思います。
そこで、まずはCreateのモードをDisplayのモードに切り替えます。
Displayのボタンを押すと、参照したいPurchaser Orderの番号を入力するように求められるので、先ほど控えておいた番号を入力し、Enterを押します。
そうすると、画面が切り替わり、先ほどテーブル上で見つけた過去データを表示させることが出来ます。これで、実際に作られたデータを見ることが出来ます。
あとは、画面を操作してみて、どんな項目がどこにあるのか、という点を確認してみましょう。確認を通じて、段々とSAPではどんな風にデータを持つのか、という点を学んでいきましょう。
Transaction Dataを見るときはHeaderとItemを意識する
Transaction Dataを実際に確認してみて、どんな項目がどこにあるのか、といった点を勉強するときは、HeaderとItemを意識する様にしましょう。
Purchaser Orderの例では、以下に示す領域がHeaderとItemとなります。
Headerとはドキュメント、つまりTransaction Data全体についての情報を持っている欄で、Itemはそのドキュメントに含まれる個別の明細を意味します。
HeaderとItemは、それぞれタブを持っており、同じグループに所属する情報が同じタブの中にまとめられています。
Purchaser Orderの例を見てみると、Delivery/Invoice、Address、Org.Data等、個別明細ごとに決めるものではなく、Purchaser Order全体について決定されるべき事項がHeaderにまとめてあります。
支払い条件、請求先住所、Purchaser Orderを作成した組織、などは個別明細ごとにばらばらに決まるものではなく、Purchaser Order全体に対して決定されるべき内容であるからですね。
一方で、Material Data、Quantity/Weights等はItem にまとまっています。これはもちろん、何を注文するのか、という個別明細ごとに注文された品目の情報、数量や重量はバラバラに決まってくるからですね。
Purchaser Orderの場合は、Item の内容の抜粋がHeaderとItemのセクションの間にあるItem Overviewという欄にまとめられている点が特徴的です。
なぜHeaderとItemを意識する必要があるのかというと、SAPのTransaction DataはHeaderとItemで別々のテーブルを持っているからです。
調べて頂くとすぐにわかりますが、Purchaser Orderについては、EKKOがHeader用のテーブルで、EKPOがItem用のテーブルとなります。さらに、EKESというこれまた別のテーブルがあるのですが、このように同じPurchaser Order上の項目でも、システム内部を見てみると別のテーブルに存在するというケースが存在します。
開発作業などを行う際には、とある機能に必要になる項目がどこにあるのか、という点を明確にしていく必要があります。その時、Purchaser Order上にある項目、という理解でいるよりも、EKKOテーブル上項目、という理解でいるほうが作業を滞りなくかつ円滑に進める上では非常に有効になります。
テーブル名や項目の名称を丸暗記する必要はありませんが、Purchaser Orderの画面上でここに表示されている項目は、Headerテーブルにある、という程度の理解はしておくようにしましょう。
実際にデータを作ってみる方法
ここまでで、過去データを見つけて、そうした過去データを表示するためのトランザクションコードを見つけて、表示してみる、ということが出来るようになりました。
あとは、実際に自分の手で作ってみる、ということを通じて、業務オペレーションを体験してみましょう。
業務フローの最後のデータがあれば参考にする
ここで皆さんにおすすめの方法があります。
それは、まずは業務オペレーションの最後に作るトランザクションデータを確認し、そこから関連する前工程のデータを確認し、同じものを作ってみる、というものです。
なぜそんなことをするのかというと、理由は業務フローの最後で作られるデータを確認すると、そのデータを作るために使用された前工程のデータが全て確認出来るため、同じようにデータを作成すれば一連の業務オペレーションの流れを追体験できる可能性が高いからです。
もし、適当にテーブル上から見つけたPurchaser Orderを参考に自分自身でPurchaser Orderを作ってみた場合、参考にしているPurchaser Orderの後続のトランザクションデータが作られていなかったら、それ以上参考にできるものがありません。
したがって、一度最後のトランザクションデータの作成までが成功しているデータを見つけることが出来れば、それに関連する前工程のデータを全て確認することが出来るため、自分自身もこれから同じように手順を踏めば同様に一連の業務オペレーションを実行できる可能性が高いのです。
業務フローは、SAP Best Practice Explorerで見つけるか、またはプロジェクト内で作成しているものがあればそれを参考にして、業務の最後に作っているトランザクションデータが何なのかを確認してみてください。
それでは具体的に手順を踏んでみましょう。
先ほどまではPurchaser Orderの表示方法を確認していましたが、業務フローの最後に作られるトランザクションデータは、業務フローを確認した結果、Supplier Invoiceであるとわかったと思います。
それでは、まずはSupplier Invoiceから前工程のデータを見つけてみましょう。
方法は、テーブル上で見つける方法と、トランザクションコードを実行して見つける方法が2つあります。勉強の観点でいえば、両方やってみるといいのですが、手っ取り早く先に進めることが出来るのはテーブル上で見つける方法です。
- Supplier Invoiceのテーブル名を確認する
- テーブル名から、関連する前工程のデータを確認する
- Supplier Invoiceを表示するトランザクションコードを確認する
- Supplier Invoiceを表示して、関連する前工程のデータを確認する
それでは、Supplier Invoiceのテーブル名を確認する方法で今回はやっていきます。TCode SearchでSupplier invoiceについてテーブル名を検索すると、以下のような結果が得られます。
Descriptionを見てみると、1から6まではなんだか違うもののように思えますが、RSEGというテーブルが、Incoming Invoiceというものであることがわかります。
それでは、TCode Search上のRSEGをクリックし、RSEG上の項目について概要を確認しましょう。
TCode Searchでは、テーブル名称を検索することでそのテーブル上に存在する項目の一覧を確認することも出来ます。
確認してみると、RSEGテーブル上に項目EBELNというものがあり、それがPurchasing Doc.を意味していると分かりました。つまり、Supplier Invoiceのテーブル上に、Purchase Orderの番号が記録として残っているということを意味します。
したがって、SAPのGUI上でSE16Nを入力し、その後テーブル名としてRSEGを入力し実行すると、まずSupplier Invoiceの一覧が表示されます。
そして、EBELN：Purchasing Doc.の欄を見れば、Supplier Invoiceを作成することに成功したPurchaser Orderの番号がわかる、ということになります。
Supplier InvoiceからGoods Receipt、Inbound Delivery、そしてPurchaser Orderとたどるような複数のステップになるかと思いきや、Supplier Invoiceから一気にPurchase Orderが追跡出来ました。
後は、先ほどのセクションで共有した方法で見つけたPurchase Orderの番号を表示させ、内容を確認してみましょう。各項目が同じ内容になるように真似をしながらPurchase Orderを作成し、以降のInbound Delivery作成、Goods Receipt作成、Supplier Invoice作成も出来るはずです。
各Transaction Dataの作成の際には、Best Practice Explorerで見つけたTest Scriptを参考にしましょう。Inbound Delivery作成、Goods Receiptの作成についてはここでは解説しませんので、ぜひ皆さんの目でTest Scriptを参考にして頂き、オペレーションを理解するよう努めてください。
SAPの機能やオペレーションを理解する一番良い方法は、実際にやってみることです。それも、他人に教えてもらうのではなく、自分で調べてやるのでは理解度の進み具合が大きく異なりますので、「自分で調べて実際にやってみる」、ぜひこの方法を通じてSAPへの理解を深めてください。
SAP Communityを活用する
ここまでで、Best Practice Explorerをスタート地点としてSAP内で行われる業務オペレーションを確認し、実行する手順をご紹介しました。
業務オペレーションを実行しようとする場合はBest Practice Explorerは非常に強力なツールとなるのですが、業務オペレーションの実行とは関係のないもの、つまりマスターデータのメンテナンスや、カスタマイズ/Configurationの方法などについて知りたいときには向かないことがあります。
そこで次にご紹介する方法が、SAP Communityを活用するというものです。
SAP Communityとは、SAPの導入に関わるコンサルタントや事業会社の情報システム部門の方々が質問を投稿し、有志がそれに回答するというWEB上のサービスです。Yahoo知恵袋のSAP限定バージョンと思って頂いて構いません。
実際にはYahoo知恵袋に類似した質問とその回答、というもの以外にも、有志のメンバーが「これはまとめておくと便利な情報だ」と思った内容などを記事として投稿するプラットフォームにもなっています。
SAP Communityを有効活用することでBest Practice Explorerでは見つけることの出来なかった内容を把握する、または「そもそもこれってなんだっけ？」という質問への回答などにもたどり着くことが出来ます。
質問や記事を投稿する場合はユーザー登録が必要ですが、検索だけする場合は不要となります。ただし、全世界の人々が使うサービスですので、使用言語は英語である点は注意しましょう。
やはり、SAPを知るには英語は避けては通れません。
SAPに存在するMaster Dataを知る
それでは、SAP Communityを活用する際のイメージを持って頂きましょう。
ここまではTransaction Dataの例を取り扱いましたので、Master Dataについても見てみたい、と思ったとします。
しかしながら、Master Dataの場合は業務オペレーションを実行するなかで変更を加える、新規作成する、といったことはあまりないので、Test ScriptがBest Practice Explorerでは見つからないケースがあります。
そのため、単純にCreate、Change、Displayの3機能のTransaction codeをTCode Searchで検索し、実際にSAPの動きを確認することにします。
ただし、この検索して見つけるという手順に問題があります。既にSAPに存在するMaster Dataがどんなものなのか、その名称を知っている場合は検索することはもちろんできますが、それも知らない場合は検索することは出来ません。
そこで、まずはSAPのMaster Dataにどんなものがあるのかを調べるようにしましょう。
ここで使用することが出来るのが、SAP Communityです。
まずはSAP Communityに行きましょう。GoogleでSAP Communityと検索して頂いても構いません。
SAP Communityにたどり着いたら、検索ボックスで調べたい内容を入力し、Enterを押します。
ここでは、そもそもMaster Dataってどんなものがあるのかを知りたいとします。ただし、「Master Data」で検索してもあまりに言葉の意味が広すぎるので、「Master Data XXXX」
と調べる対象を絞ったほうが欲しい情報にたどり着ける可能性が高まります。
前回の例に引き続き、購買管理の業務で使用するマスターデータにはどんなものがあるのかを知りたいということにします。したがって、「Master Data XXXX」のXXXXの部分に購買管理に相当する英語を入力すれば、欲しい情報にたどり着けるかもしれません。
ここで一つ、注意事項があります。SAP Communityでは、SAPで使用されている言葉や単語を用いて検索をする必要があります。
当然ながら、SAP CommunityではSAPに関する質問がされていますので、世間一般の言葉や単語よりもSAPで使用されている言葉や単語で質問がされ、回答が行われ、記事の投稿なども行われます。
したがって、SAP Communityで過去の質問や記事を検索するときは、事前に調べたい内容がSAPではなんという言葉になっているのか、という点を調べるようにしましょう。
それでは購買管理に相当する言葉は何なのか、Googleで調べてみます。
「購買管理 SAP」で検索すると、結果は以下のようになります。
SAP Help Portalという、SAPが提供するヘルプへのリンクがいくつか見つかりました。個人が投稿しているブログが見つかることも多いのですが、SAPのことについて調べるときはSAP Help Portalなどの情報の出し元がしっかりしているところを選びましょう。
では、見つかった結果のうちの一つをクリックしてみます。
この説明を見ると、購買管理は在庫/購買管理(MM)モジュールと呼ばれているもので業務オペレーションがサポートされているのだな、ということがわかります。
SAP社が提供している公式な文書なので、わかりにくい日本語になっている点は仕方がないものと捉えましょう。
では、在庫/購買管理(MM)モジュールという言葉が日本語ではありますがSAPで使用されている言葉として見つかったので、これの英語を探します。
すこし裏技っぽくなりますが、このページのURLを確認します。
URLを見てみると、「ja-JP」という文字が含まれていることがわかります。実は、ここを変更することで表示言語を変更することが出来るのです。
前半の「ja」が表示言語のJapaneseの頭2文字を意味していて、後半の「JP」が国であるJapanの短縮表示を意味しています。
したがって、これを英語に変えてみたいので、「en-US」に変更します。そうすると、先ほど日本語で表示されていた内容が英語になりました。
このページを見てみると、在庫/購買管理(MM)モジュールというものが英語だとMaterials Management Moduleと呼ばれていることがわかります。
また、Materials ManagementはMMと略されるのだな、ということもわかります。
それでは、SAP Communityに戻りまして、「Master Data MM」と検索してみましょう。
SAP Communityから推奨される2つのリンクと、過去に行われた質問がヒットしました。
推奨された2つのリンクはさておき、ヒットした質問をクリックしてみます。
そうすると、質問とその回答が表示されます。
内容を見てみると、まさに欲しかった情報が得られました。
Material Management、つまり購買管理で使用されるマスターデータとそれを作成するためのTransaction Codeがセットで回答されています。
マスターデータの名前だけがわかった場合でも、TCode Searchで検索することでTransaction Codeが確認できますね。
あとは、これまでにご紹介してきた方法と同じです。勉強したいマスターデータについて過去データを確認したいときはまずはTCode Searchでマスターデータのテーブル名称を確認し、確認した結果をSE16Nで実際に見てみます。
そして、あとは実際にCreate、Change、Displayの機能を使ってマスターデータを作る、変更する、表示する、といったことを行って理解を深めていきます。
エラーが出た場合に原因を調べる
場合によっては、Best Practice Explorerで見つけたTest Script通りにオペレーションを実行してもTransaction Dataがうまく作れない、といったときもあるでしょう。そうしたときにもSAP Communityは活用できます。
うまくTransaction Dataが作れない、という場合はさらに2つの種類に分けることが出来ます。そもそもどうやったらいいのかわからないというケースと、エラーが発生してしまうというケースです。
そもそもどうやったらいいかわからない、というのはBest Practice Explorerで見つけたTest Script通りにやっているつもりなのだが後続のプロセスに進むための方法がわからない、というケースです。このときは、「調べたい業務 Procedure」で検索するとよいでしょう。
Test Script等で、実施したい業務の名称などを見つけ、それをSAP Communityで検索します。ただし、基本的にはTest Script通りにオペレーションを実行することで問題はないかと思われるので、このケースはまれでしょう。
どちらかというと、エラーが発生するケースでSAP Communityを活用するケースの方が多いと思われます。
エラーが発生するケースというのは、SAPの画面上でオペレーションを実行していった結果、画面の左下や中央にメッセージが表示される状況を指します。
こういったエラーに遭遇したときにもSAP Communityは利用できます。
エラーメッセージが表示されたら、そのエラーメッセージをダブルクリックするか、クエスチョンマーク（？マーク）をクリックしましょう。
そうすると、エラーメッセージの詳細を確認することが出来ます。
SAPでは、発生したエラーに対して固有のメッセージ番号が付与されています。
どちらの例にも、Message no.という記載があるのがお分かりになるでしょうか。
これをSAP Communityで検索することで、何が問題の原因なのか、対処するべきことは何なのか、といった点を見るけることが出来るでしょう。
SAP Communityはうまく使いこなすことが出来れば勉強の面でも、実際に導入を進めていく場面でも非常に強力なツールになりますので、ぜひ有効活用してください。
終わりに
いかがでしたでしょうか。SAPは結構とっつきにくく、会社によってはとりあえずCertificationをとれ！というスタンスである場合や、SAP社の提供する研修にとりあえず参加させようとする場合がありますが、私個人としてはそういった方法では特にSAPに初めて触れるような初心者の方の場合、SAPへの理解は深まらないと思っています。
むしろ、ある程度SAPを知っている状況でないとCertificateも研修コースへの参加も意味が無いと考えています。
本投稿では人に頼らずにSAPの勉強がある程度できるようになるまでの方法をご紹介しました。
持論にはなりますが、「自分で調べて、実際にやってみる」、これこそが一番理解が深まる方法だと思っていますので、ご興味がおありの方はこちらの投稿でご紹介した内容を実践頂けますと幸いです。
SAPは初心者の方にとってはとっつきにくいですが、知れば知るほど奥が深く、その基本設計思想の優秀さには驚くばかりです。とっつきにくさに面食らって嫌いにならず、本投稿の内容を用いてもう少し粘り強くSAPに向き合って頂ければ、その素晴らしい世界にきっと気付いて頂けると思っていますので、ぜひ、一緒に頑張っていきましょう。