Бесплатный фрагмент - Моделирование бизнес-процессов. От идеи к результату

Введение

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

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

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

Если вы обращаетесь к врачу с переломом, результат его работы заранее очевиден, скорее всего это будет гипс. Также, если вы заказываете архитектурный проект дома, финал сотрудничества также ясен и однозначен. При работе с информационными системами, например, с Zoho или 1С или в любой другой системой организации труда, все не настолько однозначно. Как определить, в какой момент задача выполнена и сотрудничество завершено? Заказчики склонны годами обращаться за бесплатной помощью по результату законченного проекте и консультациями в полной уверенности, что так и надо.

После долгих поисков метода работы по проекту я в конечном итоге я пришел к тому, что наиболее близкой мне является методология IDEF и BPMN. Когда я начал изучать эти инструменты IDEF уже существовала многие годы, а BPMN только набирала популярность. За 15 лет я глубоко изучил эти инструменты, и теперь решил поделиться своими знаниями с читателями.

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

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

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

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

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

И здесь BPMN оказалась тем самым инструментом, который помогает закрывать проекты быстро и одновременно качественно. Как это реализовать на практике, читайте в книге.

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

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

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

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

Моделирование бизнеса. Основные подходы

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

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

Основные подходы

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

— Функциональный;

— Процессный;

— Ментальный (с применением ментальных карт).

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

Функциональное моделирование

Функциональное моделирование рассматривает деятельность в организации через призму функций (лат. functio — совершение, исполнение). В функциональной модели функция не имеет временной последовательности, а только точку ввода и точку вывода.

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

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

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

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

Процессное моделирование

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

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

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

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

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

Ментальный подход (ментальные карты)

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

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

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

— Не нужно знать какие-то специальные языки;

— Нет строгих рамок и ограничений при создании схемы;

— Ментальная карта в большинстве случаев интуитивно понятна;

— Создавать такие схемы просто.

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

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

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

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

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

Отличие языков разработки бизнес-моделей от языков проектирования систем

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

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

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

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

Преимущества разработки моделей бизнеса

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

— Языки моделирования помогают максимально качественно передать информацию. Стандартизация повышает скорость восприятия.

— Скорость разработки моделей значительно увеличивается. Языки содержат все необходимые инструменты и графические блоки в готовом виде. Вам не придется «рисовать» или придумывать свою терминологию. Инструментарий уже готов, и работа в его рамках значительно ускоряется. Конечно, язык нужно выучить. Но один раз изучить — это намного быстрее, чем каждый раз придумывать и объяснять собственный набор обозначений.

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

Применение моделей бизнеса на практике

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

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

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

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

Что такое бизнес-процесс и описание бизнес-процесса

О бизнес-процессах говорят много и часто преимущественно в связи с автоматизацией бизнеса. Использую этот термин и я, в том числе, в своих публикациях, посвященных CRM-системам, ERP, работе с BPMN-нотациями, IDEF0 и описанию других инструментов, которые могут понадобиться в работе бизнес-консультанта и внедрении систем автоматизации. При этом в Рунете понятное и развернутое определение термина «бизнес-процесс» я до сих пор не нашел.

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

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

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

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

Бизнес-процесс — это логическая последовательность действий человека (или нескольких человек) в коллективе. Цель описания бизнес-процесса — анализ и регламентация тех или иных действий в коллективе.

Почему я делаю особый упор на людях и коллективе:

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

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

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

Описание бизнес процесса

Также важно дать определение описанию бизнес процесса:

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

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

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

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

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

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

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

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

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

Технологический процесс и бизнес-процесс

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

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

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

— Берем заготовку A;

— Соединяем ее с заготовкой B;

— Обрабатываем под параметры C;

— Получаем деталь.

Все однозначно и никаких условных «вилок» не предусматривается.

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

— Получаем вводные данные A:

— Если данные соответствуют условию B, переходим на последовательность действий C;

— Если данные соответствуют условию D, выполняем действия E.

— Полученный результат передается на выход.

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

История появления термина

Я не единожды читал информацию о том, что нотации бизнес-процессов (IDEF0) появилось чуть ли ни в середине XIX века. Более реалистичные авторы пишут о периоде Второй Мировой войны. Но и они ошибаются.

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

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

На самом деле описание бизнес-процессов и нотации BPMN появились в 70-е годы XX века, когда повсеместно начали использоваться информационные системы. И сам термин, и нотации понадобились изначально именно для разработки информационный систем.

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

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

Первые методологически проработанные нотации бизнес-процессов (а я буду говорить именно о методологически проработанных нотациях, например, IDEF3***) появились у военных в США. Причина очевидна — уже тогда военные в США пользовались автоматизацией с использованием удаленных соединений, т.е. той самой системой, которая позже стала Интернетом. И при таком уровне применения информационных систем потребность в нотациях бизнес-процессов была особенно актуальной.

***По теме методологически проработанных нотаций хочу также сказать пару слов. Почему я привел в качестве примера IDEF3: я еще не видел более проработанной методологически системы описания бизнес-процессов. Даже BPMN 2.0 все еще развивается и дорабатывается. А если вы почитаете англоязычное описание IDEF3 (перевода на русский я пока не видел), то также сумеете оценить по достоинству глубину его проработки.

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

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

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

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

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

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

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

Зачем моделировать (описывать) бизнес-процессы

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

Моделирование бизнес-процессов помогает решить сразу две задачи:

— Изучение бизнеса. Графическое изображение в виде схем, т.е. моделирование бизнес-процессов позволяет быстрее понять особенности работы компании и выявить возможные «узкие места».

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

Сочетание изучения истории появления термина с моим личным опытом дает следующее определение:

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

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

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

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

Распространенные мифы и заблуждения

Не «изобретайте велосипед»! Не нужно придумывать свои нотации.

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

Я не рекомендую так поступать. Во-первых, при использовании готовых инструментов вам не потребуется изобретать свои обозначения и стандарты. Все давно придумано до вас. При этом стандартные нотации действительно понятны интуитивно, читаются однозначно, известны многим людям. Во-вторых, в готовых системах (IDEF3, BPMN 2.0 и пр.) имеется проработанная методология и строгие ограничения. Их можно воспринимать как язык программирования и среду для работы с этим языком. Здесь вы просто не сумеете совершить многих ошибок, от этого вас уберегут стандарты синтаксиса и сама среда (ограничения в редакторе, автоматические проверки).

Не путайте описания бизнес-процессы компании и бизнес-процессы IT систем.

Во многих автоматизированных системах, например, 1С или Zoho CRM, существуют собственные сущности с названием «бизнес-процессы». Но к описываемым в этой статье бизнес-процессах эти сущности не имеют никакого отношения. Считайте их «омонимами», т.е. термины вроде звучат одинаково, но в нашем случае это — описание работы компании, а в IT системах — название группы функций и отчетов.

Распространенная ошибка: Бизнес-процесс обязательно приносит ценность (прибыль).

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

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

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

Возможно ли создать идеальный бизнес-процесс — когда следует остановиться?

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

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

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

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

Бизнес процессы — это не только про бизнес

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

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

Вы можете применять бизнес-процессы для улучшения работы и автоматизации:

— государственных учреждений, в том числе, медицинских, центров выдачи документов и т. д.

— благотворительных организаций любого профиля;

— общественных организаций и т. д.

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

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

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

Декомпозиция или подпроцесс?

Нередко даже в профессиональной среде путают два понятия — декомпозиция и подпроцесс. На самом деле, это далеко не одно и то же. И важно понимать разницу между этими двумя терминами.

Декомпозиция

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

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

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

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

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

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

Подпроцесс

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

Основное отличие состоит в том, что декомпозиция допускает больше свобод, здесь вы можете совмещать различные подходы к изучению бизнеса. А подпроцесс — неотъемлемая часть BPMN нотации. В нем жестко заданы все точки входа, выхода, исполнители, инструменты еще на уровне процесса. И вы не можете выйти за эти рамки.

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

Разбираемся с понятием BPM. Что такое управление бизнес процессами

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

Определение по версии EABPM (Европейская ассоциация BPM) этого термина звучит следующим образом:

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

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

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

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

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

Как появилось BPM

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

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

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

— Описание рабочего места

— Должностная инструкция сотрудника

— Требования техники безопасности и т. д.

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

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

Об управлении бизнес-процессами простыми словами

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

Определение от меня:

Управление бизнес-процессами (BPM) — это управление действиями (автоматизированными и неавтоматизирвоанными) в коллективе посредством бизнес-процессов.

Чтобы управлять любыми бизнес процессами необходимо:

— Описать сами бизнес-процессы.

— Внедрить в работу коллектива описанный бизнес процесс.

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

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

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

И чтобы исключить путаницу в терминологии, поясню:

— BPM (Business Process Management) — это методология. т.е. набор основных принципов и подходов к построению нотаций и самой организации работы при помощи бизнес-процессов.

— BPMN (Business Process Model and Notation) — нотация (язык), в которой строятся нотации, в том числе, исполняемые.

— BPMS (Business Process Management System) — IT система исполнения, построенная по определенным правилам, заданных в методологии.

Если проводить аналогию с наукой, то BPM — это прежде всего подход, своего рода мировоззрение. BPMN — это методы и алгоритмы решения конкретных задач. Например, доказательства для теорем или набор методов для создания проекта обеспечения электричеством объекта (производства, многоквартирного дома). А, в свою очередь, BPMS- это уже готовые прикладные решения, которые можно «включить» и они уже будут работать. Для математики это — готовые решения задач, имеющих практическое значение. Для физики — непосредственное реализации той самой электропроводки и подключение объектов. Для сферы айти — готовый программный код.

Исполняемые и неисполняемые бизнес процессы

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

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

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

Описание работы с BPM

Для лучшего понимания того, что такое BPM (управление бизнес-процессами), я приведу пример последовательности действий бизнес-аналитика в рамках этой методологии:

— Опрос людей (сотрудников компании). Понимание того, каким образом производится работа в каждом конкретном случае.

— Документирование бизнес-процесса на основе полученных данных. На этом этапе аналитик получает описание бизнес-процесса «как есть».

— Изучение полученного бизнес-процесса с точки зрения слабых мест и возможности оптимизации.

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

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

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

— Далее — снова проработка изменений в инструкциях и программных системах. И новый этап внедрения в эксплуатацию.

Жизненный цикл процесса в BPM

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

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

Главное правило: при оптимизации процесса нужно уметь вовремя остановиться. И здесь необходимо четко анализировать — трудоемкость (стоимость) изменений и повышение эффективности (выгоды) в результате.

Плюсы и минусы BPM

К числу преимуществ использования BPM относятся:

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

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

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

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

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

Минусы BPM, как это часто бывает, находятся там же, где и преимущества:

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

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

— Бизнес-процесс статичен и практически не подлежит корректировкам «изнутри». Исполнитель получает четкую последовательность действий и уже не может проявить инициативу. В результате, любую ошибку исполнители будут повторять из раза в раз, пока она не будет исправлена в самом бизнес-процессе.

Каким компаниям подходит BPM

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

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

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

Вопросы и ответы

В чем отличие функционального моделирования от процессного?

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

Какие понятия входят в BPM?

В первую очередь, это непосредственно система BPMN, а также описание нотаций BPMS. О них я писал в этой статье, и подробно — в предыдущих статьях. Кроме того, не так давно появились новые понятия — DMN и CMMN. На них я сейчас подробно останавливаться не буду. Постараюсь описать новые понятия и их особенности в будущих публикациях.

Зачем нужно в построении нотаций столько сложностей и разные подходы?

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

С чего начать работу с BPM?

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

Можно ли использовать BPM для неавтоматизированных систем?

Можно. Это подход предназначен, в первую очередь, не для автоматизации (в IT сфере есть свои инструменты), а для организации работы компании или любого коллектива. Здесь могут учитываться участки работы с применением автоматизированных систем. А могут рассматриваться исключительно процессы в коллективе, причем, любом — от строительных бригад или производства до творческих коллективов в театре или филармонии. Главное, четко описать — как происходит интересующий вас процесс, а также, как вы его хотите изменить.

Что такое BPMS

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