SAPマスター管理にまつわる理解と苦労

真下：以前、沖さんにインタビューさせていただいたときに、SAPの肝はマスター管理だと教えていただきましたが、なぜマスター管理が肝となるのでしょうか。

岡田：データが正確に最新の状態になっていないと、それを受け取るシステム側も正しく動かないため、マスター管理が肝となります。

駒形：マスターが肝というのはSAPだからという意味ではなく、何事においても肝ということでしょうか？

石川：どんなシステムでもマスターの管理は重要ですが、SAPはその中でも特にマスターの役割が重要となります。

駒形：SAPではどのような点が肝となるのでしょうか。

石川： SAPは基本的にパラメーター設定が重要な役割を果たしています。マスターデータの内容により、プロセスや処理の振る舞いが決定されます。したがって、マスターデータに設定された内容が初期値として提案され、それにより処理プロセスが変化します。逆に言えば、マスターデータの管理が適切であれば、マスターデータを変更するだけで処理プロセスを変えることが可能です。

駒形：パラメーター設定は、マスターに対して行うのでしょうか。

石川：SAPは大部分で伝票やマスターで定義された内容に従ってSAP内の処理プロセスが決定します。そのためマスターでそれぞれの処理プロセスを意識した登録が必要となるため、マスターの理解がとても重要となります。

真下：簡単な例で教えていただけないでしょうか。

石川：細かな例ですが、品目マスターには明細カテゴリーという項目が用意されています。
例えば、コードが100番であれば仕入先直送、200番であれば在庫販売というような値を設定することができます。品目マスターで特定の製品を選択した際、その商品マスターのコードが100番であれば仕入先に発注してそのまま直送する処理プロセスとなり、200番であれば在庫から販売するという処理プロセスとすることができます。このようにマスター管理を適切に行っておくと、品目を受注した際に、マスターの登録内容によって処理プロセスが決まります。その結果、マスターによって業務フローと処理内容が変わるというわけです。

沖：SAPの伝票はマスターデータを参照して作成されます。初めに受注伝票が生成されます。その後、仕入先への発注を行うための購買伝票が作成され、請求伝票となり、会計に計上されます。これらの一連のプロセスは、一つのパッケージとして伝票が全て連携しており、マスターが処理の振る舞いを決定します。これがSAPにおいてマスター管理が肝と言われるゆえんです。

岡田：AMIS（アシストの販売管理システム）はフルスクラッチなので、業務要件に対してプログラムを開発して対応していましたが、SAPは、パラメーター設定をしながら業務要件を満たしていくアプローチとなります。これにより、業務の標準化・整流化を実現できるはずだと考えています。

現在、直面している課題はアシストの業務に対して、どのようにパラメーターを設定して業務を標準化・整流化するかという点です。業務をパッケージの機能に合わせるのはこれが主な目的です。
パッケージの機能の範囲内で業務を構築することが可能であれば、ビジネスモデルや業務が変化した際にも、業務設計をパッケージの機能の中で行うという文化が生まれます。
そのため、プロジェクトとしてはカスタマイズを極力避けたいと考えています。メンテナンスコストも一因ですが、それ以上に、様々な技術革新が進行する中で、企業としても働き方やビジネスモデルを変革しなければならないという状況があり、そのスピード感は急速に進んでいます。

これに対応するためにも、機能を開発・維持メンテナンスすることに時間を割く余裕はありません。これが最も大きな根底にある考え方です。

真下：なるほど。よく理解できました。

真下：SAPの場合、マスターは何種類ぐらいあるのでしょうか。

岡田： SAPではお客様（得意先）とメーカー（仕入先）を管理するマスターとして、BPマスターが存在します。その他に価格や先ほど例に挙げた品目など、数種類のマスターが存在します。

石川：SAPのBPマスターでは大きく得意先と仕入先を管理しています。物品をアシストが購入する際の仕入先や、紹介販売などで取次だけ行うような製品を取り扱う企業も仕入先になります。

岡田：お客様のシステム構築支援時の協力ベンダーも仕入先になりますね。

駒形：BPマスターとして得意先と仕入先が一緒になっているのは、SAPならではなのでしょうか。

岡田：他のERPパッケージがどう管理しているかまでは把握しきれていないですね。

駒形：構築する上で、SAPのようなマスターの持ち方をしていることで良かった点はありますか？

沖：取引先コードが1本になるため、そういう意味では会社を一元的に管理できます。同一コードで、ここは得意先でもあり、仕入先でもあるというような形になります。会社名や住所などを1ヵ所で管理できるので、メンテナンスを考えると、とてもやりやすいです。

石川：例えば、A社はアシストにとってお得意様で製品をたくさん買っていただいていますが、アシストもA社の製品を相当量発注しています。そうするとA社で見た時に、入ってくるものと出ていくものを一本化できるということになります。

真下：なるほど。それが同一コートで得意先と仕入先と言われているところですね。これはすごいことなのでしょうか。

沖：そのお客様をどう分析するかによります。このお客様に対して、アシストはどのような立場にいるの か。アシストの製品を買ってもらっているだけなのか、アシストから支払っていることもあるのか。その金額がどのようになっているかを分析することができます。お客様を分析するという意味では、お客様に対する入と出の両方が分析できることは良いことだと思います。

駒形：それはSAPならではなのでしょうか。

沖：SAPならではかどうかわからないですが、マスターが一本化されていることでやりやすくなることですね。

岡田：ERPは、会社のお金の入と出を見える化する目的もあり、その後の分析につなげられることはとても重要なことだと思います。

沖：SAPだからではなく、販売管理と会計が一緒になるということはそういうことですね。

駒形：アシストがBPマスターを設定する上で何か特殊なことはありましたか。

石川：いくつかの問題に直面しました。得意先は現在、扇子（Salesforeによる営業支援システム）に登録されており、法人データは正確に入力されています。しかし、仕入先には、お花屋さんや個人商店のような、uSonar（ユーソナー社が提供する法人企業データベース）に登録されていない法人や個人事業主も含まれており、それらをどのようにコード管理するかについての悩みがありました。アシストが利用しているuSonarは、海外の法人についてはコード管理していないため、海外の仕入先の存在も問題を難しくしています。また、先程のとおり、得意先が仕入先である場合もあります。仕入先のデータを入力するという作業は、支払いを伴うため、会計上の項目などを入力する必要があり大変でした。現在、楽楽精算（経費精算サービス）を使用していますが、楽楽精算に口座情報が記載されており、楽楽精算が口座マスターとなっています。そのため、口座の一覧はありますが、仕入先という観点での管理をあまり行っておらず、データ移行時に仕入先マスターを作成するのには苦労しました。

駒形：uSonarとBPマスターは常に連携されているのでしょうか。

石川：自動連携まではしていません。今は仕入先として新しく登録するときにLBC（uSonarで管理されている企業情報）を探してきて、見つかったらそのLBCをBPマスターにセットするようにしています。これから販売管理が動き出したら、日々連携が必要だと考えています。

駒形：BPマスターとつながりがあるような、外部のシステムはuSonarだけですか。

石川：原則、uSonarとSAPを直接つなぐのではなく、扇子からBPマスターを渡す予定です。得意先に該当するところは全部扇子経由で入ってきます。仕入先しかないデータは、手動入力で対応できそうだと想定しています。

真下：AMIS時代のマスターはどのような仕組みだったのでしょうか。また、当時、どのような課題がありましたか。苦労話があれば、ぜひ教えてください。

岡田：AMISで保持しているマスターは、スクラッチで管理してきたため、自由度が高く、長年の運用で様々な項目が管理されています。運用を開始して20年以上経過していることもあり、項目名と運用の乖離が発生したり、マスターが色々な意味合いをもつようになり、維持管理が大変になってきた、という課題があります。

石川：AMISにもマスターは存在しますが、マスターがなくてもデータ処理が可能です。見積もりを作成する際に、マスターに情報が存在しなければ手動で入力できますし、特別な製品がある場合、適当な項目を選択した後に、名前を変更して使用することもできます。しかし、このようにして作成されたデータは、商品マスターに存在しない売上情報となります。商品マスターに登録されていないということは、製品の属性情報などがわからないことになるため、例えば、実態はSaaS系のサービスであるにも関わらず、それがどういうものかわからず不明になるという問題が発生していました。このように、マスターは存在しますが、後でデータを取りたいときや、業務を運用したいときに、適切に機能していない状態でした。

沖：もう1つは受注データがないことですね。契約データはありますが、あくまで次年度継続サポート契約が発生するものに限定されるため、サポート契約がない一過性の売上げは、データとして管理されていないことになります。一般的な受注に該当するデータに近いものはあるのですがね。

真下：AMISではライセンス製品であれば後追いができますが、支援サービス系は受注してもAMIS上には情報が存在せず、契約データをさかのぼって探さなくてはならなかったので、後追いに苦労しました。

沖：元々ソフトウェアライセンスの契約システムとして作っているので、仕方がないところはありますね。AMIS上には次年度の継続契約が発生しないデータが残らないようになっていました。

真下：継続メンテナンスやサブスクリプション契約にならない契約は、データが残らないということですね。

沖：基本的には残りません。誤解がないように正確な言い方をするとデータ管理できるレベルでは残らないということになります。

真下：今後は支援サービスも後追いができるようになるということですね。

沖：受注データとして明確に管理されるようになります。そのため、品目に全部登録してくださいとお願いすることになります。

真下：今後はマスターに登録がないと受注ができないということでしょうか。

岡田：そうしていかなければならないと考えています。

真下：スポットで仕入れた製品もマスターに登録しなければならないとなると、マスターのメンテナンスが大変そうですね。

駒形：今まで支援の形態やシーンによって、様々な入力の仕方をしていましたが、全部マスターに登録するとなるとどうなるのでしょうか。品目にすごく細かく色々な種類を作るのでしょうか。それとも、今まで別々に分けていたとしても、支援としての1つの塊として、品目に載せるようにするのでしょうか。

沖：そこは、まだ技術部門と具体的な話ができていないのですが、おそらくカテゴリーで分けることになると考えています。大きくインストール系、などいくつかのパターンに分けて、名称の違いはそこで吸収することになるのではないかと想定しています。情報の持ち方はこれから考えていく予定です。

真下：アシストの取り扱い製品には保守料が毎年上がることにより金額が変わる製品があります。これは、毎年、新しいマスターを作らなければならないのでしょうか。

岡田：現在、詳細を詰めているところです。新しい品目を準備するか、価格情報としてマスター管理するか、ベンダーと詰めているところです。

石川：AMISはシステムとしてよくできており、業務を優先し、業務効率化をもとに、多くの機能拡張を実施してきました。その結果、マスターの見直しを行うことが困難になり、現在では手が入れられない状態になっています。例えば、商品マスターでは、製品の型番を1つの商品コードとして扱い、その下に使用権の価格や保守の価格が含まれており、製品＋価格で1つの商品コードとなっています。そのため、特別な仕入価格の情報があるお客様に対しては、別のコードとして登録する必要があります。しかし、本来は品目と価格の情報は別々に扱った方が良いケースもあります。長く運用してきたこともあり、コアな部分に手を入れるのは非常に難しい作業となります。

岡田：AMISは長年事業を行ってきている中、ビジネスの変革が発生するタイミングで、その時における業務要件を整理してスクラッチで拡張してきたため、マスターの維持メンテナンス作業が困難になってきたところがあります。これはパッケージではなく、スクラッチ開発ということでシステムが業務に合わせていくことができたからという側面があります。

真下：痒いところに全部手が届くシステム。ザ・日本企業ということですね。

岡田：はい。とてもよくできたシステムですが、今後を見据えたときにビジネス環境、業務を担当される方、システム担当も変わっていくことを考えると、このタイミングでの見直しが必要だと考えています。

真下：アシストでは何かマスターを追加しているのでしょうか。

岡田：システムで管理するマスターという観点では特に追加したものは無く、標準のマスターを使って構築をする予定です。お客様やメーカーの支払いサイクルなどは、標準で管理項目があります。アシスト独自で保持すべき項目についての扱いをどうしていくかは検討していく必要があります。この情報は、標準化されていないものがあるため、用語の統一を含め一元管理をしていくことになります。またアシストの場合はソフトウェアを販売するビジネスモデルのため、毎年の保守の更新など、前年の受注データをもとに翌年の受注データ（継続予定データ）を作る処理が必要となります。この継続予定データをどう作るか、それに必要なマスターをどう管理していくかベンダーとも議論をしています。

真下：どのような議論をするのでしょうか？

岡田：IPS社（今回のプロジェクトを担当）はSAP、さらには商社の構築経験が豊富なベンダーであるため、議論は基本的にSAPをベースに行われます。その議論から出てきた選択肢の中で、アシストとして処理を外出しすることが最適なのか、それともSAP内で処理を行うことが最適なのか、システムに詳しい事務局メンバーと内部で議論しています。その結果を他のメンバーと共有し、会社全体としての方向性を決定していくのですが、この一つ一つの選択を慎重に進めている状況です。

石川：継続保守契約データとは、基本的に前年に受注し、現在もライセンスとして保有され、保守契約が存在するデータのことを指します。これらのデータに対して、継続的に適切な情報の適用を行うことになります。

真下：それは一般的なフローとして、AMISの話とこれからの話に当てはめるとどうなるのでしょうか？

石川：AMISでは、受注伝票ではなく、契約データから次年度の契約データを作成しています。SAPでも同様に、次年度の受注予定データを作成する必要があります。SAPでは受注伝票が提供され、それが案件として次年度の保守を継続する見込みの案件に流れます。現在の扇子は新規案件のみ案件管理をしていますが、継続案件の管理も計画しています。SAPの受注伝票の情報をもとに、次年度の継続見込み情報を案件として作成することを想定しています。受注伝票から、次年度の案件データを作成する際には、保守料値上げなどを考慮に入れ、今年のお客様への提示額がどのようになるかを考え、それをどのように作成するかを現在IPS社と詰めています。

真下：受注したときに、来年のデータを作って渡すのでしょうか。

沖：受注時かどうかはこれから検討しますが、どこかのタイミングで契約更新されて渡していく予定です。

石川：SAPの受注伝票から仮の受注伝票として1回仮置きしてそこから扇子の案件として持っていきます。この仮受注伝票は、扇子連携が完了したら不要な伝票になります。こうする理由は、SAPの中に正しいマスターの情報が入っているため、SAP側で作った方が綺麗な情報であるという前提で実行しようとしているからです。ただ、本当にうまくいくかはわかりません。

駒形：現状からSAPに変えていく中で、マスターに手を加えるなどされていますが、一番苦労したのはどのようなところでしょうか。

石川：まだやっていないので過去形ではありませんが、品目マスターの整備に苦労しそうです。AMISの商品マスターをSAPの品目マスターに変換する過程で、データを一度洗い替えする必要があります。このとき、これまで商品マスターとして1レコードで入っていたものを品目と価格に分割する作業が必要となります。特定のお客様向け価格の管理をどうするかなども含めて、商品マスターをSAPに合わせて再構築する作業が必要になりますが、正直なところこれはやりたくない作業です。

駒形：これからなのですね。

石川：現在進行中の作業の中で、最も難易度が高いのは品目と価格の分割作業です。さらに、販売と会計が連携していることから、BPマスターを含むSAP内での会計処理に必要な項目値の扱い方も検討する必要があります。AMISの時代は品目マスターはメーカー担当者が販売と仕入れの観点で入力すれば良かったのですが、新しいマスターでは、品目を入力する際に、メーカー担当者が入力する情報と会計担当者が入力する情報の2つが必要になります。これまで、品目がどの勘定科目で処理されるか？という会計処理のことは意識せずに作成できていたのですが、今後は品目マスターを作成する際には、メーカー担当者だけでなく会計担当者とも確認しながら進める必要があります。これは品目だけでなく、BPマスターでも同じです。

真下：具体的にメーカー担当に確認するのは仕入金額のことなのでしょうか。

石川：メーカー担当が管理している情報は製品IDや定価金額、仕入金額、外貨情報です。会計担当の人は、この品目だったらどの勘定科目を設定するのかなど会計の中で決めていく必要なものが出てきます。

真下：なるほど。先日カットオーバーした会計側にはこのようなマスターはないのでしょうか。

石川：会計だけでしたら品目はないです。販売管理でつながって初めてこの品目が会計伝票で使われることになります。逆に言うとその品目がない状態でも動くものとしてリリースしました。

真下：会計には品目が不要ということですか。

石川：存在はするが今は使っていない、という状態です。債権債務をリリースしていないので使っていません。

岡田：元々、AMISからはCSVを出力し、それを経理側がSMILE（旧会計パッケージ）に投入できるように処理していました。これは会計処理に関する業務フローでした。このSMILEの部分をSAPに置き換える形になります。ただし、現時点では受注から請求に至る上流部分の処理がまだ完成していないため、この業務はあえて動かさずにリリースしました。

真下：今後はそれらのフローについても実装することになるのですね。

岡田：元々AMISとSMILEがシステムとして自動連携されておらず、経理が手動で頑張っていた状態なので、そこの部分をそのままSAPで表現したというのが、イメージとしては近いです。

真下：一旦カットオーバーはするけれどまだ連携されてない状態ということでしょうか。

岡田：そうです。ステージ1.0は、受注から会計までの連鎖がスコープとなります。受注から会計をつなげるためには、どうマスターを管理していくべきなのかもそうですし、どのように、社内業務を再構築していく必要があるのかっていうところを、今、喧々諤々と社内とベンダーとの間で議論しています。

真下：とても大変なプロジェクトですね。ありがとうございます。