После этапа бурного роста Whoosh перестал быть техностартапом и стал IT-компанией с множеством процессов и парком в более чем 200 тысяч самокатов и велосипедов. В каждом городе нашего присутствия работает минимум один сервисный центр, в крупных городах – сразу несколько. Все устройства проходят регулярное техобслуживание и ремонт во время сезона. В том числе с заменой запчастей.
В 2024 году мы в Whoosh потратили на запчасти сотни миллионов рублей. На тот момент мы уже понимали, что здесь нам есть что оптимизировать. В работе с учётом компонентов не хватало детализации и прозрачности, это приводило к срочным или ненужным закупкам. Чтобы снизить издержки, нужно было двигаться в сторону индивидуального учёта запчастей. Однако сначала у нас не было технологической платформы для улучшения этих процессов.
В прошлом году мы сделали и уже успешно обкатали решение этой проблемы — подружили программу 1С с нашим внутренним приложением WCMA для операционной команды. Это позволило нам полностью автоматизировать и сделать прозрачным финансирование обслуживания самокатов и велосипедов.
Теперь нам доступна адресная аналитика по пробегу и сервисным работам любого самоката. Мы точно знаем, какие запчасти ломаются и как часто нужен ремонт или замена компонентов для каждого устройства — износ и пробег легко прогнозировать. В компании сотни тысяч СИМ, поэтому масштаб оптимизации значителен.
Меня зовут Никита Симакин, я продакт-менеджер департамента по развитию продукта в Whoosh. Расскажу о том, как мы делали это решение. Уточню, что моя статья посвящена скорее менеджерской внутрянке и пользе для бизнеса. Технических деталей много не будет (но если интересно то, что под капотом, пишите в комментариях, призову наших разработчиков). Начнём.
Откуда колёса торчат
В своей внутренней работе по обслуживанию парка самокатов и велосипедов мы используем два приложения. WCMA (Whoosh Control Maintenance App) предназначено для управления флотом и задачами, которые выполняет сервисная команда и второе - «1С: Управление Торговлей», для учета и контроля запасных частей.
Разработка WCMA началась еще до официального запуска сервиса, около шести лет назад. В нем, например, отражаются все статусы самокатов (готов к аренде, в аренде, разряжен, неисправен и так далее), местоположение и прочие данные, нужные для перезаряда, ребаланса (перемещения самоката по парковкам в городе) или ремонта. Приложение используют полевые команды. Опираясь на данные, которые видят в нём, они расставляют самокаты в городе, следят за их зарядом и многое другое. Также в приложении работают и сотрудники сервисных центров, где ремонтируют самокаты.
В «1С: Управление Торговлей» мы фиксируем процессы, связанные с заказом комплектующих — от закупки до доставки на склад. Когда запчасти, заказанные через 1С, приходят в сервисный центр, в дело вступает WCMA: сотрудники видят, какие комплектующие доступны для списывания, перемещения, ремонта и так далее. Для команды оба приложения действуют “в связке”. Но технически они никак не были связаны ранее. Это порой приводило к сложностям.
Например, в WCMA отображается количество оставшихся на складе СЦ комплектующих. Однако в 1С информация попадала с опозданием. Данные об остатках сотрудники сервисного центра вводили туда вручную на основании накопленной в ходе сервисных работ документации. Это могло произойти в конце рабочего дня, либо раз в неделю, а порой и реже.
Типичная ситуация, которая могла происходить ранее: WCMA сообщает, что на конкретном складе имеется 100 колёс. Они есть в наличии сегодня, завтра, послезавтра... И внезапно — весь запас списывается одним днём. Так как сотрудники сервисных центров знали, что отражение количества запчастей может быть неточным, то им было сложно планировать обеспечение ремонтных работ.
В результате приходилось срочно докупать комплектующие, чтобы самокаты не простаивали в ремонте. А экстренно — равно дороже. При срочных закупках мы расходовали на запчасти больше, чем могли бы тратить в условиях прозрачных плановых процессов. Вдобавок бывали ситуации, когда компания не могла точно прогнозировать расход запчастей. А нам было необходимо понимать, что сервисный центр А в среднем меняет два колеса в день, а сервис B — пять.
Рассчитывать расход болтов и мелких расходников, конечно, не очень интересно с финансовой точки зрения. Обычно такие запчасти закупаются сразу крупным оптом. А вот строгое планирование поставок дорогих компонентов — IoT-модулей, электронных компонентов мотор-колёс и пр. — сильно сокращает издержки, связанные со спешкой.
Изучаем рынок, находим похожие успешные кейсы, понимаем – это направление можно оптимизировать. Начинаем делать решение.
Ready, set, go!
Мы начали заниматься этой задачей в начале 2024 года. На разработку потратили около четырёх месяцев. Задачу делали небольшой командой — один бэкендер и один фронтендер, большая часть работы была на бэкенде. Для сопряжения двух приложений в систему Whoosh были интегрированы мастер-артикулы из 1С для каждого вида работ по замене деталей.
Этапы обслуживания самоката, согласно новому устройству:
создание резерва на каждую деталь с указанием сотрудника и устройства;
исполнитель выполняет ремонт или замену детали;
переводит устройство в статус «Готово к проверке»;
после проверки контроля качества ремонта и успешного тестирования запчасть списывается с остатков склада 1С.
Что ещё важно — сделали адресное списание запчастей. Как это устроено? Механик собирается взять в работу запчасть для ремонта, делает заявку, а мы создаем в 1С резерв. Сразу бронируем нужную запчасть за конкретным сотрудником. Кто первый взял деталь в работу в системе, тот её и получит. А у второго механика эта запчасть уйдет в статус отсутствующих. Это позволяет избежать ситуации, когда осталась одна деталь, а за ней пришли два человека.
В ближайшее время планируем запустить поставку комплектующих с центрального склада на склады сервисных центров вовсе без участия человека – полностью в автоматическом режиме, внутри компании назвали это автозаказом. Что для этого нужно? Оперативная информация о своевременном списании запчастей с одной стороны и данные об их дефиците – с другой. Обе задачи решаются интеграцией софта. Автозаказ при этом будет работать, используя статистику потребления запчастей за определенный период и текущий дефицит запчастей.
Такой подход тесно связан с «теорией ограничений» (Theory of Constraints, TOC), ключевой концепцией в современной логистике. Теория ограничений утверждает, что в любой сложной системе – будь то завод или цепочка поставок – производительность определяется самым слабым звеном, то есть ограничением. В нашем случае ограничением может стать недостаточная скорость передачи информации между складами, некорректная оценка дефицита или несвоевременное списание деталей.
Для эффективной работы автозаказа крайне важно выявить и устранить эти «узкие места». Например, если информация о расходе или дефиците поступает с задержкой, система не сможет вовремя инициировать поставку нужных деталей: это снизит готовность сервисных центров и повысит риски простоя. Поэтому интегрированные цифровые инструменты не просто автоматизируют рутину – они позволяют минимизировать влияние основных ограничений в логистической системе, делать процесс поставок более предсказуемым и гибким. Следовательно, грамотное внедрение автозаказа не только уменьшает долю ручного труда, но и позволяет всей цепочке работать ближе к своему максимальному потенциалу, что напрямую отвечает принципам теории ограничений.
Начинаем пилотировать
В июне прошлого года мы запустили пилот в Твери. Осознанно выбрали небольшой сервисный центр и дали коллегам возможность работать через эту интеграцию.
Почти всё прошло довольно гладко. Разве что при обкатке софта вылезла проблема с учётом устройств и обеспечением их запчастями при перемещении между городами. Объясню: когда Whoosh присутствовал лишь в нескольких городах, мы вручную контролировали перемещение самокатов между городами и это порождало ошибки: несвоевременные отметки о статусе или локации самоката и так далее. Для корректного создания автозаказа нам было важно контролировать перемещение СИМ по городам внутри системы, чтобы правильно распределять запчасти по городским сервисным центрам. Сейчас процесс перемещения автоматизирован — и с осени 2024 года наша система успешно работает во всех регионах присутствия самокатов и велосипедов Whoosh.
Аналитика «ходимости»
Модернизация операционки оказалась полезной не только для сокращения издержек. Как было раньше? Сломался самокат — заменили запчасть. Но мы не знали, какому конкретно самокату оказана помощь. Видели по документам так: потребовался ремонт одному из устройств, запчасть исчезла со склада.
Теперь у нас есть полный отчёт: модель самоката, пробег и так далее. Мы можем детально отслеживать историю каждого устройства и прогнозировать, как часто ломаются дорогие компоненты у определённых моделей.
У нас появился задел для аналитики по «ходимости» комплектующих. Но прежде чем приступать к такому анализу, надо чуть-чуть подрасти в операционке. Глобально это позволит точнее прогнозировать потребление запчастей.
Тут снова речь о минимизации потенциальных потерь. Этот путь прошли многие крупные компании, которые ремонтируют свои активы, и мы решили адаптировать под себя лучшие практики. В ремонтах есть несколько стратегий: либо техника ходит до отказа того или иного узла, а замена производится, исходя из фактического состояния компонента, либо проводится превентивная замена. Первая стратегия связана с финансовыми потерями. Поломка самоката в городе означает его дальнейший простой и недополучение выручки. А надо учитывать, что не про все поломки мы можем узнать удалённо — дистанционная диагностика есть, но мы не можем по фото или датчикам оценить достаточность подтяжки тормозов. Также у нас есть идеи по внедрению CV для анализа состояния самоката, но это сложный процесс, в который мы пока не готовы инвестировать. Так, аккумулируя данные о «ходимости» основных узлов, мы в дальнейшем сможем делать необходимые плановые замены, чтобы сократить простои.
Метрики интеграции разделились на два типа. Технические — быстродействие — и бизнесовые — корректность работы интеграции и процент использования автоматических и ручных списаний. Для старта решили использовать Grafana, а далее переносить отчётность в корпоративный BI-инструмент.
Мы отслеживали скорость создания резервов, выдачи запчастей, работы веб-хуков и разные другие данные. А бизнесово проверяли, что наши процессы корректно встроились в работу интеграции, и внедряли изменения, если требовалось. Например, что будет, если один из СИМ с резервами перевезут в другой сервисный центр в связи с ротацией флота.
Сейчас процент автоматических списаний по основным компонентам — около 60%, но мы знаем, что этот показатель можем улучшить. Хочется полностью автоматизировать списания. Что собираемся для этого делать — расскажу чуть дальше в выводах.
После нескольких итераций по оптимизации быстродействия работа интеграции стала практически незаметна для пользователя (скорость работы методов измеряется сотнями мс). Такого результата получилось достичь, используя асинхронное взаимодействие двух систем с помощью очередей и приоритизацией запросов. Запросы, которые блокируют бизнес-процесс, получают наивысший приоритет, неблокирующие запросы складываются вниз очереди.
Также мы предусмотрели работу нашей системы в режиме офлайн на случай недоступности 1С или во время высокой нагрузки. Наши сервисные центры, как правило, работают 24/7, поэтому вопрос доступности был одним из ключевых, недоступность 1С не должна была блокировать операционную деятельность.
Что дальше?
Планируем развивать решение. Например, в наших силах:
полностью уйти от ручных списаний в 2025 году, автоматизировав обработку запросов на повторную выдачу запчастей в случаях брака, поломки при ремонте или других ситуаций;
сделать процесс для компонентов, которые не подлежат списанию, а требуют особого учета;
продолжим улучшать быстродействие и доступность двух систем, чтобы сократить время простоя и ожидания формирования документов.
Спасибо за внимание! Буду признателен, если поделитесь мыслями или своим опытом решения похожих задач. Прошу в комментарии.