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

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

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

кто выполняет процедуры процесса;

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

какие исходящие документы/информацию генерирует процедуру процесса;

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

какая документация/условия регламентирует выполнение процедуры;

какие параметры характеризуют выполнение процедур и процессов в целом. [38]

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

1. математические (дисперсия, среднеквадратичное отклонение и т.п.);

2. экономические (стоимость, убытки, прибыль);

3. технологические (время).

В зависимости от поставленной цели (описание, анализ или синтез), любой бизнес-процесс может быть представлен:

- концептуальной моделью;

- предметной моделью;

совокупностью знаковых моделей.

Концептуальная модель (КМ) представляет идеальный образ [4]. Детализация концептуальной модели, позволяющая экспериментировать с ней для получения необходимой информации, осуществляется в предметной и знаковой формах.

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

Функциональная модель отражает функционирование системы. Структурная модель отражает строение системы, взаимосвязи между ее элементами. [4]

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

Логико-лингвистическая (словесно-описательная) модель [33] описывает свойства на естественном языке. Графические модели можно разделить на портретные и условные. Портретная (иконическая) модель отображает свойства графическими средствами (чертеж, схема, фотография).

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

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

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

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

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

Если модель не позволяет проводить анализ, синтез объекта и получать прогноз по нему, то ее следует дополнять другими моделями.

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

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

1. показатели качества продукции и удовлетворенности потребителя;

2. показатели длительности (время выполнения процесса, цикл, производительность и т.д.);

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

В соответствии с требованиями ISO 9001:2000 разделов 5.2 “Ориентация на заказчика” и 8.2.1 “Удовлетворенность потребителя” для потребителя основной группой показателей является 1-я, но для предприятия важны все группы. Для успешной реорганизации бизнес-процессов необходимо учитывать все группы показателей. При этом сложность задачи по оптимальному выбору системы, способа сбора и обработки данных по показателям окупается улучшением системы управления процессами, снижением затрат ресурсов и времени.

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

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

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

- маркетинговая модель (оценка влияния внешней среды - рынка - на рассматриваемый бизнес);

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

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

В эти категории можно отнести и ряд других моделей. Для их построения применимы популярные на Западе концепции управления - MRP (Manufacturing Resource Planning), DRP (Distribution Resource Planning), ERP (Enterprise Resource Planning), CSRP (Customer Synchronized Resource Planning) [18].

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

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

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

Бизнес-модель -- это осязаемый результат, с помощью которого можно максимально конкретизировать цели внедрения ИСУ предприятия и определиться со следующими параметрами проекта:

1. перечень участков внедрения и последовательность их автоматизации;

2. фактическая потребность в объемах закупаемого программного и аппаратного обеспечения;

3. реальные оценки сроков развертывания и запуска ИСУ;

4. уточненный список членов команды внедрения и ключевых пользователей;

5. степень соответствия выбранного вами прикладного ПО специфике бизнеса вашей компании и многое другое.

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

В основе бизнес-модели всегда лежат бизнес-цели предприятия, по большому счету полностью определяющие состав всех базовых компонентов бизнес-модели [2]:

· бизнес-функции, описывающие, ЧТО делает бизнес;

· бизнес-процессы, описывающие, КАК предприятие выполняет свои бизнес-функции;

· организационная структура, определяющая, ГДЕ исполняются бизнес-функции и бизнес-процессы;

· фазы, определяющие, КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции;

· роли, определяющие, КТО исполняет бизнес-процессы;

· правила, определяющие связь между ЧТО, КАК, ГДЕ, КОГДА и КТО.

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

· воздействия, инициирующие каждый шаг бизнес-процесса;

· исполнители каждого шага (это могут быть как люди, так и программы и механизмы);

· воздействия, регламентирующие данный шаг (законодательные акты, рыночные условия и т. п.);

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

Моделирование ни в коем случае не должно стать внутренним процессом отдела ИТ. Так же верно и обратное: в случае привлечения группы управленческих консультантов, то со стороны заказчика модели в совместную группу моделирования должны входить менеджеры отделов и ключевые пользователи [21]. Следует позаботиться о том, чтобы все участники проектной группы к моменту начала работ по бизнес-моделированию прошли обучение методологии моделирования, основам проектирования больших систем, а также приобрели минимальные навыки работы с будущей ИСУ -- познакомились с архитектурой системы, основами навигации по системе, функциональным назначением подсистем и т. п.

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

Одним из самых важных критериев выбора инструмента моделирования является возможность поддержки нескольких этапов и даже вариантов развития вашего предприятия. Целевая модель позволит увидеть, сколько еще необходимо произвести изменений (от технологических до кадровых) в структуре вашего предприятия. Иногда возникает необходимость выстроить на основе моделей «как есть» и «как будет» несколько промежуточных моделей (а точнее, моделей того минимального числа бизнес-процессов, изменение которых предстоит осуществить в первую очередь). Затем выстраивается график введения этих моделей в эксплуатацию [11]. Такой метод последовательных улучшений позволяет ослабить сопротивление на местах, смягчить последствия «шоковой терапии» и, в конце концов, достичь поставленных целей.

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

1. Внутреннее тестирование разработчика

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

2. Тестирование проектной группой

Желательно совместить эту стадию с первой, устранив тем самым лишнее ресурсоемкое звено в цепочке приемки модели. Данная стадия выделяется только тогда, когда условия реализации проекта внедрения ИСУ на предприятии выражаются в словосочетании «под ключ».

3. Тестирование ключевыми пользователями

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

4. Опытная эксплуатация

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



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

Инструментальные средства, предназначенные для моделирования информационных систем, могут быть отнесены к одной из следующих категорий [47]:

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

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

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

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

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

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

Типичный представитель малых интегрированных средств моделирования -- комплект программных продуктов Platinum Technology (CA/ Platinum/Logic Works), основанный на популярных пакетах BPwin и Erwin.

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

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

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

К средним интегрированным средствам можно отнести такие известные продукты, как Rational Rose (Rational Software), Paradigm Plus (CA/Platinum), Designer/2000 (Oracle).

Rational Rose и Paradigm Plus основаны на объектно-ориентированном подходе к моделированию и ориентированы на метод UML (Unified Modeling Language). Помимо UML поддерживаются и другие методы. Отличия между Rational Rose и Paradigm Plus состоят в основном в доступных пользователю типах диаграмм и методов [47].

Средства моделирования среднего класса предназначены для выполнения комплексного анализа систем. Они могут быть успешно применены при создании малых и средних ИСУП, особенно с этапа анализа спецификаций. Слабая сторона -- недостаточные возможности для моделирования и анализа на верхнем уровне (анализ требований). Крупные интегрированные средства моделирования. К этой категории относится инструментальное средство, специально предназначенное для проектирования крупных ИСУП, таких, например, как системы управления предприятием класса ERP. Это -- семейство ARIS (ARIS Toolset, ARIS Easy Design) компании IDS Sheer AG. В ARIS воплощен практический опыт множества аналитиков, работающих в области проектирования ИСУП, а также учтены недостатки существующих инструментальных средств. Отличительная особенность ARIS -- особое внимание к первому уровню анализа (анализ требований).

Не отказываясь от классификации инструментальных средств на локальные, малые, средние и крупные, используем также другую классификацию инструментальных средств, аналогичную классификации ИСУП на ERP -- не-ERP.

Принадлежность к категории ERP для средств моделирования означает, что оно предназначено для выполнения комплексного анализа на всех стадиях (требования, спецификации, внедрение) разработки ИСУП класса ERP. Естественно, такое средство может быть использовано при создании любых других ИСУП, а не только ERP.

Если же средство моделирования принадлежит к категории не-ERP, это означает, что оно не предназначено для выполнения всех уровней анализа при проектировании ИСУП класса ERP, но его (средство) можно использовать при создании локальных, малых или средних ИСУП, не относящихся к классу ERP.

Из рассмотренных выше инструментальных средств к категории ERP можно отнести только ARIS.

Все рассмотренные выше инструментальные средства широко используются для моделирования и анализа систем, в том числе и при создании ИСУП.

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

Среди малых инструментальных средств доминируют пакеты BPwin и ERwin компании Platinum.

Локальные и малые инструментальные средства могут быть использованы при разработке соответственно локальных и малых ИСУП. Для средних и крупных ИСУП использование этих средств имеет смысл в качестве дополнения к более универсальному инструментальному средству средней категории [47].

Средства моделирования средней категории, как правило, основаны на использовании объектно-ориентированного подхода к моделированию и анализу систем. Фактическим стандартом для этой категории инструментальных средств является унифицированный язык моделирования UML. По данным исследовательской компании International Data Corporation, среди инструментальных средств, которые можно отнести к этой категории, лидирующее положение занимает пакет Rational Rose.

Средние интегрированные средства предназначены в основном для уровней анализа спецификаций и внедрения. Они удобны при разработке средних, малых и локальных ИСУП. Недостаточные возможности для анализа на уровне требований могут быть компенсированы путем их использования вместе с локальными или малыми инструментальными средствами.

Система ARIS как крупное интегрированное средство моделирования имеет уникальные возможности для моделирования и анализа систем. Моделирование в ARIS может выполняться как "сверху вниз", так и "снизу вверх" [48].

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

2.3 Основные методологии обследования организаций. Стандарт IDEF0, ARIS сравнительный анализ

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

Семейство методологий IDEF, является государственным стандартом в США. Данное семейство состоит из методологии функционального моделирования IDEF0 и методологии информационного моделирования IDEF1X. IDEF - методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности - ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между ВСЕМИ специалистами - участниками программы ICAM (отсюда название: Icam DEFinition - IDEF). После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов (он активно применяется и в отечественных государственных структурах, например в Государственной Налоговой Инспекции). Более того, собственно с широким применением IDEF (и предшествующей методологии - SADT) и связано возникновение основных идей реинжиниринга бизнес-процессов [49].

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

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

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

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

IDEF1X (IDEF1 Extended) - методология построения реляционных структур. IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

IDEF2 - методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе “раскрашенных сетей Петри” (CPN - Color Petri Nets);

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

IDEF4 - методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

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

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

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=ICAM DEFinition) [47].

C 1981 года стандарт IDEF0 претерпел несколько незначительных изменения, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST) [48].

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

В основе методологии лежат четыре основных понятия:

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

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

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

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

Таблица 2.3.1

Основные элементы IDEF0

№№	Наименование	Описание	Графическое представление
Нотация IDEF0
1	Модуль поведения (UOB)	Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия.
22	Стрелка слева	Стрелка описывает входящие документы, информацию, материальные ресурсы, необходимые для выполнения функции.
33	Стрелка справа	Стрелка описывает исходящие документы, информацию, материальные ресурсы, являющиеся результатом выполнения функции.
44	Стрелка сверху	Стрелка описывает управляющее воздействия, например распоряжение, нормативный документ и т.д. В нотации IDEF0 каждая процедура должна обязательно иметь не менее одной стрелки сверху, отражающей управляющее воздействие.
55	Стрелка снизу	Стрелка снизу описывает т.н. механизмы, т.е. ресурсы, необходимые для выполнения процедуры, но не изменяющие в процессе ее выполнения свое состояние. Примеры: сотрудник, станок и т.д.

Таблица 2.3.2

Основные элементы IDEF3

№№	Наименование	Описание	Графическое представление
Нотация IDEF3
11	Модель работы (UOW)	Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия.
22	Ссылочный объект	Объект, используемый для описания ссылок на другие диаграммы модели, циклические переходы в рамках одной модели, различные комментарии к функциям.
33	Логическое «И»	Логический оператор, определяющий связи между функциями в рамках процесса. Позволяет описать ветвление процесса.
34	Логическое «ИЛИ»	Логический оператор, определяющий связи между функциями в рамках процесса. Позволяет описать ветвление процесса.
55	Логическое исключающее «ИЛИ»	Логический оператор, определяющий связи функциями в рамках процесса. Позволяет описать ветвление процесса.

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

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

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

Таблица 2.3.3

Типы стрелок используемых в IDEF

№	Тип стрелки	Графическое представление
1	Стрелка предшествования. Соединяет последовательно выполняемые функции.
2	Стрелка отношения. Используется для привязки объектов-комментариев к функциям.
3	Стрелка потока объектов. Показывает поток объектов от одной функции к другой.

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

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

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

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

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

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

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

Модель IDEF0 всегда начинается с представления системы как единого целого - одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”.

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

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

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

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком - Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит - родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 - модели. Наглядно принцип декомпозиции представлен на рисунке 2.3.1. Каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

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

Нотация ARIS eEPC расшифровывается следующим образом - Extended Event Driven Process Chain - расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В таблице 2.3.4 и таблице 2.3.5 приводятся основные используемые в рамках нотации ARIS eEPC объекты [39].

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



Рисунок 2.3.1 Декомпозиция функциональных блоков

Таблица 2.3.4

Основные элементы ARIS

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

Таблица 2.3.5

Основные элементы ARIS

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

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

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

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

Сравнительный анализ нотаций ARIS и IDEF приводится в следующей таблице 2.3.6 [39].

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

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



Таблица 2.3.6

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

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

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

Функциональные возможности инструментальных средств моделирования ARIS Toolset и BPwin можно корректно сравнивать только по отношению к определенному кругу задач. В данном исследовании рассматривается задача формирования моделей (описания) бизнес-процессов предприятия. Каждая из рассматриваемых систем имеет свои преимуществ и недостатки. В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот. То же касается и недостатков: недостаток системы в рамках одного проекта, может не быть недостатком в рамках другого. Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках eEPC ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы [47], в то время как нотация IDEF0 системы BPwin позволяет решить эту задачу [43]. С другой стороны, описание процедуры, выполняемой одним сотрудником, может быть описано более адекватно при помощи eEPC ARIS, чем IDEF0 или IDEF3 BPwin. Сравнение функциональных возможностей систем приводится в следующей таблице.

Сравнивая две системы, следует сразу отметить, что для хранения моделей в ARIS используется объектная СУБД, и под каждый проект создается новая база данных. Для удобства пользователя модели (объекты моделей) могут храниться в различных группах, организованных в зависимости от специфики проекта. Вполне естественно, что в ARIS-е предусмотрены различные функции по администрированию базы данных: управление доступом, консолидация и т.п [42]. В BPwin данные модели хранятся в файле, что существенно упрощает работу по созданию модели, но с другой стороны ограничивает возможности по анализу объектов модели. В ModelMart так же предусмотрено администрирование базы данных [26].

Часто одним из недостатков BPwin сторонники ARIS-а называют ограничение по количеству объектов на диаграмме. Однако опыт реальных проектов показывает, что для проекта, результаты которого можно реально использовать (критерий - обозримость), количество объектов в базе данных ARIS или модели BPwin составляет 150-300. Это означает, что при 8 объектах на одной диаграмме, общее количество диаграмм (листов) в модели составит 20-40. Базы данных ARIS Toolset (как и BPwin), содержащие более 500 объектов, фактически невозможно использовать.

Таблица 2.3.7

Сравнительный анализ программных средств

№	Возможности/Инструментальная среда	ARIS Toolset 5.0	BPwin 4.0
1	Поддерживаемый стандарт	- (частично - DFD, ERM, UML)	IDEF0, IDEF3, DFD
2	Система хранения данных модели	Объектная база данных	Модели хранятся в файлах
3	Ограничение на размер базы данных	Нет. Размер базы данных ограничивается вычислительными ресурсами	Нет. Размер базы данных ограничивается вычислительными ресурсами
4	Возможность групповой работы	Есть. Используется ARIS Server.	Есть. Используется ModelMart.
5	Ограничение на количество объектов на диаграмме.	Нет.	От 2 до 8.
6	Возможность декомпозиции	Неограниченная декомпозиция. Возможно декомпозиция на различные типы моделей.	Неограниченная декомпозиция. Возможен однократный переход на другую нотацию в процессе декомпозиции.
7	Формат представления моделей	Не регламентируется	Стандартный бланк IDEF с возможностью его отключения
8	Удобство работы по созданию моделей	Сложная панель управления, есть выравнивание объектов, есть undo.	Простая панель управления, нет выравнивания объектов, нет undo.
9	UDP - свойства объектов, определяемые пользователем	Большое, но ограниченное количество свойств, количество типов ограничено.	Количество UDP не ограничено. Количество типов ограничено.
10	Возможность анализа стоимости процессов	Есть. Возможность использовать ARIS ABC.	Упрощенный анализ стоимости по частоте использования в процессе. Возможность экспорта в Easy ABC.
11	Генерация отчетов	Создание отчетов на основе стандартных и настраиваемых пользователем макросов Visual Basic.	RPT Win, возможность визуальной настройки отчетов, включая расчет по формулам с использованием UDP
12	Сложность разработки нестандартных отчетов	Сложно	Просто

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

ARIS предоставляет существенно больше возможностей по работе с отдельными объектами модели, но именно вследствие чрезмерного количества настроек работа по созданию модели должна регламентироваться сложной, многоаспектной документацией - т.н. «Соглашениями по моделированию». Разработка этих «Соглашений» само по себя является сложной, дорогой и требующей значительного времени (1-3 месяца) и квалифицированных специалистов задачей. Если проект с использованием ARIS начинается без детальной проработки таких соглашений, то вероятность создания моделей бизнес-процессов, не отвечающих на поставленные вопросы, составляет 80-90% [26]. В свою очередь, BPwin отличается простотой в использовании, и достаточной строгой регламентацией при создании диаграмм (стандарт IDEF и рекомендации по его применению, бланк IDEF для создания диаграммы, ограниченное количество обязательно заполняемых полей, ограничение количества объектов на одной диаграмме и т.д.). ARIS, безусловно, является более «тяжелым» инструментом, по сравнению с BPwin, но это в итоге оборачивается значительными трудностями и высокими затратами на его эксплуатацию.

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

Различные ситуации применения инструментальных средств моделирования бизнес-процессов и их экспертная оценка по 5-бальной шкале показаны в следующей таблице 2.3.8 [9].

Рисунок 2.3.3 Позиционирование программных средств



Таблица 2.3.8

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

Задача/Инструментальная среда	ARIS Toolset 5.0	BPwin 4.0
Разовый проект по описанию бизнес-процессов, например: 1. описание одного бизнес-процесса с точки зрения контроля и управления; 2. описание функциональных возможностей новой системы управления на верхнем уровне.	3 3	5 5
Длительный (непрерывный) проект по описанию деятельности компании с различных точек зрения (организационная структура, структура документов, большой объем базы данных процессов и т.д.)	5	3
Разработка системы автоматизации: 1. описание функциональных возможностей системы; 2. создание логической модели данных;	3 3	5 BPwin + ERwin + Paradigm Plus

Таким образом, для ведения небольших по масштабам (малые и средние предприятия, 2-5 человека в группе консультантов) и длительности (2-3 месяца) проектов рационально использовать BPwin. Для крупных и/или длительных проектов (например, внедрение системы непрерывного улучшения бизнес-процессов, ISO, TQM) больше подходит ARIS. В этом случае подготовительные работы по созданию регламентирующей документации могут занять 1-3 месяца, но это является необходимым элементом последующей успешной работы.

Позиционирование систем можно провести по отношению к решению задачи моделирования бизнес-процессов (см. рисунок 2.3.3).

По итогам второй главы можно сделать следующие выводы.

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

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

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

Для моделирования бизнес-процессов необходимо создание специальной группы из сотрудников предприятия и внешних консультантов-специалистов. Существует ряд требований к составу такой группы и к входящим в нее сотрудникам и специалистам.

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

Для моделирования с целью оптимизации отдельного бизнес-процесса наиболее подходящей является программная среда BPwin.



3. МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССА “ОБСЛУЖИВАНИЕ КЛИЕНТА” НА УУПП “АВТОКОНТАКТ” ВОС

3.1 Описание проблемы, цели и задачи моделирования

УПП «Автоконтакт» ВОС - государственное, промышленное предприятие Всероссийского Общества Слепых. Основной сферой деятельности является производство комплектующих на автомобили УАЗ и товаров народного потребления. За последние три года был получен ряд заказов от Волжского Автомобильного Завода.

Само предприятие функционирует более 50 лет. На УПП «Автоконтакт» ВОС сложились давние традиции, как в управлении, так и на производстве. Средний стаж рабочих составляет около 30 лет.

«Автоконтакт» является учебно-производственным предприятием Всероссийского Общества Слепых. Основная задача руководства - это обеспечение работой инвалидов по зрению. УПП «Автоконтакт» ВОС имеет льготное налогообложение. Распределение прибыли осуществляется через центральный ВОС. Обязательным условием существования этой организации является то, что численность инвалидов по зрению на предприятии должна быть не менее 52% от численности всего персонала.