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

Когда говорят, что 30 (70, 90...) процентов внедрений КИС заканчиваются неудачей, это производит очень сильное впечатление на пользователя. Но полезнее, на наш взгляд, понять причину неудач. А прежде чем ее искать, необходимо разобраться, что именно подразумевается под "неудачей" и какой опыт необходимо извлечь, анализируя проект внедрения инфосистемы.

Определенные “критические” точки в развитии любого корпоративного проекта обсуждаются в прессе достаточно давно и подробно. Пользователям информационных систем, думается, они уже известны. Важность для практики таких вопросов, как постановка основных целей автоматизации; выбор системы, адекватной этим целям; методологические основы ведения проекта (организация проектной команды, создание устава проекта и т. д.), о которых очень часто пишут и говорят и поставщики, и консультанты, действительно трудно переоценить. Это постулаты внедренческих работ, игнорирование которых уж точно не позволит заказчику достичь конечного успеха. Вместе с тем практика внедрений программных систем показывает, что заказчик в подавляющем большинстве случаев вполне “законопослушен”. Он не только в курсе всех перечисленных проблем, но и вполне честно и добросовестно старается не обходить их стороной, приступая к внедрениям на своем предприятии. Казалась бы, больших трудностей при этом возникать не должно.

Но на практике все оказывается не так просто.

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

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

В-третьих, не все работы удается довести до конца в срок, и не все работы удается выполнять без перерыва. Приостановка проекта, пусть временная, — это, конечно же, негативный фактор. Иногда это происходит по объективным обстоятельствам (в основном в результате смены руководства и пересмотра бизнес-стратегии). Но даже в этом случае подобный факт — скорее свидетельство отсутствия стабильности самого бизнеса.

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

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

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

Сергей Костяков