Эффективная реализация подсистемы ТОиР в TechnologiCS 7.1

Дмитрий Гамий, Алёна Краснощёка, Андрей Курочкин, Андрей Синельников

Что мы подразумеваем под термином ТОиР

Задачи обслуживания и ремонта возникли с появлением у человека первых орудий труда. Некоторые историки утверждают, что этой проблемой начали заниматься в средневековой Франции, поскольку слово «ремонт» происходит от французского «remonter». Сейчас трудно сказать, так это или нет, но даже в «Капитале» Маркса [1] данной теме посвящена солидная глава («Развитие машин»), где рассматриваются проблемы износа, старения и необходимости ремонта и восстановления средств труда.

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

Современные стандарты [3, 4, 5]
определяют систему техничес­кого обслуживания и ремонта техники (ТОиР) как «совокупность взаимосвязанных средств, документации технического обслуживания и ремонта и исполнителей, необходимых для поддержания и восстановления качества изделий, входящих в эту систему». Определение, прямо скажем, не очень понятное, но, тем не менее, в данных стандартах четко зафиксированы термины и определения, а также выделены основные задачи информационного и материально­технического обеспечения обслуживания и ремонта. Так, например, в [5] сказано, что информационное обеспечение предназначено для:

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

На этапе эксплуатации изделия необходимо решать следующие задачи материально­технического обеспечения (МТО):

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

В свою очередь, с появлением стандартов ИСО задачи ТОиР были отражены в этапах жизненного цикла изделий ([6], раздел 5.1.1, п. 10 «Техническая помощь и обслуживание», п. 11 «Послепродажная деятельность») и стали неотъемлемой частью общей системы PLM предприятия.

В зарубежных источниках эти задачи обычно относят к одному из разделов MES­системы (от англ. Manufacturing Execution System, система управления производственными процессами), который принято обозначать как EAM (от англ. Enterprise Asset Management, управление техническим обслуживанием и ремонтами). ЕАМ­системы [7] позволяют согласованно управлять следующими процессами:

• техническое обслуживание и ремонт;
• материально­техническое снаб­жение;
• управление складскими запасами (запчасти для техничес­кого обслуживания);
• управление финансами, качеством и трудовыми ресурсами в части технического обслуживания, ремонтов и материально­технического обеспечения.

Особенности внедрения

Теперь, когда все определено, казалось бы, ничто не мешает написать современное программное обеспечение и внедрять его, но… как только разработчик приступает к решению этих задач, он тут же понимает, что во всех современных основополагающих документах подробно сказано, как должна функционировать система ТОиР, и ни слова не говорится, что для этого нужно делать. Мало того, на рынке уже существует огромное количество систем ТОиР, как правило, ориентированных на конкретные отрасли, а зачастую и просто написанных под конкретное предприятие. Откуда такое разнообразие? Ведь подобные решения есть и у крупных зарубежных разработчиков, таких как SAP (модуль в системе SAP ERP), Oracle (Oracle EAM); есть они и у отечественных НПП «СпецТек», «Галактика», «1С» и у многих других; есть и такие предприятия, которые разрабатывают систему ТОиР самостоятельно. Корень проблемы видится в самой природе процессов, которые необходимо автоматизировать. И здесь можно выделить несколько важных моментов:

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

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

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

Как преодолеть эти трудности? В одной из предыдущих статей [8] был рассмотрен процессный подход, положенный в основу разработки системы TechnologiCS компании CSoft Development. Суть данного метода заключается в том, что задачи автоматизации представляются в виде набора «кубиков» (процессов), у которых информационные входы одних процессов связаны с информационными выходами других. Чтобы реализовать этот метод на платформе TechnologiCS, пользователю не только дана возможность работать со встроенными данными, но и предоставлен открытый механизм для построения собственных структур. В TechnologiCS такой механизм называется «Наборы данных» и реализуется с помощью специального инструмента «Визуальный построитель запросов». А для того чтобы реализовать собственную методологию (выстроить свои процессы и функции в нужной последовательности), у пользователя есть механизм модификации стандартного и создания собственного интерфейса, называемый «Дизайнер интерфейсов».

Конечно, удобно автоматизировать задачи ТОиР на предприятиях, уже имеющих TechnologiCS, поскольку, как правило, у них имеется база, заполненная актуальными данными, а внедрение представляет собой написание некоторого количества скриптов на языке VBScript и создание интерфейсов для реализации необходимых функций и процессов [9]. Об одном из таких внедрений и пойдет речь в данной статье.

Как это было сделано

Необходимость решения задачи ТОиР появилась в ходе реального внедрения на предприятии «Магма» (г.Мариуполь, Украина). В качестве инструмента автоматизации была выбрана широко известная система TechnologiCS, обеспечивающая процессный подход к решению подобных задач [8] и позволяющая наращивать функциональность собственными силами, не прибегая к услугам разработчика [9].

На момент начала решения задач ТОиР в системе TechnologiCS предприятия полноценно работали подсистемы конструкторско­технологической подготовки производства и складского учета. Таким образом, в рабочей БД уже были заполненные справочники, необходимые для ТОиР:

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

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

В процессе обследования предприятия выяснилось, что процесс выглядит так, как это показано на рис. 1.

Рис. 1. Схема процесса

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

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

По окончании планового месяца на основании графика ТОиР формируется отчет с информацией о фактическом виде и трудоемкости выполненного ремонта (техобслуживания).

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

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

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

Как это работает

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

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

Работа с подсистемой начинается запуском макроса График ППР из модуля «Станочный парк» (рис. 2). В основную таб­лицу формы собирается информация из запланированных состояний и фактической сдачи производственной спецификации для ТОиР за выбранный месяц.

Рис. 2. Вид формы График ППР

Рис. 3. Форма добавления планируемой работы
по обслуживанию станка

Командой Добавить пользователь вызывает форму добавления состояния серийного номера (рис. 3). Порядок заполнения данных следующий: из справочника «Станочный парк» пользователь выбирает необходимый станок, из раскрывающегося списка — вид планируемого ремонта (обслуживания). Далее он вносит планируемое время начала и окончания работ, заполняет планируемые показатели трудоемкости:

• продолжительность простоя оборудования;
• продолжительность ремонтных работ;
• трудоемкость работ.

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

Дополнительно есть возможность внести информацию о замечаниях по работе станка от станочника (заявителя). Историю замечаний по выбранному станку можно просмотреть на отдельной вкладке (рис. 4).

Рис. 4. Вкладка История замечаний

Штатный функционал TechnologiCS позволяет связывать запланированное состояние с существующим расчетным документом. Для удобства пользователя функционал по работе с расчетным документом был вынесен на отдельную вкладку (рис. 5). При этом у пользователя есть возможность при заполнении спецификации кроме обычного попозиционного добавления записей заимствовать записи из ранее сформированных заявок.

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

Рис. 5. Пример работы с заявкой на материалы
и комплектующие для ремонта

Рис. 6. Вид формы Журнал заявок

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

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

Рис. 7. Пример заполнения данных о выполненных ремонтных работах

На форме добавления ремонтных работ (рис. 8) пользователь заполняет поля с данными о начале и окончании работы, с результатами работ и добавляет исполнителей. Трудоемкость работ программа вычисляет автоматически.

Рис. 8. Форма добавления выполненной работы

Рис. 9. Образец сформированного акта

По завершении работ формируется «Акт сдачи­приемки оборудования в эксплуатацию после ремонта» (рис. 9). Бланк акта берется из шаблонов файлов БД TechnologiCS, заполняется информацией о станке и добавляется в файловый состав документов вида «Акт». Далее сформированный документ связывается с серийным номером оборудования. В дальнейшем из формы редактирования состояния пользователь может открыть файл документа на редактирование и внести необходимые сведения.

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

• плановое и фактическое состояние оборудования совпадают;
• не требуется закупка материалов и комплектующих;
• используется другая форма бланка: «Акт проверки оборудования на технологическую точность».

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

Рис. 10. Построение динамической дефицитной ведомости по заявкам

Рис. 11. Обработка заявки

Рис. 12. Пример складского модуля

В процессе обработки заявки вносятся все необходимые данные (рис. 11).

Далее, при поступлении позиций заявки на склад, документы обрабатываются специализированным складским модулем (рис. 12).

В ходе внедрения было принято решение совместить «График ТОиР» и «Отчет по ТОиР» в единой форме бланка (рис. 13) и формировать его дважды: в первый раз — на этапе составления плана работ, во второй — по завершении выполнения работ. Кроме того, отчет пришлось формировать программным путем, непосредственной записью данных в файл с помощью API Excel.

Бланк отчета «Журнал выполнения ремонтных работ» (рис. 14) разработан с помощью штатной системы отчетов TechnologiCS, а исходным модулем при получении сведений для отчета был набор данных, разработанный с помощью «Визуального построителя запросов».

Рис. 13. Пример отчета «График ТОиР»

Рис. 14. Пример отчета «Журнал учета выполнения ремонтных работ»

Что в итоге

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

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

Литература

1. Маркс К. Капитал. Критика политической экономии. Т. 1. Кн. 1: Процесс производства капитала. Пер. И.И. Степанова­Скворцова. М.: Политиздат, 1967. 908 с.
2. Афанасьев Н.А., Юсипов М.А. Система технического обслуживания и ремонта оборудования энергохозяйств промышленных предприятий (система ТОР ЭО). — Москва, Энергоатомиздат. 1989.
3. ГОСТ 18322­78. Система технического обслуживания и ремонта техники. Термины и определения.
4. ГОСТ 28470­90 Система технического обслуживания и ремонта технических средств вычислительной техники и информатики. Виды и методы технического обслуживания. ГОСТ 15.601­98 Техническое обслуживание и ремонт техники.
5. ИСО 9004­1­94 Управление качеством и элементы системы качества. Часть 1. Руководящие указания.
6. https://ru.wikipedia.org/wiki/Enterprise_asset_management
7. Андрей Синельников. Techno­logiCS 6 — процессный подход к разработке и внедрению. САПР и графика. 2011. № 5. С. 36­40.
8. Евгений Слинкин. Techno­logiCS 6 — разработка новой функциональности собственными силами. САПР и графика. 2011. № 11.
   С. 24­32.

САПР и графика 11`2016