Рабочая ситуация
Служба обрабатывает заявки по регламенту, но сроки срываются, а объяснения участников расходятся. Есть журнал с идентификатором заявки, шагом и временем, таблица исполнителей и их квалификаций, а также регламент, который давно не совпадает с практикой.
Студент восстанавливает фактический процесс, находит шаги, где теряется время, задаёт ограничения и перераспределяет исполнителей. Затем сценарий вводит всплеск обращений и отсутствие одного специалиста: план нужно пересчитать, проверить допустимость назначений и сравнить очереди до и после изменений.
Рабочее место
- Редактор BPMN по логике Camunda Modelerпостроение и уточнение модели процесса.
- Журнал заявок и таблица ресурсовданные о шагах, времени, исполнителях и квалификациях.
- Диаграмма Ганта и расчёт очередейпроверка плана на фиксированном потоке заявок.
В первой версии не нужен полный process mining: достаточно журналов, одного ограниченного процесса и явной модели назначения исполнителей.
Как проходит работа
- Сопоставить регламент с журналом и восстановить фактический процесс.
- Найти шаги с наибольшим ожиданием и объяснить причины.
- Задать ограничения: квалификации, занятость, зависимости шагов.
- Перераспределить исполнителей и рассчитать очереди.
- Пересчитать план после всплеска и отсутствия специалиста; сравнить варианты.
ИИ-команда
- Руководитель службы заявокзнает организационные ограничения и то, какие компромиссы допустимы.
- Исполнители процессаобъясняют, почему шаги занимают больше времени, чем в регламенте.
- Аналитик данныхпомогает прочитать журнал и указывает на пробелы в данных.
Что проверяется
| Итоговый артефакт | Автоматическая проверка в заданных границах | Оценка преподавателя |
|---|---|---|
| Модель процесса, разбор ожиданий, ограничения и план ресурсов | Допустимость назначений, соблюдение зависимостей и расчёт очередей на фиксированном потоке | Правдоподобность причин задержки, организационные ограничения и выбор компромисса |
Связанные дисциплины
Тренажёр подходит для дисциплин по моделированию систем, методам оптимизации, теории принятия решений и анализу процессов.
Общая механика серии
- Рабочая ситуациясинтетические документы, данные, сроки и противоречия образуют конкретную задачу, а не свободную беседу.
- Ролевой мессенджерзаказчик, оператор, разработчик или эксплуатация располагают только сведениями своей роли; допустимые факты сценария заданы заранее.
- Первый результатстудент создаёт спецификацию, схему, код, модель или прототип, который можно сохранить и проверить.
- Изменение условийсценарный движок вводит новую версию контракта, ограничение, возмущение или новые данные; ИИ не придумывает эти события самостоятельно.
- Пересмотрстудент обновляет решение, повторяет проверки и объясняет, почему изменил или сохранил первоначальный подход.
- Безопасное исполнениепользовательский код и SQL запускаются только в изолированной среде; реальные секреты, персональные данные и производственные системы не нужны.
Ролевые ИИ-персонажи не получают скрытый ключ проверки и не выставляют итоговые баллы: вычисляемую часть результата проверяет программное ядро, открытое инженерное решение оценивает преподаватель по заранее известной рубрике.
Статус описания: Проектируется. На странице описан проектируемый тренажёр — целевой учебный сценарий, а не готовое приложение. Состав воспроизводимых сред, механика и критерии проверки согласуются с вузом; реализация и приёмка выполняются отдельно.
Названия и логотипы сторонних платформ обозначают учебные профили интерфейсов и операций и не означают поставку оригинальных продуктов, интеграцию с ними, партнёрство или одобрение правообладателей. Упоминание программ Топ-ИТ и «Приоритет-2030» обозначает область применения тренажёра, а не официальное включение в эти программы.
