Любой сквозной бизнес-процесс компании в нормальной ИТ-системе «живет» лучше, чем в регламенте со схемами и четким текстом. Для многих этот тезис очевиден, но не для всех. Рассмотрим на примере процесса продаж новостроек в девелоперской компании: 1) «жизнь» процесса продаж в регламенте продаж, и 2) «жизнь» процесса продаж в CRM-системе (MS Dynamics CRM). С какой точки зрения процесс «живет» лучше, если под вольным сленгом «живет» будем понимать исполнение процесса, эффективность его контроля, управление процессом.
Что эффективнее для управления продажами, — хороший регламент процесса продаж или хорошая CRM-система? Поделюсь из своей практики примерами. До 2015 года в одной_неважно_в_какой_компании была «самописная» CRM-система или, как ее называли, «ЦРМ». Но, ее наличие не решало в полной мере проблем взаимодействия между подразделениями внутри Департамента продаж, — проблемы сохранялись между менеджерами продаж и оформителями/регистраторами договоров продажи недвижимости, между менеджерами продаж и ипотечными менеджерами. Четкого и внятного регламента также не было, были разрозненные фрагментарные инструкции по отдельным вопросам на тему продаж. Почему так, — система была, а проблемы оставались? Потому что, строго говоря, Системы не было, — была «самописная» система, было программирование под запрос руководителя продаж, и выстраивался некий «индивидуальный спецзаказ» на тему продаж, не от общего видения как все должно быть, а от частностей, от отдельный операционных удобств текущего понимания продаж. К сожалению, не все представители продаж умеют системно, и внятно излагать свои мысли …) Вот как раз в этих ситуациях на помощь руководителю компании приходят системные аналитики и бизнес-аналитики…
В 2014 году мы (бизнес-аналитики управления организационного развития) разработали регламент продаж новостроек, — расписали «пошагово» процесс продаж новостроек, прорисовали графическую схему процесса на 2 уровнях. Статья «Развитие системы управления компании через НМД (нормативно-методическую документацию)» была посвящена необходимым и достаточным, на авторский взгляд, требованиям, чтобы описать процесс, как раз на примере процесса продаж новостроек. Процесс в компании вполне достаточно описать графически, через табличное представление, через документооборот процесса, и роли по процессу. Работа была полезной, но рамки пользы ограничивались ровно тем периодом времени, пока велась разработка регламента с участием руководителей отделов и сотрудников департамента продаж, управления маркетинга и рекламы и других подразделений. Даже тестирование сотрудников на знание регламента продаж провели, и затем все тихонько «умерло», руководитель сменился , — регламент продаж забыт…
Отмечу еще одну интересную особенность, — при прорисовке процесса продаж в регламенте у одного опытного и сильного аналитика была уверенность, что, по крупному, процесс продаж — один и тот же для разных схем продаж недвижимости (уступка, долевое участие/ДДУ, ДКП и т.п.), — ведь состав шагов процесса в разных схемах проведения сделки один и тот же, а излишняя детализация различий сделок только усложняет восприятие графической схемы процесса продаж. Позже, при внедрении новой CRM, с этой иллюзией мы расстались. И возможно, упрощения процесса, которые допускаются при описании процесса в регламенте, создают барьер, который мешает ИТ-специалистам воспринимать регламент процесса как исходные требования для настройки CRM-системы.
Спустя 2 месяца пристальных наблюдений за конфликтом в отношениях между Управлением продаж и ИТ Управлением, к проекту внедрения CRM-системы подключилось Управление организационного и стратегического развития. Также пришлось расстаться с иллюзией того, что хороший, детальный регламент продаж будет понятным описанием исходных требований от управления продаж для ИТ-специалистов, как настроить процесс продаж в новой CRM системе.
Новой CRM системой было выбрано решение, как уже было упомянуто, MS Dynamics CRM, доминирующее на рынке девелопмента Москвы и московской области (на 2 месте после MS Excel 😉 ).
Отмечу, что были описаны 2 взаимосвязанных процесса, — процесс вывода объекта на реализацию, и процесс продаж новостроек. Когда бизнес-аналитики подкллючились к проекту внедрения CRM, одной из задач была следующая задача, — понять внутреннюю архитектуру новой системы, и внутреннюю методологию, уже «зашитую» в систему. И это понимание определило содержание плана внедрения CRM с 1 стороны, и раскрыло путь к сближению методологии продаж из регламента с методологией продаж в CRM.
Рис.1. Общая логика продаж в CRM: отражены, какие подразделения Департамента продаж с какими объектами CRM работают и как передается информация
На рис.1 представлено описание общей логики продаж с выделением сущностей (на языке системы, основных объектов), через которые циркулирует ключевая информация процесса продаж в системе.
Понимание архитектуры системы, и наложение ее элементов на уже описанные процессы вывода объектов на реализацию (синие потоки на рисунке 1), процессы продаж (красные потоки на рисунке 1), позволило сформулировать требования к настройке системы уже на языке самой системы. Так как управленческий язык регламента продаж и технический язык CRM-системы, — это разные языки, и с этим надо было также разобраться, «подружить» их между собой.
Пример графического представления процесса приема и обработки обращений, выглядит так, — см. рис.2.
Графическое представление этого же подпроцесса на «языке системы» MS Dynamics CRM выглядит так, — условный пример см. на рис. 3.
Приведу общее описание процесса «прием и обработка обращений» (рис.2) для понимания контекста: сотрудник call-центра принимает и квалифицирует звонок, заполняет карточку звонка, по итогам квалификации звонка переводит звонок на менеджера по продажам, если тема звонка «продажа новостроек» или на другого сотрудника, если тема звонка другая. Менеджер по продажам выясняет потребности, заполняет карточку клиента (потенциального клиента/lead), организует показ объекта, организует встречу, проводит встречи, самостоятельно проводит первичную оценку кредитоспособности клиента, далее, после квалификации общей заявки, заключает Договор бронирования. Для нашего примера, достаточно этого описания.
Рис. 2. Процесс 2 уровня, — Прием и обработка обращений от клиентов. Переход от звонка в call-center к заявке менеджера продаж.
Рис.3. Сценарии перехода от карточки Звонок к карточе Заявка (Общая заявка клиента/lead) в CRM
Ключевые события процесса продаж из регламента (рис.2) преобразуются в плановые задачи сотрудника при работе с заявкой (рис.3), которые сотрудник уже не может проигнорировать, так как поля обязательны к заполнению, нужные оповещения о заполнении/не заполнении полей карточки плановой задачи рассылаются по списку кому следует, и механизм работает. Даже с учетом попыток обмануть систему, что тоже возможно, но при желании, легко и быстро обнаруживается. Сложность всех сценариев процесса «спрятана» в настройках системы, для пользователя видим только свой удобный интерфейс на своем рабочем месте в процессе.
После проработки процесса в системе можно приступать к задаче формирования отчетности для контроля качества процесса, т.к. необходимые аналитические признаки уже вложены в процесс.
Итоги:
Дуэт «руководитель продаж — программист» — «узкий междусобойчик», опасный дуэт. Продажники не всегда способны внятно и четко сформулировать идеологию настройки системы. ИТ-шники не понимают или по своему понимают язык бизнеса. Всех примирить может грамотный методолог из аналитического подразделения по стратегическому или организационному развитию бизнеса. Внедрение любой нормальной ИТ-системы — это всегда проект организационного развития бизнеса под стратегические цели бизнеса в целом, с решением большого числа методологических вопросов.
Мы рассмотрели пример ключевого бизнес-процесса с двух позиций: 1) с точки зрения разработки регламента процесса, 2) с точки зрения автоматизации процесса в ИТ-системе. ИТ-система не отменяет регламент. Иначе, доработка и развитие системы отрывается от регламента/методологии процесса, через какое-то время никто не вспомнит, какие изменения внесены были и зачем ? Методические настройки системы необходимо контролировать через регламент/методологию процесса. А сам регламент проникает в систему в формате примечаний к полям, оповещений, если сотрудник выполнил ошибочное действие. Таким образом, регламент не живет отдельной жизнью в капсуле, не устаревает, быстрее обновляется, приходят новые сотрудники — через систему начнут быстрее понимать, какие правила процесса продаж надо соблюдать.
Опасно доверять контроль настроек системы только тому подразделению которое является основным ее пользователем, — начнут обходить систему или манипулировать данными. Методологический контроль настроек системы должен быть вынесен из операционного подразделения, использующего систему.
Сквозной бизнес-процесс компании в нормальной ИТ-системе «живет» лучше, чем в регламенте со схемами и четким текстом, потому что в ИТ-систему уже «вкручен» механизм контроля его исполнения, необходимая аналитика, а к документарным бизнес-процессам надо дополнительно прикручивать организационные процедуры их контроля и развития.
P.S. Уточнения по тексту:
*»Нормальная ИТ-система» — вольное наименование полнофункционального, обкатанного, тиражного ИТ-решения, аккумулирующего в себе многолетнюю практику многих компаний, регулярно обновляемое вендором решения.
