Старые песни о главном, или Типичные ошибки внедрения САПР

Александр Лоза, Станислав Бетин

Отсутствие службы поддержки САПР и CAD-администратора

Гонка за новейшими версиями программного обеспечения

Отсутствие стандартов на выполнение проектной документации в электронном виде

Отсутствие разработанной технологии проектирования

Резюме

Пример действует сильнее угрозы.
П. Корнель

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

В прошлом году мы уже писали об этом и теперь должны пояснить, почему опять возвращаемся к этому вопросу. Дело в том, что дальнейшее интенсивное развитие компании (именно интенсивное, а не экстенсивное) напрямую связано с внедрением средств автоматизации проектно-конструкторской деятельности и систем по контролю за ошибками и качеством инженерных решений, с реализацией электронного документооборота в компании, с формированием электронного архива данных, единой проектной области для работы над проектами и т.д. и т.п. Правильный выбор САПР, то есть стратегии и тактики автоматизации, приводит к стремительному росту компании и, как следствие, к пониманию того, что инвестиции, вложенные в этот бизнес, сработали и продолжают работать на благо инвестора. И наоборот: неправильный выбор САПР приводит к тому, что инвестор, намучившись с одной САПР, вынужден покупать другую и опять мучиться — в итоге наступает разочарование, возникает недоверие и предприятие надолго отказывается от рассмотрения любых вопросов, связанных с закупкой САПР. На данный момент, к нашему сожалению, разочаровавшихся намного больше, чем счастливчиков, и все претензии при этом обрушиваются на поставщиков тех или иных САПР, хотя, выбирая САПР, предприятие добровольно соглашается с предложением поставщика, а потому все последствия ошибок, связанных с этим, так или иначе ложатся именно на это предприятие и на персонал, который принимал данное решение. Возможно, персонал предприятия был недостаточно сведущим в данной области; возможно, кто-то лоббировал вопрос о закупке; возможно, были другие причины… Можно ли избежать этих ошибок и разочарований? Конечно можно! Давайте рассмотрим  наиболее типичные из них, которые допускаются различными организациями при внедрении средств автоматизации процесса проектирования — САПР. Мы основываемся на своем трехлетнем опыте работы с более чем 60 предприятиями, расположенными на территории России и Украины и представляющими  различные отрасли промышленности. Статья ограничена рамками журнала, поэтому, если у кого-либо возникнет желание обсудить что-то более подробно, нам можно написать по электронному адресу support@bentleyplant.ru или позвонить в офис (все телефоны есть на нашем сайте www.bentleyplant.ru).

Теперь вернемся к ошибкам. В общем случае эти ошибки можно разделить на три основные группы:

•  технические;

•  организационные;

•  политические.

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

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

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

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

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

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

Отсутствие службы поддержки САПР и CAD-администратора

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

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

Важной задачей службы поддержки САПР является разработка стандартов и технологии проектирования. О необходимости решения данных задач будет рассказано ниже.

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

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

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

•  организация структуры хранения проектной документации;

•  модификация скрипта подключения пользователя для настройки ПО и т.д.

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

Гонка за новейшими версиями программного обеспечения

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

Слишком частая смена программного обеспечения отрицательно сказывается на процессе проектирования, поскольку:

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

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

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

•  рано или поздно проявятся определенные отличия нового ПО (100% совместимость практически не встречается), что потребует решения возникшей проблемы, и только опыт эксплуатации сможет выявить большинство таких отличий. Например, AutoCAD версии 14 спокойно обрабатывал ссылочные файлы, содержащие в названии символ «#», в то время как в AutoCAD 2002-2006 команда Express выключения слоя не допускает этот символ в названии ссылки;

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

Таким образом, переход на новую версию ПО должен тщательно планироваться, а не осуществляться сразу же после выхода очередной версии ПО или первой «заплатки».

Отсутствие стандартов на выполнение проектной документации в электронном виде

Редко на каком предприятии есть документально оформленные стандарты  на выполнение документации в электронном виде. Гораздо чаще сталкиваешься с ситуацией, когда в организации одни проектировщики, например, задают толщину линий по цвету, другие — по весу,  а третьи применяют для этого полилинию. Или же при использовании одной методики (например, когда толщина линии определяется по цвету) применяют различные настройки: у одного проектировщика желтый цвет обозначает толщину линии 0,5 мм, у другого — 0,25 мм. До поры до времени всё прекрасно работает. Однако рано или поздно неизбежно возникают следующие проблемы:

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

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

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

•  отсутствует возможность организации электронной библиотеки наработок.

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

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

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

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

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

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

Отсутствие разработанной технологии проектирования

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

Отметим, что применение соответствующего инструментария позволяет повысить производительность труда на 5%, использование современных технологий  — на 10%, грамотное управление — на 20%, а квалифицированное применение всех вышеперечисленных факторов позволяет повысить производительность труда на 70-90%.

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

Резюме

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

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

(Продолжение следует)

САПР и графика 3`2006