Этапы больного пути
Современный рынок проектных работ требует перехода на новые технологии. Заказчики всё чаще обращают внимание не только на стоимость проекта, но и на техническое оснащение организации, ее способность в сжатые сроки выпустить качественный проект. Наряду с бумажными документами уже нередко фигурируют исходные электронные файлы, информационная и трехмерная модель проектируемого объекта. Все это вынуждает проектные организации повышать уровень технического оснащения — предприятия покупают компьютерную технику и программное обеспечение для автоматизации процессов проектирования.Кто виноват?
Такой вопрос возникает, когда после краткого периода эйфории руководство предприятия с удивлением обнаруживает, что затраченные средства не окупаются в ожидавшихся масштабах, а проектирование на компьютере, даже с использованием лицензионного программного обеспечения, не приводит к заметному росту качества и производительности.На головы сотрудников отдела САПР обрушивается критика руководства — причиной отсутствия результата объявляются их леность и нерадивость.
«Лоскутная» автоматизация
Может быть, в начальственной критике и есть некая доля истины, но давайте посмотрим, каким образом обычно организуется приобретение программного обеспечения. Сотрудники производственных подразделений находят в рекламе или видят на предприятиях сходного профиля программы, которые, по их мнению, автоматизируют выполнение производственных задач. При этом, слабо ориентируясь в области САПР, они не обращают внимания ни на то, какие платформы используются этими программами, ни на возможность связать приобретаемое программное обеспечение со средствами автоматизации, которые используются смежными специальностями. Да и кто поручится, что заявленные в рекламе функции программного обеспечения реально работают и позволяют решать производственные задачи?Но и сотрудники служб САПР не могут самостоятельно выбрать подходящее программное обеспечение: зачастую они некомпетентны в сфере проектирования.
В итоге на многих предприятиях приобретается большое количество программного обеспечения, тратятся немалые деньги на обучение сотрудников, а эффект близок к нулю. Картина напоминает разбросанные там и сям «лоскутки автоматизации» разных размеров и цветов, которые невозможно сшить в единое полотно.
Но дело еще и в том, что знания о процессе проектирования, которыми располагают руководители производственных подразделений, опираются на предшествующий опыт, полученный до появления средств автоматизации. К тому же, за редким исключением, эти знания не структурированы и не систематизированы должным образом, а потому непригодны для использования при работе с автоматизированными системами.
Вот почему попытки использования САПР без выработки регламентов и стандартов работы с электронными данными не приносят ощутимого роста эффективности труда. Использование даже большого количества вполне работоспособных автоматизированных рабочих мест, не связанных в единую технологическую цепочку проектирования, не обеспечивает желаемого результата.
Нерегламентированные и нестандартизированные интерфейсы передачи информации между рабочими местами сводят на нет все преимущества автоматизации. Плодятся копии электронных файлов, сохраненных в разнообразных форматах, происходит несогласованное изменение данных, к тому же еще и автоматизированное. Вместо системы автоматизированного проектирования — САПР получается САБР — система автоматизированного беспорядка…
Что делать
Попробуем разобраться, в каких условиях применение средств автоматизации проектирования гарантирует экономический эффект.Считавшийся до недавнего времени стандартным подход компаний-поставщиков САПРовских решений (продажа программного обеспечения, обучение будущих пользователей и предоставление технических консультаций специалистам заказчика) оказывается явно недостаточным. Необходимо проведение комплексной автоматизации, не только обеспечивающей потребности максимального количества проектных специальностей, но и корректную передачу данных между рабочими местами различного назначения, создание единого информационного пространства. Только это позволяет существенно повысить качество выпускаемой документации, уменьшить количество ошибок, сократить сроки проектирования и тем самым обеспечить необходимую эффективность инвестиций в САПР.
Комплексная система автоматизации проектирования. Поиск определения
Это комплекс программных средств и мероприятий, который призван обеспечить сквозной цикл многовариантного проектирования объектов и сооружений (изыскания и генплан, технология и инженерные коммуникации, строительство, электрика и АСУ, выпуск ПСД и КД) под управлением системы технического документооборота на базе единого информационного пространства для всего цикла проектирования в тесной связи с системой международных стандартов менеджмента качества проектной продукции ИСО 9000.Путь к формированию комплексной системы автоматизированного проектирования — создание единой информационной среды, позволяющей организовать коллективную работу подразделений, обеспечить многовариантность решений, управлять информацией и обеспечивать ее сохранность, уменьшить количество ошибок — и, как следствие, повысить производительность труда, конкурентоспособность предприятия.
Основная задача комплексной автоматизации — охват всего цикла проектирования с существенным сокращением сроков и стоимости выполняемых работ и с повышением качества выпускаемой ПСД. Основной эффект от внедрения комплексной САПР в проектное производство достигается благодаря четкому управлению и планированию работы всех участников процесса проектирования. Такое решение обеспечивает:
- директора, главного инженера — средствами общего контроля и управления ходом выполнения всех работ по различным проектам (с максимальным статусом доступа);
- ГИПа, начальника отдела — средствами
- выдачи заданий и контроля сроков выполнения работ;
- календарного планирования и контроля хода проектирования;
- согласования и утверждения документации в соответствии со статусом и правами доступа;
- руководителя среднего звена (руководителя группы или сектора, ведущего специалиста) — средствами контроля и планирования сроков выполнения работ, комплектности документации, загруженности исполнителей, номенклатуры сортамента оборудования и материалов
и т.п. ; - проектировщика (конструктора, технолога, строителя
и т.д.) — средствами- автоматизации выполнения проектных работ;
- быстрого поиска информации о разрабатываемых или сопровождаемых объектах (проектах, оборудовании, материалах, типовых или наиболее эффективных проектных решениях
и т.п.); - поиска связанных с объектами документов и другой необходимой информации;
- контроля комплектности подготавливаемой документации;
- заимствования проектных решений из других проектов;
- ведения многовариантного проектирования;
- получения предварительных и окончательных отчетов (спецификаций, ведомостей
и т.д.).
Требования к системному интегратору
Здесь мы позволим себе сослаться на конкретный пример — компанию CSoft. Итак, компания — системный интегратор должна иметь успешный опыт внедрения комплексных систем автоматизации проектных предприятий, предоставлять услуги по разработке и настройке программного обеспечения, располагать штатом не только опытных программистов, но и квалифицированных проектировщиков по всем основным специальностям.В то же время следует помнить, что все усилия компании-интегратора будут тщетны, если в работе по внедрению САПР не будут активно участвовать как руководители предприятия, так и ведущие специалисты в области проектирования и IT.
Роль руководства
На всех этапах внедрения исключительно важна роль руководства предприятия. Если генеральный директор понимает необходимость автоматизации производственного процесса, то, используя имеющиеся административные и финансовые инструменты управления, он может эффективно влиять на соответствующие процессы.Авторы проводили работу с разными проектными институтами, относящимися к инженерным центрам РАО ЕЭС. В тех организациях, где руководство действительно решило проводить автоматизацию производства, где оно обязало проектировщиков применять современные технологии проектирования, мотивируя их финансово и повышая в должности, там внедрение САПР идет успешно и затраты начинают окупаться в самом скором времени. Но в том же ведомстве достаточно организаций с совсем иной позицией руководителей: «Деньги на программы я дал, а на внедрение у нас нет времени. Давайте так, как-нибудь…». Результат — деньги потрачены, эффект минимальный.
Приведем примеры, максимально наглядно иллюстрирующие роль высшего руководства.
Чтобы обосновать приобретение «тяжелого» программного обеспечения для автоматизации электротехнического проектирования, в одном из проектных институтов было выполнено несколько проектов, подтвердивших заявленную эффективность средств автоматизации. Применение этого ПО позволило за один день выполнить работу, на которую обычно требовалось полторы-две недели. Тем не менее, покупке программного обеспечения категорически воспротивилось руководство электротехнического отдела, мотивировавшее свой отказ сложностью программ и отсутствием времени на обучение. Истинная же причина обнаружилась другом — работая по старинке, отдел имел большие трудозатраты, а следовательно мог рассчитывать на дополнительное финансирование, увеличение числа сотрудников. Применяя современные технологии, отдел рисковал потерять в деньгах. А единственным человеком, который сумел повлиять на руководство подразделения, стал генеральный директор института, заинтересованный в повышении эффективности и снижении трудозатрат.
Другой пример относится к практике работ в институте, входящем в структуры ОАО «Газпром». В начале процесса внедрения системы электронного технического документооборота авторы объясняли основные принципы и преимущества системы документооборота руководителям среднего звена. Говорилось, что такая система позволяет обеспечить полную прозрачность процесса проектирования для руководства всех уровней, и ее наличие является одним из важных факторов успешного функционирования САПР в целом.
И что же? Первая реакция руководителей отделов («Здорово, теперь я смогу отследить состояние дел в своем отделе и у смежников!») быстро сменилась другой: «Значит, теперь все что делается в моем отделе будет прозрачно и для моего руководства?!».
Как, а в предыдущем случае, решение о внедрении системы электронного документооборота было принято генеральным директором института, который в первую очередь заинтересован в обеспечении контроля над процессом выполнения проектных работ…
Таких примеров можно привести множество, но все они ведут к одному и тому же выводу: если высшее руководство не возьмет под свой контроль ход выполнения работ по автоматизации, все усилия могут быть сведены на нет в результате внутреннего саботажа на уровне руководителей отделов и групп.
Рабочая группа
Для успешного внедрения САПР необходимо создать рабочую группу, состоящую из сотрудников предприятия. Совместно с системным интегратором рабочая группа должна разработать и проанализировать различные варианты стратегии развития САПР, а затем представить их руководству предприятия с целью выбора оптимального решения.Руководителем рабочей группы должен быть человек, хорошо разбирающийся в процессе проектирования и имеющий полномочия управлять руководителями среднего звена. Как правило, это технический директор предприятия или заместитель генерального директора по производству. В состав рабочей группы следует включить ведущих специалистов производственных отделов и специалистов в области IT.
При формировании рабочей группы у руководителей отделов может возникнуть соблазн выделить специалистов по принципу «на тебе, Боже, что нам не гоже». Логика руководителей подразделений проста — у отдела есть план, его надо выполнять, и хорошие специалисты нужны в первую очередь на производстве. Но в таком случае группу можно и не создавать — от некомпетентных людей не стоит ждать грамотных экспертных оценок.
Не менее важно, чтобы руководители предприятия понимали всю важность работ, выполняемых группой, для развития предприятия в целом, а участники группы учитывали потребности не только своего отдела, но и смежников.
Не секрет, что попытки создать рабочие группы по внедрению САПР, соответствующие всем упомянутым требованиям, предпринимаются на многих предприятиях. Казалось бы, все условия соблюдены, группой грамотных и опытных специалистов руководит знающий и уважаемый человек, а результат работы — минимальный. Причины здесь просты: перегруженность всех членов группы текущими работами полностью парализует ее работу, а непонимание того, что важно не только автоматизировать свои рабочие места, но и обеспечить смежные специальности полной и пригодной для использования информацией, сводит к нулю все усилия, не позволяет выработать четкую и правильную концепцию комплексной автоматизации.
Этапы разработки и внедрения комплексной САПР
Нужно понимать, что разработка и внедрение комплексной САПР — задача непростая, и в короткий срок ее не решить. Временной интервал от начала разработки концепции автоматизации до ее полного внедрения может составить несколько лет, а это, как правило, не находит понимания у руководства.Процесс внедрения САПР на предприятии включает следующие этапы:
- обследование процессов проектирования;
- выработка концепции САПР, включая выбор средств автоматизации проектирования и разработку перечня основных работ по внедрению системы;
- формализация процесса выполнения работ — разработка стандартов предприятия, относящихся к работе в САПР;
- разработка концепции единого информационного пространства и средств ее реализации;
- обучение специалистов;
- выполнение пилотных (учебных) проектов с использованием САПР.
Обследование
Основа выполняемых работ — комплексное обследование предприятия. Как любой, даже самый высококвалифицированный врач не рискнет назначить лечение, не изучив предварительно состояние пациента, так и компания-интегратор не сможет предложить оптимальное решение по автоматизации процессов проектирования, основываясь только на опыте аналогичных компаний и не вникая в специфику предприятия.В сущности, обследование является подготовкой к внедрению.
Выработка концепции САПР
По результатам проведенного обследования определяется перечень задач, которые можно и нужно автоматизировать, возможность обмена между подразделениями информацией в электронном виде — согласно существующим на предприятии регламентам проведения проектных работ. Выбирается единая платформа (AutoCAD, Bentley), создается пошаговый план работ по внедрению САПР.Формализация процесса выполнения работ
Большинство организаций, с которыми работали авторы, сертифицировано или готово к сертификации по ISO. Но при изучении документации выясняется, что немалая часть документов разработана формально и не отражает текущего состояния дел. Основная задача данного этапа — определение перечня документов, который описывает основные регламенты работы, а также корректировка либо переработка данной документации. Процесс это довольно долгий и трудный: сложность описания технически грамотных регламентов усугубляется и постоянной нехваткой времени, и «замыленностью» взгляда.Отдельную проблему составляет стандартизация работы с программным обеспечением (прежде всего необходимо стандартизировать работу с офисными и графическими приложениями). Конечно, существуют ЕСКД, СПДС, СТП, определяющие правила оформления графической продукции, но количество вариантов оформления на основе этих стандартов не ограничено и они не регламентируют «культуру» черчения в AutoCAD. Все эти стандарты разработаны для ручного создания чертежей, не содержат таких понятий, как «блок», «слой», «правила использования стилей» и т.д, а предприятию необходим стандарт, отвечающий современным требованиям электронного оформления графической документации.
К сожалению, в России можно отметить лишь скромные попытки одиночек изменить ситуацию к лучшему, тогда как на Западе (например, в США) этой теме посвящены большие статьи, создаются группы ведущих специалистов, разрабатывающих рекомендации (см., например: www.nationalcadstandard.org, www.aia.org, www.indiana.edu).
Разработка концепции единого информационного пространства и средств ее реализации
Одна из главных задач комплексной автоматизации — создание единого информационного пространства. Что мы имеем в виду, используя этот популярный термин? В идеале — некую единую базу данных, с которой работает все программное обеспечение. Но при этом возникает ряд проблем:- разное программное обеспечение использует разные базы и структуры данных;
- вести и сопровождать базу должен соответствующий специалист: технолог, электрик, механик
и т.д. ; - объем общей базы, содержащий столь огромную и разнообразную номенклатуру, будет чрезвычайно велик.
Определим основные работы по созданию единого информационного пространства.
Первый шаг — это изучение программного обеспечения, используемого или планирующегося к использованию на предприятии в рамках каждой специальности.
Далее необходимо провести анализ внутренних потоков информации: какие данные, для какого программного обеспечения, для какой специальности и в каком формате необходимо передавать. Получив результаты такого анализа, можно формировать структуру базы данных проекта, выбирать средства реализации и разрабатывать интерфейсы к программному обеспечению. Но создание базы не означает окончания работ по созданию единого информационного пространства. Необходимо разработать регламент взаимодействия подразделений в ходе выполнения проекта.
Оптимальным решением этой задачи является внедрение системы управления проектными данными (СУПД), объединяющей в себе электронный документооборот, архив, планирование, контроль сроков и управление ходом проекта.
Существует мнение, что документооборот в проектных организациях — это в основном работа с теми документами, которые передаются заказчику. Но такие документы — лишь верхушка айсберга: 70−80% документооборота приходится на задания, промежуточную документацию, циркулирующую внутри предприятия, и электронные данные, передаваемые от одного программного средства к другому.
Анализ внутренних потоков информации позволяет составить формализованный список работ для каждого подразделения, на основе которого становится возможным составление сетевых графиков проекта. Это дает инструмент для автоматизации планирования и управления проектными работами.
Детальное изучение и формализация потоков, их содержание, описание взаимодействия подразделений и используемого ими программного обеспечения, определение возможности «выгрузки» данных из одних приложений и «закачки» их в другие — одна из сложнейших задач по внедрению СУПД, но ее выполнение позволит определить шаги по реализации следующих задач:
- планирование проектно-изыскательских работ и управление такими работами;
- передача электронных данных между различным программным обеспечением в соответствии с разработанным регламентом.
Разумеется, необходим механизм организации единого информационного пространства.
Обучение специалистов
Это постоянный и почти непрерывный процесс, который осуществляется как с привлечением сторонних организаций, так и собственными силами организации.Выполнение пилотных (учебных) проектов с использованием САПР
На всех этапах внедрения большую роль играет проведение пилотных проектов, то есть внедрение системы в опытно-промышленную эксплуатацию. В качестве пилотного выбирается наиболее характерный для предприятия и небольшой по объему проект (из числа выполненных ранее или новых), который в полной мере охватывает все задействованные специальности.Этап осуществляется в тесном сотрудничестве между проектировщиками и специалистами компании — системного интегратора. Конечно, проектировщики проходят обучение, но, как показал опыт, по ходу «пилота», предполагающего решение реальных задач, неизбежно возникает множество вопросов и ошибок. Разрешение этих проблем — первая задача внедрения, от успеха которой зависит отношение проектировщиков к новой для них среде проектирования.
Вторая задача пилотного проекта — адаптация и настройка ПО к особенностям проектирования в данной организации. Конечно, в рамках пилотного проекта программные продукты невозможно полностью адаптировать ко всем требованиям — это длительный процесс, который может осуществляться как совместно с системным интегратором, так и самими специалистами проектной организации в течении всего срока промышленного использования ПО. Но некоторые задачи адаптации, необходимые для запуска системы в промышленную эксплуатацию, могут быть решены. К таким задачам можно отнести создание новых отчетов, адаптацию меню, настройку баз данных, создание новых функций, пополнение баз данных…
Третья задача — определение необходимости создания интерфейсов к программам смежных отделов. (По сути — первые шаги к реализации идеи единого информационного пространства.)
Все это позволяет заказчику в кратчайшие сроки и максимально подготовленным начать выполнение реальных проектов и получать максимальную прибыль от вложенных средств.
В заключение — и в развитие темы! — хотелось бы предложить пример одного из самых успешных вариантов поэтапного внедрения комплексной системы автоматизации, реализованный в одной из ведущих проектных организаций ОАО «Газпром».
генеральный директор компании CSoft
Тел. +7 (495) 069−4488
E-mail: Ilya@csoft.ru
Internet: www.csoft.ru
Виталий Ревзин,
генеральный директор CSoft Engineering
Тел. (8313) 26−6733
E-mail: RevzinV@csoft.ru
Любовь Аверкина,
технический директор CSoft Engineering
Тел. (8313) 26−6733
E-mail: AverkinaL@csoft.ru
- 29 августа 2007 г.