Своя ERP вместо Excel-документа: ускорили обработку заявок в 10 раз и настроили логистику

1. Вводная задача от заказчика, проблематика, цели

СРОК ВЫПОЛНЕНИЯ: сентябрь 2017 – февраль 2018

КОМАНДА ПРОЕКТА: Team Lead, 3 fullstack-разработчика

ТЕХНОЛОГИИ: PHP, Yii2, PostgreSQL, HTML, CSS, JavaScript, Bootstrap, jQuery, Docker, Docker Compose, Git

Компания 20+ лет занимается монтажными работами и подключением Интернета, ТВ и телефонии в Москве и МО. Она успешно конкурирует на рынке провайдинга и расширяет внутрирегиональную позицию поставки услуг. Для реализации стратегии постепенно оцифровывает бизнес-процессы и переносит их на веб-платформы.

Изначально провайдер пришел к нам с доработкой личного кабинета клиента на сайте. После настройки функционала ЛК мы узнали, что у компании есть более глобальные проблемы, которые связаны с отсутствием автоматизации в обработке заявок.

БОЛЬ КЛИЕНТА

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

На занесение одного входящего запроса, поиск «‎окошка», исполнителя и логистику дальнейших действий тратилось ~30 минут менеджера. Более того, чтобы получить актуальную информацию о расписании выездных сотрудников, оператор постоянно запрашивал обновленный Excel-файл.

Здесь даже излишне рассуждать о недостатках и неудобстве работы в неподходящем для бизнеса ПО, поэтому мы сразу взялись за дело.

ЦЕЛЬ ПРОЕКТА

Ускорить обработку входящих заказов и дальнейших работ по заявкам с помощью ERP-системы.

ОСНОВНЫЕ ЗАДАЧИ

• Пошаговая форма регистрации заявок в системе и распределение по бригадам.
• Функционал для управления и изменения заявок.
• Автоматизированное распределение услуг и автоматическое определение маршрута.
• Централизованное хранение информации о сотрудниках, адресах, УК и диспетчерских.
• API для последующих интеграций с другими сервисами провайдера.

2. Описание реализации кейса и творческого пути по поиску оптимального решения

Из-за того что единственный референс будущей ERP-системы – Excel-таблица, мы упорно брифовали провайдера, чтобы углубиться в рабочие процессы и детали. Выявили, что самым сложным станет алгоритм распределения заказов по бригадам и назначения маршрутов. Но именно он закроет целый пул потребностей компании.

Что же мы сделали?

I. Шаблон для оформления заявки

Наш приоритет в работе с ERP-системой – удобство оператора. Чтобы специалист не упустил ни одного важного пункта и сразу мог предоставить клиенту выбор даты и времени, мы создали шаблон приема заявок.

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

II. Раздел «Управление»

Заявки можно редактировать: переносить на другое время, исправлять данные, добавлять и убирать работы. После правок система напоминает об оповещении клиента и фиксирует корректировки в отдельной таблице изменений.

III. Текущие заявки с выстроенным маршрутом

Все заказы услуг отображаются в разделе «Заявки». На главной странице находятся записи об актуальных работах, которые надо выполнить бригаде. Помимо данных о клиенте и хронологического интервала, здесь же расположена Google-карта с навигацией движения из офиса до адреса заказчика. Открывается она при выборе бригады-подрядчика. В ней учитывается даже то, что для определенных видов работ требуется связаться с УК и заехать за ключом от щитка.

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

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

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

IV. Реляционная база данных

Занесение и хранение информации в ERP – важная часть для алгоритма распределения заявок. Именно БД сообщает системе о видах и особенностях работ, расписании сотрудников, адресах и контакты ЖК, диспетчерских, УК. Данные можно создавать, редактировать и удалять. При правках будут меняться график, услуги и маршруты.

V. API

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

VI. Тестирование

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

3. Результаты сотрудничества

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

Уже 6 лет московский провайдер использует разработанную нами ERP, встречаясь с Excel-файлами только при экспорте данных из нее.