Онлайн-генераторы документов
работают прямо в браузере
Полное техническое задание (ТЗ) для Кейса «Прогноз нагрузки на МФЦ»
Конкурсы > Цифровой прорыв > Полное техническое задание (ТЗ) для Кейса «Прогноз нагрузки на МФЦ» | Поиск в этой теме
Страницы: | 1 | 2 |
Сообщение
1. Контекст задачи
Во многих регионах России наблюдается неравномерная нагрузка на многофункциональные центры (МФЦ). В определённые дни (первая неделя месяца, после праздников, период сдачи налоговых деклараций) очереди достигают 1,5–2 часов, в другие дни сотрудники простаивают. Это ведёт к снижению удовлетворённости граждан и неэффективному расходованию бюджетных средств.
Текущая система записи работает по принципу «выбери свободный слот сейчас», но не может прогнозировать, сколько людей придёт без записи (50-60% от общего потока). Это делает невозможным динамическое управление персоналом (вывод дополнительных окон или отправка сотрудников на обучение в часы простоя).
Во многих регионах России наблюдается неравномерная нагрузка на многофункциональные центры (МФЦ). В определённые дни (первая неделя месяца, после праздников, период сдачи налоговых деклараций) очереди достигают 1,5–2 часов, в другие дни сотрудники простаивают. Это ведёт к снижению удовлетворённости граждан и неэффективному расходованию бюджетных средств.
Текущая система записи работает по принципу «выбери свободный слот сейчас», но не может прогнозировать, сколько людей придёт без записи (50-60% от общего потока). Это делает невозможным динамическое управление персоналом (вывод дополнительных окон или отправка сотрудников на обучение в часы простоя).
2. Цель проекта
Разработать прототип системы прогноза почасовой нагрузки на выбранный филиал МФЦ с горизонтом до 7 дней вперёд. Система должна учитывать как исторические данные о посещаемости, так и внешние факторы (календарь, погоду, новостную повестку). Результат прогноза должен быть представлен в виде дашборда для управляющего МФЦ с возможностью экспорта рекомендаций по расписанию смен.
Разработать прототип системы прогноза почасовой нагрузки на выбранный филиал МФЦ с горизонтом до 7 дней вперёд. Система должна учитывать как исторические данные о посещаемости, так и внешние факторы (календарь, погоду, новостную повестку). Результат прогноза должен быть представлен в виде дашборда для управляющего МФЦ с возможностью экспорта рекомендаций по расписанию смен.
3. Исходные данные (предоставляются партнёром на хакатоне)
Исторические данные о посещениях:
✔ Дата и время прихода (таймстемп)
✔ С признаком «по записи» / «живая очередь»
✔ Тип услуги (паспорт, загран, регистрация прав, СНИЛС и т.д.)
✔ ID филиала
✔ Время ожидания в очереди (минут)
✔ Время обслуживания (минут) — опционально
Данные об услугах:
✔ Сезонность (например, «загран перед летом»)
✔ Законодательные изменения (дата, тип услуги, оценка роста потока)
Календарь:
✔ Праздники, длинные выходные, предпраздничные дни
✔ Единые дни голосования, дни выплат пособий
✔ Погода (агрегированная по часам):
✔ Температура, осадки, ветер, гололёд
Новостная повестка (для анализа):
✔ Тексты госновостей за последние 2 года (например, «Можно получить загран за 3 дня»)
Исторические данные о посещениях:
✔ Дата и время прихода (таймстемп)
✔ С признаком «по записи» / «живая очередь»
✔ Тип услуги (паспорт, загран, регистрация прав, СНИЛС и т.д.)
✔ ID филиала
✔ Время ожидания в очереди (минут)
✔ Время обслуживания (минут) — опционально
Данные об услугах:
✔ Сезонность (например, «загран перед летом»)
✔ Законодательные изменения (дата, тип услуги, оценка роста потока)
Календарь:
✔ Праздники, длинные выходные, предпраздничные дни
✔ Единые дни голосования, дни выплат пособий
✔ Погода (агрегированная по часам):
✔ Температура, осадки, ветер, гололёд
Новостная повестка (для анализа):
✔ Тексты госновостей за последние 2 года (например, «Можно получить загран за 3 дня»)
4. Требования к решению
Функциональные требования:
Автоматический сбор и предобработка источников (загрузка CSV, доступ к API погоды)
Выбор филиала из выпадающего списка
Прогноз нагрузки на выбранную дату в разрезе часов (9:00–20:00)
Отображение прогнозного числа посетителей в час:
✔ Всего
✔ По записи (ожидаемое число)
✔ Живая очередь (прогноз)
Индикатор уверенности прогноза (зелёный/жёлтый/красный флаг)
Рекомендации по оптимизации смен («час Х: нужно добавить 2 окна» или «час Y: можно отправить сотрудников на обучение»)
Экспорт прогноза и рекомендаций в PDF или Excel
Нефункциональные требования:
В расчёте прогнозной модели ошибка MAPE < 25% (среднее абсолютное процентное отклонение)
Время пересчёта прогноза для одного филиала: не более 10 секунд
Веб-интерфейс (React / Vue / Streamlit — на выбор)
Бэкенд: Python / FastAPI или Django
База данных: PostgreSQL или SQLite (для прототипа)
Запрещены готовые платформы автоматического прогнозирования (AutoML) — модель должна быть явно реализована командой
Функциональные требования:
Автоматический сбор и предобработка источников (загрузка CSV, доступ к API погоды)
Выбор филиала из выпадающего списка
Прогноз нагрузки на выбранную дату в разрезе часов (9:00–20:00)
Отображение прогнозного числа посетителей в час:
✔ Всего
✔ По записи (ожидаемое число)
✔ Живая очередь (прогноз)
Индикатор уверенности прогноза (зелёный/жёлтый/красный флаг)
Рекомендации по оптимизации смен («час Х: нужно добавить 2 окна» или «час Y: можно отправить сотрудников на обучение»)
Экспорт прогноза и рекомендаций в PDF или Excel
Нефункциональные требования:
В расчёте прогнозной модели ошибка MAPE < 25% (среднее абсолютное процентное отклонение)
Время пересчёта прогноза для одного филиала: не более 10 секунд
Веб-интерфейс (React / Vue / Streamlit — на выбор)
Бэкенд: Python / FastAPI или Django
База данных: PostgreSQL или SQLite (для прототипа)
Запрещены готовые платформы автоматического прогнозирования (AutoML) — модель должна быть явно реализована командой
5. Состав команды и роли (рекомендуемый, но команда может перераспределить)
Аналитик данных — исследование факторов, подготовка признаков
ML-инженер — построение модели прогноза (XGBoost, LightGBM, Prophet или LSTM на выбор)
Бэкенд-разработчик — API дашборда
Фронтенд-разработчик — дашборд и интерактив
DevOps (при наличии) — упаковка в Docker
Аналитик данных — исследование факторов, подготовка признаков
ML-инженер — построение модели прогноза (XGBoost, LightGBM, Prophet или LSTM на выбор)
Бэкенд-разработчик — API дашборда
Фронтенд-разработчик — дашборд и интерактив
DevOps (при наличии) — упаковка в Docker
6. Критерии приёмки (для оценки жюри)
Критерий Вес Описание
Качество прогноза 40% MAPE на скрытом тестовом периоде (от партнёра)
Работа дашборда 20% Удобство интерпретации, фильтры, экспорт
Интеграция данных 15% Автоматическая подгрузка погоды и календаря
Понятность вывода рекомендаций 10% Почему именно в это время добавлять окна?
Код и документация 10% README, инструкция по запуску, структура проекта
Дополнительная метрика bonus +5% MAPE с учётом предсказания «живой очереди» отдельно
Критерий Вес Описание
Качество прогноза 40% MAPE на скрытом тестовом периоде (от партнёра)
Работа дашборда 20% Удобство интерпретации, фильтры, экспорт
Интеграция данных 15% Автоматическая подгрузка погоды и календаря
Понятность вывода рекомендаций 10% Почему именно в это время добавлять окна?
Код и документация 10% README, инструкция по запуску, структура проекта
Дополнительная метрика bonus +5% MAPE с учётом предсказания «живой очереди» отдельно
7. Схема взаимодействия с данными
Файлы с анонимизированными данными будут выданы партнёром в момент старта (CSV)
API погоды (тестовый ключ) будет предоставлен
Запрещено использовать данные текущего дня (предсказываем будущее, не зная настоящего)
Файлы с анонимизированными данными будут выданы партнёром в момент старта (CSV)
API погоды (тестовый ключ) будет предоставлен
Запрещено использовать данные текущего дня (предсказываем будущее, не зная настоящего)
8. Результат работы (что сдать)
1. Публичный репозиторий GitHub (код)
2. README с инструкцией по запуску (локально или Docker)
3. Видео-презентация (3 минуты) — скринкаст работы дашборда и демонстрация прогноза
4. Краткое описание выбранной модели (может быть в README или отдельном PDF)
1. Публичный репозиторий GitHub (код)
2. README с инструкцией по запуску (локально или Docker)
3. Видео-презентация (3 минуты) — скринкаст работы дашборда и демонстрация прогноза
4. Краткое описание выбранной модели (может быть в README или отдельном PDF)
Страницы: | 1 | 2 |
Перейти в другой раздел:
| • | Итоговый совет: день рефлексии и планирования (12) | 25.09.2026 15:00 |
| • | День самоуправления: лагерная экономика (12) | 25.09.2026 14:58 |
| • | Совет лидеров: школа наставничества (12) | 25.09.2026 14:56 |
| • | День самоуправления: лагерь будущего (12) | 25.09.2026 14:53 |
| • | Совет дружбы народов (12) | 25.09.2026 14:51 |
| • | День самоуправления: наука и открытия (12) | 25.09.2026 14:48 |
| • | Лагерь-государство: день реформ (12) | 25.09.2026 14:46 |
| • | День самоуправления: медиапространство (12) | 25.09.2026 14:43 |
| • | Совет творчества (12) | 25.09.2026 14:40 |
| • | День самоуправления: добрые дела (12) | 25.09.2026 14:38 |
«Внимание: все примеры разделов заявок являются авторскими разборами и носят обучающий характер. Перед сдачей настоятельно рекомендуем адаптировать текст под свой проект. Прямое копирование без изменений может быть распознано системой антиплагиата конкурса».
CHAT
