Как не терять сроки и оборудование в аренде опалубки

Клиент: компания СФОРМА, поставщик строительной опалубки и сопутствующего оборудования в аренду, с подразделением в Калининграде. Сдаёт в аренду опалубку и сопутствующее оборудование строительным подрядчикам: заказчик получает комплект на объект на определённый срок, использует и возвращает, а компания должна точно знать, где сейчас находится каждая партия и когда её ждать обратно. При десятках объектов одновременно это не мелочь, а основа бизнеса.

Ситуация до

Учёт аренды вели в таблицах и частично в 1С, но общей картины не было. На практике это оборачивалось так.

• Оборудование "терялось" между объектами. Партия числится за одним объектом, а по факту уже неделю как на другом.
• Просрочки возврата обнаруживали по факту. Клиент должен был вернуть оборудование ещё неделю назад, а менеджер узнавал об этом случайно.
• Остатки склада не совпадали с реальностью. Часть оборудования числилась свободной, хотя была в пути или в ремонте.
• Подразделения вели учёт по-разному. Свести общую картину по всей компании можно было только вручную.

Задача

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

Подход

У аренды опалубки свой путь оборудования: заказ, отгрузка на объект, использование, возврат, склад, иногда ремонт. Прежде чем настраивать Битрикс24, нужно было разобраться, как этот путь на самом деле устроен в компании, а не как он описан в регламенте. Аудит показал, что перемещение оборудования между объектами нигде не фиксировалось как отдельный этап, оно просто подразумевалось.

Что сделано

Спроектированы смарт-процессы "Аренда", "Отгрузка", "Возврат", отдельные сущности "Оборудование" (единица или партия) и "Объекты" (стройплощадки, куда сдаётся техника). По той же логике в такие проекты обычно добавляется и "Ремонт" как отдельный смарт-процесс, если у клиента есть свой ремонтный участок.

Контроль сроков: у каждой аренды плановая дата возврата и фактическая, статус "в аренде", "должен вернуться", "просрочен", "возвращён". Робот заранее напоминает менеджеру и клиенту о приближающемся сроке, а при просрочке автоматически эскалирует задачу ответственному.

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

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

Экран руководителя "Требует моего внимания": просроченные возвраты, задержанные отгрузки, оборудование без движения дольше обычного, всё в одном месте вместо звонков по подразделениям.

Что стало неожиданностью

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

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

Как шло внедрение

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

Результат

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

Что дальше

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

Если у вас похожая ситуация

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

Похожий пример с фокусом на закупки и склад смотрите в кейсе "Как навести порядок в закупках, складе и сроках".

Статьи по теме

• Интеграции между сервисами: как понять, что бизнесу пора

Частые вопросы