トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS

グローバルトレード管理

Last-modified: 2020-01-09 (木) 13:26:00
Top/グローバルトレード管理

グローバルトレード管理(以下GTM)とは、機能のベースを標準の受発注(SD/MM)としながらも、その枠を超えて商いを管理・遂行するための機構である。

分野メニューは、WB20。



概要

この機能の生まれは、某ユーザ企業が自社のシステム化にあたり、「売りと買いの一貫した管理」、「それらに係る諸費用の管理」、「相互の紐付け」など商社業務で必要とされる機能が実装されていないことからSD/MMでは力不足」と判断したことに端を発し、開発を請け負ったSAPの手により目出度く誕生した・・・という経緯だそうだ。(また聞き)

確かに、取引に派生する伝票にとどまらない取引間の紐付け(紐付管理伝票フローの充実)やプラットフォームの一元化(トレードワークベンチ)など、GTMが素晴らしい機能であることに議論の余地は無い。

しかし、SAP標準の名誉のために補足すると、SD/MMがイケてないというわけではないと考える。

根拠として、「GTMを導入したものの、一部事業では冗長なだけであり、その組織向けにSD/MMを改めて導入した」というプロジェクトを筆者は経験しており、単に顧客ニーズと標準コンセプトがアンマッチだったということなのだろう。

そもそものニーズとして、利益とは期間損益を指す(それを重んじる)商社以外の文化と、利益とは付帯する費用コミコミの契約別損益を指す商社文化という違いがわかりやすいだろうか。

導入コンサルタントにとってのハードル

上記の「枠を超えて」という通り、習熟にはSDMMは無論のことSAPの機能全般について一定程度の見識があることが前提となる。

理由は、諸掛収益性シミュレーションをはじめとした独自機能もあるものの、トレードワークベンチを利用して代表的なSDMMをはじめとした機能をコントロールしているという作りがベースであり、それは即ちコンフィグだけでなく拡張も含めてSAPのコンセプトそのものや機能を自分のものにしてる必要があり、そうでなければプロセスの辻褄が合わなかったり、変化に弱かったりとロクなことにならず、そもそもトラブルシュートにあたっては仕組みを理解できていなければ手も足もでないため、それなりの見識を要すると考える。

但し、GTMのナレッジを持つ技術者はそう多くはないため、多くの場合は自ら習得する必要がある。 筆者の経験では、下記のスキルセットがあれば習得は然程難しくないと考える。

  • 必須
    • SD/MMに理解があること そもそも売買一貫した機能であるため、プロセスのデザインには片方でなく双方が必須と考える。
    • アドオンもそれなりに触ることができること GTMは、完全な機能を提供しない代わりに様々な拡張手段が用意されている。 「○○だからできません」でなく「○○だったらできます」というスタンスでソリューションを提供していくには、もはや必修と呼んでいいかと思う。 開発も組み合わせながら、追加要件を如何に小さな負荷で済ませるか、如何に少ない工数で開発メリットを見い出せるソリューションを作れるか。
  • できれば
    • 財務会計に理解があること 計上基準、適用する換算レートやその日付、仕訳についてなど、話題は尽きない。 更に言えば後続プロセスを勘案できること。オールドタイプのロジコンサルには、会計をケアしない人が多くいるが、そういった人間には正直触って欲しくない。
    • CO-PAに理解があること 条件タイプからの転送や特性のマッピング元などの擦り合わせが代表的。 そもそも、Outputたる分析系に疎いようでは、Inputたる計画系および実行系のクオリティなど知れたもの。
  • 無いよりはあった方がいい
    • 利益センタ会計に理解があること 品目マスタプラントを組み合わせどのように提案させるか、統制勘定利益センタなど後続伝票の出来方は正しいか・・・ 会計ネタだからシラネ、ではなく少しでもケアできれば。
    • 権限に理解があること TCの承認をはじめMIGOでの契約に基づかない荷動きなど、プロセスの定義とソリューションの組み立て双方で、権限の掛け方と担保の仕方は勘案すべきかと思う。

機能の制約と成長過程

正直、2010年6月現在をもってしてもGTMには不具合や不具合と目されることが多い。 これには原因は二つある。

ベンダが何でもアドオンで実現してしまうこと

本来的におかしいことであっても、現状コンフィグで出来ない = じゃあアドオンだ!・・・という流れがなんと多いことかと思う。

現状コンフィグで出来ない = 知らないだけではないのか?アドオンするにしても大中小や松竹梅はあるはずではないか? であるし、そもそも何故、標準で実現できないのか?という観点を持つことが肝要と思う。

そもそもコンセプトに沿わないのであれば即アドオンでなくBPRから入るべきだし、コンセプトに沿っているのに機能が無かったりコンセプトに沿わない動作をするのであれば、OSSに問い合わせ、SAP Noteの発行を依頼すべきだ。

確かに期間という制約の元で不本意な応急処置をせざるを得ない場合もあるが、こういった思考と実践を繰り返さなければ、標準システム自体が成長しないことになってしまう。

ちなみに、実際にあったコンセプトにあわない標準の動作は下記のものが挙げられる。

  • 諸掛経由だと公式伝票採番が動作しない 直接WLF1から仕入先請求伝票を起票すると採番されるのに、動かなかった。ゴネられたがSAP Noteは発行してもらった。
  • トレード契約を参照登録すると項目が欠落する 品目グループ品目階層原価センタなどがあった。ゴネられたがSAP Noteは発行してもらった。
  • 諸掛CO-PAへの転送に不具合 確定諸掛のプラマイ符号が逆だったり原価要素に基づいた値項目に転送されなかったり、PJ担当者が白痴だったこともあって本番前に阿鼻叫喚のトラブルシュートをする羽目になったことがある。 さんざんゴネられた挙句、作られたSAP Noteが二つとも欠陥まみれだったり、OSSがそうであることは知っていたが、いつからSAP社は素人や嘘つきの集まりになったんだ?というザマで、結局カスタマExitで逃げる羽目になった。 但し、名誉の為に補足するとドイツのMiyakeさんは神。

こなれていないこと

これは単にSDMM程の導入事例が無いことに起因する。

残念ながら成長過程と言うほかないが、一つ目のベンダが何でもアドオンで実現してしまうことを是正していかなければ、改善しないままとなってしまう。

個人的に、例えば外注加工請求計画などの機能不足*1はあるものの、不具合さえ潰すことができればGTMは素晴らしい機能だと考えており、ぜひSAPの導入プロジェクトに関わる人間総員で「こなれさせて」いきたいものと思う。

これはGTMに限らないが、SAPというシステムはOSSという窓口が存在する以上、積極的にバグfixに働きかけたり問い合わせをしConsulting Noteを発行してもらったり、業界全体でシステムを育てていくという意識でやっていきたいものである。 SAP社の中の人には、余計なお世話だ!と言われてしまうかもしれないが。

構成

シナリオから見るグローバルトレード管理

関連

グローバルトレード管理/関連テーブル グローバルトレード管理/トランザクションコード グローバルトレード管理/分野メニュー



【スポンサードリンク】
  




コメントはありません。 Comments/グローバルトレード管理

お名前:

*1 これはスコープアウトされたのだろうから、仕方がないが