1. Контекстная диаграмма: цель и точка зрения

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

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

2. Детализация

Затем блок, который отображает всю систему, детализируется на другой диаграмме.

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

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

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

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

Принцип туннелирования

Часто бывают случаи, когда отдельные стрелки не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот — отдельные блоки не имеют практического смысла выше какого-то уровня. С другой стороны, иногда возникает необходимость избавиться от отдельных “концептуальных” стрелок и не детализировать их глубже некоторого уровня.

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

Принцип ограничения сложности

Для того, чтобы ограничить перегруженность моделей и сделать их удобными для восприятия, в стандарте приняты соответствующие ограничения сложности:

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

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

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

Количественный анализ диаграмм: коэффициент сбалансированности и оценка имен

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

• количество блоков на диаграмме — N;

• уровень декомпозиции диаграммы — L;

• сбалансированность диаграммы — В;

• число стрелок, соединяющихся с блоком, — А.

Коэффициент сбалансированности

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

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

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

Введем коэффициент сбалансированности диаграммы:

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

Оценка имен

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

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

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

Коэффициент, количественно отражающий данный критерий, можно записать как:

L*C

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

http://www.nazametku.com/2010/11/idef0-%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F-%D0%BD%D0%BE%D1%82%D0%B0%D1%86%D0%B8%D1%8F-%D0%BF%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF%D1%8B-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB/

Что такое методология моделирования бизнес процессов и какие типы методологий существуют?

Октябрь 07th, 2010 | IT мир2 629 просмотров

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

Сначала разберемся в понятиях

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

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

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

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

Методология определяет стандарт и подход описания бизнес процесса организации.

Типы моделей бизнес процесса и методологий их построения

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

1. Организационная модель — описывает иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений;

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

3. Модель управления / модель потоков данных — описывает бизнес процессы компании верхнего уровня;

4. Модель потоков работ — описывает детализацию функций бизнес процесса;

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

Чаще всего используются последние три типа моделей бизнес процесса. Соответственно и методологии описания бизнес процессов также разделяются по типам:

• Методологии описания процессов верхнего уровня и потоков данных;

• Методологии описания потоков работ;

• Методологии описания структуры информации;

• прочие методологии.

http://www.nazametku.com/2010/10/tipizaciya-i-opredelenie-metodologii/

Методологии описания процессов верхнего уровня и потоков данных

Октябрь 04th, 2010 | IT мир2 076 просмотров

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

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

Принцип декомпозиции

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

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

Основные модели процессов верхнего уровня. Этапы построения.

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

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

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

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

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

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

Методологии. Особенности и использование.

	Основные элементы	Особенности	Использование, плюсы и минусы
DFD	Работа, Потоки, Внешние сущности, Хранилища.	Не задает последовательность работ. Отображает как бизнес процесс преобразует информационные и материальные потоки.	Построение сети бизнес процессов; Построение диаграмм потоков данных.
IDEF0	Работа, Потоки (управляющие, входные,выходные, механизмы)	Прототип DFD стандарта. Отличия: Типизация потоков; Последовательность работ задается четко.	Является излишне информационно насыщенным и сложным стандартом. Целесообразнее применять для небольших локальных бизнес процессов.
UML- Use case	Прецедент (функция), Актор (исполнитель); Стрелки (ассоциации, обобщения, расширения, включения)	Не может быть использована для моделирования потоков данных; На диаграмме нельзя показать последовательность выполнения работ. В основе моделирования — объектно ориентированный подход.	Подходит для построения контекстной диаграммы; Используется для определения функций создаваемой системы и их отношениями между собой и пользователем.
ARIS Основные диаграммы для моделирования процессов верхнего уровня
VAD	Процесс (основной и обеспечивающий); Тип связи «предшествует»; Тип связи «подчиняется по процессу»; Организационные единицы; Информационные и материальные объекты.	Прототип DFD стандарта, отличия: Информационные и материальные потоки изображаются не стрелками, а объектами. Позволяет отобразить логическую последовательность выполнения работ.	Отображение процессов, участвующих в создании добавленной стоимости, и поддерживающих вспомогательных процессов.
FAD	Функция; Организационные единицы; Информационные и материальные объекты.	Показывает окружение функции или бизнес процесса.	Построение контекстной диаграммы для бизнес процесса или функции.
FT	Функция	Показывает иерархическую структуру бизнес процессов или функций.	Построение дерева бизнес процессов.
PSM	Процесс; Сценарий; Организационная единица.	Прототип DFD. Не используются информационные и материальные объекты.	Используется как альтернатива VAD в случаях, когда описываемый бизнес-процесс имеет несколько вариантов исполнения, каждый из которых ложится на базовую схему.

http://www.nazametku.com/2010/10/metodologii-opisaniya-processov-verx/