納期半減の生産清流化

業務と組織の変革で、しなやかな企業体質を創ります。

トップページ

アルビスについて

業務一流化

組織自律化

情報清流化

見積清流化

資料室

リンク

お問合わせ

製造企業のデリバリー管理とSCM
第2章 サプライチェーンマネジメントの実践
2.4 SCM展開上の問題と対策
 (5)開発の問題

問題1:着荷不良
 製品を顧客に納入したときに、初期不良が発見されることがあります。これを着荷不良と呼ぶことが多いようです。これ自体顧客にとって大問題です。さらに、サプライチェーン上の在庫にも影響を与えます。こうした着荷不良が頻発すると、営業部門は代替製品を確保するために、製品在庫を多めに持とうとします。

 また不良品は、手直しすれば良品として再生できることが多いでしょう。しかしながら手直しは意外に時間がかかるために、手直し中の停滞が長くなります。さらに手直しよりも新規製造が優先されると、さらに不良品の停滞が長くなります。

 新規製造する製品ののために調達した部品を、不良品の手直しに流用することも発生します。この場合には新規製造する製品が部品不足で停滞することになります。

対策1:設計・試作の評価
 着荷不良を減らすには、量産工場での検査や品質保証体制を強化することが必要です。しかし、不良が頻発する場合には、その原因は設計にある場合が殆どです。不良防止を設計段階から織り込むことが原則でしょう。しかしそれは一朝一夕にはできません。設計品質を向上させる第一歩は、設計レビューや試作の評価を充実させることです。量産に移行できる品質レベルを規定し、それを遵守することが基本です。1枚の設計図の問題が、量産に持ちこまれると、作った数に比例した問題が発生します。派生する問題を含めると、指数的に問題が拡大することを、よく認識すべきです。

問題2:部品の共通性
 部品や材料の共通性が低いとSCM展開の阻害要因となります。共通性が低いと部品自体の在庫も多くなるだけではありません。部品の欠品の可能性が高くなるために、途中まで製造した製品が、部品待ちのために仕掛状態で停滞する要因になります。さらに、予定通りに製品が完成しないと、見込み生産の場合には製品の欠品やそれを防止するための製品在庫増加につながります。

 部品を見込みで調達しておいて、確定受注に基づいて組みたてるBTOの生産方式を実施しようとした場合、部品の共通性が低いことが致命傷となります。見込みで調達する場合、共通性が低いと部品自体の在庫増加、欠品の発生率もますます高くなります。

対策2:共通化設計
 部品の共通化は設計段階で決まります。共通化設計が対策です。しかしこれも簡単には進まないでしょう。共通化の掛け声だけでは進みません。共通化の度合いを示す評価指標を定め、その指標に関する目標値を設計部門の方針として掲げることが必要です。実績を把握してフォローも必要なことは言うまでもありません。

 さらに設計者のインセンティブプログラムに共通化の度合いを連動させることが有効でしょう。設計の現場で、実際に共通化した設計図を書くためには、設計者全員がアクセスできる図面データベース、部品データベースが必要となるでしょう。部品データベースには、過去に登録された部品番号だけでなく、現在の使用量・単価・類似部品の情報などを盛り込むべきでしょう。

問題3:新製品の開発納期
 競合他社から次々と新製品が発売される現代において、新製品の開発納期が守れないと、見込んだ売上が上げられなくなります。当然、製品は売れ残ってしまいます。それだけでなく、新製品のために準備した部品や宣伝材料なども停滞してしまいます。

 開発納期は重要です。しかし逆にこれを重視するあまり、不出来な製品を発売すると、着荷不良が頻発します。これも冒頭のように別の問題を引き起こします。品質はクリヤできても、原価が高くて儲からないというケースもあるでしょう。

対策3:設計部門の5S
 生産部門と同様に、設計部門もリードタイムの大部分は、停滞時間です。設計部門で停滞するのは情報です。最終的には、設計部門においても停滞が少なくなるような業務プロセスにし、各プロセスの標準時間に基づいたコントロールが必要です。

 その第一歩は、設計部門においても5Sでしょう。書類や図面がなぜ停滞しているかを5Sを通じて明らかにしていくことが対策です。( 1.4(4)参照

問題4:ソフトウエア
 電気機械だけでなく、製品にマイコンやそのソフトウエアが組み込まれる製品が増えています。素材の製造業でも製品製造プロセスの制御にソフトウエアが使われています。ソフトウエアの比重が増すにつれて、着荷不良や新製品の開発納期遅れの原因となる比率も増えています。ソフトウエア開発の世界では、機械設計や電気設計ほど設計ドキュメントの書き方が標準化されていません。設計のどの段階で停滞しているかが、いっそう判りにくい場合が多いようです。

対策4:ソフト開発ドキュメントの標準化
 ソフトウエアの開発においても、「設計・試作の評価」、「共通化設計」、「5S」などが、対策となります。設計ドキュメントを標準化して、「何を評価するのか」「どれを共通化するのか」「どこで停滞しているか」を、関係者が共通に認識できることが、その基盤となるでしょう。

<前のページ      目次      次のページ>

トップページ

アルビスについて

業務一流化

組織自律化

情報清流化

見積清流化

資料室

リンク

お問合わせ

Copyright(C) 2004-2017 ALBS All Rights Reserved.  アルビス 神奈川県相模原市中央区矢部1-23-18 代表:若槻直