2009年09月07日 08時00分 UPDATE
特集/連載

統合化部品表への挑戦【第3回】製造業の基幹データベースへと進化を遂げた部品表

かつてMRPのデータベースに過ぎなかった部品表は、幾つかの新たな概念を導入することによって、部門間のコミュニケーションを担う新しい情報インフラ「統合化部品表」へと進化を遂げることとなった。

[四倉幹夫,クラステクノロジー]

統合化部品表とは

 前回「レガシーホストに塩漬けの『部品表』、その中身はどうなっている?」では、主に統合化部品表が誕生する前の「第1世代」の部品表について説明した。今回は、これが統合化部品表(統合BOM)へと進化を遂げた過程について解説する。

 そもそも、統合化部品表とは一体何か? 一言で言えば、従来のPDM/PLMをさらに進化させたソリューションである。従来の部品表に製番の概念を導入し、図面や各種ドキュメントなどの成果物を包含し、さらに生産設計に必要な工程手順、需給ルートや物流ルートの情報も統合する。その統合化されたデータを「製造のビュー」や「設計のビュー」というように、それぞれの部分最適の切り口でフィルタリングして共有する新しい部品表インフラの概念である(※)。

※ 1つの統合化部品表を「設計ビュー」や「製造ビュー」のようにビューでフィルタリングする方式は、株式会社クラステクノロジーの特許。

 部品表はこれにより、MRP(資材所要量計画)の手配のための情報から、部門間のコミュニケーションを担う新しい情報インフラとして変ぼうを遂げることとなり、グローバルレベルにおける情報の共有や設計変更の伝達を可能にしたのである。統合化部品表は、生産管理の基礎インフラであると同時に設計の中心データベースでもあるので、生産に必要なすべてのデータを包含しており、「製造のバイブル」とも呼ぶべき基幹データベースなのである。

単一データベースを複数の切り口で

 従来の生産システムは、図1のように部門縦割りであった。そのために、設計と試作、試作と購買、設計と生産との間には共有のデータベースがなく、設計変更などの情報が他部門になかなか正確に伝わらなかった。その結果、それぞれの部門の仕事をつなぐために多大なオーバーヘッドが掛かっていた。

画像 図1 従来の生産システムからの脱却

 そこで考え出されたのが、全体最適(統合化部品表)から部分最適(各サブシステム)を派生させて、全体を統合化することによりスループットを向上させて全社のリードタイムを短縮できるのではないかという発想だった。

 そのためには、下図のように、単純に同じデータベースを販売、設計、購買、製造の各部門間で共有すればいいという発想になる(図2)。

画像 図2 各部門間で同じデータベースを共有

 しかし、この方法ではうまくいかなかったのである。その理由は、販売部門からこのデータベースを単純に利用すると不要な情報が山ほど多く出てきたり、設計部門から見ると煩雑すぎて使えなかったり、購買部門から見ると自分たちには関係のない情報ばかりでとてもメンテナンスできない、といった事態が発生したからである。

 そこで考え出されたのが、ビューとフィルターを通してデータをフィルタリングすることによって、各部門専用のデータベースとして使えるようにする方法だ。販売部門から見るときには販売用のビューとフィルターを通して販売専用のデータベースとして、設計部門が使うときには設計用のフィルターを通して設計専用データベースとして、購買部門から使うときには購買用のビューでフィルタリングすることによって購買専用のデータベースとして利用できるようにするのである。

 このように、同じデータベース(統合化部品表)の情報を、複数のビューを切ることによってさまざまな角度から利用する方法が考案された。技術的には、1990年代中盤にOracle Databaseがバージョン7.3にバージョンアップし、ビューの更新が可能になってから実用化された技術であった。

部品表に時間と空間の概念を導入

 統合化部品表は、従来の情報インフラをどう変化させたのか? 簡単に説明すると、従来の部品表データベースに「時間」と「空間」の概念を付加することによって実現した新しいインフラだといえる。

時間軸に沿ってデータを管理

 これまでは、部品表というものは現在=最新のものが1つあるだけで、過去の部品表も未来の部品表も管理されていなかったのである。

画像 図3 時間と空間の概念を取り入れた統合化部品表

 また、オープン化の時代(1990年代)が始まるまでは、図面やドキュメントのデータを部品表の中に内包することは不可能であったが、WindowsエクスプローラーのようなGUIが発達したことによって、部品表と成果物(図面、ドキュメント)は一体化した情報として管理できるようになった。こうしたことを背景にして、PDMやPLMといわれるソリューションが発達したのである。

 さらに、統合化部品表はPDM/PLMからもう一歩進んで、これらの情報を時間軸に沿って管理できるようにした(図4)。

画像 図4 データの時系列管理

 上図のように、統合化部品表ではすべての部品、工程、成果物はそれぞれStart/Endの時間軸を持って管理されている。上図の例では、2月15日に部品A、B、C、Dの構成で作られていた製品αは、4月30日になると途中で設計変更が入ったためA、B'、C、Dという構成に変化している。

 このように、時間軸に沿って部品表を管理することが可能になったため、例えば3年前に販売した製品のネジの購入先を割り出したり、1カ月先に生産開始予定の部品表をプレリリースしたり、3版前の図面と現在の図面を比較したりできるようになったのである。これが「時間軸の在庫管理」である。

データのフィルタリングによる空間軸の管理

 片や、空間軸の管理とはどのようなものかというと、同じ製品データでも立場によって見え方が変わるようにするということである。図3を例に取れば、設計のビューから製品イを展開すると、イの下にロとハと図面があり、ハの下にニとホと設変通知がある。同じものを購買の立場から見ると、イの下にロとニとホがあり、ハはない。ハはライン上で組み付けてできる品目なので、購入する必要がないのである。また、購買ビューでは設変通知(設計変更通知)の代わりに発注書が添付されている。

 このビューによる自由自在なデータのフィルタリングを、さまざまな部門や拠点ごとに使い分けることによって、統合化部品表は空間の共有を実現する。これはそのままインターネットを経由して情報共有するインフラとなって、コンカレント・エンジニアリングを実現するのである。

画像 図5 統合化部品表がもたらす効果

 統合化部品表が扱うデータはさまざまである。基本的には、生産に必要なすべての情報を扱うことを目的としているので、部品のほかにも成果物、工程、需給ルート、物流ルートショップ、生産資源などさまざまな種類のデータを含んでいる。生産に必要な情報をすべて包含した新しい情報インフラだといえよう。

 統合化部品表は、ビューによるフィルタリングのほかに、条件フラグによるフィルタリングの機能も持っており、さまざまな分野に応用されている。簡単な例を挙げて説明しよう。

 図6のように、同じ製品を日本と北米と欧州の工場で分散して作る場合、すべての工場が同じ部品を使用するのであれば問題ないのだが、たとえネジ1本でも現地調達品が存在するとどうなるか。本来の部品表のルールでは、下位の品目が変更または追加されると、それに従って上位の品目番号(親の品目番号のすべて)も変更せざるを得なくなるのだ。すなわち、製品としての完成品はまったく同じであるにもかかわらず、品目番号が勝手に増殖してしまうことになる。

画像 図6 条件フラグによるフィルタリングの例

 この問題に対応するために、統合化部品表は条件フラグというものを各品目で持っている。上図の例でいえば、国内工場のビューや北米工場のビューなどからその条件を参照することによって、それぞれの現地調達品を拠点別に自動的にフィルタリングし、その上位品目番号を変えないということが可能になるのである。

 さらにこれを応用すれば、多国籍原価を即時に計算できるようになる。すなわち、製品Aを国内で作ったときの値段と北米で作ったときの値段、さらに欧州で作ったときの値段を瞬時に計算できるのである。もちろん、統合化部品表は普通の原価も瞬時に計算でき、時間軸に沿って過去から現在、未来へと原価の推移を保持しているので、リアルタイム原価や未来原価のような、今まで算出不可能だった原価も算出できるようになるのである。

 また、成果物としてソフトウェアのソースコード、実行モジュール、テストデータ、設計ドキュメント、プログラム仕様書などといったソフトウェアリソースも管理できるので、ハードウェアとそれに組み込まれるソフトウェアを同時に統合化部品表の中で管理することもできる。

製番の概念を導入

 これまでは一般的に、MRPシステムと製番システムの混在は不可能だと思われていた。MRPベースのERPに製番の機能をアドオンしたパッケージ製品もあるが、実際にはあまりうまくいかないか、不完全で変則的な形での仕組みにとどまるようだ。

 その真の原因は、実は部品表にある。部品表がMRPのデータと製番のデータをハイブリッドに保持できないと、その下にぶら下がる生産管理システムでも見込み生産と個別受注生産を混在させたハイブリッド生産は実現できないのだ。このことは、実はあまり知られていない盲点である。では、ハイブリッド生産における部品表とはどのようなものなのか。以降で説明してみよう。

画像 図7 標準生産(見込み生産)における部品表

 上図は、MRPで運用される場合の部品表の一例である。左側が部品表のツリー図、右側が品目マスターと構成マスターで表現したものである(図7)。通常のMRPによる見込み生産は、このような部品表を用いて運用される。

 ではこれと同じものを、製番ひも付きの製番生産(個別受注生産)する場合の部品表はどのようなものになるだろうか。仮にα社から注文を受けた製番をα001として部品表を作ると、下図のようになる(図8)。

画像 図8 製番生産(個別受注生産)における部品表

 α001の製番の付いた車軸やタイヤなどの部品は、在庫もα001のひも付きで個別に管理され、ほかの製品に転用できないようになっている。

 統合化部品表では、図7と図8の部品表を別々のデータ、別々の部品表として同じデータベースの中に混在させることができる。これは、従来の部品表ではできなかったことだ。

 では、これらの部品表のモデルを使って、標準生産(見込生産)で仕込んでおいたユニット(半製品)をユーザーのオーダー(注文)に基づいてカスタマイズすると、部品表がどのように変化するかを見てみよう(図9)。

画像 図9 見込み生産ユニットの部品表を製番にひも付け

 上図の左側の部品表は、標準的なユニット(半製品)をMRPで見込み生産して仕込んでおいたことを表している。このユニットの在庫が4個あったとして、顧客から受注した内容に基づき、そのうち1個を製番α001に割り当てたとしよう。この段階で、汎用的に使える在庫は3個となる。また、α001にひも付けした在庫1個はα001専用になり、ほかの製品に転用されることはない。最後に、α001にひも付けした部品を個別にカスタマイズして、顧客の要求仕様に合わせるのである。

 統合化部品表であればこのとき、それぞれの部品表はデータとして完全に分離される。従来の部品表では、製番にひも付いた部品表とひも付けなしの部品表を同一のデータベース上で混在させることはできなかったが、統合化部品表ではこれが可能となっている。すなわち、1つの統合化部品表でハイブリッド生産に対応することができるのである。

 今回説明した統合化部品表の特徴は、本連載の第1回「製造業のバイブル『部品表(BOM)』の復権」で説明した部品表発達史の中の第2世代、すなわち統合化部品表が初めて誕生した際に盛り込まれた仕様である。

 次回以降では、統合化部品表のさらに発達した機能について解説したい。

<筆者紹介>

四倉幹夫

株式会社クラステクノロジー 代表取締役

1996年に生産管理システムソリューション会社、株式会社クラステクノロジーを設立。外国製品が大半を占める生産管理ソフトウェア分野において、国内製品として功績を挙げたことが評価され、2002年に創業・ベンチャー国民フォーラム企業家部門において経済産業大臣賞を受賞、2005年春の褒章では藍綬褒章を受章。著書に『エンジニアリング・チェーン・マネジメント』(翔泳社)、『グローバル生産のための統合化部品表のすべて』(日本能率協会マネジメントセンター)などがある。


関連ホワイトペーパー

運用管理 | データベース | PLM | 生産管理 | 製造業


この記事を読んだ人にお薦めのホワイトペーパー

この記事を読んだ人にお薦めの関連記事