{"id":14275,"url":"\/distributions\/14275\/click?bit=1&hash=bccbaeb320d3784aa2d1badbee38ca8d11406e8938daaca7e74be177682eb28b","title":"\u041d\u0430 \u0447\u0451\u043c \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0446\u044b \u0430\u0432\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f72066c6-8459-501b-aea6-770cd3ac60a6"}

11 Советов по выбору, внедрению CRM-систем. Совет 4.Подготовка к тендеру. Сбор требований, разработка схемы ИТ-ландшафта

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

Не пытайтесь объять необъятное. При сборе бизнес-требований будьте прагматиками. Иначе задуманный «космолет» будет оценен подрядчиками как «золотой», но при этом так никогда и не взлетит.

· Сбор и приоритезация бизнес-требований.

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

· Общие требования («коробка» или облако, требования по безопасности; популярность системы, наличие специалистов, масштабируемость, быстродействие и др.)

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

· Требования по интеграции (ERP-система, почтовая и телефонная системы, BI, специализированные программы)

· Требования к отчетности

· Требования к интерфейсам и эргономике

· Специализированные требования, сформулированные в рамках разработки целевой модели бизнес-процессов.

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

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

· Формирование целевой схемы ИТ-ландшафта.

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

Речь идет о следующих основных системах компании, обычно уже внедренных к моменту старта проекта по CRM:

ü ERP-система (для обмена данными c CRM по договорам, счетам, платежам, актам и др.)

ü Документооборот (интеграция по процессу согласования договоров)

ü Почтовая система (получение и отправка сообщений непосредственно из CRM -системы)

ü Телефонная система (поднятие карточки клиента при входящем звонке и набор номера непосредственно из CRMсистемы)

ü Web-сайт (получение лидов с сайта)

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

Масштабные проекты внедрения CRM обязательно включают в себя интеграции со всеми перечисленными основными системами. Сложность обычно связана с наличием «экзотических» систем в ИТ-ландшафте заказчика. Например, когда в качестве ERP-системы используется SAP или MS Navision, вместо наиболее распространенной 1С. В качестве почтовой системы – IBM/Lotus Notes, а не стандартный MS Exchange. И так далее по всем другим типам систем. При наличии нестандартных ИТ-систем, во время проведения тендера, рекомендуется уделить особое внимание выяснению наличия опыта реализации подобных интеграций у интегратора и вендора. Отсутствие подобного опыта скорее всего приведет к новой серьезной разработке, с соответствующим увеличением сроков и стоимости проекта.

На основе проведенного обследования разрабатывается и согласуется с заказчиком финальный документ – RFP, который включает в себя следующие модули:

§ Глоссарий (важно строить систему на общей базе терминов)

§ Цели проекта

§ Количественные параметры (число пользователей по ролям), географические и временные рамки проекта

§ Схемы и описание целевых процессов

§ Реестр бизнес-требований

§ Целевую схема ИТ-ландшафта

§ Требования к организации поддержки системы

§ Требования к участникам тендера.

Срок проведения предпроектного обследования обычно составляет 1,5 - 2 месяца в случае привлечения внешнего консультанта. И растягивается на 3-4 месяца при реализации собственными силами (как в виду операционной загрузки участников, так и зачастую в связи с неумением организовывать проектное взаимодействие собственными силами). Оформление Предпроектного обследования в отдельный Проект является важнейшим шагом. Это свидетельство перехода компании от обсуждения к практической плоскости, готовности добиваться поставленных целей, а также к выделению финансовых и временных ресурсов.

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

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