Революционный подход к рационализации. Реинжиниринг бизнес-процессов.

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

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

Одно из ключевых понятий, лежащее в основе реинжиниринга – бизнес - процессы. Именно их совершенствование является огромным резервом повышения эффективности деятельности предприятия. А для этого необходимо осмыслить природу бизнес - процессов, понять, какое значение они имеют для предприятия, как следует их правильно изменять. Само внимание к бизнес - процессам, их совершенствованию требовало от менеджеров нестандартного подхода. Постепенно реинжиниринг, который предлагает сломать существующую на предприятии систему и построить ее заново на основе такого революционного изменения бизнес - процессов, стал превращаться в систему управления. [Борис Кабанов «Бизнес-инжиниринг»]

Майкл Хаммер и Джеймс Чампи определяют реинжиниринг бизнес-процессов (BPR - business process reingineering) как «фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов компании для достижения коренных улучшений в актуальных основных показателях их деятельности: стоимости, качества, услуг и темпов».

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

На практике выделяется три типа компаний, для которых применение реинжиниринга необходимо и целесообразно:

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

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

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

Один из самых наглядных способов представления информации, часто используемый при внедрении интегрированных систем управления – диаграммы IDEF (ICAM Definition), позволяющие проводить исследования определенных характеристик любой организации.

Применение методологии IDEF позволяет решить следующие задачи:

· Выяснить структуру и содержание существующих потоков информации на предприятии

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

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

Геннадий Верников так комментирует возможные сложности при начинании перестройки системы функционирования: «:... интуитивно все вроде бы понятно, но при попытках формализовать взаимоотношения возникает "сплошной туман". В данной ситуации существенно помочь может хорошо разработанное семейство методологий IDEF, являющееся государственным стандартом в США. … IDEF - методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности - ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах.

После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов. Более того, собственно с широким применением IDEF и связано возникновение основных идей популярного ныне понятия - BPR (бизнес-процесс реинжиниринг).»

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

Основной идеей моделирования IDEF (Integration Definition for Function Modeling - интегрированное определение для функционального моделирования) является то, что процессы (или функции реального объекта бизнеса) могут быть представлены как некоторые преобразования входного (и, возможно, управляющего) потока в выходной под контролем управляющего потока с использованием для преобразования некоторого механизма (см. рис.2). Процессы представляются на более высоком уровне диаграммы достаточно общим образом, позволяющим уяснить их суть, однако, без излишней детализации, усложняющей понимание и чтение диаграмм. При необходимости более детального рассмотрения они могут быть декомпозированы, то есть представлены в виде отдельной диаграммы, для которой исходный функциональных блок играет роль контекстной диаграммы.

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

Основные элементы и понятия IDEF

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

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

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

· Верхняя сторона имеет значение “Управление” (Control);

· Левая сторона имеет значение “Вход” (Input);

· Правая сторона имеет значение “Выход” (Output);

· Нижняя сторона имеет значение “Механизм” (Mechanism).

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

Вторым “китом” методологии IDEF является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

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

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

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

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

Рис. 3. Зависимые диаграммы

На IDEF-диаграмме (рис.3) отображены уже 3 функции (А, В, С) и их взаимосвязи. Из диаграммы видно, что функция В зависит от одного входа и двух управлений и производит один выход, от которого зависит функция С.

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

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

Данная особенность IDEF-методологии показана на рис. 4, где приведены четыре диаграммы и их взаимосвязи.

Рис. 6 . Структура IDEF-модели

Каждая компонента может быть декомпозирована на другой (дочерней) диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на родительской диаграмме.

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

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

Принципы ограничения сложности IDEF-диаграмм

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

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

Система 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. В качестве примеров объектов можно привести такие как "Функция", "Событие", "Структурное подразделение", "Документ" и т.п. Между объектами устанавливаются разнообразные связи. Так, между объектами "Функция" и "Структурное подразделение" могут быть установлены связи следующих видов: выполняет; принимает решение; участвует в выполнении; должен быть проинформирован о результатах; консультирует исполнителей; принимает результаты и т.п. В следующей таблице приводятся основные типы используемых объектов.

Таблица 1.

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

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

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

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

Рисунок 7.

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

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

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

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

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

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

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

Таблица 2

В общем случае можно сделать следующие замечания по выбору системы по нотациям. Одним из важнейших аспектов описания моделей бизнес-процессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации 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] ВСЕ ЧТО 10 ШРИФТОМ ПРЕДНАЗНАЧЕНО ДЛЯ ОЗНАКОМЛЕНИЯ

• ⇐ Назад
• 1
• 23