Аварийная ситуация: как управлять поломками в сети из 300 аптек

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

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

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

И вам нужно быстро понять, что действительно требует немедленного вмешательства, что может подождать, а что вообще не требует действий.

Именно в такой ситуации находилась «Лаки Фарма» — федеральная сеть аптек с 300+ точками по всей России.

В рамках текущей проблемы решались более глубокие проблемы в логике процесса:

• Управляющие аптек не могли объективно оценить срочность. Это перегружало приоритизацию на уровне всей сети и порождало конфликты: почему у соседней аптеки техник уже приехал, а у нас нет?

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

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

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

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

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

Например, если холодильник не держит температуру и не восстанавливает её после разгрузки — это заявка. Если дверь просто оставили открытой, сотрудник справится сам по регламенту. Звучит просто, но именно такая конкретика убирает субъективность из-за которой возникали споры и лишние выезды.

Только когда правила стали общими — появился смысл их автоматизировать.

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

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

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

В-третьих, операционный управляющий получил единую точку контроля над всей сетью — вместо десятков чатов один экран где видно всё и сразу.

Отдельно продумали финальный этап — закрытие заявки. Сделали двойное подтверждение: сначала техник фиксирует что работа выполнена, потом управляющий аптеки подтверждает что доволен результатом. Маленькая деталь, которая убирает главный источник конфликтов — споры о том была ли работа сделана нормально.

При проектировании интерфейса изучили существующие helpdesk-решения, чтобы понять, какие паттерны уже работают и не изобретать велосипед. 

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

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

Техники стали выезжать на реальные проблемы чаще, чем на «у нас что-то не так, приедьте разберитесь». Потому что до подачи заявки система задаёт правильные вопросы.

А главное — появилась общая память. Раньше история заявки жила в переписке нескольких чатов и голове одного человека. Теперь каждый инцидент, каждое решение, каждый исполнитель зафиксированы. Это основа для роста сети: можно открывать новые аптеки, не боясь, что процесс рассыплется.