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

Компания планирует внедрение Битрикс24 и перечисляет задачи:

  • автоматизировать продажи;
  • связать CRM с 1С;
  • организовать закупки;
  • автоматизировать согласование договоров и счетов;
  • подключить сервисные процессы;
  • организовать склад;
  • перенести внутренние согласования;
  • автоматизировать часть HR-процессов;
  • настроить управленческую аналитику.

После этого интегратору предлагают определить архитектуру, подходящий вариант Битрикс24, этапы проекта, сроки, команду и стоимость.
Такой документ полезен. По нему уже можно понять масштаб проекта, увидеть основные функциональные контуры и сформировать вопросы.
Но большой список требований ещё не означает, что проект достаточно определён для точной оценки.

Коротко

До подробного обследования обычно можно:

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

Но точная архитектура, фиксированный объём, срок и стоимость требуют более детального ответа на вопросы:

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

Поэтому вопрос не в том, может ли интегратор назвать цену после первого документа.
Назвать цифру можно.

Вопрос в том, насколько эта цифра опирается на определённый объём работ, а не на допущения.

Список требований и техническое задание - не одно и то же

Фраза «нужно автоматизировать сервис» хорошо описывает направление работы.
Но для реализации ещё нужно понять:

  • откуда появляется сервисная заявка;
  • кто её принимает;
  • как определяется ответственный;
  • какие бывают типы обращений;
  • какие сроки контролируются;
  • какие документы используются;
  • требуется ли выезд;
  • как учитываются запчасти;
  • что происходит при повторном обращении;
  • когда заявка считается закрытой;
  • какие показатели нужны руководителю.

То же самое относится к формулировке «интегрировать Битрикс24 с 1С».
Нужно определить, какие данные участвуют в обмене, где они создаются и изменяются, какая система отвечает за конкретные данные, что запускает обмен и как обрабатываются ошибки.

Поэтому между:

Нужно связать Битрикс24 с 1С.
и:
Согласован конкретный сценарий интеграции, который можно оценить и реализовать.

может находиться отдельный этап анализа и проектирования.

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

Почему 50 требований могут давать меньше информации, чем один описанный процесс

Количество пунктов не показывает, насколько хорошо определена задача.
Например:

Автоматизировать согласование договоров.

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

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

Что интегратор может определить до обследования

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

Интегратор может:

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

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

Например:

Оценка относится только к первой очереди, без переноса исторических данных и без доработки 1С.

Так понятно, что именно было посчитано.

Почему точность оценки зависит от сценариев

Стоимость внедрения определяется не только перечнем функций Битрикс24.

На трудоёмкость напрямую влияют:

  • бизнес-сценарии;
  • исключения;
  • данные;
  • интеграции;
  • настройки и разработка;
  • тестирование;
  • запуск.

Рассмотрим простой пример.
Требование:

После перехода сделки на определённую стадию автоматически создать задачу.

Если стадия одна, задача одна, исполнитель известен заранее, а дополнительных условий нет, сценарий достаточно определён.
Теперь добавим условия:

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

Название задачи почти не изменилось. Объём реализации изменился существенно.
Поэтому фиксированная оценка становится надёжнее тогда, когда зафиксирован конкретный набор сценариев, а не только общий желаемый результат.

Какие неизвестные сильнее всего влияют на проект

Пользователи и организационная структура

Важно понимать не только общее количество сотрудников.

Для проектирования имеют значение:

  • подразделения;
  • роли;
  • различия между процессами подразделений;
  • уровни управления;
  • ограничения доступа;
  • распределение ответственности.

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

Процессы и исключения

Базовый сценарий обычно описать проще всего.
Сложность часто появляется в исключениях:

  • клиент не прислал документ;
  • договор вернулся на доработку;
  • ответственный отсутствует;
  • платёж получен частично;
  • нужного товара нет;
  • один заказ выполняют несколько подразделений.

Автоматизация должна учитывать не только идеальный путь.

1С и другие системы

Фразы «у нас есть 1С» недостаточно для оценки интеграции.
Нужно понять:

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

Пока эта граница не определена, интеграционный контур остаётся верхнеуровневой гипотезой.

Данные и миграция

«Перенести данные» может означать разный объём работы.
Нужно определить:

  • какие объекты переносить;
  • за какой период;
  • из каких источников;
  • требуется ли история;
  • есть ли дубли;
  • как сопоставлять справочники;
  • что делать с неполными и некорректными записями.

Иногда миграция является небольшой частью проекта. Иногда требует отдельной проработки.

Права и ограничения

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

Очередность

Фраза «внедрить единую систему для компании» описывает целевое состояние, но не план перехода к нему.
Комплексный проект часто разумно делить на очереди.

Например:

  1. продажи;
  2. договоры и согласования;
  3. интеграция с учётной системой;
  4. сервис;
  5. остальные внутренние процессы.

Это только пример. Конкретная последовательность зависит от связей между процессами и бизнес-приоритетов.

Когда одно ТЗ фактически содержит несколько контуров

В рассматриваемом кейсе в одном исходном документе были объединены CRM, закупки, договорная работа, производство, сервис, склад, HR, аналитика и интеграция с 1С.
Формально всё это можно назвать одним внедрением Битрикс24.

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

  • процессы;
  • владельцы;
  • данные;
  • интеграции;
  • исключения;
  • критерии готовности.

То, что хорошо описан процесс продаж, ещё ничего не говорит о сложности сервиса.
Понятная схема согласования договоров не определяет объём интеграции с 1С.

Поэтому при комплексной автоматизации полезно сначала определить:

  1. Какие задачи действительно должны решаться в Битрикс24?
  2. Какие функции должны остаться в других системах?
  3. Какие контуры зависят друг от друга?
  4. Что имеет смысл запускать первой очередью?

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

Где заканчивается предварительная оценка и начинается предпроектное обследование

Граница проходит не по количеству встреч или страниц документа.
Она проходит по типу работы.

На предварительном этапе можно:

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

Но если для ответа необходимо:

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

это уже отдельная инженерная работа.

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

Что должно быть результатом предпроектного обследования

Обследование имеет смысл оценивать не по количеству проведённых встреч, а по результату.

В зависимости от проекта на выходе могут быть:

  • описание текущего состояния;
  • целевые процессы;
  • границы Битрикс24 и других систем;
  • интеграционный контур;
  • требования к данным;
  • перечень необходимых изменений;
  • ограничения;
  • риски;
  • приоритеты;
  • этапность;
  • роли заказчика и исполнителя;
  • тестовые сценарии;
  • критерии приёмки;
  • бэклог реализации;
  • уточнённая оценка следующего этапа.

Задача обследования не в том, чтобы узнать о компании всё.
Нужно снять ту неопределённость, которая мешает принять решение по архитектуре, объёму и следующему этапу проекта.

Почему обследование тоже должно иметь границы

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

До его начала желательно зафиксировать:

  • какие процессы исследуются;
  • какие системы рассматриваются;
  • какие вопросы должны получить ответ;
  • какие материалы будут подготовлены;
  • какие решения остаются на стороне заказчика;
  • что считается завершением этапа.

Иначе обследование рискует превратиться в процесс без понятного критерия готовности.

Когда отдельное обследование не нужно

Не каждое внедрение требует предпроекта.
Например:

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

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

Здесь заказчик уже определил, что должно происходить.
Интегратору остаётся корректно реализовать согласованный объём.
То есть необходимость обследования определяется не самим фактом использования Битрикс24, а уровнем неопределённости проекта.

Можно ли получить фиксированную цену до обследования

Да, если объём достаточно определён.
Если ключевые процессы, интеграции и исключения ещё неизвестны, фиксированная сумма всё равно будет основана на каких-то допущениях.

Поэтому важнее не сам формат цены, а то, что вместе с ней зафиксировано:

  • какие сценарии входят;
  • какие работы исключены;
  • какие исходные условия предполагаются;
  • что считается новым требованием;
  • как обрабатываются изменения объёма.

Одинаковая формулировка «фиксированная стоимость» может относиться к очень разным по определённости предложениям.

Как сравнивать предложения нескольких интеграторов

Если компания выбирает подрядчика для большого внедрения, сравнивать только итоговые суммы недостаточно.
Одна цена может включать проектирование, миграцию и интеграции.
Другая может относиться только к настройке Битрикс24 после того, как все требования подготовит заказчик.

Поэтому при сравнении полезно проверить:

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

Только после этого итоговые суммы становятся сравнимыми.

Что прислать интегратору для первой оценки

Необязательно самостоятельно проектировать будущую систему.
Для первого обсуждения полезнее подготовить информацию о самом бизнес-процессе:

  • какие задачи нужно решить;
  • какие подразделения входят в проект;
  • что является главным приоритетом;
  • как работа организована сейчас;
  • какие проблемы нужно устранить;
  • какие системы уже используются;
  • что ведётся в 1С;
  • какие системы должны сохраниться;
  • какие данные должны передаваться между ними;
  • что хотелось бы запустить первым;
  • кто со стороны компании принимает решения.

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

Хорошее ТЗ уменьшает неопределённость

Качество технического задания определяется не количеством страниц.
Для оценки гораздо важнее, насколько понятно описаны:

  • результат;
  • сценарии;
  • границы;
  • данные;
  • ответственность систем;
  • исключения;
  • критерии готовности.

Для небольшой задачи это может быть короткий документ.
Для комплексного внедрения часть информации может появиться только в ходе отдельного предпроектного этапа.
Поэтому большой документ не обязательно является подробным ТЗ, а короткое описание не обязательно является поверхностным.
Главный критерий - достаточно ли информации, чтобы определить объём и проверить результат.

Частые вопросы

Можно ли бесплатно оценить внедрение Битрикс24?

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

Что должно быть в ТЗ на внедрение Битрикс24?

Состав зависит от проекта.
Для оценки важно определить не только перечень функций, но и сценарии, роли, данные, интеграции, ограничения, исключения и критерии готовности.

Можно ли назвать фиксированную стоимость до обследования?

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

Чем предпроектное обследование отличается от ТЗ?

ТЗ фиксирует требования к будущему решению.

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

Нужно ли обследование для небольшого внедрения?

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

Кто должен готовить техническое задание - заказчик или интегратор?

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

Можно ли внедрять Битрикс24 поэтапно?

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

Главное

Перечень требований - хороший первый шаг.

Он помогает понять, чего компания хочет от Битрикс24 и какие процессы затрагивает проект.

Но если в одном документе одновременно находятся CRM, закупки, производство, сервис, внутренние процессы, HR, аналитика и интеграции, количество перечисленных требований само по себе не делает оценку точной.

Для каждого существенного блока важно разделить:

  • что уже известно;
  • что пока является допущением;
  • что нужно дополнительно исследовать;
  • что можно зафиксировать только после проектирования.

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

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

Дальше

Другие материалы