Система ARIS

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

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

Для построения любой традиционной модели используются три уровня анализа:

· определение требований;

· формирование спецификаций;

· описания реализации.

На основе сформулированных требований, можно провести следующую классификацию инструментальных средств, используемых для моделирования бизнес-процессов при реинжиниринге бизнеса: инструментальные средства создания диаграмм и инструментарий низкого уровня; CASE, структурный и объектно-ориентированный инструментарий; средства имитационного моделирования/анимации; средства стоимостного анализа бизнес-процессов; интегрированные многофункциональные средства.

В зависимости от вида создаваемой системы управления предприятием все эти средства можно классифицировать на:

· локальные, поддерживающие один-два типа моделей и методов (Design/IDEF, ProCap, S-Designor, “CASE. Аналитик”);

· малые интегрированные средства моделирования, поддерживающие несколько типов моделей и методов (ERwin, BPwin);

· средние интегрированные средства моделирования, поддерживающие от 4 до 10—15 типов моделей и методов (Rational Rose, Paradigm Plus, Designer/2000);

· крупные интегрированные средства моделирования, поддерживающие более 15 типов моделей и методов (ARIS Toolset).

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

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

Изначально, фирма IDS Prof. Scheer существовала как отделение Института Информационных Систем германского Университета Саарланд. Данный институт является одним из наиболее известных германских исследовательских центров в области информационных систем. Этот факт позволил обеспечить тесную связь методологии ARIS с теорией информационных систем с учетом практики их применения в конкретных условиях.

Рассматриваемая методология основывается на разработанной профессором Шером теории «Построения Интегрированных Информационных Систем», определяющей принципы визуального отображения всех аспектов функционирования анализируемых компаний.

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

В семейство ARIS входят следующие модули:

ARIS Toolset - базовая инструментальная среда;

ARIS Easy Design - упрощенная среда моделирования;

ARIS Simulation - модуль динамического имитационного моделирования;

ARIS Link for R/3 - модуль, обеспечивающий интеграцию с репозиторием R/3;

ARIS Analyzer for R/3 - модуль проверки создаваемых моделей на соответствие методологии SAP;

ARIS ABC - модуль стоимостного анализа;

дополнительные модули-интерфейсы, обеспечивающие интеграцию с системами Microsoft Project, ERWin, Designer/2000, IBM Flowmark (класс workflow), Staffware и так далее.

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

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

- сбор информации об объекте;

- построение модели объекта «как есть»;

- анализ построенных моделей;

- построение моделей «как должно быть»;

- проектирование информационной системы (в случае необходимости).

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

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

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

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

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

2. Уровень проектной спецификации. Этот уровень соответствует концепции информационной системы, определяющей основные пути реализации предъявленных на втором этапе требований.

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

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

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

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

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

Модуль ARIS Simulation используется:

- для оценки возможностей оптимизации/модификации процессов (например, по временным затратам);

- для выявления узких мест;

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

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

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

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

Еще одним важным аспектом при моделировании становится проведение анализа финансовых затрат, необходимых для обеспечения нормальной жизнедеятельности системы. Это область стоимостного анализа, который также поддерживается средствами ARIS, а именно модулем ARIS ABC.

ARIS ABC – это автономный модуль, который может работать со средой ARIS Toolset. Он осуществляет анализ стоимости на базе моделей процессов с помощью аналитических методов оценки и исследования операций.

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

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

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

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

ARIS ABC используется:

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

- для дифференцированной оценки накладных расходов;

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

Модели в ARIS представляют собой графические схемы, отображающие соответствующие аспекты системы. Модели строятся на основе нотаций eEPC. Нотация ARIS eEPC расшифровывается следующим образом - Extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями.

eEPC-модель позволяет связать такие важные элементы бизнес-процесса, как:

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

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

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

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

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

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

Элементами таких моделей являются объекты, поддерживаемые ARIS. В качестве примеров объектов можно привести такие как «Функция», «Событие», «Структурное подразделение», «Документ» и т.п. Между объектами устанавливаются разнообразные связи. Так, между объектами «Функция» и «Структурное подразделение» могут быть установлены связи следующих видов: выполняет; принимает решение; участвует в выполнении; должен быть проинформирован о результатах; консультирует исполнителей; принимает результаты и т.п. В следующей таблице приводятся основные типы используемых объектов.

Таблица 2

№	Наименование	Описание	Графическое представление
	Функция	Объект «Функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия
	Событие	Объект «Событие» служит для описания реальных состояний системы, влияющих и управляющих выполнением функций
	Организационная единица	Объект, отражающий различные организационные звенья предприятия (например, управление или отдел)
	Документ	Объект, отражающий реальные носители информации, например бумажный документ	Document
	Прикладная система	Объект отражает реальную прикладную систему, используемую в рамках технологии выполнения функции

Таблица 2 (продолжение)

№	Наименование	Описание	Графическое представление
	Кластер информации	Объект характеризует данные, как набор сущностей и связей между ними. Используется для создания моделей данных
	Стрелка связи между объектами	Объект описывает тип отношений между другими объектами, например -активацию выполнения функции некоторым событием
	Логическое «И»	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса
	Логическое «ИЛИ»	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса
	Логическое исключающее «ИЛИ»	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса

Помимо указанных в табл. 2 основных объектов, при построении диаграммы могут быть использованы многие другие объекты.

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

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

Нотация eEPC построена на определенных семантических правилах описания:

1. Каждая функция должна быть инициирована событием и должна завершаться событием.

Рисунок 16. Пример модели, описывающей фрагмент

бизнес-процесса предприятия

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

На рис. 16 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1 «инициирует» выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3.

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

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

Начнем с сравнения нотаций, поддерживающих системы моделирования ARIS и IDEF. Сравнительный анализ нотаций ARIS и IDEF приводится в следующей таблице 3.

Таблица 3

В общем случае можно сделать следующие замечания по выбору системы по нотациям. Одним из важнейших аспектов описания моделей бизнес-процессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации ARIS eEPC управление процедурой может быть отражено только при помощи указания входящих документов, которые регламентируют выполнение процедуры, и последовательности выполнения процедур во времени (запускающие события). В отличие от ARIS, в нотации IDEF каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления – стрелка сверху). Если при создании модели в eEPC указывать только последовательность выполнения процедур, не заботясь об отражении управляющих воздействий (например, документов и информации), полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования. К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель Work Flow (поток работы), отражающая простую последовательность выполнения процедур и входящих/исходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются. Реальные процессы управления могут остаться «за кадром» на 30-90%.

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

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

Управлять можно только тем объектом, модель которого существует в системе управления этим объектом. Это необходимое условие управляемости. Поэтому, основной целью проектирования организации является построение ее модели или в соответствии с современной концепцией управления изменениями – процессной модели организации.

Здесь мы сталкиваемся с традиционной проблемой сложности, подробно исследованной Стэффордом Биром в 70-х. Объект анализа, на котором сосредотачивает свое внимание модельер, всегда демонстрирует растущее многообразие свойств по мере его изучения. Модельер не всеведущ в понимании объекта и в определении параметров «фильтрации», обрушивающейся на него информации в процессе разработки модели. При этом инструмент моделирования выступает не только как средство концептуального видения, но и как один из настраиваемых «фильтров». Они подавляют многообразие до уровня восприимчивости модельером (обеспечивают гомеостаз модельера). Бир отмечал, что снижение многообразия не только положительно, но и часто приводит к застою гомеостаза и разрушению кибернетической системы. В нашем случае снижение многообразия является необходимым условием формирования навыков моделирования. Часто разработчики инструментов, осознавая возможную узость инструмента и испытывая «испуг по Эшби», пренебрегают объективностью этой узости и снабжают инструмент избыточными свойствами. В результате, с ростом вариативности настройки «фильтра» (например, возможность выбора одной из нескольких равноценных нотаций) повышается «шум моделирования». Поэтому, инструменты могут работать как «фильтры», и как «усилители» шумового разнообразия.

В данном контексте видятся два основных направления развития инструментов реинжиниринга БП.

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

Другое – охватывает лишь отдельные фрагменты проектного цикла и направлено на представление сервиса для выражения «творческих» взглядов на проектирование организационных процессов.Например, методология ARIS, предлагает рассматривать организацию с позиции 12 аспектов, отображающих разные взгляды на предприятие, а также разную глубину этих взглядов. Для описания БП предлагается использовать 85 типов моделей, каждая из которых принадлежит тому или иному аспекту. Другими словами, два подхода различаются количеством стандартных отношений, которые представляет программная среда для описания БП.

Назовем первый подход- «узкий, но глубокий» (т.е. способствует большой глубине проработки проектных решений, но обладает небольшим спектром репрезентативных возможностей), а второй- и «широкий, но мелкий» (т.е. предлагает широкий спектр стандартных объектов для описания БП, но не позволяет осуществлять полный цикл проектных работ). Например, стандарт IDEF «заставляет» нас представлять функциональную (или процессную) модель в виде иерархической структуры, обеспечивая достаточную глубину проектной проработки, он «загоняет» проектировщика в рамки листового формата А4.

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

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

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

По различным данным от 30% до 80% реализаций РБП заканчиваются неудачей. Основная причина – инерционность РБП неадекватна скорости внешних изменений. Оперативность же достигается снижением количества вариантов в выборе или снижением многообразия. Отсюда – необходимость соответствия инструмента доктрине управления, культивируемой в организации.

Существуют определенные методические ограничения на описание БП, определяемые методом управления, которые уменьшают многообразие. Очевидно, что эти ограничения являются довольно жесткими в сравнении с ситуацией отсутствия этих ограничений. К сожалению, ни один из существующих инструментов РБП не предоставляет сервис, поддерживающий декомпозицию всех БП на процессы анализа, моделирования и регулирования. В этом смысле все известные альтернативы инструментов неудачны потому, что, пытаясь описать каждый БП в виде контура самоуправления, модельер будет испытывать перегрузку, проделывая большой объем ручной работы. Нужен ли ему в этом случае «широкий, но мелкий инструмент»? Если модельер стремится к минимизации ошибок и снижению риска быть непонятым, то, естественно, ответ на поставленный вопрос будет отрицательным.

Как известно, современные CASE средства используют не только в РБП, но и для узких задач. Например, для разработки средств программной поддержки исполнения БП. Как правило, эти функции поддерживаются в одном инструменте (ARIS) или системе согласованных друг с другом инструментов (ORACLE Designer, BPwin/Erwin/Paradigm Plus).

Методически функции формирования требований к БП и разработки систем по требованиям также реализуются по-разному. В первом случае осуществляется движение от «абстрактного» к «конкретному» (ARIS), а во втором (IDEF) – наоборот, от «конкретного» к «абстрактному». В части «конкретного» (техническое задание, требования и т.п.) эти движения пересекаются. Во втором случае «абстрактным» является множество связанных программных объектов, а в первом случае - множество БП уже формализованных на данный момент. В примитивном варианте – это, например, первый лист IDEF диаграммы.

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

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

Итак, какой же из известных инструментов РБП принесет организации наименьший вред?

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

В наибольшей степени свойствами подавления ментальных шумов и целенаправленности обладает методология IDEF.

Контрольные вопросы:

1. В чем отличие эволюционного и революционного подхода к рационализации организационных структур?

2. Какие механизмы эволюционного подхода к рационализации организационных структур вы знаете? Охарактеризуйте их кратко.

3. В чем суть реструктуризации?

4. Перечислите основные принципы IDEF- моделирования.

5. Перечислите основные принципы ARIS- моделирования.

6. В чем принципиальные отличия IDEF- и ARIS- моделирования?