{"id":14274,"url":"\/distributions\/14274\/click?bit=1&hash=fadd1ae2f2e07e0dfe00a9cff0f1f56eecf48fb8ab0df0b0bfa4004b70b3f9e6","title":"\u0427\u0435\u043c \u043c\u0443\u0440\u0430\u0432\u044c\u0438\u043d\u044b\u0435 \u0434\u043e\u0440\u043e\u0436\u043a\u0438 \u043f\u043e\u043c\u043e\u0433\u0430\u044e\u0442 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u0430\u043c?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"6fbf3884-3bcf-55d2-978b-295966d75ee2"}

11 Советов по выбору и внедрению CRM-систем. Записки бизнес-консультанта.Совет 7. Планирование проекта внедрения

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

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

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

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

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

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

Разбиение проекта на этапы решает ряд задач, как со стороны заказчика, так и со стороны интегратора, а именно позволяет:

· спланировать получение бизнес-результата в кратчайше сроки;

· учесть сезонный фактор загрузки сотрудников и провести внедрение при минимальной нагрузке на пользователей;

· учесть фактор лояльности филиалов и пиковой загрузки при планировании тиражирования системы на региональные филиалы (рекомендуется начинать проведение программы внедрения с наиболее лояльных департаментов/регионов);

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

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

При планировании работ обязательно учитываются возможности по распараллеливанию части задач у команд интегратора и Заказчика. Обычно удается распараллелить задачи настройки объектной модели/бизнес-процессов и интеграций, как с точки зрения формирования ТЗ, так и с точки зрения разработки, поскольку физически в каждой из команд этими процессами занимаются разные сотрудники (бизнес-процесса – бизнес-заказчики и бизнес-аналитики; интеграции – сотрудники ИТ и системные аналитики).

В среднем на крупном проекте внедрения (от 100 АРМ) процесс внедрения занимает от 9 до 12 мес. Первый этап, разработка ТЗ, занимает от 2 до 4 месяцев (об этом подробно в следующем материале). Второй этап, настройка объектной модели системы и бизнес-процессов, занимает 3-4 месяца. Третий этап, настройка интеграций, занимает также 3-4 месяца. Для ускорения проекта этот этап может проводиться параллельно с этапом 2. Четвёртый этап, передача системы в ОПЭ, включает тестирование, обучение, доработки системы и др., занимает 1-2 месяца. Далее происходит переход к промышленной эксплуатации и технической поддержке проекта.

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

С моей точки зрения, наиболее оптимальной выглядит схема, когда на начальном этапе Интегратор настраивает объектную модель, базовый набор функционала и интеграций, проводит внедрение. А дальнейшее развитие системы (новые процессы, изменения, отчеты, поддержку пользователей) ведет внутренний сотрудник – технолог/разработчик Системы. Подобная схема позволяет с одной стороны сэкономить средства на оплате интегратору, с другой - обеспечивает возможность быстрого запуска доработок и гибкость в вопросах формализации постановки задачи (здесь разумно применять те самые популярные ныне Agile-подходы).

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

Еще одной особенностью проектов внедрения CRM является необходимость проведения параллельного внедрению внутреннему проекту Заказчика по разработке внутренней документации: политик - клиентской, скидочной, контактной и др., регламентов, схем классификации/сегментации клиентов, печатных форм и других методологических документов. На ряде проектов при старте формировался документ под названием График предоставления документов заказчиком, в котором перечислялись документы, необходимые интегратору для реализации проекта. Статус этого документа контролировался в виде регулярного отчета, поскольку оказывал влияние на сроки реализации проекта в целом. Необходимость разработки новых внутренних документов связана с тем, что в «доCRMный» период жизни в компании многие вопросы решались не стандартизовано, не централизовано, а новый уровень автоматизации требует от заказчика нового уровня организационного управления. Как следствие, попытки автоматизировать устаревшие процессы является одним из значимых рисков на проектах внедрения CRM.

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

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

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

0
Комментарии
-3 комментариев
Раскрывать всегда