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

Немногие специалисты смогут точно подсчитать потери от неудачного внедрения или обновления корпоративных бизнес-приложений. Только прямые убытки в средних и крупных компаниях составляют тысячи и миллионы рублей и человеко-часов, связанные с перебоями в работе бухгалтерии, казначейства или финансового департамента. Эти потери потом обрастают легендами о потраченных впустую миллионах, о бесплодной работе целых коллективов в течение нескольких лет. Несмотря на то что российские предприятия накопили значительный опыт в этой области, подобные истории продолжают повторяться.
Ответственность за неудачи лежит во многом не на системных интеграторах - компании-заказчики часто не готовы создать условия для успешного выполнения проекта. Приведем наиболее значимые риски со стороны заказчика на примере ERP-проектов на платформе "1С" из практики авторов. Анализ этих рисков до внедрения позволит повысить эффективность проекта, сэкономить человеческие, временные и материальные ресурсы компании-пользователя.
Достаточно ли осознаны масштаб и сложность поставленных задач? Внедрение новых ERP-систем на предприятии чаще всего обусловлено проблемами, связанными с неспособностью старых учетных систем адаптироваться под изменяющиеся потребности бизнеса. Практика показывает, что, как бы глубоко заказчик ни смотрел на поставленную задачу, он часто не осознает масштабов и комплексности решаемых задач, недооценивает время и затраты на решение своих внутренних методологических, управленческих и учетных вопросов. Это касается в первую очередь инновационных ИТ-проектов. В условиях, когда ни заказчик, ни исполнитель до конца не понимают глубины необходимых изменений и требуемой степени автоматизации бизнес-процессов, зачастую внедрение превращается в итерационные НИОКР. Тогда само понятие "проект", обладающее четкими временными и ресурсными рамками, превращается в постоянный "процесс" по доводке системы, результаты которого за отрезок времени сложно измерить и оценить.
Цели проекта по внедрению ERP-системы должны вытекать из существующих проблем предприятия и его общей стратегии развития, каждая цель должна быть разбита на несколько подцелей со своими измеримыми, пусть и небольшими результатами. В сумме такие промежуточные результаты дадут достижение центральных целей, значимых для предприятия в целом.
Корректно ли очерчены рамки проекта, сформулированы ли цели, выделены ли ресурсы? Часто заказчик ожидает от новой системы решения всех своих внутренних проблем. Хотя понятно, что все проблемы она не сможет решить. Поэтому перед стартом автоматизации важно очертить организационный и технический периметры проекта, тем самым систематизируя и сужая круг задач, решения которых заказчик будет реально ожидать от внедрения ERP-системы.
Многие проекты оказывались долгими и дорогими из-за расплывчатых формулировок рамок проекта, споры о толковании изначально поставленных задач начинались в разгаре работ, что оттягивало получение результатов. Если следовать проектным учебникам, по каждой задаче нужно выработать измеримые критерии ее успешного разрешения. Но, к сожалению, для многих задач проекта очень проблематично сформулировать адекватные измеримые цели, которые бы не просто демонстрировали успех "для руководства", но действительно свидетельствовали бы о повышении эффективности работы автоматизируемых бизнес-процессов.
Следовательно, расчет сроков окупаемости и защита бюджета проекта перед инвесторами всегда вызывает большие сложности. Есть и другое заблуждение: "В результате внедрения ERP-системы мы сократим персонал и окупим стоимость внедрения системы". В реальности в результате внедрения комплексной системы данные неизбежно детализируются, уточняются. Предприятие получает возможность анализировать их, получать информацию, помогающую принимать управленческие решения, приводящие к увеличению прибыли. Расплата за точность - увеличение ввода информации в систему, рост затрат на получение желаемой детализации. Это могут быть затраты на оборудование, программное обеспечение или повышение численности персонала.
Есть ли единое понимание, какими путями и технологиями достичь результата? Считается, что переход от функциональных требований к проектным решениям - это прерогатива исполнителя. Однако результатами внедрения предстоит пользоваться заказчику, а не исполнителю, поэтому выработка основных проектных решений должна происходить в тесном контакте между сторонами, причем на всех уровнях проектных команд.
Как правило, используется общепринятая схема управления проектом: кураторы проектов, их руководители и специалисты - по ролям. Кураторами проекта назначаются, как правило, топ-менеджеры. В узконаправленном проекте такая схема оптимальна, а для внедрения комплексного проекта недостаточна. Задачи одного руководителя службы неразрывно связаны с задачами других служб. Решить их в одиночку он не может, это вопрос уровня предприятия. И так почти со всеми вопросами. Более корректен подход, при котором создается штаб проекта, состоящий из руководителей служб, в задачи которого входит решение задач уровня предприятия.
Готово ли предприятие к организационным изменениям в ходе проекта? Любая ERP-система имеет четко определенную схему работы и реализует заложенную бизнес-логику. На практике большинство попыток перестроить бизнес-логику предприятия под бизнес-логику программного продукта заканчивались провалом, поскольку изменение исторически сложившихся бизнес-процессов, затрагиваемых автоматизацией, всегда происходит болезненно (неразбериха, сопротивление на местах и пр.). Главное - готовность предприятия в целом, как единого, сложного организма. Например, в процессе внедрения новой ERP-системы на предприятии автоматизация затрагивает цеха, где изначально наличие компьютера даже сложно себе представить. Готов ли к этому заказчик? Мы даже не имеем в виду финансовые затраты. Готов ли заказчик ввести новую штатную единицу, выделить комнату, организовать измерение и нормирование непосредственно в условиях цеха? Часто системные интеграторы переоценивают возможности предприятия по решению данных вопросов. Привыкшие работать в офисах и с высококвалифицированным персоналом, многие консультанты в ИТ-компаниях даже не представляют себе, как в реальности выглядит цех отечественного предприятия. Другой пример - вовлечение в работу конструкторов и технологов, предпочитающих использовать в работе специализированное программное обеспечение.
Актуальной проблемой при переходе на новую систему является подготовка данных для наполнения системы. Имеющаяся на предприятии нормативно-справочная информация, как правило, неполная, она не структурирована в соответствии с требованиями новой системы, содержит "исторический мусор". Данные по остаткам ТМЦ и старые документы не обладают необходимой глубиной аналитики. Чтобы привести в порядок большой объем информации, также нужны серьезные организационные усилия, которые часто недооцениваются заказчиком.
Компетентна и последовательна ли проектная команда? Пожалуй, данный риск не относится конкретно к внедрению ERP-системы, однако он наиболее типичен в силу сложности и многозадачности. Заказчиком ERP-проекта не может выступать начальник производства или руководитель любого другого подразделения. Им может быть только лицо, реально управляющее предприятием, или совет директоров предприятия. Однако не следует забывать, что внедрение затрагивает все подразделения предприятия, и вопрос коммуникаций, лояльности целям, понимания решаемой задачи играет решающую роль. На практике, как бы усердно ни работали топ-менеджеры со своими подчиненными-руководителями, цели у каждого свои и понимание результатов для каждого подразделения тоже свое. И они могут совершенно расходиться с целями топ-менеджеров. Самое простое, с чем приходилось сталкиваться, - это явное противостояние, самое сложное - это тихое бездействие под видом "невероятной активности и содействия".
Среди множества проектных рисков, один приводит практически к 100%-ному провалу - это риск отсутствия лидера проекта или потребителя продукта, который создается как результат проектной деятельности. Часто бывает, что лидер проекта и потребитель продукта - это один и тот же человек. Реальность всегда отличается от начальных планов, и если некому решать многочисленные проблемы, то шансов на успех практически нет. Если нет функционального заказчика или потребителя, который действительно заинтересован в использовании созданной системы автоматизации, то даже при формально успешном завершении проекта его результат будет отражен только на бумаге и его практическую пользу узнают только немногочисленные читатели соответствующих документов, а разработанная система никогда не перейдет в промышленную эксплуатацию.
Адекватен ли уровень детализации при проектировании решений? Проектное решение должно быть актуальным и достаточно подробно детализировано для раскрытия бизнес-логики. Минималистичное описание функциональных требований - часто встречающаяся проблема проектов по автоматизации. Причин, как правило, две. Первая - желание сделать описание функциональных требований быстро и дешево, задачи формулируются в общем виде ("и так понятно, что требуется"). Вторая - сложно представить абстрактную систему со всеми особенностями и во всех деталях. На практике это приводит к тому, что каждый участник проектных команд с обеих сторон видит задачу по-своему. Как результат, постоянные изменения разработанного функционала, упущенные сроки и превышенный бюджет проекта. Как же понять, что задача описана достаточно детально? Зачастую достаточно понять, что систему будут создавать люди, которые заменяют ваш опыт работы логическим описанием бизнес-процесса. Представьте, например, что вы берете на работу нового сотрудника и должны написать ему инструкцию, по которой он сможет работать без подсказок, - вот и получится пример того, насколько детальным должно быть описание задачи. Частичным исключением является ситуация, когда система создается на основе существующего программного продукта. В этом случае требуется детально прописать только дорабатываемый функционал, но при этом существующий функционал должен быть всесторонне изучен и рассмотрен.
Не нарушается ли при выполнении проекта технология внедрения? Технология внедрения может нарушаться вследствие низкой проектной компетентности исполнителя, по политическим мотивам, но, как правило, это возникает из-за желания ускорить сроки завершения проекта. Ускорение хода проекта допустимо при взвешенном и обоснованном подходе. Необходимо определить все риски уменьшения сроков и изменения плана проекта и свести их к разумному минимуму.
Вторая причина нарушения проектной технологии - это затягивание согласований. Казалось бы, технический проект давно написан, несколько раз уточнен и даже предварительно согласован по электронной почте. Поэтому, не дожидаясь официального утверждения, проектная команда садится за разработку. Однако спустя пару месяцев у заказчика сменяются ключевые пользователи, которые все видят по-другому, и подписание бумажного комплекта документов превращается в очередную корректировку проектного решения, которое в старом варианте уже было почти реализовано. Следовательно, какова бы ни была потребность в ускорении хода разработки, нужно не поддаваться эмоциям, а смотреть на проект трезво и критически.
В заключение следует отметить, что в любом проекте есть множество рисков. Одни встречаются чаще, другие реже. Но каждая ситуация и среда, в которой они "прорастают", всегда уникальна, как, впрочем, и сам проект. Всегда нужно помнить, что основа успеха - люди. Именно они делают проект, решают вопросы и достигают результатов.