Бизнес-процессы: нотификации и моделирование, что выбрать?

Обновлено: 16 сент.

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

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

Основные подходы к описанию бизнес-процессов

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

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

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

Условно существует несколько подходов к описанию бизнес-процессов:

Диаграммы цепочки добавленной ценности (VAD - value added chain diagram)

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

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

Правила построения модели процесса добавленной стоимости (VAD)

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

  2. Далее выстраивается их логическая взаимосвязь

  3. Определяются и указываются владелец и подразделение, отвечающие за процесс

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

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

  6. Каждому верхнеуровневому бизнес-процессу прописываются или прикрепляются ссылки на диаграммы (VAD или EPC) более низкого уровня.

Видео:

Полезные ссылки:

SIPOC

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

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

  • Input (входах) – ресурсы для бизнес-процесса: материалы, деньги, производственные мощности);

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

  • Output (выходах) – продукты деятельности бизнес-процесса;

  • Customer (заказчиках) – получатели услуги, те кто пользуется продуктом бизнес-процесса.

Алгоритм описания бизнес-процессов:

1. Определение заказчика бизнес-процесса;

2. Описание итогового продукта (выхода), который нужен заказчику;

3. 5-7 ключевых операций бизнес-процесса;

4. Определение необходимых ресурсов (входов) для бизнес-процесса;

5. Определение поставщиков этих ресурсов.

Видео:

Полезные ссылки:

Событийная цепочка процессов (EPC - event-driven process chain)

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

Основные элементы описания:

  • Событие – что-то, что создает необходимость действия.

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

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

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

В отличии от предыдущего подхода, где начало было слева и финиш справа, здесь все стартует сверху и идет вниз.

Алгоритм описания:

  1. Определяем, что у нас есть и чего мы хотим – граничные события.

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

  3. Добавляем всю необходимую информацию об исполнителях и ресурсах.

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

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

Полезные ссылки:

BPMN 2.0 (Business Process Model and Notation 2.0)

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

Видео:


Полезные ссылки:

Flow Charting (нотации Процесс и Процедура)

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

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

Видео:

Полезные ссылки:

IDEF (Integrated Definition Language)

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

К семейству IDEFотносятся следующие стандарты:

  • IDEF0 — методология функционального моделирования (Function Modeling). Наиболее часто встречаемый подходDEF1 и IDEF1X - Информационное моделирование (Information and Data Modeling Method). В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях, так называемый язык диаграмм "сущность-связь". Наиболее популярный подход в настоящее время

  • IDEF1 и IDEF1X - Информационное моделирование (Information and Data Modeling Method). В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях, так называемый язык диаграмм "сущность-связь".

  • IDEF2 - Поведенческое моделирование (Simulation Modeling Method). В основе поведенческого моделирования лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри.

  • IDEF3 - Моделирование деятельности (Process Flow and Object Stale Description Capture Method). В методике детализируется ответ на вопрос не "что система делает", а "как система это делает".

  • IDEF4 - Объективно-ориентированное проектирование (Object-oriented Design Method). Модель предоставляет пользователю графический язык для изображения классов, диаграмм наследования, таксономии методов.

  • IDEF5 - Систематизация объектов приложения (Ontology Description Capture Method). Модель представляет онтологической информации приложения в удобном для пользователя виде, Для этого используются символические обозначения (дескрипторы) объектов, их ассоциаций, ситуаций и схемный язык описания отношений классификации, "часть-целое", перехода и т. п. В методике имеются правила связывания объектов (термов) в предложения и аксиомы интерпретации термов.

  • IDEF6 - Использование рационального опыта проектирования (Design Rational Capture Method). Способствует предотвращению структурных ошибок.

  • IDEF8 - Взаимодействие человека и системы (Human-System Interaction Design). Модель предназначена для проектирования диалогов человека и технической системы.

  • IDEF9 - Учет условий и ограничений (Business Constraint Discovery). Модель предназначена для анализа имеющихся условий и ограничений (в том числе физических, юридических, политических) и их влияния на принимаемые решения в процессе реинжиниринга.

  • IDEF14 - Моделирование вычислительных сетей (Network Design). Модель предназначена для представления и анализа данных при проектировании вычислительных сетей на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности и т.п.

Полезные ссылки

Видео

UML (Unified Modeling Languages)

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

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

  1. Диаграмма прецедентов (Use-case diagram). В основе — Actor (исполнитель), который устанавливает логические связи между ролями и прецедентами и Use case (сам прецедент), демонстрирующий какой именно процесс исполняется.

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

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

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

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

Полезные ссылки:

Видео

VSM (Value Stream Mapping)

Один из инструментов бережливого производства, наряду с SIPOC. Также Value Streams являются основополагающим компонентом SAFe® (Scaled Agile Framework®) и бывают двух типов: разработческие (Development Value Stream, DVS) и операционные (Operational Value Stream, OVS).

Value Stream Mapping — это инструмент, который визуализирует процесс превращения сырья в готовую продукцию, отпускаемую потребителям. Его объекты — материальные и информационные потоки ресурсов, а также время.

Создание Value Stream Mapping делится на три блока:

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

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

  3. Timeline и расстояния — линии, которые рисуются в нижней части карты. Линия времени делится на верхнюю и нижнюю части. Сверху отображается lead time — время ожидания. Снизу наносится продолжительность цикла. Под линией времени может находиться еще одна линия, в самом низу, показывает расстояния, по которым продукт или персонал движутся внутри процесса.

https://worksection.com/blog/value-stream-mapping.html
https://worksection.com/blog/value-stream-mapping.html

Упрощенный алгоритм работы:

Шаг 1. Выбор процесса для систематизации потока ценности (подготовительный)

Шаг 2. Символы Value Stream Mapping

Шаг 3. Определение границ процесса

Шаг 4. Шаги процесса

Шаг 5. Добавление информационных потоков на карту

Шаг 6. Добавление данных о каждом шаге процесса

Шаг 7. Подсчет запасов

Шаг 8. Добавление хронологии процесса — Timeline

Шаг 9. Карта будущего состояния

Шаг 10. План для внедрения улучшений

Полезные ссылки:

Видео

Заключение

Если вы дочитали эту статью, то вероятнее всего у Вас в голове вопрос: "А какую нотацию то выбрать? Какая лучше?" Ответ довольно простой - никакая. Нужно выбирать нотацию под задачу и команду. Главный критерий - чтобы было понятно. Нужно понять, кто будет пользоваться Вашей схемой, каков уровень компетенций этих людей. Если Вы молодая команда / руководитель, то начните с "высокоуровневных" нотаций, например с VAD, VSM. Так Вы поймете, как в целом работает Ваша команда. Далее, как показывает практика, хорошо работает Flow Charting в нотации Процесс. Она проста и подходит для управления отдельном процессом. Также отличный вариант нотация Процедура в этом же подходе. Для рабочего персонала в нашей практике хорошо работает обыкновенная блок схема.

При этом наиболее типовая ошибка – рисование огромных карт. Это неправильно. Никто не будет смотреть на простыни. Выбирайте «кусок» так, чтобы он помещался на 1 экран или лист А4.

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

Еще один пример - адаптация нотации Процесс

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

Для задач же бизнес-анализа и глубокого погружения уже необходимо использовать BPMN 2.0 или EPC, для проектирования ИТ-систем - IDEF.

Еще одно правило - думайте о том, какая культура в вашей компании

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

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

Полезные материалы

Решения_класса_BPM
.xlsx
Download XLSX • 17KB