Согласно исследованиям, проведенным Standish group (консалтинговая компания, специализирующаяся на анализе эффективности ИТ проектов), доля успешных ИТ-проектов не превышает 31%. Под успешными понимаются проекты, в которых достигаются поставленные цели, и они укладываются в установленные сроки и бюджет. При этом свыше 30% неуспешных проектов проваливаются по причине недооценки рисков проекта.
Под рисками ИТ-проекта мы будем понимать какие-то неопределенные события, которые могут случиться (а могут и не случиться) по ходу проекта, и которые могут повлиять на цели, сроки или бюджет проекта.
Все риски проекта внедрения программы «1C: ERP Управление предприятием» можно разделить на несколько групп по областям возникновения:
- Технические — проблемы с инфраструктурой, на которой разворачивается система;
- Программные — ошибки в коде базовой программы;
- Кадровые — проблемы с квалификацией и доступностью специалистов заказчика и исполнителя;
- Организационные — неорганизованность процессов как на предприятии заказчика, так и в проектной команде;
- Ресурсные — перерасход ресурсов из-за неверной оценки объемов работ или непредвиденных работ.
С рисками проекта внедрения можно и нужно работать. Необходимо:
- вовремя их обнаруживать;
- планировать мероприятия по предотвращению рисков;
- минимизировать воздействие возникших рисков на ход проекта.
Далее мы рассмотрим отдельные риски по сферам возникновения на примерах из практики. И расскажем о том, что можно сделать для их предотвращения.
Технические риски.
Пример из практики. Подрядчик взялся внедрить программу 1С: ERP на заводе. Внедряемая подсистема «Управление производством» предполагала установку программы на рабочих местах мастеров. Размещение компьютеров в цехах и прокладку к ним локальной вычислительной сети взял на себя заказчик. После того как программа была настроена и доработана, специалисты подрядчика отправились в цеха для обучения мастеров. И обнаружили, что там нет ни компьютеров, ни сети. Однако, это обстоятельство не помешало заказчику обвинить подрядчика в срыве сроков проекта, так как в договоре никак не упоминались обязательства заказчика по организации рабочих мест пользователей.
Что можно было сделать, чтобы избежать такого риска? Здесь было бы достаточно предвидеть то, что заказчик может и не выполнить свои обязательства. И установить не конкретные, а условные сроки в договоре для обучения и внедрения. Не «с 1 апреля по 30 апреля», а «в течение 30 календарных дней с даты установки доработанной программы на рабочие места пользователей».
Программные риски.
Пример из практики. На предприятии решили внедрять не редакцию 2.4 «1С: ERP Управление предприятием», а свежую, только что вышедшую редакцию 2.5. К сожалению, редакция программы в момент выпуска содержала ошибки, которые мешали работать. При обращении к разработчику ошибки признавались, но по ним не назначались определенные сроки исправления. А проект горел, заказчик нервничал и требовал немедленного решения проблем. Пришлось подрядчику оперативно и за свой счет исправлять ошибки вендора.
Что можно было сделать, чтобы избежать такого риска? Здесь было бы достаточно прописать в договоре, что подрядчик не несет ответственности за ошибки базового программного обеспечения вендора. И в случае выявления таких ошибок заказчик может ждать исправления ошибки в следующих релизах программы, либо заказать и оплатить исправление ошибки силами подрядчика.
Кадровые риски.
Пример из практики. Договором была предусмотрена доработка программы 1С: ERP и сдача доработок по листам тестирования представителям заказчика. При попытке сдать доработки подрядчик столкнулся с тем, что их некому принимать. Ключевой пользователь заказчика отправился в отпуск. Также выяснилось, что сдать доработки замещающему не получится, так как «он совсем не в теме и боится брать на себя ответственность». В итоге сроки работ по проекту были сорваны, а заказчик недоволен.
Что можно было сделать, чтобы избежать такого риска? Правильная работа с таким риском предполагает разработку детального календарно-сетевого графика работ (КСГ) до заключения договор, или, хотя бы, до начала работ. КСГ должен учитывать все отпуска сотрудников, как заказчика, так и подрядчика. А также иметь определенный буфер по времени на непредвиденные случаи, такие как внеплановые отгулы и больничные.
Организационные риски.
Пример из практики. К директору подрядчика пришел молодой, неопытный руководитель проекта с жалобой, что заказчик отказывается подписывать акт по этапу внедрения 1С: ERP. При анализе ситуации выяснилось, что дело совсем не в заказчике. Руководитель проекта подрядчика не организовал должным образом работу. Не определил состав проектной команды со стороны заказчика, обязанности каждого сотрудника и ответственность за результат. И хотя работы были выполнены, заказчик просто не понимал, кто именно и в какой срок их должен принять.
Что можно было сделать, чтобы избежать такого риска? Для исключения организационных рисков руководителю проекта достаточно было бы подготовить устав проекта или приказ по предприятию заказчика. Этот документ должен был бы определить:
- Цели проекта и его сроки по этапам;
- Состав проектной команды со стороны заказчика и ответственность каждого члена команды;
- Регламент взаимодействия членов команды заказчика и подрядчика.
Ресурсные риски.
Пример из практики (первый). Заказчик присылает подрядчику готовое техническое задание на внедрение 1С: ERP и требует назвать точную стоимость проекта. Собирает предложения с нескольких подрядчиков, рассчитывает среднюю цену и проводит конкурс на внедрение. Побеждает предложение одного из подрядчиков с самой низкой ценой. Так как обследование не проводилось, только в ходе проекта выясняется, что объем доработок типовой программы существенно превышает плановый. Подрядчик из последних сил пытается доделать проект, но у него ничего не выходит. Квалифицированные сотрудники, оставшись без зарплаты, разбегаются. Проект полностью проваливается, и иллюзорная экономия, полученная заказчиком на тендере, превращается в потерю всего бюджета на внедрение.
Что можно было сделать, чтобы избежать такого риска?
Для исключения ресурсных рисков заказчику следовало бы:
- Установить правильные показатели на тендере, исключающие победу по одному показателю — цене, и устанавливающие приоритет опыта и репутации подрядчика над ценой;
- Дать возможность подрядчику самостоятельно провести полноценное обследование объекта автоматизации по отдельному договору и подготовить бюджет проекта;
- Разделить договор на внедрение на две части: в первой части провести моделирование системы на типовом решении и подготовить технический проект на доработки системы. А во второй — выполнить доработки и завершить внедрение. Это позволило бы подрядчику гораздо точнее оценить объем доработок и бюджет на внедрение.
Пример из практики (второй). Заказчик и подрядчик заключили договор на внедрение 1С: ERP с фиксированной ценой. К договору приложили техническое задание, подготовленное подрядчиком на основе интервью, проведенных с пользователями заказчика. В ходе проекта выяснилось, что требования заказчика, заложенные в техническое задание, неполные. И заказчик их все время дополняет и изменяет. На возражения подрядчика «а вот в техзадании этого нет» отвечает «ну вы же опытные специалисты, вы должны были это предвидеть». В итоге, после полного исчерпания бюджета проекта, система осталась не внедренной. Заказчик подал в суд на подрядчика, подрядчик мучительно ищет документы для объяснений в суде.
Что можно было сделать, чтобы избежать такого риска?
Для исключения таких рисков подрядчику следовало бы:
- Внести в договор специальный раздел «управление изменениями», в котором определить четкие правила работы с новыми требованиями заказчика;
- Игнорировать обвинения в некомпетентности и пересматривать бюджет и сроки проекта после анализа каждого нового требования, если изменение может повлиять на бюджет и сроки проекта;
- Исключить заключение договора с фиксированной ценой и сроками, предусмотреть возможность их изменения в процессе уточнения требований заказчика.
Заключение
Мы рассмотрели только несколько примеров из практики. Конечно, количество возможных рисков проекта внедрения «1С: ERP Управление предприятием» гораздо больше. Основная идея, которую бы хотелось донести до читателей, следующая. Важно научиться правильно работать с рисками еще на стадии заключения договора. Чем больше рискованных ситуаций будет описано в договоре, тем выше вероятность, что проект будет успешен.