Что должно быть готово после этапа проектирования
Проектирование CRM оценивается не по количеству встреч, а по фактически достигнутым результатам, которые можно использовать в работе. Если по завершении этого этапа руководитель проекта все еще не может составить план работ, разработчик не знает, какой объект управляет процессом, а менеджер по данным не понимает, откуда поступает информация о клиентах, — значит, проектирование не завершено, даже если презентация одобрена.
Данное руководство описывает семь ключевых результатов. Для каждого из них определен критерий готовности: одно утверждение, на которое можно ответить «да» или «нет». Если ответов «почти» наберется более двух, то переход к этапу реализации сопряжен с риском, который уже можно оценить. Общий обзор этапов после проектирования представлен в Руководстве по внедрению Salesforce.
Результат 1: Карта процессов с уровнем принятия решений
Это не детальная блок-схема каждого клика, а карта точек принятия решений: кто принимает решение, на основе какой информации, что происходит в каждом ответвлении и что происходит при отсутствии решения. Большинство сбоев в проектах CRM возникают не в стандартном процессе, а в его ответвлениях — замороженная сделка, клиент, вернувшийся через два года, запрос, открытый не тем клиентом.
Критерий готовности: можно взять реальную сделку за последний месяц и отследить ее по карте от начала до конца без пробелов.
Результат 2: Бизнес-глоссарий
Этим результатом чаще всего пренебрегают, и на этом же чаще всего платят. «Клиент» означает одно в финансах и другое в продажах. «Активный проект» интерпретируется по-разному в операционной деятельности и в управлении. Пока определения не зафиксированы, каждый отчет вызывает споры.
Глоссарий для каждого термина должен содержать: определение в одном предложении, сущность в Salesforce, которая его представляет, поле, определяющее статус, и департамент, ответственный за это определение.
Результат 3: Утвержденная базовая модель данных
На этапе проектирования не создается полная ERD (диаграмма «сущность-связь»), но принимаются решения по четырем вопросам, изменение которых впоследствии будет дорогостоящим:
- Основывается ли бизнес-активность на Opportunity, на пользовательском объекте или на их комбинации, и каково соотношение между ними.
- Представляет ли Account юридическое лицо, физическое местоположение или группу закупок — и как обрабатывается иерархия.
- Каков уникальный идентификатор, который связывает клиента между Salesforce и основными системами.
- Какие исторические данные будут перенесены в систему, а какие останутся в источнике.
Критерий готовности: можно нарисовать на доске пять основных объектов и связи между ними, не открывая файл.
Результат 4: Модель полномочий и доступа
Модель полномочий определяется вопросом о том, кто не должен видеть информацию, а не о том, кто должен видеть. Эти два вопроса кажутся одинаковыми, но приводят к противоположным архитектурным решениям. Хорошее проектирование определяет организационные настройки по умолчанию для каждого основного объекта, механизм расширения и исключительные случаи, требующие особого доступа.
| Вопрос | Что проверяется при проектировании | Почему это дорого изменить позднее |
|---|---|---|
| Настройка по умолчанию для объекта | Приватный (Private), Общий доступ на чтение (Public Read) или Чтение/Запись (Read/Write) | Влияет на весь механизм совместного доступа выше |
| Структура иерархии | Отражает ли иерархия ролей управление или географию | Изменение требует пересчета доступа по всем записям |
| Межфункциональный доступ | Общие команды, ручной доступ или критерии | Определяет необходимость специализированной логики |
| Конфиденциальные данные | Какие поля ограничены и кому | Последующее изменение может раскрыть уже просмотренную информацию |
Результат 5: Карта систем и источников истины
Для каждой основной сущности должен быть один объявленный источник истины и четкое направление синхронизации. Проектирование, которое оставляет две системы «обновляющими друг друга», создает конфликты, которые проявятся только в процессе эксплуатации. Карта должна также включать частоту и допустимую задержку: процесс продаж может выдерживать синхронизацию в течение пяти минут, кредитный контроль — обычно нет.
Результат 6: Критерии приемки для ключевых процессов
Это связь между проектированием и тестированием. Для каждого ключевого процесса требуется от трех до пяти приемочных критериев, сформулированных как наблюдаемый результат: «После закрытия сделки заказ создается в основной системе в течение пяти минут с тем же идентификатором клиента». Такая формулировка является одновременно требованием, тестовым сценарием и определением завершения. Без этого этап UAT (пользовательское приемочное тестирование) превращается в сбор комментариев по дизайну.
Результат 7: Базовые показатели до изменений
Невозможно доказать улучшение без предварительного измерения. На этапе проектирования выбираются три-пять показателей и измеряются в текущем состоянии, даже если измерение выполняется вручную и приблизительно. Выбор показателей и способ их привязки к бизнес-выгоде подробно описаны в Руководстве по ROI и показателям успеха Salesforce.
Иллюстративный пример: Сеть частных клиник
Следующий сценарий является гипотетическим и предназначен только для иллюстрации. Сеть клиник с восемью филиалами приступила к проекту CRM для централизации запросов пациентов. В ходе проектирования выяснилось, что два филиала по-разному определяют «повторный запрос»: один считает каждый звонок, другой — только запрос по новой теме. Различие казалось семантическим, но оно определяло, нужна ли системе один объект Case с иерархией или два отдельных объекта, и влияло на все отчеты по нагрузке для руководства.
Команда не разрешила этот спор в документе. Она зафиксировала открытое решение, назначила ответственного на уровне операционного директора и установила крайний срок до начала разработки. Решение было принято в течение двух недель, и модель была построена однократно. Если бы решение было отложено, оно бы проявилось на этапе UAT — после того, как уже были созданы экраны и отчеты на основе ошибочного предположения.
Признаки поверхностного проектирования
- В документе описываются экраны и поля, но не описывается, что происходит при сбое процесса.
- Нет зафиксированных решений, альтернативы которым были рассмотрены.
- Все требования имеют высокий приоритет.
- Рядом с процессами нет имен людей, только названия отделов.
- Количество полей, запрашиваемых на одном экране, превышает двадцать пять, и никто не проверил, кто их заполняет.
Связь между поверхностным проектированием и возникающими впоследствии сбоями подробно описана в Руководстве по типичным ошибкам внедрения CRM, а его влияние на сроки проекта объясняется в Руководстве по длительности проектов Salesforce.
При замене существующей системы
Когда проект предполагает замену устаревшей CRM, проектирование получает дополнительную задачу: определить, что не будет переноситься. Старая система накапливает поля, автоматизации и отчеты, которыми уже никто не пользуется, и их слепое копирование переносит старый «технический долг» на новую платформу. Рекомендуемый порядок действий при такой миграции подробно описан в Руководстве по замене CRM на Salesforce.
Как понять, что можно начинать разработку
Проанализируйте семь результатов и для каждого задайте вопрос о готовности. Если шесть из семи отвечают «да», можно начинать первый этап, управляя седьмым пунктом как задокументированным риском. Если три или более отвечают «почти», лучше продлить этап проектирования на две недели, чем обнаруживать пробелы после трех месяцев работы, построенной на неполных данных.
Следующий логичный шаг — это преобразование результатов в поэтапный план, с четким решением о том, что входит в первую волну, а что сознательно откладывается.