Чем крупнее компания, тем сложнее контролировать ее работу. Если нет единого инструмента работы с заказами, даже самые ответственные менеджеры могут забыть перезвонить клиенту, не вовремя рассчитать стоимость заказа или попросту его потерять.
Из этого кейса вы узнаете, как внедрение CRM на крупном заводе помогло повысить уровень продаж и продуктивность менеджеров. Мы расскажем и об инструментах, использованных нами для разработки системы, а также о сложностях, с которыми столкнулись.
Предыстория
К нам обратился директор по производству завода “Экипаж”. Это крупнейшее производство металлопластиковых окон, дверей, роллетов и алюминиевых конструкций в Восточной Украине. Завод производит 1000 единиц продукции в сутки, имеет более 3000 точек продаж.
Завод работал по старинке: дилеры звонили менеджерам, оставляли заказ. Информация о заказах отправлялась по почте. Чтобы узнать статус заказа, дилеры опять-таки звонили менеджерам. С рекламациями работали в формате крика из кабинета в кабинет: "Юля, что там по рекламации №1234"?
Заказов много, телефон звонит не умолкая. При таком количестве звонков легко было что-то упустить или забыть, поэтому менеджеры находились в постоянном напряжении.
Задача
Оптимизировать бизнес-процессы завода и снизить нагрузку на менеджеров по работе с дилерами. Создать эффективный инструмент для работы менеджеров с заказами.
Решение
После длительных переговоров и погружения в задачу мы приняли решение разработать CRM. Это прикладное программное обеспечение, которое строит взаимодействие с клиентами по единому стандарту: фиксирует заявки и распределяет их менеджерам, ведет финансовый учет, наглядно показывает работу каждого менеджера и анализирует продажи.
Сложности
Завод “Экипаж” работает одновременно с двумя учетными системами, поэтому при разработке CRM возникает дополнительная сложность - необходимо обеспечить синхронизацию с обеими системами.
Ресурсы и сроки
Программный комплекс разрабатывался с нуля. Поэтому изначально определили срок разработки - 4-6 месяцев. Мы разобрались с задачей и на старте определили бюджет. Но в процессе работы совместно с заказчиком было принято решение расширить функционал системы, сделать ее более гибкой с учетом будущих потребностей. Для этого требуютя дополнительные ресурсы и поэтому срок и бюджет был увеличен.
Кого мы привлекли к работе над проектом
Мы сформировали команду и приступили к работе. Над проектом работали:
Project manager
UX specialist
UI specialist
Art-director
Back-end developer
Front-end developer
DevOps specialist
Q/A engineer
CTO
Эффективную CRM можно разработать, только полностью погрузившись в бизнес клиента. Для этого необходимо тесно сотрудничать с командой заказчика. Мы нашли общий язык с командой. Начальник производства, начальники отделов, технические специалисты - в проект были вовлечены все.
Результат работы
В результате внедрения CRM нам удалось ускорить работу завода: менеджеры перестали “висеть” на телефоне, у них появилось больше времени на работу с дилерами. Дилерам стало проще отслеживать статус заказа и общаться с менеджерами. Все процессы стали прозрачными.
Схема взаимодействия участников процесса
В системе взаимодействуют несколько типов пользователей: дилеры, рекламаторщики и контент-менеджер. Каждый участник системы видит и работает с той информацией, которая касается именно его. Дилеры видят информацию по своим заказам, финансовый отдел – взаиморасчеты и оплаты с клиентами, ответственные за рекламации – только рекламации. Дилеру нет необходимости делать десяток звонков. Всю информацию о заказе он отслеживает через систему.
Сам процесс выглядит так:
В магазине делают заказ в конструкторской программе.
Заказ поступает в программу работы с заказами завода.
Затем конструктор завода должен убедиться, что все передано без ошибок, и одобрить заказ. После этого со статусом “Принято” заказ синхронизируется с нашей системой и становится доступен дилерам.
Далее уже дилер сам следит за статусами выполнения заказа. Когда заказ отгружен, он видит, каким рейсом прибудет груз, дату доставки и данные водителя.
Дилеру доступны все взаиморасчеты по финансам, остаток на начало, компенсации, оплаты за доставку.
Если с заказом что-то не так, дилер подает рекламацию и ее рассматривает специалист.
Теперь все процессы на производстве упорядочены, работа идет быстрее
Для каждого участника процесса разработан свой функционал
Интервью и скетчи
CRM должна отражать существующий бизнес-процесс, но в то же время ускорять и упрощать его. Для этого надо досконально понимать, как все устроено и как участники процесса взаимодействуют между собой. Чтобы разобраться в процессе, мы провели серию интервью с топ-менеджерами, а также с сотрудниками отделов завода - производственного, IT-департамента, бухгалтерии. Отдельно общались с дилерами.
Досконально вникаем в каждую мелочь. Только так получится создать полезную программу.
Основательно разобравшись, как все устроено, строим процесс на верхнем уровне.
Прописываем сценарии взаимодействия.
Сделали скетчи. Проходим по основным сценариям. Созваниваемся с клиентом и обсуждаем.
Создание прототипа
Приступаем к созданию интерактивного прототипа. Прототип - это демоверсия будущей программы. Его можно сравнить с тест-драйвом автомобиля: заказчик может все посмотреть, покрутить и понять, как работает система. Если какие-то нюансы упущены, на этом этапе сразу становится понятно, что именно нужно доработать.
В прототипе все как в будущей CRM. Сразу понятно, что и как будет работать.
Презентуем клиенту и доделываем мелочи: изменяем формулировки, меняем приоритетность информации, прописываем порядок уведомлений. Проводим диалоги с дилерами.
Разработка концепции дизайна
Дизайн CRM-системы должен ассоциироваться с фирменным стилем завода “Экипаж” и со стилем сайта. Дилер, попадая в админпанель приложения, должен понимать, что он зашел по адресу.
Когда создаешь концепцию, важно помнить о полезном действии: какую задачу будет решать дизайн. При этом учитывать существующий прототип, а также то, как дизайн будет выглядеть на разных экранах. А так как дизайн мы реализуем в коде, на каждом этапе проекта дизайнер взаимодействует с технической командой.
От завода мы получили брендбук с фирменным стилем - логотип, плакаты, график работы. Используя эти материалы, готовим мудборд — своеобразное превью будущего дизайна. Мудборд помогает понять, каким будет дух и настроение проекта. Для мудборда использовали фотографии завода, фасадов магазинов продаж, страницы текущего сайта, билборды. Все это собрали на одной доске, изучили, как клиенты воспринимают фирменные цвета завода.
Мудборд - превью будущего дизайна
Для заказчика мы подготовили две концепции. Обе соответствуют заявленным требованиям.
Концепция №1
Использованы цвета, соотносящиеся с цветами логотипа компании. Основным цветом стал плотный темно-коричневый.
В качестве контрастного выбрали оранжевый - он должен быть максимально контрастирующим, выгодно выделяться на фоне основного.
Разделы и элементы, которые выбраны, и кнопки, которые можно нажать, выделены акцентным цветом. Это поможет пользователю быстрее разобраться с возможностями интерфейса.
Для кликабельных ссылок, таких как заказ, дата доставки, мы использовали шрифт синего цвета. Это привычно для пользователя веб-приложений.
Для каждого статуса подобрали свой цвет, чтобы пользователь сразу видел, в каких статусах находятся заказы и рекламации. Все эти цвета сочетаются с основными цветами интерфейса и гармонично вписываются в общую концепцию.
Концепция № 2
Как и в первой концепции, за основу взяли цвета, которые используются в логотипе. Подготовили мудборд (логотип сайта, фотографии завода и другие элементы фирменного стиля).
Основной цвет - темно синий.
Контрастный - оранжевый, более яркий, чем в предыдущей концепции. На фоне основного он выделяется максимально выгодно.
Для шрифта ссылок, на которые можно нажать, использован привычный пользователю акцентный синий цвет.
Для каждого статуса подобрали свой цвет.
Строки таблицы чередуем разным фоном, чтобы пользователь не путался в заказах.
Обе концепции дизайна удобны для пользователя: ссылки выделены привычным синим цветом, заказы отделены друг от друга.
Кроме работы с заказами и финансами, есть «служебные страницы»: информация от завода, настройки административной панели, настройка уведомлений, справочник. Их мы тоже тщательно проработали, чтобы сделать удобными и интуитивно понятными.
Служебные страницы мы сделали простыми и интуитивно понятными
Презентация концепции заказчику
С самого начала заказчик был вовлечен в проект. Для оценки концепций клиент дополнительно привлек отдел маркетинга завода.
В целом концепции заказчику понравились, но предложено внести три правки:
1. Статусы заказов и рекламаций сделать одной длины.
Наше решение: мы оставили свой вариант и сделали вариант с новыми статусами. Оба варианта показали клиенту и аргументировали, почему наш вариант лучше решает задачу. Пользователь легче воспринимает большой объем информации, если дополнительно использовать:
цвета - для каждого статуса был подобран свой цвет, что позволяет легко и быстро воспринимать информацию;
названия статуса;
формы - длины статуса. Этот параметр помогает пользователю воспринимать информацию еще быстрее.
2. На боковом меню выделить акцентным ярким цветом тот раздел, в котором находится пользователь.
Наше решение: мы подобрали такой цвет бокового меню, на котором акцентный цвет смотрелся выигрышно и решал задачу.
3. Фон на экране авторизации заменить на фото “Дом с цветными окнами”.
Наше решение: данное фото достаточно гармонично вписалось в концепцию дизайна проекта. Мы нашли эту фотографию на фотостоках, купили ее и использовали как фон на экране авторизации.
После того, как заказчик утвердил концепт, переходим к дизайну.
Работа над дизайном программы
Рисуем все страницы, показываем состояние каждого элемента. Получилось 380 страниц.
Мы прорисовали состояние каждого элемента, чтобы учесть все сценарии пользователя с интерфейсом
Адаптация дизайна
Для дилера важен доступ к системе со смартфона или планшета. Ведь они работают «в поле»: приходится обращаться к системе в квартире клиента, придорожном кафе или в машине.
Дополнительно разрабатывать и поддерживать мобильное приложение трудоемко. К тому же это лишние расходы. Поэтому мы решили делать адаптивный дизайн. К CRM будет доступ с компьютеров, телефонов и планшетов.
Мы проработали все состояния на разных разрешениях
Уменьшение размера экрана – ювелирный процесс. Каждый экран прорабатывается отдельно: ранжируется информация по степени важности, часто используемые функции поднимаются вверх, некоторые функции скрываются. Каждый проект разрабатывается индивидуально - нельзя сделать один шаблон для всех админпанелей, так как у каждого проекта своя задача и своя цель.
В админпанели одновременно работают тысячи дилеров. При этом информации на страницах много и нужно упорядочить ее так, чтобы пользователям было удобно работать и чтобы они могли быстро и интуитивно находить нужное.
В первую очередь мы думали об удобстве пользователя. При изменении размеров экрана данные не просто сжимаются, а адаптируются таким образом, чтобы важная информация оставалась на виду.
Подача информации
CRM – это рабочий инструмент для дилеров и основной канал связи с заводом. В системе дилер видит всю информацию по своим заказам: на каком этапе производства находится каждый из них и когда какой заказ будет отгружен. При частичном или полном выполнении заказа, отгрузке и доставке дилер сразу получает информацию о смене статуса. Через CRM дилер может формировать финансовые отчеты, видеть фотографии и схемы конструкций, отслеживать даты доставки и общаться с менеджером завода.
Для дилера важны точность и достоверность данных. Так он сможет планировать свою работу. Поэтому вся информация синхронизируется и данные регулярно обновляются.
По каждому статусу заказа дилер получает полную информацию: когда заказ принят, когда запущен в производство, даты изготовления, отгрузки и доставки, рейс и контактные данные водителя.
Конструкция
Каждая конструкция отображается отдельным блоком, где указана полная информация о заказе.
Чтобы дилеру было удобно, все названия, описания и значения в системе отображаются полностью, без сокращений.
В разделе “Финансы” дилер видит полную информацию по заказу и оплате. Процесс доставки также полностью визуализирован.
Дилер точно знает движение средств по заказам.
Нагрузка на завод
После утверждения дизайна готовимся к программированию. Начинаем с high-level архитектуры. Прогнозируем, какая нагрузка будет на систему, и подбираем технические решения.
У завода нет права на ошибку, он не может подвести клиента, поэтому система должна работать безотказно.
Мы прогнозируем, что бизнес клиента будет расти. А значит, инструменты должны иметь возможность быстро меняться и масштабироваться. Поэтому особое внимание мы уделили архитектуре проекта: серверную архитектуру разбили на отдельные сервисы. Такая архитектура упрощает поддержку системы. Даже если возвращаешься к проекту через несколько месяцев, в нем можно быстро сориентироваться. К тому же проект легко тестировать, отлаживать и внедрять новые функциональные блоки.
Серверную архитектуру мы разбили на отдельные сервисы, а код в сервисах сделали модульным, со слабыми зависимостями между слоями. Это позволит максимально быстро внедрять новые функциональные блоки.
В процессе работы мы убедились, что это решение было правильным. Когда компания “Экипаж” открыла свой второй завод в Хмельницком, мы без проблем и без дополнительных вложений подключили к системе и его.
Решения фиксируем в техническом задании. По документу работает команда программистов.
Программирование: особенности
Для передачи данных между элементами системы создаем закрытое API. С помощью методов API принимаются данные и записываются в базы данных.
Обмен данными и актуализация данных в базах данных - это фоновый процесс. Поэтому потенциально узким местом будет передача данных с серверов завода и их фоновая запись.
Для поиска решения и синхронизации двух команд мы поехали на завод для презентации и согласования нашего решения.
При создании ТЗ учитываем все эти нюансы.
Так выглядит ТЗ на реализацию программы. В ТЗ прописано все, вплоть до мелочей
Наша главная задача - создать систему с высокой отказоустойчивостью. Источники нагрузки на систему - две учетные системы и пользователи.
Чтобы повысить отказоустойчивость, мы использовали современный стек технологий. На проекте использовался сервер очередей Gearman, который обеспечивает:
Параллельное выполнение процессов. Это позволяет быстро обновлять данные.
Регулирование доступа к внешним ресурсам.
Кроме того, Gearman решает задачи параллельной обработки данных и позволяет обойти ограничения на лимит памяти одного PHP-скрипта.
Мы понимали, что 2-4 раза в секунду происходят изменения по статусу изготовления с линии, есть еще и другие фоновые задачи, которые порождают нагрузку на сервер. В холостом ходу на систему уже была нагрузка примерно 2500-3500 запросов в минуту. Это не так много, если брать общее количество запросов на сервер, но это фоновые запросы, а значит, при таком количестве высока вероятность ошибки, которая даст сбой. Поэтому наши действия были направлены на снижение вероятности фонового сбоя системы.
Для этого мы использовали сервер очереди. Он принимал все запросы при синхронизации и, не создавая большой нагрузки на сервер, с выделенной ему производительностью уверенно разбирал огромное количество обновлений по заказам.
Мы подключили очень подробную систему логирования, которая в случае любой ошибки блокировала обновления информации и одновременно в фоне отправляла нам письмо на почту о том, что есть системный сбой.
Мы очень плотно работали с разработчиками со стороны завода. Совместно приняли удобный формат передачи объектов данных и согласовали ограничения, чтобы избежать неожиданной отправки данных невалидного формата и непреднамеренных DDoS атак при синхронизации.
Дополнительно мы решили сделать доступность системы не ниже 99,98%, что означает время простоя сервера в неделю 4,01 минуты, в месяц 16,9 минуты и в год 3,38 часа. Такие же показатели у серверов AWS. Важно понимать: нет систем, доступных на 100%. Любая система, даже если в ней нет проблем, будет простаивать во время перезагрузки серверов, выката новых версий или проведения профилактических работ. Нам удалось достигнуть этого показателя. Сейчас система работает в “боевом” режиме уже 4 месяца, а показатель на момент написания статьи 99,99 -это всего 4,32 минуты простоя в месяц.
Для увеличения скорости отдачи информации использовали Redis, эта система за счет работы из оперативной памяти значительно ускоряет работу над проектом.
Чтобы найти оптимальные решения, проводим мозговые штурмы
Синхронизация
CRM синхронизируется с несколькими программами завода: производственной, где происходит процесс работы с производством, и бухгалтерской с финансовой информацией. Со стороны завода работала команда, которая отвечала за синхронизацию. Это важный этап. От того, насколько точно передаются данные, зависит корректность работы системы. Поэтому было составлено техническое задание на синхронизацию, которое описывало логику процесса.
Например, на странице заказа данные собираются из нескольких баз данных.
Самым сложным в этом проекте для нас была работа с системами учета. Они строились и развивались не один год, и менять мы там ничего не могли. Нам пришлось балансировать, чтобы не нарушить то, что есть. При этом и система, которую мы создавали, не должна была быть зависимой от систем учета. Таким образом, нам пришлось добавлять в бизнес-логику серверного приложения лишние процессы. Они денормализировали полученные объекты данных и записывали их в ту структуру, которую мы могли использовать максимально эффективно. Много времени потратили на то, чтобы дополнительные процессы не стали для нас “якорем”.
На этом примере видно, из каких баз берутся данные и как они попадают на страницу
Тестирование и отладка
Разработка велась по методологии SCRUM. Тестирование на проекте делится на две части: тестирование в процессе программирования (в спринтах) и финальная отладка системы.
Финальная отладка системы проходила довольно долго - мы хотели убедиться, что в “боевом” режиме система будет работать безотказно. Например, во время тестирования наши тест-кейсы покрывали не только новую реализованную систему, но и выявляли, как системы учета будут себя вести в случае отказа новой системы. Будет ли ошибка принята и синхронизация продолжится с небольшими потерями данных или же вовсе остановится.
Нагрузочное тестирование системы проводилось 5 раз на старте, и каждый раз мы добавляли в производительности +30%. Считаем, что тот результат, который мы получили на выходе, стоил всех приложенных усилий. Ведь мы достигли самого важного - созданный инструмент решал проблемы и потребности бизнеса и при этом не порождал новых.
Процесс тестирования системы
В процессе разработки участвовал инженер по тестированию, который проверял каждую выполненную функцию. До начала тестирования был составлен план тестирования и чек-листы для проверки методов.
План тестирования и чек-листы для проверки методов
На этапе финальной отладки проверяли каждый элемент системы: API для синхронизации, API для web-панели, административную панель, синхронизацию между CRM и базами завода. Провели нагрузочное тестирование системы под граничные значения.
После финальной отладки проект передан клиенту для работы. Всего разработка системы вместе с тестированием заняла 11 месяцев.
CRM системой заказчик доволен. Уже видны первые результаты: значительно ускорилась работа завода, появился потенциал для роста производства при том же количестве сотрудников. Дилеры тоже довольны: работа ведется по единому стандарту, заказы не теряются, работа с рекламациями идет быстро.
Итак, система запущена и появилась обратная связь с пользователями. Теперь этап совершенствования.
