Задачи обслуживания и ремонта возникли с появлением у человека первых орудий труда. Некоторые историки утверждают, что этой проблемой начали заниматься в средневековой Франции, поскольку слово «ремонт» происходит от французского «remonter». Сейчас трудно сказать, так это или нет, но даже в «Капитале» Маркса [1] данной теме посвящена солидная глава («Развитие машин»), где рассматриваются проблемы износа, старения и необходимости ремонта и восстановления средств труда.
Поскольку в начале своего развития промышленность не располагала данными о надежности деталей, сроках износа механизмов
Современные стандарты [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С и у многих других; есть и такие предприятия, которые разрабатывают систему ТОиР самостоятельно. Корень проблемы видится в самой природе процессов, которые необходимо автоматизировать. И здесь можно выделить несколько важных моментов:
Как преодолеть эти трудности? В одной из предыдущих статей [8] был рассмотрен процессный подход, положенный в основу разработки системы TechnologiCS компании CSoft Development. Суть данного метода заключается в том, что задачи автоматизации представляются в виде набора «кубиков» (процессов), у которых информационные входы одних процессов связаны с информационными выходами других. Чтобы реализовать этот метод на платформе TechnologiCS, пользователю не только дана возможность работать со встроенными данными, но и предоставлен открытый механизм для построения собственных структур. В TechnologiCS такой механизм называется «Наборы данных» и реализуется с помощью специального инструмента «Визуальный построитель запросов». А для того чтобы реализовать собственную методологию (выстроить свои процессы и функции в нужной последовательности) у пользователя есть механизм модификации стандартного и создания собственного интерфейса, называемый «Дизайнер интерфейсов».
Конечно, удобно автоматизировать задачи ТОиР на предприятиях, уже имеющих TechnologiCS, поскольку, как правило, у них имеется база, заполненная актуальными данными, а внедрение представляет собой написание некоторого количества скриптов на языке VBScript и создание интерфейсов для реализации необходимых функций и процессов [9]. Об одном из таких внедрений и пойдет речь в данной статье.
Необходимость решения задачи ТОиР появилась в ходе реального внедрения на предприятии «Магма» (г. Мариуполь, Украина). В качестве инструмента автоматизации была выбрана широко известная система TechnologiCS, обеспечивающая процессный подход к решению подобных задач [8] и позволяющая наращивать функциональность собственными силами, не прибегая к услугам разработчика [9].
На момент начала решения задач ТОиР в системе TechnologiCS предприятия полноценно работали подсистемы конструкторско-технологической подготовки производства и складского учета. Таким образом, в рабочей БД уже были заполненные справочники, необходимые для ТОиР:
В ходе внедрения подсистем ТОиР был заполнен справочник состояний оборудования и актуализирован справочник «Станочный парк». Дополнительно были внесены необходимые параметры для расширения записываемой информации о планируемых состояниях оборудования, а в справочниках складских документов заведены необходимые типы расчетных и учетных документов.
В процессе обследования предприятия выяснилось, что процесс выглядит так, как это показано на рис. 1.
За 5−10 дней до начала нового планового месяца на основании годового плана планово-предупредительных ремонтов, нормативов по техобслуживанию, а также учитывая замечания по работе оборудования от станочников, главный механик предприятия составляет график ТОиР. Далее график согласуется с производственными подразделениями предприятия и утверждается. При необходимости формируются заявки на закупку материалов и комплектующих для ремонта, заявки передаются в службу снабжения.
Утвержденный график ТОиР является основанием для проведения ремонтов и техобслуживания станков ремонтной службой предприятия; по мере выполнения работ в журнале ведется учет трудоемкости выполненного ремонта. По окончании ремонта (техобслуживания) формируется акт сдачи-приемки оборудования в эксплуатацию, который подписывается представителями ремонтной службы и представителями подразделения-владельца оборудования.
По окончании планового месяца на основании графика ТОиР формируется отчет с информацией о фактическом виде и трудоемкости выполненного ремонта (техобслуживания).
Весь необходимый функционал для планирования работ по планово-предупредительным ремонтам уже есть в самой системе TechnologiCS, но, по мнению заказчика, часть функций была либо слишком проста, либо неудобна для внесения информации.
Штатный функционал для ввода информации о факте выполнения работ довольно прост и не позволяет вносить информацию о трудозатратах на ремонтные работы, поэтому было принято решение разработать на TechnologiCS API программный модуль, позволяющий вести учет выполнения ремонтных работ по работникам с помощью штатного функционала для оформления фактического выполнения в производственной подсистеме. Для этого программный модуль дополнительно к созданию записей о состояниях станков создает производственные спецификации и связывает их между собой посредством параметров. Такая связь позволила в дальнейшем получить наборы данных для построения отчетов о выполненных работах. Кроме того, программа формирует упрощенный техпроцесс для выполнения ремонта, если таковой не был заведен в номенклатурном справочнике «Оборудование».
Для удобства пользователей были разработаны формы ввода, упрощающие ввод данных в части работы с заявками на материально-техническое снабжение ремонтов и учета выполненных ремонтных работ работниками службы главного механика предприятия.
Интерфейсные решения, реализующие необходимый для пользователя функционал, вызываются из одного режима — справочника «Станочный парк».
Первый этап работы — составление плана работ и, если необходимо, формирование заявок на материальное обеспечение ремонтных работ.
Работа с подсистемой начинается запуском макроса График ППР из модуля «Станочный парк» (рис. 2). В основную таблицу формы собирается информация из запланированных состояний и фактической сдачи производственной спецификации для ТОиР за выбранный месяц.
Командой Добавить пользователь вызывает форму добавления состояния серийного номера (рис. 3). Порядок заполнения данных следующий: из справочника «Станочный парк» пользователь выбирает необходимый станок, из раскрывающегося списка — вид планируемого ремонта (обслуживания). Далее он вносит планируемое время начала и окончания работ, заполняет планируемые показатели трудоемкости:
При необходимости вносятся указания по предварительным работам и перечень работ, которые необходимо выполнить во время ремонта.
Дополнительно есть возможность внести информацию о замечаниях по работе станка от станочника (заявителя). Историю замечаний по выбранному станку можно просмотреть на отдельной вкладке (рис. 4).
Штатный функционал TechnologiCS позволяет связывать запланированное состояние с существующим расчетным документом. Для удобства пользователя функционал по работе с расчетным документом был вынесен на отдельную вкладку (рис. 5). При этом у пользователя есть возможность при заполнении спецификации кроме обычного попозиционного добавления записей заимствовать записи из ранее сформированных заявок.
Чтобы сделать удобным получение информации о заявках на материалы и комплектующие для обслуживания станочного парка была разработана форма «Журнал заявок» (рис. 6), которая вызывается одноименным макросом из режима «Станочный парк».
Второй этап — оформление фактически выполненных работ и передача оборудования в эксплуатацию. Внесение этой информации осуществляется из ранее описанной формы «График ППР» командой Редактировать. При редактировании запланированного состояния оборудования в диалоговом окне становится доступной вкладка Фактические работы. Здесь пользователь вводит вид фактически выполненного ремонта, время начала и окончания ремонта, вид выполненных работ и имена их исполнителей. В реальных условиях фактический вид ремонта может отличаться от запланированного — например, по результатам осмотра или дефектации станка.
Для удобства пользователя период фактического выполнения работ можно позаимствовать из запланированного либо, при наличии записей о выполнении работ, — из фактической сдачи. Фактические показатели трудоемкости ремонта вычисляются программой на основании данных о выполненных ремонтных работах (рис. 7).
На форме добавления ремонтных работ (рис. 8) пользователь заполняет поля с данными о начале и окончании работы, с результатами работ и добавляет исполнителей. Трудоемкость работ программа вычисляет автоматически.
По завершении работ формируется «Акт сдачи-приемки оборудования в эксплуатацию после ремонта» (рис. 9). Бланк акта берется из шаблонов файлов БД TechnologiCS, заполняется информацией о станке и добавляется в файловый состав документов вида «Акт». Далее сформированный документ связывается с серийным номером оборудования. В дальнейшем из формы редактирования состояния пользователь может открыть файл документа на редактирование и внести необходимые сведения.
Аналогичным образом ведется работа с журналом проверок на технологическую точность (ПТТ). Отличие работы с журналом ПТТ состоит в следующем:
Другой аспект работы, идущий параллельно с планированием работ по ТОиР, — обеспечение работ материалами, комплектующими и инструментами для выполнения ремонтов и обслуживания оборудования. Все заявки обрабатываются отделом материально-технического снабжения в специальном режиме ведения рабочих дефицитных ведомостей (рис. 10).
В процессе обработки заявки вносятся все необходимые данные (рис. 11).
Далее, при поступлении позиций заявки на склад, документы обрабатываются специализированным складским модулем (рис. 12).
В ходе внедрения было принято решение совместить «График ТОиР» и «Отчет по ТОиР» в единой форме бланка (рис. 13) и формировать его дважды: в первый раз — на этапе формирования плана работ, во второй — по завершении выполнения работ. Кроме того, отчет пришлось формировать программным путем, непосредственной записью данных в файл с помощью API Excel.
Бланк отчета «Журнал выполнения ремонтных работ» (рис. 14) разработан с помощью штатной системы отчетов TechnologiCS, а исходным модулем при получении сведений для отчета был набор данных, разработанный с помощью «Визуального построителя запросов».
В итоге была разработана и внедрена понятная, эффективная и гибко настраиваемая подсистема ТОиР, которую сам пользователь может настроить для нужд своего предприятия, так как все необходимые настройки находятся в открытом коде. Такой подход дает системе неоспоримые преимущества по отношению к имеющимся на рынке системам: