Стандарты, регламенты в проектировании. Для чего?
В этой статье рассматриваются только структура и общее содержание регламентирующей документации, описывающей процесс проектирования с использованием современных САПР, которая, по мнению автора, необходима для разработки и применения во всех проектных организациях.
Введение
Основная задача автоматизации проектных работ — ускорение темпов их проведения и повышение качества технической документации проектов.
Одним из важных и самых модных направлений автоматизации в последнее время считается применение 3Dтехнологий.
На это тратится много сил и средств, закупается новое программное обеспечение, оборудование, проводится обучение и выполняются пилотные проекты. Но, к сожалению, в конечном счете в большинстве случаев всё сводится к «поднятию» трехмерных моделей по разработанным 2Dчертежам для выявления коллизий и показа потенциальным заказчикам красивой модели.
Попытки замены одного ПО на другое (по мнению ИТспециалистов, более продвинутое) ни к чему хорошему не приводят. Порой поражаешься, глядя на перечень программ, купленных организациями. Бросаются в глаза метания людей в безуспешной попытке найти ту пресловутую «красную кнопку». Но, к сожалению, все это напоминает слова из известной басни Крылова: «…а вы, друзья, как ни садитесь…»
Чего же не хватает организациям для внедрения в жизнь полноценной автоматизации проектирования?
Ответ лежит на поверхности. Покупая и внедряя новое программное обеспечение, разрабатывая различные концепции комплексной автоматизации, применяя современное программное обеспечение, мы забываем, что при этом меняется сама технология проектирования. Появляется возможность параллельной работы над одним проектом различных специалистов, использующих единую базу проекта, возможность верификации на разных стадиях разработки, возможность автоматизации формирования заданий и многое другое.
Но при этом не существует регламентирующей документации, описывающей процесс проектирования с учетом новых условий.
Конечно, уже предпринимаются определенные попытки разработки стандартов на государственном уровне, но это в основном касается области машиностроения.
В этой статье рассматриваются вопросы, затрагивающие только этап проектирования. Но решая вопрос совершенствования его процессов, мы подготавливаем проектные организации к внедрению ГОСТ Р ИСО 1592612008 «Промышленные автоматизированные системы и интеграция. ИНТЕГРАЦИЯ ДАННЫХ ЖИЗНЕННОГО ЦИКЛА ДЛЯ ПЕРЕРАБАТЫВАЮЩИХ ПРЕДПРИЯТИЙ, ВКЛЮЧАЯ НЕФТЯНЫЕ И ГАЗОВЫЕ ПРОИЗВОДСТВЕННЫЕ ПРЕДПРИЯТИЯ». По нашему мнению, не внедрив новые регламенты в процесс проектирования, к этому приступить невозможно.
Процессы/регламенты/нормативные документы
Чтобы система управления работала эффективно, необходима технологическая основа — информационные технологии.
Существующий уровень регламентации процессов проектирования не позволяет использовать весь потенциал комплекса современных программ.
Опыт внедрения САПР свидетельствует, что трудности чаще всего возникают изза сопротивления системы организации вносимым в нее изменениям. В большинстве проектных предприятий процесс проектирования формализован весьма незначительно. При этом, как правило, существует неявная сложившаяся схема выполнения проекта, то есть нет документированного алгоритма, но есть общепринятая схема взаимодействия, которую целиком не знает никто. Для небольших предприятий такая формализация — слишком дорогое удовольствие, эффект же от нее совсем незначителен. Зато в крупных проектных организациях и их объединениях отдача может быть весьма ощутимой, поскольку «прозрачность» системы позволяет рациональнее управлять процессами в ней, прогнозировать и рентабельнее распределять ресурсы. Неоспоримым плюсом, с точки зрения предприятия, является также снижение последствий потери сотрудника. Негативный эффект замены ключевых специалистов обратно пропорционален степени формализации процессов, которыми он управляет. К сожалению, и сопротивляемость крупных систем гораздо выше изза инертности и страха перед новым…
Рис. 1. Уровни регламентирующих документов
В чем заключается формализация и из чего она состоит? А заключается она, в том числе, и в разработке и внедрении пакета документов, регулирующих собственно процесс проектирования. Структура такого пакета приведена на рис. 1. Состоит же формализация, как процесс, из:
- выявления и анализа имеющихся моделей бизнеспроцессов проектирования;
- построения новой модели с учетом комплексной системы автоматизации проектирования организации;
- разработки регулирующей документации;
- обучения персонала, выполнения пилотных проектов;
- корректировки регламентов по результатам выполненных пилотных проектов;
- введения документации как нормы организации на постоянной основе.
Структура документации
Для крупных проектных организаций оптимальна, по нашему мнению, следующая структура регулирующей документации:
- документы, вводящие необходимые понятия, термины и определения, — являются основополагающими, обеспечивающими единство терминологии комплекса стандартов;
- документы, описывающие процесс концептуально, — не привязаны к конкретным программам, а служат для регламентации правил взаимодействия участников процесса;
- документы, описывающие процессы с учетом специфики определенных программ, — создаются на основе документов, описывающих процесс концептуально;
- инструкции — пошаговое руководство для участников процесса.
Структура документов может варьироваться в зависимости от того, для кого документы разрабатываются — для отдельной организации или для концерна (Газпром, Роснефть и т.д.).
В обоих случаях на верхнем уровне должен быть документ с общими определениями, а на следующих уровнях — стандарты, регламенты, описывающие процесс проектирования с использованием комплексных САПР.
Для тех организаций, которые выбрали конкретное ПО и не планируют осуществлять переход на иное, рекомендуется объединять документы второго и третьего уровня. Для объединений и концернов важны первый и второй уровни. Наличие этих документов позволит организациям, входящим в состав объединения, разрабатывать единообразные документы третьего и четвертого уровней.
Остановимся более подробно на содержании данных документов.
Первый уровень
Стандарт «Электронная модель объекта» (рис. 2) должен определять понятие электронной модели объекта проектирования, общие требования к ней, виды контроля электронной модели, ее статусы и этапы жизненного цикла. Нет необходимости читать его полностью, изучать, но он всегда должен быть под рукой, чтобы значения тех или иных терминов всегда понимались однозначно.
Рис. 2. Стандарт «Электронная модель объекта»
Рис. 3. Пример стандартов, регламентов, документированных процедур второго уровня
Второй уровень
Включает «Технологические правила проектирования с применением электронных моделей». Разработку документов этого уровня (рис. 3) оптимально было бы начать с формирования моделей бизнеспроцессов проектных работ с использованием САПР и регламентирующей на их основе документации. При этом описываются общие принципы без привязки к конкретному ПО.
В ходе разработки моделей необходимо определить и создать «Унифицированные варианты моделей бизнеспроцессов», предусматривающие создание различных типов проектов и разных специальностей — ведущих технологов.
Третий уровень
Документация этого уровня или создается на основе документации второго уровня при его наличии или, когда документы разрабатываются для конкретной организации, включает второй и третий уровни с привязкой к конкретному ПО (рис. 4). Документация этого уровня содержит:
- регламенты и инструкции, описывающие правила коллективной работы внутри одной специальности;
- регламенты и инструкции по взаимодействию различных специальностей в ходе совместной работы;
- регламенты и инструкции по созданию, пополнению и ведению баз данных.
Рис. 4. Пример структуры документации третьего и четвертого уровня по проектированию КИПиА с применением SmartPlant Instrumentation
Четвертый уровень
Как правило, документы этого уровня — инструкции по работе с конкретным ПО — есть в каждой организации (рис. 4).
Для ускорения разработки и внедрения обычно предварительно разрабатываются временные регламенты — документы, содержащие всё необходимое для организации проектных работ с применением определенного набора программ. Регламенты вводятся в действие на небольшой срок (до года), который необходим для устранения недочетов и обучения персонала. Для небольших организаций, как правило, этого вполне достаточно, и доработанные регламенты вводятся на постоянной основе. В крупных организациях регламенты служат основой для разработки комплекса стандартов.
Роль системного интегратора
Казалось бы, Америку тут никто не открыл, всем и так понятна необходимость документации этого типа. Так в чем причина, почему ее нет?
Разработка такого рода документов требует долгой и кропотливой работы, наличия знающего проектное производство персонала, способного анализировать существующую ситуацию, генерировать решения.
Если со знающим процесс проектирования персоналом в организациях, как правило, дело обстоит хорошо, то со свободным временем и возможностью отвлечения ведущих специалистов от основной работы на долгий срок — очень проблематично.
Вот тут и должен подключаться системный интегратор, обладающий знаниями не только в области САПР, но и в области проектирования, бизнеспроцессов, а также имеющий опыт аналогичной работы с проектными организациями. В этом случае роль ведущих специалистовпроектировщиков будет сводиться к оценке предлагаемых вариантов решения и выбору из них оптимальных.
Группа компаний CSoft осуществляет консалтинг и внедрение комплексных решений в области систем автоматизированного проектирования (САПР), технологической подготовки производства (ТПП), документооборота и геоинформационных систем (ГИС). Большая часть решений базируется на уникальном сочетании мировых и отечественных разработок в этой области.
Сегодня в нашем активе — десятки успешных комплексных проектов, собственные методики обследования организаций, внедрения проектноконструкторских и технологических решений, опыт создания стандартов в области САПР и документооборота, специализированные решения для узкопрофильных заказчиков.
Услуги, предлагаемые CSoft, включают анализ существующей технологии выполнения работ, определение наиболее эффективных программноаппаратных решений, разработку концепции развития САПР на предприятии, поставку, установку и настройку компонентов автоматизированной системы, обучение пользователей, выполнение пилотных проектов, внедрение автоматизированных систем «под ключ».
