|
|
поиск:
|
![]() |
Без краха, но не без сомнения |
![]() ![]() ![]() ![]() |
Без краха, но не без сомнения«Директор информационной службы» (CIO.RU) №2, февраль 2006 Известно, что значительное число проектов по созданию информационных систем масштаба предприятия терпит фиаско. Каковы типичные причины краха крупных ИТ-проектов и что нужно предпринять для их устранения? Проекты не созрели или плохо продуманы Причины неудач в проектах создания полномасштабных систем зачастую связаны либо с недостаточным уровнем зрелости предприятия, либо с отсутствием системного подхода в решении сложной задачи. Недостаточный уровень организационной зрелости не следует воспринимать как негативную характеристику, это просто одна из ступеней естественного развития предприятия. Компаниям, переживающим этот этап, характерны следующие черты: изменчивость процессов, их неустойчивость, отсутствие целевой модели процессов и, как следствие, невозможность четко сформулировать задачи, связанные с их автоматизацией. Подчиняясь указаниям руководства по внедрению системы масштаба предприятия, ряд подразделений могут высказать свои требования и пожелания к будущей системе, в то время как другие остаются незадействованными. У некоторых подразделений, возможно, отсутствует как сама потребность в системе, так и интерес к ней. Если руководство не воспринимает систему как бизнес-инструмент, охватывающий все предприятие или организацию, либо не может донести это видение до сотрудников, то результаты проекта, скорее всего, окажутся неадекватными его целям. Все закончится «лоскутной» автоматизацией либо отображение бизнес-процессов в системе будет иметь мало общего с реальным положением дел на предприятии. В любом случае проект изначально обречен на неудачу. Возможным решением в данной ситуации могла бы стать разработка комплексной программы развития информационных технологий в компании, которая рассчитана на три-пять лет вместо 8-24 месяцев (обычных целевых сроков внедрения систем масштаба предприятия). Такая программа может предусматривать поэтапную автоматизацию процессов предприятия. В первую очередь программа охватит приоритетные и достаточно устоявшиеся процессы, а затем, по мере развития компании, и те, которые приобретают устойчивую форму или могут быть представлены в виде некой целевой модели. Автором и идеологом такой программы, безусловно, будет директор информационной службы. Разумеется, чтобы отстоять такую программу, он должен обладать соответствующим «весом» в компании. Кроме того, ИТ-директор должен удовлетворить потребности в информационной поддержке как отдельного подразделения, так и компании в целом. Другой распространенной причиной краха проектов становится отсутствие системного подхода к реализации подобных начинаний. Частным проявлением этой проблемы можно назвать нарушение порядка принятия решений в проекте. Зачастую сначала принимается техническое решение, а затем все усилия направлены на то, чтобы «подогнать» параметры уже выбранной платформы к реальным потребностям. Вот пример провального проекта. Финансовый директор одной крупной компании настоял на том, что корпоративная система должна быть построена на базе известной ERP-платформы. Решение о приобретении этой системы приняли еще до систематизации функциональных требований к ней. В результате проект заморозили на этапе согласования функциональных требований, поскольку средствами системы невозможно было автоматизировать ряд ключевых бизнес-процессов. Поскольку бюджет на программное обеспечение был израсходован, организации пришлось искать другие пути решения задач развития, в частности, пересматривать всю модель взаимоотношений внутри предприятия. Подобные упущения можно предупредить на начальном этапе проекта или компенсировать уже в ходе работ при наличии профессионального управления проектом со стороны заказчика. Руководитель проекта воспринимает его целостно и отслеживает все моменты, которые впоследствии могут негативно сказаться на бизнесе заказчика. Именно руководитель поддерживает должный ритм и направление деятельности, активно вовлекает участников проекта со стороны заказчика в решение актуальных вопросов. Чем больше участников в проекте, тем сложнее им ознакомиться с его документацией, собраться для принятия тех или иных решений, вовремя прореагировать на изменения. В таком случае профессиональное руководство проектом просто необходимо. Среди других наиболее частых причин провала проектов — непонимание влияния проекта на бизнес предприятия в целом, неэффективность коммуникаций с субподрядчиками, отсутствие административной поддержки, неопределенные критерии оценки результата и нереалистичные ожидания. Сергей Гончаров, директор консалтинговой компании PM City, S.Goncharov@pmcity.ru Все кроется в людях Основные причины краха проектов лежат в области человеческих отношений. Вот наиболее распространенные из них, а также рекомендации по их преодолению.
Общий принцип : всех, кто может помешать в конце проекта, необходимо привлечь к его реализации. Тогда любой действительно нужный для организации проект обречен на успех. Валерий Чашкин, директор департамента ИТ-систем «Внешэкономбанка» Пять категорий краха Причины, которые могут привести к краху ИТ-проекта, можно разделить на пять групп: стратегические и организационные, функциональные, оперативные, технические, политические и внешние. Стратегические и организационные причины: отсутствие у предприятия долгосрочной стратегии в области ИТ, ошибки в постановке целей и задач проекта, переоценка возможностей готовых бизнес-приложений, недооценка стоимости проекта, изначально недостаточный бюджет. Причиной краха проекта может быть также непонимание руководством необходимости организационных преобразований в компании, обусловленных внедрением системы. Как правило, когда развертывается информационная система масштаба предприятия, бизнес-процессы предприятия в той или иной степени приходится менять. Важно еще на начальной стадии проекта представлять тот компромиссный вариант, который возможен за счет того, что бизнес предприятия подстроится под модели процессов, заложенные в готовом решении. Последнее, в свою очередь, предстоит доработать, учитывая специфику деятельности компании. Чтобы добиться успеха, предприятию необходимо обдумать и сформулировать на бумаге все эти аспекты до начала проекта, возможно, совместно с консультантами. Функциональные причины: несоответствие сложности бизнес-процессов предприятия функциональным возможностям внедряемых бизнес-приложений. К краху проекта может также привести плохое знание отраслевой специфики поставщиком услуг внедрения либо недостаточные возможности выбранных решений в том, что касается поддержки отраслевой специфики. Как с этим бороться? Предприятию необходимо не только определить, какая функциональность ему нужна сейчас, но и спрогнозировать, какие возможности потребуются через один-два года. Следует выбирать исполнителя проекта, уже имеющего успешный опыт внедрения аналогичных систем в той же отрасли. Оперативные причины: ошибки управления проектом (просчеты в планировании сроков и стоимости работ, неэффективное управление бюджетом, несвоевременная идентификация проектных рисков), недостаточное участие руководства предприятия в проекте, нечеткое разграничение ответственности между проектными командами заказчика и исполнителя, сопротивление персонала предприятия внедрению информационной системы и сопутствующим этому процессу изменениям. К этой же группе рисков относятся отсутствие поддержки внедрения или прямое противодействие внедрению системы со стороны некоторых топ-менеджеров заказчика (это встречается, когда проект внедрения бизнес-приложений служит рычагом «политической» борьбы на предприятии), нехватка специалистов или радикальная смена состава проектной команды. Технические причины: наиболее вероятно возникновение сложностей в процессе интеграции внедряемых бизнес-приложений с уже имеющимися на предприятии учетно-управленческими системами. По оценке специалистов нашей компании, затраты на интеграцию могут составлять до 60 % бюджета проекта. Политические и внешние факторы: составляют особый риск в крупных проектах. Один из них — изменение рыночной конъюнктуры во время внедрения: если проект длится несколько лет, то за это время может что-то случиться с поставщиком решения, исполнителем проекта или предприятием-заказчиком. В проектах для госструктур определенный риск представляют возможные метаморфозы законодательства, регламентирующего их деятельность. Если законы изменятся в процессе внедрения, то автоматизация в том виде, в котором была изначально задумана, может потерять смысл. Игорь Никулин, директор департамента информационных технологий компании КРОК, INikulin@croc.ru ![]() При копировании необходимо сохранять оригинальное авторство, ссылку на данную страницу и по возможности ссылки внутри текста. Семинары и тренинги по теме:
![]() |
Архивы новостейОтзыв клиентаО тренинге «Профессиональное планирование и управление проектами с помощью MS Office Project. Практический курс. 2 дня»
Водянников Денис Владимирович
зам. Руководителя управления IT, АльфаСтрахование, ОАО |
![]() |
© «PM City» на рынке с 2005 г. Создание КСУП, Проектный офис, Обучение проектному управлению
|