Опубликовано: 24.09.2026 | Источник: CNews (новости)

Процессная аналитика в дипломе: цифровой двойник процесса и измеримая эффективность

Семантический анализ материала (перед чтением)

24 марта в Москве прошла конференция ProcessTech, целиком посвящённая процессной аналитике и управлению эффективностью бизнеса. Главный сюжет дня простой: компании перестали мерить эффективность «по ощущениям» и перешли к восстановлению реальных маршрутов работы из цифровых следов — журналов событий информационных систем. Из этих следов строится цифровой двойник процесса, а дальше уже считаются отклонения от регламента, узкие места, стоимость лишних шагов.

Для выпускника ИТ-направления это подарок. Тема ВКР, построенная на процессной аналитике, автоматически получает измеримую метрику, обоснование выбора стека и наглядную защиту: комиссия видит не абстрактную «оптимизацию», а конкретный процесс, который стал короче и дешевле. Ниже — как превратить сюжет конференции в рабочую структуру диплома.

Три темы ВКР, которые вырастают прямо из кейсов конференции

Тема 1. Цифровой двойник бизнес-процесса на основе журнала событий

• Актуальность. Доклады ProcessTech показали переход от статичных BPMN-схем «как задумано» к моделям «как происходит на самом деле». Регламент устаревает быстрее, чем его успевают согласовать.
• Цель. Разработать программный модуль восстановления фактической модели процесса из event log и расчёта отклонений от эталонной BPMN 2.0-схемы.
• Задачи. Проанализировать форматы журналов (XES, CSV, выгрузки из БД); спроектировать архитектуру загрузчика и хранилища событий; реализовать алгоритм построения графа процесса и метрик (частота переходов, время цикла, коэффициент повторной работы); провести эксперимент на реальном или синтетическом наборе данных.
• Структура. Глава 1 — теория process mining и стандарт ISO/IEC 25010 в части метрик качества; Глава 2 — проектирование по ГОСТ 34.602-89, схема архитектуры, диаграммы классов и последовательностей; Глава 3 — нагрузочное тестирование, расчёт эффекта от устранения узких мест.

Тема 2. Платформа мониторинга эффективности процессов с интеграцией OpenTelemetry

• Актуальность. На конференции много говорили о «живой» аналитике: метрики нужны в момент выполнения процесса, а не через месяц в отчёте. Это ровно та ниша, где observability-стек встречается с BPM.
• Цель. Собрать конвейер сбора трассировок и метрик из микросервисов и преобразования их в панель KPI процессов.
• Задачи. Настроить инструментирование сервисов; определить словарь метрик; спроектировать хранилище временных рядов; построить дашборд с RTO/RPO-контролем; оценить накладные расходы на сбор данных.
• Структура. Глава 1 — обзор observability и процессной аналитики, сравнение подходов; Глава 2 — архитектура сбора и хранения, схема развёртывания в Kubernetes; Глава 3 — замеры производительности до и после внедрения, экономическое обоснование.

Тема 3. Автоматизация рутинных операций на основе анализа цифровых следов

• Актуальность. Кейсы ProcessTech прямо подводят к связке «аналитика → роботизация»: сначала находим повторяющийся шаг, потом отдаём его роботу.
• Цель. Разработать методику выявления кандидатов на автоматизацию и прототип обработчика для одного сценария.
• Задачи. Сформулировать критерии отбора шагов; реализовать парсер журнала событий; построить прототип RPA-сценария; посчитать трудозатраты до и после.
• Структура. Глава 1 — анализ предметной области и существующих RPA-платформ; Глава 2 — проектирование методики и прототипа; Глава 3 — тестирование, расчёт экономии человеко-часов.

Аналитическая глава: чем обосновывать выбор решений

Первая глава — то место, где комиссия ловит на небрежности чаще всего. Сравнение инструментов должно опираться на критерии, а не на личные симпатии. Возьмите за основу перечень из докладов ProcessTech и добавьте технические ограничения вашего проекта.

Отдельным подпунктом стоит оформить требования к системе по ГОСТ 34.602-89: назначение, состав функций, требования к надёжности и к видам обеспечения. Это добавляет работе инженерного веса и снимает половину вопросов на защите.

Проектная часть: от схемы до кода

Архитектура и интеграция

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

Если защищаете тему по автоматизации, добавьте в схему оркестратор и объясните, почему выбрали именно его. Диаграммы делайте в единой нотации: BPMN 2.0 для процессов, UML для классов и последовательностей. Смешение нотаций без пояснений — классическая придирка рецензента.

# упрощённый конвейер обработки журнала событий
events = load_xes("orders.xes")          # загрузка цифровых следов
df = pm4py.convert_to_dataframe(events)  # нормализация
df["duration"] = df["time:timestamp"].diff()
kpi = df.groupby("case:concept:name")["duration"].sum()
model = pm4py.discover_heuristics_miner(events)  # фактическая модель
pm4py.view_heuristics_net(model)                 # визуализация отклонений

Обработка данных и логика расчётов

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

Тестирование и метрики: где живёт защищаемость

Именно этот раздел отличает работу на «отлично» от работы «сделал и работает». Покажите числа.

• Функциональное тестирование — таблица тест-кейсов с входными данными и ожидаемым результатом, покрытие ключевых сценариев.
• Нагрузочное тестирование — сколько событий в секунду выдерживает конвейер, как растёт потребление памяти, при какой нагрузке деградирует время отклика API.
• Отказоустойчивость — заявленные RTO и RPO, сценарии восстановления после падения узла, поведение очереди при недоступности хранилища.
• Качество данных — соответствие требованиям ISO/IEC 25010 по полноте, точности и согласованности входных журналов.

Результаты сведите в таблицу «до/после»: время выполнения процесса, количество ручных операций, стоимость часа работы. Даже скромное улучшение на 12–15% выглядит убедительно, если подкреплено методикой замера.

Чему вы научитесь, пока пишете эту работу

• Читать отраслевую повестку и переводить её в техническое задание.
• Обосновывать стек через критерии, а не через «мне так удобнее».
• Строить архитектуру обмена данными между разнородными системами.
• Работать со стандартами оформления ГОСТ 34 и 19, а не только с шаблоном кафедры.
• Считать метрики эффективности и защищать их перед комиссией.
• Оформлять технические диаграммы так, чтобы они читались без пояснений автора.

Частые вопросы выпускников

Обязательно ли писать код в такой ВКР?

Не обязательно, но крайне желательно. Если работа чисто аналитическая, компенсируйте отсутствие кода глубиной методики: формализованные критерии, расчёты, проверяемые на открытых данных. Однако прототип на 300–500 строк резко повышает защищаемость.

Где брать тестовые журналы событий?

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

Как оформлять UML- и BPMN-диаграммы?

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

Можно ли ссылаться на отраслевую конференцию как на источник?

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

Источник: Новая логика эффективности: какие кейсы представили на конференции по процессной аналитике ProcessTech (опубликовано 2026-03-25)