前回「製造業の基幹データベースへと進化を遂げた部品表」では、レガシーホスト上に構築された原初の部品表が、時間軸や仕向地・生産地といった情報の新たな切り口を備えることにより、統合化部品表という新たな情報インフラとして生まれ変わった経緯を解説した。
現在の統合化部品表はそこからさらに発達し、製造業の統合情報インフラとなるべくさまざまな機能を備えている。今回はそれらを1つ1つ紹介していきたいと思う。
なお、今回紹介する機能は、統合化部品表の発展段階でいうと第3世代と第4世代で新たに導入されたものである。各世代の特徴については、本連載の第1回「製造業のバイブル『部品表(BOM)』の復権」を参照されたい。
エリヤフ・ゴールドラット(※1)は1991年の著書『The Haystack Syndrome』(邦題『ゴールドラット博士のコストに縛られるな!』)の中で、「BOMとRouting(工程データ、需給ルートデータ、物流ルートデータ)は、コンピュータの草創期にメモリやHDDなどの資源的な制約があって別々のデータベースとして発達し、現在でも分離されたままになっている。これはいずれ統合化されなければならない」と予言している。
※1 小説『The Goal』の著者で、TOC(Theory of Constraints:制約理論)の提唱者。
ゴールドラットが書いたように、部品表(BOM)と工程データは統合される必要がある。なぜなら、MRP(Material Requirements Planning:資材所要量計画)がMRP IからMRP IIへ進化するための条件であるCRP(Capacity Requirements Planning:能力所要量計画)を行うのに必要だからである。
もう少し詳しく説明しよう。MRP Iはオーダー(製造指示、発注指示、出庫指示などの具体的な生産活動を行う指示)を生成するのにリードタイムを使用する。リードタイムとは、発注リードタイム、製造リードタイムなどのように、部品や製品を発注してから納品されるまでの総時間のことである。MRP Iという生産管理システムは、あらかじめこのリードタイムを品目ごとに設定しておき、生産計画日を起点にしてオーダーを生成する仕組みなのである。
それに対してMRP IIというのは、そのオーダー生成の際にリードタイムだけでなく、さらに生産工程と生産能力も加味したものである。MRPで立案された計画オーダーをCRPで工程順に展開し、各工程の着手日と完了日の日程計算を行い、その結果を部門ごと(あるいはライン、ワークセンター、作業場所ごと)に積算して負荷積みをする。この計算を行う際に、工程手順や需給ルートなどの工程データが必要なのである。
さらに、各部門ごとに積んだ負荷のオーバー分を、実現可能な計画になるようスケジューラで一定の条件の下に山崩し(※2)し、再編成するのがAPS(Advanced Planning and Scheduling)である。ここでも、工程データは必須となる。
※2 各部門に割り当てられた作業負荷を、それぞれの負荷能力に合わせて平準化すること。
このような理由から、第3世代の統合化部品表には工程手順や需給ルートのデータが含まれるようになったのである。

統合化部品表のもう1つの特徴として、物流ルートの管理がある。物流ルートというのは、一種のサプライチェーンである。
例えば上図の物流ルートでは、製品が工場から出荷されてA埠頭の倉庫→コンテナ船→中国倉庫→顧客先という経路で製品が輸送されている。統合化部品表では、こうしたサプライチェーンの経路が管理できるようになっている。また、製品の保管時間も併せて管理しているので、時間当たりの保管料を保管時間と掛け合わせることによってサプライチェーンの原価を管理できるようになるのである。
このように、統合化部品表で物流情報を管理することによって、国内外の拠点に対する資材の供給や製品の輸送を一元的に管理し、社内の各部門間で共有できるようになるのである。ここに来て部品表は、MRPの手配のための情報から、部門間のコミュニケーションを担う新しい情報インフラへと完全に進化を遂げたのである。
なお、この物流ルートのようなデータモデルは従来の部品表では扱えなかった(データのパターンがまったく異なるため)のだが、次回説明する「多項モデル」という部品表を駆使することによってこうしたデータを完全に扱うことが可能となった。
ビジネス環境のグローバル化の進展に伴い、昨今のITソリューションはさまざまなグローバル機能を実装している。統合化部品表も例外ではなく、グローバルに運用されることを前提としているので、当然グローバル機能を実装している。これは、世代的には第4世代の統合化部品表で新たに導入された機能だ。
第一に、言語変換の機能が備わった。例えば、中国工場からログインしてシステムを利用するときには中国語、米国工場から利用するときには英語の文字コードとユーザーインタフェースが適用される機能だ。
また言語だけでなく、受注情報などの項目ではマルチカレンシー(多通貨)機能も必要になってくる。さらに製品によっては、世界各国の異なるタイムゾーンを扱うことができるようになっている。グローバルに事業展開している製造企業であれば、例えばフランスにある拠点で入力した設計変更の時刻と、日本で入力した設計変更の時刻を矛盾なく扱うことができなければ、設計データの整合性を保てなくなってしまう。統合化部品表では、GMT(グリニッジ標準時間)機能などを搭載することでこれに対応している。
統合化部品表の中には、設計部品表や購買部品表、製造部品表など数多くの部品表が内在しているが、原初の設計部品表がどのような経緯・手順でこれらの派生を生んでいくのか説明してみよう。
上図を見ていただきたい。単純な万年筆の図面である。図面には万年筆の寸法が記されており、各部品に「風船」と呼ばれる番号が付いている。さらに、それらを図面の右脇に部品表としてまとめている。この部品表を取り出してリストにすると、単層レベルの設計部品表になる。
次の図はもう少し複雑な組み立て図の例として、自動車の図面を挙げてみた。複数の図面で1つの製品を表しており、それが部品表上で階層構造を形成する原理を示している。
まず全体図が大本としてあり、その下に各部品の部品図がある。これら複数の図面を階層ごとにまとめると、図5の下半分にあるような複数階層を持った設計部品表が出来上がるのである。昨今のPLMやPDMシステムで扱っている設計部品表とは、このレベルの情報をCADシステムから生成した情報なのである。
ただし、このレベルのデータだけでは生産したり、購買したり、MRPのような生産計画を立案したりすることはできないので、この設計部品表のデータをそれぞれの用途で進化させなければならない。そのための器が統合化部品表であり、部品表を進化させるために用意されたさまざまなアプリケーション群を「設計製造連携」と呼んでいる。
では、設計部品表と製造部品表は何が異なるのだろうか? 設計部品表は図面とその図面に記載された風船に基づいた単層レベルの部品表があり、それを組み上げた設計部品表というものが設計部門の最終アウトプットとして出力される。従ってPLMシステムの最終ゴールは、CADシステムからこれらの設計部品表をアウトプットすることにある。これを製造部品表に変換するためには、ざっと概観しただけでも以下のような情報のアドオンや変換が必要となる。
これらの情報を、設計製造連携という一連のアプリケーション群を通すことにより、製造部品表を生成するのである。これらのデータは1つの部署ですべて入力・管理することもあるが、複数の部門がそれぞれの担当のデータを入力・管理するケースもある。
こうしたデータのアドオンや変更が、「設計部品表から購買部品表へ」「設計部品表から販売部品表へ」「設計部品表から保守部品表へ」などの各パターンに対応したアプリケーションを通じて変換/生成されていく仕組みになっているのである。その度に部品表はより具体的な生産のためのインフラとして、下流工程に向かって成長することになるのである。
「統合化部品表のデータのメンテナンスをどの部門が行うべきか」という質問をよく受けるが、統合化部品表はこのようにまずは小さく作って、その後いろいろな部門で大きく育てていくという側面を持っているのである。工務や生産技術といった部門ですべてのデータを主管できれば理想的かもしれないが、現実にはなかなかそうもいかないようである。そのため、さまざまな連携アプリケーション群を通すことにより統合化部品表は大きく育っていくのである。
1996年に生産管理システムソリューション会社、株式会社クラステクノロジーを設立。外国製品が大半を占める生産管理ソフトウェア分野において、国内製品として功績を挙げたことが評価され、2002年に創業・ベンチャー国民フォーラム企業家部門において経済産業大臣賞を受賞、2005年春の褒章では藍綬褒章を受章。著書に『エンジニアリング・チェーン・マネジメント』(翔泳社)、『グローバル生産のための統合化部品表のすべて』(日本能率協会マネジメントセンター)などがある。