SAP Knowledge Wiki
グローバルトレード管理
の編集
Top
/
グローバルトレード管理
-- 雛形とするページ --
(no template pages)
グローバルトレード管理(以下GTM)とは、機能のベースを標準の受発注([[SD>販売管理]]/[[MM>在庫・購買管理]])としながらも、その枠を超えて商いを管理・遂行するための機構である。 [[分野メニュー>SAPのオブジェクト/分野メニュー]]は、WB20。 ---- #contents ---- * 概要 [#jc92ac28] この機能の生まれは、某ユーザ企業が自社のシステム化にあたり、「売りと買いの一貫した管理」、「それらに係る諸費用の管理」、「相互の紐付け」など商社業務で必要とされる機能が実装されていないことから''「[[SD>販売管理]]/[[MM>在庫・購買管理]]では力不足」''と判断したことに端を発し、開発を請け負ったSAPの手により目出度く誕生した・・・という経緯だそうだ。(また聞き) 確かに、取引に派生する伝票にとどまらない取引間の紐付け([[紐付管理>グローバルトレード管理/紐付管理]]、[[伝票フロー>SAPの共通用語/伝票フロー]]の充実)やプラットフォームの一元化([[トレードワークベンチ>グローバルトレード管理/トレードワークベンチ]])など、GTMが素晴らしい機能であることに議論の余地は無い。 しかし、SAP標準の名誉のために補足すると、[[SD>販売管理]]/[[MM>在庫・購買管理]]がイケてないというわけではないと考える。 根拠として、「GTMを導入したものの、一部事業では冗長なだけであり、その組織向けに[[SD>販売管理]]/[[MM>在庫・購買管理]]を改めて導入した」というプロジェクトを筆者は経験しており、単に顧客ニーズと標準コンセプトがアンマッチだったということなのだろう。 そもそものニーズとして、利益とは期間損益を指す(それを重んじる)商社以外の文化と、利益とは付帯する費用コミコミの契約別損益を指す商社文化という違いがわかりやすいだろうか。 ** 導入コンサルタントにとってのハードル [#e65cf4c4] 上記の「枠を超えて」という通り、習熟には[[SD>販売管理]]と[[MM>在庫・購買管理]]は無論のこと''SAPの機能全般について一定程度の見識がある''ことが前提となる。 理由は、[[諸掛>グローバルトレード管理/諸掛管理]]や[[収益性シミュレーション>グローバルトレード管理/収益性シミュレーション]]をはじめとした独自機能もあるものの、[[トレードワークベンチ>グローバルトレード管理/トレードワークベンチ]]を利用して''代表的な[[SD>販売管理]]や[[MM>在庫・購買管理]]をはじめとした機能をコントロールしている''という作りがベースであり、それは即ちコンフィグだけでなく[[拡張>SAPの拡張手段]]も含めてSAPのコンセプトそのものや機能を自分のものにしてる必要があり、そうでなければプロセスの辻褄が合わなかったり、変化に弱かったりとロクなことにならず、そもそもトラブルシュートにあたっては仕組みを理解できていなければ手も足もでないため、それなりの見識を要すると考える。 但し、GTMのナレッジを持つ技術者はそう多くはないため、多くの場合は自ら習得する必要がある。 筆者の経験では、下記のスキルセットがあれば習得は然程難しくないと考える。 -必須 --[[SD>販売管理]]/[[MM>在庫・購買管理]]に理解があること そもそも売買一貫した機能であるため、プロセスのデザインには片方でなく双方が必須と考える。 --[[アドオン]]もそれなりに触ることができること GTMは、完全な機能を提供しない代わりに様々な[[拡張手段>SAPの拡張手段]]が用意されている。 「○○だからできません」でなく「○○だったらできます」というスタンスでソリューションを提供していくには、もはや必修と呼んでいいかと思う。 開発も組み合わせながら、追加要件を如何に小さな負荷で済ませるか、如何に少ない工数で開発メリットを見い出せるソリューションを作れるか。 -できれば --[[財務会計]]に理解があること [[計上基準>財務会計/計上基準]]、適用する[[換算レート>SAPの共通用語/換算レート]]やその日付、仕訳についてなど、話題は尽きない。 更に言えば''後続プロセスを勘案できること''。オールドタイプのロジコンサルには、会計をケアしない人が多くいるが、そういった人間には正直触って欲しくない。 --[[CO-PA>管理会計/収益性分析]]に理解があること [[条件タイプ>価格設定/価格条件タイプ]]からの転送や[[特性>管理会計/特性]]のマッピング元などの擦り合わせが代表的。 そもそも、Outputたる分析系に疎いようでは、Inputたる計画系および実行系のクオリティなど知れたもの。 -無いよりはあった方がいい --[[利益センタ会計>管理会計/利益センタ会計]]に理解があること [[品目マスタ]]と[[プラント>ロジスティクス共通/プラント]]を組み合わせどのように提案させるか、[[統制勘定>財務会計/統制勘定]]の[[利益センタ>管理会計/利益センタ]]など後続伝票の出来方は正しいか・・・ 会計ネタだからシラネ、ではなく少しでもケアできれば。 --[[権限>権限管理]]に理解があること [[TC>グローバルトレード管理/トレード契約]]の承認をはじめMIGOでの契約に基づかない荷動きなど、プロセスの定義とソリューションの組み立て双方で、権限の掛け方と担保の仕方は勘案すべきかと思う。 ** 機能の制約と成長過程 [#s9ed4e86] 正直、2010年6月現在をもってしてもGTMには不具合や不具合と目されることが多い。 これには原因は二つある。 *** ベンダが何でも[[アドオン]]で実現してしまうこと [#ddaab3f8] 本来的におかしいことであっても、現状コンフィグで出来ない = じゃあ[[アドオン]]だ!・・・という流れがなんと多いことかと思う。 現状コンフィグで出来ない = 知らないだけではないのか?[[アドオン]]するにしても大中小や松竹梅はあるはずではないか? であるし、そもそも''何故、標準で実現できないのか?''という観点を持つことが肝要と思う。 そもそもコンセプトに沿わないのであれば即[[アドオン]]でなく[[BPR>プロジェクト/BPR]]から入るべきだし、コンセプトに沿っているのに機能が無かったりコンセプトに沿わない動作をするのであれば、[[OSS>SAPの共通用語/OSS]]に問い合わせ、[[SAP Note]]の発行を依頼すべきだ。 確かに期間という制約の元で不本意な応急処置をせざるを得ない場合もあるが、こういった思考と実践を繰り返さなければ、標準システム自体が成長しないことになってしまう。 ちなみに、実際にあったコンセプトにあわない標準の動作は下記のものが挙げられる。 -[[諸掛>グローバルトレード管理/諸掛管理]]経由だと[[公式伝票採番>財務会計/公式伝票採番]]が動作しない 直接WLF1から[[仕入先請求伝票>ロジスティクス共通/仕入先請求伝票]]を起票すると採番されるのに、動かなかった。ゴネられたが[[SAP Note]]は発行してもらった。 -[[トレード契約>グローバルトレード管理/トレード契約]]を参照登録すると項目が欠落する [[品目グループ>品目マスタ/品目グループ]]、[[品目階層>品目マスタ/品目階層]]、[[原価センタ>管理会計/原価センタ]]などがあった。ゴネられたが[[SAP Note]]は発行してもらった。 -[[諸掛>グローバルトレード管理/諸掛管理]]の[[CO-PA>管理会計/収益性分析]]への転送に不具合 確定諸掛のプラマイ符号が逆だったり[[原価要素>管理会計/原価要素]]に基づいた値項目に転送されなかったり、PJ担当者が白痴だったこともあって本番前に阿鼻叫喚のトラブルシュートをする羽目になったことがある。 さんざんゴネられた挙句、作られた[[SAP Note]]が二つとも欠陥まみれだったり、[[OSS>SAPの共通用語/OSS]]がそうであることは知っていたが、いつからSAP社は素人や嘘つきの集まりになったんだ?というザマで、結局[[カスタマExit>SAPの拡張手段/カスタマExit]]で逃げる羽目になった。 但し、名誉の為に補足するとドイツのMiyakeさんは神。 *** こなれていないこと [#m018e343] これは単に[[SD>販売管理]]や[[MM>在庫・購買管理]]程の導入事例が無いことに起因する。 残念ながら成長過程と言うほかないが、一つ目の''ベンダが何でも[[アドオン]]で実現してしまうこと''を是正していかなければ、改善しないままとなってしまう。 個人的に、例えば[[外注加工>購買管理/外注加工]]や[[請求計画>販売管理/請求計画]]などの機能不足((これはスコープアウトされたのだろうから、仕方がないが))はあるものの、不具合さえ潰すことができればGTMは素晴らしい機能だと考えており、ぜひSAPの導入プロジェクトに関わる人間総員で「こなれさせて」いきたいものと思う。 これはGTMに限らないが、SAPというシステムは[[OSS>SAPの共通用語/OSS]]という窓口が存在する以上、積極的にバグfixに働きかけたり問い合わせをしConsulting Noteを発行してもらったり、''業界全体でシステムを育てていく''という意識でやっていきたいものである。 SAP社の中の人には、余計なお世話だ!と言われてしまうかもしれないが。 * 構成 [#b24a9539] -[[トレード契約>グローバルトレード管理/トレード契約]] 取引の母体となる大元の伝票であり、また[[受注伝票>販売管理/受注伝票]]や[[購買発注伝票>購買管理/購買発注伝票]]との繋ぎ部分について。 -[[トレードワークベンチ>グローバルトレード管理/トレードワークベンチ]] 結局別の画面に飛んでいるだけであるものの、窓口を一元化できた功績は偉大。 とはいえ、それを使うために諸々の制約もある。 -[[諸掛管理>グローバルトレード管理/諸掛管理]] [[仕入先請求伝票>ロジスティクス共通/仕入先請求伝票]]を使用した、取引の付帯費用計上について。 -[[収益性シミュレーション>グローバルトレード管理/収益性シミュレーション]] [[トレード契約>グローバルトレード管理/トレード契約]]の段階での粗利照会について。 -[[価格設定]] SDやMMはいわゆる[[標準価格設定>グローバルトレード管理/標準価格設定]]、GTMでは[[販売価格設定>グローバルトレード管理/販売価格設定]]を主軸とする。 * シナリオから見るグローバルトレード管理 [#ac9b4849] * 関連 [#eba71065] [[グローバルトレード管理/関連テーブル]] [[グローバルトレード管理/トランザクションコード]] [[グローバルトレード管理/分野メニュー]] ~ ~ CENTER:【スポンサードリンク】 #htmlinsert(amazon_book_sap_system_implement) ~ ~ ---- #pcomment(reply)
タイムスタンプを変更しない
グローバルトレード管理(以下GTM)とは、機能のベースを標準の受発注([[SD>販売管理]]/[[MM>在庫・購買管理]])としながらも、その枠を超えて商いを管理・遂行するための機構である。 [[分野メニュー>SAPのオブジェクト/分野メニュー]]は、WB20。 ---- #contents ---- * 概要 [#jc92ac28] この機能の生まれは、某ユーザ企業が自社のシステム化にあたり、「売りと買いの一貫した管理」、「それらに係る諸費用の管理」、「相互の紐付け」など商社業務で必要とされる機能が実装されていないことから''「[[SD>販売管理]]/[[MM>在庫・購買管理]]では力不足」''と判断したことに端を発し、開発を請け負ったSAPの手により目出度く誕生した・・・という経緯だそうだ。(また聞き) 確かに、取引に派生する伝票にとどまらない取引間の紐付け([[紐付管理>グローバルトレード管理/紐付管理]]、[[伝票フロー>SAPの共通用語/伝票フロー]]の充実)やプラットフォームの一元化([[トレードワークベンチ>グローバルトレード管理/トレードワークベンチ]])など、GTMが素晴らしい機能であることに議論の余地は無い。 しかし、SAP標準の名誉のために補足すると、[[SD>販売管理]]/[[MM>在庫・購買管理]]がイケてないというわけではないと考える。 根拠として、「GTMを導入したものの、一部事業では冗長なだけであり、その組織向けに[[SD>販売管理]]/[[MM>在庫・購買管理]]を改めて導入した」というプロジェクトを筆者は経験しており、単に顧客ニーズと標準コンセプトがアンマッチだったということなのだろう。 そもそものニーズとして、利益とは期間損益を指す(それを重んじる)商社以外の文化と、利益とは付帯する費用コミコミの契約別損益を指す商社文化という違いがわかりやすいだろうか。 ** 導入コンサルタントにとってのハードル [#e65cf4c4] 上記の「枠を超えて」という通り、習熟には[[SD>販売管理]]と[[MM>在庫・購買管理]]は無論のこと''SAPの機能全般について一定程度の見識がある''ことが前提となる。 理由は、[[諸掛>グローバルトレード管理/諸掛管理]]や[[収益性シミュレーション>グローバルトレード管理/収益性シミュレーション]]をはじめとした独自機能もあるものの、[[トレードワークベンチ>グローバルトレード管理/トレードワークベンチ]]を利用して''代表的な[[SD>販売管理]]や[[MM>在庫・購買管理]]をはじめとした機能をコントロールしている''という作りがベースであり、それは即ちコンフィグだけでなく[[拡張>SAPの拡張手段]]も含めてSAPのコンセプトそのものや機能を自分のものにしてる必要があり、そうでなければプロセスの辻褄が合わなかったり、変化に弱かったりとロクなことにならず、そもそもトラブルシュートにあたっては仕組みを理解できていなければ手も足もでないため、それなりの見識を要すると考える。 但し、GTMのナレッジを持つ技術者はそう多くはないため、多くの場合は自ら習得する必要がある。 筆者の経験では、下記のスキルセットがあれば習得は然程難しくないと考える。 -必須 --[[SD>販売管理]]/[[MM>在庫・購買管理]]に理解があること そもそも売買一貫した機能であるため、プロセスのデザインには片方でなく双方が必須と考える。 --[[アドオン]]もそれなりに触ることができること GTMは、完全な機能を提供しない代わりに様々な[[拡張手段>SAPの拡張手段]]が用意されている。 「○○だからできません」でなく「○○だったらできます」というスタンスでソリューションを提供していくには、もはや必修と呼んでいいかと思う。 開発も組み合わせながら、追加要件を如何に小さな負荷で済ませるか、如何に少ない工数で開発メリットを見い出せるソリューションを作れるか。 -できれば --[[財務会計]]に理解があること [[計上基準>財務会計/計上基準]]、適用する[[換算レート>SAPの共通用語/換算レート]]やその日付、仕訳についてなど、話題は尽きない。 更に言えば''後続プロセスを勘案できること''。オールドタイプのロジコンサルには、会計をケアしない人が多くいるが、そういった人間には正直触って欲しくない。 --[[CO-PA>管理会計/収益性分析]]に理解があること [[条件タイプ>価格設定/価格条件タイプ]]からの転送や[[特性>管理会計/特性]]のマッピング元などの擦り合わせが代表的。 そもそも、Outputたる分析系に疎いようでは、Inputたる計画系および実行系のクオリティなど知れたもの。 -無いよりはあった方がいい --[[利益センタ会計>管理会計/利益センタ会計]]に理解があること [[品目マスタ]]と[[プラント>ロジスティクス共通/プラント]]を組み合わせどのように提案させるか、[[統制勘定>財務会計/統制勘定]]の[[利益センタ>管理会計/利益センタ]]など後続伝票の出来方は正しいか・・・ 会計ネタだからシラネ、ではなく少しでもケアできれば。 --[[権限>権限管理]]に理解があること [[TC>グローバルトレード管理/トレード契約]]の承認をはじめMIGOでの契約に基づかない荷動きなど、プロセスの定義とソリューションの組み立て双方で、権限の掛け方と担保の仕方は勘案すべきかと思う。 ** 機能の制約と成長過程 [#s9ed4e86] 正直、2010年6月現在をもってしてもGTMには不具合や不具合と目されることが多い。 これには原因は二つある。 *** ベンダが何でも[[アドオン]]で実現してしまうこと [#ddaab3f8] 本来的におかしいことであっても、現状コンフィグで出来ない = じゃあ[[アドオン]]だ!・・・という流れがなんと多いことかと思う。 現状コンフィグで出来ない = 知らないだけではないのか?[[アドオン]]するにしても大中小や松竹梅はあるはずではないか? であるし、そもそも''何故、標準で実現できないのか?''という観点を持つことが肝要と思う。 そもそもコンセプトに沿わないのであれば即[[アドオン]]でなく[[BPR>プロジェクト/BPR]]から入るべきだし、コンセプトに沿っているのに機能が無かったりコンセプトに沿わない動作をするのであれば、[[OSS>SAPの共通用語/OSS]]に問い合わせ、[[SAP Note]]の発行を依頼すべきだ。 確かに期間という制約の元で不本意な応急処置をせざるを得ない場合もあるが、こういった思考と実践を繰り返さなければ、標準システム自体が成長しないことになってしまう。 ちなみに、実際にあったコンセプトにあわない標準の動作は下記のものが挙げられる。 -[[諸掛>グローバルトレード管理/諸掛管理]]経由だと[[公式伝票採番>財務会計/公式伝票採番]]が動作しない 直接WLF1から[[仕入先請求伝票>ロジスティクス共通/仕入先請求伝票]]を起票すると採番されるのに、動かなかった。ゴネられたが[[SAP Note]]は発行してもらった。 -[[トレード契約>グローバルトレード管理/トレード契約]]を参照登録すると項目が欠落する [[品目グループ>品目マスタ/品目グループ]]、[[品目階層>品目マスタ/品目階層]]、[[原価センタ>管理会計/原価センタ]]などがあった。ゴネられたが[[SAP Note]]は発行してもらった。 -[[諸掛>グローバルトレード管理/諸掛管理]]の[[CO-PA>管理会計/収益性分析]]への転送に不具合 確定諸掛のプラマイ符号が逆だったり[[原価要素>管理会計/原価要素]]に基づいた値項目に転送されなかったり、PJ担当者が白痴だったこともあって本番前に阿鼻叫喚のトラブルシュートをする羽目になったことがある。 さんざんゴネられた挙句、作られた[[SAP Note]]が二つとも欠陥まみれだったり、[[OSS>SAPの共通用語/OSS]]がそうであることは知っていたが、いつからSAP社は素人や嘘つきの集まりになったんだ?というザマで、結局[[カスタマExit>SAPの拡張手段/カスタマExit]]で逃げる羽目になった。 但し、名誉の為に補足するとドイツのMiyakeさんは神。 *** こなれていないこと [#m018e343] これは単に[[SD>販売管理]]や[[MM>在庫・購買管理]]程の導入事例が無いことに起因する。 残念ながら成長過程と言うほかないが、一つ目の''ベンダが何でも[[アドオン]]で実現してしまうこと''を是正していかなければ、改善しないままとなってしまう。 個人的に、例えば[[外注加工>購買管理/外注加工]]や[[請求計画>販売管理/請求計画]]などの機能不足((これはスコープアウトされたのだろうから、仕方がないが))はあるものの、不具合さえ潰すことができればGTMは素晴らしい機能だと考えており、ぜひSAPの導入プロジェクトに関わる人間総員で「こなれさせて」いきたいものと思う。 これはGTMに限らないが、SAPというシステムは[[OSS>SAPの共通用語/OSS]]という窓口が存在する以上、積極的にバグfixに働きかけたり問い合わせをしConsulting Noteを発行してもらったり、''業界全体でシステムを育てていく''という意識でやっていきたいものである。 SAP社の中の人には、余計なお世話だ!と言われてしまうかもしれないが。 * 構成 [#b24a9539] -[[トレード契約>グローバルトレード管理/トレード契約]] 取引の母体となる大元の伝票であり、また[[受注伝票>販売管理/受注伝票]]や[[購買発注伝票>購買管理/購買発注伝票]]との繋ぎ部分について。 -[[トレードワークベンチ>グローバルトレード管理/トレードワークベンチ]] 結局別の画面に飛んでいるだけであるものの、窓口を一元化できた功績は偉大。 とはいえ、それを使うために諸々の制約もある。 -[[諸掛管理>グローバルトレード管理/諸掛管理]] [[仕入先請求伝票>ロジスティクス共通/仕入先請求伝票]]を使用した、取引の付帯費用計上について。 -[[収益性シミュレーション>グローバルトレード管理/収益性シミュレーション]] [[トレード契約>グローバルトレード管理/トレード契約]]の段階での粗利照会について。 -[[価格設定]] SDやMMはいわゆる[[標準価格設定>グローバルトレード管理/標準価格設定]]、GTMでは[[販売価格設定>グローバルトレード管理/販売価格設定]]を主軸とする。 * シナリオから見るグローバルトレード管理 [#ac9b4849] * 関連 [#eba71065] [[グローバルトレード管理/関連テーブル]] [[グローバルトレード管理/トランザクションコード]] [[グローバルトレード管理/分野メニュー]] ~ ~ CENTER:【スポンサードリンク】 #htmlinsert(amazon_book_sap_system_implement) ~ ~ ---- #pcomment(reply)
テキスト整形のルールを表示する