CADmaster

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

1. Актуальность проблемы построения оптимальной архитектуры проектной организации. Экономический кризис и связанная с ним минимизация себестоимости продукции

   Экономический кризис и связанные с ним негативные тенденции в виде падения спроса на рынке проектных услуг являются для проектных организаций стимулом для пересмотра маркетинговой политики и технологии производства.

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

   В качестве примера таких новых сегментов можно указать:

   • имитационное моделирование на заказ с применением дорогостоящих программных систем;
   • методологические разработки в предметной области проектирования объектов ТЭК с использованием новых и новейших информационных технологий (разработка баз данных и баз знаний нормативных документов, семантических сетей структурированных документов и т.п.);
   • хостинг проектной документации;
   • типовое проектирование с разработкой библиотек трехмерных параметрических моделей;
   • создание фонда автоматизированных методик инженерных расчетов и оформление его в виде специализированных программных продуктов.

   Архитектура проектной организации в соответствии с «процессным» подходом [1] и так называемой «теорией организации» [2] должна следовать за модификацией технологии производства, а степень оптимальности архитектуры проектной организации напрямую зависит от совершенства и структурной мобильности технологии на изменчивом рынке проектных услуг.

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

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

   Производительность труда, напротив, является фактором, хорошо поддающимся управлению. Низкий уровень оснащенности программным обеспечением и, как следствие, низкая производительность труда существенно снижают конкурентоспособность организации. «Молодые» проектные организации с низким уровнем предметной квалификации персонала, низким уровнем зарплат, но высокой технологической оснащенностью, а следовательно и высокой производительностью труда (в итоге — с низким уровнем себестоимости проектов) начинают успешно конкурировать со «старыми» участниками рынка.

   Все вышесказанное свидетельствует об актуальности проблемы совершенствования архитектуры проектной организации как следствия необходимости постоянной модификации и модернизации технологии производства.

2. Развитие рынка проектных услуг и связанный с этим рост уровня требований к проектной продукции

   Рынок проектных услуг находится в постоянном развитии. Развиваются методы проектирования и конструирования — от выполнения «плоских» чертежей до трехмерного параметрического проектирования. Развиваются методы обработки и хранения проектных данных — от структурированного сетевого ресурса до программных систем PDM (Product Data Management).

   Методологической основой этого развития является концепция PLM (Product Lifecycle Management) — управление жизненным циклом изделия. Концепция PLM предполагает однократное создание данных об объекте на этапе проектирования и многократное использование и модификацию этих данных на других этапах жизненного цикла объекта (рис. 1).

   Рис. 1. Жизненный цикл объекта проектирования

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

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

3. Методологические основы построения архитектуры проектного предприятия с точки зрения «теории организации»

   Теория организации [2] рассматривает предприятие как динамическую структуру, развивающуюся в рамках определенного жизненного цикла. В процессе существования организация может претерпевать несколько различного рода кризисов. Некоторые из таких кризисов являются неизбежными, и само их наличие говорит о положительных тенденциях в развитии организации. К таким кризисам можно отнести, например, кризис количественного роста, который может привести к пересмотру структуры и способов управления организацией, или же кризис, связанный с глобализацией деятельности компании и переходом в связи с этим на дивизиональную архитектуру.

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

   Любая перестройка организации является, безусловно, затратным мероприятием и начинать ее следует только в том случае, если рыночное положение организации определяется именно как кризис. Искусство управления предприятием в случае появления негативных тенденций и состоит в том, чтобы в ходе анализа определить невозможность или чрезвычайную затратность ликвидации негативных факторов и прийти к выводу о наличии кризиса и необходимости перестройки предприятия.

   Наиболее предпочтительными считаются эволюционные методы преобразования организации с использованием так называемых реинжиниринговых технологий. Реинжиниринг (перестройка) структуры предприятия помимо затратности является еще и достаточно рискованным мероприятием. По оценкам М. Хаммера и Дж. Чампи, успешно реинжиниринг происходит лишь в 30−50% случаев [3]. Поэтому выбор принципов и методологии реинжиниринга является ответственным этапом преобразования организации. Самым худшим вариантом в этом случае будет полное отсутствие заранее выработанных подходов к реинжинирингу. В такой ситуации в зависимости от опыта высшего менеджмента предприятия выбирается только один из аспектов его архитектуры, и только он подвергается преобразованию.

   Под архитектурой проектного предприятия в этой статье понимается совокупность функциональных схем высокого уровня, представляющих структуру организации в следующих аспектах:

   • технологический — схема производственного цикла и его оснащение;
   • информационный — схема информационных потоков и их обработки;
   • финансовый — схема формирования финансовых потоков;
   • административный — схема управления и административное деление предприятия.

   Указанные аспекты архитектуры проектного предприятия приведены на рис. 2.

   Рис. 2. Аспекты архитектуры проектного предприятия

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

   • в качестве основы, главной парадигмы, построения архитектуры проектной организации выбирается технологическая схема производства, состоящая, в свою очередь, из связанных в неразрывную структуру элементарных бизнес-процессов;
   • остальные виды функциональных структур, образующих аспекты архитектуры проектной организации, строятся вокруг технологии производства, обслуживая и обеспечивая ее;
   • административный аспект архитектуры формируется последним, главная цель его реализации — эффективное управление бизнес-процессами, а не людьми.
4. Составляющие (аспекты) архитектуры проектной организации: технология производства, технологическое оснащение, справочно-нормативные данные и т.п.

   Рассмотрим более подробно приведенные выше составляющие (аспекты) архитектуры проектной организации.

   Технология производства

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

   С описательной точки зрения технология проектного производства является эргатической системой, преобразующей исходные, промежуточные и нормативные данные в данные нового качества — проектные (документацию, модели и т.п.). Эмерджентным качеством [4] технологии производства как системы является способность синтеза проектных данных из исходных. Условно этот процесс можно проиллюстрировать в виде плоского семантического пространства Осгуда [5], имеющего два измерения: количество информации и ее качество (рис. 3). Идеальный технологический процесс сначала агрегирует исходные данные (например, данные топосъемки в цифровую модель рельефа), а затем производит (синтезирует) проектные данные. Качество информации при этом непрерывно повышается. Реальная технология не является непрерывной, в ней, как и в любой эргатической системе, имеются разрывы, в которых находятся специалисты, манипулирующие данными при помощи каких-либо инструментальных средств. Естественной для развития такой системы целью является уменьшение количества разрывов (повышение степени автоматизации технологии) [6].

   Рис. 3. Преобразование информации о проекте в плоском семантическом пространстве Осгуда

   Элементы технологической системы взаимодействуют между собой, образуя элементарное звено технологии (рис. 4).

   Рис. 4. Элементарное звено технологии проектирования

   Следует отметить, что сам объект проектирования представляет собой техническую систему. Методологически наиболее верным способом создания объекта проектирования является его синтез из отдельных подсистем, создаваемых в одновременно действующих технологических звеньях. Такой принцип чаще всего и применяется на практике. Кроме того, для уменьшения размерности объекта используется его предварительное разбиение на подобъекты, как правило, по территориальному признаку.

   Таким образом, сначала объект проектирования разбивается на составляющие, которые затем синтезируются (проектируются) из заранее определенных подсистем. Одновременно подсистемы проектируются исходя из специализации сотрудников и соображений экономии времени. Это также порождает целый ряд проблем, связанных с необходимостью контроля совместимости подсистем (так называемая «проблема контроля коллизий»). Однако ресурсный и временной выигрыш полностью перекрывает потери качества из-за коллизий и необходимости их контроля.

   Вот как выглядит парадигма процесса проектирования (рис. 5).

   Рис. 5. Парадигма процесса проектирования

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

   Информационные потоки

   Информационные потоки внутри технологии производства проектной продукции являются основным системообразующим элементом.

   Наиболее часто используемой методологией для представления информационных потоков является описание по Гейну и Сарсону [7]. Эта нотация поддерживается несколькими программными системами, предназначенными для представления и анализа информационных потоков. Пример такого представления приведен на рис. 6.

   Рис. 6. Пример схемы информационных потоков по Гейну и Сарсону

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

   Финансовые потоки

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

   Административное деление организации

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

   Определить простые правила административного деления организации не представляется возможным, необходимо учитывать сложность управления в каждом конкретном случае, загруженность управленческого персонала в случае совмещения производственных и управленческих функций и т.п.

   Каковы же показатели качества уже произведенного административного деления? Самым объективным показателем, как уже было сказано выше, является минимум трансакционных издержек. Для вспомогательных бизнес-процессов косвенно оценить издержки можно по количеству виз на документах и времени их оформления.

   Существуют общепринятые критерии оценки штатной структуры предприятия, основанные на общих соображениях трудоемкости управления. Например, считается, что один руководитель может эффективно управлять командой, состоящей из 7−10 специалистов.

   Вот так, например, может выглядеть структура «бюрократизированного» предприятия, имеющая необоснованно большое количество уровней управления с руководителями, управляющими не более чем 4 специалистами (рис. 7).

   Рис. 7. Пример организационной структуры предприятия со слишком большим числом уровней подчиненности

   В данной структуре пять уровней подчиненности, 34 руководителя разного уровня, соотношение рабочего и управленческого персонала — 34%.

   Теперь приведем пример структуры предприятия, в котором руководитель каждого уровня управляет 10 подчиненными (рис. 8).

   Рис. 8. Пример организационной структуры предприятия с оптимальным числом уровней подчиненности

   В данной структуре три уровня подчиненности, 11 руководителей разного уровня, соотношение рабочего и управленческого персонала — 11%.

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

5. Обобщенный технологический процесс производства проектной продукции как основа для построения структуры подразделений организации (описание технологии проектирования)

   Элементарный процесс проектирования, отображенный в его парадигме в виде одной линии («Система 1» на рис. 5) и состоящий из совокупности последовательно взаимодействующих элементов технологии, в действительности имеет более сложную структуру (рис. 9).

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

   На этапе формирования организационного аспекта архитектуры проектной организации ее административное деление должно проводиться вдоль течения бизнес-процессов проектирования различных подсистем. При этом задачей руководителей является организация обмена заданиями и результатами проектирования, их согласование и синхронизация. Деление на подразделения должно проводиться в местах наименьшей интенсивности информационного обмена, так как наличие любого отношения между подразделениями ведет к появлению трансакционных издержек. Эти издержки, в свою очередь, прямо пропорциональны интенсивности информационного обмена, независимо от качества его организации и степени автоматизации. Приведем пример такого рационального административного деления на схеме (рис. 10).

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

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

   Технологическое оснащение, то есть то, что обеспечивает реализацию описанной выше технологии производства, состоит из:

   • программного обеспечения;
   • вычислительной техники и локальной сети;
   • полиграфического оборудования.

   Здесь мы рассмотрим самую сложную часть технологического оснащения — программное обеспечение. Часть технологии и все информационные потоки в проектной организации реализуются с помощью специальных программных средств, образующих в совокупности корпоративную информационную систему. Архитектура подобной информационной системы представлена на схеме (рис. 11).

   Рис. 11. Архитектура информационной системы в масштабах проектного предприятия

   Центральное место в архитектуре занимает подсистема управления проектными данными. Это система PDM (Product Data Management), которая обеспечивает:

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

   В большинстве реализаций систем PDM они поддерживают:

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

   Отдельно следует остановиться на принципах организации хранилищ информации в системе управления проектными данными.

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

   База данных (БД) представляет собой строго определенным образом организованное хранилище интерпретированных фактических сведений некоторой ограниченной предметной области. Данные в этой базе чаще всего имеют определенную логическую структуру, в той или иной степени соотнесенную со структурой понятий или с процессами обработки информации в представляемой предметной области. На вводимые в базу данные для облегчения использования информации могут накладываться некоторые синтаксические ограничения.

   Смысл создания баз знаний (БЗ) заключается в необходимости более строгого, чем в обычной БД, упорядочения данных. Необходимость такого упорядочения, в свою очередь, обусловлена ростом объема и номенклатуры данных, с одной стороны, и требованием соотнесения между собой разнородных данных — с другой. Для большей упорядоченности данных при их внесении в базу знаний, кроме синтаксических, проверяются некоторые семантические ограничения. Эти семантические ограничения хранятся в БЗ в виде описания совокупности взаимосвязанных понятий и называются «знаниями». Поэтому БЗ, в отличие от БД, практически всегда является некоторой моделью представлений человека о предметной области. Отсюда же вытекает характерная для любой БЗ архитектура с делением на две части: систему знаний и контролируемую ею систему данных.

   Вводимые в БЗ знания, в свою очередь, также подчиняются определенным правилам, называемым моделью знаний. Модель знаний упорядочивает систему понятий и не позволяет вносить в БЗ противоречивые знания.

   Таким образом, все вносимые в БЗ знания проверяются на отсутствие противоречия существующим знаниям, а все вносимые данные — на отсутствие противоречия существующим знаниям и данным. Это отличительное свойство базы знаний называется целостностью, а операция по ее проверке — контролем целостности.

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

   Итак, от обычной БД база знаний отличается тем, что в ней:

   • пользователь имеет возможность явно описать систему понятий предметной области в соответствии с моделью знаний;
   • при вводе знаний и данных выполняется контроль целостности, в результате чего некоторые знания и данные могут быть отвергнуты;
   • по результатам некоторых изменений существующих знаний и данных другие соответствующие изменения модели знаний могут быть выполнены автоматически.

   Нелишним будет также сказать о применимости для моделирования предметной области системной парадигмы [4]. То есть объекты (данные и знания о них) представляются как технические системы. Системы считаются техническими в том случае, если представляют собой объекты, созданные человеком для определенной практической цели. Объекты же, моделируемые в базе знаний, названы системами потому, что, согласно принятому в концепции описательному положению, их свойства вытекают из их структуры. Таким образом, системой считается всякая структура (то есть совокупность упорядоченно расположенных объектов), обладающая определенной совокупностью свойств, иметь которую не способна ни одна из частей структуры. Этот принцип называется эмерджентностью.

   Таким образом, в БЗ объектов предметной области описываются структуры, свойства эмерджентных систем и связь между ними.

   Более подробно модель базы знаний о технических системах изложена в статье П.К. Петрова «Моделирование знаний для построения специальных информационных технологий, поддерживающих влияние ограничительных положений нормативной базы на технологический процесс проектирования объектов магистральных нефтепроводов», опубликованной в журнале «Трубопроводный транспорт. Теория и практика» [8].

   Какие же преимущества получит проектировщик от использования моделирования знаний при хранении проектных данных?

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

   Далее — возможность выбора аналогов и использование их в качестве прототипов для проектирования. Достаточно указать несколько характеристик объекта проектирования — и пользователь получает перечень объектов с таким же или близким набором показателей. Более сложным является поиск структурных аналогов (или гомологов), такая возможность также может быть предусмотрена в модели хранилища проектных данных, если оно основано на принципах обработки знаний.

   И наконец, беспрецедентный уровень сервиса при вводе данных. Используя свойства целостности и процедуры по ее поддержке, пользователь может ввести новый объект, отнести его к какому-либо классу и получить готовый состав, структуры всевозможного вида и набор показателей объекта, типичный для выбранного класса.

   Поскольку БЗ объектов проектирования является наиболее важным элементом PDM-системы, имеет смысл обсудить некоторые особенности ее реализации.

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

   Как уже было сказано выше, большое количество и номенклатура слабоструктурированных данных привели к появлению в компьютерной практике специальных программных средств — систем управления базами данных (СУБД) [9].

   Введенные механизмы СУБД, с одной стороны, позволили логически упорядочить массивы накопленных данных в рамках средств описания логической модели данных (ЛМД) — языка описания данных (ЯОД). С другой стороны — они позволили организовать логический доступ из программных приложений к БД. Этот доступ реализуется из любого приложения средствами языка манипулирования данными (ЯМД).

   Дальнейшее развитие СУБД привело к появлению так называемых активных СУБД и дедуктивных СУБД [10]. Под активной СУБД понимается такая СУБД, в которой выполняются не только те действия, которые явно указывает пользователь, но и дополнительные действия в соответствии с правилами, заложенными в саму БД. А дедуктивная СУБД представляет композицию из компоненты, содержащей факты (экстенционал), и компоненты, содержащей правила для логического вывода новых фактов (интенционал) на основе экстенционала и запроса пользователя.

   Следует отметить, что упомянутые СУБД хранят мгновенный снимок модели предметной области. Любое изменение в момент времени t некоторого объекта данных приводит к недоступности состояния этого объекта в предыдущий момент времени. Самое интересное, что в действительности в большинстве развитых СУБД предыдущее состояние объекта сохраняется в журнале изменений, но возможности доступа для пользователя к этой информации нет. Развитие СУБД в этом направлении базируется на разработке темпоральных (временных) СУБД — ТСУБД [11]. Основная особенность темпоральных СУБД состоит в том, что для любого объекта данных, созданного в момент времени t1 и уничтоженного в момент времени t2, в БД сохраняются (и доступны приложениям) все его состояния во временном интервале [t1, t2].

   ТСУБД позволяет организовать хранение истории поведения данных модели предметной области в виде архивных БД, что особенно важно для приложений, работающих в реальном времени [12].

   Такое развитие СУБД при появлении новых единиц информации, именуемых знаниями, потребовало разработки новых программных средств — систем управления базами знаний (СУБЗ) [13, 14, 15, 16], реализация которых опирается на описанный выше опыт активных СУБД, дедуктивных баз данных, темпоральных СУБД.

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

   Исходя из вышесказанного, можно утверждать, что с точки зрения реализации СУБЗ является развитием СУБД с учетом свойств единиц знаний.

   Архитектура системы управления базами знаний представлена на рис. 12.

   Рис. 12. Архитектура системы управления базами знаний

   Второй важной для нас компонентой архитектуры информационной системы проектной организации является подсистема автоматизированного проектирования. Рассмотрим инструментальную часть этой подсистемы, которая представляет собой совокупность CAD-систем (CAD — Computer-Aided Design — автоматизированное проектирование).

   В настоящее время наиболее перспективным направлением в развитии CAD-систем принято считать 3D-проектирование. Дело в том, что использование систем, основанных на технологии трехмерного параметрического проектирования, позволяет:

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

   Главным обоснованием необходимости внедрения современных параметрических САD-систем является существенное снижение при этом трудоемкости проектирования.

   Следует отметить, что готовые параметрические модели из выполненных проектов могут быть использованы для создания моделей типовых объектов, которые, в свою очередь, могут предлагаться на рынке в качестве объекта интеллектуальной собственности в совокупности с комплексом услуг по его поддержке и актуализации. Таким образом можно извлечь прибыль не только из результатов проектирования, но и из продажи самого инструмента для создания проектов.

   Ведущими мировыми производителями трехмерных параметрических CAD-систем являются:

   • Dassault Systemes (продукт CATIA);
   • Parametric Technologies Corp. (РТС) (продукт ProE);
   • Siemens PLM Software (продукт NX);
   • Autodesk (продукты AutoCAD, Inventor, Revit и др.);
   • Bentley Systems (продукты AutoPlant и др.).

   Компании Dassault, РТС и Siemens PLM более ориентированы на рынок машиностроительного проектирования.

   Компании Autodesk и Bentley являются крупнейшими поставщиками так называемых «вертикальных» программных решений, то есть надстраиваемых друг над другом программных систем, позволяющих решать задачу проектирования объектов какой-либо ограниченной предметной области в комплексе. У этих двух компаний имеется широкая номенклатура программ, ориентированных на проектирование объектов транспорта нефти и газа.

   В последнее время на рынок универсальных CAD-систем выходят так называемые «клоны» AutoCAD китайского (продукт ZWCAD+) и европейского производства (продукт BricsCAD), которые при сходном функционале и организации диалога имеют значительно меньшую стоимость.

   На рынок вертикальных решений выходит и отечественная компания CSoft Development — крупнейший в России разработчик и поставщик САПР. В этой области компания успешно конкурирует с Bentley Systems, отличаясь от последней низкой стоимостью решений и их адаптированностью к отечественному рынку деталей, узлов и агрегатов, а также к стандартам выпуска проектной документации.

   Политика формирования номенклатуры программных средств для инструментальной поддержки проектирования в проектной организации может строиться следующим образом:

   • номенклатура формируется на основе вертикальных специализированных решений (компании-производители — Autodesk, Bentley, CSoft Development);
   • в области систем инженерных расчетов формирование номенклатуры производится преимущественно за счет специализированных отечественных решений;
   • стоимость владения программными средствами на рабочем месте снижается за счет использования «клонов», а также бесплатного ПО с «открытым кодом»;
   • формирование номенклатуры производится пошаговым путем с апробацией в ходе выполнения реальных работ, что позволяет сделать номенклатуру более обоснованной и быстрее вернуть инвестиции.
7. Заключение

   Мы рассмотрели методологические основы построения архитектуры проектного предприятия, особенности и принципы его перестройки (реинжиниринга). Затем сформулировали и рассмотрели различные аспекты архитектуры проектной организации: технологический (подробно), информационный, финансовый и административный. Описали типовой процесс проектирования, подробно проанализировали архитектуру информационной системы проектного предприятия и принципы организации хранилищ проектных данных. Более подробно остановились на принципах реализации наиболее важной структурной единицы хранилища проектной документации — базе знаний проектов, поддерживаемой при помощи системы управления базами знаний. А также рассмотрели принципы административного деления проектного предприятия.

   Материал, изложенный в статье, может использоваться как методический при реорганизации проектного предприятия, особенно на этапе планирования реорганизации.

В следующей статье будут рассмотрены:

• рациональный состав проектных подразделений;
• организация работ и мотивация персонала;
• принципы управления проектной организацией;
• распределение полномочий между управленческими звеньями;
• оптимизация структуры управления и численного состава управленческого звена;
• стратегия ведения бизнеса в области проектирования;
• состав портфеля заказов, методы его формирования;
• представление организации на рынке проектных услуг.

Литература

1. Оголева Л.Н. Реинжиниринг производства: учебное пособие. М.: КНОРУС, 2005, 304 с.
2. Акулов В.Б., Рудаков М.Н. Теория организации. Учебное пособие. Петрозаводск, ПетрГУ, 2002, 190 с.
3. Хаммер М., Чампи Дж. Реинжиниринг корпораций: манифест революции в бизнесе: Пер. с англ. СПб., 1997.
4. Флейшман Б.С. Основы системологии. М.: Радио и связь, 1982, 368 с.
5. Charles E. Osgood, George Suci & Percy Tannenbaum, The Measurement of Meaning. University of Illinois Press, 1957.
6. Хоменко К.В., Петров П.К., Куликов О.В. Концептуальные основы корпоративной информационной системы в области проектирования магистральных нефтепроводов. — Трубопроводный транспорт. Теория и практика № 2 (4) 2006.
7. Гейн К., Сарсон Т. Структурный системный анализ: средства и методы. М.: Эйтекс, 1993.
8. Петров П.К. Моделирование знаний для построения специальных информационных технологий, поддерживающих влияние ограничительных положений нормативной базы на технологический процесс проектирования объектов магистральных нефтепроводов. — Трубопроводный транспорт. Теория и практика. № 4 (6) 2006 г.
9. К. Дж. Дейт. Введение в системы баз данных. Пер. с англ., 8-е изд., М.: Вильямс, 2005.
10. Кузнецов С.Д. Основы современных баз данных. М.: Вильямс, 2005.
11. C.J. Date, Hugh Darwen, Nikos Lorentzos. Temporal Data and the Relational Model. Morgan-Kaufmann Publishers, 2002.
12. Dengfeng Gao, S. Jensen, T. Snodgrass, D. Soo. Join operations in temporal databases. The VLDB Journal — The International Journal on Very Large Data Bases. Vol. 14 Issue 1, 2005.
13. Башлыков А.А. Проектирование систем принятия решений в энергетике. М.: Энергоатомиздат, 1986.
14. Системы управления базами данных и знаний. Под ред. А.Н. Наумова. М., 1991.
15. Гаврилова Т.А., Хорошевский В.Ф. Базы знаний интеллектуальных систем. СПб.: Питер, 2000.
16. Ларичев О.И. Объективные модели и субъективные решения. М.: Наука, 1987.

Скачать статью в формате PDF — 556.0 Кбайт