2 - 2007

Опыт создания автоматизированной системы управления учетом отказов

Александр Колчин, Сергей Сумароков, Тембулат Жабоев

Цели и задачи

Описание системы

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

Организация работ по внедрению

Текущая ситуация и перспективы проекта

Ожидаемые организационно-экономические результаты

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

Одним из первых приборостроительных предприятий авиационной отрасли, поставившим перед собой задачу реализации автоматизированного учета отказов собственных и покупных изделий, является ОАО «Раменский приборостроительный завод» (г.Раменское Московской обл.), выпускающий навигационные приборы для авиации, устройства отображения информации, параметрические приборы и другую наукоемкую продукцию. В качестве исполнителя была привлечена компания «Корпоративные электронные системы» («КЭЛС-центр»). Сотрудничество завода с компанией «КЭЛС-центр» в области внедрения перспективных технологий поддержки жизненного цикла продукции началось в 2001 году, когда был запущен проект по внедрению автоматизированной системы подготовки технологической документации (АСУ ТД) на основе продукта компании «Лоция Софт» — LotsiaPDM Plus. Именно на базе уже внедренной системы было принято решение реализовать задачу учета отказов.

ОАО «РПЗ» (www.rpz.ru) работает в области авиационного приборостроения с 1939 года и в настоящее время является лидером в отрасли инерциальных навигационных систем, пилотажно-навигационных индикаторов и систем траекторного управления. Располагая современным технологическим оборудованием и производственными помещениями для изготовления деталей, сборки и испытания приборов по всему технологическому циклу, завод способен в короткие сроки организовать серийное производство новой продукции высокого качества.

ООО «КЭЛС-центр» (www.calscenter.com) занимается комплексным внедрением на промышленных предприятиях CALS-технологий (автоматизированных систем управления конструкторско-технологическим документооборотом, компьютерных систем менеджмента качества продукции, автоматизированных систем интегрированной логистической поддержки, интерактивных электронных технических руководств), а также проводит курсы переподготовки и повышения квалификации специалистов в области CALS-технологий.

«Лоция Софт» (www.lotsia.com) является ведущим российским разработчиком систем автоматизации технического документооборота, PDM/PLM и управления предприятием. Основные ее разработки: интегрированная система PDM/TDM/Workflow Lotsia PDM PLUS (PartY PLUS), система управления предприятием Lotsia ERP, комплексное решение по поддержке жизненного цикла продукции Lotsia PLM.

Цели и задачи

Среди основных целей создания АСУ УО стоит выделить:

• повышение эффективности процессов работы с данными об отказах и дефектах продукции ОАО «РПЗ» и покупных комплектующих изделий к ней, включая классификацию отказов и дефектов;

• обеспечение прослеживаемости истории отказов и дефектов каждого экземпляра изделий ОАО «РПЗ» и покупных комплектующих изделий в течение периода их эксплуатации;

• накопление и систематизация статистических данных по качеству выпускаемой продукции ОАО «РПЗ»;

• обеспечение руководства ОАО «РПЗ» всех уровней оперативной информацией об отказах и дефектах изделий и комплектующих, в том числе покупных, в рамках процессов:

- учета и анализа отказов изделий ОАО «РПЗ» у потребителя,

- учета и анализа отказов изделий на всех стадиях производства,

- учета и анализа отказов покупных комплектующих изделий.

Построение системы условно подразделяется на два этапа:

• создание электронного архива (ЭА) информации по отказам (включая реализацию статистических отчетов);

• автоматизация управления потоками работ по учету и анализу отказов.

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

В начало В начало

Описание системы

Общий вид схемы обработки отказа представлен на рис. 1. Выделены участники процесса и данные, с которыми они имеют дело (в общем виде).

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

Рис. 1. Организация обработки отказов и решение смежных задач

Рис. 1. Организация обработки отказов и решение смежных задач

Как было указано, созданию системы учета отказов предшествовала работа по внедрению системы управления технологическим документооборотом. И теперь можно утверждать, что последняя послужила неплохим фундаментом для реализации задач по учету отказов. Конечно, точек пересечения у этих двух систем не так много и они не очевидны, но, тем не менее, они есть. Во-первых, обе задачи основаны на составе изделия, который является базисом для данных систем. А во-вторых, АСУ ТД может быть потребителем информации из системы учета отказов, в частности может получать данные об отказах в производстве (изделие, номер операции сборки, переход и др.) для отработки технологического процесса. Общность двух систем по составу изделия показана на рис. 2.

Рис. 2. Фрагменты информационных моделей систем

Рис. 2. Фрагменты информационных моделей систем

Поскольку на заводе долгие годы существует и развивается АСУП собственной разработки, то, конечно же, необходимым условием успешного внедрения системы управления учетом отказов являлась интеграция систем для создания единого информационного пространства — основной концепции CALS-технологий. Состав передаваемых данных между ЭА и БД АСУП показан на рис. 3.

Рис. 3. Интеграция электронного архива с БД АСУП

Рис. 3. Интеграция электронного архива с БД АСУП

В начало В начало

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

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

Создание ЭА потребовало решения следующих задач:

• ведение истории по отказавшим экземплярам;

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

• генерация отчетов на основе архивной информации;

• обмен данными между ЭА и АСУП ОАО «РПЗ».

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

Рис. 4. Фрагмент информационной модели системы

Рис. 4. Фрагмент информационной модели системы

Данные в системе распределены по информационным сущностям (в соответствии с информационной моделью) и представлены в виде дерева, в корне которого находится блок «Изделие» (рис. 4). В качестве изделия выступают элементы конструкторского состава: сборочные единицы, детали, покупные элементы и пр. К данному блоку снизу прикрепляются отказавшие « экземпляры», к которым, в свою очередь, крепится блок «Событие отказа» — факты отказов, со всеми сопутствующими характеристиками. Экранные формы состава изделия и дерева отказов отображены на рис. 5.

Рис. 5. Состав изделия и дерево отказа

Рис. 5. Состав изделия и дерево отказа

«Событие отказа» имеет связи с блоками «Мероприятие», «Документ» и «Виновник». В качестве виновников отказа могут назначаться подразделения завода, выпускающие изделие или ответственные за приемку изделия или его компонентов. Виновники отказа не выделены в отдельную сущность, а реализуются посредством задания специальной связи между объектом «Событие отказа» и элементами справочника «Контрагенты» и/или «Оргструктура» (рис. 6).

Рис. 6. Справочники

Рис. 6. Справочники

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

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

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

 

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

 

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

 

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

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

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

Уважаемые коллеги!

Сообщаем вам, что компания «Лоция Софт» с 5 февраля 2007 года начинает работу в новом офисе, расположенном в бизнес-центре «Серпуховской двор».

Адрес: 115419 Москва, 2-й Рощинский проезд, д. 8, стр. 1.

Ближайшие станции метро: «Шаболовская», «Ленинский проспект», «Тульская».

Телефоны компании остались прежними: (495) 74-804-74, 74-803-74.

Мы рады видеть вас в нашем офисе в бизнес-центре «Серпухов­ской двор»!

В начало В начало

Организация работ по внедрению

На начальном этапе проекта была сформирована рабочая группа, в которую вошли представители РПЗ и «КЭЛС-центра». В частности, со стороны завода были привлечены руководители и специалисты отдела главного конструктора (ОГК), отдела главного технолога (ОГТ), эксплуатационно-ремонтного отдела (ЭРО), отдела технического контроля (ОТК), отдела надежности (ОН), лаборатории входного контроля (ЛВК) и различных служб цехов. От каждой стороны был назначен руководитель проекта. Координацию проекта взял под личный контроль главный инженер завода. Ответственным за внедрение проекта со стороны заказчика был назначен заместитель директора по качеству.

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

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

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

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

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

Вся основная работа по адаптации Lotsia PDM Plus к требованиям проекта ведется на следующем этапе — настройке системы. Информационная модель отражается в терминах PDM-системы. Также настраиваются процедуры работы пользователей с информацией, помещаемой в ЭА. Отчеты, шаблоны документов, интеграция с офисными пакетами, другие прикладные настройки — все это выполняется на данном этапе.

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

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

В начало В начало

Текущая ситуация и перспективы проекта

В настоящее время значительная часть пути уже пройдена. Электронный архив запущен в эксплуатацию. Практически завершены настройки Lotsia PDM Plus по управлению процессами обработки отказа на местах — осталось внести последние коррективы. На данный момент завершена опытная эксплуатация одного из потоков работ — обработка отказа гарантийного изделия в эксплуатации.

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

В начало В начало

Ожидаемые организационно-экономические результаты

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

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

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

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

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

Совокупный результат от вышеперечисленных достижений — ожидаемое сокращение сроков обработки отказа.

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

В начало В начало

САПР и графика 2`2007