現場の事実から考え、
業務の目的を見失わない。

生産管理は、システム、帳票、既存の業務名称からではなく、

現場で実際に何が起きているか

から考える。

モノ、人、設備、情報が、いつ、どこで、どのように動いているのかを理解することを出発点とする。

管理項目やシステム機能を増やす前に、

「その情報を何の判断に使うのか」

を明確にする。

管理できるから管理するのではない。

管理粒度は、利用目的と現場負荷のバランスで決める。

ERPパッケージ、生産管理パッケージ、MES、WMSなど、特定の商品や機能を起点として業務を考えない。

まず、

業務上何を実現したいのか。

何を管理し、何を判断する必要があるのか。

を明確にする。

そのうえで、標準機能の活用、業務変更、追加開発、外部システム連携を判断する。

パッケージファーストでも、現行業務ファーストでもない。業務目的ファーストで考える。

生産管理の基本は、

計画 → 実行 → 実績 → 差異 → 次の判断

の循環である。

計画と実績を混同せず、その差異と原因を把握できる仕組みを持つ。

生産管理では、

◆ モノの動き

◆ 情報の動き

◆ 金額・原価・会計の動き

をつなげて考える。

ただし、それぞれが同じタイミングで発生するとは限らない。

物理的な出来事、業務上の認定、会計上の計上を分け、それぞれの関係を明確にする。

現在の状態を正しくするだけでは不十分である。

何が起きた結果、現在の状態になったのか

を追跡できるようにする。

入出庫、訂正、取消、棚卸差異、状態変更などは、可能な限り業務上の事実として履歴を残す。

品目、BOM、工程、能力、リードタイム、取引先などのマスタは、単なるコード表ではない。

マスタは、計画、調達、製造、在庫、原価を成立させる基礎情報である。

マスタの品質以上の生産管理はできない。

版、有効期間、変更履歴も含めて考える。

同じモノであっても、

◆ 現物が存在する

◆ 使用できる

◆ 引当できる

◆ 所有している

◆ 資産として評価される

ことは同じではない。

在庫や仕掛は、

数量、所在、状態、利用可能性、所有、評価

を必要に応じて分けて考える。

ERP、MES、WMS、PLMその他のシステムで、同じ情報を無目的に二重管理しない。

各データについて、

「何が正であり、誰が責任を持つのか」

を明確にする。

これはシステムだけではなく、部門や担当者についても同じである。

通常処理だけで業務やシステムを設計しない。

返品、不良、保留、過不足、緊急処理、移送途中、直送、支給、棚卸差異など、

実際の現場で起こる例外

を確認する。

例外処理に耐えられない仕組みは、実運用に耐えられない。

システムで実現できることと、システムで実現すべきことは同じではない。

業務ルール、組織責任、人による判断、システムによる制御を分けて考える。

システムは業務上の問題を覆い隠すものではなく、

正しく業務を行い、正しく判断するための手段

として使う。

一部門、一工程、一システムだけを見て最適化しない。

需要、調達、製造、在庫、物流、販売、原価、会計までのつながりを見る。

ある部門の効率化が、

◆ 他部門の負荷

◆ 在庫増加

◆ リードタイム増加

◆ データ不整合

を生んでいないかを確認する。

企業、生産形態、製品によって、生産管理の方法は異なる。

すべてを一つの方法に統一することは目的としない。

まずエクステンドとしての標準的な考え方を持つ。

そのうえで、

「なぜ、この会社では標準と違うのか」

を説明できる状態にする。

標準から外れることを問題とするのではなく、理由なく外れることを問題とする。

顧客が使う言葉を、自分が知っている一般用語やシステム用語へ勝手に置き換えない。

「部品」「品目」「製品」「仕掛」「完成」「入荷」「受入」「検収」「出荷」など、一般的に使われる言葉であっても、その意味や業務上のタイミングは会社・工場によって異なる。

まず、

「この会社、この工場では、その言葉を何の意味で使っているのか」

を確認する。

聞くことを恥じるな。分かったつもりを恐れろ。

分からない言葉、曖昧な言葉は、その場で確認する。

用語の違いを単なる呼び方の違いとして処理せず、必要に応じて、

◆ 何を指しているのか

◆ いつその状態になるのか

◆ 前後にどの業務イベントがあるのか

◆ システム上どのデータ・ステータスに対応するのか

まで確認する。

重要な用語はプロジェクト内で定義し、関係者が同じ意味で使える状態にする。