Менеджмент

Рефераты

Скачать

НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ КОМИТЕТ ПО СТАНДАРТИЗАЦИИ

«УПРАВЛЕНИЕ КАЧЕСТВОМ»

МЕТОДИКА И ПОРЯДОК РАБОТ ПО ОПРЕДЕЛЕНИЮ, КЛАССИФИКАЦИИ И ИДЕНТИФИКАЦИИ ПРОЦЕССОВ И ПОСТРОЕНИЮ КАРТ ПРОЦЕССОВ

МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ

ТК РБ 4.2-Р-05-2001

Издание НЕофициальное

Минск

Ключевые слова: система менеджмента качества, процессный подход, процесс, моделирование процессов, определение процесса, классификация процессов, идентификация процессов, карта процесса, методология IDEF0

Предисловие

1.                                                      1.      РАЗРАБОТАН _________________________________
ВНЕСЕН Национальным техническим комитетом по стандартизации «Управление качеством»

СОДЕРЖАНИЕ

Область применения

Нормативные ссылки

Общие положения

Объекты менеджмента организации

Процессный подход

ПОРЯДОК ПРОВЕДЕНИЯ РАБОТ ПО ОПРЕДЕЛЕНИЮ, КЛАССИФИКАЦИИ И ИДЕНТИФИКАЦИИ ПРОЦЕССОВ

ВВЕДЕНИЕ

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

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

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

Лоббируемые на рынке Республики Беларусь западные информационные технологии менеджмента качества (QFD, FMEA, QLF, VE и др.) ставят зачастую в тупик руководство и службы качества предприятий: приобретать – не приобретать; если приобретать, куда и как внедрять. При этом вряд ли будет достигнут ожидаемый эффект от подобного рода разовых мероприятий, так как это напоминает латание "тришкиного кафтана". Для эффективного решения проблем качества в отношении методов и средств на наш взгляд необходим именно последовательный комплексный подход. Его еще называют принципом «кайцен» - постепенное, поэтапное проведение улучшений.

Итак, с чего начать? Какие информационные технологии, в каких направлениях деятельности компании необходимы в первую очередь? Начинать надо с базиса – определения сети процессов организации, определяющих качество конечной продукции. Это требование международных стандартов ИСО семейства 9000, регламентирующих требования к системам менеджмента качества.

Данный документ является результатом адаптации современных технологий моделирования бизнес - процессов к требованиям стандартов ИСО семейства 9000 версии 2000 года.

Цель настоящего документа – внедрение современных эффективных информационных технологий менеджмента качества на предприятиях Республики Беларусь.

Область применения

Настоящие методические рекомендации содержат методику и порядок проведения работ по моделированию процессов - определению, классификации и идентификации, и построению карт процессов в рамках систем менеджмента качества, соответствующих требованиям стандартов ИСО семейства 9000 версии 2000 года.

Нормативные ссылки

В настоящем руководящем документе использованы ссылки на следующие нормативные документы:

1.                                                1.          Международный стандарт ИСО 9000. Системы менеджмента качества. Основные положения и словарь. 2-е изд. 2000-12-15. ISO - 2000.

2.                                                2.          Международный стандарт ИСО 9001. Системы менеджмента качества. Требования. 3-е изд. 2000-12-15. ISO - 2000.

3.                                                3.          Международный стандарт ИСО 9004. Системы менеджмента качества. Руководство по улучшению деятельности. 2-е изд. ISO - 2000.

4.                                                4.          РД IDEF0-2000. Методология функционального моделирования IDEF0. М.: Госстандарт России, 2000.

Определения

< Есть в официальном издании >

Общие положения

Объекты менеджмента организации

Менеджмент – это скоординированная деятельность по руководству и управлению организацией [1, пункт 3.3.1].

Для успешного руководства и управления организацией необходимо, чтобы менеджмент осуществлялся систематически и наглядным способом. Успех должен быть результатом внедрения и поддержания в рабочем состоянии системы менеджмента, спроектированной для постоянного улучшения деятельности посредством акцентирования внимания на запросы всех заинтересованных сторон [3].

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

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

·                                                        ·        сеть процессов, с помощью которых организация выполняет свою миссию;

·                                                        ·        совокупность источников и каналов связи потоков информации и типов данных;

·                                                        ·        организационная структура;

·                                                        ·        инфраструктура (территории, здания, сооружения, коммуникации);

·                                                        ·        и т.д.

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

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

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

Рис. 1. Многообразие форм проявления объекта («фасетный» подход обеспечения «прозрачности»)

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

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

Процессный подход

Эффективный менеджмент качества можно представить условно как совокупность двух элементов:

·                 ·     хорошо структурированная система качества, как совокупность организационной структуры, методик, ресурсов;

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

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

Система качества выступает в роли базиса, а постоянно действующие процедуры руководства качеством основных процессов выступают в роли надстройки, поддерживающей активную жизнедеятельность организации (конкурентоспособность). Причем надстройка предполагает прежде всего комплексное решение задач планирования, обеспечения, управления и улучшения качества каждого процесса и сети процессов в целом, образующих так называемый цикл управления ”p-d-c-a”. В свою очередь каждый этап цикла ”p-d-c-a”, базируется на развертывании подсистемы сбора, анализа и обобщения данных о качестве, выработки и принятии решений, организации корректирующих и предупреждающих воздействий и контроля их эффективности. В результате менеджмент качеством в организации представляет собой довольно сложную систему взаимосвязанных процедур, «обслуживающих» сеть процессов, определяющих качество конечной продукции. Этот аспект особо подчеркивается и положен во главу угла в проектах стандартов ИСО семейства 9000 версии 2000 года.

Следует отметить, что сеть процессов и процесс – понятия условно относительные и определяются целым рядом факторов:

·                                                  ·        целями классификации и описания;

·                                                  ·        точкой зрения того, кто их определяет;

·                                                  ·        контекстом;

·                                                  ·        другими факторами.

В принципе любой процесс может быть детализирован в виде компонентов (подпроцессов) и взаимодействий между ними, т.е. в виде сети подпроцессов. С другой стороны, он может входить отдельным компонентом в сеть процессов более высокого уровня ( REF _Ref520634677 \h <![endif]>

<![endif]>

Рис. 2).

<![endif]>

Рис. 2. Сеть процессов и детализация процессов с помощью карт процессов

Основу представления организации (системы) представляет процесс (Рис. 3). Согласно [1, пункт 3.4.1], процесс - «совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующая входы в выходы.

ПРИМЕЧАНИЕ 1. Входами к процессу обычно являются выходы других процессов.

ПРИМЕЧАНИЕ 2. Процессы в организации, как правило, планируются и осуществляются в управляемых условиях с целью добавления ценности».

В [4] приведено следующее схематическое представление процесса (Рис. 3).

Рис. 3. Схематическое представление процесса в [4]

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

Входы и выходы процесса могут быть как материальными, так и нематериальными (например, информационными) объектами. Примерами входов и выходов являются: оборудование, материалы, компоненты, энергия, информация, финансовые ресурсы, документы и т.п.

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

На Рис. 3 также показано, что контролировать и производить необходимые измерения следует на различных стадиях: до, во время и после исполнения процесса.

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

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

Применение в организации системы процессов, наряду с их идентификацией и взаимодействием, а также менеджмент процессов могут считаться «процессным подходом»[3].

Преимущество данного процессного подхода заключается в «тотальном управлении, которое охватывает как отдельные процессы внутри системы процессов, так и их комбинации и взаимодействия [3]. Причем очень существенна «…непрерывность управления» [1], которую процессный подход обеспечивает на стыке между отдельными процессами в рамках системы процессов, а также при их комбинации и взаимодействии.

При применении в системе менеджмента качества такой подход подчеркивает важность:

а) понимания требований и соответствия им;

б) необходимости рассмотрения процессов с точки зрения добавленной ценности;

в) достижения результатов выполнения процессов и их результативности;

г) постоянного улучшения процессов, основанного на объективном измерении.[2]

<![endif]>

Рис. 4. Идеология процессного подхода в соответствии с МС ИСО семейства 9000 версии 2000 года

Способы описания процессов

Имеет место ряд требований стандартов ИСО семейства 9000, в которых предписано, что организация могла бы повышать эффективность своей системы менеджмента качества и демонстрировать ее соответствия стандартам, разрабатывая и поддерживая в рабочем состоянии ряд документов, непосредственно не предписанных ИСО 9001:2000. Среди них на первом плане – карты процессов, блок – схемы процессов, описания процессов [4]. При этом организация должна определить в отношении каждого процесса следующие моменты:

·                       ·     Определить иерархию потока процессов;

·                       ·     Способ описания процессов (карты процессов или блок – схемы);

·                       ·     Каналы связи между процессами;

·                       ·     Необходимость документирования процессов [4].

Моделирование как формализованная форма описания объектов

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

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

Модель дает полное и точное и адекватное описание системы и имеет конкретное назначение. Целью создания модели является получение ответов на некоторую совокупность вопросов. Именно эти вопросы руководят созданием модели и направляют его.

«М» моделирует систему «С», если «М» отвечает на вопросы относительно «С» с точностью «Т».

Если модель отвечает не на все вопросы, или ее ответы не точны, считается, что модель не достигла поставленной цели. Качество модели оценивается степенью полноты ответов на поставленные вопросы.

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

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

Соответственно различные представления организации или системы (Рис.1) могут быть описаны соответствующими моделями, отвечающими на конкретные вопросы. Функциональная модель представляет описание с требуемой степенью детализации сети процессов, например, с целью их планирования, обеспечения, управления и улучшения. Модели данных (информационные модели) представляют собой подробное описание объектов и типов информации и данных, например, с целью оптимизации и последующей автоматизации и т.д.

Функциональное моделирование деловых процессов.

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

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

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

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

Для описания процессов в мире разработано большое количество различных подходов и методов. Так, еще в начале 70-х годов Д. Росс в США предложил метод структурного проектирования и анализа систем SADT (Structured Analysis and Design Techniques) [5]. В основе этого подхода лежит графический язык описания (моделирования) систем.

В середине 70-х ВВС США реализовало программу интегрированной компьютеризации производства ICAM (Integrated Computer Aided Manufacturing). В рамках этой программы были разработаны методы проектирования и анализа сложных производственных систем, а также способы обмена информацией между специалистами, занимающимися такмими проблемами. Для удовлетворения этих потребностей в рамках программы ICAM была разработана методология IDEF (ICAM Definitions), позволяющая представить и исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем. Процессы, описывающие деятельность организации, относятся именно к этому классу систем.

В настоящее время общая методология IDEF включает ряд частных методологий для моделирования систем, в том числе:

·                                                        ·        IDEF0 – функциональное моделирования

·                                                        ·        IDEF1 – информационное моделирование

·                                                        ·        IDEF1X – моделирование данных

·                                                        ·        IDEF3 – моделирование процессов

·                                                        ·        IDEF4 – объектно-ориентированное проектирование и анализ

·                                                        ·        IDEF5 – определение онтологий (словарей)

·                                                        ·        IDEF9 – моделирование требований

В 1993 году методология IDEF0 была утверждена в качестве федерального стандарта США для функционального моделирования [6].

В 2000 году Госстандарт России принял Руководящий документ «Методология функционального моделирования IDEF0» для целей реинжиниринга деловых процессов и процессов менеджмента качества [7].

В настоящее время методология IDEF0 рассматривается ИСО на предмет международного стандарта IPS (стандарты по обработке информации).

Для описания процессов в рамках системы менеджмента качества наибольший интерес представляет собой методология функционального моделирования IDEF0. Её рациональность предопределена целым рядом обстоятельств, главным из которых является следующее. В основе IDEF0-методологии лежит понятие блока, моделирующего определенную «бизнес-функцию», которая преобразует «вход» в «выход», руководствуясь «управление» (документы), используя «механизм» (материально – технические, людские и др. ресурсы) (Рис. 5). Очевидно, что методологические подходы IDEF0 и менеджмента качества, как управления сетью процессов в организации в соответствии с требованиями ИСО 9001:2000, идентичны, что очень важно и привлекательно, например, для целей сертификации.

<![endif]>

Рис. 5. Концепции управления процессами в соответствии с МС ИСО семейства 9000 (а) и концепция моделирования процессов IDEF0 (б).

Примечание - Можно позволить себе такую интерпретацию преимущества IDEF0 –подхода к описанию процессов по сравнению с традиционным (для промышленных предприятий). Предположим необходимо разработать проект изделия – вала (в виде информации о нем). Это можно сделать двумя путями:

·                    ·        Первый – описание вала словами, типа: …тело цилиндрической формы с n ступенями. Левая ступень имеет диаметр…. и т.д. со словесным изложением конструктивных особенностей (фасок, канавок, галтелей и т.п.), требований к размерам, форме, расположению, шероховатости, материалу.

·                    ·        Второй – графическое изображение вала в виде чертежа, выполненного в соответствии с определенными правилами –ЕСКД.

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

Если провести параллель описания процессов в рамках систем качества с такой аналогией, то:

·                    ·        Первый подход – традиционный подход описания процессов в виде стандартов, методик, инструкций.

·                    ·        Второй подход  - графическое изображение сети процессов с интегрированным первым подходом.

Фигурально выражаясь, IDEF0 – это аналог ЕСКД (ЕСТД) для разработки  и идентификации сети процессов компании в рамках системы качества, позволяющая сделать проект системы качества как сети процессов более наглядным (прозрачным), увязанным, «готовым» к регулярному анализу (управлению, улучшению).

Классификация процессов

«Познание» системы менеджмента качества посредством функционального моделирования – описания сети процессов - необходимо начинать с классификации процессов.

Существует целый ряд соображений. Это определяется, прежде всего, целями моделирования:

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

2.                  2.      Процессы имею разную природу и по-разному влияют на качество конечной продукции: производственные процессы – прямое влияние; процессы управления – опосредованное (хотя может быть и наоборот).

3.                  3.      Для различных по сущности своей процессов удобство их описания и управления требует различных алгоритмов (правил) описания.

Примечание. - Распределение ответственности между участниками деятельности (иерархия управления – иерархия процессов), компетенция участников. Управляют теми процессами, в которых компетентны.

4.                  4.      Формализация процессов для их автоматизированного управления.

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

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

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

Рис. 6. Классификация деловых процессов организации по признаку управления

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

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

Процессы менеджмента качества относятся к категории процессов «внутреннего управления».

В системах менеджмента качества[2, 3] используется несколько различных классификаций, среди которых можно выделить:

1.                                                      1.      Классификация процессов;

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

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

В системе менеджмента качества выделяют следующие классы процессов [1, 4] (рис. 7):

1.                                                      1.      Процессы высшего руководства;

2.                                                      2.      Процессы менеджмента ресурсов

3.                                                      3.      Процессы жизненного цикла продукции

4.                                                      4.      Процессы измерения, анализа и улучшения.

5.                                                      5.      Процессы системного уровня (процессы собственно системы качества).

Примечание - Процесс в нотации «как есть» - не всегда добавляет ценность продукту на выходе. Такие процессы по результатам анализа являются объектом улучшения.

Системный подход к менеджменту качества

Еще один важный принцип, положенный в основу системы менеджмента качества, - это системный подход к менеджменту качества как к менеджменту процессов организации. В [2] этот принцип определен следующим образом:

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

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

Рис. 7. Классификация типовых деловых процессов в рамках системы менеджмента качества в соответствии требованиями ИСО 9001:2000

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

Идентификация – это установление совпадения, идентичности процессов и их компонентов в организации.

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

Идентификация процесса может осуществляться, например:

·                              ·       уникальным названием процесса

·                              ·       с помощью маркировки - присвоения уникального идентификационного номера и др.

Взаимодействие процессов

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

Рис. 8. Интерпретация системного подхода к менеджменту качества как к руководству сетью процессов организации.

Обратная связь от потребителя (степень удовлетворенности или неудовлетворенности результатом процесса) является существенным входом процесса постоянного улучшения процессов системы менеджмента качества. Следует отметить, что цикл «p-d-c-a» применим к каждому отдельному процессу и к сети процессов в целом.

Примечание. – Некоторые важные процессы системы менеджмента качества могут не иметь непосредственного взаимодействия с внешним потребителем. Например, процесс «F» на рис. 8 ( внутренний аудит, анализ со стороны руководства, процесс обучения персонала и др.) непосредственно «не соединен» входами с процессами, непосредственно ориентированных с внешним потребителем. Тем не менее, такие процессы входят в сеть процессов системы качества и должны быть объектами руководства и управления. [4].

Динамика развития функциональной модели процесса

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

Построение модели КАК ЕСТЬ

Обследование сети процессов является обязательной частью любого проекта создания или развития системы менеджмента качества. Построение функциональной модели КАК ЕСТЬ позволяет четко зафиксировать, какие процессы осуществляются на предприятии, какие информационные объекты используются при выполнении процессов различного уровня детализации. Функциональная модель КАК ЕСТЬ является отправной точкой для анализа потребностей предприятия, выявления проблем и “узких” мест и разработки проекта совершенствования деловых процессов.

Бизнес- правила

Модель процессов позволяет выявить и точно определить бизнес- правила, используемые в деятельности предприятия.

На рис. 9 представлен фрагмент функциональной модели документооборота. При выполнении процесса “сортировать документы” используется бизнес-правило: “регистрации не подлежат: документы, присланные в копии для сведения, телеграммы и письма о разрешении командировок и отпусков ...”. Это правило зафиксировано в инструкции по документообороту. Функциональная модель позволяет не только идентифицировать существование этого правила, но также определить, при выполнении какой операции и на каком рабочем месте оно должно применяться.

Рис. 9. Карта процесса в виде диаграммы IDEF0 в нотации «КАК ЕСТЬ»

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

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

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

Построение модели КАК БУДЕТ

Создание и внедрение корпоративной информационной системы приводит к изменению условий выполнения отдельных операций, структуры деловых процессов и предприятия в целом. Это приводит к необходимости изменения системы бизнес- правил, используемых на предприятии, модификации должностных инструкций сотрудников. Функциональная модель КАК БУДЕТ позволяет уже на стадии проектирования будущей информационной системы определить эти изменения. Применение функциональной модели КАК БУДЕТ позволяет не только сократить сроки внедрения информационной системы, но также снизить риски, связанные с невосприимчивостью персонала к информационным технологиям.

Дополнительные функции и возможности при построении модели процессов в нотации «КАК ЕСТЬ»:

·              ·      Функциональная модель позволяет идентифицировать все информационные объекты, которыми оперирует предприятие в своей деятельности. В отличие от информационных моделей (Data Flow Diagrams, IDEF1X) функциональная модель IDEF0 отражает, как именно используются информационные объекты в рамках деловых процессов.

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

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

МЕТОДИКА ОПРЕДЕЛЕНИЯ, КЛАССИФИКАЦИИ И ИДЕНТИФИКАЦИИ ПРОЦЕССОВ

Общие положения

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

В результате применения методики создается комплект документов, включая:

·                                                        ·        Перечень процессов организации;

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

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

Методика определения, классификации и идентификации процессов включает следующие этапы:

1.                                                      1.      Построение функциональных моделей процессов;

2.                                                      2.      Классификация и анализ процессов с точки зрения системы менеджмента качества;

3.                                                      3.      Идентификация и документирование процессов.

Построение функциональной модели процесса

Контекст, точка зрения и цель модели процесса

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

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

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

Примечание 1. Следует помнить, что одна модель представляет одну точку зрения и преследует поставленную цель именно с этой единственной точки зрения. Для моделирования системы с нескольких точек зрения используется несколько моделей.

Примечание 2. Цель построения модели кажого конкретного процесса, как правило, согласована с общей целью – ответа на вопросы в рамках системы менеджмента качества.

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

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

Примечание 2. Общей целью моделей является система менеджмента качества.

Рассмотрим обобщенный процесс «Производить партию продукции».

Контекст модели – границы процесса – определяется следующим образом:

Входами процесса являются:

·                                                        ·        Спецификации заказа на партию продукции,

·                                                        ·        Исходные материалы со склада,

Выходами процесса являются:

·                                                        ·        Готовая продукция, предназначенная для отправки на склад,

·                                                        ·        Записи качества, создаваемые на различных стадиях процесса.

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

Цель моделирования – отразить структуру процесса производства партии продукции и его соотвтествие требованиям системы менеджмента качества.

Точка зрения – Начальник управления качества.

Процессы и Блоки. Дуги

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

Процесс всегда выражается активным глагольным оборотом:

глагол + объект действия + [дополнение].

Глагол отвечает на вопрос: “Что делать?” Объект действия отвечает на вопрос: “Что?” А дополнение может служить для уточнения функции.

Обрабатывать деталь на станке, передать документы в отдел А, разработать план-график проведения аудита, составить протокол испытаний и  т.д.

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

«публикация», «проведение», «обработка»...

Дуги XE "Дуга"  служат для отображения информационных или материальных объектов, которые необходимы для выполнения функции или появляются в результате ее выполнения (объекты, обрабатываемые в процессе). За каждой Дугой закрепляется Замечание, которое отображает суть объекта. Замечание формулируется в виде оборота существительного, отвечающего на вопрос: “Что?”

Рис. 10. Дуги, как ограничивающие и уточняющие факторы Блока

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

Дуга, входящая в левую сторону Блока является Входной Дугой XE "Дуга: Входная Дуга" . Дуга, выходящая из правой стороны Блока – Выходная Дуга XE " Дуга: Выходная Дуга" . Выходные Дуги служат для отображения объектов, полученных в результате выполнения процесса. Таким образом “вход” превращается в “выход” (слева направо).

Дуга управления XE " Дуга: Дуга управления"  входит в верхнюю границу Блока и служит для отображения условий, которые управляют (влияют) исполнением процесса, накладывая некоторые условия, при которых возможно выполнение этого процесса. Частным случаем управления в процессе в рамках системы менеджмента является задокументированная процедура, которая регламентирует условия выполнения процесса. Каждый Блок должен иметь, как минимум, одну управляющую Дугу.

Дуги механизмов XE " Дуга: Дуга механизмов"  присоединяются к нижней границе Блока и служат для отображения человека или другого ресурса, непосредственно исполняющего процесс, описанный внутри Блока.

Рис. 11. Структура Дуг, присоединяемых к Блоку

Диаграмма (карта) Процесса

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

Неоднозначность описаний устраняется за счет:

·                                                        ·        стандартизации интерпретации графических обозначений. Так, например Рис. 11 интерпретируется следующим образом: «Процесс 1 преобразует Вход в Выход при выполнении условий, заданных в Управление с помощью Механизм;

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

В рамках методологии IDEF0 модель процесса описывается при помощи Графических IDEF0 Диаграмм и уточняется за счет использования дополнительных Текстовых Диаграмм и Диаграмм Глоссария. При этом модель включает в себя серию взаимосвязанных Диаграмм, разделяющих сложную систему на составные части. Диаграммы более высокого уровня (А-0, А0,) – являются наиболее общим описанием процесса, представленным в виде отдельных Блоков. Декомпозиция этих Блоков на других Диаграммах позволяет достигнуть требуемый уровень детализации описания процесса.

На Рис. 12 представлена диаграмма (карта) процесса производства партии продукции верхнего уровня.

Рис. 12. Диаграмма А-0. Обобщенное представление процесса

На этой диаграмме процесс производства партии продукции представляется одним блоком.

Принцип иерархической декомпозиции

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

Рис. 13. Иерархическая декомпозиция Диаграмм

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

Разработка IDEF0 Диаграмм начинается с построения самого верхнего уровня иерархии (А-0) – одного Блока и интерфейсных Дуг, описывающих внешние связи рассматриваемой системы. Имя функции, записываемое в Блоке 0, является общей функцией системы с принятой точки зрения и цели построения модели.

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

В свою очередь, функциональные Блоки на Диаграмме А0 могут быть также декомпозированы для более детального представления. При этом интерфейсные Дуги, присоединенные к Блоку, переносятся на Диаграмму-потомок (через ICOM коды). Таким образом родительский Блок и его интерфейсные Дуги определяют контекст для Диаграммы-потомка.

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

Декомпозиция процесса «Произвети партию продукции» позволяет представить внутреннюю структуру процесса, т.е. под-процессы, из которых состоит процесс производства партии продукции, а также взаимосвязи между ними. Декомпозиция процесса представлена на Рис. 14.

Рис. 14. Диаграмма А0. Детализация процесса «Произвести партию продукции»

В соответствии с диаграммой А0 процесс производства партии продукции состоит из четырех под-процессов:

1.                                                      1.      Составить производственные задания

2.                                                      2.      Произвести продукцию

3.                                                      3.      Произвести (подготовить) тару

4.                                                      4.      Упаковать продукцию

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

Производственные задания служат основанием (управлением) для выполнения остальных процессов (процессы 2-4).

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

Классификация процессов

Цели классификации процессов изложены в разделе 0 настоящего документа. В этом разделе представлена процедура классификации применительно к функциональной модели процесса.

Процедура классификации

Процедура классификации состоит в том, чтобы процессы, определенные в рамках деятельности предприятия, отнести к одной из заданных в стандартах ИСО 9000:2000 категорий. Другими словами, классифицировать процесс означает определить, к какой из категорий относится рассматриваемый процесс.

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

Виды классификаций

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

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

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

Категории процессов

В стандартах ИСО серии 9000 версии 2000 года определены следующие категории процессов, относящихся к системе менеджмента качества (Рис. 7):

·                                                        ·        Процессы системы менеджмента качества

·                                                        ·        Процессы высшего руководства

·                                                        ·        Процессы управления ресурсами

·                                                        ·        Процессы реализации продукции и услуг (жизненного цикла продукции)

·                                                        ·        Процессы измерения, анализа и улучшения

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

< Есть в официальном издании

Рассмотрим функциональную модель процесса «производить партию продукции» (диаграмма А0, Рис. 13). Представленный на этой диаграмме под-процесс «составить производственные задания» относится к категории «ответственность руководства»; под-процессы «произвести продукцию» и «упаковать продукцию» относятся к категории «процессы жизненного цикла продукции»; под-процесс «произвести (подготовить) тару» может быть отнесен к категории «менеджмент ресурсов». На Рис. 15 представлена диаграмма А0, которая демонстрирует декомпозицию  процесса «произвести партию продукции».

Рис. 15. Процессы различной категории

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

Категории связей между процессами

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

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

Рис. 16. Определить требования к продукции

Раздел 7.2.2 стандарта ИСО 9001:2000 определяет, что требования к продукции должны быть определены; специфические требования, которые отличаются от ранее сформулированных, должны быть согласованы с потребителем и соответствующими подразделениями организации; изменения требований должны фиксироваться.

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

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

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

·                                                        ·        утверждение согласованных требований и их передача в подразделения.

Все перечисленные процедуры относятся к процессам жизненного цикла продукции.

Особое внимание следует обратить на различные способы обработки типовых и специфических требований потребителя к продукции. Типовые требования не требуют специального согласования с подразделениями или потребителем, т.к. они являются фиксированными с точки зрения огранизации и потребителя. Например, напряжение сети для электрочайника – 220 вольт +/- 5%.

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

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

Правила классификации процессов по взаимодействию

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

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

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

< Есть в официальном издании

ПОРЯДОК ПРОВЕДЕНИЯ РАБОТ ПО ОПРЕДЕЛЕНИЮ, КЛАССИФИКАЦИИ И ИДЕНТИФИКАЦИИ ПРОЦЕССОВ

Общие положения

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

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

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

Поддержка коллективной работы

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

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

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

При разработке проекта авторы на основе знаний, полученных от экспертов, строят первоначальные Диаграммы (уровень РАБОЧАЯ ВЕРСИЯ), которые впоследствии передаются через библиотекаря другим участникам проекта для рассмотрения и анализа (см. рисунок 2.3.3.8). Читатели (рецензенты) формулируют свои замечания и комментарии в письменной форме и через библиотекаря передают их автору. Библиотекарь в свою очередь фиксирует все изменения в архиве проекта и отвечает за своевременность передачи папок с комментариями как автору, так и читателям. Предложения по внесению изменений принимаются или отвергаются с письменным указанием причины.

Примечание – Изменения, вносимые рецензентами, самим автором, регистрируются для целей идентификации и прослеживаемости при разработке карты процесса.

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

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

Окончательная модель содержит согласованное представление моделируемой системы с конкретной точки зрения и определенной целью. Модель, имеющая статус ПУБЛИКАЦИЯ, может использоваться в дальнейшем как для анализа работы системы, так и для организации проектов, связанных с модификациями рассмотренной системы.

Порядок построения модели процесса

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

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

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

Построение контекстной Диаграммы

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

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

Выбор цели осуществляется с учетом вопросов, на которые должна ответить модель, а выбор точки зрения – в соответствии с выбранной позиции, с которой будет описываться система. Дуги на Диаграмме А-0 описывают взаимодействие рассматриваемой системы с окружающей средой. Таким образом, Диаграмма с единственным Блоком является наиболее общим описание системы и определяет контекст XE "Диаграмма:Контекстная"  для всей будущей модели.

Построение Диаграмм

Хотя вершиной модели является Диаграмма уровня А-0, настоящей “рабочей вершиной” является Диаграмма А0, поскольку она является уточненным выражением точки зрения модели. Ее содержание показывает, что будет рассматриваться в дальнейшем, ограничивая последующие уровни в рамках цели проекта. Нижние уровни уточняют содержание функциональных Блоков, детализируя их, но не расширяя границ модели.

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

При детализации, декомпозируя каждый Блок Диаграммы А0, необходимо более подробно отражать то, что представлено на родительском Блоке. Это может потребовать дополнительного сбора информации о моделируемой системе. Поэтому, сделав предварительный эскиз Диаграммы-потомка, необходимо перечислить все объекты и уточнить перечень функций, выполнения которых обеспечит выполнение функции, описанной в родительском Блоке.

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

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

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

Выбор Блока для декомпозиции

Перед декомпозицией Блоков родительской Диаграммы необходимо очень хорошо проработать ее Блоки, чтобы свести до минимума повторную работу при возможных изменениях в Диаграммах верхних уровней. Опираясь на хорошо проработанную Диаграмму А0, необходимо сосредоточиться на построении Диаграмм А1, А2, А3..., не пытаясь максимально декомпозировать одну функцию, строя, например, Диаграммы А11, А111 или А21, А211.

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

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

Резюме

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

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

Порядок классификации процессов

< Есть в официальном издании >

Порядок идентификации процессов

< Есть в официальном издании >

ПЕСПЕКТИВЫ ПРИМЕНЕНИЯ ФУНКЦИОНАЛЬНЫХ МОДЕЛЕЙ СИСТЕМАХ МЕНЕДЖМЕНТА КАЧЕСТВА

< Есть в официальном издании >

ЗАКЛЮЧЕНИЕ

< Есть в официальном издании >

БИБЛИОГРАФИЯ

1.                                                      1.      Международный стандарт ИСО 9000. Системы менеджмента качества. Основные положения и словарь. 2-е изд. 2000-12-15. ISO - 2000.

2.                                                      2.      Международный стандарт ИСО 9001. Системы менеджмента качества. Требования. 3-е изд. 2000-12-15. ISO – 2000.

3.                                                      3.      Международный стандарт ИСО 9004. Системы менеджмента качества. Руководство по улучшению деятельности. 2-е изд. ISO – 2000.

4.                                                      4.      ISO 9000 Introduction and Support Package: Guidelines on the Process Approach to quality management systems. ISO/TC 176/SC 2/N 544R. 17 May, 2001.

5.                                                      5.      Давид Марка, Клемент МакГоуэн. Методология структурного анализа и проектирования. Пер . с англ . М .:1993, 240 с ., ISBN 5-7395-0007-9

6.                                                      6.      INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0). Draft Federal Information Processing Standards Publication 183, 1993, December 2

7.                                                      7.      РД IDEF0 – 2000. Методология функционального моделирования IDEF0. М.: Госстандарт России, 2000.

8.                                                      8.      Рахлин К.М. МС ИСО серии 9000 версии 2000 г .: сущность и содержание процессного подхода. М.: Стандарты и Качество, №3, 2001.

ПРИЛОЖЕНИЕ А.
Синтаксис языка моделирования IDEF0

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

Блоки представляют функции, определяемые как деятельность, процесс, операция, действие или преобразование (см. ниже). Стрелки представляют информационные или материальные объекты, связанные с функциями. Правила определяют, как следует применять компоненты; диаграммы обеспечивают формат графического и словесного описания моделей. Формат образует основу для управления конфигурацией модели.

Блок

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

Рис. 17. Синтаксис Блока

Синтаксические правила для блоков включают:

·                                                        ·        Размеры блоков должны быть достаточными для того, чтобы включать имя блока и номер блока.

·                                                        ·        Блоки должны быть прямоугольниками, с прямыми углами.

·                                                        ·        Блоки должны бытиь нарисованы сплошными линиями.

Стрелка

Стрелка формируется из одного или более сегментов (отрезков) и наконечника на одном конце. Как показано на Рис. 18, сегменты стрелки могут быть прямыми и ломанными; в последнем случае горизонтальные и вертикальные отрезки стрелки сопрягаются под углом 90⁰. Стрелки не представляют поток или последовательность событий, как в традиционных блок-схемах потоков или процессов. Они лишь показывают, какие информационные или материальные объекты должны поступить на вход функции для того, чтобы эта функция могла выполняться.

Рис. 18. Синтаксис Стрелки

Синтаскические правила для стрелок включают:

·                                                        ·        Ломанные стрелки изменяют направление только под углом 90⁰.

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

·                                                        ·        Стрелки могут состоять только из вертикальных и горизонтальных сегментов; сегменты, направленные по диагонали, не допускаются.

·                                                        ·        Концы стрелок должны касаться внешней границы блока, но не должны пересекать его.

·                                                        ·        Стрелки должны присоединяться к блоку на его сторонах. Присоединение в углах не допускается.

Диаграмма

IDEF0-модели состоят из трех типов документов: графических диаграмм, текста и глоссария. Эти документы имеют перекрестные ссылки друг на друга. Графическая диаграмма – главный компонент IDEF0-модели, содержит блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения. Блоки представляют основные функции моделируемого объекта. Эти функции могут быть разбиты (декомпозированы) на составные части и представлены в виде более подробных диаграмм; процесс декомпозиции продолжается до тех пор, пока объект не будет описан на уровне детализации, необходимом для достижения целей конкретного проекта. Диаграмма верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. За этой диаграммой следует серия дочерних диаграмм, дающих более детальное представление об объекте.

Контекстная диаграмма верхнего уровня

Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется A-0 (А минус нуль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку единственный блок представляет весь объект, его имя – общее для всего проекта. Это же справедливо и для всех стрелок диаграммы, поскольку они представляют полный комплект внешних интерфейсов объекта. Диаграмма A-0 устанавливает область моделирования и ее границу . Пример диаграммы A-0 показан на Рис. 19.

Рис. 19. Пример диаграммы А-0

Контекстная диаграмма A-0 также должна содержать краткие утверждения, определяющие точку зрения должностного лица или подразделения, с позиции которого создается модель, и цель, для достижения которой ее разрабатывают. Эти утверждения помогают руководить разработкой модели и ввести этот процесс в определенные рамки. Точка зрения определяет, что и в каком разрезе можно увидеть в пределах контекста модели. Изменение точки зрения приводит к рассмотрению других аспектов объекта. Аспекты, важные с одной точки зрения, могут не появиться в модели, разрабатываемой с другой точки зрения на тот же самый объект.

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

Дочерняя диаграмма

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

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

Родительская диаграмма

Родительская диаграмма – та, которая содержит один или более родительских блоков. Каждая обычная (не-контекстная) диаграмма является также дочерней диаграммой, поскольку, по определению, она подробно описывает некоторый родительский блок. Таким образом, любая диаграмма может быть как родительской диаграммой (родительские блоки), так и дочерней (описывать собственный родительский блок). Аналогично, блок может быть как родительским (описываться дочерней диаграммой) так и дочерним (на дочерней диаграмме). Основное иерархическое отношение существует между родительским блоком и дочерней диаграммой, которая его подробно описывает (Рис. 20).

Рис. 20. Структура декомпозиции блоков

То, что блок является дочерним и раскрывает содержание родительского блока на диаграмме предшествующего уровня, указывается специальным ссылочным кодом, написанным ниже правого нижнего угла блока. Этот ссылочный код может формироваться несколькими способами, из которых самый простой заключается в том, что код, начинающийся с буквы А (по имени диаграммы А-0), содержит цифры, определяемые номерами родительских блоков. Например, показанные на Рис. 21 коды означают, что диаграмма является декомпозицией 2-го блока диаграммы, которая, в свою очередь является декомпозицией 2-го блока диаграммы А0, а сами коды образуются присоединением номера блока.

Рис. 21. Диаграмма декомпозиции блока А22

Таким образом, код формируется так:

Рис. 22. Код блока

Текст и Глоссарий (Словарь)

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

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

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

Глоссарий модели имеет линейную структуру. Каждый элемент глоссария представляет собой термин и его определение.

Диаграммы-иллюстрации (FEO)

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

ПРИЛОЖЕНИЕ Б.
Семантика языка моделирования IDEF0

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

Семантика блоков и дуг

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

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

Каждая сторона функционального блока имеет стандартное значение с точки зрения связи блок/дуга. В свою очередь, сторона блока, к которой присоединена дуга, однозначно определяет ее роль. Дуги, входящие в левую сторону блока – входы. Входы преобразуются или расходуются функцией, чтобы создать то, что появится на ее выходе. Дуги, входящие в блок сверху – управления. Управления определяют условия, необходимые функции, чтобы произвести правильный выход. Дуги, покидающие блок справа – выходы, т.е. информационные или материальные объекты, произведенные функцией. Дуги, подключенные к нижней стороне блока, представляют механизмы. Дуги, направленные вверх, идентифицируют ресурсы, поддерживающие выполнение функции. Другие ресурсы могут наследоваться из родительского блока. Дуги механизма, направленные вниз, являются дугами вызова (запроса). Дуги вызова обозначают обращение из данной модели или из данной части модели к блоку, входящему в состав другой модели или другой части модели,  обеспечивая их связь, т.е. разные модели или разные части одной и той же модели могут совместно использовать один и тот же элемент (блок). Стандартное расположение дуг показано на Рис. 23.

Рис. 23. Стандартное расположение дуг

Имена и метки

Как указывалось выше, имена функций – глаголы или глагольные обороты. Примеры таких имен:

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

Примеры размещения меток стрелок представлены на Рис. 24.

Рис. 24. Расположение меток

Семантические правила

Семантические правила блоков и дуг включают:

·                                                        ·        Имя блока должно быть активным глаголом или глагольным оборотом.

·                                                        ·        Каждая сторона блока должна иметь стандартное отношение блок/дуги:

o                                                                               o       Входные дуги должны связываться с левой стороной блока;

o                                                                               o       Управляющие дуги – с верхней стороной блока;

o                                                                               o       Выходные дуги – с правой стороной блока;

o                                                                               o       Дуги механизмов и запросов – с нижней стороной блока. При этом дуга механизама должна быть направлена вверх, а дуга запроса – вниз.

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

·                                                        ·        Чтобы связать метку с дугой, необходимо использовать знак «тильда» (~).

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

Свойства диаграмм

Стрелки как ограничения

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

Рис. 25. Стрелки – условия для выполения функции

На Рис. 25 представлен случай, при котором Функция 3 может быть выполнена только при поступлении инфомрации и/или материальных объектов от Функции 1 и Функции 2.

Параллельное функционирование

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

Рис. 26. Параллельное выполнение функцй

Ветвление и слияние сегментов стрелок

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

Отношения блоков на диаграммах

В методологии IDEF0 существует 6 (шесть) типов отношений между блоками в пределах одной диаграммы:

·                                                        ·        доминирование;

·                                                        ·        управление;

·                                                        ·        выход - вход;

·                                                        ·        обратная связь по управлению;

·                                                        ·        обратная связь по входу;

·                                                        ·        выход – механизм.

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

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

Отношения между блоками диаграммы и другими диаграммами

Все описанные выше отношения отображаются внутренними стрелками, т.е. такими, у которых оба конца связаны с блоками диаграммы. Отношения между блоками диаграммы и другими диаграммами, являющимися по отношению к рассматриваемой диаграмме окружающей средой (контекстом), описываются граничными стрелками (ССЫЛКА). Обе ситуации отражены на Рис. 27.

Рис. 27. Внутренние и граничные стрелки

У внутренней стрелки оба ее конца соединены с блоками диаграммы, у наружной стрелки один конец не имеет соединения с блоком на диаграмме.

Граничные стрелки

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

<РИСУНОК Есть в официальном издании >

ICOM-кодирование граничных стрелок

ICOM-коды связывают граничные стрелки на дочерней диаграмме со стрелками родительского блока. Нотация, названная ICOM-кодом, определяет значения соединений. Буквы I, C, O или M, написанные около несвязанного конца граничной стрелки на дочерней диаграмм идентифицируют стрелку как Вход (Input), Управление (Control), Выход (Output) или Механизм (Mechanism) в родительском блоке. Буква следует перед числом, определюящим относительное положение точки подключения стрелки к родительскому блоку; это положение определяется слева направо или сверху вниз. Например, код «C3», написанный возле граничной стрелки на дочерней диаграмме, указывает, что эта стрелка соответствует третьей (слева) управляющей стрелке родительского блока.

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

Иногда буквенные ICOM-коды, определяющие роли граничных стрелок (вход, управление, механизм), могут меняться при переходе от родительского блока к дочерней диаграмме. Например, управляющая стрелка в родительском блоке может быть входом на дочерней диаграмме. Аналогично, вход родительского блока может быть управлением для одного или более дочерних блоков. Примеры изменения ролей стрелок можно видеть на .

<РИСУНОК Есть в официальном издании >

Стрелки, помещенные в «туннель»

Туннель - круглые скобки в начале и/или окончании стрелки. Туннельные стрелки означают, что данные, выраженные этими стрелками, не рассматриваются на родительской диаграмме и/или на дочерней диаграмме.

Правила построения диаграмм

1.                                                      1.      В составе модели должна присутствовать контекстная диаграмма A-0, которая содержит только один блок. Номер единственного блока на контекстной диаграмме A-0 должен быть 0.

2.                                                      2.      Блоки на диаграмме должны располагаться по диагонали – от левого верхнего угла диаграммы до правого нижнего в порядке присвоенных номеров. Блоки на диаграмме, расположенные вверху слева «доминируют» над блоками, расположенными внизу справа. «Доминирование» понимается как влияние, которое блок оказывает на другие блоки диаграммы. Расположение блоков на листе диаграммы отражает авторское понимание доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные.

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

4.                                                      4.      Каждый блок неконтекстной диаграммы получает номер, помещаемый в правом нижнем углу; порядок н умерации - от верхнего левого к нижнему правому блоку (от 1 до 6).

5.                                                      5.      Каждый блок, подвергнутый декомпозиции, должен иметь ссылку на дочернюю диаграмму; ссылка (например, узловой номер, C-номер или номер страницы) помещается под правым нижним углом блока.

6.                                                      6.      Имена блоков (функций) и метки стрелок должны быть уникальными. Если метки стрелок совпадают, это значит, что стрелки отображают тождественные объекты.

7.                                                      7.      При наличии стрелок со сложной топологией целесообразно повторить метку для удобства ее идентификации.

8.                                                      8.      Следует обеспечить максимальное расстояние между блоками и поворотами стрелок, а также между блоками и пересечениями стрелок для облегчения чтения диаграммы. Одновременно уменьшается вероятность перепутать две разные стрелки.

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

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

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

12.                                                 12. Стрелки связываются (сливаются), если они представляют сходные данные и их источник не указан на диаграмме ().

13.                                                 13. Обратные связи по управлению должны быть показаны как "вверх и над " (.27, а ). Обратные связи по входу должны быть показаны как "вниз и под " (). Так же показываются обратные связи посредством механизма. Таким образом обеспечивается показ обратной связи при минимальном числе линий и пересечений.

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

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

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

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

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

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

20.                                                 20. Необходимо использовать (если это целесообразно) выразительные возможности ветвящихся стрелок.

Ссылочные выражения (коды)

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

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

Номера блоков

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

На контекстной диаграмме A-0 единственному блоку присваивается номер 0 (ноль). На всех других диаграммах блоки нумеруются цифрами от 1 до 6, начиная с верхнего левого блока (при их диагональном размещении ) и кончая нижним правым блоком. Если некоторые блоки на диаграмме размещены не по диагонали, то сначала нумеруются «диагональные» блоки (также начиная с левого верхнего блока) , а затем – «недиагональные» блоки, начиная с нижнего правого против часовой стрелки.

Узловые номера

Узловой номер базируется на положении блока в иерархии модели. Обычно узловой номер формируется добавлением номера блока к номеру диаграммы, на которой он появляется. Например, узловой номер блока 2 на диаграмме A25 – A252. Все узловые номера IDEF0 начинаются с заглавной буквы, например, "A". Когда родительский блок подробно описывается дочерней диаграммой, узловые номера родительского блока и дочерней диаграммы совпадают.

Контекстные диаграммы и дочерняя диаграмма верхнего уровня – исключения в вышеуказанной схеме узловой нумерации. Каждая модель IDEF0 имеет контекстную диаграмму верхнего уровня – диаграмму A-0. Эта диаграмма содержит единственный «вышестоящий блок», который является единственным родителем всей модели и несет уникальный номер 0 (ноль) и узловой номер A0. Каждая модель IDEF0 должна также иметь по крайней мере одну дочернюю диаграмму, содержащую декомпозицию блока А0 на 3 … 6 дочерних блоков. Этим блокам присваиваются уникальные узловые номера A1, A2, A3, … A6. Таким образом, последовательность [A0, A1,..., A2,..., A3,...] начинает нумерацию узлов для любой модели.

Например, модель может иметь следующие узловые номера:

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

Перечень узлов

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

А0 Изготовить партию продукции

     А1 Сформировать производственное задание

     А2 Изготовить продукцию

                 А21 Изготовить комплектующие

                 А22 Осуществить сборку

                 А23 Выполнить проверку качества

                 А24 Доставить продукцию на склад

     А3 Подготовить тару

     А4 Упаковать продукцию

Рис. 28. Перечень узлов

Дерево узлов

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

Рис. 29. Дерево узлов

ПРИЛОЖЕНИЕ В.
Обобщенная функциональная модель системы менеджмента качества

Есть в официальном издании

Приложение Г.
Пример функциональной модели процесса изготовления шасси телевизора

Есть в официальном издании

Скачать

Похожие работы:

Если Вы не нашли нужную работу, то закажите ее у нас.

Если Вы имеете свои уникальные рефераты, сданные на 5 и 4 балла, то разместите их на нашем сайте! Вы сможете продать свои рефераты тем, кому они нужны!