Система управления жизненным циклом
Пространства имён
Действия на странице
«Управление жизненным циклом» — это термин, которым люди пытаются обозначить практику обеспечения связности всех состояний системы, как в прямом направлении (например, передача рабочей документации на стадию сооружения), так и в обратном направлении (например, учет данных по надёжности аналогичных эксплуатируемых уже систем на стадии проектирования новых). Эту практику трудно выделить из традиционных практик системной инженерии – управления требованиями, создания системной архитектуры, системной интеграции, верификации и валидации и т.д..
«Управление жизненным циклом» сводится к необходимости освоения привычных для системной инженерии практик:
- управление информацией («нужная информация должна быть у нужных заинтересованных сторон вовремя, и в доступной для её использования форме»),
- управление конфигурацией («проектная информация должна соответствовать требованиям, информация «как построено» должна соответствовать проекту, в том числе проектным обоснованиям, физическая система должна соответствовать информации «как построено», а разные части проекта при этом должны соответствовать друг другу», иногда часть этой практики назвают «управление изменениями»).
Содержание
СУЖЦ vs PLM
Системная инженерия редко использует понятие «управление жизненным циклом», но это понятие часто используется поставщиками программных систем PLM (Product Life cycle Management).
В России сейчас проходит серия межотраслевых и международных мероприятий (совещаний, конференций и т.д.), где активно используется название «система управления жизненным циклом» (СУЖЦ), вводимое взамен PLM (product lifecycle management). Эта замена термина требует некоторой расшифровки.
Слово «продукт» из PLM в СУЖЦ пропало не случайно, ибо речь идет о сложных инженерных объектах – если вертолёт еще можно с натяжкой назвать «продуктом» в силу его серийности, то атомная станция «продуктом» обычно уже не называется. Поэтому «жизненным циклом» какой именно системы тут «управляется», нужно уточнять в каждом конкретном случае. «Система УЖЦ системы» немного запутывает, но именно это и имеется ввиду.
«Система УЖЦ» — это прежде всего социотехническая система, т.е. она включает не только программные средства PLM, но и организацию людей (практики работы, профессиональные роли, необходимый инструментарий для поддержки этих профессиональных ролей, утвержденные виды жизненного цикла каких-то конкретных рабочих продуктов и т.д.). Поэтому специалисты в слове «система» слышат одно («информационная система», прежде всего PLM), а менеджеры — совсем другое («система менеджмента», способ организации работ). Тут еще нужно отметить западную традицию произвольного добавления слова management в сочетаниях «чего-нибудь менеджмент».
По-новому сформулированная СУЖЦ не использует PLM как обязательный класс программных средств, вокруг которого такая система строится. В крупных инженерных проектах обычно используется сразу несколько (чаще всего существенно «недоосвоенных») PLM разных вендоров, и при создании СУЖЦ речь идёт обычно уже об их межорганизационной интеграции. Конечно, при этом решаются и вопросы, как интегрировать в СУЖЦ информацию и тех систем, которые еще не имеют связи с какой-то из PLM систем расширенного предприятия. Термином «расширенное предприятие» (extended enterprise) обычно называют созданную посредством системы контрактов организацию из ресурсов (людей, инструментов, материалов) участвующих в конкретном инженерном проекте различных юридических лиц. В расширенных предприятиях ответ на вопрос, в какую именно PLM интегрируются данные какой именно из систем CAD/CAM/ERP/EAM/CRM/и т.д.. становится нетривиальным: владельцам разных предприятий не предпишешь использовать программные средства одного поставщика.
А поскольку PLM-система всё-таки являтся программными средствами, а «система управления» из СУЖЦ явно понимается в том числе как «система менеджмента», то термин СУЖЦ подразумевает явно и организационный аспект, а не только аспект информационных технологий. Тем самым фраза «использование PLM для поддержки системы управления жизненным циклом» вполне осмыслена, хотя может запутывать при дословном переводе в ней “PLM” на русский.
Тем не менее, понимание «системы управления жизненным циклом», когда ею занимаются специалисты из IT-служб, немедленно нивелируется назад к «только софту», подозрительно напоминающему программные средства PLM. И после этого переупрощения начинаются трудности: «коробочная» система PLM от какого-то поставщика программных средств автоматизации проектирования обычно сразу представляется конструктивно, как набор программных модулей из каталога этого поставщика, вне связи с поддерживаемыми инженерными и менеджмерскими функциями, и рассматривается как тройка из следующих компонент:
- датацентрический репозиторий данных жизненного цикла,
- «система документооборота» (workflow engine) для поддержки «управления»,
- «портал» для просмотра содержимого репозитория и состояния документооборота.
Назначение СУЖЦ
Главное назначение: СУЖЦ обнаруживают и предотвращают коллизии, неизбежные при коллаборативной разработке. Все остальные функции СУЖЦ являются производными, поддерживающими эту главную функцию.
Главная идея любой современной СУЖЦ — это использование аккуратного и непротиворечивого представления системы и окружающего её мира в неизбежно разнородных и изначально несовместимых между собой компьютерных системах расширенной организации. Использование виртуальных макетов, информационных моделей, датацентрических репозиториев проектной информации обеспечивает выявление коллизий при «сооружении в компьютере», «виртуальной сборке», а не при выносе чертежей и других моделей проекта в материальную реальность в ходе действительного сооружения «в металле и бетоне» и пуска в эксплуатацию.
Идея СУЖЦ не имеет тем самым отношения к разнообразным «автоматизациям проектирования», прежде всего – к «порождающему проектированию» (generative design) и «порождающему производству» (generative manufacturing). СУЖЦ озабочена более не синтезом, а анализом: обнаруживает и/или предотвращает коллизии в результатах проектирования отдельных подсистем, когда их будут собирать вместе по самым разным технологиям:
- сливая данные проекта вместе в один репозиторий,
- запуская алгоритм проверки целостности для распределенных в нескольких репозиториях инженерных данных,
- проводя актуальную «виртуальную сборку» и имитационное моделирование для специально отобранного подмножества проектных данных.
Моделеориентированный подход
Использование СУЖЦ подразумевает отказ не только от бумаги в проектировании, но и от «электронной бумаги» (.tiff или других растровых форматов) и переход к датацентрическому представлению информации. Сравнить две модели, существующие на бумаге в каких-то нотациях и найти в них несоответствия много сложнее и дольше, нежели предотвращать коллизии в структурированных электронных документах, использующих не растровую графику, а инженерные модели данных.
Модель данных может быть разработана в соответствии с каким-то языком, например:
- в терминах стандарта описания метода разработки ISO 24744),
- метамодель (в терминах консорциума стандартизации OMG),
- модель данных/справочные данные (в терминах стандарта интеграции данных жизненного цикла ISO 15926).
Именно такой переход к структурно представляемым моделям, существующим уже на ранних стадиях проектирования и называется «Системной инженерией на основе моделей» (MBSE, model-based systems engineering). Снимать коллизии при помощи компьютерной обработки данных становится возможным уже на самых ранних стадиях жизненного цикла, еще до появления полноценных 3D моделей конструкции.
- обеспечивать механизм передачи данных из одного приложения CAD/CAM/ERP/PM/EAM/и т.д. в другое – причем в электронном структурированном виде, а не в виде «пачки электронной бумаги». Передача данных из одной инженерной информационной системы (с четким пониманием откуда, куда, когда, что, зачем, как) — это часть обеспечиваемой СУЖЦ функциональности. Тем самым СУЖЦ должна поддерживать workflow (ход работ, который частично выполняется людьми, а частично компьютерными системами).
- контролировать версии, то есть предоставлять функцию управления конфигурацией — как моделей, так и физических частей системы. СУЖЦ поддерживает таксономию требований разного уровня и предоставляет средства для проверки коллизии разноуровневых проектных решений и их обоснований с этими требованиями. В ходе инженерной разработки любое описание системы, любая её модель изменяются и дополняются многократно, и существуют поэтому во множестве альтернативных версий разной степени правильности, и в разной мере соответствующих друг другу. СУЖЦ должна гарантировать, что для текущей работы используется только правильное сочетание этих версий.
Архитектура СУЖЦ
Архитектурных решений для СУЖЦ может быть множество, одна и та же функция может быть поддержана различными конструкциями и механизмами работы. Можно выделить три вида архитектуры:
- Традиционные попытки создать СУЖЦ – это обеспечить важнейшие передачи данных по принципу «точка-точка» между разными приложениями. При этом может быть использована какая-нибудь специализированная система поддержки workflow (BPM engine, «движок управления бизнес-процессами»), или система обработки событий (complex event processing engine). К сожалению, объем работы по обеспечению обменов «точка-точка» оказывается просто грандиозным: каждый раз требуются специалисты, разобравшиеся в обоих связываемых системах и методе передаче информации.
- Использование стандарта интеграции данных ЖЦISO 15926 по методу «ISO 15926 outside», когда для каждого инженерного приложения разрабатывается адаптор в нейтральное представление, соответствующее стандарту. Тем самым, все данные получают возможность встретиться в каком-то приложении и коллизия между ними может быть обнаружена – но для приложения требуется разработать лишь один адаптер передачи данных, а не несколько таких адаптеров (по числу других приложений, с которыми нужно обеспечить связь).
- PLM (Teamcenter, ENOVIA, SPF, NET Platform и т.д.) — используется стандартизованная архитектура, за тем лишь исключением, что используемая в каждой из этих PLM модель данных менее универсальна в плане отражения любой предметной области инжиниринга, а также не является нейтральным и доступным всем форматом. Так что использование ISO 15926 в качестве базового представления при передаче данных в СУЖЦ можно считать дальнейшим развитием идей, по факту реализованных в современных PLM.
По архитектуре управления конфигурацией, СУЖЦ можно разделить на три вида:
- «репозиторий» (актуальное хранение всех данных проекта в одном репозитории СУЖЦ, куда копируются данные оттуда, где они были разработаны),
- «регистр» (СУЖЦ поддерживает список адресов данных жизненного цикла в многочисленных репозиториях других САПР, систем инженерного моделирования, PLM, ERP и т.д.),
- «гибридная архитектура» — когда часть данных копируется в центральный репозиторий СУЖЦ, а часть данных доступна из других мест по ссылкам.
Архитектора СУЖЦ должна также описывать:
- «портал» (в том числе «веб-портал»), его функциях и способ реализации. Само наличие портала позволяет успокоить топ-менеджеров демонстрируя отсутствие коллизий. К архитектурным решениям по «порталу СУЖЦ» предъявляются специфические требования.
- алгоритмы проверки целостности/непротиворечивости данных жизненного цикла, а также описание работы этих алгоритмов:
- стандартный модуль в отдельном приложении, работающий над данными в репозитории этого приложения – будь это САПР или PLM;
- специально разработанное для СУЖЦ программное средство проверки коллизий, имеющее доступ к данным разных приложений, находящихся в центральном репозитории СУЖЦ;
- специально разработанное программное средство, обращающееся через интернет по защищенному каналу к разным хранилищам данных, находящимся в разных организациях;
- специально запрограммированные проверки с контролем коллизий при загрузке разных инженерных наборов данных в центральный репозиторий СУЖЦ;
- комбинация из всех перечисленных методов – разных для разных типов коллизий; и т.д.
- способ взаимодействия пользователей СУЖЦ (инженеров-проектантов, закупщиков, монтажников, менеджеров проекта сооружения и т.д.), и как именно программное обеспечение СУЖЦ поддерживает это взаимодействие способом, предотвращающим появление коллизий. Стандарты системной инженерии (в частности, стандарт практик системной инженерии ISO 15288) требуют выбора вида жизненного цикла для инженерии сложных объектов и указания того, какие варианты практик системной инженерии будут использованы. Модель жизненного цикла является одним из основных артефактов, которые служат для организационных договоренностей по координации работ расширенной организации инженерного проекта. Скоординированные работы в ходе коллаборативной разработки (collaborative engineering) – это залог малого числа проектных коллизий. Как именно поддержит модель жизненного цикла СУЖЦ? Так, системы PLM обычно не находят место моделям жизненного цикла, и уж тем более моделям организации. Поэтому для СУЖЦ нужно искать другие решения по программной поддержке этих моделей.
- Организационный аспект перехода к использованию СУЖЦ. Переход к использованию СУЖЦ может вызвать существенное изменение в структуре и даже кадровом составе инжиниринговой компании: не всех землекопов берут в экскаваторщики, не всех извозчиков берут в таксисты.
Главное для СУЖЦ – насколько предлагаемое решение способствует раннему обнаружению, а то и предотвращению коллизий. Ежели речь заходит о чём-то другом (содержательный выбор вида жизненного цикла в соответствии с профилем риска проекта, управление старением, управление стоимостью и реформа сметной системы, освоение axiomatic design, сооружение с поставками «точно вовремя», порождающее проектирование и сооружение, а также многое-многое другое, также крайне полезное-современное-интересное), то это вопрос других систем, других проектов, других методов, других подходов. СУЖЦ должна хорошо делать своё дело, а не плохо решать огромный набор произвольно выбираемых чужих задач.
У архитектора СУЖЦ тем самым две основные задачи:
- породить некоторое количество лучших архитектур-кандидатов и их гибридов
- совершить многокритериальный выбор из этих архитектур.
- содержательное рассмотрение (содержательность критериев выбора)
- оформление результата (обоснование).
Источник
Calls – современные технологии управления жизненным циклом проекта
Проектом принято называть совокупность действий, направленных на достижение поставленной производственной или коммерческой цели и связанных с использованием ресурсов различного типа. Технология управления проектами не зависит от содержания проектов, что позволяет рассматривать ее как базовую (инвариантную). Специальный термин Ргоject Маnagement (РМ) обозначает класс управленческих задач, связанных с планированием, организацией и управлением действиями, направленными на достижение поставленных целей при заданных ограничениях на использование ресурсов.
Типовыми задачами РМ являются:
разработка планов выполнения проекта, в том числе разработка структурной декомпозиции работ проекта и сетевых графиков;
составление и оптимизация календарных планов с учетом ограничений на ресурсы; разработка графиков потребности проекта в ресурсах;
мониторинг выполнения работ и сравнение текущего состояния с исходным планом;
формирование управленческих решений, связанных с воздействием на процесс или с корректировкой планов;
формирование различных отчетных документов.
Действия, приводящие к выполнению проекта, потребность в которых выявляется в ходе планирования, могут быть типовыми бизнес-процессами (закупка комплектующих, разработка документации, производство). Такие бизнес-процессы часто выполняются по формальным схемам (моделям) [IDEF/0/3]. Исполнители (организации или сотрудники), действуя в соответствии с заданной технологией (моделью процесса), получают и выполняют задания, соответствующие структурным элементам бизнес-процесса (операциям). Автоматизация управления потоком таких заданий — функция технологии «workflow» (дословно с английского — «поток работ»).
Особую роль в их реализации сыграли и продолжают играть информационные технологии, развитие которых можно охарактеризовать таблицей 1.
Эволюция информационных технологий
Автоматизация выполнения простейших функций
Интеллектуальная направленность информационных технологий, развитие информационного моделирования, прогнозирования и управления
Расширение областей применения информационных технологий, создание локальных сетей и электронных баз данных. Привлечение к использованию информационных технологий руководителей всех уровней управления
Стремление к объединению информационных ресурсов и кооперации при создании информационных технологий; совместное использование информации; виртуальные предприятия
В итоге информация стала основным товаром.
Информацию, циркулирующую в системе информационной поддержки жизненного цикла изделия, можно условно разделить на три класса:
данные о продукции (изделии);
данные о выполняемых процессах;
данные о ресурсах, требуемых для выполнения процессов.
Под изделием (конечным) понимается комбинация материалов, предметов, программных и иных компонентов, готовых к использованию по назначению. Компоненты конечного изделия тоже являются изделиями. Данные об изделии составляют основной объем информации в ИИС. Международные стандарты ИСО 10303 и ИСО 15384 регламентируют технологию представления данных об изделии и его компонентах на стадии проектирования и подготовки производства, стандарты ИЛП [DEF STAN 0060] — представление данных об изделии в контексте обеспечения эффективной эксплуатации, стандарты серии ИСО 9000 рассматривают данные о качестве изделий.
Одним из ключевых понятий в проектировании является ресурс — совокупность материальных, финансовых, интеллектуальных или иных ценностей, используемых и расходуемых в ходе деятельности, связанной с разработкой, проектированием, производством или эксплуатацией изделия. Некоторые классификационные характеристики ресурсов приведены в таблице 2.
Классификационные характеристики ресурсов
По типу физической природы
По характеру расхода и возобновления
По профилю доступности
По способу измерения величины
Не расходуемый (используемый)
Расходуемый, но возобновляемый
соответствии с расписанием
Измеряемый в количественных единицах
Измеряемый в логических единицах (есть/нет)
Между ресурсами могут существовать отношения заменяемости, когда один ресурс может заменить другой, и взаимозаменяемости, когда ресурсы могут заменять друг друга. Ресурсы могут быть простыми и составными и соответственно образовывать иерархические структуры.
Структуры данных, описывающих ресурсы различного типа, регламентируются стандартом ИСО 15551.
Процесс (бизнес-процесс) — это совокупность последовательно или/и параллельно выполняемых операций, преобразующая материальный или/и информационный потоки в новые потоки с другими свойствами. Бизнес-процесс протекает в соответствии с управляющими директивами, вырабатываемыми на основе целей деятельности. В ходе процесса потребляются финансовые, энергетические, трудовые и материальные ресурсы и выполняются ограничения со стороны других процессов и внешней среды.
Описание процесса может быть представлено как совокупность составляющих процесс операций, необходимых условий и ресурсов, входных и выходных потоков. Совокупность стандартизованных информационных моделей изделия, процессов и ресурсов образует единую интегрированную модель, обеспечивающую информационную поддержку задач, выполняемых в ходе жизненного цикла (ЖЦ).
На каждой стадии ЖЦ требуется свой объем данных, определяемый содержанием решаемых задач. Например, на стадии проектирования и разработки используются данные об изделии, о процессе проектирования, о требуемых организационных и иных ресурсах. Информационная модель технологической подготовки производства трактуется как описание процесса, использующее данные об изделии и технологических ресурсах. Модель производства также может быть представлена как описание процесса, связанного с данными об изделии и потребных материальных, финансовых и иных ресурсах. Частные информационные модели могут быть сформированы для специфических точек зрения («управление качеством» или «обеспечение эффективной эксплуатации»).
У каждого класса данных есть свой набор методов работы, который образует технологический слой программного обеспечения — систему (или комплекс систем) управления данными, учитывающую их семантику, особенности организации и обеспечивающую высокоуровневый интерфейс обмена с прикладными системами.
Под технологией управления данными будем понимать комплекс методов, понятий (объектов), информационных моделей, правил использования, интерфейсов доступа к данным, необходимых и достаточных для работы с данным классом данных при решении различных задач в ходе ЖЦ изделия.
Модели данных (или их части) могут быть представлены с использованием различных технологий (ИСО 10303-11 Ехрress, ИСО 8879 SGML). Они должны быть логически связаны. При преобразовании данных из одной формы в другую объекты информационных моделей должны интерпретироваться однозначно. Один из вариантов такой технологии изложен в стандарте ИСО 18876.
Приведение совместно используемых в ходе ЖЦ данных к единой стандартизованной информационной модели существенно упрощает построение интегрированной информационной системы, поскольку позволяет применять коммерческие прикладные решения для различных задач. Развитие информационных технологий нашло яркое воплощение в идеологии CALS.
Предпосылки создания CALS
В течение многих десятков лет общепринятой формой представления результатов интеллектуальной деятельности людей и инструментом их информационного взаимодействия являлась бумажная документация. Ее созданием были заняты(и заняты по сей день) миллионы инженеров, техников, служащих промышленных предприятий, государственных учреждений. С появлением компьютеров начали создаваться и широко внедрялись для изготовления чертежей, спецификаций, технологической документации разнообразные средства и системы автоматизированного проектирования (САПР); системы автоматизированного управления производством (АСУП), назначенные для создания планов производства и отчетов о его ходе; офисные системы, служащие для подготовки текстовых и табличных документов.
К концу XX века стало ясно, что эти достаточно дорогостоящие средства не оправдывают возлагающихся на них надежд: разумеется, некоторое повышение производительности труда происходит, однако не в тех масштабах, которые прогнозировались. Дело в том, что они не решают проблем информационного обмена между различными участниками жизненного цикла изделия (заказчиками, разработчиками, производителями, эксплуатационниками). При переносе данных из одной автоматизированной системы в другую требуются большие затраты труда и времени для повторной кодировки; перекодировка заодно приводит к многочисленным ошибкам. Оказалось, что разные системы «говорят на разных языках» и плохо понимают друг друга. Более того, выяснилось, что бумажная документация и способы представления информации на ней ограничивают возможности использования современных ИТ. Так, трехмерная модель изделия, создаваемая в современной САПР, вообще не может быть адекватно представлена на бумаге.
С другой стороны, по мере усложнения изделий происходит резкий рост объемов технической документации. Сегодня они измеряются тысячами и десятками тысяч листов, а по некоторым изделиям (например, кораблям) — тоннами. При использовании бумажной документации трудно отыскать необходимые сведения, внести изменения в конструкцию и технологии изготовления изделий. Возникает множество ошибок, на устранение которых затрачивается время. В результате резко снижается эффективность процессов разработки, производства, эксплуатации, обслуживания, ремонта сложных наукоемких изделий. Возникают трудности во взаимодействии заказчиков и производителей при подготовке и реализации контрактов, особенно при поставках сложной техники.
Для преодоления этих трудностей потребовались новые концепции и новые идеи. Базовой стала идея информационной интеграции стадий жизненного цикла продукции (изделия), которая и легла в основу CALS. Она состоит в отказе от «бумажной среды», в которой осуществляется традиционный документооборот, и переходе к интегрированной информационной среде, охватывающей все стадии жизненного цикла изделия. Информационная интеграция заключается в том, что все автоматизированные системы, применяемые на различных стадиях жизненного цикла, оперируют не с традиционными документами и даже не с их электронными отображениями (например, отсканированными чертежами), а с формализованными информационными моделями, описывающими изделие, технологии его производства и использования.
Эти модели существуют в интегрированной информационной среде как информационные объекты. Системы по мере необходимости могут извлекать их из интегрированной информационной среды, обрабатывать, создавать новые объекты и помещать результаты своей работы в ту же интегрированную информационную среду. Чтобы все это было возможно, информационные модели и информационные объекты должны быть стандартизованы.
Интегрированная информационная среда представляет совокупность распределенных баз данных, в которой действуют единые стандартные правила хранения, обновления, поиска и передачи информации, через которую осуществляется безбумажное информационное взаимодействие между всеми участниками жизненного цикла изделия. Однажды созданная информация хранится в интегрированной информационной среде, не дублируется, не требует перекодировок в процессе обмена, сохраняет целостность.
Очевидно, что такой подход представляет своего рода революцию в организации взаимодействия всех участников жизненного цикла сложных наукоемких изделий. Революционность подхода состоит в том, что многие поколения конструкторов, технологов, производственников воспитаны на основе совершенно другой культуры, базирующейся на сотнях стандартов ЕСКД, ЕСТД, СРПП, детально регламентирующих ведение дел с использованием бумажной документации. В условиях применения CALS эта культура должна претерпеть коренные изменения, поскольку:
появляются принципиально новые средства инженерного труда;
полностью изменяется организация и технология инженерных работ;
должна быть существенно изменена, то есть дополнена и частично переработана, нормативная база; тысячи специалистов должны быть переучены для работы с новыми средствами труда.
Для подготовки и осуществления этой революции, сулящей многократное повышение эффективности процессов жизненного цикла изделий, необходимо создать новую культуру инженерной деятельности. Первоочередной проблемой является формирование нормативно-правовой базы, узаконивающей новые способы и средства информационного обмена, заменяющего традиционный бумажный документооборот. Такую базу образуют стандарты и инструктивно-методические материалы, регламентирующие упомянутые способы и средства, форматы данных, их логическую структуру, процедуры информационного обмена, способы обеспечения легитимности данных. Это необходимо для того, чтобы электронные документы и данные имели ту же юридическую силу, что и обычные бумажные документы. Кроме того, одна из важнейших задач стандартизации в рассматриваемой сфере — обеспечение информационной совместимости различных автоматизированных систем.
К настоящему времени СALS-технологии образуют самостоятельное направление в области ИТ. За рубежом создана нормативно-правовая база этого направления, которую составляют серии международных стандартов ISO, государственные стандарты и нормативные документы военного министерства США, НАТО, Великобритании и ряда других стран. Общее число этих стандартов — многие десятки и даже сотни, причем объемы документов подчас исчисляются тысячами страниц. На их разработку правительства и ведущие корпорации Запада израсходовали суммы, превышающие 1 млрд долл., и эта работа продолжается. Так, в ближайшем будущем конгресс США планирует выделить только на цели стандартизации СALS 47 млн долл.
CALS родилась в Департаменте обороны США в середине 80-х годов прошлого века. Тогда эта аббревиатура расшифровывалась как «Компьютерная Поддержка Логистических Систем (Computer-Aidеd of Logistics Support)».
В то время компьютерные системы, закупленные военными ведомствами с целью усовершенствования процессов создания и технического обслуживания военной техники, не могли обмениваться информацией между собой и с аналогичными системами, использовавшимися в промышленности. Это приводило к изоляции вычислительных систем, ставших похожими на островки автоматизированной обработки данных. В 1985 году Департамент обороны США приступил к разработке CALS для решения вставших перед ним проблем. Вначале CALS была связана только с масштабными проектами американского военно-промышленного комплекса, позднее, в целях повышения производительности труда, принципы CALS стали применяться и в гражданской промышленности. Была произведена «демилитаризация» CALS, которая позволила американским организациям и предприятиям внедрять ее принципы. Благодаря быстрому росту интереса со стороны бизнесменов многих стран, стало происходить географическое расширение CALS. Трактовка аббревиатуры CALS несколько раз менялась.
В 1988 году в смысловом содержании CALS были сняты военные ограничения, и она стала называться «Компьютеризированные Поставки и Поддержка (Computer-Aided Acquisition and Support)». В этом варианте была усилена организационная направленность CALS. В 1993 году технология стала называться «Поддержка Непрерывных Поставок и Жизненного Цикла (Computer-Aided Acquisition and Lifecyclе Support)». В новом названии учитывалась методология параллельного проектирования, интегрированной логистической поддержки, управления конфигурацией и управления документопотоком. Это позволило интегрировать процессы на всем протяжении жизненного цикла изделий — от выражения потребности в изделии до его утилизации. Позднее, в 1995 году, под влиянием американского военно-промышленного комплекса CALS иногда стали называть «Бизнесом в Высоком Темпе (Commerce At Light Speed)», подчеркивая переориентацию этих технологий в направлении информационных магистралей и электронной коммерции.
Областями применения CALS принято считать:
совершенствование деятельности в области разнородных процессов, происходящих на всех этапах жизненного цикла продукции;
управление цепными поставками в течение всего жизненного цикла продукции (от создания концепции изделия до его утилизации);
электронную интеграцию организаций, участвующих в этих процессах на различных этапах жизненного цикла продукции;
управление поддержкой жизненного цикла продукции.
Философия проектирования как философия части жизненного цикла продукции родилась в 1987 году, когда Newport News получил от ВМФ заказ на разработку проекта подводной лодки «морской волк» . Это было первое изделие, где появилась широкомасштабная возможность заставить работать идеи CALS и использовать усовершенствованный опыт и новую технологию для производства миллионов отдельных узлов лодки с соблюдением одинаково высоких требований как по качеству, так и по совместимости друг с другом.
К 1989 году, по мнению авторов CALS, вся техническая документация должна была представляться в электронном виде. К 1991 году вся конструкторско-технологическая документация должна была быть представлена в электронном виде. На первом этапе были определены «независимые стандарты», а также определен механизм обмена информацией с помощью магнитного носителя. На втором этапе в рамках всемирного консорциума 25 ведущих технических организаций достигли соглашения об использовании нового стандарта описания данных, а также осуществлен доступ Министерства обороны США к базам данных его поставщиков. На самом деле лишь в 1995 году был заключен меморандум по общему пониманию и кооперации в использовании нового стандарта STEP (ISO 10303).
CALS-ориентированный подход внедряется заказчиками и поставщиками во многих отраслях промышленности: от автомобилестроения до предприятий ВПК; от здравоохранения до производственной сферы. Каждое из предприятий адаптирует принципы CALS-технологий. Отрасли находятся на различных стадиях внедрения CALS: от полной деинтеграции информации до разработки и широкой реализации CALS-технологий.
Технологии, стандарты и программно-технические средства CALS обеспечивают эффективный и экономичный обмен электронными данными и безбумажными электронными документами, предоставляя возможности:
параллельного выполнения сложных проектов несколькими рабочими группами (параллельный инжиниринг), что существенно сокращает время разработок;
планирования и управления многими предприятиями, участвующими в жизненном цикле продукции, расширения и совершенствования кооперационных связей (электронный бизнес);
резкого сокращения количества ошибок и переделок, что приводит к уменьшению сроков реализации проектов и существенному повышению качества продукции;
распространения средств и технологий информационной поддержки на послепродажные стадии жизненного цикла.
На экономические показатели предприятий, применяющих CALS-технологии, непосредственно влияют:
сокращение затрат и трудоемкости процессов технической подготовки и освоения производства новых изделий;
сокращение сроков вывода на рынок новых конкурентоспособных изделий;
сокращение брака и затрат, связанных с внесением изменений в конструкцию;
увеличение объемов продаж изделий, снабженных электронной технической документацией (в частности, эксплуатационной), составленной в соответствии с требованиями международных стандартов;
сокращение затрат на эксплуатацию, обслуживание и ремонт изделий («затрат на владение»), которые для сложной наукоемкой продукции подчас не меньше затрат на закупку.
В публикациях можно отыскать некоторые количественные оценки эффективности внедрения CALS в промышленности США:
прямое сокращение затрат на проектирование — от 10 до 30%;
сокращение времени разработки изделий — от 40 до 60%;
сокращение времени вывода новых изделий на рынок — от 25 до 75%;
сокращение доли брака и объема конструктивных изменений — от 20 до 70%.
сокращение затрат на подготовку технической документации — до 40%;
сокращение затрат на разработку эксплуатационной документации — до 30%.
По зарубежным данным, потери, связанные с несовершенством информационного взаимодействия с поставщиками, только в автомобильной промышленности США составляют порядка 1 млрд долл. в год. Аналогичные потери имеют место и в других отраслях промышленности.
В тех же источниках указывается, что затраты на разработку реактивного двигателя GE 90 для самолета «Боинг-777» составили 2 млрд долл., а разработка новой модели автомобиля компании «Форд» стоит от 3 до 6 млрд долл. Это означает, что экономия от снижения прямых затрат на проектирование только по двум указанным объектам может составить от 500 млн до 2,2 млрд долл.
Как видим, внедрение CALS-технологий приводит к существенной экономии и получению дополнительной прибыли. Поэтому эти технологии и их отдельные компоненты широко применяются в промышленности развитых стран. Так, из числа 500 крупнейших мировых компаний, входящих в перечень «Fortune 500», почти 100% используют такой важнейший компонент CALS, как средства PDM (Product Data Management — «управление данными об изделии»). Среди предприятий с годовым оборотом свыше 50 млн долл. такие системы используют более 80%.
В связи с большими объемами ожидаемой экономии и дополнительных прибылей в эту сферу привлекаются значительные инвестиции, измеряемые миллиардами долларов. По данным зарубежных источников, инвестиции правительства США в сферу CALS-технологий составляют около 1 млрд долл. в год. Затраты других стран меньше, однако, например, правительство Финляндии затратило на национальную программу в этой области свыше 20 млн долл., и примерно такую же сумму (около 25 млн долл.) вложили частные компании. Корпорация General Motors в течение 1990—1995 годов израсходовала на эти цели 3 млрд долл. Средние затраты на один проект, посвященный решению локальной задачи в области CALS-технологий (например, разработка стандарта или программы), составляют 1,2—1,5 млн долл. при среднем сроке выполнения от двух до четырех лет.
Проблемы освоения CALS в России
Россия существенно отстает от промышленно развитых стран в части внедрения современных ИТ, в том числе технологий CALS. Это отставание чревато далеко идущими негативными последствиями, прежде всего высокой вероятностью резкого сокращения экспортного потенциала российских производителей наукоемкой продукции, вплоть до полного вытеснения их с международного рынка, что может, по мнению зарубежных экспертов, произойти к 2005—2008 годам.
Мировой рынок полностью отторгнет продукцию, не снабженную электронной документацией и не обладающую средствами интегрированной логистической поддержки послепроизводственных стадий жизненного цикла. Уже сегодня многие иностранные заказчики отечественной продукции выдвигают требования, удовлетворение которых невозможно без внедрения CALS-технологий:
представление конструкторской и технологической документации в электронной форме;
представление эксплуатационной и ремонтной документации в форме интерактивных электронных технических руководств, снабженных иллюстрированными электронными каталогами запасных частей и вспомогательных материалов, средствами дистанционного заказа запчастей и материалов;
организация интегрированной логистической поддержки изделий на послепроизводственных стадиях их жизненного цикла;
наличие и функционирование электронной системы каталогизации продукции;
наличие на предприятиях систем менеджмента качества, соответствующих требованиям стандартов ИСО 9000:2000.
Выполнение этих требований предопределяет необходимость внедрения на отечественных предприятиях CALS-технологий в полном объеме.
В период с 1999 по 2002 год Минпромнауки РФ совместно с Госстандартом РФ и Минобразования РФ осуществили ряд мер, направленных на создание предпосылок к внедрению CALS-технологий в промышленности России.
Были созданы начальные элементы инфраструктуры, необходимой для разработки и внедрения CALS-технологий: Государственный научно-образовательный центр CALS-технологий, Научно-исследовательский центр (НИЦ) CALS-технологий «Прикладная логистика» и технический комитет ТК 431 Госстандарта России, координирующий разработку отечественной нормативной базы.
Подготовлены научно-методические разработки: концепция развития CALS-технологий в промышленности России, концепция интегрированной логистической поддержки наукоемких изделий и концепция внедрения CALS-технологий на машиностроительном предприятии.
Созданы программные средства, реализующие CALS-технологии. В их числе — программный продукт Technical Guide Builder, предназначенный для автоматизированной подготовки электронной технической эксплуатационной документации на экспортируемую продукцию, соответствующей требованиям CALS-стандартов. Создание с помощью этого продукта интерактивных электронных технических руководств значительно повышает конкурентоспособность продукции. Другой продукт — PDM STEP Suite — служит для управления данными об изделии в процессе конструирования и технологической подготовки производства, что необходимо предприятиям, разрабатывающим наукоемкую продукцию и продающим лицензии на ее производство.
Разработаны методические основы создания интегрированной системы управления качеством продукции, соответствующей требованиям стандартов ИСО серии 9000 версии 2000 года.
Работы по внедрению CALS-технологий в промышленность России продолжаются, но требуют адекватной финансовой поддержки государства, контроля и содействия в реализации усилий предприятий со стороны Минпромнауки РФ, Госстандарта РФ и других министерств и ведомств России.
Успешное решение проблем освоения CALS непосредственно связано с такими задачами, как обеспечение национальной безопасности и конкурентных позиций России на мировых рынках.
1. Левин А.И., Давыдов А.Н., Барабанов В.В. Концепция развития CALS-технологий в промышленности России. — М.: НИЦ CALS-технологий «Прикладная логистика», 2002.
2. Р50-1-031-2001. Информационные технологии поддержки жизненного цикла продукции: Терминологический словарь. Часть 1. Стадии жизненного цикла продукции. Госстандарт РФ. — М., 2001.
3. Р50-1-028-2001. Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования. Госстандарт РФ. — М., 2001.
4. Концепция развития ИПИ-технологий в промышленности России. — М., ВИМИ. 2002.
Источник