«ТОРО» — — все сокращения России!

3.1. Иерархическая структура данных об объектах ТОРО – информационная основа системы

Построение рациональной иерархической структуры технических объектов ТОРО – не тривиальная задача. В принципе, сама по себе система SAP ERP не накладывает каких-либо ограничений на число уровней иерархии, но здесь нельзя переусердствовать. При построении структуры объектов нужно, прежде всего, исходить  из принципа «разумной достаточности».

На нижних уровнях иерархии следует создавать только те объекты, которые и являются и объектами технического обслуживания и ремонта и объектами отнесения затрат (Рис 9). Чрезмерная детализация структуры и попытки воспроизвести конструкторские чертежные  спецификации с помощью системы кодирования объектов типа «Техническое место» не имеют никакого экономического смысла.

Рис. 9

Зачастую чрезмерная детализация структур объясняется заказчиками необходимостью облегчения поиска объекта, но достичь максимальной скорости и удобства поиска объектов можно и другими средствами, предоставляемыми в SAP ERP. Те же подходы применимы и к построению справочника (реестра) единиц оборудования.

Рис. 10

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

Далее будет показано, каким образом следует оптимально структурировать объекты до уровня запасных частей и комплектующих изделий с помощью системы узловых спецификаций. В данном конкретном случае такое структурирование объекта  оправдано и дает значительные преимущества при организации процесса учета наличия и перемещений УЭЦН.

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

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

Рис. 11

Что такое sap торо в системе sap erp?

• Что, когда и как ремонтировалось? Когда и как выполнялось ТО оборудования?
• Какие основные виды и причины дефектов оборудования? Сколько стоит устранение вновь возникающих/повторяющихся дефектов оборудования?
• Каков перспективный план ремонтов/ТО оборудования? Сколько это будет стоить?
• Каково время простоев оборудования в результате ремонтов? Сколько стоят внеплановые остановы оборудования (штрафы, санкции)?
• Сколько рабочего времени потрачено на ремонт/ТО оборудования?
• И т.д. . .

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

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

Итак, что мы сделали. Я начала с непланового ТОРО, с журнала дефектов, и что в нем содержится. Я видела в другой энергокомпании решение журнала дефектов тоже на базе SAP, но у них журнал дефектов, я бы сказала, «мертвый»: он просто ведется, но если надо вытащить какую-то информацию, нужно смотреть в другие модули.

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

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

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

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

Заказ ТОРО — это документ, который разрешает нам выполнять ремонтные мероприятия, в том числе и получение материалов со склада, потому что с 2022 года ни один материал ремонтники не могут получить без заказа ТОРО. Это очень не нравилось кладовщикам, потому что были там то возвраты, то еще что-то, не могли 10 м трубы так вот точно отрезать.

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

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

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

И вот этот заказ ТОРО является основным документом, уже из него и в бухгалтерию, и в финансы, и в HR уходит информация. Через заказы согласовываются человеко-часы или подрядные работы. Также в заказе ТОРО у нас отображается номер договора с контрагентом, и мы можем отчет получить, сколько уже оплачено по договору, какие мероприятия были проделаны.

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

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

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

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

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

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

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

Также для общестанционного оборудования простой график, для РЗА отдельно.

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

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

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

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

Для классификации оборудования в БДО мы используем справочник KKS — кодированное наименование оборудования, систем, задача только правильно выбрать код из классификатора. KKS-код — немецкий классификатор, который имеет в своем составе все основное оборудование, которое применяется в энергетике.

«карельский окатыш» запустил проект «мобильное торо» |
карельский окатыш

2.   Взаимодействие со смежными бизнес-процессами

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

Рис. 2

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

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

2 специально показано, что между модулем ТОРО и модулем FI нет прямой связи. Для решения задач бухгалтерского учета не требуется детальная аналитика затрат по видам оборудования или по исполнителям мероприятий ТОРО. Анализ себестоимости продукции, расчеты амортизационных отчислений, расчеты с поставщиками услуг ТОРО, расчеты налоговых обязательств и др. расчеты могут быть осуществлены без привлечения данных, извлекаемых из системы управления ТОРО. Для этих целей вполне достаточно данных, поставляемых модулем MM.

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

Из всех представленных на рынке ИТ программных продуктов SAP ERP обладает наилучшими возможностями для интеграции всех бизнес-процессов управления большими корпорациями в единую систему управления, основной целью которой является повышение эффективности компании.

3.4. Система классификации   объектов в ТОРО

Система классификации в рамках системы SAP ERP – универсальный инструмент наделения любых объектов дополнительными характеристиками, обладающими свойством наследования. Система классификации строится как многоуровневая иерархическая структура, у которой каждый нижестоящий уровень наследует свойства (характеристики) вышестоящего.

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

Основная запись в реестре (справочнике) технических мест или реестре (справочнике) единиц оборудования обладает фиксированным и единым для всех набором полей для описания свойств и характеристик объекта. Использование системы классификации позволяет практически неограниченно расширить набор данных об объекте.

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

Рис. 15

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

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

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

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

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

Для автоматического образования имени объекта используются наименования класса и некоторые значения его технических характеристик. Пример такого способа наименования единиц оборудования описан в разделе «Оперативный учет ГНО». При этом первоначальное, неформализованное наименование, введенное при первичном наполнении базы данных, будет автоматически приводиться к унифицированному виду при любых изменения и сохранении основной записи об объекте.

Пример построения классификатора для единиц оборудования, характерный для нефтедобывающего предприятия:

Рис. 16

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