Инфраструктура и производственная среда

информационные технологии
Александр Анатолиевич Брилёнок
заместитель директора по качеству
ООО «Хьюмен систем»
(Минск, Республика Беларусь)
Инфраструктура и производственная
среда
Ключевые слова: автоматизация управления инфраструктурой и рабочей средой, принцип постоянного контроля
параметров, программы планового технического обслуживания.
автоматизация смк
В очередной статье цикла, посвященного комплексной
автоматизации системы менеджмента качества (СМК)
рассмотрены общие подходы к автоматизации управления
инфраструктурой и производственной средой предприятия.
Вопросы управления и соответствующего обеспечения необходимого уровня инфраструктуры, а также
корректное управление параметрами производственной (рабочей) среды являются важными составляющими в деятельности любого предприятия. Представить некоторое стабильное качество продукции или
услуг без стабильности в управлении инфраструктурой (ресурсами), рабочей средой очень сложно и зачастую предприятия ответственно подходят к решению
данных проблем. Вопросы управления инфраструктурой, средой эффективно или не очень поставлены на
любом предприятии еще за долго до решения о начале внедрения СМК. Как правило, при внедрении
СМК описываются лишь существующее процессы
или деятельность по управлению данными требованиями иногда с некоторой оптимизацией, переназначением ответственности в рамках процессного подхода,
но суть остается той же.
В отношении автоматизации ситуация меняется еще
меньше, и крайне редко кто-либо пытается комплексно
автоматизировать данную деятельность. Стоит отме-
22
методы
менеджмента
качества ®
11' 2010
тить, что в отдельных отраслях автоматизация управления инфраструктурой и особенно производственной
средой присутствует изначально. Например, ITкомпании, банковская сфера, интернет-провайдеры и
т. д. используют системы (Service Desk), позволяющие
своевременно обслуживать и устранять проблемы в
работе оборудования и программного обеспечения.
Используемые, например, в химической, пищевой
промышленности автоматизированные линии также
управляют параметрами среды вплоть до остановки
линии, если параметры выходят за допустимые пределы (активный контроль). Независимо от отрасли во
многих специальных технологических процессах, которые роботизированы или автоматизированы, используется тот же принцип постоянного контроля параметров
и некоторых действий при выходе параметров за установленные границы. Современное оборудование,
например, многокоординатные обрабатывающие центры и т. д. уже содержат встроенные программы планового технического обслуживания и своевременно
оповещают о необходимости выполнения данных работ.
К сожалению, не все предприятия могут похвастаться высокотехнологичным и современным оборудованием, которое почти «все» делает самостоятельно,
поэтому цель данной статьи — обсудить некоторые
общие подходы к автоматизации управления инфраструктурой для среднестатистического предприятия.
Инфраструктура и производственная среда
информационные технологии
а в т о м а т и з а ц и я
с м к
1
См.: Бриленок А.А. Мониторинг процессов системы менеджмента качества // ММК. – 2010. – № 5. – С. 24–29.
Первый — сделать объект универсальным, т. е.
один объект может описывать, например, здание или
станок или рабочее место, единицу транспорта и т. д.
В зависимости от объекта-инфраструктуры, отдельные
поля, реквизиты могут быть доступны или нет. Далее
можно построить иерархию одинаковых объектов, т.
е. создать первый объект инфраструктуры (здание,
цех), далее создать необходимое число объектов (рабочие места), которые находятся в этом здании, связать с объектом «здание». По каждому объекту «рабочее место» создать необходимое число объектов
«обору­до­вание», сделать необходимые связи.
Суть в том, что программно объект один, но его
тип может быть разным (цех, рабочее место, станок). Соответственно в объектах разная информация в зависимости от описываемого физического
объекта-инфраструктуры. Кроме того, ссылаясь друг
на друга от большего (здание) к меньшему (станок)
совокупность объектов формируют сеть инфраструктуры по конкретному зданию, производству,
предприятию.
Универсальность объекта «инфраструктура» несет в
себе как очевидные плюсы, так и некоторые минусы,
связанные со сложностью разработки данного объекта, а также с трудностями внесения изменений при
появлении, например, нового типа объекта «инфра­
структура».
Второй подход заключается в разработке отдельного объекта по каждому типу инфраструктуры: объект
«здание», «рабочее место», «оборудование» и т. д.
Каждые тип описывает только соответствующий физический тип объекта инфраструктуры. При появлении, например, нового типа (транспортное средство)
программируется новый объект в системе: объект
«транспортное средство». В остальном подход анало-
23
методы менеджмента качества ®
Рассмотрим пп. 6.3 и 6.4 стандарта ISO 9001, предположив, что все необходимое оборудование, помещения и рабочие места, средства связи, транспорт,
информационные системы имеются в необходимом
количестве и благополучно функционируют. Вопросы
автоматизации обеспечения необходимыми ресурсами
в части инфраструктуры на этапе постановки продукции на производства, оперативного обеспечения,
установки параметров рабочей среды более подробно
будут представлены в следующих статьях, посвященных жизненному циклу продукции.
Здания, рабочие места, оборудование. За редким
исключением любое предприятие имеет в наличии
необходимые здания, производственные помещения
(цеха), административные здания и т. д., которые,
в свою очередь, содержат рабочие места, участки,
оборудование, линии и т. д. Вся эта инфраструктура
должна находиться в управляемых условиях с целью
оперативного обслуживания, ремонта, проведения
других регламентных работ.
С точки зрения автоматизации в комплексной
системе понадобится новый объект, который будет
описывать одну единицу инфраструктуры (здание, рабочее место, станок и т. д.), а также объект «заявка на
ремонт, обслуживание», объект «запись о проведенном обслуживании, ремонте» и т. д.
Объекты могут быть реализованы по-разному в зависимости от возможности платформы. Это может
быть объект интерфейса СУБД, карточка СЭД, документ САУ1.
Реализовать объект инфраструктуры можно, как
минимум, двумя способами.
11' 2010 ® www.ria-stk.ru/mmq
Рис. 1. Пример объекта "оборудование"
информационные технологии
а в т о м а т и з а ц и я
с м к
гичен первому. Создается необходимое число соответствующих объектов, определяются связи, выстраивается иерархия инфраструктуры.
Чтобы не описывать детально данный объект, приведем пример существующего объекта «оборудование»
из одной информационной системы (рис. 1). В данном примере объект инфраструктуры связан с реальным объектом, который является основным средством
в рамках бухгалтерского учета.
Как видно из рис. 1, важным разделом является
перечень необходимых работ в рамках обслуживания
с указанием периодичности, трудозатрат, возможно,
необходимым перечнем расходных материалов для автоматического формирования заявки на закупку или
забор со склада. Разумеется, в зависимости от типа
объекта инфраструктуры, перечень работ будет отличаться. Для помещений это одни работы, для оборудования — другие и т. д. Технически перечень работ
реализуется в виде одного или нескольких справочников в системе.
Объект «заявка на ремонт, обслуживание» может
быть разработана как отдельный объект или быть
универсальной заявкой на все, что угодно (на закупки, ремонт, транспорт, документы и т. п. ) Плюсы и
минусы универсального подхода были рассмотрены
выше. В качестве заявки может использоваться задача
в системе2. Заявка оформляется инициатором (создается объект в системе) на имя ответственного за ре2
Там же.
монт, внеплановое техническое обслуживание (ТО),
где указывается вся необходимая информация.
Минимальные поля, реквизиты заявки:
• номер;
• дата;
• автор;
• описание проблемы, необходимых работ;
• объект(ты) инфраструктуры;
• сроки;
• состояние (например: новая, принята, отклонена,
отработана);
• примечание;
• причины выхода из строя и т. п.
При правильном построении заявки и ее использовании в дальнейшем можно получить неплохую статистику по работе оборудования и инфраструктуры в
общем для реализации мероприятий по улучшениям.
По результатам ремонта, обслуживания независимо от типа объекта инфраструктуры необходимо делать записи. Можно предложить несколько вариантов
решения данного вопроса.
Один из способов — вносить некоторые отметки,
информацию непосредственно в объект инфра­струк­
туры, т. е. при разработке следует предусмотреть соответствующий раздел, куда ответственный будет вносить данные (например: дата, состав работ, исполнитель и т. д.).
Второй вариант — использовать заявки или задачи
на обслуживание, которые создаются автоматически
системой при наступлении очередного срока или
Рис. 2. Пример объекта "записи о ТО"
24
методы
менеджмента
качества ®
11' 2010
Инфраструктура и производственная среда
информационные технологии
а в т о м а т и з а ц и я
с м к
го срока необходимых работ и
уведомлять соответствующих ответственных лиц. Данный механизм не раз обсуждался в предыдущих статьях, например, в отношении периодического мониторинга процессов СМК3. Для того
чтобы определить наступление
очередного срока, функция системы должна «пройти» по всем
объектам инфраструктуры, в которых есть работы, и проверить,
наступил срок или нет исходя из
даты последнего обслуживания
по конкретной работе, периодичности и текущей даты. Если оборудование введено в эксплуатацию недавно и еще не обслуживалось, то вместо последней даты
обслуживания можно использовать дату ввода в эксплуатацию,
которая должна быть внесена в
объект. При вводе периодичности работ целесообразно указывать такое значение,
чтобы ответственный получал информацию за несколько дней до ТО, которые могут понадобиться на
подготовку, закупку необходимых расходных материалов и т. п.
При обнаружении объектов инфра­структуры и соответствующих работ система автоматически формирует сообщения или задачи или объекты «заявки ответственным лицам ТО» и при необходимости уведомляет тех, в чьем ведении находится объект инфраструктуры для того, чтобы определиться со временем
проведения работ, вывести оборудование из технологического процесса, обеспечить доступ и т. п.
Обычно функция запускается автоматически системой раз в сутки в период низкой загрузки (вечернее, ночное время) и уже утром все ответственные видят информацию, что именно и где надо обслужить.
2. Внеплановое ТО, ремонт. Независимо от автоматизации периодического обслуживания всегда должна
существовать возможность внепланового ремонта оборудования или проведения каких-то регламентных работ до момента наступления очередного срока. Ответственные лица, в чьем ведении находится оборудование и другие объекты-инфраструктуры должны иметь
возможность создать заявку, задачу ответственным за
ТО, ремонт с указанием всей необходимой информации. Желательно, чтобы создаваемые объекты системой (см. п. 1) и пользователями были одинаковы по
типу. Иными словами, если принято решение при
проектировании системы, что ответственный по ТО
будет получать задачи, значит, и система, и пользова3
Там же.
25
методы менеджмента качества ®
вручную при внеплановом обслуживании, ремонте.
Отработанная заявка или выполненная задача (соответствующий статус) и является записью о том, что
указанные в ней работы выполнены.
Последний вариант — использовать отдельный
объект, например объект «запись о ТО», который будет создаваться в системе исполнителем после проведения необходимых работ и содержать всю информацию по перечню обслуженного, отремонтированного
оборудования, составу работ, срокам, трудозатратам и
т. п. Пример такого объекта приведен на рис. 2.
После краткого рассмотрения необходимых объектов приведем общий сценарий работы системы в части управления инфраструктурой (схема). В данной
схеме не учитывается возможная автоматизация закупок, получения расходных материалов и запасных частей, необходимых для работ в рамках обслуживания
и ремонта объектов инфраструктуры. Любая организация без труда добавит необходимую логику и объекты
в приведенный сценарий. Единственное, что необходимо помнить: лучше это сделать после того, как будет автоматизирован процесс закупок, автоматизацию
которого мы рассмотрим в одной из следующих статей цикла.
1. Периодическое ТО. Многие объекты «инфраструктура», независимо от типа обслуживаются на планово.
Это может быть банальная уборка помещения,
планово-предупредительный ремонт (ППР) станка,
техническое обслуживание автомобиля. Как мы увидели выше, объект «инфраструктура» должен содержать или ссылаться на соответствующий перечень работ и установленную периодичность. Системе остается лишь постоянно проверять наступление очередно-
11' 2010 ® www.ria-stk.ru/mmq
Сценарий системы по обслуживанию и ремонту объектов инфраструктуры
информационные технологии
а в т о м а т и з а ц и я
с м к
тели создают задачи, если заявки — значит заявки.
Это позволит избежать путаницы и упростит разработку системы, получение статистики.
3. Выполнение работ. Оформление результатов.
После выполнения необходимых работ согласно информации в системе необходимо внести некоторые
записи по результатам выполнения. Следует указать
лицо, выполнявшее работы, и дата проведения, для
того чтобы система смогла рассчитать следующую
дату обслуживания. Если используется задача, то вся
информация уже введена. Задачу необходимо перевести в состояние, например «Выполнено», предварительно внеся дополнительные данные, если это необходимо. Выполненная задача и будет являться записью. Дата выполнения задачи может использоваться для расчета следующего срока ТО. Даты выполнения можно хранить в самом объекте инфраструктуры
или ином связанном объекте. При выполнении ремонта целесообразно указывать причины выхода из
строя оборудования или других объектов-инфраструктуры.
Также можно использовать специально разработанный объект «запись о ТО» (см. выше), который
создается ответственным после выполнения работ, заполняется автоматически или вручную и является записью о проведенных работах. Дата данного объекта
может служить датой выполнения работ и использоваться для определения следующего срока.
4. Отчетность. Важно предусмотреть некоторую отчетность в рамках управления инфраструктурой. Это
могут быть:
• перечни объектов инфраструктуры (по типам, в
разрезе подразделения, зданий и т. п.) – комбинации могут быть любыми;
• план-графики проведения ТО, ППР — опять же
по различным срезам (производство, цех, рабочие
места, по ответственным, предприятие целиком
и т. п. );
• сроки, нарушение сроков выполнения работ;
• статистика по причинам отказов, наиболее часто выполняемым работам, расходным материалам и т. д.
Правильно построенные отчеты помогут очень
быстро получить необходимые данные и информацию
для оперативного проведения работ, анализа и дальнейшего улучшения управления инфраструктурой.
Информационные системы, программное обеспечение, средства связи. Приведенные объекты инфра­
структуры также должны находиться в управляемых
условиях. Данные объекты можно разделить на аппаратную составляющую (компьютеры, компоненты локальной вычислительной сети (ЛВС), оргтехника и
т. п.) и программную (программы, операционные системы, драйверы оборудования).
Аппаратная часть — так называемое железо — может обслуживаться и ремонтироваться в рамках автоматизированной системы по аналогии, как и рассмо-
26
методы
менеджмента
качества ®
11' 2010
тренное выше оборудование. В большинстве случаев
компьютерная техника редко обслуживается так, как
оборудование или, например, транспортные средства.
Современные аппаратные средства достаточно надежны и успевают морально состариться (и соответственно замениться) до момента возникновения значительных отказов. Иногда аппаратные средства используются в (производственных) помещениях с агрессивной средой (значительный уровень пыли, влажность,
вибрации и т. д.). В данном случае необходимо плановое обслуживание согласно эксплуатационной документации или специально разработанным регламентам. Все вышесказанное касается и различных средств
связи, оргтехники.
Несколько иначе ситуация обстоит с программным
обеспечением (ПО), которое, с одной стороны является инфраструктурой и с другой (например, для ITкомпаний) — это та же производственная среда, которая должна быть в управляемых условиях. Как правило, за стабильность работы всего ПО отвечают специальные службы или администраторы системы, обладающие необходимыми знаниями и опытом.
В настоящей статье мы не будем рассматривать
нюансы автоматизации управления ПО, так как данные вопросы находятся в компетенции определенного
круга специалистов, а лишь приведем некоторые
аспекты, которые при грамотном подходе необходимо
реализовать:
• обеспечение безопасности ЛВС, корпоративной
сети (авторизированный вход, политика безопасности, безопасная связь с другими локальными и
глобальными сетями);
• наличие и автоматическая работа, обновление антивирусных программ, брандмауэров (файерволов);
• своевременное (возможно, автоматическое) обновление установленного на рабочих станциях, серверах программного обеспечения, включая операционные системы, драйверы оборудования и т. д.;
• автоматическое резервное копирование используемых баз данных, файловых хранилищ;
• автоматическое ведение аудита действий пользователей, других необходимых логов и журналов.
Приведен лишь незначительный перечень возможных вопросов, но это тот минимум, который должен
быть для обеспечения стабильной работы информационной системы. Разумеется, например, в банковской
сфере данный список значительно шире.
Очень часто для решения проблем, возникающих
с аппаратным, программным обеспечением, средствами связи, оргтехникой используют системы Service
Desk, в основе которых лежит объект «инцидент».
При возникновении некоторой проблемы пользователь создает данный объект в системе при условии,
что компьютер позволяет это сделать, иначе он связывается с ответственным лицом при помощи телефонной связи и прочее. Объект «инцидент» (или, на-
а в т о м а т и з а ц и я
с м к
вать что-то вряд ли возможно при помощи системы и
автоматизация может быть обеспечена внутренним
устройством сварочного оборудования, использованием электронных расходомеров, сигнализирующих о
выходе параметра за допустимые пределы и т. п.
Далее работа сценария очень похожа на сценарий
по ТО объектов-инфраструктуры. При наступлении
очередного срока замера параметров система уведомляет ответственное лицо (сообщение, задача, объект
«результат замера»). Лучше использовать отдельно
разработанный объект «результат замера», который
будет автоматически сформирован системой, например по конкретным ответственным, и содержать перечень помещений, рабочих мест, параметров, которые
необходимо замерить, и что самое главное, в этот
объект вносятся полученные значения. Можно использовать другой подход, важно, чтобы фактические
значения попали в систему и были проанализированы.
После внесения данных, система проверяет, находятся ли введенные значения в допустимых пределах,
если нет — создает задачу ответственному о том, что
следует принять меры по доведению параметров среды до необходимого уровня.
Если пойти дальше, то можно (если это под силу
предприятию) использовать автоматические измерения, т. е. наступило время замера, например, температуры в конкретном помещении. В помещении находится электронный термометр, который через специальный интерфейс связан с системой. Система получает значение температуры, сохраняет (если это необходимо), сравнивает с граничными значениями и,
если уровень превышен, создает задачу ответственному. Подход значительно упрощает работу по контролю параметров, но достаточно трудоемок и сложен в
отношении технической реализации.
Часто используются локальные системы предупреждения, оповещения о выходе каких-то параметров за
допустимые границы. Такой подход прост и очень часто оправдывает себя, но не позволяет фиксировать,
сохранять историю значений параметров и т. д.
В отношении автоматизации управления параметрами производственной среды надо подходить с позиции здравого смысла и всегда индивидуально принимать решения о необходимости и способе автоматизации контроля тех или иных параметров рабочей
среды.
Рассмотренные в статье подходы к автоматизации
управления инфраструктурой и рабочей средой описывают лишь основные аспекты, не учитывая различных нюансов, зависящих от вида продукции, масштабов предприятия, сферы деятельности. Несмотря на
это при необходимости автоматизации данного требования стандарта ISO 9001 любая организация сможет
использовать приведенные сценарии, изменить их
или разработать собственные. 27
11' 2010 ® www.ria-stk.ru/mmq
пример, задача) попадает к ответственному, который
устанавливает приоритет, планирует загрузку по всем
инцидентам, готовит, при необходимости, расходные
материалы и запасные части, устраняет проблему и
закрывает объект или задачу.
Сценарий довольно прост, но может отличаться
в зависимости от масштабов и сферы деятельности
предприятия.
Можно использовать готовое решение Service Desk
или смоделировать собственную систему, связав ее
или интегрировав с механизмом, описанным выше,
по управлению другими объектами инфраструктуры.
Рабочая среда. В начале статьи мы рассмотрели некоторые используемые подходы к автоматизации
управлением параметрами рабочей среды (автоматизированные, робототизированные линии, специальные технологические процессы и т. п. ).
Далее кратко опишем некий сценарий, который
можно автоматизировать в рамках разрабатываемой
комплексной системы и который очень часто можно
использовать для управления параметрами рабочей
среды. Данный подход сложнее применить ко всем
специальным технологическим процессам, и при разработке системы надо учитывать возможность автоматизации управления теми или иными параметрами
спецпроцессов.
Первый шаг — получение необходимого перечня
помещений, участков, рабочих мест и список соответствующих параметров (температура, влажность, освещенность, шум и т. д.), которые влияют на качество
выпускаемой продукции. Для этого вполне можно использовать объект-инфраструктуры, который был
описан в первой части статьи. Достаточно предусмотреть дополнительный раздел в объекте, например
«Контролируемые параметры среды».
Раздел может содержать следующие данные:
• необходимые параметры рабочей среды (согласно
технологической документации и инструкций);
• граничные значения;
• периодичность контроля;
• ответственных лиц по всем или каждому параметру: кто должен фиксировать и вносить данные;
• ответственных лиц, кто должен принимать меры,
если фактические значения выйдут за допустимые
пределы.
После внесения данной информации можно получить отчетность по разным срезам о всех контролируемых параметрах по всему предприятию.
Основная проблема — это сбор и внесение данных. В зависимости от помещения и параметра, периодичность и сложность могут сильно отличаться. Например: замер освещенности на рабочих местах может
делаться раз в год, температуры и влажности в складских помещениях — два раза в сутки, контроль расхода газа при аргонно-дуговой сварке — постоянно в
процессе сварки. В примере со сваркой автоматизиро-
информационные технологии
методы менеджмента качества ®
Инфраструктура и производственная среда