Как правильно составить требования к CRM для крупного бизнеса

• Что такое функциональные требования?
• Особенности функциональных требований к CRM для производства
• Что должно быть в функциональных требованиях к CRM
• Составляем функциональные требования к CRM для производства: 5 шагов
• Управление бюджетом при составлении требований
• Частые ошибки в функциональных требованиях и сопутствующие риски
• 4 совета от эксперта
• Вопросы для самопроверки

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

С чего начать? Чем функциональные требования отличаются от техзадания? Что обязательно нужно учесть и написать в этом документе? Как попасть в собственный бюджет и не наделать ошибок? С нашим экспертом, руководителем отдела интранет-систем ИНТЕРВОЛГИ Дарьей Кугатовой составили гайд, который поможет вам правильно написать функциональные требования к CRM для производства и крупного бизнеса.

Что такое функциональные требования?

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

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

Особенности функциональных требований к CRM для производства

Главное отличие CRM для предприятий и крупного бизнеса от систем торговых и сервисных компаний — более высокий уровень сложности бизнес-процессов:

• индивидуальный расчет цен по формулам с множеством переменных;

• длинный цикл сделки — от первого касания до завершения проходят месяцы;

• множество потоков данных и их пересечений;

• зависимость отдела продаж от производства и наоборот;

• длинные маршруты согласований.

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

Пример: место CRM-системы на производственном предприятии

Что должно быть в функциональных требованиях к CRM

В функциональных требованиях к CRM для крупного предприятия нужно отразить:

1. Цели и задачи внедрения CRM.

2. Объекты системы (сделка, лид, закупка, рекламация и т.д.).

3. Роли пользователей и их права доступа.

4. Описание автоматизируемых процессов как минимум на верхнем уровне.

5. Какая отчетность и аналитика необходимы.

6. Какие необходимы интеграции с внешними системами (1С, SAP, складской учет и другие). Какой объем данных будет поступать в CRM извне за единицу времени.

7. Необходим ли импорт данных в CRM. Если да, то тип и объем информации.

8. Нефункциональные требования, в первую очередь, к безопасности и производительности системы.

Этот список можно использовать в качестве структурного плана функциональных требований.

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

• проанализировано ли взаимодействие отделов: как они коммуницируют, какие зависимости существуют между их действиями;

• учтены ли интересы и потребности всех взаимосвязанных с продажами подразделений (производство, склад, закупки, маркетинг, логистика и т.д.);

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

• какие операции занимают много времени, но при этом их можно назвать рутинными — это первые претенденты на автоматизацию.

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

Составляем функциональные требования к CRM для производства: 5 шагов

Как собрать, проанализировать и правильно изложить информацию в функциональных требованиях к CRM? Ниже — 5 шагов к составлению идеального документа.

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

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

Анализ собранной информации позволит емко описать процессы, выявить объекты CRM и роли пользователей.

С указания целей внедрения CRM и компании в целом. Они — отправная точка проекта и служат маркером «нужности» и важности конкретных требований.

Исходя из целей, укажите задачи проекта, например:

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

• централизованное ведение клиентской базы, ее сегментирование;

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

• ускорение и повышение прозрачности взаимодействия подразделений;

• повышение точности планирования продаж и производства;

• упрощение найма и онбординга новых сотрудников.

Декомпозируйте задачи внедрения CRM в вашей компании и, исходя из этого, составьте список необходимых объектов в системе, процессов и ролей, участвующих в них. По мере дробления задач станет очевидно, какие потребуются интеграции и отчеты, сколько пользователей будут работать одновременно, насколько критичен отказ системы и допустимое время простоя (downtime).

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

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

Оптимальный уровень детализации требований — средний. Что это значит?

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

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

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

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

Чтобы достичь оптимального уровня детализации, можно использовать технику User Story (пользовательская история). Она помогает описать функции с точки зрения конечных пользователей: РОПа, менеджера по продажам, руководителя подразделения, начальника склада, топ-менеджеров и других сотрудников.

User Story содержит описание:

• роли пользователя;

• его потенциальных действий;

• желаемого результата.

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

При этом мгновенный доступ к плану загрузки производства могут иметь еще РОП, руководитель подразделения, топ-менеджмент и CEO — каждый со своими целями. Для каждой роли потребуется отдельная User Story.

Управление бюджетом при составлении требований

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

Итерационный подход предполагает запуск MVP (minimum viable product, минимально жизнеспособный продукт) в течение 3–4 месяцев с момента обращения. Пользователи получают достаточный функционал, чтобы начать работу в системе. Затем мы поэтапно внедряем остальные функции CRM.

Стоимость внедрения MVP значительно меньше, чем всего проекта. Вы быстрее видите отдачу от меньшего объема инвестиций по сравнению с ситуацией, когда крупная CRM разрабатывается и внедряется полностью в течение 8–12 месяцев.

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

Как это сделать?

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

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

1. Необходима безусловная реализация, потому что без нее система не будет работать как задумано (must).

2. Менее важные, но тоже необходимые требования к системе. Их нужно реализовать во вторую очередь (should).

3. Желаемые функции, запуск которых можно отложить на более поздний срок (could).

4. «Хотелки», без реализации которых система продолжит работать на достижение основных целей (would).

К четвертой категории обычно относят требования к внешнему виду и различные мелкие «фичи», которые делают работу в CRM более приятной и удобной.

Как составить функциональные требования под свой бюджет?

Скажем прямо — 100% работающего способа написать документ под конкретный бюджет нет. Но есть небольшой лайфхак, который поможет сориентироваться в рынке и не потратить собственные ресурсы впустую.

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

Частые ошибки в функциональных требованиях и сопутствующие риски

Через наши руки прошли сотни требований к CRM (и не только). Большинство написаны хорошо, но у некоторых были недостатки:

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

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

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

4. Отсутствие приоритизации. Без нее внедрение итерациями невозможно, а проект рискует превратиться в «Титаник». Монолитный сервис, запущенный спустя 8–12 месяцев после старта, трудно дорабатывать по замечаниям и отзывам эксплуатантов. Итог — ожидания расходятся с реальностью, а CRM не помогает достигать поставленных целей.

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

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

Перечисленные ошибки хотя и не являются критичными, но влекут существенные риски:

1. Ошибочные решения при реализации. Когда у команды интегратора нет отчетливого понимания, зачем и для чего внедряется CRM, велика вероятность предложить неверные решения и выбрать не те инструменты. Исправление этих ошибок требует времени, следовательно, удорожает проект.

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

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

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

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

6. Сложности с масштабированием. Когда у компании есть долгосрочные планы, особенно связанные с поэтапным внедрением софта, а интегратор о них не знает, в будущем это может создать барьеры для масштабирования. Лучше заранее предусмотреть возможности развития CRM и ее интеграции с новыми системами.

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

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

4 совета от эксперта

1. Не приступайте к описанию процессов и объектов системы, пока не сформулированы цели внедрения CRM. Это столп всего проекта. Без понимания целей с большей долей вероятности он провалится: системой перестанут пользоваться — инвестиции не окупятся.

2. Соотнесите описанное в функциональных требованиях к CRM с целями. Убедитесь, что всё направлено на удовлетворение потребностей вашего бизнеса и решение конкретных задач предприятия.

3. Не старайтесь детализировать функциональные требования, полагая, что так они быстрее станут техническим заданием. Создание техзадания — задача интегратора. Его пишут для разработчиков и тестировщиков, поэтому у документа своя специфика.

4. Проведите со всеми стейкхолдерами демо требований к CRM. Формат неважен, главное — показать документ всем заинтересованным лицам и согласовать его с ними. Иными словам, необходимо достичь согласия внутри компании прежде, чем передавать требования интегратору.

Вопросы для самопроверки

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

• определены цели и задачи внедрения?

• указаны все основные объекты системы?

• указаны роли пользователей и права доступа?

• достаточно полно описаны процессы (а не просто «Нужен процесс согласования КП»)?

• если требуется разработка отчетности, то есть ее описание?

• если требуется выгрузка данных либо их импорт/миграция, она описана?

• если требуется импорт данных, то уточнен и указан объем данных?

• указаны нефункциональные требования (скорость загрузки страниц, количество пользователей, при котором CRM нормально работает и т.д.)?

• указано количество записей за единицу времени, которые поступают в CRM из внешних систем, например, при интеграции с 1С?

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