Карантин — время свободное от “текучки” и операционки. Для предпринимателя — это отличная возможность заняться стратегическими и тактическими вопросами своего бизнеса. Описание и оптимизация бизнес-процессов — подходящее занятие для освободившегося времени.
Моя команда специализируется на разработке франчайзинговых программ. Важной частью упаковки франшизы является разработка правил и стандартов ведения бизнеса компании. Эти правила обычно описываются в форме методического материала, который называют кто во что горазд: бизнес-бук, гайд, руководство партнера и так далее. Методичка эта обычно включает описание бизнес-процессов.
В этой статье я постараюсь поделиться опытом описания бизнес-процессов, дать нескольких простых и понятных способов, а также дать рекомендации, которые, надеюсь, помогут в вашем процессоописательном деле. Моя цель, чтобы после прочтения вы поняли, что описать процессы вашей компании — это просто, сели за комп и попробовали набросать процессы вашей компании.
В работе с процессами очень важна лаконичность, краткость, понятность. Улучшать описательную часть можно сколь угодно долго, стремиться к идеалу можно бесконечно, но если описание понятно:
собственнику, который заинтересован, чтобы процесс корректно работал.
и исполнителю, который с этим процессом будет работать, значит ваш бизнес-процесс описан идеально.
Для примера возьмем всем понятный процесс — прием заказа официантом.
Зачем описывать бизнес-процессы
Если у вас мелкий бизнес, где все на виду и вы в оперативном режиме управляете всем, что происходит в компании, возможно, вам не нужно описывать процессы. Не стоит описывать процессы если вы хотите сделать это для галочки, чтобы где-то на полке лежала красивая книга с какими-то умными схемами.
Описание бизнес-процессов поможет чтобы:
- снизить зависимость от сотрудников, которые со своим уходом заберут понимание того, как следует выполнять те или иные операции в компании.
- упростить адаптацию новых сотрудников. Куда удобнее получить знания в графической или текстовой форме, чем «вытягивать» знания из старшего сотрудника.
- улучшить то или иное действие. Чтобы что-то усовершенствовать, нужно понимать, как именно это работает по состоянию на сегодняшний день.
- появляется возможность контроля качества. Если не описано как правильно, нет возможности выявить отклонения от нормы.
Какие бизнес-процессы стоит описывать.
Обычно выделяют 4 вида процессов:
- Основные процессы — это те процессы, которые составляют основу бизнеса. В этот раздел можно отнести процессы, которые напрямую влияют на создание ценности для потребителя, удовлетворение потребностей потребителя и напрямую влияют на извлечение прибыли.
- Поддерживающие процессы — это процессы, которые нужны для корректной работы основных процессов.
- Процессы управления определяют движение и развитие компании. Можно выделить: a) стратегический уровень (3-5 лет или меньше) b) тактический уровень с) (1-4 месяца)оперативный уровень (1 неделя). Они отличаются в основном горизонтами будущего, в которое целится вектор движения
- Процессы совершенствования — в этот блок можно отнести процессы, которые помогают управленческому уровню достигать своих целей на всех трех уровнях. Сюда можно отнести процессы обработки новых инициатив от сотрудников, сортировка и прием в работу инициатив и предложений от потребителей.
Оформление бизнес-процесса
Оформим описание в виде официального документа на официальном бланке. В шапке укажем:
Исполнителя (должности или ФИО) — сотрудники, которые непосредственно задействованы в процессе. Каждый сотрудник отвечает за свой участок процесса.
Руководителя — сотрудник, который отвечает за работоспособность всего процесса.
Архитектор — лицо, которое разработало процесс и к которому нужно обращаться если что-то в процессе не работает и требует доработки.
Шапку оформили, теперь опишем саму суть процесса. Существует несколько способов для описания процессов. Рассмотрим их от простого к сложному, выбирайте тот, который вам больше подходит. Какой бы способ вы ни выбрали, руководствуйтесь принципом 5W+H, чтобы было понятно:
Who (Кто)
When (Когда)
Where (Где)
Why (Зачем)
What (Что)
и How (Как) будет делать.
Текстовое описание процесса
В виде обычного текста иногда описывают процессы в должностных инструкциях, политиках компании. Описываем детально 5W+H в формате текста.
Некоторые процессы просто невозможно описать ввиду их сложности. Мелкие процессы возможно и стоит так описывать. Обычно текстом описывают процессы, в котором не так много действующих лиц и мало взаимодействий между отделами.
Процесс в виде таблицы
Способ удобен для описания простых операций и лучше всего подходит для действий, которые должны происходит по цепочке, как конвейер. Сложные взаимосвязи таким способом довольно сложно описать.
Описание процесса в виде блок-схемы
Этот способ подходит для описания процессов, которые не требуют много дополнительных текстовых пояснений, за счет стрелок и прямоугольников получается удобно проиллюстрировать сложные взаимосвязи между исполнителями и отделами.
При описании процессов методом блоков-схем есть определенная установленная система обозначений. Например, ромб, как в нашем примере является блоком принятия решений, цилиндром обычно обозначают базы данных или информационные системы. Серым на схеме обозначены документы, которые регламентируют каждый из участков процесса. Систему обозначений можно найти в интернете, глубоко погружаться в эту тему не будем.
Метод SIPOC
Это метод, назван по первым буквам блоков, которые задействованы в описании.Каждая новая строка — это новая операция процесса.Чтобы описать процесс вы должны указать в каждой операции:
Supplier (Поставщик) — кто двигает конкретную операцию. В нашем примере, рассадку определяет гость, а клиентом является официант. Вы сами вольны определять роли в каждой операции в соответствии со своим видением. Поставщик предоставляет входящую информацию в операции.
Input (Вход) — входящие данные, необходимые для запуска и реализации операции.
Process (Процесс) — непосредственный набор действий, определяющий операцию.
Output (Выход) — данные на выходе операции, итог операции.
Client (Пользователь процесса) — фактический получатель выходных данных из операции.
SIPOС — удобная система описания процесса, но в ней нужно разобраться.
Этот метод является оптимальным для описания процессов. Он лаконичен, информативен и подходит для описания большого количества операций. Он немного отличается от привычной логики и наверное, для описания простых процессов для линейного персонала его выбирать не стоит.
Общие рекомендации к внедрению процессов
Описывайте лаконично и понятно. «Сушите» текст по-полной программе, оставляйте только самое важное.
Привлекайте исполнителей процесса к описанию разработке и описанию процессов. В противном случае, процесс останется на бумаге.
В компании работают люди, а не роботы. Оптимизация процессов должна происходить постепенно. Люди не любят перемены, даже если они позитивные.
Прежде, чем внедрять процессы в работу, необходимо подготовить сотрудников.
Описание бизнес-процессов — отличный способ разобраться в том, как работает компания. Предприниматель может взглянуть на процесс и понять, что в его компании работает не так, как нужно. В наших проектах по упаковке франшиз, без этого инструмента, мы как без рук. Как еще в сжатой понятной форме передать информацию о том, как стоит построить работу предприятия, на что обратить внимание.
Надеюсь, вы последуете моему совету, который я давал в начале статьи и прямо сейчас сядете за описание процессов вашей компании: сперва крупными мазками, а потом все глубже и глубже детализируя.
Желаю успехов!
Способы описания бизнес-процессов
Компании, которые решили следовать тренду на цифровую трансформацию бизнеса становятся перед выбором – что использовать при работе с бизнес-процессами? Ведь практически любой средний и крупный бизнес нуждается в четкий и регламентированных процессах, которые способны ускорить и улучшить его работу. На сегодняшний день выделяют 3 основных способа описания бизнес-процессов – текстовый, табличный и графический. Мы уже писали о текстовом способе описания Б-П, как о непрактичном, который подходит для малого бизнеса или для описания коротких процессов. Табличный способ отличается большей практичностью и наглядностью. Используя данный способ можно описывать как простые, так и сложные процессы. Впрочем, рассмотрим более детально.
Как это работает – пример?
Изначально определяется Б-П, который необходимо описать, составляется список участников процесса, операций, которые они выполняют и результат, который должен быть на выходе из бизнес-процесса. Результатом, в зависимости от типа процесса, может быть подписанный договор, оформленный заказ, завизированная заявка HR и т.д.
Рассмотрим на примере, как это работает на примере бизнес-процесса визирования заявки в HR-департаменте:
| № | Действие | Ответствен- ный |
Данные на входе | От кого | Данные на выходе | Получатель |
| 1 | Составляет заявку | Сотрудник компании | – | – | Завизирован- ная заявка |
HR-департамент |
| 2 | Визирует заявку | HR-департамент | Заявка | От сотрудника | – | – |
Как видим, запускает процесс (заказчик процесса) это сотрудник, визирование и итог процесса у HR-подразделения. Большинство компаний уже перевели все подобные заявки в электронный вид. Уже не нужно ходить по кабинетам чтобы оформить типичную заявку на отпуск, отгул, перенос рабочего дня и т.д. Аналогичная схема описания подходит к процессам, которые связаны с продажами, оформлением заказов на доставку и др.
Преимущества данного способа – можно описывать процессы любой сложности и
смотреть на полную картину работы каждого подразделения. Анализ позволит быстро
откорректировать проблемные места и улучшить работу.
Табличный или графический способ описания?
Графический способ описания считается наиболее практичным и эффективным, однако для его реализации необходимо специализированное ПО, которое называется BPM-системы. Не всегда у компании есть средства на покупку лицензий, что делает табличный способ описания отличной альтернативной. Вносить корректировки в таблицу не так просто, как в блок-схемы, однако уже намного удобнее, чем при текстовом способе.
Подводя итог, можно сказать – табличный способ описания бизнес-процессов считается одним из лучших решений для компаний, которые уже хотят работать и описывать бизнес-процессы, но пока не обладают необходимым бюджетом на BPMS-решения.
От текстового описания до систем Business Process Analysis
Внедрение процессного управления в компаниях, как правило, сопровождается определением ключевых бизнес-процессов и их последующим описанием, анализом и оптимизацией. В бизнес-процессах участвует множество исполнителей от разных подразделений, создается множество документов, а главное присутствует сложная логика взаимодействия исполнителей между собой, что требует отображения процесса формате, удобном для восприятия и анализа.
Описание существующего состояния бизнес-процесса, в статусе «как есть», позволяет не только зафиксировать существующее состояние дел, но и провести первичный анализ бизнес-процесса. Тогда как описание бизнес-процесса в статусе «как должно быть» позволяет формализовать, и главное регламентировать новое состояние бизнес-процесса для его последующего внедрения в практику компании.
Текстовый формат описания бизнес-процесса
Существует множество примеров регламентов бизнес-процессов, которые достигают сотни листов, однако, чем больше по объему такой документ, тем меньше шансов, что его прочтут, и тем более станут исполнять. Именно поэтому, необходимо описывать бизнес-процессы предельно короткими документами в формате структурированного текста, фокусируясь на том, кто, что делает, и в какой срок.
Секретом описания бизнес-процессов в виде структурированного текста является следование четкой структуре – сначала фиксируется кто и когда исполняет операцию, а далее в подпункте, уровнем ниже, описываются сами действия, после чего указывается кому и в каком случае передается результат.
Таким образом, шаг за шагом описывается весь бизнес-процесс с указанием перечня документов, которые передаются по процессу и информационных систем, которые используются для выполнения той или иной операции.
На практике даже очень «масштабные» бизнес-процессы могут быть легко описаны в такой структуре, при этом, преимуществом текстового подхода является его простота и доступность не только бизнес-аналитикам, но и любому сотруднику компании. Используя эти простейшие правила структуризации текста в компании, можно легко создать систему регламентов, стандартизирующих ключевые бизнес-процессы.
Недостатком текстового описания, является возможность «спрятать» в нем недосказанности и неточности в бизнес-процессе, которые можно обнаружить лишь внимательно «вычитывая» получившийся документ. Однако несмотря на недостатки, на начальных этапах управления бизнес-процессами, структурированное текстовое описание позволяет провести первичный анализ бизнес-процессов в компании, а также закрепить их целевое состояние в виде утвержденного регламента.
Табличный формат описания бизнес-процесса
Относительно варианта описания процессов в текстовом формате, использование табличной формы добавляет «структурированности» создаваемому описанию бизнес-процесса.
Бизнес-процесс описывается в виде таблицы, где строки описывают операции в бизнес-процессе, при этом каждая строка содержит не только номер и название операции, но и входящие и исходящие документы, временные нормативы исполнения, исполнителя, используемые информационные системы и логику дальнейших действий. Фактически при описании бизнес-процесса в табличной форме создаются технологические карты, подробно описывающие все необходимые действия с указанием их окружения.
В зависимости от поставленных задач, в табличном описании можно отображать различные элементы окружения бизнес-процесса, например, если в компании идет работа с операционными рисками, можно добавить дополнительный столбец в таблицу, в котором указать существующие операционные риски с их привязкой к операциям процесса.
С использованием единого шаблона таблицы и простой инструкции по ее заполнению, достаточно легко описать ключевые бизнес-процессы в компании силами сотрудников бизнес-подразделений, при этом качество полученного описания безусловно будет выше, чем в текстовом формате, однако результат будет иметь недостаточную визуализацию, относительно описания процесса в виде графической модели.
Единственным недостатком табличной формы, является сложность отображений логики бизнес-процесса, так как для каждой операции в таблице приходится описывать в каком случае какое действие выполняется, например, «если документ согласован, то далее выполняется операция 5, а если не согласован, то выполняется операция 6», что не всегда удобно для понимания особенностей бизнес-процесса и его анализа.
Графическая модель бизнес-процесса
В последнее время многие компании описывают бизнес-процессы в формате графических моделей. Это может быть схема, нарисованная на флипчарте, а может быть модель, нарисованная в специальном инструменте, в соответствии с утвержденной в компании нотацией.
Для большинства компаний, описывающих процессы в графической форме, инструментарием моделирования бизнес-процессов является MS Visio или MS Power Point. Эти инструменты входят в стандартный офисный пакет, что позволяет создавать модели бизнес-процессов широкому кругу лиц.
В дополнении к существующим инструментам, относительно недавно появились облачные бесплатные средства моделирования бизнес-процессов, в которых можно нарисовать модель в браузере, при этом сохранить результат, либо на диске, либо в облачном хранилище.
Учитывая бесплатность и легкость начала использования облачных средств моделирования бизнес-процессов, они быстро завоевывают поклонников, как среди бизнес-аналитиков и ИТ-специалистов, так и среди сотрудников и руководителей компании.
С помощью графической модели бизнес-процесс может быть описан наиболее качественно, ведь в ней можно отразить не только все необходимое окружение операций, но и визуализировать саму логику бизнес-процесса с помощью логических операторов и событий.
Правда, в случае использования графической формы моделирования бизнес-процессов, количество сотрудников в компании, создающих модели бизнес-процессов может серьёзно уменьшиться, так как некоторых из них оттолкнёт сложность инструментария и дополнительные трудозатраты на создание графических моделей, относительно текстового и табличного описания.
Для того, чтобы среди тех, кто моделирует бизнес-процессы в компании было как можно больше представителей бизнес-подразделений, необходимо выбирать инструменты моделирования с удобным и простым интерфейсом, а также использовать простейшие нотации для отображения процессов.
Система моделирования бизнес-процессов
Некоторые компании, имеющие большое количество сотрудников и высокую зрелость в области управления бизнес-процессами, переходят от простейших инструментов моделирования бизнес-процессов к системам класса Business Process Analysis, которые позволяют моделировать бизнес-процессы в едином репозитории, что позволяет не только создать целостную взаимосогласованную модель описания деятельности организации, но и получать на ее основе регламентирующие документы с помощью настраиваемой отчетности.
Как правило, если количество нарисованных в компании моделей бизнес-процессов начинает превышать несколько тысяч, то возникает необходимость обеспечить их интеграцию между собой, а также получить возможность создания регламентирующей документации на базе созданных моделей, именно в этом случае применение инструментария Business Process Analysis является оправданным.
Работа в инструментах Business Process Analysis требует жесткой дисциплины при моделировании бизнес-процессов, которая достигается через нормализацию справочников организационной структуры, документов и информационных систем, а также утверждение нотации моделирования бизнес-процессов и аудит соответствия создаваемых моделей утвержденной нотации или на уровне инструментария, или с помощью процедур согласования.
Использование средств Business Process Analysis имеет и определенные риски, связанные как раз с необходимостью жесткой дисциплины при создании моделей и со сложностью интерфейса инструментария, что приводит к уменьшению числа моделирующих бизнес-процессы среди представителей бизнес-подразделений. В результате достаточно часто работа в инструментарии Business Process Analysis становится прерогативой бизнес-аналитиков и ИТ специалистов, что сужает возможные ресурсы для моделирования бизнес-процессов в компании, и приводит либо к расширению штата бизнес-аналитиков, либо к привлечению внешних консультантов. При этом, бизнес часто не желает работать с полученными моделями и возвращается к текстовому или табличному формату описания бизнес-процессов, полученному с помощью отчетов из инструментария Business Process Analysis.
От моделирования к автоматизации
Не секрет, что несмотря на созданные регламенты бизнес-процессов, сотрудники компании часто работают по своим правилам, ведь проконтролировать правильность исполнения регламента достаточно непросто, а проводимые аудиты требуют дополнительных трудозатрат.
Совершенно логично переложить контроль правильности исполнения бизнес-процессов на автоматизированную систему, в которой заложить всю необходимую логику его исполнения. При использовании специализированных систем класса Business Process Management Suite, модель бизнес-процесса становится исполняемой, и информационная система сама управляет бизнес-процессом в соответствии с правилами, описанными в модели, назначая исполнителей операций и маршрутизируя заявки в соответствии с логикой бизнес-процесса.
В данном случае модель становится необходимым условием для автоматизации бизнес-процесса, однако данная модель бизнес-процесса требует куда более подробной проработки, ведь она должна быть «понятна» информационной системе, автоматизирующей процесс.
Столь специфичный «потребитель» модели бизнес-процесса делает ее разработку непростым занятием, для которого, как правило, привлекается системный аналитик или даже ИТ-разработчик, которой хорошо знает систему автоматизации. Представители бизнеса или бизнес-аналитики в данном случае могут представить лишь прототип такой модели, после чего согласованный прототип необходимо серьезно дорабатывать с учетом особенностей BPMS системы.
Что же выбрать?
Что бы определиться с форматами описания бизнес-процессов нужно проанализировать размер организации, ее зрелость в области управления бизнес-процессами, а также определить потребителей создаваемого описания.
В компании от 50 до 500 человек для совершенствования и регламентации бизнес-процессов вполне достаточно текстового или табличного описания процессов, при этом, описание может вестись силами сотрудников и руководителей, прошедших специализированное обучение по теме управления бизнес-процессами.
В компании от 500 до 5000 человек, также можно ограничится текстовым или табличным описанием, используя графические нотации для визуализации особо «запутанных» бизнес-процессов с большим количеством участников. В компаниях такого масштаба для систематизации создаваемого описания необходимо уже вести реестр бизнес-процессов и регламентов, а также создать шаблоны, как для регламентов, так и для графических моделей.
В крупных компаниях с численностью от 5 000 человек, с развитым процессным офисом и высокой зрелостью в управлении бизнес-процессами, можно задуматься о применении средств Business Process Analysis для моделирования бизнес-процессов, в рамках которых создать единый репозиторий моделей бизнес-процессов, после чего формировать на его основе регламенты бизнес-процессов и другую нормативную документацию.
Системы BPMS наиболее эффективны там, где важна скорость и контроль логики исполнения бизнес-процессов, поэтому их чаще всего можно встретить в тех процессах, где обрабатываются клиентские заявки, заказы, жалобы и договора, вне зависимости от масштаба компании.
Андрей Коптелов, опубликовано на c-news.ru
СПОСОБЫ ОПИСАНИЯ БИЗНЕС-ПРОЦЕССА
Давайте рассмотрим основные подходы к горизонтальному описанию бизнес-процессов. В настоящее время существуют три основных способа описания:
1. Текстовый: «Отдел продаж составляет договор и согласует его с юридическим отделом».
2. Табличный.
|
№ |
Операция |
Ответственный |
Что (Вход) |
От кого (Поставщик) |
Что (Выход) |
Кому (Клиент) |
|
1 |
Составляет договор |
Отдел продаж |
— |
— |
Договор |
Юридический отдел |
|
2 |
Согласует договор |
Юридический отдел |
Договор |
Отдел продаж |
3. Графический.
Первый способ есть не что иное, как текстовое последовательное описание бизнес-процесса. Пример текстового описания фрагмента бизнес-процесса приведен выше.
Многие российские компании разработали и используют в своей деятельности регламентирующие документы, часть которых является процессными регламентами и представляет не что иное, как текстовое описание бизнес-процессов.
Но для целей анализа и оптимизации деятельности компании данный вариант не оптимален. Дело в том, что описание бизнес-процесса в текстовом виде системно рассмотреть и проанализировать невозможно. Текстовая информация воспринимается человеческим мозгом последовательно. Например, когда человек читает регламент и доходит до его конца, он практически всегда забывает про то, что было в начале документа. Второй недостаток текстового представления бизнес-процесса заключается в том, что человеческое сознание устроено так, что оно может работать эффективно только с образами. При восприятии и анализе текстовой информации человеческий мозг раскладывает ее на ряд образов, на что уходят дополнительное время и умственные усилия. Поэтому при использовании текстового описания бизнес-процессов производительность и качество решений по оптимизации деятельности оставляют желать лучшего, что особенно сильно проявляется, когда решение принимается группой людей.
В свое время специалисты по информационным технологиям разработали более структурированный подход к описанию бизнес-процессов. Ими было предложено разбить бизнес-процесс по ячейкам структурированной таблицы, в которой каждый столбец и строчка имеют определенное значение. Данную таблицу читать проще, из нее легче понять, кто за что отвечает, в какой последовательности в бизнес-процессе выполняются работы, и, соответственно, бизнес-процесс проще проанализировать. Табличная форма описания бизнес-процессов более эффективна по сравнению с текстовой и в настоящее время активно применяется специалистами по информационным технологиям для описания бизнес-процессов в приложении к задачам их автоматизации.
В последнее время стали интенсивно развиваться и применяться при описании бизнес-процессов графические подходы. Признано, что графические методы обладают наибольшей эффективностью при решении задач по описанию, анализу и оптимизации деятельности компании.
Оказалось, что графика хороша тем, что графическая информация, расположенная в поле зрения человека, воспринимается его мозгом одновременно. Второе преимущество в том, что менеджер, как и любой человек, имеет правополушарное мышление и мыслит в виде образов. Любую текстовую информацию он переводит в образы. В случае когда ему представляется информация в виде графических образов, значительно возрастают его возможности анализа и принятия решений. В статье будут рассматриваться именно графические подходы к описанию процессов, так как они себя хорошо зарекомендовали и их можно эффективно использовать для оптимизации деятельности организации.
ОПИСАНИЕ ОКРУЖЕНИЯ БИЗНЕС-ПРОЦЕССА
Первый шаг описания бизнес-процесса — описание его окружения, которое представляет совокупность входов и выходов бизнес-процесса с указанием поставщиков и клиентов. Поставщики и клиенты процесса могут быть как внутренними, так и внешними. Внутренними поставщиками и клиентами являются подразделения и сотрудники компании, которые взаимодействуют с данным процессом.
Пример 1
В бизнес-процессе «Поиск, подбор и прием сотрудника в штат компании» входом является заявка на подбор сотрудника, поступающего из профильного подразделения, которое в данном случае является внутренним поставщиком процесса. Выходом процесса является принятый на работу сотрудник, который направляется в данное профильное подразделение, и в этом случае профильное подразделение одновременно является и внутренним клиентом бизнес-процесса.
За счет четкого обозначения входов, выходов, поставщиков и клиентов горизонтальное описание бизнес-процесса позволяет более точно представить бизнес-процесс и его границы. В этом и заключается одно из его преимуществ перед вертикальным подходом.
Пример 2
В одной компании было осуществлено вертикальное описание деятельности, в рамках которого был сформулирован перечень процессов и работ, реализуемых в компании. Среди данных бизнес-процессов был процесс, который назывался «Комиссионирование». Новые сотрудники, приходящие в компанию, долго не могли понять, что это за бизнес-процесс. Интересно, что и сотрудники, проработавшие несколько лет в данной организации, путано и по-разному объясняли его структуру.
Для вертикального описания деятельности это считается вполне естественной ситуацией, так как только одним названием невозможно четко определить бизнес-процесс. Когда данная организация применила горизонтальное описание, в рамках которого было описано окружение этого процесса, то оказалось следующее. Входом бизнес-процесса «Комиссионирование» была заявка на набор заказа, которая поступала от внутреннего поставщика процесса — отдела сбыта. Выходом этого процесса является собранный заказ, внутренним клиентом которого был отдел доставки, далее доставлявший заказ внешнему клиенту. Сейчас можно догадаться, что бизнес-процесс «Комиссионирование» представляет собой набор заказа для клиента и что этот процесс происходил на складе. Только описание входов и выходов позволяет точно и конкретно описать границы бизнес-процесса, и зачастую без горизонтального описания бизнес-процессов в сложных ситуациях обойтись практически невозможно.
При описании окружения бизнес-процесса рекомендуется построить его графическую схему (рис. 1).
КЛАССИФИКАЦИЯ ВХОДОВ И ВЫХОДОВ БИЗНЕС-ПРОЦЕССОВ
При описании окружения бизнес-процесса приходится его входы и выходы делить на два типа: первичные и вторичные. В результате такого деления получаются первичные и вторичные входы, а также первичные и вторичные выходы.
Это делается для того, чтобы не нарушать принцип Парето 20 на 80. Дело в том, что когда описывается окружение бизнес-процесса, количество различных входов и выходов оказывается очень большим, в результате чего и описанное окружение получается чрезвычайно громоздким и насыщенным. На это уходит много времени и сил, и при этом малосущественная для анализа и принятия решения информация будет без необходимости затруднять видение, что в дальнейшем может привести к неуспешности проекта по оптимизации деятельности компании. Для того чтобы отделить существенное от несущественного, используется деление входов и выходов бизнес-процесса на первичные и вторичные. Чтобы провести такое разделение, нужно воспользоваться определениями, приведенными в таблице, и примерами.
Характеристики первичных и вторичных входов и выходов бизнес-процесса
|
Элемент |
Определение и характеристики |
|
Первичный выход |
· Основной результат, ради которого существует бизнес-процесс. · Определяется целью, назначением бизнес-процесса. |
|
Вторичный выход |
· Побочный продукт бизнес-процесса, который может быть востребован вторичными клиентами. · Не является основной целью бизнес-процесса. |
|
Первичный вход |
Поток объектов, инициирующий «запуск» бизнес-процесса, например заказ клиента, план закупок и т.д. |
|
Вторичный вход |
Потоки объектов, обеспечивающие нормальное протекание бизнес-процесса, например стандарты, правила, механизмы выполнения действий, оборудование и пр. |
Первичный вход — это вход, который инициирует начало бизнес-процесса. В примере с бизнес-процессом «Комиссионирование» заявка на набор заказа является первичным входом. В данном процессе наборщицы, которые набирают заказ, используют тару, которая тоже является входом, но это вход вторичный, он не инициирует бизнес-процесс.
При описании бизнес-процесса нужно сделать акцент на первичные входы и показать их. Про вторичные входы можно забыть. Они будут автоматически описаны при дальнейшей детализации процесса, так как на более низком уровне найдутся операции, для которых данные входы являются первичными.
То же самое относится и к выходам. Первичным выходом называют такой выход, ради которого процесс существует. В примере с бизнес-процессом «Комиссионирование» первичным выходом является собранный заказ. При выполнении данного бизнес-процесса имелись и другие выходы. Если складская ячейка, содержащая определенную товарную позицию, оказывалась пуста, то наборщица информировала об этом складских рабочих, в чьи обязанности входит бизнес-процесс «Подпитка ячеек». Эта информация также является выходом, но этот выход не первичный для бизнес-процесса «Комиссионирование», ради него процесс не существует. Следовательно, он является вторичным.
Данный инструментарий первичности-вторичности нужно использовать для того, чтобы упростить, ускорить и повысить качество работ по описанию и оптимизации деятельности компании. Правило его использования следующее: при описании окружения бизнес-процесса нужно сделать акцент на описание его первичных входов и выходов; вторичные входы и выходы нужно описывать на более детальном уровне, когда найдутся подпроцессы, для которых эти входы и выходы станут первичными.
КЛАССИЧЕСКАЯ МЕТОДОЛОГИЯ ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ
После описания окружения бизнес-процесса наступает очередь описания его внутренней структуры. При вертикальном описании были показаны работы, из которых бизнес-процесс состоит. На этапе горизонтального описания описываются взаимодействия между работами, включая материальные и информационные потоки.
В настоящее время существует несколько десятков подходов, или стандартов, описания бизнес-процессов — ARIS, IDEF0 и др. При этом перед людьми, желающими освоить навыки описания и оптимизации бизнес-процессов, часто встает трудная задача: разобраться во всем этом многообразии и принять окончательное решение о том, какой стандарт в данной ситуации использовать.
Кажущаяся на первый взгляд сложность описания бизнес-процессов преувеличена. Классическая технология описания бизнес-процессов, которая была разработана на заре рождения процессных технологий управления, достаточно проста и состоит всего лишь из двух стандартов описания бизнес-процессов — DFD и WFD. Большинство других современных стандартов, несмотря на другие названия, представляют разновидности и дополнения двух классических подходов DFD и WFD.
Согласно классическому подходу стандарт DFD, который расшифровывается как Data Flow Diagram, представляет собой диаграмму потоков данных, которая используется для описания бизнес-процессов верхнего уровня. В свою очередь стандарт WFD расшифровывается как Work Flow Diagram и представляет собой диаграмму потоков работ, которая используется для описания бизнес-процессов нижнего уровня. У диаграммы потоков работ имеется и другое название — диаграмма алгоритмов. Давайте рассмотрим два этих стандарта, составляющих классическую методологию описания бизнес-процессов.
ПОСТРОЕНИЕ ДИАГРАММ ПОТОКОВ ДАННЫХ — DFD
На диаграмме потоков данных показываются работы, которые входят в состав описываемого бизнес-процесса, а также входы и выходы каждой из работ. Данные входы и выходы представляют собой информационные либо материальные потоки. При этом выходы одной работы могут являться входами для других.
Входы и выходы, которые были показаны при описании окружения бизнес-процесса (см. рис. 1), являются внешними. Внешние входы на DFD-схеме поступают извне от поставщика процесса, а внешние выходы уходят наружу к клиенту процесса. При построении DFD-схемы бизнес-процесса их нужно перенести со схемы окружения процесса на DFD-диаграмму. Для окончательного описания бизнес-процесса остается описать только внутренние информационные и материальные потоки. Каждый из них является выходом одной из работ и в то же время входом для другой (рис. 2).
При построении DFD-схемы бизнес-процесса нужно помнить, что данная схема показывает материальные и информационные потоки и ни в коем случае не говорит о временной последовательности работ. В большинстве случаев временная последовательность работ совпадает с направлением движения потоков в бизнес-процессе. В общем случае это неверно, так как могут быть случаи, подобные примеру, приведенному на рис. 3.
В данном примере вторая работа по времени начала выполняться раньше первой работы, но документ движется от первой работы ко второй. Именно поэтому стандарт DFD целесообразен для описания бизнес-процессов верхнего уровня или макропроцессов, когда в общем случае невозможно указать временную последовательность работ, так как все работы выполняются одновременно или существует несколько вариантов различных последовательностей, которые к тому же могут зависеть и от различных точек зрения. Давайте рассмотрим пример бизнес-процесса, приведенный на рис. 4.
Если компания использует схему работы «на склад», то на вопрос, что происходит раньше — закупка продукции или ее продажа, могут быть даны два ответа в зависимости от двух различных ситуаций. Если конкретный продукт имеется на складе, то его закупка по времени происходит ранее, чем продажа. Если при обращении клиента продукции на складе нет и клиент готов подождать, пока будет произведена закупка, то процесс продажи начинается по времени раньше, чем закупка, а заканчивается позже. Поэтому при описании данного бизнес-процесса и ему подобных целесообразно использовать DFD-стандарт, который не делает акцент на временную последовательность работ.
При построении DFD-схемы бизнес-процесса также нужно показать подразделения и должности, участвующие в работах процесса и отвечающие за их выполнение. Рекомендуется каждой работе присвоить номер или идентификатор, а также использовать два правила при формулировке названия работ.
Правило 1. Названия работы нужно формулировать согласно следующей формуле:
Название работы = Действие + Объект, над которым действие осуществляется.
Например, если эта работа представляет собой действие по продаже продукции, то ее нужно назвать «Продажа продукции», а еще лучше конкретизировать, что это за продукция. В данном случае «продажа» — это действие, а «продукция» — объект, над которым действие по продаже производится.
Правило 2. При формулировании названия работы нужно стараться использовать лаконичную формулировку, что повысит эффективность дальнейшей работы по оптимизации бизнес-процесса. Идеальным вариантом является случай, когда название работы формулируется при помощи 2–3 слов. В крайнем случае нужно стремиться использовать в названии не более 50 символов. В сложных случаях рекомендуется для каждого краткого названия работы сделать ее подробное описание, которое поместить в глоссарий.
При формулировании названий материальных и информационных потоков также нужно использовать подобные правила. В данном случае второе правило используется без изменений, а первое правило выражается следующей формулой:
Название потока = Объект, предоставляющий поток + Статус объекта.
Например, если речь идет о продукции, которую отгрузили клиенту, то данный поток нужно сформулировать следующим образом: «Продукция отгруженная» или «Продукция, отгруженная клиенту». В данном случае «продукция» — это объект, представляющий поток, а «отгруженная клиенту» — статус объекта.
ПОСТРОЕНИЕ СЕТИ БИЗНЕС-ПРОЦЕССОВ
В проекте по описанию и оптимизации деятельности организации целесообразно разработать DFD-схему на самом верхнем уровне — уровне компании в целом. При выделении бизнес-процессов разрабатывается дерево бизнес-процессов, в котором процессы классифицируются как основные, обеспечивающие и управленческие. Основными задачами данной классификации являются облегчение работы по выделению процессов, снижение вероятности пропуска важных процессов, а также наглядное представление выделенных бизнес-процессов, разбитых на небольшие группы.
Другое наглядное представление бизнес-процессов компании — сеть процессов, которая представляет DFD-схему, построенную на основе бизнес-процессов, составляющих дерево.
При построении окружения бизнес-процесса были описаны входы и выходы. Вход и выход каждого бизнес-процесса соответственно является выходом и входом для другого бизнес-процесса или внешнего субъекта, с которым взаимодействует организация. Взаимодействия между бизнес-процессами, составляющими дерево, показываются с помощью сети процессов (рис. 5).
Иерархические связи и классификация бизнес-процессов на сети процессов не показывается для того, чтобы не загромождать модель. В отличие от дерева бизнес-процессов сеть процесса дает более полное системное представление о деятельности организации, так как позволяет показать не только элементы организации, но и взаимодействия между ними. Помимо этого сеть процессов обеспечивает проверку разработанной модели деятельности организации на целостность, правильность выделения бизнес-процессов и описания их окружения. Если выход одного из бизнес-процессов, например документ, нигде далее не используется, то есть не является входом для другого бизнес-процесса или внешнего субъекта, то это означает следующее: описанный выход бизнес-процесса является либо ошибочным, либо лишним. В противном случае нужно найти бизнес-процесс, для которого данный выход является входом, и доработать схему окружения этого бизнес-процесса.
На практике сеть процессов часто называют сетью или схемой взаимодействия бизнес-процессов. Отличие сети процессов от классической схемы DFD состоит в том, что на сети нужно показать внешние субъекты, с которыми взаимодействуют бизнес-процессы компании, — клиентов, поставщиков, банки и др. На рис. 6 приведен пример сети бизнес-процессов для производственной компании.
ДЕКОМПОЗИЦИЯ БИЗНЕС-ПРОЦЕССА
При построении DFD-схемы бизнес-процесса необходимо использовать правило «7», согласно которому нужно выбрать такой уровень абстрагирования и детализации, при котором схема бизнес-процесса будет состоять в среднем из семи работ. Использование большей детализации и соответственно количества работ приведет к значительному усложнению схемы и снижению возможности проведения качественного анализа бизнес-процесса. Это вызвано тем, что человек может эффективно оперировать не более чем семью различными объектами. Использование небольшой детализации и меньшего количества работ на схеме бизнес-процесса приведет к тому, что работы будут излишне укрупненными, и это также уменьшит возможность проведения их качественного анализа и оптимизации.
В случае если для достижения целей оптимизации бизнес-процесса требуется большая его детализация, то ее нужно сделать посредством проведения декомпозиции работ, составляющих процесс. Для этого каждую или некоторые работы процесса рассматривают как подпроцесс и описывают в виде отдельной схемы бизнес-процесса второго уровня (рис. 7).
При классическом подходе описания бизнес-процессов для разработанной схемы второго уровня может использоваться как DFD-, так и WFD-формат описания в зависимости от уровня и глобальности работы. Если работа глобальна и ее невозможно представить в виде временной последовательности более мелких работ, то используют DFD-стандарт ее описания. В противном случае работу целесообразно описать посредством WFD-модели.
В случае необходимости работы на схеме процесса второго уровня могут быть декомпозированы на схемы бизнес-процессов третьего уровня и т.д. Декомпозиция бизнес-процесса должна продолжаться до тех пор, пока не будут достигнуты цели его описания. В данном случае удобно использовать понятия «вложенный процесс» или «подпроцесс». На рис. 7 процессная схема работы 3 является вложенным процессом или подпроцессом процесса верхнего уровня. Аналогичным образом процессные схемы работ 3.1 и 3.4 являются вложенными процессами или подпроцессами процесса второго уровня.
В итоге описание бизнес-процесса представляет собой иерархически упорядоченный набор DFD- и WFD-схем, в котором схемы верхнего уровня ссылаются на схемы нижнего уровня. При этом схемы DFD, используемые на более высоких уровнях, декомпозируются или ссылаются на схемы DFD и WFD. Схемы WFD, используемые на более низких уровнях, декомпозируются или ссылаются только на схемы WFD.
ПОСТРОЕНИЕ ДИАГРАММЫ ПОТОКОВ РАБОТ — WFD
При описании бизнес-процессов нижнего уровня используются несколько иные процессные схемы — WFD. На этих схемах появляются дополнительные объекты, с помощью которых описывается процесс: логические операторы, события начала и окончания процесса, а также элементы, показывающие временные задержки (рис. 8).
С помощью логических операторов, которые еще называются блоками принятия решений, показывается в каких случаях процесс протекает по одной технологии, а в каких — по другой. Например, с помощью данных элементов можно описать ситуацию, когда договор, стоимость которого меньше определенной суммы, согласуется одной группой сотрудников, а договор с большей стоимостью согласуется по более сложной технологии или цепочке, в которой участвует большее количество сотрудников.
С помощью событий начала и окончания процесса показывается, когда процесс начинается и когда заканчивается. Для жестко формализованных бизнес-процессов, например, таких, как бюджетирование, в качестве событий может выступать время.
В случаях когда описание бизнес-процесса проводится с целью его дальнейшей временной оптимизации, используют элементы задержки времени, которые показывают места, в которых между последовательно выполняемыми работами имеется временной разрыв. В данном случае последующая работа начинается только через некоторое время после завершения предшествующей.
В классическом подходе WFD на данной схеме не показывают документы. Эти схемы используются для описания процессов нижнего уровня, содержащих детальные работы, по названию которых понятно, что является входом и что — выходом.
Отличительной особенностью WFD-диаграммы является то, что стрелки между операциями бизнес-процесса обозначают не потоки объектов (информационные и материальные), а потоки или временную последовательность выполнения работ.
Итак, с помощью двух классических схем — DFD и WFD — можно описать подробно все бизнес-процессы компании.
Статья опубликована в журнале «Справочник экономиста» № 11, 2006.
!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >
Создание бизнес процессов начинается с их описания. Описание бизнес процессов можно делать разными способами. Каждый имеет как плюсы, так и минусы. Можно выделить 3 типа описания – текстовый, табличный и графический. Естественно, в чистом виде они встречаются редко. В большинстве случаев мы комбинируем эти методы в том или ином виде. Но если вы делаете упор и берете за основу один из 3 элементов – описание текстом, таблицы или схему бизнес процесса, то тем самым вы выбираете один из типов описания.
Управление бизнес процессами без их описания крайне затруднительно.
Текстовое описание бизнес процессов
Наверное, самый простой в реализации и распространенный вариант. Все происходящее в бизнес процессе описывается словами, т.е. в итоге у нас получается текст. Построение бизнес процессов требует описания довольно-таки большого количества элементов и вариантов развития бизнес процесса, текст может получиться весьма громоздким. Мне очень запомнился процесс, текстовое описание которого занимало 32 страницы, а схема – лишь 3.
Плюсы описания бизнес процессов текстом
- Очень просто сделать – просто садись и пиши.
- Не требует специальных навыков – темные времена прошли, теперь писать умеет каждый:)
Минусы
- Текст сложно обрабатывать – работа с массивами текста весьма сложна, ведь нам нужно найти суть, скрытую за словами.
- Затрудняет целостное восприятие процесса: читая вторую страницу, можно уже забыть, что было на первой. Очень тяжело читать текст, описывающий сложный, разветвленный процесс. Приходится постоянно возвращаться назад, чтобы понять, о чем речь. В итоге восприятие картины целиком нарушается.
- Сложно для восприятия – если текст готовит человек без писательских навыков, его прочтение превратится в пытку. У каждого свой язык, и порой он может быть очень сложен. Вы же встречали “плохие” книги? Описание процесса может быть еще хуже:)
- Сложно структурировать и анализировать – процесс может иметь множество путей развития. Это значит, что в зависимости от результатов, событий и условий мы выполняем разные действия в процессе. А теперь представьте, каково это – описывать текстом. Очень сложно сохранить простую структуру, когда у вас десяток “если” на одну страницу. В результате этого анализ потребует от вас огромных усилий и титанической предварительной работы.
Подсказка – используйте структурированные списки
Описание бизнес процессов в виде таблиц
Таблица – это здорово! Таблицы я люблю. Их можно рассматривать часами… и не найти ответ на свой вопрос:) Шучу. На самом деле описание бизнес процессов компании в виде связанных таблиц – это не такая уж плохая идея. По крайней мере, намного лучше текстового описания. Самая большая сложность заключается в том, чтобы подготовить хороший шаблон таблицы, в которую, собственно, потом уже внесут данные.
Плюсы описания бизнес процессов текстом в виде таблиц
- Относительно просто подготовить – подготовить шаблон не так сложно. Главное, чтобы он был понятен тем, кто будет его заполнять. Кроме того, все программы для работы с таблицами (например, Excel) позволяют добавлять описание к ячейкам таблицы. Используйте эту возможность для пояснений данных.
- Относительно просто заполнить шаблон – еще раз, если шаблон понятен, заполнить его не составит труда. Для этого не нужны специальные навыки и знания.
- Наличие структуры – таблица сама по себе уже предполагает некую структуру.
- Удобство обработки цифровых данных – с цифрами лучше всего работать в таблице. Так что для данного типа данных этот тип описания подходит лучше всего. Данные в таблице (даже текстовые) гораздо удобнее сравнивать и анализировать.
Минусы
- Некомпактно – описание больших процессов со всем множеством подпроцессов и элементов будет выглядеть как «простыня». Компактным такой вид назвать сложно.
- Отсутствует необходимая детализация – для того чтобы таблица имела более компактный вид, количество данных должно быть ограничено. Это значит, что даже если вы вносите текст в таблицу, он должен быть ограничен. А значит, добиться необходимой детализации может стать непросто.
- Нет целостности восприятия – большое количество данных не способствует этому. Хотя если необходимо просмотреть данные одной операции (подпроцесса) в строке или данные одного типа в столбце, то лучше таблицы не придумать.
- Сложно отобразить ветвления – та же проблема, что и с текстом. Большое количество ветвлений и, что важно, развитие процесса исходя из условий ветвления довольно сложно отобразить наглядно.
- Требует подготовки – нужно потратить время на подготовку хорошего шаблона.
Подсказка – располагайте подпроцессы, операции в строках, а данные в столбцах. Это облегчает восприятие. Вместо одной большой таблицы используйте связанные таблицы.
Описание в виде схемы, модели бизнес процесса
Не буду тянуть кота за март. Графическое описание бизнес процессов предприятия в виде схемы, модели – лучший тип описания. Большинство специалистов уже давно отдают предпочтение именно графическому типу описания. Просто посмотрите на плюсы и минусы этого типа.
Плюсы описания бизнес процессов в виде модели
- Простота восприятия – наш мозг устроен таким образом, что картинку мы воспринимаем быстрее, чем что-либо. Поэтому схему воспринимать очень просто. Мозг “фотографирует” схему и обрабатывает ее на бессознательном уровне в разы быстрее, чем наше сознание. Схему воспринимать просто еще потому, что мы сразу видим взаимосвязи элементов.
- Целостность восприятия – 1 схема представляет из себя модель процесса на определенном уровне. Это значит, что схема сразу дает нам представление о процессе в целом. В частности, о его границах, основных элементах и т.д. Если процесс детализируется на нескольких уровнях, то схемы все равно остаются связанными.
- Необходимая и достаточная детализация – в то же время на схеме можно отобразить относительно большое количество деталей без потери качества восприятия.
- Наглядное отображение ветвлений и путей развития процесса – правильно построенная схема сразу дает представление о том, каким путем должен развиваться процесс в правильном варианте. А также другие варианты развития событий.
- Удобство автоматизации – многие программные инструменты позволят переводить диаграммы в языки программирования, что очень сильно упрощает жизнь разработчикам и внедренцам ПО.
Минусы
- Требует специальных навыков – нужно знать, как правильно строить диаграммы. Знать разные нотации. А иногда даже самостоятельно сделать набор элементов и правил, которыми вы будете пользоваться для описания.
- Относительно большое время на подготовку описания – хорошо построенная модель процесса должна быть проста и понятна. Для того, чтобы сделать схему таковой, необходимо потратить кучу времени. Сложно может сделать каждый дурак, а вот простота требует мастерства;)
Инвестиции в графический тип описания окупаются весьма неплохо.
Подсказка – для описания бизнес процессов может быть достаточно 3-5 графических элементов (фигур).
!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >
В итоге
В итоге вы будете задействовать все типы описания. Документ под названием “Описание бизнес процесса…” будет содержать и графическую схему, и таблицы, и текст. Это нормально. Но мой вам совет – ориентируйтесь на графические модели и избегайте текста. Хорошая модель не нуждается в сопровождении текстом. В большинстве случаев.
Создание бизнес процессов начинается с их описания.
Источник: материалы сайта rzbpm.ru
Существует два вида инструментов,
применяемых при описании бизнес-процессов
– вертикальное и горизонтальное
описание.
При вертикальном описании показывают
только работы и их иерархический порядок
в дереве бизнес-процесса. В этом случае
имеются только вертикальные связи между
родительскими и дочерними работами
(рис.4а).
При горизонтальном описании так же
показывается, как эти работы между собой
взаимосвязаны, в какой последовательности
они выполняются, какие информационные
и материальные потоки между ними
движутся. В этом случае в модели
бизнес-процесса появляются горизонтальные
связи между различными работами, которые
процесс составляют (рис.4б).
(а)
(б)
Рисунок 2.
Вертикальное и горизонтальное описание
бизнес-процессов
Специалисты по организационному
проектированию используют различную
терминологию при описании бизнес-процессов.
Например, вертикальное описание называют
функциональным описанием, горизонтальное
– процессным описанием или просто
описанием бизнес-процессов.
2.2 Горизонтальное описание бизнес-процессов.
В
настоящее время существуют три основных
способа горизонтального описания
бизнес-процессов:
текстовый, табличный, графический.
Опишем кратко эти способы.
1. Текстовый
Этот способ есть не что иное, как текстовое
последовательное описание бизнес-процесса.
Многие российские компании разработали
и используют в своей деятельности
регламентирующие документы, часть
которых является процессными регламентами
и представляет не что иное, как текстовое
описание бизнес-процессов. Приведем в
качестве примера текстовое описание
одного из бизнес-процессов нашего
мебельного цеха:
Бизнес процесс: «Оформление заказа»
— Продавец принимает заказ от покупателя,
оформляет договор, принимает предоплату.
Предоплата передается в бухгалтерию.
Информация о заказе поступает директору,
и запускается следующий бизнес-процесс
«Выполнение заказа».
2. Табличный.
Для целей анализа и оптимизации
деятельности компании текстовое описание
бизнес-процессов не оптимально. Дело в
том, что описание бизнес-процесса в
текстовом виде системно рассмотреть и
проанализировать невозможно. Текстовая
информация воспринимается человеческим
мозгом последовательно. Например, когда
человек читает регламент и доходит до
его конца, он практически всегда забывает
про то, что было в начале документа.
Второй недостаток текстового представления
бизнес-процесса заключается в том, что
человеческое сознание устроено так,
что оно может работать эффективно только
с образами. При восприятии и анализе
текстовой информации человеческий мозг
раскладывает ее на ряд образов, на что
уходят дополнительное время и умственные
усилия. Поэтому при использовании
текстового описания бизнес-процессов
производительность и качество решений
по оптимизации деятельности оставляют
желать лучшего, что особенно сильно
проявляется, когда решение принимается
группой людей.
В свое время специалисты по информационным
технологиям разработали более
структурированный подход к описанию
бизнес-процессов. Ими было предложено
разбить бизнес-процесс по ячейкам
структурированной таблицы, в которой
каждый столбец и строчка имеют определенное
значение. Данную таблицу читать проще,
из нее легче понять, кто за что отвечает,
в какой последовательности в бизнес-процессе
выполняются работы, и, соответственно,
бизнес-процесс проще проанализировать.
Табличная форма описания бизнес-процессов
более эффективна по сравнению с текстовой
и в настоящее время активно применяется
специалистами по информационным
технологиям для описания бизнес-процессов
в приложении к задачам их автоматизации.
Таблица №1. Табличное
описание бизнес-процесса «Оформление
заказа».
|
№ |
Операция |
Ответствен-ный |
Что (Вход) |
От кого |
Что (Выход) |
Кому (Клиент) |
|
1 |
Принять заказ |
Продавец |
Заказ |
Покупатель |
— |
— |
|
2 |
Оформить договор |
Продавец |
— |
— |
Договор |
Директор, б-п. «Выполне-ние заказа». |
|
3 |
Получить предоплату |
Продавец |
Предоплата |
Покупатель |
Предоплата |
Бухгалтерия |
3. Графический.
В последнее время стали интенсивно
развиваться и применяться при описании
бизнес-процессов графические подходы.
Признано, что графические методы обладают
наибольшей эффективностью при решении
задач по описанию, анализу и оптимизации
деятельности компании.
Оказалось, что графика хороша тем, что
графическая информация, расположенная
в поле зрения человека, воспринимается
его мозгом одновременно. Второе
преимущество в том, что менеджер, как и
любой человек, имеет правополушарное
мышление и мыслит в виде образов. Любую
текстовую информацию он переводит в
образы. В случае, когда ему представляется
информация в виде графических образов,
значительно возрастают его возможности
анализа и принятия решений.
Рисунок 2.1
Бизнес-процесс «Оформление заказа»
В данной работе мы будем описывать
бизнес-процессы текстовым способом и
графически.
Соседние файлы в предмете Системный анализ
- #
- #
- #
- #
- #
- #
- #
- #
#статьи
- 7 дек 2022
-
0
Рассказываем главное, что нужно знать об описании бизнес-процессов с помощью нотации BPMN.
Иллюстрация: Оля Ежак для SKillbox Media
Рассказывает просто о сложных вещах из мира бизнеса и управления. До редактуры — пять лет в банке и три — в оценке имущества. Разбирается в Excel, финансах и корпоративной жизни.
Бизнес-аналитик с опытом работы более четырёх лет, магистр в области информационной бизнес-аналитики. Сейчас участвует в проектах, связанных с нефтедобычей, геологоразведкой, логистикой. Принимала участие во внедрении «1С:ERP» как основной бизнес-аналитик. Проверяющий куратор курсов Skillbox «Профессия Бизнес-аналитик», «Профессия Операционный менеджер».
Перед тем как улучшать процессы любого бизнеса, важно описать, как они работают сейчас, — смоделировать их. Нотация BPMN (Business Process Model and Notation) — один из способов такого моделирования.
BPMN в графическом виде отражает последовательность работ бизнес-процессов и логику их выполнения. С помощью нотации любой человек может разобраться, что изображено на схеме, даже если видит её впервые. Дальше эту схему используют для управления бизнес-процессами — ищут слабые участки и оптимизируют их.
BPMN широко применяется в России и за рубежом. Если бизнес-аналитик научится строить бизнес-процессы в этой нотации, он будет востребован.
В статье для Skillbox Media расскажем:
- что такое бизнес-процессы и для чего ими управлять;
- какие есть способы описания бизнес-процессов;
- что такое нотация BPMN и в чём её главные преимущества;
- из каких элементов состоит BPMN;
- как построить модель бизнес-процесса с помощью BPMN пошагово;
- как применяют нотацию BPMN в бизнес-аналитике;
- как узнать больше об управлении бизнес-процессами.
Бизнес-процесс — это логически связанная последовательность действий, направленных на создание продуктов или услуг. К бизнес-процессам относятся все повторяющиеся операции, которые помогают решать задачи бизнеса и получать доход.
К ним можно причислить, например, обработку заказов в интернет-магазине, доставку товаров клиенту, подготовку договоров.
Чтобы всё работало, процессами нужно управлять. От гибкости и управляемости бизнес-процессов зависит, насколько успешным будет бизнес. Есть разные подходы к управлению — все они включают три основных элемента:
- анализ бизнес-процессов;
- выявление проблем;
- оптимизация бизнес-процессов.
В Skillbox Media есть статья, где подробно рассказано об управлении бизнес-процессами.
Перед тем как анализировать бизнес-процессы, важно зафиксировать их исходное состояние — разобрать их на этапы и описать, как они выглядят в данный момент. О способах описания говорим ниже.
Три самых распространённых способа описания бизнес-процессов:
- Текстовый — подготовка письменных инструкций, регламентов, стандартов и других нормативных документов.
- Табличный — описание процессов в формате таблиц.
- Схематичный — графическое изображение процессов.
Наиболее удобный способ для описания бизнес-процессов — схематичный. Текстовое описание часто получается слишком громоздким и сложным для восприятия. В таблицах не всегда можно отразить всю необходимую информацию так, чтобы она читалась.
В моделировании бизнес-процессов используют нотации — стандартизированные системы условных обозначений. Они нужны, чтобы любой человек понимал, что изображено на схеме. Это позволяет прочесть схему, не изучая специальные обозначения, принятые в конкретной компании.
Нотации описывают:
- какие обозначения использовать в описании процессов и как их читать;
- как отображать последовательность действий и отношения внутри них;
- какие элементы нужно обязательно учесть.
Есть несколько вариантов нотаций — их выбирают в зависимости от типов бизнес-процессов и потребностей бизнеса. Вот некоторые примеры нотаций:
- Блок-схема — используют для описания алгоритмов, статусов и ролей процесса.
- EPC — используют для описания событий бизнес-процессов.
- IDEF0 — используют для описания логических отношений между этапами процесса.
- ARIS — используют для описания одновременно всех бизнес-процессов компании и её архитектуры.
- BPMN — используют для подробной детализации действий в бизнес-процессах.
В следующих разделах подробно говорим о нотации BPMN.
BPMN — аббревиатура от Business Process Model and Notation. Это система условных обозначений и их описания для моделирования бизнес-процессов.
BPMN — одна из самых популярных нотаций для изображения бизнес-процессов в виде схем. Она широко применяется в России и за рубежом. Обучившись построению бизнес-процессов в ней, бизнес-аналитик точно будет востребован.
Первая версия BPMN создана в 2004 году рабочей группой IBM. В 2010 году — дополнена и выпущена под названием BPMN 2.0. В неё добавили новые типы событий и диаграмм, устранили ошибки первой версии.
Вот главные преимущества нотации BPMN перед другими нотациями:
- Универсальность — позволяет описать даже специфические, сложные процессы.
- Схемы в нотации BPMN выглядят компактнее и нагляднее, чем текстовые документы, — они интуитивно понятны даже тем, кто незнаком с нотацией.
- Позволяет выявлять узкие места процесса. Например, если в процессе много лишних действий, они путаются или резко обрываются — на схеме в нотации BPMN это будет хорошо видно.
Как мы сказали выше, BPMN представляет собой систему условных обозначений для моделирования бизнес-процессов. Процессы в нотации представлены в виде графических последовательностей.
Ниже на иллюстрации приведён пример процесса — поиска и приёма на работу нового сотрудника.
Скриншот: личный архив Анны Солодовниковой
Разберём основные элементы нотации. Их будет достаточно для большинства схем.
Процесс (задача, подпроцесс). Задача — действие или операция, у которых нет дальнейшей декомпозиции в рамках процесса. Подпроцесс — декомпозированный процесс, в который включено несколько задач. На диаграмме он обозначается блоком со знаком +.
Примеры задач в иллюстрации выше — «Заявка на подбор нового сотрудника», «Проведение собеседования». Часто задачи формулируют через глагол: «Провести собеседование», «Подобрать сотрудника».
Событие. Показывает состояние, которое влияет на дальнейшее течение бизнес-процесса или контролирует его. Примеры событий — старт процесса, его завершение, смена статуса документа, получение сообщения.
Любая схема должна начинаться со стартового события и завершаться конечным. Промежуточных событий в процессе может и не быть, поэтому это необязательный элемент.
В нашем примере стартовые события — «Потребность в расширении штата» и «Текущий сотрудник написал заявление на увольнение».
Шлюзы. Показывают слияния потоков управления в рамках процесса. Среди них выделяют:
- Параллельный шлюз — означает, что два процесса исполняются одновременно. Читается как «И».
В нашем примере параллельный шлюз — «Проведение собеседования» и «Проведение собеседования, заполнение листа оценки кандидата».
- Эксклюзивный шлюз — используют, чтобы обозначить ветвление потока управления на несколько альтернативных потоков, когда процесс зависит от выполнения условия. Читается как «ИЛИ».
В этом случае процесс идёт чётко по одному из потоков.
- Неэксклюзивный шлюз — применяют, чтобы показать ветвление потока управления на несколько других, когда процесс зависит от выполнения условий. Читается как «И/ИЛИ».
В этом случае процесс может пойти по двум потокам одновременно, а может — только по одному из них. Такой шлюз используется редко.
Объект данных. Показывает, какие объекты сопровождают выполнение процесса. Например, бумажный документ, электронный документ, информацию и так далее.
В нашем примере объекты данных — «Заявка на подбор», «Лист оценки кандидата», «Предложение о работе».
Потоки. Это стрелки, которые показывают движение по процессам и порядок их выполнения. Есть несколько видов потоков:
- Поток управления — показывает, в каком порядке выполняется процесс. Эти стрелки связывают между собой задачи, события и шлюзы.
Пример — связь между задачами «Поиск подходящих кандидатов» и «Отправка релевантных резюме». Это две задачи, которые последовательно идут друг за другом.
- Поток сообщений — показывает передачу сообщений или объектов из одного процесса в другой. В нашем примере так показана связь между подготовкой заявки на подбор сотрудника и принятием этой заявки в работу.
- Ассоциация — показывает связи объектов данных и баз данных с процессами.
Например, задача «Проведение собеседования, заполнение листа оценки кандидата» связана с помощью ассоциации с документом, где хранится этот лист оценки.
Пулы (дорожки). Показывают участников бизнес-процессов. Например, должности, подразделения, роли, внешние субъекты. Дорожка не может соответствовать системе или другим объектам — только людям.
Например, в нашей иллюстрации дорожки соответствуют кандидату, HR-менеджеру, руководителю отдела.
Полный список элементов, которые используют в нотации, можно посмотреть здесь.
Существует много инструментов для разработки процессов в BPMN. Мы рекомендуем бесплатный онлайн-сервис Diagrams.net. В нём можно создавать схемы, модели, диаграммы и обмениваться ими в браузере.
Чаще всего бизнес-процессы изображают в специальных программах для моделирования. Также это можно делать и от руки, но только в качестве черновика.
Вот пошаговый план того, как построить бизнес-процессы в нотации BPMN:
1. Изучите процесс: для чего он нужен и какие задачи решает.
2. Определите, является он основным, вспомогательным или процессом управления.
Основной процесс — приносящий прибыль или влияющий на прибыль компании. Например, производство или продажи. Таким процессам нужно уделять особое внимание.
Вспомогательный процесс — процесс, который не генерирует доход, но обеспечивает качественное выполнение основных процессов. Например, бухгалтерский учёт.
Процесс управления — процесс, влияющий на существование и развитие компании. Например, управление командами компании.
3. Запросите у ответственных за процесс инструкции, регламенты и другие нормативные документы, которые описывают процесс или работу участвующих в нём отделов. По этим документам можно составить первичное представление о процессе.
4. Выявите всех участников процесса: должности, роли, отделы, в некоторых случаях — Ф. И. О. ответственных сотрудников. Но в схемах процесса лучше избегать построения дорожек, завязанных на Ф. И. О., — иначе нужно будет постоянно следить за актуальностью данных.
5. Определите границы бизнес-процесса: назначьте стартовое и конечное события и назовите их. Начиная построение схемы, помните, что именно вы хотите отразить и какую цель преследуете.
6. Отметьте все внутренние события бизнес-процесса. Дополнительные детали можно при необходимости уточнить у владельцев процесса.
7. Если в процессе важно отразить внутренние действия систем, попросите участников процесса наглядно показать, что они делают и какой результат получают. Продемонстрируйте это на схеме.
Задачи бизнес-аналитика, для которых требуется BPMN, делят на два этапа:
- Построение схем «как есть» (as is) — описание текущей последовательности работ бизнес-процесса.
- Построение схем «как будет» (to be) — описание целевого процесса с фиксацией требуемых изменений: этапов модернизации, автоматизации.
Разберём на примере. Допустим, в компании N было 70 сотрудников, которые работали в одном офисе. Всю необходимую документацию они распечатывали, подписывали от руки и самостоятельно относили получателю — например, бухгалтеру, отделу кадров или секретарю.
Потом компания выросла в 2,5 раза, появились удалённые сотрудники. Руководство приняло решение внедрить систему электронного документооборота (СЭД). Перед внедрением такой системы бизнес-аналитику потребуется выполнить три основные задачи:
- Разобраться и описать, как сейчас сотрудники знакомятся с документами и подписывают их. При этом учесть два типа сотрудников — работающих в офисе и удалённо.
- Выявить возможные узкие места и особенности процесса в данной компании. Эти особенности должны быть учтены при разработке или покупке готовой СЭД.
- Проанализировать, как бизнес-процесс «ложится» на новую систему: в каких местах необходима доработка ПО, в каких — организационные изменения внутри компании.
Что даёт описание текущего процесса и моделирование целевого процесса документооборота? Снизится риск упустить ключевые функции СЭД и получить на выходе систему, которая не будет решать задачи компании.
В дальнейшем описанный и согласованный ключевыми участниками процесс можно брать за основу для написания регламентов или инструкций.
- Бизнес-процессы — все операции, которые помогают решать задачи бизнеса и получать доход. Чтобы всё работало по плану, процессами нужно управлять: описывать их, анализировать и оптимизировать.
- Эффективнее всего описывать бизнес-процессы графически — в виде интуитивно понятных схем. Для этого используют различные нотации — системы условных обозначений. Они нужны для того, чтобы любой человек понимал, что изображено на схеме.
- Одна из универсальных и самых наглядных нотаций — нотация BPMN (Business Process Model and Notation). Она в графическом виде отражает последовательность работ бизнес-процессов и логику их выполнения.
- Если вы только начали разбираться в управлении бизнес-процессами — прочитайте статью Skillbox Media «Большой гайд по управлению бизнес-процессами: главное, что должен знать каждый менеджер».
- В этой статье отдельно разбирали вопрос моделирования бизнес-процессов, в этой — процесс их автоматизации.
- Также в Skillbox есть курс «Профессия Бизнес-аналитик». На нём учат собирать данные о финансах компании и бизнес-процессах, проводить продуктовые интервью и определять стратегии развития, оптимизировать процессы.
Другие материалы Skillbox Media для менеджеров
Научитесь: Профессия Бизнес-аналитик
Узнать больше