На российском рынке представлено множество PDM-систем — и отечественных, и западных. Однако меня всегда удивляло то, что одни и те же системы совершенно по-разному работают на предприятиях. Почему они работают не так, как должны, а то и не работают совсем?

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

Риск как мотивация

Не так давно мне довелось участвовать в переговорах о создании российско-японского совместного предприятия по производству автокомпонентов. Одним из требований японской стороны было использование системы управления инженерными данными (PDM). Российские руководители «пытали» японских коллег, чтобы выяснить, какая именно PDM-система нужна и зачем. Японский специалист долго не мог понять суть вопросов, а потом объяснил: «У вас больше шести инженеров». Другими словами, для координации усилий в достаточно многочисленном, с его точки зрения, коллективе PDM-инструмент необходим, иначе риски будут слишком велики. Западный бизнес (а к Западу мы по привычке относим и Японию) рассматривает не столько дополнительные преимущества использования ИТ-систем, сколько риски неиспользования, которые значительно возрастают при коллективной работе.

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

Прежде чем ответить на этот вопрос, постараемся определить, от каких факторов зависит скорость работы при проектировании машиностроительного изделия:

• время на проектирование, расчеты;

• время на поиск информации;

• время на решение возникающих проблем;

• время на согласование;

• потери времени на ожидание задания, входных данных;

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

• степень унификации;

• мотивация.

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

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

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

Как конкретно нормально работающая PDM-система помогает ускорить создание новых изделий? По-настоящему эффективно она может влиять только на три процесса: поиск информации, коллективную работу, электронное согласование — благодаря этому потери времени в проектах создания изделий снижаются в разы.

Простота или функциональность?

Разработчики материальных товаров (обуви, чайников, автомобилей и пр.) учитывают особенности и ограничения людей, которые будут ими пользоваться. Создатели нематериальных объектов, к которым относится и ПО, похоже, сильно переоценивают реальные возможности и мотивы пользователей, их способности и желание осваивать новые, сложные системы. Яркий тому пример — современные PDM-системы, они перегружены функциями: десятки кнопок, сотни команд, множество окон. Выглядит очень «круто», только шансов самостоятельно разобраться с таким программным инструментарием у рядового инженера нет.

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

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

Я и мои коллеги посещали предприятия, использующие PDM-решения известных международных компаний, чтобы изучить их практику и перенять положительный опыт. Но в большинстве случаев нас ожидало разочарование, мы слышали: «С этим мы не разобрались», «Это мы не используем» и, наконец, самый популярный ответ «Пока не используем, но будем внедрять в будущем». После нескольких лет сложных, тяжелых и дорогих проектов внедрения предприятие получило в лучшем случае электронный архив, где хранятся составы изделий и конструкторские документы. И всё.

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

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

Управление проектами

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

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

При этом все разработчики PDM-систем развивают свои инструменты проектирования бизнес-процессов в сторону все более сложных алгоритмов, и у внедренцев появляется соблазн создавать автоматизированные процессы «как есть», как бы перекладывая на программу функции конт­роля и зоны ответственности, предусмотренные в документах предприятия. В действительности же бумажные процессы согласования проходят совсем не так, как написано в стандартах, регламентах и инструкциях: начальники ничего не проверяют, ставя подписи формально; один человек может ставить подпись за другого; этапы в процессе выполняются в другом порядке, а при необходимости и вовсе пропускаются. Реализовать такой «формальный» процесс в электронном виде невозможно. Ключевая ошибка при внедрении ЭДО формулируется обычно так: «У нас проблемы с управлением бизнес-процессами, и нам нужна автоматизированная система, чтобы сотрудники находились в жестких рамках и процессы выполнялись правильно». На самом деле проблема в самих процессах.

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

Коллективная работа

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

В практике российских предприятий принято последовательное проектирование: смежным подразделениям передаются уже готовые документы, поскольку считается, что работа с «сырыми» данными приводит к большому объему переделок. Однако это не совсем так: подобный порядок — не что иное, как наследство чисто бумажной технологии проектирования, когда возможностей для параллельной работы практически не было. Реальный опыт показывает, что изменений все равно не избежать, и чем раньше об этом узнает конструктор, тем меньше ему нужно будет переделывать.

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

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

Управление изменениями

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

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

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

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

Если в ходе создания предварительного состава появляется спецификация деталей (сборочных единиц) или документ с обозначением, которое уже присутствует в архиве, то система автоматически создает «изменение» и при последующем проведении в архив всегда знает, что на что меняется. Важно, что при этом конструктор работает со структурой изделия обычным образом, а система сама отслеживает все изменения. Это соответствует реальной работе: конструктор сначала разрабатывает новый узел, его чертежи и только потом оформляет «извещение об изменении». Большинство же PDM-систем предлагает конструктору выбрать архивный узел и указать, какие изменения в нем необходимо сделать, то есть навязывает ему обратный процесс. Для крупных изделий и больших изменений это очень неудобно, требует много времени и потенциально опасно, так как любая ошибка конструктора приведет к появлению неактуального состава в архиве.

Архив

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

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

К тому же мониторы в цехах пока выглядят скорее экзотикой, и если проектирование и согласование конструкторской документации может идти в электронном виде, то для производства изделия наверняка потребуются бумажные чертежи и, соответственно, бумажный документооборот. Чтобы соединить бумагу и «цифру», в PDM-системе необходимо учитывать бумажные подлинники. Часто бывает достаточно в PDM-системе при регистрации документа в архиве ввести атрибуты «инвентарный номер» и «список рассылки», это позволит отказаться от ведения бумажных карточек документов.

Поиск

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

Кроме актуальности электронного архива, необходимо обеспечить конструктору простой и удобный поиск информации в нем. Это вроде очевидно, однако не все так просто. Очень часто конструктор не знает точно, что именно он ищет, у него может быть только косвенная информация о том, что надо найти. И многие PDM-системы в силу своей универсальности предлагают такой выход: поскольку предметная область заранее неизвестна, они предлагают искать абстракт­ные объекты. Бывает, что функционал поиска настолько сложный, что не каждый конструктор может с ним разобраться.

Выход — помимо стандартного поиска по атрибутам объекта, предусмотреть в PDM-системе поиск деталей (сборочных единиц), документов по входимости или собственным связям. Например, если конструктор совсем не помнит ни обозначения, ни наименования детали, но знает, что искомая деталь применялась в конкретном проекте и изготавливалась из определенного материала, он может задать поиск по этим параметрам. Задать их можно в одном окне — быстро, удобно и очень просто. Кроме этого, всегда должен быть доступен простой поиск по любому атрибуту.

* * *

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

• Юрий Сирота, руководитель разработки комплексных решений компании «Аскон»; ysirota@ascon.ru