11 Советов по выбору и внедрению CRM-систем. Записки бизнес-консультанта. Совет 8. Что должно быть в составе ТЗ

Чекин Николай, CRM- архитектор, Главный редактор Guidebook CRM. www.nchekin.ru

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

Этап разработки Технического задания является обязательным при реализации проекта внедрения CRM. В результате Предпроектного обследования у вас появился документ под названием RFP, предназначенный для выбора CRM-платформы и партнера-интегратора, а также получения достаточно точной оценки стоимости проекта. Техническое задание предназначено для формализации детальных требований к разрабатываемой системе на базе уже выбранной CRM-платформы с учетом ее возможностей и ограничений. Именно потому оно не может быть заменено более высокоуровневым документом – RFP. Между тем, на проектах с проведенным предпроектным обследованием удается существенно сократить сроки на реализацию этапа ТЗ. Это достигается за счет проработанности ключевой бизнес-логики и возможности для интегратора быстрее погрузиться в специфику работы заказчика за счет наличия подробного документа.

Как показывает практика, не существует единых стандартов по составу и формату ТЗ. Чаще всего у зрелых интеграторов отводится значительное внимание этапу аналитики. Предлагаемые ими форматы документов достаточно информативны. Небольшие начинающие интеграторы зачастую ограничиваются минимальным составом описаний в ТЗ. Это вызывает в дальнейшем необходимость выделения большего времени на проработку требований уже на этапе внедрения и зачастую приводит к неприятному удивлению от первого показа настроенной по такому «псевдо-ТЗ» системы.

На ряде проектов на этапе ТЗ разрабатывается два отдельных документа. Первый, преимущественно для бизнеса, называемый, например, «Концепция внедрения CRM». А второй, преимущественно для ИТ-специалистов, может называться, например, «Технический дизайн». Если формируется одно общее ТЗ его также можно разделить на блоки, согласуемые только с бизнесом или ИТ.

Состав ТЗ должен включать следующие важные разделы:

· Глоссарий

· Целевые схемы и детальное описание бизнес-процессов, учитывающих возможности и ограничения выбранной CRM-платформы

· Объектную модель (список бизнес-объектов/сущностей системы и схему их взаимосвязей между собой)

· Описание параметров бизнес-объектов и справочников

· Описание интеграционного взаимодействия

· Описание модели безопасности и ролевой модели

· Описание схемы миграции данных

· Описание отчетности и др.

Дополнительно в ТЗ могут быть включены следующие разделы:

· расширенное описание специализированных нестандартных модулей, разрабатываемых в данном проекте;

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

· схемы смены статусов задач/запросов;

· список скрин-шотов макетов интерфейсов выбранной платформы

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

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

Напоминаю о возможности бесплатно скачать Guidebook CRM (в проекте по его созданию я выступил в качестве главного редактора и автора ряда материалов), получив ссылку на моем сайте: nchekin.ru. Здесь собраны обзоры экспертов, сравнения решений поставщиков и кейсы компаний-потребителей CRM-решений. К вашим услугам 489 страниц, 34 статьи экспертов, 38 кейсов компаний, 20 интервью с экспертами.

Информация из Guidebook CRM позволит вам в дальнейшем на равных вести переговоры с интеграторами, не давая вводить вас в заблуждение.

Продолжение следует.