Управление ремонтами и техническим обслуживанием в 1C:ERP

Нормативно-справочная информация и иерархия объектов эксплуатации

Добро пожаловать в курс «Управление ремонтами и техническим обслуживанием в 1C:ERP». Мы начинаем наше погружение в подсистему, которая отвечает за надежность оборудования, планирование ресурсов и минимизацию простоев. Любая автоматизированная система начинается с фундамента — нормативно-справочной информации (НСИ). Без корректно настроенной структуры данных невозможно построить эффективные процессы планирования и учета.

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

Зачем нужна подсистема ремонтов?

Прежде чем переходить к настройкам, важно понять философию 1C:ERP в части управления активами. Подсистема «Ремонты» (часто называемая ТОиР — Техническое Обслуживание и Ремонты) решает три глобальные задачи:

Обеспечение готовности оборудования. Мы должны знать, когда станок сломается, и предотвратить это (ППР — планово-предупредительные ремонты).

Учет затрат. Сколько денег, материалов и трудочасов уходит на содержание конкретного актива.

Снижение стоимости владения. Оптимизация запасов запчастей и графиков обслуживания.

Все это строится вокруг центрального понятия — Объекта эксплуатации.

Классы объектов эксплуатации

В 1C:ERP нельзя просто создать «станок» в вакууме. Система требует структурирования данных. Верхним уровнем этой структуры является Класс объектов эксплуатации.

Класс — это шаблон, объединяющий однотипное оборудование. Если у вас на заводе стоит 50 одинаковых токарных станков, нет смысла настраивать правила ремонта для каждого из них отдельно. Вы создаете класс «Токарные станки», задаете правила один раз, и все 50 станков наследуют эти настройки.

!Схематичное изображение того, как настройки класса распространяются на конкретные объекты эксплуатации.

Что настраивается в классе?

В карточке класса определяются критически важные параметры:

* Набор паспортных характеристик. Например, для автомобилей это будет VIN, мощность двигателя и грузоподъемность. Для станков — точность обработки и потребляемая мощность. Эти дополнительные реквизиты создаются именно на уровне класса. * Показатели наработки. Как мы измеряем жизнь оборудования? В часах, километрах, циклах, штуках выпущенной продукции? Класс определяет, какие счетчики мы будем вести. * Ремонтный цикл. Это правила планирования. Например: «Каждые 1000 часов наработки — Техническое Обслуживание (ТО-1), каждые 5000 часов — Капитальный ремонт». * Прочие настройки. Необходимость регистрации дефектов, связь с подсистемой производства и т.д.

> Правильно спроектированная структура классов — это 50% успеха внедрения. Избыточное дробление классов усложнит администрирование, а слишком обобщенные классы не позволят настроить точные правила планирования.

Объект эксплуатации: физическая сущность

Если класс — это шаблон, то Объект эксплуатации — это конкретная единица техники с инвентарным номером. Это может быть здание, станок, автомобиль, компьютерный сервер или даже участок трубопровода.

Отличие от Основных Средств (ОС)

Часто возникает путаница: «У нас же есть справочник Основных средств в бухгалтерии, зачем нам еще Объекты эксплуатации?». Это фундаментальный момент.

* Основное средство (ОС) — это финансово-бухгалтерская сущность. Она нужна для начисления амортизации, расчета налогов и баланса. ОС интересует стоимость и срок полезного использования. * Объект эксплуатации — это техническая сущность. Она нужна главному механику и инженеру. Их интересуют наработка, запчасти, нормативы ремонта и физическое состояние.

В 1C:ERP эти справочники разделены, но могут быть связаны. Одному объекту эксплуатации может соответствовать одно ОС, или несколько объектов могут составлять одно инвентарное ОС (компонентный учет).

Иерархия: Узлы и компоненты

Сложное оборудование редко обслуживается целиком и сразу. Рассмотрим пример карьерного самосвала. У него есть двигатель, трансмиссия и шины. Шины меняются по пробегу, масло в двигателе — по моточасам, а кузов ремонтируется по мере износа.

Для реализации такой логики в 1C:ERP используется иерархическая структура Узлов объекта эксплуатации.

!Пример декомпозиции сложного оборудования на ремонтопригодные узлы.

Зачем выделять узлы?

Разные стратегии ремонта. Узел может иметь свой собственный класс и, следовательно, свой ремонтный цикл, отличный от родительского объекта.

Локализация дефектов. При регистрации поломки диспетчер может указать не просто «Сломался станок», а конкретно «Сгорел электродвигатель подачи».

Замена компонентов. Узлы можно демонтировать и отправлять в ремонт отдельно, заменяя их на оборотный фонд.

Структура расположения и владения

Помимо технической иерархии (из чего состоит), существует иерархия расположения (где находится). В 1C:ERP объекты эксплуатации привязываются к структуре предприятия.

Важные разрезы учета:

* Подразделение-владелец. Кто отвечает за объект? Обычно это цех или отдел. * Местонахождение. Где физически стоит объект? Это может быть склад, территория или конкретный адрес. * Ремонтирующее подразделение. Кто обычно чинит этот объект? Собственная ремонтная служба или внешний подрядчик?

Интеграция с производством: Рабочие центры

Одной из самых сильных сторон 1C:ERP является бесшовная интеграция подсистем. Ремонты тесно связаны с Производством через понятие Рабочего центра (РЦ).

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

Связь работает в обе стороны:

Ремонты -> Производство: Если мы запланировали ремонт объекта эксплуатации на завтра, связанный с ним Рабочий центр становится недоступным. График производства автоматически перестроится, учитывая этот простой.

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

Паспортизация и мониторинг показателей

Для каждого объекта эксплуатации в системе ведется своего рода «медицинская карта». В ней фиксируются:

* Паспортные данные: Год выпуска, серийный номер, производитель, технические характеристики (значения дополнительных реквизитов). * Текущие показатели наработки: Вводятся вручную (по журналам) или автоматически (через АСУ ТП или производственный учет).

Показатели наработки критически важны для стратегии ремонта «по состоянию» или «по наработке». Если вы настроили правило «Менять масло каждые 500 часов», система будет ждать, пока счетчик наработки достигнет этого значения, и только тогда предложит создать заказ на ремонт.

Резюме

Мы рассмотрели фундамент подсистемы ТОиР в 1C:ERP. Давайте закрепим основные тезисы:

* Класс объектов эксплуатации — это шаблон настроек и правил планирования для группы однотипных объектов. * Объект эксплуатации — это техническая единица учета, отличная от бухгалтерского Основного средства. * Узлы позволяют детализировать сложные объекты и назначать разные ремонтные циклы для составных частей. * Связь с Рабочими центрами обеспечивает синхронизацию планов ремонтов и планов производства.

В следующей статье мы перейдем от статических данных к динамике: рассмотрим виды ремонтов, настройку ремонтных циклов и формирование графика ППР.

Учет показателей наработки и регистрация дефектов оборудования

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

В этой статье мы разберем два ключевых потока информации, которые питают подсистему ремонтов в 1C:ERP:

Показатели наработки — как много и интенсивно работает оборудование (аналог одометра в автомобиле).

Регистрация дефектов — фиксация неисправностей, поломок и отклонений от нормы (аналог лампочки «Check Engine»).

Именно эти данные позволяют перейти от ремонтов «по интуиции» к ремонтам «по состоянию» и объективной статистике.

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

Зачем нам знать наработку? Большинство регламентных работ (ТО) привязаны не к календарю, а к фактическому использованию. Бессмысленно менять масло в двигателе резервного генератора каждый месяц, если он запускался всего один раз на 15 минут. Но для основного конвейера, работающего 24/7, обслуживание нужно проводить строго по часам работы.

Настройка показателей

Как мы уже упоминали, показатели наработки задаются в Классе объектов эксплуатации. Это логично: все станки одной модели имеют одинаковые счетчики. В 1C:ERP вы можете создать любые показатели:

* Моточасы (время работы двигателя); * Километры пробега (для автотранспорта); * Количество циклов (для прессов или штампов); * Объем выпущенной продукции (литры, штуки, метры).

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

Способы регистрации наработки

В 1C:ERP существует два основных способа сообщить системе, сколько «пробежал» наш станок или автомобиль.

#### 1. Ручная регистрация

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

Для этого используется документ «Наработка объектов эксплуатации».

Процесс выглядит так:

Ответственный (мастер смены, механик или диспетчер) создает документ.

Подбирает объекты (можно заполнить списком по цеху).

Вводит текущие значения счетчиков или дельту (сколько наработано с прошлого раза).

> Важно: Система хранит историю значений. Это позволяет строить графики интенсивности использования и прогнозировать, когда наступит следующий ремонт.

!Визуализация потока данных при ручном вводе показателей наработки.

#### 2. Автоматическая регистрация через Производство

Это один из самых мощных механизмов интеграции в 1C:ERP. Если вы ведете производственный учет в системе, то данные о работе оборудования у вас уже есть, и дублировать их вручную не нужно.

Логическая цепочка выглядит следующим образом:

У нас есть Объект эксплуатации (например, «Станок фрезерный №5»).

Этот объект связан с Рабочим центром (ресурсом для планирования производства).

Производственный диспетчер отмечает выполнение этапов производства на этом Рабочем центре (например, «Выполнена операция фрезеровки, затрачено 4 часа»).

Система автоматически конвертирует эти 4 часа загрузки Рабочего центра в 4 моточаса наработки Объекта эксплуатации.

Для настройки такой магии в карточке Объекта эксплуатации необходимо установить связь с Рабочим центром и указать коэффициент пересчета (обычно 1 к 1, но бывают исключения).

Остаточный ресурс

Главная цель учета наработки — расчет остаточного ресурса. Если межремонтный интервал составляет 1000 часов, а текущая наработка после последнего ремонта — 850 часов, система понимает: осталось 150 часов. Зная среднесуточную загрузку, 1C:ERP может точно спрогнозировать дату следующего ТО. Это позволяет заказать запчасти заранее, именно к нужному моменту, а не хранить их на складе годами.

Регистрация дефектов: управление инцидентами

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

В старых системах управления механик просто записывал проблему в бумажный журнал («Журнал дефектов»), и запись могла потеряться. В 1C:ERP процесс регистрации дефектов формализован и прозрачен.

Документ «Регистрация дефектов»

Любой инцидент фиксируется с помощью документа «Регистрация дефектов». Этот документ является точкой входа для внеплановых ремонтов.

Ключевые поля документа:

* Объект эксплуатации. Что сломалось? * Дефектный узел. Если мы используем иерархию, можно указать конкретную часть (например, не весь автомобиль, а «Тормозная система»). * Вид дефекта. Выбирается из справочника (например, «Износ подшипника», «Обрыв цепи»). Это нужно для последующей аналитики: какие поломки случаются чаще всего? * Критичность дефекта. Это важнейший параметр, определяющий скорость реакции.

Уровни критичности

Обычно на предприятиях настраивают несколько уровней критичности, например:

Аварийная (Высокая). Оборудование остановлено, производство стоит. Требуется немедленная реакция.

Средняя. Оборудование работает, но с ограничениями (снижена скорость или точность). Ремонт нужен в ближайшее время.

Низкая. Дефект не влияет на работу (например, царапина на корпусе или перегоревшая лампочка индикации). Можно устранить при следующем плановом ТО.

!Схема жизненного цикла дефекта в зависимости от его критичности.

Жизненный цикл дефекта

Документ дефекта имеет статусы, которые позволяют отслеживать процесс его устранения:

* Зарегистрирован. Проблема зафиксирована, но решение еще не принято. * В работе. На основании дефекта создан Заказ на ремонт. * Устранен. Ремонт выполнен, оборудование исправно. * Отклонен. Если при проверке выяснилось, что дефекта нет (ложная тревога).

Связь с ремонтными заказами

Сам по себе документ «Регистрация дефектов» ничего не чинит. Он лишь сигнализирует о проблеме. Чтобы начать работы, на основании дефекта создается Заказ на ремонт.

Здесь проявляется гибкость системы: * Один дефект -> Один заказ на ремонт (срочное устранение). * Несколько мелких дефектов -> Один заказ на ремонт (накопили список замечаний и устранили все разом во время плановой остановки).

Журнал дефектов

Для главного механика или инженера по надежности основным рабочим местом является Журнал дефектов. Это сводная таблица всех зарегистрированных инцидентов с цветовой индикацией.

Что позволяет делать журнал:

Видеть оперативную сводку по цеху или заводу.

Контролировать сроки реакции (сколько времени прошло от регистрации до взятия в работу).

Анализировать «больные места». Если на одном и том же станке каждую неделю регистрируется дефект «Перегрев двигателя», это повод не просто чинить его, а пересмотреть условия эксплуатации или провести глубокую модернизацию.

Интеграция с мобильными устройствами

Хотя в рамках базового курса мы рассматриваем настольную версию 1C:ERP, важно знать, что процесс регистрации наработки и дефектов идеально подходит для мобильной автоматизации. Обходчик с планшетом или смартфоном может считывать штрих-код на станке, вводить показания счетчика и делать фото дефекта, которое сразу прикрепляется к документу в системе. Это значительно ускоряет передачу информации от цеха к отделу планирования.

Резюме

Мы рассмотрели, как система наполняется данными о жизни оборудования.

* Наработка — это «пульс» актива. Мы регистрируем её вручную или получаем автоматически из производства. Наработка расходует ресурс и приближает плановый ремонт. * Дефекты — это «симптомы болезни». Мы регистрируем их, оцениваем критичность и на их основании создаем заказы на внеплановый ремонт или дополняем плановые работы.

Теперь, когда у нас есть НСИ (кто?), и есть оперативные данные (в каком состоянии?), мы готовы перейти к самому сложному и интересному этапу — Планированию ремонтов. В следующей статье мы разберем, как система строит график ППР, балансирует ресурсы и формирует бюджет на обслуживание.

Планирование технического обслуживания и формирование графиков ремонтов

Мы продолжаем наш курс по управлению ремонтами в 1C:ERP. В прошлых статьях мы создали структуру оборудования (НСИ) и научились собирать данные о его состоянии (наработка и дефекты). Теперь у нас есть «пациент» и его «история болезни». Настало время перейти к профилактике.

В этой статье мы разберем сердце подсистемы ТОиР — планирование. Мы узнаем, как превратить хаотичный поток поломок в стройный график планово-предупредительных ремонтов (ППР), как настроить ремонтные циклы и как система помогает балансировать потребности в запчастях и людях.

От реакции к предупреждению

Главная цель внедрения 1C:ERP в ремонтах — переход от стратегии «чиним, когда сломалось» к стратегии «обслуживаем, чтобы не ломалось». Это называется Планово-предупредительный ремонт (ППР).

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

Настройка правил планирования

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

Виды ремонтов

Сначала необходимо определить, какие вообще вмешательства требуются оборудованию. В справочнике «Виды ремонтов» мы создаем перечень возможных активностей, например:

* ТО-1 (Ежемесячное): Осмотр, смазка, чистка. * ТО-2 (Полугодовое): Замена фильтров, проверка электрики, калибровка. * Капитальный ремонт: Полная разборка, замена узлов, восстановление геометрии.

Для каждого вида ремонта мы указываем:

Длительность: Сколько времени оборудование будет простаивать (например, 4 часа или 5 дней).

Материалы: Какие запчасти нужны по умолчанию (масло, ветошь, подшипники).

Трудозатраты: Какие специалисты и сколько часов должны отработать (слесарь 3 разряда — 2 часа).

Ремонтные циклы

Просто создать список ремонтов недостаточно. Нужно выстроить их в последовательность. Это и есть Ремонтный цикл.

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

!Графическое представление ремонтного цикла: последовательность малых и больших ремонтов.

В 1C:ERP вы настраиваете эти зависимости. Вы можете сказать системе: * «Выполнять ТО-1 каждые 500 моточасов». * «Выполнять ТО-2 каждые 2000 моточасов».

Система автоматически поймет, что на отметке 2000 часов нужно делать именно ТО-2, который «поглощает» или заменяет собой ТО-1.

Стратегии планирования: Время vs Наработка

1C:ERP поддерживает два основных подхода к расчету даты следующего ремонта. Выбор зависит от типа оборудования и режима его эксплуатации.

1. Планирование по времени

Самый простой вариант. Ремонт назначается строго по календарю. Пример:* Проверка пожарной сигнализации — раз в год. Осмотр кровли здания — раз в сезон.

Система просто берет дату последнего ремонта и прибавляет заданный интервал (например, 365 дней).

2. Планирование по наработке

Более точный и экономичный вариант для производственного оборудования. Ремонт назначается, когда станок реально отработал определенный ресурс. Пример:* Замена масла в двигателе каждые 10 000 км или 500 моточасов.

Здесь работает механизм прогнозирования. Система знает:

Дату и показания счетчика при последнем ремонте.

Текущие показания счетчика (которые мы научились вводить в прошлой статье).

Среднесуточную наработку (как интенсивно используется объект).

На основе этих данных 1C:ERP рассчитывает дату, когда счетчик достигнет критической отметки. Если станок стал работать в две смены вместо одной, система увидит ускоренный рост наработки и автоматически сдвинет плановый ремонт на более раннюю дату.

> Важно: Можно комбинировать подходы. Например, «Менять масло каждые 10 000 км, но не реже 1 раза в год». Система выберет то событие, которое наступит раньше.

Рабочее место «Планирование ремонтных работ»

Когда правила настроены, в игру вступает диспетчер или планировщик. Его основной инструмент — рабочее место «Планирование ремонтных работ».

Это специализированный интерфейс, который позволяет сформировать график ремонтов в несколько шагов.

Шаг 1: Расчет потребностей

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

В результате формируется список Распоряжений на ремонт. Это еще не утвержденный план, а рекомендация системы: «Судя по правилам, в следующем месяце нужно обслужить эти 15 станков».

Шаг 2: Формирование графика и устранение коллизий

На этом этапе диспетчер видит предварительный график, часто представленный в виде диаграммы Ганта.

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

Здесь решаются организационные вопросы: * Доступность оборудования. Не запланирован ли станок под важный производственный заказ? 1C:ERP подсветит конфликт, если ремонт пересекается с планом производства. * Доступность бригад. Хватит ли у нас слесарей, чтобы починить три станка в один день? Если нет, ремонт можно перетащить мышкой на другую дату.

Шаг 3: Создание Заказов на ремонт

Когда график утрясен и согласован, диспетчер превращает виртуальные планы в реальные документы — Заказы на ремонт.

Заказ на ремонт — это ключевой документ планирования. Он выполняет несколько функций:

Бронирует мощности. С этого момента производство «видит», что станок будет остановлен, и не планирует на него работу.

Резервирует материалы. Система создает потребность в запчастях на складе. Если запчастей нет, формируется заказ поставщику.

Назначает исполнителей. Указывается бригада или подразделение, ответственное за работу.

Скользящее планирование

В практике крупных предприятий часто используется подход скользящего планирования.

Например, график ППР составляется на год вперед, но он является предварительным. Каждый месяц происходит перепланирование (актуализация) на ближайший месяц с учетом фактической наработки.

1C:ERP идеально поддерживает этот процесс. Вы можете сформировать годовой план для бюджета (чтобы понять, сколько денег нужно на запчасти), а затем ежемесячно создавать точные Заказы на ремонт, корректируя даты в зависимости от реального износа оборудования.

Внеплановые ремонты в графике

А что делать с дефектами, которые мы регистрировали в прошлой статье? Они тоже попадают в этот общий котел планирования.

В рабочем месте планирования есть отдельная вкладка для зарегистрированных дефектов. Диспетчер может: * Создать срочный Заказ на ремонт для устранения критичного дефекта. * Присоединить устранение мелкого дефекта к ближайшему плановому ТО. Это позволяет сэкономить время простоя: раз уж мы все равно останавливаем станок для замены масла, давайте заодно починим и мигающую лампочку, о которой сообщали неделю назад.

Обеспечение материалами

Одной из частых причин срыва сроков ремонта является отсутствие запчастей. «Разобрали двигатель, а прокладки нет на складе».

Подсистема ремонтов в 1C:ERP тесно интегрирована с подсистемой Закупок и Склада.

В момент формирования Заказа на ремонт система автоматически проверяет остатки. * Если детали есть — они резервируются под этот конкретный ремонт. * Если деталей нет — они попадают в план закупок. Логист видит потребность: «К 15-му числу для ремонта станка №5 нужны подшипники».

Это позволяет реализовать принцип Just-in-Time (точно в срок) для ремонтных нужд, не замораживая лишние деньги в складских запасах.

Резюме

Планирование ремонтов в 1C:ERP — это переход от хаоса к системе.

Мы задаем Ремонтные циклы в классах оборудования.

Система отслеживает наработку и прогнозирует даты ремонтов.

Диспетчер использует рабочее место планирования для балансировки ресурсов и устранения конфликтов с производством.

Итогом планирования является Заказ на ремонт, который запускает процессы обеспечения материалами и подготовки к работам.

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

Управление заказами на ремонт и отражение фактических затрат

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

В этой статье мы разберем процесс исполнения ремонтных работ в 1C:ERP: от выдачи задания бригаде до списания последней гайки и расчета итоговой стоимости владения оборудованием.

Заказ на ремонт: центр управления полетами

В подсистеме ТОиР (Техническое обслуживание и ремонты) центральным документом исполнения является Заказ на ремонт. Если график ППР — это стратегия, то Заказ на ремонт — это тактика.

Этот документ выполняет три критически важные функции:

Организационная: является официальным распоряжением для ремонтной службы начать работы.

Логистическая: резервирует материалы на складе и инициирует закупку недостающих запчастей.

Финансовая: выступает «котлом», в котором собираются все затраты (материалы, зарплата, услуги подрядчиков), связанные с конкретным ремонтом.

Жизненный цикл заказа

Работа с документом строится на системе статусов. Это позволяет диспетчеру и главному механику видеть реальную картину в цехе.

!Жизненный цикл Заказа на ремонт: от планирования до закрытия.

Создан: Документ сформирован на основании плана или дефекта. В нем указано, что* нужно сделать, но работы еще не начаты. * К выполнению: Все материалы в наличии, бригада назначена, станок остановлен. Можно приступать. * Выполнен: Механик отчитался о завершении работ. Оборудование снова в строю. * Закрыт: Экономисты проверили списания и «закрыли» документ, запретив его редактирование.

Обеспечение материалами и запчастями

Одна из самых частых проблем на производстве — простой ремонтной бригады из-за отсутствия нужной прокладки или подшипника. 1C:ERP решает эту проблему через механизм обеспечения потребностей.

Внутри Заказа на ремонт есть вкладка «Материалы и работы». Она заполняется автоматически на основании Технологической карты (если мы настроили её в Классе объектов эксплуатации) или вручную мастером.

Для каждой номенклатуры (запчасти) указывается Действие:

К обеспечению: Сигнал для отдела закупок. Это значит «нам нужна эта деталь к дате начала ремонта, купите или переместите её».

Резервировать: Если деталь есть на складе, система «замораживает» её под этот заказ. Никто другой не сможет её забрать.

Отгрузить: Команда кладовщику выдать деталь мастеру. Обычно этот статус ставится непосредственно перед началом работ.

> Эффективное управление обеспечением позволяет реализовать стратегию «Just-in-Time» (точно в срок) для ремонтов, минимизируя складские запасы дорогостоящих узлов.

Списание материалов по факту

План есть план, но реальность вносит коррективы. Планировали заменить 2 литра масла, а пришлось долить 2.5. Сломали шпильку при откручивании — потребовалась новая.

В 1C:ERP реализован принцип разделения плановых и фактических затрат. В Заказе на ремонт вы указываете норматив. Но фактическое списание со склада оформляется документом «Внутреннее потребление товаров» с операцией «Списание на расходы».

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

Учет трудозатрат

Ремонт — это не только запчасти, но и труд людей. Учет трудозатрат необходим для двух целей:

Расчет себестоимости ремонта. Зарплата слесаря — это часть стоимости владения станком.

Начисление сдельной оплаты. Если ремонтный персонал работает на сделке, система должна знать, кто и сколько часов отработал.

Для фиксации работ используется документ «Выработка сотрудников».

Процесс выглядит так:

В Заказе на ремонт на вкладке «Трудозатраты» мы планируем: «Слесарь 5 разряда, 4 часа».

По факту выполнения мастер создает документ выработки, где указывает конкретных сотрудников (Иванов, Петров) и их реальное время работы.

Эти данные автоматически попадают в модуль «Зарплата и управление персоналом» для расчета выплат.

Отражение результатов: Текущий ремонт или Модернизация?

Когда ремонт завершен, перед бухгалтером и финансистом встает вопрос: как отразить эти затраты в учете? В 1C:ERP есть два принципиально разных пути, выбор которых зависит от сути выполненных работ.

1. Текущий ремонт (Операционные расходы)

Это обычное обслуживание: замена масла, фильтров, изношенных деталей. Цель таких работ — поддержать оборудование в рабочем состоянии, не улучшая его характеристик.

* Куда идут затраты: Списываются на расходы текущего периода (себестоимость продукции или общецеховые расходы). * Влияние на актив: Стоимость станка не меняется.

В Заказе на ремонт для этого выбирается соответствующая Статья расходов (например, «Ремонт оборудования»). Система распределит эти суммы согласно правилам управленческого учета.

2. Модернизация (Капитальные вложения)

Это серьезное вмешательство, которое улучшает характеристики объекта. Например, установка ЧПУ на старый токарный станок или замена двигателя на более мощный.

* Куда идут затраты: Увеличивают первоначальную стоимость Основного Средства (ОС). * Влияние на актив: Станок становится дороже, и амортизация пересчитывается.

Для отражения такой операции на основании Заказа на ремонт создается документ «Модернизация ОС». Все накопленные на заказе затраты (материалы + труд) капитализируются в стоимость объекта.

!Визуализация финансового различия между текущим ремонтом и модернизацией.

Анализ стоимости владения

Финальный аккорд любого процесса управления — аналитика. В 1C:ERP подсистема ремонтов предоставляет отчеты, которые отвечают на главные вопросы главного инженера и директора завода.

План-фактный анализ

Отчет показывает, насколько мы отклонились от нормативов. Мы видим перерасход материалов, превышение времени ремонта или, наоборот, экономию. Это база для принятия управленческих решений.

Полная стоимость владения (TCO)

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

Заключение курса

Мы прошли полный путь настройки и использования подсистемы ремонтов в 1C:ERP.

Давайте подведем итоги всего курса:

НСИ: Мы создали иерархию объектов и классы, задав правила игры.

Мониторинг: Настроили сбор данных о наработке и регистрацию дефектов, чтобы держать руку на пульсе.

Планирование: Научились формировать графики ППР, переходя от аварийных ремонтов к плановым.

Исполнение: Разобрали, как управлять заказами, обеспечивать их материалами и корректно считать деньги.

Внедрение этих процессов позволяет предприятию перейти от хаоса «тушения пожаров» к прозрачной и управляемой системе надежности оборудования. Спасибо, что были с нами на этом курсе!

Аналитическая отчетность и контроль эффективности ремонтной деятельности

Мы подошли к финальной точке нашего курса по управлению ремонтами в 1C:ERP. В предыдущих статьях мы прошли долгий путь: от создания справочников оборудования и настройки нормативов до планирования и фактического выполнения работ. Теперь ваша система наполнена данными. Но данные сами по себе — это просто цифровой шум. Чтобы они приносили пользу бизнесу, их нужно превратить в информацию, а информацию — в управленческие решения.

В этой статье мы разберем, как использовать аналитические инструменты 1C:ERP для оценки эффективности ремонтной службы. Мы узнаем, как считать деньги, оценивать надежность оборудования и контролировать работу персонала.

Зачем нужна аналитика в ремонтах?

Многие руководители считают, что хорошая работа главного механика — это когда «ничего не ломается». Это опасное заблуждение. Можно добиться нулевой аварийности, меняя исправные детали каждый день, но тогда предприятие разорится на запчастях.

Эффективное управление ремонтами (ТОиР) — это баланс между надежностью и затратами. Аналитика в 1C:ERP позволяет ответить на три главных вопроса:

Где мы теряем деньги? (Анализ затрат).

Насколько эффективно работает оборудование? (Анализ надежности).

Как работают наши люди? (Анализ трудозатрат и дисциплины).

Оперативный контроль: План-фактный анализ

Первый уровень отчетности — это оперативный контроль. Диспетчеру и начальнику цеха нужно знать, что происходит «здесь и сейчас», и насколько мы отклонились от графика.

Отчет «Состояние объектов эксплуатации»

Это «приборная панель» диспетчера. Отчет показывает текущий статус каждой единицы оборудования:

* В работе; * В ремонте (плановом или аварийном); * Простаивает.

Здесь же подсвечиваются «просроченные» ремонты — работы, которые должны были начаться вчера, но заказ на них до сих пор не создан или не переведен в статус выполнения.

План-фактный анализ выполнения работ

Это основной инструмент контроля дисциплины. Система сравнивает два потока данных:

План: То, что мы запланировали в «Графике ремонтных работ».

Факт: То, что мы отразили в закрытых «Заказах на ремонт».

!Визуализация сравнения плановых и фактических показателей ремонта.

Отчет позволяет увидеть отклонения в трех разрезах:

* По срокам: Планировали чинить 4 часа, чинили 8. Почему? Нет запчастей или низкая квалификация слесаря? * По материалам: Планировали заменить 2 подшипника, списали 4. Куда делись лишние? * По стоимости: Бюджет ремонта был 50 000 руб., по факту потратили 75 000 руб. из-за срочной закупки деталей по завышенной цене.

Финансовый контроль: Полная стоимость владения

Переходим на уровень выше. Финансового директора не интересует, сколько гаек вы потратили. Ему важно знать TCO (Total Cost of Ownership) — полную стоимость владения активом.

В 1C:ERP отчет «Стоимость владения объектами эксплуатации» собирает все затраты за выбранный период:

Стоимость материалов и запчастей.

Зарплата ремонтного персонала (через выработку сотрудников).

Стоимость услуг сторонних подрядчиков.

Амортизация (если настроена интеграция с регламентированным учетом).

Зачем это нужно?

Представьте, что у вас есть два станка с одинаковой производительностью:

| Параметр | Станок А (Китай) | Станок Б (Германия) | | :--- | :--- | :--- | | Цена покупки | 1 000 000 руб. | 3 000 000 руб. | | Затраты на ремонт в год | 500 000 руб. | 50 000 руб. | | Срок службы | 5 лет | 10 лет |

Без аналитики TCO вы видите только цену покупки и считаете, что Станок А выгоднее. Но отчет в 1C:ERP покажет, что через 5 лет владения Станок А «съест» еще 2.5 млн на ремонтах, плюс убытки от простоев. Анализ стоимости владения помогает принимать обоснованные решения о списании старой техники и закупке новой.

Анализ надежности: KPI ремонтной службы

Для главного инженера и службы надежности деньги — это следствие. Причина — в физике процессов. Чтобы управлять надежностью, используются международные показатели эффективности (KPI). 1C:ERP позволяет рассчитать их на основании данных о наработке и дефектах.

MTBF (Mean Time Between Failures)

Это среднее время между отказами. Показатель говорит о том, как часто ломается оборудование. Чем выше это число, тем надежнее станок.

Формула расчета:

где — среднее время между отказами, — суммарное время полезной работы оборудования за период, — количество аварийных остановок (отказов) за тот же период.

> Если падает со временем, значит, оборудование изнашивается или качество ремонтов ухудшается.

MTTR (Mean Time To Repair)

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

Формула расчета:

где — среднее время восстановления, — суммарное время аварийных простоев (время ремонта), — количество аварийных остановок.

!Графическое пояснение смысла показателей MTBF и MTTR на временной шкале.

КТГ (Коэффициент технической готовности)

Это интегральный показатель, который отвечает на вопрос: «Какую долю времени станок готов к работе?».

Формула расчета:

где — коэффициент технической готовности, — плановый фонд времени работы (сколько станок должен был работать), — время всех простоев (и плановых, и аварийных).

Обычно целевой уровень КТГ для промышленного оборудования составляет 85-95%.

Анализ причин дефектов

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

В аналитическом блоке 1C:ERP можно построить отчет по частоте возникновения дефектов. Часто используется принцип Парето (80/20):

> 20% типов неисправностей вызывают 80% простоев.

Выявив эти «болевые точки» (например, постоянный перегрев подшипника на конвейере), вы можете изменить стратегию обслуживания: поставить более качественные детали, увеличить частоту смазки или провести модернизацию узла.

Монитор целевых показателей

Для высшего руководства в 1C:ERP существует инструмент «Монитор целевых показателей». Это настраиваемый дашборд, куда можно вывести ключевые метрики ремонтной деятельности в упрощенном виде:

* Текущий КТГ по заводу; * Сумма затрат на ремонты с начала месяца; * Количество открытых аварийных заявок.

Это позволяет директору держать руку на пульсе, не погружаясь в детали конкретных заказ-нарядов.

Заключение курса

Мы завершаем наш курс «Управление ремонтами и техническим обслуживанием в 1C:ERP». Давайте вспомним путь, который мы прошли:

НСИ: Мы структурировали оборудование, разделили его на классы и узлы.

Учет: Наладили сбор данных о наработке и дефектах.

Планирование: Перешли от хаотичных ремонтов к системе ППР, настроив ремонтные циклы.

Производство ремонтов: Научились управлять заказами, материалами и трудозатратами.

Анализ: И, наконец, научились оценивать эффективность всей системы через KPI и финансовые отчеты.

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