Business_Studio_нотации_и_построение_моделей

1.

BUSINESS STUDIO: НОТАЦИИ BASIC FLOWCHART, CROSS-FUNCTIONAL FLOWCHART,
FLOWCHART, EPC И ПОСТРОЕНИЕ МОДЕЛЕЙ БИЗНЕС-ПРОЦЕССОВ
Лямцев Кирилл Игоревич
Доклад по дисциплине «Анализ и моделирование
бизнес-процессов»
Преподаватель: к.т.н., доц. Школина Т.В.
Брянск 2026

2.

Содержание
1.Business Studio: назначение и устройство модели
5.Cross-functional Flowchart: дорожки
исполнителей
2.Нотации и уровни модели
6.EPC: событийная цепочка процессов
3.Кейс: IT-компания «КодЛаб»
7.Сравнение нотаций и выбор
4.Basic Flowchart: алгоритм процесса
8.Построение модели: шаги, свойства, регламенты,
анализ
Сквозной пример — процесс «Исправление ошибки по обращению клиента». Один и тот же процесс показан во всех трёх
нотациях, чтобы было видно, чем они отличаются.
2

3.

Что такое Business Studio
Business Studio — российская система бизнес-моделирования, в которой деятельность компании
описывается как единая модель: цели, процессы, оргструктура, документы и ресурсы связаны
между собой.
Разработчик
Принцип
Результат
Группа компаний «Современные
технологии управления» (г. Самара)
Одна база данных (репозиторий) —
много диаграмм и отчётов на её
основе
Регламенты процессов, положения
о подразделениях и должностные
инструкции формируются
автоматически
Отличие от «рисовалок» (Visio, draw.io): фигура на схеме — не картинка, а объект базы со свойствами. Поэтому модель можно
проверять, анализировать и превращать в документы.
3

4.

Цикл управления в Business Studio
Проектирование
Внедрение
Контроль
Анализ
Цели и показатели,
процессная модель,
оргструктура
Регламенты, положения,
инструкции;
публикация модели для
сотрудников
Значения показателей
процессов и целей
Функциональностоимостной анализ,
имитационное
моделирование
↻ По итогам анализа модель меняют — и цикл повторяется
В этом докладе основное внимание — этапу проектирования: как описать процессы на диаграммах и связать их со
справочниками.
4

5.

Модель хранится в справочниках
Фигура на диаграмме — это ссылка на элемент справочника. Изменили элемент — он изменился на всех
диаграммах и во всех отчётах.
Справочник
Что хранит
Пример для «КодЛаб»
Процессы
Дерево процессов и их диаграммы
Сопровождение ПО → Исправление ошибки
Субъекты
Подразделения и должности
Отдел тестирования, Тестировщик
Объекты деятельности
Документы, информация, материалы
Обращение клиента, Отчёт о тестировании
Ресурсы
Ресурсы для расчёта стоимости и имитации
Рабочее время сотрудников, серверы
Цели и показатели
Стратегические цели и KPI процессов
Среднее время исправления ошибки
Интерфейс: слева — Навигатор (дерево справочников), в центре — графический редактор диаграмм, отдельно — окно свойств выбранного
элемента.
5

6.

Нотации Business Studio
Нотация
Уровень модели
Что показывает
IDEF0
Верхний
Состав функций и их связи: вход, выход, управление, механизм
VAD
Верхний
Цепочку процессов, создающих ценность для клиента
Basic Flowchart
(в BS — «Процесс»)
Нижний
Алгоритм: шаги, решения, начальное и конечное события
Cross-functional Flowchart
(в BS — «Процедура»)
Нижний
Тот же алгоритм + дорожки: кто выполняет каждый шаг
EPC
Нижний
Цепочку «событие → функция → событие» с логикой И / ИЛИ / XOR
BPMN 2.0
Нижний
Сложную логику; экспорт для исполнения в BPMS
■ Жёлтым выделены нотации, которые разбираем подробно. Все три относятся к классу workflow: описывают как выполняется
процесс, шаг за шагом.
6

7.

Уровни модели: от «что» к «как»
Уровень
Нотация и вопрос
Пример «КодЛаб»
Верхний
IDEF0 / VAD
Что делает компания?
А0 «Деятельность компании»: продажи,
разработка, внедрение, сопровождение
Средний
IDEF0 (декомпозиция)
Из чего состоит процесс?
А4 «Сопровождение ПО» → консультации,
исправление ошибок, обновления
Нижний
Basic Flowchart · Cross-functional · EPC · BPMN
Как выполняется шаг за шагом?
«Исправление ошибки по обращению клиента»
Декомпозиция: каждый процесс можно раскрыть дочерней диаграммой. Важное ограничение: функцию EPC раскрывают только
в EPC или BPMN.
7

8.

Кейс: IT-компания «Fixorix»
Компания разрабатывает веб-сервис и сопровождает его у клиентов.
Проблема (условная): обращения об ошибках теряются между
поддержкой и разработкой, непонятно, кто отвечает на каждом шаге,
клиент не знает статус.
Задача моделирования: описать процесс «Исправление ошибки по
обращению клиента», закрепить ответственных, получить регламент и
найти узкие места.
Участники процесса
1. Специалист поддержки
2. Тимлид
3. Разработчик
4. Тестировщик
5. DevOps-инженер
Сценарий: обращение → регистрация → «это ошибка?» → анализ → исправление → тестирование (с возвратом на доработку)
→ выпуск релиза → уведомление клиента.
8

9.

Шаг 1. Оргструктура — справочник «Субъекты»
■ подразделение
■ должность
Начинаем с субъектов: они понадобятся на
каждой диаграмме.
Должности станут дорожками в Crossfunctional и оргединицами в EPC.
По ним BS соберёт положения о
подразделениях и должностные
инструкции.
9

10.

Шаг 2. Верхний уровень — диаграмма А0 (IDEF0)
Стрелки IDEF0: слева — вход, справа — выход,
сверху — управление, снизу — механизм (кто и
чем).
А4 раскрываем дальше → «Исправление ошибки
по обращению клиента».
10

11.

Basic Flowchart: назначение и элементы
Basic Flowchart (в Business Studio — нотация
«Процесс») — блок-схема алгоритма: в каком порядке
выполняются шаги и где принимаются решения.
Когда применять
Простые процессы, где важен порядок действий, а
исполнители очевидны или указаны в свойствах шагов.
Любой шаг можно декомпозировать — раскрыть дочерней
диаграммой.
11

12.

Basic Flowchart: «Исправление ошибки по обращению»
Пунктир — поток
объектов; сплошная —
связь предшествования
12

13.

Basic Flowchart: правила и типичные ошибки
Правила
Типичные ошибки
✓ Процесс начинается инициирующим и заканчивается
завершающим событием; у каждой ветки — свой конец
✗ Промежуточные события отдельными фигурами — в
«Процессе» и «Процедуре» их нет, ломаются регламент и
имитация
✓ Шаги называют отглагольным существительным:
«Регистрация обращения»
✓ Решение — вопрос; все выходы подписаны
✓ Порядок — связью предшествования, документы —
потоком объектов
✗ Входы и выходы «висят в воздухе» — без источника или
получателя
✗ Документ привязан к стрелке предшествования
✗ Ветка решения обрывается без завершающего события
✓ Документы берутся из справочника, а не вписываются
текстом
13

14.

Cross-functional Flowchart: дорожки исполнителей
Cross-functional Flowchart (в Business Studio — нотация «Процедура») = все элементы Basic Flowchart + дорожки
(swimlanes). Каждая дорожка — субъект: подразделение или должность.
Дорожка = субъект
Выбирается из справочника «Субъекты»; ориентация —
горизонтальная или вертикальная
Шаг в дорожке
Субъект дорожки становится исполнителем шага — это попадёт в
регламент и инструкции
Переход между дорожками
Передача работы и ответственности — главная точка риска
задержек
14

15.

Cross-functional Flowchart: тот же процесс по дорожкам
15

16.

Что показала диаграмма с дорожками
5
5
1
участников (дорожек)
передач работы в основном сценарии
петля возврата на доработку
Каждая передача — риск, что задача
«зависнет». В регламент добавляем срок
реакции и документ передачи — задачу в
трекере.
Возвращаться из DevOps в поддержку
приходится вручную. Решение —
автоуведомление о выпуске релиза.
Петля «Тест → Разработка» — кандидат в
показатели: доля возвратов на доработку.
16

17.

EPC: событийная цепочка процессов
EPC (Event-driven Process Chain) — процесс как
цепочка: событие запускает функцию, функция
порождает новое событие.
Когда применять
Процессы со сложной логикой: параллельные ветки,
условия, много состояний объекта.
Нотация пришла из методологии ARIS. Вокруг функции
показывают исполнителей и документы.
17

18.

EPC: правила построения
1. Цепочка начинается и заканчивается событием.
2. События и функции чередуются: событие → функция → событие.
3. Событие пассивно и не принимает решений: после одного события нельзя
ветвление через ИЛИ / XOR.
4. Решение принимает функция: после неё оператор разводит поток на
события.
5. Ветки разводят и сводят только операторами, закрывая тем же
оператором.
6. В Business Studio функцию EPC раскрывают только в EPC или BPMN.
18

19.

EPC: фрагмент «Анализ → Исправление → Тестирование»
19

20.

Сравнение нотаций
Критерий
Basic Flowchart
Cross-functional
EPC
Главный вопрос
В каком порядке?
Кто и в каком порядке?
Что запускает действие и что
получается?
Исполнители
В свойствах шага, на схеме не видны
Дорожки
Оргединицы у функций
Ветвление
Решение (ромб)
Решение (ромб)
Операторы И / ИЛИ / XOR
События
Только начальное и конечное
Только начальное и конечное
После каждой функции
Лучше всего для
Простых линейных процессов
Регламентов и передачи работы
между отделами
Сложной логики и проверки полноты
Для «Fixorix»: регламент для сотрудников — в Cross-functional; разбор логики тестирования и состояний задачи — в EPC.
20

21.

Построение модели в Business Studio: 8 шагов
1
2
3
4
Создать базу и продумать
структуру справочников
Заполнить «Субъекты»:
подразделения и
должности
Заполнить «Объекты
деятельности»: документы
Построить верхний уровень
в IDEF0 или VAD
5
6
7
8
Декомпозировать процесс
и выбрать нотацию
нижнего уровня
Нарисовать диаграмму:
фигуры из панели, стрелки,
дорожки
Заполнить свойства:
владелец, исполнители,
входы, выходы, время
Сформировать регламент и
опубликовать модель
Главное правило: сначала справочники — потом диаграммы. Тогда на схемы ставятся готовые элементы, а не текст.
21

22.

Шаг 7. Свойства процесса
Карточка процесса «Исправление ошибки по обращению клиента» — то, что Business Studio затем выведет в регламент:
Свойство
Значение
Владелец процесса
Тимлид
Исполнители
Специалист поддержки, Разработчик, Тестировщик, DevOps-инженер (из дорожек)
Начало
Поступило обращение клиента
Результат
Ошибка устранена, клиент уведомлён
Входы / выходы
Обращение клиента → Исправленный релиз, уведомление клиенту
Показатели
Среднее время исправления; доля возвратов на доработку
Длительность шагов
[задаётся по данным компании] — нужна для ФСА и имитации
22

23.

Шаг 8. Документы формируются из модели
Регламент процесса
Положение о подразделении
Схема + таблица шагов: кто, что делает, вход, выход, срок
Функции отдела тестирования во всех процессах компании
Должностная инструкция
Публикация модели
Обязанности тестировщика, собранные из всех шагов, где он
исполнитель
Сотрудники открывают схемы и регламенты в браузере
Изменили диаграмму → переформировали отчёт. Документы всегда соответствуют модели, их не нужно
переписывать вручную.
23

24.

Анализ модели: ФСА и имитация
Функционально-стоимостной анализ
Имитационное моделирование
Задаём: ресурсы и время каждого шага
Задаём: частоту обращений, длительности, вероятности веток
(доля возвратов)
Получаем: стоимость процесса и каждого шага, долю затрат
по исполнителям
Получаем: время цикла, очереди, загрузку исполнителей
Вопрос для «Fixorix»: справится ли один тестировщик, если обращений станет вдвое больше? Имитация покажет, где
возникнет очередь — до запуска изменений в реальности.
Условие: шаги связаны связями предшествования, у веток решений заданы вероятности.
24

25.

Выводы
1. Business Studio хранит модель в справочниках: диаграммы, регламенты и инструкции строятся из одних и тех же
объектов.
2. Модель строится сверху вниз: верхний уровень — IDEF0 или VAD, нижний — Basic Flowchart, Cross-functional, EPC или
BPMN.
3. Basic Flowchart показывает порядок шагов, Cross-functional — ещё и исполнителей, EPC — события и логику переходов.
4. На кейсе «Fixorix» диаграмма с дорожками выявила 5 передач работы и петлю возврата — точки для сроков и
показателей.
5. Соблюдение правил нотаций — условие для корректных регламентов, ФСА и имитационного моделирования.
25

26.

BUSINESS STUDIO: НОТАЦИИ BASIC FLOWCHART, CROSS-FUNCTIONAL FLOWCHART,
FLOWCHART, EPC И ПОСТРОЕНИЕ МОДЕЛЕЙ БИЗНЕС-ПРОЦЕССОВ
Лямцев Кирилл Игоревич
Спасибо за внимание!
Брянск 2026