Проблемы и решения автоматизации проектных работ

[samsony1]

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

Кто виноват?
Такой вопрос возникает, когда после краткого периода эйфории руководство предприятия с удивлением обнаруживает, что затраченные средства не окупаются в ожидавшихся масштабах, а проектирование на компьютере, даже с использованием лицензионного программного обеспечения, не приводит к заметному росту качества и производительности. На головы сотрудников отдела САПР обрушивается критика руководства – причиной отсутствия результата объявляются их леность и нерадивость.

"Лоскутная" автоматизация
Может быть, в начальственной критике и есть некая доля истины, но давайте посмотрим, каким образом обычно организуется приобретение программного обеспечения. Сотрудники производственных подразделений находят в рекламе или видят на предприятиях сходного профиля программы, которые, по их мнению, автоматизируют выполнение производственных задач. При этом, слабо ориентируясь в области САПР, они не обращают внимания ни на то, какие платформы используются этими программами, ни на возможность связать приобретаемое программное обеспечение со средствами автоматизации, которые используются смежными специальностями. Да и кто поручится, что заявленные в рекламе функции программного обеспечения реально работают и позволяют решать производственные задачи?

Но и сотрудники служб САПР не могут самостоятельно выбрать подходящее программное обеспечение: зачастую они некомпетентны в сфере проектирования. В итоге на многих предприятиях приобретается большое количество программного обеспечения, тратятся немалые деньги на обучение сотрудников, а эффект близок к нулю. Картина напоминает разбросанные там и сям "лоскутки автоматизации" разных размеров и цветов, которые невозможно сшить в единое полотно.

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

Вот почему попытки использования САПР без выработки регламентов и стандартов работы с электронными данными не приносят ощутимого роста эффективности труда. Использование даже большого количества вполне работоспособных автоматизированных рабочих мест, не связанных в единую технологическую цепочку проектирования, не обеспечивает желаемого результата. Нерегламентированные и нестандартизированные интерфейсы передачи информации между рабочими местами сводят на нет все преимущества автоматизации. Плодятся копии электронных файлов, сохраненных в разнообразных форматах, происходит несогласованное изменение данных, к тому же еще и автоматизированное. Вместо системы автоматизированного проектирования –САПР получается САБР – система автоматизированного беспорядка…

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

Комплексная система автоматизации проектирования. Поиск определения
Это комплекс программных средств и мероприятий, который призван обеспечить сквозной цикл многовариантного проектирования объектов и сооружений (изыскания и генплан, технология и инженерные коммуникации, строительство, электрика и АСУ, выпуск ПСД и КД) под управлением системы технического документооборота на базе единого информационного пространства для всего цикла проектирования в тесной связи с системой международных стандартов менеджмента качества проектной продукции ИСО 9000.

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

Основная задача комплексной автоматизации – охват всего цикла проектирования с существенным сокращением сроков и стоимости выполняемых работ и с повышением качества выпускаемой ПСД. Основной эффект от внедрения комплексной САПР в проектное производство достигается благодаря четкому управлению и планированию работы всех участников процесса проектирования. Такое решение обеспечивает:
1. директора, главного инженера – средствами общего контроля и управления ходом выполнения всех работ по различным проектам (с максимальным статусом доступа);
2. ГИПа, начальника отдела - средствами выдачи заданий и контроля сроков выполнения работ, календарного планирования и контроля хода проектирования, согласования и утверждения документации в соответствии со статусом и правами доступа;
3. руководителя среднего звена (руководителя группы или сектора, ведущего специалиста) - средствами контроля и планирования сроков выполнения работ, комплектности документации, загруженности исполнителей, номенклатуры сортамента оборудования и материалов и т.п.;
4. проектировщика (конструктора, технолога, строителя, инженера и т.д.) - средствами автоматизации выполнения проектных работ; быстрого поиска информации о разрабатываемых или сопровождаемых объектах (проектах, оборудовании, материалах, типовых или наиболее эффективных проектных решениях и т.п.); поиска связанных с объектами документов и другой необходимой информации; контроля комплектности подготавливаемой документации; заимствования проектных решений из других проектов; ведения многовариантного проектирования; получения предварительных и окончательных отчетов (спецификаций, ведомостей и т.д.).
Большая часть проектных предприятий не располагает достаточными силами и ресурсами, позволяющими самостоятельно реализовать концепцию комплексной автоматизации проектирования. Постепенно приходит понимание, что без помощи специалистов по внедрению, консультантов из внешней компании, существенного эффекта от перехода к автоматизированному проектированию ждать не приходится.

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

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

В других организациях с совсем иной позицией руководителей: "Деньги на программы я дал, а на внедрение у нас нет времени. Давайте так, как-нибудь…". Результат – деньги потрачены, эффект минимальный.

Приведем примеры, максимально наглядно иллюстрирующие роль высшего руководства. Чтобы обосновать приобретение "тяжелого" программного обеспечения для автоматизации электротехнического проектирования, в одном из проектных институтов было выполнено несколько проектов, подтвердивших заявленную эффективность средств автоматизации. Применение этого ПО позволило за один день выполнить работу, на которую обычно требовалось полторы две недели. Тем не менее, покупке программного обеспечения категорически воспротивилось руководство электротехнического отдела, мотивировавшее свой отказ сложностью программ и отсутствием времени на обучение. Истинная же причина обнаружилась в другом – работая по старинке, отдел имел большие трудозатраты, а следовательно мог рассчитывать на дополнительное финансирование, увеличение числа сотрудников. Применяя современные технологии, отдел рисковал потерять в деньгах. А единственным человеком, который сумел повлиять на руководство подразделения, стал генеральный директор института, заинтересованный в повышении эффективности и снижении трудозатрат. Другой пример относится к практике работ в институте. В начале процесса внедрения системы электронного технического документооборота авторы объясняли основные принципы и преимущества системы документооборота руководителям среднего звена. Говорилось, что такая система позволяет обеспечить полную прозрачность процесса проектирования для руководства всех уровней, и ее наличие является одним из важных факторов успешного функционирования САПР в целом.

И что же? Первая реакция руководителей отделов ("Здорово, теперь я смогу отследить состояние дел в своем отделе и у смежников!") быстро сменилась другой: "Значит, теперь все что делается в моем отделе будет прозрачно и для моего руководства?!"

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

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

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

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

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

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

Не секрет, что попытки создать рабочие группы по внедрению САПР, соответствующие всем упомянутым требованиям, предпринимаются на многих предприятиях. Казалось бы, все условия соблюдены, группой грамотных и опытных специалистов руководит знающий и уважаемый человек, а результат работы – минимальный. Причины здесь просты: перегруженность всех членов группы текущими работами полностью парализует ее работу, а непонимание того, что важно не только автоматизировать свои рабочие места, но и обеспечить смежные специальности полной и пригодной для использования информацией, сводит к нулю все усилия, не позволяет выработать четкую и правильную концепцию комплексной автоматизации.

[samsony1]

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

Процесс внедрения САПР на предприятии включает следующие этапы:
1. обследование процессов проектирования;
2. выработка концепции САПР, включая выбор средств автоматизации проектирования и разработку перечня основных работ по внедрению системы;
3. формализация процесса выполнения работ – разработка стандартов предприятия, относящихся к работе САПР;
4. разработка концепции единого информационного пространства и средств ее реализации;
5. обучение специалистов;
6. выполнение пилотных (учебных) проектов с использованием САПР

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

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

Формализация процесса выполнения работ
Большинство организаций сертифицировано или готово к сертификации по ISO. Но при изучении документации выясняется, что немалая часть документов разработана формально и не отражает текущего состояния дел. Основная задача данного этапа – определение перечня документов, который описывает основные регламенты работы, а так же корректировка либо переработка данной документации. Процесс это довольно долгий и трудный: сложность описания технически грамотных регламентов усугубляется и постоянной нехваткой времени. Отдельную проблему составляет стандартизация работы с программным обеспечением (прежде всего необходимо стандартизировать работу с офисными и графическими приложениями). Конечно, существуют ЕСКД, СПДС, СТП, определяющие правила оформления графической продукции, но количество вариантов оформления на основе этих стандартов не ограничено и они не регламентируют "культуру" черчения в в графических программах. Все эти стандарты разработаны для ручного создания чертежей, не содержат таких понятий, как "блок", "слой", "правила использования стилей" и т.д., а предприятию необходим стандарт, отвечающий современным требованиям электронного оформления графической документации.

Разработка концепции единого информационного пространства и средств ее реализации
Одна из главных задач комплексной автоматизации – создание единого информационного пространства. Что мы имеем в виду, используя этот популярный термин? В идеале – некую единую базу данных, с которой работает все программное обеспечение. Но при этом возникает ряд проблем:
1. разное программное обеспечение использует разные базы и структуры данных;
2. вести и сопровождать базу должен соответствующий специалист: технолог, электрик, механик и т.д.;
3. объем общей базы, содержащей столь огромную и разнообразную номенклатуру, будет чрезвычайно велик.
Какова же альтернатива? Разумеется, объединенная база необходима, но она должна быть некой базой данных по проекту. Это даст возможность получать любую выходную документацию, существенно уменьшить количество ошибок при передаче данных, минимизировав влияние "человеческого фактора".

источник - здесь

[samsony1]

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

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

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

Существует мнение, что документооборот в проектных организациях – это в основном работа с теми документами, которые передаются заказчику. Но такие документы – лишь верхушка айсберга: 70-80% документооборота приходится на задания, промежуточную документацию, циркулирующую внутри предприятия, и электронные данные, передаваемые от одного программного средства к другому.

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

Детальное изучение и формализация потоков, их содержание, описание взаимодействия подразделений и используемого ими программного обеспечения, определение возможности "выгрузки" данных из одних приложений и "закачки" их в другие – одна из сложнейших задач по внедрению СУПД, но ее выполнение позволит определить шаги по реализации следующих задач:
1. планирование проектно-изыскательских работ и управление такими работами;
2. передача электронных данных между различным программным обеспечением в соответствии с разработанным регламентом.
Эти работы являются первым шагом к созданию единого информационного пространства и ключом к выполнению требований стандарта ISO 9000. Разумеется, необходим механизм организации единого информационного пространства.

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

Выполнение пилотных (учебных) проектов с использованием САПР
На всех этапах внедрения большую роль играет проведение пилотных проектов, то есть внедрение системы в опытно-промышленную эксплуатацию. В качестве пилотного выбирается наиболее характерный для редприятия и небольшой по объему проект (из числа выполненных ранее или новых), который в полной мере охватывает все задействованные специальности. Этап осуществляется в тесном сотрудничестве между проектировщиками и специалистами компании - системного интегратора. Конечно, проектировщики проходят обучение, но, как показал опыт, по ходу "пилота", предполагающего решение реальных задач, неизбежно возникает множество вопросов и ошибок. Разрешение этих проблем – первая задача внедрения, от успеха которой зависит отношение проектировщиков к новой для них среде проектирования.

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

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

источник ->здесь