1. はじめに

 

　「ニーズの多様化」のもとに、あらゆる製品において、少品種大量生産から多品種少量生産および個別の仕様への対応が求められるようになった。

　従来の共通設計、需要予測に基づく大量生産、大量販売のサイクルは、一度製品がヒットすれば生産能力がシェア獲得と利益の源泉であった。

　しかし現在では、「カスタマイズ」の名目のもと、顧客の要望や要求される仕様に基づき、基本的な製品設計はありながらも、多種多様な製品バリエーションが展開されることも珍しくなくなった。

　このような時代においては、個別の仕様に都度対応していると、リードタイムやコストの面で不利となり、顧客満足と利益確保の両方を満たすのが難しくなっている。

　本稿では、多くの製造業で直面している、この多品種少量生産化の流れにどのように対応してゆけばよいのかを、情報システムの観点で説明する。

 

 

 

2. CADで作成する設計データ

 

　多くの製品において、すでに設計業務のデジタル化は進んでいるのではないであろうか。

　一般的にはCAD（Computer-Aided Design）システムを使用し、設計データはPLM（Product Lifecycle Management）にてバージョン管理や保守用の文書を管理する。

　同時にE-BOM（Engineering Bill of Material : 設計部品表）が管理される。しかし、製造業のプロセスは、当然ここで終わりではない。

　設計データと需要予測に基づいた生産計画をもとに、部品の調達を行い、生産が開始される。

　調達および生産プロセスでは、部品をM-BOM（Manufacturing Bill of Material : 製造部品表）をもとに部品を管理する。単一仕様の大量生産であれば、E-BOMにおける設計用の部品管理と、M-BOMにおける調達、生産用の部品管理が異なっていても大きな問題はなった。

　例えば、設計時はスペックによって部品Aと管理されているが、調達時は調達先X社からのA-1とY社からのA-2の二つの部品で管理されているかもしない。

　つまり、E-BOMとM-BOMは同期している必要は必ずしもなかったのである。

　しかし、個別設計による受注型設計生産になると、これは問題になる。

　例えば、これまでの標準設計で使用していた部品Aが、個別の要求仕様によってA-aという仕様の部品になったとすると、調達や生産もA-aという部品が管理されなければならない。

　さらに生産開始前までにさらなる設計変更が行われるということも頻繁に起こる。

　その結果、すべての設計が完了するまで、どのようなスペックの部品をいくつ調達しなければいけないのかが確定できず、生産のリードタイムが長くなるとともに、小ロットの調達となりがちで、単価も上がり、十分な利益が確保できなくなる可能性もある。

　このように、受注型の設計生産においては、これまでの大量生産型のプロセスの延長線上で行っていると、顧客の要求に応えるために時間がかかるとともに、利益を圧迫する可能性があるのである。

　これらの課題を解決するには、いくつかのアプローチがある。ここでは、大きく2つの方法をご紹介する。

 

① フロントローディングと標準化

　大量生産における設計プロセスにおいても、開発期間の短縮や原価を低減させることを目的にしたアプローチとして取り組まれてきたのがフロントローディングである。

　これは、設計工程の初期の工程において、これまで後工程で行われた作業も取り込み、より多くの作業を行うことによって、後工程の負荷を低減し、設計プロセス全体の期間の短縮や、結果としてコストの削減を目指す。

　「製品の品質とコストの8割は、設計段階で決まる」という言葉があるように、初期工程は製造業にとっての生命線ともなりうる。

　このフロントローディングを実現するためには、PLMの活用と標準化が求められる。

　もともと設計情報は、PDM（Product Data Management）と呼ばれるシステムで管理されていた。

　しかし、ここでは主に設計データおよびE-BOMが管理され、後工程に必要なデータを管理することができないため、後工程の作業を初期工程で行うことができないのである。

　そのため、設計のあとのプロセスである調達、生産から保守サービスに至る製品ライフサイクル全般に関する情報を一元的に管理するPLMを活用することが求められる。

　次に標準化である。

　これは、大量生産から少量多品種生産に移行する際にも非常に重要なポイントになる。

　大量生産の設計の仕組みのまま、個別の仕様に対応しようとすると、ほとんどの製品が標準品ではなくなる。

　そのため、E-BOMだけではなく、調達や生産に使用されるM-BOMのデータもすべてが個別のものとなり、「マスタ」としての機能が失われる。

　そのため、設計から生産に至るすべてのデータが再利用できず、毎回新しい製品を開発するのと同じ状況に陥ってしまう。

　設計効率が低下するだけでなく、部品の調達コストも上昇し、かつ最終製品の原価把握も困難になる。

　その結果として、なんとか顧客の要求に応えて生産まで対応したとしても、十分な利益が確保できず、会社全体が疲弊してゆくことにもつながりかねない。それを防ぐためには、ある程度の仕様の幅をあらかじめ「標準」のオプションとして準備し、標準品の一部として対応することで大きなメリットが生まれるのである。

 

② PLMとERPの連携

システムの観点で見ると、一般的にはE-BOMがPLMにて管理されるのに対し、後工程の調達や生産に必要なM-BOMはERP（Enterprise Resource Planning : 統合基幹業務システム）で管理され、調達における発注業務、支払管理、在庫管理などから会計情報を作成し、企業の資産や資金を統合されるシステム内で管理される。

　先に述べた通り、個別受注生産に効率よく対応するためには、E-BOMとM-BOMの連携が不可欠になる。

　しかしながら、多くの企業ではそれぞれを管理するPLMとERPの2つのシステムが分断され、その間の情報連携はアナログな方法で行われていることも珍しくない。

　この連携をシステム的に行うとともに、製品のライフサイクル全体にわたるデータの整合性を保つことにより、大量生産から個別受注生産のような生産形態に移行しても、適切なリードタイムと利益の確保が可能になるのである。

 

図1 設計・生産プロセス連携発展のステージ

 

 

 

3. 設計・生産プロセス連携発展のステージ

 

　しかし、E-BOMとM-BOMの連携は、実際にはそこまで単純ではない。なぜなら、同じ部品表であっても、その目的や構造が異なるからである。

　その違いの典型的なパターンを見てみよう。

 

① 図番コードと品目コードの違い

　E-BOMにおける図番コードと、M-BOMにおける品目コードは、その目的の違いから定義や粒度などが異なる場合がある。

　もともと、機種や形状などによって定義を行っているものの、E-BOMとM-BOMでコード体系が異なる場合や、特に定義や意味づけを行わず、連番などで管理している場合など様々である。

 

② 管理している属性情報の違い

　E-BOMで管理している属性は、生産や組み立てに必要なスペック情報が中心であるが、M-BOMでは調達や会計情報に必要な情報が付加されている。

　たとえば、在庫数に応じてどのように会計に計上するべきかを判別するために、製品、半製品、原材料などの分類情報などが必要になる。

 

③ 構成情報の違い

　たとえば、複数の部品を組み合わせる工程を経て、そのユニット部品を使用する場合などは、E-BOMではユニット部品を明示的に管理する必要はないが、M-BOMではそれを工程品として認識する必要があり、もとの部品は同じでもユニット部品の有無によって構成情報が異なる。

 

④ 購入品の扱いの違い

　複数の部品が組み合わさったユニット部品を外部調達する場合、E-BOMでは設計上は構成している個別の部品を認識する必要があるが、M-BOMでは調達や在庫管理が購入するトランザクションの単位となるので、その構成部品の管理は必要なく、省略される。

 

⑤ 設計変更時の管理の違い

　製品情報を親子の階層構造で管理している場合、その子要素である構成要素に変更があり、バージョンが変わると、E-BOMにおいてはその親である製品管理上バージョンが変わるとみなされる。

　設計上はすべての構成要素を含めて一つのバージョンとみなすからである。これに対　し、M-BOMでは、変更のあった子要素のバージョンを変更する場合がある。

　会計上の部品管理においては、変更のあった要素の管理で十分な場合がある。

 

　以上のように、いくつかの違いを例として挙げたが、これ以外にも製品の特性などにより、多くの違いがある。

　E-BOMとM-BOMの連携は、受注型設計製造を円滑に行うためには重要な要素であるが、その目的や設計思想が異なることも多く、単純にデータを連携できない場合も多いのである。

 

 

 

4. 連携を実現する方法

 

　では、実際にE-BOMを管理しているPLMと、M-BOMを管理しているERPの2つのシステムを連携するには、どのような対応が必要になるのであろうか。それには、3つの要素がある。

 

図2 PLM×ERP連携の流れと注意すべきポイント

 

 

 

① データ構造の整備

　E-BOMとM-BOMでは、管理している属性情報や階層構造が異なる場合がある。

　お互いが必要とする情報を保有していないケースである。

　この場合には、まず各部品のレコードに必要な属性情報を持てるようにするため、データベースのテーブルを拡張する必要がある。

　必要な列を定義し、テーブルを拡張する。

 

② データの変換

　それぞれが管理している部品のコード体系や階層構造が異なる場合、そのままデータを連携しても適切な管理ができない。

　そのため、中間にデータを変換するロジックを入れる必要がある。変換テーブルや参照するマスタを用意し、ロジックによって適切なデータ変換ができるようにする。

 

③システム的な連携

　基本的なデータの流れは、E-BOMのデータをM-BOMに反映させることであるので、PLMからERPに接続してデータを更新することが必要になる。

　その主要な方法として、ファイル転送とAPIコールの2つがある。ファイル転送はシンプルな方法で、PLMからデータをCSV形式などのファイルにエクスポートし、データ変換処理を行ったうえでERPにインポートする。

　汎用的な仕組みで保守性も高い方法であるが、リアルタイムな連携には向いていない。

　一方、APIコールは、ERPが用意しているAPI（外部アプリケーションから利用するためのインタフェース）を利用してデータを更新するアプリケーションを作成する。

　リアルタイム性の高い更新が可能であるが、APIの仕様変更などに集う対応する必要があり、運用負荷が高くなる。

　一般的にはE-BOMとM-BOMの連携にそこまでのリアルタイム性は求められないので、通常はファイル転送方式で十分であろう。

 

 

 

5. デジタルトランスフォーメーションはあらゆるところに

 

　多くの製造業において、少品種大量生産から、多品種少量生産への変化が求められている中、それに対応するためにはデジタルの活用は不可欠な要素である。

　そして、それを実現するためのアプローチをして、E-BOMを管理するPLMとM-BOMを管理するERPの連携についてご紹介した。

　デジタルトランスフォーメーション（DX）という言葉が飛び交う世の中であるが、それは決して特別で華々しいものではなく、デジタルを活用して業務プロセスをつなぎ、その結果、短納期、低コスト、高品質などの価値を顧客に提供することにほかならない。

　より柔軟で創造性が高く、そしてそれを実行できる製造業になるために、データの活用を起点にしたデジタルトランスフォーメーションに取り組んでみてはいかがだろうか。