Как Заказчику получить более точную оценку работ по внедрению CRM?

Автор: Анастасия Еремичева

Всем привет, меня зовут Анастасия Еремичева, я аналитик в компании RDN Group. Наша команда специализируется на разработке сложных и высоконагруженных решений для промышленных компаний: личных кабинетах, торговых площадках, порталах и интеграционных проектах. RDN Group – один из 30 партнёров 1С-Битрикс с расширенной компетенцией Enterprise.

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

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

Цифровой проект начинается с определения целей и задач. Исходя из этих данных, мы можем определить проблемы и боли в бизнес-процессах Заказчика.

Начнем с проблем, которые, как правило, устанавливаются во время пресейлов. Разберем их на конкретных примерах.

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

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

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

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

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

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

На основании вышеперечисленных проблем, мы можем выделить боли заказчика.

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

В случае с первым примером у компании несколько болей сразу:

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

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

Для HR отдела больше проблем: им надо создать вручную с помощью MS Office шаблоны онбординга для каждого отдела в зависимости от филиала, описать возможности геймификации и в таблице Еxcel подбивать результаты по каждому сотруднику, направлять все эти документы по разным источникам.

Для руководства собрать в Еxcel отчет о нанятых/ уволенных сотрудниках в рамках периода с фильтрацией по филиалам и закрепленному HR менеджеру.

Вести новости компании сразу в нескольких источниках (почта, мессенджеры) 

Все эти проблемы можно решить с помощью внедрения, настроив систему гибко под требования бизнеса.

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

Больше материалов на эту тему читайте в Компас CIO

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

Как правило, при внедрении CRM системы целевой аудиторией (ЦА) является:

• Отдел продаж.
• HR-отдел.
• Маркетинг и другие.

2. Установить функции и особенности системы.

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

3. Определить технические требования.

Если есть понимание технических требований проекта, то эта информация поможет выполнить проект в соответствии с нормами и стандартами ИТ политики компании Заказчика. Если требования не предоставлены, то исполнитель самостоятельно выбирает технологический стек. Отметим, что на этапе пресейла важно определить необходимые интеграции со смежными системами.

4. Определить требования к безопасности.

Заказчик предоставляет требования, если в компании есть регламенты, которые к этому относятся. Если регламентов нет, то исполнитель самостоятельно выбирает публикацию системы в закрытом или открытом контуре. Данная информация поможет не нарушить правила компании, определить возможные интеграции.

5. Утвердить документы. которые должны быть предоставлены по окончании разработки системы.

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

6. Привлечение целевых сотрудников.

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

7. Планирование сроков и бюджета.

Если требования меняются, но не корректируются сроки и бюджет, то это может привести к ухудшению качества проекта.

Как аналитик может взаимодействовать с подрядчиком во время проведения пресейла?

Рассмотрим два способа:

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

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

Методология управления проектами

На этапе пресейла необходимо учитывать методологию управления проектами.

Рассмотрим водопадную и гибкую методологию:

Водопадная модель (Waterfall)

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

Гибкая методология (Agile)

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

Как можно достичь эффективного взаимодействие с подрядчиком:

1. Регулярные встречи и обсуждения

• Проведение регулярных встреч поможет аналитику точнее изучить БП Заказчика и составить спецификацию на работы по проекту.
• Аналитику важно узнать как можно больше деталей, для закрытия потребностей Заказчика.

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

• Заказчик уверен в том, что разработанная система будет соответствовать обозначенным границам проекта;
• Исполнитель уверен в том, что в процессе разработки проекта новые требования не нарушают границ проекта и будут выполнены в рамках последующих этапов разработки системы.

2. Прозрачность и открытость

• Обеспечьте прозрачность в коммуникации и доступ к необходимой информации, предварительно обезличив чувствительные данные. Подпишите NDA с подрядчиком если того требует политика информационной безопасности компании.
• Будьте открыты к обсуждению и внесению изменений в Ваши бизнес-процессы.

Дополнительные шаги для повышения точности оценки: 

Прототипы страниц и модели бизнес-процессов

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

Создание простых моделей бизнес-процессов AS-IS и TO-BE дает подрядчику четкое представление о том, как устроены бизнес-процессы на текущий момент и как они должны измениться в конечном итоге. При формировании модели можно использовать нотацию UML или BPMN.

Формирование бизнес-требований и пользовательских требований

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

• За Х месяцев увеличить рыночную долю в регионе с У% до V%;
• Сократить использование электроэнергии и сэкономить Y рублей в год.

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

• Рассчитать показатели прибыльности по отгруженным заказам за несколько периодов: месяц, квартал, год.;
• Внедрить процесс согласования договора с клиентом в зависимости от условий договора, опираясь на политику контрактования Заказчика.

Предоставление максимального объема информации

Требования к документации для существующей системы. Если проект предполагает модернизацию уже существующей системы, то важно предоставить подрядчику максимально полную документацию. Это может быть ранее составленное техническое задание, инструкции, Программа и Методика Испытаний (ПМИ), документация API и другие документы.

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

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