Меня часто спрашивают — что почитать о бизнес-процессах?
Одним из лучших сайтов на просторах рунета является www.klubok.net. Я сам «вырос» на форуме и статьях этого сайта. Многие статьи не потеряли актуальности и сейчас. Начать учиться рекомендую именно с него.
А вот если говорить о книгах — то уверенно могу сказать лучшая книга о бизнес-процессах — это книга, написанная Репиным и Елиферовым: «Бизнес-процессы компании. Построение, анализ, регламентация».
Великолепную статью одного из этих авторов я и приведу.
Описание бизнес-процессов: стремление к простоте.
В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема» в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие.
При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.
Нотации описания бизнес-процессов. Часть 3. Нотация EPC | Naked BPM
Для бизнес-аналитиков компаний тезисы, обсуждаемые в статье, — это серьезный повод задуматься, насколько эффективны используемые ими подходы к разработке графических схем процессов организации.
Введение
Одной из важнейших целей формирования графических схем процессов является последующее их использование в регламентирующих документах организации. По этим схемам, как правило, работают сотрудники, которые не обучены сложным нотациям, не имеют навыков системного анализа и т.п. Для них очень важна простота и наглядность схем.
Сложные, запутанные схемы, содержащие много различных условных обозначений, плохо воспринимаются людьми, что затрудняет их практическое использование. Поэтому для практических целей важным является корректный выбор и использование нотации (методики) описания процессов. По каким критериям следует выбирать такую нотацию? Как сравнивать разные нотации между собой? Рассмотрим несколько популярных нотаций и попытаемся ответить на эти вопросы.
Сравнение нотаций
Для сравнения были выбраны следующие нотации описания процессов:
- «Простая блок-схема» (с отображением движения документов, с использованием блока «Решение»);
- «Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);
- «Процедура» системы Business Studio (один из возможных вариантов представления);
- ARIS eEPC.
В качестве тестового примера был выбран простой и интуитивно понятный процесс. Результаты описания этого процесса представлены на рис. 1-4.
Рис. 1. Схема процесса в нотации «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение»).
На схеме рис. 1. Последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов – при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых «зависит» последующий ход процесса.
Нотации описания бизнес-процессов. Часть 4. Нотация BPMN | Naked BPM
Такой подход к использованию «ромбиков» является весьма распространенным. Но фактически, вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если задуматься, то ценность (смысл) рисования этих «ромбиков» не является очевидным. Что это за объекты: операции процесса, события? Вроде бы ни то, и не другое.
Это скорее операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе «ромбик» был бы полноценной операцией сравнения условий и т.п. Но на схеме процесса нужно показывать реальные объекты – процессы, выполняемые людьми, документы, информационные системы и т.п. Задумайтесь, корректно ли показывать «ромбики» отдельно от операции процесса на схеме? Вместо этого можно:
а) описать логику принятия решения в виде последовательность операций на схеме рассматриваемого процесса;
б) описать логику в виде схемы шагов соответствующего подпроцесса, переходя на уровень ниже;
в) описать логику текстом (в текстовых атрибутах операции) и в последующем вывести в регламент выполнения процесса.
Сформулируем «плюсы» и «минусы» рассмотренного выше (рис. 1.) способа использования «ромбиков».
- Наглядное отображение «логики» выбора тех или иных выходов процесса.
- Акцентирование внимания исполнителя на точку принятия решения/ветвление процесса в зависимости от условий.
- Вынос логики принятия решения «наружу» операции процесса (некорректно с точки зрения формальной декомпозиции процессов).
- Неудобно документировать процесс (приходится дублировать «ромбики» текстом при формировании текстового описания операции).
- Схема процесса становится информационной перегруженной.
- «Ромбики» часто используются слишком формально, без реальной необходимости.
По мнению автора статьи, рассмотренный на рис. 1. способ применения блоков «Решение» («ромбиков») является некорректным с точки зрения бизнес-моделирования.
На рис. 2. показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме рис. 1. Схема рис. 2. выглядит гораздо проще.
От графических элементов не рябит в глазах, а с точки зрения информативности, эта схема вполне понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.
Рис. 2. Схема процесса в нотации «Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»).
«Плюсы» и «минусы» графического представления процесса в форме, представленной на рис. 2., показаны ниже.
В целом, применение схем в формате, подобном представленному на рис. 2, является удобным как для разработчиков, так и для сотрудников, работающих по этим схемам.
На рис. 3. представлена схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки «Решение» использованы не стандартным образом – не как графический элемент для отображения вопроса и ветвления, а как полноценная операция процесса, связанная с принятием решений.
В Business Studio «ромбик» обладает почти всеми атрибутами полноценного процесса, но не может быть декомпозирован (возможно, разработчики системы со временем сделают такую возможность). Использование «ромбика» (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты «ромбика» можно внести любую текстовую информацию: описание, начало, завершение, требование к срокам и т.п.
Второй особенностью схемы процесса, представленной на рис. 3., является применение стрелок. Для отображения последовательности операций можно использовать стрелку с одним наконечником – стрелку «предшествования». Для отображения движения документов можно использовать стрелку с двумя наконечниками.
Но именно в Business Studio можно пользоваться только одним типом стрелок – стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности. Такой подход дает возможность:
- существенно сократить количество графических элементов на схеме процесса, и при этом:
- вывести в регламент процесса необходимую информацию о входящих и исходящих документах.
Таким образом, не загромождая схему лишними элементами, мы можем, тем не менее, полно описать процесс и выгрузить в регламент всю необходимую информацию.
«Плюсы» и «минусы» графического представления процесса в форме, представленной на рис. 3., показаны ниже.
Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»).
В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на рис. 3.
На рис. 4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Заметим, что на схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий! Сотрудник, читающий схему, должен уметь правильно интерпретировать все эти логические операторы.
Без специального обучения и наличия некоторых навыков чтения подобных схем, рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или помощи квалифицированного бизнес-аналитика.
Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на рис. 1-3. Трудоемкость формирования такой схемы так же существенно выше.
В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.
Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio).
Описание процесса для целей последующей автоматизации
Интересно посмотреть на рассматриваемую схему процесса в случае, если она описана в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, т.е. процессов которые поддерживает система BPM.
Своим мнением об использовании BPMN 2.0. делится А.А. Белайчук — Генеральный директор компании «Бизнес-консоль»:
На рис. 5 изображен тот же процесс в нотации BPMN. Как мы видим, этот рисунок похож на рис.1: в нотации BPMN задачи изображаются прямоугольниками, развилки – ромбами, данные – пиктограммой, похожей на документ. Потоки управления – сплошные линии, потоки данных – пунктирные.
Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением – «движком» BPM-системы.
В то же время, как показывает данный пример, при использовании ограниченного подмножества палитры BPMN оказывается не сложнее привычной блок-схемы. Ну а тем, кто хочет освоить BPMN профессионально, мы рекомендуем специализированные тренинг www.bpmntraining.ru.
Рис. 5. Схема процесса в нотации BPMN 2.0.
Практика жизни
На рис. 6 показан фрагмент схемы процесса, разработанный бизнес-аналитиками вполне конкретной компании в придуманной ими нотации. Схема построена с применением принципов «Простой блок-схемы» — применяется блок «Решение» в своем классическом варианте. Кроме этого, на схеме представлено множество других условных обозначений, использованных не совсем стандартным образом.
Рис. 6. Примеры схемы процесса одной из компаний.
При формировании схемы рис. 6, бизнес-аналитики очевидно, «боролись» за наглядность и максимальную понятность для рядового пользователя. Они стремились свести к минимуму, или вообще отказаться от текстового комментария к схемам процессов. Исполнителям просто печаталась схема формата А3, при чтении которой все сразу становилось понятно: что делать, как, какие документы использовать и т.п.
Рассматриваемая схема не является, конечно, образцом простоты и наглядности. Но она была сформирована, чтобы донести максимум полезной информации для исполнителей процесса.
Выводы
Итак, очевидно, что при описании процессов нужно стремиться к простоте и понятности для сотрудников.
Использование сложных, формализованных нотаций при описании процессов приводит к:
- трудностям при использовании (интерпретации) схем рядовыми сотрудниками;
- невозможности (сложности) организации работ по описанию процессов силами сотрудников подразделений, не прошедших специальное обучение;
- значительному увеличению трудозатрат бизнес-аналитиков на формирование схем;
- дополнительным сложностям при документировании схем (большой объем и т.п.);
Поэтому не стоит загромождать схему процесса различными графическими элементами. Но уже если их использовать, то лучше, чтобы они несли полезную информацию для сотрудников, а не были просто следствием формального применения нотаций моделирования.
В.В. Репин, к.т.н., доцент, Исполнительный директор ООО «BPM Консалтинг Групп», зав. кафедрой Управления бизнес-процессами НОУ ВПО «ИЭФ «Синергия», основатель портала www.FineXpert.ru
Именно эти простые принципы я и пытаюсь донести до руководителей предприятий, которые очарованные красивыми презентациями программных продуктов зачастую забывают, что часто простой чек-лист лучше 10 страниц регламентов.
Tags:
Источник: tetervak.livejournal.com
Нотации бизнес процессов что это
В статье рассмотрена задача выбора графической нотации описания процессов предприятия. В работе рассмотрены следующие графические нотации: унифицированный язык моделирования (UML), IDEF0, IDEF3, DFD, EPC, BPMN, графоаналитические схемы. Сравнительный анализ нотаций проведен по двум группам критериев.
Первая группа включает описание особенностей технологических, логистических и организационных процессов предприятия. Вторая группа ориентирована на описание типового постоян-но действующего бизнес-процесса предприятия по изменению производственных процессов. В результате сравнения нотаций по первой группе критериев выбраны нотации EPC, BPMN и нотация мультиагент-ного процесса преобразования ресурсов. При сравнении по второй группе критериев выбраны нотации EPC, BPMN и нотация языка UML. Выбранные графические нотации предполагается реализовать в си-стеме имитационного моделирования.
программное обеспечение
архитектура
графическая нотация
бизнес-процесс
имитационное моделирование
1. Волков В.Н. Информационное взаимодействие подразделений в АСУ промышленными предприятиями с единичным и мелкосерийным типом производства : автореф. дис. … канд. техн. наук. — Орел, 2007.
2. Калянов Г.Н. CASE структурный системный анализ (автоматизация и применение). — М. : Лори, 1996. — 242 c.
3. Михелев М.В., Маторин С.И. Формализация бизнеса с помощью графоаналитических моделей // Научные ведомости БелГУ. Сер. Информатика. 2009. – № 1 (56). – Вып. № 9/1. – С. 86-94.
4. Смирнова Г.Н. Проектирование экономических информационных систем : учебник / Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов. — М. : Финансы и статистика, 2001. — 512 с.
5. Шеер А.В. Моделирование бизнес-процессов. — М. : Весть-Метатехнология, 2000. — 205 с.
6. Aksyonov K.A., Bykov E.A., Dorosinskiy L.G., Smoliy E.F., Aksyonova O.P., Antonova A.S. and Spitsina I.A. (2011). Decision Support Systems Application to Business Processes at Enterprises in Russia, Efficient Decision Support Systems — Practice and Challenges in Multidisciplinary Domains, Chiang Jao (Ed.), ISBN: 978-953-307-441-2, InTech. — URL: http://www.intechopen.com/articles/show/title/decision-support-systems-application-to-business-processes-at-enterprises-in-russia. — pp. 83-108. (дата обращения: 30 июня 2013).
7. ARIS Platform. — URL: http://www.softwareag.com/corporate/products/aris_platform/default.asp (дата обращения: 30 июня 2013).
8. Business Process Model Notation. — URL: http://www.bpmn.org/ (дата обращения: 30 июня 2013).
9. MultiMethod simulation software. — URL: http://www.anylogic.com/ (дата обращения: 30 июня 2013).
10. PowerSim software. — URL: http://www.powersim.com/ (дата обращения: 30 июня 2013).
Современное развитие систем имитационного моделирования (СИМ) следует тренду активного использования средств визуализации и применения распространенных графических нотаций. Так, системы AnyLogic [9], PowerSim [10] и iThink поддерживают при моделировании непрерывных процессов визуальный язык Dynamo, разработанный Дж. Форрестером.
Система AnyLogic для описания дискретных процессов использует State Chart (диаграммы состояний) языка UML. Система BPsim [6] поддерживает диаграммы прецедентов, классов, последовательности и активности языка UML, а также нотацию DFD. CASE-средство All Fusion Modeling Suite позволяет формализовать процесс с помощью нотации IDEF3 и передать это описание в систему имитационного моделирования Arena. Система моделирования бизнес-процессов ARIS [7] поддерживает большое количество графических нотаций (включая UML, EPC и BPMN), однако имитационное моделирование поддержано только для нотации EPC.
В связи с этим актуальной задачей данного исследования является выбор набора графических нотаций для формализации типового бизнес-процесса промышленного предприятия с целью дальнейшей реализации в современной СИМ.
Требования к графической нотации описания технологических, логистических и организационных процессов предприятия
При выборе графической нотации для описания типового постоянно действующего бизнес-процесса предприятия по изменению производственных процессов (ТБПИ) автоматизированной системы управления предприятием (АСУП) необходимо учитывать две группы требований: 1) возможность представления процессов предприятия (технологических, логистических, организационных); 2) представление сценариев ТБПИ. Рассмотрим наиболее известные графические нотации описания процессов: IDEF0 [2], IDEF3 [2], EPC [5], DFD [2], графоаналитические схемы информационного взаимодействия (ГАС) [1; 3], BPMN [8], язык UML [4].
Первая группа требований при выборе графической нотации включает в себя возможность представления в графическом виде следующих особенностей деятельности предприятия: 1) процесса, операции; 2) одиночных входных и выходных ресурсов; 3) вектора входных и выходных ресурсов; 4) состава процесса (декомпозиция); 5) условия запуска процесса; 6) средств выполнения процесса; 7) ветвлений и слияний процессов; 8) асинхронных и синхронных процессов. К критериям второй группы требований относится возможность представления в графическом виде следующих особенностей ТБПИ: 1) событие (например, инцидент, проблема, запрос и т.д.); 2) роль (элемент организационной структуры) АСУП; 3) элемент сценария действий ТБПИ (операция); 4) последовательность действий сценария (переходы с ветвлениями и синхронизацией); 5) элемент АСУП (элемент информационной системы); 6) элемент документооборота; 7) объектно ориентированное описание архитектуры АСУП. Данные требования формируют как требования к средствам визуализации СИМ, так и к средствам описания базы знаний предметной области ТБПИ АСУП. Ниже представлены результаты анализа нотаций.
В IDEF0 выглядят одинаково ресурсные потоки и потоки событий (инцидентов, проблем), роли и средства ТБПИ могут быть представлены в виде механизмов. IDEF0 плохо ориентирована на описание архитектуры программного обеспечения.
В IDEF3 выглядят одинаково ресурсные потоки и потоки событий (инцидентов, проблем), роли и средства ТБПИ могут быть представлены в виде механизмов. IDEF3 плохо ориентирована на описание архитектуры программного обеспечения. IDEF3 хорошо представляет логику синхронных и асинхронных процессов и событий.
В СИМ ARIS для описания процессов используется стандарт EPC (extended Event Driven Process Chain) – «расширенная нотация описания цепочки процесса», управляемого событиями. Процесс в нотации EPC представляет собой последовательность процедур, расположенных в порядке их выполнения.
В EPC хорошо идентифицировать ресурсные потоки и потоки событий, роли и средства ТБПИ разделяются. EPC плохо ориентирована на описание технологических и логистических процессов, в которых используется большое количество разных ресурсов и средств (схемы становятся плохо воспринимаемыми). EPC плохо ориентирована на описание архитектуры программного обеспечения. EPC поддерживает выход на динамическое моделирование процессов.
В DFD выглядят одинаково ресурсные потоки и потоки событий, роли и средства ТБПИ могут быть представлены в виде внешних сущностей. DFD плохо ориентирована на описание технологических и логистических процессов, в которых используется большое количество разных ресурсов и средств (схемы становятся плохо воспринимаемыми, целесообразнее векторное представление потоков ресурсов и его детализация). DFD хорошо ориентирована на описание архитектуры программного обеспечения (представление информационных потоков, функций информационной системы, хранилищ данных).
Диаграмма ГАС [1; 3] состоит из набора графических блоков и комментариев к ним, отражающих выполнение функций, закрепленных за соответствующими подразделениями. Все блоки диаграммы связаны друг с другом отношениями передачи данных или управляющих воздействий. ГАС отражает динамику взаимодействия подразделений в процессе функционирования в соответствии с требованиями стандартов серии ИСО 9000. Основу модели информационного взаимодействия составляют классификаторы, представляющие собой структурированное описание функций обеспечения деятельности, функций управления, организационной структуры и бизнес-процессов предприятия.
В ГАС хорошо идентифицировать потоки событий. Роли и средства ТБПИ разделяются и могут быть описаны в виде дорожек и внешних модулей соответственно. ГАС плохо ориентирована на описание технологических и логистических процессов: нет средств формализации потоков ресурсов, нет выхода на описание динамики процессов, нет средств формализации асинхронных и синхронных процессов. ГАС хорошо ориентирована на описание архитектуры программного обеспечения (представление информационных потоков, функций информационной системы, хранилищ данных).
Нотация BPMN (Business Process Model and Notation, нотация и модель бизнес-процессов) [8] предназначена для описания диаграмм бизнес-процессов, понятных как техническим специалистам, так и бизнес-пользователям. Графические аспекты нотации разделены по конкретным категориям. Совокупность категорий нотации невелика, что позволяет читателю схемы BPMN легко узнавать основные типы элементов и облегчает понимание схемы. Выделяют четыре основные категории элементов нотации [8]: 1) объекты потока управления – события (инициаторы действия или результаты действия), действия (задачи, подзадачи) и логические операторы (точки принятия решений); 2) артефакты – группа (объединение действий без влияния на поток управления), аннотация, объект данных (информационные данные и документооборот); 3) роли – пул (область организации различных действий в категории со сходной функциональностью), дорожка (часть пула); 4) соединители – поток процесса (задает порядок выполнения действий), сопоставление (ассоциирование артефактов или данных с объектами потока управления), поток сообщений.
В BPMN хорошо идентифицировать потоки событий. Роли и средства ТБПИ разделяются и могут быть описаны в виде дорожек и внешних модулей соответственно. BPMN не ориентирована на описание ресурсных потоков, что затрудняет описание технологических и логистических процессов, использующих большое количество разных ресурсов. BPMN хорошо ориентирована на описание архитектуры программного обеспечения. BPMN хорошо представляет логику синхронных и асинхронных процессов и событий, поддерживает выход на динамическое моделирование процессов.
В UML потоки событий могут быть представлены как информационные потоки (с использованием диаграмм активности, состояний или последовательности), роли и средства ТБПИ могут быть представлены в виде акторов. UML плохо ориентирована на описание технологических и логистических процессов: нет средств формализации потоков ресурсов и средств, выход на описание динамики процессов имеется только у диаграмм активности и состояний, нет средств формализации асинхронных и синхронных процессов. UML хорошо ориентирована на описание архитектуры программного обеспечения и поддерживает объектно ориентированный подход.
Для описания процессов предприятия (технологических, логистических, организационных) предлагается использовать расширяемую нотацию мультиагентных процессов преобразования ресурсов (МППР), интегрированную на основе нотаций IDEF0, IDEF3, EPC и диаграмм активности языка UML. Данная нотация реализована в мультиагентной СИМ BPsim. На рис. 1 и 2 показан бизнес-процесс обслуживания клиентов в нотации BPMN и МППР.
Рис. 1. Представление процесса в нотации BPMN
Рис. 2. Представление процесса в нотации МППР
Результаты сравнительного анализа представлены в таблице 1.
Возможность представления в графической нотации:
Источник: science-education.ru
Нотация BPMN как внутренний стандарт компании для проектирования бизнес-процессов: «за» и «против»
Какие нотации используют компании для описания процессов сегодня?
Многие успешные компании, внедряющие технологии автоматизации бизнес-процессов, используют нотацию BPMN. Многие, но не все… Более того, в РФ существует огромное количество средних и крупных предприятий, на которых вообще отсутствует принятый корпоративный стандарт проектирования бизнес-процессов. Какими средствами они «рисуют» процессы?
Чаще всего в MS Visio используют набор объектов для «Простой блок-схемы». Бывают ситуации хуже, когда в компании одновременно применяют 3-4 разных подхода к описанию процессов, причем все они нестандартные и реализованы в различных «нотациях» и программных продуктах, включая MS Excel и Power Point. Интересно, почему, когда речь заходит о необходимости описать процессы, все (кроме узкого круга профи) хватаются за эту «Простую блок-схему» с ромбиками?
Возможный ответ – этому учили в школе на уроках информатики. Вдолбили, так сказать. Если бы в школе учили описывать исполняемые процессы в BPMN, то вряд ли чья-то рука потянулась к блок-схеме родом из 70-х. Но пока этого, увы, нет.
К чему приводит такая практика проектирования бизнес-процессов? Во-первых, схемы процессов понятны весьма узкому кругу лиц, а не всем сотрудникам компании. Во-вторых, такие схемы, чаще всего, носят аналитический характер. Это означает, что процесс описан весьма укрупненно, без деталей. Таки схемы нельзя «исполнить».
Если попытаться выполнить работу как указано на схеме, то сразу возникнут вопросы, ответов на которые схема не дает. Это звучит странно – как схема, предназначенная для описания алгоритмов, дает сбои при описании процессов для бизнеса? Конечно, ответ заключен не в наборе используемых значков нотации. Причина — в идеологии формирования схемы.
Сегодня тренд цифровизации бизнеса явно набирает обороты. Но может ли компания, которая даже не имеет внутреннего стандарта моделирования и обученных сотрудников, быть успешной в цифровой трансформации? Сомнительно. Для начала, придется научиться быстро и эффективно проектировать процессы своими силами (создать внутренние компетенции), либо заплатить большие деньги внешним провайдерам.
Ситуацию с использованием устаревших подходов частично усугубляет наличие в крупных компаниях действующих систем электронного документооборота. То, что в них творится, назвать автоматизацией бизнес-процессов можно весьма условно. Большинство руководителей это понимает, но не знает возможностей современной BPMS (Business Process Management System) в части автоматизации процессов и, особенно, применения концепции «Документ без документа». Вообще, относительно недавно вступил в стадию умирания бумажный документооборот, а теперь и электронный документооборот должен умереть, оставив вместо себя автоматизированные процессы с нужным набором данных. В BPMS, если потребуются, документы можно формировать автоматически, так сказать, «налету».
Использование нотации BPMN в качестве корпоративного стандарта дает возможность не только проектировать процессы, но и внедрять в массы идеологию исполняемых процессов в купе с новыми ИТ-технологиями, такими как PM (Process Mining), RPA (Robotic Process Automation) и проч. Рассмотрим аргументы «За» и «Против» использования нотации BPMN в качестве корпоративного стандарта.
Почему нотация BPMN: «За» и «Против»
Руководителям компании нужно объяснить, что BPMN – это не просто значки другого, незнакомого вида и цвета. Это – инженерный стандарт проектирования исполняемых бизнес-процессов, обладающий следующими преимуществами (плюсами):
- наглядность, понятность и красота схем;
- после базового обучения можно начинать с использования ограниченного набора объектов;
- BPMN — стандарт ISO с 2013 года;
- BPMN де-факто использует большинство разработчиков BPMS.
Да, BPMN – сложный стандарт. Однако, даже начинающие при использовании ограниченного набора объектов и понимания сути метода (исполняемый процесс, токен, экземпляр) могут проектировать вполне качественные схемы.
Более того, применение сложных семантических конструкций без действительной практической необходимости может только осложнить работу, привести к созданию неоправданно сложных схем или вообще исказить смысл процесса до неузнаваемости. С чем бы сравнить? Это как неопытный спортсмен, не освоивший базовую технику бросков, начинает пытаться применять сложные и опасные приемы.
Я уверен, что можно обучить сотрудников, так сказать, использовать верхушку айсберга. Этого на первых порах будет достаточно. Крайне важно, чтобы сотрудники компании научились формировать наглядные, понятные и красивые схемы. Много раз на практике наблюдал ситуацию, когда запутанная, уродливая схема после соответствующей доработки становится красивой, а главное, понятной участникам процесса и внутреннему заказчику – руководителю.
Что важно донести до руководителей?
В первую очередь, нужно довести до сведения руководителя компании, что нотация BPMN – это лучший инженерный стандарт для проектирования процессов. Вряд ли в ближайшее время появится какой-то другой стандарт. Если поставлена цель цифровизации компании, то навык проектирования исполняемых процессов с использованием нотации BPMN будет одним из ключевых.
Далее важно объяснить руководителю разницу между общей, аналитической схемой и схемой исполняемого процесса. Для этого потребуется раскрыть понятие токена и экземпляра процесса. Более сложные аспекты, связанные с межпроцессным взаимодействием, можно будет объяснить на примерах компании несколько позже (чтобы поначалу не вызвать отторжения к подходу в целом из-за сложности этого конкретного метода).
BPMN – сложный стандарт. Но в рамках первичного ознакомления достаточно дать руководителям минимально необходимые знания семантики и метода моделирования бизнес-процессов. Это сделать вполне реально, например, в рамках проведения моделирующих (рабочих) сессий по описанию и анализу бизнес-процессов компании.
По ходу вовлечения, руководителям обязательно нужно показывать возможности, ограничения и условия эффективного использования современных решений класса BPMS, PM, RPA, AI и проч. Но надо четко понимать, что передаваемая и, можно сказать, культивируемая в умах менеджеров идеология исполняемых бизнес-процессов является базой для пропаганды новых информационных технологий.
Как обучать сотрудников нотации BPMN?
Это не так уж и сложно. Нужно:
- найти хорошего специалиста, который умеет преподавать тему, и обсудить с ним учебную программу;
- подготовить учебные и методические материалы;
- выбрать инструмент моделирования;
- разработать внутренний стандарт применения нотации BPMN для проектирования бизнес-процессов;
- организовать обучение;
- организовать работу по практическому закреплению навыков моделирования процессов.
В настоящее время специалистов, хорошо знающих BPMN, на рынке уже достаточно много. Но важно, чтобы такой специалист мог научить использовать нотацию на простых и понятных примерах, без использования «птичьего языка» (сленга ИТ-специалистов – профессиональных внедренцев BPMS). Кстати, я категорически против так называемого «каскадного» обучения, когда одного сотрудника отправляют на тренинг, а он потом пытается учить всех остальных. Результат – множество ошибок, а главное, — искаженное понимание темы.
Обучение проектированию процессов в нотации BPMN я провожу по книге «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I». Как правило, в течение 4-6 часов слушатели делают практические задания, осваивая элементы нотации от простого к сложному. Затем, они выполняют комплексное практическое задание по проектированию трех связанных между собой процессов.
Проводится презентация результатов, анализ схем по чек-листу и разбор ошибок. Для такого обучения достаточно одного дня.
Далее выдаются практические задания, которые слушатели делают в течение недели. Затем проводится рабочая сессия по представлению и разбору схем процессов («домашние задания» я проверяю заранее). После 2-3 сессий участники приобретают навык формирования вполне адекватных схем в нотации BPMN.
На следующем этапе развития можно использовать книгу Игоря Федоров «Нотация BPMN 2.0. Стандарт ISO/IEC 19510:2013 для создания исполняемых моделей бизнес-процессов», сам стандарт и множество практически полезных материалов в сети Интернет.
Идеальным вариантом освоения BPMN является практикум с использованием, собственно, BPMS (например, такой практикум проводит А.А. Белайчук, Президент ABPMP Russian Chapter, с использованием системы BizAgi). Однако, в ряде случаев это сделать технически и организационно сложно. Приходится начинать с простого. Но, как минимум, демонстрацию движения токенов вдоль схемы исполняемого процесса сделать крайне полезно.
Внедрение нотации BPMN как корпоративного стандарта проектирования процессов в Иркутской нефтяной компании
В качестве примера рассмотрим кейс внедрения нотации BPMN в «Иркутской нефтяной компании» («ИНК»), в которой я уже более 1,5 лет сопровождаю проект создания и развития Системы управления бизнес-процессами. Информацию любезно предоставил Юрий Андреевич Федосеев, начальник отдела оптимизации бизнес-процессов и стандартизации ООО «ИНК» (ОБПиС).
За время проекта в «ИНК» удалось сделать многое:
- разработан и внедрен стандарт «Моделирование бизнес-процессов»;
- установлен и настроен инструмент проектирования и анализа процессов (Business Studio 4.2);
- обучено 259 руководителей и специалистов;
- сформировано более 226 схем в BPMN;
- внешние подрядчики (в т.ч. крупные консалтинговые компании) обязаны представлять результаты работы в виде схем BPMN с учетом требований стандарта компании;
- внедрены регламенты сквозных процессов, разработанные на основе схем процессов в нотации BPMN;
- внедряется система оценки процессной зрелости компании;
- проект на стадии выбора BPMS.
Самое главное, что в «ИНК» активно формируется процессное мышление у руководителей и специалистов. Высокая практическая оценка используемых методов и инструментов подтверждается большим количеством запросов от подразделений в ОБПиС с просьбой провести анализ и оптимизацию их процессов. Юрий Федосеев отмечает:
«В проектах оптимизации мы преимущественно используем базовый набор элементов нотации (стартовые и конечные события, события отправки и приема сообщения, таймеры, шлюзы и/или… Несмотря на сложность, базовые элементы и логика нотации хорошо воспринимается сотрудниками на обучении. Освоение происходит быстро.
Все бизнес-аналитики отдела прошли подготовку по программе Внутренних тренеров, что позволило организовывать качественное обучение для небольших групп на постоянной основе. Мы не ставим перед собой цель описать все процессы Компании. Ценность нашей работы – в помощи, внутреннем консалтинге. Наши клиенты – подразделения, которые хотят разобраться в своей работе и в том, как лучше взаимодействовать с другими в рамках сквозных процессов. И моделирование – это наш основной инструмент в этом деле…»
«Оптимизация процессов Электроснабжения» — так назывался один из проектов «ИНК», в рамках которого использовалась технология описания и анализа процессов в нотации BPMN. По ходу проекта было сформировано 59 процессов в нотации BPMN. Описание и анализ процессов позволил выявить 10 критичных зон безответственности и последствия, к которым наличие этих зон может привести. Прогнозный экономический эффект от устранения зон безответственности составляет около 78,6 млн. рублей в год.
Второй проект с использованием BPMN, как корпоративного стандарта проектирования процессов «ИНК», — это «Оптимизация процессов Капитального строительства». В рамках данного проекта в условиях жестких ограничений удалось выстроить слаженную и эффективную работу подразделений. Основные результаты моделирования процессов на текущей фазе проекта: прозрачный процесс капитального строительства, оперативный доступ сотрудников к схемам процессов и регламентам через корпоративный портал.
Подводные камни внедрения нотации BPMN в качестве корпоративного стандарта
В некоторых компаниях при использовании нотации BPMN для проектирования процессов возникают определенные трудности. Работа организована неэффективно. На выходе получаются поверхностные схемы аналитического характера, которые невозможно использовать для анализа и принятия решений. Некоторые причины такой ситуации:
- плохое обучение – как следствие, непонимание исполняемых процессов и формирование аналитических схем;
- архитектурные решения низкого качества – проектирование процессов нижнего уровня без понимания системы процессов в целом;
- попытка формально «перерисовать» в BPMN старые схемы с сохранением их недостатков;
- схемы огромного размера с ошибками (семантика, логика);
- низкая степень мотивации участников процесса (или обратная мотивация – желание скрыть реальную картину);
- моделирование ради моделирования.
Резюме
Хочу отметить, что навык проектирования процессов в нотации BPMN – это только один из многих навыков второй группы компетенций («Операционные») модели Gartner 2013 года, которые необходимы для успешного выполнения BPM-проекта в компании. Это означает, что руководители не должны ожидать «процессно-цифрового чуда» только от того, что они заставили необученных сотрудников с низким уровнем внутренней мотивации «рисовать» схемы процессов. Другими словами, внедрение Системы управления бизнес-процессами компании – это не только проектирование процессов, но их активное улучшение и внедрение изменений, создание методов и инструментов управления бизнес-процессами.
Если руководство компании поставило цель трансформировать систему управления с использованием современных процессных технологий, то навык проектирования и анализа исполняемых процессов является одним из ключевых. Нотация BPMN в этом случае может и должна быть выбрана в качестве внутреннего корпоративного стандарта проектирования бизнес-процессов.
Архивы
- Май 2023 (2)
- Апрель 2023 (2)
- Март 2023 (4)
- Февраль 2023 (4)
- Январь 2023 (4)
- Декабрь 2022 (3)
- Ноябрь 2022 (2)
- Октябрь 2022 (3)
- Сентябрь 2022 (3)
- Август 2022 (5)
- Июль 2022 (4)
- Июнь 2022 (3)
- Май 2022 (4)
- Апрель 2022 (3)
- Март 2022 (4)
- Январь 2022 (3)
- Декабрь 2021 (5)
- Ноябрь 2021 (4)
- Октябрь 2021 (4)
- Сентябрь 2021 (5)
- Август 2021 (3)
- Июль 2021 (5)
- Июнь 2021 (2)
- Май 2021 (3)
- Апрель 2021 (5)
- Декабрь 2020 (1)
- Август 2020 (1)
- Июль 2020 (5)
- Июнь 2020 (6)
- Апрель 2020 (1)
- Март 2020 (1)
- Февраль 2020 (2)
- Январь 2020 (3)
- Декабрь 2019 (5)
- Ноябрь 2019 (4)
- Октябрь 2019 (1)
- Сентябрь 2019 (1)
- Июль 2019 (3)
- Июнь 2019 (2)
- Март 2019 (1)
- Январь 2019 (7)
- Декабрь 2018 (5)
- Ноябрь 2018 (5)
- Октябрь 2018 (2)
- Сентябрь 2018 (1)
- Август 2018 (6)
Источник: bpms.ru
