リエンジニアリングの対象はプロセスであって組織ではありません。この点は、誤解されやすいところです。
組織は組織図に表すことができ、日常的に人は組織に所属して仕事をしているため、組織を実感することができます。しかし、プロセスは通常目に見えません。
多くの企業では、人は特定の職能部門のなかで仕事をし、その仕事がわが部門の仕事ですが、その仕事がわが部門を出たら別の部門の仕事と認識され、責任の範囲外になります。ですから、プロセスを実態としてつかめていることはほとんどありません。
部門には責任者がいますが、それと同じ意味でのプロセス全体の責任者は通常いません。
このような理由で、日常的にプロセスを認識して仕事をしている従業員はほとんどいません。ですから、リエンジニアリングを行うためには、わが社において、どのような仕事の流れ、すなわちプロセスが存在しているのかを認識することがまず必要になります。
プロセスを認識する
プロセスを把握する方法の一つは、そのプロセスの始まりと終わりに名前をつけて呼ぶことです。例えば、「製造」は部門名ですが、「調達から出荷までのプロセス」と言えば、プロセスの流れと境界がより明確になります。一つのプロセスには、通常、複数の部門にまたがった仕事の流れがあります。
プロセスは「プロセス・マップ」によって表現することができます。一つの企業が複数の事業をもつ場合、複数のプロセス・マップを描くことができます。プロセス・マップはより複雑かつ詳細に描くこともできますが、一つの事業について、外部からのインプットに始まり、外部へのアウトプットに終わるプロセスとしてマップを表現する場合、概ね10以内の段階で表現できるといいます。
プロセス・マップを構成する一つひとつの段階もまた、社内のプロセスとみなすことができます。複数の社内プロセスが大きな一つの事業プロセスを構成していると考えることができます。一つの社内プロセスは、それぞれがインプットとアウトプットをもち、社内の前段階プロセスのアウトプットをインプットとし、自らのアウトプットを後段階プロセスのインプットとして提供します。
プロセスでとらえると、一つの部門の仕事がプロセスの複数の箇所に関わっていることも見えてきます。この点が、プロセスの認識を妨げる働きをするとも言えます。部門単位の認識でプロセス・マップを描こうとすると、それほど簡単には行かないことがほとんどです。部門を超えた発想で仕事の流れを見通すことが意外に難しいのです。しかし、実際に作成し終えたものを見ると、非常に簡潔でわかりやすく、むしろ当たり前のように見えることがほとんです。
リエンジニアリングするプロセスの選択
どのような企業でも、すべての高レベルのプロセスを同時にリエンジニアリングすることはできません。リエンジニアリングするプロセスを選択しなければなりません。選択基準は、まず、もっとも深刻な機能的障害を抱えていること、次に、もっとも顧客への影響が強いこと、最後に、もっともリエンジニアリングに成功しそうであることです。
これらの基準は絶対的なものではありませんが、選定の基準としてもっとも活用できるものです。
すでに会社の戦略が定まっているのであれば、その方向性に重要な影響を与えるプロセスを選ぶこともできます。そのプロセスが現在のままであっては戦略の実現がままならないとすれば、リエンジニアリングの候補になるはずです。
機能していないプロセス
膨大な情報の交換やデータの再入力が行われている場合、プロセスに問題があります。情報を高速で送るとか、再入力を自動化するなどの対処療法は意味がありません。本来分割されるべきでない活動が、不自然に分割されているということですから、一つの活動として統合すべきです。一人の人間やチームがやるべき活動であるはずです。
不確実な状況に対応する必要があるため、余剰の在庫や資産を保有していることがあります。確かに、組織の境界、企業の境界においては、不確実性が存在することはやむを得ないかもしれません。しかし、現在は、JIT（Just in time）が基本です。情報技術の進展によって、企業の境界を超えたプロセスの統合も可能になっています。供給業者や顧客と共にプロセスを計画し、運営していくことが可能です。
プロセスのなかで、検査（チェック）や管理が頻繁に行われている場合、活動が細分化されすぎている可能性があります。検査や管理は、それ自体、顧客にとっての価値を付加していません。企業内部の都合によって行われているものです。ですから、検査や管理は、効率化するのではなく、なくすことを考えなければなりません。
やり直しや繰り返しが生じるのも、プロセスに問題があります。情報のフィードバックが不十分であったり、タイムリーでなかったりすることから起こります。それを頻繁な検査で補おうとするのは、本質的な問題の解決ではありません。
単純なプロセスで始まったものが、時間が経つにつれて、例外処理が増え、複雑になっていくことがあります。組織では、プロセスの数を増やしたくないと考え、一つのプロセスのなかにさまざまな例外処理を盛り込もうとします。その結果、一つのプロセスのさまざまな段階で意思決定が必要になり、その都度、場合分けを行わなければならなくなります。そうではなく、意思決定はプロセスの最初の段階で行い、その後に単純な複数のプロセスに分けていくほうが効率的です。
プロセスのなかで、仕事が複数の人や部門を移動していくことは多いですが、移動が存在するだけで、理由なく大幅に時間を要していることがあります。実際の例として、プロセスの処理時間の実に9割は、誰かの書類トレーに眠っている時間であったといいます。このような例は、特定の会社や特定の業種に限られるわけでありません。複数の人や部門を仕事が渡り歩こと自体に伴う遅れであり、何ら考慮すべき事情のない無駄な遅れです。
注意しなければならないことは、症状を見ただけで、必ずしも正しい病気が分かるわけではないということです。あるプロセスの病気が、別のところに症状として現れることさえあります。あるプロセスの問題を補うために、別のプロセスが無駄なフォローをしているために、そのフォローをしているプロセスに問題があると勘違いしてしまうことがあるのです。
重要なプロセス
重要なプロセスとは、顧客への影響度が大きいプロセスのことです。その判断には、顧客からの情報が欠かせません。顧客がどの問題に強い関心を抱いているかを聞くことによって、その問題にもっとも影響を与えるであろうプロセスを選別することができます。
リエンジニアリングが実行可能なプロセス
規模の大きなプロセスをリエンジニアリングしようとすると、一般に、関連する組織の数が多くなるため、多くの人々との調整が必要になります。必要なコストやリスクも大きくなり、成功の可能性は小さくなります。
リエンジニアリングはプロセスの抜本的なつくり直しですから、通常、長期の取組になります。そのため、持続させることに困難が伴うことは覚悟しておかなければなりませんが、持続させるための刺激として、短期的な成果はやはり不可欠です。その意味で、実行可能で成果が出やすいプロセスを選ぶことも考慮しなければなりません。
仮に企業全体をリエンジニアリングする必要がある場合であっても、管理しやすい単位に分けて順次行っていくことは重要です。すべてを行わなければ結果が見えないということにならず、順次確実に結果を確認していくことができるからです。それに、一つの結果が次の変革に連鎖的につながっていくことを実感することができます。結果による学びが次に生かされ、成果が皆の意欲を一層高めていくからです。
特に、最初のパイロット・プログラムは、必ず成功させるつもりで、慎重に選ばなければなりません。信頼できるプログラムとして実施でき、他の領域でも再現できるようなモデルにならなければなりません。継続的な改善ではなく、抜本的なつくり直しが不可欠であることが理解され、なおかつ劇的な成果を生むものでなければなりません。
プロセスを理解する
プロセスをリエンジニアリングするには、対象とするプロセスを理解しなければなりません。現在のプロセスが何を行っているか、どれだけうまく機能しているか、または機能していないか、そしてその成果を左右する決定的問題点などを知る必要があります。
ここで改めて重要なことは、リエンジニアリングとは、現在のプロセスの改善ではなく、抜本的なつくり直しであるということです。つくり直すために必要なことが「理解する」ことであり、「分析する」ことではないということです。ところが、プロセスを理解しょうとしながら、いつしか職能に深く焦点が当たっていることがあります。このようなときは、プロセス内部を分析していることが多いと言えます。
求めるべきは、知識と洞察です。既存のプロセスはつくり直されるのですから、既存のプロセスを深く分析することに意味はありません。常に高い視点からプロセスを見る必要があります。
顧客の立場で考える
プロセスを理解するためにもっとも重要なことは、顧客がプロセスのアウトプットで何をするか、つまり、顧客がそのアウトプットを利用する目的です。
プロセスの分析では、アウトプットを所与のものと考えがちですが、リエンジニアリングにおいては、アウトプットが顧客の目的に適っていることがもっとも重要です。顧客の目的に適っていなければ、アウトプットそのものを変えなければなりません。アウトプットをつくり変えることも、リエンジニアリングの重要な一部です。
したがって、プロセスの理解においては、顧客の立場を理解することが何よりも重要な視点です。さらにここで注意すべきことは、顧客の声を聞くことは大事ですが、顧客の言うとおりにすることが重要であるとは限らないということです。顧客が欲しいと訴えているものと、顧客が本当に必要としているものとは、必ずしも一致しないからです。顧客は本心を語らないことが多いことも、よく知られています。
顧客の声を聞き、顧客の問題を知り、実際に顧客がプロセスのアウトプットを用いて何をどのようにしようとしているのかを観察し、時には、自ら顧客と同じ環境下で仕事をしてみることによって、本当に顧客のニーズを理解することができるようになります。
そこに来て、プロセスが現在提供しているアウトプットが、そのニーズを満たしているのかを判断することができます。現在のアウトプットが顧客のニーズを十分に満たしていないのであれば、アウトプットを変えなければなりません。もはや、現在のプロセスが何をどう行っているかは重要でなくなります。そもそも違うプロセスをつくらなければならなくなるからです。
ベンチマーキングの活用
リエンジニアリングにおいては、ベンチマーキングが活用されることもあります。
ベンチマーキングの問題点は、業界内で現在すでに行われていることのフレームワークのなかに、リエンジニアリング・チームの思考を制限してしまう可能性が高いことです。
ベンチマーキングによってリエンジニアリングのアイデアを得るためには、自社の属する業界外の企業をベンチマーキングすべきです。しかも、世界のベストからベンチマーキングすべきです。
プロセス・リデザインの試行
プロセス・リデザインは、その会社をもう一度描き直し、新しい仕事のやり方を見つけることです。
リエンジニアリングの全過程のなかで、純粋に創造的な部分であり、想像力、帰納的思考、少々の奇抜さも必要です。見慣れたものを除外し、突飛なものを求めます。これまでのルール、手順、価値への信念を忘れることが要求されます。
かといって、まったく何も参考にすべきものがないわけではありません。リデザインされたプロセスには、いくつかの共通点を見つけることができるといいます。
まず、プロセスの実行に関わる人はできる限り少なくなるようにリデザインすべきです。結果的に人数が少なくなるように考えるというよりも、「もし一人で行うとすれば、どのように行うだろうか、どのような助けを必要とするだろうか」と問うことによって、スケールの大きなアイデアを思いつく可能性が出てきます。
次に、前提を見つけてそれを削除していくことです。前提とは、現在のプロセスの根底に流れ、組み込まれている深い信念です。このような前提をあれこれ考えたり、完全に捨て去ってしまったりすることを試み、プロセスのどこを削除でき、どこが残るのかを判別することができます。また、前提をなくすために何をすべかを考えます。
さらに、現在活用できる情報技術によって、新たにできること、解決できる問題がないかを考えてみます。
