Развитие экосистемы 1С:ТОИР — новая функциональность для управления ремонтами обслуживанием оборудования

Наша цель — улучшить культуру принятия эффективных управленческих решений в бизнесе

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

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

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

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

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

«Умная программа»: вся сложность мира — за фасадом

За 15 лет работы в области автоматизации предприятий я часто слышал от пользователей фразу: «Ну программа же сама должна...». Меня это искренне удивляло тогда. Программа — это инструмент. Как молоток или рубанок может быть кому-то что-то должен, тем более «сам»? Программа должна быть понятной и прозрачной, у нее нет своего мнения или воли. Она точно не может принять решение за человека.

А потом в наш обиход вошли «умные» дома, «умные» автомобили, «умные» часы... Устройства прятали за своим фасадом сложность мира.

Дома делают комнаты комфортными, скрывая в себе сложный алгоритм управления освещением, нагревателями и кондиционерами. Автомобили позволяют «просто ехать», не нагружая тонкостями того, как должна работать АБС, как избежать отката при начале движения в горку и прочее. Многие автомобили могут сами парковаться, но не пытаются объяснять водителю, как они это делают.

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

Материально-техническое обеспечение: подсистема МТО

Самым крупным нововведением в 1С:ТОИР 2 КОРП последнего времени стала переработка блока МТО.

Материально-техническое обеспечение занимает одно из важнейших мест в жизни ремонтной службы:

• большую часть бюджета составляют именно запчасти и материалы;
• отсутствие к сроку ремонта нужных материалов может нарушить все планы;
• хранение материалов и запчастей требует финансов, человеческих ресурсов и помещений.

Процессы МТО

Всю деятельность по материально-техническому обеспечению можно разделить на несколько укрупненных процессов. Эти процессы МТО предназначены для обеспечения наличия требуемых ТМЦ (товарно-материальных ценностей) для выполнения ремонтных работ хозспособом в нужное время в нужном месте.

Процесс МТО выглядит следующим образом.

1. Ведение НСИ, т.е. нормативно-справочной информации (справочников «Номенклатура» и «Склады», а также связанных справочников).

2. Формирование потребностей ТМЦ на предприятии на основании нормативов или смет ремонтов.

3. Обеспечение потребности в ТМЦ.

• Фиксация потребностей к обеспечению в виде заказов на ТМЦ на склады.
• Оценка и согласование заказов на ТМЦ (по бюджету).
• Определение способов обеспечения потребностей.
• Закупка ТМЦ (формирование заказов на закупку, оценка и согласование заказов на закупку (по бюджету и срокам), формирование плана поставок, заключение договоров с поставщиками (в т.ч. проведение тендеров), учет поставок).
• Формирование заказов на перемещение, производство и сборку/разборку.

4. Управление складскими запасами:

• Оперативный учет движения ТМЦ на складах.
• Инвентаризация ТМЦ на складах.
• Поддержание минимального складского запаса ТМЦ.
• Резервирование складских остатков под заказы на ТМЦ.
• Учет ТЗР.
• Учет партий, ГТД, СФ.

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

Как эти процессы отражены в 1С:ТОИР?

Мы стали применять различные подходы и проектировать модели, чтобы отразить эти процессы в 1С:ТОИР 2 КОРП, и увидели два противоречивых требования от пользователей.

• С одной стороны, в блоке МТО нужны богатые возможности, которые могут встретиться в работе реального крупного предприятия.
• С другой стороны, блок не должен быть переусложнен. Он должен быть простым в использовании.

Чтобы удовлетворить этим требованиям, мы решили предложить два разных способа ведения МТО в 1С:ТОИР 2 КОРП:

• блок внутри системы 1С:ТОИР;
• обмен с «1С:ERP Управление предприятием 2» (или «1С:Управление торговлей», «1С:Комплексная автоматизация 2».

Подчеркну, что внутренний блок реализует все основные процессы МТО и ограничен только тем, что использует исключительно внутренние данные системы 1С:ТОИР 2 КОРП.

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

Возможности внутреннего блока МТО в 1С:ТОИР

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

Первый слой

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

• Фиксация плановой потребности в заказах на внутреннее потребление.
• Заказы поставщикам.
• Резервирование.
• Поддержание минимального складского запаса.
• Учет ТМЦ на складах и на руках.
• Инвентаризация.

Фиксация плановой потребности в заказах на внутреннее потребление

Что такое потребность? Как ее зафиксировать? Откуда вообще возникает потребность в материалах и запчастях? Потребность характеризуется двумя составляющими: «Что нужно?» и «Когда нужно?».

В системе 1С:ТОИР 2 КОРП часть «что» определяется:

• в технологических картах в виде материальных затрат;
• в объектах ремонта и типовых объектах ремонта в виде списка запчастей входящих в конструкцию.

Часть «когда» определяется размещением мероприятий в календарном графике. На нее влияют:

• графики ППР (планово-предупредительных ремонтов);
• графики регламентных мероприятий;
• общий план работ подразделения;
• остановочные ремонты;
• закрытие заявок.

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

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

Умный заказ на внутреннее потребление

Очевидно, что вручную собрать потребности не представляется возможным.

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

Смета ремонта

Благодаря тому, что вся сложность «спрятана» за фасадом простого заказа, в системе МТО правильно поддерживаются даже самые вычурные случаи. Например, в результате корректировки общего плана работ смещается срок одного из ремонтов с марта на апрель. А для этого вида ремонта с апреля должна действовать другая версия техкарты с другими летними материалами. Система это правильно учтет и поменяет потребности. При этом всё останется прозрачным и прослеживаемым.

Остальные возможности первого слоя

Коротко про остальные возможности первого слоя.

• Заказы поставщикам. Позволяют учесть, что уже заказано и когда прибудет к нам.
• Резервирование. Позволяет заблокировать материалы на складе под конкретный ремонт. Резервирование у нас тоже «умное» — нет необходимости вручную размещать и привязывать каждое поступление. «Программа сделает сама» — зарезервирует по потребностям по хронологии или с учетом критичности ремонтов.
• Поддержание минимального складского запаса. Позволяет отслеживать и поддерживать наличие некоего постоянного уровня определенных материалов — например, для аварийных работ, или тех, чей расход достаточно регулярный.
• Инвентаризация. Позволяет напечатать форму инвентаризационная описи ИНВ-3, отразить излишки и недостачи.

Второй слой

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

1. Обеспечение ремонтов и мероприятий.

• Какие будущие ремонты обеспечены, а какие нет?
• Обеспечен ли ремонт?
• Обеспечена ли смета?
• Хочу зарезервировать материалы под этот ремонт/эту смету!

2. Управление запасами.

• Что нам потребуется в ближайшем будущем?
• Что и где у нас лежит сейчас?
• Что заказано и когда прибудет?
• Откуда можно забрать, если очень надо?

3. Работа кладовщика.

• Хочу, чтобы на складе и в учете было одинаково!
• Что из имеющегося можно отдать бригаде?

• Хочу принять затраты по тем материалам, которые в акте
• Остальные материалы, переданные бригаде, — вернуть на склад!

Третий слой

Третий слой — это материализованное решение задач предыдущего слоя с разбивкой по ролям. Именно здесь мы больше всего пытаемся «помочь» пользователям принимать решения эффективно.

Инструментальные возможности внутреннего блока:

• рабочее место специалиста по обеспечению;
• рабочее место «Передача на руки/возврат на склад»;
• состояние обеспечения заказов (СОЗ);
• отчетность.

Рабочее место специалиста по обеспечению

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

Рабочее место специалиста по обеспечению

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

Состояние обеспечения заказов

Состояние обеспечения заказов

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

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

Разные отчеты и ведомости по наличию на складах и на руках. Развитие блока не останавливается, в нем регулярно появляются новые возможности — например, учет сроков поставки материалов или резервирование с учетом критичности дефектов и объектов ремонта.

МТО при интеграции 1С:ТОИР с 1С:ERP/1С:УТ/1С:КА2

Несколько слов о том, как работает 1С:ТОИР 2 КОРП совместно с «1С:ERP Управление предприятием 2», а также с «1С:Управление торговлей» или «1С:Комплексная автоматизация 2».

Никакие рабочие места внутреннего блока МТО при этом не используются. «Умные» заказы на внутреннее потребление передаются из 1С:ТОИР 2 КОРП в одну из систем и там фиксируют потребность в материалах и запчастях. Обеспечение потребностей и оперативный складской учет осуществляются целиком на стороне этих систем. Кроме этого, из 1С:ТОИР 2 КОРП передаются документы «Внутреннее потребление».

В 1С:ТОИР 2 КОРП из 1С:ERP/1С:УТ/1С:КА2 загружаются только актуальные остатки по складам.

Ресурсное планирование и плановая доступность персонала

Еще один полезный новый механизм — ресурсное планирование работ подразделения.

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

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

Плановая доступность персонала

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

В 1С:ТОИР 2 КОРП для установки плановой доступности персонала предназначена обработка «Управление плановой доступностью персонала». Обработка расположена в подсистеме «Управление персоналом». Она помогает заполнить расписание по каждому сотруднику в соответствии с установленным для него графиком работы. Заполнять плановую доступность можно для всех сразу, для нескольких или же для отдельно выбранного сотрудника.

Управление плановой доступностью персонала

В течение месяца может возникнуть ситуация, когда для сотрудника необходимо изменить плановую доступность по различным причинам: больничный, отгул, командировка. Обработка содержит для этого ряд инструментов — можно задать новое состояние сотрудника на день или на определенный период. Помимо ручного заполнения, в будущем мы планируем добавить заполнение плановой доступности из «1С:Зарплата и управление персоналом».

Правильно заполненная плановая доступность используется дальше в механизме ресурсного планирования.

Ресурсное планирование работ подразделения

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

Вся работа происходит в обработке «Ресурсное планирование работ подразделения». Для каждого подразделения в ней виден хронологический список предстоящих ремонтов. Каждый такой ремонт представлен одной или несколькими технологическими картами со списком техопераций. Технологическая операция — это одна элементарная работа с датами начала и окончания и нормой времени. Каждая техоперация требует одного или нескольких сотрудников определенных квалификаций для выполнения. Кстати, квалификации в 1С:ТОИР 2 КОРП указываются для каждого сотрудника.

Ресурсное планирование работ подразделения

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

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

Подсистема мониторинга KPI

В 1С:ТОИР 2 КОРП есть достаточно мощная подсистема мониторинга KPI для быстрого и наглядного просмотра важных показателей, характеризующих работу ремонтной службы. Этот инструмент решает более широкую задачу, чем просто отображение значений на дашборде.

Система состоит из трех больших элементов:

• системы хранения внешних показателей,
• конструктора показателей,
• монитора показателей.

Многие показатели, рекомендуемые консультантами в этой области для расчета, требуют данные, которые не хранятся в 1С:ТОИР 2 КОРП, — например, общие затраты на производство, выручка от продукции, общее количество производственного персонала и даже количество бумажных документов. Часто это данные из бухгалтерской или ERP-системы.

Причем из всех компонентов, нужных для расчета показателя, часть хранится в 1С:ТОИР, а другая часть — нет. В итоге нет одного места, где можно было бы удобно рассчитывать эти KPI.

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

2. Конструктор показателей

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

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

3. Набор универсальных показателей

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

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

Монитор показателей (KPI)

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

Цели автоматизации процессов ТОиР.

• Обеспечить оперативный доступ к техдокументации по оборудованию и ремонтам.
• Обеспечить, чтобы 100% критичного для производства оборудования обслуживалось своевременно.
• Сократить время аварийных (внеплановых) ремонтов основного (критичного) оборудования на ХХ% за YY месяцев.
• Сократить количество аварийных (внеплановых) ремонтов основного (критичного) на ХХ% за YY месяцев.
• Сократить внутренний документооборот ТОиР на бумажных носителях, сократить время согласования документов на ХХ%. Сократить время от регистрации дефекта до выдачи задания непосредственному исполнителю в XX раз.
• Повысить эффективность использования рабочего времени персонала. Снизить простои персонала на ХХ% с получением необходимого качества ремонтов.
• Обеспечить обоснованное планирование затрат на разных уровнях детализации, вплоть до единиц оборудования.
• Снизить складские запасы ТМЦ на XX% с сохранением необходимого качества ремонтов.

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

Вот тут-то нам самим очень помогло наличие нашего инструмента для создания и мониторинга таких показателей!

По результатам этой работы были добавлены 22 новых показателя (всего их стало 29, поставляемых в коробке) и 5 новых отчетов.

Показатели процессов (KPI)

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

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

Функциональные места

А теперь о полезном улучшении в модели данных 1С:ТОИР 2 КОРП, о котором спрашивали многие клиенты на проектах, — функциональные места. Использование иерархии функциональных мест особенно актуально для клиентов с непрерывным циклом производства (химпром, нефтехимия, пищевая промышленность и другие отрасли).

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

Например:

• «5-3 Прием апатитового концентрата» — место приема исходного сырья, на котором установлен бункер для приема и хранения запаса апатитового концентрата);
• «20-2 Подача кислоты» — место для откачки и передачи в химический аппарат фосфорной кислоты, на котором установлены насос для кислоты, трубопровод и аппаратура контроля и измерения.

Экструзионная линия

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

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

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

• идентифицировать места нахождения каждой единицы оборудования в соответствии с технологическим регламентом цеха;
• корректно отображать в системе зависимость производительности оборудования и, как следствие, бизнеса от состояния каждой единицы оборудования. В свою очередь, это позволяет использовать иерархию функциональных мест для корректного автоматического планирования зависимых ремонтов. До этого в 1С:ТОИР был сделан несколько искусственный механизм выстраивания отдельной иерархии зависимого оборудования;
• разделить требования к техпроцессу (указывая характеристики, относящиеся к технологическим параметрам оборудования на функциональных местах) и требования к фактическим параметрам реального оборудования (указывая его параметры для объекта ремонта). В свою очередь, это позволяет реализовать подбор оборудования взамен вышедшего из строя по характеристикам, предсказание отказа оборудования из-за деградации характеристик производительности или мощности до значений ниже, чем требуется для выполнения производственной функции. И это еще одно место, в котором система теперь помогает лучше принимать эффективные решения, показывая информацию, которая необходима для его принятия;
• отражать монтаж/демонтаж единицы оборудования на функциональном месте, что позволяет сохранять в системе историю перемещений оборудования между функциональными местами;
• формировать дерево объектов ремонта в виде, пригодном для передачи в систему «1С:RCM Управление надежностью» для RCM-анализа

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

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

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

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

Общий план работ

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

Анализ коренных причин

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

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

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

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

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

1. Почему редуктор остановился?

• Потому что разрушился подшипник первичного вала.

2. Почему разрушился подшипник?

• Потому что отсутствовала смазка подшипника.

3. Почему подшипник был плохо смазан?

• Потому что насос, подающий смазку, работал на 10% своей производительности (вышел из строя).

4. Почему он вышел из строя?

• Потому что в программу ТОиР оборудования не включена периодическая диагностика насоса.

5. Почему в программе ТОиР нет диагностики насоса?

• Потому что методика определения критичности оборудования содержит ошибки.

Анализ коренных причин

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

Матрица оценки рисков

Еще один важный инструмент в моей подборке — назначение на ремонт с учетом рисков.

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

Чтобы назначение на ремонт было обоснованным, предлагается применить риск-ориентированный подход к обслуживанию оборудования, для чего был реализован инструмент «Матрица оценки рисков». Она служит для определения возможного ущерба (людям, имуществу, окружающей среде, репутации, производству), тяжести и вероятности последствий возможного наступления риска.

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

Матрица оценки рисков

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

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

Обновление интерфейса и кастомизация

Ну и последнее, возможно самое важное и значимое изменение не только для целей повышения культуры принятия решений, а вообще для любых целей, — интерфейс 1С:ТОИР 2 КОРП с новыми иконками.

• Панель разделов слева — с новыми монохромными иконками.
• Новые иконки в иерархии объектов ремонта.
• Новые иконки для специфичных команд в 1С:ТОИР по всем разделам (вы их могли уже заметить на скринах).
• Плюс античная цветовая схема для всех отчетов, чтобы их легче было читать.

1С:ТОИР 2 КОРП всегда был и остается очень гибким инструментом в плане настройки возможностей. Например, есть возможность настраивать используемые документы и их порядок в бизнес-процессе на схеме. Необходимость использования элемента «цепочки» настраивается при помощи интерактивного конструктора. Интерактивный конструктор представлен группой закладок, на которых с помощью включения/отключения связей (или установки соответствующих флажков) определяется необходимость введения и последовательность документов по каждому бизнес-процессу.

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