ERP и САПР: полная интеграция не нужна?Основными составляющими информационной среды машиностроительных предприятий выступают обычно система автоматизированного проектирования (САПР) и управленческая ERP. В идеале, эти элементы должны консолидироваться в единый комплекс, однако, как показывает практика, полная их интеграция зачастую оказывается излишней. Отраслевая спецификаОсобенности автоматизации бизнеса в значительной мере определяются отраслевой принадлежностью предприятия. Помимо специфичных бизнес-процессов, существенно различаться могут и финансово-экономические показатели, которые во многом определяют последовательность автоматизации. Единоразово вложить сотни тысяч или даже миллионы долларов в создание консолидированной информационной среды способны только традиционно «богатые» предприятия добывающей промышленности или экспортно-ориентированной металлургии. Между тем, костяк российской промышленности (77% по количеству предприятий) составляет машиностроение, автоматизация которого разбита на несколько элементов, зачастую не связанных друг с другом. Как в силу отраслевых особенностей, так и по причине не слишком высокой рентабельности, предприятия машиностроения начинали внедрение передовых технологий только на самых критичных участках своей деятельности. С управленческой стороны это касалось, в первую очередь, автоматизации бухгалтерского и налогового учета, с инженерной стороны - проектирования изделий. К настоящему времени большинство российских предприятий уже прошло первые этапы информатизации – бухгалтерия работает на основе «легкой» программы, конструкторы пользуются системы автоматизированного проектирования (в англоязычном варианте – Computer Aided Design, CAD). Однако с развитием информационных технологий растут и потребности бизнеса, кроме того, постепенно высвобождаются средства для новых инвестиций в ИТ. В результате учетное ПО заменяется полноценной ERP, а к инженерным системам добавляются продукты класса PDM (Product Data Management – управление данными об изделии), которые позволяют автоматизировать не только собственно процессы проектирования, но и управление жизненным циклом изделия. Интеграция CAD- и PDM-систем обычно протекает безболезненно, поскольку эти решения зачастую поставляются одним разработчиком. Проблем не возникает, даже если на практике предприятие использует системы от различных производителей, поскольку они обычно основываются на единых интерфейсах. Так, например, программа управления данными об изделии «Лоцман:PLM» не только легко встает рядом с «родным» CAD от АСКОНа, но и поддерживает интерфейсы других популярных систем SolidWorks, Unigraphics, Inventor и т.д. Консолидация между этими классами продуктов происходит настолько тесная, что иногда систему PDM называют составляющей единой САПР. Независимо от процессов интеграции конструкторских программ на предприятиях протекает развитие бухгалтерского ПО, которое, приобретая новые функции, перерождается в ERP. Именно на этом этапе автоматизации и появляются проблемы, связанные с дублированием функций и невозможностью получить консолидированную отчетность. Для решения подобных вопросов требуется создать единое информационное пространство, т.е. в первую очередь, интегрировать различные разработки. Грубая сшивкаО минусах «островковой» автоматизации написано немало статей, с необходимостью интегрировать различные решения рано или поздно сталкиваются все предприятия, вне зависимости от отраслевой принадлежности. Специфика же машиностроения заключается в том, что САПР и ERP-системы традиционно производятся различными разработчиками, причем если продукты первых в значительной мере определяются требованиями ГОСТов, то вторые ориентируют свои решения на бизнес-логику. В результате предприятие получает две абсолютно не связанные системы, интеграция которых является серьезной проблемой. Потребность переносить в ERP данные, полученные в САПР в результате проектирования, неоспорима. Так, например, чтобы эффективно планировать процессы заказа комплектующих, управлять работой складов и другими аспектами производства, необходимо обладать информацией о составе не только производимых, но и проектируемых изделий. Подобные данные зачастую переносятся из САПР в ERP вручную. Помимо того, что такой подход приводит к нерациональному расходу ресурсов, например, лишним трудозатратам, он порождает дополнительный источник ошибок. По данным исследования АСКОН, обнародованного на форуме «Белые ночи САПР 2005», ручное внесение состава изделия в ERP-систему приводит к ошибочному вводу до 30% информации. Кроме того, по словам представителей машиностроения, ручной перенос информации значительно затрудняется вследствие низкой исполнительной дисциплины на предприятиях. Зачастую сотрудники явно или скрыто бойкотируют попытки навязать им двойную работу – по проектированию изделия и вводу в ERP данных, уже внесенных в САПР. Возможно, именно эта причина определяет печальную статистику, которая свидетельствует о трети ошибок при ручном переносе информации из одной системы в другую. Все эти доводы говорят о жесткой необходимости создавать механизмы автоматизированного взаимодействия ERP и САПР, чем сегодня и занимаются как сами предприятия машиностроения, так и разработчики ПО. В настоящее время уже есть ряд успешных примеров интеграции, однако абсолютное большинство из них нацелено лишь на устранение ручного ввода данных в систему планирования. Такие решения фактически представляют собой модуль, обеспечивающий преобразование информации САПР к виду, понятному для интерфейсов ERP.
Такой подход снимает необходимость ручного переноса информации из САПР в управленческую систему, т.е. ликвидирует наиболее острые проблемы, однако его еще нельзя назвать полноценной интеграцией. Глобальная задача по созданию единого информационного пространства при этом остается решенной лишь частично, поскольку не предусматривается алгоритмов обратной передачи данных – из ERP в САПР. Между тем, существует точка зрения,что такое направление информационных потоков является целесообразным. Если разработчик будет знать, какие комплектующие стоят дешевле, какие находятся на складе в избытке и т.д., он сможет выбрать более выгодный для предприятия вариант конструкции. В принципе, знание отдельных параметров бизнес-процессов может привести к сокращению не только издержек, но и сроков реализации проектов. С другой стороны, прагматичные специалисты предприятий, выступавшие и на «Белых ночах САПР», отмечают, что даже если разработчик будет иметь возможность выбирать наиболее эффективные варианты на основе данных, полученных из ERP-системы, он не станет ей пользоваться. С точки зрения простого сотрудника, работающего «на зарплату», дополнительные функции создают только лишние сложности, поэтому они окажутся невостребованными. При этом оценить эффективность проектирования (с точки зрения его соответствия множеству «экономических» параметров ERP-системы без потери технических качеств) фактически невозможно, поэтому крайне сложно создать адекватную систему поощрений и мотивации. В этом отношении ситуация еще более осложняется нехваткой квалифицированных специалистов, что не перестают отмечать как руководители ИТ-отделов промышленных предприятий, так и разработчики ПО. Например, Александр Голиков, генеральный директор АСКОН отмечает, что «кадровый голод – до сих пор остается проблемой отечественного рынка автоматизации во всех сегментах». В ситуации, когда из всевозможных информационных потоков востребованной является только однонаправленная передача данных из САПР в ERP, по мнению некоторых экспертов, логично ей и ограничиться. При этом система в целом значительно упростится, что, как минимум, приведет к снижению ее стоимости. Если остановиться на меньшем функционале, система останется более прозрачной, в результате чего на более высоком уровне сохранится и надежность ее работы. Сегодня вопрос о целесообразности глубокой интеграции конструкторских и управленческих решений остается открытым. Пока большинство предприятий машиностроения останавливаются на варианте одностороннего взаимодействия – передаче данных только из САПР в ERP. Взаимодействие САПР с системой планирования ресурсов не является единственной проблемой, возникающей на пути автоматизации конструкторской деятельности. Интеграционные вопросы возникают также в отношении аппаратной части, недостаточные мощности которой могут свести на нет все преимущества современных решений. Чтобы обеспечить высокие скорости обработки 3D-изображений, производительности обычных «офисных» ПК зачастую недостаточно уже сегодня. «Узким» местом большинства компьютеров является слабая видеокарта, не предназначенная для работы с графическими приложениями. Однако этот фактор - не единственное ограничение. Даже при использовании ПК с мощной видеокартой, которые традиционно называют игровыми, производительность останется существенно ниже оптимальной. Чтобы достичь максимальной приспособленности аппаратной части к конкретным потребностям разработчика, все аспекты конфигурации рабочей станции должен проработать специалист по «железу». Стоимость и производительность графической станции САПР для различных конфигураций ПК Примечания: Источник: Arbyte, форум «Белые ночи САПР 2005» Грамотно подобранная аппаратная часть способна повысить эффективность труда не только за счет увеличения скорости обработки изображений. Существенного эффекта можно добиться, например, при помощи снижения шума рабочих станций. Не секрет, что гул кулеров и жестких дисков отвлекает внимание и, тем самым, снижает производительность труда. На первый взгляд эти факторы являются малозначительными, однако, при более детальном анализе ситуации можно придти к другим выводам. Согласно результатам исследования, проведенного Arbyte, обеспечение мероприятий по снижению шума дает почти 10%-ный прирост производительности труда, а количество ошибок при этом уменьшается примерно на треть. Оптимизация графических станций САПР является только одним из аспектов обеспечения высокой производительности современных программных продуктов. Отдельного обсуждения заслуживает выбор конфигурации расчетных комплексов, т.е. фактически серверных систем, оптимизированных под работу с конкретным ПО. Кроме того, в последнее время все чаще слышны разговоры о необходимости использовать специализированные системы 3D-визуализации. Все это дает основания говорить, что системы САПР, которые раньше являлись фактически чистым ПО, сегодня все больше приобретают черты программно-аппаратных комплексов. |