Amrita Service — discovery операционного долга
Discovery и проектирование для бизнеса по ремонту оборудования, работающего «между системами». Мы выявили три источника операционного долга и спроектировали единую операционную модель — частично реализовано, затем приостановлено из-за бюджета клиента.
Эта система была спроектирована и частично реализована — полное внедрение приостановлено из-за бюджета клиента. Показываем её как discovery-кейс, чтобы продемонстрировать наш подход.
- Индустрия
- Ремонт оборудования и выездной сервис
- Формат
- Discovery и проектирование системы
- Статус
- Частично реализовано (на паузе)
- Наша роль
- Анализ процессов и архитектура
- Существующие инструменты
- CRM · учётная система · Excel
Сценарий 1 — Быстрая услуга, которая должна обгонять систему
Для коротких выездных заказов скорость — часть услуги. Мастер записывал заказ на бумаге, потому что оформить цифрой было медленнее; затем тот же заказ заново создавали в учётной системе. Бумага выигрывала скоростью, а не современностью.
Сценарий 2 — Основной бизнес и ручная передача
Для многодневного ремонта гидроцилиндров приёмка шла на бумаге, фото — через мессенджер, а бухгалтер позже переносил всё в систему. В сезон десятки заказов в день превращали ручную передачу в главное узкое место — повторный ввод, ошибки, устаревшие данные.
Сценарий 3 — Когда Excel становится системой управления производством
Каждое утро команда вручную собирала операционную картину из выгрузок — срочность, обещанные сроки, текущий этап, потребность в запчастях, загрузка специалистов — и планировала день. Excel был не проблемой, а симптомом отсутствия единой операционной картины.
Единое операционное пространство
Один операционный слой, связанный с существующей учётной системой, — а не ещё один силос.
Ultra-fast приёмка для быстрых услуг
Создать заказ на месте, найти запчасти по артикулу/названию/ключевому слову, собрать типовые комплекты, автоматически рассчитать стоимость и передать в учёт без повторного ввода.
Цифровая приёмка для основного ремонта
Единая карточка заказа с данными клиента, замерами, фото, комментариями специалистов, историей работ и текущим статусом.
Дашборды операционной видимости
Заказы по этапам, просрочки, срочные, ожидающие запчастей и загрузка по подразделениям — формируются автоматически.
У компании уже было ПО, которое должно было поддерживать ключевые процессы: CRM для работы с клиентами, учётная система для заказов и бухгалтерии, накопленные данные о продажах. При этом Excel оставался основной точкой входа для ежедневных решений — что делать сегодня, какие заказы приоритетны, куда направить ресурсы команды.
Часть процессов всё ещё происходила между системами — на бумажных листиках, в мессенджерах и в памяти сотрудников. Этот разрыв — между тем, как бизнес работает на самом деле, и тем, как работают его системы — и есть операционный долг. Не отсутствие технологий, а стремительно растущий разрыв между реальным workflow и инструментами.
Бумага продолжала выигрывать у софта не потому, что сотрудники сопротивлялись, а потому что в ряде сценариев она была быстрее. Excel выживал, потому что был единственным местом, где видно бизнес целиком.
- Время оформления быстрого заказа — из минут ручной координации в один непрерывный цифровой процесс
- Меньше ручных передач между подразделениями
- Меньше зависимости от отдельных сотрудников
- Выше прозрачность статуса заказа на всём жизненном цикле ремонта
- Меньше времени на ежедневное планирование
- Единая операционная картина без ручного сбора данных
- Ниже стоимость координации по мере роста бизнеса
Информация вводится один раз
Данные вводятся однократно и используются всеми — без повторного переноса между людьми и системами.
Разные сценарии — разные workflow
Быстрая услуга и многодневный ремонт требуют разных интерфейсов и логики.
Видимость как результат работы системы
Операционная видимость должна возникать автоматически, а не собираться вручную каждое утро.
Отражать реальную работу
Система должна отражать, как реально работает бизнес, и снижать трение, а не заставлять подстраиваться под ограничения софта.
Проблема была не в отсутствии данных. Проблема была в том, что информация двигалась между людьми быстрее, чем через инструменты.
Если управлять операциями сложнее, чем должно быть, — мы с радостью посмотрим.
Обычно мы начинаем с того, что находим одну область, которую можно быстро улучшить.
Обсудить ситуацию