今、原材料メーカーの研究開発プロセスの改革のコンサルティングをしています。まだ始めたばかりなので速断はできませんが、顧客、事業部経由、研究開発部門と要求が伝わっていくのが、まるで伝言ゲームのような感じです。そして、その要求自体も、企画レベル、構想設計レベル、基本設計レベルとまちまちです (これは当然)。

  最初の目標は、研究開発本部内でのプロセスの標準化、次は事業部とのプロセス、最終は顧客とのプロセスを標準化することです。 

  この標準プロセスには下記を含むことになります。

  (1)各レベルでの要求項目の標準化

  (2)各レベルの要求による設計成果物の標準化

  (3)各設計プロセスにおいてこれらを参照可能にすること

  (4)各要求から設計するためのノウハウを形式知化して組織内共有

  (5)各設計完了レビューのプロセスの公式化(一般にゲートウェイと呼ばれる)

   上記の標準化は単にフローだけではなく、用語定義、階層別プロセス図、プロセス詳細定義、業務ルール(プラクティスを含む)ものです。詳細⇒最下段 

 

  上記(1)(2)は、中小製造企業ながらETO品の売上を10倍にした事例Aで実現しているものです。さらに、受注した顧客に対しては上記(3)の設計途中の成果物を見せて、顧客満足度を高めています。

  大手製造業業ならば、上記(1)(3)(4)(5)が出来て無ければその大きさに見合う組織力があると言えるのでしょうか? 

  たとえば、(1)顧客は自分が欲しいものを本当に分かっているのでしょうか? そして、(4)形式知にするには、誰が設計の暗黙知から使えそうに標準化して形式知化するのか、これらを具体的な仕組みとして構築しなければ「ただの掛け声」で終わります。たとえば、(4)に該当する失敗ノウハウは本人は分かっているのでもう不要、これが必要なのは他の人。

  大手IT企業では、上記(2)に関するシステム開発方法論を持っているでしょう。しかし、(3)(4)がないため設計者からするとメリットが無く、その方法論が形骸化しています。さらに、一番重要な(1)要求 (このレビューを含む)、これが抜け落ちてIT要件からスタートしていては、IT開発トラブルは減少しません。さらに、多重下請構造のため、小さなミスでもブルウィップ効果で増幅してしまう。

    

     プロセス概念が弱い日本企業にとっては、(ビジネス)プロセスというと外食産業の定型的なものだけを思い浮かべるでしょう。そして、標準化は画一化だと大きく誤解も。

  同様に、知的な研究開発もプロセスです。そして、個人が持つスキルの限界を上記(3)(4)でさらに向上できます。(5)はビジネス上の観点からすべき、「その設計で市場で売れるか?」と。

       しかし、研究開発のノウハウは社内だけにある訳ではありません。デュポン社のように(それも20数年前)「創造的な仕事をする人は30%の時間は社外で見聞を広めるために費やすべき」と、個人の能力向上や動機付けの仕組みも必要です。

 

  過去に、下記ブログを書きましたが、それは研究開発プロセスにも通用するものです。

       日本企業には標準たるレベル4プロセスがない・・・・この甚大な弊害

  プロセスの標準化への誤解、2種類の標準化とその効果

  プロセス標準化で定義するもの 用語定義階層別プロセス図プロセス詳細定義業務ルール(プラクティスを含む)など