Ремонт обладнання та виїзний сервісDiscovery-кейс

Amrita Service — discovery операційного боргу

Discovery та проєктування для бізнесу з ремонту обладнання, що працює «між системами». Ми виявили три джерела операційного боргу та спроєктували єдину операційну модель — частково реалізовано, потім призупинено через бюджет клієнта.

Цю систему було спроєктовано та частково реалізовано — повне впровадження призупинено через бюджет клієнта. Показуємо її як discovery-кейс, щоб продемонструвати наш підхід.

Індустрія
Ремонт обладнання та виїзний сервіс
Формат
Discovery та проєктування системи
Статус
Частково реалізовано (на паузі)
Наша роль
Аналіз процесів та архітектура
Наявні інструменти
CRM · облікова система · Excel
Операційний виклик

Сценарій 1 — Швидка послуга, яка має обганяти систему

Для коротких виїзних замовлень швидкість — частина послуги. Майстер записував замовлення на папері, бо оформити цифрою було повільніше; потім те саме замовлення заново створювали в обліковій системі. Папір вигравав швидкістю, а не сучасністю.

Сценарій 2 — Основний бізнес і ручна передача

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

Сценарій 3 — Коли Excel стає системою управління виробництвом

Щоранку команда вручну збирала операційну картину з вивантажень — терміновість, обіцяні строки, поточний етап, потребу в запчастинах, завантаження спеціалістів — і планувала день. Excel був не проблемою, а симптомом відсутності єдиної операційної картини.

Що ми будуємо

Єдиний операційний простір

Один операційний шар, пов'язаний із наявною обліковою системою, — а не ще один силос.

Ultra-fast приймання для швидких послуг

Створити замовлення на місці, знайти запчастини за артикулом/назвою/ключовим словом, зібрати типові комплекти, автоматично розрахувати вартість і передати в облік без повторного введення.

Цифрове приймання для основного ремонту

Єдина картка замовлення з даними клієнта, замірами, фото, коментарями спеціалістів, історією робіт і поточним статусом.

Дашборди операційної видимості

Замовлення за етапами, прострочення, термінові, що очікують запчастин, і завантаження по підрозділах — формуються автоматично.

Компанія вже мала ПЗ, яке мало підтримувати ключові процеси: CRM для роботи з клієнтами, облікову систему для замовлень і бухгалтерії, накопичені дані про продажі. Проте Excel залишався основною точкою входу для щоденних рішень — що робити сьогодні, які замовлення пріоритетні, куди спрямувати ресурси команди.

Частина процесів усе ще відбувалася між системами — на паперових листочках, у месенджерах і в пам'яті співробітників. Цей розрив — між тим, як бізнес працює насправді, і тим, як працюють його системи — і є операційний борг. Не відсутність технологій, а стрімко зростаючий розрив між реальним workflow та інструментами.

Папір продовжував вигравати у софту не тому, що співробітники опиралися, а тому що в низці сценаріїв він був швидшим. Excel виживав, бо був єдиним місцем, де видно бізнес цілком.

Очікуваний ефект
  • Час оформлення швидкого замовлення — з хвилин ручної координації в один безперервний цифровий процес
  • Менше ручних передач між підрозділами
  • Менше залежності від окремих співробітників
  • Вища прозорість статусу замовлення на всьому життєвому циклі ремонту
  • Менше часу на щоденне планування
  • Єдина операційна картина без ручного збору даних
  • Нижча вартість координації в міру зростання бізнесу
Як ми працюємо
1

Інформація вводиться один раз

Дані вводяться одноразово й використовуються всіма — без повторного перенесення між людьми та системами.

2

Різні сценарії — різні workflow

Швидка послуга та багатоденний ремонт потребують різних інтерфейсів і логіки.

3

Видимість як результат роботи системи

Операційна видимість має виникати автоматично, а не збиратися вручну щоранку.

4

Відображати реальну роботу

Система має відображати, як реально працює бізнес, і знижувати тертя, а не змушувати підлаштовуватися під обмеження софту.

Проблема була не у відсутності даних. Проблема була в тому, що інформація рухалася між людьми швидше, ніж через інструменти.
Інсайт discovery

Якщо керувати операціями складніше, ніж мало б бути, — ми радо подивимося.

Зазвичай ми починаємо з того, що знаходимо одну область, яку можна швидко покращити.

Обговорити ситуацію