Модели бизнес-процессов

Моделирование бизнес-процессов

Модель бизнес-процесса традиционно является основной составляющей управления бизнес-процессами.

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

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

Цель моделирования бизнес-процессов

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

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

Как моделировать бизнес процесс зависит от целей моделирования:

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

Обратите внимание

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

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

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

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

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

Этапы моделирования бизнес-процессов

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

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

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

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

Свойства моделей бизнес-процессов

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

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

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

Уровень детализации бизнес-процесса зависит от целей моделирования и определяется на этапе планирования моделирования бизнес-процессов.Предмет моделированияВ зависимости от целей моделирования, информация модели может отражать взаимосвязи разной информации.

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

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

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

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

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

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

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

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

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

Нотации моделирования бизнес-процессов

Унификация правил моделирования бизнес-процессов приводит к использованию действующих правил и созданию новых стандартов моделирования.

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

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

Unified Modeling LanguageОбъектно-ориентированный метод моделирования, позволяющий моделировать различные статичные или динамичные свойства объектов модели. Применяется для низкоуровневого описания состояния объектов информационной среды.Integrated Definition for Function ModelingНабор различных методов для описания целевых аспектов бизнес-процесса. Широко распространённая нотация моделирования бизнес-процессов в 20 веке, сейчас не находит практического применения из-за наличия более гибких методик.Event-driven ModelingОдна из универсальных нотаций моделирования, позволяющая представить поток работ или данных как следствия возбуждающих событий.Business Process Model and NotationУнифицированная нотация моделирования бизнес-процессов. Наиболее подходит для автоматизации потоков работ.Task-driven ModelingРасширение событийной нотации для возможности анализа бизнес-процесса со стороны задач, подаваемых на его вход. Разработана специально для использования в сервисе имитационного моделирования bpsimulator.com.

Важно

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

Как например, платформа Aris имеет возможность конвертации из EPC в BPMN, а платформа БП Симулятор позволяет импортировать и конвертирует пару BPMN в EPC. Даже при отсутствии специального программного обеспечения возможно проводить моделирование в любых графических средствах и редакторах.

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

Источник: https://www.bpsimulator.com/ru/bpm/modeling.html

Примеры моделей предприятий

Типовые структуры бизнес-процессов (Process Frameworks) разработаны Группой компаний «Современные технологии управления» в качестве методической основы для построения моделей бизнес-процессов реальных компаний. Типовые структуры представлены в формате PDF для ознакомления и в формате XML для использования в Business Studio (доступны для загрузки на странице Пакеты для самостоятельной загрузки).

Оказание услуг (PDF)

Проектная деятельность (PDF)

Производство (PDF)

Управляющая компания (PDF)

Уникальная возможность

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

Модели бизнес-процессов, созданные в системе Business Studio

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

Модели опубликованы в формате HTML-публикации, автоматически формируемой Business Studio. HTML-публикация содержит диаграммы бизнес-процессов предприятия, основные регламентные документы (Регламент процесса, Регламент процедуры, Положение о подразделении, Должностная инструкция) и управленческую информацию с возможностью перехода между документами по гиперссылкам.

Внимание!

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

Модель производственного предприятия

Характеристика предприятия

Основные направления деятельности:

  • Производство и продажа алюминиевого профиля;
  • Производство и продажа автокомпонентов.

Численность персонала: 1200 человек.

Описание модели

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

Модель включает:

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

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

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

Техническое задание на автоматизацию

Нормативная 8-процессная модель деятельности производственного предприятия

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

Модель включает в себя:

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

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

Объект управленияПроцесс первого уровня
Бизнес-система Выработка согласованных условий деятельности
Продукт Разработка и модификация продуктов
Клиент Продвижение и продажи
Производственный цикл Производство продукции
Ресурсы Материально-техническое обеспечение
Технология Воспроизводство средств производства
Персонал Воспроизводство трудовых ресурсов
Финансы Финансирование деятельности и расчеты по обязательствам
Читайте также:  Формула расчёта ндфл 13 процентов

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

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

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

Модель компании «ИнТехПроект»

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

Модель включает:

Данная модель содержится в демо-версии системы Business Studio.

Модель производственной деятельности в соответствии со стандартом ИСО 9001:2000

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

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

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

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

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

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

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

В связи с этим, на практике, такую модель можно использовать как основу для анализа соответствия деятельности предприятия (по зонам ответственности — разделы стандарта) требованиям ИСО 9001:2000, а также как нормативную модель для разработки и внедрения СМК.

Совет

Свои предложения и замечания по моделям бизнес-процессов Вы можете сообщить по электронной почте: mail@businessstudio.ru.

Источник: https://www.businessstudio.ru/community/models/

Моделирование бизнес-процессов – обзор нотаций

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

Моделирование бизнес-процессов — VAD (value added chain diagram)

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

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

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

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

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

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

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

Модель нотации VAD можно нарисовать во множестве инструментов, например, в MS Visio, ARIS, Archi и многих других инструментах моделирования бизнес-процессов.

Моделирование бизнес-процессов – EPC (event-driven process chain)

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

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

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

Обратите внимание

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

Существует множество вариантов нотации EPC, в формате столбцов, строк, а также с разными перечнями используемых объектов, однако все эти варианты доступны только в инструментарии ARIS, тогда как в остальных инструментах, например, MS Visio или Business Studio доступно моделирование бизнес-процессов EPC лишь в классическом формате.

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

Моделирование бизнеспроцессов – BPMN (Business Process Model and Notation 2.0)

Нотация BPMN создана консорциумом Object Management Group (OMG) и предназначена для моделирования бизнес-процессов с целью их последующей автоматизации.

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

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

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

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

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

Важно

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

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

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

Моделирование бизнес-процессов — Flow Charting

Название нотации Flow Charting, проще всего перевести как блок-схемы. Данная нотация изначально появилась в стандарте ANSI в 1970 году, и содержит очень простой набор символов.

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

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

Нотация Flow Charting не имеет жесткого стандарта, что позволяет моделировать бизнес-процессы с различных точек зрения, добавляя те или иные объекты в модель по необходимости.

Этим данная нотация очень похожа на EPC, но имеет еще больше свободы в части применения.

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

Совет

Из недостатков Flow Charting можно выделить отсутствие типового перечня объектов и атрибутов, что является обратной стороной «свободы» данной нотации. Это позволяет моделировать один и тот же бизнес-процесс в данной нотации так, что модели будут серьёзно отличаться друг от друга.

Несмотря на то, что модели бизнес-процессов в нотации Flow Charting можно встретить достаточно часто, скорее всего она будет уходить в прошлое, уступая место более «строгим нотациям»

Моделирование бизнеспроцессов – IDEF (Integrated Definition Language)

Нотация IDEF появилась в 70 ых годах, как стандарт правительства США, фокусирующий внимание на входах, выходах, механизмах и средствах управления бизнес-процессом и увязывающий процессы организации в иерархию. Ключевым элементом данной нотации является функция, тогда как все остальные объекты и взаимодействия моделируются с помощью связей.

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

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

Моделирование бизнес-процессов – UML (Unified Modeling Languages)

Унифицированный язык моделирования (UML) – это набор нотаций и методов моделирования, предназначенных для описания требований к информационным системам, однако среди нотаций UML есть и специализированная нотация, предназначенная именно для моделирования бизнес-процессов.  UML поддерживается Object Management Group (OMG), что сделало данную методологию достаточно распространенной среди ИТ-специалистов.

Данная нотация очень похожа на EPC и BPMN, единственное отличие в отображении логических операторов и событий, и, хотя по нотации UML существует множество книг, и поддержана она множеством инструментов моделирования, используется UML Activiti Diagram в основном для системного анализа и проектирования, и лишь незначительное число компаний используют UML, чтобы моделировать бизнес-процессы

Моделирование бизнес-процессов – VSM (Value Stream Mapping)

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

Читайте также:  Сменный график работы: трудовой кодекс, норма часов

Нотация VSM была разработана как часть методологии бережливого производства, и использует набор специфических символов для отображения элементов затрат ресурсов и времени для анализа эффективности бизнес-процесса в проектах Lean 6Sigma.

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

Задача данной нотации вовлечь в анализ бизнес-процесса его участников, для того, чтобы стимулировать их к самостоятельному поиску возможностей оптимизации. Как правило модели VSM рисуются в проектах на Flip Chart и не требуют серьёзных средств моделирования бизнес-процессов, ведь на ее основании принимаются решения, а сама модель не становится основой ни для регламента, ни для ИТ-решения.

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

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

Моделирование бизнес-процессов – SIPOC

Аббревиатура SIPOC означает: Supplier (поставщик), Input (вход), Process (процесс), Output (выход), Customer (потребитель).

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

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

Обратите внимание

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

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

Моделирование бизнес-процессов – выводы

Итак, я рассмотрел некоторые нотации моделирования бизнес-процессов, которые можно встретить на российском рынке (более подробно они описаны в главе BPM CBOK, посвященной моделированию бизнес-процессов).

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

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

Ну а если необходимо автоматизировать бизнес-процесс в BPMS системе, то тут уже не обойтись без нотации BPMN.

Источник: http://koptelov.info/publikatsii/modelirovanie-biznes-protsessov/

Моделирование бизнес-процессов (стр. 1 из 3)

СОДЕРЖАНИЕ

Введение

1. Моделирование бизнес-процессов

2. Классификация бизнес-процессов

3. Стандарты моделирования бизнес-процессов

Заключение

Список используемых источников

ВВЕДЕНИЕ

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

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

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

Важно

Это и естественно, сложившийся годами коллектив всегда сложно заставить «думать по-новому».

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

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

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

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

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

Существует несколько подходов к определению понятия «моделирование бизнес-процессов»:

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

моделирование бизнес-процессов — это эффективное средство поиска возможностей улучшения деятельности предприятия;

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

моделирование бизнес-процессов — это метод, позволяющий дать стоимостную оценку каждому процессу, взятому в отдельности, и всем бизнес-процессам на предприятии, взятым в совокупности [1].

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

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

Совет

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

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

Решения по моделированию бизнес-процессов обычно принимается по причинам, представленным на рисунке 1.

Рисунок 1 — Причины, по которым принимается решение по моделированию бизнес-процессов

Моделирование бизнес-процессов затрагивает многие аспекты деятельности компании:

изменение организационной структуры;

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

перераспределение прав и обязанностей руководителей;

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

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

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

Структурное моделирование бизнес-процессов организации может выполняться в нотации IDEF0 с использованием инструментария BPwin или на языке UML с использованием инструментария Rational Rose. Детальное моделирование выполняется на языке UML.

На этапе структурного моделирования в модели должны быть отражены:

существующая организационная структура;

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

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

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

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

Детальная модель бизнес-процесса должна включать:

набор прецедентов отражающих возможные варианты выполнения бизнес-процессов «как есть»;

Обратите внимание

диаграммы действий, детально описывающие последовательность выполнения бизнес-процессов;

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

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

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

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

Бизнес-Модель — это то, что делает компания и благодаря чему она зарабатывает деньги (Том Мэлоун)

Бизнес-стратегия есть теория, бизнес-модель — гипотеза (Николас Карр)

Бизнес-модель — это представление набора связанных модельных элементов, определяющих внутреннюю и внешнюю среду компании в рамках единой системы [2].

2. КЛАССИФИКАЦИЯ БИЗНЕС-ПРОЦЕССОВ

Выделяют следующую классификацию [5]:

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

горизонтальные процессы – процессы, отражающие взаимодействие по горизонтали;

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

межфункциональные горизонтальные процессы – процессы, выполняемые многими работниками (организационными единицами);

вертикальные процессы – процессы, отражающие взаимодействие работников (организационных единиц) по вертикали;

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

В зависимости от степени их сложности выделяют:

монопроцессы – односложные процессы;

вложенные процессы — монопроцессы, входящие в состав более сложного процесса (макропроцесса);

Важно

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

В зависимости от их предназначения:

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

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

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

В зависимости от их места в иерархии целей организации:

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

бизнес-процессы среднего уровня – бизнес-процессы, направленные на реализацию тактических целей;

бизнес-процессы нижнего уровня бизнес-процессы, направленные на реализацию оперативных целей.

В зависимости от степени их детализации [4]:

макропроцессы – укрупненные бизнес-процессы имеющие степень детализации необходимую чтобы описать бизнес-процессы верхнего уровня;

Источник: http://MirZnanii.com/a/164155/modelirovanie-biznes-protsessov

Построение модели бизнес-процесса

Артур Хедж

Первый шаг к повышению эффективности процесса: определите, где вы сейчас находитесь.

Краткое описание процесса построения модели бизнес- процесса

Этап подготовки.

  • Определить границы процесса
  • Определить конечного потребителя процесса
  • Установить состав участников

Этап разработки модели процесса.

  • Определить инициирующее событие
  • Определить результат процесса
  • Создать диаграмму процесса
  • Определить исключения

Этап проверки (валидации).

  • Проверить соответствие диаграммы процесса действительности
  • Определить исключения

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

Читайте также:  Как написать заявление в трудовую инспекцию на работодателя: образец

Первым шагом в процессе создании ВРМ- приложений является разработка модели бизнес-процесса.

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

Совет

В этой статье обсуждается построение модели с помощью нотации графического представления бизнес-процессов (BusinessProcessModelingNotation — BPMN). Стандарт BPMN представляет собой типовой набор символов и правил для описания бизнес- процессов. Стандарт поддерживается консорциумом Object Model Group (OMG), спецификацию стандарта можно найти на сайте консорциума OMG.

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

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

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

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

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

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

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

Обратите внимание

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

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

Подготовка

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

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

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

Правильный вопрос, требующий ответа, звучит так: «Для кого непосредственно это все делается?».

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

Термин «участник» при описании процесса относится к лицу или системе, а термин «область» («pool») — к существующей диаграмме. Участники — это люди или вещи, принимающие участие в процессе, который моделируется. Людей лучше идентифицировать не по именам, а по ролям, которые они играют.

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

Абитуриенты на BPD представлены в виде областей, и к областям можно обращаться так же, как к дорожкам.

Важно

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

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

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

Начинаем составлять диаграмму

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

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

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

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

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

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

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

Совет

Еще раз хочется заострить внимание: очень важно обозначить стартовую и конечную точки именно с точки зрения пользователя.

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

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

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

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

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

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

Определяем шаги процесса

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

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

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

Обратите внимание

Например, описание «Рассмотреть заявление» означает, что приемная комиссия должна рассмотреть заявление абитуриента.

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

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

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

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

Проверка

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

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

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

Важно

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

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

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

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

Перевод компании DIRECTUM

Источник: AIIM (Developing a Business Process Model)

Источник: https://bpmsoft.org/postroenie-biznes-processov/

Ссылка на основную публикацию