Прогноз загрузки сервиса по данным 1С: планирование смен

Как платформа получает и проверяет картину

Analytics Bridge читает метаданные реальной конфигурации 1С. ИИ-сотрудник через describe_schema находит документы и регистры, связанные с работами и загрузкой. Срезы через run_slice собираются по дням, подразделениям и видам услуг. Если готовый отчёт в 1С считает сложный показатель, describe_report помогает изучить его статическую схему компоновки; затем нужно отдельно проверить расчёт на контрольных датах.

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

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

Что написать в регламенте

Для сервиса важны правила, которые легко забыть в общей модели. Какая заявка считается новой, а какая — продолжением старой? Как учитывать отмену за час до визита? Сколько времени обычно занимает работа разных типов и кто имеет право её выполнять? Если эти определения записаны в VibeLab, ИИ-сотрудник может готовить один и тот же разбор каждую неделю, а не каждый раз заново угадывать смысл данных.

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

Когда подключать прогноз

Прогноз загрузки полезен, если есть история по сопоставимым дням и сведения о событиях, влияющих на поток. Для клиники это могут быть праздничные дни и расписание врачей, для автосервиса — сезон смены шин, для сервисной службы — плановые работы у крупных клиентов. Прогноз надо проверять на датах, которые модель не видела. Методика временной проверки не допускает подсматривать будущие записи.

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

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

Важно учитывать ограничения самой 1С-базы. Если обращения из телефонии или сайта попадают в неё только после ручного ввода, ранний прогноз будет неполным. Такие каналы можно подключить к VibeLab отдельно, но сначала стоит определить, кто отвечает за качество входящих данных.

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

Где ожидания модели расходятся с работой людей

Услуги одной категории могут занимать разное время из-за сложности случая или опыта специалиста. Если 1С хранит только факт выполнения, но не причину задержки, средняя длительность сгладит важные различия. На первом этапе лучше показывать диапазон ожидаемой нагрузки и отмечать работы, для которых данных мало.

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

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

Выберите один участок сервиса и один горизонт планирования. Сверьте историю из 1С, отметьте дни с известными исключениями и сравните рекомендации с фактическим расписанием. Обсудите этот маршрут с VibeLab — покажем, как соединить данные, регламент и решение руководителя в одном процессе.