Сертификат о соответствии системы менеджмента качества стандарту ISO9000, выданный предприятию ОАО «Ратеп», которое входит в концерн ПВО «Алмаз-Антей» и выпускает продукцию как военного, так и гражданского назначения, числится в «Военном регистре» под номером 0001. И вот уже десять лет эта система непрерывно совершенствуется. Технологии информационной поддержки производства на предприятии также развиты очень сильно. О том, насколько смыкаются эти направления, мы беседуем с заместителем генерального директора «Ратеп» по ИТ Геннадием Савченко и заместителем генерального директора по качеству Борисом Варламовым.

Intelligent Enterprise: Пред­прия­тий, имеющих сертификат качества ISO9000, сейчас немало, и в связи с этим хотелось бы разобраться, что вы вкладываете в понятия качества и управления качеством.

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

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

Один из ключевых постулатов, который мы как производственники считаем правильным и которым руководствуемся в своей работе, состоит в том, что качество продукции на 70 процентов определяется уровнем разработки, на 20 — изготовлением и на 10 процентов культурой эксплуатации.

Не менее значим для нашего предприятия и для меня лично единый подход к понятию «система менеджмента организации». Мне, честно скажу, не всегда бывает близко дробление данного понятия на несколько разных областей, что если не раскалывает саму концепцию, то излишним образом дифференцирует подход к ней. Это, кстати, отнюдь не является следствием чьего-то невежества и даже косвенно прослеживается в подходах к формированию того же семейства стандартов ISO. Я думаю, нельзя создавать различные правила движения для одной и той же территории, даже если делать оговорки, что эти правила будут по возможности синхронизированы, непротиворечивы и проч. В то же время качество присутствует везде, и имея в виду разноплановые направления, развиваемые внутри любого современного предприя­тия, уместно было бы представлять его в виде известной иерархической нотации — например, «финансы.качество», «информационная система.качество» и т. д.

И, наконец, качество — не самоцель. Цель, связанная с его повышением, так или иначе соотносится с иными приоритетами предприятия. Для нас помимо качества таковыми являются цена и дисциплина поставок.

Геннадий Савченко: Для нас как ИТ-специалистов качество, наверное, ближе всего ассоциируется с понятием единого информационного пространства предприятия, со сквозной автоматизацией производственных процессов. Конечно, эти слова сейчас произносятся довольно часто, и говорить о том, насколько они важны, лучше всего на примерах конкретных задач, сравнивая сценарии сквозной автоматизации с ситуациями, когда таковая отсутствует. Характерно также, что ИТ-поддержка управления качеством иногда может представляться несколько размытой концепцией с точки зрения практического применения, и именно потому, что ее составляющие, будь то производственное планирова­ние, технологическая либо конструкторская подготовка производ­ст­ва, при наличии сертифицированной системы качества или же без нее все равно работают на те или иные производственные задачи.

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

Если уж мы говорим о единстве качества, уместно заметить, что ракурсы рассмотрения этой проблемы действительно различны. Двумя по сути параллельными подтемами являются, например, качество продукта и качество процесса. Что вы могли бы сказать по этому поводу?

Б. В.: Да, действительно, такое разделение вполне корректно. Хотя здесь надо оговориться, что существует своего рода перекрестная область, которую условно можно было бы назвать «процесс-тире-продукт». Но начнем, тем не менее, с продукта.

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

Г. С.: Что касается нашей роли в решении только что обозначенной проблемы, то здесь как раз можно конкретизировать тезисы о едином информационном пространстве и о сквозной информационной поддержке. Идеальной является ситуация, если изделие запускается в производство в тот момент, когда всё дерево конструкторской спецификации (а это часто многие тысячи позиций номенклатуры и более десятка уровней вложенности) полностью готово и в дальнейшем изменяться не будет. В таком случае ИТ-поддержку обозначенной выше задачи доведения изделия до приемо-сдаточных испытаний вполне можно было бы решать за счет сохранения вводимой информации в электронном виде и доведения ее до конкретных сотрудников. На практике, однако, дела обстоят сложнее, и проблему параллельного с подготовительным и производственным процессами учета конструкторских изменений надо решать в любом случае.

Выход здесь виделся нам, во-первых, в сквозной автоматизации производства — в данном случае в виде единого комплекса тесно интегрированных между собой CAD-, PDM- и ERP-систем. Во-вторых, в реорганизации бизнес-процессов, достижимой, в свою очередь, только на базе той самой сквозной ИТ-поддержки. Сегодня, к примеру, мы сделали конструкторов ответственными за качество всех вводимых в систему данных, которыми впоследствии пользуются и технологи на этапе подготовки производства, и производственники в ходе изготовления заказа. Таким образом, мы твердо знаем: то, что считается корректным в конструкции, корректно и для производства. При этом мы исключили прин­ципиальную возможность хождения нескольких вариантов «правильных» чертежей, возникающую вследствие того, что конструкторы часто изменяли документацию согласно замечаниям технологов, минуя централизованные механизмы согласования и по сути запуская в производство второй комплект документации параллельно с уже существующим. Казалось бы, все это естественные, основанные на здравом смысле решения, которые следовало претворить в жизнь уже давно. Но не всё так просто.

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

Постараюсь пояснить еще более детально. Наши конструкторы в рамках собственных ОКР проектируют изделие или его составные части в системе SolidWorks, после чего оно в виде 3D-модели, 2D-чертежа и электронной иерархической спецификации попадает в архивы базы данных PDM-системы, с которой начинают работать технологи. В результате элементы спецификации обрастают информацией о соответствующих им технологических операциях, маршрутах, нормах расходов материалов, трудовых нормативах и т. п. К началу производственного процесса мы эту информацию через специальные конверторы и фильтры выгружаем в ERP-систему. Не могу сказать, что вследствие отмеченных мною нюансов все эти преобразования выполняются абсолютно автоматически, но сквозная автоматизация, перевод поддержки жизненного цикла изделия в электронный вид и наличие единого ИТ-пространства здесь налицо.

Далее, говоря о цепочке CAD — PDM — ERP, я бы подчеркнул зна­чимость этой связки с точки зрения организации процессов. PDM-система — это по сути единый концентратор, позволяющий гарантированно иметь единственно верную информацию на любой стадии жизненного цикла изделия. Да, теперь конструктор в принципе не имеет возможности локально утрясти изменения в документации с технологом. Любое, даже самое мелкое изменение в конструкторской или технологической документации приходится проводить централизованно, фактически возвращая процесс в начальную точку, заново оформляя всю необходимую документацию, снова пропуская её через PDM, которая в данном случае выполняет также функции workflow-системы (включая этап нормоконтроля). Быть может, вполне уместно сказать, что бюрократия при этом формально даже несколько увеличивается. Но конечная эффективность, без сомнения, повышается значительно.

Остается добавить, что в роли PDM-системы мы используем продукт Search компании «Интермех», для автоматизации разработки техпроцессов — решение Techcard этой же компании, а в качестве ERP у нас развернута КИС «Флагман» разработки «Инфософт».

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

Б. В.: Как я уже отмечал, для нас чрезвычайно важна связка «про­цесс — продукт». Я занимаюсь во­просами обеспечения качества с 1990 года, когда доминирующей концепцией в этой области была известная с советских времен комплексная система управления качеством продукции — КС УКП. В этой связи могу сказать, что если раньше мы просто стремились максимально наладить контроль деталей по бинарному принципу «годен — негоден», то после того как в 1996 году менеджмент прошёл обучение методам статистики и были получены практические результаты, пришло осознание того, что производственному процессу по определению присущи отклонения от некоего идеального режима, и мы поняли, какие возможности несёт в себе применение статистики. Соответственно после принятия идеологии стандарта ISO9000, который как раз и пропагандирует этот важный принцип, контроль практически всегда подразумевает под собой сбор соответствующих данных и последующую их статистическую обработку. В результате данные всех стадий испытания продукции превращаются в гистограммы, распределения, а также обобщенные и имеющие статистическую значимость числовые параметры. И как следствие мы имеем уже не результаты контроля, а рычаги управления процессом. Иными словами, располагая объективными статистическими характеристиками результатов контрольных испытаний, мы анализируем их и можем целенаправленно влиять на процесс. Другое дело, что порой здесь складывается совсем не простая ситуация, потому что влияние тех или иных параметров процесса на динамику наблюдаемой нами статистической картины контроля продукции часто далеко не очевидно. Но тем не менее речь идет о совершенно реальных зависимостях и реальных рычагах влияния на процесс, в чем мы постоянно убеждаемся на практике.

Что касается производства и его процессной составляющей, то на каждую деталь, запущенную сквозь производственный цикл (и часто по многим цехам), у нас составляется так называемая «наряд-марш­рутная карта». Она существует в электронном виде, и в ней расписаны все операции, которые проходит эта деталь, все отметки отдела обеспечения качества, ОТК и проч. Полученная информация обобщается, и по ней принимаются решения. Если, к примеру, на шестой операции обнаружится, что не закрыта пятая, то сразу состоится «разбор полетов», где будет выяснено, почему так произошло. То есть в процессе производства каждый последующий исполнитель, изготовляющий деталь под конкретный заказ, по сути контролирует предыдущего.

Г. С.: Говоря о процессах, мы, «айтишники», прежде всего имеем в виду применение CASE-средств для моделирования бизнес-процессов. На предприятии в качестве стандартного использовался популярный продукт Workflow Modeler компании Meta Software, на базе которого на стадии подготовки системы менеджмента качества к сертификации была разработана функциональная модель управления бизнес-процессами по методологии IDEF0/3. Эти же наработки (электронные функциональные модели) позже были взяты для проведения реинжиниринга бизнес-процессов, создания и оптимизации информационной модели в рамках внедрения ERP-системы. Практически тотальный переход к статистическим методам обработки информации на предприятии «Ратеп» действительно произошел, и информационную поддержку здесь напрямую можно ассоциировать с применением известной программы статистической обработки данных Industrial Statistica. Мы начали применять ее в 1998 году, практически сразу после того, как культура статистической обработки результатов в связи с принятием идеологии ISO стала у нас доминирующей. Это не только средство построения всевозможных отчетов, но и средство анализа в руках специалистов ОТК, отдела главного технолога и т. д. А значит, прямой инструмент поиска той самой связи «продукт — процесс».

Далее разговор о сквозной автоматизации и о едином информационном пространстве можно продолжать уже в контексте производственных задач. Имея единый концентратор информации в виде PDM-системы, мы получаем единую корректную версию данных для производства — с номенклатурой, нормами и т. д. И хотя в нашей ERP-системе реализовано и перспективное, и объемно-календарное, и оперативное (внутри- и межцеховое) планирование, в контексте разговора о поддержке управления качества в разрезе процессов хотелось бы остановиться именно на вопросах диспетчеризации производства. Ведь реализация ИТ-поддержки в данном случае особенно чувствительна к коррект­ности и полноте информации, накопленной на подготовительном этапе. Только что мой коллега сказал про наряд-маршрутную карту и сквозной контроль продукции по всему производственному циклу в разрезе заказа. На самом деле это требование наших специалистов по качеству. Мы же должны все это поддержать с точки зрения автоматизации.

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

Вроде бы здесь всё предельно просто, тем более что подобная прослеживаемость продукции даже вне требований менеджмента качества является важной составляющей производственного процесса. Однако такая детальная диспетчеризация, или своего рода «производственный workflow», эффективна только тогда, когда мы четко знаем, что следим за деталями, которые действительно необходимо произвести в данный момент, а связанные с ними технологические операции, маршруты и конструктивные характеристики известны, доступны и не допускают неоднозначных толкований. Это, в свою очередь, обеспечивается за счет выполнения нескольких обязательных условий. Во-первых, на предприятии должны быть зрелые механизмы автоматизации внутрицехового и межцехового планирования и их оптимизации и не менее зрелые инструменты подготовки производства в электронном виде. А во-вторых, обрабатывающим центрам необходимы самые современные методы контроля размерных характеристик деталей, в том числе и изготовленных по 3D-моделям, вкупе с контрольно-измерительными машинами.

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

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

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

Б. В.: Прежде всего надо хотя бы совсем кратко пояснить некоторые организационные моменты. Любые первичные производственные инциденты у нас фиксируются инженерами отдела технического контроля, заносятся в базу данных и проходят этап предварительного анализа, после чего принимается решение на уровне цеха. Примерно по той же схеме работает специально созданный в рамках опытно-конструкторского бюро отдел надежности, для которого этими первичными инцидентами служат извещения об изменении конструкторской документации, да и вообще любые исключения, касающиеся подготовки производства. Он же следит за нашими изделиями, находящимися в эксплуатации. Затем собранная и предварительно обработанная информация обсуждается на заводском дне качества, где присутствуют все руководители заводских подразделений, принимающие решения на своём уровне. Одновременно на предприятии работает постоянно действующая комиссия по качеству. В неё входят топ-менеджеры «Ратепа», и она по сути является высшим органом, принимающим на основе представленной информации решения в области управления качеством, которые оперативно доводятся до исполнителей.

Я опустил довольно много подробностей нашей работы, пытаясь выделить главное. Например, у нас реализован хорошо известный в теории управления качеством цикл Демминга PDCA: Plan-Do-Check-Act, или «спланируй — сделай — проверь — действуй». Ин­формация о качестве выделяется, обобщается и по мере обобщения поднимается наверх. Далее принимаются решения, и цикл «сбор информации — анализ — улуч­шение» начинается заново. Здесь огромное значение имеет наша способность управлять документацией, относящейся к управлению качеством, которую необходимо на основе единых принципов хранить, классифицировать, анализировать, изменять и доводить до сотрудников.

Г. С.: В подобных случаях в контексте ИТ-поддержки качества традиционно принято говорить о системах электронного управления документами, и их роль действительно очень важна. В этой связи еще раз отмечу программу Statistica, которая кроме всего прочего является мощным инструментом представления статистически обработанных данных. Значительную роль в ИТ-поддержке работы с документацией именно как инструмент, обеспечивающий единые прин­ципы хранения, актуализации и распространения информации, играет наш внутренний интернет-портал (интранет). Он-то и обеспечивает реализацию вышеупомянутого цикла. Есть у нас и своего рода классическая система workflow, которая выполняет типичные для продуктов данной категории функции.

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

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

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

Приведу еще характерный для нас пример создания так называемых интерактивных электронных технических руководств — ИЭТР. Это документация, которую мы вместе с изделиями поставляем нашим заказчикам, в основном зарубежным. Можно сказать, что она революционна по форме, так как насыщена современными технологиями — электронными древовидными каталогами, обучающими видеороликами, трехмерными и двумерными моделями, интерактивной логикой работы с разнообразным контентом и т. д., и понятно, что ни о каких бумажных вариантах здесь вообще не может идти речь. Все это немаловажно в том числе и в контексте проблем качества, ведь, как было сказано вначале, стадия эксплуатации изделия хотя и уступает по значимости фазе ее разработки, все же достаточно важна. При этом хочу особо подчеркнуть, что ее создание не является неким творческим импульсом с нашей стороны в попытке отойти от скучных текстовых документов, которые к тому же поставлялись в огромных объемах и физически могли помещаться лишь в большом количестве ящиков. ИЭТРы регламентируются спецификациями серии STEP, которые, как извест­но, вообще очень значимы для сложного машиностроительного производства, и сегодня для многих предприятий они уже являются обязательными по техническому заданию при заключении контрактов на поставку продукции с зарубежными заказчиками.

Но опять-таки тут очень многое связано с пресловутой сквозной автоматизацией. Трехмерные модели для ИЭТР мы, например, в значительной мере черпаем из CAD-системы, если и не напрямую, то за счет полностью автоматического преобразования. Словом, даже в такой классической форме ИТ-поддержки систем качества, какой является документооборот, имеются нюансы, характерные для деятельности нашего предприятия.