ビジネスプロセスリエンジニアリングの第一波は、率直に言える理由から失敗した。当時の技術が、理論の約束したものを実現できなかったのである。1993年には、企業はホワイトボード上でプロセスを描き直すことはできたが、その下にあるシステムは硬直的でバッチ処理に縛られ、統合が困難であった。そのため再設計はメインフレームの境界で行き詰まるか、変革の言葉で装われたコスト削減の作業へと堕していった。着想は健全であり、道具立てはそうではなく、そしてその二つは一緒くたに記憶された。

その制約は大部分が解消された。API(アプリケーションプログラミングインターフェース)は、いまや特注のプロジェクトではなく標準的に期待されるものとなっている。イベントストリーミング、クラウドデータプラットフォーム、オーケストレーションエンジンによって、複数の記録システムをまたいで動くプロセスを、システム間で手作業でデータを運ぶことなく構成することが実現可能になった。かつては英雄的な統合であったものが、いまでは平凡なエンジニアリングである。その結果、あまりに高くつくために長く先送りされてきたリエンジニアリングの問いが、再び手の届くものとなり、大半の組織において別の名の下で回帰している。すなわち、オーダーツーキャッシュの再設計、顧客オンボーディング、供給のレジリエンス、財務決算の迅速化といった名の下でである。

リエンジニアリングの問いを先送りしたくなる誘惑は理解できるが、もはや安全ではない。長年にわたって合理的な進路は待つことであった。いかなる本格的な再設計であれ、その統合コストが便益を上回っていたからであり、企業は次のシステムアップグレードで解消されるだろうという確信の下で場当たり的な回避策を積み重ねていった。だが実際に解消されることはめったになかった。各アップグレードは古いプロセスの形を温存した。その形を移行するほうが、それを問い直すよりも安上がりだったからであり、こうして偶然の設計は見かけ上の恒久性へと硬化していった。変わったのは、その問いを実際に発する競合他社が、いまやその答えに基づいて行動できるようになったことであり、二倍の時間を要し二倍のコストがかかるプロセスは、もはや他の誰もが同じように遅いことによって覆い隠されはしない。

この問いがいま重要である理由はもう一つある。30年におよぶエンタープライズソフトウェアの導入の結果、大半の大企業は、顧客をモデル化するCRM、取引と財務をモデル化するERP、資材と能力をモデル化するサプライチェーンスイートを抱えることになった。そのそれぞれが、異なる時期に、異なる部門によって、異なる論理に基づいて構成されている。実際に価値を生み出すプロセス、すなわち受注してそれを履行すること、顧客を獲得して対応すること、実需に対して供給を計画することは、これら三つすべてを一直線に貫いて走る。組織は機能別に編成され、業務は流れに沿って編成される。そしてその二つの隔たりこそが、コスト、遅延、誤りの集まる場所である。リエンジニアリングとは、その隔たりを表計算ソフトと善意で糊塗するのではなく、意図的に閉じていく規律である。

リエンジニアリングの創始的な洞察は、いまなお最も多くの仕事をなすものだが、事業は組織図によってよりもそのプロセスによってのほうが、より真実に近く描かれるということである。機能中心の企業は、各部門を自らの目標に照らして最適化する。営業は受注を最大化し、業務部門は単位コストを最小化し、財務は運転資本を守る。それぞれは局所的には合理的でありながら、その総和はしばしば全体としては貧弱である。機能間の受け渡し、すなわち顧客が実際に待たされる場所が、誰のものでもないからである。プロセス中心の企業はこれを逆転させる。重要なエンドツーエンドの流れに名を与え、そのそれぞれに機能の垣根を越えた実質的な権限を持つ責任者を割り当て、流れを全体として測定する。すなわち、所要時間、一発通過率、サービスコスト、現金化サイクルによってである。

ここから、我々がいかなる再設計に着手する前にも答えることを譲らない、厳しい前提の問いが導かれる。リエンジニアリングするのか、それとも漸進的に改善するのか、である。この二つは互換ではなく、両者を混同することはどちらの方向にも高くつく。漸進的な改善が正しい選択となるのは、プロセスが根本的に健全でありながら、ただ無駄に覆われている場合である。この場合、リーンや継続的改善の道具立てが、速やかに、そして安全に元を取る。リエンジニアリングが正当化されるのは、プロセスがもはや成り立たない前提を体現している場合、手順の連なりが、その後消え去った制約ゆえに存在している場合、あるいは望ましい成果が既存の設計をいくら調整しても到達不可能な場合に限られる。我々が適用する判定基準は率直である。今日の成果のために白紙から設計していたとしたら、このプロセスにはたどり着けなかったであろうなら、それは再設計の候補である。たどり着けたであろうなら、それは改善の候補である。

第三の原則は、CRM、SCM、ERPをまたぐプロセスは、そのうちの一つだけの中では再設計できないということである。顧客マスター、製品マスター、価格ロジック、注文状態は、共有された事実であり、それらは冗長に、そしてしばしば矛盾したまま、三つのシステムすべてに存在している。真の再設計は、各事実がどこで作成されるか、それがどう伝播するか、そしてそれらが食い違ったときにどのシステムが信頼されるかを決めなければならない。だからこそ我々は、データと統合を下流の実装上の関心事としてではなく、設計そのものの実質として扱う。プロセスモデルとデータモデルは同じものの二つの見方であり、美しいプロセス図を生み出しながらデータの所有権を未解決のまま残すリエンジニアリングの取り組みは、実際には何もリエンジニアリングしていない。

第四の原則が他の三つを支えている。プロセス、システム、組織は、整合させるべき三つの物ではなく、三つの角度から見た一つの物である。それらが別々のガバナンスを持つ別々のワークストリームとして扱われると、それぞれが自らの完成に向けて最適化し、そして本稼働時に互いに矛盾しながら出会う。システムは、組織がそれに対して運用する人員を備えていない流れを、プロセスが清潔だと想定していたデータに対して強制する。それらを一つの意思決定として設計することは、知的にはより厳しいが、実務上ははるかに安上がりである。矛盾が本番ではなく紙の上で見つかるからである。

この分野は動いており、そしてそれは必ずしもベンダーが宣伝する方向にではない。いくつかのパターンは、再設計への取り組み方を変えるがゆえに、率直に名指ししておく価値がある。

モノリスに対するコンポーザビリティ。単一のERPスイートがプロセスの大半を所有すべきだという前提は、統合によって結ばれた専門システム群のアーキテクチャに道を譲りつつある。顧客エンゲージメント層、計画エンジン、財務の中核、履行システムは、ますます別個のものとなり、それぞれの長所に基づいて選ばれ、一つの流れへと構成される。これはプロセス設計にとって解放的である。オーダーツーキャッシュがどう動くべきかについての一ベンダーの見解に縛られなくなるからである。だがそれは、困難を統合とガバナンスの層へと移す。この層がいまや、かつてモノリスが提供していた一貫性を担うことになる。

証拠としてのプロセスマイニング。その歴史の大半にわたって、リエンジニアリングはワークショップから始まった。そこでは人々が、プロセスがどう動いていると信じているかを述べたが、それは決まって作り話であった。プロセスマイニングは、システムがすでに発している実際のイベントログから、実際のプロセスを再構成し、あらゆる派生形、手戻りのループ、迂回を、それが真に起きているとおりに示す。我々はいまや、この証拠なしに再設計を始めることを、怠慢に近いものと見なしている。それは意見を測定された基準線で置き換え、そして後には、再設計が本番で意図どおりに振る舞っているかどうかを教えてくれる計器を提供する。

クラウドERPと二層構造という現実。クラウドERPへの移行は、しばしば標準プロセスに立ち返り、長年のカスタマイズを捨てる機会として売り込まれる。真に共通の業務については、それは健全な助言である。だが同じ移行が、頻繁に二層構造の景観へと硬化する。すなわち、標準化された中核を、企業の実際の独自性を担う専門システム群が取り囲む構造である。したがって設計上の問いは、カスタマイズするか否かではなく、独自性がどこに正当に宿るかであり、中核を標準に近く保ちつつ、周縁が異なることを許し、その二つを偶然によってではなく意図的に統合することである。

タスクからプロセスへと移る自動化。自動化の第一世代、とりわけロボティックプロセスオートメーションは、その大半が画面をクリックしていく人間を模倣するものであり、それはプロセスを再設計するのではなく、既存のプロセスを固定化した。いまやより有用なパターンは、再設計された流れを、オーケストレーションとネイティブ統合を用いてプロセスの水準で自動化し、画面水準の自動化は、インターフェースの存在しない真の周縁のためにとっておくことである。悪いプロセスを自動化しても、それをより速く実行できるようになるだけである。

リエンジニアリングされたプロセスは、それを担うアーキテクチャの良し悪しにしか及ばない。いくつかの設計原則が、持ちこたえる再設計を、ひそかに元に戻る再設計から分かつ。

システムごとではなく、事実ごとに唯一の真実の源を。一つのシステムをすべての親とみなそうとする本能は、親をまったく持たないことと同じくらい誤っている。規律はより精緻である。すなわち、重要な各エンティティと属性について、それを作成するシステムをちょうど一つ名指し、他はそれを購読させるのである。CRMが顧客関係を所有する一方でERPが法的な取引先と与信状態を所有してもよい。肝心なのは、所有権が明示的で、合意され、強制されていることであり、それによって照合が毎月の儀式であることをやめることである。

接続ではなく契約としての統合。急ごしらえで構築された二点間インターフェースは、システム景観の中で最も脆い部分となる。それぞれが、誰も書き留めなかった前提を符号化しているからである。我々は統合を、定義されたイベント、ペイロード、意味論を備えた、バージョン管理された契約として設計し、どちらの側の変更も吸収できる層を介して仲介する。狙いは、あるシステムをその契約の背後で置き換えても、隣接するすべてのシステムがそれを知る必要がないようにすることである。

プロセスを観測可能に設計する。稼働中に測定できないプロセスは管理できず、そして大半は測定できない。我々は再設計された流れを、その状態、その所要時間、その例外が、構造上イベントとして発せられるように構築し、基準線を確立したのと同じプロセスマイニングに供給する。観測可能性は後から付け加える計装ではなく、設計に組み込まれる性質であり、それこそがプロジェクト終了後もプロセスが改善を続けることを可能にするものである。

可逆性を前提に設計する。前進しかできない再設計は、抵抗される再設計である。誤りであった場合の代償が破滅的だからである。我々は移行を、各増分が一時停止でき、既存のものと並行して走らせることができ、証拠が要求するなら巻き戻せるように構築する。これは臆病さではない。それこそが大胆さを手の届くものにする。変更を安価に元に戻せるとき、組織はオールオアナッシングの切り替えの下では決して冒さないような変更を試みる。そして真の変革へと積み上がっていくのは、まさにそうした試みなのである。

幸福な経路ではなく、例外を前提に設計する。大半の再設計は、行儀よく振る舞う取引のために描かれるが、コストの大半は、そうでない取引に宿る。すなわち、分割出荷、係争中の請求書、わずかに異なる名前で二重に存在する顧客である。例外を表計算ソフトと進んで引き受ける個人へと振り向けるプロセスは、設計されたのではない。半分だけ設計され、残りは人間の善意に委ねられたのである。我々は例外経路を明示的にモデル化し、そのうちどれがシステムを通じた第一級の経路に値するほど一般的か、どれが熟慮された手作業に委ねてよいほど真に稀かを決め、その区別を、たまたまソフトウェアが対応していたことの偶然ではなく、意図的な選択とする。再設計の真の尺度は、最良の火曜日にどう振る舞うかではなく、最悪の火曜日にどう振る舞うかである。

これらのプログラムが失敗する仕方は、目録に載せられるほど一貫しており、その大半は技術ではなく判断の失敗である。

ビッグバン型のERP刷新。最も高くつく単一の誤りは、ERPを刷新し、プロセスをリエンジニアリングすることを、全社にわたって同時の一斉切り替えで行うことである。理屈の上では、きれいな断絶が二つの世界を並行運用するコストを避けるとされる。実務では、リスクが累積する。あらゆる問題が一度に、原因を切り分ける術のないまま浮上し、そして事業は後戻りする能力を失うからである。我々は、プロセスごと、ドメインごとに提供される再設計を好み、新しい流れを、範囲を広げる前に、限定された範囲で実証する。段階的な移行はより遅いが、たどり着く見込みははるかに高い。

既存の混乱を自動化すること。現行プロセスを写し取り、それを忠実に自動化し、その結果を変革と呼ぶプログラムは、誤った方向へより速く進むために多額を費やしたのである。自動化は再設計に従うべきであって、それに代わってはならない。

組織ではなく図をリエンジニアリングすること。システムとプロセスを変えながら、インセンティブ、役割、報告系統には手を触れない再設計は、それによって不都合を被る人々によってひそかに元に戻される。プロセスがいまや機能横断的であるのに賞与が依然として機能別のままなら、機能別の目標が勝つ。権限を伴わないプロセスの所有権は、飾りである。

先送りされたデータの負債。チームはしばしばマスターデータと品質の作業を、地味であるとして先送りし、後で対処するつもりでいる。後になって、清潔で一貫したデータを想定していた再設計プロセスが、現実のそれと出会い、行き詰まる。データ品質はプロジェクトに隣接する清掃作業ではない。それはプロセスがそもそも機能するための前提条件である。運用担当者を場に置かないコンサルタント主導の設計は、これに輪をかける。専門家だけによって描かれた再設計は、業務を回す人々の暗黙知を見落とす。すなわち、冗長に見える手順が実は荷重を担っている理由、毎週起きるのに一度も文書化されなかった例外である。それらの運用担当者が新しいプロセスに研修で初めて出会うとき、彼らはその欠落を発見し、そして彼らの信頼は、いったん失われれば、取り戻すのに高くつく。

成果ではなくシステムによる範囲設定。ERPプロジェクトあるいはCRMプロジェクトとして認可されたプログラムは、業務の境界ではなくソフトウェアの境界を受け継ぎ、そしてシステムをまたぐ流れ、すなわちまさに価値の宿る場所が、ストリーム間の隙間に落ちる。認可は成果と流れに名を与え、システムをその内側に収めるべきである。

我々はシステムからではなく、流れと成果から始める。いかなる変更を提案する前にも、エンドツーエンドのプロセスが達成すべきものを、事業が認識できる言葉で、すなわち所要時間、サービスコスト、現金化サイクル、顧客の労力によって定め、そして現状をそれに照らして、ワークショップで人々が語る物語ではなく、システムがすでに保持しているイベントデータを用いて測定する。その測定された基準線が、最初の論点、すなわちプロセスがリエンジニアリングに値するのか改善に値するのかを、熱意ではなく証拠に基づいて決着させる。

再設計が正当化される場合、我々はプロセス、データモデル、統合を一体として設計し、それらを三つの逐次的なプロジェクトではなく、一つの意思決定の三つの見方として扱う。CRM、SCM、ERPをまたぐ各共有事実の所有権を明示的に解決し、統合をバージョン管理された契約として定義し、流れのオーケストレーションを、設定のあちこちに散らばったロジックではなく、検査可能な成果物とする。再設計されたプロセスは、自らの状態を発するように構築され、それによって、それを正当化したのと同じ基準線に照らして本番で測定できる。

我々はドメインごと、流れごとに提供し、決してビッグバン型の一斉切り替えでは行わない。再設計されたプロセスの限定された一片を、実際の取引において本番で実証してから、範囲を広げる。それによってリスクは隔離されたままとなり、事業は後戻りする能力を保持する。全体を通じて、我々は組織的な変化、すなわち所有権、インセンティブ、役割を、後付けではなくエンジニアリングの一部として扱う。組織がそれを回すように編成されていないプロセスは生き残らないからである。我々の狙いは、我々が去った後も改善を続ける再設計である。それを管理する計器が、最初から組み込まれているからである。

我々はペースについて率直である。三つの記録システムにまたがる再設計を、四半期で終えられると正直に言うことはできず、それを約束するいかなる提案も、再設計ではなく一斉切り替えを売っているのである。我々は作業を、各ドメインがそれ自体で測定可能な改善をもたらすように順序立てる。それが次のために必要な信頼と注目を勝ち取るのであって、単一の遠い報酬のために複数年のプログラムを通じて事業に息を止めさせるのではない。その順序立ては、設計そのものをも律する。限定された一片で自らの価値を証明することを義務づけられた流れは、すべてが最後に整合するという約束の背後に隠れることができない。ある一片が、それが改善すべく認可された成果を改善できないなら、我々はそれを三つのドメインすべてで一度に発見するよりも、一つのドメインで発見するほうをはるかに好む。

プロセスリエンジニアリングにおける我々の仕事を際立たせているのは、CRM、サプライチェーン、ERPを別々の再設計を持つ別々の領域として扱うことを拒む点である。我々は、エンドツーエンドの流れ、それを貫いて走るデータ、それを運用する組織を、単一の視野に保ち、所有権と統合という難しい問いを、実装に先送りするのではなく、設計上の意思決定として解決する。それは切り出すには難しい会話であり、成し遂げるにははるかに持続的な結果である。

そこには、仕事が前提としてよいものを変える実務上の帰結もある。ある取り組みが、まだ存在しない能力を必要とするとき、それは調達サイクルやベンダーのロードマップを待つ必要はない。enterprise platformは、エージェンティック・エンジニアリングを通じて、ほとんどあらゆる機能を素早く受け入れられるように構築されている。必要なものが平易な言葉で記述され、素早く生成されるが、それは常に確固たるアーキテクチャ原則の内側で、厳格な品質保証の下で行われ、それによって速さが一貫性、セキュリティ、統制を犠牲にすることは決してない。その効果は、単に便利であるにとどまらず、戦略的である。それは内製か購入かの境界を動かし、選択肢を安価に保ち、戦略が棚にたまたまあったものに屈するのではなく、アーキテクチャが戦略に従うことを可能にする。

この規律に対する報酬は、事業が実際に必要とすることをなす一連の中核プロセスであり、それは事業が気にかける成果に照らして測定され、壊れることなく変化できるアーキテクチャによって担われ、それらを回すように編成された組織によって運用される。それこそが、リエンジニアリングが常に提供すべく意図されていたものであり、そして今日の道具立てをもってすれば、それはついに実現できるのである。