【目次】
- 製品データ管理の導入 (その1) PDM/PLMの概要
- 製品データ管理の導入 (その2) 「リンク」で開発を変える
- 製品データ管理の導入 (その3) 部品データを活用した全体最適設計の仕組み
- 製品データ管理の導入 (その4) 部品データを活用した全体最適設計の仕組み
- 製品データ管理の導入 (その5) アセンブリ単位に CAD リンクで作る部品表
- 製品データ管理の導入 (その6) 生産工程標準化による製造性設計と原価の最適化
- 製品データ管理の導入 (その7) 顧客対応や業務効率化が業務の滞留を引き起こす
- 製品データ管理の導入 (その8) データ指向、IT要員育成が製品開発基盤構築のカギ
- 製品データ管理の導入 (その9) データ指向、IT要員育成が製品開発基盤構築のカギ
この連載では、PDM/PLM（以下、PDM：製品データ管理）の導入・運用をシステムベンダー主導ではなく、自社の設計・製造をデータで「リンク」することにより設計、製造、保守といった開発の全体最適を実現する仕組みを設計し、PDM を使って実装するためのポイントを解説しています。
前回の第5回に続き今回は、顧客要求への柔軟な対応や効率化のための作業改善が、結果的に開発業務の滞留を引き起こしてしまうことについて解説します。顧客要求や作業改善に個別に対応することで、業務に必要な管理台帳やマスターデータの種類が増えていくことが原因です。この問題を事前に仕組みとして解決しておかなければ PDM/PLM の導入は成功しません。
1．台帳が増え続けるで業務効率が低下
前回までに見てきたように、製品開発現場には部品や部品表、図面などに関係する様々なデータが存在していますが、多くの開発現場でそれらはマイクロソフトの Excel や Access、または紙で管理され「台帳」や「マスター」という単語を含む名前になっているはずです。
ここで自分の組織で IT 化要員を持たない場合、「台帳」や「マスター」の変化によって開発業務がどのように変わるのか、あるメーカーでの例を紹介したいと思います。
このメーカーは、これまでに使った部品すべての型式や購入価格などを Excel で作成した部品台帳に、また設計図面やその作成日、作成者などは図面管理台帳、そして製品の部品構成（部品表）を部品構成台帳にそれぞれ Excel ファイルとして記録し管理していました。この他にも、製品開発業務で必要となる共通データは台帳にして管理するなど、これらすべての管理台帳は Excel で作成していました。
Excel で作成したこれら台帳は、誰もが簡単に扱うことができ、検索などもできるので技術者全員が便利に使っていたのですが、開発している製品ラインナップが増えたことで、一つだった設計部署が3つに分かれ、さらに新しい顧客向けの製品の開発・製造を行う事業所が新設されるのと並行して部品コードや部品発注方法の見直しなどの業務改善活動を行う中で、次のようなことが起きました。
増えた設計部署がそれぞれで部品コード台帳を管理することになってしまった上に、部品コードの見直しによって旧部品コードと新部品コードが並行して使われることになったため、一つの Excel ファイルだった部品コード台帳から部品に関する多くの派生ファイルができました。たとえば、事業所ごとに使われている部品が分かるように作成した「事業所別部品台帳」や、旧部品コードで部品検索するための「旧部品コード台帳」、全社の部品を一つにまとめた「品目コード台帳」などが作られたのです。さらに、このようにして作られた派生の管理台帳は、それぞれ作成した人の好みで Excel や Access、 FileMaker だったりしたためファイル形式もバラバラでした。
部品コード台帳に限らず、部品構成表などの他の管理台帳も同じ状況でした。図1はこのようにして増えていった台帳を示しています。
図1. 業務拡大への対応で増えていく管理台帳
増えていく製品や新しい顧客への追従、業務の効率化、顧客要求やトラブルなどの対応など、それぞれの部署で必要に迫られて前向きに対応したことが、利用方法や管理方法が少しずつ違う同じような台帳を増やしてしまったのです。
2．増えた台帳が滞留を引き起こす
このような状況になっている開発現場は決して少なくないのですが、派生の台帳とはいえそれぞれの目的に沿って作ったものだから問題ないだろうというトップ・マネジメントも少なくはありません。モノの流れとは違い、データの流れは見えにくいことが原因かもしれませんが、派生の台帳が増えれば増えるほど、その派生台帳の使い方は手間が掛かるものになり、維持するためのメンテナンス作業も複雑化し開発業務の流れを妨げる原因となるのです。図2は、この開発現場で設計から生産開始までに関係している主な管理台帳とデータの流れを表したものなのですが、これを見ると派生台帳の存在が多くのデータのやり取りを生じさせ、さらにそのやり取りの多くが手作業になるために必然的に開発業務が滞ることになります。
例えば、ここの技術者が部品を特定するために部品型式が必要になったとします。
部品データが記載されているすべての管理台帳には部品型式が登録されており、さらに部品構成表（部品表）関連の台帳にも部品型式が登録されていますので、新規部品を採用した時や変更があった時は、すべての台帳に一字一句間違わないように部品型式を登録しなければなりません。部品型式だけでなく、部品名称や価格なども同じように複数の台帳に登録されていると、部品名称や価格が変わるたびにすべての台帳を漏れなく更新しなければなりません。
部品データが記載されているすべての管理台帳には部品型式が登録されており、さらに部品構成表（部品表）関連の台帳にも部品型式が登録されていますので、新規部品を採用した時や変更があった時は、すべての台帳に一字一句間違わないように部品型式を登録しなければなりません。部品型式だけでなく、部品名称や価格なども同じように複数の台帳に登録されていると、部品名称や価格が変わるたびにすべての台帳を漏れなく更新しなければなりません。
図2. 管理台帳間でのデータのやり取りが業務滞留を引き起こす
このように、台帳に記載されているデータを正しい状態にするのは派生の台帳が増えれば増えるほど大変な手間となり...
、開発作業の効率はどんどん低下してしまいます。入力ミスや入力漏れなどによる手戻りを引き起こすことになりますし、すべての台帳を正しい状態にできない場合は、参照した台帳によって部品型式が違う、価格が違うというようなことが起き、ご発注や想定していた原価に収まらず大きな手戻りとなってしまうのです。そもそも部品、部品表、図面に関するデータは相互に関連しているものなので、それらを管理している台帳が増えることで相互の関連がより複雑になり、データの利用や保守により手間が掛けてしまうことになるのは当然の成り行きです。
この開発現場のように、顧客要求への対応や作業の効率化、トラブル対応など個別に対処しているとその都度、派生台帳が増えることになり、全体で見るとその度に業務効率を下げてしまうことになります。現場で個別に対応している限り、このような状況になってしまうことを避けるのは困難です。
この開発現場のように、顧客要求への対応や作業の効率化、トラブル対応など個別に対処しているとその都度、派生台帳が増えることになり、全体で見るとその度に業務効率を下げてしまうことになります。現場で個別に対応している限り、このような状況になってしまうことを避けるのは困難です。
以上はあるメーカーでの事例ですが他人事だと思わず、ぜひ自社の開発現場にどのような管理台帳があるのかを調査してみることをお勧めします。思っている以上に多くの管理台帳が存在していることが分かるはずです。次回は、このような派生の台帳が増えて開発業務の滞留をもたらす原因を解消する仕組みについて解説します。