|
||||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||||
| 変更管理の見える仕組み | ||||||||||||||||||
|
変更管理とは、製品の改良や原価の低減、品質の保証などによって部材や部品構成の変更情報を管理することである。設計時の変更情報には、BOMや図面、仕様書などの設計帳票、データの変更がある。 そのような変更が発生する要因は表4のように分けられる。
表4:変更要因 またその変更内容には、表5に示すものが想定される。
表4:変更内容 |
||||||||||||||||||
| 変更処理の例 | ||||||||||||||||||
|
それではBOMによる製品管理において変更が発生した場合について考える。例えば、製品C内の部材Aに対して変更が発生し、部材Aを部材Dに変更した場合、BOMの情報は図4のように付け替えられる。 ![]() 図4:変更処理の概要 変更については関連各部門の作業状況を確認した上で、変更の影響範囲と有効日を決定する必要がある。 製品と工程進捗の関係を考えた場合、製品が出荷済みなのか、組立て品(出荷前)なのかなどによって、工程進捗に与える影響が変化するため留意する。特に、製造工程に入っている場合、生産ラインを止めるなどの処置が必要となるケースが多く、納期遅延や製造コストの増大につながる要因となりやすい。 |
||||||||||||||||||
| システム化のための前提条件は品目コードの統一 | ||||||||||||||||||
|
ここまでで製品ライフサイクル管理の仕組みについて解説してきた。ではこのシステム化にともない必要となる要素は何か。それが品目コードの統一である。 製品の品目をあらわす単位である品目コードは、設計・製造・調達・販売で異なるケースが多い。従来のように、顧客や調達先の既存システムに依存するような場合、品目コードのコード体系のみならず桁数までもが異なっており、品目コードが管理ができていないケースが散見される。 現状を考えれば、この品目コードを設計・製造・調達・販売で完全に統一するのは困難であろう。 |
||||||||||||||||||
| 「品目」はユニークなままで、「コード」を統一して管理する | ||||||||||||||||||
|
しかしこれまでのような「N:N」の関係になっている品目コードを「1:N(N:1)」の関係に整理し、変換テーブルをタイムリーにメンテナンスする体制とルールを整え、システム化を行うことで、データ精度が向上し、これまで手作業で行っていたデータ集計業務の負荷を軽減できる。 つまりシステム化によって製品ライフサイクルを通した製品情報の一元的な管理を実現するためには、ライフサイクル内における「品目」はあくまでもユニークなままで、統一された「コード」で管理することが前提条件となる。 |
||||||||||||||||||
| 次回は | ||||||||||||||||||
|
今回は品目情報を基幹系システムから抽出することで、その外部で製品ライフサイクル管理を実現する仕組みについて解説した。 次回はBOMにコスト情報を付加することにより、バリューチェーンの中で目標コストの変遷を可視化する仕組みについて解説し、原価企画の効率的な考え方について考察していく。 |
||||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||||
|
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||


