目的別BOMは、私が1990年代終わり頃から提唱してきたものです。E-BOMやM-BOMに加えて、販売BOMや設計開発BOM、購買BOM、メンテナンスBOMなど目的別にBOMが必要で、それらを整備、連携する事で設計開発、生産のみならず販売、購買、メンテナンスの戦略が決まり、サプライチェーン全体が計画主導型のものづくりが出来るとしたものです。

今では当たり前な考え方ですが、当時はシステム開発導入の世界で大きな論争になっていました。システム導入の目的は、データ統合なのだからBOMはマスターデータであり、複数BOMがあるのはかえって統合を阻害する、E-BOMと M-BOMの連携なんて出来ないというのが目的別BOMの考え方を否定する大きな根拠でした。また、ERPを導入しているベンダーからは、 M-BOMを中心に考えれば良いのであって、特にE-BOMの整備は既にPDMがあるのだから無意味とまで言われました。

当時、私は、多くのERPの導入に携わり、またそのプロジェクトの多くの失敗を経験してきました。ベンダーやコンサルには様々なシステム導入の方法論があり、その通りやっても何故失敗するのか考えてきました。様々な理由があるものの最大の問題は、マスターデータの整備をしないままにシステム開発やカスタマイズを行い、実物と合わず全く意味のないものを作っている実態を見てきました。 ものづくりをサポートするシステムなのにも関わらず、もの実物やその構成には目を向けず生産性向上を掛け声として業務プロセスをひたすらシステムに転写するという作業を行っていました。また、設計段階でも無理にERPを活用しようとして、仮BOMなるものをシステム上に設定してめちゃくちゃな運用で失敗しているケースもありました。

どうしたら「もの」の情報をシステムで管理できるのか？特に実物になる前の設計開発段階のエンジニアリング情報をコントロールする事ができるのか？研究を重ねて、目的に合わせて、全く管理単位の違う販売、購買、メンテナンス段階を合わせてコントロールできる目的別BOMとその統合を編み出しました。その為にそれらを導入するBOMやマスター情報、PLM領域を専門に実装するネクステック株式会社を創設し上場までこぎつけました。概念を提唱するだけでは駄目で、多くの実装とその為のパッケージ開発まで行ってきました。

今では当たり前のPLMの手法である目的別BOMは、当初、多くの批判や実装できるのかという疑念をもたれながら始められました。

今後は、生成系AIの普及でマスターデータやBOMそのものが必要ならなるかも知れません。SQLは、LLMやRAGに置き換えられるかも知れません。もちろん品質やコストなど過去のデータを構造的に蓄積しておく事は必要であるものの、固定的にデータを蓄積したものだけで設計開発をするよりも、世の中にある全件データを加味して設定開発した方が有利だと考えるからです。

今、日本のものづくりでは、エンジニアリング領域における生成系AIの活用が遅れています。議事録や品質検査、生産性向上などのサブプロセスでは活用が進んできましたが、ものづくりに付加価値を与えるエンジニアリング上では、全く進んでいません。設計開発者の人手不足、後継者不足で技術継承が叫ばれる中、その活用は急務です。もちろん、知財の徹底した管理や保護は最も重要です。だから政治の世界では、知財の徹底した保護を目指してます。

20年も前に業界と闘っていた事を懐かしく想っている余裕は、今の日本のものづくりには無いのか思います。今の私に何ができるのか？改めて考えながら前に進んでいきたいと考えています。

山田太郎

関連動画