Оптимизация бизнес-процессов

Выводы по диаграммам:

В  языке UML для этапов анализа предназначены следующие виды диаграмм:

• use case diagram (диаграммы прецедентов);
• ·activity diagram (диаграммы описаний технологий, процессов, функций);
• sequence diagram (диаграммы последовательностей действий);
• collaboration diagram (диаграммы взаимодействий).

Проанализируем их функциональную пригодность для этих целей.

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

Плюсом диаграммы является ее простота, наглядность и читабельность  неспециалистами. Фактически является некоторым аналогом нотации IDEF0 (прецедент  – работа, актер – один из механизмов).

Activity diagram – представляют собой схемы потоков управления в системе от действия к действию, а также параллельные и альтернативные потоки,  с является неким аналогом нотаций IDEF0 и IDEF3. Т.е. понятие  «перекресток» заменяется элементами «линия синхронизации» и «выбор», а «работа» - «действием». Диаграмма не очень приспособлена для отображения сложной логики, но возможно ее использование в качестве доступного для понимания аналога заказчику.

Дуги Use Case и Activity диаграмм не имеют смысловых типов, которые указаны для дуг IDEF0. Использование данных диаграмм требует установления дополнительных синтаксических соглашений, т.к. UML нежесткий язык и  допускает построение синтаксически корректных Activity-диаграмм, не имеющих смысла или не поддающихся объяснению. Например, чтобы определить тип входящей стрелки, различать документы, можно их выделять цветом, использовать пунктирные и сплошные стрелки и т.п.

Sequence diagram –  иллюстрирует события, инициированные в системе исполнителями. Если изобразить диаграмму на абстрактном уровне в терминах предметной области, а систему рассматриваются как "черный ящик", то она является достаточно удобным инструментом для построения общей информационной модели. Т.е. входное сообщение является входной информацией в терминах IDEF0, а отклик системы (объекта) – выходной информацией.

3. Методология ARIS

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

Методология ARIS включает большое количество методов моделирования, в том  числе известных как диаграммы  Чена ERM, язык UML (Unified Modeling Language), методики ОМТ (Object Modeling Technique), BSC (Balanced Scorecard) и т.п.

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

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

 

 

1. Сравнительный анализ методов.

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

1. Целей проекта;
2. Требований к информации необходимой для анализа и принятия решений в рамках конкретного проекта;
3. Возможностей  подхода с учетом требований п. 2;
4. Особенностей разрабатываемой/внедряемой информационной системы.

Сравнение подходов должно дать ответы  на следующие вопросы:

1. На сколько сам подход и его нотации применимы для того или иного этапа проектирования ИС.

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

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

 

 

 

Сравнительный анализ нотаций

ARIS (eEPC), IDEF, Sequence и Activity diagram

Таблица 2

№	Критерии сравнения	ARIS	IDEF0	IDEF3	Sequence diagram	Activity diagram
1	Принцип построения диаграммы	Временная последовательность выполнения	Принцип иерархической упорядоченности	Временная последовательность выполнения	Последовательность выполнения	Последовательность выполнения
2	Описание процедуры процесса	Объект на диаграмме	Объект на диаграмме	Объект на диаграмме	Объект на диаграмме	Объект на диаграмме
3	Входящий документ	Используется отдельный объект для  описания («документ»)	Стрелка слева, стрелка сверху	Нет (может быть отражен привязкой объекта)	В зависимости от принятого соглашения может быть объектом или стрелкой	Может быть объектом или стрелкой
4	Входящая информация	Используется объект для описания («кластер», «технический термин»)	Стрелка слева, стрелка сверху	Нет (может быть отражен привязкой объекта)	Может быть объектом или стрелкой	Может быть объектом или стрелкой
5	Исходящий документ, информация	Используется объект для описания («документ», («кластер»)	Стрелка справа	Нет (может быть отражен привязкой объекта)	Может быть объектом или стрелкой	Может быть объектом или стрелкой
7	Исполнитель процедуры	Используется объект для описания («позиция», «организационная единица»)	Стрелка снизу	Нет (может быть отражен в модели только привязкой объекта-комментария)	Используется отдельный объект «Actor»	Разграничение зон на диаграмме
8	Используемое оборудование	Используется отдельный объект для  описания	Стрелка снизу	Нет (может быть отражен привязкой объекта)	-	-
9	Управление процедурой	Нет. Может быть отражено только последовательностью  выполнения	Стрелка сверху	Только логика процесса	Только логика процесса	Только логика процесса
10	Контроль выполнения процедуры	Нет. Может быть отражен указанием входящих документов	Стрелка сверху	Нет	Нет. Может быть отражен указанием входящих документов	Нет. Может быть отражен указанием  документов
11	Обратная связь по управлению/контролю	Нет. Может быть отражена последовательностью выполнения	Стрелка сверху	Нет	Нет. Может быть отражен указанием входящих документов	Нет. Может быть отражен указанием входящих документов
12	Наглядность модели	Модель наглядна и есть возможность  использования визуальных образов  с последующей конвертацией	Модель нечитабельна неспециалистами	Модель нечитабельна неспециалистами	Модель наглядна, но несколько громоздка	Модель очень наглядна

 

 

 

Функциональные возможности подходов можно корректно сравнивать только по отношению к определенному  кругу задач.

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

 

 

4. Сравнительный анализ CASE-средств.

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

• какое программное обеспечение использовать в проекте («ARIS лучше BPWin?», «ERWin лучше ARIS?» и т.п.);
• как моделировать процессы с использованием продукта «Х»?;
• как проводить анализ и выявлять проблемы при помощи продукта «Х»?;
• какую методологию использовать для описания процессов?

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

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

В России для моделирования и  анализа бизнес-процессов достаточно широко используются следующие средства моделирования: Rational Rose, Oracle Designer, AllFusion Process Modeler (BPWin) и AllFusion ERwin Data Modeler (ERWin), ARIS, Power Designer.

В данном сравнительном анализе  мы будем рассматривать Rational Rose, ARIS и BPwin

1. Общая информация о продуктах.

BPwin - средство моделирования бизнес-процессов

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

Основные достоинства  BPwin:

• BPwin обладает интуитивно-понятным графическим интерфейсом, быстро и легко осваивается, что позволяет сосредоточиться на анализе самой предметной области, не отвлекаясь на изучение инструментальных средств. BPwin помогает быстро создавать и анализировать модели с целью оптимизации деловых и производственных процессов. Применение универсальных графических языков бизнес-моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов.
• Посредством набора графических инструментов для отображения действий и объектов, BPwin позволяет легко построить схему процесса, на которой показаны исходные данные, результаты операций, ресурсы, необходимые для их выполнения, управляющие воздействия, взаимные связи между отдельными работами.
• Интерактивное выделение объектов обеспечивает постоянную визуальную обратную связь при построении модели. BРwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами при моделировании.
• Встроенный механизм вычисления стоимости позволяет оценивать и анализировать затраты на осуществление различных видов деловой активности. BPwin может генерировать отчеты непосредственно в формате MS Excel. Связь с ERwin (IDEF1X) позволяет сократить время проектирования и разработки сложных информационных систем. Для системных аналитиков тесная интеграция BРwin с инструментом проектирования баз данных открывает уникальные возможности по созданию действительно комплексных систем, в которых ERwin служит для описания информационных объектов системы, в то время как BPwin отражает функциональные особенности предметной области.

 

IBM Rational Rose - входит в состав пакета IBM Rational Suite и предназначен для моделирования программных систем с использованием широкого круга инструментальных средств и платформ. Rational Rose является одним из ведущих инструментов визуального моделирования в программной индустрии, благодаря полноценной поддержке языка UML и многоязыковой поддержке командной разработки. Инструмент полностью поддерживает компонентно-ориентированный процесс создания ИС. Любые участники проекта - аналитики, специалисты по моделированию, разработчики и другие - могут использовать модели, построенные в Rational Rose, для большей эффективности создания конечного продукта. Для аналитиков, специализирующихся в области разработки баз данных, Rational Rose даст возможность визуально проектировать и генерировать базы данных любого размера. Таким образом, можно создавать базы данных Microsoft SQL Server, Oracle, Sybase, SQL Anywhere, IBM DB2 и любые другие, которые поддерживают возможность запуска скриптов стандарта ANSI SQL. Любые модели, создаваемые с помощью данного средства, являются взаимосвязанными: бизнес-модель, функциональная модель, модель анализа, модель проектирования, модель базы данных, модель компонентов и модель физического развертывания системы. Интеграция Rational Rose с Rational RequisitePro позволяет на базе визуальной модели разработать полный набор требований, которые необходимо реализовать при создании конечного продукта. Интеграция Rational Rose с Rational TestManager позволяет создавать сценарии тестирования на базе визуальной модели. Интеграция Rational Rose с Rational ClearCase позволяет поставить на версионный контроль модель целиком или по частям. Интеграция Rational Rose с Rational SoDA позволяет автоматизировать процесс создания документов и отчетов по визуальной модели.