«У нас в CRM бардак» - это ещё не техническое задание

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

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

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

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

Одна жалоба может означать разные проблемы

Например, в CRM не ставятся дела - следующие действия по клиенту. Что с этим делать?
Можно предположить, что сотрудникам неудобно пользоваться системой.
А можно - что они не знают, когда такое действие нужно фиксировать.
Или знают, но никто не проверяет исполнение.
Возможна и техническая проблема.
Пока это только разные объяснения одного симптома.

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

Мне важно разделять 3 вещи:

1. Симптом: что сейчас происходит или на что жалуются.
2. Причина: почему это происходит; её ещё надо проверить.
3. Решение: что именно нужно изменить после проверки.

Не всякая проблема с работой в CRM решается настройкой CRM.
И обратное тоже верно: если дело действительно в неудобном процессе внутри системы, один регламент его не исправит.

Не «что настроить», а «как должно работать»

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

Скажем, компания хочет, чтобы сделки сами переходили на следующий этап.
При каком событии?
Что делать, если нужных данных нет?
Кто должен получить уведомление об ошибке?
Как проверить, что переход сработал правильно?

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

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

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

Проблема есть. А решение её устранять?

Для себя я разделяю три разных события:

1. Кто-то заметил проблему и собрал замечания.
2. Компания решила, что проблему нужно устранять, и определила желаемый результат.
3. Компания выбрала способ решения и исполнителя.

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

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

Как выглядит задача, которую можно проверить

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

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

Возможное требование:

Когда во внешней системе появляется подтверждённая запись клиента, связанная сделка в CRM должна получить дату, время и соответствующую стадию. Если связанная сделка не найдена, ответственному должно прийти уведомление для ручной проверки.

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

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

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

Когда оценивать внедрение, а когда сначала описывать процесс

Я вижу два рабочих варианта.

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

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

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

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

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

Пять вопросов перед оценкой CRM-проекта

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

1. Кто принимает решение?
   Есть ли человек, который согласует цели, приоритеты и результат?

2. Что должно измениться в процессе?
   Не какие кнопки добавить, а как компания должна работать после проекта?

3. Как должна вести себя CRM?
   Какие события, условия, данные и исключения необходимо учесть?

4. Как будем принимать работу?
   Какие проверки покажут, что требование выполнено?

5. Что именно оцениваем?
   Реализацию согласованных требований или отдельный этап обследования и постановки задачи?

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

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