ИТ АРХИТЕКТУРА ПРЕДПРИЯТИЯ / ENTERPRISE IT ARCHITECTURE / ДЕКОМПОЗИЦИЯ МОДЕЛИ ПРОЦЕССА / PROCESS MODEL DECOMPOSITION / ОНТОЛОГИЯ БУНГЕВАНДА-ВЕБЕРА / BUNGE-WAND-WEBER ONTOLOGY / СЦЕПЛЕНИЕ / СВЯЗНОСТЬ / COUPLING / COHESSION
Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Фёдоров И.Г.
Проблема декомпозиции модели бизнес-процесса является ключевой при разработке ИТ архитектуры предприятия . Пока она не будет решена, работа аналитика останется ремеслом, тогда как требуется инженерный подход. Цель статьи анализ и теоретическое обоснование в контексте онтологической модели Бунге-Ванда-Вебера свойств такой декомпозиции, которую можно считать «правильной», разработке принципов, позволяющих получить правильную декомпозицию.
i Надоели баннеры? Вы всегда можете отключить рекламу.
Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Фёдоров И.Г.
Адаптация онтологии Бунге-Ванда-Вебера к описанию исполняемых моделей бизнес-процессов
Теория бизнес-процессов: формальные модели и методы
Анализ концептуальной модели бизнес-процесса с использованием онтологии Бунге-Ванда-Вебера
Формальные методы теории бизнес-процессов
Модели и методы теории бизнес-процессов (обзор)
i Не можете найти то, что вам нужно?
Как описать бизнес-процесс
Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.
A principles of a process model decomposition
One of the actual problems of applied informatics is the issue of a good decomposition of a business process model. Almost any applied project in the field of IT development includes modeling of a business processes, so that their success depends significantly on the quality of the models used for the analysis, re-engineering and automation. The decomposition of business process model is a key problem in the development of IT enterprise architecture. While this problem is not yet solved, the work of an analyst remain a craft, while engineering approach is required.
The purpose of this article is to analyze the theoretical basis and in the context of the Bunge-Wanda Weber ontologicy, develop the principles of a decomposition, which can be considered as a «good» one, suggest criterion which will help to achieve a proper model decomposition. It is wrong to understand decomposition as an identification of components of a system. One should take into consideration the links between its modules if the connections are complex, their analysis may negate the advantage of decomposition. Strongly connected components cannot be considered separately, but only jointly.
The reason for the strong connection is the intersection of an information objects and sub-processes, resulting decomposition. The peculiarity of this research is that we consider a coordinated decomposition of data objects, process operations and external events.
Текст научной работы на тему «Принципы декомпозиции модели процесса»
Принципы декомпозиции модели процесса
Кратко и системно об описании бизнес-процессов
Проблема декомпозиции модели бизнес-процесса является ключевой при разработке ИТ архитектуры предприятия. Пока она не будет решена, работа аналитика останется ремеслом, тогда как требуется инженерный подход. Цель статьи — анализ и теоретическое обоснование в контексте онтологической модели Бунге-Ванда-Вебера свойств такой декомпозиции, которую можно считать «правильной», разработке принципов, позволяющих получить правильную декомпозицию.
Ключевые слова: ИТ архитектура предприятия, декомпозиция модели процесса, онтология Бунге-Ванда-Вебера, сцепление, связность.
Одна из актуальных проблем прикладной информатики — правильная декомпозиция модели бизнес-процесса. Практически любой прикладной проект в области ИТ включает моделирование бизнес-процессов, так что его успех существенно зависит от качества моделей, используемых для анализа, реинжиниринга и автоматизации [1]. Модель, содержащая много мелких деталей, сложна для понимания [2], однако, если детали опущены, она окажется непригодной для автоматизации [3]. Чтобы обеспечить одновременно полноту и точность модели, сохранив при этом ее понимание, используют декомпозицию [4; 5], выполняемую с целью замены рассмотрения сложной проблемы решением нескольких задач меньшей сложности [6; 7]. Преимущества декомпозиции неоспоримы, однако принципы ее реализации до сих пор рождают споры. Обзор существующих подходов
1 Работа выполнена при поддержке Минобрнауки России, в рамках базовой части государственного задания проект 2966 (шифр 2014/162).
к проблеме декомпозиции [8] показывает, что общепринятых методик структуризации модели процесса не существует, результат зависит от личного мастерства аналитика [11], так что модели, созданные разными аналитиками, могут различаться и с высокой вероятностью содержать ошибки. Проблема декомпозиции модели бизнес-процесса — ключевая для разработки архитектуры процессов предприятия, без ее решения невозможно снизить число неудач проектов по внедрению новых ИТ.
Так как успех разработки и использования информационных технологий зависит от качества декомпозиции модели процесса на образующие ее подпроцессы, поставим цель — теоретически обосновать свойства «правильной» декомпозиции, разработать принципы, позволяющие исключить субъективизм аналитика при структуризации модели процесса, поскольку в основе многих работ в области теории моделирования бизнес-процессов лежит концептуализация, предложенная Я. Вандом и Р. Вебером [9] на базе онтологии, разработанной М. Бунге [12; 13].
Особенность декомпозиции системы
Будем различать состав системы, определяющий номенклатуру ее компонентов, и структуру, трактуемую как совокупность устойчивых связей между этими элементами [12]. Неверно понимать декомпозицию как выявление состава системы, следует обязательно учитывать связи. Если они имеют сложный характер, их анализ может свести на нет преимущество декомпозиции — сильно связанные компоненты нельзя рассматривать по отдельности, но только совместно. Таким образом, система не определяется ее частями, не может быть познана и объяснена на основе одного лишь знания о ее составе [14].
Чтобы понять, что мы имеем дело с системой, нужно найти эмерджентное, системообразующее свойство [13]. Если в результате декомпозиции свойство исчезнет, это будет свидетельствовать о том, что разрушенная связь между элементами системы сильна. В качестве системообразующего свойства выберем детерминированность поведения. Поскольку нас изначально интересуют только детерминированные процессы, нарушение детерминации в результате декомпозиции будем считать недопустимым.
М. Бунге настоятельно рекомендует различать агрегат, образованный совокупностью независимых элементов, — его состояние в любой момент времени равно сумме состояний образующих его компонентов, — и систему, состояние которой не аддитивно [12]. Можно сделать вывод, что декомпозиция агрегата тривиальна, поскольку его части не взаимодействуют, а декомпозиция системы не неординарна, поскольку взаимодействующие подсистемы нельзя рассматривать изолированно друг от друга, но только во взаимосвязи.
Содержимое понятия «процесс»
Исследуем содержимое понятия «процесс», воспользуемся моделью Бунге-Ванда-
Вебера [9]. М. Бунге называет процессом историю состояний некоторого объекта, который изменяется под действием трансформаций, инициируемых событиями [13]. Объект может быть простым — неделимым, или комплексным — иметь внутреннюю структуру, в последнем случае он может быть разделен на образующие его элементы. Трансформация понимается как работа, изменяющая объект, она может быть простой или сложной, состоящей из нескольких простых.
Событие отражает факт и момент времени, когда происходит изменение объекта [15]. Событие предполагается дискретным, его длительностью принято пренебрегать. Различают внутренние события, связанные с наблюдаемым объектом, и внешние — связанные с объектом окружения.
Внутреннее событие отмечает момент времени, когда закончилась предыдущая трансформация, — объект готов к исполнению очередной операции. Однако наступления внутреннего события недостаточно для начала исполнения очередной трансформации.
Внешнее событие отражает факт изменения состояния объекта окружения системы, оно инициирует исполнение операции, фиксирует момент времени, когда началась трансформация. Оно не только инициирует выполнение операции процесса, но может прекратить ее, например, если возникла нестандартная ситуация, требующая специальной обработки. Можно говорить, что внешнее событие «управляет» исполнением операции процесса. Внешнее событие можно назвать генерирующим, оно связано с некоторой операцией процесса, которую будем называть обработчиком.
М. Бунге называет два объекта связанными, если изменение одного приводит к изменению другого. Он отмечает, что природа связи у объектов разной физической натуры различна, так что не существует универсального подхода для исследования этой связи [13]. Это побуждает более внимательно исследовать возможное взаимодействие между элементами бизнес-процесса. Мы исключим самопроизволь-
ное изменение информационного объекта, будем считать, что он не подвержен «старению», один информационный объект не может влиять на другой объект, так что трансформация является единственной причиной изменения состояния информационного объекта.
Особенности декомпозиции модели процесса
Необходимо учитывать следующие общесистемные принципы декомпозиции. Разделение системы на подсистемы должно выполняться по определенному основанию. В методологии SADT выделяют следующие стратегии декомпозиции: 1) функциональную, 2) структурную, 3) по этапам жизненного цикла, 4) по физическому процессу [16].
Две последние относятся к темпоральной моде, описывают историю некоторого объекта: одна рассматривает значительные временные интервалы и фиксирует существенные изменения, происходящие в объекте, другая — короткие промежутки и фиксирует любые изменения. Выбор стратегии предопределяет результат, так что функциональная декомпозиция приводит к функциональным моделям, а темпоральная — к процессным [17]. Следует использовать одно основание деления для всех уровней декомпозиции — избрав определенную моду, необходимо придерживаться ее до тех пор, пока исходный объект не будет полностью раскрыт [19]. Использование одновременно нескольких оснований деления недопустимо, так как может привести к пересечению объема понятий или к потере элементов в составе системы. Необходимо обеспечить следующее: а) непрерывность деления — при разбиении делимого необходимо последовательно переходить от уровня декомпозиции раскрытого последним к следующему, не перескакивая к уровням, относящимся к другому порядку; б) бездефектность — каждый нижележащий уровень должен раскрывать предыдущий полностью, не упустив ни одного элемента; в) безызбы-
точность — недопустимо добавлять в ходе деления то, чего в оригинале нет [18].
Вначале рассмотрим процесс, образованный простым неделимым объектом, который изменяется под действием операций, исполняемых в определенном порядке. С процессом целиком и с каждой его операцией связаны внешние события, управляющие исполнением операций. Ограничимся рассмотрением детерминированного процесса, так что состояние объекта в любой момент времени определяется его исходным состоянием и теми операциями, которые его изменяют. В этом случае операции могут исполняться только последовательно, в противном случае мы не сможем указать, результатом какой операции является текущее состояние объекта.
Теперь предположим, что объект является комплексным, может быть разделен на элементы меньшего размера. В этом случае исходный процесс распадается на соответствующее число подпроцессов, каждый описывает историю отдельного субобъекта, при этом операции процесса разделяются так, что каждая связана с соответствующим субобъектом. Аналогично разделяется внешний объект окружения. Таким образом, декомпозиция процесса предполагает разделение информационного объекта на образующие его компоненты, разложение работы на простые операции, разложение событий на элементарные. Рассмотрим эти три декомпозиции по отдельности, обращая внимание на случаи, когда в результате будет нарушена детерминация.
Декомпозиция информационного объекта процесса
Декомпозиция информационного объекта выполняется по функциональному принципу. Если придерживаться общесистемных критериев декомпозиции, следует так разделить исходный объект, чтобы субобъекты были независимы друг от друга — не имели общих (разделяемых) свойств (элементов данных) [20]. Однако при моделировании процессов это условие часто не выполняется,
так что два или более субобъекта имеют общие данные. Это означает, что, изменяя один из них, мы автоматически меняем второй (в части общих для них элементов данных). В результате декомпозиции оба информационных объекта окажутся в разных подпроцессах, в каждом из которых операции исполняются асинхронно, так что возникнет коллизия, когда два подпроцесса одновременно изменяют разделяемый фрагмент данных, так что невозможно определить, результатом какой из операций является состояние информационного объекта в данный момент времени (1А). Будем считать связь, возникающую между двумя подпроцессами, которые обращаются к разделяемому информационному объекту, сильной, поскольку происходит нарушение детерминации.
Чтобы исключить взаимовлияние через разделяемые объекты, подпроцессы следует синхронизировать [21]. Можно предложить не исполнять оба подпроцесса одновременно, а только поочередно. Именно так работают так называемые последовательные процессы [21]. В этом случае детерминация не нарушается, связь между последовательными процессами остается слабой.
Декомпозиция работ, образующих процесс
Рассмотрим различные стратегии декомпозиции работ процесса. Если используется функциональная стратегия, то ее результатом
является функциональная декомпозиция работ (work breakdown structure), другое название — библиотека функций [22]. Результат такой декомпозиции — бездефектная и безызбыточная иерархическая модель, в которой работы на одном уровне иерархии независимы друг от друга. Функциональная декомпозиция — мощное средство для выявления пропущенных, избыточных, дублирующих или ненужных работ процесса [23], однако она приводит к функциональным моделям, тогда как нас интересуют процессные.
При декомпозиции работ используется темпоральная мода декомпозиции, при этом вначале выбирается объект наблюдения, затем рассматривается последовательность операций, изменяющих этот объект. Если каждая работа процесса связана только с одним объектом, причем последний не имеет общих, разделяемых элементов данных, то результирующие подпроцессы окажутся полностью взаимонезависимыми, так что они образуют агрегат, а не систему (рис.
1, Б). Однако часто работы разных процессов могут «пересекаться». Рассмотрим два сценария. В первом случае один объект связан с двумя работами, которые в результате декомпозиции оказались в разных подпроцессах, при этом обе асинхронно изменяют этот объект (рис. 1, В).
Поскольку мы не знаем, в каком порядке выполняются эти операции, детерминация нарушается. Например, поток управления процесса разветвляется на логической опера-
Источник: cyberleninka.ru
Особенности моделирования бизнес-процессов компании
В статье рассмотрены основные виды и подходы к моделированию бизнес-процессов. Приведены рекомендации по декомпозиции процессов компании на подпроцессы.
В предыдущих статьях мы с вами научились выделять и классифицировать бизнес-процессы компании. Следующий шаг на пути внедрения процессного подхода — визуализация моделей бизнес-процессов. Выделяют 3 основным вида моделирования или описания бизнес процессов:
- графический (с использованием различных нотаций моделирования);
- тестовый (словесное описание процессов);
- табличный (составление таблиц входов/выходов).
Сразу хочу отметить, что текстовый и табличный способы, это давно устаревшие, трудоемкие и неудобные средства описания процессов. С развитием современных программно-технических средств моделирования бизнес-процессов графическая визуализация гораздо проще, быстрее и понятнее для конечного пользователя. Например, использование нотации моделирования BPMN 2.0 (Business Process Management Notation) позволяет осуществлять автоматизацию и роботизацию бизнес-процессов, с использованием специализированных средств BPMS (Business Process Management System) или RPA (Robotic Process Automation). Однако о преимуществах и недостатках нотаций моделирования мы поговорить чуть-чуть позже.
Что касается проекта внедрения процессного подхода, то выделяют два основных этапа моделирования бизнес-процессов: моделирование «как есть» и моделирование «как должно быть». Первый этап осуществляется в целях аудита текущей деятельности компании, то есть, проводится анализ того, как функционирует компания, но уже в рамках системы процессов. На этом этапе выделяются основные «узкие места» процессов — области, которые нуждаются в усовершенствовании. Это может быть длительные процедуры согласования, высокая/низкая нагрузка на отдельных специалистов, операции, не несущие конечной ценности, дублирование операций или выходов и многое другое.
Моделирование бизнес-процессов «как должно быть» осуществляется на этапе оптимизации процессов компании. По сути, это идеальное видение протекания процесса с точки зрения его владельца. Полученный графический результат или диаграмма процесса, послужит основой для составления регламентирующей документации.
Итак, давайте разберемся как же происходит моделирование бизнес-процессов. Как я уже раньше говорил, что процесс — это совокупность взаимосвязанных видов деятельности, направленных на преобразование входов в выходы, имеющие ценность для конечного потребителя. Таким образом, схематично процесс можно представить следующим образом — рисунок №1.
Рисунок №1 — Схематичное представление процесса
Первое с чего необходимо начать, так это определить цель процесса. Другими словами, для чего этот процесс предназначен в компании и какую ценность он несет для конечного пользователя. Определив цель процесса, далее приступаем к анализу границ процесса, то есть, каким событием/событиями начинается процесс и каким событием/событиями заканчивается.
Границы процесса определяют зоны ответственности владельцев бизнес-процессов. Определение зон ответственности и точек их передачи (событий инициации и завершения процесса) является ключевой задачей при моделировании бизнес-процессов. Таким образом, вы систематизируете ответственность за конкретные результаты деятельности компании среди владельцев процессов.
Давайте рассмотрим пример того, как будет выглядеть процесс «Продажа» нашей абстрактной компании (рисунок №2).
Рисунок №2 — Схематичное представление процесса «Продажа»
Целью данного процесса является заключение договора с заказчиком и получение выплат денежных средств. Входами является: заказ в личном кабинете интернет-магазина, заявка на закупку, поступившая любыми другими способами (по телефону, по почте и т.д.) и заявка на участие в тендерной процедуре, полученная на тендерной площадке. Выходы: заключенный договор с заказчиком и сформированное задание на производство продукции. Таким образом, мы можем заключить, что за все мероприятия, начинающиеся с получения заявки или заказа до заключенного договора и формирования задания на производство продукции, несет ответственность коммерческий директор компании.
Для упрощения анализа моделей бизнес-процессов лучше всего разделять процесс на подпроцессы, то есть, разбивать одну длинную цепочку на несколько отдельных, но меньшего размера. Данный прием называется декомпозиция процессов. Выделять большое количество подпроцессов не стоит, каждый из них должен быть завершенным. Точно также как у процесса, у подпроцесса есть входы и выходы. По сути, это тот же процесс, только с меньшим количество операций.
Итак, рассмотрим декомпозицию процесса «Продажа». Анализируя входы данного процесса можно выделить следующие виды деятельности: «Безличные продажи», «Личные продажи» и «Продажи на тендерных площадках». Безличные продажи, связаны с работой интернет-магазина, которые осуществляются без личного вмешательства сотрудников коммерческого отдела.
Личные продажи, связанны с непосредственной коммуникацией сотрудников с потенциальным покупателем или заказчиком. Тендерные продажи осуществляются только на специализированных тендерных площадках, в виду особенностей данной процедуры их выделяют в отдельный подпроцесс. Наглядно это можно представить следующим образом (рисунок №3).
Рисунок №3 — Декомпозиция процесса «Продажа» на подпроцессы
По факту, конечно, выходов у процесса «Продажа» всего два, но они могут быть результатом деятельности трех подпроцессов, поэтому на рисунке их шесть. У подроцесса также есть владелец, который отвечает за реализацию подконтрольного вида деятельности. Например, у подпроцесса «Безличные продажи» владельцем может выступать начальник отдела интернет-продаж, «Личные продажи» — коммерческий директор, «Продажи на тендерных площадках» — начальник тендерного отдела. Важно отметить, что декомпозировать можно только процессы, не стоит дробить подпроцессы на операции и выделять у них владельцев.
Особенности графического представления бизнес-процессов компании в различных нотациях моделирования рассмотрим в следующих статьях.
Источник: dzen.ru
Теоретические сведения о шаблонах моделей управления бизнес-процессом
В соответствии с требованиями международных стандартов ИСО 9000—2000, 9001—2001 и 9004——2001, для организации системы постоянного улучшение процессов организации необходимо использовать циклы PDCA (Plan – планировать; Do – выполнять; Check – контролировать; Act – активное вмешательство в ход процесса) Деминга. Эти циклы управляют всей сетью процессов организации. В свою очередь, система управления тоже представляет собой сеть вложенных друг в друга циклов PDCA, с верхнего до нижнего уровня управления. Причем циклы PDCA процессов нижнего уровня входят в цикл PDCA процесса верхнего уровня. Таким образом, все процессы организации связаны между собой вложенными циклами PDCA.
Из четырех функций цикла PDCA, владелец процесса выполняет три функции PCA (Plan, Check и Act). Функцию Do выполняют подчиненные подразделения и сотрудники. Поэтому при разработке сети процессов возникает вопрос правильного графического отображения вложения всех циклов PDCA в рамках сети процессов организации.
Для решения этого вопроса можно использовать два типовых шаблона описания циклов PDCA.
На рис. 2.1 представлена схема декомпозиции (в нотации IDEF0) исходного цикла PDCA верхнего уровня управления организации по шаблону № 1. Штриховыми линиями показаны декомпозируемые блоки и их состав. Как видно из рисунка 1, шаблон № 1 начинается с исходного цикла PDCA, который состоит из двух базовых блоков, входящих в состав контур управления процессом:
Ø объект управления, состоящий из функции Do;
Ø система управления, включающая три функции PCA.
Блок PCA выполняется владельцем процесса PDCA, и, как показано на рисунке 2.1, состоит из функций Plan, Check и Act. Объект управления, состоящий из функции Do (рис. 1), включает в себя несколько подпроцессов PDCA1, PDCA2 и PDCA3, которые выполняются подчиненными подразделениями организации. Каждый из этих подпроцессов также подразделяется на два блока, как и цикл верхнего уровня PDCA:
Ø объект управления, состоящий из функции Do1;
Ø система управления, включающая три функции PCA1.
Аналогично, блок Do1 декомпозируется на подпроцессы PDCA1.1, PDCA1.2 и PDCA1.3. Эти подпроцессы опять разбиваются на два блока.
Например (рис. 2.1), блок PDCA1.1 декомпозируется на два блока:
Ø объект управления, состоящий из функции Do1.1;
Ø система управления, включающая три функции PCA1.1.
В свою очередь блок PCA1 разбивается (на рис. 1 не показано) на блоки Plan1, Check1 и Act1. Такое дробление процессов производится без ограничений до нижнего уровня процессов организации.
Рассмотрим другой способ декомпозиции цикла PDCA (рис. 2.2) по шаблону № 2. В этом случае исходный цикл PDCA верхнего уровня управления декомпозируется на четыре процесса: Plan, Do, Check и Act. Из них, процессы Plan, Check и Act управляются владельцем процесса, а процесс Do выполняется подчиненными подразделениями. Соответственно, процесс Do декомпозируется на процессы PDCA1, PDCA2 и PDCA3.
Каждый из этих процессов, по аналогии с верхним процессом, разбивается опять на четыре процесса. Например (рис. 2.2), процесс PDCA1 разбит на вложенные процессы Plan1, Do1, Check1 и Act1.
При дальнейшей декомпозиции, например процесс Do1, разбивается на подпроцессы PDCA1.1, PDCA1.2 и PDCA1.3. Подобным образом, декомпозиция процессов может производиться без ограничений, пока не будет достигнут нижний уровень процессов организации.
Таким образом, шаблоны 1 и 2 позволяет графически описать сеть процессов организации и встроенную систему управления любой степени сложности.
Преимущество шаблона № 1 заключается в том, что при двухблочной декомпозиции, в одном блоке концентрируются функции управления владельца процесса, а в другом блоке — функции его подчиненных. Модель сети процессов в наибольшей степени соответствует классической теории управления процессами. Диаграммы процессов простые и технически не трудоемкие. Пример формирования вложенных циклов PDCA по шаблону №1 в нотации IDEF0 приведен на рисунках 2.3 – 2.9.
Шаблон № 2 состоит из четырех базовых блоков, напрямую соответствующих функциям цикла PDCA. Преимущество шаблона № 2 заключается в том, что он наиболее прост для понимания, но технически более трудоемок, т.к. на диаграммах процессов смешаны функции управления и выполнения процесса. Пример формирования вложенных циклов PDCA по шаблону №1 в нотации IDEF0 приведен на рисунках 2.10 – 2.15.
Пример декомпозиции по шаблону №1 бизнес-процесса с расширенной функциональностью блока управления, приведен на рисунках 2.16-2.19.
Рис. 2.1. Схема цикла PDCA по шаблону №1
Рис. 2.2. Схема цикла PDCA по шаблону №2
Рис. 2.3. Диаграмма А-0 цикла PDCA по шаблону №1
Рис. 2.4. Диаграмма А0 цикла PDCA по шаблону №1
Рис. 2.5. Диаграмма А1 цикла PDCA по шаблону №1
Рис. 2.6. Диаграмма А2 цикла PDCA по шаблону №1
Рис. 2.7. Диаграмма А2.1 цикла PDCA по шаблону №1
Рис.2.8. Диаграмма А2.1.2 цикла PDCA по шаблону №1
Рис.2.9. Диаграмма А2.1.1 цикла PDCA по шаблону №1
Рис.2.10. Диаграмма А-0 цикла PDCA по шаблону №2
Рис.2.11. Диаграмма А0 цикла PDCA по шаблону №2
Рис.2.12. Диаграмма А2 цикла PDCA по шаблону №2
Рис.2.13. Диаграмма А2.1 цикла PDCA по шаблону №2
Рис.2.14. Диаграмма А2.1.2 цикла PDCA по шаблону №2
Рис.2.15. Диаграмма А2.1.2.1 цикла PDCA по шаблону №2
Рисунок 2.16. Пример бизнес-процесса с расширенной функциональностью блока управления. Диаграмма А-0
Рисунок 2.17. Пример бизнес-процесса с расширенной функциональностью блока управления. Диаграмма А0. Бизнес-процесс декомпозирован на два блока: «управлять» и «исполнять»
Рисунок 2.18. Пример бизнес-процесса с расширенной функциональностью блока управления. Диаграмма А1. Блок управления декомпозирован на шесть типовых подпроцессов управления
Рисунок 2.19. Пример бизнес-процесса с расширенной функциональностью блока управления. Диаграмма А2. Блок исполнения декомпозирован на пять подпроцессов
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru