Диссертация (1152223), страница 64
Текст из файла (страница 64)
Стильworkflow предполагает изображать на диаграмме процесса в основном операционные обязанности исполнителя, а его организационные обязанности и полномочия не моделируются на схеме,но программируются. В определённой степени — это обоснованно, модель процесса верхнегоуровня описывает, что нужно сделать, показывает только отельные варианты исполнения процесса, имеет детализацию уровня операций, не опускается до деталей организационного взаимодействия, что делает её более простой для понимания.
Поскольку паттерны организационного взаимодействии не показываются на схеме, они программируются. Стиль СУБП предполагает отображать на диаграмме процесса операционные обязанности и полномочия, организационные обязанности, так что программированию подлежат в основном организационные полномочия исполнителя.Научная новизна и практическая ценность метода моделирования организационноговзаимодействияНаучная новизна результатов исследования определяется тем, что предложен метод моделирования организационного взаимодействия участников бизнес процесса, отличающийся тем,что: (1) выделены типовые операционные и организационные функции участников; (2) система-246тизированы их операционные и организационные полномочия; (3) разработан типовой шаблонвзаимодействия сотрудников структурного подразделения компании; (4) предложены абстрактные роли участников, позволяющие не привязывать типовой шаблон к конкретной штатнойструктуре; (5) разработан алгоритм выбора потенциальных кандидатов и актуального исполнителя операции процесса, особенностью которого является последовательное сужения кругакандидатов, что позволяет учесть все возможные бизнес ограничения и реализовать его в среденотации BPMN 2.0.
Особенностью и характерным отличием предлагаемого метода, является то,что он основывается на ролевой модели управления доступом, а не на пооперационной моделиуправления доступом, как прочие методы.Практическая значимость предложенного метода заключается в том, что он позволяетописать организационное взаимодействие участников бизнес-процесса в модели, а не в программном коде, внедрённом в исполняемую модель бизнес-процесса, благодаря чему исполняемая модель бизнес-процесса не теряет свойства моделеориентированности.Методологическая значимость результата заключается в том, что проведена гармонизацияпонятийного аппаратов процессного управления и теории организационного менеджмента, систематизированы и унифицирована базовые термины.
Это позволяет аналитику, который выполняет моделирование бизнес-процесса, однозначно понимать представителя бизнеса, который занимается проектированием организационной структуры предприятия. Для базовых понятий из области организационного менеджмента указан способ их реализации в модели бизнеспроцесса и найдена точка привязки к модели.4.6Метод отображения ролевой перспективы модели бизнес-процесса наорганизационную структуру компании моделирования ролей бизнес-процессаВ практике бизнес информатики широко применяется процессно-ролевая модель. Прианалитическом моделировании ролевая модель должна визуально отобразить распределениеобязанностей между участниками процесса, в исполняемой модели, кроме того, определить ихправа доступа к объектам системы.
Однако ролевая модель обладает рядом особенностей, которые необходимо учитывать при моделированииЦелью данного исследования является формулирование принципов разработки ролевоймодели бизнес-процесса. В первой части мы обсудим аспект распределения работ между исполнителями, во второй — разделение доступа к объектам системы.247Ролевая модельВ бизнес-информатике получила широкое распространение процессно-ролевая модельГ.Раммлера и А. Брэйча [282]. Они предложили изображать на диаграмме процесса дорожки,группирующие пользователей по работам, которые те должны выполнить. Дорожкам даётсяимя, позволяющее однозначно идентифицировать соответствующую категорию исполнителей.Аналитики часто смешивают роль с функцией или группой исполнителей.
Рассмотрим, в чемзаключаются их отличия.Функция есть работа, которую обязуется выполнить субъект, а роль — это круг субъектов, которым может быть поручена данная работа. На лицо различие обоих понятий и их очевидная взаимосвязь. Группа есть совокупность пользователей, объединённых общим признаком. Например, в группу можно собрать сотрудников некоторого подразделения или работников обладающих определённой квалификацией и пр. Поскольку квалифицирующее свойствоприсуще самому субъекту, состав группы изменится, если поменяется штатный состав или характеристики субъекта.
Роль так же можно рассматривать как группировку, где в качестве критерия отбора выступает исполняемая участниками функция. До тех пор, пока состав функцийпроцесса не изменяется, номенклатура ролей остаётся неизменной.Иерархии ролейОдна роль может включать много сотрудников и несколько операций, а один сотрудникможет быть участником многих ролей. Предложим разделять простую роль, которой соответствует одна функция, и составную роль, включающую несколько операций. Составную роль легко представить в форме иерархии, в которой участники верхнего уровня могут выполнить всеоперации ролей нижнего уровня (наследовать обязанности), а нижнего — только свою. Количество уровней не ограничивается. Пример изображённый на рисунке 4.19 показывает составнуюРоль А, которая объединяет две простые роли.РольAРоль1Роль2Операция 1Операция 2Рисунок 4.19 - Иерархия ролейИсточник: составлено автором.Иерархию ролей можно построить двумя способами, методом синтеза — снизу-вверх илипутём декомпозиции сверху вниз.
Рассмотрим декомпозицию, планирование любой деятельности начинается с функциональной декомпозиции работ (work breakdown structure), при этом всефункции, образующие процесс, связываются в структуру типа дерево. Можно образовать груп-248пы участников в соответствии с полученной иерархией функций, мы автоматически получимдревовидную ролевую модель. Полученная иерархия не повторяет организационную модель, аопределяется деревом функций моделируемого процесса.Способы формирования ролейРассмотрим основные способы формирования ролей. Наиболее просто привязать роль кконкретным пользователям, например, указать, что работу выполняет определённый сотрудник.Но что делать, если пользователи уволятся или перейдут работать в другое подразделение.
Этотспособ находит применение только в организациях небольшого размера.Второй способ предполагает привязку роли к должности работника. Первоначально методкажется удобным, поскольку, чтобы занять должность, сотрудник должен удовлетворять соответствующим квалификационным требованиям. К сожалению, метод обладает рядом недостатков. Если одну операцию могут выполнять сотрудники в разных должностях, мы не сможемизобразить это на схеме.
А если изменится распределение работ, модель процесса придётсякорректировать. Рассмотрим пример, изображённый на рисунке 4.20, процесс включает двеоперации, исполняемые сотрудниками в разных должностях. Если, изменится штатное расписание, операция, выполнявшаяся ранее последним сотрудником, теперь станет функцией другой должности, модель придётся изменить.Должность1Должность2Операция 1Операция 2Изменилосьраспределение работДолжность1Должность3Операция 1Операция 2Рисунок 4.20 - Изменение штатного расписания приводит к изменению моделиИсточник: составлено автором.Третий способ предполагает привязку роли к соответствующему организационному подразделению компании, так что выполнить операцию сможет любой сотрудник.
При этом, модель не показывает реальное распределение работ внутри подразделения. Кроме того, возникнут проблемы, если операцию могут выполнить сотрудники разных подразделений. Наконец, вслучае изменения организационно штатного расписания, ролевую модель придётся изменять.Часто иерархию ролей пытаются рассматривать как способ реализации организационнойструктуры управления компании [283]. При этом используется одновременно привязка к должности и к организационному подразделению. Например, вводится роль «начальник подразделения», включающая все роли всех сотрудников, что позволяет руководителю выполнять функции своих подчинённых.
Модель показывает распределение работ, но оказывается привязаннойк конкретной организационной структуре, как изображено на рисунке 4.21.249Начальник подразделенияДолжность 1Должность 2Рисунок 4.21 - Должность в качестве ролиИсточник: составлено автором.Очевидно, что аналитику удобно ассоциировать роль c понятиями организационно штатного расписания, однако в случае его изменения, модель придётся корректировать, что недопустимо. Следует стремиться к ролевой модели, которая инвариантна к изменению организационной структуры.Следует остерегаться использовать на схеме процесса разные способы формирования ролей. Если в рамках модели одного процесса распределение ответственности ещё можно отследить, то в рамках большого проекта, включающего несколько процессов, ролевая структураокажется неуправляемой.Роль — логический уровень модели процессаРоль следует рассматривать как логический слой модели, инвариантный к изменению еёорганизационной структуры.
Роль не должна быть связана с должностью, например, руководитель и его подчинённый могут иметь право выполнить одну операцию. Точно так же она непривязана к структурному подразделению, например, исполнить работу могут члены рабочейгруппы, работающие в разных отделах. Она не зависит от территориального расположения исполнителя, например, инициировать процесс может как сотрудник территориального подразделения, так и работник центрального офиса. Роль не привязана к квалификации или иными свойствами субъекта — одну и ту же работу можно поручить сотрудникам с разным опытом.Изначально роль рассматривалась как абстрактное обозначение исполнителя, которомуможет быть поручена работа. Представим себе операцию «оформить заявку», которая принадлежит абстрактной роли «Оформитель», которая не является именем собственным исполнителя,названием структурного подразделения или должностью.