Описание декомпозиций бизнес процессов

Презентация на тему: » Декомпозиция процессов. Сеть процессов организации. (лекция 3)» — Транскрипт:

1 Декомпозиция процессов. Сеть процессов организации. (лекция 3)

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

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

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

Принципы и практика декомпозиции бизнес-процессов при построении архитектурной модели компании

5 Сеть процессов организации Определение. Сеть процессов – это совокупность взаимосвязанных и взаимодействующих процессов предприятия, включающих в себя все виды деятельности, осуществляемой на предприятии.

6 Самые распространенные ошибки при описании сети процессов организации

7 Ошибка 1- процесс 5 не имеет входов. Это означает, что при выделении процессов часть деятельности организации для процесса 5 была пропущена. Ошибка 2 – процесс 10 ничего не не создает. Это означает, неполную картину описания процессов или ненужность процесса 10.

8 Правила выделения процессов в организации. Классификация процессов.

9 Выделение процессов в организации При выделении процессов возникает ряд вопросов: Какие процессы должны быть в организации? Список обязательных процессов? Сколько процессов должно быть в организации? Кто такой «владелец» процесса, его права и обязанности? Как обеспечить взаимосвязь процессов в единую сеть?

10 Классификация процессов Тип процесса: Основной процесс ( процесс основной деятельности). Характерные признаки. Назначение процесса – создание основных продуктов. Результат – основной продукт и/или полуфабрикат для его изготовления. Процесс лежит на пути создания основных продуктов. Процесс добавляет к продукту ценность для потребителя. Клиенты. 1. Внешние клиенты.

2. Конечные потребители. 3. Внутренние клиенты – другие процессы организации.

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

12 Классификация процессов Тип процесса: Вспомогательный процесс. Характерные признаки. Назначение процесса – обеспечение деятельности основных процессов. Результат – ресурсы для основных процессов. Деятельность процессов не касается основных продуктов. Процесс добавляет к продукту стоимость.

Описание бизнес процессов. Бизнес-процессы компании простыми словами

Клиенты. Внутренние клиенты – другие процессы организации.

13 Вспомогательные процессы Вспомогательные процессы напрямую не добавляют стоимости и являются по своей сути затратными. Примеры: подготовка кадров, сервисное обслуживание оборудования, обеспечение связью, IT –обеспечение, административно-хозяйственное обеспечение, финансовое и бухгалтерское обеспечение деятельности организации, обеспечение безопасности, другие процессы. Критерий выделения вспомогательного процесса – использование результатов этого процесса многими функциональными подразделениями и процессами.

14 Классификация процессов Тип процесса: Процесс управления. Характерные признаки. Назначение процесса – управление деятельностью всей организации. Результат – деятельность всей организации. Клиенты. 1. Собственники (инвесторы). 2. Потребители (клиенты).

3. Персонал (сотрудники). 4. Поставщики и субподрядчики. 5. Общество (внешняя среда).

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

16 Аппарат управления Отдел стратегического развития. Функции: определение проектов стратегических целей организации, составление проектов долгосрочных планов, контроль и анализ их выполнения и т.д. Планово-экономический отдел.

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

17 Пример Процессы ВГУЭС

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

19 Внутренние и внешние клиенты процесса Внешние клиенты рассматриваются по отношению к организации в целом. Внешними клиентами предприятия являются пять основных групп лиц. Клиенты (потребители основных продуктов, производимых организацией). Собственники (акционеры, инвесторы, аффилированные лица). Персонал (сотрудники и руководители организации).

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

20 Внутренние и внешние клиенты процесса Внутренними клиентами процесса являются подразделения (исполнители, процессы), использующие результат выполнения (выход) процесса.

Источник: www.myshared.ru

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

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

Модель может содержать четыре типа диаграмм:

• контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма );
• диаграммы декомпозиции ;
• диаграммы дерева узлов ;
• диаграммы только для экспозиции (FEO) .

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

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

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

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

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

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

Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, «Деятельность компании», «Прием заказа» и т.д.). Работа «Деятельность компании» может иметь, например, следующее определение: «Это учебная модель, описывающая деятельность компании». При создании новой модели (меню File/New) автоматически создается контекстная диаграмма с единственной работой , изображающей систему в целом (рис. 7.6).

Рис. 7.6. Пример контекстной диаграммы

Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы . Для описания других свойств работы служит диалог Activity Properties (рис. 7.7).

Рис. 7.7. Редактор задания свойств работы

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

на панели инструментов.

Возникает диалог Activity Box Count (рис. 7.8), в котором следует указать нотацию новой диаграммы и количество работ на ней. Остановимся пока на нотации IDEF0 и щелкнем на ОК. Появляется диаграмма декомпозиции (рис. 7.9).

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

Рис. 7.8. Диалог Activity Box Count

Рис. 7.9. Пример диаграммы декомпозиции

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

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

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

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

7.9 все работы еще не были декомпозированы.

Источник: intuit.ru

Особенности произведения декомпозиции процессно-событийной модели бизнес-процесса в нотации ARIS

Акатьев Ярослав Алексеевич – ассистент кафедры Практической и прикладной информатики МИРЭА – Российского технологического университета.

Анищенко Екатерина Игоревна – студент магистратуры кафедры Практической и прикладной информатики МИРЭА – Российского технологического университета.

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

Ключевые слова: проектирование программного продукта, моделирование, процессно-событийная модель, eEPC, ARIS, декомпозиция.

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

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

Для детального описания процессов, которые выполняются в рамках одного или нескольких подразделений конкретными сотрудниками используется процессно-событийная модель в нотации eEPC (extended Event-driven Process Chain). Данная нотация относится к методологии ARIS и предлагает такую систему описания процессов, в которой все функции семантически связаны.

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

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

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

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

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

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

Для связи процессов между собой используется «коннектор» к процессам уровня выше или объект Process Interface. Другими словами, если событие формируется в другом процессе, то ему предшествует интерфейс, который ссылается на предыдущий процесс. Если результатное событие является инициирующим для другого процесса, то за ним также должен располагаться интерфейс, отражающий последующий процесс. Process Interface при декомпозиции процессов является средством связи и границей между двумя функциональными объектами.

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

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

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

Рисунок 1. Верхний уровень процесса.

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

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

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

Рисунок 2. Декомпозиция процесса «Проверка состояния квартиры клиента».

Из приведенного примера наглядно заметно, что нарушение парадигм и семантики построения диаграмм в нотации ARIS влечет за собой затрудненное чтение диаграммы, а также ошибочные рассуждение при предоставлении диаграммы заказчику.

Перечислим основные требования к декомпозиции процесса:

• наличие стартового/завершающего события с верхнего уровня для четкого определения точки начала бизнес-процесса, так как в ARIS отсутствует понятие, как например, в BPMN0;
• наличие структурного элемента Process interface содержащего ссылку на внешний предшествующий и последующий процесс, также данный элемент может использоваться для отображения внешнего процесса, влияющего на текущий;
• все элементы документы и базы данных должны располагаться по возможности слева от процесса, а местоположение и роль справа;
• агрегирование атомарных функций в один функциональный блок позволит значительно сократить схему, а также способствует более качественному анализу бизнес-процесса.
• моделирование и чтение процесса должно проводиться «сверху-вниз» для наибольшей читаемости диаграммы.

На основании изложенных пунктов сформирован общий вид модели, описывающий верное расположение объектов при декомпозиции (Рисунок 3).

Рисунок 3. Общий вид модели.

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

1. Бьерн Андерсен. Бизнес-процессы. Инструменты совершенствования – Москва: Издательство «ASQ», 2019 г.
2. Д. Джестон. Управление бизнес-процессами. Практическое руководство по реализации проектов – Москвы: Издательство «Альпина Диджитал», 2020 г.
3. Владимир Репин. Бизнес-процессы. Моделирование, внедрение и управление – Москва: Издательство «Манн, Иванов и Фербер», 2019 г.
4. Шёнталер Франк, Фоссен Готфрид. Бизнес-процессы. Языки моделирования, методы, инструменты. 2019. – C. 86-134
5. Майк Мартин Хаммер. Реинжиниринг корпорации: манифест революции в бизнесе. Москва: Издательство «Манн, Иванов, Фербер», 2019 г.
6. Карл И. Вигерс, Джой Битти. Разработка требований к программному обеспечению. Санкт-Петербург: Изд-во БХВ-Петербург 2020.

Источник: na-journal.ru