Разработка системы для учета заявок на ремонт и обслуживание
для сети аптек «Лаки Фарма»
«Лаки Фарма» — федеральная сеть аптек с 300+ точками по всей России.
В сети такого масштаба проблемные ситуации возникают постоянно: в одной аптеке ломается оборудование, в другой требуется срочный ремонт, и от правильности приоритета зависит стабильность работы сети и планирование затрат.
Чтобы управлять инфраструктурой на местах и выстроить систему при обработке заявок, важно быстро отделять критичные инциденты от некритичных, собирать обязательные детали по заявке и фиксировать ответственность и сроки на каждом этапе.
Проблемы в текущем процессе
До начала проекта процесс работы с заявками на ремонт и обслуживание сильно нагружал операционного управляющего сети: требовалось разбирать заявки в свободной форме из общих чатов в мессенджерах
Операционный управляющий без фиксированных форм и единых критериев анализировал каждую заявку, запрашивал дополнительную информацию в переписке и субъективно приоритезировал заявки.
При этом аптеки не всегда корректно оценивали критичность проблемы и необходимость привлечения мастера.
Задачи проекта и ожидания Заказчика
Чтобы решить проблему Заказчика, мы предложили автоматизировать процесс работы с заявками на ремонт и обслуживание для всей сети аптек.
В задачи проекта вошли:
Централизация процессов сбора и фиксации заявок
Формализация процесса обработки и распределения работ
Снижение субъективности в оценке критичности инцидентов
Обеспечение контроля сроков и качества выполнения услуг
Создание основы для масшта-бирования общего процесса
Реализованное решение
Разработали систему управления сервисными заявками для сети аптек «Лаки Фарма».
Ход проекта
Discovery-фаза
Провели серию интервью. Работу над проектом начали с серии рабочих обсуждений с Заказчиком. На этом этапе было важно понять, как устроена работа с сервисными заявками, а также какие функции и ожидания компания закладывает в будущую систему.
Описали жизненный цикл заявки. Чтобы убрать неопределённость в работе с обращениями и снизить зависимость от неформальных договоренностей, зафиксировали единый жизненный цикл сервисной заявки и роли участников.

Каждая заявка отличается по типу работ, классу оборудования и приоритету — эти параметры используются для обработки, назначения исполнителей и контроля сроков.
Исследовали референсы. Референсы helpdesk- и service-desk-решений использовали как инструмент проверки гипотез. Изучали структуру списков, набора колонок, принципов отображения статусов и таймеров SLA.

Результатом Discovery-фазы стал набор требований и пользовательских сценариев, которые использовались при проектировании интерфейсов и архитектуры системы приёма и обработки заявок на ремонт.
Целевой процесс обработки сервисной заявки
Создание заявки
Создание заявки — точка входа в процесс сервисного обслуживания.


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

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

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

Работа над заявкой
После подтверждения и назначения исполнителя заявка переходит в следующий статус.
Система отправляет уведомление, и у техника запускается SLA по реакции и решению.

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

Если выполнить работу сразу невозможно (нет запчастей, нужен перенос, выявлены дополнительные ограничения), техник фиксирует проблему в системе.
Завершение заявки возможно только через отчёт: техник указывает выполненные работы, итоговую причину, стоимость и использованные запчасти. После этого она передаётся на приёмку.
Закрытие заявки
Закрытие работает по механизму двойного подтверждения: сначала техником, затем управляющим аптеки, который проверяет результат и закрывает заявку.


Во втором сценарии управляющий возвращает заявку в работу обратно, указав причину возврата:

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

В системе для обработки и управления заявками предусмотрены показатели реакции и решения — они рассчитываются автоматически и отображаются прямо в списке. Это позволяет сразу видеть, какие заявки укладываются в SLA, а какие — приближаются к нарушению.
Карточка заявки
Карточка заявки — это основное рабочее пространство для работы с конкретным инцидентом. Доступ к карточке и набор действий зависят от роли пользователя в системе.

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

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

Второй сценарий работы с отчётами — формирование актов выполненных работ. Акты формируются на основе уже закрытых и принятых заявок.
Руководитель может собрать данные за нужный период, по конкретному юридическому лицу или исполнителю и выгрузить их в удобном формате для дальнейшего использования в системе для управления заявками на обслуживание.
Справочники
Справочники в системе — это область работы администратора
Frontend-архитектура
Систему для учёта и управления заявками на ремонт реализовали как веб-приложение с поддержкой PWA, чтобы сотрудники аптек и техники могли работать с заявками с компьютера и мобильных устройств без отдельного приложения.
Фронтенд построен на React с модульной архитектурой. Состояние и бизнес-логику вынесли в отдельный слой, чтобы гибко управлять статусами заявок, ролями пользователей и сложными сценариями обработки.

Что изменилось после внедрения
Внедрение системы управления заявками на ремонт и обслуживание оборудования позволило:
- централизовать работу с сервисными заявками по всей сети аптек
- сократить время реакции на инциденты
- снизить долю ручного управления
Процесс стал управляемым и масштабируемым. При этом руководство получило инструмент для контроля качества обслуживания и планирования затрат.
Обсудить идею или проект
Шаг 1 из 6
Выберите тип вашего проекта






