• Смотреть запись доклада на youtube >>

Подтянуть и систематизировать знания методов процессного управления и нотации BPMN вы можете на тренингах, которые ведет Анатолий. Очередной курс стартует в 12 февраля.

• Зарегистрироваться на тренинг >>

Ключевые тезисы:

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

Подробнее:

• презентация (pdf) >>
• видео (youtube) >>

Возражения? Дополнения? Мысли по поводу? Делитесь в комментариях -

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

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

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

(Дисклеймер: я не являюсь членом жюри и членом оргкомитета конкурса. Я не обсуждал проекты с членами жюри и не знаю какие оценки они ставят. У меня нет аффилированности с какой-либо из компаний-участников или заинтересованности в каком-либо из представленных проектов. Проекты следуют в том порядке, в котором они презентовались конкурсантами.)

1. Модель компетенций служащего Самарской области (АНОО ДПО «Таволга»)

О компании

Специализированная некоммерческая организация при губернаторе Самарской области

О проекте

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

Что сделано:

• разработана модель компетенций и система грейдов
• разработан пилотный видеокурс
• входное и выходное тестирование
• обучено порядка 10 тыс. из запланированных 160 (суммарная численность служащих региона)

Заказная ИТ-платформа.

Что примечательного

Системный подход: модель компетенций, траектория таланта (по аналогии с путем клиента).

Ставка на дистанционное обучение.

О взаимодействии с разработчиками ИТ-платформы: «мы хотели быстро и по аджайлу, а разработчики хотели от нас ТЗ» (странно, в моей практике наоборот).

Резюме

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

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

К сожалению, проект слабо соотносится с процессным управлением.

2. Система категоризации рисков на основе объективных источников получения данных о принципах нарушений (Государственная инспекция по контролю за использованием объектов недвижимости города Москвы)

О компании

Департамент Правительства Москвы, контролирующий использование жилых и нежилых зданий, сезонных сооружений (летних кафе), земельных участков

О проекте

Необходимо выявлять нарушения и реагировать. Распространенные нарушения: нецелевое использование земельных участков, самовольная установка шлагбаумов.

ИТ-система собственной разработки.

Что примечательного

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

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

Обезличенность контроля (квадрокоптеры и искусственный интеллект вместо визита инспектора) устраняет коррупционные риски в нижнем звене.

Резюме

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

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

3. Внедрение процессного управления на государственном предприятии ФГУП «НПП «ГАММА»

О компании

Продукция и услуги в сфере защиты информации, в том числе для МВД, МО, СВР и ФСБ России

О проекте

Внедрение процессного управления и BPMS. Реализовано 50 процессов: HR, документооборот, управление проектами, закупки, продажи (CRM).

Реализовано на платформе ELMA.

Что примечательного

Двукратное ускорение согласования документов, повышение исполнительской дисциплины на 60%.

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

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

Резюме

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

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

4. Автоматизация бизнес-процесса доставки банковских продуктов физическим лицам (КБ УБРиР)

О компании

Банк с филиальной сетью от Алма-Аты до Варшавы.

О проекте

Бизнес-процесс от заявки до активации клиентом банковской карты (не именной). Три участника: банк, партнер, клиент (физическое лицо).

Реализовано с использованием Camunda, интеграционной шины, микросервисов, Kubernetes.

Что примечательного

На старте проекта не было процессных компетенций.

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

Полностью распределенная команда. Использовали распределенность по часовым поясам, чтобы продлить рабочий день команды.

Резюме

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

Акцент на сокращении трудоемкости и уменьшении потерь из-за ошибок, а не на клиентоориентированности.

5. Цифровизация сквозных бизнес-процессов на платформе ELMA BPM (S8 Capital)

О компании

Диверсифицированный ИТ-холдинг

О проекте

На конкурс представлен бизнес-процесс разработки и печати лотерейных билетов. Жесткие сроки, 120 тысяч точек продаж.

Реализовано на платформе ELMA.

Что примечательного

Сочетание творческих и рутинных задач.

Чат и канбан для облегчения перехода с Trello.

Рецензирование эскизов прямо из портала BPMS.

Взаимодействие с типографией (субподрядчик) через личный кабинет.

Резюме

Проектирование под заказ – заведомо выигрышная область применения для BPMS, но здесь дополнительно реализован ряд нестандартных «изюминок».

Успех пилотного проекта и положительное восприятие бизнес-пользователей дают основания надеяться на продолжение.

6. Упрощенный налоговый вычет без документов в ВТБ Онлайн

О компании

Проект реализован банком ВТБ при активном содействии Федеральной налоговой службы.

О проекте

Процедура получения имущественного налогового вычета (приобретение недвижимости, ипотека) сведена до пары подтверждающих кликов на предзаполненной форме в банковском приложении и на сайте ФНС, срок получения вычета сократился с 4 месяцев до 24 дней.

Реализовано на собственной технологической платформе.

Что примечательного

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

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

Веб-версия на смартфонах Apple работает не хуже нативного мобильного приложения.

Резюме

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

7. Sello — маркетплейс для всех (ООО «Маркетплейс трэйдинг»)

О компании

Интернет-магазин (аналог Ozon или Widlberries) в республике Узбекистан – 4 распределительных центра, 25 пунктов выдачи.

О проекте

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

Бизнес создан с нуля, и с первого дня ставка сделана на BPM и на BPMS в качестве технологического ядра.

Реализовано на платформе ELMA.

Что примечательного

Фактор успеха – глубокая собственная компетенция в электронной торговле, BPM и ИТ. Также привлекались эксперты из DPD и Ozon.

Постоянное совершенствование: 142 версии одного из ключевых процессов, у процесса отмены заказа 27 маршрутов.

«Вернуть товар легче, чем заказать» – правильный лозунг, в электронной торговле лояльность клиентов завоевывается не когда все идет гладко, а когда что-то пошло не так.

Собственные алгоритмы маршрутизации транспорта.

Полностью омниканальные коммуникации с клиентом.

Резюме

Впечатляющая демонстрация возможностей BPM/BPMS в умелых руках: в рекордные сроки (старт в феврале 2021, а в сентябре 2021 уже запустили веб-версию приложения) реализован огромный бизнес-проект.

8. Оптимизация процесса договорной работы методом process mining на основе решения Promease (АО ОДК-Климов)

О компании

Разработчик двигателей для вертолетов (95% российских вертолетов) – конструкторское бюро, производственная и испытательная база

О проекте

Анализ процедуры согласования договоров в «1С Документооборот» с помощью технологии process mining.

Результат проекта – предложены мероприятия, реализация которых позволит сократить сроки согласования договоров на 20%.

Использовалось ПО Promease отечественной разработки.

Что примечательного

В компании сочли стандартный метод value stream mapping из арсенала бережливого производства слишком трудоемкий и решили попробовать альтернативу в виде автоматического выявления процесса по его «следу» в информационной системе.

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

Резюме

Попытка использовать новые технологии заслуживает уважения, но результаты нельзя назвать впечатляющими – неужели то, что договора гоняют по кругу, является таким уж секретом?

Усилия направлены на обеспечение соблюдение стандарта предприятия, а не на реинжиниринг процесса.

9. Фабрика роботизации бизнес-процессов (ОАО «РЖД»)

О компании

Проект выполнен силами Главного вычислительного центра, обслуживающего 240 тыс. пользователей РЖД

О проекте

Процессный конвейер по созданию роботов RPA. За первый год создано 1000 роботов, автоматизирующих деятельность ГВЦ: администрирование учетных записей, составление сводной отчетности, тестирование приложений. На втором этапе приступили к роботизации деятельности других подразделений – создано 470 роботов, 1200 заявок на 2022 г.

Используется отечественное ПО ROBIN RPA.

Что примечательного

Роботизация встроена в системные усилия по оптимизации процессов: если в ходе анализа процесса выясняется, что для какой-то операции подходит робот, то ГВЦ выполняет соответствующую заявку.

Процесс охватывает жизненный цикл робота от идеи до эксплуатации (вообще-то должно быть до вывода из эксплуатации).

На основе статистики Service Desk рассчитывается экономическое обоснование – эффект от робота по отношению к затратам.

Типичная стратегия роботизации – роботов разрабатывают сами бизнес-пользователи (или как минимум активно участвуют в разработке), ИТ обеспечивает необходимую инфраструктуру, компетенции и надзор. В РЖД разработка полностью в руках ИТ.

Резюме

О цифровой рабочей силе много кто говорит, а ГВЦ демонстрирует ее в действии: раньше ГВЦ обслуживало пользователей, сейчас ГВЦ обслуживает роботов, а роботы обслуживают пользователей. ГВЦ стал Robotic Resources департаментом (по аналогии с Human Resources).

10. Трансформация бизнес-процессов клиентского сервиса (АО «НПФ «Благосостояние»)

О компании

Компания из топ-5 независимых пенсионных фондов России – более 25 лет на рынке, 16 филиалов, 1,3 миллиона клиентов

О проекте

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

Спроектированы бизнес-процессы и разработана автоматизирующая их система, интегрированная с CRM и учетными системами Фонда. Раньше оператор работал с 7 системами, свели к трем, цель – свести к одной системе.

На протяжении 10 лет используется ПО Business Studio.

Что примечательного

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

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

Моделирование системной динамики Simantics System Dynamics (нет, это не опечатка).

Резюме

Ценный опыт компании – достигнутый баланс между оптимизацией затрат и клиентоориентированностью. Не сокращать ФОТ, а обслуживать больше клиентов с более высоким качеством при том же штате сотрудников.

Также поучительно внимание к комфорту как клиента, так и сотрудников: чтобы хорошо было клиенту, хорошо и удобно должно быть сотруднику. Здесь компания следует современному тренду Total Experience, под которым понимается слияние улучшения клиентского (Customer Experience) и пользовательского опыта (User Experience).

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

11. Комплексный проект по созданию и внедрению Общих центров обслуживания (Комос групп)

О компании

Крупный агропромышленный холдинг: порядка 10 брендов, 35 компаний; от производства кормов, животноводства, свиноводства производства яиц до переработки молока, мяса, логистики и фирменных розничных магазинов

О проекте

Проект ОЦО – составляющая программы повышения операционной эффективности. Цели стандартные: убрать дублирующие функции, автоматизировать и в итоге сократить затраты. Направления: ITSM (7500 пользователей, 1640 процессов), HR (250 процессов), право (70 процессов).

Фактические результаты превзошли плановые: HR ОЦО внедрен за 8 месяцев (12 по плану), экономия 18+ млн.руб. (10 по плану).

Используемое ПО: Business Studio, Creatio, ElectroNeek.

Что примечательного

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

В нотации BPMN смоделировано свыше 2 тыс. бизнес-процессов. Активно практикуется функционально-стоимостной анализ. Процессы автоматизируются в Creatio, а рутинные операции – средствами RPA.

Резюме

Добротный и масштабный проект реинжиниринга вспомогательных процессов.

Полезный опыт совместного использования средств моделирования процессной архитектуры, BPMS и RPA.

12. Увеличение прибыли в три раза за счёт изменения бизнес-процессов продаж и закупок («Кормовит»)

О компании

Оптовый поставщик кормовых добавок, 2000 товаров (75% импортных), 35 сотрудников

О проекте

Расширение клиентской базы и ассортимента, жесткие требования к срокам поставки, к управлению резервированием и дебиторской задолженности привели к тому, что управлять с помощью Excel стало невозможно. Разработаны модели 30 основных процессов, которые стали заданием для настройки 1С ERP-системы.

Результат: за три года прибыль увеличилась в три раза.

Используемое процессное ПО: Business Studio.

Что примечательного

Радикальный реинжиниринг – на моделирование as-is силы не тратили, т.к. все надо было переделывать.

Реализованы личные кабинеты клиентов и транспортных компаний.

Компания выступает в роли внешнего отдела закупок для клиентов – напоминает, что пора делать заказ.

Мобильное приложение для руководителей.

Резюме

Графические модели процессов плюс текстовые регламенты поверх 1С – бюджетное решение, которое может быть привлекательным для небольших компаний.

13. Создание общего центра обслуживания HR (X5 GROUP)

О компании

Бренды «Пятерочка», «Перекресток», цифровой сервис доставки – 17 тыс. магазинов, 300 тыс. сотрудников

О проекте

В компании давно существует финансовый ОЦО: расчет зарплаты, казначейство, налоги, часть бюджетного планирования. HR «Пятерочки» находился на аутсорсинге у IBS, и целью проекта стало сделать собственный – лучше и на 40% дешевле.

Разработка велась полтора года, реализовано 200 процессов, в месяц обрабатывается 1 миллион заявок. Сейчас в системе 60 тыс. пользователей, к сентябрю планируется охватить оставшиеся 200 тыс. Цели сокращения затрат достигнуты.

Используемое ПО: Camunda, OpenText, SAP.

Что примечательного

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

Процессы были классифицированы на простые типовые, для которых достаточно коротких спецификаций (70%) и нетиповые, для которых разрабатывались модели BPMN.

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

Бесплатный Camunda Community Edition удалось дополнить такими фичами Enterprise-версии, как миграция экземпляров процессов на новую версию. Это стало возможным благодаря наличию сильной команды java-программистов; формирование и поддержание такой команды – отдельная непростая задача.

Резюме

Множество крупных российских компаний говорят «у нас все процессы в SAP» и не воспринимают аргументов в пользу BPM и BPMS. В реальности в таких компаниях SAP не обходиться без многостраничных регламентов, служебных записок, электронной почты и Excel.

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

Стоит оговориться, что опыт X5 в части использования BPMS Camunda подойдет не всем, т.к. не у всех есть мощная команда java-разработчиков. Возможная альтернатива – low-code BPM системы с более демократичными требованиями к квалификации разработчиков.

14. Управление обратной связью с потребителями (Автохолдинг Максимум)

О компании

4 дилерских центра в Санкт-Петербурге – 8 брендов, 800 тыс. клиентов; осенью 2022 г. планируется дополнить продажей автомобилей с пробегом

О проекте

Бизнес-процессы сбора, обработки и анализа обратной связи и претензий клиентов.

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

В результате реализации проекта в компании изменилась культура работа с обращениями и рекламациями, что не замедлило отразиться на количестве претензий (уменьшение на 47%), возросшей удовлетворенности клиентов и рейтинге компании на интернет-ресурсах (с 52% до 75%).

Используемое ПО: Business Studio, 1С Альфа Авто, Qlik Sense.

Что примечательного

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

Управление изменениями на основе модели ADKAR – дифференцированный контроль принятия изменений различных заинтересованными сторонами (директорами дилерских центров и сотрудниками).

Контроль корректирующих действий по каждой претензии.

Резюме

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

15. Единая сервисная экосистема работы с обращениями (АНО «Служба обеспечения деятельности финансового уполномоченного»)

О компании

Уполномоченный государством орган по защите прав потребителей услуг финансовых организаций (банки, страховые, микрозаймы, пенсионные фонды, кредитные кооперативы, …)

О проекте

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

Используемое ПО: NAUMEN, Directum.

Что примечательного

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

Конструктор решений: автоматизация подготовки ответов по типовым шаблонам из единой базы.

Личный кабинет экспертной организации.

Личный кабинет судьи: если гражданин параллельно обратился в суд, то судья самостоятельно сможет получить все документы по делу без участия сотрудников Службы.

Интеграция с Почтой России по API – почта получает письмо в электронном виде и доставляет его в бумажном.

Система размещена в коммерческом облаке.

Резюме

Еще один образец цифровой трансформации в интересах общества.

16. Трансформация технической поддержки по продукту (IEK GROUP)

О компании

Производитель электротехнического оборудования, 2000+ сотрудников

О проекте

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

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

Используемое ПО: Битрикс24.

Что примечательного

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

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

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

Резюме

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

Мой топ-5

Мой личный шорт-лист конкурса «BPM-проект года’2022″:

• Инспекция по контролю недвижимости правительства Москвы
• ВТБ Онлайн
• Sello
• X5
• Служба обеспечения деятельности финансового уполномоченного

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

Поскольку по условиям голосования за приз сообщества АПУБП нужно выбрать только один проект, мой голос уходит X5 GROUP.

Обе отрасли очень перспективны с точки зрения применения BPM и BPMN. Сильными стимулами являются:

• в энергетике – жесткая регламентация со стороны государства (доступ к энергосетям должен предоставляться всем на равных основаниях, а значит – на основе четко прописанного, четко исполняющегося и постоянно контролируемого бизнес-процесса, т.е. с помощью BPMS)
• в медицине – стремление передовых медицинских учреждений уйти от импровизаций и выполнять лечение на основе стандартизованных методов, статистически доказавших свою эффективность (подробнее об этом на сайте OpenHealth.ru)

Комсофт подобрал очень сильную команду – это видно хотя бы по результатам тренинга: 5 из 11 слушателей по результатам тестирования получают сертификаты с отличием. Поздравляем!

Максим Усольцев показал абсолютно лучший на сегодняшний день результат: 28,5 балла из 30 возможных. Плюс к этому он заработал дополнительные 5 баллов, найдя ошибку в нашей шпаргалке по BPMN. Опять-таки, он первый, кому это удалось – ошибка мелкая и заметить ее сложно.

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

1. Экстракорпоральное оплодотворение (ЭКО) – медицина
2. Заявка на технологическое присоединение – электроэнергетика
3. Разработка и сопровождение ПО

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

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

Попутно обнаружилась интересная параллель:

• В задаче разработки ПО всем изначально было понятно, что есть процесс работы над инцидентом и есть процесс доработки программы. Процессы это связанные, но не тождественные.
• В то же время в процессе ЭКО диагностика и принятие решения о выборе лечения, с одной стороны, и собственно ЭКО, как один из вариантов лечения, с другой, в исходной версии не были разделены. А ведь здесь полностью аналогичная картина: обращение за помощью в медицинский центр соответствует инциденту, а лечение – внесению изменения в программный код. (Это к вопросу о том, что полезнее – паттерны или шаблоны.)

Результаты выложены (ну или будут выложены в ближайшие дни) на BPMN-форуме. Если что-то непонятно – не стесняйтесь, задавайте вопросы авторам.

Кстати, теперь ссылки на последние комментарии BPMN-форума выводятся на панель справа на каждой странице сайта тренинга.

• Александр Зверев
• Александр Гундоров
• Андрей Урин
• Иван Ксенофонтов
• Николай Степин
• Михаил Кириллов

Михаил Кириллов установил рекорд: 25 баллов (из 30 возможных)!

Для второго тренинга были выбраны следующие бизнес-процессы:

1. Изготовление памятника
2. Обновления вебсайта
3. Ремонт сетевого оборудования
4. Согласование договора

Обсуждение процесса «Ремонт сетевого оборудования» уже началось на linkedin, остальным тоже предлагаю включаться.

Уважаемые слушатели!

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

Начнем с первого процесса. Первоначально он назывался «Обновление релизов», но в итоге был переосмыслен как «Внедрение обновления учетной системы».

Исходная постановка задачи:

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

Схема процесса в первом, эскизном приближении:

Процесс «Обновление релизов»

Проблемы этой диаграммы:

1. Чрезмерная сложность. Впрочем, для начальной стадии разработки это нормально: структура процесса – понимание того, как надо процесс разбивать на подпроцессы – обычно приходит только после того, как попытка разместить все шаги процесса на одном уровне приводит к «спагетти» типа изображенного выше.
2. Автор перемудрил с сообщениями и циклами по объектам. Непонятно, как сообщения о завершении тестирования РСС найдут «свои» потоки в циклах по объектам, которые их дожидаются. Это распространенная ошибка, а правильное решение – выполнять всю работу, которую автор вынес в отдельный пул, в рамках подпроцесса внутри цикла по объектам.
3. В данной задаче не имеет смысла объединять в один процесс тестирование РСС и фиксацию релиза – это приводит к лишнему усложнению. Если рассматривать их как два независимых подпроцесса, то мы избавимся от необходимости синхронизации при помощи сообщений при переходе от тестирования к фиксации – заметное упрощение.
4. Можно придраться и к постановке задачи: в ней не учитывается различие между релизом и билдом. Согласно схеме, если обнаруживается ошибка, процесс завершается, т.е. предполагается, что после того, как разработчики ее исправят, мы запустим новый экземпляр процесса. В жизни обычно все происходит иначе: после исправления ошибки разработчики выпускают новый билд, но все же работа продолжается над тем же самом релизом с той же самой запланированной функциональностью. В итоге, после энного числа билдов, релиз доводится до работоспособного состояния и внедряется. С точки зрения бизнеса нам было бы интересно знать суммарное время, потраченное на внедрение релиза. Более правильной была бы схема, в которой обнаружение ошибки приводит к завершению не процесса, в всего лишь очередной итерации цикла.

Опуская все поиски и промежуточные версии – в итоге группа пришла к следующей структуре процесса на верхнем уровне:

Процесс «Внедрение обновления учетной системы»

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

Подпроцессы «Тестирование ЦСС» и «Управление тестированием РСС» могут закончиться либо успехом, либо выявлением ошибки. Мы могли бы проверить результаты этих подпроцессов при помощи развилок «или-или» после завершения первого и второго подпроцесса, но предпочли более изящные способ – прикрепленное событие «ошибка». В случае неудачи тестирования на любом этапе мы сообщаем разработчику по электронной почте, что мы ждем от него новый билд с исправленными ошибками, и идем на новый круг тестирования.

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

Подпроцесс «Тестирование ЦСС»

В группе оказалась представительница компании-разработчика ПО, которая подняла интересный вопрос: почему тестирование завершается после обнаружения первой же ошибки? Обсуждение выявило разницу в подходах к тестированию между разработчиком (альфа-тестирование) и заказчиком (бета-тестирование). Разработчики имеют дело с достаточно «сырым» софтом, поэтому они пытаются найти максимум ошибок в каждом билде. Заказчик же рассчитывает получить версию уже протестированную – с минимумом ошибок или вообще без них. Поэтому заказчик предпочитает не искать еще одну ошибку, которой в софте с большой вероятностью может и не быть, а, не теряя времени, запросить новый билд.

Тестирование РСС – подпроцесс более сложный: в нем надо предусмотреть таймер, который будет ограничивать время тестирования (5 дней) и прерывать все потоки тестирования, когда время истекло или один из процессов выявил ошибку. В общем случае это делается при помощи сообщений, транзакций и компенсаций. Но в данной задаче дело сильно упрощается благодаря тому, что в работе никогда не бывает одновременно больше одного релиза. Это позволяет использовать для коммуникаций сигналы и обойтись одним пулом.

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

В данном же случае все процессы тестирования РСС запускаются по отмашке «дирижера» – подпроцесса «Управление тестированием РСС»:

Подпроцесс «Управление тестированием РСС»

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

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

Подпроцесс «Тестирование РСС»

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

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

• Просто завершить процесс – негуманно. Представьте себе, что вы выполняете задачу, скажем, «Тестировать функционал». Вы ее выполнили, нажали на кнопку, и тут портал BPMS сообщает вам, что задача, которую вы пытаетесь завершить, больше не существует. (Именно это произойдет, если пока вы работали над задачей, истекло время или в другом потоке тестирования была выявлена ошибка.) Мягко говоря, пользователь будет в недоумении.
• Информировать пользователя по email, что подпроцесс прерван аналогично тому, как мы информируем разработчика – тоже плохо, ведь он в данный момент работает не с почтой, а BPM-порталом. Если взамен прерванной он тут же получит задачу «Истекло время теста РСС», это будет более понятно.
• Но тут возникает другая проблема: а что, если он вообще думать забыл о тестировании? Пока он не войдет в портал и не кликнет по заданию, подпроцесс будет оставаться активным. Чтобы от этого застраховаться, мы поставили на информирование таймер в 1 час.

С отправкой и обработкой сигнала «тест РСС не прошел», надеюсь, все ясно.

Итак, в итоге мы получили четыре диаграммы вместо одной. Но посмотрите, насколько прозрачной стала логика! Число шагов на одной диаграмме близко к оптимальному: от 6 до 9 (не считая подпроцесса «Управление тестированием РСС», где их всего два), никаких проблем с дальнейшими усовершенствованием процесса нет.

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

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

На первый взгляд процесс выглядел просто:

1. Рассмотреть заявку на доработку
2. Запланировать доработку
3. Выполнить доработку
4. Внедрить доработку

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

Процесс «Доработка учетной системы»

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

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

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

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

И последнее замечание относительно объекта данных, обозначенного на схеме как «БД заявок на доработку»: при использовании BizAgi BPMS ее даже не придется специально создавать. В этой системе реализовано очень удачное решение: каждому процессу соответствует определенная таблица в БД, и для каждого нового экземпляра процесса система автоматически создает новую запись в этой таблице. Нетрудно заметить, что «БД доработок» – это и есть процессная таблица бизнес-процесса «Заявка на доработку учетной системы».

Вообще же все схемы, разработанные на этом тренинге, готовы к исполнению BPMS. Правда не каждой BPMS, поскольку не каждая BPMS поддерживает сообщения и сигналы. (А по правде говоря, таких BPMS на удивление мало.) Но в BizAgi BPMS все схемы будут работать. Но это уже тема для следующего тренинга «BPM103: Исполняемый BPMN».

Спасибо тем, кто нашел время оставить отзыв – от себя и от тех, кто планирует посещение тренингов. Намекаю: оставшимся тоже не поздно это сделать.

Главный результат тренинга – отчетливо видимый прогресс в понимании предмета после прохождения тренинга. Целый ряд аспектов BPMN, казалось бы уже усвоенных в теории, потребовал тщательного разбора применительно к практическим задачам, в частности:

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

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

Новыми на этом тренинге были вопросы пограничные между BPMN и процессным анализом:

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

Основной результат с точки зрения тренера – форма тренинга полностью себя оправдала:

• Работа над проектами в группами по двое-трое (по трое мне показалось оптимальным вариантом). Единственно, на будущих тренингах не надо пытаться рисовать всем одновременно. Должно быть так: один рисует, остальные подсказывают (а-ля экстремальное программирование). Ролями можно и нужно периодически меняться, но в каждый момент времени мышь должна быть в руках только у одного члена команды. Собственно так оно и задумывалась, но я не довел эту установку до аудитории. К слову: мышь обязательна! Рисовать тачпадом получается слишком медленно.
• Обсуждение проектов между группами было очень интересным и полезным. Каждая группа совершала свои собственные ошибки и сталкивалась со своими собственными затруднениями, а уроки извлекали все! Интересно, что два проекта оказались взаимодополняющими: одна группа работала над процессом «от заказа до оплаты», оставив (намеренно) без его часть под названием «заключение договора». А другая работала над согласованием и заключением договоров, и процесс, надо которыми работали коллеги, помог им понять как их процесс должен взаимодействовать с окружающим миром.

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

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

Поделюсь некоторыми итогами тестирования.

1. Первое и самое главное. Как я и рассчитывал, тестирование оказалось важной частью процесса обучения. Тема BPMN коварна: прослушал лекцию и сложилось впечатление, что все просто и понятно. Тестирование разрушает эту иллюзию. Особенно ценен оказался (и это выпускники отметили в своих отзывах) «разбор полетов» после тестирования. Вопросы, на которые ты ответил неправильно, в итоге дают больше для понимания предмета, чем те, на которые ответил правильно! Тесты, как мне кажется, получились достаточно интересными, заставляющими задуматься.
2. Но к сожалению, не обошлось без накладок: некоторые формулировки вопросов оказались неоднозначны, кое-где можно поспорить по вариантам ответов. Не обошлось без опечаток. Некоторых сбило с толку то, что тесты напечатаны на двух сторонах листа – надо внизу первой странице дать примечание «продолжение теста на обороте». Спасибо за критику, отшлифую.
3. Регламент оказался слишком жестким: все тесты по 15 минут, первый 10 вопросов, второй и третий – по 5. Времени явно не хватало. На будущее увеличил продолжительность первого теста до 30 минут, второго и третьего – до 20. Чтобы как-то компенсировать, пришлось сократить время обеда с часа до 45 минут.
4. Итоговые оценки считались следующим образом: каждая задача первого теста оценивалась в один балл, второго и третьего – в два балла. Таким образом, теоретический максимум для каждого теста – 10 баллов, сумма для всех тестов – 30 баллов. При этом за частично решенную задачу я ставил 0.25, 0.5 или 0.75 балла. Фактические результаты легли в диапазон от 13.75 до 26.25:
   
5. Пять человек набрали больше 20 баллов и заработали сертификаты с отличием:
   • Щербаков
   • Федоров
   • Курышев
   • Меньшова
   • Кастанова

   Поздравляем!

Не забываем оставлять отзывы и готовиться к следующему тренингу.

Напоминаю какие процессы мы с вами определили для тренинга 14.11.10:

1. Управление инцидентами
2. От заказа до оплаты (дистрибуция)
3. Бюджетирование
4. Управление договорной деятельностью