Чьи в лесу шишки?
То, что на стадии предварительной проработки проекта закладывается значительная часть его полезности, общеизвестно. И тем не менее, самой распространенной ошибкой на этапе принятия решения о внедрении УИС является слабая проработка целей этого самого внедрения и ключевых требований к системе. Здесь возможны две одинаково пагубные крайности.
С одной стороны, когда внедрение УИС является инициативой какого-то конкретного отдела, службы и выбор определятся потребностями именно этого отдела, а другие направления не получают решений стоящих перед ними задач. С другой стороны, когда техническое задание составляется путем сбора и обобщения данных от всех подразделений — получается длинный, сложный и практически бесполезный список. Хуже всего, что такой подход учитывает исключительно текущие требования подразделений, а не стратегические цели предприятия в целом. На данной стадии также наиболее тяжкие последствия имеют факторы риска, связанные с отсутствием у предприятия стратегии в области ИТ (это часто приводит к несоответствию функциональных возможностей системы масштабу бизнеса предприятия), заниженная оценка руководством предприятия масштабов организационных преобразований, обусловленных внедрением УИС, переоценка заказчиком возможностей УИС (а иногда — и консультанта — «за такие деньги они должны все сделать сами и представить в лучшемвиде»), недостаточное представление о той роли, которую в проекте играют человеческий фактор и административная вертикаль (начинать нужно не с системы — начинать нужно с исполнителей с опытом успешной работы, «победителей»).
| Опыт показывает, что проект, не дающий определенного результата в течение более 12 месяцев, очень похож на провал. |
Не следует сильно переживать по поводу как «неполноты», так и избыточности списка требований к системе от разных областей деятельности предприятия — скорее всего эту задачу просто невозможно будет решить. Потребуется достаточно глубоко изучить сравниваемые системы — иначе невозможно будет выбирать из нескольких функционально близких систем. Сравниваться должны не только системы, но и партнеры по внедрению. Окончательное решение при проведении закрытого конкурса должен принимать комитет по автоматизации, в состав которого входят топ-менеджеры предприятия. Повторимся: главное — тщательно проработать исходные цели проекта с учетом стратегии дальнейшего развития предприятия и выбрать УИС в соответствии с этими целями. Опыт показывает, что и руководству, и сотрудникам предприятия, скорее всего, придется более активно участвовать в проекте, чем им это представлялось изначально.
Факторы риска, связанные с выбором поставщика услуги по внедрению программного продукта (УИС) рассматривать не будем — теоретически можно обойтись и без оного, а качество услуг «внедренца» можно оценить лишь по завершении проекта. Заметим лишь, что сильно рискует тот, кто выбирает консультанта по принципу минимальной стоимости его услуг или внушительной клиентской базы.
На этапе — планирование внедрения — закладываются сроки проекта (внедрения и окупаемости), его организационный план и бюджет. Расхождение между планом и фактом неизбежны при неправильной постановке задач. К сожалению, здесь также нередки крайности — либо увязание в бесконечных обследованиях, либо полное пренебрежение постановкой исходных требований. Свести к минимуму ошибки при планировании стоимости и сроков внедрения проекта можно, если не пытаться внедрить все сразу, а начать с пилотного проекта. В дальнейшем отслеживать результаты промежуточных этапов и своевременно обнаруживать отклонения поможет специально разработанная серия контрольных точек. Здесь должен сыграть свою роль как опыт работы руководителя проекта внедрения со стороны компании — поставщика, так и аналогичный — со стороны руководителя проекта от компании-клиента.
| По оценкам специалистов, десятая часть проектов внедрения управленческих информационных систем информационных систем класса ERP (Enterprise Resource Planning) никогда не доводится до конца. |
На стадии внедрения в проекте преобладают организационные риски. В первую очередь — это недостаточное участие топ-менеджмента в проекте: именно они станут ключевыми пользователями информации, получаемой из системы, именно они должны принимать окончательные решения в ходе проекта, именно от них зависит придание проекту необходимого статуса. Несоответствие бизнес-процессов предприятия эталонным бизнес-процессам УИС/неупорядоченность бизнес-процессов/отсутствие корпоративных стандартов — являются серьезными рискам при условии, что они не были нейтрализованы на этапе предварительной подготовки проекта (лучше всего — при участии консультантов по управлению компании-поставщика УИС). С точки зрения бизнес-процессов, наиболее трудными для внедрения оказываются модули по материальному производству (особенно с точки зрения планирования потребностей) и логистике. Зачастую в середине проекта, когда затрачено уже много времени, сил и ресурсов, а окончательного результата еще не видно, у участников возникает психологическая усталость, которая может перерасти в негативное отношение и сопротивление проекту.
Опыт показывает, что проект, не дающий определенного результата в течение более 12 месяцев, очень похож на провал. Необходимо время также для постепенной подготовки персонала предприятия-клиента к новой системе работы (изменения в процессах, регламентах, форматах), в том числе широкое информирование персонала о текущих результатах работы и задачах на ближайшее время, пропагандой позитивных примеров, материальным стимулированием («внутренний пиар» проекта). Саботаж со стороны персонала можно побороть при условии, что топ-менеджмент заинтересован в проекте и не боится принимать непопулярные решения, понимая, что внедрение УИС — это не приобретение (пусть даже за большие деньги) волшебной палочки, которая решит все его проблемы. Человеческий фактор сказывается еще в чрезмерной увлеченности технической стороной дела в ущерб функциональной целесообразности, продиктованной конечным целями внедрения.
| Около 30% проектов заканчиваются с превышением сроков и бюджета более, чем на треть. Еще примерно половина проектов завершается, не соответствуя изначальным ожиданиям (не реализован намеченный объем автоматизации хозяйственных процессов). |
Долгосрочные факторы риска могут препятствовать дальнейшему развитию системы на предприятии после окончания этапа внедрения. Основной вывод из наблюдений на этом этапе таков: и предприятие, и лица, участвовавшие в проекте, выходят из него сильно изменившимися. Меняется структура, цели и стратегия предприятия. Повышение прозрачности предприятия пропорционально снижению его информационной безопасности. Внедренная УИС не позволяет гибко реагировать на изменение требований бизнеса — снижается скорость перестройки локальных хозяйственных процессов. Проектная команда, накопившая уникальный опыт, может уйти (что наиболее болезненно для крупного предприятия). Законодательство, «прошитое» в УИС, может сильно измениться. Но, если внедрение УИС завершилось успешно, и основные функциональные компоненты были запущены в промышленную эксплуатацию, можно говорить о второстепенности долгосрочных факторов риска внедрения УИС.
Говоря о рекомендациях по успешному внедрению проекта, мы помним, что нет двух одинаковых проектов. Не повторяя вышеприведенные рекомендации, заметим лишь, что минимизация факторов риска при внедрении УИС должна происходить, по крайней мере, в четырех сферах: роль высшего руководства предприятия и ведущих специалистов, организации проекта, правил формирования/функционирования проектной команды и управления изменениями.
Відгуки
Учитывая, что по статистике 90% неудачных ИТ-проектов "пролетают над Парижем" именно по причине "кривых" требований, не совсем понятно, почему "Не следует сильно переживать по поводу как «неполноты», так и избыточности списка требований к системе...". По этому поводу, как раз, и надо переживать сильнее всего! Обратный профиль рисков ИТ-проекта "выгибается" в нужную строну, в основном, благодаря грамотному управлению требованями!!!
Так же, не совсем понятно почему явный дилетантизм в области управления требованиями принимается за норму жизни: "С другой стороны, когда техническое задание составляется путем сбора и обобщения данных от всех подразделений — получается длинный, сложный и практически бесполезный список. Хуже всего, что такой подход учитывает исключительно текущие требования подразделений, а не стратегические цели предприятия в целом". Если к работе с требованиями к системе подойти грамотно, то "длинный, сложный и практически бесполезный список" превращается в ценный и практически единственный инструмент, на основании которого ведется проект. И, более того, без которого вообще невозможно ничего сделать, в том числе, и сдать систему заказчику. На основании чего, например, предполагается в процессе User Acceptance Test показывать заказчику, что он получил то, что заказывал?
Например, "На этапе — планирование внедрения — закладываются сроки проекта (внедрения и окупаемости), его организационный план и бюджет.", если нет внятных требований к системе, то на основании чего, собственно говоря, предполагается составлять план проекта? (Напомню, проект это: результат, сроки и бюджет. Которые расчитываются исходя из трудоемкости, которая расчитывается исходя из того, что надо сделать, что, в свою очередь, становится понятно из требований к системе).
"К сожалению, здесь также нередки крайности — либо увязание в бесконечных обследованиях, либо полное пренебрежение постановкой исходных требований. Свести к минимуму ошибки при планировании стоимости и сроков внедрения проекта можно, если не пытаться внедрить все сразу, а начать с пилотного проекта." - здесь тоже не совсем все понятно. Если требования таки отстутствуют, то чем поможет пилотный проект? Вероятно тем, что гарантированно провалится и покажет заказчику (слава Богу, на небольших деньгах), что действительно ничего не получится внедрить и весь проект лучше "похоронить" сразу?...
Короче говоря, общее впечатление от статьи: заказчику показывать ее нельзя.
Грамотный подход к работе с требованиями к системе дается не вдруг. Это надо выстрадать и пропустить через себя не один раз. Если бесцельно и бессистемно блуждаешь по заводу в поисках КАКИХ-НИБУДЬ требований хоть ОТ ВСЕХ, то на выходе как раз и получишь КАКОЙ-ТО продукт для НИКОГО...