在庫管理システム統合計画の監査

概要

P社の子会社であるA社とB社が合併し、新会社をつくる
それぞれ持っていた在庫システムはA社側によせる
- システムをA社側に寄せるにあたり、A社側のシステム強化する


[P社]--------------+---------[A社]----(在庫システム)　
                   |
                   |
                   +---------[B社]----(在庫システム)


　　　　　　　　　↓

[P社]--------------+-----[新会社（A＋B)]----((新・在庫システム))

統合スケジュール

8/31	実施棚卸	在庫数量差異調整
		↓
9/30	在庫数量確定	在庫移管	システム変更/マスタ登録
		↓	↓
10/31	在庫移管完了		↓
			↓
11/30	在庫データの統合完了		↓

従来のモジュール製品の製造と在庫管理

以下の通り、B社の製品をいったんA社に集めて改めて管理する。
その後A社内でモジュール製造をするフローとしていた。

( [A社倉庫管理システム] @ A社コード )             ( [B社倉庫管理システム] @ B社コード )

             +＜---------------------------------------------<B社製品>
             |
       [A社コードの付与]
             |
             |
       (モジュール製造)

(1)在庫データの統合方法

＞現状

A社・・・10桁（ただし1桁目に「８」を使っていない）
B社・・・9桁

使っているパッケージソフトは同じ。つまりコード体系が違うだけ　⇔　言い換えると、同じ製品でもそれぞれでコードが違う製品が存在する、ということ

＞統合後

10桁コードで統合する　※B社は先頭に「8」を付ける形式とする

(2)実地棚卸と差異調整の仕方

差異調整は以下の通りにやる。

実地棚卸
在庫システムへ結果を入力し差異データを取得
差異について原因調査
修正値を入力
責任者の承認をもってDBを更新する

[実地棚卸]-------(入力)-------＞[[在庫管理システム]]＜---------(照合)---------＞（（在庫数量DB））
                                                                  |
                                                                  |
[原因調査] ＜-----------------｜差異データ｜----------------------+
    |
    |
    +-------(修正値入力)------＞[[在庫管理システム]]-----------(update)---------＞（（在庫数量DB））
                        ↑
                         |                          
                         |
                     [責任者承認]

(3)長期滞留品

12か月以上売上実績がない製品が対象とする

⇒　今回は棚卸日から12か月以上経過しているものが対象。
※これらは、現品確認のうえ、廃棄/評価減処理を実施する

◆取り出しイメージ

 select * from ～～～ 
          where (棚卸日() - 最終出荷日()) >= 12

みたいな感じ

監査ポイント

長期滞留品の抽出漏れが生じないようになっているか
- つまり、前提としているDB上の最終出庫日が本当に正しいかどうかが懸念される

　　　　　　　↓

棚卸作業など移管のために製品の取り出し作業が発生しても
最終出庫日はそのまま書き変わらない、
ということをインタビューにて確認する

RCM

NO.	リスク	コントロール
1	在庫データの統合が適正に行われない	・A社/B社の統合前後の在庫データを在庫システムで全件照合する

指摘事項①：統合されない在庫データが発生する可能性がある

A社とB社で製品コードが別々である一方、
- B社の製品を受け取ったA社はA社として製品コードをあらためて付与する

　　　　　　　　　　　↑
統合後は当然同じものとして扱う必要がある

現在、A社とB社で同一製品で異なるコードを設定しているため
統合後このような在庫データは統合されない。
　↓　
同一製品が複数コードに分かれて記録されてしまう

NO.	リスク	コントロール
2	実地棚卸の際数量が適正に修正されない	・差異の原因/修正入力ができる担当者を限定する・担当者と責任者は必ず職務分離する・十分な教育訓練を行う

DBの値修正にあたっては、かならず修正・承認の流れをとる
同時に、自演による不正登録を予防するために、職務分離を必ず行う！

NO.	リスク	コントロール
3	システム上の数量と現品の数量が不一致のまま、在庫移管を開始してしまう	・移管開始前に、すべての差異データの承認入力が完了しているかを確認する