Итак, вы решили провести автоматизацию бизнес-процессов в компании. Ошибка или недопонимание в этом деле может стоить бизнесу больших финансовых потерь и увеличить срок реализации, поэтому начинать всегда следует с планирования. В этой статье мы рассмотрим, как происходит предпроектное обследование для внедрения систем автоматизации.
Это подготовительный этап для разработки или внедрения продукта. Комплекс действий, который поможет заказчику и подрядчику понять, какие ресурсы потребуются для реализации проекта. ППО особенно актуально, когда автоматизацию бизнес-процессов или разработку нового ПО выполняют не силами самой компании, а с привлечением стороннего подрядчика. ППО позволяет ответить на такие вопросы, как:
После сбора, обработки и системного анализа данных, специалисты формируют для заказчика две картины: «AS-IS» — как осуществляется процесс сейчас и «TO-BE» — как все будет работать после автоматизации.
Смысл ППО в том, чтобы оптимизировать бизнес-процессы компании путем их автоматизации, для этого необходимо вникнуть в текущие процессы, выявить узкие места и предложить решение по их устранению.
Рассмотрим распространенный пример:
Компания продает турецкие напольные покрытия. В штате 150 сотрудников. Отдел продаж ведет отчеты по статусам заказов, отгрузок и собирает обратную связь в excel-файлах. Возникла потребность внедрить в отдел продаж CRM-систему. Для чего она нужна?
Бывают и задачи более специфического характера.
Допустим, есть глобальный производитель цемента и сухих смесей. У компании дочерние предприятия по всему миру в том числе в России. Все работают на едином западном ПО. Из-за внешнеполитических факторов российскую «дочку» в ближайшее время планируют отключить от иностранного ПО. Нужно разработать для компании оптимальную схему перехода на российское ПО, без потери функциональности.
Когда дело касается крупного бизнеса, практически не существует полностью идентичных шаблонных задач. Всегда приходится учитывать массу особенностей и нюансов. Поэтому без предпроектного обследования просто не обойтись, а поверхностное, формальное отношение к ППО может обернуться для заказчика большими потерями.
Глобально можно выделить четыре этапа:
Проектная группа со стороны исполнителя ведет диалог с ключевыми сотрудниками со стороны заказчика, которые являются владельцами обследуемых бизнес-процессов компании. И здесь не обязательно включать в процесс топ-менеджмент. Зачастую важнее со всей тщательностью расспросить линейных сотрудников, которые заняты на рутинных процессах. Обычно хватает 2-3 человек.
Проектной группе важно предложить такое решение, которое не только устранит текущие «боли» сотрудников, но и будет грамотно выстроенным с технической точки зрения: не сломает базовую архитектуру системы и не повлияет на обновления ядра системы.
Когда все требования к функционалу системы собраны и проанализированы, проектная группа переходит к декомпозиции полученных требований. В результате декомпозиции формируется концепция системы:
Проектная группа направляет концепт на согласование руководству компании.
В результате согласования концепт может быть принят руководством, и тогда команда исполнителя переходит к следующему этапу «Написание ТЗ».
В случае, если руководство не согласовало концепт, так как в нем не описан желаемый функционал или описан недостаточно подробно. Тогда команда исполнителя переходит на повторный круг внесения изменений и после заново согласует его с руководством.
Снова обратимся к примеру.
У производственной компании существует два типа контрактов, стандартный и офферный (когда менеджер сам предлагает нестандартные ценовые условия). Узкое место — согласование контрактов — проходит где-то во внутренних документах менеджера, в таблицах или в личной переписке. После ППО может быть предложено комплексное решение, автоматическую воронку статусов согласования контракта: «не обработано — на согласовании — отклонен — согласован».
В процессе согласования с руководством предложенного концепта выясняется, что информации о статусе недостаточно, дополнительно в карточке контракта необходимо фиксировать комментарии от каждого согласованта, причины отклонения и необходимые корректировки по контракту. В связи с чем требования к функционалу были расширены.
Таким образом руководство всегда в курсе текущего статуса контрактов, а менеджеры не отвлекаются от работы.
На этом этапе исполнитель и заказчик обсуждают все идеи по автоматизации бизнес-процессов, после чего разрабатывается последовательный план действий с четко прописанными схемами.
Грамотное ТЗ состоит из следующих пунктов:
Чтобы готовое техническое задание превратилось в утвержденный план действий, его нужно согласовать с лицом, принимающим решение по проекту на разработку системы.
На основании согласованного ТЗ на реализацию системы компания подрядчика приступает к декомпозиции ТЗ и оценке стоимости и сроков проекта.
В результате этапа формируется смета проекта:
Таким образом, в смете будет изложен перечень задач и ресурсы, требуемые для выполнения указанных задач, в разрезе данных: наименование специалиста — ставка часа, занятость на проекте (10, 25, 50, 100% от восьми часов), количество месяцев участия на проекте — количество часов в месяц — количество часов на проекте — стоимость.
На первый взгляд это логично. Кто знает бизнес лучше, чем его собственник и руководство. В реальности это довольно рисковый подход. При разработке системы важен не только взгляд изнутри, но и опытный и «незамыленный» взгляд со стороны на процессы компании, которые можно автоматизировать в новой системе. Взгляд профессионала, который реализовал уже подобные проекты, обладает необходимым уровнем насмотренности, компетенций и знает «подводные камни».
Руководитель компании может хорошо знать рабочий процесс, но углубляться в понимание того, как этот процесс поведет себя в различных сценариях, у него нет времени. Невозможно смотреть на каждый участок глазами линейного сотрудника, а это важно. У руководства и рядового сотрудника разное понимание конечной цели.
В практике случались ситуации, когда исполнитель реализовал в точности ТЗ заказчика, однако ожидания заказчика, как оказалось, были иными, так как заказчик описал требование неоднозначно. В результате репутация исполнителя пострадала, а заказчику все равно нужно выделять новый бюджет на новую разработку.
Без профильного опыта и знаний заказчик не сможет предоставить разработчику перечень необходимых задач, с описанием в точности «шаг за шагом». У топ-менеджера нет временного ресурса для разбора и изучения поведения процессов и сценариев.
Из этого следуют два золотых правила:
На первый взгляд, такое решение кажется очевидным, но это опасное заблуждение.
Практика показывает, что даже если ваш конкурент занимается точно такой же деятельностью, организация бизнес-процессов на ваших предприятиях далеко не идентична.
В каждом отдельном бизнесе есть свои особенности, без которых он не может функционировать. Если внедрить программу один в один «как у соседа», она не будет удовлетворять вашим требованиям. В реальности пока не существует, и вряд ли когда-нибудь появится «идеальный» программный продукт, который подойдет всем без исключения и будет включать одинаковые настройки.
Зависит от масштаба и сложности задач. Исходя из нашей практики, самый короткий срок — 40 часов, самый долгий — 800 часов. Это долгий и ресурсозатратный процесс, поэтому схема «при заказе у нас проект в подарок» здесь неприменима.
Предпроектное обследование это намного больше, чем просто подготовка к внедрению новых инструментов автоматизации. Заказчик получит документы и артефакты, которые позволят планировать стратегическое развитие бизнеса на годы вперед.
Таким образом предпроектное обследование — это не только детальный пошаговый план по модернизации бизнес-процессов, но и гарантия для заказчика, что в ходе реализации проекта не возникнет недопонимания и неприятных сюрпризов. А еще оно создаст задел для дальнейшей модернизации компании на годы вперед.