第144回 設計部門BOM改善コンサルの現場から～その73～設計変更（設変）のジョブフローを考える。「その1」～設変に対するジョブフローが整流されていない中小中堅製造業～

設計変更（設変）の流れを再度考え直してみましょう

そもそも、なぜ設変が必要か？
このことに対しては皆さんも論を俟（ま）たないと思いますので、深堀は避けますが、一言でいえば「製造業として、QCD維持・改善の根幹を成す大切なフィードバックサイクル」です。従って、設変なしには製造業が成り立たないと言っても過言ではないでしょう。

しかし、その割には設計成果物のアウトプットばかりに目を奪われて、設変という修正フィードバックがないがしろになっている場合を多く見受けるのです。

お預かりしている製造業で、私から「御社の設変ワークフローはどのようになっていますか？」という質問に対し、多くが「ISOの規定で、このようになっています」という回答。そして、そのワークフロー自体に疑義は生じません。

しかし、私が「本当にこのとおりに運用できでいますか？」と鼻眼鏡で見渡すと参加者全員下を向いて「沈黙」……
よくよく聞いてみると……
設計担当者と製造（購買）担当者とが口頭伝達＋図面（修正赤ペン入り）でやりとりしています。

私から「設計変更要求書（ECR：Engineering Change Request）や、設計変更通知書（ECN：Engineering Change Notice）というワークフローの起承転結の起と結となるドキュメントはありますか？ ISOにはあることになっていますが？」と問いただすと。

回答は「一応フォームはありますが、紙ですのでうまく伝達できませんから、担当者同士での口頭伝達やメール依頼で終わっています」

「しかしそれでは、設変要求がしっかり設計部門に伝わったのか？ そして、その要求がしっかり設計成果物に反映できたのか？ 確認のしようがありませんね」との質問に、

ためらいもなく「そうなんです！ 前回の不具合が再度起きたり、ディスコン部品が入手できず混乱したりしています」
という嘆きが聞こえて来ます。

「ISOで決めたのではないですか、なぜ、それを実行しないのですか？」などと言っても始まりません。
はっきり申し上げれば、実現が難しいワークフローを机上（紙上）で作り上げてしまった成れの果てなのです。そこのところの反省は持つべきだと思います。

DXとしてのICTによるワークフローを積極的に活用しよう

まずは設計変更要求書（ECR：Engineering Change Request）について考えてみましょう。
このECR発行が必要とされる場面を状況ごと部門ごとに、大まかにまとめてみます。

1. 設計責任としての不具合発生
特に新規設計時に多く発生します。新たな開発や新規ノウハウへのチャレンジなど、やってみなければ分からない不具合発生から、寸法、公差、剛性等々、いわゆる技量や経験不足に関わる不具合まで、その原因は多岐にわたりますが、設計責任による設変ですので「設計部門が自ら発行する」ことになります。

2. 下流側（生産部門、品質管理部門）からのQCD改善提案
前項で述べた試作開発設計品の生産工程で「生産部門目線」での不具合対策要求。案外貴重な提案が存在します。流用化・標準化された製品であってもQCD改善に寄与する提案は常に改善を行っていくための、大変大切なフィードバック情報です。「生産部門・品質管理部門からの発行」が主体です。

3. 購買部門からのディスコン（生産中止）部品、納期・コスト異常部品の置換要求
今年の中盤まで部品異常納期部品やディスコン部品が継続していました。それ故、購買部門から悲鳴にも似た「何とか使える部品に置換してほしい」との要求からECRが乱発されました。しかし、この場合、ここでもう一度、立ち止まって考えてもらいたいことは、「ECRなのか代替品管理なのか？」という場合分けです。ここのルールをしっかり決めておきたいものです。

順番としては代替品管理が優先策です。まずは、生産管理システムに登録されている代替品への切り替えを行います。代替登録品さえも入手困難の場合、初めてECRの発行となります。これによって異なる品目コードの部品が置換されることになります。

従って、BOM上では親品目コードの変更などの影響が出てきますので、慎重な対応が必要なのです。近々に代替品管理については述べてみたいと思っていますが、コロナ禍以降の不安定な部品調達環境に耐えうる、一手法として代替品管理は不可欠です。そのため、これらは「購買部門」からの発行が主体です。

多くは以上の状況分けによって、ECR発行の部門分掌が明確になると思います。
ECRのフォームの項目については、各社の事情に合わせて必要な情報を網羅できるように作成してください。

加えて、以下に必須なワークフローとしての考え方を述べてみます。

まず、ECRをどのように設計部門にその存在を認識させるか？ でしょう。
口頭伝達や紙回議、メールでは「放置プレー」必至です。やはりDXが叫ばれる中、ICTによる承認付きワークフローに乗せてペーパーレスでいきたいものです。

流れの概念は以下のとおりです。

以上が設変フィードバックのワークフロー概念ですが、

これらの条件を満足させるには、何らかのICTによる仕組みが必須です。

少なくとも「ECRをもらったの、もらっていないの」とか、「ECNを見たの、見ていないの」という徒労感漂うやりとりはなくなりますし、設変未完による不具合再発という無駄な経費発生をなくせるわけです。

次回、「その2」は「効率の良いECNとは？」という切り口で述べてみたいと思います。
ECNの中には軽微な情報から直接不具合改善につながる重要情報まで存在しています。「また、こんなにたくさんECNが回ってきた。読んでいる時間がない」という事態をできるだけ解消するには？
この辺りを考えてみたいと思います。

以上

次回は12月1日（月）の更新予定です。