SAP/IT

【SAP導入】初心者が知っておくべきこと、独学で1人前になる勉強方法

前置き:初心者に優しくないSAP導入プロジェクト

皆さん、こんにちわ。突然ですが、SAPって、とっつきにくいですよね。

色々な機能があるというのはわかりますが、そうした機能を活用するための項目が画面上に敷き詰められ、いったいどの項目をいじってどのボタンを押せばいいのか、ということを把握するだけでも大変です。

特に、SAP導入プロジェクトに関わることになったSAP未経験の方、初心者の方は何から学んでいけばいいのか、という点で迷われる方が多いのではないでしょうか。

こちらの投稿は、そうしたSAP未経験の方、SAP導入プロジェクト初心者の方向けの内容となっています。

なお、私はこれまでにコンサルタントとして複数のお客様のSAP導入プロジェクトに関わり、以下領域の業務設計、要件定義、システム設計、開発とテスト等を担当してきました。 現在も需要予測、S&OP関連のモジュール導入を担当している状況です。

  • 担当してきた業務領域
    • 購買管理
    • 販売管理
    • 在庫管理
    • 物流実行
    • 需要予測
    • S&OP
    • 管理会計
    • カスタマーサポート、保証

皆さんがご自身の意思でSAP導入をしたいと思われているかはわかりませんが、これからSAP導入をするという立場になった場合、熱心な方はまず事前知識としてSAP導入プロジェクトについて勉強しようと考えられると思います。

当然ながら私自身にもSAP未経験の時がありましたし、未経験の業務領域を担当することになったときは色々とイチから学んでいく必要があります。

しかし、多くの方が「いったい何を知っておけばいいのか?何からどうやって勉強していけばいいのか?」という点を疑問に思われるのではないでしょうか。

なぜ私がそう考えるのかというと、私自身がSAP導入プロジェクトに初めて関わることになったときに、自分自身がそう感じたからです。

例えばSAPに関する書籍等をAmazon等で探しても、SAPの製品そのものについての解説や、SAPという会社についての解説があるばかりで、SAP導入プロジェクトというものがどう進んでいくのか、SAP導入プロジェクトに巻き込まれた場合にどんな仕事をしていくことになるのか、そして何を学んでいけばいいのか、どうやって学んでいけばいいのか、という点を解説する書籍はほぼ見つからないためです。

あるとしても、英語で記述された1冊1万円近くする書籍がほとんどです。

それこそがSAP導入の経験が転職市場やフリーランスの求人募集において高い価値を発揮している要因でもあるのですが、とにかくSAP導入プロジェクトは初心者に優しくありません。

したがって、こちらの投稿ではSAP導入プロジェクトに関わることになった方、特にコンサルタントの方、または事業会社で情報システム部門に在籍されており、SAP導入プロジェクトにアサインされることになった方で、各種業務領域における担当者となられた方を対象に、まずはどういったことを理解しておくべきなのか、そしてどういったことを勉強していくとSAP導入プロジェクトの中で活躍するために必要な知識を手に入れられるのか、またその勉強方法について解説しています。

SAP導入プロジェクトでキャリアを形成していきたい、フリーランスとして独立したい、という方向けにもどうやったら一人前になれるのか、という部分では参考になる情報があるかと思います。 ご興味御座いましたら是非ご覧いただけますと幸いです。

想定読者

  • SAP導入プロジェクトに初めて関わることになったコンサルタントの方
  • SAP導入プロジェクトに初めて関わることになった事業会社の情報システム部門の方
  • SAP導入プロジェクトの進め方を知りたい方
  • キャリア形成としてSAP導入に必要な知識の身に着け方、勉強方法を知りたい方

期待できるメリット

  • SAP導入プロジェクトの進め方、流れ、タイムラインがわかる
  • SAP導入において知っておくべき基本事項がわかる
  • SAP導入において必要な知識を身に着けるための勉強方法がわかる

初心者が知っておくべきこととは

SAP導入プロジェクトの流れ

SAP導入プロジェクトにこれから関わります、という方はまず、SAP導入プロジェクトの流れを理解しましょう。

もちろん、企業によって、あるいはプロジェクトによってどのような進め方を取るか、という点は細かくは変わりますが、大まかには共通している点があります。

まずはこうした、大まかなプロジェクトの流れを理解するようにしましょう。

プロジェクトの流れがわかると、今、プロジェクト全体では何をしていて、何を成果物として作っていく必要があるのか、という点を理解することが出来ます。

そうすることによって、自分自身が担当している作業とは何なのか、考えなくてはいけない物事の範囲はどこからどこまでなのか、という点が明確になり、日々の作業スケジュールを立てることも容易になります。

逆に、今はまだ考えなくてよいこと、という点も把握できますので、無駄な作業を省いて業務に取り掛かることが出来ます。

したがって、まずはSAP導入のプロジェクトの流れを理解する様にしましょう。

SAPの基本要素:業務オペレーションとそれを構成する要素

次に、SAPの導入によって提供される業務プロセスがどういったオペレーションで実行されるのか、という点と、そうしたオペレーションを行う上でどういった要素が関係しているのか、という点を理解しましょう。

業務オペレーションを実行するということは、SAPに手作業で、あるいは自動化された形でデータを打ち込んでいくということになるのですが、どういったマスターデータ、トランザクションデータがあるのか、テーブル構造はどうなっているのか、カスタマイズはどのように実施されるのか、という点を大まかに理解しましょう。

もちろん、いきなりSAPが提供する機能や画面上に存在する項目の全てを理解しろとは言いません。ここでは、あくまで前提知識となるものを理解することの必要性を言っています。

ここで前提知識を得ることで、その後、実際の業務の中で何かしらの調査や検討を進めなくてはいけなくなったときに、どこをどういった視点で調べる必要が出てくるのか、という点が自分自身の中で明らかにできるようになり、あとは実際に調査をするだけ、という状態になります。

SAPの機能を調査する方法≒独学で1人前になる勉強方法

大まかにプロジェクトの流れ、そして前提知識を得たら、あとは必要に応じて個別に調査をすることが出来るようになりましょう。

もちろん、業務の中で必要性に駆られた状態でなくても自分自身の自己研鑽のためにSAPの機能を調査することは成長につながりますし、将来的に業務の中でも生かされ、またはキャリア形成の部分でも役に立ちます。

したがって、独学で勉強が出来るようになりましょう、と言い換えてもよいでしょう。

自分自身で調査するのではなく、SAPについて詳しい方にお聞きしたほうが早いこともあるでしょう。しかし、毎回周囲のメンバーに聞いていると、自分自身の成長につながりませんし、同じことを繰り返していると自分自身がプロジェクトに貢献していない状況になってしまいます。

少なくとも、何から調査すればいいのか、程度は周囲のメンバーに相談してもいいですが、実際に調査する作業自体は自分自身で完結できるようになるべきです。

これが出来ると、あとは加速度的にSAPの理解が進みますし、自分自身で対応できる業務の範囲が拡大していきます。 したがって、何か確認する必要がある事項が出た場合に自分自身でSAPの機能を調査する方法、言い換えれば独学でも1人前になれる勉強方法を身に着けるようにしましょう。

SAP導入プロジェクトの流れ

まずはSAP導入プロジェクトというものがどういった流れで進んでいくのか、という点を解説します。

プロジェクトに途中から入られた方は、今自分がいるのはどこなのか?という点を把握する様にしましょう。

一般的な流れ:構想策定、要件定義/設計、開発、テスト、移行、保守

以下にSAP導入プロジェクトがとる一般的な流れを図解します。

プロジェクトは複数のフェーズと呼ばれる作業の集まりで構成されます。

SAP導入プロジェクトが対象とする業務領域、あるいは導入対象のモジュール(SAPの機能をまとめた単位)によってプロジェクトの長さ、期間は変わりますが、一般的に基幹業務と呼ばれる領域の全てを対象にした場合、合計で14カ月ほどの期間が必要となります。

プロジェクトによっては日本語ではなく、英語で各フェーズのことを呼ぶケースも多いので、こうした言葉も覚えておくとよいでしょう。

また、SAP導入プロジェクトは、前のフェーズが終わらない限りは次のフェーズに移らない、というWaterfallアプローチを基本としています。

各フェーズにおいて実施する作業内容は、大まかに以下の通りとなります。

  • 構想策定/Planning
    • SAP導入プロジェクト全体の計画を作ります。SAPを導入する対象の業務領域、SAP製品の中で使用する機能モジュール、プロジェクトに関わるチームの体制や、各チームがいつ何を実施するのか、という点を明らかにしていきます。
  • 要件定義・設計/Design
    • SAPを導入する対象業務において、何が出来ることが必要なのか?という点を明らかにしていきます。「こういうことが出来るべき」という内容を要件と呼ぶため要件定義、または設計とも表現します。
    • さらに、要件あるいは設計に従って、システム的にはどういったことを実現しないといけないのか、という点を明らかにします。
  • 開発/Build
    • 前のフェーズで定義した設計にしたがって、SAPのカスタマイズやプログラムの開発を行います。カスタマイズしたもの、開発したものについては簡単な機能のテストも行います。
  • テスト/Test
    • カスタマイズ、開発した機能がきちんと業務全体を実行できるものかをテストします。開発フェーズでは機能そのものの簡単なテストをしていましたが、ここでは様々な業務について一連の流れをテストします。これが終わることできちんとしたバグのない状況に至ったと判定されます。
  • 移行/Migration
    • SAP導入をするということは、それまでに使用していたシステムから新しいSAP製品に乗り換えるということになるので、マスターデータやトランザクションデータを旧システムから移すことになります。これを移行と呼びます。
  • 保守/Hyper Care
    • 移行後、実際に業務が問題なく新しいシステムで実施できるかを継続的に監視し、何か問題があった場合にはすぐに対処できるように保守活動を行います。

こちらでは大まかにプロジェクトの流れを解説させて頂きました。

詳細に見ていくと、各フェーズにおいて行うべき作業、作成するべき資料や成果物などがあるのですが、そちらについてはまた別の機会に解説致します。

SAPの基本要素:業務オペレーションとそれを構成する要素

それでは次に、SAPの基本要素、1人前になっていくことを目指すためにまずどういった要素を知っていくことが必要なのか、という点をご説明します。

SAPの基本要素として知っておくべきものとは、第一に業務オペレーションです。

オペレーションとは、どういったことをSAP上で行うことで業務が進んでいくのか、という手順のことを指します。

これを理解していないことには始まらないと言っても過言ではないですが、同時にこれさえ理解していればあとはどうにでもなります。

そして、このオペレーションを支えるためのデータや、関連する設定といった要素も複数あります。これらを項目として見ていくと数多く存在するのですが、それらすべてを理解するのではなく、まずはまとまった要素として確認していきましょう。

SAPの基本要素は以下の4点です。これらを適切に活用することで業務オペレーションが実行されます。

  • マスターデータ
    • トランザクションデータによって参照されるデータ
      日々変更されるものではなく、ある一定期間において使いまわしが出来るデータ
  • トランザクションデータ
    • 日々の作業の記録をするためのデータ
      マスターデータの一部を活用して作成される
  • カスタマイズ/Configuration
    • 業務オペレーションの流れ、使用できる項目選択肢などを設定する
      設定と言い換えてもよい
  • 開発(WRICEF)オブジェクト
    • SAPに備わっているカスタマイズ機能では対処できない機能に対して個別に開発をしたもの
      性質に応じて5つのカテゴリーに分類される(カテゴリー:W, R, I, C, E, F)

業務オペレーションとトランザクションデータの関係

業務オペレーションとは、どういったことをSAPで行うことで業務が進んでいくのか、という手順であると説明しました。

この業務オペレーションですが、処理を進めていく過程で必ずトランザクションデータを生成します。

トランザクションデータとは、日々の業務の記録を行うものです。トランザクションデータが作成されると、それがまた別のトランザクションデータの作成のために使用される、という形で情報が引き継がれていきます。 以下に、購買管理の例を使って業務オペレーションとトランザクションデータの関係性を図示します。

PR、PO、IBD、GR、IVと表記されているものがそれぞれトランザクションデータを指しており、これらが関連する業務オペレーションの実行によって作成されている様子を示しています。

これらがいったい何なのか、という点はまだ理解していただく必要はありません。

まずは、業務オペレーションとトランザクションデータの関係について理解する様にしましょう。

マスターデータとトランザクションデータの関係

次に、マスターデータとトランザクションデータの関係についてです。業務オペレーションの実行によって、トランザクションデータが生成されると説明をしました。

トランザクションデータを生成する際には、データとして記録される内容を入力する必要があります。このとき、入力するデータ以外に参照するデータ、それがマスターデータです。

購買管理の例でいえば、最初に購買要求を作成するときは「何を買いたい」、「どこから買いたい(仕入先)」という情報が必要になるということは想像頂けるかと思います。

その時に、「買いたいものの重さ、大きさ」、「仕入先からの購入リードタイム、支払い条件」などを都度入力するのは非常に手間になります。

したがって、あらかじめそうした情報を記録しておき、あとは「買いたいもの(品目)」、「仕入先の情報」を入力するだけで関係する情報は全部自動で取得されるようにするという仕組みがあると非常に便利です。

これが、マスターデータです。 以下に、マスターデータとトランザクションデータの関係について図示します。

トランザクションデータを生成する際に、マスターデータを特定するキー情報、ここでは品目のコードや仕入先のコードを入力することで、それらのマスターに関係する情報を自動でトランザクションデータに取得させることが出来ます。

トランザクションデータの生成の際には、必須で参照することが必要なマスターデータもあれば、任意でOKなものも存在します。

任意参照のマスターデータは、あとのステップで結局参照することになるか、完全にあってもなくても良いという性質のものがあります。 これは、ご自身が担当した領域について個別に調査することとして、ここではマスターデータとトランザクションデータの関係について理解しましょう。

カスタマイズ/Configurationの例

カスタマイズ/Configurationについて解説します。

カスタマイズ/Configurationは、SAPが標準の機能として備えているもので、簡単な設定変更によって画面上の項目について選択できる候補を変更したり、あるいは業務の流れそのものを変更したり、必要な項目が入力されていなかった場合にアラートを上げる、といったことを可能にするものです。

カスタマイズ/Configurationにおいては複雑なプログラミング、コーディングといったものは不要で、いくつかの項目を適切に設定することが求められます。

ものによっては大量に項目を設定しなくてはいけなかったりもしますが、それでもプログラミングやコーディングの知識なしにSAPの機能を設定できるため、これをうまく使いこなすことがSAP導入プロジェクトの成功・失敗を分ける結果につながります。 以下に、カスタマイズ/Configurationの例を図解しています。

例としては特定の項目で使用できる選択肢を決定する、あるいは業務の流れを自動にするか主導にするか、といったものが設定出来るのですが、もはや分類分けが出来ないほどに多種多様な機能がSAPによって提供されています。

まず何かしらの機能が必要になった場合には、このカスタマイズをうまく行うことで対応が出来ないか、という調査をしていくことになります。

ここでは、カスタマイズ/Configurationをうまく使いこなすことがSAP導入プロジェクトにおいては重要だ、という程度に理解いただければと思います。

開発(WRICEF)オブジェクト

SAPが備えている標準機能で対応が出来ない機能が求められた場合に開発するものが、WRICEF(ライセフ)オブジェクトとも呼ばれる、開発オブジェクトです。

プロジェクトによってはアルファベットの順番を変えてFRICEW(フライス)と呼んでいるケースもあります。

開発オブジェクトを作っていくときには、プログラミング、コーディングが必要になってきますが、SAP導入プロジェクトを進める立場としては、必ずしもプログラミング、コーディングの理解が必要ではありません。

業務的には何を実施したくて、どんなデータをInputにして、何をOutputしたいのか、という点を理解することが出来れば、開発者に対して必要な機能設計について伝達することが出来ます。

そこでここでは、開発オブジェクトがどのように分類分けされるのか、そしてそれぞれがどういった機能を提供するのか、という点の解説をします。

この部分を理解することで、必要な機能を開発者に伝達するときにはどういったポイントを押さえておくとよいのかがわかるようになります。

WRICEFの意味

開発オブジェクトは、WRICEF(ライセフ)オブジェクトとも呼ぶと解説しました。 その理由は、開発内容を分類分けすると以下の6種類に分けることが出来、それぞれの頭文字をとったものがWRICEFとなるからです。

  • WRICEF
    • Workflow
    • Report
    • Interface
    • Conversion
    • Enhancement
    • Form

それぞれがどういったものなのか、確認していきましょう。

Workflow

Workflowは、業務オペレーションの流れの中で特定のタイミングにおいて、承認や確認解いたステップを追加するためのものです。

SAP標準の業務オペレーションを実施していくと、必要になる承認行為などがされなくなってしまう、というときにこのWorkflowを活用します。

以下に、Workflowのイメージを図示します。

Workflowを用いると、特定のトランザクションデータが生成されたときに、そのトランザクションデータの内容の確認や主任を行う必要がある人に向かって承認の依頼を通知することが出来ます。

そして、承認がされれば次のステップに進むことが出来ますし、承認がされなかった場合は前のステップに戻る、という制御をすることが出来ます。

もちろん、承認行為の結果は記録することも出来ます。

SAPの標準機能で提供されている機能もあるので、それらを確認の上、監査対応のためにどうしても必要、というときには開発を実施することとなります。

Report

Reportは、複数のマスターデータ、トランザクションデータの内容をまとめ、一つのレポートに仕上げるという開発になります。

SAP標準で提供されているレポート機能もあるのですが、その多くは一つのマスターデータの内容や、2-3個のトランザクションデータの内容をまとめたものとなっております。

そのため、それ以上のもっと多くの情報を一元化してみてみたい、という要望が上がったときにはReportを開発することとなります。

Interface

Interfaceは、SAPと他のシステムを連携させるための開発オブジェクトです。

SAPは基幹システムを担当し、需要予測や在庫管理、物流管理、予算管理などは他のシステムを使っている、というケースは多くあります。

そうしたときに、SAPと他システムの間で情報のやり取りをする必要があるとき、Interfaceを開発します。

以下に、Interfaceのイメージを図示します。

やり取りする情報は、SAPの視点ではマスターデータ、トランザクションデータに加え、カスタマイズ/Configurationも対象となります。

SAPから送り出すときと、SAPで受け取るときで処理は明確に異なるため、それぞれを別のプログラムとして開発することとなります。

なお、Interfaceが対象とする情報は、日々更新がされるようなデータで、継続的にSAPと他システムの間で連携が必要とされる情報となります。

グローバル企業などは子会社が独自のシステムを持っているケースがあり、それらとの連携をするためにInterfaceの開発が大量に発生してしまうことが多いのですが、大量に開発を行うことはプロジェクトのスケジュールを長引かせる要因にもなりますので、出来るのであれば大半の業務をSAPで行うようにすると、Interfaceの必要性は減っていきます。

Conversion

Conversionは、旧システムから新システムであるSAPへデータを移し替えるときに使用されます。

以下にイメージを図示します。

対象となるのは、マスターデータ、トランザクションデータとなります。

カスタマイズ/Configurationはここには登場しませんが、新システムであるSAPを動かすときには、それはカスタマイズ/Configurationは手作業で実施するからです。

なお、旧システムからの移すのではなく、Excelなどのファイルからデータを取り込んで移すという場合にもConversionは使用されます。

Interfaceでは、日常的に情報の連携をしなくてはいけない性質のデータを取り扱いましたが、Conversionは基本的には一回だけデータを移し替えればあとは使用しないものとなります。

しかしながら、移し替えなくてはいけないデータのボリュームが大量になっている場合はもちろんプログラムでデータを移し替える以外に選択肢はありませんので、頻度高く使うものではないのですが利用する開発オブジェクトとなります。

Enhancement

Enhancementは、SAP標準機能が提供していない項目を作る、または業務の自動化を進めるためにトランザクションデータ生成を自動化する、といったものです。

以下にイメージを図示します。

マスターデータ、トランザクションデータに存在していない項目を追加する、これはイメージしやすいですね。

なお、項目を追加することを項目の拡張、と表現し、こうして追加された項目は追加項目、または拡張項目と言われます。

あるいは、業務の自動化を進めたいので、特定のトランザクションデータを生成したときにボタンを押して処理を実行すると自動で後続のステップで必要なトランザクションデータを生成する、といったことも可能です。

トランザクションデータの中で見ても、とある項目を指定すれば、SAP標準機能では参照していないマスターデータから自動で情報を取得し、項目を埋める、といったことも可能です。

Enhancementは、無いと業務が全く実行できない、という性質のものが多くないため、開発オブジェクトの数を減らしたいというときには真っ先に減らすターゲットとなります。

Form

Formは、マスターデータやトランザクションデータの内容を使用して外部に出力できる形式の帳票を作成します。 以下にイメージを図示します。

例えば、企業は発注書や領収書などを作成しますよね。そうしたものを作る機能がFormです。

Formを開発するときは、どの情報を取って、どこに表示するかというレイアウトなどを設計していきます。

Formは商習慣的に、あるいは規制当局への提出の必要性などから必須なものが多いです。

SAPの機能を調査する方法≒独学で1人前になる勉強方法

それでは次に、SAPの機能を自分自身で調べる方法、独学で1人前になるための勉強方法を解説します。

ここまでの解説で、SAP導入プロジェクトがどのように進んでいくのか、そしてその中で議論の中心となる業務オペレーションを形作る基本要素について学んできました。

それでは、これらの基本要素をどうやったら効率よく学んでいくことが出来るのか、それも周りの人に聞くのではなく、自分自身で勉強していくことが出来るのか、具体的な方法を解説していきます。

まず、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の画面となっています。

この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の画面を見て処理を行うというステップであることを示しています。

各ボックスの左上に人型のマークがあるものは、人が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
  • Master Data, Organizational Data, and Other Data
  • Overview Table
  • Test Procedures

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という言葉に注目しながら業務フローを確認してきたことで、何をトランザクションデータまたはマスターデータとして作ることになるのか、という点も理解が及んでいると思います。

そういったデータを作るための方法を確認し、実際に試してみることを通じて、理解を深めていくことが出来ます。その方法は、後述します。

Testフェーズの場合

既にTest フェーズに突入しているのであれば、Best Practiceが提供しているTest Scriptに近いものをプロジェクト内で作成しているかもしれません。

そうした資料が既にあれば、そちらを探し出して、業務オペレーションを実行してみると理解が早いでしょう。

使用するデータはすでに整っており、カスタマイズなども住んでいる状況なので、問題なく処理を進めていくことが出来るはずです。

過去データを見つける方法

さて、具体的な話に入っていきます。

前提として、既に皆さんはSAPへのアクセスが出来るGUIをインストールしている状況とします。もし、GUIの設定がまだ済んでいないという方がいらっしゃいましたら、情報システム部門の方やプロジェクト内の関係者に確認をしてみてください。

GUIがインストールされていれば、SAPにログインし、SAPの機能をテストすることが出来ます。

まずは過去データを見つける方法です。

第一に、今から何を見たいのか、という点を決めましょう。

今回は、例として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の後続のトランザクションデータが作られていなかったら、それ以上参考にできるものがありません。

したがって、一度最後のトランザクションデータの作成までが成功しているデータを見つけることが出来れば、それに関連する前工程のデータを全て確認することが出来るため、自分自身もこれから同じように手順を踏めば同様に一連の業務オペレーションを実行できる可能性が高いのです。

それでは具体的に手順を踏んでみましょう。

先ほどまでは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/IT

© 2022 Soloblog - コンサル日記、体験談 Powered by AFFINGER5