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

Что такое предпроектное обследование (ППО)

Это подготовительный этап для разработки или внедрения продукта. Комплекс действий, который поможет заказчику и подрядчику понять, какие ресурсы потребуются для реализации проекта. ППО особенно актуально, когда автоматизацию бизнес-процессов или разработку нового ПО выполняют не силами самой компании, а с привлечением стороннего подрядчика. ППО позволяет ответить на такие вопросы, как:

  • Для каких целей создают систему.
  • Какие проблемы она решит.
  • Какие выгоды она принесет.
  • Какие материальные, технические и трудовые ресурсы потребуются для реализации проекта.

После сбора, обработки и системного анализа данных, специалисты формируют для заказчика две картины: «AS-IS» — как осуществляется процесс сейчас и «TO-BE» — как все будет работать после автоматизации.

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

Рассмотрим распространенный пример:

Компания продает турецкие напольные покрытия. В штате 150 сотрудников. Отдел продаж ведет отчеты по статусам заказов, отгрузок и собирает обратную связь в excel-файлах. Возникла потребность внедрить в отдел продаж CRM-систему. Для чего она нужна?

  1. Сотрудники компании смогут вести сделки по жизненному циклу в автоматизированной воронке продаж, которая, посредством роботов, будет:
    • уведомлять задействованных сотрудников о промежуточном/ итоговом результате по сделке;
    • запускать процесс согласования ценовых условий для клиента/ коммерческого предложения, позволяя направлять задания ответственным лицам и фиксировать результат согласований в едином окне;
    • запускать рассылки, например, по сегментам клиентов;
    • коммерческий отдел сможет исследовать конверсию продаж с целью анализа эффективности работы отделов компании.
  2. Система будет автоматически фиксировать все коммуникации с клиентом в едином окне, а также в разрезе каждого заказа.

Бывают и задачи более специфического характера.

Допустим, есть глобальный производитель цемента и сухих смесей. У компании дочерние предприятия по всему миру в том числе в России. Все работают на едином западном ПО. Из-за внешнеполитических факторов российскую «дочку» в ближайшее время планируют отключить от иностранного ПО. Нужно разработать для компании оптимальную схему перехода на российское ПО, без потери функциональности.

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

Из чего состоит ППО

Глобально можно выделить четыре этапа:

1. Интервьюирование

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

  • Как выстроена работа сейчас?
  • Что их не устраивает в текущем положении дел?
  • Как они видят решение проблем?
  • Как процесс должен отрабатывать в новой системе?
  • С какими смежными системами взаимодействуют сотрудники в рамках своего процесса?

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

2. Разработка концепции информационной системы

Когда все требования к функционалу системы собраны и проанализированы, проектная группа переходит к декомпозиции полученных требований. В результате декомпозиции формируется концепция системы:

  • Текущие бизнес-процессы компании.
  • Бизнес-процессы после автоматизации.
  • Ролевая модель (структура и сущности работы отделов).
  • Рекомендации к устранению текущих проблем.

Проектная группа направляет концепт на согласование руководству компании.

В результате согласования концепт может быть принят руководством, и тогда команда исполнителя переходит к следующему этапу «Написание ТЗ».

В случае, если руководство не согласовало концепт, так как в нем не описан желаемый функционал или описан недостаточно подробно. Тогда команда исполнителя переходит на повторный круг внесения изменений и после заново согласует его с руководством.

Снова обратимся к примеру.

У производственной компании существует два типа контрактов, стандартный и офферный (когда менеджер сам предлагает нестандартные ценовые условия). Узкое место — согласование контрактов — проходит где-то во внутренних документах менеджера, в таблицах или в личной переписке. После ППО может быть предложено комплексное решение, автоматическую воронку статусов согласования контракта: «не обработано — на согласовании — отклонен — согласован».

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

Таким образом руководство всегда в курсе текущего статуса контрактов, а менеджеры не отвлекаются от работы.

3. Написание технического задания

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

Грамотное ТЗ состоит из следующих пунктов:

  • Актуальность — какие проблемы должна решить разработка системы.
  • Организационный объем — количество подразделений и количество сотрудников в каждом подразделении, которые будут работать в новой системе.
  • Ролевая модель — перечисление подразделений компании с правами каждого подразделения. Например, с сущностью контракта работает только отдел контрактования, у его сотрудников есть право читать, изменять документ и т. д., соответственно у других подразделений нет прав даже на просмотр контрактов. Руководство компании имеет право на просмотр контрактов.
  • Процессы AS-IS (опционально) — определение процессов компании, которые должны быть заведены в новую систему и описание этих процессов в модели AS-IS, сопровождаемое схематическим описанием в нотации BPMN 2.0, а также UML-диаграммами. Описание процессов AS-IS по умолчанию в ТЗ не закладывается, но может быть добавлено по требованию заказчика.
  • Функциональные требования — четкое детализированное решение для каждого бизнес-процесса, сопровождаемое схематическим описанием в нотации BPMN 2.0, а также UML-диаграммами. Описание процесса — как должна отработать система для всех сценариев.
  • Нефункциональные требования — требования к материально-технической части. Описание инфраструктуры системы, отвечающей требованиям заказчика по безопасности, производительность и масштрабируемости.

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

4. Расчет сметы проекта

На основании согласованного ТЗ на реализацию системы компания подрядчика приступает к декомпозиции ТЗ и оценке стоимости и сроков проекта.

В результате этапа формируется смета проекта:

  • спецификация работ, предусмотренных в рамках проекта;
  • состав команды, необходимой в рамках проекта;
  • сроки проекта.

Таким образом, в смете будет изложен перечень задач и ресурсы, требуемые для выполнения указанных задач, в разрезе данных: наименование специалиста — ставка часа, занятость на проекте (10, 25, 50, 100% от восьми часов), количество месяцев участия на проекте — количество часов в месяц — количество часов на проекте — стоимость.

Какие материалы получает заказчик по результатам ППО

  • Техническое задание на разработку системы.
  • Смету с расчетом проекта, указанием сроков реализации и информации по ключевым специалистам.

Может ли заказчик провести ППО своими силами

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

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

В практике случались ситуации, когда исполнитель реализовал в точности ТЗ заказчика, однако ожидания заказчика, как оказалось, были иными, так как заказчик описал требование неоднозначно. В результате репутация исполнителя пострадала, а заказчику все равно нужно выделять новый бюджет на новую разработку.

Без профильного опыта и знаний заказчик не сможет предоставить разработчику перечень необходимых задач, с описанием в точности «шаг за шагом». У топ-менеджера нет временного ресурса для разбора и изучения поведения процессов и сценариев.

Из этого следуют два золотых правила:

  1. Все мысли, идеи и решения команды должны быть записаны аналитиком на бумаге или в электронном сервисе заметок. Тогда информацию проще структурировать и презентовать в понятном виде как топ-менеджеру, так и разработчику.
  2. Разработку проекта лучше поручить той же команде, которая проводила ППО.

Можно ли в точности скопировать систему коллег или конкурентов

На первый взгляд, такое решение кажется очевидным, но это опасное заблуждение.

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

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

Сколько длится ППО

Зависит от масштаба и сложности задач. Исходя из нашей практики, самый короткий срок — 40 часов, самый долгий — 800 часов. Это долгий и ресурсозатратный процесс, поэтому схема «при заказе у нас проект в подарок» здесь неприменима.

Какие выгоды получает заказчик после проведения ППО

Предпроектное обследование это намного больше, чем просто подготовка к внедрению новых инструментов автоматизации. Заказчик получит документы и артефакты, которые позволят планировать стратегическое развитие бизнеса на годы вперед.

Что останется у заказчика после ППО

  • Документ с детальным описание бизнес-процессов в компании. У заказчика будет возможность сравнить текущее состояние бизнес-процессов с тем, как они будут функционировать с участием новой системы.
  • Рекомендации, как оптимизировать бизнес-процессы от экспертов по внедрению CRM.
  • Несколько вариантов внедрения предложенной системы. Заказчик сможет выбрать оптимальное решение по целям, срокам и бюджету. Еще до начала внедрения проекта он будет знать стоимость и сроки реализации проекта, с учетом рисков и возможности для доработки будущей системы.
  • Описание общей концепции информационных систем и их взаимосвязи. Это позволит в будущем не переделывать всю систему из-за неверного выбора ПО или отдельных решений.
  • Документ с оценкой текущих ресурсов предприятия в части программного и технического обеспечения. Заказчик заранее будет понимать, нужно ли будет заложить дополнительные денежные средства на обеспечение инфраструктуры информационной системы.

Таким образом предпроектное обследование — это не только детальный пошаговый план по модернизации бизнес-процессов, но и гарантия для заказчика, что в ходе реализации проекта не возникнет недопонимания и неприятных сюрпризов. А еще оно создаст задел для дальнейшей модернизации компании на годы вперед.

Анастасия Еремичева, аналитик RDN Group