人気ブログランキング | 話題のタグを見る

コミュニケーションの基盤としてのBOM=部品表

拙著『BOM/部品表入門 (図解でわかる生産の実務)』(日本能率協会マネジメントセンター刊)が増刷になり、累計5,000部の出荷となった。専門書としては堅実な部類に入る数字だ。これまで読んでいただいた多くの方に深く感謝したい。執筆に着手した段階では、BOMを主題とした本はほとんど出ていなかった。今では何冊も出版されているので、おそらく読者ニーズの時宜にかなったのでは、と思う。

本書は山崎誠氏との共著だが、全体構成と本文の8割を私が執筆した。2000年に出版した『革新的生産スケジューリング入門―“時間の悩み”を解く手法』の続編という位置づけで、同じ登場人物の「矢口先生」が、今度は大学ではなく企業に出張講義するスタイルで書かせてもらった。私はなぜか、一方的な叙述よりも、対話的な文章の方が書きやすいのである。

ところで、本書の執筆には1年ほどかかったが、書くにつれて、自分自身BOMに関する認識の深化していくのを感じていた。じつは、書き始めたときは、ERP技術者向きの本にするつもりだったのだ。それなのに、書き終わる頃には、まったく別の意図をもった本になっていた。そのメッセージとは、こうだ:「BOMデータを、特定のパッケージや外部コード体系に依存するべきではない」。なぜなら、広義のBOMとは、生産に関する企業内コミュニケーションの基盤であり、製造業のすりあわせ的統合の要(かなめ)となるからだ--

BOMの問題に気づいたのは、生産スケジューリングの仕事にいくつかたずさわるようになってからだった。じっさい、多くの企業でスケジューラ導入時にぶつかる主要な困難が、BOMデータの構築なのだ。スケジューラはお金を出せば一応、買える。しかし自社の部品表データは、世の中のどこにも売っていない。だから自分たちで整理するしかない。上の方の偉い人は、“そんなのソフトウェア・ベンダーにやってもらえばいいだろう”などと無責任に発想するが、現実を知っている技術者はそうはいかない。まして、「設計部門と製造部門で持っているBOMが違っているんです」なんて、コワくて報告できたものではない。

MRPⅡをベースにしたERPパッケージの生産管理システムの場合、ある意味で問題はもっと深刻だ。MRPのスケジューリングは、タイムバケットと標準リードタイムと無限負荷計画が生み出す、ラフな近似でしかない。近似は近似として使いこなせばいいのだが、困ったことにERPは原価管理に主眼がある。ERPのもつ奇妙な厳格さが、ここでは足かせとなってしまう。たとえば、製品を構成する部品を全部きちんとリストアップしないと、正しい原価がつかめない。購買オーダーも出てこない。つまり、おなじ部品表というマスタを見る視点が、違う粒度を持っているのだ。

一つの会社の中で、相矛盾する複数の部品表が生まれてしまう原因は、複数の機能部門が、異なる目的と粒度でBOMを見ているためである。BOMはもともと、資材購買の必要性から生まれ、ついで生産計画の主要概念になった。そこから派生して、設計・生産技術・生産管理・購買・在庫・製造・物流・保守・サービス・IT・営業・財務と、あらゆる部門が大なり小なり関わるハブ的な存在となっている。

そこで、『BOM/部品表入門』では、各々がいかなる視点からBOMをながめ、そこにどのような要件を持っているかを解説することで、BOMをとりまく課題を多角的に示そうとしたのである。そして、その結果としてたどりついたのが、「BOMプロセッサの発想である。企業内コミュニケーションの基盤情報をコントロールするための、アプリケーションから独立した一種のデータベースが必要だ、というのが私の結論だ。

一種のデータベースであるから、できれば標準スキーマを示すべきなのだろう。しかし、いろいろ考えた末、本書ではスキーマを書くのはやめてしまった。製造業は多様である。BOMはプロセス生産から切替型連続生産をへて組立加工生産まで、あらゆる生産形態に存在する。それらの最大公約数的なスキーマを提示しても、誰の役にも立たないからだ。むしろ、その企業固有の思想を反映するかたちで、各企業がスキーマを自分で考えるべきだと私は信じる。
(とはいえ、何かテンプレートとなるものがあると助かる人は多いと思う。この点で、私は渡辺幸三氏の仕事=Conceptware 生産管理に期待している)

この本では、まだ書き残した部分も多い。たとえば:
・設計ブロックと製造ユニット
・トランザクションBOMデータの内容とマスタからの変換
・個別受注生産のBOMの問題
などだ。こうした点については、どこかでおいおい書いていきたい。

企業内のBOMとマテリアル・マスタの統合は、今日のサプライチェーン問題を解決する最重要課題である。そのためには、企業内に、BOMの登録とライフサイクルをつかさどる、クロス・ファンクショナルな機能が必要になる。BOMに関してだけは、どこからか『解決策』を買ってくることはできない。自分たちで解決するしかないのだ。拙著が、そのわずかな助けにでもなれば幸いである。

コミュニケーションの基盤としてのBOM=部品表_e0058447_23261197.jpg
by Tomoichi_Sato | 2008-01-23 23:20 | サプライチェーン | Comments(0)
<< ジャパン・パッシング--『日本... ベースラインとしてのNET COST >>