Особенности национального CRM, или Как систематизировать взаимоотношения с клиентами на производстве

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

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

Очевидно, что каждая компания — это уникальный бизнес-организм и имеет ряд своих особенностей, которые необходимо учитывать. Плюс к этому есть и отраслевые нюансы. Так, ТОО «Maker (Мэйкер)» работает в горнодобывающей области и имеет широкий профиль деятельности — от производства насосов до сборки горно-шахтного оборудования и самоходной техники, — что накладывает определенную специфику на процесс реализации CRM-решений.

ТОО «Maker (Мэйкер)», г. Караганда
В 1941 году была организована Ремонтно-проектная база треста «Карагандашахтострой»,
на базе которого и был создан завод. В 2000 году завод вошел в состав холдинга «Казахмыс»
Количество сотрудников — 795 человек
В запросе и обработке КП участвует 17 подразделений

В результате проб и ошибок был выработан следующий чек-лист внедрения CRM:

— Создать рабочую группу (но не более 12-15 человек) из профильных специалистов (не всегда это начальник или руководитель отдела). Практика и опыт показывает, что такие команды наиболее эффективны, да и «Закон парадокса и кооперации» никто не отменял.

— Определить контрольные точки проекта (показатели успеха, сроки, план мероприятий).

— Определить стратегию. Идти по пути:

1. Обсуждение и совместная разработка. В данном случае речь идет больше об описании существующего бизнес-процесса (БП) со всеми заинтересованными службами, при этом соблюдается принцип «как есть».
2. Руководитель проекта самостоятельно определяет как будет работать бизнес, затем должен внедрить разработанный БП в компанию и ждать результата. При этом повышаются такие риски, как: правильность определения БП, необходимого для бизнеса; кадровый резерв (в случае ухода из команды руководителя повышается риск провала проекта); неготовность сотрудников компании перестраиваться под новые условия БП.
3. Смешанная стратегия, при которой соблюдается принцип «как есть» и используются инструменты по оптимизации БП руководителем проекта.

Нами была выбрана смешанная стратегия как наиболее оптимальное решение.

— Определить CRM-систему для реализации проекта. Было рассмотрено и протестировано три предложения:

1. AmoCRM
   Удобная и простая система. Быстро развертывается, но простота накладывает определенный отпечаток на функциональность системы: в нашем случае не было возможности построения и применения переменных, констант; нет коробочкой версии (только облако). Узкая специализация системы (оптимально — для отделов продаж).
   Сложность внедрения — легкая.
   Сложность освоения пользователями — легкая.
2. Terrasoft
   Одна из наиболее оптимальных систем для автоматизации БП. Система изначально разработана по стандарту BPM. Есть как облако, так и коробочная версия.
   Сложность внедрения — средняя.
   Сложность освоения пользователями — средняя.
3. Bitrix24
   Корпоративный портал включает в себя функционал чат-мессенджера, видеозвонки, визуальный редактор программирования. Возможность ведения задач и проектов, облачное хранение данных БитриксДиск, календари, структура компании.
   Сложность внедрения — средняя.
   Сложность освоения пользователями — средняя.

Принимая решение о внедрении CRM, мы выбрали Корпоративный портал Bitrix24, так как он показался нам более гибким. Широкий функционал этой системы позволяет объединить компанию в единое целое. Существует возможность совместной работы с документами, обсуждения проектов и задач, планирования графиков, контроль исполнения и многое другое. Это решение выбора CRM субъективно и индивидуально, и может варьироваться в зависимости от потребностей бизнеса/компании. Самое главное — тестируйте, пробуйте, подключайте интеграторов: зачастую они готовы оказать содействие и сделать первоначальные настройки самостоятельно или вместе с вами. Кроме того, у большинства CRM есть бесплатный пробный период.

— Определить формат описания бизнес-процесса. Мы остановились на функциональной блок-схеме (ФБС) (BPMN 2.0), так как данная методология наиболее оптимальна как для бизнеса, так и для программистов.

— Разделение ролей в группе было осуществлено следующим образом. Руководитель проекта — отвечает за сбор и организацию совещаний, результат проекта, сроки. Архитектор бизнес-процессов (по сути, правая рука руководителя проекта) — отвечает за корректное построение БП, а также выступает в качестве front-офиса для программистов, — т. е. является связующим звеном между разработчиками и бизнесом, — кем, собственно и был я. Специалисты по направлениям — участвуют в совещаниях, обозначают свой функционал и роль в БП. Программисты-разработчики отвечали за код и правильное выполнение поставленных front-офисом задач.

— Наберитесь сил и терпения, ибо вам никто не будет рад (ну почти никто, кроме заинтересованных в конечном результате лиц). Какому сотруднику будет приятно, что вы начинаете разбираться в его повседневных рутинных процессах, а в будущем еще и будете контролировать их. Возможны срывы, диверсии и саботаж: «мы так всегда работали, и лучше уже не будет».

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

Процесс совещаний опишу максимально коротко, акцентировав внимание на том, как лучше НЕ делать:

1. Собирать всегда и всех участников БП. При таком совещании теряется контроль, отсутствует корректное взаимодействие. К примеру, при запланированном обсуждении блока взаимодействий исполнительного директора и производственного отдела нет необходимости вызывать отдел контроля качества.
   В отдельных случаях, конечно, имеет смысл собрать всех — обычно это требуется в начале проекта для объяснения всем участникам целей и задач проекта, и в определенные контрольные точки проекта, чтобы проверить корректное взаимодействие отделов при написании БП.
2. Визуализация БП после совещания. Корректнее и эффективнее на момент проведения совещания выводить обсуждаемую ФБС на проектор и вносить правки в случае необходимости. При таком подходе участники БП визуально принимают и понимают каждый свою зону ответственности, также исключены неточности при построении ФБС БП постфактум.
3. Излишне бюрократизировать процедуру. На выходе у нас было всего три документа: а) ФБС, согласованная всеми участниками БП и утвержденная заказчиком (директором); б) регламент внесения изменений в ФБС; в) приложения в виде документов, входящих/исходящих между отделами при отработке БП. Возможно, имеет смысл разработки и написания дополнительных документов, но так как все разработки велись своими силами внутри компании, то нам этого было достаточно.

Сам процесс программирования в Битрикс24 представлен в виде визуального редактора программирования с определенным функционалом. Задача программистов была правильно понять и реализовать потребность бизнеса, отраженной в ФБС. На что стоит обратить внимание:

1. При автоматизации БП в облачной версии Битрикс24 возможны сбои в работе системы по причине автоматического обновления и может понадобиться актуализировать уже написанный БП.
2. Слабо развитая техническая поддержка в Битрикс24. Обращения отправляются от службы к службе, на что тратится немало времени.
3. Не автоматизировать все и сразу. Делать работу блоками. Тестировать и сдавать в опытную эксплуатацию разработанный блок архитектору и участникам БП.

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

В итоге внедрения нам удалось получить:

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

P. S. Главное — начать и не терять энтузиазма!