ISO, менеджмент, консалтингпользователи сайтаRSSФОРУМСТАНДАРТЫГОСТ РСЛОВАРЬНАВИГАТОРКОНСУЛЬТАНТЫ 
Логин : Пароль:   
       [регистрация] [напомнить пароль]
 

ФОРУМ
• Re: методики описания БП 
 23. Окт 08:43 от PrilipkoAI
• ISO 22000:2018 
 10. Сент 23:29 от GurbanovR
• HACCP vs FSMS 
 23. Авг 10:52 от PrilipkoAI
• Re: план контроля качества 
 13. Авг 12:07 от Facebook



Языковой фактор в менеджменте качества

Страница для печати 

  • размещено в разделе: Школа качества
  • Автор: cir


  • найти еще статьи по теме:


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

    «1. В начале было Слово…».
    Евангелие от Иоанна

    1. Введение

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

    • проблемное, состоящее из типовых объектов или задач данной предметной области, для описания или решения которых требуется языковой инструмент;
    • языковое, состоящее из реально существующих языков, потенциально применимых для описания объектов или решения задач данной предметной области.

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

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

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

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

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

    Влияние языкового фактора реализуется через субъекта, действующего в предметной области. При этом существенными оказываются такие моменты, как:

    • степень осознанности проблемы субъектом;
    • степень осведомленности субъекта о существовании языка, пригодного для решения проблемы;
    • степень, в которой субъект владеет языком;
    • способность субъекта в приемлемые сроки породить подходящий язык или усовершенствовать существующий.

    2. Менеджмент качества: проблемы и языки

    Конкретная конфигурация проблемного и языкового полей - производная определения предметной области. В нашем случае (менеджмент качества) предметная область очерчена:

    1. сложившейся практикой;
    2. положениями Международных стандартов (МС) ISO серии 9000:2000 и, в частности, требованиями к системам менеджмента качества (СМК).

    Далее при ссылках на данную серию МС я буду использовать слово «Стандарты», а для ссылок на МС ISO 9001:2000 - слово «Стандарт».

    Сложившаяся практика обусловливает присутствие в проблемном поле таких семейств компонентов:

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

    Стандарты расширяют проблемное поле, требуя присутствия в СМК следующих компонентов:

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

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

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

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

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

    Проблемы автоматизации решаются с применением языков описания данных, программирования, интерфейсов и др.

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

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

    Можно ли конкретный вид деятельности, например, управление несоответствующим продуктом, описать (одним) алгоритмом? Скорее всего, нет. Но вполне можно допустить, что хорошее описание будет включать в себя некоторые алгоритмы - там, где они действительно нужны.

    Структура документированного Руководства по качеству определяется тем, какую роль оно играет для предприятия (например, рекламную, связующую между требованиями Стандарта и документами СМК, прямую реализацию требований Стандарта).

    Что касается документирования реализации «процессного подхода», то эту тему рассмотрим подробнее.

    3. «Лиха беда начало»

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

    Сравню проект СМК с кораблем, в котором, стоит ли он у причала, плывет ли, постоянно открываются все новые и новые течи (малые и большие языковые проблемы). Некоторые из них удается обнаружить вовремя, другие - нет. Множество протекающих трещинок удается надежно залепить мягким податливым материалом, например, воском (естественный язык). Этого материала почти достаточно и для более крупных отверстий. Но для остальных (пробоин!) нужно заранее запасаться специальными средствами (специализированными языками), либо пытаться их «имитировать» из подручных материалов и предметов (порождать специализированные языки самостоятельно).

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

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

    4. Идти «от процессов» или «к процессам»?

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

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

    Если процесс нетривиален, скорее всего, его модель будет представлять собой систему дополняющих друг друга и согласованных моделей.

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

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

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

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

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

    Приведу несколько примерных ситуаций, которые могут иметь место в действительности:

    • объект, являющийся выходом для одного процесса, может быть входом для другого процесса;
    • объект является для одного процесса одновременно и входом, и выходом. Кроме того, он является преобразователем входа в выход для другого процесса;
    • процесс является входом другого процесса.

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

    В идеале каждый объект или связь между объектами должны быть описаны один раз. Описание составного объекта должно содержать не описания подъобъектов, а лишь ссылки на них.

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

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

    5. Взрослые игры взрослых людей: моделирование деятельности

    Люди издавна строят модели различных объектов. Можно сказать, что моделирование - неотъемлемая составляющая человеческой деятельности.

    Модели создаются как для реально существующих, так и для не существующих объектов. Они могут выполнять функции игрушки, как символа, объекта исследования и др.

    Модель может быть материальной и информационной. Каждый из этих видов моделей имеет свои преимущества и недостатки.

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

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

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

    Особой разновидностью моделирования деятельности с целью ее автоматизации является программирование для компьютеров.

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

    6. Автоматизированное использование моделей деятельности

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

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

    7. Процедурное моделирование деятельности

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

    7.1. Программирование деятельности

    Своеобразной «точкой отсчета» при рассмотрении процедурного моделирования деятельности, на мой взгляд, целесообразно считать «программирование деятельности» А. Л. Фуксмана [Фуксман, 1979], которое зиждется на двух «китах»:

    1. полноценная система программирования, в центре которой находится язык программирования, обладающий рядом специальных свойств (средства описания типов реальных объектов, параллельных и альтернативных ветвей потока управления и др.);
    2. исполнительный механизм, автоматизирующий как выполнение имеющихся программ деятельности, так и ведение тех или иных записей о процессах их выполнения.

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

    Обычная компьютерная программа - всего лишь частный случай программы деятельности, допускающий свое тотальное выполнение на компьютере.

    Проиллюстрирую возможности программирования деятельности на примерах.

    Пример 1. Кулинарный рецепт

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

    Можно спорить, что лучше - рецепт или программа, но у последней есть один важный плюс: она надежно обеспечивает повторимость достижения определенного результата. Можно представить себе совокупность подобных программ могла как алгоритмическое ядро «электронного повара», способного вести кулинарный процесс любой сложности, в котором (при необходимости) задействованы и люди.

    Пример 2. Процедура регистрации предприятия

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

    • подробная типовая программа осуществления этого вида деятельности;
    • программа настройки типовой программы на условия конкретного применения (исходные данные о регистрируемом предприятии, адреса задействованных учреждений, режимы их работы, Ф.И.О. и контактные реквизиты ответственных лиц и т.д.).

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

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

    7.2. Интеграционная дефиниция

    Интеграционная дефиниция (Integration Definition - IDEF) представляет собой семейство взаимно дополняющих и поддерживающих друг друга методов и техник (языков) моделирования различных аспектов деятельности организации. В него наряду с другими языками (например, функционального, информационного моделирования) входит язык описания процессов (IDEF3) [IDEF3, 1995], который позволяет строить два основных вида схем:

    • собственно схемы процессов;
    • схемы изменения состояния объектов.

    Схемы обоих видов могут быть взаимоувязаны между собой.

    Для схем процессов основными строительными блоками являются:

    • так называемый «элемент поведения» (unit of behavior - UOB);
    • связи между «элементами поведения» по следованию;
    • соединения (слияние и ветвление) связей различных типов.

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

    7.3. Унифицированный язык моделирования

    Унифицированный язык моделирования (Unified Modeling Language - UML) [UML, 2001] возник на основе объектно-ориентированного подхода к программированию в результате осознания необходимости моделирования двух вещей - создаваемой «преимущественно программной системы» (ППС) и самого процесса создания ППС.

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

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

    Наиболее «созвучными» с идеей процедурного моделирования являются диаграммы деятельности, похожие на обычные блок-схемы, однако и они «не дотягивают» до уровня языка программирования. Это и понятно, поскольку диаграмма деятельности с самого начала рассматривается не как конечный продукт (программа), а как промежуточная модель, которая может привести к компьютерной программе, а может и не привести.

    На UML можно также создавать модели (а также метамодели) процессов другого рода; в них дается подробная картина классов объектов, входящих в процесс, и отношений между ними. Примером подобной метамодели является метамодель процесса разработки программного обеспечения (Software Process Engineering Metamodel - SPEM) [SPEM, 2001].

    Вообще говоря, модель системы на UML может насчитывать до четырех уровней абстракции: реализации модели (реальные сущности), модель, метамодель и мета-метамодель.

    В частности, UML используется при создании так называемого Rational Unified Process - перспективного типового процесса разработки ППС [Крачтен, 2002].

    8. Заключение

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

    Хотелось бы предостеречь конструкторов от самодеятельного языкотворчества. Можно ли в рамках проекта СМК для описания процессов попутно породить «с нуля» что-либо подобное IDEF3 по глубине проработки, уровню строгости и перспективам использования средств поддержки? Безусловно, нет. Не в языковой ли «самодеятельности» кроется одна из основных причин появления мертворожденных систем?

    Что же касается так называемых «практических» рекомендаций (типа «пишите на IDEF3, а не на UML»), то считаю себя не вправе делать их «здесь и сейчас». Уверен, что всех нас в ближайшее время ожидает напряженная работа по широкому обсуждению («В начале было Слово...») данной темы, а также по унификации (возможно, стандартизации) языков, разработке и внедрению доступных средств их поддержки.

    Общие же советы, основанные на изложенном выше, на данный момент таковы:

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

    Не сомневаюсь, что следование этим нехитрым советам оправдает себя сторицей.

    Список использованной литературы

    1. [Фуксман, 1979] Фуксман А. Л. Технологические аспекты создания программных систем. - М.: Статистика, 1979. - 184 с., ил.
    2. [IDEF3, 1995] Information Integration for concurrent engineering (IICE). IDEF3 Process description capture method report. - Knowledge based systems, Inc. - September 1995. - 218 p.
    3. [UML, 2001] OMG Unified Modeling Language Specification. Version 1.4. -September 2001. - 566 p.
    4. [SPEM, 2001] Software Process Engineering Metamodel Specification. OMG Adopted Specification. - December 2001. - 108 p.
    5. [Крачтен, 2002] Крачтен Ф. Введение в Rational Unified Process. 2-е изд.: Пер. с англ. - М.: Издательский дом «Вильямс», 2002. - 240 с.: ил. - Парал. тит. англ.

    О. В. Малышев, к.т.н.





  • размещено в разделе: Школа качества
  • Автор: cir


  • найти еще статьи по теме:
      

    менеджмент качества ( процессы | школа качества | нормирование | управление качеством | хассп)
    книги: стандарты | качество | ХАССП | маркетинг | торговля
    управленческий консалтинг ( планирование и контроль | конфликтменеджмент)
    новости и события: пресс-релизы | новые стандарты | новости партнеров | новости | архив новостей, статей
    новая торговля (автоматизация | магазиностроение | маркетинг и экономика)
    интернет-маркетинг (создание сайта | интернет - бизнес)
    финансы & страхование (страхование | бизнес-школа)
    обзоры и интервью: маркетинг | консалтинг | торговля | управление качеством )
    энциклопедия: это интересно | глоссарий | о семье | менеджмент семьи | каталог ресурсов