Системы управления проектными данными в области промышленного и гражданского строительства: наш опыт и понимание

Общая картина

В этой публикации мы попытаемся обозначить проблемы, которые накопились в результате более чем 15-летнего опыта работы в сфере создания систем управления проектными данными в промышленном и гражданском строительстве (ПГС), а также в других отраслях. В настоящее время состояние дел в области автоматизации проектных организаций характеризуется наличием различных факторов, на фоне которых с тем или иным успехом проводится внедрение и развитие информационных технологий. К основным реалиям, на наш взгляд, нужно отнести:

• наличие подходов к поддержке жизненного цикла:
  • PLM,
  • BIM;
• проблемы сбора проектных данных и управления ими:
  • структурированные и неструктурированные данные,
  • различное понимание термина «Системы управления проектными данными»,
  • различное понимание терминов, связанных с процессом проектирования, умышленная или неумышленная их подмена,
  • невозможность на 100% совместить несколько разных методов и инструментов проектирования;
• прочие факторы:
  • ментальность,
  • несовершенство нормативных актов,
  • «непоколебимые традиции».

О вопросах терминологии

По роду деятельности нам часто приходится общаться с представителями проектных организаций на самых разных уровнях: в производственных подразделениях, в ИТ-службах, с высшим руководящим составом. Всё чаще и чаще звучат термины, которые до конца не ясны, часто подменяют друг друга. Благодаря эффективной или, наоборот, малоэффективной работе компаний — поставщиков ИТ-решений по созданию мнения о продвигаемых средствах и технологиях, эти термины часто воспринимаются как «панацея, единственно верное решение», призванное «немедленно поднять эффективность производственных процессов, а как следствие — прибыль» в наше «непростое рыночное время» (приведены реальные высказывания). Наиболее часто упоминаемые из таких неологизмов: модель, PLM, BIM, система управления проектными данными, жизненный цикл, управление проектами, управление проектированием...

Позволим себе другой термин — «проект как Design», который описан и существует в терминах другой дисциплины — Design Management. Несмотря на «неблагозвучность» («Мы не рекламно-дизайнерское бюро, а проектная организация!» — очередная цитата), именно этот термин лучше всего определяет управление проектной деятельностью (не проектом как Project, да простит нас читатель, а производством ПСД), что так понятно нашим заказчикам.

Много путаницы возникает вокруг термина «модель». Смеем заверить читателей, что его трактовка даже в области автоматизации проектной деятельности без «необходимых дополнений» очень широка. Так, существует понятие «3D-модель» — результат работы в 3D-САПР, и понятие «информационная модель». В первом случае речь идет о 3D-графике, как правило, содержащей различные атрибуты, например те или иные характеристики арматуры, конструкций, трубопроводов и прочих конструктивных элементов проектируемого при помощи 3D-САПР объекта, его конструкций и компонентов. При этом в качестве таких атрибутов может быть использована информация, связанная с различными аспектами той или иной стадии жизненного цикла (ЖЦ) объекта. Например, на стадии ЖЦ «Проектирование и строительство» такими атрибутами могут быть данные материально-технического обеспечения (МТО) (изделия, оборудование, материалы) и их отдельные характеристики (диаметры, массы, геометрические размеры и т.д.). На стадии ЖЦ «Эксплуатация» наиболее востребована «техническия атрибутика» эксплуатируемого объекта (температура, влажность, давление, параметры технологических процессов, связанные с производственной деятельностью объекта, например технологической установки).

Термин «информационная модель» несколько шире. Вовсе не обязательно, что информация об объекте представлена в виде 3D-графики с упомянутой выше атрибутикой. Несомненно, информационная модель может быть построена и таким способом. Хотя в ряде случаев 3D-графика необязательно является «центром информационной модели». Всё зависит от конкретного объекта моделирования и принципов поддержки ЖЦ, например от того, как построена система управления проектными данными. Часто бывает, что в информационную модель включают 3D-модели, вовсе не являющиеся «ее центром». В ряде случаев информационная модель может вообще не содержать 3D-модели.

Подробнее остановимся на новых технологиях, часто использующих моделирование. Проектирование в области ПГС идет тем же путем, который был сравнительно недавно пройден нашими коллегами из сферы машиностроения, авиастроения, приборостроения, судостроения. В этих областях уже довольно давно говорят о технологиях поддержки жизненного цикла изделия: CALS, ИПИ, PLM. Сравнительно недавно в ПГС начался бум (иначе не скажешь), связанный с поддержкой жизненного цикла объекта. При этом всё чаще говорится о «модели».

Постараемся расставить все точки над «i». Графическая информация 3D-модели может использоваться «в центре» технологии поддержки ЖЦ объекта. При этом 3D-графика дополняется разными атрибутами, которые в различных технических реализациях имеют «разную физическую природу» (внешние базы данных (БД), БД конкретных САПР, «ручное» добавление значений). В любом случае такие атрибуты образуют БД, связанную с 3D-моделью, либо «встроенную» в 3D-модель (зависит от реализации). При этом 3D-графика часто выполняет функции удобной навигации, визуализации, взваливает на себя функционал пользовательского интерфейса. На основе использования 3D-графики «в центре» информационной модели и реализована технология BIM. Мы предлагаем называть такую информационную модель 3D-центричной. Хотя отметим, что BIM вовсе не отрицает связь с внешними БД. Более того, всё чаще в моделях применяется информация из таких БД. При этом, как правило, точкой доступа к информации внешних БД для пользователя является 3D-графика. Вопросы «степени отношений» с внешними БД определяются производителем решений и обусловлены в конкретных случаях лишь техническими причинами, политикой создания решения и ведения бизнеса.

Мы вынуждены опять вернуться к вопросу терминологии, поскольку аббревиатура BIM имеет два значения, существенно различающиеся при переводе на русский язык: Building Information Modeling — информационное моделирование зданий (процесс) и Building Information Model — информационная модель здания (далеко не процесс). Кроме того, заметим, что BIM без B превращается в «информационную модель» (следуя логике родного языка), центром которой необязательно является 3D-модель, да и, вообще, 3D-графика в информационной модели может отсутствовать...

Очень часто приходится слышать, что BIM — единственно правильное решение и цель современной автоматизации для поддержки ЖЦ. Постараемся быть объективными и пояснить, почему это далеко не всегда так.

При моделировании несложных с точки зрения технологии строительства производственных и технологических процессов (да простят меня представители гражданского строительства!) объектов, таких как, скажем, жилой дом, BIM часто является очень удачным решением. Действительно, использование одной 3D-САПР на стадии ЖЦ «Проектирование» эффективно. В созданную на этом этапе ЖЦ 3D-модель могут быть сравнительно нетрудоемко добавлены необходимые атрибуты. Такая модель может быть облегчена (применяются «легкие» форматы графики, поскольку для последующих этапов ЖЦ графика, созданная на стадии проектирования, избыточна). После такой адаптации к дальнейшей жизни модель может быть передана на последующие стадии ЖЦ.

В случае же проектирования сложного промышленного объекта круг дисциплин очень широк и использование одной 3D-САПР просто невозможно. Применяется, как правило, несколько САПР (не все 3D!); кроме того, существует огромное количество неструктурированных данных, иногда даже и в электронных форматах. Да и о «бумажной» документации забывать пока не стоит. Далее под неструктурированными данными мы будем понимать необходимые для нашей модели значения атрибутов, которые невозможно получить из содержащего их источника с требуемыми достоверностью, степенью автоматизации и скоростью. Например, сканированная таблица технических параметров насоса или та же таблица в бумажном (например, нормативном) документе, несомненно, содержит необходимые атрибуты для модели. Для получения значений из таких источников и добавления их в модель требуется выполнить ряд действий (как правило, «вручную» найти, прочесть и записать). Если же данные структурированы, например, в таблицах СУБД, то эти же самые действия могут быть практически полностью автоматизированы и времени на них будет тратиться гораздо меньше.

Эксплуатация объекта гражданского строительства (еще раз просим прощения у специалистов в этой области!) на несколько порядков проще, чем эксплуатация, скажем, химического комбината или электростанции. Действительно, говоря языком заказчика, при эксплуатации жилого здания в основном поддерживаются следующие системы: «Водопровод и канализация», «Электрика и освещение», «Отопление, вентиляция и кондиционирование», которые в жилом здании несколько проще, чем на производственном объекте. Поэтому на стадии ЖЦ «Эксплуатация» использовать 3D-модель «в центре» информационной модели жилого здания очень удобно. При падении температуры в помещении с помощью трехмерной навигации несложно найти соответствующий датчик, элементы системы отопления, технические характеристики, содержащиеся в атрибутах, эксплуатационную документацию, руководство по замене, сведения о поставщиках, возможных заменах на аналогичное оборудование и т.д.

При эксплуатации предприятия, даже если и удалось бы создать его полную 3D-модель, содержащую в атрибутах максимальное количество параметров, в случае отклонения важных технологических характеристик «не спеша бродить по 3D» просто недопустимо. При повышении концентрации газа на химическом производстве или, не дай Бог, угрозе неуправляемой реакции на АЭС должна сработать автоматика. Если клапаны не закрылись или стержни в рабочую зону не сбросились, «бродить по 3D» в поисках решения нет времени — применяются резервные способы выхода из аварийной ситуации, заранее проработанные и выполняемые соответствующим персоналом на автомате, опять же далекие от применения трехмерной модели.

В связи с этим подчеркнем, что, на наш взгляд, технология поддержки жизненного цикла на основе 3D-центричной модели (например, BIM) может использоваться в области гражданского строительства. В сфере проектирования, строительства и эксплуатации промышленных объектов BIM вряд ли применима в масштабе всего предприятия. Да и первая буква в аббревиатуре BIM, на которой внимание ранее не акцентировалось, обозначает Building, то есть в наиболее точном переводе — «здание» (термин из гражданского строительства и термин, обозначающий лишь некую часть завода, фабрики, электростанции, верфи и прочих промышленных объектов).

Чтобы окончательно запутать читателей, сообщим, что также существуют термины PIM (Plant Information Modeling) — информационная модель завода и сPLM — система управления жизненным циклом объекта капитального строительства.

О «непримиримых технологиях»

Изначально переход к компьютеризованным средствам проектирования включал внедрение двумерных САПР. Вся технология «плоского проектирования», по сути, пытается максимально повторить принципы и подходы проектирования на кульмане. Результатом работ является ПСД в электронном виде, сгруппированная по томам и/или комплектам.

Для хранения разрабатываемой и/или разработанной ПСД в электронном виде может применяться банальный способ — хранение в файловой системе. При этом аналогом разделов проекта, томов, комплектов, а также структурных единиц «складирования ПСД», например, узлов, зданий сооружений зачастую являются каталоги (папки), имеющие соответствующие обозначению имена. Аналогом же документов являются файлы, размещенные в соответствующих папках (аналог тома или комплекта). При этом файлы именуются в соответствии с обозначением того или иного чертежа комплекта. Несколько усложненный способ подразумевает использование СУБД. В этом случае все структурные элементы ПСД и непосредственно файлы имеют атрибутивные карточки, по которым в дальнейшем возможен поиск, сортировка и группирование документов. Несомненно, второй способ более прогрессивен. Понятие «электронный документ» соответствует определению ГОСТ 2.051-2006 (ЕСКД. Электронные документы. Общие положения).

Но и тот и другой способ — большей частью попытка повторения работы с «бумагой», естественно, с учетом того, что используются другие средства проектирования, имеющие соответствующие особенности. Например, «проводить изменения в поле чертежа, если его читаемость не нарушается», приемлемо на бумаге, а в электронном документе, согласно приведенному выше ГОСТу, изменения проводятся в новой версии. С появлением средств трехмерного моделирования принципиально изменилась сама методика ведения проектных работ. Использование 3D-САПР не соответствует ранее принятым подходам к «плоскому проектированию», имеет ряд преимуществ, например, высокое качество ПСД за счет исключения коллизий, высокую производительность, более привлекательные финансово-экономические показатели. Кроме того, появилась нормативная база. Но так ли всё безоблачно?

Авторы статьи проводили небольшой эксперимент — в многочисленной аудитории представителей проектных организаций в области ПГС просили отозваться тех, кто не отгружает заказчику «плоскую ПСД» (тома и комплекты тех или иных марок), а отгружает только трехмерную модель, по своим параметрам соответствующую законодательству, легитимность которой подтверждена электронной цифровой подписью (ЭЦП) (реализованной на основе Федерального Закона)... Читатель догадывается о результатах опроса?

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

• использование САПР различных производителей, и далеко не только 3D (о какой единой 3D-модели может идти речь?);
• невозможность применения нормативной базы;
• ментальность;
• традиции;
• необходимость качественного скачка к новой технологии, при современных подходах и средствах часто просто несовместимой с «традиционной» технологией.

Таким образом, при всех прогрессивных и положительных аспектах применения 3D-САПР ситуация по отношению к «плоскому» проектированию напоминает мытарства Остапа Бендера со сценарием «Шея», который должен быть только либо «немым», либо «звуковым». Напомню, что сценарий не был экранизирован по причине того, что «немого кино уже нет», а «звукового кино нет еще».

Различные точки зрения на построение системы управления проектными данными

Точка зрения 1

Сразу отметим, что цель публикации — не «научить и рассказать, как надо», а, скорее, показать, какие есть подходы и варианты, позволяющие автоматизировать управление проектными данными с учетом описанных в предыдущих разделах реалий. Забегая вперед, ответим на постоянно задаваемый вопрос: «Какую конкретно систему управления проектными данными вы посоветуете?» (Цитата.) Дело в том, что говорить о том или ином решении можно, лишь поняв то, какими проектными данными вы собираетесь управлять, какие используете САПР и как у вас поставлена методика самого процесса проектирования, что является источником данных, что и кто потребляет данные... Перечень вопросов далеко не полный. При этом ответы должны учитывать факторы, описанные в предыдущих разделах статьи.

Существует наиболее распространенная точка зрения о том, что представляет собой СУПД. В этом случае под термином «проектные данные» понимается чуть ли не вся информация, порождаемая на стадии проектирования. Такая СУПД, естественно, «отражает чаяния» основных участников процессов работы с информацией на стадии ЖЦ «Проектирование» — проектные организации. Прежде всего, такая СУПД — единая среда, позволяющая накапливать данные, разделять права доступа к ним, автоматизировать различные процессы, связанные с управлением этими самыми данными, например процессы разработки, обмена между проектными специальностями, выгрузки для внешних потребителей, получения данных от внешних исполнителей, проведения экспертиз и т.п.

Схема СУПД, в которой реализованы перечисленные подходы, приведена на рис. 1.

Рис. 1. Схема СУПД

Идеология такой СУПД заключается в следующем:

• основные типы данных, которые накапливает и обрабатывает СУПД, приведены в верхней части рисунка;
• данные порождаются и потребляются различными источниками. Сама СУПД никаких данных не порождает. Исключением являются отчеты и некоторые документы, автоматическое формирование которых возможно в виде документов-отчетов и/или файлов со структурированными данными, например перечень основных комплектов, состав комплекта, отчеты по объемам данных, документов, состоянию процессов автоматизируемых СУПД и т.д.;
• к источникам данных относятся САПР, расчетные программы, текстовые редакторы, БД МТО и ERP, внешние организации и т.д. Эти источники выдают данные как в структурированном, так и в неструктурированном виде (например, результаты работы в САПР) и/или потребляют их (например, при отгрузке ПСД на экспертизу или заказчику);
• для СУПД процесс разработки данных является «таинством», а сам набор источников данных — «черным ящиком».

Основным «преимуществом» такой СУПД является отсутствие необходимости затрат на разработку интеграционных решений с источниками данных, отсутствие «глобальных изменений» в традиционных бизнес-процессах. Несомненно, при переходе на электронное управление проектными данными реинжиниринг неизбежен, но он, как правило, минимально захватывает непосредственно методику проектирования, работы с САПР по сравнению с другими подходами.

Основным «недостатком» такой СУПД является то, что очень часто управление проектными данными в такой системе сводится в основном к управлению документами — результатами работы источников (см. рис. 1). Это связано с низкой степенью интеграции. При этом часто в таких документах данные неструктурированы.

Отметим, что слова «преимущество» и «недостаток» взяты в кавычки. Причина проста: в 50% конкретных случаев, в зависимости от методики проектирования в проектной организации, используемых средств — источников данных, да и вообще от специфики самих проектируемых объектов «преимущество» можно указывать как «недостаток», и наоборот.

Точка зрения 2

Такая точка зрения на СУПД преобладает на стадиях ЖЦ «Строительство» и «Эксплуатация» объекта. Упрощенная схема системы на стадии ЖЦ «Эксплуатация» объекта приведена на рис. 2.

Рис. 2

Логика работы системы следующая:

• существует БД значений атрибутов объекта и его составляющих (эти значения, говоря принятой в РФ терминологией, содержатся в исполнительной документации, на Западе есть понятие «As Build» — «Как построено». Не будем подробно останавливаться на всех способах получения такой БД, ибо диапазон велик — от «ручной» корректуры документации до 3D-сканирования;
• существуют датчики контроля значений, показания которых поступают в систему (не будем углубляться в описание работы в дискретных режимах или режиме реального времени);
• полученные значения сравниваются соответствующим механизмом на предмет отклонения;
• результаты работы отображаются через пользовательский интерфейс.

Вернемся к началу статьи, где мы говорили о технологии BIM. Дело в том, что в ряде случаев пользовательский интерфейс такой системы, представленной в виде трехмерной модели, очень удобен. Напомним: мы считаем, что наиболее рационально использовать 3D-визуализацию в тех случаях, когда речь идет об объекте-здании со сравнительно несложными технологическими процессами, чаще — о жилом здании или отдельном здании на предприятии. При поддержке на стадии ЖЦ «Эксплуатация» сложного производственного, энергетического или другого сравнимого объекта использование 3D не «всегда удобно», а иногда и просто неуместно. Впрочем, тут мы начинаем вторгаться в область автоматизированных систем безопасности промышленных объектов, что не является предметом рассмотрения этой публикации.

Точка зрения 3

Схема такого подхода к реализации СУПД приведена на рис. 3.

Рис. 3

Логика работы по схеме (см. рис. 3) следующая:

• проектные данные поступают в единую БД СУПД из источников — САПР. При этом данные:
  • в основном структурированные,
  • представляют собой атрибуты моделей (их частей), причем способы добавления значений таких атрибутов могут быть самыми различными («ручной ввод» через пользовательский интерфейс САПР, подключение к внешним БД, например каталогам стандартных изделий и материалов, БД MTO, БД нормативных документов и т.п.);
  • существует инструментарий-надстройка над БД, которая позволяет работать с данными, получать отчеты и т.д.

«Пионерами» подобного подхода являлись производители машиностроительных САПР, создавшие PDM/PLM-системы. Основное их отличие в том, что для машиностроительных САПР подобные системы создавались изначально для одного «родного» САПР: Windchill для ProE, Teamcenter для Unigraphics, Enovia для Catia и пр. Несомненно, производители утверждают, что «есть интерфейсы с любыми САПР»... В области проектирования для ПГС, в отличие от машиностроения, как правило, на крупных проектах используются «линейки» САПР, автоматизирующие проектирование в той или иной области (марке, проектной специальности). Поэтому подобные СУПД изначально создавались для нескольких САПР. В качестве примеров подобных решений можно привести систему Autodesk Vault от компании Autodesk и систему ProjectWise от компании Bentley. Такой подход к управлению проектными данными в настоящее время имеет некоторые «размытости» в понимании того, как должна выглядеть конкретная реализация, ибо все СУПД — настраиваемые среды, которые необходимо как-то адаптировать. Основными проблемами, с которыми придется столкнуться тому, кто пойдет подобным путем реализации СУПД, можно назвать следующие:

• система — детище производителя одной линейки САПР. Несомненно, в этой линейке она способна «собирать» необходимые значения — проектные данные и управлять ими. Что касается интерфейсов с САПР других производителей, то, как заявляют поставщики, «есть интерфейсы с любыми САПР» (цитата). С одной стороны, производитель подобной системы, естественно, стремится вывести ее на рынок, создав в том числе и механизмы взаимодействия для «неродных» (говоря прямо — конкурирующих) САПР. С другой стороны, любой производитель, совершенствуя свой САПР и, cкажем прямо, защищая свой уникальный продукт и бизнес, довольно часто меняет форматы данных, интеграционные механизмы. При этом, несомненно, реализуется совместимость со своей «предыдущей» продукцией... А вот совместимость с продукцией «сторонних» производителей систем управления проектными данными (того типа, о котором говорим сейчас) поддерживать просто бессмысленно, а зачастую и невыгодно с точки зрения бизнеса (если есть своя «линейка», позволяющая успешно делать то же, что и конкурентная). К тому же подобная несовместимость вынуждает конечного пользователя писать интерфейс к новой версии «чужого САПР» за свой счет или использовать «родную» для САПР СУПД;
• методика проектирования при использовании различных инструментов отличается. Какие данные существенны? Какие должны передаваться, накапливаться и обрабатываться в СУПД? Есть еще много вопросов, ответ на которые можно получить, лишь осуществив «постановку» основных принципов работы с конкретными САПР в той или иной области...Поэтому говорить о «выборе конкретной СУПД» без выполнения этих мероприятий преждевременно;
• что делать с неструктурированными документами и проектными данными, не порождаемыми САПР, которые всё равно есть и будут?
• такого рода система опять сталкивается с противоречиями, о которых мы говорили ранее. Принятые и устоявшиеся принципы проектирования, проведения изменений, нормативная база и т.д. пока что делают невозможным только такой подход (СУПД по такой схеме в «чистом виде»).

Наша точка зрения на СУПД

Под «идеальной СУПД» будем понимать такую систему, которая управляет всеми типами проектных данных, реально существующими в современных условиях (в проектных организациях РФ), учитывает уровень автоматизации, развитие нормативной базы, принципы проведения проектных работ, ментальность, традиции, наличие двух основных подходов (2D и 3D) и прочие факторы.

Пример управления «идеальной СУПД» приведен на рис. 4.

Рис. 4

Такая СУПД должна управлять двумя большими группами данных:

• структурированными;
• неструктурированными.

К первой группе относятся данные из таблиц, БД MTO и ERP, планово-ресурсные показатели из систем ресурсного планирования, СRM, договорных систем. Несомненно, такими данными являются атрибуты 3D-моделей. Структурированию подлежат данные, содержащиеся в форматах файлов MS Excel, MS Word (если они содержатся в структурированных элементах документов, например в таблицах, колонтитулах и т.д.). Файл DWG изначально имеет структуру.

В то же время существует огромный пласт неструктурированных проектных данных. В основном они содержатся в документах. Получить такие данные с целью дальнейшей обработки, управления в СУПД не просто, не всегда окупаемо, далеко не всегда целесообразно. В таких случаях документ — носитель проектных данных рассматривается как некое «неделимое целое». Например, если формат DWG является структурированным, это далеко не всегда означает, что получить данные из него просто. При отсутствии должной стандартизации текст может быть, например, просто текстом, значением атрибута блока и т.д. Отсутствие шаблонов, стандартов, позволяющих даже в структурируемом приложении получать произвольно «разбросанные» в структуре файла данные, ведут к сложностям, а иногда и невозможности доступа к таким данным. Есть группа форматов, применяемых в проектной деятельности, доступ к данным «внутри которых» еще сложнее — сканированные образы чертежей, таблиц и т.п. Конечно, «можно всё автоматически распознать». А вы пробовали? Это — отдельная большая тема. Просим читателя пока принять на веру тот факт, что распознавание носит ярко выраженный вероятностный характер и далеко не всегда «овчинка стоит выделки» в связи с низкой рентабельностью.

Не хочется возвращаться к теме «войны технологий» (2D и 3D), но для реализации «идеальной СУПД» эта война должна как-то закончиться. Причем совсем не важно, как, но пока нет никакого «компромисса сторон» или «победы одной из сторон», вопрос, как создать «идеальную СУПД», остается без ответа.

Выводы

Не будем никого интриговать и обманывать, приводя примеры «идеальной СУПД». Честно признаем следующее:

• в настоящее время управление проектными данными в большинстве случаев сводится к управлению документами;
• СУПД, управляющая структурированными данными, часто «упускает» данные, содержащиеся в неструктурированных документах, и наоборот;
• сегодня существует ряд предприятий, использующих отдельно СУПД, управляющую неструктурированными данными (по сути, навороченный «электронный архив»), и СУПД, управляющую структурированными данными (по сути, систему управления спецификациями и ведомостями или недоразвитую PDM-систему);
• авторы не видят путей реализации «идеальной СУПД» в существующих нормативных и ментальных (традиционных) реалиях;
• на ряде предприятий существуют реализации, которые в той или иной мере приближаются к «идеальной СУПД», но этот опыт фактически невозможно тиражировать на другие предприятия.

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

Мы очень надеемся, что наше, вероятно, сумбурное изложение проблем заставит наших партнеров и в первую очередь наших заказчиков задуматься, ради чего мы все вместе пытаемся внедрить современные технологии проектирования и управления проектными данными. Для нас ответ очевиден — это повышение качества и сокращение сроков проектирования и строительства промышленных и гражданских объектов.

Список литературы:

1. Рындин А., Галкина О., Благодырь А., Кораго Н. Автоматизация потоков документации — важный шаг к созданию ЕИП // REM.2012. № 4. С. 42-48.
2. Чиковская И., Данилова Л., Лянда А. Переход на трехмерную технологию проектирования станций Санкт-Петербургского метрополитена на основе вертикальных решений компании Autodesk, Inc. // САПР и графика.2012. № 9. С. 108-112.
3. Малашкин Ю., Шатских Т., Юхов А., Галкина О., Кораго Н., Рындин А., Фертман И. Опыт разработки системы электронного документооборота в ОАО «Гипроспецгаз» // САПР и графика. 2011. № 12. С. 96-98.
4. Долгалев Д. Обмен данными между различными системами // САПР и графика. 2011. № 9. С. 73-75.
5. Сладковский А., Кузьмин Е., Шалаева О. Информационная система визуализации 3D-моделей на базе Intergraph SmartPlant Review // САПР и графика. 2011. № 9. С. 2-5.
6. Тучков А., Максимов Н. Работа с данными на разных этапах жизненного цикла промышленных объектов с использованием SmartPlant Enterprise // САПР и графика. 2011. № 8. С. 2-5.
7. Воробьев А., Данилова Л., Игнатов Б., Рындин А., Тучков А., Уткин А., Фертман И., Щеглов Д. Сценарий и механизмы создания единого информационного пространства // CADmaster. 2010. № 5. С. 48-51.
8. Латыпов Е., Хуснутдинова К., Юмашев Э. Опыт применения технологии SmartPlant Enterprise на протяжении всего жизненного цикла объектов обустройства нефтяных и газовых месторождений // CADmaster. 2010. № 5. С. 80-83.
9. Санев В., Суслов Д., Смирнов С. Использование информационных технологий в ЗАО «ЦНИИ судового машиностроения» // CADmaster. 2010. № 3(53). С. 29-32.
10. Данилова Л., Щеглов Д. Методология создания единого информационного пространства ракетно-космической отрасли // REM.2010. № 6. С. 14-15.
11. Воробьев А., Пивоваров В., Щеглов Д., Алимов М., Ведерникова Т., Данилова Л., Рындин А., Тучков А., Фертман И. Концепция создания единой среды проектирования, как первый этап обеспечения жизненного цикла изделий (опыт ОАО «КБСМ») // CADmaster. 2008. № 2. С. 18-20.
12. Грачев В. Современное состояние дел с электронными архивами // CADmaster. 2008. № 2. С. 92-97.
13. Тучков А. Внедрение электронных архивов инженерной документации // CADmaster. 2008. № 3. С. 42-49.
14. Чиковская И. Тихая революция. Электронный кульман или информационная модель здания // CADmaster. 2008. № 3. С. 88-92.
15. Рындин А., Тучков А., Фертман И. Ступени внедрения ИПИ-технологий. Опыт реализации электронного документооборота. Материалы конференции «Моринтех-практик информационные технологии в судостроении — 2006», 2006 г.
16. Алимов М., Рындин А., Тучков А., Фертман И. Ступени внедрения ИПИ-технологий. Опыт реализации электронного документооборота // REM. 2006. № 2.
17. Рындин А., Рябенький Л., Тучков А., Фертман И. Ступени внедрения ИПИ-технологий // Судостроение. 2005. № 4.
18. Ведерникова Т., Смирнов С. Использование современных достижений информационных технологий в ЦНИИ судового машиностроения // CADmaster. 2005. № 5. С. 31-33.
19. Чиковская И. Autodesk Architectural Desktop — единая среда для коллективной работы над проектом // CADmaster. 2005. № 2. С. 63-65.
20. Галкина О., Рындин А., Рябенький Л., Тучков А., Фертман И. Построение информационных моделей изделий судостроения на различных стадиях жизненного цикла с элементами логистической поддержки. Сборник докладов конференции «Технологии информационной поддержки жизненного цикла сложных изделий в российской промышленности», 2004 г.
21. Бененсон А., Рябенький Л., Тучков А., Шептунов И. Опыт организации системы сквозного проектирования — изготовления для судостроения. Сборник докладов конференции «Роль и значение „Адмиралтейских верфей“ в научно-техническом развитии российского и мирового судостроения», 2004 г.
22. Голованов В., Рябенький Л., Давыденко С., Острокопытов Д., Тучков А., Фертман И. Опыт внедрения комплексных программно-аппаратных решений САПР и электронного архива инженерной документации на судостроительных предприятиях. Cборник докладов конференции «Роль и значение „Адмиралтейских верфей“ в научно-техническом развитии российского и мирового судостроения», 2004 г.
23. Рындин А. Ввод сканированных документов в электронный архив предприятия // CADmaster. 2003. № 1. С. 41-43.
24. Рындин А. Архив без пыльных полок, или Способы организации архива предприятия // JetInfo. 2002. 10/113.
25. Фертман И., Тучков А., Попов К. Аппаратное обеспечение электронного технического документооборота // CADmaster 2001. № 8/3.
26. Сомов И., Лисицын Н., Порфирьев Д., Раменский В. Опыт использования ГИС AutoCAD Map 2000 в условиях нефтеперерабатывающего завода ООО «Киришинефтеоргсинтез» // CADmaster. 2001. № 1. С. 26-29.
27. Давыденко С., Павлович М. Реализация системы конструкторского документооборота и решение проблемы тиражирования документации в ЦКБ МТ «РУБИН» // CADmaster. 2000. № 5. С. 16-19.