　そのためには、中国仕様で価値のある製品の提案をしなければなりません。単に、高機能で高品質な日本製品だから売れるというものではありません。現地仕様に見合った製品を提案しなければなりません。受注案件が増えれば設計案件も増えますから、設計作業もこれまで以上にスピードアップできる仕組み（システム）が必要です。営業活動と設計活動を効率化し、売り上げ倍増を実現できるソリューションを求めています。

　このような場合、まず製品ライフサイクルのどの段階で、どの部署のためのIT改革なのか、そのスコープ（範囲）を的確に特定する必要があります。すなわち、プロセスと組織を横断するように、いくつかのフレームワーク（枠）を定義してみることです。図6を見てください。この例では、2つのスコープ決めをしています。（A）と（B）のように、業務プロセスを横断するように2つの枠を置いています。

図6　IT改革を実行するフレームワークの定義

　（A）は、営業引き合い段階です。見積もり作業を有利にするために、基本設計作業に付加価値を与えようとしている活動です。見積もり提案段階ですから、まずはたくさんの製品案を簡単に定義したいことでしょう。そのために、「構想設計プロセス」を基軸にしています。そして「要件の取り組みと管理」と「プロポーザルへの返答」に関するプロセスを組み合わせながら、1つの営業引き合いシステムに仕立てようとしています。

　一方（B）は、定型的な詳細設計作業を、いままでよりもっともっとスピードアップさせるための方策です。すなわち「詳細設計プロセス」を基軸とし、それに「変更管理と構成管理プロセス」が監視役となり、かつ外注設計の合理化のために「設計アウトソーシングプロセス」にも着目しています。そして、これらの3つのプロセス（詳細設計、変更＆構成管理、設計アウトソーシング）で必要となるITツールを、上述の5つのITタイプから選択し、ベストなITの組み合わせを考えます。いわば、誰がやっても同じ設計品質を実現できる設計管理システムを狙っているようです。

　さて、このような状況の中で、（A）と（B）の優先順位や実現可能性を掘り下げていかなければなりません。（A）と（B）の2つを同時に進めるには、ボリュームが大き過ぎます。年度予算も限られています。

　まず、現場の人の思いをマッピングしていきましょう。そうすると、実現可能性からして、まず（B）に取り組んで、その次に（A）に展開した方が無難という意見が出てきそうです。理由は、（B）の領域の方が、ものづくりのIT活用に関する現場の素地ができているからです。As-Isのレベルが青色になっているプロセスが多いです。IT操作の作法が身に付いている可能性がありそうです。

　一方（A）の部分は、営業と設計の部門を超えた協働作業であり、かつ、まったくIT化が促進できていないプロセスばかりです。部門間の調整も難航を極めるかもしれません。できれば、（A）は後回しにしたいところです。しかし、経営者の視点として、（A）の方が（B）より優先順位が高かったらどうしますか。

　このように、部門横断で取り組まなければならない場合は、トップの考え方が重要性を帯びてきます。部門を横断するITシステムに取り組む場合は、トップの思いや優先度について、よく確かめる必要があります。

　この例にあるような、（A）と（B）のどちらをどの順番で進めるかに関しては、正解が唯一決まるというものではありません。重要なことは、会社の目標と現場の実践能力とを総合的に掘り下げながら、ITを処方する方向性を見極めることです。そのためには、読者の皆さんのようなミドルクラスの分析能力とリーダーシップが必要です。

前のページへ 1|2|3|4 次のページへ