Качество - это не евангелизм, не рацпредложение и не лозунг; это образ жизни. (А. Фейгенбаум)

Инструментарий систем менеджмента качества


  Малышев О. В., к. т. н.,
Исполнительный директор Всеукраинской общественной организации "Украинское общество качества",
директор по качеству Научно-консультативного предприятия "АСТЮС".




    1. Введение

    Любой вид человеческой деятельности рано или поздно обрастает инструментарием. Как же обстоят дела с инструментальной поддержкой процессов создания и функционирования систем менеджмента качества (СМК)?
    Для ответа на этот вопрос попытаемся взглянуть на СМК с различных точек зрения:
    1) как на проект, который требует ресурсов для своего осуществления и далеко не всегда "обречен на успех";
    2) как на деятельность, всецело опирающуюся на документирование;
    3) как на деятельность, отдельные элементы которой обладают устойчивой спецификой;
    4) как на целенаправленное упорядочение и оптимизацию системы деятельности организации.


    2. СМК как проект

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

    От редкатора

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

    Конечно, на это можно посмотреть предельно просто и все пустить на самотек. Но тогда не нужно и удивляться, если вместо желаемых, всем понятных и всеми осязаемых успехов сотрудники организации получат дополнительную каждодневную "головную боль".
    Вывод: следует рассматривать СМК как проект и постараться использовать существующие методы и средства управления проектами.


    3. Документирование в СМК

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


    4. Элементы СМК

    Системное осмысление отдельных сторон деятельности организации, таких, например, как выполнение закупок, применение статистических методов, как правило, приводит к постановкам задач на создание специфического инструментария для их поддержки.


    5. СМК как средство совершенствования системы деятельности предприятия/организации

    По определению стандарта ISO 9000:2000: requirement=need or expectation that is stated, generally implied or obligatory; quality=degree to which a set of inherent characteristics fulfils requirements; quality management system=management system to direct and control an organization with regard to quality;
    Несколько наблюдений:
    1) речь не идет исключительно о качестве продукции;
    2) качество функционирования организации и качество выпускаемой ею продукции и/или предоставляемых ею услуг - вещи различные;
    3) перевод определения СМК на русский язык - занятие неблагодарное в силу необходимости различения значений "manage", "direct", "control".
    Название "СМК" - на мой взгляд, не самое удачное. Предположим, предприятие выпускает продукцию определенного качества, не имея СМК и, соответственно, сертификата.
    На что же направлены усилия при разработке и внедрении СМК? На повышение качества продукции?
    Не всегда. Как правило, происходит постепенное документированное упорядочение деятельности, дорисовываются ее обязательные фрагменты в соответствии с требованиями стандарта. Первыми результатами этого являются повышение стабильности (помехоустойчивости) деятельности, улучшение психологического климата в организации, разгрузка руководителей от рутины, резкое снижение уровня непрозводительных затрат и потерь от брака.
    Что касается качества продукции, то оно может и не меняться. Оно просто становится более управляемым и стабильным.
    Таким образом, при разработке и внедрении СМК в центре внимания находится упорядочение и повышение эффективности системы деятельности (СД) организации.
    Сущностью процесса создания СМК является создание модели СД, отображаемой в определенной части документации СМК.
    Моделирование СД должно осуществляться по определенным правилам и должно поддерживаться соответствующими инструментами. Разве можно не согласиться с этим утверждением?
    Весь вопрос в том, какими должны быть эти правила и инструменты.
    Может быть, ответ на этот вопрос следует поискать на тропе "подхода от процессов"?


    6. От "процессов" ли?

    Что такое "процесс"? Согласно ISO 9000:2000: process=set of interrelated or interacting activities which transforms inputs into outputs.
    Оказывается, процесс - вещь сложная, состоящая из взаимосвязанных и взаимодействующих "активностей" и преобразующая "входы" в "выходы".
    Что такое "активность" и как из "активностей" строится процесс, стандарт не уточняет.
    Возможно, в английском языке, термин "activities" обозначает "кирпичики", а термин "process" - "строительный блок", из которых строится здание СД. Но в русском языке, на мой взгляд, "процесс" - неудачный термин. И вот почему.
    Давайте различать три сущности:
    1) типовой объект, над которым осуществляется типовое действие;
    2) типовое действие, осуществляемое над типовыми объектами;
    3) процесс выполнения типового действия над типовыми объектами.
    С одной стороны, ни одна из этих сущностей в принципе неустранима из моделирования СД. С другой, их вполне достаточно для моделирования СД.
    Если назвать 2-ю сущность "процессом", то для 3-й сущности это приводит к "процессу выполнения процесса".
    Предлагается (в рабочем порядке) называть 1-ю сущность "операндом", а 2-ю "операцией".
    По отношению к операции можно различать такие классы операндов, как входные, выходные и вспомогательные. Кроме того, одни операции могут быть вспомогательными для других.


    7. Борьба с хаосом

    Борьбу с организационным хаосом будем отождествлять с повышением уровня определенности описания операндов каждого класса (входные, выходные, вспомогательные), а также способа выполнения операции (см. табл. 1 и 2 соответственно).

    Таблица 1. Уровни определенности описаний операндов
    Определение уровня
    0 Операнды данного класса не определены. Из описания операции невозможно (затруднительно) установить их количество и назначение каждого из них
    1 Операнды данного класса слабо определены. Из описания операции возможно лишь частично установить их количество и назначение некоторых из них
    2 Определен список операндов данного класса и назначение каждого из них
    3 Существует типизация операндов и для каждого операнда из данного класса определена его принадлежность к тому или иному типу


    Таблица 2. Уровни определенности описания способа выполнения операции
    Определение уровня
    0 Вспомогательные операции не определены. Из описания операции невозможно (затруднительно) установить их количество и назначение каждой из них
    1 Вспомогательные операции слабо определены. Из описания операции лишь частично возможно установить их количество и назначение некоторых из них
    2 Определен список вспомогательных операций и назначение каждой из них
    3 Существует типизация операций и для каждой вспомогательной операции определена ее принадлежность к тому или иному типу
    4 Определен порядок выполнения вспомогательных операций

    Уровень определенности описания операции характеризуется четверкой , где n1, n2, n3 - значения уровней определенности описания операндов входных, выходных, вспомогательных соответственно, а n4 - значение уровня определенности описания вспомогательных операций.
    Несмотря на простоту подобного деления на уровни, его, тем не менее, можно использовать на практике для идентификации уровней определенности реальных описаний, например, фиксации факта существования описаний с уровнем <0, 0, 0, 4>.
    Пытаться использовать его для сравнительной оценки реальных описаний, возможно, и не стоит - все они (по разным причинам) имеют право на существование, принося пусть относительную, но пользу, как средство борьбы с организационным хаосом.
    Процедурное описание способов выполнения операций, в которых устанавливается порядок выполнения вспомогательных операций и обработки операндов различных классов (уровень <3, 3, 3, 4>) называется программированием деятельности [1].


    8. Инструментальная поддержка программирования деятельности

    Для внедрения программирования деятельности в практику оно должно быть поддержано такими средствами, как:
    • общепризнанный (унифицированный) язык программирования деятельности, основанный на унифицированном описании операндов, операций и процессов.

    • специальная исполнительная система.
    Основным назначением исполнительной системы (в [1] это "программная система автоматизации операционных маршрутов", в [2] - "механизм процесса" (Process Mechanism), в [3] - "технологическая операционная система") является выполнение программ деятельности и генерация описаний порождаемых при этом процессов.
    Связующим звеном между языком программирования и исполнительной системой является система программирования, позволяющая разрабатывать, транслировать, отлаживать и анализировать программы деятельности.


    9. Преимущества, обеспечиваемые программированием деятельности

    Наличие языка программирования дает возможность регулярным образом отобразить в документальном виде знания эксперта о системе деятельности: об объектах и действиях, их типах, о порядке выполнения действий и многом другом. Попытка запрограммировать деятельность, как правило, вскрывает ее "белые пятна", помогает вскрыть причины потерь, являющихся следствием неопределенности и ошибок. Имеющиеся описания могут быть проанализированы и улучшены, а также использованы для обучения персонала.
    Наличие исполнительной системы снимает с участников деятельности необходимость выполнения какой бы то ни было рутинной работы. Запрограммированная деятельность диспетчируется и поддерживается системой, которая:
  • ведет все процессы выполнения программ, протекающие на предприятии (в организации), отслеживая и анализируя результаты выполнения работ, осуществляя предусмотренные в программах передачи управления и т. д.;
  • своевременно уведомляет исполнителей о необходимости выполнить определенную операцию;
  • предоставляет необходимую поддержку для выполнения определенных в системе операций;
  • не дожидаясь указаний со стороны человека, сама инициирует выполнение имеющихся в программе деятельности компьютерных операций (например, трансляцию программы или теста или анализ окончания параллельных работ);
  • осуществляет мониторинг процессов выполнения операций (например, размещает входные и выходные данные, следит за длительностью выполнения работы и дает "сигнал тревоги" при превышении некоторой заданной величины и т. д.);
  • ведет описания реализуемых процессов, структура и полнота которых управляемы, и обеспечивает доступ к ним с целью анализа.
  • Все это обеспечивает реальную возможность достижения того предела, за которым уделом человека остается только человеческий труд, неразложимый на какие-либо составляющие.
    Наконец, наличие получаемых автоматически описаний процессов, имеющих заданную структуру и степень детализации, создает необходимые условия для исследования фактической картины осуществляемой деятельности. Первоочередная цель таких исследований - получение данных для последующего совершенствования систем деятельности.
    Подобный анализ накопленной информации вряд ли осуществим без использования специальных автоматизированных аналитических систем.


    Библиография

    1. Фуксман А. Л. Технологические аспекты создания программных систем. - М.: Статистика, 1979. - 184 с., ил.
    2. Hoffnagle G.F., Beregi W.E. Automating the software development process // IBM System Journal. - Vol. 24. - No. 2. - 1985. - P. 102-120.
    3. Малышев О. В. Типовая технология программирования. Часть 3. Техноло-гическая операционная система / Учебное пособие. - К.: Международный научный центр технологии программирования "ТЕХНОСОФТ". Курсы подготовки и повышения квалификации специалистов, 1991. - 63 с.




Также на сайте:
Интегрированность СМК
Концепция автоматизированной системы управления документооборотом в системе качества

О проекте

quality.eup.ru - один из самых старых в рунете ресурсов, посвященных менеджменту качества во всем его разнообразии.

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

Кроме отличной и действительно большой подборки статей, действует живой форум по менеджменту качества.

Добавить в "Избранное"

Реклама на сайте