Как задолбать всех коллег: собираем требования к CRM06.02.2018 13:48

Вы замечали, насколько по-разному покупают люди, например, смартфоны? Один подходит, уверенно берёт нужную модель и может проконсультировать всех вокруг, второй робко слоняется вдоль витрины, трогает экраны и оценивает вес и яркость, третий открывает камеру и делает селфи, четвёртый набирает «Привет! Как дела», тестируя клавиатуру одной рукой. Ничего необычного — каждый смотрит то, что ему важнее. Хуже, когда так же покупают CRM или ERP — буквально с закрытыми глазами, бегло глянув на яркую презентацию или прочитав советы на форуме. Потом сыпятся негативные отзывы, а автоматизация вызывает стойкую неприязнь. Казалось бы, что проще — собрать требования и приступить к трезвому выбору вендора. Но нет, инструкцию будем читать потом, когда сломается… А вот, собственно, и подробная инструкция.

Если вы вендор CRM-систем или любого другого ПО/сервиса/услуги для бизнеса, то наверняка знаете, что пользователь с хорошо собранными требованиями — большая редкость. Мы в RegionSoft составили список самых распространённых случаев:

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

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

Рабочая группа

Если в компании больше одного подразделения, то один человек не справится с внедрением CRM, даже если к нему на подмогу придёт орава бизнес-консультантов (на самом деле, они никому не помогут, только денег отъедят, но мы сегодня не об этом). Поэтому первый шаг, который предстоит сделать для качественного сбора требований, это создать рабочую группу. В неё могут войти руководители подразделений (это самый простой и очевидный вариант), а могут — самые сильные и включённые сотрудники, которые владеют всей информацией и вникают во все процессы. Вы же не будете говорить, что начальники отделов всегда самые грамотные и опытные? Вот и мы не будем. Члены рабочей группы должны:

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

Это удивительное дело, но стоит сформироваться группе и начать составлять первый шаблон сбора требований, так сразу неплохие, в общем-то, коллеги превращаются в агрессивных акул. В этом нет ничего предосудительного: каждый хочет сделать так, чтобы автоматизация покрыла как можно больше задач именно его подразделения. Такое положение вещей сглаживается либо в ходе работы либо после первой встречи (созвона) с вендором, который объясняет, что софт сам не продаёт, клиентов не ищет, код не пишет, баги не фиксит и деньги не зарабатывает. То есть работать всё равно придётся.

Несколько моментов:

В рабочую группу обязательно должен входить CTO, CIO или CEO. Ну или соответствующие им люди с менее пафосными названиями.
Не стоит поручать внедрение одному лишь директору по продажам или по маркетингу — они непременно стянут одеяло на себя, и у вас будет не просто лоскутная, но ещё и дырявая автоматизация (если вообще будет). Дело в том, что CRM-система — это не просто набор функциональности, это программный комплекс, с которым работают сразу несколько подразделений (либо вся компания целиком), и важно, чтобы внедрение прошло гладко и с практической (пользовательской), и с технической стороны, без перекосов в сторону того или иного отдела.
Все действия, обсуждения и заключения рабочей группы должны протоколироваться, чтобы не упустить важную информацию и исключить дальнейшие разбирательства.

Примерный план работы проектной группы по внедрению CRM

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

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

На этом этапе особенно важно, чтобы CRM-система не превратилась в инструмент давления, шантажа или превосходства. Например, маркетинг может объявить себя холдером всех процессов и оттеснить продажи, проигнорировать их интересы. Или, например, лидер рабочей группы может «забыть» пригласить к обсуждению представителей технической поддержки, думая, что они воспримут систему как данность. Такой расклад уже давно описан в известной басне Крылова:

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

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

Базовое самообследование компании

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

Итак, что вам непременно понадобится для выбора CRM-системы и дальнейшего внедрения.

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

Размер и примерная структура клиентской базы. Первое, что вам надо знать — это какой тип карточки клиента вам понадобится: для юридических или физических лиц (ну или оба и ещё доработанный для B2G —, а вдруг?). Второе — увы и ах, но некоторые вендоры до сих пор умудряются продавать СУБД клиентам отдельно, и вы при 100 000 записей можете, например, влететь на необходимость покупки MS SQL. Ну и опять же, это важный элемент анализа бизнес-процессов. Заодно вы оцените, где и как хранится ваша клиентская база, какая её часть потеряна, бесполезна или «крысится» продажниками.
Список потенциальных пользователей CRM-системы, можно прямо поимённо. Во-первых, вы оцените будущие затраты на обучение, во-вторых, сможете наметить ранних последователей, будущих холдеров процессов и внутренних экспертов.
Уже существующий в компании пул программного обеспечения нужен вам для того, чтобы понять, что из имеющегося зоопарка сможет заменить CRM-система (и за что вы перестанете платить), с чем придётся интегрироваться, откуда мигрировать, а что так и останется работать, как работало. Например, RegionSoft CRM в самой навороченной конфигурации Enterprise способна заменить все планировщики, картотеку клиентов с исчерпывающим досье, почтовый клиент, систему управления проектами, складскую программу, тикет-систему и багтрекер (для нетехнической компании, хотя мы сами её используем для этих целей вполне успешно), базу знаний и проч.
Бюджет на CRM (покупка + внедрение). Мы уже писали, сколько стоит CRM — почитайте подробный текст на эту тему. Повторимся лишь, что нередко прайс-лист и калькулятор на сайте разработчика и цена проекта внедрения — абсолютно разные вещи, всё зависит как раз от ваших потребностей (в доработке, обучении, установке, поддержке и т.д.).

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

Ищите вендора

Поиск вендора — отдельная большая история, в которой нет мелочей. Считайте, в ближайшей перспективе эта компания станет вашим партнёром, помощником и консультантом. Мало, что сойтись должно всё: от отношений до потребностей, так ещё и важно, чтобы вас не бросили на полпути. А такое может легко случиться, если вы, например, доверитесь молодой компании-разработчику, которая через год внезапно решит, что продавать раскрашенные сноуборды выгоднее, чем пилить и поддерживать CRM (так и есть). Но это такой минимальный «визуальный» отбор, на самом деле есть более важные маркеры неплохого вендора.

Тип поставки CRM-системы. Буквально года три назад, на пике повальной моды на облака, мы могли бы агрессивно написать «не берите облачников — у них цена владения заоблачная». Однако разработчики быстро огляделись, увидели, что приличный бизнес не всё и не всегда готов доверить облачному хранилищу (клиентскую базу и данные о поставщиках в первую очередь) и почти все серьёзные вендоры выпустили и облачные SaaS-версии (платите каждый месяц, храните в облаке), и серверные SaaS (платите каждый месяц, храните у себя) и полный on-premise (платите один раз + за обновления, храните у себя). Не будем мучить вас расчётами, всё уже было написано до нас и нами. Ну и да, цена аренды всегда выше, но иногда аренда оправдана.
Обновляемость системы — спросите вендора, как часто происходят минорные обновления, как часто — мажорные, что входит в те и другие, какие из них платные, какие — нет, как они накатываются.
Опыт компании-вендора (или его отдельных сотрудников) в сфере, аналогичной вашей. В принципе, в подавляющем количестве случаев этот пункт необязателен — внедрение в большинстве сфер довольно однородно. Но если у вас специфическая отрасль (медицинский центр) или вы — крупный завод, то не лишним будет узнать у вендора, есть ли у него опыт похожих внедрений. Опыта и функциональности CRM-ки для стартаперов может просто не хватить для внедрения в производственно-торговом холдинге.
Возможность доработки системы силами вендора — в принципе, пункт кажется очевидным, и разработчик всегда готов доработать свою систему. Но всё же уточняйте — бывает, что бизнес-модель системы не предполагает глубокую кастомизацию.
Ресурс вендора в отношении технической поддержки — уточните, что входит в платную техподдержку, что в бесплатную, какие категории инцидентов и в какие сроки обслуживаются. Платная ТП — это абсолютно нормально, главное, понять, за что платите: за приоритет, за опыт сотрудников, за сложность или за всё вместе взятое.
Возможность обучения — тоже вроде бы очевидная вещь, на которой однако вендоры могут и сэкономить и отказаться от обучения вовсе или под видом обучения провести презентацию продукта. Некоторые популярные вендоры на российском рынке представляют отсутствие необходимости обучить персонал как маркетинговое преимущество, так и заявляя, что «обучение не требуется», а в «интерфейс легко влюбиться». Ну, во-первых, вам с интерфейсом работать, а не на свидания ходить, а во-вторых это звучит примерно как «вот на механике нужно учиться, а с коробкой автомат две педальки, одна ручка — сел и поехал». Понятно, что обучение необходимо более, чем в половине компаний (а по-честному, во всех) — хотя бы для того, чтобы сотрудники могли задать вопросы и быстро стартовать основную работу в системе.

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

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

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

Вот список того, что чаще всего нужно от CRM-системы любой компании:

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

Это необходимый и обязательный минимум, который нужен любому бизнесу в России. Сюда же, к функциональным требованиям относят специфические требования, характерные для конкретного бизнеса: управление производством, управление складом, кассы, сканеры штрих-кодов, интеграция с сайтом и т.д. Все перечисленные возможности в идеале должны реализовываться внутри интерфейса системы и комплиментарных ей продуктов-сателлитов (например, у нас есть базовый продукт — RegionSoft CRM, а расширение её возможностей происходит за счёт наших же разработок — VoIP Connector и Application Server, но никак не за счёт сторонних приложений). Однако может быть так, что часть функционала реализована за счёт плагинов сторонних разработчиков. Если ваш выбор пал на такую систему — приготовьтесь платить и за них тоже.

Вы можете спросить, зачем собирать вот эти требования, ведь они есть абсолютно во всех системах — сложно представить CRM без менеджера контактов или какого-никакого календаря, например. Отвечаем.

Нет, не у всех. Даже среди CRM «на слуху» можно найти системы, например, без коллективного или перспективного планирования рабочих задач, без адекватной интеграции с телефонией и т.д.
Вам может быть что-то особенно важно — например, флажки статуса клиента в карточке, всплывание карточки при звонке, возможность делегирования задач, приватные клиенты или просмотр воронки продаж в разрезе менеджеров, периодов и т.д. Мелочь, а у кого-то её может не быть и это уже платная доработка, в то время как у другого вендора всё это есть в базовой поставке.
Опять же, нужно проверить весь список необходимой вам функциональности и уточнить, поддерживается ли он вендором или необходима доработка.

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

Тот самый диалог

Что ещё важно знать, собирая функциональные требования к CRM.

Когда требования будут собраны, обязательно проставьте приоритеты и ранжируйте список: по срочности (что должно быть сразу, а что — потом) и важности (что можно реализовать в последнюю очередь).
Вам не нужно создавать ТЗ — его разрабатывает ваш вендор. Почему — мы уже объясняли один и второй раз.
Не нужно прибегать к формализации (квалифицированный лид должен быть передан соответствующему менеджеру согласно внутренней процедуре К-8785ап «О формировании пула заинтересованных лиц и делегировании процесса продаж») или писать фривольно (когда продаван впаяет этому лоху кпэшку, обметить его красным и кинуть ропу для сабмита). Пишите простым человеческим языком, желательно русским — у вас нет задачи показать себя, у вас есть задача донести до инженеров и аналитиков вендора свои пожелания.
Не стремитесь вписать в требования всё, что нужно и не нужно — тут нет понятия «всякий случай». Если есть сомнения в необходимости функциональности, отправьте такие пункты в отдельный блок. Может так случиться, что после старта использования CRM-системы вы пересмотрите процессы и что-то вам уже не понадобится.

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

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

Если CRM облачная, обязательно запросите информацию о том, как часто создаются бэкапы, где они хранятся, на каких условиях предоставляются владельцу данных (то бишь вам). Узнайте показатель доступности — в идеале вам должны в рамках договора гарантировать 99,9% времени безотказной работы. Узнайте, сколько занимает аварийное восстановление данных. Спросите, на серверах какой страны будут храниться данные (скорее всего, это у всех Россия, но всё же уточните, потому что вам предстоит хранить клиентскую базу — то есть персональные данные).
Пропишите требования к интеграции: с телефонией, 1С, виртуальной АТС и проч.
Определите требования к миграции и импорту данных. Составьте список источников, откуда предстоит мигрировать существующие данные (записи в Excel, СУБД старой CRM или иного ПО и т.д.). Часть накопленной информации вам придётся перенести вручную, большую часть электронных данных вам поможет перенести вендор.
Любого вендора расспросите о масштабировании — что будет, если у вас втрое вырастет количество пользователей, а если на 1 млн. (ну или иное число в ваших масштабах) увеличится количество записей? Укажите в требованиях возможную нагрузку на CRM-систему (у нас 7 000 клиентов, до 600 000 покупок в месяц, по каждой сделке нужно хранить минимум 7 документов и т.д.).
Определите требования к стоимости — сколько вы готовы потратить на CRM. Разобраться в нюансах ценообразования проекта внедрения CRM вам поможет эта статья.
Пропишите требования к удалённой/мобильной работе, если в вашей компании это необходимо. Желательно пояснить, кем и как будут использоваться удалённые и мобильные возможности.

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

Бизнес-требования

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

Поэтому с бизнес-требованиями обязательно нужно поработать.

Для начала определите цели и задачи вашего бизнеса. Основное отличие: цели — это большие и глобальные (рост продаж на 140% за год), задачи — небольшие и выполнимые (обучить персонал новой технологии продаж, внедрить автоматизацию, привлечь клиентов высокодоходного сегмента и проч.). Скорее всего, вендору эта информация не будет полезной, а вот вам самим для понимания и настройки бизнес-процессов — вполне. Внимание! Не требуйте выполнения этих задач от вендора, он вам даёт инструмент, ваша задача — овладеть им как самурайским мечом.

А вот после этого нужно приступать к самому важному моменту — пересмотру бизнес-процессов в компании.

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

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

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

Важные замечания по процессу сбора требований

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

Все требования по сути — контрольный список того, что у вас должно быть, и с которым вы будете сопоставлять функциональность выбранных CRM-систем. Поэтому прописывайте даже мельчайшие детали, чтобы максимально точно подобрать «свой» софт.
Не забывайте присваивать категории важности каждому требованию. Создайте стандартную для себя шкалу и ориентируйтесь по ней (например, высокая важность, средняя важность, низкая важность, факультативно).
Работая над требованиями, мысленно прогоняйте в голове модель использования того, о чём вы пишите. CRM должна стать не идеалом и не дорогой вазой империи Цин на полке, а инструментом, решающим конкретные деловые задачи, вашим помощником. Поэтому не нужно писать в требованиях несбыточные желания, хотелки и прочие фантазии. Только рабочий процесс, только деловой подход.

Нужно ли мне это всё?

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

Чаще всего компании игнорируют требования. Причин на то масса: начиная с того, что CRM навязали сверху и заканчивая тем, что никому не охота разбираться в хитрых отношениях внутри компании. Могу провести аналогию с автомобилем: если вы сами переберёте электрику и повесите кучку проводов на соплях, есть вероятность, что оно поедет и даже повезёт, но в какой-то момент обязательно откажет сигнал или не сработает поворотник. А это уже прямой путь к ДТП. Так и тут — в «бардачной» компании можно работать, зарабатывать, получать премии и т.д. Но однажды из-за разлаженности процессов пойдут крупные сбои, которые приведут к потере сотрудников, ушедшим клиентам и просевшей прибыли.

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

И да, мы просто не имеем права в такой теме не вставить картинку, вечную и актуальную: