А. С. Шалумов, С. И. Никишкин, В. Н. Носков

А.С. ШАЛУМОВ, С.И. НИКИШКИН, В.Н. НОСКОВ

 

 

ВВЕДЕНИЕ В CALS-ТЕХНОЛОГИИ

 

Учебное пособие

 

 

Ковров 2002

 

 

УДК 621.396.6.671.7

Ш-18

 

Шалумов А.С., Никишкин С.И., Носков В.Н. Введение в CALS-технологии: Учебное пособие. Ковров: КГТА, 2002. - 137 с.

 

 

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

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

Пособие предназначено для студентов специальности 2203 «Системы автоматизированного проектирования» при изучении дисциплин «Модели и методы анализа проектных решений», «Комплексное моделирование физических процессов», «Разработка САПР», при выполнении курсовых, дипломных проектов и для аспирантов.

 

Рис. 58., библиогр. 18 назв.

 

Печатается по решению …

 

 

Рецензенты: д-р техн. наук, профессор, Лауреат государственной премии СССР, директор КБ ИГАС «Волна» Малютин Н.В.; д-р техн. наук, профессор, Лауреат премии Правительства РФ Кофанов Ю.Н. (Московский государственный институт электроники и математики); д-р техн. наук, профессор Житников Ю.З. (Ковровская государственная технологическая академия)

 

 

Ó Ковровская государственная

ISBN 5-86151-024-5 технологическая академия,

 

 

 

СОДЕРЖАНИЕ

ВВЕДЕНИЕ………………………………………………………………………….. 1. ИСТОРИЯ РАЗВИТИЯ CALS – ТЕХНОЛОГИЙ..……………………….. 2. КОНЦЕПЦИЯ CALS ………………………………………………………………. 2.1. Основные определения……………………………………………….………….. 2.2. Задачи, решаемые при помощи CALS-технологий ……………………………. 2.3. Что дают CALS-технологии.…………………………………………………….. 3. СТАНДАРТЫ CALS ………………………………………………………………. 3.1. Объекты стандартизации …………………………………………….………….. 3.2. Стандарты и методы семейства IDEF ……………………………….…………. 3.3. Стандарт ISO 10303 (STEP)………………….……………………….………….. 3.4. Стандарт ISO 13584 (PLIB) ……………………………………..………………. 3.5. Стандарт ISO 15531(MANDATE)……………………………………………….. 3.6. Стандарт ISO 8879 (SGML)…………………………..………………………….. 4. ЭЛЕКТРОННАЯ МОДЕЛЬ ИЗДЕЛИЯ…………………………..….……………. 4.1. Требования к электронной модели изделия и средствам ее поддержки..……. 4.2. Способы реализации средств поддержки электронной модели изделия……………………………………………………………………………………… 4.3. Пример системы управления данными об изделии: PDM-STEP Suite……….. 5. ИНТЕРАКТИВНЫЕ ЭЛЕКТРОННЫЕ ТЕХНИЧЕСКИЕ РУКОВОДСТВА……………….. ………………………………………………….. 5.1. Интерактивные электронные технические руководства – компонент электронной модели изделия……………………………………………….……………... 5.2. Язык разметки SGML…………………………………………………………… 5.3.Технология подготовки ИЭТР………………………………………….………... 6. ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ В CALS-СИСТЕМАХ……………... 6.1. <!--mstheme-->Основные понятия и определения…………………………………….………… 6.2. <!--mstheme-->Технологии построения защищенной сети виртуального предприятия………………………………………………….………………………………….. 6.3. <!--mstheme-->Нормативно-правовое обеспечение информационной безопасности………… 7. ВОПРОСЫ ВНЕДРЕНИЯ CALS-ТЕХНОЛОГИЙ……………………………….. 7.1. Основные принципы внедрения CALS……………………………….………… 7.2. Детально проработанный подход к внедрению CALS………………………... 7.3. Реформирование процессов……………………………………………………… 7.4. Кадровые и организационные изменения…………………………….………… 7.5. Совершенствование информационной инфраструктуры……………………… 7.6. Предпосылки внедрения CALS …………………………………………………. 8. ПРИМЕНЕНИЕ CALS ТЕХНОЛОГИЙ в различных областях…………………. 8.1. Применение CALS-ТЕХНОЛОГИЙ области электроники……….…………… 8.2. Применение CALS-ТЕХНОЛОГИЙ области стандартизации ……………….. ЗАКЛЮЧЕНИЕ………………………………………………………………………... СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ…………………………………. ПРИЛОЖЕНИЕ 1. ПЕРЕЧЕНЬ СТАНДАРТОВ CALS…………………………….. ПРИЛОЖЕНИЕ 2. МЕТОДИКА РЕИНЖИНИРИНГА БИЗНЕС-ПРОЦЕССОВ… ПРИЛОЖЕНИЕ 3. ТЕРМИНОЛОГИЯ, ОТНОСЯЩАЯСЯ К СТАДИЯМ ЖИЗНЕННОГО ЦИКЛА ПРОДУКЦИИ……………………………….

 

ВВЕДЕНИЕ

Современные условия характеризуются все более жесткой конкуренцией на междуна­родном рынке, повышением сложности и наукоемкости продукции, что ставит перед промыш­ленниками и предпринимателями страны новые проблемы. К их числу относятся:

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

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

- повышение качества процессов проектирования и производства;

- обеспечение гибкого и надежного эксплуатационного обслуживания.

Действенным средством решения этих проблем в последнее десятилетие выступают новые информационные CALS-технологии сквозной поддержки сложной наукоемкой продукции на всех этапах ее жизненного цикла (ЖЦ) от маркетинга до утилизации. Базирующиеся на стандартизованном едином электронном представлении данных и коллективном доступе к ним, эти технологии позволяют существенно упростить выполнение этапов ЖЦ продукта и повысить производительность труда, согласно западному опыту, примерно на 30%, автоматически обеспечить заданное качество продукции.

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

Впервые элементы CALS-технологий начали применяться в середине 80-х годов при взаимодействии Министерства обороны США со своими поставщиками, когда была поставлена задача перевести все операции с ними в электронный вид. Впоследствии сфера применения CALS-технологий расширилась до всего жизненного цикла изделия и вышла за пределы военных ведомств. Несмотря на это, наиболее передовыми пользователями CALS-технологии все же являются военные разработчики. Например, с помощью CALS-технологий были созданы истребитель F-22 (США), подводная лодка Viking (Дания, Норвегия и Швеция), самоходная гаубица Crusader (США). Во всех этих проектах делалась попытка организовать полномасштабное единое информационное пространство для всех участников жизненного цикла изделия. В области гражданского внедрения CALS-технологий в мире и в России лидируют аэрокосмическая и атомная промышленности, автомобиле- и судостроение.

В России подобные работы начались в середине 90-х годов, на рубеже столетий при Госстандарте был создан комитет № 431, координирующий работы по CALS-технологиям; создан НИЦ CALS-технологий «Прикладная логистика»; разработана программа стандартизации в сфере CALS-технологий в 2000 - 2003 годах; в авиастроении, судостроении, оборонной промышленности реализуются пилотные проекты по внедрению CALS-технологий. В нашей стране среди пионеров внедрения CALS — АВПК «Сухой», ОАО «Туполев», Конструкторское бюро приборостроения (Тула), Воронежский механический завод. Эти проекты поддерживаются Минпромнауки РФ, Минатомом РФ. Тем не менее, для нормального внедрения CALS в России необходимы переподготовка специалистов предприятий, подготовка специалистов в вузах и т. п.

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

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

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

 

КОНЦЕПЦИЯ CALS

2.1. Основные определения

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

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

CALS (Сontinuous Acquisition and Life Cycle Support) - непрерывная информационная поддержка жизненного цикла изделия или продукта. Это стратегия повышения эффективности, производительности и рентабельности процессов хозяйственной деятельности предприятий за счет внедрения современных методов информационного взаимодействия участников ЖЦ продукта.

Жизненный цикл продукта, как его определяет стандарт ISO 9004-1, — это совокупность процессов, выполняемых от момента выявления потребностей общества в определенной продукции до момента удовлетворения этих потребностей и утилизации продукта. Основные стадии жизненного цикла показаны далее на рисунках.

Процесс -это структурированный набор функций, охватывающий различные сущности и завершающийся глобальной целью (определение по ISO/CD 15531-1). По определению, приведенному в стандарте ISO 8402:1994, процесс - это совокупность взаимосвязанных ресурсов и деятельности, которая преобразует входящие элементы в выходящие. Ресурсами являются персонал, средства обслуживания, оборудование, технология, методология.

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

Для общей характеристики этих процессов используется понятие «бизнес-процесс».

Что дают CALS-технологии

 

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

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

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

- повысить «прозрачность» и управляемость бизнес-процессов путем их реинжиниринга, на основе интегрированных моделей ЖЦ и выполняемых бизнес-процессов, сократить затраты в бизнес-процессах за счет лучшей сбалансированности звеньев;

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

- обеспечить заданное качество продукции в интегрированной системе поддержки ЖЦ путем электронного документирования всех процессов и процедур.

- сократить издержки производства и снизить стоимость продукции;

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

 

 

Стандарты CALS

Объекты стандартизации

Фундаментом CALS-технологии является система единых международных стандартов.

CALS-стандарты можно подразделить на три группы:

- функциональные стандарты, определяющие процессы и методы формализации;

- информационные стандарты по описанию дан­ных о продуктах, процессах и средах;

- стандарты технического обмена, контролиру­ющие носители информации и процессы обмена данными между передающими и принимающими системами.

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

 

 

Таблица 2

Информационные модели	Стандарт представления информации	Содержание стандарта
Модель ЖЦ продукта и выполняемых в его ходе бизнес-процессов	IDEF – Integrated Definition,	Функциональное моделирование жизненного цикла и выполняемых бизнес-процессов
ISO 10303 AP208
Модель продукта	Конструкторская	ISO 10303 (STEP)	Структура, конфигурация и геометрия изделия
Производственная	ISO-13584 (PLIB)	Формат данных о библиотеках деталей у поставщиков
MIL-STD- 1388-1/2 Logistic Support Analysis (LSA) Record	Формат данных в процессах материально-технического снабжения
Эксплуатационная	MIL-M-87268– Manuals, Interactive Electronic Technical General Content, Style, Format, and User-Interaction Requirements (IETM)	Требования к электронным руководствам: содержание, стиль, формат, Интерфейс с пользователем
MIL-D-87269–Data Base, Revisable Interactive Electronic Technical Manuals, for the support of	Требования к оформлению баз данных и электронных справочников по изделиям
ISO 8879 (SGML) – Standard Generilized MarkUp Language	Способ представления информации в тексто-графических документах
MIL-PRF-28001C- Markup Requirements and Generic Style Specification for Electronic Printed Output and Exchange of Text	Требования к оформлению электронных документов (рекомендации по применению SGML для оформления электронных документов)
MIL-PRF-28002C –Requirements for Raster Graphics Representations in Binary Format	Требования к представлению растровых изображений в двоичном формате в электронной документации
MIL-PRF-28003 – Color Graphics Metafile (CGM)	Требования к представлению иллюстраций для технической документации в электронном виде
ISO 10744 HyTime - (Hypermedia/Time Based Structuring Language	Требования к мультимедийной информации в электронных документах
Модель среды	ISO 15531 (MANDATE)	Форма представления и методы использования информации о производстве и используемых производственных ресурсах, их характеристиках и ограничениях с точки зрения управления производством.

Метод IDEF0

Графический язык IDEF0 прост и гармоничен. В основе метода лежат 4 основных понятия.

Первым из них является понятие функционального блока (Activity Box). Функциональный блок изображается в виде прямоугольника (см. рис.4) и олицетворяет некоторую конкретную функцию в рамках рассматриваемой системы, которая выражается глагольной формой. Например: «Обработать заготовку», а не «Обработка заготовки».

 

 

Рис. 4. Функциональный блок <!--mstheme--><!--msthemelist-->

 

Каждая из сторон блока имеет определенное значение (роль):

- верхняя сторона имеет значение «Управление» (Control);

- левая сторона имеет значение «Вход» (Input);

- правая сторона имеет значение «Выход» (Output);

- нижняя сторона имеет значение «Механизм» (Mechanism).

Каждый блок должен иметь уникальный идентификационный номер.

Вторым понятием метода является понятие интерфейсной дуги (Arrow). Графическим отображением интерфейсной дуги является однонаправленная стрелка (поэтому дуги часто называют стрелками, потоками). Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label), которое должно быть оборотом существительного. С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Это могут быть элементы реального мира (люди, изделия, детали и др.), потоки данных и информации (документы, инструкции и др.). «Источником» (началом) и «приемником» (концом) каждой функциональной дуги могут быть только блоки, причем «источником» может быть только выходная сторона блока, а «приемником» – любые из трех оставшихся. Функциональный блок должен обязательно иметь управляющую и исходящую интерфейсную дугу, поскольку каждый процесс должен происходить по каким –то правилам и давать некоторый результат (иначе его рассмотрение не имеет смысла).

При построении IDEF-диаграмм важно отделять входящие дуги от управляющих. Например, в реальном процессе рабочий получает заготовку и технологические указания по ее обработке. Ошибочно может показаться, что и заготовка, и указания – входящие объекты. На самом деле технологические указания (нормативы, правила техники безопасности) должны изображаться управляющей дугой, поскольку они регламентируют процесс. Другое дело, когда технологические указания редактируются технологом. Тогда они изображаются входящей дугой, а управляющей дугой могут быть новые стандарты.

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

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

Процесс моделирования начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами. Эта диаграмма называется контекстной и обозначается идентификатором «А0». В пояснительном тексте к контекстной диаграмме в краткой форме должна быть указана цель (Purpose) и зафиксирована точка зрения (Viewpoint). Цель определяет области в анализируемой системе, на которых необходимо фокусироваться в первую очередь. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Она позволяет отказаться от несущественных свойств в данном аспекте рассмотрения. Например, функциональные модели предприятия с точки зрения главного технолога и финансового директора будут различаться, поскольку финансового директора интересуют финансовые потоки, а главного технолога – аспекты переработки сырья.

В процессе декомпозиции функциональный блок в контекстной диаграмме подвергается детализации на другой диаграмме – дочерней. На ней фиксируются все функциональные дуги родительской диаграммы, за счет этого достигается структурная целостность модели. Связана также нумерация блоков и диаграмм: каждый блок имеет свой уникальный номер - цифра в правом нижнем углу, а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы (см. рис. 5, 6).

Следует отметить, что рис.6 выполнен с использованием специализированного программного средства – CASE-средства Design/IDEF для построения диаграмм в соответствии с методами IDEF0 и IDEF1X. Design/IDEF автоматически контролирует основные правила построения диаграмм, автоматически выполняет оцифровку блоков, переносит интерфейсные дуги с родительской диаграммы, вписывает в соответствующие поля необходимую информацию (например, в нижней части диаграммы указано имя родительской функции и номер родительской диаграммы).

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

 

 

 

Рис. 5. Декомпозиция диаграмм при функциональном моделировании

 

 

Рис.6. Функциональная диаграмма создания и модификации проекта изделия (второй уровень)

Четвертым из основных понятий метода является глоссарий (Glossary). Для каждого из элементов IDEF0 (диаграмм, функциональных блоков, интерфейсных дуг) создаются и поддерживаются определения, ключевые слова, повествовательные изложения, которые характеризуют объект. Глоссарий снабжает диаграммы дополнительной информацией.

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

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

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

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

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

- сбор информации о предприятии;

- идентификация бизнес-процессов предприятия и создание функциональной модели бизнес-процессов предприятия;

- анализ и возможный реинжиниринг бизнес-процессов предприятия.

Для анализа распределения затрат применяется метод ABC, базирующийся на IDEF0. Метод ABC основывается на том, что выполнение каждой функции в процессе функционирования предприятия обладает определенной стоимостью, то есть вносит свой вклад в появление издержек. АВС аналогично понятию ФСА - функционально-стоимостного анализа. При помощи метода АВС рассчитываются затраты на выполнение всего процесса или отдельной функции, стоимость продукции на выходе процесса, выявляются источники основных затрат. Затраты на выполнение декомпозируемой функции определяются как сумма затрат на выполнение всех составных элементов в этой функции.

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

Для построения функциональной модели предлагается выбрать CASE-пакет Design/IDEF, так как помимо возможностей создания функциональной модели этот пакет содержит встроенный механизм АВС подсчета затрат на выполнение функций, позволяющий анализировать бизнес-процессы и их составляющие. Каждый вид ресурса, потребляемый (обрабатываемый) функцией, а также механизмы, выполняющие функцию, добавляют стоимость к этой функции, при этом учитываются элементы затрат, игнорируемые при обычном представлении предприятия как совокупности организационных структур. Следовательно, каждой функции h модели IDEF0 можно поставить в соответствие значение затрат на выполнение этой функции Ex(h). Математический аппарат АВС для решения конкретной задачи изложен в Приложении 2.

 

 

Рис. 7. Общая схема методики анализа и реинжиниринга бизнес-процессов предприятия

 

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

<span style="mso-spacerun: yes"><span style="mso-spacerun: yes"><span style="mso-spacerun: yes">

3.2.3. <!--mstheme-->Метод моделирования данных IDEF1X<!--mstheme-->

Стандарт FIPS 184 на основе этого метода, выпущенный в 1993 году, не входит в перечень CALS-стандартов. Однако разработанные на его основе структуры реляционных баз данных напрямую могут быть использованы для создания информационных систем с использованием языка EXPRESS стандарта ISO 10303 (STEP)<!--msthemeseparator-->, который составляет основу CALS-технологий. Аналогия положений IDEF1X и требований языка EXPRESS станет очевидной при рассмотрении EXPRESS.

<!--mstheme-->IDEF1X - это метод для разработки реляционных баз данных. Он использует условный синтаксис для описания семантических конструкций, необходимых для построения концептуальной схемы. Концептуальная схема - это единое интегрированное определение данных предметной области, не ориентированное на какое-либо конкретное приложение и независимое от способов доступа и способов физического хранения данных.

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

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

Предполагается, что окончательный логический проект моделей IDEF1X будет использоваться программистами, которые берут схему логического проекта базы данных и реализуют этот проект (например, с использованием языка EXPRESS).

<!--mstheme-->Концепция IDEF1X несколько отличается от <!--mstheme--> IDEF1, хотя их терминология схожа. Сущность в IDEF1X ссылается на коллекцию или набор аналогичных экземпляров данных, которые могут отличаться друг от друга. Отдельные члены набора называются экземплярами сущности. Таким образом, блок в IDEF1X представляет набор экземпляров реального мира. Атрибут - это значение, ассоциированное с каждым конкретным экземпляром набора. Отношению, существующему между отдельными экземплярами этих наборов, даётся имя, которое выражено глагольной формой.

Сильной особенностью IDEF1X является его поддержка моделирования логических типов данных через использование структуры классификации. Эта конструкция является попыткой отразить модель реального мира, данные о которых представляются либо блоками, либо сущностями, попыткой промоделировать типы данных вещей. Эти отношения категоризации представляют взаимно исключающиеподмножества родовой сущности или множества. Подмножества общего надмножества не могут иметь общих экземпляров. Например, родовая сущность ОСОБА имеет два подмножества, представляющих полный набор категорий, а именно, МУЖЧИНА и ЖЕНЩИНА. Ни один экземпляр подмножества МУЖЧИНА не может быть экземпляром подмножества ЖЕНЩИНА, и наоборот. Уникальный идентификатор атрибута для каждого подмножества - это тот же атрибут, что и для экземпляра родовой сущности.

<!--mstheme-->Сущности<!--mstheme--> в IDEF1X сущности являются либо идентификационно независимыми, либо идентификационно зависимыми. Экземпляры идентификационно независимых сущностей могут существовать независимо от другого экземпляра сущности, в то время как экземпляры идентификационно зависимых сущностей являются бессмысленными (по определению) без другого ассоциированного экземпляра сущности. Зависимость и независимость являются спецификой модели.

<!--mstheme-->Отношения связности<!--mstheme--> (сплошные или пунктирные линии с кружками с одной или двух сторон) показывают, как сущности (множества экземпляров данных) относятся друг с другом. Отношения связности существуют всегда только между двумя сущностями. Отношение связности, начинающееся с независимой родовой сущности и заканчивающееся на зависимой порождённой сущности, помечается глагольной фразой, описывающей отношение. Каждое отношение связности имеет соответствующую мощность. Мощность определяет число экземпляров зависимой сущности, связанных с экземпляром независимой сущности.

<!--mstheme-->Отношения категоризации<!--mstheme--> позволяют проектировщику определить категорию общей сущности. Сущность может принадлежать только одной категории. Например, может существовать общая сущность МАШИНА, являющаяся родовой сущностью для категории, представляющей различные марки машин (ВОЛГА, ОКА, НИВА). Каждая сущность-категория должна иметь одинаковый первичный ключ с общей сущностью. Кроме того, обязаны существовать различия между сущностями-категориями. Сущности-категории различаются атрибутом – дискриминатором (описателем), который обязан иметь различные значения для каждой сущности-категории. В рассмотренном примере дискриминатор - МАРКА МАШИНЫ.

<!--mstheme-->Атрибуты<!--mstheme--> - это свойства, используемые для описания сущностей. Имена атрибутов являются уникальными для всей модели IDEF1X, значения имён должны быть согласованными. Например, атрибут «цвет» можно использовать для цвета волос, цвета кожи, цвета радуги. Каждое такое использование имеет допустимый диапазон значений, и, следовательно, сущность необходимо раздельно именовать. Каждый атрибут принадлежит только одной сущности. Например, атрибут «страховой номер» может использоваться в модели во многих местах, но должен принадлежать только одной сущности (например, ПЕРСОНА). Все другие появления атрибутов страхового номера будут наследоваться через отношения.

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