Сначала проверяем готовую ТОиР на вашем цикле
График ППР живёт в Excel, заявки приходят в чат, а после ремонта мастер оставляет запись в журнале. Чтобы понять, обслужили ли конкретный насос, техническому директору приходится сводить эти следы вручную. Ручная сверка отнимает время; оставшуюся операцию легко потерять между планом и отчётом. При выборе системы полезно сразу проверить, как она связывает план, наряд и принятый результат с одним активом.
Разработка системы ТОиР на заказ имеет смысл, когда у вашего процесса есть конкретный шаг, который готовое решение и его настройка не покрывают. Мы предлагаем начать с одного класса оборудования: пройти плановое обслуживание и один внеплановый отказ, сравнить варианты и зафиксировать границы пилота. Ниже есть карта этой проверки, условия выбора и состав работ для оценки.
ТОиР означает техническое обслуживание и ремонт. ППР расшифровывается как «планово-предупредительные ремонты»: это заранее назначенные работы по утверждённым правилам. Под CMMS обычно понимают систему управления обслуживанием: активы, задания и историю работ. EAM охватывает более широкий жизненный цикл имущества, от приобретения до вывода из эксплуатации. IBM объясняет эту разницу через объём задач. Для вашего заказа важнее перечислить нужные действия и данные, чем выбрать аббревиатуру.
Демонстрационная иллюстрация подготовки обслуживания: оборудование, перечень операций и необходимые детали связаны с одним заданием.
План, заявка и факт сохраняют разные смыслы
Активом здесь называем конкретную единицу оборудования с устойчивым идентификатором. В его карточке нужны местоположение, ответственный, модель и ссылки на применимые регламенты. Название «насос в цехе» может оказаться недостаточным: после замены агрегата история прежней единицы должна оставаться различимой.
В предлагаемом пилоте связываем следующие шаги. Плановая работа получает основание из действующего регламента. Внеплановая начинается с зарегистрированного дефекта или отказа. Обе проходят подготовку, выполнение и приёмку; основание остаётся в истории.
- План. Определяем операции, срок или согласованное условие запуска, версию регламента и потребность в ресурсах.
- Заявка и наряд. Заявка описывает потребность в работе. Наряд задаёт согласованное задание исполнителю: актив, операции, ответственного и условия выполнения. В вашей системе эти документы могут называться иначе; смысл проверяем на реальном примере.
- Подготовка. Согласуем исполнителя, доступ к оборудованию и материалы. Если работа требует остановки, ответственный подтверждает доступное окно.
- Выполнение. Мастер отмечает фактические операции, обнаруженные дефекты и расход деталей. Для невыполненного указывает причину.
- Подтверждение. Ответственный за приёмку проверяет результат по согласованным правилам. Передача записи на сервер, приёмка работы и её отражение в учёте имеют отдельные состояния.
- История и следующий цикл. Сохраняем связь с активом, основанием, версией регламента и результатом. Проверяем, как назначается следующее обслуживание по правилам владельца оборудования.
Предлагаемый цикл пилота. В каждом шаге проверяем входные данные, ответственного и результат, который получит следующий сотрудник.
Отметка в календаре подтверждает плановую дату. Выполненное обслуживание подтверждаем сведениями об операциях и принятом результате по вашим правилам. Нормативы, периодичность и допустимые отклонения берём из утверждённых регламентов и применимой документации производителя.
Перенос и частичное выполнение требуют следующего шага
Допустим, мастер провёл осмотр насоса, но нужного уплотнения на складе нет. В системе должны остаться выполненный осмотр, незавершённая замена, причина и ответственный за продолжение. Закрытие всего наряда одной отметкой скроет оставшуюся работу.
Мы предлагаем проверить это как отдельный сценарий: сотрудник фиксирует дефицит, ответственный согласует дальнейшее действие, а диспетчер видит ожидаемое поступление или новое назначение. Кто вправе перенести работу и как оценить допустимость переноса, определяет ваша техническая служба.
При внеплановом отказе создаём связь с активом и исходным дефектом. Если ремонт меняет состав будущих работ, назначенный специалист пересматривает план. Автоматическое закрытие будущего ППР после любого ремонта допустимо лишь при согласованном правиле и составе выполненных операций.
Ещё одна проверка касается изменения регламента. Уже принятая работа сохраняет версию, по которой её выполняли. Для открытых заданий отдельно решаем, какие операции пересмотреть, кто согласует изменение и как мастер увидит актуальный перечень. Старую историю сохраняем доступной для разбора.
Готовая система, настройка или собственный модуль
Начать сравнение можно с предметного ядра. В 1С:ТОИР КОРП описаны реестр оборудования, графики ППР, потребность в ресурсах, наряды, учёт выполненных работ и история ремонтов. Технологические карты поддерживают версии. Это функции производителя, которые стоит проверить на демонстрации с вашими данными.
Затем отмечаем, какие расхождения закрываются настройками, какие требуют изменения процесса, а какие нуждаются в программной доработке. Готовое ядро с собственным мобильным модулем тоже может быть рабочим вариантом, если между ними определены владельцы данных и правила обмена.
Готовая ТОиР / CMMS
Когда проверять: Основной цикл укладывается в функции продукта; команда готова работать с его документами и ролями.
До заказа: Пройти наряд на ваших данных, проверить исключения, нужную редакцию, поставку, мобильные функции и поддерживаемый обмен.
Настройка и внедрение
Когда проверять: Ядро подходит, но нужно подготовить реестр, регламенты, роли, согласования и отчёты.
До заказа: Разделить настройки и кодовые доработки. Уточнить перенос данных, обучение, проверку обновлений и сопровождение.
Собственный модуль рядом с готовой системой
Когда проверять: Учёт уже работает, а конкретный шаг требует другого интерфейса или правила: например, задания для вашего парка устройств.
До заказа: Проверить доступный интерфейс обмена, права, повторы, ошибки и ответственность за две связанные системы.
Система на заказ
Когда проверять: Ключевой процесс существенно расходится с проверенными продуктами; замена этого процесса неприемлема по понятным причинам.
До заказа: Зафиксировать разрывы, объём первого цикла, миграцию, эксплуатацию и стоимость поддержки собственного решения.
Сравнивать затраты удобнее за один согласованный период: лицензии и поставка, настройка, очистка данных, интеграция, обучение, обновления и поддержка. Например, если мастеру нужна работа без сети, проверяем её включение в каждый вариант оценки. У собственного решения учитываем разработку и эксплуатацию серверной части. Для каждого варианта фиксируем одинаковый состав пилота.
Мобильный наряд проверяем на месте работы
Мобильное приложение технического обслуживания оборудования должно показывать мастеру конкретное задание: какой актив обслужить, по какой версии инструкции, что отметить и кому передать результат. В пилоте проверяем поиск нужной единицы, читаемость операций, вложения и заполнение факта на устройствах, которыми команда действительно пользуется.
Если на месте нет устойчивой связи, отдельно проектируем предварительную загрузку и сохранение результата на устройстве. Мастер должен различать «сохранено локально», «получено сервером» и «принято». Проверяем восстановление связи, повтор отправки и одновременное изменение наряда в офисе. До передачи серверу утрата устройства может привести к потере локальных записей; порядок хранения и восстановления согласуем заранее.
При оценке готовой 1С:ТОИР КОРП учитывайте отдельное мобильное приложение «Мобильная бригада». Производитель описывает получение заданий и обмен в онлайн- и офлайн-режимах и указывает, что приложение не входит в комплект поставки ТОИР КОРП. Состав поставки, совместимость и условия использования уточняем для выбранной версии.
Состав отдельного мобильного рабочего места мы разбираем на странице приложения сервисного инженера.
В обмене с 1С определяем владельца каждого факта
Фраза «интеграция с 1С» ещё не определяет состав проекта. Сначала фиксируем конфигурацию, версию, размещение базы и доступный интерфейс. Платформа 1С:Предприятие поддерживает разные способы интеграции; конкретные объекты и операции проверяем в вашей базе и с её правами.
Например, если материалы и стоимость уже учитываются в 1С, предлагаем сохранить этот учёт там. Мобильный модуль передаёт согласованные сведения о расходе и получает состояние обработки. Заранее решаем, кто утверждает расход, какой документ создаётся, кто его проводит и как возврат или исправление попадут в историю. Статус «отправлено» сам по себе не подтверждает списание.
Для пилота составляем карту обмена: идентификатор актива, устойчивый идентификатор задания и его номер для сотрудника, операции, материал и единица измерения, факт расхода, результат приёмки и состояние обработки. У каждого поля указываем основную систему, разрешённое направление изменения и ответственного за ошибку. На повторе после пропавшего ответа проверяем, как распознать уже обработанную операцию и избежать повторного учёта в согласованных сценариях.
Связанный мобильный процесс в нашей работе
В «Бакаеве» мы связали мобильный магазин, админ-панель и 1С через сервер синхронизации. Изменение фотографии в админке отражается в 1С; заказ в приложении меняет остатки в админке и учётной системе; изменения из 1С доходят до приложения. Для новой ТОиР этот опыт используем при проектировании связанного пути данных, а состав ремонтных документов и правила приёмки определяем по вашему процессу.
Реальный проект 13FOX / мобильный магазин
Админ-панель и 1С работают со связанными данными
В «Бакаеве» команда управляет каталогом через свою панель. Товары, остатки и изображения входят в двусторонний обмен.
Сотрудник меняет данные в панели; сервер синхронизации связывает изменения с 1С и приложением.
Экран проекта «Бакаев»: управление каталогом мобильного магазина и обмен с 1С.
Карта пилота: один класс активов и принятый результат
Для первой проверки предлагаем выбрать один класс оборудования, действующий регламент и типичный наряд. Техническая служба назначает владельца регламента и ответственного за приёмку. Вместе фиксируем обычный цикл и исключения, затем проводим их в выбранном решении. Эта карта помогает одинаково проверить готовый продукт и заказной модуль.
Актив и регламент
Подготовить: Реестр выбранного класса, идентификаторы, утверждённую инструкцию, версии и ответственных.
Приёмка: Задание относится к нужной единице. Из его истории можно открыть использованную версию регламента.
План и внеплановая заявка
Подготовить: Правило назначения ППР, пример отказа, заявку и наряд.
Приёмка: Основание и плановая дата сохранены отдельно от фактического выполнения; отказ связан с активом.
Ресурсы и исполнение
Подготовить: Пример учёта материалов, назначение исполнителя, доступ к оборудованию и парк устройств.
Приёмка: Факт операций различим; у дефицита, переноса и частичной работы есть причина, ответственный и следующий шаг.
Подтверждение и обмен
Подготовить: Правила приёмки, конфигурацию 1С, доступные объекты и ограничения обмена.
Приёмка: Отправка, получение, приёмка и обработка в учёте различимы. Повтор после сбоя проверен на согласованных сценариях.
История и продолжение
Подготовить: Правило следующего цикла и пример изменения регламента.
Приёмка: Можно восстановить ход обслуживания, увидеть оставшиеся работы и проверить основание следующего задания.
В границы первого этапа включаем выбранный реестр, цикл задания, роли, необходимый мобильный сценарий, историю и согласованный обмен. Несколько площадок, сложное планирование остановок, телеметрию и прогнозирование отказов оцениваем отдельно, если они нужны вашему процессу.
До расширения проверяем также права сотрудников, резервное копирование и восстановление, доступ к журналу ошибок и передачу сопровождения. Мастер, планировщик и специалист учёта проходят один и тот же контрольный наряд: каждый видит свой результат и следующий доступный шаг.
Оценка зависит от данных, правил и обмена
Смету предлагаем разложить на обследование процесса, подготовку реестра и регламентов, настройку или разработку, мобильную работу, интеграцию с 1С, перенос истории, испытания и запуск. Для каждого пункта фиксируем результат и допущения. Если нужны несколько баз 1С или работа без сети, выделяем их в отдельные проверяемые задачи.
Качество исходных данных влияет на объём работ: одинаковые активы с разными названиями, материалы без единиц измерения и история без идентификаторов потребуют сверки. Перед переносом согласуем, какие записи импортировать и как связать их с оборудованием. Один образец исходного файла часто полезнее длинного перечня желаемых функций.
К первой встрече достаточно обезличенной карточки актива, регламента и одного наряда. Если есть готовая CMMS или ТОиР, добавьте название и версию, описание незакрытого шага, текущую 1С и ответственных за процесс. На этих данных мы сравним варианты и подготовим границы пилота с проверками.
Вопросы перед выбором
Можно ли начать с журнала ремонта и графика ППР в Excel?
Да. Возьмём один класс активов и проверим связи между реестром, регламентом, планом и фактом. До переноса согласуем идентификаторы, качество истории и роли. Затем сравним готовую систему, настройку и доработку на этом цикле.
Когда нужен собственный модуль вместо замены всей ТОиР?
Когда готовое ядро ведёт активы и учёт, а разрыв касается отдельного шага, например мобильного задания. Проверяем интерфейс обмена, права, обработку ошибок и сопровождение связанной системы.
Может ли система сама назначать интервалы обслуживания?
Правила и допустимые интервалы утверждает ваша техническая служба по применимым регламентам и документации оборудования. Система может применять согласованные правила. Выбор методики и её изменение включаем в отдельное согласование с ответственным специалистом.
Что нужно для оценки мобильных заданий и обмена с 1С?
Карточка актива, регламент, пример наряда и расхода материалов, условия связи и устройства, конфигурация и версия 1С. Мы определим владельцев данных, направления обмена и проверки первого цикла.
Разберём ваш цикл обслуживания
Пришлите карточку актива, регламент и один наряд. Сравним готовую ТОиР, настройку и заказной модуль на вашем цикле, подготовим границы пилота и проверки.