Почему «без ТЗ результат ХЗ». Разбираем на примере CRM-систем

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

К нам пришла компания с внедренной CRM-системой. Компания клиента давно существует на рынке. Несмотря на то, что ее процессы не описаны «на бумаге» — они работают довольно хорошо, но не системно.

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

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

Как обычно заказывают внедрение системы

Почему интеграторы делают то, что не поможет клиенту

Проблема № 1 — Недополученная прибыль

Проблема № 2 — Бесконечный цикл внедрения

Проблема № 3 — Ожидания ≠ результат

Проблема № 4 — Непонятная стоимость проекта

Этап № 0. Бизнес-цели

Этап № 1. Сроки и бюджеты

Этап № 2. Требования

Этап № 3. Ролевые модели, объекты системы и данные

Этап № 4. Моделирование процессов «как есть»

Этап № 5. Моделирование процессов «как должно быть»

Этап № 6. Точки интеграции

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

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

Клиент со своей стороны хочет быстрее получить КП, чтобы показать руководству свою эффективность.

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

Сотруднику, который занимается сбором предложений, нельзя ошибиться перед своим руководством, но они не могут объяснить, зачем нужно ТЗ, и просят простую поверхностную оценку, а сверху просто закладывают бОльший бюджет на ошибки (в лучшем случае).

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

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

Прежде чем выбирать по цене — нужно понять, как интегратор делал оценку. Как минимум вы потеряете время, как максимум —деньги.

Иногда разработчики предлагают работать без оценки, по часам. Еще это называют Time&Material. Работает это так: есть согласованная ставка — прилетает задача — делаем — сколько потратили, столько потратили.

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

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

Часто интеграторы не пытаются узнать, зачем клиент хочет сделать ту или иную задачу: что решает проект, как он повлияет на финансы компании?

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

Разберем типовые проблемы, которые возникают из-за отсутствия ТЗ.

Когда бизнес работает давно, и ему нужно внедрить систему — нет права на ошибку. Пару лет назад мы делали CRM, и параллельно клиент у себя делал систему учета (ERP). Но из-за того, что процессы не были формализованы, не получилось их оцифровать.

Когда запустили ERP-систему — она заблокировала работу из-за отсутствия нужных сценариев. Отгрузки встали.

Это очень опасно, как для клиента, так и для интегратора. Расскажем на нашем примере проекта по фиксированной стоимости.

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

Проект растянулся на 2 года по времени и ушел в бесконечный цикл правок. По итогу мы поняли, что мы накосячили с тем, что не прописали четкое ТЗ в самом начале, и решили прекратить работу по проекту.

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

С одной стороны — клиент в постоянной «запаре» и не может четко понять, что именно ему нужно сделать. С другой — интегратор, который делает все четко по словам клиента и не понимает, почему каждый раз приходится все переделывать.

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

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

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

Требования могут менять и это нормально, ведь бизнес — это живой организм. Но ТЗ должно покрывать хотя бы 80-90% кейсов, а все изменения нужно документировать, чтобы потом не потеряться.

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

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

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

Но проблем достаточно, давайте разберемся, как их избежать.

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

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

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

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

Важно сделать изменения в первый год, чтобы в оставшиеся 4 года обеспечивать этот рост. А возможно после первого года приоритеты изменятся и задачи поменяются.

Возвращаясь к нашему примеру — сроки мы уже определили (1 год).

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

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

Представим, что наш потенциал роста — 15 млн. Значит бюджет проекта может составить 5 млн. Но вообще, ваши финансисты подскажут подробнее.

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

Пример функциональных требований:

Нефункциональные требования — это те требования, которые не отражает прямой функционал системы. Например:

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

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

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

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

Отдельно еще важно упомянуть про миграцию данных. Нужно описать процесс перехода информации из текущей системы в будущую: из какой системы в какую мигрируем и какую глубину данных (за год или за последние 10 лет) мы забираем.

Далее составляем карты маппинга — старая система → новая система

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

Зачем это нужно

Мы описываем процессы с использованием BPMN, но можно использовать и простые блок-схемы. Обычно выделяют 3 уровня моделирования процессов:

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

Согласовательный уровень — это уровень для руководства, которое заинтересовано в улучшении процесса. Как правило, руководителям интересны: результаты; основные задачи; исполнители и KPI процесса. Тут схема должна быть максимально простой и понятной.

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

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

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

Зачем нужно

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

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

Если расписать все эти этапы, то получится документ на 20-30 страниц А4. Для примера — можете посмотреть пример такого ТЗ на нашем сайте.