ITの役割
多くの場合、おそらくほとんどの大企業ではサプライチェーンを運営する中で、IT部門には何年にもわたるバックログが存在する。このバックログは、数え切れないほどの不具合、不整合、または脆弱性で構成されており、修正可能_であるにもかかわらず_修正されていない。広大な官僚主義的な負担を生み出すと同時に、この終わりのない一連の無意味な苛立ちが皆のやる気を奪う。サプライチェーンは、アプリケーション環境の真ん中に位置しており、特に大きな影響を受ける。逸話的には、サプライチェーン部門1は企業全体のITバックログの半分を占めることが多い。
さらに悪いことに、バックログはしばしば何らかの_大転換_、通常はERPのアップグレードによって覆い隠される。これは、大転換が過去10年間に放置されたすべての問題を解決するという期待の直接的な結果である。しかし、その期待は的外れである。実際、2大転換が成功裏に完了したとしても、5年後には古い問題のいくつかを解消するに留まるか、むしろ新たな多くの問題を引き起こすだろう。
大転換には2つの副作用がある。第一に、ソフトウェアに関する事項において、ITを除くすべての部門の発言が封じられることである。第二に、大転換はすべての予算とエネルギーを吸い込むブラックホールのような役割を果たす。第二の副作用は第一の結果である。
大転換の性質上、非常に技術的である。IT専門家を除いて誰も、あるデータベースシステムから別のシステムへの移行における細かい条項や、両者間に存在する微妙な非互換性を真に理解していない。他部門が沈黙させられると、すべてのリソースが大転換に向けられることに対する抵抗はなくなる。他部門は通常、大転換が加速するという誤った希望のもとで同調する。しかし、実際は逆であり、予算が大きくなるほど取り組みは遅れる。
大企業の間では、このアプローチが過去20年間にわたって普及している。その結果は惨めである。企業は依然として、10年以上前にオープンソースによって商品化されるべきだったCRUDアプリ3に対して法外な料金を支払っている。実装の遅延はこれまでで最長となっており、皮肉なことに、エンタープライズソフトウェアのパフォーマンスと応答性は依然として低く、一方で基幹ハードウェアは20年前の1000倍の能力を持つようになっている。
この状況は根本的な修正を必要としている：IT部門は他の全ての部門の代理として_大アーキテクト_のような振る舞いをやめなければならない。代わりに、IT部門はインフラ4に専念し、他部門のソフトウェア関連の取り組みに対する_コーチ_となり、その他の部分は各部門自身がイネーブラーとして担うべきである。
大アーキテクトのポジションは維持不可能である。たとえ全体としてでも、IT部門が財務、マーケティング、営業、給与、製造、会計、輸送、計画、コンプライアンス、法務などすべてを理解することはできず、何でも屋は手掛けるプロジェクトのほとんどで失敗する。半端な納品は、後に修正が必要なさらなる問題を生む。バックログの発生は避けられず、終わることがない。ソフトウェアが年々普及するにつれて、バックログは毎年ますます管理不可能になっていく。
解決策は単純である5：_大アーキテクト_の考えを放棄し、IT部門を他部門が実行する全てのソフトウェア関連の取り組みのイネーブラーおよびメンターへと再配置することである。サプライチェーンのような部門に自らのソフトウェア取り組みを管理させることで、彼らは自身の野心を見直すことを余儀なくされる－もはやバックログが手に負えなくなる際の言い訳は存在しない。各部門は成功も失敗も自らが背負うことになる。
しかしながら、この解決策はほとんど実施されることはない。
IT部門をイネーブラーとして再配置することは、企業内での運営規模が大幅に縮小される直接の結果として、その予算を半分以上削減することを意味する。これは、大転換時にCEOと肩を並べるほどの権限を持つIT部門の責任者にとっては容認できないことである。
また、部門長は自らのソフトウェア取り組み―あるいはその欠如―に対して責任を負う必要がある。プロジェクトが失敗するたびに、責任をITに転嫁できるという安心感があるのだ－これはソフトウェアでよく見られる現象である。また、これにより部門は何十年にもわたって苦しんできたIT人材の採用という厄介な問題を回避することができる。
それにもかかわらず、エンタープライズソフトウェアがSaaS（Software as a Service）へと移行する中で、大アーキテクトの視点は次第に重要性を失いつつある。ベンダーがホスティング、バックアップ、アップグレードなどを担うためである。結果的に、部門長は自らのソフトウェアに関する意思決定に責任を負わざるを得なくなり、IT部門は従来の責任を徐々に手放すことになる。
エンタープライズソフトウェアはSaaSの流れに10年遅れて参入した。私は、ほとんどの大企業が_大アーキテクト_の考え方から脱却するには、さらに10年を要すると予測する。
-
サプライチェーンのバックログは多様な形態をとる。例として、シャドウITが蔓延し、Excelがあらゆる場所に存在し、オペレーションや顧客、サプライヤーが情報から隔絶され、在庫、注文、出荷がシステム間で適切に同期されず、手動入力が自動化に取って代わるといった状況がある。 ↩︎
-
これらの大転換では、勝者はただ一人、すなわちプロセスを主導するソフトウェアベンダーである。15年間で、数年にわたるアップグレードがごく僅かな改善以外のものをもたらしたのを見たことはない。しかし、ソフトウェアベンダーがそれらの運用から華々しいリターンを得るのを何度も見てきた。 ↩︎
-
Create, Read, Update, Delete. CRUDアプリはエンタープライズソフトウェアの基礎であり、ほぼすべてのワークフローおよびトランザクションアプリはCRUDで構成される。 ↩︎
-
ネットワーク、アイデンティティフェデレーション、オペレーティングシステム、バックアップなど。 ↩︎
-
2000年代までは、インターネット上でエンタープライズソフトウェアを連携させるのは困難であった。そのため、異なるソフトウェアを導入し、その後に接続するという選択肢は、2000年代以前にはほとんど実現可能ではなく、ましてや安価なものではなかった。初期のエンタープライズシステムは、必然的にモノリシックな構造で始まったため、上記の「解決策」が現実的なオプションとなったのは2010年代初頭になってからである。 ↩︎
