Решение задач электронной паспортизации имущества и ППР с помощью систем PartY и PartY PLUS
В предыдущих статьях мы рассказывали об использовании PartY и PartY PLUS в качестве систем PDM и электронного архива технической документации. Но возможности PartY и PartY PLUS не ограничиваются только этой сферой применения.
Системы PartY и PartY PLUS позволяют также автоматизировать учет имущества (оборудования), для чего необходимо решить такие задачи, как учет наличия и местонахождения имущества, учет его состояния и истории ремонтов и перемещений в течение всего жизненного цикла, а также ведение планов-графиков ремонтных работ, то есть задачи, описываемые как Asset Information Management.
Модель данных управления имуществом предприятия может быть представлена в виде иерархического дерева мест установки единиц имущества (рис. 1). Это может быть, например, структуризация здания на этажи, помещения и более мелкие единицы. Таким же образом можно провести структурирование завода на заводоуправление, цеха и рабочие места. Примеров подобной структуризации можно привести достаточно много. Объекты системы PartY, представляющие собой единицы имущества, включаются в древовидную структуру согласно местам установки (нахождения).
Аналогично может быть представлена информация об оборудовании, например по технологическому принципу.
Несколько более сложными на первый взгляд представляются задачи учета движения имущества. Под движением в данном контексте понимается изменение состояния единицы имущества (оборудования), ведение истории эксплуатации, ремонтов и перемещений в течение всего жизненного цикла. Пытаясь решить подобные задачи что называется «в лоб», пользователь сталкивается с такой проблемой, как потеря истории жизненного цикла имущества. Под решением задачи «в лоб» понимается обычное перемещение объектов учета с одного места в дереве модели имущества предприятия на другое.
Что при этом происходит? Пользователь устанавливает связь объекта с новым местом его установки. При этом следует разорвать связь со старым местом установки, иначе у данного объекта окажется два места установки.
Кроме того, как уже упоминалось выше, остается проблема потери истории жизненного цикла имущества, и если ее не решить, то никто никогда не узнает истории перемещения объекта с места на место, дат и причин такого перемещения. То же самое относится к задаче учета ремонтов оборудования. Да, можно перемещать оборудование, но получить аналитическую информацию по истории ремонта конкретной единицы имущества не представляется возможным.
Системы PartY и PartY PLUS позволяют получить универсальное решение вышеозначенной задачи учета движения имущества. Оно заключается в создании объектов с набором атрибутов, хранящих данные по конкретному движению объекта. При этом становится возможным учитывать как само движение имущества, так и его причины. Перечень этих атрибутов может быть расширен, но об этом мы расскажем ниже. Атрибуты, характеризующие движение, формируют отдельную группу с соответствующим названием, что облегчает поиск информации по этим критериям.
Далее, для того чтобы знать, для какого объекта учитывается движение (или, другими словами, какие движения соответствуют данному объекту), устанавливается однозначная связь между экземплярами объектов и информацией о его перемещениях.
Системы PartY и PartY PLUS позволяют реализовать это путем создания отдельной направленной связи. И наконец, для того чтобы все объекты типа «Движение» хранились в одном месте, формируется объект, хранящий в себе все ссылки на информацию о движении имущества.
Теперь в окне проекта на вкладке «Связанные» можно увидеть перечень объектов типа «Движение» (рис. 2). Настроив вид окна этой вкладки, можно видеть и атрибуты «Дата движения» и «Причина движения».
Теперь у пользователей системы имеется возможность получать всю информацию по движению имущества с помощью встроенных и пользовательских отчетов (рис. 3). Характер получаемой информации может быть практически любой: откуда и куда перемещался объект, когда и по какой причине.
Однако приведенная последовательность действий по учету движения может оказаться не очень привлекательной для пользователя, в первую очередь в силу своей трудоемкости.
Системы PartY и PartY PLUS предлагают удачный выход из этой ситуации. Это — редактор шаблонов операций (действий пользователя). Являясь мощным инструментом администратора системы, он позволяет автоматизировать последовательность определенных действий пользователя и сохранять их как операции.
Работа пользователя в таком случае сводится лишь к запуску операции путем выбора соответствующего пункта меню и к вводу данных (значений атрибутов) в поля формы (рис. 4).
Все остальные действия: создание объекта типа «Движение», установление связей, разрыв связей — производятся автоматически. Отметим, что система все же требует от пользователя подтверждения выбора объекта, с которым следует разорвать связь. Это является необходимым условием для блокировки ошибочных действий пользователя.
Если найденный объект — один, то никаких действий от пользователя не требуется. Однако если объектов несколько, то пользователю будет предложен список найденных объектов, из которых он должен будет выбрать один.
Рассмотренный нами вариант решения задачи учета имущества и его движения предполагает, что для учета каждого движения объекта создается новый объект типа «Движение». Это абсолютно логично в случаях обычного перемещения объектов с места на место. Но ведь существуют такие задачи, как учет ремонтов оборудования, где возникает другой аспект рассматриваемой задачи. Логичнее было бы на передачу объекта в ремонт и на возврат из ремонта иметь один объект типа «Движение» с набором атрибутов, полностью характеризующим данную операцию. Для этого следует создать дополнительные атрибуты нужного содержания, например «Дата возврата», «Содержание ремонта» и «Текущее состояние».
Естественно, в таком случае добавится еще одна операция по возврату объекта из ремонта. Для пользователя это означает лишь то, что при возврате из ремонта единицы имущества необходимо будет выбрать из списка соответствующую операцию. Здесь придется потрудиться только администратору, настраивая шаблон операции, но такая настройка не займет много времени. Добавим, что несколько изменятся действия при постановке оборудования в ремонт (рис. 5). Изменение коснется лишь добавления атрибута «Текущее состояние».
Аналогичным образом система позволяет автоматизировать процедуры возврата оборудования из ремонта и пр.
Генератор отчетов системы PartY позволяет настроить отчет, показывающий движение имущества в ремонт и из ремонта для анализа причин и частоты ремонта, межремонтных периодов, видов наиболее часто ремонтируемого оборудования. Имеется возможность проследить и маршрут объекта, если после ремонта его место установки изменилось.
Настройка редактора операций позволяет заполнять значения атрибутов «Прежнее место установки» и «Новое место установки» автоматически. При этом значительно упрощается настройка отчетов по движению объектов.
Учет планов-графиков ППР — задача, аналогичная учету движения. Возможно построение графиков на произвольные временные интервалы: год, квартал, месяц...
Если для оборудования характерны разные виды ремонтов (ТО, ТР, КР), то ведение объектов соответствующих типов (ТО, ТР и КР) позволяет анализировать информацию раздельно по видам ремонтов (рис. 6). Формирование плана-графика сводится к установлению связи между единицами имущества и объектами видов ремонтов соответствующего месяца.
Установка связи реализуется через редактор операций или производится вручную, что тоже несложно. Генератор отчетов позволяет создать форму, содержащую данные о плановых датах ремонта оборудования (рис. 7).
На этом мы завершаем краткий обзор возможностей систем PartY и PartY PLUS по управлению информацией об имуществе и оборудованию.
Прикладные системы на основе PartY и PartY PLUS, в которых реализован описанный в статье функционал, успешно работают на предприятиях нефтегазовой и других отраслей, а также в банках.
Принципы использования вспомогательных связей между объектами легли также в основу системы учета ресурсов, которая помимо задачи учета имущества позволяет вести учет трудовых ресурсов, отпусков и т.п. Но это уже тема отдельной статьи.
«САПР и графика» 11'2001
