Черепашков А.А., Носов Н.В. Компьютерные технологии, моделирование и автоматизированные системы в машиностроении

Подождите немного. Документ загружается.

Раздел 6. Создание, внедрение и интеграция систем и технологий

без передачи промежуточной части процесса другим исполните-

лям. При этом необходимо выявить служебные обязанности ис-

полнителя, участие в различных процессах и его роль по отноше-

нию ко всем основным техническим документам.

3. Целеориентированный способ представляет собой описа-

ние алгоритма (последовательности действий), необходимого

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

пользуется при интервьюировании руководителей (владельцев)

бизнес-процессов. При отсутствии владельцев процессов целе-

вые функции процессов могут быть аналитически определены на

основании анализа результатов по первым двум способам.

Следует обратить внимание, что для внедрения новых компью-

терных технологий, кроме административного взаимодействия

между всеми субъектами бизнес-процессов, необходимо точ-

но знать все составляющие информационного потока, средства

и характеристики используемых коммуникационных каналов.

Одним из основных организационных документов любого

предприятия является схема организационной структуры, кото-

рую обычно изображают произвольным образом (без определен-

ных правил) в виде иерархического рисунка, во главе которого

находится руководитель.

Главным недостатком типовой организационной схемы,

впрочем, как и большинства других организационных (офисных)

документов, является отсутствие формальных правил описания,

вследствие которых сведения, содержащиеся в документах, мо-

гут трактоваться неоднозначно, а часто и ошибочно. Как пра-

вило, такое схематическое описание не призвано отражать всех

достаточно сложных взаимных отношений, прав, должностных

обязанностей и фактически исполняемых функций, т.е. изна-

чально является неточным и неполным.

В условиях современного бизнеса для принятия правильных

решений по реорганизации предприятия подобной информации

может оказаться недостаточно.

Даже гораздо более полная и формализованная нормативная

документация системы управления качеством и официальные

должностные инструкции часто не отражают полноту взаимо-

действия между элементами организационной системы, тем

более в условиях динамики протекания бизнес-процессов. Как

462

6.6. Технологии анализа и реинжиниринга бизнес-процессов

Правило, в официальной организационной документации со-

вершенно не учитывается и не отражается большой комплекс

ситуаций и событий, регулярно или эпизодически происходя-

щих в процессе функционирования предприятия. Например,

кто, когда и каким образом передает документы из одного под-

разделения в другое; как исполняются устные распоряжения ру-

ководства и т.д.

Для получения полной и объективной информации требуется

проведение углубленного обследования предприятия с исполь-

зованием специальных методов и средств, в том числе математи-

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

Таким образом, процесс разработки сложной комплексной ав-

томатизированной системы предполагает проведение обширного

и глубокого исследования производственной среды с целью выявления

структуры и динамики процессов, разработки научно обоснованной

концепции, использования математического моделирования, син-

теза технических решений и их оптимизации.

На основании приведенного выше краткого обзора и анали-

за последовательности и содержания работ по созданию PLM-

системы, который содержит основные признаки прикладных

научных исследований, можно сделать вывод о необходимости

использования научного подхода к разработке и оценке проектов

современных автоматизированных систем.

Научная методология разработки и внедрения сложных ав-

томатизированных систем базируется на использовании поло-

жений системного подхода и системного анализа. Сложились

и используются следующие классические определения этих тер-

минов и понятий [3].

Системный подход — это методология специального науч-

ного познания и социальной практики, объяснительный прин-

цип, в основе которого лежит исследование объектов как систем

с определенной структурой, состоящих из элементов, которые

необходимо рассматривать во всем многообразии их свойств

и связей, дающих в своей совокупности новое качество, опреде-

ляющее целостность и специфику свойств системы.

Признано, что системный подход способствует адекватной по-

становке проблем и выработке эффективной стратегии их реше-

ния во многих прикладных науках и вследствие своих выдающихся

463

Раздел 6. Создание, внедрение и интеграция систем и технологий

гносеологических качеств занимает одно из ведущих мест в на-

учном познании в целом.

Системный анализ основывается на системном подходе и вклю-

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

подготовки и обоснования решений сложных проблем различно-

го характера.

Основная процедура системного анализа — построение обоб-

щенной модели, адекватно отображающей интересующие ис-

следователя свойства реальной системы. Полученная модель ис-

следуется с целью выяснения близости и сравнения вариантов

объектов, выявления степени чувствительности модели к внеш-

ним воздействиям.

Один из важнейших принципов системного анализа пред-

полагает разложение (декомпозицию) сложной задачи на более

простые составляющие ее подзадачи с целью упрощения её опи-

сания и решения.

В задачах реинжиниринга бизнес-процессов используется

так называемый структурно-функциональный анализ, который

представляет собой методологическую разновидность общего

системного анализа. Основная идея структурного анализа за-

ключается в выявлении структуры как относительно устойчивой

совокупности отношений между элементами системы во време-

ни. При этом каждый элемент структуры имеет определенное

функциональное назначение. Понятие функции при исследова-

нии автоматизированных систем подразумевает служебную роль

(назначение) одного из элементов системы по отношению к дру-

гому или системе в целом.

Стандарты информационных технологий поддержки жиз-

ненного цикла продукции (CALS/ИПИ технологий) включают

положения методологии функционального моделирования, ко-

торые вводят в практику следующие основные термины и опре-

деления из этой научной области [92].

Система представляет собой совокупность взаимосвязанных

и взаимодействующих частей, выполняющих некоторую полез-

ную работу. Частями (элементами) системы могут быть любые

комбинации разнообразных сущностей, включающие людей,

информацию, программное обеспечение, оборудование, изде-

лия, сырье или энергию.

464

6.6. Технологии анализа и реинжиниринга бизнес-процессов

465

Модель системы — это искусственный объект, представля-

ющий собой отображение (образ) системы и ее компонентов,

оторый разрабатывают для понимания, анализа и принятия

решений о реконструкции (реинжиниринге) или замене суще-

ствующей системы либо проектировании новой.

Считается, что модель Л моделирует систему Б, если А отвеча-

ет на необходимые вопросы относительно Б.

Модель описывает, что происходит в системе, как ею управ-

ляют, какие сущности она преобразует, какие средства исполь-

зует для выполнения своих функций и что производит система

в конечном итоге.

В процессе создания PLM-системы могут последовательно

разрабатываться множество моделей, которые совместно охва-

тывают все важнейшие решения относительно описания, проек-

тирования и документирования автоматизированной системы,

например:

-модель бизнес-процессов — формализует абстракцию органи-

зации;

- модель предметной области — формализует содержательную

часть (контент) системы;

- модель развертывания — формализует топологию аппарат-

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

- модель тестирования — для определения технико-эконо-

мических характеристик и анализа эффективности разработан-

ной системы и ряд других.

6.7. Методология структурного анализа

и моделирования систем

Современные методы структурно-функционального анализа

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

фессора Массачусетского технологического института Дугласа

Росса в начале 70-х гг. XX в. и нашли свое воплощение в кон-

цепции SADT (Structured Analyses and Design Technique), что в до-

словном переводе означает «технология структурного анализа

и проектирования».

Раздел 6. Создание, внедрение и интеграция систем и технологий

Со времени своего появления в SADT постоянно совер-

шенствовалась и была с успехом использована в ряде крупных

проектов в области управления финансами и материально-

технического снабжения, стратегического планирования дея-

тельности фирм, при проектировании вычислительных систем

и сетей и др. [66].

SADT был принят за основу при реализации программы

ВВС США по созданию интегрированной автоматизированной

системы управления производством (Integreted Computer Aided

Manufacturing — ICAM), призванной решить актуальную задачу

повышения эффективности производства военной техники по-

средством широкого внедрения компьютерных технологий.

В результате развития проекта ICAM в 1981 г. разработан об-

щесистемный стандарт, получивший название IDEF0. Семейство

стандартов IDEF унаследовало свое обозначение от названия

этой программы (ICAM DEFinition), однако методологически его

следует рассматривать как определенное подмножество SADT.

Методология структурного анализа систем IDEF позволя-

ет исследовать структуру, параметры и характеристики широ-

кого круга производственно-технических и организационно-

экономических систем. Общая методология IDEF состоит из

ряда частных методологий моделирования, число которых уже

доведено до 14.

В настоящий момент к семейству IDEF относятся следующие

основные стандарты структурно-функционального моделирования:

— IDEF0 — методология функционального моделирования.

(Function Modeling Method). Моделирование процессов и систем

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

жающего структуру и функции системы, а также все основные

связи между ними.

— IDEF1 — методология информационного моделирования

(Information and Data Modeling Method), отображающая структу-

ру и содержание информационных потоков, необходимых для

поддержки функций системы. Развивается в основном версия

IDEF1X(IDEFI Extended), приспособленная для моделирования

реляционных баз данных.

— IDEF2 — методология построения динамических моделей,

меняющихся во времени поведения функций, информации и

466

6.7. Методология структурного анализа и моделирования систем

467

ресурсов системы (Simulation Modeling Method). В связи со слож-

ностью анализа динамических систем от этого стандарта прак-

тически отказались. Он официально не принят и в российских

стандартах.

— IDEF3 — методология моделирования и документирования

процессов, происходящих в системе (Process Flow and Object Stale

Description Capture Method). Нотация удобная для описания по-

следовательности работ (сценария, алгоритма) и может приме-

няться при исследовании технологических процессов на пред-

приятиях.

— IDEF4 — методология построения объектно-ориентирован-

ных систем (Object Oriented Design Method). Средства IDEF4 по-

зволяют отображать структуру объектов, классов, диаграмм на-

следования и принципы их взаимодействия.

— IDEF5 — методология онтологического исследования сложных

систем (Ontology Description Capture Method). Под «онтологией»

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

области знаний с помощью некой концептуальной схемы. Обыч-

но такая схема состоит из иерархической структуры данных, со-

держащей все релевантные классы объектов, их связи и правила

(теоремы, ограничения), принятые в этой области. С помощью

методологии IDEF5 онтология системы может быть описана при

помощи определенного словаря терминов и правил.

К IDEF относятся и некоторые другие стандарты [34, 66]. Для

решения задач разработки автоматизированных систем практи-

ческое распространение подучили стандарты IDEFO, IDEF1X

и IDEF3.

Семейство методологий IDEF продолжает развиваться, в

том числе практическое распространение получил метод DFD

(Data flow diagram — «диаграммы потоков данных»), предназна-

ченный для моделирования процессов в информационных си-

стемах. DFD включает такие понятия, как «хранилища данных»

и «внешние сущности», и используется при разработке про-

граммного обеспечения.

Основные положения стандартов IDEF использованы также

при создании комплекса стандартов ISO 10303, задающих техно-

логию STEP для представления в компьютерных средах инфор-

мации, относящейся к промышленному производству, и нашли

Раздел 6. Создание, внедрение и интеграция систем и технологий

отражение в отечественных стандартах CALS/ИПИ, принятых

2001

г.

[92].

Семейство стандартов IDEF отличается от многих формаль

ных методов и языков моделирования тем, что в нем регламен

тируются не только средства отображения бизнеспроцессов,

но и содержатся рекомендации по проведению взаимодействия

«аналитикспециалист» в процессе проведения обследований

предприятий, т.е. предлагается формализованная технология

создания модели системы, охватывающая всю последователь

ность процесса моделирования.

Следует заметить, что многие начинающие проектировщики

и специалисты по внедрению автоматизированных систем не

дооценивают важность функционального моделирования. Зача

стую это воспринимается как трудоемкая и утомительная работа.

Однако методы формализации, кроме поддержки исследователь

ских задач, выполняют важную стабилизирующую роль в про

цессе обследования, поскольку построение однозначной и на

глядной концептуальной схемы придает направленный, целевой

характер взаимоотношениям «аналитикспециалист», позволяет

более полно оценить специфику моделируемой предметной об

ласти и избежать возможных ошибок на стадии проектирования

системы. При этом в процессе моделирования производится до

кументирование процессов на единообразном и строгом языке,

что может быть использовано при проектировании, сопровожде

нии и развитии спроектированной системы.

Иногда для моделирования функционирования бизнес

процессов применяют нотацию, разработанную ранее для гра

фоаналитического представления алгоритмов и программ в виде

блоксхем единой системы программной документации (ЕСПД)

Этот понятный и широко известный метод документирования

можно рассматривать как дополнительный инструмент при опи

сании частных операций, имеющих выраженный алгоритмиче

ский облик. К сожалению, блоксхемы не позволяют отразить

все типы структурных связей, а их листинги слишком громоздки

для представления сложных систем.

Оптимизация PLM-решений. Поскольку целью реинжини

ринга является нахождение оптимального решения, по мнению

автора, к функциональному моделированию вполне применим

468

6.7. Методология структурного анализа и моделирования систем

Вход

ИМЯ

,« ж 7-г»ТГ¥ TfXf Ж

•>

• •

ФУНКЦИИ

А 0

Выход

Механизм Вызов

Рис. 6.7.1. Функциональный блок

469

понятийный аппарат, используемый в теории оптимального

проектирования.

Разработка любой структурнофункциональной модели на

чинается с формулировки вопросов, на которые модель должна

давать ответы, т.е. формулируются целевые функции.

Далее выполняются сбор информации с целью выявить со

став и характер проектных переменных и ограничений.

Полученная адекватная модель используется для генерации

вариантов проекта системы и их оптимизации.

6.7.1. Основы метоликн молелировання IDEF0

Основной принцип методологии IDEF заключается в пред

ставлении изучаемой системы в виде набора взаимодействую

щих и взаимосвязанных функциональных блоков (или просто

функций), отображающих процессы, операции и действия, про

исходящие в изучаемой системе.

Функция в терминах IDEF — это деятельность, работа, про

цесс или преобразование (материалов, энергии, документов, ин

формации и т.д.).

Каждой функции ставится в соответствие один блок (рис.

6.7.1). Функциональные блоки (Activity Box — блоки деятельно

сти) изображаются графически на отдельном отформатирован

ном листе (шаблоне) документа, называемом IDEFOдиаграмма

(см. рис 6.7.4).

Управление

Раздел 6. Создание, внедрение и интеграция систем и технологий

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

моугольника (рис. 6.7.2), который олицетворяет собой некото-

рую конкретную функцию в рамках рассматриваемой системы.

По рекомендациям стандарта название каждого функциональ-

ного блока нужно сформулировать в глагольном наклонении

(например «разрабатывать документацию», а не «разработка до-

кументации»). В том числе производить детали, проектировать

изделие, разработать чертежи, проверить деталь и т.д.

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

ваемой системы должен иметь свой уникальный идентификаци-

онный номер, например А-0, А-1, А-2 и т.д.

Связи (интерфейсы), посредством которых блок взаимодей-

ствует с другими блоками или с внешней средой, изображаются

стрелками, входящими в блок или выходящими из него. Причем

количество стрелок может быть различным, но принципиально

важно, на какую сторону блока стрелка (связь) указывает или от

какой стороны исходит.

Графическим отображением связей является однонаправ-

ленная стрелка (Arrow). Стрелка может состоять из одного или

нескольких горизонтальных и (или) вертикальных сегментов

и моделирует своеобразный канал, передающий данные (инфор-

мацию) или материальные объекты от источника (начальная точ-

ка стрелки) к потребителю (конечная точка с «наконечником»).

Каждая стрелка должна иметь свое уникальное наименование

(Arrow Label — Метка стрелки), причем наименование должно

быть оборотом существительного, например:

Чертежи, Технологические требования, Конструкция детали,

Геометрическая модель, Инженер-конструктор, Требования.

Каждая из четырех сторон функционального блока имеет

строго определенное значение:

— левая

сторона определяет, что и откуда приходит на вход

функции (Input — Вход);

— правая

сторона определяет, что и куда выходит в результате

выполнения функции (Output — Выход);

— верхняя сторона определяет, как и откуда осуществляется

управление функцией (Control — Управление);

— нижняя сторона определяет средства, используемые для

выполнения функции (Mechanism — Механизм). Стрелки меха-

470

6.7. Методология структурного анализа и моделирования систем

низма, направленные вниз, являются стрелками вызова, которые

обозначают обращение из данной модели к блоку, входящему

в состав другой модели или другой части модели, обеспечивая их

связь.

Сами эти термины (функция, вход, управление, выход, меха-

низм, вызов) не должны использоваться в метках стрелок.

471

Рис. 6.7.4. Пример контекстной диаграммы верхнего уровня

Контекстная диаграмма А-0 должна содержать краткие утверж-

дения, определяющие точку зрения (Viewpoint) должностного

лица или подразделения, с позиций которого создается модель,

и цель (Purpose), для достижения которой ее разрабатывают.

Считается, что существует множество различных точек зре-

ния (разрезов) на процессы, протекающие в организации. Поня-

тие «точка зрения» позволяет определить, какие связи и объекты

более подробно будут исследоваться в данном разрезе в пределах

контекста модели. Аспекты, важные с одной точки зрения, могут

не проявляться в описании, выполняемом с другой точки зрения

на тот же самый объект.

Важным принципом стандарта IDEF0 является декомпозиция

моделей (Decomposition), позволяющая разрабатывать функци-

ональную модель сверху вниз, от общего к частному. При этом

итоговая модель представляет собой иерархическую структуру*

состоящую из ряда уточняющихся диаграмм (рис. 6.7.5).

472

473

Раздел 6. Создание, внедрение и интеграция систем и технологий

Затем, на следующем уровне иерархии, модель уточняется

и создается «дочерняя диаграмма» (Child diagram), ссылающаяся

на «родительскую диаграмму» (Parent Diagram) верхнего уровня

Каждая из дочерних диаграмм может быть далее детализирована

путем аналогичной декомпозиции соответствующего ей функ-

ционального блока. При декомпозиции функционального бло-

ка все стрелки, входящие в данный блок или исходящие из него,

отображаются на дочерней диаграмме, чем обеспечивается чита-

бельность и структурная целостность модели (см. рис 6.7.5).

Принцип ограничения сложности IDEFO-диаграмм заключа-

ются в следующих правилах-рекомендациях:

— стандартом [92] рекомендуется, чтобы неконтекстные диа-

граммы содержали не менее трех и не более шести блоков;

— количество подходящих к одной стороне функционально-

го блока интерфейсных стрелок не рекомендуется делать более

четырех.

Диаграммы с количеством блоков менее трех вызывают се-

рьезные сомнения в необходимости декомпозиции родитель-

ской функции. Диаграммы с количеством блоков более шести

сложны для восприятия читателями и вызывают у автора труд-

ности при внесении в нее всех необходимых графических объ-

ектов и меток.

Эти ограничения не являются абсолютно жесткими. С целью

обеспечения читабельности диаграмм на практике допускается

несколько отступать от этих правил сообразно удобству исполь-

зования.

Блоки на диаграмме должны располагаться по диагонали —

от левого верхнего угла диаграммы до правого нижнего в поряд-

ке присвоенных номеров (цифра в правом нижнем углу прямоу-

гольника), а обозначение под правым углом указывает на номер

дочерней для этого блока диаграммы.

Отсутствие номера дочерней диаграммы говорит о том, что

декомпозиции для данного блока не существует. Ссылочный код

формируется из последовательности номеров диаграмм, от име-

ни блока (А), и включает номера всех дочерних блоков.

Достаточно часто отдельные стрелки-связи не имеет смысла

продолжать рассматривать в дочерних диаграммах или, наобо-

рот, они затрудняют чтение диаграмм верхнего уровня. Для таких

474

6 7

методология структурного анализа и моделирования систем

сВ

язей в стандарте IDEF0 предусмотрено «обозначение туннеля»

(Arrow Tunnel). Например, стрелку, изображающую «деталь» на

входе в функциональный блок «Обработать станок», можно не

указывать на диаграммах более высоких уровней, при этом она

отмечается в виде двух круглых скобок. Метка, поставленная во-

круг начала стрелки, означает, что эта дуга не была унаследована

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

неля) только на этой диаграмме. Такое же обозначение вокруг

конца (стрелки) означает, что в дочерней по отношению к это-

му блоку диаграмме эта дуга рассматриваться не будет, но она

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

другой диаграмме.

Отображение отношений функций на диаграммах. В методоло-

гии IDEF0 принято шесть типов отношений между функцио-

нальными блоками в пределах одной диаграммы:

— доминирование;

— управление;

— выход — вход;

— обратная связь по управлению;

— обратная связь по входу;

— выход — механизм.

Считается, что процессы, имеющие раннее начало, «домини-

руют» над более поздними функциями, описываемыми блоками,

расположенными ниже и правее начальных. «Доминирование»

определяет уровень влияния, которое одна функция может ока-

зывать на другие.

Рассмотренные ранее связи вход — выход, выход — управление

представляются достаточно очевидными линейными понятиями,

отображение которых показано соответственно на рис 6.7.6 а, б.

Обратные связи по управлению и по входу являются более слож-

ными типами отношений, поскольку они описывают итерацион-

ное взаимодействие процессов. Выход функции влияет на буду-

щее выполнение других функций с большим доминированием,

что впоследствии влияет на исходную функцию [92].

Отношение обратной связи по входу имеет место тогда, когда

результаты деятельности дочерней функции становятся входом

блока с большим доминированием, например как показано на

рис. 6.7.6

в.

475

Обратная связь по управлению возникает тогда, когда выход до-

чернего блока создает управляющее воздействие на блок с боль-

шим доминированием, например как показано на рис. 6.7.6 г.

Связи «выход — механизм» отражают ситуацию, при которой

выход одной функции становится средством достижения цели

для другого функционального блока (рис. 6.7.6 д).

476

Связи «выход — механизм» возникают при отображении в мо-

дели процедур пополнения и распределения ресурсов (например,

финансирование, закупка материалов), создания или подготов-

ки различных средств обеспечения (например, приобретение

иди изготовление требуемых инструментов и оборудования),

также в результате обучения персонала.

Содержание пакета диаграмм, составляющих IDEF0-

описание разработанной модели системы со всеми уровнями

и структурной декомпозицией, может быть представлено на ито-

говой диаграмме в виде «дерева узлов». Согласно рекомендаци-

ям по стандартизации [92] для изображения дерева узлов модели

нет стандартного формата. Единственное требование состоит

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

наглядно и понятно. Пример дерева узлов показан на рис. 6.7.7.

477

Раздел 6. Создание, внедрение и интеграция систем и технологий

обозначений и сокращений, а также для размещения данных

важных для понимания и определения параметров процессов

Текст не должен использоваться для описания синтаксиса языка

моделирования, только семантики — смысловой части описаний.

В пакет документов допускается включать «диаграммы — иллю-

страции (FEO)», которые используются в качестве дополнений

поясняющих содержание основных диаграмм. Иллюстративные

диаграммы могут не подчиняться синтаксическим правилам

IDEF0, например, выполняться в виде рисунков и схем.

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

ствующих определений, ключевых слов, повествовательных из-

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

В глоссарии дается определение введенным сущностям (рас-

шифровывается их смысл), а также содержится дополнительная

информация, например, понятие «конструкторский документ»

может содержать перечень необходимых согласующих подписей.

6.7.2. Метлика групповой разработки IDEF-молели

Стандарт IDEF0 содержит практические рекомендации, по-

зволяющие участвовать в обследовании и разработке функцио-

нальных моделей большой группы экспертов и специалистов,

являющихся носителями знаний в разных областях деятельности

моделируемой системы.

Обычно процесс разработки является итеративным и состоит

из следующих условных этапов:

— Создание первоначальной модели группой специалистов-

аналитиков, которые в терминах IDEF0 называются авторами

(Authors). В процессе предварительного обследования предприя-

тия создается первое описание, которое предлагается рассматри-

вать как «черновик модели» (Model Draft) (рис 6.7.8, 6.7.9).

— Обсуждение и уточнение модели. На данном этапе черновик

модели предлагается для рассмотрения компетентным специа-

листам предприятия (в терминах IDEF Readers — читатели).

Обсуждения проводятся в форме совещаний, которые необ-

ходимы для согласования точек зрения и получения разверну-

тых комментариев по процессам, проходящим на предприятий.

При этом могут использоваться методы теории принятия решении,

478

479

480

6.7. Методология структурного анализа и моделирования систем

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

грамм черновой модели письменно критикуется и комменти-

руется, а затем передается автору. Автор, в свою очередь, также

письменно соглашается с критикой или отвергает её с изложе-

нием логики принятия решения и вновь возвращает откоррек-

тированный черновик для дальнейшего рассмотрения. Этот

цикл продолжается до тех пор, пока авторы и читатели не придут

к единому мнению.

— Оформление и утверждение модели. Утверждение согласо-

ванной модели происходит как руководителем рабочей группы,

так и руководством предприятия, когда в экспертной группе до-

стигнут консенсус по поводу ее адекватности.

В результате получается IDEFO-модель предприятия, адек-

ватно отражающая настоящее состояние основных бизнес-

процессов по принципу «Как есть».

В дальнейшем эта модель передается на анализ и обработку

к специалистам (бизнес-аналитикам) по CALS/MFIM/PLM-

технологиям, которые должны будут проанализировать раз-

работанные функциональные модели с целью трансформации

описания «как есть» в оптимизированное описание «как должно

быть».

На основании результатов моделирования и проведенных на

комплексе моделей исследований формируются рекомендации

по реорганизации бизнес-процессов, и определяется концепция

оптимального PLM-решения для конкретного предприятия.

6.7.3. Терминология и синтаксис

информационного молелирования

IDEF1 создавался как стандартный метод моделирования ин-

формационных потоков внутри системы, позволяющий на опре-

деленном графоаналитическом языке отображать их структуру

и взаимосвязи для последующего анализа и реинжиниринга.

Как мы уже отмечали, в настоящее время развивается в основ-

ном расширенная версия IDEF1X (Extended), приспособленная

Для моделирования реляционных баз данных, реализующая так

Называемое семантическое моделирование. Семантическая или

инфологическая модель представляет собой описание структуры

481