При проектировании системы электроснабжения над одним решением могут одновременно работать заказчик, проектный институт, генеральный подрядчик, производители оборудования, монтажные организации и другие участники.
У каждого из них собственная зона компетенции.
Проектировщик знает объект и отвечает за принятые проектные решения. Производитель глубже знает возможности и ограничения собственного оборудования. Монтажная организация работает непосредственно с условиями площадки. Заказчик располагает информацией о технологическом процессе и планах развития объекта.
Поэтому распределение инженерных задач между участниками само по себе не является недостатком проекта.
Проблемы начинаются тогда, когда вместе с задачей не передаются необходимые исходные данные, а граница между консультацией производителя и проектным решением становится неопределенной.
Что означает делегирование инженерной задачи
Само слово «делегирование» здесь требует уточнения.
Проектировщик может обратиться к производителю шинопроводной системы для подбора оборудования, проработки трассы, формирования спецификации, проверки возможности изготовления определенной конфигурации или получения технической информации.
Это позволяет использовать компетенции специалиста, который ежедневно работает с конкретным оборудованием.
Но передача такой задачи не означает автоматическую передачу ответственности за всю систему электроснабжения.
Производитель работает в пределах полученных исходных данных и собственной компетенции.
Например, он может предложить конфигурацию шинопровода для заданной трассы и требуемых параметров. Но определение расчетной нагрузки объекта, построение всей схемы электроснабжения и принятие проектных решений находятся в другом контуре ответственности.
Поэтому первый принцип эффективного взаимодействия прост:
делегировать нужно конкретную инженерную задачу, а не неопределенную ответственность за результат всей системы.
Производителю недостаточно получить номинальный ток
На практике одна из главных проблем возникает из-за состава передаваемых исходных данных.
Запрос вида «нужен шинопровод на 1600 А» содержит слишком мало информации для полноценной проработки решения.
Одинаковый номинальный ток может относиться к совершенно разным объектам и условиям применения.
В зависимости от задачи производителю могут потребоваться:
- параметры проектируемой системы;
- расчетные нагрузки;
- необходимые характеристики оборудования;
- параметры короткого замыкания;
- схема и геометрия трассы;
- расположение точек подключения;
- условия эксплуатации;
- требования к конструктивному исполнению;
- информация о сопряжении с другим оборудованием;
- ограничения объекта;
- требования к дальнейшему расширению, если оно предусмотрено проектом.
Конкретный состав данных зависит от стадии и характера задачи.
Чем раньше становится понятно, какое решение требуется получить на выходе, тем точнее можно определить необходимый набор исходной информации.
Проектировщик отвечает за систему, производитель - за свое оборудование
Это принципиальная граница.
Производитель шинопровода обладает компетенциями в конструкции и применении собственной системы. Он знает доступные типоразмеры, конфигурации элементов, конструктивные ограничения и требования к монтажу своего оборудования.
Проектировщик рассматривает объект шире.
Он должен увязать шинопровод с источником питания, распределительным оборудованием, потребителями, аппаратами защиты, строительной частью и другими инженерными системами.
Поэтому консультация производителя не должна превращаться в ситуацию, когда отдельный элемент фактически проектируется вне контекста общей системы.
Рабочая схема выглядит иначе:
проектировщик формирует требования → производитель прорабатывает решение в пределах своего оборудования → результат возвращается проектировщику → проектировщик проверяет и интегрирует его в общую систему.
Это не лишнее согласование, а нормальный цикл инженерного взаимодействия.
Чем раньше подключается производитель, тем больше вопросов можно решить до поставки
Производителя оборудования часто привлекают тогда, когда основная часть проектных решений уже принята и необходимо получить коммерческое предложение или сформировать заказ.
Для стандартной задачи этого может быть достаточно.
Но в более сложных проектах раннее взаимодействие позволяет проверить решения до того, как их изменение станет дорогим.
Например, на стадии проработки трассы можно заранее уточнить:
- возможно ли изготовить предусмотренную конфигурацию;
- какие элементы потребуются;
- существуют ли конструктивные ограничения;
- какие пространства необходимы для монтажа;
- как организовать сопряжение с другим оборудованием;
- какие данные необходимо дополнительно получить от объекта.
В результате производитель не принимает решение вместо проектировщика, а предоставляет ему информацию, необходимую для более точной разработки проекта.
Именно в этом заключается практический смысл раннего вовлечения.
Техническое задание должно описывать не только оборудование
Еще один важный инструмент взаимодействия - техническое задание.
Если оно сводится к перечню номинальных характеристик, значительная часть требований остается незафиксированной.
Для инженерной проработки важно понимать не только что требуется поставить, но и в какой системе это оборудование должно работать.
Поэтому техническое задание и исходные данные должны давать достаточный контекст для конкретной задачи.
Особенно это важно при нестандартной конфигурации объекта, реконструкции действующего производства или необходимости интегрировать новое оборудование в существующую систему.
Чем больше существенной информации остается только в переписке и устных обсуждениях, тем выше риск, что разные участники работают с разным пониманием задачи.
Граница ответственности должна быть определена до возникновения проблемы
Фраза «это должен был учесть другой участник» обычно появляется слишком поздно.
Чтобы ее избежать, до начала работы полезно определить не только перечень участников, но и границы инженерной ответственности.
Например:
кто предоставляет исходные данные;
кто выполняет электротехнические расчеты;
кто определяет требования к оборудованию;
кто разрабатывает конфигурацию конкретной системы;
кто проверяет сопряжение со смежным оборудованием;
кто согласовывает изменения;
кто актуализирует документацию;
кто принимает окончательное проектное решение.
На сложных проектах такая схема может быть значительно подробнее.
Главное, чтобы инженерная задача не оказалась в промежутке между двумя зонами ответственности.
Изменение должно пройти обратный путь
Даже хорошо распределенная работа перестает быть управляемой, если изменения движутся только вперед.
Предположим, производитель получил исходные данные и подготовил конфигурацию шинопровода.
Позднее на объекте изменилось расположение технологического оборудования.
Если информация дошла только до монтажной организации, проектировщик и производитель продолжают работать с предыдущей конфигурацией.
Поэтому изменение должно возвращаться ко всем участникам, решения которых оно затрагивает.
Иногда потребуется только корректировка трассы.
В другом случае изменится спецификация.
В третьем необходимо повторно проверить часть проектных параметров.
Задача системы взаимодействия - не исключить изменения, а определить маршрут изменения внутри проекта.
BIM также требует распределения ответственности
При работе с информационной моделью появляется дополнительный уровень взаимодействия.
Проектировщик может использовать BIM-модель производителя, самостоятельно размещать оборудование или передавать часть проработки трассы специалистам производителя.
В любом варианте должно быть понятно:
- кто отвечает за исходную геометрию;
- кто размещает оборудование;
- какие параметры элементов являются достоверными;
- кто проверяет коллизии;
- кто актуализирует модель после изменения;
- какая версия считается рабочей.
Наличие общей цифровой среды не отменяет необходимость распределять ответственность.
Наоборот, чем больше участников используют одну модель, тем важнее определить правила работы с ней.
Монтажная организация - источник инженерной обратной связи
Монтажника также неправильно рассматривать только как исполнителя готового решения.
Именно на площадке окончательно проявляются фактические условия объекта.
Если обнаруживается расхождение с документацией или ограничение, которое невозможно было выявить ранее, эта информация должна возвращаться участникам, способным оценить инженерные последствия.
При этом задача монтажной организации - не самостоятельно перепроектировать систему непосредственно на площадке, если изменение затрагивает проектные параметры.
Ее роль - зафиксировать проблему, передать необходимые данные и реализовать согласованное решение.
Так сохраняется связь между фактической системой и документацией.
Что должен контролировать заказчик
При распределенной модели заказчику необязательно самостоятельно разбираться во всех технических деталях каждого элемента.
Но ему важно понимать архитектуру ответственности проекта.
Для управления достаточно получить ответы на несколько вопросов:
- кто отвечает за систему в целом;
- кто принимает окончательные инженерные решения;
- где находятся актуальные исходные данные;
- как производитель взаимодействует с проектировщиком;
- кто согласовывает замены оборудования;
- как обрабатываются изменения на площадке;
- кто актуализирует документацию после изменений.
Если на эти вопросы нет однозначных ответов, количество профессиональных участников само по себе не гарантирует управляемость проекта.
Партнерство - это не отсутствие границ
В инженерной среде часто используется формулировка «работать одной командой».
Но эффективное партнерство не означает размывания ответственности.
Наоборот, участники могут полноценно использовать компетенции друг друга только тогда, когда понятно, кто какую задачу решает и кто принимает итоговое решение.
Производитель может предложить более подходящую конфигурацию оборудования.
Монтажная организация - указать на ограничение площадки.
Проектировщик - оценить влияние предложения на систему в целом.
Заказчик - уточнить технологические требования.
Каждый участник добавляет информацию в общий процесс, но не подменяет компетенцию остальных.
«Для нас работа с проектными институтами и подрядчиками - это не передача готового каталога оборудования. Важно получить достаточно данных об объекте, проработать свою часть решения и вернуть проектировщику информацию, которую он сможет корректно встроить в общую систему», - отмечает коммерческий директор ГК «Терра-Ток» Алексей Козлов.
Эффективное делегирование сохраняет инженерную целостность
Сложный проект невозможно сделать сильнее простым увеличением количества участников.
Но и стремление сосредоточить все решения у одного специалиста не дает преимущества само по себе.
Результат определяется тем, насколько правильно распределены компетенции.
Для этого необходимо:
определить задачу → передать достаточные исходные данные → получить решение в пределах компетенции исполнителя → проверить его в контексте всей системы → зафиксировать результат → возвращать изменения всем затронутым участникам.
При такой организации проектный институт, производитель и подрядчик не дублируют работу друг друга.
Каждый отвечает за ту часть, в которой обладает необходимой компетенцией, а инженерное решение последовательно проходит между ними без потери контекста.
Поэтому эффективное делегирование - это не передача ответственности «куда-то наружу».
Это точное распределение инженерных задач при сохранении ответственности за целостность проекта.
