2025/8/20

5.E-BOM構築で陥りがちな罠とは？

このコラムでは、何度も口酸っぱく言い続けていますが、まずその変革の「目的」を具体化し、会社内で整合することから始めましょう。
そのためには、Before→Afterをシンプルに示すことがポイントと思います。

よくあるのが、現状をしっかりと分析もせずに、
　・Before ： E-BOMが無い
　・After ： E-BOMで仕事をする
のような、何がE-BOM導入の目的かハッキリしない中で改革を進めることです。

今、PLM/BOMプロジェクトを推進中の方、もう一度自分たちの現状を分析してみてください。
本当に上記のような曖昧な目的で変革プロジェクトを進めていませんか？
BOM関係のプロジェクトは、手段先行で目的がおざなりになっている事が本当に多いのが実態ですので、注意・再点検をお勧めします。

陥りがちな罠１：目的を曖昧にE-BOM構築に着手してしまう

さて、前回、その典型的な目的と、それに伴って管理すべき情報について書きましたが、その目的は様々です。
更には、業界別、あるいはプロセス別や、現状の管理方式別に、ケースバイケースというのが実態です。
今回は少し踏み込んで、ある機械メーカー様での事例を元に考えていくことにしましょう。

このお客様は、製造装置機械メーカー様で、機種シリーズはあるものの、オーダーに対してオーダーメイド部分を個別設計し、製造・出荷するモデルを採用していました。
現状、モジュラーデザインを進めていることもあり、設計部門内にPLMシステムの刷新検討プロジェクトが立ち上がっていましたが、何をどう変えれば良いか、変えていくべきかは、社内でまとまらず、苦労されていました。
お客さまがまずコンタクトを取ったのは、PLMパッケージベンダーです。
パッケージベンダーは、お客様の現状を一通りサッと聞いた上で、「弊社のソリューションを使えば、こんな事ができるようになります」と、夢のような提案をしてきました。
お客様にとってみれば、社内で合意をとるにも、「そんな事ができるようになるのであれば、ぜひそのソリューション（PLMパッケージ）を導入したい、と話がトントン拍子に進んでいきました。
約1年後、そのソリューションのシステムインテグレーションを終え、リリースしたシステムは、現状の仕事のやり方を、そのPLMパッケージに置き換えただけの何の発展もないシステムとなってしまいました。もちろん、E-BOMも何か変わった訳ではなく、そのままです。
PLMパッケージベンダー曰く「もう少し、お客様の中でモジュラーデザインの設計が進み、標準化されれば、当初提案した内容は実現できたんですけどね。これからですね。」と、それならそうと早く言ってよ、といったコメントを残すのみでした。

この場合、何が悪かったのでしょうか？

これは、典型的な失敗事例なのですが、Before/Afterの構造が、
　・Before：　PLMソリューションを導入していない
　・After：　PLMソリューションを導入する
という自社の業界特性、プロセス特性、現状での管理方式特性を無視した構造となっていたのが原因です。
PLMパッケージベンダーは、そのお客様の現状をサッと聞いただけで、自社のソリューションテンプレートに当てはめて提案することが通常です。ソリューションテンプレートは、業界別だとか、プロセス特性別だ、とか提案書上は綺麗なスライドと共に説明を受けますが、本当に自社の現状に合っているか、確認できていなかったことが敗因です。

陥りがちな罠２：自社の業務課題とその原因分析をせずにPLMソリューションに頼ってしまう

この事例は、目的を曖昧にしているだけでなく、自社の業務課題とその原因分析を行うことを怠っていました。
なぜ、それが敗因なのでしょうか？
E-BOM構築とは言え、そのE-BOMは図面と共に出図され、生産側に渡ります。
上記事例メーカーの場合、オーダーメイドも受け付けるビジネスモデルですが、通常は受注前の先行手配を行なっている事が通常です。そうなると、その先行手配している部品やユニットを長期在庫として抱えないために、E -BOMは、営業の商談情報とも連携していくべき、と話が膨らんでくることが通常です。
参照：PLMコラム　3.「PLM」は、もはや部門システムではない

その場合、自社の業務課題とその原因分析を行っておけば、「どのような問題点を解決するために、どういうことが原因になっていて、その原因に対する解決策としてE-BOMを導入するんだ」という部門間での認識共有を図る事ができるようになります。
上記機械メーカーの事例では、運良く（？）1年後にはシステムリリースできたようですが、この認識共有が曖昧だと、最悪、システム構築の仕様検討段階でプロジェクトが止まってしまうケースになってしまっている事例も存在します。

陥りがちな罠３：他部門や、自社内で動いている他プロジェクトとの整合無し（あるいは整合不足）でE-BOMプロジェクトを進めてしまう

例えば、「在庫削減プロジェクト」や、「納期短縮プロジェクト」と言った改革プロジェクトが自社内で並行して進められている事が通常です。
しかし、そのプロジェクトは「生産側のプロジェクト」であるため、プロジェクト同士の会話が無かったり、初期段階で1回話をした後は全くコミュニケーションできていなかったりするケースがあります。
これまでのコラムでも解説している通り、E-BOMを中心としてエンジニアリングチェーンで生まれ、成長する技術情報は、やがてサプライチェーン側で消費されます。
つまり、消費者としてのサプライチェーンからの要求を無視してしまうと、後々データが繋がらない、という失敗を起こしてしまうリスクがあります。
よくあるケースとしては、E-BOMには、マスターBOMと、オーダーBOMをもつとして、マスターBOMがサプライチェーン上有効活用できない、といった問題です。

このように、陥りがちな罠は、PLMソリューション側にあるのではなく、自社での検討の進め方や体制の組み方等にある事がわかります。

BOM周りの改革経験に乏しい場合、あるいは過去に失敗してしまった場合、後者で、自分は経験しているので成功や失敗のポイントをわかっているが、社内の横や縦の周囲に、効率的にその展開・認識共有をしていきたい際などには、是非PLMコンサルタントの活用を考えていただけると幸いです。