Диссертация (1152223), страница 57
Текст из файла (страница 57)
При этом на этапе оформления доставки к ним будут добавлены изделия, которые были заказаны ранее по-другому заказ, имеет место перегруппировка потоков заявок. Исходный заказ будет закрыт, когда все изделия, сгруппированные в разные посылки, доставлены заказчику. В этом примере происходит многократнаяперегруппировка потоков управления, что приводит к дроблению основного процесса, так чтоможно выделить три подпроцесса, но соотношение входов и выходов — одному заказу соответствует несколько посылок заказчику. Таким образом, чтобы обнаружить фрагментацию процесса,аналитик должен внимательно следить за основным информационным объектом, через которыйпередаются результаты между этапами.
Смена основного информационного объекта является218сигналом, что фрагментация возможна. Затем аналитик должен проанализировать отдельные потоки управления. Перегруппировка потоков приводит к фрагментации, процесс разделяется нацепочку взаимодействующих подпроцессов. Таким образом, смена объекта управления есть достаточное условие разделения процессов, а перегруппировка —необходимое.Б) Несколько объектовуправления– несколькоподпроцессов123Подготовитьдеталь 1Отправитьзаказ 1Подготовитьдеталь 2ОформитьзаказЗакрыть заказПодготовитьдеталь 2Отправитьзаказ 2Подготовитьдеталь 3ЗаказНакладнаяСчет12Акт3Рисунок 4.9 - Деление и перегруппировка потоков управленияИсточник: составлено автором.Примеры деления процесса на подпроцессыДавайте рассмотрим «типичный пример» процесса заключения договора в нотации BPMN[209].
Этот пример имеет две точками старта, причём некоторые ведут в середину процесса инесколько завершающих событий, причём некоторые находятся в середине процесса. Мы можем заметить, что сквозной процесс имеет два объекта управления: коммерческое предложениеи договор, как показано на рисунке 4.10. Таким образом внимательный аналитик увидит сменуобъекта управления и предположит, что сквозной процесс распадётся на два подпроцесса: «Согласовать коммерческое предложение» и «Заключить договор.
В подтверждение обратим внимание, промежуточные точки старта и завершения соответствуют границам подпроцессов.Еще не принятоПодготовитькоммерческоепредложениеКлиент проситкоммерческоепредложениеОтправитькоммерческоепредложениеСправиться орешенииКонтрольныйсрокКлиент просит заключить договорРешение?ДаЗаключитьдоговорЗаключен?Договор заключенНетКоммерческое предложение не устраиваетДоговор не заключенРисунок 4.10 - Сквозной процесс: от заявки до договораИсточник: составлено автором.Этапы исполнения процессаМы разделили сквозной процесс на подпроцессы, ориентируясь на смену объекта управления.
Получившиеся в результате подпроцессы могут оказаться достаточно большими, так что может возникнуть потребность повторно декомпозировать их на более мелкие фрагменты. Без потери219общности будем считать, что у процесса, есть только один объект управления. Рассмотрим алгоритм разбиения, для этого выделим основные этапы жизненного цикла объекта управления.В качестве следующего примера, иллюстрирующего предлагаемый подход, рассмотримбизнес-процесс «присуждение Нобелевской премии», взятый из альбома типовых моделей внотации BPMN, опубликованного OMG, показанный на рисунке 4.11 [261].
В этом процессеможно выделить следующие объекты управления:Объявление о начале кампании по сбору заявок на номинацию;Заявка на номинацию, каждая заявка может содержать имена нескольких кандидатов;Список отобранных кандидатов на присуждение премии, один на всех номинантов;Запросы экспертам, по каждому кандидату из списка в отдельности;Отчет по списку кандидатов, содержащий заключение по каждому номинанту;Результат голосования по списку, определяет одного лауреата премии;Анализ модели показывает, что по ходу исполнения происходит многократная смена объ-ектов и перегруппировка потоков управления. В ответ на одно объявление происходит сбор заявок, их число меняется из года в год.
Каждая заявка может включать несколько кандидатов, ихколичество заранее не известно. После отбора часть кандидатов попадёт в список номинантов,его размер зависит от обстоятельств. Это означает, что соотношение между объявлением о выдвижении кандидатов, числом заявок на выдвижение, количеством запросов на экспертизу заранее не известно. На модели следует выделить подпроцессы: «объявить о сборе заявок», «собрать заявки», «провести экспертизу кандидатов».Основной процесс, Объявление о начале кампании по сбору заявок на номинациюПодпроцесс, Выбор лауреатаПодпроцесс, Номинация претендентаПодпроцесс, Запрос экспертамПодпроцесс, Приглашение лауреатаРисунок 4.11 - Декомпозиция бизнес-процесса «присуждение Нобелевской премии»Источник: составлено автором по материалам [261].220Научная новизна и практическая ценность метода проектирования архитектуры модели бизнеспроцессовНаучная новизна исследования заключается в разработке архитектурного метода декомпозиции исполняемой модели бизнес-процесса, где в качестве необходимого условия разбиениясквозного бизнес-процесса на цепочку взаимодействующих подпроцессов рассматриваетсясмена объекта управления процесса, а в качестве достаточного условия выступает перегруппировка потоков управления, отличающийся от используемого сегодня метода структурированияпроцесса по организационным подразделениям предприятия, благодаря чему разбиение не зависит от организационной структуры предприятияТеоретическая значимость полученного результата заключается в том, что предложенныйметод соответствует критериям правильной декомпозиции модели бизнес-процесса, которыебыли разработанным на основе анализа онтологической модели Бунге-Ванда-Вебера, впервыесформулированы необходимое и достаточное условия разделения сквозного процесса на подпроцессы.Практическая ценность результата заключается в том, что предлагаемые критерии выделения подпроцесса являются объективно наблюдаемыми и измеримыми, что исключает субъективность при их применении.
Благодаря использованию предложенного архитектурного метода, аналитик сможет разделить процесс на подпроцессы единственно возможным образом.4.4Метод выявления логики бизнес-процессаЛюбая инициатива по реорганизации бизнеса начинается с анализа процессов компании.Но если процессы ещё не формализованы, то их надо выявить и построить соответствующиемодели. Выявление процесса — это процедура, направленная на обнаружение способов исполнения какой-либо деятельности с целью построение модели бизнес-процесса.
Бытует мнение,что процесс можно выявить методом снизу-вверх, интервьюируя участников [262]. Такой способ достался нам в наследство от производственных процессов, имеющих линейную, последовательную структуру. Таким образом, налицо противоречие, разработку ИТ решений принятопроводить сверху вниз, на пример методология SADT, тогда как выявление процессов принятопроводить сверху вниз, например, метод ARIS, как показано на рисунке 4.12.Однако, логика бизнес-процессов имеет сложный алгоритм, немудрено, что проектирование модели процесса методом снизу-вверх приводит к запутанным и трудно читаемым схемам[263]. Выявление процесса снизу-вверх включает: опрос участников, сбор исторических дан-221ных, затем из многочисленных и зачастую избыточных деталей синтезируются процессы иподпроцессы [62].
Поскольку процедура синтеза не формализована, каждый аналитик использует собственные приёмы и методы, так что моделирование становится ремеслом, тогда как задача требует инженерного решения. Модели, построенные снизу-вверх, имеют множество недостатков: перегружены деталями и трудно понятны [264]. Считается, что сложность есть свойство конкретных нотаций, но это неверно, запутанность есть следствие отсутствия методикимоделирования. Большинство моделей вряд ли можно назвать полными, поскольку они описывают отдельные наиболее очевидные маршруты, по которым исполняется наибольшее числопроцессов, забывая, что в реальности сценарий более сложный.
Часто модели не точны, не достигают нужного уровня детализации. В функционально ориентированных системах, где человек играет активную роль, а ИТ система — подчинённую, пропуск сценария на этапе моделирования или недостаточная точность модели не являются критичными, т.к. человек определяетпорядок исполнения. Но в процессно-ориентированной системе маршрут обработки заранееопределен, пропуск сценария или недостаточная точность недопустимы, исполнение процессаокажется невозможным.Рисунок 4.12 - Разработка ИТ решений и выявление бизнес-процессовИсточник: составлено автором.Цель исследования — представить бизнес аналитику пошаговую методику действий, которая поможет выявить модель процессов методом сверху вниз, найти и зафиксировать все варианты исполнения.
Полученная диаграмма процесса будет иерархической, где верхний уровень даст концептуальное представление о процессе и его окружении, а нижний уровень опишет детали, важные для исполнения. В рамках настоящей работы мы рассмотрим только выявление и моделирование бизнес логики процесса, но не будем выявлять роли и участников процесса. Договоримся рассматривать только изолированный процесс, который не взаимодействует с другими процессами, это позволит не рассматривать вопросы процессной хореографии.Точность модели потоков работТочностью модели принято называть степень совпадения полученных в процессе моделирования результатов с заранее установленными, желаемыми [201]. Примем во внимание, что222модель потоков работ относится к классу структурных, она показывает состав системы и связимежду образующими её элементами [265].
При данном типе моделировании, точность определяется структурным подобием между оригиналом и моделью, степенью совпадения связеймежду элементами. В качестве элементов структуры мы будем рассматривать работы, образующие процесс. Связями между этими элементами являются переходы управления между работами процесса. Последовательность переходов управления называется сценарием выполнения.Таким образом, мы можем определить точность модели, как её способность передать все возможные работы, образующие процесс, а также, изобразить все допустимые сценарии исполнения процесса.К сожалению, вопросы точности моделей потоков работ остаются вне внимания бизнесаналитиков.
Если проектируется функционально ориентированная информационная система,перед аналитиком ставится задача выявить все функции, выполняемые этой системой, однакоему не ставится задача выявить все допустимые сценарии исполнения. Таким образом, получаемая модель включает те же элементы, что и оригинал, однако некоторые связи (переходыуправления) могут отсутствовать. При проектировании процессно-ориентированных системставится задача выявить все возможные сценарии исполнения. Таким образом, в случае проектирования СУБП вопрос точности модели оказывается принципиально важен.
Рассмотрим подходы выявления сценариев исполнения процесса.Метод выявления логики исполнения бизнес-процессаДля выявления вариантов использования (use case) А. Кобэрн предложил находить нормативный маршрут, затем добавить все отклонения от этого маршрута [266]. Цель абсолютно правильная, однако метод выявления основного и дополнительных сценариев не ясен. Во-первых,не вполне корректно определять нормативный маршрут, как наиболее короткий путь достижения цели процесса, например, отказ в выдаче кредита есть кратчайший путь, но вряд ли егоможно назвать основным сценарием. Во-вторых, рекомендация «выделить нормативный сценарий, определить типичный ход событий, линейную последовательность шагов, наиболее быстроприводящую главное действующее лицо к цели», хотя и является правильной, но остаётся малополезной, автор не объясняют, как добиться результата.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
