CONFIRMは、航空会社、レンタカー会社、ホテル会社が使用する単一のコンピュータ予約システム/グローバル配信システムを構築するという野心的なITプロジェクトでした。プロジェクト管理における大きな失敗の例として、ケース スタディとしてよく使用されます。
歴史
このシステムは、 AMR、マリオット、ヒルトンホテルズコーポレーション、バジェットレンタカーの間で相乗効果を生み出し、関係各社の予約システムを完全に統合・統一する ために開発が進められました。
1988年、4つの大企業は、1992年6月までに5,500万ドルの費用でシステムを完成させる契約を交わした。残念ながら、プロジェクトはパートナーが予想していたよりもはるかに複雑であることが判明した。彼らは皆、航空業界の規制緩和後にアメリカン航空が持続可能な競争上の優位性を築くのに役立った非常に成功したSABREコンピュータ予約システムをAMRが拡張することに大きな期待を抱いていた。1992年4月、システムの稼働開始のわずか3か月前に、Confirmはロサンゼルスのヒルトンでのテストに合格しなかった。AMRはまた、システムを完成させるのにさらに15〜18か月必要であるとパートナーに伝えた。プロジェクトは完了しなかった。その過程で500人以上の技術者がプロジェクトに従事し、パートナーが1992年7月にプロジェクトを解散したとき、彼らはプロジェクトに3年半と1億2,500万ドルを費やしていた。
このプロジェクトの技術的複雑さは極めて大きかった。CONFIRM は 2 台のIBM 3090メインフレームで稼働している。1 台にはトランザクション処理機能で稼働する中央予約システムが格納されている。もう 1 台のメインフレームには、MVS [1] (IBM メインフレームのオペレーティング システム) 環境の DB2 リレーショナル データベースが格納されている。データベースには、顧客履歴や価格データなどの意思決定支援情報が格納されている。このシステムでは、約 60 のアプリケーションについて、2 台のメインフレーム (CPU/IBM 3090) 間でアプリケーション間のブリッジングが必要だった。主な問題は、CONFIRM のトランザクション処理機能ベースの中央予約システムと意思決定支援システムを結び付けることだ。ヒルトンのユーザーは、システムのユーザー インターフェイス、メインフレームのトランザクション処理、およびメインフレーム データベースが適切に通信できないことに気付いた。その他の問題としては、プログラミング言語が異なることや、クラッシュ時にデータベースを回復するのが難しいことなどがある。これらの問題は克服できないものではなかったが、プロジェクトをさらに 2 年ほど遅らせることになった。
1992 年 9 月、AMR (アメリカン航空) は、マリオット、ヒルトン、バジェットを相手取り、資金の差し止め、不適切な人員配置、早期撤退により CONFIRM の破綻を引き起こしたとして訴訟を起こしました。3 社のパートナーは反訴しました。
1994年1月、アメリカン航空はすべてのパートナーと非公開の金額で法廷外和解に達した。[2] [3]
参照
- リアルタイムオペレーティングシステム- SABREはそのようなシステムの最初のものの1つでした
さらに読む
- Oz, Effy (1994 年 10 月)。「専門的基準が緩い場合: CONFIRM の失敗とその教訓」。Communications of the ACM。37 ( 10)。米国ニューヨーク市: ACM: 29–43。doi : 10.1145 / 194313.194319。ISSN 0001-0782。S2CID 10723179。
参考文献
- ^ MVS
- ^ 「IT プロジェクトの失敗例」。2010 年 3 月 30 日時点のオリジナルよりアーカイブ。2010 年 6 月 12 日閲覧。
- ^ 「THE STANDISH GROUP REPORT」(PDF) . The Standish Group . 1995年. 2010年6月12日閲覧。
