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

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

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

　これまでは、部品表というものは現在＝最新のものが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世代、すなわち統合化部品表が初めて誕生した際に盛り込まれた仕様である。

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