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

Опасно! Не пытайтесь повторить.

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

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

Неправильно: email через сообщение	Правильно: email через пользовательскую задачу (ручной процесс)	Правильно: email через задачу-сценарий (процесс, реализованный в BPMS)

Если вам надо показать, что какая-то задача взаимодействует с внешним миром (например, с заказчиком или поставщиком), то можно использовать пул - черный ящик и сообщения, прикрепленные непосредственно к задаче:

Но лучше не засорять диаграмму потоками сообщений и черными ящиками. Ведь если задача называется “Get customer’s commitment”, то и так понятно, что она взаимодействует с клиентом:

Использование черных ящиков и сообщений имеет смысл только в одном случае: если вам надо отобразить ВСЕ сообщения, входящие в / исходящие от внешнего контрагента, чтобы специфицировать “коммуникационный контракт” с ним.

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

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

В качестве примера, исполнитель A должен передать эстафетную палочку либо B, либо C в зависимости от результатов выполнения назначенной ему задачи Task 1:

Исполнитель A должен отдавать себе отчет, что он отвечает за исполнение не только задачи, но и следующей за ней развилкой “или-или”. Он должен знать и понимать что означает следующий элемент и как его обрабатывать. В примере выше это достаточно очевидно - догадаться, что это развилка, способен каждый - но другие элементы BPMN не столь очевидны.

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

Задачи на вызов сервиса, задачи на выполнение сценария? Забудьте, они вам не понадобятся; автоматическая процедура, запускаемая пользователем - это пользовательская задача, а не сценарий или сервис.

Элементы BPMN, которые можно рекомендовать для использования в процессах, которые будут исполняться без движка:

• пулы и дорожки
• объекты данных, хранилища данных, потоки данных
• аннотации и ассоциации
• потоки управления и потоки сообщений
• задачи: пользовательские и ручные; никаких сценариев, сервисов, бизнес-правил, отправки и получения сообщений
• цикл по объектам необходим; стандартный цикл избыточен и поэтому не рекомендуется
• подпроцессы: встроенные и повторно-используемые, только свернутые (развернутые не рекомендуются), “по требованию”; подпроцессы-обработчики избыточны, сложны и поэтому не рекомендуются
• развилки: “или-или”, “и”; никаких комплексных и по событиям; развилки “и/или” избыточны и нетривиальны и поэтому не рекомедованы
• события: простое, таймер, сообщение (включая прикрепленные прерывающие и непрерывающие), останов, ошибка
• полностью за рамками: транзакция, компенсация, отмена

Дополнено: задачи-сообщения и события сообщения лучше оставить за рамками сокращенной палитры. Подробнее о сообщениях в BPMN >>

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

С другой стороны, поразительно как много можно смоделировать даже со столь ограниченной палитрой. Чем более профессиональны вы в BPMN, тем меньше элементов вы используете на постоянной основе.

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

Для бизнеса эти изменения в ожиданиях потребителя являются вызовом такого масштаба, аналог которому и не подберешь. Под каток «цифрового переворота» (Digital Disruption) попадают отрасль за отраслью: сначала электронные СМИ и индустрия развлечений (цифровой аудио- и видеоконтент), за ними розница (онлайновые гиганты Amazon, Aliexpress) и телекоммуникации (проводная связь стала анахронизмом). На наших глазах перекраиваются рынки финансовых услуг (онлайн-банкинг и финтех) и образования, гостиничный (booking.com, Airbnb) и транспортный (Uber, Yandex-такси). На очереди — производство (встраиваемые датчики, Интернет вещей, 3D-печать) и здравоохранение (носимые датчики). » читать дальше

Этот контент доступен на языках: English.

Этот контент доступен на языках: English.

Тест ниже - перевод статьи Shelly Sweet (i4process) - часть 1, часть 2.

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

Методология BPM: » читать дальше

Некая организация живет по плану: на регулярной основе планы составляются, затем пункты плана выполняются.

1. Антипаттерн: планирование и исполнение в одном процессе

Проблема этой диаграммы в том, что планирование длится, пока не будут выполнены все пункты плана. » читать дальше

Текст ниже - перевод отличной статьи из блога Скотта Фрэнсиса.

 
Нам в BP3 множество раз приходилось идти спасать проекты BPM, которые до этого не удалось запустить большим консалтинговым компаниям широкого профиля. Я решил, что будет полезно объяснить, почему подобные провалы происходят и как нам удается избежать подобных ловушек. Для начала, что мы обычно наблюдаем в таких проектах.

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

» читать дальше

Заказчику нужно срочно привести в порядок процесс заключения договоров - что называется, “уже вчера”.

Но для этого надо заключить договор с консультантом BPM

Из серии “непридуманные истории”.

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

Как в случае проектов, так и процессов можно выделить два уровня управления:

1. собственно управление объектом (бизнесом, компанией или ее частью)
2. управление системой управления - будем называть это мета-управлением

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