Объясните общую схему процесса диагностирования кратко

Методы диагностирования

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

Субъективные методы

Наибольшее распространение получили следующие субъективные методы:

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

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

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

Прослушивание работы механизма позволяет обнаружить следующие неисправности:

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

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

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

На основании логического мышления можно сделать заклю­чение о следующих неисправностях:

• топливной аппаратуры — затруднен пуск двигателя
• системы охлаждения — двигатель перегревается и др.

Объективные методы

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

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

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

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

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

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

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

• камеру сгорания
• герметичность которой зависит от состояния цилиндропоршневой группы и клапанов газораспределения
• систему охлаждения
• систему питания двигателя
• шины
• гид­равлические и пневматические приборы и механизмы

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

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

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

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

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

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

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

ПО ТЕМЕ:

• Люфтомеры рулевого управления. Прибор для измерения суммарного люфта
• Нормативные требования к тормозным системам, проверяемые стендовым методом
• Мультипротокольный адаптер
• Контролируемые системы и датчики D-OBD

Процесс диагностирования

В общем случае процесс технического диагностирования включает следующие элементы:

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

Рис. Схема процесса диагностирования: S — диагностический параметр; S’ — диагностический параметр в трансформированном виде; Si — текущее значение диагностического параметра; Sном — номинальное значение; Sд — допустимое значение диагностического параметра; Sп — предельное значение

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

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

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

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

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

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

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

ПО ТЕМЕ:

• Диагностика автомобиля
• Виды стендов и методы испытания тормозных систем
• Общее диагностирование двигателя
• Регулировка угла наибольшего поворота колес

Объясните общую схему процесса диагностирования кратко

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

• (бесплатный номер по вопросам подписки)
  пн-пт с 10 до 18

• Издательство «Медиа Сфера»
  а/я 54, Москва, Россия, 127238
• info@mediasphera.ru

• вКонтакте
• Telegram

• Издательство
• «Медиа Сфера»

Результаты поиска: 0

Глава 3. Краткое описание процесса внутренних аудитов

Скачать PDF
Связаться с автором
Оглавление

Глава 3. Краткое описание процесса внутренних аудитов. Лабораторная служба. 2014;3(3):7‑18.
Chapter 3. Description of internal audits process. Laboratory Service. 2014;3(3):7‑18. (In Russ.)

Читать метаданные

3.1. Внутренний аудит — это процесс обзора деятельности подразделений, процессов и т.д.

Проводят сотрудники самой организации. Руководство по проведению аудитов см. в ГОСТ Р ИСО 19011

Реальные цели аудитов:

— поиск возможностей для улучшений;

— поиск подтверждения соответствий требованиям.

— соотнести реальную деятельность тому, что прописано в документации СМК;

— наблюдение за деятельностью;

— анализ записей и документов;

3.2. Результат внутренних аудитов: коррекции, корректирующие и предупреждающие действия.

Коррекция — устранение конкретного несоответствия.

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

Предупреждающее действие — деятельность, направленная на предотвращение еще не случившихся проблем (т.е. профилактика несоответствий).

3.3. Пример. В табл. 1 представлен вариант итога внутреннего аудита.

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

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

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

Аудитор попросил руководителя подразделения:

— проверить маркировку в подразделении;

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

Это была коррекция — устранение несоответствия.

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

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

Это корректирующее действие — мы пытаемся устранить причину выявленных несоответствий.

Помимо этого, по требованию стандарта ГОСТ Р ИСО 9001 мы оцениваем результативность корректирующих действий.

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

Результативность этого корректирующего действия будет проверена при анализе СМК со стороны руководства.

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

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

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

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

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

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

— для подтверждения соответствия выбранному стандарту (ГОСТ Р ИСО 15189, ГОСТ Р ИСО 9001 и т.п.);

— для подтверждения выполнения любых внутренних требований организации;

— для проверки выполнения конкретного распоряжения руководства;

— для проверки выполнения обязательных требований по технике безопасности и т.п.

Эксперт (технический специалист, технический эксперт) — наиболее компетентный в рамках целей данного аудита специалист.

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

Такие люди не могут быть полностью компетентными во всех вопросах работы лаборатории.

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

Так, проверяя проведение внутреннего контроля качества, полезно к аудиту привлечь эксперта в этом вопросе.

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

3.5. Процесс внутренних аудитов.

С точки зрения СМК, основанной на требованиях ГОСТ Р ИСО 9001, для любого процесса СМК полезно описать:

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

— входы процесса, т.е. те ресурсы, сырье, материалы, информация и т.п., которые необходимы для функционирования процесса;

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

— описать систему, с помощью которой осуществляется мониторинг процесса;

— описать методы контроля результативности процесса.

Любой процесс имеет результат.

Результативность процесса — его способность достигать поставленного результата, то есть степень реализации запланированной деятельности.

Результативность должна быть выражена численно.

Это отношение соответствующих требованиям продуктов процесса и общего числа продуктов.

— описать процедуры, необходимые для выполнения процесса. То есть ответить на вопрос — КАК делать;

— определить, какие записи будут возникать в процессе реализации процедур. Эти записи будут использоваться для внутреннего контроля и позволят доказать, что процесс проходит так, как запланировано.

Опишем процесс внутренних аудитов по этой схеме.

3.5.1. Цели и потребители процесса внутренних аудитов.

Цели процесса внутренних аудитов:

— найти возможности для улучшений;

— найти подтверждения соответствия требованиям (которые являются критерием аудита, например: требования законодательства, ГОСТ Р ИСО 15189, внутренним требованиям организации и т.п.).

— администрация (руководство) организацией;

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

— руководители структурных подразделений, где проводится аудит;

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

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

— сотрудники структурных подразделений.

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

3.5.2. Входы процесса внутренних аудитов:

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

— процедура внутренних аудитов;

— должным образом утвержденный годовой план аудитов, программа аудита, чек-лист;

— в некоторых случаях, например при внеплановом аудите, распоряжение (или приказ) высшего руководства о проведении аудита;

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

1) методы сбора информации (опросы, наблюдения, оценка документов и т.д.);

2) методы фиксации информации (например, чек-лист);

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

4) методы определения критериев результативности предпринятых мер по решению найденных проблем;

5) методы транслирование информации по результатам внутренних аудитов по организации.

3.5.3. Выходы процесса внутренних аудитов:

— план коррекций, корректирующих и предупреждающих действий (включая, по меньшей мере, указание сроков устранения несоответствий, ответственных, критерии результативности);

— возможно, внесение изменений в годовой план внутренних аудитов;

— записи по внутреннему аудиту (например, заполненный чек-лист, отчеты аудиторов и т.п.);

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

3.5.4. Требования к результатам процесса внутренних аудитов:

— вся документация, возникающая на выходе процесса менеджмента рисков, должна соответствовать, во-первых, требованиям стандарта ГОСТ Р ИСО 9001, а во-вторых — требованиям, изложенным в процедуре по проведению внутренних аудитов;

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

3.5.5. Мониторинг процесса внутренних аудитов.

Мониторинг осуществляется через анализ соответствующих записей. А именно:

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

— проверка выполнения программы каждого аудита. В рамках этого проверяют:

1) квалификацию группы аудиторов (детальнее см. пункт 7 настоящего пособия), отдельно квалификацию технических экспертов, других членов группы аудиторов и ведущего внутреннего аудитора (пункт 4 настоящего пособия);

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

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

3.5.6. Контроль результативности процесса внутренних аудитов

Возможные объективные критерии измерения результативности (начинаем с простых, переходим к более сложным, но более информативным):

— количество запланированных аудитов и количество реально проведенных аудитов;

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

— количество найденных возможностей для улучшений и количество улучшений принятых к реализации;

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

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

3.5.7. Процедуры процесса внутренних аудитов

Необходима документированная процедура по проведению внутренних аудитов.

В рамках этой процедуры необходимо описать:

— планирование внутренних аудитов;

— процесс проведения внутреннего аудита;

— требования к компетенции внутренних аудиторов;

— требования к документообороту.

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

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

— правила этики для внутренних аудиторов;

— методика определения причин выявленных несоответствий;

— экстренная остановка процесса при выявлении серьезного несоответствия, несущего большую угрозу безопасности персонала и/или потребителя и т.п.

3.5.7.1. Годовой план аудитов

Полезно иметь единый план аудитов на год.

В таком плане можно указывать как внутренние, так и внешние аудиты.

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

То есть, если наибольшее количество проблем было выявлено в лаборатории биохимии, то при планировании будущих аудитов необходимо либо чаще проводить проверку деятельности лаборатории биохимии, либо выделять на ее оценку больше времени. Пример простого годового плана аудитов см. в табл. 2.

Комментарии к табл. 2. В колонке «вид аудита» указывают, внутренний это аудит или внешний.

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

В колонке «подразделения» указывают отделы, которые будут проверяться.

В колонке «процессы» указывают основные процессы, подлежащие проверке.

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

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

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

Комментарий к табл. 3. В самом простом виде данную информацию можно делать в программе Excel или в его аналоге — Open Office Calc. При желании и возможности полезно интегрировать эти данные в существующую лабораторную информационную систему.

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

По каждому процессу (табл. 5):

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

3.5.7.2. Программа аудита

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

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

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

3.5.7.3. Совещание группы аудиторов

Непосредственно перед началом аудита полезно проводить совещание группы аудиторов. Данное совещание может преследовать несколько целей.

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

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

2) если в состав комиссии включены новые сотрудники, еще не участвовавшие во внутренних аудитах, задачами главного аудитора на совещании являются:

a) убедиться, что новый сотрудник знает нормы и правила проведения внутреннего аудита;

b) еще раз дать четкий инструктаж по методам проведения аудита;

c) четко обозначить ответственность и полномочия нового специалиста, объяснить ему порядок действий при нахождении несоответствий, ситуаций с повышенным риском и возможностей для улучшений;

d) точно объяснить новичку правила заполнения чек-листов и ведения записей;

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

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

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

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

3.5.7.3. Проведение аудита

3.5.7.3.1. Методика проведения аудита

Чтобы аудит был полезным и результативным, необходимо, чтобы ответственные за проверку тех или иных процессов аудиторы владели следующей информацией:

— требования к данным процессам, которые описаны в стандартах ГОСТ Р ИСО 9001 и ГОСТ Р ИСО 15189, законодательные требования (если есть), внутренние требования лаборатории. Обычно в документации СМК, где описаны процессы, требования стандартов и законодательные требования уже соблюдены. Соответственно, аудиторы в первую очередь должны знать внутренние требования лаборатории к проверяемым процессам. То есть, они должны знать внутреннюю документацию и владеть профессиональными знаниями в проверяемых областях.

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

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

В процессе аудитов обычно используют три основных метода сбора информации:

— беседа с сотрудниками;

— наблюдения за работой;

— работа с документами и записями.

Приведем пример:

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

— кто отвечает за выдачу результатов, интерпретации и рекомендаций из лаборатории врачу-клиницисту или пациенту;

— на каком конкретно оборудовании были проведены анализы;

— доказана работоспособность этого оборудования на момент проведения анализов;

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

— есть возможность узнать, на каких реагентах проводились исследования (вплоть до лота);

— есть данные по калибраторам и контрольным сывороткам, которые использовались для конкретного исследования;

— есть данные, подтверждающие, что реагенты, контроли, сыворотки и биоматериал должным образом хранились;

— персонал, выполняющий исследования, обладает должной квалификацией;

— исследования выполнялись в контролируемой среде (влажность, чистота и т.п.);

— там, где применимо: использовалось оборудование закрытого типа с «родными» реагентами. Если применялось оборудование открытого типа, то есть данные о валидации методик;

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

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

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

3.5.7.3.2. Психологические и этические аспекты проведения внутреннего аудита

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

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

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

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

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

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

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

3.5.7.3.3. Записи в процессе аудита. Чек-лист

Важно, чтобы аудиторы фиксировали все конкретные доказательства соответствий и несоответствий.

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

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

Полезно использовать так называемый чек-лист в процессе аудита.

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

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

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

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

3.5.7.3.4. Окончание внутреннего аудита

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

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

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

Ориентировочно обозначить срок передачи отчета по аудиту руководителю подразделения.

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

3.5.7.3.5. Завершающее совещание группы аудиторов

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

Собрать с аудиторов опросники, замечания и рекомендации.

На практике может получиться так, что непосредственно после аудита аудиторам требуется один-два дня на подготовку документов.

Тогда итоговое совещание можно провести через несколько дней после аудита.

Важно потребовать от аудиторов помимо записей по аудиту предоставить свои видения корректирующих и предупреждающих действий.

3.5.7.3.6. Составление отчетности, создание плана коррекций, корректирующих и предупреждающих действий

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

Здесь мы рекомендуем иметь два типа документов. Первый — для отдела качества. По сути это должен быть поддерживаемый в Е-виде общий план по каждому аудиту. Такая общая таблица служит для мониторинга выполнения коррекций, корректирующих и предупреждающих действий. Пример и описание работы с такой таблицей приведен в п. 3.5.10. «Мониторинг» настоящего пособия.

Второй вариант документов составляется для каждого подразделения или для конкретных сотрудников. Пример его приведен на рис. 2 п. 3.3 настоящего пособия.

3.5.7.3.7. Рассылка плана коррекций, корректирующих и предупреждающих действий

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

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

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

Далее. Разработка корректирующих и предупреждающих действий это также совместная работа.

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

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

На рис. 2 приведен наглядный пример.

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

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

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

3.5.7.3.8. Контроль результативности предпринятых мер

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

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

3.5.9. Схема процесса внутренних аудитов (рис. 4).

Краткое описание BPMN с примером

О том, что такое BPMN, написано очень много. Но проблема в том, что почти вся информация, которую можно найти в Интернет, ориентирована на людей, которые уже ранее сталкивались с BPMN или с другим стандартом моделирования бизнес-процессов. Я же предлагаю разобраться «с нуля» — что такое BPMN? В чем особенности и преимущества этой технологии и почему она появилась и оказалась столь востребованной, по крайней мере, за рубежом. Да и у нас в стране ей все больше и больше интересуются.

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

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

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

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

Лично я познакомился впервые с BPMN около восьми лет назад, когда начал изучать систему Bizagi Modeler. Заинтересовался я этой системой по причине того, что давно уже понимал всю важность моделирования. До этого я лично пользовался IDEF0 и IDEF3, но там я сталкивался с определенными ограничениями. Дело в том, что IDEF0 несколько ограничен по числу возможностей. А IDEF3 мне лично показался излишне строгим и «сухим», в нем было сложно моделировать многие виды бизнес-процессов с участием программных продуктов.

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

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

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

У меня есть видео-курс по BPMN, в котором бесплатно доступны несколько уроков:

BPM: основные понятия

Для того чтобы разобраться, что такое BPMN , нужно понимать, что часть этой аббревиатуры «BPM» имеет две расшифровки — Business Process Modeling и Business Process Management. В первом случае – это непосредственно моделирование бизнес процесса, а во втором – управление бизнес-процессами, т.е. общая система, частью которой и является Business Process Modeling.

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

Есть и еще одно понятие, о котором стоит сразу упомянуть – это «BPMS», т.е. Business Process Modeling System. Этот термин описывает те самые системы управления, в которых производится моделирование, а также исполнение бизнес-процессов.

Можно сказать, что BPMN является частью двух важнейших составляющих:

• BPM (Business Process Modeling) – это та среда, где вы занимаетесь непосредственно моделированием. Самостоятельно или в команде.
• BPMS (Business Process Modeling System) – это инструменты для исполнения созданных вами моделей. Это может быть Bizagi, Comundo,ELMA и пр.

Разбираемся с понятием BPM. Что такое управление бизнес процессами

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

Язык описания бизнес-процессов

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

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

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

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

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

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

Немного истории BPMN

Для большего понимания особенностей моделирования бизнес-процессов и структуры языка моделирования, я хочу немного рассказать об истории появления нотации BPMN. Разработка системы моделирования бизнес-процессов и спецификаций для нее (языка моделирования) ведется относительно давно.

Первая версия BPMN 1.0 была выпущена в мае 2004 года компанией Business Process Management Initiative. Эта версия обладала ограниченными возможностями и была, так сказать, «пробным вариантом», который нуждался в многочисленных доработках.

Следующая версия BPMN 1.1 выходит в январе 2008, и здесь разработкой и поддержкой занималась уже Object Management Group, организация, появившаяся в результате слияния BPMI с другой компанией-разработчиком программного обеспечения.

Еще один релиз появляется всего через год, версия BPMN 1.2 выходит в свет в январе 2009. Разработчик OMG остается прежним. Команда, которая занимается продуктом, после слияния практически не меняется.

В январе 2011 года компания OMG выпускает версию BPMN 2.0, а в декабре 2013 выходит последний на данный момент релиз – BPMN 2.0.2. Именно эта версия предлагается всем пользователям и сегодня, так как система получилась стабильной, возможности моделирования в ней очень широкие, а язык моделирования (набор обозначений) по большей части понятен всем бизнес-пользователям – как бизнесменам, бизнес-консультантам, так и техническим специалистам.

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

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

Я особенно хочу подчеркнуть этот момент, так как и сам столкнулся поначалу с непониманием, зачем те или иные вещи усложнять? Ведь для описания бизнес-процессов, например, при GAP-анализе (анализ разрывов) или для представления заказчику бизнес-модели в какой-то упрощенной форме, всего многообразия элементов BPMN вам не нужно.

Использование GAP-анализа для выявления и согласования задач по проекту

Что такое GAP-анализ и какие задачи он помогает решать. Основные этапы работы. Диагностика и ее разновидности. Чем интересен метод GAP-анализа для анализа выбранных решений. Преимущества графики.

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

Из чего состоит нотация BPMN?

И здесь я хочу сделать небольшое отступление. Дело в том, что перевод терминов и понятий с английского языка на русский – занятие сложное. Найти наиболее точное слово обычно может специалист, но переводом занимается совсем другой человек, часто вообще не имеющий понятия о сути тех понятий, которые он переводит. В результате появляется множество неточностей, понятия усложняются, возникает путаница. Об особенностях перевода и сложностях применения терминов в сравнении с графикой я уже писал, например, в статье «Знакомство с нотацией IDEF0 и пример использования» (см. раздел “Несколько слов о преимуществах графики”).

IDEF0. Знакомство с нотацией и пример использования

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

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

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

Язык описания бизнес-процессов опирается на следующие базовые объекты:

• Event – Событие;
• Activity – Действия;
• Gateway – Шлюзы или Развилки;
• Flow – Поток.
• Date – Данные;
• Artefact – Артефакты;
• Pool (Пул) — набор.

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

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

Event (Событие)

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

Например, опишем процесс получения заказа от клиента по телефону:

• Событие Старт – это входящий звонок от клиента.
• Событие Финиш – это отправка готового расходного документа на печать.

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

Activity (Действия)

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

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

Обычно действия делят следующим образом:

• Процесс – крупное действие, которое требует дальнейшей детализации при моделировании.
• Задача – элементарное действие, которое уже не может быть дальше детализировано.

Gateway (Шлюз, Развилка)

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

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

Flow (Поток) и Message Flows (поток сообщений)

Поток Flow – это последовательность действий, обозначается как стрелка, и показывает, какое действие после какого необходимо совершить.

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

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

Pool (Пул)

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

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

Data Object (данные, объекты данных)

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

Message (Сообщение)

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

Artefact (Артефакты)

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

Выделяют два вида артефактов:

• Object Group (Группа объектов)
• Text Annotation (Текстовая аннотация)

Object Group (Группа объектов) – это еще одна возможность объединить под общим символом несколько элементов, чтобы сэкономить место на диаграмме и повысить простоту ее восприятия. Здесь собираются различные активности под одним общим названием. Группу объектов также всегда можно рассмотреть детально. Группа выглядит как прямоугольник с закругленными углами, выполненный штриховой линией с точками.

Text Annotation (текстовые аннотации) применяют для различных уточнений к диаграмме. Это могут быть комментарии, пояснения, другая информация, которая повысит читабельность диаграммы. Аннотации – это незакрытый прямоугольник, выполненный сплошной линией, от которого к объекту аннотации ведет линия, состоящая из точек.

Исполняемые и неисполняемые бизнес-процессы

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

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

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

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

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

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

Подходит ли BPMN для малого и среднего бизнеса?

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

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

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

Минусы и важные особенности BPMN

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

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

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

Необходимо знание бизнес-анализа. В BPMN модели — это не просто картинки или схемы, которые вы можете нарисовать в любом графическом редакторе. Здесь очень важна грамотная структура и четкая последовательность.

Пример практического применения BPMN

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

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

Данный бизнес-процесс выполняется следующим образом:

1. Менеджер по продажам получает информацию о потребностях клиента (заказ).
2. В системе CRM создается документ Заказ покупателя.
3. Если нужные товары есть в наличие, то менеджер создает расходный документ в программе учета. Если товара нет в наличии, менеджер делает запрос в отдел закупки.
4. Отдел закупки оформляет запрос поставщикам на получение товара.

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

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

Точкой входа служит получение заказа от покупателя. Точкой выхода – «резервирование товара».

Обратите внимание, что после получения заказа стрелка ведет к этапу-ромбу, т.е. условию:

• Если весь товар имеется в наличие, то менеджер выполняет подпроцесс «резервирование товаров». Я специально оформил эти действия именно подпроцессом, чтобы иметь возможность при необходимости детализировать действия менеджера. А потом – к точке выхода «Резервирование товаров проведено».
• Если товаров в наличие нет, то менеджер выполняет запрос в отдел закупки. Информация о заказе переходит в отдел закупки к другому исполнителю – менеджеру по закупкам, что наглядно видно на схеме, и уже этот исполнитель создает заказ поставщику. На схеме также видно, что заказ поставщику создан на основе запроса на поставку и заказа поставщикам.

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

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

Как разрабатывать диаграммы BPMN на практике?

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

1. Необходимо запланировать начало и конец процесса. С этого начинается моделирование любого процесса. Так мы обозначаем рамки, в которых будем работать.
2. Для начала лучше всего описать линейную последовательность действий: шаг за шагом движение от начала к финальному результату. Далее при необходимости добавляются ветвления. В таком порядке работать намного проще, чем ставить две или более ветвей одновременно и путаться в стрелках, что откуда и куда идет.
3. Пришло время определить ответственных лиц. До этого мы работали с событиями «в чистом виде». Теперь у них появились исполнители и ответственные.
4. Добавляем данные, сноски, комментарии.

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

Что еще хотелось бы посоветовать:

1. Создавайте диаграммы как можно менее разветвленные. Чем больше элементов окажется на вашей диаграмме, тем сложнее ее будет читать и вам, и вашим заказчикам.
2. Используйте наиболее простую и понятную терминологию. Очень важно, чтобы ваши заказчики, а также технические специалисты, которые будут работать с диаграммами, без лишних пояснений понимали все (или почти все) термины.
3. Все названия процессов должны быть максимально информативны и понятны. Иначе читабельность диаграммы также будет крайне низкой. Для названий процессов лучше всего подойдут либо термины, принятые в конкретной организации для описания работы, либо – просто понятные интуитивно фразы.
4. Зоны ответственности также важно называть понятно для сотрудников компании, бизнес-модель работы которой вы описываете. Самое простое решение – выбирать названия среди существующих подразделений. А если необходимой должности или отдела в компании пока еще не существует, не бойтесь придумывать его сами. Но постарайтесь, чтобы название также было «говорящим», понятным для широкого круга бизнес-аудитории.
5. Подпроцессов должно быть столько, чтобы избежать ненужной детализации, но не более того. Помните о чувстве меры. Если подпроцессов будет слишком мало, то действия, которые стоило бы спрятать в них, будут находиться в общем процессе, создавая дополнительные объекты, стрелки, ветвления и, как следствие, путаницу. Если вы перестараетесь с желанием убрать все в подпроцессы, то диаграмма потеряет свою информативность, а какие-то изменения в подпроцессе начнут ненаглядно влиять на результаты всего процесса.
6. Не бойтесь ошибаться! Если вы ошибетесь в исполняемой методологии, это очень быстро выяснится в процессе исполнения (отладки) процесса. Если вы создаете просто наглядную схему, то мелкие ошибки не столь важны, главное, чтобы эта схема помогла вам и людям, для которых вы ее делаете (заказчики, технические специалисты), понять все нюансы вашей идеи. И в любом случае, на ошибках учатся, а исправления внести в бизнес-модель можно быстро и просто.

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

Примеры описания бизнес-процессов

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

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

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

Общие правила и рекомендации

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

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

Пример 1

Текстовое описание процесса:

«При необходимости в товаре которого нет в наличии продавец создает документ “Заявка на закупку” и направляет его на согласование закупщику. Закупщик проверяет необходимость в закупке данного товара и если закупщик разрешает закупить товар согласно документу “Заявка на закупку”, то продавец информируется о разрешении закупить товар, и закупщик создает документ “Заказ поставщику”. Иначе заявка аннулируется с комментарием содержащем причину отказа в закупке товара. Продавец информируется об отказе в закупке товара».

Анимация токена в схеме BPMN в формате GIF:

Описание бизнес-процесса

1. Создать документ «Заявка на закупку».

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

1. Отправить заявку на согласование.

Продавец отправляет сформированный документ на согласование Закупщику.

1. Проверить заявку.

Закупщик проверяет «Заявку на закупку» и определяет, действительно ли эти товары необходимо закупить у поставщика.

Если Закупщик приходит к выводу, что закупка целесообразна:

1. Закупщик подтверждает заявку.
2. Информация о разрешении закупить товар отправляется Продавцу.
3. Закупщик создает документ Заказ поставщику. На этом процесс завершен.

Если Закупщик заявку не одобряет:

1. Закупщик аннулирует заявку с комментарием, который поясняет причины отказа.
2. Продавец получает уведомление об отказе с комментарием Закупщика. На этом процесс завершен.

Пример 2

«При необходимости в товаре, которого нет в наличии, продавец создает документ «Заявка на закупку» и направляет в стороннее приложение. Стороннее приложение проверяет сумму заявки и, если стороннее приложение одобряет заявку, она отправляется к закупщику. Если заявка не была одобрена сторонним приложением, скрипт автоматически аннулирует ее с комментарием и информирует об отказе продавца. Закупщик принимает заявку и проверяет необходимость в закупке данного товара и, если закупщик разрешает закупить товар согласно документу «Заявка на закупку», то он информирует продавца о разрешении закупить товар и одновременно создает документ «Заказ поставщику». Иначе заявка аннулируется с комментарием, содержащим причину отказа в закупке товара. Продавец информируется об отказе в закупке товара».

Также в процессе утверждения процесса было решено, что задачи «Создать документ «Заказ поставщику» и «Информировать о разрешении закупить товар» должны выполняться одновременно.

Описание бизнес-процесса

1. Создать документ «Заявку на закупку»

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

1. Отправить заявку на согласование.

Продавец направляет сформированный документ на согласование в сторонний сервис.

1. Проверить сумму заявки:

Если заявка не удовлетворяет заданным условиям:

1. Сервис автоматически аннулирует ее с комментарием, поясняющим отказ.
2. Продавец информируется об отказе. На этом процесс завершен.

Если заявка одобрена сервисом:

1. Закупщик принимает сообщение о заказах на проверку.
2. Закупщик проверяет заявку.

Если Закупщик принимает решение одобрить Заявку:

1. Закупщик одобряет Заявку в информационной системе.
2. Одновременно формируется документ «Заказ поставщику» и отправляется уведомление Продавцу о разрешении закупить товар. Процесс завершен.

Если Закупщик не одобряет Заявку:

1. Заявка аннулируется с комментарием, поясняющим причины отказа.
2. Продавец информируется об отказе и его причинах. Процесс завершен.

Пример 3

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

В этом примере мы используем для проверки суммы заказа стороннюю IT-систему, а чтобы это правильно отобразить графически, используем элемент «Сервисная задача».

Анимация токена в схеме BPMN в формате GIF:

Описание бизнес-процесса

1. Создать документ «Заявка на закупку».

Продавец формирует в информационной системе список товаров, которые необходимо закупить.

1. Отправить заявку на согласование.

Продавец отправляет Заявку на согласование, она отправляется в стороннее приложение.

1. Проверить сумму заявки.

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

Если заявка не одобрена сервисом, процесс завершен.

Если заявка одобрена сервисом:

1. Закупщик получает сообщение о заказах на проверку.
2. Закупщик проверяет заявку.

Если Заявка одобрена:

1. Одобрить заявку.

Закупщик в системе подтверждает одобрение заявки.

1. Информировать о разрешении закупить товар.

Система автоматически отправляет Продавцу информацию о том, что Заявка на закупку одобрена.

1. Создать документ «Заказ поставщику».

Закупщик формирует «Заказ поставщику». Процесс завершен.

Если заявка не одобрена:

1. Аннулировать заявку с комментарием.

Закупщик аннулирует заявку, в комментарии поясняет причины отказа.

1. Проинформировать об отказе. Продавцу отправляется уведомление об отказе с комментарием Закупщика. Процесс завершен.

Пример 4

«Если продавец получает сообщение о необходимости в товаре, он создает документ заявка на закупку и направляет его на согласование закупщику. Закупщик проверяет необходимость в закупке данного товара и, если закупщик разрешает закупить товар согласно заявке на закупку, то продавец информируется о разрешении закупить товар и закупщик создает заказ поставщику. Закупщик информирует клиента о статусе его заказа. Иначе заявка аннулируется с комментарием, содержащем причину отказа в закупке. Продавец информируется об отказе в закупке».

Анимация токена в схеме BPMN в формате GIF:

Описание бизнес-процесса

Процесс инициируется после того, как Продавец получает Заказ от клиента.

1. Создать документ «Заявка на закупку»

Продавец на основе заказа клиента формирует в информационной системе документ «Заявка на закупку».

1. Отправить заявку на согласование.

После того как документ полностью сформирован, он отправляется на согласование Закупщику.

1. Проверить заявку.

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

Если заявка одобрена:

1. Одобрить заявку.

После принятия положительного решения Закупщик в системе подтверждает одобрение заявки.

1. Информировать о разрешении закупать товар.

Покупателю отправляется сообщение, в котором он информируется об одобрении заявки.

1. Создать документ «Заказ поставщику». Закупщик формирует документ «Заказ поставщику». Система отправляет клиенту письмо с информацией «Ваш заказ принят» и завершает процесс.

Если заявка не одобрена:

1. Аннулировать с комментарием в случае отказа.

Закупщик аннулирует заявку, но при этом пишет комментарий, где указывает причины отказа.

1. Проинформировать об отказе.

Продавец получает уведомление об отказе, которое также включает комментарий Закупщика. Процесс завершен.

Об авторе

Кинзябулатов Рамиль

Кинзябулатов Рамиль Хибатуллович, бизнес консультант и it консультант. Опыт автоматизации более 17 лет. Занимаюсь управленческим консультированием и разработкой it решений в составе команды Trinion. Автор 3-х книг и множества статей на тему организации труда.

Комментарии

Екатерина

calendar_month 24 марта 2023

Посоветуйте, пожалуйста, как лучше всего освоить данную нотацию? Достаточно ли хорошо описано в оригинале самой нотации как её применять?

Кинзябулатов Рамиль

calendar_month 19 июля 2023