Диссертация (1152223), страница 70
Текст из файла (страница 70)
Результатом функциональной декомпозиции является модель деятельности, тогда как процессная модель требует использования декомпозиции по процессу. Обосновано, что в результате многократной функциональной декомпозиции работ бизнес-процесса, теряется логическая связь,описывающая очерёдность исполнения работ, восстановить утерянную связь затруднительно,что объясняет трудности, возникающие при переходе от справочной модели к процессной.Практическая ценность результата заключается в рекомендациях аналитику создавать функци-270ональную модель деятельности параллельно с процессной моделью бизнес-процесса.
Работа сдвумя моделями помогает аналитику: (а) легко выявлять на процессной модели дублирующиеоперации и функции; (б) использовать в рамках одной модели работы, имеющие сходный уровень детализации; (в) выявлять в процессе повторно используемые компоненты; (г) осуществлять генерализацию модели, заключающуюся в выявлении работ процесса, сходства которыхважнее незначительных отличий, которые можно «спрятать» на нижнем уровне детализации.Предложен метод моделирования организационного взаимодействия участников бизнеспроцесса, отличающийся тем, что: (1) выделены типовые операционные и организационныефункции участников; (2) систематизированы их операционные и организационные полномочия;(3) разработан типовой шаблон взаимодействия сотрудников структурного подразделения компании; (4) предложены абстрактные роли участников, позволяющие не привязывать типовойшаблон к конкретной штатной структуре; (5) разработан алгоритм выбора потенциальных кандидатов и актуального исполнителя операции процесса, особенностью которого является последовательное сужения круга кандидатов, что позволяет учесть все возможные бизнес ограничения и реализовать его в среде нотации BPMN 2.0.
Особенностью предлагаемого метода, является то, что он основывается на ролевой модели управления доступом, а не на пооперационноймодели управления доступом, как прочие методы. Его значимость метода заключается в том,что он позволяет описать организационное взаимодействие участников бизнес-процесса в модели, а не в программном коде, внедрённом в исполняемую модель бизнес-процесса, благодарячему исполняемая модель бизнес-процесса не теряет свойства моделеориентированности.Методологическая значимость результата заключается в том, что проведена гармонизацияпонятийного аппаратов процессного управления и теории организационного менеджмента, систематизированы и унифицирована базовые термины. Для базовых понятий организационногоменеджмента разработан способ их реализации в модели бизнес-процесса и найдена точка привязки к модели.
Это позволяет аналитику, который выполняет моделирование бизнес-процесса,однозначно понимать представителя бизнеса, который занимается проектированием организационной структуры предприятия.Разработан метод отображения ролевой перспективы модели бизнес-процесса на организационную структуру компании, отличающийся тем, что роль участника рассматривается в качестве промежуточного логического слоя модели процесса, который связывает диаграмму потоков работ и организационно-штатную структуру компании, что делает модель процесса инвариантной изменениям штатного расписания или распределения ответственности.
Показано, чтосуществующая сегодня практика подмены роли должностью, названием организационногоподразделения или именем сотрудника делает модель не гибкой, привязывает её к конкретнойорганизационной структуре;271Предложена авторская концепция интегрированной исполняемой модели бизнес-процесса, которая состоит из нескольких взаимосвязанных субмоделей, называемых перспективами, каждая из которых отображает отдельные аспекты структуры процесса, а все вместе ониспособны отобразить динамику его поведения, отличающаяся набором перспектив и их аспектов, а также тем, что связями между одноименными элементами на разных моделях, образующих эти перспективы, реализуются на уроне данных, а не на уровне ссылок;272ГЛАВА 5ПРОВЕРКА КОРРЕКТНОСТИ ИСПОЛНЯЕМОЙ МОДЕЛИБИЗНЕС-ПРОЦЕССА5.1Проблема выявления ошибок в модели бизнес-процессаИзвестно, что поиск и выявление допущенных ошибок на стадии моделирования оказывается значительно дешевле и экономичнее, чем на поздних этапах разработки или внедрения.Интересные цифры приводит Б.
Боэм: если принять за единицу стоимость выявления ошибкина этапе проектирования, то её исправление на стадии разработки будет стоить в 3,5 раза дороже, на стадии внедрения цена возрастает в 50 раз, а на стадии эксплуатации в 170, как показано на рисунке 5.1 [297]. Поэтому вопросы выявления ошибок в модели процесса на раннемэтапе стоят очень остро.Стоимость17010050501ПроектированиеВремя3,5РазработкаВнедрение ЭксплуатацияЭтап создания ИСРисунок 5.1 - Стоимость исправления ошибки на разных этапах создания ИСИсточник: составлено автором по материалам [297]Верификация и валидация модели бизнес-процессаВалидация — проверка истинности, подтверждение того, что требования, предназначенные для конкретного использования или применения, выполнены, она гарантирует, что системаспособна выполнять заданные функции в соответствии с установленными целями и назначением в конкретных условиях функционирования [298].
Валидация демонстрирует, что процессобладает повторяемостью и приводит к ожидаемым результатам, следовательно, удовлетворяет273потребителя. Мы будем понимать валидацию, как процедуру подтверждения того, что модельсоответствует пользовательским (функциональным) требованиям (см. п.
3.2.6.).Верификация есть процедура подтверждения того, что соблюдены особые требования,предназначенные для конкретного применения [298]. Верификация показывает, что система создана «правильно», не содержит ошибок и соответствует техническим условиям.
Верификациясообщает о потенциальных ограничениях на проектные решения. Мы будем понимать верификацию, как процедуру поиска возможных ошибок, которые сделают невозможным исполнениеданного процесса. Например, в главе 2 мы определили условие нормального завершения процесса. Если условие не будет выполнено, исполняемая модель содержит ошибки, которые препятствуют нормальному завершению процесса.Верификация модели заключается в проверке её адекватности. Верификация модели, организованной в виде вычислительной программы для компьютера, заключается в исправленииошибок в её записи на алгоритмическом языке. Валидация модели производится тогда, когдаэкспериментатор убедился на предшествующей стадии (верификации) в правильности структуры (логики) модели [120].Проблема завершаемости бизнес-процессаИсполняемая модель бизнес-процесса подобна программе.
Как отмечают Кларк Э., Грамберг О., Пелед Д., «наблюдаемое поведение модели является с точки зрения субъекта, осуществляющего моделирование (полагающего, что модель адекватна), предполагаемым поведением реальной системы» [180]. Очевидно, что в общем случае наблюдаемое поведение реальной системы и её ожидаемое поведение могут различаться.Исполняемые модели бизнес-процессов, как и программы, нуждаются в доказательствебездефектного завершения. Единожды стартовав, процесс должен завершиться за конечноечисло шагов, для этого — не содержать ловушек, тупиков и бесконечных циклов. Вопросы анализа бездефектного завершения является очень актуальным, поскольку сложность моделей постоянно возрастает, а встроенные в среду моделирования средства проверки пока являются далеко не совершенными. Поэтому основная нагрузка по отладке модели ложится на аналитика,который не имеет достаточной математической подготовки, чтобы анализировать процесс инженерными методами [186].Поставим цель — обосновать способы отображения модели процесса в нотации BPMN вСП, выявить свойства модели процесса, важные для дальнейшего анализа, осуществить анализбездефектного завершения процесс с помощью структурных методов анализа СП.274Коллизии в моделях бизнес-процессовМодель бизнес-процесса в нотации BPMN может иметь ошибки, приводящие к отказу илизатруднению её исполнения.
К числу отказов относятся: (а) тупик, (б) мёртвая зона, (в) генератор маркеров, (д) ловушка; (е) висячие и оборванные цепи, (ж) множественный старт, (з) множественный финиш [208]. Будем различать: структурные и поведенческие ошибки. Первыепроявляются при любых сочетаниях данных, вторые только при определённых комбинациях.Известно, что логические операторы ветвления и слияния «И» и «ИЛИ» по отдельности имеютпростое и детерминированное поведение, но будучи объединены в определённые последовательности, называемые «процессными паттернами», могут создавать конструкции, приводящиек коллизиям. Набор паттернов, возникающих при моделировании оркестровки бизнеспроцессов, описан и размещён на сайте www.workflowpatterns.com последовательностей (описание паттернов на русском см.
[140]). В первоначальном виде этот материал касался в первуюочередь систем workflow, затем был адаптирован для BPMN 1.0. Авторы проанализировали работу большинства доступных workflow систем, выделили типовые ситуации и обобщили их ввиде типовых. Проанализируем паттерны, описывающие ошибки исполнения.Рассмотрим первый пример, изображённый на рисунке 5.2. В результате первого ветвления на ЛО «ИЛИ» поток управления будет направлен в одну из альтернативных ветвей Б1 илиБ2.
Однако ЛО слияния «И» ожидает поступления сигналов из обоих ветвей, образуется тупиковая ситуация, операция В не выполняется ни при каких условиях.Б1ВАБ2Рисунок 5.2 - ТупикИсточник: составлено автором.Рисунок 5.3 показывает пример, изображающий пару логических операторов ветвления ислияния «И», причём в одной из альтернативных ветвей размещён ЛО ветвления «исключающее ИЛИ». В результате первого ветвления «И» возникнут два потока, направленные на операции Б1 и Б2.
После завершения операции Б1 выходной поток поступает на ЛО «исключающееИЛИ». Если выполняется Условие1, то следующей будет исполнена операция Г, так что потокиз этой ветви не поступит на вход узла слияния «И». Поскольку узел слияния «И» будет ожидать появления двух стоков, возникает тупиковая ситуация (DEAD LOCK).275Условие1ГБ1АВБ2Рисунок 5.3 - Мёртвая зонаИсточник: составлено автором.Третий пример, изображённый на рисунке 5.4, показывает модель, где ЛО «И» осуществляет ветвление на параллельные потоки, а ЛО слияния «исключающее ИЛИ» пропустит на выход поток из каждой параллельной ветви. В результате операция В будет выполнена столькораз, сколько параллельных ветвей приходит на узел слияния.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
