Сервис из двух модулей: Бриф и Портал 73. Вместе они дают управлять командой выездных сотрудников так, чтобы техническое обслуживание и ремонт были прозрачны с обеих сторон — и для тех, кто планирует и принимает работу, и для тех, кто едет на объект и делает её руками.
Мы не писали это под заказ. Оба модуля выросли внутри нашей сервисной компании и каждый день используются инженерами, руководителями регионов и бухгалтерией. Поэтому в них учтены мелочи, до которых обычно доходят на втором году работы: дубли записей, отклонённые акты, поездки на личном авто, суточные, чеки.
Заявка заказчика заводится сделкой: объект, окно работ, назначенные инженеры и документы по ней. Сроки плановых работ видны заранее, а не вспоминаются по факту: портал сам показывает, где окно работ кончилось, а акта нет, и где заявка стоит без следующего шага. У каждого объекта своя карточка с историей всех прошлых работ.
Приехав, инженер видит в телефоне не только сегодняшнюю заявку, но и всё, что на этом объекте делали раньше: кто, когда, что менял, какие были замечания. Рядом — документация по оборудованию с поиском по модели и бренду и ИИ-помощник, которому можно показать фото шильдика. Человек приезжает с контекстом, а не с одной строчкой в мессенджере.
Мы работаем рядом с 1С, а не вместо неё: остатки запчастей и резервы берутся из неё без переноса данных, реестры компенсаций уходят обратно выгрузкой. CRM не обязательна — сделки и календарь живут в Брифе; если у вас уже есть Битрикс24, подключается синхронизация. Уведомления дублируются в Telegram. Каждая компания получает отдельную инсталляцию со своей базой, роли строгие, все действия журналируются. Своих серверов держать не нужно.
Логика везде одна: объект, осмотр по чек-листу, работа, акт, проверка, оплата. Меняются чек-листы, бланки актов и словарь. Отрасли с примерами мы разобрали на странице Портала 73 — там же видно, как это выглядит у полевых сотрудников разных специальностей.
Коротко: у каждой единицы оборудования появляется карточка с историей, регламентом и наработкой. Заявки на ремонт и плановые работы идут через одну очередь, а не через личный телефон главного механика.
Работы делим на этапы и фиксируем результат каждого. Платите за принятый этап, а не за обещания.
Смотрим парк оборудования, действующие регламенты и то, как сейчас доходят заявки. 5–7 рабочих дней.
Реестр оборудования, формы заявок, графики ППР, наряды, права и отчёты. 10–15 рабочих дней.
Учим механиков и мастеров, запускаем на одном участке или одной группе оборудования. 3–5 дней.
Поддержка, донастройка регламентов по факту эксплуатации, подключение склада запчастей.
Пакет — это сразу два модуля: Бриф для координатора и руководителя, Портал 73 для инженера на объекте. Цена в карточке — всё внедрение целиком: оба портала, платформа, интеграции и скидка за объём уже внутри. Классический контур по своему оборудованию — реестр, графики ППР, наряды — считается отдельно после аудита: он слишком зависит от размера парка, чтобы называть цену вслепую.
Минимум, с которого начинают: координатор видит загрузку людей и ставит выезды, инженер работает с телефона и сдаёт акт прямо на объекте.
Основная работа направления: акт проходит согласование и превращается в счёт, осмотры идут по чек-листам, у инженера под рукой документация.
Всё, что работает у нас самих: история по каждому объекту, ИИ-помощник по оборудованию, аттестация инженеров, QR-метки на объектах.
Поддержка и подписка на обновления — 2 % от стоимости внедрения в месяц, но не меньше 15 000 ₽. Обновления выходят регулярно и приходят сами: в эту же сумму входят помощь вашим сотрудникам и небольшие доработки. Вместе с облаком и внешними сервисами ежемесячный платёж выходит от 28 000 ₽ на «Старте» до 38 000 ₽ на «Полном» при тридцати работающих в системе. Цены указаны «от»: они посчитаны на едином портале, где обе службы работают в одном окне. Если нужны отдельные порталы — как устроено у нас самих, — платформа считается иначе. «Старт» разворачивается от трёх недель; «Оптимум» и «Полный» запускаются дольше — в них больше сервисов и больше настройки под ваши процессы. Расчёт ориентировочный: точную сумму называем после разбора процессов, он бесплатный.
С переписи. На аудите мы вместе с вашим механиком составляем реестр: что за единица, где стоит, какой узел критичен, что ломалось за последние год-два. Это самая трудоёмкая часть проекта, и делать её всё равно придётся — без реестра автоматизировать нечего. Обычно начинают не со всего парка, а с оборудования, которое чаще всего останавливает производство.
Не обязательно. В большинстве проектов показания счётчиков вводит оператор или мастер в конце смены — этого достаточно, чтобы планировать обслуживание по моточасам, а не только по календарю. Автоматический съём данных имеет смысл там, где оборудование уже отдаёт их наружу; если нет, разговор про датчики — это отдельный проект со своим бюджетом.
И не нужно. Заявка подаётся с телефона: фото, короткое описание, участок. Наряд механик закрывает там же — отмечает время, что сделал и какие запчасти поставил. Интерфейс делаем в несколько крупных кнопок, потому что работать с ним будут в перчатках и не всегда при хорошем свете.
Тем, что в центре стоит оборудование, а не задача. Заявка привязана к конкретной единице, поэтому накапливается история: этот узел меняли трижды за год, а на этом станке простои растут второй квартал подряд. В обычном таск-трекере такие вопросы задать нечему — там задачи закрываются и исчезают.
Через складской учёт. Под плановый ремонт запчасти резервируются заранее, при закрытии наряда списываются на конкретную единицу оборудования. Так появляется честная стоимость содержания: не общая сумма по цеху, а расход по станку. Если складского учёта в системе нет, ТОиР всё равно работает, просто запчасти учитываются отдельно.
Журнал отвечает на вопрос «что чинили», и этого хватает, пока единиц немного и помнит их один человек. Он не отвечает на три других вопроса: когда подойдёт срок следующего обслуживания, сколько стоило содержание конкретной единицы за год и почему этот узел ломается четвёртый раз. Система ТОиР — это тот же журнал, только он сам напоминает о сроках, сам считает стоимость и не исчезает вместе с ноутбуком механика. Переносить старый журнал целиком обычно не нужно: берём последний год и дальше пишем уже в системе.
1С:ТОиР — сильный продукт для предприятия, которое уже живёт в 1С и держит штат специалистов по ней. Мы заходим с другой стороны: не меняем вашу учётную систему, а добавляем к ней то, чего в ней нет, — работу с телефона прямо на объекте и живой контур выездной службы. Если у вас уже внедрён 1С:ТОиР и он закрывает задачу, честный ответ — ничего не менять. Разговор имеет смысл, когда механики и инженеры в систему не заходят, а всё живёт в мессенджерах и Excel.
Да, и это как раз наш основной опыт. Логика та же: объект, регламент, осмотр по чек-листу, ремонт, история работ. Добавляется планирование выездов и расчёты с инженером: переработки, дорога, командировки. Такой контур у нас работает на собственной сервисной компании по судовому оборудованию, поэтому в нём учтены мелочи, до которых обычно доходят только на втором году эксплуатации: дубли записей, отклонённые акты, поездки на личном авто, чеки.
Заявки и история появляются сразу. Снижение аварийных простоев видно не раньше, чем через два-три месяца планового обслуживания, и только если графики действительно соблюдаются. Система показывает, что регламент нарушен, но выполняет работы всё равно человек — обещать сокращение простоев одной настройкой было бы нечестно.
Запчасти под ремонт: резерв заранее, списание по наряду, честная стоимость содержания по единице.
Подробнее →Приём, отпуска и заявки сотрудников: инженеров в выездной службе много, а кадровик один.
Подробнее →Курсы и аттестация инженеров: допуск к оборудованию подтверждается, а не держится на памяти мастера.
Подробнее →