スピード追求がもたらす明日のソフトウェアの問題

ERPおよびビジネスクリティカルソフトウェアを迅速に提供する圧力は、組織が最終的に対処しなければならない隠れたコストを生み出すことが多いと、カール・アンドリュース、オリジナル・ソフトウェアのCEOは主張する。

すべてのCIOは、プロジェクトの完了を祝う式に出席したことがある。ケーキ、祝賀、プロジェクトが遂に完了したという安心感について話される。ただし、完了後に続く数ヶ月間に、プロジェクトを時間通りに完了するために圧力をかけていたチームが、維持するシステムのコストを負担することになることは、話されないことが多い。

これは、ニッチな問題ではない。ソフトウェアの提供スピードを上げる動きは、減速するのではなく、加速している。スプリントサイクルは短くなり、リリース頻度は増え、技術がビジネスのニーズにほぼリアルタイムで対応することが期待されるようになった。速く進むことは、通常、正しい直感である。問題は、速く進むために、どのようなものが無意識のうちに犠牲になっているかである。

負債が始まる場所

テクニカルデットは、警告なしに訪れることが多い。個別の決定は、全体として見ると、完全に正当化できるものである。しかし、ドキュメントの優先順位が低くなる。ワークアラウンドがERPの設定に追加される。テストが減る。カスタマイズが残される。

誰もが、負債を蓄積しようとはしない。ただ、プレッシャーの中でなされた、もっともらしい決定の結果である。ショートカットがシステムを変更しにくくし、頻繁にエラーを起こし、予算よりも維持コストがかかるシステムになる。

ERP環境は、特に脆弱である。組織の中核にあるため、財務、人事、サプライチェーン、調達、その他の重要なビジネス機能と接続している。ショートカット、ワークアラウンド、ドキュメント化されていない変更が、誰も意図しなかった複雑さを生み出す。結果は予測可能であるが、タイミングは問題である。テストでは検出されなかった問題が、ビジネスプロセスで発生する。

組織が問題を軽視する理由

課題の1つは、テクニカルデットが明確なコストとして現れないことである。失敗したプロジェクトや遅れたデッドラインとは異なり、負債は徐々に蓄積する。予想よりもアップグレードに時間がかかる。変更には予想よりも多くの労力が必要になる。チームは、以前なら簡単に解決できた問題を調査するのに数週間を費やす。

これらのコストはゆっくりと現れるため、個別の事例として扱われることが多い。組織は、迅速に提供することの明らかな利点に焦点を当て、システムを維持し進化させることの長期的な結果を無視することが多い。

結果として、テクニカルデットは、ビジネスパフォーマンスに影響を与えるまで、注目されないことが多い。

イノベーション、生産性、回復力への影響

テクニカルデットの最も大きなコストは、技術的なものではない。戦略的なものである。ERP環境が複雑になるにつれて、ITチームは、既存のシステムの維持に多くの時間を費やすようになり、新しい機能を提供する時間が減る。変革プロジェクト、プロセス改善、AIイニシアチブをサポートできるリソースは、トラブルシューティング、再作業、システムの維持に費やされる。

イノベーションは遅くなる。変更にはより大きなリスクが伴う。生産性は低下する。回復力は低下する。システムはテスト、サポート、復旧が困難になる。組織は、競争力を維持するためにスピードを上げようとする。しかし、スピードによって生み出された負債は、将来的に変更を遅くし、費用を増やし、提供を困難にする。

バランスをとる

答えは、遅くすることではない。ほとんどの組織は、それを許容できない。目標は、長期的な品質を損なうことなく、提供プロセスを構築することである。テスト、ドキュメント化、ガバナンスなどの活動は、提供の障害ではない。持続可能な提供を可能にするものである。特にERPシステムの場合、回帰テストは不可欠である。

組織は、変更、更新、アップグレードを導入する際に、予期せぬ混乱を生み出すことなく、ビジネスに自信を持つことができる。デリバリーライフサイクル全体でより多くの自動化とテストを組み込むと、問題が高額な問題になる前にそれらを特定するのに役立つ。

最も重要なことは、組織がテクニカルデットを技術的な問題ではなく、ビジネス上の問題として見なす必要があることである。今日行われる決定は、将来的にシステムのコスト、柔軟性、回復力を影響することになる。

プロジェクトの完了は、ゴールではない。ただ、決定の長期的な結果が現れ始める地点である。時間の経過とともに成功する組織は、短期的に最も速く進む組織ではなく、システムの制限を受けずに変更し続け、イノベーションを続けることができる組織である。