Крушение унаследованной системы, имевшей для компании Comair критически важное значение, — классический пример ошибки при организации управления рисками, которая обошлась авиаперевозчику в 20 млн. долл. и серьезно повредила его репутации.
Когда в 1997 году Эрик Бардс начал работать в ИТ-службе компании Comair, одно из первых совещаний с его участием было посвящено замене унаследованной системы, которую этот региональный авиаперевозчик использовал для управления экипажами рейсов. Приложению, разработанному компанией SBS International, исполнилось уже 11 лет, и оно считалось одним из самых старых. Программа, написанная на Фортране (а в Comair к тому времени не осталось людей, в достаточной мере владевших этим языком), единственная из всех продолжала работать на платформе IBM AIX. Остальные приложения уже были перенесены в среду HP-UX.
В тот период представители SBS активно рекламировали свою новую программную систему управления экипажами Maestro. Одному из руководителей подготовки экипажей Comair на предыдущей работе довелось познакомиться с Maestro — программой, относящейся к первому поколению приложений для Windows. Новый инструментарий показался ему крайне неудобным и неуклюжим.
«Он говорил, что не пожелает такой программы и злейшему врагу», — вспоминал Бардс. Существующая система управления экипажами тоже не отличалась особой элегантностью, но в Comair уже привыкли к ней. Кроме того, к этой программе были приспособлены существующие бизнес-процессы компании. В итоге, в Comair смирились с необходимостью финансирования работ по модернизации устаревшей системы управления экипажами, но одновременно поставили задачу подобрать более достойную замену.
Потянулось долгое ожидание. Перспектива замены системы управления экипажами на более совершенную замаячила примерно через год. С поставщиком предполагалось определиться в 2000 году. Однако этого не произошло. В последующие несколько лет компания Comair начала терять свои рыночные позиции. Это было обусловлено целым рядом событий. Надвигался 2000 год, а вместе с ним и известная проблема, требующая решения. В 2000 году независимого перевозчика проглотил более крупный игрок — корпорация Delta. Захлестнувшая компанию в 2001 году забастовка летчиков еще более усугубила финансовое положение Comair, а после 11 сентября кризис накрыл всю авиационную отрасль.
В прошлом году руководство компании наконец дало добро на внедрение альтернативной системы от Sabre Airline Solutions, но переход стал осуществляться совсем не так быстро, как хотелось бы. Сбой устаревшей системы в самом разгаре сезона отпусков парализовал деятельность всей авиакомпании. В результате было задержано 3900 рейсов, пострадало почти 200 тыс. пассажиров. Сбой стоил Comair и ее владельцу Delta Air Lines 20 млн. долл. и утраченной репутации. Кроме того, он привлек к компании пристальное внимание Министерства транспорта.
Вполне вероятно, всего этого удалось бы избежать, если бы руководство Comair и Delta уделяло больше внимания анализу рисков, связанных с влиянием системы на выполнение авиакомпанией своих повседневных операций, и предприняло необходимые меры для снижения этих рисков. Однако выяснилось, что замену системы вовсе не собирались включать в список приоритетных задач, а ИТ-службе так и не удалось побороть у руководства чувство самоуспокоенности. Наверное, всем было понятно, что нужно продолжать поддерживать старые приложения и архитектуру, которые обеспечивали бы дальнейшее развитие растущего регионального перевозчика. Компания даже разработала пятилетний план стратегического развития, но сжатые сроки внесли в процесс свои коррективы, и в конечном итоге возобладала иная точка зрения.
После вхождения компании в состав Delta бывшие сотрудники Comair отмечали, что руководство ИТ-службы так и не провело тщательного анализа процесса управления, способного заставить корпорацию инвестировать средства в обновление информационной системы, пока не стало слишком поздно. В Delta, напротив, резко ограничили капиталовложения в Comair. А это с большой вероятностью могло привести к самым тяжелым последствиям. Сбой в работе системы планирования, которая эксплуатировалась в течение почти 20 лет, не только заставил руководство Delta задуматься о качестве обслуживания клиентов и о финансовом положении Comair, но и напомнил неприглядные истории ушедших в небытие компаний, которые постоянно откладывали замену унаследованных систем «еще совсем на чуть-чуть».
Несостоявшийся пятилетний план
Сегодня Comair — это региональный авиаперевозчик, который работает в 117 городах и ежедневно выполняет 1130 рейсов, обслуживая 30 тыс. пассажиров. В каждом полете задействован экипаж из трех-четырех человек. В 1984 году, когда обязанности финансового директора и директора по управлению рисками Comair стал выполнять Джим Дабликер, у компании имелось всего 25 самолетов. По словам Дабликера, занимавшего в период с 1992-го по 1999 год пост директора Comair по управлению рисками и ИТ, все планирование команда управления полетами осуществляла с помощью бумаги и ручки. Впрочем, в 1986 году Comair арендовала у SBS программное обеспечение, которое отслеживало состав и полеты экипажей, регистрируя часы налета в соответствии с требованиями отраслевых нормативных актов и федерального законодательства.
Стоить отметить, что система работала довольно неплохо.
В 1993 году Comair купила реактивный самолет — первый реактивный самолет Bombardier CRJ в отрасли — предназначенный для выполнения региональных рейсов. Оборот компании рос очень быстрыми темпами. Но в 1996 году собственные реактивные самолеты появились и у American Eagle, Mesa и Continental Express.
«В этом смысле компании стали равными конкурентами, — вспоминает Дабликер, являющийся ныне консультантом авиаперевозчиков. — Нужно было заняться поисками более совершенных способов эффективного решения стоящих перед нами задач».
С годами у Comair, как и у большинства других авиакомпаний, накопилось множество разнообразных приложений, начиная от программ составления расписания для экипажей и заканчивая механизмами резервирования билетов для пассажиров.
«У нас был целый ряд довольно старых систем, — вспоминал Дабликер. — Они эксплуатировались в течение семи, восьми и даже девяти лет».
К сожалению, выявить момент, когда система управления экипажами уже исчерпала себя, непросто. Ведь это не ржавчина на самолете, которую видно невооруженным глазом. Но как бы то ни было, ни для кого не секрет, что информационные системы устаревают.
«Все здесь происходит точно так же, как и с физическими активами, — заметил бывший технический директор Delta, а ныне вице-президент EDS по приложениям и отраслевым архитектурам Майк Чилдресс. — С годами они теряют устойчивость, и приходится уделять слишком много внимания их технической поддержке».
В 1998 году Дабликер и другие члены комитета управления ИТ пригласили к себе представителей компании Sabre, специализирующейся на разработке программного обеспечения для авиакомпаний. Консультанты должны были помочь им выработать долгосрочную стратегию развития ИТ и решить вопросы, связанные с устаревшими системами и архитектурой. Пять месяцев ушло у консультантов на то, чтобы определить потребности бизнеса в информационных технологиях. Они изучили существующую информационную инфраструктуру авиакомпании и предложили рассчитанный на пять лет стратегический план, в котором помимо всего прочего указывалось, какие системы необходимо исключить, заменить или дополнить. Оговаривались и сроки выполнения этих работ.
От системы планирования экипажей предполагалось отказаться.
«Принятие решения о замене системы не вызывало сомнений, — вспоминал Дабликер. — Приложение уже давно устарело. Его дальнейшая эксплуатация была сопряжена с немалым риском, а в мире имелись гораздо более прогрессивные инструменты. Замена системы сулила определенные выгоды даже в финансовом плане, поскольку способствовала повышению эффективности работы экипажей и обеспечивала лучший контроль за расходами».
Но на дворе стоял 1998-й, и в последующие два года основное внимание ИТ-службы было приковано к решению «проблемы 2000 года». К 1999 году основной объем работы в рамках пятилетнего плана уже был выполнен или находился в процессе выполнения, включая внедрение системы электронных билетов, модернизацию корпоративной сети, замену комплекса технической поддержки и обслуживания (еще одна унаследованная система, написанная на Коболе, эксплуатация которой также была сопряжена с высоким риском) и внедрение приложения управления доходами.
Замена системы составления графика работы экипажей уже давно стояла на повестке дня. Но за полтора десятилетия ее эксплуатации развитие бизнеса было тесно привязано к системе SBS, и большая часть бизнес-процессов управления экипажами Comair формировалась непосредственно на ее основе. Достаточно взглянуть на договор, который пилоты подписывали с Comair. Определение рабочего дня здесь связано с особенностями старого приложения управления экипажами SBS, в котором использовалось представление времени, выраженное в минутах. (В месяце, состоящем из 31 дня, согласно данному представлению, насчитывается 44 640 минут.)
«Вот лишь один из аргументов, объясняющих, почему заменить подобную систему практически невозможно», — пояснил Джон Паркер, бывший ИТ-директор Delta и ветеран этой корпорации, проработавший там 17 лет. Сегодня Паркер занимает пост директора информационной службы компании A.G. Edwards & Sons.
Тем не менее требования к новой системе были определены, и специалисты ИТ-службы приступили к ее поиску. По словам Дабликера, окончательное утверждение поставщика было намечено на 2000 год.
Но в середине 1999 года Дабликер покинул компанию, а вскоре руководство Delta объявило о своих планах приобретения Comair.
Передача дел
Причины покупки Comair — одного из наиболее удачливых региональных партнеров — представлялись достаточно очевидными. Delta просто делала деньги. Компания имела лучшие в отрасли показатели как по рейсам, выполненным вовремя, так и по их отмене и потерям багажа. Удача сопутствовала ей и на фондовом рынке.
«До вхождения в состав Delta Comair считалась одним из наиболее успешных и хорошо управляемых региональных перевозчиков в стране, — заметила аналитик отрасли авиаперевозок, основатель компании PlaneBusiness.com Холли Хегеман. — Она по праву заслужила репутацию победителя».
По общему мнению, в Delta полагали, что не стоит вмешиваться, если дела и так идут прекрасно. Даже в области ИТ все представлялось вполне благополучным. На бумаге у Comair имелись планы реализации перспективных проектов, хороший бюджет, словом, все, что хотелось бы видеть ее новым владельцам.
«С точки зрения внешнего наблюдателя, у менеджеров Delta не было никаких поводов вмешиваться в работу ИТ-службы Comair», — заметила Хегеман.
Единственное, к чему новый владелец проявил пристальное внимание, касалось области маркетинга. Вся маркетинговая служба Comair была обновлена уже через несколько дней после совершения сделки.
Сотрудников же Comair, как обычно бывает в таких случаях, не особо радовал приход нового хозяина.
«Сразу возникли трения, — вспоминала Хегеман. — Топ-менеджеров Comair отнюдь не прельщала перспектива стать частью Delta».
В результате во многих отношениях оно продолжало проводить независимую политику, несмотря на то, что формально компания полностью принадлежала Delta, и все основные расходы теперь утверждались новым владельцем.
После ухода Дабликера должность директора ИТ-службы оставалась вакантной в течение нескольких месяцев. В начале 2000 года курировать вопросы, связанные с ИТ, стал старший вице-президент по полетам Майк Стюарт. Затем на пост директора ИТ-службы была назначена Шерри Курлас-Шалк, работавшая в компании с 1990 года.
«Между тем все по-прежнему предпочитали не высовываться, — отметил Бардс, покинувший Comair в 2003 году, заняв должность старшего системного архитектора в компании Compuware, которая специализируется на разработке программного обеспечения и предоставлении ИТ-услуг. — После затянувшейся неопределенности в компании ощущался явный недостаток твердой руки, способной привести ИТ-проекты в порядок. Все ждали, что за продвижение проектов возьмется кто-то другой. Представители бизнес-подразделений ожидали проявления активности от ИТ-службы. А сотрудники ИТ-службы хотели, чтобы инициатива исходила от бизнес-подразделений».
Выполнение заданий пятилетнего плана, сроки которых должны были регулярно пересматриваться, откладывалось.
В 2001 году забастовка пилотов, продолжавшаяся с марта по июнь, привела к тому, что 90% рейсов Comair и Delta, которые совершались из международного аэропорта Цинциннати, пришлось отменить. Comair временно закрыла залы аэропорта в Цинциннати, ежедневно лишаясь доходов более чем от 800 рейсов. Убытки Delta за квартал составили около 200 млн. долл. Впрочем, и после окончания забастовки все мысли сотрудников группы управления полетами, которые являлись основными пользователями системы планирования экипажей, были направлены лишь на то, чтобы поднять самолеты в воздух.
«Для того чтобы авиакомпания заработала вновь, недостаточно лишь включить рубильник, — пояснил Бардс. — Прекращая функционировать, вы теряете приобретенный импульс, лишаетесь инерции, а начинать все заново становится совсем непросто».
Естественно, в этот период никто даже и не думал (или почти не думал) о замене системы планирования экипажей.
А затем наступило 11 сентября. Разрушительная волна накрыла больших и маленьких перевозчиков, довела до банкротства ряд крупнейших авиакомпаний. И хотя Delta удалось избежать этой печальной участи, за последующие четыре года компания потеряла почти 8,5 млрд. долл. Непрерывное давление со стороны рынка заставляло ее снижать цены.
«Восстановление финансирования модернизации системы управления экипажами в тот период представлялось совсем неочевидным, особенно если учесть, что утверждение инвестиций в Delta редко когда проходит с первого раза, — заметил Бардс. — Руководство хотело получить более глубокий анализ. Ему нужны были достаточно определенные прогнозы окупаемости данного проекта».
В Delta отказались комментировать эту историю и посоветовали нам обратиться в Comair. Пресс-секретарь Comair Ник Миллер ограничился лишь осторожным заявлением: «Сегодня приходится признать, что авиационная отрасль и мы вместе с ней переживаем тяжелые времена, поэтому, принимая решение о проведении инвестиций в технологии, нам нужно действовать крайне осмотрительно».
Тем не менее в конце 2002 года сотрудники ИТ-службы Comair все же вернулись к вопросу замены системы управления экипажами и попросили ряд производителей, включая Sabre и SBS, продемонстрировать им свои наработки. В дальнейшем в Comair сузили круг возможных поставщиков и ограничились рассмотрением продуктов лишь одной компании, название которой держалось в секрете. Впрочем, когда начались переговоры о стоимости проекта, имя поставщика перестало быть тайной. В то же время ни в Comair, ни в Delta не форсировали процесс реализации проекта, несмотря на то, что система планирования экипажей была (и, согласно последнему отчету бюллетеня Regional Aviation News, остается) самым старым приложением регионального авиаперевозчика.
В конечном итоге Comair все же удалось добиться утверждения кураторами из Delta проекта замены унаследованного программного обеспечения. В июне 2004 года с компанией Sabre было подписано соглашение о развертывании в Comair ее системы AirCrews Operations Manager. Внедрение наметили на начало 2005 года. Но когда этот срок пришел, было уже слишком поздно.
Еще 16 декабря финансисты Comair с удовлетворением сообщали о том, что операционная прибыль компании по итогам третьего квартала 2004 года составила 25,7 млн. долл. А уже через неделю жестокая снежная буря обрушилась на штат Огайо. Вместе со снегом в воздухе летали замерзшие крупинки льда. Борьба с обледенением затянулась, и колеса сразу нескольких реактивных самолетов примерзли к земле. С 22 по 24 декабря Comair вынуждена была отменить или задержать 91% своих рейсов.
Выявилась и другая проблема. Совершенно неожиданно для сотрудников компании выяснилось, что приложение планирования экипажей рассчитано на обработку лишь 32 тыс. изменений в течение месяца. Превышение установленного разработчиками ограничения наступило в самое неподходящее время. В канун Рождества внесение в планы изменений, вызванных непогодой, привело к краху системы. В результате все 1100 рождественских рейсов Comair пришлось отменить. Десятки тысяч пассажиров вынуждены были проводить рождественские каникулы дома. А 26 декабря компания отменила 90% рейсов, породив новую волну возмущения со стороны клиентов.
Возможность перехода на работу с резервной системой отсутствовала. Поставщику понадобился целый день для того, чтобы хотя бы частично восстановить работоспособность программного обеспечения. А в полном объеме функционирование системы было восстановлено лишь 29 декабря.
Главный урок: управляйте вашими рисками
По мнению экспертов, все несчастья Comair — классический пример неправильного управления операционными рисками. Ответственность за это несут представители как Comair, так и Delta. Сотрудникам ИТ-службы Comair следовало провести анализ рисков, который позволил бы предупредить руководство Delta об опасности отказа от скорейшей замены унаследованной системы. Внимание Delta к результатам данного анализа необходимо было привлекать вновь и вновь, вплоть до начала финансирования модернизации системы. Аналогичным образом ответственным лицам Delta следовало внимательно изучить операции Comair и провести свой собственный анализ рисков, которым подвергался авиаперевозчик.
«Все, что способно повредить имени или репутации родительской компании, необходимо тщательно отслеживать, — говорит бывший сотрудник ИТ-службы Delta. — В конечном итоге Delta пришлось столкнуться с худшим из возможных сценариев развития событий в Comair, который вполне можно было спрогнозировать на основе оценки рисков».
То, что произошло с Comair, едва ли можно назвать исключением. Старые унаследованные системы с «зелеными экранами» до сих пор продолжают эксплуатироваться во многих компаниях, хотя они и не в состоянии обрабатывать сегодняшние транзакции с должной скоростью.
«Надежность унаследованной системы обратно пропорциональна числу приложений, которыми она обрастает с годами», — пояснил бывший директор ИТ-службы Delta Чарли Фельд, работающий ныне в компании EDS.
Хуже всего, что в большинстве организаций операционные риски не учитываются при принятии решений, связанных с выполнением повседневных операций. Именно поэтому в Comair все закончилось весьма печально. Директор Cutter Consortium по управлению корпоративными рисками Роберт Чаретт считает, что руководство Comair так и не извлекло необходимого урока из того, что произошло: так, Миллер объясняет неудачи компании природными катаклизмами.
«Если погода снова не преподнесет нам сюрпризов, подобная ситуация никогда больше не повторится», — заявил он.
Обозреватели отрасли признают, что убедить руководство сначала Comair, а затем и Delta в необходимости замены системы представителям ИТ-службы оказалось весьма нелегко. Но при наличии результатов анализа рисков, обусловленных отказом от модернизации, сделать это было бы значительно легче.
«Необходимые решения на рынке уже имеются, — отметил Фельд. — Вопрос заключается лишь в том, сумеют ли сотрудники ИТ-службы грамотно составить план модернизации, рассчитанный на много лет, и подобрать себе партнеров, которые помогли бы им трансформировать унаследованные системы должным образом. Потому что упущенное время грозит вам серьезной катастрофой».
Инициативы наказуемы
Потеряв почти все, что Comair заработала в предыдущем квартале, руководство Delta решило наконец вмешаться. В январе нынешнего года президент Comair Рэнди Радемахер, ветеран, проработавший в компании 20 лет, был смещен со своей должности, а его обязанности руководство Delta возложило на Фреда Баттрелла, генерального директора подразделения Delta Connection, отвечающего за сеть региональных перевозчиков. Вскоре после отставки Радемахера Стюарта тоже попросили уйти. Некоторые утверждают, что в региональное подразделение решено было добавить побольше свежей крови Delta.
Впрочем, посмотрим, начнет ли Delta вкладывать деньги в информационные технологии Comair. В ежегодном отчете Delta за 2004 год говорилось о том, что в 2005 году компанию ждут новые серьезные убытки. Возможно, даже инициирование дела о банкротстве.
«А когда авиакомпания находится в сложном положении, найти деньги на обновление и модернизацию ИТ становится гораздо труднее, — заметил Чилдресс. — На самом деле, в Delta вовсе не исключают возможности продажи Comair или какой-то другой региональной авиакомпании для пополнения своего банковского счета».
Между тем Бардс продолжает регулярно встречаться со своими бывшими коллегами из Comair.
«На вопрос, предпочитают ли они, как и прежде, не высовываться, я получаю утвердительный ответ, — сообщил он. — А следовательно, инициативы, как и в былые времена, остаются наказуемыми».
Вот и сейчас в Comair по-прежнему работает система управления экипажами SBS почти 20-летней давности, хотя и относятся к ней с гораздо большей осторожностью. В SBS предложили построить своеобразный мост, разделив унаследованную систему на два модуля — один для составления расписания пилотов, а второй для расписаний бортпроводниц. В каждом из планов ежемесячно может присутствовать не более 32 тыс. транзакций. Учитывая эти ограничения, сотрудники Comair начали ежедневно формировать отчет, позволяющий следить за объемом транзакций, которые были обработаны системой. Что касается плана замены, его по-прежнему никто не отменял.
Жизнь с унаследованной системой
Иногда унаследованные информационные системы похожи на бомбы с часовым механизмом. Даже если и найдется им замена, это потребует времени. И уж если вы вынуждены в течение определенного периода жить с унаследованной системой, для того чтобы обезопасить свой бизнес, необходимо помнить о соблюдении следующих правил.
- По крайней мере, раз в год выполняйте проверки на эффективность и составляйте план распределения ресурсов.
- Тщательно тестируйте критически важные приложения, особенно на возможность переполнения буферов, которое приводит к сбоям в работе приложения.
- Наметьте план резервного копирования и восстановления, к которому можно будет прибегнуть в случае катастрофических отказов унаследованной системы.
- Если, на ваш взгляд, унаследованная система имеет для бизнеса настолько важное значение, что замена невозможна, необходимо продумать план ее модернизации, который позволил бы уменьшить риски, связанные с эксплуатацией устаревшей системы.
Риск может оказаться слишком высок
«Само по себе то, что унаследованной системе Comair исполнилось 18 лет, еще не является признаком необходимости ее замены, — подчеркнул директор Cutter Consortium по управлению корпоративными рисками Роберт Чаретт. — Помимо срока службы есть и другие, более значимые факторы, которые делают эксплуатацию вашей системы крайне рискованной».
- Среди персонала компании не осталось никого, кто хорошо знал бы язык программирования, на котором она написана.
- Невозможно найти ее исходный код и документацию, а единственный человек, имевший представление об ее архитектуре, уволился много лет назад.
- Вокруг не осталось никого, кто мог бы восстановить работоспособность системы в достаточно короткий срок.
- Тестирование систем резервного копирования не проводилось долгие годы или же создание резервных копий осуществляется вручную, и процедура эта слишком сложна.
- Компания, разработавшая систему, прекратила свое существование или занимается совсем другими делами.
- Нет уверенности, что в части масштабируемости у системы еще остался какой-то запас с момента ее последнего обновления.
- Обнаружилось, что в систему интегрированы и другие приложения, о существовании которых ранее не было известно.
- Выполнение организацией повседневных операций во многом зависит от работоспособности системы.
Как обосновать необходимость обновления
Выбить у руководства финансовые ресурсы, необходимые для управления рисками или замены системы, во многих компаниях очень тяжело. И это понятно, ведь замена всего лишь одной старой системы требует значительных затрат.
Чтобы преодолеть весьма распространенное нежелание проводить инвестиции в ИТ, директорам ИТ-служб необходимо доказать, что унаследованная система имеет критически важное значение для выполнения компанией своих операций, а отказ системы может отрицательно отразиться на положении организации на рынке. Опытные ИТ-руководители, в частности, Джон Паркер из A.G. Edwards & Sons, советуют проводить анализ соотношения между стоимостью и эффективностью, который учитывает не только стоимость замены унаследованных систем, но и расходы на проведение работ, позволяющих исключить риск их отказа.
«Именно в этом и заключается основное преимущество подобных решений с точки зрения бизнеса, — пояснил Паркер. — К примеру, в компании Comair отказ от замены системы управления экипажами повлек за собой простой в течение нескольких дней и потерю 20 млн. долл. из-за недополученной выручки и высоких текущих расходов. Кроме того, не следует забывать, что замена унаследованной системы сулила множество потенциальных выгод — снижение стоимости выполнения операций и осуществления технической поддержки, улучшение обслуживания клиентов, повышение степени интеграции и адаптируемости системы и даже увеличение общего объема доходов».
Сотруднику ИТ-службы страховой компании AIG Кевину Мюррэю в 2002 году удалось грамотно обосновать необходимость замены унаследованной системы. В качестве основных аргументов Мюррэй выбрал оценку потерь от потенциального отказа устаревшей системы, а также больших расходов на ее техническую поддержку. Эта сумма, по его словам, вполне сравнима со стоимостью замены системы.
«Я знал, что в случае модернизации общая стоимость владения уменьшится, и мы сможем быстрее реагировать на запросы рынка», — отметил он.
Приведенные доводы попали точно в цель.
«У нашего генерального директора буквально отвисла челюсть, — вспоминал Мюррэй. — Он вместе с другими членами совета директоров наконец увидел реальные размеры затрат и понял, что после перехода на новую технологию мы сможем добиться 30-процентной экономии. Мой план сработал идеально».
При обосновании проектов ИТ-руководителям нужно обязательно обращаться к анализу рисков, но при этом не следует забывать и о достоинствах, которыми обладает предлагаемая система.
«Гибкость и получаемая экономия могут оказаться как раз тем сеном, которое заставит нашего верблюда вернуться», — заметил Мюррэй, занимающий сегодня пост ИТ-директора компании AXA и продвигающий там аналогичный проект замены унаследованной системы.
ИТ-руководители, которые сегодня не пытаются доказать начальству необходимость финансирования соответствующих проектов, рано или поздно придут к тому, что менять рискованную унаследованную систему все равно придется.
«Когда события совершенно неожиданно для вас начинают развиваться по наихудшему сценарию, легко впасть в отчаяние, — предупреждает Паркер. — Нужно очень быстро принимать решение о переходе на другую платформу, а в таких условиях скоропалительные решения зачастую оказываются непродуманными. Поэтому гораздо лучше проводить стратегическую линию, направленную на полную замену унаследованных систем, чем ограничиваться тактическими ответными мерами, призванными временно восстановить их работоспособность после очередного отказа»
Stephanie Overby. Bound To Fail. CIO Magazine. May 1, 2005