Без краха, но не без сомнения

Каковы типичные причины краха крупных ИТ-проектов и что нужно предпринять для их устранения? Эксперты придерживаются сходных мнений в отношении этой проблемы.

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

Проекты не созрели или плохо продуманы

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

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

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

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

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

Другой распространенной причиной краха проектов становится отсутствие системного подхода к реализации подобных начинаний. Частным проявлением этой проблемы можно назвать нарушение порядка принятия решений в проекте. Зачастую сначала принимается техническое решение, а затем все усилия направлены на то, чтобы «подогнать» параметры уже выбранной платформы к реальным потребностям.

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

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

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

Все кроется в людях

Основные причины краха проектов лежат в области человеческих отношений. Вот наиболее распространенные из них, а также рекомендации по их преодолению.

• Крупный ИТ-проект не нужен организации. Рекомендация : крупный ИТ-проект должен быть подпроектом не менее крупного бизнес-проекта.
• Предан забвению особо важный для проектов масштаба предприятия принцип участия "первого лица". Рекомендация: любой крупный проект должен иметь активную поддержку руководства предприятия, поэтому одно из первых лиц должно входить в состав руководства проектной группы, всячески демонстрируя и поддерживая ее деятельность.
• Проектная группа оказалась непредставительной, некомпетентной или не имеющей полномочия принимать решения. Рекомендация : сделать все, чтобы проектная группа по составу и качеству соответствовала масштабу проекта, его задачам и уровню принимаемых решений.
• Слабый менеджер проекта. Рекомендация : очевидна необходимость найти другого менеджера.
• Широкие массы работников предприятия, которых затронут результаты проекта, не подготовлены к грядущим переменам как морально, так и профессионально (перемены мало кто любит). Рекомендация: проводить широкомасштабную разъяснительную работу и обучение, особенно перед внедрением.

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

Пять категорий краха

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

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

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

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

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

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