Когда руководитель компании получает предложения от нескольких интеграторов на одно и то же внедрение, разница в оценках нередко выглядит абсурдной: один подрядчик называет одну сумму, второй — в полтора-два раза больше, а третий предлагает сначала оплатить предпроектный анализ.
Возникает закономерный вопрос: кто ошибается и не пытается ли интегратор просто продать ещё один этап работ?
На самом деле предпроектный анализ — полезный инструмент, но не обязательная процедура для каждого проекта. Его ценность напрямую зависит от сложности бизнеса и уровня неопределённости.
Главная задача такого анализа — не «поговорить с заказчиком перед внедрением», а снизить неопределённость и понять, что именно предстоит автоматизировать.
Что такое предпроектный анализ простыми словами
Предпроектный анализ — это исследование того, как компания работает сейчас и что именно должна делать будущая система.
Аналитик изучает не только пожелания руководителя вроде «нам нужна CRM» или «хотим автоматизировать закупки». Он пытается разобраться, что происходит в реальной работе:
- какие сотрудники участвуют в процессе;
- кто и в какой момент принимает решения;
- какие документы создаются и где они хранятся;
- откуда берутся данные;
- какие системы уже используются;
- какие действия выполняются вручную;
- где есть согласования;
- какие бывают исключения из стандартного сценария;
- какие данные нужно передавать между системами.
Иными словами, аналитик смотрит не на отдельную кнопку в будущей системе, а на весь процесс от начала до результата.
Почему интеграторы дают настолько разные оценки
Причина часто не в том, что один подрядчик «дорогой», а другой «дешёвый».
Они могут по-разному понимать сам объём проекта.
Например, фраза «внедрить CRM для отдела продаж» может означать совершенно разные вещи.
Для одного интегратора это:
настроить воронку, карточку клиента, несколько ролей и подключить телефонию.
Для другого:
построить сложный процесс продаж с несколькими типами сделок, индивидуальными маршрутами согласования, интеграцией с ERP, автоматическим расчётом коммерческих предложений и обменом документами.
Оба подрядчика формально отвечают на один и тот же запрос, но оценивают разные проекты.
Поэтому при сравнении предложений руководителю важно смотреть не только на цену, но и на то, что именно подрядчик включил в эту цену.
Когда полноценный предпроектный анализ не нужен
Не каждый проект настолько сложен, чтобы проводить отдельное исследование.
Если речь идёт о понятной CRM-системе, стандартном процессе продаж и нескольких типовых интеграциях, опытный интегратор зачастую может достаточно точно оценить проект уже на этапе первичного обследования.
Например, компания:
- продаёт стандартный набор товаров;
- имеет один отдел продаж;
- работает по понятной воронке;
- использует одну CRM;
- хочет подключить телефонию и корпоративную почту;
- не требует сложных согласований;
- не имеет собственного производства;
- не нуждается в сложном обмене данными с десятком информационных систем.
В такой ситуации полноценный предпроектный анализ может оказаться экономически неоправданным.
Если процесс понятен, система типовая, а количество интеграций ограничено, необязательно оплачивать отдельный большой этап только потому, что так принято у интегратора.
Грамотный подрядчик должен уметь сказать: «Здесь достаточно обычной оценки, отдельное обследование вам не нужно».
Где проходит граница
Предпроектное исследование становится особенно важным там, где непонятно заранее, сколько вариантов процесса и скрытых зависимостей существует внутри компании.
Риск существенно возрастает, если в проекте присутствуют:
- несколько подразделений с разными правилами работы;
- сложные бизнес-процессы;
- производство;
- закупки;
- складская логистика;
- многоступенчатые согласования;
- сложный документооборот;
- несколько информационных систем;
- нестандартные интеграции;
- большое количество ролей и прав доступа;
- различные сценарии для разных категорий клиентов или товаров;
- значительное количество исключений и ручных операций.
В таких проектах фраза «нам нужно автоматизировать закупки» практически ничего не говорит о реальном объёме работ.
Сначала необходимо выяснить, как именно устроены закупки.
Что на самом деле изучает аналитик
Хороший предпроектный анализ — это не набор общих интервью и не презентация на несколько десятков слайдов.
Аналитик пытается восстановить реальную картину работы компании.
1. Текущие процессы
Как процесс начинается, какие этапы проходит и чем заканчивается?
Например, закупка может начинаться не с заявки сотрудника, а с автоматического сигнала о снижении складского остатка.
2. Роли сотрудников
Кто выполняет каждую операцию?
Один сотрудник может создавать заявку, другой — проверять бюджет, третий — выбирать поставщика, четвёртый — согласовывать стоимость, а финансовый директор — утверждать платеж.
3. Точки принятия решений
Где процесс может пойти по разным сценариям?
Например:
- сумма до 100 тысяч рублей — согласует руководитель отдела;
- от 100 тысяч до 1 миллиона — директор;
- выше 1 миллиона — несколько руководителей.
Это уже существенно влияет на будущую систему.
4. Документы
Какие документы используются, кто их создаёт, кто подписывает и где они хранятся?
Иногда выясняется, что один процесс связан с договором, счётом, спецификацией, заявкой, актом и несколькими версиями согласования.
5. Источники данных
Откуда система должна получать информацию?
Данные могут находиться в CRM, ERP, бухгалтерской системе, Excel-файлах, интернет-магазине, на файловом сервере или вообще поступать по электронной почте.
6. Исключения
Это один из наиболее важных элементов анализа.
В регламенте может быть написано, что все заявки проходят стандартный маршрут. Но на практике существует десяток исключений.
Например, срочную закупку можно провести без обычного согласования, а стратегического клиента обслуживать по отдельному сценарию.
Именно такие исключения часто становятся причиной неожидательного роста стоимости разработки.
7. Интеграции
Важно понять не только с чем нужно интегрироваться, но и что именно системы должны передавать друг другу.
Фраза «интегрировать CRM с ERP» звучит просто. Но на практике необходимо определить:
- какие данные передаются;
- в каком направлении;
- с какой периодичностью;
- какая система является источником истины;
- что происходит при ошибке;
- как обрабатываются дубли;
- что делать, если одна система временно недоступна.
Это уже непосредственная часть оценки проекта.
Экономика предпроектного анализа
Здесь возникает главный вопрос: если анализ стоит денег, почему бы не начать сразу разработку?
Потому что стоимость разработки зависит от того, насколько хорошо мы понимаем объём работ.
Условно у проекта есть две величины:
известный объём + неопределённость.
Если неопределённость маленькая, её можно принять на себя и сразу оценить проект.
Если неопределённость большая, она превращается в риск для обеих сторон.
Для заказчика это риск получить дополнительные счета, перенос сроков и бесконечные изменения требований.
Для интегратора — риск взять проект по слишком низкой цене и обнаружить уже в процессе, что реальный объём значительно больше.
Качественный предпроектный анализ позволяет часть этой неопределённости убрать до начала основной разработки.
Поэтому его правильнее воспринимать не как «лишний этап», а как инвестицию в определённость проекта.
Почему после анализа проще сделать техническое задание
Техническое задание часто пытаются написать сразу после нескольких встреч с заказчиком.
Но если процессы ещё не исследованы, получается документ, в котором много формулировок вроде:
«система должна обеспечивать удобное согласование заявки».
Проблема в слове «удобное». Для разработчика оно практически ничего не значит.
После анализа формулировка может стать конкретной:
«Заявка на закупку стоимостью до 100 000 рублей направляется на согласование руководителю подразделения. При превышении лимита добавляется согласование финансового директора. Для срочных закупок предусмотрен отдельный маршрут».
Теперь разработчику понятно, что именно необходимо реализовать.
Таким образом, предпроектный анализ упрощает подготовку технического задания, потому что превращает общие пожелания в описанные процессы, правила и требования.
Два примера
Пример 1. Простая компания
Компания продаёт офисную мебель.
В ней 12 менеджеров, один руководитель отдела продаж и бухгалтерия.
Клиент оставляет заявку, менеджер связывается с ним, формирует коммерческое предложение, получает заказ и передаёт его на исполнение.
Руководство хочет:
- внедрить CRM;
- настроить воронку продаж;
- подключить телефонию;
- интегрировать корпоративную почту;
- настроить несколько автоматических уведомлений.
Процесс стандартный, участников немного, исключений мало.
Здесь вполне разумно сразу оценить внедрение без отдельного полноценного предпроектного анализа.
Интегратор может провести несколько рабочих встреч, уточнить требования и сформировать коммерческое предложение.
Пример 2. Сложная компания
Теперь представим производственную компанию с несколькими филиалами.
Продажи принимают заказы клиентов. После этого данные поступают в ERP. Производство проверяет возможность изготовления, закупки рассчитывают потребность в материалах, склад контролирует остатки, финансовый блок проверяет лимиты, а руководители согласуют нестандартные условия.
Дополнительно есть:
- несколько типов заказов;
- разные правила для филиалов;
- производственное планирование;
- закупки;
- склад;
- электронный документооборот;
- несколько уровней согласования;
- CRM;
- ERP;
- бухгалтерская система;
- интеграции с внешними сервисами.
Здесь попытка оценить всё «с ходу» — уже риск.
Потому что невозможно надёжно определить объём работ, пока не понятно, как реально взаимодействуют все эти подразделения и системы.
В таком случае предпроектный анализ становится оправданным.
Как руководителю оценивать предложение интегратора
Не стоит задавать вопрос только:
«Почему вы хотите сначала провести предпроектный анализ?»
Лучше спросить:
«Какую неопределённость вы собираетесь снять в ходе анализа и как его результаты повлияют на итоговую оценку проекта?»
Хороший интегратор должен суметь объяснить:
- какие процессы будут исследованы;
- с какими сотрудниками будут проведены интервью;
- какие системы и интеграции будут изучены;
- какие результаты компания получит на выходе;
- как результаты анализа повлияют на состав работ;
- какие вопросы после анализа перестанут быть неопределёнными.
Если ответ сводится к «так положено по нашей методологии», это слабое обоснование.
Если же интегратор показывает конкретные риски, которые необходимо выяснить до разработки, — предпроектный анализ имеет понятную экономическую ценность.
Главное правило
Предпроектный анализ не должен становиться ритуальным платным этапом каждого внедрения.
Для небольшого и понятного проекта разумнее быстро определить требования, оценить объём и начать работу.
Но чем больше в проекте подразделений, процессов, интеграций, документов, согласований и исключений, тем опаснее оценивать его «по аналогии» или только по нескольким пожеланиям руководителя.
Простой проект можно оценить. Сложный проект сначала нужно понять.
Именно в этом и заключается основная ценность предпроектного анализа: он не делает внедрение дороже ради самого анализа. Он помогает сделать понятнее что именно покупает компания, какой объём работ ей действительно нужен и где находятся основные риски проекта.
А уже после этого становится значительно проще сравнивать предложения разных интеграторов — не по красивой итоговой цифре, а по сопоставимому объёму работ и понятному результату.