Сергей Голуб,
заместитель генерального директора по проектированию, ООО «Волгограднефтепроект»
Современное проектирование отличается от того, что было 10 лет назад, а тем более — 15-20 лет назад. Требования к квалификации, к знаниям, составу задач и участию проектировщика в процессе реализации (при закупках, строительстве, наладке и сдаче в эксплуатацию) возрастают как на законодательном уровне, так и со стороны заказчиков. И информационное моделирование уже не воспринимается как отдельная задача — она непосредственно связана с процессом и результатом проектирования. Как в текущих реалиях проектировщику «все успеть», при этом быть полноправным участником процесса, а не отрабатывать поручения прочих сторон, зависит от исходной стратегии проектирования и реализации проекта. Мы продолжаем развивать методологию декомпозиции, которая решает одновременно две задачи: упорядочить само проектирование и перейти на новый уровень взаимодействия между участниками, не нарушая внутренних «традиций» каждого.
Подобным вопросом, как правило, никто не задается. А если и задается, то ответ сводится к шаблонным представлениям процесса проектирования: для начала работ нужно техническое задание, исходные данные, требования заказчика… Спорить с этим сложно — эти данные действительно необходимы. А вот наполнение их может от проекта к проекту кардинально отличаться.
В одной из наших статей уже в далеком 2020 году мы рассуждали на подобную тему и представили свое видение по этому вопросу: проектирование начинается с эксплуатации. Там же был нами описан фундаментальный подход к моделированию (читай — начальной стадии проектирования) — декомпозиции объекта, в основе которого пространственно-функциональное деление объекта на части (рис. 1 и 2). Прошло уже целых пять лет, и данная методология при проектировании оказалась актуальной. Более того, она развивается, при этом развиваются и появляются инструменты для работы с декомпозицией и использованием ее результатов как для проектирования, так и для реализации проектов.
Рис. 1. Дерево объекта с документацией в СтРИМ
Рис. 2. Документация и 3D-модель узла в ИМАК
Давайте попробуем оттолкнуться от итогового результата. Что должно получиться в итоге? Сданный в эксплуатацию объект и — сейчас уже стало практически обязательным требованием — цифровая модель или актив объекта. Перед сдачей в эксплуатацию объект должен пройти пуско-наладочные работы, причем до этого каждая функциональная система должна быть готова как к испытаниям, так и механически. Это уже результат строительно-монтажных работ и планирования на уровне графиков. При планировании нужно учесть необходимые объемы материалов и оборудования для выполнения конкретных операций. Следовательно, эти объемы должны быть наглядно выделены в спецификациях к чертежам, а чертежи разработаны до начала запланированных работ по графику. Звучит все просто и логично. Недостающим звеном в этой цепочке обратного хода является поставка оборудования и материалов, проведение тендеров, подготовка технических требований и ведомостей заказа. Таким образом, само формирование закупочных ведомостей должно быть разделено исходя из видов закупаемого материала, возможности их поставки одним поставщиком и с учетом необходимости их к конкретному времени для монтажа.
Фактически мы говорим о том, что в современных условиях проектировщик должен не только предоставить оформленные решения в виде моделей, документов, требований, регламентов и т.д. для эксплуатации, но и учесть всю цепочку реализации — понимать технологию монтажа, формировать объемы для своевременных поставок и разработать документацию так, чтобы можно было обеспечить данную цепочку: документ — спецификация — объем — поставка — работа — сдача/приемка.
Конечно, данный сценарий идеализирован. Имеет ли проектировщик в настоящее время такую квалификацию, чтобы обеспечить подобную реализацию? Ведь в данном случае он должен фактически понимать организацию и логистику закупок, технологию монтажа, очередность испытаний составных частей объекта… Можно задать и другой вопрос — готов ли заказчик или подрядчик работать с таким квалифицированным проектировщиком и реализовывать проект по сценарию, заложенному проектировщиком? Или задачами по декомпозиции и планированию должна заниматься отдельная структура, а все участники проекта (заказчик, подрядчик, проектировщик) должны выполнять свою работу на основании такой проработанной философии по конкретному объекту? Последнее выглядит более вероятным сценарием, поскольку никто из участников процесса не вмешивается во внутреннюю работу друг друга, а взаимодействует на уровне локальных результатов и приемки/передачи их для реализации.
Сам процесс декомпозиции связан со следующими факторами: пониманием функционирования самого объекта (фактически, мы говорим о результате проработки основных технических решений), классификацией оборудования и материалов (разделение зон ответственности по поставкам, формирование ведомостей заказа), пониманием процесса монтажа (речь не столько о технологии и оптимальной последовательности работ, в том числе и готовность к проведению испытаний, сколько об оптимальном разбиении по объемам работ, позволяющим оперативно минимизировать риски, если что-то пошло не так). Данный процесс не имеет универсального алгоритма для каждого объекта (пусть даже мы говорим о промышленных или опасных производственных объектах) и в целом занимает достаточно продолжительное время. Стоит заметить, что к декомпозиции мы относим не только подготовку состава систем и разделение территории объекта на зоны/узлы/захватки. Речь идет также о формировании исходя из данного разделения структуры 3D-модели, состава разрабатываемых документов (не только проектной и рабочей, но и исполнительной, приемо-сдаточной, эксплуатационной — то есть любой, которая должна быть), ведомостей заказа, WBS-структуры графиков (ПНР — СМР — поставка — РД). Возникает вопрос — как формировать данную декомпозицию, когда в современном мире у каждого заказчика, как правило, свои требования и процедуры (например, по составу документации, тегированию оборудования и конструкций), а проектировщик имеет свои внутренние регламенты и процедуры работ? Ответ оказался на поверхности. Для любого заказчика важен результат, который должен быть представлен по его требованиям, но сама декомпозиция может выполняться по схеме исполнителя.
Рис. 3. Правила генерации документации в СтРИМ
И этот процесс вполне можно автоматизировать, формализовав требования заказчика и внутренние процедуры исполнителя в виде справочников, а затем синхронизировав их. После этого надо запустить процесс «генерации» и получить в первом приближении нужный состав данных (документов, 3D-моделей, WBS) с наименованиями, шифрами и прочими необходимыми атрибутами. В простейшем случае можно говорить о получении ГРД (главный реестр документации), причем в разной степени детализации — исходя из задач (рис. 3). А далее уже каждый участник процесса использует эти результаты для организации своей работы: система документооборота и 3D-моделирования у проектировщика, система планирования (в том числе и 4D — рис. 4 и 5), у подрядчика (или заказчика, управляющей компании), портал для публикации текущего состояния дел, цифровые модели и т.д.
Рис. 4. График и статусы СМР в ИМАК (4D)
Рис. 5. План и факт СМР в ИМАК
Наш стандартный подход в таких случаях — формирование и отработка такого процесса на «подручных» средствах и инструментах, затем уже разработка программного продукта. Так было с ИМАК (Информационная модель актива, о которой мы писали в 2022 году — см. рис. 2), так и сегодня идет работа над созданием нового продукта — СтРИМ (Структурная разметка инженерной модели). Основные задачи Системы — полноценный модуль работы со справочной информацией (как заказчика, так и с внутренними требованиями), формирование на основе этой справочной информации декомпозиции объекта и генерация любых видов документации, обращающейся при реализации проекта. В первую очередь, так как мы все-таки занимаемся проектированием, речь идет о формировании Главного реестра документации и структуры 3D-моделей (рис. 6 и 7). Подход в инструменте простой — есть справочники, есть требования к наименованию и шифрам, на основе чего формируются правила генерации. Таких правил может быть сколь угодно много. Инструмент реализовывается в виде конструктора для простоты настроек под требования каждого проекта (мы помним, что требования заказчика имеют свойство меняться). Также в виде конструктора выполнен почти весь функционал — начиная от настройки модели данных и заканчивая формами импорта/экспорта информации (см. рис. 3). В настоящее время идет опытно-промышленная эксплуатация первого разработанного модуля, в основе которого — работа со справочной информацией, формирование декомпозиции объекта, правил генерации и на их базе — реестров документации в виде ГРД.
Рис. 6. Узлы в СтРИМ
Рис. 7. Узлы в ИМАК
Так с чего же все-таки начинается проектирование? Здесь мы не описываем уже ставшие стандартными процедуры: подготовку шаблонов документации, каталогов элементов 3D-модели… Обобщая сказанное выше — проектирование начинается с базовых технических решений, на основе которых можно готовить декомпозицию. Подготовили, настроили документооборот, систему трехмерного моделирования, определились с датами… И все участники процесса взаимодействуют исходя из данной декомпозиции и результатов работ каждого участника. При этом, как к этому результату приходит каждая сторона — дело уже соответствующего исполнителя.
