Только управление

Стэн Гибсон

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

Стэн Гибсон

Тот же принцип сохраняет силу и при создании информационных систем. Эта мысль пришла мне в голову во время последней конференции DCI Enterprise Architecture в Бостоне, когда я присутствовал на презентации с весьма интригующим названием “В гуще огня. Уроки успехов и провалов архитектуры корпоративных систем”. Выступал Николас Фьековски, старший консультант фирмы Wyeth-Ayerst Pharmaceuticals (Раднор, шт. Пенсильвания). Он основательно и детально проанализировал неудачную архитектуру крупной корпоративной системы, создававшейся на его предшествующем месте работы. Фьековски не указал названия этой компании, ограничившись лишь замечанием, что это была крупная фирма, но в прошлом году она сдала свои позиции и превратилась во второстепенное предприятие.

Фьековски работал в группе, получившей задание придумать и спроектировать информационную систему следующего поколения. Заместитель директора по информатизации (впоследствии ему первому пришлось подать в отставку) потребовал, чтобы группа выявила наиболее перспективные технологии и положила их в основу архитектуры создаваемой корпоративной системы. Проект, осуществление которого началось в 1993 г., предполагалось завершить к 2000 г. Однако несмотря на то что на эту работу уже были потрачены десятки миллионов долларов, ее в конце концов пришлось прекратить, и в прошлом году группа была распущена.

Что значат неверные ориентиры

В чем крылась причина неудачи? Проект оказался порочен в самой своей основе. Он был далек от задач бизнеса, и технология была его самоцелью. Группа основывала свой проект на еще не выпускавшихся продуктах, причем ее планы и материальные приобретения никак не состыковывались с сегодняшними интересами, а ориентировались на туманное завтра. К тому же весь план составлялся с расчетом на слишком длительный срок.

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

Когда впоследствии дело дошло до закупок намеченного оборудования, выяснилось, что финансовые возможности компании исчерпаны.

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

В чем же заключается правильный подход? Делайте все наоборот. Планируйте на короткое время. Беритесь только за проекты, имеющие ясные деловые цели, и внедряйте только те технологии, что способствуют их достижению. Привлекайте к работе над проектом компетентных людей. Закупайте только то оборудование, без которого нельзя обойтись.

Ричард Бейкер, менеджер по бизнесу и технологиям из компании EDS, увез с конференции, по его собственным словам, понимание необходимости заблаговременно согласовывать производимые закупки с менеджерами, непосредственно занятыми бизнесом, поддерживать с ними тесные связи на протяжении всего времени работы над проектом и установить четкую ответственность за осуществление этих контактов.

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

На первом месте для ИТ-отделов всегда должен быть бизнес и лишь на втором - технология, и это непреложная истина.

Бывало ли в вашей компании так, что бизнес-процессы и технология оказывались в отрыве друг от друга? Сообщите мне по адресу: stan_gibson@zd.com.