Владимир Репин
Генеральный директор ООО «Владимир Репин Менеджмент»
Член ABPMP Russia
Консультант по управлению
Бизнес-тренер
Кандидат технических наук
В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема » в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие. При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.
Для бизнес-аналитиков компаний тезисы, обсуждаемые в статье, — это серьезный повод задуматься, насколько эффективны используемые ими подходы к разработке графических схем процессов организации.
Введение
Одной из важнейших целей формирования графических схем процессов является последующее их использование в регламентирующих документах организации. По этим схемам, как правило, работают сотрудники, которые не обучены сложным нотациям, не имеют навыков системного анализа и т. п. Для них очень важна простота и наглядность схем. Сложные, запутанные схемы, содержащие много различных условных обозначений, плохо воспринимаются людьми, что затрудняет их практическое использование. Поэтому для практических целей важным является корректный выбор и использование нотации (методики) описания процессов. По каким критериям следует выбирать такую нотацию? Как сравнивать разные нотации между собой? Рассмотрим несколько примеров описания бизнес-процесса при помощи популярных нотаций и попытаемся ответить на эти вопросы.
Сравнение нотаций
Для сравнения были выбраны следующие нотации описания процессов:
- «Простая блок-схема » (с отображением движения документов, с использованием блока «Решение»);
- «Простая блока-схема » (без отображения движения документов, без использования блоков «Решение»);
- «Процедура» системы Business Studio (один из возможных вариантов представления);
- ARIS eEPC.
В качестве тестового примера был выбран простой и интуитивно понятный процесс. Результаты описания этого процесса представлены на Рис. 1-4.

Рис. 1. Схема процесса в нотации «Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)
На схеме, представленной на Рис. 1, последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов — при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых «зависит» последующий ход процесса. Такой подход к использованию «ромбиков» является весьма распространенным. Но фактически, вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если задуматься, то ценность (смысл) рисования этих «ромбиков» не является очевидным. Что это за объекты: операции процесса, события? Вроде бы, ни то, и ни другое. Это скорее операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе «ромбик» был бы полноценной операцией сравнения условий и т. п. Но на схеме процесса нужно показывать реальные объекты — процессы, выполняемые людьми, документы, информационные системы и т. п. Задумайтесь, корректно ли показывать «ромбики» отдельно от операции процесса на схеме? Вместо этого можно:
- Описать логику принятия решения в виде последовательность операций на схеме рассматриваемого процесса;
- Описать логику в виде схемы шагов соответствующего подпроцесса, переходя на уровень ниже;
- Описать логику текстом (в текстовых атрибутах операции) и в последующем вывести в регламент выполнения процесса.
Сформулируем «плюсы» и «минусы» рассмотренного выше (Рис. 1) способа использования «ромбиков».
«Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)
На Рис. 2 показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме Рис. 1. Схема Рис. 2 выглядит гораздо проще. От графических элементов не рябит в глазах, а с точки зрения информативности эта схема вполне понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.

Рис. 2. Схема процесса в нотации «Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)
«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 2, показаны ниже.
«Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)
В целом, применение схем в формате, подобном представленному на Рис. 2, является удобным как для разработчиков, так и для сотрудников, работающих по этим схемам.
На Рис. 3 представлена схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки «Решение» использованы нестандартным образом — не как графический элемент для отображения вопроса и ветвления, а как полноценная операция процесса, связанная с принятием решений. В Business Studio «ромбик» обладает почти всеми атрибутами полноценного процесса, но не может быть декомпозирован (возможно, разработчики системы со временем сделают такую возможность). Использование «ромбика» (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты «ромбика» можно внести любую текстовую информацию: описание, начало, завершение, требование к срокам и т. п.
Второй особенностью схемы процесса, представленной на Рис. 3, является применение стрелок. Для отображения последовательности операций можно использовать стрелку с одним наконечником — стрелку «предшествования». Для отображения движения документов можно использовать стрелку с двумя наконечниками. Однако в Business Studio можно обойтись использованием только одного типа стрелок — стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности.
Такой подход дает возможность:
- Существенно сократить количество графических элементов на схеме процесса, и при этом;
- Вывести в регламент процесса необходимую информацию о входящих и исходящих документах.
Таким образом, не загромождая схему лишними элементами, мы можем, тем не менее, полно описать процесс и выгрузить в регламент всю необходимую информацию.
Тот факт, что название стрелки не зависит от документов, которые к ней привязаны, позволяет именовать стрелки на схеме максимально понятным и удобным для сотрудников образом. Например, к стрелке предшествования «Подготовлен комплект отчетов» можно привязать комплект конкретных документов. Название стрелки в этом случае указывает исполнителю на событие, завершившее предыдущую операцию под названием «Сформировать отчет по инкассации за день». (Заметим, что в методологии компании «СТУ» стрелка после операции процесса — это сущность, а не событие. После блока «Решения» можно показывать возможные результаты решения).

Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)
«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 3, показаны ниже.
«Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)
В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на Рис. 3.
На Рис. 4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Заметим, что на схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий! Сотрудник, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем, рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или помощи квалифицированного бизнес-аналитика.
Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на Рис. 1-3. Трудоемкость формирования такой схемы также существенно выше.

Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio)
Схема процесса в нотации ARIS eEPC (построена в Business Studio)
В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.
Описание процесса для целей последующей автоматизации
Интересно рассмотреть приведенный выше пример описания бизнес-процесса в случае, если он представлен в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, т. е. процессов которые поддерживает система BPM.
Своим мнением об использовании BPMN 2.0. делится А. А. Белайчук — Генеральный директор компании «Бизнес-консоль»:
«На Рис. 5 изображен тот же процесс в нотации BPMN. Как мы видим, этот рисунок похож на Рис. 1: в нотации BPMN задачи изображаются прямоугольниками, развилки — ромбами, данные — пиктограммой, похожей на документ. Потоки управления — сплошные линии, потоки данных — пунктирные.
Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением — „движком“ BPM-системы.
В то же время, как показывает данный пример, при использовании ограниченного подмножества палитры BPMN оказывается не сложнее привычной блок-схемы. Ну, а тем, кто хочет освоить BPMN профессионально, мы рекомендуем специализированные тренинги bpmntraining.ru .»

Рис. 5. Схема процесса в нотации BPMN 2.0
Практика жизни
На Рис. 6 показан фрагмент схемы процесса, разработанный бизнес-аналитиками вполне конкретной компании в придуманной ими нотации. Схема построена с применением принципов «Простой блок-схемы » — применяется блок «Решение» в своем классическом варианте. Кроме этого, на схеме представлено множество других условных обозначений, использованных не совсем стандартным образом.

Рис. 6. Примеры схемы процесса одной из компаний
При формировании схемы Рис. 6, бизнес-аналитики очевидно, «боролись» за наглядность и максимальную понятность для рядового пользователя. Они стремились свести к минимуму, или вообще отказаться от текстового комментария к схемам процессов. Исполнителям просто печаталась схема формата А3, при чтении которой все сразу становилось понятно: что делать, как, какие документы использовать и т. п.
Рассматриваемая схема не является, конечно, образцом простоты и наглядности. Но она была сформирована, чтобы донести максимум полезной информации для исполнителей процесса.
Выводы
Итак, очевидно, что при описании процессов нужно стремиться к простоте и понятности для сотрудников.
Использование сложных, формализованных нотаций при описании процессов приводит к:
- Трудностям при использовании (интерпретации) схем рядовыми сотрудниками;
- Невозможности (сложности) организации работ по описанию процессов силами сотрудников подразделений, не прошедших специальное обучение;
- Значительному увеличению трудозатрат бизнес-аналитиков на формирование схем;
- Дополнительным сложностям при документировании схем (большой объем и т. п.).
Поэтому не стоит загромождать схему процесса различными графическими элементами. Но уже если их использовать, то лучше, чтобы они несли полезную информацию для сотрудников, а не были просто следствием формального применения нотаций моделирования.
http://finexpert.ru/ — среда общения профессионалов http://bpm3.ru/ — процессы, проекты, эффективность
Что собой представляют бизнес-процессы? Примеры позволят нам лучше разобраться в данном предмете, поэтому мы будем активно их использовать.
Общая информация
Для начала давайте разберёмся с тем, чем же являются бизнес-процессы. Так называют совокупную последовательность определённых действий, направленных на то, чтобы преобразовать ресурсы, полученные на входе в завершенный продукт, обладающий ценностью для потребителей на выходе. Благодаря такому определению можно понять, что бизнес-процессы есть внутри каждой организации. Формализованы они или нет, это роли не играет. Запомните: можно везде встретить бизнес-процессы. Примеры их будут наведены далее в статье.
Давайте рассмотрим бытовой пример. Есть домохозяйка, которая хочет помыть посуду (бизнес-процесс). Она поручает эту задачу посудомоечной машине. На входе мы имеем грязную посуду. Во время процесса будут использоваться вода, моющее средство и электричество. И на выходе мы получим чистую посуду. По подобной схеме и строятся бизнес-процессы. Примеры, которые будут приведены в дальнейшем, только подтвердят эти слова.
Функциональный подход
Поскольку нас интересуют (примеры конкретные), то давайте не будем откладывать их рассмотрение, а сразу приступим к делу. Допустим, у нас есть компания, где действует к вопросам управления. Согласно ему, предприятие - это набор подразделений. Причем каждое работает на выполнение своей определённой функции. Но в таких случаях, когда отдельные подразделения ориентированы на достижение их показателей, часто страдает общая эффективность компании.

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

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

Чтобы избежать ухода в сторону, можно использовать стандартные карты и формы процессов. При разработке процессов рекомендуется использовать метод последовательных приближений. Иными словами, необходимо повторять цикл действий по улучшению, пока не будет получен приемлемый результат.
Чему следует уделить внимание?
Следует сконцентрироваться на следующих разделах:
- Стандартные формы.
- Карта.
- Маршруты.
- Матрицы.
- Блок-схемы.
- Описание стыков.
- Вспомогательные описания.
- Документирование.
- Развернутое описание.
- Определение индикаторов и показателей.
- Регламент выполнения.
Лучше всего понятие о необходимых элементах сможет дать реальный пример -реинжиниринг бизнес-процессов существующего предприятия. Но в таких случаях необходимо быть готовым к тому, что придётся ознакомиться с огромным количеством документации.
О картах замолвим слово
Итак, мы уже рассмотрели, что собой представляют бизнес-процессы, примеры их в реальной жизни. Сейчас давайте пройдёмся по технической документации, которая должна быть, если нам нужно точное и четкое описание. Итак, первоначально хочется уделить внимание карте бизнес-процесса. Она является графическим представлением, выполненным как блок-схема. При этом необходимо позаботиться о том, чтобы для каждого участника был отведён свой отдельный столбец. В строки заносят временные интервалы. Полностью оформленная карта позволяет проверить, была ли синхронизирована операция.

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

При анализе цепочки процессов несложно обнаружить, что обмен информацией передвигается из верхнего левого угла в нижний правый. То есть в таком математическом виде описываются отношения между поставщиком и потребителем, представленные в виде прямоугольника. В каждой ячейке матрицы при этом указываются все необходимые требования для действия, что были/совершаются/будут сделаны. Они являются своеобразными двухмерными моделями, с помощью которых можно судить о том, что и как делается и какая цель при этом преследуется. Сложности при составлении матрицы здесь бывают в том, что для просчета с максимальной точностью часто приходится использовать значительное количество данных. А это подразумевает наличие большого При этом в таких случаях обычно используется цифровая информация, которую часто ещё приходится обсчитывать.
В нашей компании, которая управляет проектами строительства крупных энергетических объектов, описание бизнес-процессов сегодня особенно актуально для проектов и проектных команд.
Каждый проект – это новая команда, много заинтересованных сторон и взаимосвязей, своя специфика, высокая загрузка персонала. Руководство проекта ставит задачу описывать процессы быстро, просто и понятно. И естественно, они должны работать.
Довольно давно занимаясь описанием бизнес-процессов, я опробовала разные техники, инструменты и шаблоны. Поделюсь методом, который использую в последнее время и который «прижился» в нашей компании.
Итак, определяем процесс , который нужно описать. Далее
- собираемся с ответственным за процесс
и основными участниками/ экспертами (до 3 человек);
- определяем границы процесса, участников, входы/ выходы, этапы процесса
– блоки, на которые разбиваем процесс и результаты этих этапов;
- договариваемся и в итоге рисуем такую схему процесса:
описываем каждый блок (подпроцесс). Для этого используем графическую функциональную блок-схему, шаблон которой есть в MS Visio:

В описании мы используем обозначения:

В результате схема процесса (этапа) выглядит так:

На схеме представлены участники процесса, действия, которые они выполняют и их продолжительность. На стрелках, соединяющих действия, указываем результаты.
Схема, нарисованная в MS Visio, - это уже окончательный вариант. Вся суть в ее создании. И главное здесь – вовлечение непосредственных участников процесса.
Мы описываем процесс так:
1. Организуем рабочее совещание участников процесса и экспертов;
2. Готовим «клейкую стену» , карточки формата A5, маркеры;
3. Определяем модератора, который ведет дискуссию, пишет и клеит карточки на стену;
4. Размечаем горизонтальные строки малярным скотчем;
5. Определяем участников процесса, записываем на карточках и клеим слева на стене в соответствующих строках;
6. Определяем (подтверждаем) вход/ выход процесса (желтые карточки);
7. Участников разбиваем на две группы, каждая группа обсуждает и пишет на карточках действия процесса от «входа» до «выхода». Раскладывает на столе;
8. По очереди берем от каждой группы по одной карточке, начиная от «входа» процесса; определяем, кто его выполняет, и наклеиваем на стену, соединяя последовательно малярным скотчем (это стрелки). В ходе этой работы договариваемся о формулировках и использовании различающихся карточек, приводим участников к общей схеме;
9. Проходимся по схеме (читаем), добавляем недостающие действия, задавая группам вопросы, определяем результаты действий (пишем на стрелках);
10. Фотографируем и отдаем на оцифровку.
В итоге получаем схему в MS Visio, как на предыдущем рисунке.
Все описание мы размещаем на одной странице – компактно и наглядно. Действия каждого участника описаны в отдельной строке, что позволяет быстро определить его роль и функции в процессе.
Если процесс сложный, действия требуют пояснения или непоследовательны – добавляем страницу с комментариями или пишем их на свободном месте в рамочке прямо на схеме.
Итоговую схему рассылаем всем участникам для согласования. Руководитель проекта (или другой ответственный) утверждает ее, она сохраняется в альбоме процессов проекта и становится руководством к действию.
Бизнес-процесс (процесс) - это совокупная последовательность действий по преобразованию ресурсов, полученных на входе, в конечный продукт, имеющий ценность для потребителя, на выходе.
Благодаря такому определению, становится понятно, что бизнес-процессы
существуют внутри каждой организации, независимо от того, формализованы они или нет. В организации может быть принят функциональный подход к управлению
, который рассматривает компанию как набор подразделений, каждое из которых исполняет определенные функции.
В этом случае отдельные подразделения ориентированы на выполнение своих собственных показателей, но не всегда - на конечный результат компании, что может вызвать конфликт интересов между подразделениями и отрицательно сказываться на общей результативности бизнеса.Приведем типичный конфликт («грозовую тучу», в терминах Теории ограничений
) между отделами продаж и закупа торговой компании. Отдел продаж для увеличения оборота требует обеспечить максимально возможный ассортимент и поддерживать постоянное наличие товара на складе, а отдел поставок закупает узкий ассортимент товара большими партиями, потому что его главный показатель работы - получение более низкой цены от поставщика для снижения затрат - никак не связан с увеличением объема продаж компании
.

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

Технология описания бизнес-процесса делает все операции компании прозрачными и понятными, позволяет анализировать операции и находить в них проблемы, приводящие к сбоям. Главное, что бизнес-процессы позволяют понимать взаимодействие между разрозненными подразделениями: что, кому и для чего они передают или принимают на каждом этапе. Как следствие, процессный подход значительно упрощает адаптацию новых сотрудников и снижает зависимость работы компании от человеческого фактора. Важно, что процессная система упрощает управление операционными расходами .
Наличие проработанной системы бизнес-процессов значительно упрощает приведение деятельности компании на соответствие требованиям стандартам качества ISO 9001:2015 . В условиях свершившегося вступления России в ВТО, соответствие предприятия стандартам ISO 9001:2015 становится важным конкурентным преимуществом.
Внедрение СМК на предприятии в обязательном порядке требует создания и описания бизнес-процессов.
Разработка бизнес-процессов
Рассмотрим порядок разработки бизнес-процессов . Для начала необходимо создать рабочую команду проекта из сотрудников компании. Обычно, одной рабочей команды бывает недостаточно. Тогда к ее деятельности привлекают временную группу из подразделений клиентов и поставщиков конкретного бизнес-процесса, которые обеспечивают входы, выходы и ресурсы бизнес-процесса.
Чтобы понять, как функционирует система и сохранить накопленный опыт, сначала записывают, как процесс реально функционирует сейчас. Нужно помнить, что целью описания является выявление связей между предпринимаемыми действиями, а не фиксирование мельчайших подробностей. Поэтому описание бизнес-процессов рекомендуется стандартизовать, используя стандартные формы и карты процесса.
В описании бизнес-процесса можно выделить следующие разделы:
- Стандартные формы бизнес-процесса
- Карта бизнес-процесса
- Маршруты бизнес-процесса
- Матрицы бизнес-процесса
- Блок-схемы бизнес-процесса
- Описание стыков бизнес-процесса
- Вспомогательные описания бизнес-процесса
- Развернутое описание бизнес-процесса
- Документирование бизнес-процесса
- Определение показателей и индикаторов бизнес-процесса
- Регламент выполнения бизнес-процесса
Рассмотрим подробнее каждый этап.
1.Стандартные формы описания бизнес-процесса
Рекомендуем использовать типовой образец стандартной формы описания бизнес-процесса. Это позволит добиться единого подхода к фиксированию процесса разными людьми, что затем значительно облегчит анализ процессов.
2.Карта бизнес-процесса
Карта бизнес-процесса - графическое представление бизнес-процесса в виде блок-схемы. Обратите внимание, что каждому участнику бизнес-процесса соответствует отдельный столбец. Строки - это временные интервалы. Оформленная карта позволяет синхронизировать операции и проследить путь прохождения информации между подразделениями компании.
На этапе составления карты бизнес-процесса, от сотрудника, выполняющего эту работу, не требуется компетенции в области описываемых процедур бизнес-процесса. Он только фиксирует знания исполнителей, что и как они делают. Необходимо получить ответы на вопросы:
- Каким документом завершается рабочий цикл, чтобы его можно было начать сначала?
- Кому передается этот документ?
- Что этому предшествует?
- Кто вовлечен в этот процесс внутри и вне организации?
- Кто выдает задание для запуска процесса?
При составлении карты бизнес-процесса следует воспользоваться популярной вопросной формулой 5W1H. Коротко, это 5 вопросов W:
- Who?(Кто совершает данную операцию?)
- Why? (Почему или зачем выполняется эта операция?)
- What? (Что представляет собой эта операция?)
- When? (Когда нужно проводить данную операцию?)
- Where? (Где производится операция?)
и один вопрос H
- How? (Как совершается эта операция? Можно ли сделать это иначе или внести улучшения?).
Если карта получается слишком сложной - это сигнал о том, что в управлении организацией нет должного порядка.
3. Маршруты бизнес-процесса
В реальных бизнес-процессах часто участвует несколько подразделений предприятия. Для них необходимо распределить роли в процессе. Кроме того, встречаются ветвления и параллельные действия. Поэтому представление в виде маршрутов очень удобно. Маршруты дают нам логистическую схему процесса - движение материалов, людей, денежных и информационных потоков . Блок-схемы используются для расшифровки логики действий команды.
4. Матрицы бизнес-процесса
Матрица (таблица) анализа взаимодействия процессов позволяет выделить самые важные бизнес-процессы, установить их взаимосвязь и оценить степень влияния процессов на функционирование СМК.
Анализ цепочки процессов обнаруживает, что обмен информацией идет между всеми подпроцессами. Цепочка процессов идет из левого верхнего угла в правый нижний. Внутренние отношения «поставщик-потребитель» показаны как прямоугольники, в которых указаны требования для действий, выполняющихся ранее.
5. Составление блок-схемы бизнес-процесса
Блок-схема процесса представляет собой наглядную схему всей цепочки взаимоотношений между всеми участниками бизнес-процесса (потребителями, поставщиками и исполнителями). В процессе составления блок-схемы ставятся вопросы:
- Сопоставима ли ценность от данного бизнес-процесса с затратами на его проведение?
- Насколько он интегрирован с другими бизнес-процессами?
- Могут ли быть сразу обнаружены ошибки этого бизнес-процесса?
- Что сделано для улучшения и обеспечения качества этого бизнес-процесса?
6. Описание стыков бизнес-процессов
Труднее всего описывать деятельность предприятия на стыках бизнес-процессов. Согласие между собственниками процессов иногда получить очень сложно.
Сначала составьте описание выходов. Сначала впишите их в реестр, затем определите показатели результативности и значения, к которым нужно стремиться. Опишите процесс измерения этих показателей. Продумайте возможность перехода от них к другим показателям эффективности, интересующим других пользователей.
Затем составьте аналогичное описание входов.
7. Вспомогательные описания бизнес-процессов
В качестве вспомогательно описания используются компоновочные схемы, мнемосхемы, диаграммы Ганта и сетевые графики . Две последние удобно использовать для процессов управления проектами .
8. Развернутое описание бизнес-процессов
Развернутое описание бизнес-процесса может быть в любой удобной для предприятия форме, но должно содержать основные положения:
- полное наименование бизнес-процесса;
- код бизнес-процесса;
- определение бизнес-процесса, раскрывающее его основное содержание;
- цель бизнес-процесса;
- владелец бизнес-процесса, отвечающий за перспективное планирование процесса;
- руководитель бизнес-процесса, отвечающий за текущее ведение процесса;
- нормативы бизнес-процесса;
- входы бизнес-процесса (потоки, поступающие извне и подлежащие преобразованию);
- выходы бизнес-процесса (результаты преобразования);
- ресурсы, которыми располагает бизнес-процесс;
- бизнес-процессы внутренних и внешних поставщиков - источники входов;
- бизнес-процессы потребителей - пользователи результатов рассматриваемого бизнес-процесса;
- измеряемые параметры процесса;
- показатели результативности процесса.
9. Документирование бизнес-процесса
Бизнес-процессы, входящие в систему СМК , подлежат документированию. Наиболее удобной формой описания является процедура. Бизнес-процесс может быть описан одной или несколькими процедурами, в зависимости от сложности. Удобно сделать единый вид для описания всех бизнес-процессов.
10. Определение показателей и индикаторов бизнес-процесса
Бизнес-процесс должен быть охарактеризован некими показателями, чтобы процесс можно было измерить и оценить его эффективность. Все показатели входят в 4 основные группы:
- качество;
- время выполнения;
- количество;
- издержки.
Кроме того, принято выделять особые группы - группу индикаторов бизнес-процесса, группу требований, группу обеспечения желаемого протекания процесса, группу рекомендаций.
Группа индикаторов бизнес-процесса показывает степень достижения цели.
Группа требований включает в себя:
- человеческие ресурсы;
- инфраструктура;
- условия производственной среды.
Группа обеспечения желаемого протекания процесса:
- информация;
- инструкции по выполнению работ;
- время.
- финансы;
- логистика;
- поставщики;
- партнеры и т.д.
11. Регламент выполнения бизнес-процесса
Крупные бизнес-процессы целесообразно оформлять в виде отдельного документа «Регламента выполнения бизнес-процесса ». Остальные бизнес-процессы могут быть оформлены в виде положений о подразделении и должностных инструкций.
В регламент следует заложить требования, обеспечивающие соответствие циклу Шухарта-Деминга:
- определение плановых показателей бизнес-процесса на следующий период;
- анализ владельцем бизнес-процесса отклонений от нормального хода процесса и их документирование;
- анализ результативности корректирующих мероприятий;
- формирование отчетности для вышестоящего руководства.
Разработка и описание бизнес-процессов - первый шаг на пути внедрения СМК на предприятии. Впереди - постоянная и кропотливая работа по их доведению до всего персонала, анализу и, в случае необходимости, внедрению корректирующих действий.
Инструкция
Первое - это и точно сформулировать название описываемого процесса, которое должно быть понятным и отражать общую суть последовательности действий, составляющих -процесс. Например, вместо «Подача заявки на в производство и контроль ее исполнения», достаточно назвать процесс «Контроль изделия».Второе - это правильно разбить весь описываемый процесс на более мелкие («атомарные») задачи или функции-подпроцессы и определиться с последовательностью их выполнения. При подобном разбиении описываемый процесс будет являться процессом верхнего уровня. Степень детализации процесса верхнего уровня может быть различной, но должна быть адекватной для понимания той аудиторией, которая будет пользоваться вашим описанием.
Описать бизнес-процесс можно несколькими способами. Наиболее популярный из них - графический, с помощью , выполненных в различных нотациях (нотация - набор символов для обозначения чего-либо).
Самые распространенные виды нотаций для описания бизнес-процессов - это IDEF0, BPMN, EPC (ARIS) и др.
В качестве примера остановимся на диаграмме, выполненной в нотации BPMN (Business Process Modelling Notation) с помощью CASE-средства PowerDesigner (Рис.1). Главными элементами на диаграмме являются:
1. «Процесс» (функция) - скругленный по углам прямоугольник;
2. «Переход» - стрелка, соединяющая процессы;
3. «Решение» - ромб, содержащий вопрос, на который можно ответить только «Да» или «Нет»;
4. Условия - текстовые выражения, при которых осуществляется переход от функции к другой. Условия всегда заключаются в квадратные скобки. Иногда полезно разбить вашу на «Дорожки» - вертикальные или горизонтальные секции, обозначающие подразделения предприятия или сотрудников, ответственных за выполнение определенной функции. В таком случае этой функции должен находиться в пределах своей секции. Кроме перечисленных элементов, может содержать также перечень данных, которые являются входными или выходными для процесса, а также ссылки на правила или регламент, согласно которым выполняется та или иная функция. Пример описания бизнес-процесса «Контроль производства изделия» показан на рис.1. Нетрудно заметить, что эта диаграмма очень похожа на блок-схему алгоритма решения задачи.
Графическое описание процесса также может быть дополнено текстовым описанием его функций-подпроцессов в виде таблицы, содержащей следующие столбцы: название процесса, подразделение (владелец процесса), описание процесса, результат выполнения процесса. Пример подобного описания приведен на рис.2. Если предполагается дальнейшая оптимизация описываемого бизнес-процесса, то в таблицу можно добавить еще столбец с описанием трудностей или недостатков выполняемых на данный момент функций-подпроцессов.
Всегда придерживайтесь правил выбранной графической нотации описания бизнес-процессов.
Источники:
- М.Рыбаков. Оптимизация бизнес-процессов.
- как составить бизнес процесс
Процесс как явление представляет собой качественное изменение, происходящее с объектом наблюдения в течение некоторого времени. Следовательно, еще до начала описания вы должны указать объект и промежуток времени наблюдения.

Инструкция
Сперва вам необходимо описать суть процесса, иными словами - наблюдаемое вами качественное изменение. Например, загорелась, сгорела, погасла (суть события – процесс горения). Изменение может быть внешне видимым (целая спичка превратилась в стержень), измениться может структура объекта, система связей, в зависимости от того, что именно вы отслеживаете. В любом случае, описывая изменение, вам необходимо будет указать дополнительно время и скорость (например, спичка горела 20 секунд, скорость обугливания - 2 миллиметра в секунду). Иногда к этому добавляют такую характеристику процесса, как «цикличность» (происходит наблюдаемое вами изменение один раз или периодически).
Показав суть изменения, обычно переходят к описанию процесса как последовательности «состояний» С этой целью обычно все время наблюдения с

