Руководители проектов в Hewlett-Packard знали, что именно может пойти не так при развертывании системы планирования ресурсов предприятия. Но они даже не предполагали, что неприятности могут случиться одновременно, причем в таком крупном масштабе.

Руководители проектов в Hewlett-Packard знали, что именно может пойти не так при развертывании системы планирования ресурсов предприятия. Но они даже не предполагали, что неприятности могут случиться одновременно, причем в таком крупном масштабе.

Привычка постоянно подозревать худшее противоречит человеческой природе. Но когда дело касается ИТ-проектов, пессимизм — иначе известный как планирование чрезвычайных обстоятельств — единственный способ, позволяющий предотвратить переход от маленьких технологических проблем к крупномасштабному стихийному бедствию.

К сожалению, никто не может заставить себя предусмотреть это планирование в достаточном объеме.

У Кристины Хэнгер было не много причин для пессимизма в мае 2004 года, когда она переводила одно из крупнейших в США подразделений компании Hewlett-Packard на централизованную систему планирования ресурсов предприятия (ERP) от SAP. Будучи руководителем ИТ-проекта по слиянию, заключавшегося в приобретении HP компании Compaq двумя годами ранее, Хэнгер, занимающая должность старшего вице-президента по операциям на южно- и североамериканских рынках и по ИТ, поставила непревзойденный рекорд успешного перевода пяти промышленных групп в рамках упомянутых выше компаний на одну из двух систем SAP.

Жиль Бушар, главный управляющий по ИТ и исполнительный вице-президент по операциям на мировом рынке, компания HP

У Хэнгер были все причины полагать, что и в шестой раз все пройдет успешно. Несмотря на это, она понимала, что нужно быть готовыми к появлению проблем. Подразделение Industry Standard Servers (ISS), вовлеченное в этот последний проект, приносит приблизительно 7,5 млрд. долл. в год и является наиболее крупным из всех подразделений, которые Хэнгер до того момента переводила на систему SAP. Поэтому она взяла за основу план чрезвычайных обстоятельств, разработанный ее помощниками для других пяти случаев, и внесла в него уточнения, согласовав цифры с более крупными объемами продаж подразделения ISS. Хэнгер планировала, что путаница и неразбериха продлятся недели три, и в основном уделила внимание проблемам, которые могли возникнуть в результате завершающей настройки для совместной работы действующей системы учета поступлений заказов и новой системы SAP. Чрезвычайный план был направлен также на то, чтобы снизить негативное влияние на работу коммерческих подразделений. В HP предусмотрели дополнительные серверные мощности, которых хватило бы на три недели, оборудовали свободную часть завода HP в Омахе, чтобы быть наготове и справиться с любым наплывом заказов, которые требовали специальной конфигурации (например, редкого компонента или необычной комбинации программного обеспечения) и не могли быть заготовлены заранее.

Но подготовленный чрезвычайный план был недостаточно пессимистичным.

С начала июня — того момента, как систему ввели в эксплуатацию, — и в течение всего месяца практически 20% клиентских заказов на серверное оборудование сразу же застряли намертво между старой системой учета поступлений заказов и новой системой SAP. Сама ИТ-проблема была не очень серьезной: кое-какие неувязки в моделировании данных между уже существующей и новой системами не давали системе SAP обрабатывать некоторые клиентские заказы на оборудование нестандартной конфигурации. Эти ошибки в программировании были исправлены в течение четырех или пяти недель. Но Хэнгер и ее деловые партнеры из подразделения ISS, члены руководящего комитета по данному проекту, не могли даже представить себе, насколько негативно эти программные сбои скажутся на бизнесе.

Невыполненные заказы начали быстро накапливаться, и компания не успевала вручную исправлять программные недочеты для того, чтобы сохранить скорость серверного потока, удовлетворяющую покупательский спрос. Разгневанные клиенты хватались за телефон и звонили в HP или — что значительно хуже — их основным конкурентам, Dell или IBM. На таком товарном рынке, как рынок продаж серверного оборудования, покупательская преданность зиждется на способности компании сконфигурировать оборудование под конкретный заказ и доставить его вовремя. Большую часть летнего сезона компания HP не могла обеспечить ни то, ни другое. В третьем квартале на совещании 12 августа председатель совета директоров и главный управляющий HP Карлтон Фьорина определила финансовый ущерб в 160 млн. долл.: на 120 млн. долл. заказов, в результате невыполнения которых потеряно 40 млн. долл. прибыли. Это больше, чем стоимость самого осуществляемого проекта, которую AMR Research оценивает в 30 млн. долл.

Заголовки газет утверждали, что виной всему ИТ-катастрофа, но действительной причиной катастрофы в HP стали несколько относительно небольших ИТ-ошибок, которые, как снежный ком, превратились в намного более значительную проблему для бизнеса: неспособность справиться с задолженностью по невыполненным заказам. Эту катастрофу можно было бы предотвратить, не пытаясь ликвидировать любую возможность для совершения ошибок при масштабном переносе ИТ-системы, что практически невозможно, а заранее просчитав все последствия для корпоративной цепочки поставок, к которым может привести осуществление подобных проектов.

В большинстве компаний ИТ-руководители не имеют отношения к цепочке поставок, поэтому им очень сложно представить, что произойдет с продажами, если испытываемая система не будет работать должным образом несколько дней или недель. Сотрудники коммерческих отделов с трудом представляют себе программный сбой ИТ-системы, который выходит из стен информационного центра и становится причиной потерь продаж на сотни миллионов долларов. Связь между причиной и следствием настолько неявная, что ее почти невозможно разглядеть.

Но если ИТ-руководители хотят, чтобы из-за относительно небольших ИТ-проблем на них перестали возлагать всю ответственность за понесенные компанией убытки в сотни миллионы долларов, они должны убедить руководство коммерческих подразделений в том, что масштабные корпоративные проекты по замене программного обеспечения несут с собой большой риск для компаний, имеющих крупные цепочки поставок. Они должны использовать свою осведомленность в данном вопросе для того, чтобы создать — при полной поддержке и взаимодействии с коммерческими подразделениями — бизнес-план на случай чрезвычайных обстоятельств для ИТ-проектов, что требует таких же затрат сил и энергии, как создание проектных планов для нового программного обеспечения.

Кристина Хэнгер, старший вице-президент по операциям на южно- и североамериканских рынках и по ИТ в HP

«Вероятная выгода для цепочки поставок в подобных проектах намного больше, чем ИТ-издержки, — утверждает Билл Свэнтон, вице-президент по исследованиям AMR Research. — Но вероятный риск для цепочки поставок также намного больше». Если чрезвычайное бизнес-планирование по-прежнему будет играть второстепенную роль в управлении ИТ-проектами, данная проблема будет только усугубляться, так как компьютерные системы становятся все более мощными, средства интеграции совершенствуются и компании используют для своих ключевых бизнес-процессов все меньшее количество ИТ-систем.

Возвращаясь к событиям тех дней, директор информационной службы и исполнительный вице-президент HP по операциям на мировом рынке Жиль Бушар считает, что проблемы с моделированием данных между существующей системой и системой SAP не были причиной 160-миллионных убытков компании. Он обращает внимание на то, что компания HP не смогла справиться со скоростью поступления заказов в цепочке поставок после того, как данные проблемы были обнаружены. «Это в основном был вопрос производительности и обеспечения материальных и производственных мощностей, — утверждает он. — У нас был ряд небольших проблем, каждая из которых по отдельности не представляла серьезной угрозы. Но вместе они породили настоящее стихийное бедствие».

Рамки проектного менеджмента

Когда чрезвычайное планирование предотвращает катастрофу, практически невозможно сказать, все ли необходимое было сделано. Помните проблему 2000 года? Многие руководители промышленных предприятий до сих пор подозревают, что миллиарды, потраченные на решение этой проблемы, были просто тратой денег, потому что ничего так и не произошло. ИТ-руководители, которые пытаются предупредить высшее руководство своей компании по поводу того, что программные сбои могут стоить компании миллионы долларов, практически стопроцентно получат в ответ: «Тогда сделайте так, чтобы их не было!»

Вот почему управление ИТ-проектами стало высоким искусством, в то время как чрезвычайное бизнес-планирование до сих пор переживает период средневековья. Но проблемы, которые могут нанести вред корпоративному проекту по установке программного обеспечения, возникают постоянно, учитывая, что такие проекты осуществляются для все большего числа программ и бизнес-процессов. И существует практически бесконечное множество комбинаций маленьких проблем, которые в сочетании друг с другом могут иметь разрушительные последствия. В конечном счете компании выбирают более рискованный путь, пытаясь защитить себя от сбоев при установке нового программного обеспечения с помощью самых лучших методов управления ИТ-проектами, а не планируя заранее обходные пути работы без применения электроники для того, чтобы доставить продукцию потребителям в случае поломки электронной системы.

Не только HP, но и другие компании столкнулись с похожими катастрофическими последствиями для бизнеса, выросшими из относительно небольших ИТ-ошибок. Например, компания Nike столкнулась с проблемой при подключении приложения для планирования покупательского спроса к централизованной системе SAP в 2001 году. Проблема была решена в течение нескольких недель. Но из-за того, что у компании не было соответствующего бизнес-плана на случай чрезвычайных обстоятельств, небольшой программный сбой стоил Nike 100 млн. долл. дохода.

Как в случае с Nike, так и в случае с HP ИТ-проблемы возникли из-за сочетания факторов, которые было бы сложно исключить в процессе проектного планирования. В HP Хэнгер говорит, что ее команда тестировала связи между действующей клиент-серверной системой обработки заказов и системой SAP. И эти связи работали прекрасно для заказов стандартной конфигурации, а также для некоторых заказов со специальной клиентской конфигурацией.

Но команда Хэнгер не могла адекватно оттестировать заказы, подразумевающие клиентскую конфигурацию, так как маркетинговая группа не рассмотрела все варианты конфигураций, которые могут потребовать заказчики. Когда установленную систему запустили и она начала функционировать, то часть клиентских конфигураций проходила сквозь нее, а часть — нет. Те, что не проходили, выпадали в «мертвую зону» и находились там без движения до тех пор, пока кто-нибудь не введет эти заказы вручную. «Наши клиенты хотели немного больше гибкости, маневренности при покупке и конфигурации своего серверного оборудования, — говорит она. — А у нас не всегда для этого правильно были смоделированы данные». Могла Хэнгер протестировать большее число конфигураций, прежде чем запускать систему в эксплуатацию? Да. Могла ли ее команда предвидеть их все? Наверное, нет.

Вспоминая ту ситуацию, Жиль Бушар говорит, что ему следовало иметь в резерве дополнительные производственные мощности до запуска системы ERP

Но это была не единственная проблема. Команда Хэнгер обучила сотрудников службы работе с покупателями, которые должны были использовать новую систему, за две недели до ее запуска. Все сотрудники прошли тест, который показал, что они умеют вносить заказы без ошибок. Но когда система была введена в действие, эти сотрудники с трудом вспоминали то, чему их обучали, и нервничали, вычисляя количество выпадающих заказов. Команда Хэнгер предложила провести повторное обучение сотрудников через две недели после запуска системы, но к тому моменту слишком много заказов потерялось, чтобы можно было исправить ситуацию. «Мы могли бы поправить положение вещей, если бы ввели повторное обучение сотрудников через неделю после запуска системы, а не через две недели», — утверждает она.

Все стало еще хуже, когда покупательский спрос на системы со специальной конфигурацией (под заказ) резко вырос на 35% в июне, вопреки тому, что предсказывали все прогнозы покупательского спроса, сделанные HP. А чрезвычайный бизнес-план Хэнгер был разработан для нормального спроса в течение всего лета. «Мы планировали использовать дополнительные производственные мощности в течение трех недель при спросе 50 на 50 на серверы стандартной конфигурации и серверы с конфигурацией под заказ», — говорит она. Завод в Омахе, который остановил работу нескольких своих линий для того, чтобы справиться с наплывом заказов в течение трех недель, быстро оказался переполнен. Компания HP поспешила подготовить второй завод в Европе в помощь первому две-три недели спустя, но к тому моменту было уже слишком поздно.

Раз невыполненные заказы накапливались, единственное, что могла сделать HP, — повысить скорость доставок. В зависимости от размера товара и расстояния до точки отгрузки дополнительная стоимость возросла примерно на 35-40%, по данным HP, и позволила компании выиграть несколько дней при доставке заказов, которые и так уже были задержаны на недели.

Чрезвычайный план, которого не было

Судя по традиционному чрезвычайному ИТ-планированию, HP уже вышла за рамки чувства долга. Чаще всего чрезвычайное ИТ-планирование уделяет основное внимание подготовке дополнительных программ, а не дополнительных товаров. Традиция гласит: для того, чтобы обеспечить безболезненный переход на новую систему, следует подготовить резервную систему, которая поможет в случае проблем с запуском. Или хотя бы следует продумать алгоритм возврата для того, чтобы иметь возможность вернуться к старой системе, если понадобится.

Но Бушар и Хэнгер утверждают, что ни одна из этих стратегий не помогла бы в данном случае, учитывая масштаб продаж серверного оборудования HP. «Если бы у нас одновременно были запущены две системы, это бы означало, что каждый поставщик имел бы для нас заказ и в старой системе, и в новой, — говорит Хэнгер. — При поступлении на производственную линию этот заказ нужно было бы получить дважды, а затем дважды же согласовать». Говорит Бушар: «Создалась бы задолженность из невыполненных заказов в результате неразберихи с этим дублированием».

Что HP следовало сделать, так это создать план для получения заказов и отгрузки товаров, который предполагал бы, что ИТ-системы, планируемой к запуску, не существует. «Предметом чрезвычайного планирования не являются информационные технологии, — говорит Свэнтон из AMR Research. — Оно направлено на то, чтобы были люди, следящие за тем, что происходит, способные определить наличие проблемы и разрабатывающие ряд простых способов справиться с проблемой вручную до полной наладки ИТ-системы. Если на все это потребуется дополнительная куча времени, пусть так. Это зло намного меньшее, чем потеря продаж и финансовый ущерб». Возврат процесса обработки заказов к 50-м годам прошлого века требует определенных перемен в мышлении всех ваших сотрудников, вовлеченных в этот процесс, начиная с сотрудников службы работы с покупателями и заканчивая складскими служащими. Ведь это будет казаться глупой и ненужной затеей — такой же, как представлять, что будет, если солнце завтра не взойдет.

В следующий раз готовьтесь к худшему

Даже внесение в чрезвычайный бизнес-план HP пункта о создании резерва серверного оборудования в расчете на несколько недель могло показаться рискованным, потому что эти дополнительные серверы могли бы остаться невостребованными. В большинстве компаний при принятии подобных решений ИТ-руководителям намного удобнее пытаться исключить риск, связанный с проектом, оттачивая свои навыки проектного менеджмента. Этот путь апеллирует к нашему оптимизму и поиску компетенции, по мнению Роберта Шарэ, президента компании Itabhi, специализирующейся на консультировании по вопросам управления рисками. Чрезвычайное бизнес-планирование, напротив, унылое и дорогостоящее дело.

Но если компании когда-либо соберутся усовершенствовать менеджмент ИТ-проектов, по словам Шарэ, это потребует революционного подхода, который позволит свергнуть принципы, управляющие большинством ИТ-проектов: бюджет и график. «Расходы и график — вот что заставляет людей из рационалистических соображений отбрасывать такие важные аспекты проектного менеджмента, как тестирование программы и обучение», — говорит он.

По словам Шарэ, плохо еще то, что подход «бюджет-график» никогда не помогает во время кризиса. Когда в HP увидели, что система обработки заказов работает некорректно, то направили все усилия на то, чтобы исправить недочеты в программе. Шарэ говорит, что при использовании подхода «событие-действие» проект не двигается вперед до тех пор, пока не отлажена каждая его ступень. Все же проектный менеджмент на основе подхода, управляемого событиями, имеет свои недочеты. Он не является абсолютно надежным, и при неосмотрительном менеджменте проекты могут затянуться навсегда.

Вот что Бушар должен был сделать по-другому. Ему нужно было расширить чрезвычайный план, чтобы тот был рассчитан на пять или шесть недель. Вместо того чтобы пытаться предотвратить ИТ-проблемы, которые были слишком незначительными и складывались в слишком большое число странных комбинаций, было бы проще заранее подготовить к работе резервный завод в Европе и запасти побольше стандартных серверов. В своем интервью журналу CIO он не выделил особо, помогли бы в этой ситуации дополнительные обходные пути, такие как введение заказов вручную.

Если это звучит как перекладывание ответственности, то Бушар всего лишь перекладывает ее из одной руки в другую. В декабре 2003 года он занял должность директора информационной службы и исполнительного вице-президента по операциям на мировом рынке — это один из тех редких случаев, когда ИТ-руководитель также связан и с цепочкой поставок. Помимо того что он более серьезное внимание в настоящее время уделяет чрезвычайному бизнес-планированию, он также находится в процессе реорганизации операций и ИТ-групп в коммерческих подразделениях HP. И на более низкой ступени служебной лестницы, которую занимает Хэнгер, двойная роль Бушара отражается как в зеркале: Хэнгер отвечает как за ИТ, так и за операции на южно- и североамериканских рынках. Более объединенный подход должен повысить уровень взаимосвязи между ИТ- и коммерческими подразделениями, полагает Бушар, и способствовать более четкому определению того, как ИТ-проекты отражаются на коммерческих операциях.

По мнению Бушара, идея, которую необходимо более настойчиво внедрить в сознание сотрудников HP, а также сотрудников любой компании в наши дни, — это идея, которую подразумевает его двойная должность: «Между ИТ и бизнес-процессами существует большая система рычагов, когда вы имеете дело с крупной цепочкой поставок, — объясняет он. — Рассматривать чрезвычайное планирование только с позиций ИТ будет огромной ошибкой. Его нужно рассматривать с позиций объединенного знания как ИТ-процессов, так и бизнес-процессов».

Три ступени к бизнес-плану на случай чрезвычайных обстоятельств

  1. Создайте официальную обучающую группу для сотрудников из коммерческих подразделений, чтобы объяснять им, какой риск для цепочки поставок может создать введение в эксплуатацию масштабной ИТ-системы.
  2. Разработайте план перевода на новую систему, который предполагает тот факт, что система может дать сбой во время окончательного прогона. Дайте осторожную оценку временного периода, в течение которого продлятся системные неполадки.
  3. Продумайте процедуры обработки вручную заказов и доставок на время проблемного периода. Запаситесь дополнительной рабочей силой и производственной мощностью на случай большого объема срочной работы.

Как избежать 120-миллионной задолженности по невыполненным заказам

Чрезвычайный план Hewlett-Packard предусматривал негативные последствия программного сбоя для бизнеса, но не предполагал наихудшего сценария развития событий

Christopher Koch. When Bad Things Happen to Good Projects. CIO Magazine. December 1, 2004