В конце марта 2026 года Росгосстрах рассказал о применении платформы Proceset для аналитики бизнес-операций: компания ищет узкие места в операционной деятельности не «по рассказам сотрудников», а по цифровым следам — журналам событий, действиям в интерфейсах, времени выполнения шагов. Для ИТ-специальностей это сигнал прикладного характера: на защитах всё чаще спрашивают не «какой фреймворк вы использовали», а «на каких данных вы это утверждаете и как измерили эффект». Task Mining и Process Mining дают как раз такой измеримый аппарат — и одновременно готовый каркас для дипломной работы, где есть и анализ, и проектирование, и численные результаты.
Ниже — разбор того, как этот кейс превращается в главы ВКР: что писать в аналитической части, что проектировать, чем мерить и какие грабли чаще всего ловят студенты на предзащите.
Статья о Росгосстрахе хороша тем, что описывает конкретный класс задач: поиск точек потерь в операционных процессах страховщика (обработка обращений, проверка документов, согласования). В первой главе диплома это превращается в обоснование выбора метода, а не в пересказ пресс-релиза. Ключевой шаг — развести три близких понятия, которые студенты постоянно смешивают.
| Подход | Источник данных | Что показывает | Где уместен в ВКР |
|---|---|---|---|
| Process Mining | Логи информационных систем (ERP, BPM, CRM), формат XES | Фактический маршрут процесса, отклонения от модели, «переработки» | Глава 1 — анализ «как есть», проверка соответствия регламенту |
| Task Mining | Телеметрия рабочих станций: окна, клики, горячие клавиши | Ручные операции внутри шага, кандидаты на автоматизацию | Глава 2 — обоснование участков для роботизации |
| RPA | Не данные, а сценарий автоматизации | Исполнение рутинных действий вместо человека | Глава 3 — внедрение и оценка эффекта |
Отсюда естественно вытекает обоснование стека: если в вашем проекте данные — это журналы веб-приложения, то ближе Process Mining с выгрузкой в XES; если предметная область — работа оператора в десктопных формах, то Task Mining. Ссылка на кейс Росгосстраха здесь работает как отраслевое подтверждение: подход применяется не в лаборатории, а в операционной деятельности крупного страховщика.
Вторая глава — место, где диплом перестаёт быть рефератом. Минимальный рабочий набор артефактов: модель процесса «как есть» в BPMN 2.0, модель «как должно быть», спецификация журнала событий и схема интеграции сбора данных.
Формально это контракт между источником данных и аналитикой. В приложении к ВКР достаточно таблицы полей плюс примера записи:
case_id | activity | timestamp | resource | channel
--------+-----------------+---------------------+----------+---------
CL-1042 | Заявка_создана | 2026-02-11 09:14:02 | operator | web
CL-1042 | Документ_проверен| 2026-02-11 09:41:37 | operator | web
CL-1042 | Согласование | 2026-02-12 10:02:11 | manager | crm
Если вы собираете телеметрию собственного приложения, уместно сослаться на OpenTelemetry и трассировку спанов: тогда «Task Mining» перестаёт быть абстракцией, а метрики шагов появляются из инструментария, а не из ручного хронометража.
Самая частая слабость дипломных проектов — отсутствие базы сравнения. Планируйте измерения до внедрения и после, а в тексте держите таблицу метрик с указанием источника данных и периода замеров. Опирайтесь на требования ГОСТ 34.602-89 к составу технического задания: там же фиксируются критерии эффективности и требования к точности.
| Метрика | Формула / способ сбора | Куда в ВКР |
|---|---|---|
| Среднее время цикла дела | Разность timestamp начала и завершения case_id | Глава 3, раздел «Оценка эффективности» |
| Доля ручных операций | События без автоматизированного исполнителя / все события | Глава 2, обоснование RPA |
| Стоимость обработки одной заявки | (Часы × ставка) / число заявок | Экономический раздел, расчёт окупаемости |
| P95 времени ответа API сбора событий | Нагрузочный тест, Grafana / Prometheus | Раздел «Тестирование» |
| RTO / RPO хранилища журналов | Сценарий отказа узла, время восстановления | Раздел «Надёжность» |
Нагрузочное тестирование конвейера сбора событий обязательно: если ваша система не выдерживает поток телеметрии, никакая аналитика не поедет. Достаточно 2–3 сценариев нагрузки и график деградации пропускной способности.
Актуальность: по статье, страховщик ищет узкие места в операционной деятельности на данных, а не на экспертных оценках — значит, нужен инструмент сбора и первичной агрегации событий.
Цель: разработать прототип, который собирает действия пользователя в веб-интерфейсе и строит отчёт о кандидатах на автоматизацию.
Задачи: обзор методов process/task mining; проектирование модели данных журнала событий; реализация сборщика и агрегатора; оценка на тестовом наборе, расчёт метрик.
Структура: Гл. 1 — анализ методов и инструментов, обоснование стека; Гл. 2 — архитектура сборщика, схема данных, диаграммы компонентов по UML; Гл. 3 — тестирование, метрики, оценка трудозатрат и эффекта.
Актуальность: кейс Росгосстраха показывает спрос на аудит процессов по цифровым следам; аналогичная задача воспроизводима на открытом стеке.
Цель: построить методику сравнения «как есть» и «как должно быть» и апробировать её на синтетическом или открытом журнале событий.
Задачи: формализовать метрики отклонений; реализовать конвейер обработки логов; визуализировать граф процесса; оценить достоверность при зашумлённых данных.
Структура: Гл. 1 — теория process mining и BPMN 2.0; Гл. 2 — алгоритм и архитектура конвейера; Гл. 3 — эксперименты, чувствительность к качеству данных, выводы.
Актуальность: связка «Task Mining → RPA» — прямое продолжение логики статьи: сначала найти ручное, потом автоматизировать.
Цель: спроектировать сценарий роботизации по данным о повторяющихся действиях и оценить экономию.
Задачи: разметка шагов процесса; выделение топ-N повторяемых операций; спецификация робота; расчёт TCO и окупаемости.
Структура: Гл. 1 — анализ рынка решений; Гл. 2 — проектирование сценария, диаграммы активности, интеграция с CRM; Гл. 3 — пилот, метрики, риск-анализ, экономика внедрения.
1. Терминологическая путаница. Process Mining и Task Mining объявляются синонимами, а RPA — «тем же самым, только кодом». На защите это ловят сразу. Лечение: таблица разграничения понятий в первой главе и единый глоссарий.
2. Нет базы сравнения. «Стало быстрее» без чисел, без периода замеров и без выборки. Лечение: план измерений на 2 недели данных, таблица метрик с формулами, честное указание ограничений эксперимента.
3. ТЗ «на салфетке». Игнорирование требований ГОСТ 34.602-89 при оформлении технического задания на систему — частая причина замечаний нормоконтроля. Лечение: типовой раздел ТЗ как приложение, критерии эффективности — в явном виде.
Нет, но нужен артефакт, который можно проверить. Варианты: прототип сборщика событий, конвейер обработки готового журнала (XES/CSV) или воспроизводимый эксперимент с расчётами. Чистая теория без апробации на данных сильно ослабляет защиту.
Три источника: открытые наборы журналов событий (в том числе учебные логи событий с сайта процесса), синтетический генератор с заданным числом отклонений, логи собственного учебного проекта. Валидация на синтетике с известной «истиной» — сильный аргумент в главе 3.
Достаточно диаграммы компонентов и диаграммы последовательности для ключевого сценария: поступление события → обогащение → запись → агрегация → отчёт. Плюс описание протоколов обмена (HTTP/REST или брокер сообщений) и модели отказа.
Средняя сложность. Трудоёмкая часть — подготовка данных и измерение метрик, а не программирование. Реалистичный план: 3–4 недели на аналитическую главу, 4–5 на прототип, 2–3 на эксперименты и оформление.
Если тема уже есть, а каркас глав пока «плывёт» — приходите на бесплатную консультацию: 120 часов работы над структурой, метриками и оформлением можно распределить так, чтобы успеть к сроку сдачи. Мы разбираем и техническую часть, и защиту — от постановки задач до репетиции доклада.
Источник: Росгосстрах применяет Proceset для анализа и оптимизации операционной деятельности (опубликовано 2026-03-30)