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

Риск №1. Недостаточный, неточный сбор требований

Собранные требования — это базис для разработки системы, фундамент, на котором она будет строиться. Если на старте команда исполнителя соберёт неполные или ошибочные требования — то на финише вы получите совсем не тот продукт, на который рассчитывали.

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

Риск №2. Внутреннее сопротивление изменению старых процессов

В продолжение предыдущего пункта. У заказчика часто есть опыт работы на другой системе и со словами «А у нас всё работает вот так!» он пытается перенести привычную логику на новую систему, у которой может быть совсем другая логика. Бизнес-аналитикам сложно работать на таком проекте, да и для самого проекта последствия могут быть довольно плачевными.

Риск №3. Отсутствие построенных бизнес-процессов внутри компании и перенос этого хаоса в новую систему

Снова частично продолжаем предыдущий пункт. Нередко бывает, что в компании не выстроены бизнес-процессы, да и цели их выстраивать ни у кого нет. И к нам обращаются с мыслями «А давайте-ка мы внедрим ERP-систему и она нам всё поправит». Нет, не поправит — хаос останется.

Запомните главное: системы автоматизации помогают автоматизировать уже существующие бизнес-процессы, а не создают их с нуля.

Риск №4. Отсутствие документации на проекте

По разным причинам. С чисто человеческой точки зрения нам понятно и желание заказчика сэкономить, и желание поскорее приступить непосредственно к разработке. Но документация — это не бюрократия и создание бумажек ради бумажек.

Проектная документация — это помощник, который позволяет:

— напомнить и исполнителю, и заказчику кто, когда и зачем просил сделать определённую функциональностью; почему её сделали именно так, а не иначе. В процессе разработки и внедрения заказчики нередко задают такие «почему» — и документация помогает оперативно восстановить всю хронологию событий без мучительных попыток вспомнить, что же было 2, 3 или 6 месяцев назад;

— на каждом этапе проверять, насколько разрабатываемая система соответствует установленным целям;

— новым сотрудникам — быстро включаться в проект;

— исполнителю — не совершать одни и те же действия по кругу, например, тестировщикам — не указывать на одни и те же ошибки, потому что они вовсе и не ошибки, а особенности реализации;

— заказчику — не зависеть от исполнителя (подрядчика или своих разработчиков), потому что лишь он один знает все исходные требования и особенности системы.

Помните лозунг «Экономика должна быть экономной» — и не экономьте на том, что в будущем может обернуться ещё большими расходами. Не экономьте на документации.

Риск №5. Изменение целей проекта

Разработка и внедрение любой бизнес-системы — дело не одного месяца (а порой и не одного года). Понятно, что жизнь всё это время не стоит на месте и в бизнесе происходят различного рода изменения. Например, проект по тем или иным причинам теряет для заказчика актуальность. Или со стороны заказчика меняется ключевое лицо, приходит новый человек со своим видением того, что и как должно быть. Причины могут быть разными, но любые изменения в духе «Стоп, теперь нам нужно не так, а вот так!» не приведут проект к успеху.

Риск №6. Отсутствие управления изменениями проекта

Требования от заказчика всё идут и идут, идут и идут, бесконечно — и нет им ни конца, ни края. А главное — заказчик не может расставить приоритеты, для него важно сделать ВСЁ. А ведь необходимо ещё уложиться в срок: дедлайн-то проекта никто не отменял.

Это — настоящий кошмар для любой команды. Если не управлять бесконечным потоком требований, то он попросту захлестнёт, утопит: проект затянется и выжмет все соки из аналитиков и разработчиков, а заказчик всё равно останется недоволен.

Прежде чем отдавать каждое требование заказчика в разработку, его важно анализировать и приоритезировать: для чего оно нужно, на что влияет, насколько важно.

Из нашей практики: сначала заказчик говорит «Мне это нужно, это очень важно!». Проходит неделя, проходит итерация — он возвращается со словами «Ой, в принципе, не так уж и важно было, я передумал».

По статистике 45% функциональности, которая изначально запрашивалась заказчиком, вообще не используется в системе, а ещё 19% используется очень редко. А ведь заказчик за эти 45% заплатил… Поэтому всегда очень важно приоритезировать.

Риск №7. Неопытный руководитель или его отсутствие

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

Опытный руководитель проекта может предотвратить и нивелировать конфликты и наладить взаимоотношения и внутри фокус-группы, и между фокус-группой и нами, как исполнителями, способен быстро реагировать на возникающие проблемы.

Отсутствие руководителя вообще или его недостаточная компетентность могут привести к хаосу.

Риск №8. Частое изменение состава команды как со стороны заказчика, так и со стороны исполнителя

Тут важно, на каком этапе происходит изменение состава. На этапе инициирования, планирования? Риск для проекта невелик. На этапе разработки и тем более внедрения? А это уже гораздо болезненнее.

Человеческий фактор, конечно, никто не отменял, но очень желательно, чтобы определённые в самом начале фокус-группа со стороны заказчика и команда со стороны исполнителя работали с проектом до конца.

Риск №9. Сильная кастомизация коробочного решения с изменением изначальной логики системы

Тоже не работает. Возьмём ERP-систему. У каждой — своя логика, которую тщательно продумывало и выверяло большое количество людей. Сказать, что «Нам надо по-другому!» и ломать эту логику больно и дорого. Возможно, даже дороже, чем разрабатывать систему с нуля. Знаем случаи, когда заказчик ломал бизнес-процессы коробочного решения — а потом приходил к изначальному варианту со словами «Хорошее было решение, зря только распотрошили».

Опыт в разработке и внедрении различных систем автоматизации бизнеса помогает нашим сотрудникам грамотно оценивать и управлять рисками, повышая шансы проекта на успех. Хотите внедрить ERP, CRM, MRP, PLM, SRM или eCommerce систему? Оставьте заявку на нашем сайте — и мы свяжемся с вами, чтобы всё обсудить.