Файл: Основные понятия методологии aris aris.docx

Невозможность визуального отражения длительности выполнения процедур. Бизнес-процесс в нотации еЕРС методологии представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в еЕРС визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе "Microsoft Project".

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

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

Необходимость разработки соглашений о моделировании. Методология ARIS поддерживает большое количество типов моделей, нотаций и объектов, т.е. предоставляется чрезмерное количество возможностей. Поэтому перед началом моделирования необходимо определиться с набором используемых типов моделей, а следовательно, объектов, их атрибутов и связей. Для этого формируются так называемые соглашения по моделированию. Разработка этих соглашений сама по себе является сложной, дорогостоящей задачей, требующей значительного времени (1—3 месяца) и квалифицированных специалистов. Если проект с использованием системы ARIS начинается без детальной проработки таких соглашений, то вероятность создания моделей бизнес-процессов, не отвечающих па поставленные вопросы, составляет 80—90%.

---

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

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

Основные модели ARIS

Как уже говорилось ранее, на практике применяется ограниченное количество моделей методологии ARIS организационная схема (Organizational Chart — ОС), функциональная модель (Function Tree — FT), процессно-событийная модель (extended Event-Driven Process Chain — eEPC).

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

Организационная схема (Organizational Chart — ОС) (далее — организационная модель) описывает организационные единицы различного уровня и их взаимосвязи. Эта модель — одна из важнейших, так как она описывает субъекты, которые определяют выходы и входы потоков ресурсов предприятия, управляют и участвуют в "деловых процессах".

В модели организационной структуры целесообразно отражать:

• 
  • подразделения предприятия;
  
• 
  • наименование должности и фамилии руководителей подразделений;
  
• 
  • физическое местоположение отделов на предприятии.
  

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

Описание организационной структуры не имеет фиксированного количества уровней, а имеет столько уровней, сколько требуется для полного описания структуры организации. Между объектами организационной модели устанавливаются взаимосвязи. Пример организационной модели представлен на рис. 6.1.

---

Рис. 6.1. Организационная модель

Функциональная модель (Function Tree — FT).

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

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

Пример функциональной модели приведен на рис. 6.2.



Рис. 6.2. Модель описания бизнес-процессов верхнего уровня

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

Процессно-событийная модель (Extended Event-Driven Process Chain — еЕРС) (кратко — модель или диаграмма еЕРС) предназначена для детального описания процессов, выполняемых в рамках одного подразделения, несколькими подразделениями или конкретными сотрудниками.

Модель еЕРС позволяет выявлять взаимосвязи между организационной и функциональной моделями.

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

Нотации ARIS еЕРС и IDEF3 базируются на одних и тех же принципах моделирования потоков работ (Work Flow), предполагающих использование символов логики ("перекрестков" в 1DEF3). С помощью этих символов отражаются ветвления и слияния потоков работ в рамках бизнес-процесса.

Модель еЕРС является расширением методологии IDEF3 за счет такого понятия, как событие (Event). Возможность моделирования событий в ARIS еЕРС позволяет создавать более корректные и подробные описания процессов. При этом, однако, существенно повышается сложность и трудоемкость описания.

---

Модель еЕРС наиболее информативна и удобна при описании деятельности подразделений организации.

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

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

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

Основу модели составляют чередующиеся объекты функция (Function) и событие (Event), связанные друг с другом. Пример простой цепочки (без ветвлений) событий и функций приведен на рис. 6.3.



Рис. 6.3. Цепочка событий и функций

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

• 
  • наступление плановой даты, времени, например, "принято решение о начале проекта";
  
• 
  • получение или отправка работником заявки, распоряжения, формы, информации, например, "поступила заявка от клиента".
  

Для удобства восприятия создаваемых моделей необходимо придерживаться ряда правил графического расположения объектов:

• 
  1. События и функции принято располагать последовательно сверху вниз.
  
• 
  2. Объекты, составляющие окружение функций (документы, данные, организационные элементы и информационные системы), располагаются относительно функции следующим образом:
  
  • 
    • входящие документы и данные — слева сверху;
    
  • 
    • исходящие документы и данные — слева снизу;
    
  • 
    • исполнители (организационные элементы) — справа но центру.
    

---

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



Рис. 6.4. Цепочка событий и функций и интерфейсов в другие процессы

Модель еЕРС выстраивается в соответствии со следующими правилами:

• 
  1. Каждая модель еЕРС должна начинаться как минимум одним стартовым инициирующим событием и завершаться как минимум одним результирующим событием.
  
• 
  2. События и функции должны иметь только по одному входящему и исходящему отношению (связи), показывающему ход управления процесса.
  
• 
  3. Путь процесса всегда разделяется и объединяется с помощью правил ветвления/слияния (об этом будет информация далее по тексту).
  

Для описания ветвлений процесса используется объект "Оператор правила" (Rule Operator), который размещается между функциями и событиями и соединяется с ними таким образом, чтобы правило имело одну входящую связь и несколько исходящих связей либо несколько входящих связей и одну исходящую связь, как это представлено в примерах на рис. 6.5.



Рис. 6.5. Варианты использования операторов правила

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

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

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

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

---