Как проверить график EPC-подрядчика до разговора о задержках

Зачем проверять график до разговора о задержках?

КороткоКогда EPC-проект отстаёт, подрядчик объясняет задержку по своему графику (на крупных проектах это часто Primavera P6): опоздало проектирование, поставщики, данные заказчика. Прежде чем обсуждать причины, заказчику стоит проверить сам график: есть ли в нём принятый базовый план, сохранились ли связи между работами и подтверждены ли фактические даты. Ниже пять проверок: как проверить график подрядчика по его исходным файлам и реестру документации.

Ситуация обычная. Срок сорван, подрядчик объясняет отставание проектированием, поставщиками или данными заказчика и показывает график. Консалтинговая компания HKA ведёт базу проектов, по которым её эксперты разбирали претензии и споры: 1801 проект в 106 странах. Среди горно-металлургических проектов этой базы позднее проектирование вторая по частоте причина после изменения объёма работ: оно встречается больше чем в каждом третьем, в 36,1%. По ресурсным отраслям в целом оно тоже на втором месте (HKA CRUX Insight 2023, с. 40).

Если на руках только PDF, проверить почти ничего нельзя: в нём не видно ограничений, связи видны в лучшем случае частично, дата данных показана не всегда. Нужен исходный файл графика, для Primavera это XER, причём базового плана и всех ежемесячных обновлений. Протокол британского Общества строительного права (SCL) о задержках рекомендует передавать обновления «в исходном формате, а не в PDF» и не перезаписывать ни одну версию (п. 1.59; здесь и дальше перевод мой). Если в договоре этого нет, просить файлы всё равно стоит. Ставки ресурсов и стоимость, если подрядчик считает их коммерческой тайной, можно из выгрузки убрать: для проверок они не нужны.

Своя Primavera для проверок не обязательна. XER - текстовый файл, в котором таблицы идут подряд: TASK (работы и даты), TASKPRED (связи), PROJECT (параметры проекта). Его можно разобрать в Excel или Power Query, с непривычки на это уходит около часа, кодировку файл не указывает, и русский текст из русской Windows обычно приходит в Windows-1251: её выбирают при импорте вручную. Есть бесплатные библиотеки для чтения XER, например MPXJ и xerparser, если рядом есть аналитик. Самый простой путь - попросить у подрядчика вместе с XER выгрузку работ и связей в Excel или доступ на чтение в P6.

Если подрядчик ведёт график в другой программе, например в MS Project, Spider Project или Asta Powerproject, проверки остаются теми же, меняются формат файла и названия полей. Просите исходный файл программы или её выгрузку в XML, а для первой проверки уточните, где хранится базовый план. Дальше я показываю технику на примере P6.

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

Проверка 1. Где в графике базовый план?

КороткоПлановые даты в рабочем графике P6 и базовый план - разные вещи. У неначатых работ программа пересчитывает плановые даты при каждом расчёте, а если базовый план не назначен, сравнивает проект с ним же. Базовый план - замороженная копия графика, принятая сторонами. Её нужно запросить отдельно и знать её дату данных, то есть дату, на которую в ней проставлен факт.

У каждой работы в P6 несколько пар дат, и названия обманчивы. Плановые даты (Planned Start и Planned Finish) звучат как план, но по документации Oracle их рассчитывает сама программа, и меняться они перестают, только когда работа начата. Планировщик Я. Аль-Бустанджи в блоге Planning Planet описывает их так: плановые даты «не статичны, как даты базового плана, и не динамичны, как ранние и поздние». Ручную правку плановой даты начала у неначатой работы, по его словам, пересчёт сбрасывает без предупреждения.

Базовый план в P6 устроен иначе: это копия проекта на определённый момент. Если её не назначить, Oracle прямо пишет, что «значением по умолчанию становится текущий проект». Колонки отклонений тогда сравнивают график с ним же, и у неначатых работ отклонение выходит нулевым. Есть и второй подвох. Базовый план проекта (Project Baseline) и базовые планы пользователя (BL1-BL3) - разные настройки, и вторые у каждого, кто смотрит график, свои. Скриншот с колонками BL1 мог сравнивать график совсем с другой базой.

Американская Счётная палата (GAO) в руководстве по оценке графиков формулирует коротко: «базовый график - не то же самое, что текущий» (GAO-16-89G, с. 135). Там же сказано, что перебазирование должно быть редким и что оно «обычно стирает накопленные отклонения» (с. 140). В P6 есть функция, которая заливает в базу свежие данные без смены её имени (дату такой заливки P6 показывает в поле Last Update Date базы), поэтому свою копию принятой базы заказчику лучше хранить у себя.

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

Что сделать:

1. Запросить базовый план, принятый сторонами письмом или протоколом. Привязанные к проекту базы P6 в XER не выгружает, поэтому просите базу отдельным XER, восстановленной как обычный проект, или выгрузку в формате P6 XML, который переносит базы вместе с проектом. Записать дату данных базы.
2. Спросить, перебазировался ли график. Если да, получить все версии и документ, которым новую базу приняли.
3. Сравнить 10-20 ключевых вех: дата в базовом плане против текущего прогноза или факта.
4. Проверить внимательнее, если будущие вехи совпадают с базой до дня, а соседние работы явно отстают. Это повод выяснить, что именно стоит в колонке «база».

В MS Project и некоторых других программах базовый план живёт в замороженных полях того же файла, и руководство NDIA по планированию это допускает (PASEG, § 4.4). Отдельный файл не обязателен, важна заморозка: базу меняют только по согласованной процедуре изменений.

Проверка 2. Не потерялась ли логика, когда график перестроили?

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

Цепочка в EPC типовая: заказ оборудования, затем данные поставщика (нагрузки, габариты, присоединения), затем РД фундаментов, конструкций и сетей, затем стройка. Т. М. Корриган в журнале Американской арбитражной ассоциации пишет, что подтверждённые данные поставщика «предшествуют многим другим работам критического пути» и что «слишком часто графики проекта игнорируют сроки данных поставщиков при планировании закупок» (AAA Mediation Magazine, 2026). Если таких связей нет даже в базе, это отдельная находка.

Перестройка графика сама по себе нормальна: его детализируют, меняют структуру, переносят в другую систему кодов. Вопрос в том, куда при этом делись связи. GAO не рекомендует удалять работы из графика с базовым планом: удаление «может нарушить логику и затруднить сравнение текущего графика с базовым» (с. 126). Протокол SCL советует показывать информацию заказчика логическими связями с работами подрядчика, вместо фиксированных дат (п. 1.43(c)), и прикладывать к каждому обновлению отчёт об изменениях логики с причинами (п. 1.59).

Как проверить:

1. Выбрать 10-20 ключевых работ проектирования: комплекты РД под фундаменты основного оборудования, металлоконструкции, сети.
2. Для каждой проследить цепочку предшественников вверх на 3-5 звеньев и отметить, есть ли в ней данные поставщика, изыскания или данные заказчика. После детализации нужное звено часто оказывается на два-три уровня выше прямого предшественника. В P6 для этого есть трассировка логики (Trace Logic). В XER связи в таблице TASKPRED записаны по внутренним номерам работ, которые в разных файлах разные, поэтому коды работ берите из таблицы TASK.
3. Если коды работ не менялись, быстрее всего сравнить версии штатным инструментом P6 (Schedule Comparison, раньше Claim Digger) с отметкой добавленных и удалённых связей. Если менялись, этот инструмент покажет почти всё как удалённое и добавленное. Тогда попросите у подрядчика таблицу соответствия старых и новых кодов, а если её нет, сопоставляйте по шифру комплекта РД.
4. Свести в таблицу.

Условный пример того, что получается:

• РД фундаментов под оборудование корпуса А. В базе в цепочке нагрузки от поставщика оборудования, сейчас предшественника нет.
• РД металлоконструкций корпуса А. В базе и сейчас перед ней РД фундаментов.
• РД наружных сетей корпуса А. В базе в цепочке изыскания по площадке, сейчас веха начала проектирования корпуса.

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

Полезный косвенный признак даёт GAO: значительные изменения резерва времени (float) «могут указывать, что логическая связь разорвана или что работа выполнена с нарушением последовательности» (с. 95). Я сравниваю общий резерв времени работ проектирования в двух соседних обновлениях и смотрю, где он скачет.

Если график вашего подрядчика хочется разобрать вместе, это нормальный повод для короткого разговора.

Проверка 3. Можно ли верить фактическим датам?

КороткоФактическая дата в графике - это запись планировщика, и с реальным событием она совпадает не всегда. Два быстрых признака и один долгий. Быстрые: факт позже даты данных и одна и та же дата окончания у десятков работ. Долгий: факт, который нечем подтвердить. По каждому спорному месту нужна первичка: журналы, сопроводительные письма, акты.

GAO формулирует правило одной строкой: «прошлые даты не прогнозируют, будущие не бывают фактическими» (с. 122). В проверке из 14 пунктов, которую американское оборонное агентство DCMA применяет к графикам подрядчиков, это отдельный пункт о недопустимых датах. В одном из разборов GAO у 9% оставшихся работ фактические даты стояли в будущем (с. 125).

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

Третий признак - отсутствие опоры. По протоколу SCL записи о ходе работ должны создаваться одновременно с работами (п. 1.7). Проверка факта на деле означает сверку с ежедневными отчётами, табелями и актами, и это самая долгая часть работы.

Технически первые два признака несложно найти в Excel. В XER фактические даты лежат в полях act_start_date и act_end_date таблицы TASK, а дата данных - в поле last_recalc_date таблицы PROJECT. Если в одном файле несколько проектов, например база и текущий график, строки фильтруют по проекту.

Проверка 4. Окончание проектирования в графике - это выдача РД?

КороткоДата окончания работы проектирования в P6 и дата, когда комплект РД выдан в производство работ, обычно разные. Между ними проверка, замечания, повторная выдача, изменения. Для разговора о задержке дату выдачи берите из реестра проектной документации (MDR) и сопроводительных писем, а лучше из журнала входящих документов вашей же службы. График используйте для логики.

Планировщик закрывает работу проектирования в разные моменты: при передаче на проверку, при получении замечаний, при выдаче со штампом «в производство работ». Даже английский термин IFC (issued for construction) у разных участников значит разное. Консультанты Mesa Associates так и пишут: IFC «может означать разное для разных участников». Протокол SCL относит к записям журналы подачи документов, где есть дата подачи, дата ответа и статус.

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

Как сверить:

1. Взять комплекты РД, о которых идёт спор.
2. По шифру комплекта выписать четыре даты: окончание работы в P6, первая передача на проверку, выдача в производство, последнее изменение.
3. Посмотреть, с какой из них совпадает дата в графике. Так становится понятно, насколько график можно читать как журнал выдачи.
4. Отдельно отметить изменения после выдачи: стройке мог понадобиться второй выпуск комплекта, с изменением.

Проверка 5. Могло ли проектирование держать стройку?

КороткоОпоздание РД от базового плана и задержка стройки из-за РД - разные вопросы. Если работы СМР начинались через месяцы после выдачи РД, для этих работ проектирование напрямую ограничением не было. Тест: по работам СМР посчитать запас между выдачей нужного комплекта РД и стартом работы, затем медиану и квартили. Это скрининг, он показывает, где искать причину, и анализа причин задержки не заменяет. Метрика моя, отраслевого норматива для неё я не нашёл.

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

Как посчитать:

1. Взять работы СМР с фактическим стартом за период.
2. Для каждой найти комплекты РД, без которых её не начать. Надёжнее по шифру комплекта в описании работы: связи в графике могли потеряться (проверка 2). Если нужно несколько комплектов или комплект выдавали частями, берите последнюю выдачу до старта.
3. Дату выдачи в производство взять из реестра документации или из своего журнала входящих.
4. Посчитать запас: старт работы СМР минус выдача РД, в днях. У работ, начатых до выдачи, запас отрицательный, в медиану он входит.
5. Посмотреть медиану, 25-й и 75-й перцентили, долю работ с запасом меньше двух недель и долю работ, начатых до выдачи РД.
6. Отдельно выписать работы СМР, которые по базовому плану уже должны были начаться, но не начаты, и проверить, выдана ли для них РД. Без этого шага в выборку попадают только работы, которым РД не помешала, и медиана выходит благополучнее, чем на деле.
7. Отдельно посмотреть работы на критическом и околокритическом пути: срок держат они, а медиана по всем работам на это не отвечает.

Условный пример по двум корпусам:

• Корпус А. Начато 80 работ СМР. Медиана запаса 120 дней, 25-й перцентиль 60, 75-й 190. Запас меньше двух недель примерно у 10% работ, 5 начаты до выдачи РД. Ещё 2 работы ждут РД, хотя старт по базе прошёл.
• Корпус Б. Начато 60 работ СМР. Медиана запаса 9 дней, 25-й перцентиль 2, 75-й 30. Запас меньше двух недель больше чем у половины работ, 11 начаты до выдачи РД. Ещё 14 работ ждут РД, хотя старт по базе прошёл.

25-й перцентиль означает, что у четверти работ запас не больше этого числа.

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

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

Четыре оговорки. Первая: при параллельном проектировании и стройке (fast-track) малый запас бывает запланированным. Институт строительной индустрии США (CII) пишет, что перекрытие проектирования, закупок и строительства присуще типичному fast-track-проекту, поэтому сравнивайте с запасом, заложенным в базовом плане. Вторая: для работ с изготовлением (металлоконструкции, трубные узлы, закладные детали) сравнивайте выдачу РД с запуском изготовления или заказа. При сравнении со стартом монтажа «материалы», которые держали стройку, могут оказаться теми же комплектами РД. Третья: срез одного месяца не равен истории проекта, считайте по периодам. Четвёртая: работы, начатые до выдачи РД, разбирайте отдельно, их начали по предварительной документации или неверно связали в графике.

Что ещё проверить, прежде чем читать критический путь?

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

• Связи. У каждой работы, кроме вех начала и конца проекта, должны быть предшественник и последователь (GAO, с. 31). DCMA при подсчёте берёт незавершённые работы, его порог - 5% исключений.
• Жёсткие ограничения. Обязательные даты (Mandatory Start и Mandatory Finish в P6) разрывают логику: работа стоит на своей дате, даже если её предшественники опоздали, и задержка за ней не видна. В P6 ограничение вида «закончить не позже» (Finish On or Before) действует только на поздние даты: задержку оно не прячет, но превращает её в отрицательный резерв времени и делает работу критической из-за даты, хотя логика этого не требует. GAO прямо пишет, что дата, требуемая заказчиком, «включая договорные обязательства», не является обоснованной причиной для ограничения работы (с. 40). Протокол SCL советует таких дат избегать или объяснять их (п. 1.47).
• Отрицательный резерв времени. Он появляется, когда прогноз перерос ограничение по дате, чаще всего договорную дату на финише или на промежуточной вехе. В обновлении отстающего проекта это нормально. Но большие отрицательные значения, например минус 300 дней, по GAO «скорее всего указывают на отсутствующую логику или нереалистичную последовательность работ» (с. 94).
• Режим расчёта. Когда работу начали с нарушением последовательности, P6 может считать график с сохранением логики (retained logic), с приоритетом факта (progress override) или по фактическим датам (actual dates). Progress override обычно укорачивает график. Смена режима между обновлениями двигает финиш без единого события на площадке, если такие работы в графике есть. Причины для смены бывают, но её стоит увидеть и обсудить. Режим виден в настройках расчёта, в XER это таблица SCHEDOPTIONS.

Сам DCMA предупреждает, что «красная» метрика «сама по себе не означает провала» и служит поводом копать глубже (DCMA-EA PAM 200.1, § 4.0). GAO добавляет, что пороги DCMA «не являются триггерами соответствия» (с. 190). Значит, зелёная таблица из 14 пунктов не доказывает, что графику можно верить, а красная не доказывает обратного.

Что делать, если проверка что-то нашла?

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

Протокол SCL советует решать споры о том, что считать принятым графиком, сразу, как только они возникли (п. 1.56). Чем раньше стороны договорились о базе, тем меньше поводов спорить о ней потом.

Методы формального анализа описывает рекомендация AACE 29R-03 «Forensic Schedule Analysis». Среди методов, которые смотрят на фактический ход проекта, одни сравнивают факт с логикой одного графика, обычно базового плана, другие берут каждое обновление с его собственной логикой. Есть приём промежуточной версии, в которую внесён только прогресс: он отделяет влияние факта от влияния правок логики. Ещё рекомендация описывает методы, которые моделируют события в графике. Если график перестраивали, выбор подхода меняет ответ, и договариваться о нём стоит до расчёта. Как и с резервом стоимости в записке о модели RAND, принятое прочтение лучше назвать заранее.

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

Какие вопросы задать подрядчику?

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

1. Какой файл - принятый базовый план, какая у него дата данных и каким документом он принят?
2. Перебазировался ли график? Если да, когда и почему, и где лежат все версии?
3. Где в текущем графике данные поставщиков, изыскания и данные заказчика, от которых зависит проектирование, и когда они фактически получены?
4. Если коды работ менялись, где таблица соответствия старых и новых?
5. Чем подтверждаются фактические даты по проектированию и по стройке?
6. Что считается выдачей РД: дата окончания работы в графике или дата в реестре документации?
7. Какие ограничения стоят в графике и почему, в каком режиме он рассчитывается?

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