Содержание статьи

1. ИТ в настоящее время.

2. Знакомство с задачей № 3.

3. Предварительные результаты выполнения задачи № 3 участниками.

4. Модель, разработанная командой процессного аналитика.

5. Проведение анализа результата выполнения задачи № 3 участниками.

1. ИТ в настоящее время.

Развитие информационных технологий в настоящее время предоставляет возможности для создания ИТ-продуктов не только ИТ-специалистами, но и людям, которые таковыми не являются. Можно предположить, что конечный ИТ-продукт у ИТ-специалистов и у не ИТ-специалистов будет отличаться.

Чем же могут отличаться ИТ-продукты, созданные ИТ-специалистами, от ИТ-продуктов, созданных не ИТ-специалистов, и как последние могут это сделать?

Будучи процессным аналитиком и консультантом по управлению, решил не практике это проверить путем участия в хакатоне 2026, проводимом под эгидой Московского правительства. Наша команда состояла из двух человек: процессного аналитика и молодого специалиста, специализирующегося на машинном обучении.

Конечно, соревноваться в программировании с ИТ-специалистами никоим образом не собирались, так как мы обладаем знаниями в разных сферах. Однако возможность создать ИТ-продукт, по крайней мере прототип модели, возможно, если использовать потенциал какого-либо ИИ-агента, которые можно найти в интернете свободно и которые предоставляются бесплатно. Хочется заметить, что ИТ-специалисты также их используют, чтобы ускорить разработку ИТ-продукта.

2.  Знакомство с задачей № 3.

Итак, сначала из списка выбрали задачу № 3, которая называется «Интеллектуальный сервис планирования рабочих маршрутов для инженеров с учетом временных окон и сложности проводимых работ».

Так как данные, содержащиеся в ТЗ к задаче № 3, являются конфиденциальной информацией, то опубликовать их здесь не представляется возможным.

3. Предварительные результаты выполнения задачи № 3 участниками.

На момент написания статьи эксперты Заказчика отобрали 12 команд, которые прошли в финал, и уже из них они будут определять призеров. Общее количество команд, которые участвовали в этой задаче, неизвестно (по косвенным данным значительно более 70).

В чате, где участники обменивались мнениями по задаче № 3, появилась следующая интересная информация (см. https://nami.amik.am/app/bee-ltzp-2026/xdet70qha8q1dr5d/):

Работы участников задачи № 3: оценка четырёх моделей и финалисты жюри.

Работ — 72 открытых репозиториев с GitHub и SourceCraft.

Оценка — Claude Opus, Codex, Kimi K3 и Gemini 3.8 Flash, вслепую, по пяти критериям ТЗ.

Финалисты — список жюри от 15 октября 2026.

Здесь собраны открытые решения задачи «Интеллектуальный сервис планирования рабочих маршрутов для инженеров». Четыре модели прочитали код, README и презентации и оценили каждую работу по критериям ТЗ, не зная, чья она и кто прошёл в финал. Рейтинг моделей — не итог конкурса: жюри смотрело ещё живые прототипы, презентации и ответы команд.

Целью данной статьи не является оценка прототипов моделей, представленных командами (да это и невозможно, так как это закрытые данные), а хотелось бы сравнить по возможности (данных крайне мало) подход организатора, участников и получившийся результат.

Оценку проводили: Claude Opus, Codex, Kimi K3 и Gemini 3.8 Flash, вслепую, по пяти критериям ТЗ (см. Таблица 1):

Таблица 1 Критерии ТЗ

Как видно из представленных в Таблице 1 критериев, по которым осуществлялся рейтинг моделей, от наиболее соответствующих ТЗ и далее по нисходящей линии и здесь в первую очередь учитывались ИТ-решения команд. Это, конечно, важный фактор, но ведь работать с такой моделью предстоит диспетчеру, но насколько она удобна и информативна и помогает в его работе решать возложенные на него задачи оценка не проводится, так как такие критерии отсутствуют. Постановщика задач больше интересует пробег автомобилей и эффективность работы инженеров, что, конечно, нужно, но ведь разрабатываемый ИТ-продукт в первую очередь предназначен для диспетчера, а уже потом можно проводить анализ деятельности инженеров и оценка пробега.

Стек решений

Чем написаны 72 работы: язык, сервер, интерфейс, карта, решатель, расчёт дорог, хранение данных и запуск. Стек каждой работы — в её карточке.

Посмотрим, какие были выделены сильные стороны у некоторых моделей (см. Таблицу 2).

Таблица 2 Сильные стороны моделей.

Наша модель по указанным критериям заняла 40 место среди 72 команд, найденных в открытых репозиториях. Конечно, были отмечены и слабые стороны у всех моделей, а также было представлено много других технических данных, которые сравнивались между командами.

4. Модель, разработанная командой процессного аналитика.

Для того, чтобы получить работающую модель (прототип) – помощника диспетчера, который организует и контролирует работу выездных инженеров, были изучены все предоставленные Заказчиком данные, описаны процессы, где отражалась деятельность участников, их функционал и их взаимодействие в текстовом и визуальном виде. Очень важно отображать представляемую модель как в виде текста, так и виде схем, так как при этом происходит более полное понимание и осознание того, как это происходит сейчас, какое между участниками при этом складывается взаимодействие, какие информационные потоки образуются и как это может быть, если использовать возможности разрабатываемой программы.

Общую примерную схему формирования плана и выполнения работ участниками можно видеть на Рис. 1.

Алгоритмы работы диспетчера и выездных инженеров можно видеть на Рис. 2.

Всё описанное на Рис. 1 и Рис. 2 относится к операционной деятельности сотрудников. Обычно по практике это служит основой для разработки программ. Но бизнес-процесс, выполняемый участниками, состоит из двух процессов: операционный процесс и процесс управления.

Описание процесса управления при выполнении задачи «Выполнять заявки, поступающие от клиента» «как есть» и «как может быть» можно видеть на Рис. 3.

На Рис. 3 видно, что описание процессов управления выявляет весь функционал, выполняемый диспетчером и выездными инженерами, а также информационные потоки, которые при этом образуются. Это дает возможность определить, какой функционал диспетчера можно или даже нужно передать на исполнение программе (модели), с помощью чего это делается и как это можно улучшить. Полученная таким образом информация позволяет со всех сторон изучить материал, понять как должна работать модель «Помощник диспетчера» и что должно быть результатом ее работы, а также подготовить ТЗ (в текстовом формате) для разработки программы ИИ-агентом.

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

—  поступающих от клиентов заявок;

—  мест выполнения этих заявок (адресов клиентов);

—  необходимой квалификацией инженеров, выполняющих эти заявки;

—  потребностью в оборудовании;

—  времени выполнения и другое.

Посмотрим действующую имитационную модель «Помощник диспетчера».

На Рис. 4 показан полный рабочий экран диспетчера, где он может видеть в режиме реального времени все заявки, места их выполнения, кто выполняет заявки, маршруты выездных инженеров, достаточно ли ресурсов для их выполнения. В любой момент времени диспетчер знает, кто где находится и что делает, какие ресурсы еще требуются, чтобы выполнить план.

В начале рабочего дня на основании полученных от клиентов заявок формируется план и маршруты, на которых с заявками работают выездные инженера. В данном случае имеется 112 заявок и сформировано 14 маршрутов исходя из имеющихся в наличии выездных инженеров и автомобилей. При отсутствии автомобилей инженера могут добираться до клиентов наземным транспортом или пешком. Также при формировании маршрутов учитываются окна протяженностью 120 мин., во время которых клиенты готовы принять выездного инженера.

На Рис. 5 видна вся картина выполнения выездными инженерами заявок в режиме реального времени, т.е. как диспетчер наблюдает ход выполнения заявок инженерами в разное время. Красные точки означают, что к работе с данной заявкой еще не приступали, желтым цветом – что заявка находится в работе, а зеленым цветом – что заявка инженером выполнена. Также серым цветом отображаются заявки, которые переносятся на следующий день, а черным – что нет исполнителя, т.е. решение по данной заявке пока не принято.

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

На Рис. 6 видно, что во вкладке «Заявки» диспетчер видит дополнительную информацию по выполняемым заявкам:

—  приоритет их выполнения,

—  требования к квалификации инженера,

—  окно выполнения,

—  статус заявки (назначена, выполняется, выполнена).

На Рис. 7 видно, что во вкладке «Маршруты» диспетчер может просмотреть все маршруты, а именно:

—  какой инженер выполняет заявки по маршруту;

—  какая для этого требуется квалификация;

—  статус заявки, расстояние по маршруту, виды заявок.

Также диспетчер может внести новую заявку и назначить инженера, который будет ее выполнять, что автоматически вносит изменения в план сервисных работ и отражается на экране и во всех приложениях.

На Рис. 8 во вкладке «Инженеры» диспетчер может видеть: какой инженер какой маршрут обслуживает, какие заявки им выполнены и сколько осталось, какие есть задержки и с чем они связаны, а также время, когда он заканчивает работу по маршруту.

На Рис. 9 во вкладке «Без исполнителя» диспетчер видит заявки, которые не имеют исполнителя или не могут быть выполнены сегодня и причины этого. Заявки без исполнителя диспетчер может перенести на следующий день или найти возможность их выполнить в текущий день, если появляется такая возможность.

На Рис. 10 во вкладке «Отчеты» диспетчер (и его руководитель) видит отчет о выполненных в течение рабочей смены выездными инженерами заявкам и возникшим в процессе этого проблемах из-за нехватки ресурсов.

На Рис. 11 во вкладке «Сравнение» диспетчер (и его руководитель) видит результаты работы инженеров по количеству выполненных заявок и пробегу автомобилей. Также модель позволяет проводить анализ работы (сравнивать показатели) за текущий и прошлые периоды работы.

На Рис. 12 во вкладке «Настройки» можно моделировать рабочий день сотрудников путем изменения следующих параметров:

—  количества и квалификации инженеров;

—  количества автомобилей;

—  количества заявок на начало дня и поступивших в течение рабочего времени;

—  района обслуживания клиентов;

—  рабочего времени инженеров;

—  видов работ по заявкам.

Наличие возможности моделирования позволит руководителю компании, используя уже реальные данные за прошедшие периоды, путем их экстраполяции на будущие периоды выбирать наиболее оптимальный состав сотрудников, в т.ч. по их квалификации и необходимому числу автомобилей, позволяющих быстро добираться до клиентов.

5.  Проведение анализа результата выполнения задачи № 3 участниками.

Очевидно, что участвующие в хакатоне команды имеют более продвинутые в техническом плане решения и лучшее оформление (визуализация данных на экране в модели, презентация) и заслуженно занимают более высокие позиции в рейтинге моделей. Хочется только отметить, что, быть хорошим ИТ-специалистом, еще не означает, что полученный этим специалистом продукт будет удобен и востребован пользователями, если в нем не учитываются их интересы и пожелания. Без тщательно проработанного ТЗ, где учитываются все особенности и функционал участников, создать эффективный прототип модели трудно.

Таким образом, наличие в команде специалиста, хорошо разбирающегося в теме задачи, типа процессного аналитика может положительно повлиять на эффективность разрабатываемого ИТ-продукта.

Настоящей проверкой ИТ-продукта может быть только тестирование его конечным пользователем, в данном случае диспетчером, который может оценить его практическое использование. Ясно, что две недели крайне мало, чтобы разработать полноценный ИТ-продукт, и организаторы, понимая это, предлагают командам создать имитационные модели, что проще и быстрее, не ограничивая себя в используемых инструментах.

Разработанная командой процессного аналитика и представленная выше модель «Помощник диспетчера» после ее доработки может послужить основой для разработки полноценной программы (платформы) по диспетчеризации выполнения сервисных работ или обслуживания оборудования, расположенных в разных местах.

Комментарии:

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

1)  Публиковались данные о количестве команд, решающих те или иные задачи на момент старта и окончания хакатона.

2)  Финалисты, вошедшие в десятку, а тем более команды, занимающие призовые места показывали полученные результаты и хотя бы в общих чертах рассказывали о своих моделях (подходах).

3)  Команды, не попавшие в финал, получали от организаторов хакатона разъяснения о том, какие этому послужили причины (хотя бы в общих чертах).

В хакатонах принимают участие ИТ-специалисты разных возрастов (много молодежи), и такая информация поможет им понять, где и что они должны улучшить в своей деятельности, а это будет способствовать поднятию уровня решения предлагаемых заказчиками задач в будущем.

Вы можете принять участие в обсуждении различных вопросов, касающихся управления в организации, на моем ТГ-канале Управление – Новый подход: https://t.me/upravlenie_novyj_podhod/5.