Специалисты по закупкам, которые направляют запрос на предоставление коммерческого предложения на основе неполной спецификации требований пользователя (URS), редко обнаруживают эти пробелы на этапе подготовки предложения. Проблема всплывает на этапе ввода в эксплуатацию, когда инженер по аттестации пытается составить приемочный тест для функции локализации, которая в URS была описана с использованием слишком расплывчатых формулировок, не поддающихся тестированию, а поставщик может справедливо доказать, что поставленное оборудование соответствует каждому слову заданных требований. Результатом становится переработка протокола в условиях дефицита времени, задержка приемочных испытаний на объекте и повторные переговоры о том, на кого ложится ответственность за проведение испытаний в присутствии свидетелей — при этом ни одна из этих проблем не была заметна на момент отправки тендерной документации. Понимание того, где провести границу между тем, что должно входить в спецификацию требований пользователя (URS), чем должен быть ответ на запрос предложений (RFQ) и кому формально возлагается ответственность за валидацию до присуждения контракта, — это именно тот аспект, который отличает хорошо организованный процесс закупок от того, который приводит к накоплению споров во второй половине проекта.
Требования заказчика, которые должны быть включены в техническое задание (URS)
URS — это не просто список пожеланий и не упрощённая спецификация. Это документ, на который будут опираться все последующие этапы валидации — FAT, SAT, IQ, OQ, PQ — для определения соответствия поставленной системы замыслу пользователя. Если URS имеет структурные пробелы или содержит формулировки, которые невозможно соотнести с измеримыми условиями испытаний, у отдела контроля качества не будет обоснованных оснований для приёмки, и никакие последующие исправления в документации не смогут исправить эту ситуацию задним числом.
Структурные компоненты правильно составленного документа URS для оборудования с высоким уровнем локализации аварийных ситуаций в профессиональной проектной практике следуют единой схеме: введение и общее описание, определяющие эксплуатационный контекст и нормативную базу; функциональные требования, определяющие характеристики локализации аварий, требования к асептическим процессам и поведение систем безопасности; нефункциональные требования, касающиеся надежности, удобства технического обслуживания и экологических ограничений; определения интерфейсов, охватывающие физические соединения, подключения к инженерным сетям и точки интеграции с системой управления; ограничения и допущения, документирующие пространственные ограничения, доступность инженерных сетей и предполагаемые условия на объекте; а также раздел, посвященный документации и результатам работы, в котором перечислены требуемые результаты с критериями приемки. Именно в этом последнем компоненте URS чаще всего терпит неудачу. Когда раздел, посвящённый конечным результатам, опускается или остаётся общим, проект доходит до этапа сдачи без согласованных критериев, и обе стороны обнаруживают, что они исходили из разных предположений о том, что составляет полный пакет.
Риск заключается не в том, что URS будет явно неверным, а в том, что он будет достаточно точным для формирования связного предложения, но при этом слишком расплывчатым, чтобы служить основой для протокола квалификации. Такие формулировки, как “надлежащая эффективность локализации” или “соответствующая фильтрация HEPA”, подходят для получения ответа от поставщика, но они не подходят для составления испытания, которое лицо, ответственное за обеспечение качества, сможет обосновать перед инспектором регулирующего органа. Приложение 15 к тому 4 EudraLex рассматривает задокументированные и четко определенные требования как основу всей деятельности по квалификации и валидации — не потому, что оно предписывает формат URS, а потому, что исходит из того, что до начала квалификации уже существует нечто, обладающее поддающимися проверке критериями приемлемости. Если URS этого не обеспечивает, Приложение 15 не поможет это исправить.
| Компонент URS | Что необходимо определить | Риск в случае неопределённости или отсутствия информации |
|---|---|---|
| Введение и общее описание | Операционный контекст, целевое назначение и система обеспечения соблюдения нормативных требований | Поставщик может неверно истолковать классификацию защитных оболочек, что приведет к поставке оборудования, не соответствующего требованиям |
| Функциональные требования | Эффективность локализации, требования к асептическим технологическим процессам, блокировки безопасности | Оборудование соответствует техническим требованиям, но не прошло испытания на локализацию рисков в рамках контроля качества |
| Нефункциональные требования | Надежность, удобство технического обслуживания, экологические ограничения, стандарты очистки | Недостатки в эксплуатации и техническом обслуживании становятся проблемами после сдачи объекта в эксплуатацию |
| Интерфейсы | Физические соединения, подключения к инженерным сетям, точки интеграции с системой управления | Неясность в отношении ответственности за интерфейс приводит к расширению объема работ и сбоям при интеграции |
| Ограничения и допущения | Ограничения по площади, наличие инженерных сетей, ограничения доступа, предполагаемые условия на объекте | Предположения, заложенные в предложении, не соответствуют реальной ситуации на объекте, что приводит к появлению распоряжений об изменениях |
| Документация и результаты работы | Перечень необходимых документов с критериями приемлемости | В документации по сдаче объекта отсутствуют четко определенные критерии, что приводит к задержке окончательной приемки |
Раздел “Функциональные требования” требует особого внимания в случае изоляторов OEB4/OEB5 и систем локализации BSL-3/4, где характеристики локализации должны быть сформулированы в терминах, определяющих конкретные пределы приемлемости — скорость утечки, перепад давления, время срабатывания блокировки — а не в виде категорий. Техническое задание (URS), в котором говорится, что «изолятор должен поддерживать отрицательное давление», является неполным. Спецификация, в которой указаны диапазон рабочего перепада давления, допустимое отклонение до срабатывания сигнализации и время срабатывания автоматической блокировки, дает поставщику основу для разработки функциональной проектной спецификации и обеспечивает отделу контроля качества (QA) конкретные параметры для тестирования.
Документы поставщика, которые должны быть включены в ответ на запрос предложений
Запрос предложений (RFQ) — это не запрос на предоставление цены. Это механизм, позволяющий преобразовать требования технического задания (URS) в обязательства поставщиков, которые можно оценить до принятия решения о присуждении контракта. Если в запросе предложений не указано, какие подтверждающие документы должен предоставить поставщик, заказчик получает предложения, которые сопоставимы с коммерческой точки зрения, но несопоставимы с технической — в них содержатся разные допущения относительно объема работ, разные результаты проверки и разные интерпретации ответственности за интерфейсы, причем все они оцениваются так, как будто они эквивалентны.
Наиболее существенным недостающим элементом в большинстве предложений по запросам на предложение (RFQ) в сфере высокого уровня биологической защиты является функциональная проектная спецификация (FDS). Требование предоставления FDS на этапе подготовки предложения — или, как минимум, её предварительной версии, в которой каждое требование технического задания (URS) соотносится с конкретным проектным решением, — является единственным механизмом, позволяющим сохранить цепочку прослеживаемости от URS до проекта в целостности до момента присуждения контракта. Без этого URS существует как отдельный документ, а предложение поставщика — как отдельный документ, и именно в пробеле между ними возникают споры по поводу объема работ. Требование предоставить FDS на этапе запроса предложений увеличивает инженерную нагрузку на поставщика на ранних этапах и на практике может привести к сокращению числа ответивших поставщиков. Это реальный компромисс. Команда по закупкам, которая принимает нечеткие предложения с целью сохранения более широкого круга поставщиков, переносит инженерные затраты на этап после присуждения контракта, где они проявляются в виде распоряжений об изменениях.
Полный ответ на запрос предложений по данному классу оборудования должен также включать график этапов работ, охватывающий сроки проектирования, закупок, приемочных испытаний на заводе (FAT), приемочных испытаний на объекте (SAT), квалификационных испытаний (IQ/OQ/PQ) и сдачи оборудования; структуру отчетности, определяющую периодичность и формат отчетов о ходе работ; оценку компетентности, определяющую персонал, ответственный за проектирование, испытания и сдачу оборудования; а также коммерческие условия, определяющие этапы оплаты, условия внесения изменений в заказ и рамки гарантийного обслуживания. Каждый из этих элементов выполняет свою контрольную функцию в ходе реализации проекта, и упущение любого из них приводит к возникновению определённого вида неоднозначностей после присуждения контракта.
| Обязательный элемент ответа на запрос предложений | Что должно быть продемонстрировано | Риск в случае отсутствия |
|---|---|---|
| Перечень результатов работы | Оборудование, документация и услуги, включенные в предложение | Споры после присуждения контракта относительно того, что входит в сферу применения, а что нет |
| График основных этапов | Сроки выполнения работ по проектированию, закупкам, приемочным испытаниям на заводе (FAT), приемочным испытаниям на объекте (SAT), квалификационным испытаниям (IQ/OQ/PQ) и сдаче объекта | Несоответствие графика готовности объекта и плана валидации |
| Требования к отчетности | Форматы отчетов о ходе работы, периодичность их представления и этапы рассмотрения | Статус проекта остался неясным; задержки были обнаружены слишком поздно |
| Оценка компетенций | Квалификация персонала, осуществляющего проектирование, испытания и сдачу объекта | Ненадлежащее выполнение работ, необходимость доработки или нарушения требований |
| Коммерческие условия | Этапы оплаты, условия внесения изменений в заказ, рамки гарантийного обслуживания | Финансовые неожиданности и риски, связанные с утверждением финансирования |
| Спецификация функционального проектирования (FDS) | Как проект поставщика преобразует требования URS в конкретное решение | Нарушена прослеживаемость от URS до проекта; возрастает риск использования оборудования, не соответствующего требованиям |
В отношении оборудования со встроенной функцией дезактивации — например, проходных камер с VHP, служащих границами локализации — требования к FDS должны четко оговаривать параметры разработки циклов и основания, на которых поставщик определил размеры системы дезактивации. Анализ того, какую документацию поставщики должны предоставить до направления запроса предложений (RFQ) на оборудование со встроенной системой VHP, помогает прояснить, что на самом деле должно содержаться в полном FDS для таких систем. В запросе предложений следует требовать предоставления подтверждающих документов, а не допускать ссылки на стандартные технические характеристики продукции в качестве замены.
Границы валидации в рамках FAT, SAT и IQ/OQ/PQ
Наиболее частым источником споров после заключения контракта при закупках оборудования высокого уровня биологической защиты является нерешенный вопрос: кто отвечает за проведение каждого этапа испытаний, в соответствии с каким протоколом, по каким критериям приемки и на каком объекте. Если этот вопрос не урегулирован в запросе предложений, он решается в ходе переговоров после заключения контракта — в тот момент, когда перевес в переговорах в значительной степени переходит от покупателя к поставщику.
Определение границ валидации не является задачей планирования валидации — это задача в области закупок, которую необходимо решить до выпуска пакета предложений. Стандарт ASTM E2500-25 поддерживает принцип, согласно которому мероприятия по проверке должны соответствовать задокументированным техническим условиям и основываться на научной и риск-ориентированной оценке; он не решает договорный вопрос о том, кто разрабатывает протокол, кто присутствует при испытании и кто подписывает акт приемки. Это распределение обязанностей должно быть указано в запросе предложений в качестве требования к закупке, а не определяться на этапе запуска проекта после присуждения контракта.
Вопросы, касающиеся границ на каждом этапе, охватывают весь жизненный цикл проекта, и на каждом этапе возникают свои последствия, если вопрос об ответственности остается нерешенным.
| Этап проекта | Вопрос о границе проверки ключа | Последствия в случае отсутствия ясности |
|---|---|---|
| Дизайн | Соответствует ли проектная документация поставщика критериям приемки, зафиксированным в техническом задании (URS)? | Отклонение от проекта, доработки на поздних этапах и неудачи при аттестации |
| Закупки | Кто проверяет технические характеристики компонентов и результаты работ поставщиков и субподрядчиков? | Детали, не соответствующие требованиям, обнаруженные в ходе ввода в эксплуатацию |
| Строительство | Какая сторона обеспечивает соответствие монтажных работ стандартам локализации? | Расходы на устранение нарушений и задержки с подтверждением соответствия |
| Ввод в эксплуатацию | Кто проводит предварительные проверки и по каким критериям? | Разногласия между этапом ввода в эксплуатацию и приемом по результатам IQ/OQ |
| Валидация (FAT, SAT, IQ/OQ/PQ) | Какая сторона несет ответственность за проведение каждого этапа испытаний, обеспечение присутствия свидетелей и подписание актов приемки? | Объем работ согласовывается после присуждения контракта; границы тестирования расширяются |
| Стартап | Кто обеспечивает поддержку на месте и устраняет возникающие на начальном этапе эксплуатации проблемы? | Простои и доработки в рамках эксплуатационной аттестации |
| Передача дел | Какие отчеты необходимо составлять и кто утверждает их в окончательном виде? | Неполные пакеты документов по сдаче объекта; задержка окончательной приемки |
На практике граница между вводом в эксплуатацию и IQ является наиболее спорной. Проверки в рамках ввода в эксплуатацию, предшествующие валидации, проводятся командой поставщика по собственным критериям. Процесс IQ начинается, когда система качества объекта принимает на себя ответственность за протокол квалификации. Если в запросе предложений (RFQ) не определено, где происходит эта передача — какие мероприятия относятся к вводу в эксплуатацию, а какие — к IQ, и какая сторона должна утвердить и то, и другое, — поставщик завершит ввод в эксплуатацию, руководствуясь своими критериями, и представит систему как готовую к IQ без доказательств предварительной квалификации, которые, согласно протоколу заказчика, должны были быть уже сформированы. Этот пробел более подробно описывается в контексте ввода в эксплуатацию по методу BIBO, где при передаче от поставщика объекту регулярно упускаются конкретные пункты IQ и OQ. Такая же схема сбоев характерна для любой системы с высоким уровнем биологической защиты, требующей формальной квалификации перед вводом в эксплуатацию.
Предположения относительно интерфейса, влияющие на объем предложения
В каждом заказе на оборудование с высоким уровнем герметичности участвуют как минимум три стороны: поставщик оборудования, инжиниринговая или EPC-компания, отвечающая за интеграцию инженерных сетей и строительных работ, а также проектная группа заказчика на объекте. Каждая из сторон, как правило, исходит из того, что остальные стороны задокументировали границы взаимодействия между своим объемом работ и смежными объемами. В большинстве проектов ни одна из них этого не делает. Результатом этого становится не конфликт, возникающий при заключении контракта, а конфликт, возникающий тогда, когда оборудование поступает на объект, а подключения к инженерным сетям находятся в неправильном месте, имеют неправильное давление или находятся в зоне ответственности, которая явно не закреплена ни в одном контракте.
Неясность в определении границ интерфейса влияет на объем предложения следующим образом: каждый поставщик рассчитывает цену исходя из собственных предположений о том, что предоставит заказчик. Когда эти предположения в разных предложениях расходятся, заказчик сравнивает цены, отражающие разные совокупные затраты на проект, а не разную эффективность работы поставщиков. Поставщик, который исходит из того, что воздуховоды и подключения к инженерным сетям будут предоставлены заказчиком, предложит более низкую цену, чем тот, кто включает их в свой объем работ — не потому, что они дешевле, а потому, что объем его работ меньше. Запрос предложений должен устранить эту неоднозначность, точно указав для каждой области взаимодействия, за что именно отвечает поставщик и где именно заканчиваются границы его объема работ.
| Область интерфейса | Что необходимо уточнить в запросе предложений | Последствия неоднозначности |
|---|---|---|
| Гражданское строительство/Строительная инженерия | Подготовка фундамента, трассы прокладки трубопроводов, защитные барьеры | Поставщик исходит из того, что объект готов к работе, хотя на самом деле это не так; превышение сметы |
| Процесс/Утилита | Подключения к системам газоснабжения, водоснабжения, канализации, подачи чистого пара и границы давления | После присуждения контракта ответственность за подключение к инженерным сетям переходит к другому лицу |
| Системы управления/Автоматизация | Интеграция BMS и SCADA, обмен сигналами, управление аварийными сигналами | Недостатки в сфере контроля приводят к необходимости прибегать к ручным обходным решениям или перепроектированию |
| Обязанности сотрудников компании/клиентов | Разрешения на эксплуатацию объектов, надзор за соблюдением техники безопасности, ответственность за протоколы валидации | Заказчик полагает, что поставщик берет на себя проведение валидации, а поставщик исходит из того, что протоколы определяются заказчиком |
Именно в сфере интерфейса управления и автоматизации допущенные предположения приводят к самым затратным исправлениям в ходе реализации проекта. Интеграция систем управления зданием (BMS) и систем диспетчерского контроля и сбора данных (SCADA) для систем локализации уровней биологической безопасности BSL-3/4 часто включает в себя обмен сигналами, логику сигнализации и последовательности блокировок, охватывающие как архитектуру управления поставщика оборудования, так и инфраструктуру управления зданием на объекте. Если в запросе предложений (RFQ) не определены границы объема интеграции — какая сторона предоставляет логику интеграции, какая сторона отвечает за тестирование интеграции и какая сторона несет ответственность за ввод в эксплуатацию объединенной системы — в результате проекта будут созданы две проверенные подсистемы, которые не будут надежно взаимодействовать друг с другом, а расходы на устранение неполадок лягут на ту сторону, на которую удастся возложить ответственность за возникший пробел.
До окончательной приемки необходимо предоставить протоколы передачи объекта
Окончательная приемка — это не церемония, а мероприятие в рамках системы управления качеством, для проведения которого требуется определённый пакет документации, подтверждающий, что оборудование было изготовлено, смонтировано и проверено в соответствии с техническим заданием (URS). Если эти документы не указаны в техническом задании и не предусмотрены в запросе предложений (RFQ), то на этапе сдачи проекта пакет документации оказывается неполным, и обе стороны не могут прийти к единому мнению о том, что необходимо для его доработки.
Полный пакет документов для передачи оборудования с высоким уровнем герметичности должен включать, как минимум: скомпилированное досье по безопасности со всей применимой проектной документацией; документацию по строительству и монтажу, содержащую сведения о сертификатах на материалы, проверках размеров, а также записи о сварных швах или соединениях, имеющих отношение к целостности герметичной оболочки; документацию по вводу в эксплуатацию, подтверждающую функциональные характеристики в ходе предварительной квалификации в соответствии с установленными критериями; документацию по квалификации, охватывающую IQ, OQ и, где это применимо, PQ, с заполненными протоколами испытаний, протоколами отклонений и подписями уполномоченных лиц, утвердивших приемку; а также перечень всех невыполненных пунктов с согласованными сроками устранения и распределением ответственности. Досье по безопасности и документация по квалификации не являются взаимозаменяемыми — одно документирует, как была построена система и какие риски учитывались в ходе строительства, другое — соответствует ли установленная система заданным техническим требованиям. Оба документа должны быть представлены, прежде чем лицо, ответственное за обеспечение качества, сможет обоснованно закрыть проект.
Типичная причина сбоев в данном случае — перегрузка в условиях сжатых сроков. Когда график проекта очень плотный, подготовка пакета документов для сдачи проекта рассматривается как административная задача, которую можно выполнять параллельно с окончательным вводом в эксплуатацию. На практике отсутствующие записи из ранних этапов проекта — например, не зафиксированный сертификат сварки или никогда официально не задокументированное испытание перед вводом в эксплуатацию (pre-IQ) — выявляются во время окончательной проверки пакета документов и приводят к задержкам, несоразмерным объему необходимой работы. Указание структуры пакета документов для сдачи объекта, включая его содержание и критерии приемки, в техническом задании (URS) и в перечне результатов работ поставщика в запросе предложений (RFQ) является единственным механизмом, предотвращающим незаметное накопление таких пробелов на протяжении всего жизненного цикла проекта.
В отношении инфраструктуры лабораторий уровня BSL-3 структурированный подход к составлению документации по вводу в эксплуатацию — с четко определенными этапами проверки на всех этапах, от строительства до окончательной аттестации — служит полезной моделью того, как следует организовать требования к документации по передаче объекта до начала работ. Пошаговый процесс ввода в эксплуатацию, описанный для объектов уровня BSL-3, демонстрирует, что структура ведения документации должна быть сформирована до начала первых монтажных работ, а не создаваться задним числом.
Этап принятия решения перед отправкой пакета предложений
Публикация запроса предложений (RFQ) в определенном смысле, который зачастую недооценивается, является точкой невозврата. После подачи предложений объем работ фиксируется в соответствии с тем, что указано в RFQ. Изменения в требованиях к техническому заданию (URS) после получения предложений либо требуют проведения повторного тендера — что приводит к задержке проекта, — либо согласовываются в рамках уточнений объема работ, что переносит преимущество на сторону поставщика. На практике это означает, что решение о публикации RFQ должно выступать в качестве формального внутреннего контрольного этапа, а не просто вехи в графике работ.
Прежде чем можно будет обоснованно перейти к следующему этапу, необходимо доработать три базовых документа. Во-первых, техническое задание (URS) должно быть полностью завершено и утверждено — не в виде черновика и не в статусе “по существу завершено”. Во-вторых, должен существовать общий график, охватывающий этапы ввода в эксплуатацию, квалификационных испытаний и сдачи объекта, с указанием ключевых вех для каждого из них. Без этого предложенный поставщиком график не будет иметь ориентира, а несогласованность сроков с готовностью объекта и окнами валидации станет заметной только после присуждения контракта. В-третьих, в документе по реализации проекта должна быть определена стратегия проектирования, закупок, строительства, ввода в эксплуатацию, валидации, запуска и сдачи объекта, с четким указанием этапов валидации и их границ. Именно этот документ позволяет разрешать споры о границах валидации путем ссылки на него, а не путем переговоров. Четвертый элемент — базовая смета затрат, увязанная с техническим заданием (URS), графиком и планом реализации — предоставляет руководителю проекта единственную обоснованную отправную точку для управления изменениями объема работ после присуждения контракта и служит основой для принятия решений об утверждении финансирования, которые не могут быть пересмотрены после заключения контракта.
| Базовый документ | Что это устанавливает | Риск в случае, если соглашение не будет заключено до направления запроса предложений |
|---|---|---|
| URS (Область применения) | Все функциональные, нефункциональные, интерфейсные и документационные требования | Поставщики выдвигают возражения в связи с неполным или противоречивым объемом работ |
| Общий график | Этапы ввода в эксплуатацию, аттестации и сдачи объекта с указанием ключевых контрольных точек | Графики поставщиков не согласованы с готовностью объекта и сроками валидации |
| Документ о реализации проекта | Стратегия проектирования, закупок, строительства, ввода в эксплуатацию, валидации, запуска и сдачи объекта с определёнными этапами и границами ответственности | Вопрос о границах валидации будет согласован после присуждения контракта |
| Базовая смета расходов | Внутренний показатель затрат, привязанный к URS, графику и плану выполнения работ | Руководитель проекта не может контролировать изменения в объеме работ; под угрозой находится утверждение финансирования |
Риск не в том, что команды не знают об этих документах — большинство руководителей проектов понимают, что они должны существовать. Риск заключается в том, что запрос предложений (RFQ) публикуется, пока один или несколько из этих документов остаются в черновом варианте, поскольку давление со стороны графика, требующего получения предложений, перевешивает риск наличия неполных базовых документов. Когда это происходит, руководитель проекта теряет ориентир для контроля объема работ именно в тот момент, когда проект начинает принимать на себя обязательства. Изменения объема работ, поступающие после присуждения контракта в отсутствие утвержденного технического задания (URS), по которому можно было бы провести оценку, не имеют объективного механизма урегулирования и решаются тем, кто на данный момент проекта занимает более выгодную коммерческую позицию.
Самое важное решение в рамках данного процесса закупок принимается ещё до установления контактов с каким-либо поставщиком: достаточно ли конкретны требования к пользовательским спецификациям (URS), чтобы на их основе можно было сформулировать поддающиеся проверке критерии приёмки, и предусматривает ли запрос предложений (RFQ) от поставщика предоставление документации, обеспечивающей непрерывность цепочки прослеживаемости от URS до проекта на всех этапах — включая приёмку на производстве (FAT), приёмку на сайте (SAT) и квалификацию установки/операции/процесса (IQ/OQ/PQ). Эти два условия не являются административными предварительными требованиями — они представляют собой механизм, с помощью которого заказчик сохраняет контроль над объемом работ, ответственностью за валидацию и качеством передачи на протяжении всего жизненного цикла проекта.
Перед выпуском пакета предложений команда должна быть готова ответить на три вопроса, предоставив задокументированные и утвержденные ответы: какой конкретный критерий эффективности определяет, прошла ли каждая функция локализации испытание или нет? Какая сторона несет ответственность за каждый этап валидационных испытаний и формирует акт приемки? И что входит в полный пакет документов для передачи проекта, и каковы критерии его приемки? Если какой-либо из этих вопросов остается открытым, запрос на предложение (RFQ) не готов — и споры, которые последуют за присуждением контракта, уже предрешены.
Часто задаваемые вопросы
Вопрос: Что произойдет, если техническое задание (URS) уже выпущено в черновом варианте до подготовки запроса предложений (RFQ) — следует ли отделу закупок дождаться окончательного утверждения или продолжить работу?
A: Отдел закупок должен дождаться полного утверждения URS перед публикацией запроса предложений (RFQ). В черновом варианте URS формулировки, касающиеся характеристик локализации, остаются открытыми для пересмотра, а это означает, что цены в предложениях поставщиков будут рассчитываться исходя из требований, которые могут измениться, что создает почву для споров по поводу объема работ или повторного проведения тендера. Условие публикации RFQ не имеет практического значения, если документ, на котором оно основано, все еще подлежит внутреннему пересмотру.
Вопрос: Если поставщик отказывается предоставить функциональную проектную спецификацию на этапе подготовки коммерческого предложения, лишает ли это его права на участие в отборе?
A: Не автоматически, но их предложение следует рассматривать как технически неполное для целей оценки. FDS — это механизм, который обеспечивает сохранность прослеживаемости от URS до проектной документации до момента присуждения контракта. Поставщик, который не может или не желает предоставить даже предварительный FDS на этапе запроса предложений (RFQ), лишает заказчика объективных оснований для оценки того, действительно ли предлагаемый им проект соответствует заданным требованиям к локализации — этот пробел проявится в виде спора по объему работ после присуждения контракта, а не станет основанием для дисквалификации на этапе оценки.
Вопрос: На каком этапе ответственность за определение интерфейсов переходит от заказчика (в рамках технического задания) к подрядчику EPC или инженерной бригаде на объекте?
A: В URS должны быть определены все границы взаимодействия, влияющие на функцию локализации рисков или объем валидации, — включая условия подачи инженерных сетей, точки интеграции систем управления и места физического подключения. Все, что в статье описывается как требующее уточнения в запросе предложений (RFQ) в отношении ролей и обязанностей сторон, занимающихся строительством, технологическими процессами и системами управления, подразумевает, что в URS уже зафиксированы технические границы; затем в RFQ распределяется договорная ответственность за каждую сторону этой границы. Если в URS какой-либо интерфейс остаётся неопределённым, никакое последующее уточнение в RFQ не сможет полностью исправить эту ситуацию — поставщик просто рассчитает цену, исходя из собственных предположений.
Вопрос: Необходима ли исходная смета расходов, если для проекта уже утвержден финансируемый бюджет в рамках внутреннего планирования капитальных вложений?
A: Да, поскольку утвержденный бюджет — это не то же самое, что базовая смета, привязанная к объему работ. Цель базовой сметы затрат заключается не в обосновании финансирования, а в том, чтобы дать руководителю проекта ориентир для оценки запросов на изменение объема работ после присуждения контракта. Без сметы затрат, привязанной к подписанному техническому заданию (URS), графику и плану выполнения работ, отсутствует объективный критерий для определения того, отражает ли заказ на изменение после присуждения контракта реальное увеличение объема работ или же поставщик компенсирует заниженную цену в тендерном предложении. Утверждение финансирования без базовой сметы, привязанной к объему работ, делает контроль за объемом работ полностью зависимым от коммерческих переговоров.
Вопрос: Применимы ли рекомендации, приведенные в этой статье, в равной степени как к закупкам индивидуально разработанных систем локализации у одного поставщика, так и к конкурентным процедурам запроса предложений с участием нескольких поставщиков?
A: Требования к прослеживаемости — полный URS, FDS на этапе предложения, четко определенные ответственные за валидацию, конкретизированные протоколы передачи — действуют в обоих случаях, но последствия их несоблюдения различаются. В условиях конкурентной процедуры нечеткие требования в запросе предложений приводят к появлению предложений с несопоставимым объемом работ, что делает оценку на основе цены вводящей в заблуждение. При закупках у единственного поставщика такие же упущения полностью перекладывают преимущество на сторону поставщика еще до заключения контракта, поскольку отсутствует конкурентное давление, заставляющее придерживаться консервативных оценок объема работ. Требования к подготовке остаются одинаковыми; профиль риска, связанный с их игнорированием, меняется в зависимости от коммерческой структуры.
