数字はツールであって、ゴールではない
From 【週刊 戦略調達 vol.81 2010.10.26】
以下抜粋：
数値目標、数値管理をどう使いこなすか、数値目標にどう振り回されないようにするかというのは、一サッカーチームだけの問題ではない。ビジネスの世界でも、数値目標、数値管理は何らかの形でほぼすべての企業のあらゆる現場で用いられている。担当レベルから経営トップの様々な意思決定、評価に数字が使われる。その時に誤った数値に基づいて意思決定、評価していては、望むべき結果が得られない。誤った数値が出てくるのは、必ずしも数値目標のプレッシャーに負けての悪意のあるものばかりではない。単に間違い、ミスということもよくある。数値を扱う時には、データを提出する側もそれを使う側も、数字は意図的あるいは誤って正しい数字が出てこないことが多々あるということを、常に頭の片隅に置いておいた方がよい。
たとえば、我われ調達・購買の世界では、よく価格、コスト削減額といった数値が使われる。サプライヤから非常に魅力的な価格が提示された時、すぐにそれに飛びついてはいけない。なぜ、その価格が出せるのか、それが持続可能かものか、少し考えてみよう。その価格に飛びついて、折角、苦労して技術、製造部門を説き伏せて、そのサプライヤに切り替えた所、その価格は単に今回の注文に限った挨拶価格で、次からの注文ですぐに値上げを要請してくるかもしれない。競合に比べて1割も価格が異なるのであれば、他社にはない技術を用いている、材料･部品を上手く調達している、工程が簡素化されている等の何らかの工夫か、あるいは、それまで調達活動をまったく徹底していなかったといった理由があるはず。
こうした視点は管理者、経営者にも不可欠だ。調達・購買担当者が5％のコスト削減を達成したと報告してきたら、手放しで喜ぶ前にそのコスト削減がどのようになされたかを確認してみよう。単に物流費を切り出して、物流部門に付け替えただけかもしれない。あるいは、単に新規品の取引で初回見積から5％下げただけかもしれない。これでは、貴社のコスト構造、損益分岐点は何も変わっていない。
コスト削減には、取引条件、取引先、仕様など何らかの変更が伴う。担当者の言っているコスト削減が本物ならば、数値の裏にあるそうしたストーリーを報告するのは簡単だ。反対に、出てきた数値にそうした裏付けがなかったら、何かがおかしいと疑うべき。
一つの数値だけ見ていては何も分からないが、その原因、波及効果に思いを寄せれば、その数字が本物かウソかはすぐ分かる。数字一つに一喜一憂するのではなく、その数字がそうであるならば、何がなされ、何が起こっているべきかまで考えよう。そして、そういう施策が打たれているか、起こるべき波及効果が出ているか、違う数字や情報を集めてみよう。そうすることによって初めて元の数値が何を意味するのか、本物の数字かウソのものかが分かってくる。そして、今、何が起こっているのか、これからどうすべきなのか、色々と語りかけてくれる。そうすれば、数字に惑わされることなく、目指すゴールを達成するためのツールとして、上手に数字を活用することができる。
数字そのものは嘘はつかない。数字が嘘をつくのは、それを使う人間によってのみだ。
2010年10月27日水曜日
2010年10月22日金曜日
2010年10月21日木曜日
【機能検証】会社コード間在庫転送プロセス
【要件】
1. 同じグループに属する二つの会社
2. 2Step
【システム図】
【検討ポイント】
1. 内部請求書の価格
【実装方法】
1. マスタ
・入庫プラント2200が関連販売エリアで得意先マスタ22000を登録
・供給プラント（1200）は購買組織（2200）で仕入先マスタを登録（10000）
2. カスタマイズ
・出荷伝票タイプおよび確認規則（購買伝票タイプUB ← 出荷タイプNLCC、確認規則RP、Ship.Sch.）
・購買伝票タイプ、ワンステップ転送、不足納入許容範囲 （OneStepにチェックを入れない）
1. 同じグループに属する二つの会社
2. 2Step
【システム図】
【検討ポイント】
1. 内部請求書の価格
【実装方法】
1. マスタ
・入庫プラント2200が関連販売エリアで得意先マスタ22000を登録
・供給プラント（1200）は購買組織（2200）で仕入先マスタを登録（10000）
2. カスタマイズ
・出荷伝票タイプおよび確認規則（購買伝票タイプUB ← 出荷タイプNLCC、確認規則RP、Ship.Sch.）
・購買伝票タイプ、ワンステップ転送、不足納入許容範囲 （OneStepにチェックを入れない）
2010年10月19日火曜日
【機能検証】会社コード内在庫転送プロセス
【要件】
1. 分散倉庫は中央倉庫から部品を在庫転送で調達する。
2. 中央倉庫の出庫は出荷活動（ピッキング、梱包、納品書印刷など）で処理する。
【システム図】
【検討ポイント】
1. 1Step Or 2 Step
【実装方法】
1. マスタ
・入庫プラント1400が関連販売エリアで得意先マスタ14000を登録
・品目マスタの供給プラント（1200）を登録
・品目マスタの調達タイプ（F：外部調達）、特殊調達タイプの設定
2. カスタマイズ
・出荷伝票タイプおよび確認規則（購買伝票タイプUB ← 出荷タイプNL、確認規則RP）
・購買伝票タイプ、ワンステップ転送、不足納入許容範囲
・得意先コード14000を入庫プラント1400に割り当て
・販売エリア（1000、12、00）の供給プラント（1200）への割り当て
1. 分散倉庫は中央倉庫から部品を在庫転送で調達する。
2. 中央倉庫の出庫は出荷活動（ピッキング、梱包、納品書印刷など）で処理する。
【システム図】
【検討ポイント】
1. 1Step Or 2 Step
【実装方法】
1. マスタ
・入庫プラント1400が関連販売エリアで得意先マスタ14000を登録
・品目マスタの供給プラント（1200）を登録
・品目マスタの調達タイプ（F：外部調達）、特殊調達タイプの設定
2. カスタマイズ
・出荷伝票タイプおよび確認規則（購買伝票タイプUB ← 出荷タイプNL、確認規則RP）
・購買伝票タイプ、ワンステップ転送、不足納入許容範囲
・得意先コード14000を入庫プラント1400に割り当て
・販売エリア（1000、12、00）の供給プラント（1200）への割り当て
【機能検証】会社間販売プロセス
【要件】
グループ傘下の別会社の在庫から得意先に直接出荷する。
【システム図】
【検討ポイント】
1. 供給プラント：マスタレコードより提案される
・ 得意先/品目情報レコード
・ 得意先マスタレコード
・ 品目マスタレコード
【実装方法】
1. カスタマイズ：
・ 出荷プラント（1200）が受注販売組織（2200）、流通チャンネル（10）へ割り当て
・ 出荷プラント（1200）が販売エリア（1000、12、00）へ割り当て → 会社間請求
・ 定義: 内部得意先コード (販売組織別) 22000
２. マスタ：
・ 品目：販売組織（2200）、流通チャンネル（10） → 出荷プラント（1200）
・ 出荷プラント（1200）が販売エリア（1000、12、00）へ割り当て → 会社間請求
・ 得意先マスタコード（22000）を販売エリア（1000、12、00）で登録する
【実装結果】
・ 価格関連
・ 請求関連
グループ傘下の別会社の在庫から得意先に直接出荷する。
【システム図】
【検討ポイント】
1. 供給プラント：マスタレコードより提案される
・ 得意先/品目情報レコード
・ 得意先マスタレコード
・ 品目マスタレコード
【実装方法】
1. カスタマイズ：
・ 出荷プラント（1200）が受注販売組織（2200）、流通チャンネル（10）へ割り当て
・ 出荷プラント（1200）が販売エリア（1000、12、00）へ割り当て → 会社間請求
・ 定義: 内部得意先コード (販売組織別) 22000
２. マスタ：
・ 品目：販売組織（2200）、流通チャンネル（10） → 出荷プラント（1200）
・ 出荷プラント（1200）が販売エリア（1000、12、00）へ割り当て → 会社間請求
・ 得意先マスタコード（22000）を販売エリア（1000、12、00）で登録する
【実装結果】
・ 価格関連
・ 請求関連
2010年10月18日月曜日
【機能検証】仕入先直送
【要件】
自社の倉庫を介さず仕入先から得意先へ仕入先直送を行う。
【システム図】
【検討ポイント】
1. 受注から購買依頼が自動的に作成。
2. 仕入先が直接得意先へ納入する
【実装方法】
1. カスタマイズ：
・ 受注から購買依頼が自動的に作成
→ 受注伝票明細カテゴリ：購買発注自動作成 チェック
→ 明細カテゴリの決定： 販売伝票タイプ ＋ 明細カテゴリグループ ＋ 明細用途 ＋ 上位明細カテゴリ
→ 納入日程カテゴリ： 出荷関連チェック OFF、発注タイプ（購買依頼）、明細カテゴリ（仕入れ先直送）、勘定設定カテゴリ
→ 納入日程カテゴリ決定： 明細カテゴリ、MRPタイプ（品目マスタ）
・ 勘定設定カテゴリの設定内容確認（出庫関連チェック）
・ 明細カテゴリと勘定設定カテゴリの組み合わせ設定
２. マスタ：
・ 購買情報を設定する（購買価格）
・ 仕入先1010と購買組織1000を固定供給元として設定する。
・ 品目マスタ設定（明細カテゴリグループ）得意先マスタコード（22000）を販売エリア（1000、12、00）で登録する
【実装結果】
Could not GI. Why?
Message: Purchase order XXXX has no items.
→ POの入庫区分チェックしていない
→ 勘定設定カテゴリの入庫区分にチェックをいれていない
自社の倉庫を介さず仕入先から得意先へ仕入先直送を行う。
【システム図】
【検討ポイント】
1. 受注から購買依頼が自動的に作成。
2. 仕入先が直接得意先へ納入する
【実装方法】
1. カスタマイズ：
・ 受注から購買依頼が自動的に作成
→ 受注伝票明細カテゴリ：購買発注自動作成 チェック
→ 明細カテゴリの決定： 販売伝票タイプ ＋ 明細カテゴリグループ ＋ 明細用途 ＋ 上位明細カテゴリ
→ 納入日程カテゴリ： 出荷関連チェック OFF、発注タイプ（購買依頼）、明細カテゴリ（仕入れ先直送）、勘定設定カテゴリ
→ 納入日程カテゴリ決定： 明細カテゴリ、MRPタイプ（品目マスタ）
・ 勘定設定カテゴリの設定内容確認（出庫関連チェック）
・ 明細カテゴリと勘定設定カテゴリの組み合わせ設定
２. マスタ：
・ 購買情報を設定する（購買価格）
・ 仕入先1010と購買組織1000を固定供給元として設定する。
・ 品目マスタ設定（明細カテゴリグループ）得意先マスタコード（22000）を販売エリア（1000、12、00）で登録する
【実装結果】
Could not GI. Why?
Message: Purchase order XXXX has no items.
→ POの入庫区分チェックしていない
→ 勘定設定カテゴリの入庫区分にチェックをいれていない
2010年10月13日水曜日
日付型（DATUM）項目
問題：
日付項目に「 / / 」の内容をセットされ、IF 日付項目 = INITIAL.に入れない。
調査：
2010/10/02
・ Clear → 0000/00/00 ＝ Initial
・ Space → / / Initial
原因：
日付項目の初期値は「00000000」である、これは「 / / 」とは違うため、IF分に入れない。
解決案：
① 日付項目のリセットは「00000000」を代入するかClearを用いる
② IFを書く際、SAPCEでクリアしようというミスを防ぐため、以下の構文で対応する
IF 日付項目 IS INITIAL OR
日付項目 = SPACE
日付項目に「 / / 」の内容をセットされ、IF 日付項目 = INITIAL.に入れない。
調査：
2010/10/02
・ Clear → 0000/00/00 ＝ Initial
・ Space → / / Initial
原因：
日付項目の初期値は「00000000」である、これは「 / / 」とは違うため、IF分に入れない。
解決案：
① 日付項目のリセットは「00000000」を代入するかClearを用いる
② IFを書く際、SAPCEでクリアしようというミスを防ぐため、以下の構文で対応する
IF 日付項目 IS INITIAL OR
日付項目 = SPACE
日付型（DATUM）項目
問題：
日付項目に「 / / 」の内容をセットされ、IF 日付項目 = INITIAL.に入れない。
調査：
2010/10/02
・ Clear → 0000/00/00 ＝ Initial
・ Space → / / <> Initial
原因：
日付項目の初期値は「00000000」である、これは「 / / 」とは違うため、IF分に入れない。
解決案：
① 日付項目のリセットは「00000000」を代入するかClearを用いる
② IFを書く際、SAPCEでクリアしようというミスを防ぐため、以下の構文で対応する
IF 日付項目 IS INITIAL OR
日付項目 = SPACE
日付項目に「 / / 」の内容をセットされ、IF 日付項目 = INITIAL.に入れない。
調査：
2010/10/02
・ Clear → 0000/00/00 ＝ Initial
・ Space → / / <> Initial
原因：
日付項目の初期値は「00000000」である、これは「 / / 」とは違うため、IF分に入れない。
解決案：
① 日付項目のリセットは「00000000」を代入するかClearを用いる
② IFを書く際、SAPCEでクリアしようというミスを防ぐため、以下の構文で対応する
IF 日付項目 IS INITIAL OR
日付項目 = SPACE
2010年10月1日金曜日
ERPと日本商習慣
ＥＲＰの世界では、「ＥＲＰパッケージの機能が、日本の商習慣に対応しているか」というのが問題になります。
◆ 製造
・ 有償支給
・ 内示
・ 製番管理
・ かんばん
◆ 販売・購買
・ 仮単価
・ リベート（複雑な計算式とか）
・ 月次一括請求（ＥＲＰでは各受注に対して請求、が基本）
◆ 会計
・ 消費税（課税、非課税、免税、不課税または対象外）
・ ５・１０日締め
・ 手形管理（例：現物管理、半金半手、手形分割など）
・ 全銀協のＦＢデータ
・ 減価償却
- 会計用、法人税用、償却資産税用など
・大半の会社では、法人税用の耐用年数を会計用にも使用。
外資系の会社では、会社のグローバルルールを会計用に使用
することも。
・但し、IFRSでは、会計用に法人税ルールを使うのはＮＧ。
- 端数処理
日本の法人税法では１円未満切捨て
例えば、Oracle EBSは四捨五入（だったと思う）
・ 固定資産関連レポート
- 償却資産申告書
・市区町村の設定要
・自動車は申告不要（自動車税がかかるので）
・ソフトウェアなどの無形固定資産は申告不要
- 種類別明細書
- 法人税確定申告書（別表１６）
From：ＥＲＰコンサルタントのブログ
◆ 製造
・ 有償支給
・ 内示
・ 製番管理
・ かんばん
◆ 販売・購買
・ 仮単価
・ リベート（複雑な計算式とか）
・ 月次一括請求（ＥＲＰでは各受注に対して請求、が基本）
◆ 会計
・ 消費税（課税、非課税、免税、不課税または対象外）
・ ５・１０日締め
・ 手形管理（例：現物管理、半金半手、手形分割など）
・ 全銀協のＦＢデータ
・ 減価償却
- 会計用、法人税用、償却資産税用など
・大半の会社では、法人税用の耐用年数を会計用にも使用。
外資系の会社では、会社のグローバルルールを会計用に使用
することも。
・但し、IFRSでは、会計用に法人税ルールを使うのはＮＧ。
- 端数処理
日本の法人税法では１円未満切捨て
例えば、Oracle EBSは四捨五入（だったと思う）
・ 固定資産関連レポート
- 償却資産申告書
・市区町村の設定要
・自動車は申告不要（自動車税がかかるので）
・ソフトウェアなどの無形固定資産は申告不要
- 種類別明細書
- 法人税確定申告書（別表１６）
From：ＥＲＰコンサルタントのブログ
ERPと日本商習慣
ＥＲＰの世界では、「ＥＲＰパッケージの機能が、日本の商習慣に対応しているか」というのが問題になります。
◆ 製造
・ 有償支給
・ 内示
・ 製番管理
・ かんばん
◆ 販売・購買
・ 仮単価
・ リベート（複雑な計算式とか）
・ 月次一括請求（ＥＲＰでは各受注に対して請求、が基本）
◆ 会計
・ 消費税（課税、非課税、免税、不課税または対象外）
・ ５・１０日締め
・ 手形管理（例：現物管理、半金半手、手形分割など）
・ 全銀協のＦＢデータ
・ 減価償却
- 会計用、法人税用、償却資産税用など
・大半の会社では、法人税用の耐用年数を会計用にも使用。
外資系の会社では、会社のグローバルルールを会計用に使用
することも。
・但し、IFRSでは、会計用に法人税ルールを使うのはＮＧ。
- 端数処理
日本の法人税法では１円未満切捨て
例えば、Oracle EBSは四捨五入（だったと思う）
・ 固定資産関連レポート
- 償却資産申告書
・市区町村の設定要
・自動車は申告不要（自動車税がかかるので）
・ソフトウェアなどの無形固定資産は申告不要
- 種類別明細書
- 法人税確定申告書（別表１６）
From：ＥＲＰコンサルタントのブログ
◆ 製造
・ 有償支給
・ 内示
・ 製番管理
・ かんばん
◆ 販売・購買
・ 仮単価
・ リベート（複雑な計算式とか）
・ 月次一括請求（ＥＲＰでは各受注に対して請求、が基本）
◆ 会計
・ 消費税（課税、非課税、免税、不課税または対象外）
・ ５・１０日締め
・ 手形管理（例：現物管理、半金半手、手形分割など）
・ 全銀協のＦＢデータ
・ 減価償却
- 会計用、法人税用、償却資産税用など
・大半の会社では、法人税用の耐用年数を会計用にも使用。
外資系の会社では、会社のグローバルルールを会計用に使用
することも。
・但し、IFRSでは、会計用に法人税ルールを使うのはＮＧ。
- 端数処理
日本の法人税法では１円未満切捨て
例えば、Oracle EBSは四捨五入（だったと思う）
・ 固定資産関連レポート
- 償却資産申告書
・市区町村の設定要
・自動車は申告不要（自動車税がかかるので）
・ソフトウェアなどの無形固定資産は申告不要
- 種類別明細書
- 法人税確定申告書（別表１６）
From：ＥＲＰコンサルタントのブログ
締め処理
【品目マスタ締め処理】
１．品目管理レコードテーブルMARV
入出庫伝票を登録可能期間を管理しているテーブル。入出庫を登録する際、転記日付とMRAVの前期、
当期を比較して、制御を行う。当期と前期の2ヶ月間のみ伝票入力可能。
２．会計期間締め処理(T-CD：MMPV)
翌月の転記を許可するため、MARVの当期、前期を１ヶ月ずらす処理。当処理によって、MARVのデー
タを更新される。
MARVのデータ動き(９月→１０月)
締め前 締め後
当年度 2010 → 2010
当期 09 → 10
前年度 2010 → 2010
前期 08 → 09
３．締め処理と在庫の関係
最新の在庫はMARD、過去在庫はMARDH。締め処理をした時点で、MARDからMARDHへ推移せず、受払を発
生した時点で在庫推移を発生する。
月末の確定在庫はMARDHより取得、取得できない場合、MARDの数値を利用する。
４．締め処理後の在庫転記
締め処理後に前期日付で伝票を登録した場合、前期、今期の在庫を両方更新される。当期日付で入出
庫伝票を登録した場合、当期在庫のみ更新される。
１．品目管理レコードテーブルMARV
入出庫伝票を登録可能期間を管理しているテーブル。入出庫を登録する際、転記日付とMRAVの前期、
当期を比較して、制御を行う。当期と前期の2ヶ月間のみ伝票入力可能。
２．会計期間締め処理(T-CD：MMPV)
翌月の転記を許可するため、MARVの当期、前期を１ヶ月ずらす処理。当処理によって、MARVのデー
タを更新される。
MARVのデータ動き(９月→１０月)
締め前 締め後
当年度 2010 → 2010
当期 09 → 10
前年度 2010 → 2010
前期 08 → 09
３．締め処理と在庫の関係
最新の在庫はMARD、過去在庫はMARDH。締め処理をした時点で、MARDからMARDHへ推移せず、受払を発
生した時点で在庫推移を発生する。
月末の確定在庫はMARDHより取得、取得できない場合、MARDの数値を利用する。
４．締め処理後の在庫転記
締め処理後に前期日付で伝票を登録した場合、前期、今期の在庫を両方更新される。当期日付で入出
庫伝票を登録した場合、当期在庫のみ更新される。
締め処理
【品目マスタ締め処理】
１．品目管理レコードテーブルMARV
入出庫伝票を登録可能期間を管理しているテーブル。入出庫を登録する際、転記日付とMRAVの前期、
当期を比較して、制御を行う。当期と前期の2ヶ月間のみ伝票入力可能。
２．会計期間締め処理(T-CD：MMPV)
翌月の転記を許可するため、MARVの当期、前期を１ヶ月ずらす処理。当処理によって、MARVのデー
タを更新される。
MARVのデータ動き(９月→１０月)
締め前 締め後
当年度 2010 → 2010
当期 09 → 10
前年度 2010 → 2010
前期 08 → 09
３．締め処理と在庫の関係
最新の在庫はMARD、過去在庫はMARDH。締め処理をした時点で、MARDからMARDHへ推移せず、受払を発
生した時点で在庫推移を発生する。
月末の確定在庫はMARDHより取得、取得できない場合、MARDの数値を利用する。
４．締め処理後の在庫転記
締め処理後に前期日付で伝票を登録した場合、前期、今期の在庫を両方更新される。当期日付で入出
庫伝票を登録した場合、当期在庫のみ更新される。
１．品目管理レコードテーブルMARV
入出庫伝票を登録可能期間を管理しているテーブル。入出庫を登録する際、転記日付とMRAVの前期、
当期を比較して、制御を行う。当期と前期の2ヶ月間のみ伝票入力可能。
２．会計期間締め処理(T-CD：MMPV)
翌月の転記を許可するため、MARVの当期、前期を１ヶ月ずらす処理。当処理によって、MARVのデー
タを更新される。
MARVのデータ動き(９月→１０月)
締め前 締め後
当年度 2010 → 2010
当期 09 → 10
前年度 2010 → 2010
前期 08 → 09
３．締め処理と在庫の関係
最新の在庫はMARD、過去在庫はMARDH。締め処理をした時点で、MARDからMARDHへ推移せず、受払を発
生した時点で在庫推移を発生する。
月末の確定在庫はMARDHより取得、取得できない場合、MARDの数値を利用する。
４．締め処理後の在庫転記
締め処理後に前期日付で伝票を登録した場合、前期、今期の在庫を両方更新される。当期日付で入出
庫伝票を登録した場合、当期在庫のみ更新される。
登録:
投稿 (Atom)