Специалистам по автоматизации свойственно все усложнять, причем искусственно созданные проблемы затем решаются путем добавления различной логики и данных, необходимость которых сомнительна по существу, а их обработка оказывается непозволительно дорогой в реализации. А так ли уж плохи процессы «как есть»? Так ли уж неправы были люди, которые их придумали и выполняют, причем иногда с момента основания компании или предприятия? Попытаемся ответить на эти вопросы применительно к проектной деятельности, результатом которой являются технические требования, задания на разработку, 3D-модели и чертежи изделия, ведомости и спецификации.
Разработчики систем управления документами и инженерными данными неизбежно сталкиваются с такими задачами, как управление изменениями самих объектов проектирования, управление правами доступа, управление состояниями объектов и условиями, при которых эти состояния изменяются. Наиболее распространенным методом решения таких задач является использование статических данных, которыми обрастает объект проектирования, обретая при этом дополнительную логику поведения и «обслуживания». Например, в области управления изменениями объекту (изделию или документу) присваивается статическое свойство «Версия», чье значение увеличивается после каждого «возврата» объекта в систему. Такой вариант, безусловно, работает, но часто с логическими ошибками и сопровождается сопротивлением со стороны пользователей, которым приходится работать с дополнительными понятиями и заполнять некоторые статические данные вручную. Причиной тому служит искусственная связь процессов проектирования и управления.
В производстве качество планирования собственно производства и закупок определяется качеством исходных данных, таких как состав изделия и описание способов изготовления (или способов получения) изделия и его составных частей. Что представляют собой эти данные и как они рождаются? Такими исходными данными в отечественной практике являются так называемые комплекты технологической документации, в которых содержится информация о порядке изготовления деталей и узлов (маршрутные, маршрутно-операционные и операционные карты). Кроме того, в документации могут присутствовать подробные инструкции, а также определяться потребности в материальных ресурсах в виде ведомостей. Потребности в трудовых ресурсах при этом, как правило, описываются в других, не технологических документах. Проблема в том, что все эти документы — исключительно плод «бумажного» подхода, принятого в эпоху индустриализации экономики, которая характеризовалась довольно узким взглядом на производство. Во-первых, это было, как правило, серийное производство. Во-вторых, производство однотипных изделий, изготавливаемых в соответствии со «спущенным сверху» планом, а не желаниями конкретного покупателя, которого как такового раньше и не было. В-третьих, применялось универсальное оборудование — без ЧПУ, которого на момент создания стандартов ЕСТД (единая система технологической документации) просто не существовало. В-четвертых, подразумевалось использование неквалифицированной рабочей силы. Задачи автоматизации перед создателями ЕСТД не стояло, соответственно, с появлением систем автоматизации планирования производства мы пожинаем плоды старого подхода, связанного с ручным вводом данных в системы планирования, что чревато дополнительными затратами, задержками и ошибками.
Конечно, нашлись разработчики, которые создали программы, предназначенные для автоматизации разработки комплекта технологической документации, и даже появился целый класс систем — САПР ТП (система автоматизированного проектирования технологических процессов). Все это неплохо для инженеров-технологов, поскольку позволяет избавиться от рутины при заполнении массы документов, однако конечный результат представляет собой все тот же самый комплект документов по ЕСТД, малопригодный для автоматического использования в планировании закупок и производства, хотя основные технологические документы (карты) называют «технологическими процессами».
BPM в инжиниринговой деятельности
Могут ли помочь методики, которые принято объединять термином BPM (Business Process Management), в сфере инжиниринга? Да, но есть нюансы.
Во-первых, ключевая задача BPM — описание бизнес-процессов, что занимает много времени, дорого и не все компании готовы идти на это.
Во-вторых, пока консультанты опишут процессы и сделают «правильные» шаблоны процессов, жизнь уйдет вперед и шаблоны станут неактуальны. Кроме того, шаблоны обычно накладывают ограничения, неприемлемые для динамичного по своей природе предприятия. Конечно, можно постоянно изменять шаблоны, что будет похоже на гонку за собственным хвостом.
В-третьих, деятельность по проектированию плохо поддается «шаблонизации». Конечно, у ведущего конструктора (руководителя проекта) всегда есть общее представление об изделии и укрупненный план работ, а в организации есть типовые процессы согласования документации, но «середину» — выработку конкретных инженерных решений, в которой и заключается суть инженерной деятельности, — под шаблон не подгонишь.
Изменить ситуацию можно путем динамического подхода, при котором бизнес-процессы (или «задания») естественным способом порождаются самими исполнителями в рамках выполнения других заданий, а результаты их работы в режиме реального времени прикрепляются к выходным данным такого «живого» процесса.
Динамика инжиниринга
Попробуем подойти к решению задач управления проектированием и производством с позиции «динамического» процессного подхода. Возьмем за основу каноническое, согласно методологии IDEF0, понимание процесса с его входами, выходами, ресурсами, с управлением и обратной связью. Имеем в виду, что процессы могут быть связаны друг с другом двумя типами связей: горизонтальными (между предыдущими и последующими процессами) и вертикальными (иерархия процессов или декомпозиция работ). Для процессов выделим два уровня: уровень описаний процессов или шаблонов (в которых декларируется, кто, что, когда, на основе каких входных данных будет выполнять такие процессы) и уровень экземпляров (непосредственно исполняющихся процессов). Для ключевого понятия — изделия — также выделим уровни описаний (это собственно конструкторская документация, включающая как модели и чертежи, так и описание структуры изделия в виде спецификаций) и экземпляров. Теперь посмотрим на задачи управления проектированием и производством изделий сквозь призму этих понятий.
Для процессов проектирования изделий и технологической подготовки производства получаем следующую логику:
- Конструкторы и технологи исполняют экземпляры инженерных процессов.
- Входами экземпляров процессов проектирования изделия являются исходные технические требования, а выходами — конструкторская документация.
- Входами экземпляров процессов технологической подготовки производства являются описания изделий, а выходами — описания производственных процессов.
- Исполнители инженерных процессов самостоятельно определяют их иерархию и последовательность, формируя так называемый естественный план работ. Экземпляры инженерных процессов и связи между ними могут быть порождены и на основе шаблонов (описаний), но, как уже было отмечено, с «шаблонизацией» инженерных процессов торопиться не стоит.
- Руководитель проекта, который инициирует процессы «стартового» уровня, должен быть в состоянии контролировать ход работ, видя их структуру, занятость исполнителей и результаты.
Для производственных процессов логика такова:
- Участники производственной деятельности исполняют экземпляры производственных процессов. Речь идет о работниках, отвечающих за исполнение заказов (заказов на продажу, на закупки, на производство, на перемещения): сбытовиках, снабженцах, производственниках и логистах. Заказы здесь — это прямой аналог экземпляров процессов.
- Входами экземпляров производственных процессов являются экземпляры изделий, причем вместо «экземпляра» может быть «партия», а вместо «изделия» — «заготовка» или «материал».
- Выходами экземпляров производственных процессов являются экземпляры изделий.
- Экземпляры производственных процессов порождаются только на основе описаний (шаблонов или техпроцессов), которые были созданы на этапе подготовки производства. Иными словами, производство — не лучшее место для свободы творчества.
- Складские запасы легко «раскрываются» за счет понятия экземпляра (партии) изделия (полуфабриката, материала), а к изменению запасов приводит исполнение заказов.
- Управление в производстве, в отличие от инженерии, сложнее, и здесь ручным проектным управлением не обойтись, поэтому управленцу должна помогать программа, реализующая некоторый алгоритм планирования и анализа исполнения производственных процессов.
От теории — к практике
К чему все эти рассуждения, зачем изобретать велосипед — ведь изделия все равно сегодня как-то проектируются и производятся? Дело в том, что сейчас компаниям приходится ездить как минимум на двух «велосипедах»: один — для управления проектированием, другой — для производства. Несмотря на то что концепция Product Lifecycle Management («управление данными об изделии») формально охватывает и процессы производства, в реальности традиционные системы PLM производством не управляют, отдавая эту миссию системам ERP. Соответственно, предприятия-пользователи пытаются интегрировать эти «велосипеды», каждый из которых построен на своих механизмах. И если для большой и стабильной компании данная интеграция вполне посильна, то для небольшой — нет. Таким компаниям желательно иметь один «велосипед», причем такой, на который можно сразу сесть и поехать, а не осваивать годами.
Одним из таких средств для небольших развивающихся компаний является система Dexma компании «АСКОН», построенная на «процессном» движке, охватывающем оба ключевых процесса — проектирование и производство. Для инженерных процессов Dexma дает возможность естественным образом декомпозировать работы, выдавать и исполнять задания, планировать и контролировать их с учетом загрузки исполнителей. Автоматическая привязка результатов к процессам позволяет управлять изменениями данных об изделиях и процессах (способах) их изготовления без введения дополнительных статических понятий. А естественная иерархия процессов и логика их исполнения позволяют управлять правами доступа и «видимостью» сделанных изменений. Через архив обеспечивается параллельная работа пользователей с инженерной информацией.
Среди важнейших особенностей Dexma следует отметить подход к описанию процессов изготовления изделия — эти процессы описываются в тех же терминах (входы, выходы, ресурсы, горизонтальные и вертикальные связи), в которых работает производственный контур системы. Иными словами, указывается, что для изготовления такого-то изделия нужно выполнить такой-то производственный процесс и на выходе получить изделие, а на входы подать такие-то компоненты и привлечь в качестве ресурсов такие-то объекты производственной инфраструктуры. В свою очередь, каждый компонент также является выходом процесса изготовления или закупки — процесс описания продолжается вплоть до последнего винтика. Производственные процессы могут декомпозироваться на цепочки: этапов, операций, переходов — с указанием их длительности и иных свойств.
Исполнение производственно-логистических процессов работает по классическому циклу Material Requirements Planning с обратной связью, однако понятия MRP выражены в «процессных» терминах так, как это было описано. При старте исполнения заказа на продажу изделия программа «думает», как его исполнить. Если экземпляры изделия недоступны на складе и их нельзя просто отгрузить, то решается вопрос о выборе процесса, который нужно выполнить, чтобы изделие появилось на нужном складе в нужное время. Для исполнения этого процесса порождаются новые заказы (процессы) на закупку, производство или перемещение с учетом того, что им должно быть дано на вход и как им обеспечить выполнение своей функции. Далее каждый заказ запускается на исполнение, в результате которого происходит изменение состояния запасов (или количества экземпляров изделий) на складе, что учитывается при следующем планировании, и так далее.
Система Dexma реализована в виде облачного сервиса, что привлекательно для небольших динамичных компаний, которым важно направлять финансовые и человеческие ресурсы в основные процессы, а не на внедрение и поддержку сложных аппаратно-программных комплексов. Для тех, кто еще не готов доверить облаку свои данные, имеется возможность размещения Dexma на собственной ИТ-инфраструктуре.
***
Взгляд с позиций BPM позволил предложить естественное решение «классических» задач и проблем PLM, а его воплощение в виде доступных облачных сервисов дало возможность предоставить машино- и приборостроительным компаниям сквозную систему управления ключевыми бизнес-процессами.
Николай Нырков (nyrkov@dexma-plm.com) — директор Dexma Labs (Санкт-Петербург).
