Сотрудник не вышел: как изменить меньше клиентских договорённостей

Сначала сохраните то, что уже обещано

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

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

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

Разделите обязательные условия и разрешённые предложения

Условие «начать в 10:00» отличается от «только специалист B». Первое может разрешать замену человека, второе — другое время, если оно отдельно согласовано. Если обязательны оба условия, кандидат должен сохранить оба. Не превращайте их в штрафные баллы, которыми алгоритм вправе пожертвовать ради красивого результата.

В документации Microsoft о фиксации записи отдельно описаны время, ресурс, их сочетание и временной диапазон. Вариант Time Range удерживает расчётное прибытие в диапазоне, но не гарантирует попадание туда окончания работы. Это смысл конкретной настройки Microsoft, а не определение любого обещания клиенту.

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

Три записи и два выполнимых проекта

Учебные условия: три неделимые работы J1, J2 и J3 назначены на 10:00–11:00 одного дня. Каждая требует одного человека на весь час. В подтверждении указан специалист: J1 — A, J2 — B, J3 — C. Другие ресурсы и буферы уже проверены, дорога не нужна. Все данные вымышлены.

A отсутствует, D свободен. Заранее проверенные рабочие условия разрешают B выполнять J1 или J2, C — J2 или J3, D — J2 или J3. Причины допустимости здесь заданы как входные данные; статья не определяет квалификацию сотрудников. Для каждой замены требуется предусмотренное согласование с клиентом.

Проект П: J1 → B, J2 → C, J3 → D. Все три работы покрыты. Но относительно подтверждённого плана изменились исполнители у всех трёх клиентов.

Проект К: J1 → B, J2 → D, J3 → C. Все работы также покрыты, а J3 остаётся у прежнего человека. Изменения затрагивают только J1 и J2. В обоих проектах заняты три человека по часу, начало и окончание одинаковы. Отличается число клиентских договорённостей, которые предстоит пересогласовать.

Почему два изменения — доказанный минимум

Определим счётчик заранее: одна запись считается изменённой, если в проекте отличается хотя бы одно согласованное с клиентом поле. В примере меняется только специалист. У проекта П счёт равен 1 + 1 + 1 = 3, у проекта К — 1 + 1 + 0 = 2. Два изменённых поля одной записи не превращаются в двух клиентов.

J1 неизбежно теряет A. Из оставшихся людей эту работу может выполнить только B, значит, прежний исполнитель J2 тоже должен измениться. Уже необходимы две замены. Проект К достигает этой нижней границы, поэтому он минимален при заданных условиях.

Для независимой проверки переберите шесть перестановок B, C и D по трём работам. Ограничения оставляют ровно два проекта, показанных выше. Большое расписание потребует другого способа поиска, но результат всё равно должен объяснять, какие условия выполнены и с какой исходной версией сравнивался счётчик.

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

Если J2 обязательно остаётся у B

Добавим одно условие: клиенту J2 обещан именно B, и разрешения на замену нет. Теперь оба проекта недопустимы. B одновременно нужен для J1 и закреплён за J2, а одного человека нельзя поставить на две часовые работы. Нулевой список решений означает открытый конфликт, а не право снять обещание.

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

Превратите проект в одну проверенную версию

Для выбранного проекта подготовьте короткий список различий по записям: было, предлагается, что остаётся прежним, чей ответ нужен. В проекте К в этот список входят J1 и J2. По J3 не требуется придумывать изменение только ради одинакового сообщения всем.

Дальше проверьте принятие работы сотрудниками, полномочия администратора и необходимые клиентские ответы. Доставка уведомления не завершает согласование. Если J1 согласился на B, а J2 ещё не согласился на D, зависимая цепочка не стала целиком выполнимой. Нужен явный ответственный за её завершение.

Перед фиксацией снова проверьте доступность D и весь комплект ресурсов. Сохраните новую версию, затем сверьте фактические назначения и подтверждения. Если операция выполнилась частично, сначала установите результат по каждой записи. Слепой повтор или откат способен затронуть уже принятые изменения. Общий порядок принятия замены описан в руководстве по графику смен.

Пять проверок перед использованием

1. Сравнение проектов. На исходных данных П получает счёт 3, К — 2. J3 в проекте К сохраняет C и интервал 10:00–11:00.
2. Обязательное назначение. После фиксации J2 за B полный план признаётся невозможным. Система или оператор объясняет конфликт, не снимая ограничение.
3. Неполное согласование. Ответ только по J1 не закрывает восстановление обеих зависимых записей. Видны оставшийся вопрос и ответственный.
4. Изменившаяся доступность. Если D занят другим подтверждённым визитом, проект К не фиксируется на прежнем расчёте. Новая проверка охватывает весь затронутый набор.
5. Повтор и старая версия. Повторная обработка уже завершённого изменения не создаёт ещё один визит. Поздний ответ на прежнее предложение не переписывает актуальный результат.

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