🦒
System Analyst | Knowledge base
  • Введение
  • Soft skills
    • 📍Продукт
      • Роли в IT продукте
        • Системный аналитик (SA)
        • Бизнес-аналитик (BA)
        • SA vs BA
        • 📎Другие аналитики
      • Жизненный цикл продукта
      • Методологии разработки
        • Waterfall
        • Agile
          • Scrum
          • Kanban
      • 📎Целеполагание
        • SMART
        • Матрица Эйзенхауэра
        • RICE
        • 🔒HADI
    • 📍Требования
      • Классификация требований
        • Уровень: Бизнес
        • Уровень: Пользователь
          • Use case
          • User story
          • 📎Job story
        • Уровень: Продукт
          • Функциональные требования
          • Нефункциональные требования
      • Качества требований
      • Методы сбора требований
      • Техническое задание (ТЗ)
  • Hard skills
    • 📍Базы данных
      • Реляционные
        • Транзакции
          • 🔒CAP
        • Нормальные формы
        • SQL
          • DML
          • DDL/DCL/TCL
          • 📎Представления VIEW
        • Констрейты
        • 📎Типы данных
        • 🔒Middle+
          • Особенности работы с конкертными реляционными БД
      • Нереляционные
        • Примеры использования
        • 🔒Middle+
          • Колоночные
            • Сlickhouse
          • Ключ-значение
          • Матричные
          • Документо-ориентированные
          • Графовые
            • JanusGraph | Neo4j etc
      • Масштабирование БД
      • Оптимизация БД
        • 📎Типы индексов
        • 📎Уникальные индексы
        • 🔒Анатомия плана запроса
      • 📎Какую СУБД выбрать
      • 📎Хранение и анализ данных
        • ETL
        • DWH
          • DWH vs Data Lake vs Data Mart
        • OLAP
          • OLAP vs OLTP
        • BI-аналитика
    • 📍Интеграции
      • Форматы данных
        • JSON + JSON Schema
          • 🔒AVRO
        • JSON vs XML
      • Виды интеграций
        • Синхронное взаимодействие
          • REST
            • RESTful принципы
              • Отсутствие состояния (Авторизация)
                • 🔒OAuth / OpenID Connect
              • Кеширование
              • Единообразие интерфейса (CRUD)
                • Запрос/ответ
              • 🔒Cтепень зрелости REST API
            • Проектирование API
            • 📎Асинхронный REST
          • SOAP
            • XSD
            • WSDL
          • REST vs SOAP
        • Асинхронное взаимодействие
          • Kafka
          • RabbitMQ
          • Kafka vs RabbitMQ
          • ESB
          • gRPC
            • Правила proto-контракта
            • Protobuf vs JSON
            • Сравнительная таблица
          • Другое
          • 🔒WebSocket API
        • Sync vs Async
      • 🔒Middle+
        • Stateful vs Stateless
        • Apache Flink
        • оркестрация и хореография
    • 📍Проектирование
      • Архитектура
        • Монолит
        • Микросервисы
          • Паттерны реализации
        • Монолит vs Микросервисы
        • 🔒Middle+
          • Бессерверная
          • Сервис-ориентированная (SOA)
          • Другое
      • Нотации и диаграммы
        • UML
          • Диаграмма классов
          • Диаграмма последовательности
            • Фреймы
          • Диаграмма прецедентов (use case)
          • 🔒Middle+
            • Диаграмма деятельности/активности
            • Диаграмма состояний
        • BPMN
          • Основные элементы
        • BPMN vs UML
        • ERD
        • 📎IDEF0
      • Прототипирование
        • Figma vs Axure
      • Мониторинг
        • Логирование
        • Метрики
        • Алерты
        • 🔒Инструменты
          • Grafana
          • Prometheus
          • ELK
            • Elasticsearch
            • Logstash
            • Kibana
      • 🔐Системный дизайн
    • 📎DevOps for SA
      • Основы сетей
        • OSI
        • TCP/IP
        • HTTP
        • DNS
      • Git (VCS)
        • GitHub vs GitLab
      • Развертывание приложений
        • CI/CD
        • 🔒Middle+
          • Виртуализация/контеризация
            • ✍️Docker
            • Kubernetes
              • ✍️Openshift
      • Cloud Native
        • Сервисы облачных вычислений
        • Cloud-native app vs Traditional app
      • Командная строка
    • 📎QA for SA
      • Postman | Insomnia
      • Swagger
      • Верификация vs Валидация
      • Идентификация/Аутентификация/Авторизация
    • 📎PM for SA
      • Метрики
        • Метрики привлечения
        • Метрики вовлечённости
          • ARPU
          • LTV
          • NPV
          • ROI
          • NPS
      • Прокси метрики
      • Дерево метрик
      • Фреймворки
      • Юнит-экономика
      • Модель Кано
  • Другое
    • Литература
    • Советы по составлению резюме
    • Общие вопросы на собеседовании
    • Вопросы которые надо задать интервьюеру
  • Контакты
Powered by GitBook
On this page
  • Преимущества
  • Недостатки
  • Как использовать нотацию BPMN
  • Как построить модель бизнес-процесса в нотации BPMN
  • Примеры инструментов

Was this helpful?

  1. Hard skills
  2. Проектирование
  3. Нотации и диаграммы

BPMN

BPMN — аббревиатура от Business Process Model and Notation. Это система условных обозначений и их описания для моделирования бизнес-процессов.

BPMN — одна из самых популярных нотаций для изображения бизнес-процессов в виде схем. Она широко применяется в России и за рубежом.

Первая версия BPMN создана в 2004 году рабочей группой IBM. В 2010 году — дополнена и выпущена под названием BPMN 2.0. В неё добавили новые типы событий и диаграмм, устранили ошибки первой версии.

Преимущества

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

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

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

  • Интеграция. BPMN может быть интегрирован с другими системами, такими как UML и ERP, что позволяет создавать комплексные модели бизнес-процессов.

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

Недостатки

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

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

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

Как использовать нотацию BPMN

Задачи системного-аналитика, для которых требуется BPMN, делят на два этапа:

  • Построение схем «как есть» (as is) — описание текущей последовательности работ бизнес-процесса.

  • Построение схем «как будет» (to be) — описание целевого процесса с фиксацией требуемых изменений: этапов модернизации, автоматизации.

Как построить модель бизнес-процесса в нотации BPMN

Вот пошаговый план того, как построить бизнес-процессы в нотации BPMN:

  1. Изучите процесс: для чего он нужен и какие задачи решает.

  2. Определите, является он основным, вспомогательным или процессом управления.

    • Основной процесс — приносящий прибыль или влияющий на прибыль компании. Например, производство или продажи. Таким процессам нужно уделять особое внимание.

    • Вспомогательный процесс — процесс, который не генерирует доход, но обеспечивает качественное выполнение основных процессов. Например, бухгалтерский учёт.

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

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

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

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

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

Примеры инструментов

  • Camunda

Источники:

PreviousДиаграмма состоянийNextОсновные элементы

Last updated 1 year ago

Was this helpful?

Draw.io ()

📍
https://app.diagrams.net/
https://demo.bpmn.io/
https://skillbox.ru/media/management/notatsiya-bpmn-chto-eto-takoe-i-kak-eye-ispolzuyut-v-biznesanalize/
https://investim.guru/stati/bpmn-i-uml-razlichiya-i-sravnenie