Учёт оборудования и плановое ТО в Битрикс24: от паспорта техники до истории работ

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

Дмитрий Максимов28.10.20266 мин чтения

Керамическое колесо в круговом контрольном маршруте и инструмент в нише: история оборудования и плановое обслуживание.

Содержание

В торговой сети две одинаковые машины работают на разных складах. Одну недавно осматривали, другая ждёт обслуживания, но в заявках обе названы просто «погрузчик». Поиск по комментариям показывает выполненные работы, однако не позволяет понять состояние каждой единицы. Новое напоминание в чат не исправит отсутствие устойчивой связи с оборудованием.

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

Сделайте оборудование отдельным объектом #

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

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

Объект	Что в нём хранится	С чем связывается
Единица оборудования	Паспорт, состояние, место и владелец	Работы, показания и документы
Программа обслуживания	Вид операции и условия наступления	Применимые единицы и модели
Задание на работу	Исполнитель, срок и состав действий	Конкретная техника и программа
Результат работы	Выполненные операции и замечания	Задание и основание следующего цикла

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

Различайте календарный срок и наработку #

Одно обслуживание назначают по дате, другое — по часам работы или пробегу. Для правила «по первому наступившему условию» нужно наблюдать обе величины. Само поле с датой не сможет проверить счётчик, который никто не обновляет.

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

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

Сохраните основание следующего задания #

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

example-policy.jsonJSON

{
  "asset_id": "ASSET-DEMO-19",
  "maintenance_rule_id": "RULE-DEMO-A",
  "last_completed_work_id": "WORK-DEMO-72",
  "next_due_date": "2026-11-12",
  "meter_unit": "operating_hours",
  "last_meter_value": 1240,
  "asset_status": "in_service"
}

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

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

Разделите ремонт, осмотр и подтверждение результата #

Сообщение о неисправности может создать обращение, но не обязано автоматически закрывать плановое ТО. При ремонте могли устранить одну проблему, не выполнив остальные операции программы. И наоборот, осмотр может завершиться новым дефектом, требующим отдельной работы.

Исполнитель фиксирует выполненные действия, показания и замечания, прикладывает предусмотренные документы. Уполномоченный сотрудник принимает результат или возвращает его на уточнение. Только после принятия соответствующей работы изменяют основание следующего цикла. Простая отметка «задача выполнена» не должна скрывать незаполненный результат.

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

Учитывайте перемещения и вывод из эксплуатации #

После переноса на другой склад меняется место и, возможно, обслуживающая группа. Историю не нужно переносить в новую карточку вручную. Запланированные задания должны оставаться видны новой ответственной стороне, а уведомления — перестать уходить прежнему владельцу.

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

Как проверить систему до рабочего запуска #

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

Наступил календарный срок, показания ещё не достигли порога.
Порог наработки достигнут раньше календарной даты.
Показание пришло повторно или оказалось меньше предыдущего.
Работа закрыта исполнителем, но результат ещё не принят.
Оборудование переместили, пока задание открыто.
Единицу вывели из эксплуатации и затем вернули.
Внеплановый ремонт не покрывает обязательные операции программы.

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

Достаточно ли регулярной задачи «проверить оборудование»? #

Для простого напоминания — иногда да. Но без реестра единиц, результата осмотра и связи с программой такая задача не создаёт полноценную историю обслуживания. Выбор зависит от того, какие решения должен принимать ответственный по данным системы.

Когда вместо Битрикс24 нужна специализированная система ТОиР? #

Когда нужны сложные структуры оборудования, большой объём телеметрии, подробное планирование ресурсов или специальные функции технического учёта. Битрикс24 может остаться местом обращения и взаимодействия сотрудников, а технические данные — в профильной системе. Границу определяют по процессу и интеграциям.

Поможем связать реестр техники с исполнением работ #

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