Notice Register по FIDIC 2017: как управлять 28/84-day workflow без потери claim

Правило 28 дней знают почти все. Пропускают его тоже почти все одинаково: событие заметили, на совещании обсудили, письмо “потом подготовим”, planner занят, QS ждет цифры, юрист просит больше фактов. Через месяц команда внезапно понимает, что спор может быть сильным, но notice уже живет в зоне риска.

Проблема редко в том, что люди не читали Clause 20. Проблема в том, что на проекте нет операционной системы для notices.

Notice Register по FIDIC 2017 нужен не для красоты и не для audit folder. Он нужен, чтобы связать событие, дату осведомленности, 28-day notice, records, 84-day fully detailed claim и последующий decision trail в одну управляемую цепочку.

Чем эта статья отличается от статьи про 28 дней

Базовая статья о правиле 28 дней объясняет, почему notice критичен и чем опасен time-bar.

Эта статья про другое: как проектной команде построить workflow, чтобы notice не зависел от памяти одного contract manager.

Иными словами: знать срок - это юридическая грамотность. Управлять сроком - это contract administration.

Что должен фиксировать Notice Register

Минимальный register должен отвечать на семь вопросов.

Поле	Зачем оно нужно
Event ID	Чтобы событие не потерялось в переписке
Event description	Короткое описание факта, без длинной позиции
Date of event	Когда событие произошло или началось
Date of awareness	От какой даты потенциально считается notice period
Potential entitlement	Time, cost, both, or other relief
Notice due date	Контроль 28-day deadline
Detailed claim due date	Контроль 84-day или иного contract-specific срока
Evidence owner	Кто собирает records
Status	Watching, notice issued, particulars pending, submitted, determined, disputed

В реальном проекте полей может быть больше: affected activities, clause reference, responsible person, correspondence link, Engineer response, claim value, risk rating. Но если нет даже минимальных полей, команда управляет claims через inbox.

28 дней: считать не от удобной даты

Самый опасный вопрос в notice workflow - дата осведомленности. Команда часто хочет считать срок от момента, когда стало понятно, сколько денег или времени потеряно. Это может быть поздно.

На практике register должен фиксировать три разные даты:

1. Event date - когда событие произошло.
2. Awareness date - когда сторона узнала или должна была узнать о событии.
3. Impact confirmation date - когда последствия стали понятнее.

Notice обычно не должен ждать полного расчета. Его задача - сохранить право и предупредить другую сторону о событии. Расчет и causation раскрываются дальше, в fully detailed claim.

Формулировки и последствия всегда зависят от конкретного контракта, Particular Conditions и governing law. Но с операционной точки зрения лучше открыть event file раньше, чем спорить через два месяца, была ли команда “достаточно осведомлена”.

84-day workflow: notice не заканчивает работу

В FIDIC 2017 notice - это входная точка. После него начинается более тяжелая часть: substantiation.

Для каждого notice register должен автоматически запускать evidence workflow:

• открыть event file;
• назначить владельца records;
• проверить affected activities в programme;
• запросить daily reports, photos, manpower and equipment logs;
• собрать correspondence and instructions;
• отделить direct cost evidence от общих жалоб;
• подготовить chronology;
• согласовать draft claim narrative;
• контролировать срок fully detailed claim.

Если notice отправлен, но evidence workflow не запущен, команда просто купила себе немного времени. Claim от этого еще не стал доказанным.

Подробно о доказательственной архитектуре см. в статье Обоснование claims по FIDIC.

Кто должен владеть register

Плохой register обычно принадлежит “кому-то из юристов”. Хороший register принадлежит проекту.

Роли могут распределяться так:

• Contract Manager ведет notice logic и correspondence status.
• Planner проверяет activity impact, baseline/revised programme and critical path.
• QS или cost team собирает quantum evidence.
• Site team дает daily records, photos, manpower, equipment and disruption facts.
• Project Manager принимает коммерческое решение: issue notice, reserve rights, escalate or close.

Юрист полезен, особенно на sensitive claims. Но юрист не может задним числом создать site records, которых не было.

Event watching: не каждое событие сразу claim

Notice Register не должен превращать проект в фабрику конфликтов. Для этого нужен статус watching.

Например:

• late drawing может исчезнуть без impact;
• minor access issue может быть absorbed by float;
• design clarification может не изменить sequence;
• weather event может оказаться обычным seasonal condition.

Но если событие потенциально затрагивает time, cost or rights, его стоит поставить на watching с deadline. Это дисциплинирует команду: через несколько дней событие либо закрывается, либо превращается в notice candidate.

Типичные провалы

Один общий claim file на все. Через полгода команда пытается доказать “проект в целом был disrupted”. Без event-by-event tracking это слабая позиция.

Notice есть, но нет records. Письмо сохраняет procedural position, но не доказывает entitlement, causation or quantum.

Register не связан с programme. Событие описано словами, но affected activities не указаны. Потом delay analysis становится ретроспективной реконструкцией.

Сроки считаются вручную. Excel без владельца, reminders и weekly review быстро умирает.

Команда боится слова claim. Notice воспринимается как начало войны. В зрелом FIDIC-администрировании notice - это hygiene, not escalation.

Минимальный weekly rhythm

Практический notice workflow можно встроить в weekly contract meeting:

1. Просмотреть новые events за неделю.
2. Проверить approaching 28-day deadlines.
3. Проверить notices already issued.
4. Проверить records status по каждому open event.
5. Обновить 84-day/detailed claim tracker.
6. Решить, какие events закрываются, какие идут в notice, какие требуют escalation.

Если такой rhythm работает, claim readiness становится частью проекта, а не пожаром перед DAAB.

FAQ

Notice Register нужен только подрядчику?

Нет. Заказчику и Engineer тоже полезно видеть events, notices, determinations, payment issues and dispute exposure. У каждой стороны может быть свой register с разным уровнем детализации.

Можно ли вести register в Excel?

Да, если есть владелец, weekly review, ссылки на документы и контроль сроков. Проблема не в Excel, а в том, что файл часто не является частью управленческого процесса.

Надо ли подавать notice по каждому мелкому событию?

Нет. Но каждое потенциально значимое событие надо оценить быстро. Если возможны time, cost or other relief, лучше зафиксировать event и deadline, чем вспоминать о нем после истечения срока.

Bridge Consult помогает проектным командам выстроить notice register, claims workflow и records discipline по FIDIC 2017: от event watching до fully detailed claim и подготовки к Engineer’s determination или DAAB.

Sources and further reading

• Society of Construction Law, Delay and Disruption Protocol, 2nd Edition.
• World Bank, Project Procurement.
• World Bank, Contract Management: Practice Procurement Guidance, Second Edition, May 2024.
• FIDIC, Conditions of Contract for Construction, 2017 edition.
• См. также: Правило 28 дней, Обоснование claims по FIDIC и Notice Deadline Calculator.