Мастер-класс: BPMN и Stormbpmn (15 ноября, новый интерфейс)

• Приветствие участников и проверка связи.  

• Представление ведущего и его помощника Кости.  

• Объявление темы мастер-класса: основы BPM и их применение в сервисе Stormbi Payman.  

• Ведущий Костя начинает мастер-класс.  

• Участники делятся своими погодными условиями.  

• Костя предлагает начать с обсуждения принципов описания бизнес-процессов.  

• Обсуждение принципов описания бизнес-процессов в нотации BPMN.  

• Представление нового интерфейса Stormbi.  

• План мастер-класса: четыре блока, обсуждение процессов, уровней моделирования и важных терминов.  

• Определение процесса как совокупности повторяющихся видов деятельности.  

• Процесс должен создавать ценность для клиента.  

• Кроссфункциональная взаимосвязь процессов и их влияние на организационную структуру.  

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

• Важность схем для понимания процессов и выявления коллизий.  

• Применение моделей для автоматизации, роботизации и масштабирования бизнеса.  

• Модель должна быть в нотации BPMN.  

• Отражение ролей и систем на схеме.  

• Важность понимания документарного потока вокруг каждой активности.  

• Возможность добавления описания задач, не всегда помещающегося в квадратик.  

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

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

• Различие между процессом и моделью процесса.  

• Модель процесса предполагает наличие BPMN и последовательности действий.  

• Введение новой сущности "процесс" в Storm для учета и управления процессами.  

• Проект направлен на создание уникального продукта, процесс - на создание постоянного продукта.  

• Процессы должны стабильно выдавать хороший результат.  

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

• Три уровня представления моделей: корпоративный, аналитический и исполняемый.  

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

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

• Исполняемый уровень используется для разработки приложений и внедрения сложных систем.  

• BPMN-диаграмма - это Excel-файл, составленный по правилам.  

• BPM-движки могут преобразовывать BPMN-диаграммы в исполняемый код.  

• Использование BPMN для автоматизации бизнес-процессов требует проверки на ошибки.  

• Описательный уровень показывает руководству, как движется процесс.  

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

• Линейная структура с использованием активити и кол-активити.  

• Пул: бассейн, в котором живет процесс.  

• Активити: абстрактная задача, пользовательская задача, ручная задача, сервисная задача, подпроцесс вызов.  

• События: стартовые, завершающие, таймеры, условия, месседжи.  

• Месседжи: сообщения для взаимодействия между процессами.  

• Партисипанты: кол-активити, пулы, свернутые кол-активити.  

• Шлюзы: исключающая или, и, или.  

• Потоки: операций, сообщений, ассоциаций.  

• Стоит ли проектировать BPM для технической организации?  

• Описание процессов: для стандартизации или для договоренности.  

• Важность BPM в корпоративной жизни.  

• Пользовательская задача: коммуникация с сложной системой или оборудованием.  

• Ручная задача: взаимодействие с простым инструментом.  

• Задачи и операции: одно и то же в нотации BPMN.  

• Действия с разными ответственными лицами в одном пуле.  

• Первый уровень BPMN легко понимается.  

• Важность объяснения ценности и важности BPM.  

• Дорожки: не используются на первом уровне BPMN.  

• Аргументация против использования дорожек.  

• Обсуждение нового интерфейса New-Storm.  

• Возможность перехода между старым и новым интерфейсами.  

• Автоматическое отражение схем из старого интерфейса в новом.  

• Создание новой диаграммы в New-Storm.  

• Добавление тегов для фильтрации и поиска.  

• Сохранение и автоматическое сохранение диаграмм.  

• Создание процесса передачи сырья переработчику.  

• Проверка наличия свободного переработчика.  

• Формирование и передача заявки.  

• Транспортировка и приемка от подрядчика.  

• Изменение типа элемента для повторного использования.  

• Подготовка для упаковки.  

• Определение ролей для выполнения задач.  

• Создание новой роли "менеджер по производству".  

• Привязка системы для формирования и передачи заявки.  

• Переход к аналитическому уровню.  

• Описание всех исполнителей и экспертов, работающих с процессом.  

• Использование символов BPM для описания процессов.  

• Рекомендуется использовать следующий перечень символов.  

• События BPMN делятся на два блока: стартовые, завершающие и промежуточные.  

• На канале есть два ролика: краткий и детальный, с примерами и тайм-кодами.  

• Часто используемые символы не закрашены красным.  

• Эскалация, терминейт и компенсация используются реже из-за сложной семантики.  

• Подготовлен справочник с примерами по всем элементам BPMN.  

• Подпроцессы и признаки добавляются в BPMN.  

• Признаки включают параллельность и цикл.  

• Событийный подпроцесс описывает процедуру для неизвестных событий.  

• Поток по умолчанию используется для отображения хэппи паса.  

• Хранилище данных и объект данных используются для передачи данных внутри процесса.  

• Соглашение о моделировании BPMN помогает правильно использовать алфавит BPMN.  

• Инструменты управления пространством в BPMN.  

• Пример использования инструмента для раздвижения объектов внутри пула.  

• Анализ переработчиков и заключение договоров.  

• Книжный клуб BPMN для обсуждения лучших практик и стратегии.  

• Встречи проходят раз в месяц, с участием экспертов из крупных компаний.  

• Ссылка на регистрацию для участия в следующем выпуске.  

• BPMS используется архитекторами и разработчиками.  

• Различия между аналитическим и исполняемым уровнями.  

• Важность учета контекста и атрибутов системы.  

• Системы до второго уровня более-менее одинаковы.  

• Третий уровень требует адаптации под конкретную систему.  

• Важно учитывать особенности систем при моделировании.  

• Бизнес-процесс — это схема, отражающая все ветки и шлюзы.  

• Экземпляр — это исполнение одной из веток в реальном времени.  

• Важно учитывать все экземпляры для предотвращения ошибок.  

• Токин — это абстракция, показывающая поведение процесса.  

• Помогает анализировать логику процесса и избегать белых пятен.  

• Токин может рождаться, умирать, делиться и сливаться.  

• Формальное описание: формулировка операций от глагола.  

• Стилистическое описание: удобство чтения и модификации схем.  

• Логическое описание: правильность описанной схемы.  

• Важно определить продукты процесса перед описанием схемы.  

• Определение границ процесса влияет на его размерность и владельца.  

• Использование элементов BPMN, а не других нотаций.  

• Шторм автоматически определяет потоки управления и ассоциации.  

• Отсутствие брошенных элементов, таких как шлюзы без завершающего события.  

• Скоринг помогает выявлять ошибки и настраивать видимость диаграмм.  

• У процесса может быть только один владелец.  

• Владелец управляет процессом, изменяет и модифицирует его.  

• Рекомендуется использовать до 15 активити в одном процессе.  

• Превышение этого количества усложняет чтение схемы.  

• Всего рекомендуется использовать до 40 элементов, включая шлюзы, артефакты и эвенты.  

• Превышение рекомендаций не требует разрыва процессов.  

• Рекомендуется использовать свернутые процессы для улучшения читаемости.  

• Принципы выделения процессов и разграничения ответственности требуют отдельного обсуждения.  

• Не используйте неизвестные символы, если не знаете, как они работают.  

• Неизвестные символы усложняют чтение диаграммы.  

• Используйте элементы, которые знаете и понимают все пользователи.  

• Дорожки не рекомендуются для сжатия диаграммы.  

• Возвратные петли усложняют чтение схемы.  

• Дорожки могут раздувать схему и усложнять чтение.  

• У каждого потока должно быть свое завершающее событие.  

• Шлюзы должны быть семантически правильными.  

• Сводящие шлюзы не обозначаются, они просто для сведения потоков.  

• Задачи на клиента не могут быть частью процесса.  

• Для задач на клиента используется отдельный пул.  

• Клиент отображается как черный ящик.  

• Возможность коммуницировать с клиентом через активити или мессенджеры.  

• Неправильное использование нотации может привести к зависанию процесса.  

• Пример с магазином: продавец может уйти в кладовку, что приведет к зависанию процесса.  

• Логическое описание не используется для детализации технических действий.  

• Пример с заполнением договора: не нужно детализировать каждое поле.  

• Пользовательская задача "заполнить договор" используется для описания процесса.  

• Задачи "передать информацию" и "отправить данные" не ставятся.  

• Поток управления служит для передачи данных между активити.  

• Симуляция токинов позволяет наблюдать за процессом и его ходом.  

• Использование токинов для визуализации процесса.  

• Люди быстро привыкают к абстракции и начинают понимать процесс.  

• Демонстрация работы с токинами помогает в обучении.  

• Приглашение в телеграм-сообщество для общения и вопросов.  

• Напоминание о канале на YouTube для дополнительного контента.  

• Завершение трансляции и приглашение на курсы и в каналы.