Типовые роли сотрудников в системе управления бизнес процессами

Введение

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

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

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

Семантика. Определение

Слово роль происходит от фр. role — роль, список, свиток, из лат. rotulus — бумажный свиток (для актеров), далее из rota — колесо, из праиндоевропейского корня rot — катить (Источник — словарь М. Фасмера). Обратимся к семантике слова (заимствовано из ru.wikitionary.org).

1. Перен. деятельность, образ действий, манера держать себя. — Как изменилася Татьяна! Как твердо в роль свою вошла. А. С. Пушкин;
2. Значение, род и степень участия в каком-либо деле, предприятии, событии. — Ленин правильно указал путь борьбы рабочего класса, определил его роль, как передовой революционной силы общества, определил роль крестьянства, как союзника рабочего класса. История ВКП(б) — Ему принадлежит большая роль в этом деле. — Блестящая роль в жизни;
3. Комп. набор функций для выполнения определённого круга задач, назначаемый серверу.

Практическое использование

Обратимся к практике бизнеса. Рассмотрим цепочку образования сущности «роль» в процессном подходе к моделированию бизнес-процессов.

Рис. 1. Схема образования сущности «Роль»

Исходя из приведенной на рисунке 1 схемы, мы будем определять роль как совокупность компетенций, обладая которыми участник бизнес-процесса может выполнять свои функции. Роль определяется уровнем экспертизы предметной области или обязанностями и полномочиями в рамках бизнес-процессов.

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

Должность и роль. Связь. Различия

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

Главный специалист Правового Управления (должность) = Главный специалист (компонента, отражающая уровень принятия решений) + Сотрудник Правового Управления (компонента, определяющая тип бизнес-подразделения)

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

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

Рис. 2. Ролевая схема бизнес-процесса. Связь с оргструктурой (диаграмма построена в системе бизнес-моделирования Business Studio)

Рассмотрим для примера следующую схему образования функционала для некоторого сотрудника Банка (рисунок 3):

Рис. 3. Регламенты, роли и должностная инструкция

Система бизнес-моделирования Business Studio устроена таким образом, что в должностной инструкции будут указываться роли из бизнес-процессов, в которых данный сотрудник участвует, образуя его функционал.

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

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

Все это значительно упрощает проведение изменений.

Классификация ролей

Обратим внимание, что любая роль возникает при взаимодействии субъекта и другого субъекта либо субъекта и объекта. Мы будем использовать тип взаимодействия как критерий выделения и классификации ролей. Условимся называть такие роли как бизнес-роли и метароли соответственно. Метароли необходимо идентифицировать и описывать не только в рамках составления карты бизнес-процессов, но и при определении прав доступа к любой автоматизированной банковской системе (АБС). В частности, требования по определению и фиксации метаролей при работе с АБС диктуются стандартом информационной безопасности Банка России (СТО БР ИББС-2010). Для этого удобно использовать матрицы метаролей, которые дают подробную «развертку» организационной структуры с разбивкой на ролевую и структурную компоненты (рисунок 4).

Рис. 4. Матрица фиксации метаролей

После того, как проведена работа по составлению карты бизнес-процессов и определению соответствующих ролей, не менее важным аспектом является структурирование множества ролей в комплексной бизнес-модели Банка. В команде проекта можно ввести отдельную роль Rolekeeper (Хранитель ролей) и назначить на нее человека. При определении новой роли или редактировании старой необходимо согласование с Хранителем ролей. Желательно зафиксировать аксиоматику по названию и структурированию множества ролей в качестве приложения к соглашению по бизнес-моделированию.

Приведем практический пример:

Аксиоматика по названию ролей

А1. Название роли не может совпадать с элементом или совокупностью элементов организационной структуры. Исключения составляют роли Главного бухгалтера и Председателя Правления.

Пример: УИТ (Управление информационной безопасности) — не роль.

А2. Название роли должно отражать доминирующую функцию в процессе или уровень экспертизы предметной области участника бизнес-процесса.

Пример: регистратор, администратор баз данных.

А3. Название роли должно стремиться быть инвариантным относительно перемещений между элементами организационной структуры.

Пример: охранник.

А4. Если 2 роли имеют что-то общее из набора функций, но относятся к разным бизнес-процессам, то название каждой роли должно подчеркивать принадлежность конкретному бизнес-процессу.

Пример: регистратор приказов по персоналу, регистратор приказов по основной деятельности.

А5. Если 2 роли имеют что-то общее из набора уровней экспертизы предметной области, но относятся к разным бизнес-процессам, то название ролей полностью определяется набором необходимых компетенций.

А6. Название должно иметь следующую структуру: существительное + «хвост».

А7. Количество слов в названии роли не должно превышать 4 слов, не включая предлоги, союзы и междометия.

Пример: регистратор приказов по основной деятельности.

А8. В названии роли сокращению может подвергаться только «хвост».

Пример: администратор ИБ=администратор информационной безопасности.

А9. Исключениями из пунктов А5-А7 являются названия ролей, установившиеся и принятые в бизнес-среде.

Пример: системный администратор.

Аксиоматика по структурированию множества ролей

А1. Первоначальное множество ролей формируется в виде списка.

А2. Структура множества ролей переходит от списка к дереву по достижению критического количества бизнес-ролей в списке.

А3. Формирование дерева происходит по 3 уровневому принципу, то есть каждая роль относится к одной из следующих групп, определяемых в каждом бизнес-процессе: Front-office, midle office и back-office.

А4. Роли, отражающие названия коллегиальных органов, помещаются в отдельную папку «Комитеты».

Рис. 5. Пример дерева ролей (построено в системе бизнес-моделирования Business Studio)

Выводы

Плюсы ролевого подхода:

• Методологический плюс — независимость от существующей организационной структуры в рамках регламента конкретного бизнес-процесса;
• Операционное преимущество — в случае изменения организационной структуры, создания нового подразделения или упрощения существующих подразделений нет необходимости изменять существующие регламенты, достаточно просто назначить приказом новых сотрудников на исполнение ролей в рамках определенного регламента.

Январь 2011 г.

Рекомендуемые материалы по тематике

Business Studio: разграничение прав через HTML-навигатор

Регламент рабочей группы

Достичь вершины легко, если ваши работники умеют и хотят работать — интервью с Игорем Лозовицким в проекте «Управление из первых рук»

О настоящем и будущем процессного управления в России — интервью Владимира Репина в рамках проекта «Управление из первых рук»

В бизнесе вы можете играть разные роли[58]:

• Заказчик.

• Архитектор.

• Оперативный управляющий (руководитель).

• Исполнитель.

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

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

Архитектор[59] – тот, кто продумывает архитектуру бизнеса, его стратегию: на каких рынках работать, какие продукты предлагать клиентам, с помощью каких бизнес-процессов и проектов выполнять работу и достигать целей бизнеса, какая нужна оргструктура, как нанимать и мотивировать людей и многое другое. Он не выполняет работу лично. Он не ставит оперативные задачи и не контролирует их исполнение. Он разрабатывает подходы, алгоритмы и технологии и т. п., по которым потом будут многократно работать другие люди.

Оперативный управляющий (руководитель) выполняет работу головами и руками других людей. Он не ищет клиентов сам, не изготавливает продукцию, не занимается доставкой и т. д. Он организует своих подчиненных: ставит им задачи, контролирует правильность выполнения ими алгоритмов работы (заданных архитектором в бизнес-процессах и пр.). А также отвечает за результаты – достижение целевых показателей[60]. Например, руководитель отдела, коммерческий директор, генеральный директор. А также руководитель бизнес-процесса – важная роль, которую мы подробно рассмотрим в последующих главах.

Исполнитель выполняет работу лично: своими руками, ногами и головой. У него нет никого в подчинении. Он никому не ставит задачи и ни с кого не спрашивает за их выполнение. Например: продавец, водитель, программист, кассир, рабочий.

Практическое задание 7

Выпишите роли. Если вы собственник бизнеса, то все четыре. Если работаете по найму, то все, кроме Заказчика. Определите, сколько процентов времени вы проводите в той или иной роли (в сумме 100 %). Учитывайте все время, которое вы посвящаете работе, включая вечера и выходные. Пишите как есть, а не как вам кажется «правильным» или как хочется.

Ну вот, вы получили картину на сегодня. Надеюсь, честно.

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

Как вы думаете, хорошо это или не очень?

Практика показывает, что компания или подразделение, в котором шеф много работы делает лично, почти не развивается. Да и когда: нужно же вкалывать день и ночь! Как белка в колесе…

Инициативы и ответственности от сотрудников не дождешься: «На фига? За нас шеф все доделает, решит все вопросы – ему же больше надо. Да и голова у него вон какая!» Новые сотрудники быстро схватывают правила игры и становятся такими же, как и остальные.

Почему так происходит?

Из-за страха руководителя, что «никому ничего нельзя доверить, только я могу хорошо выполнить работу», из-за нежелания и неумения выстроить систему, делегировать, организовать других людей[61].

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

Такой горе-руководитель часто выгорает, начинает ненавидеть людей, наживает проблемы в семье и со здоровьем. Да и не руководитель он пока что. А возможно – никогда им не станет.

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

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

Следующий уровень развития руководителя – когда он работает в основном оперативным управляющим. Много командует, раздает «ценные указания» (ЦУ). Сотрудникам – грузить машину или выполнять заказ клиента, а солнцу – вставать[62] ?.

Все при деле, а он – особенно. Телефон разрывается. Руководитель – самый важный, без него все останавливается. В отпуск – ни-ни!

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

В одном из отделов: завтра на объект нужно доставить готовую конструкцию с производства, а машины нет – за день организовать не смогли: «Что нам делать?» Шеф достал наличные из сейфа и распорядился: «Отправляйтесь на трассу и ловите грузовик-длинномер – срочно! О результатах доложить мне».

Работал почти без выходных, держался на кофе и сигаретах. Здоровье уже пошаливало, несмотря на возраст около 35 лет.

У такого шефа любая проблема решается каждый раз как впервые. Будто в советское время, когда очередной урожай яблок и картошки опять был «неожиданным». Приходилось привлекать к уборке ученых, студентов и других людей, далеких от сельской жизни. Какая уж тут эффективность? Главное – трудовой подвиг!

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

И как все это работает – хрен его знает! Каждый сотрудник чем-то занят. Но никто не сможет нарисовать полную картину и объяснить, что делается, зачем и почему – даже сам собственник[63].

Если хотя бы часть времени вы – Заказчик в своем бизнесе, вас можно поздравить – это редкость. Такая роль проявляется в полной мере, только если у вас есть команда зрелых лояльных топ-менеджеров.

Довольно давно я работал с разнопрофильным холдингом: торговля, недвижимость, гостиницы, рестораны и пр. Когда на сессии начали выделять роли (тогда я называл их всего три: от исполнителя до архитектора), собственник сказал задумчиво: «Михаил, меня здесь нет. Они у меня архитекторы!» – и показал на директоров своих компаний.

Так родилась роль Заказчика.

* * *

Сейчас логично перейти к тому, какие роли в своем бизнесе хотите играть вы?

Но прежде нужно найти ответ на один ключевой вопрос:

Данный текст является ознакомительным фрагментом.

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

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

Ролевая модель

В бизнес-информатике получила широкое распространение процессно-ролевая модель Г. Раммлера и А. Брэйча [1], предложивших изображать на диаграмме процесса дорожки, группирующие пользователей по функциям, которые те должны выполнить. Дорожкам дается имя (синоним — роль), позволяющее однозначно идентифицировать соответствующую категорию исполнителей, выполняющих назначенные им функции.

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

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

Можно представить составную роль в форме иерархии, где на нижнем уровне находятся простые роли, а на верхних — составные [2]. Участники нижнего уровня могут выполнить только свою функцию, а верхних — все нижележащие. Иерархия может строиться, во-первых, снизу вверх, путем синтеза сложных ролей из простых: например, сотрудник офиса продаж принимает заказ клиента и выдает результат — таким образом, роль «операционист» объединяет обе функции. Во-вторых, метод декомпозиции позволяет построить иерархию ролей сверху вниз. Например, операция «проверить сведения о заемщике» может включать две функции: «уточнить адрес проживания» и «проверить место работы». При синтезе критерий консолидации функций в одну роль отражает текущий способ распределения работ в компании, и, если он изменится, ролевую модель придется корректировать. Декомпозиция отражает функциональное разбиение работ, не привязанное к конкретной организационной структуре компании, выполняющей эти действия, это как бы «абсолютный» взгляд на то, из каких компонентов и операций состоят процессы компании. Можно образовать роли участников в соответствии с построенным деревом функций, и такая ролевая модель окажется инвариантна изменениям его организационной структуры.

Способы формирования ролей

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

Часто иерархию ролей рассматривают как способ отображения организационной структуры управления компании. Во-первых, роль привязывают к должности работника — чтобы занять должность, сотрудник должен удовлетворять соответствующим квалификационным требованиям. Но если одну операцию могут выполнять сотрудники в разных должностях (например, руководитель и его подчиненный), то эту операцию придется изобразить на схеме несколько раз, для каждой роли в отдельности. Если изменится организационно штатное расписание, то модель процесса придется корректировать. В примере на рис. 1 показаны две операции, исполняемые сотрудниками в разных должностях. Если изменится распределение обязанностей, вторая операция станет функцией другой должности, при этом модель потеряет актуальность.

Рис.1. Изменение ролевой модели вследствие изменения распределения работ

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

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

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

Роль как логический слой модели процесса

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

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

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

Имя роли

Имя роли можно образовать от соответствующей ей функции, последняя обозначает работу и передается глаголом [3]. Имя роли есть название группы людей, которые выполняют эту работу, его можно образовать как отглагольное существительное или прилагательное: например, функция — «контролировать заявку», а роль — «контролер» или «контролирующий».

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

Операционные и организационные роли

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

Параметрические роли

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

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

Разделение и связывание обязанностей

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

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

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

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

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

Разграничение прав доступа участников к объектам системы

Каким образом ролевая модель позволяет разграничить права доступа участников бизнес-процесса к объектам системы? В ИТ ролью принято называть сотрудников, обладающих одинаковыми разрешениями для работы с объектами системы. В исполняемой модели в качестве объекта принято рассматривать операции бизнес-процесса. Таким образом, дорожка на схеме процесса санкционирует доступ к операциям, а не к данным (рис. 2). Принадлежность к роли определяет разрешение выполнить операцию, но не устанавливает права доступа к самому объекту. По аналогии, разрешение записи в некоторый файл позволяет редактировать данные, но не определяет, каким образом может быть изменен этот файл.

Рис. 2. Процессно-ролевая модель

Можно говорить, что субъект играет роль, роль имеет разрешение выполнить операцию, а операция определяет метод работы с объектом данных. При этом один субъект может иметь несколько ролей, а роль — включать множество субъектов; роль может иметь несколько разрешений, открывая доступ к разным операциям, а одно разрешение может принадлежать многим ролям; операция может изменять множество объектов данных, а объект  может быть изменен разными операциями. Таким образом, роль определяет права доступа к операциям, но не к данным процесса. Как следствие, пользователю невозможно делегировать права на какой-то определенный информационный объект. Для ориентации в этом множестве связей «многие ко многим» в BPMS предлагаются различные модели разграничения доступа.

Управление доступом на основе ролей (Role Based Access Control, RBAC) имеет статус национального стандарта [4]; аналогичные требования содержатся в рекомендациях Банка России [5]. Плоская модель (RBAC0) соответствует ранее рассмотренной процессно-ролевой модели. Иерархия ролей (RBAC1) определяет наследование функций и их объединения в роли. Статическое разделение обязанностей (RBAC2) подразумевает выделение взаимоисключающих функций и распределение пользователей по ролям на этапе моделирования процесса. Динамическое разделение обязанностей (RBAC3) подразумевает уточнение состава участников ролей непосредственно в ходе исполнения. Перед стартом каждой операции происходит авторизация пользователя в назначенные ему роли. При этом проверяются бизнес-правила, и если пользователь уже был авторизован в одной взаимоисключающей роли, то авторизация в другой ему будет запрещена. Кроме того, используется понятие мощности роли, определяющее максимальное количество лиц, которые могут быть авторизованы в роли в рамках одной сессии.

Модель RBAC широко используется в процессных системах. Роли находятся в иерархической связи, образуя дерево (рис. 3), а отображение пользователей на роли происходит либо статически, либо динамически, в последнем случае роли присваиваются только на соответствующую сессию.

Рис. 3. Модель RBAC

Модель RBAC учитывает разделение обязанностей, но игнорирует их объединение, не позволяет моделировать исторический аспект и назначение на основе доступа к общим данным. Модель не разделяет процедуры отбора и назначение исполнителей.

Для расширения возможностей RBAC и реализации динамического разделения обязанностей, используется пооперационная модель доступа (Task Based Authorization Control, TBAC), предполагающая, что для каждого шага процесса можно индивидуально определить правила отбора исполнителя. В этом случае распределение прав доступа становится динамическим и децентрализованным, а разрешения проверяются, активизируются и отменяются для каждой операции в отдельности. Это позволяет смоделировать различные политики выбора исполнителя, применяемые на предприятии.

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

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

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

***

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

Игорь Федоров (IFedorov@mesi.ru) — профессор, Московский государственный университет экономики, статистики и информатики (МЭСИ).

Литература

1. Rummler G., Brache A., Improving Performance: How to Manage the White Space in the Organization Chart. San Francisco: Jossey-Bass Publishers, 1995.
2. Moffet J. Control Principles and Role Hierarchies // Proceedings of the 3rd ACM Workshop on Role Based Access Control (RBAC). 1998.
3. Федоров И.Г. О терминологии процессного управления // Открытое образование. — 2013. — № 4.
4. American National Standard Institute Inc., Role Based Access Control, ANSI INCITS 359-2004, 2004.
5. Стандарт СТО БР ИББС-1.0-2008. Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Банк России, 2009.

Имеющиеся в интернете базовые должностные инструкции нуждаются в адаптации под индивидуальные условия бизнеса. Должность (должностные инструкции) и Бизнес-роли связаны между собой, но именно Бизнес-роли обеспечивают функционирование Бизнес-модели компании и естественное управление бизнес-процессами. 

Должность является совокупностью Бизнес-ролей, однако один сотрудник может выполнять Бизнес-роли разных должностей в рамках одной компании и это является еще одним преимуществом работы по Бизнес-ролям.

Бизнес-роль – это набор полномочий и ответственности, необходимых для выполнения определенных функций в рамках конкретного бизнес-процесса. Бизнес-роли характеризуются тем, что имеют измеримый конечный комплексный результат процесса, называемый “Продукт” Бизнес-роли. Именно Продукт Бизнес-роли вносит необходимую ясность в работу любой компании и значительно облегчает процесс управления.

Продукт Бизнес-роли

Каждая Бизнес-роль имеет свой Продукт Бизнес-роли, который определяется приоритетами компании и стратегией развития в соответствии с Бизнес-моделью Будущего. Продукт Бизнес-роли в свою очередь определяет “как” будет выполняться входящая задача соответствующая этой Бизнес-роли и какой конечный Продукт Задачи будет переходить от одной Бизнес-роли к другой. Формирование задач и взаимодействие между Бизнес-ролями показано на схеме.

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

Практическая значимость Продукта Бизнес-роли (Продукта Задачи) определяется качеством выполняемых задач и соответственно четко определенной ответственностью сотрудников по каждой выполненной задаче.  Такой подход обеспечивает слаженную работу и эффективное управление.

Бизнес-роли на примере Бизнес-ассистента

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

 Бизнес-роли Бизнес-ассистента

• Составление оперативных планов (месячные и декадные) и утверждение их у руководителя. Ведение календаря руководителя.

• Подбор и адаптация новых сотрудников.

• Контроль исполнения поставленных задач (планов) сотрудниками (подрядчиками, фрилансерами).

• Организация мероприятий в online и offline формате.

• Организация делопроизводства, ведение документации компании (юридическая и экономическая проработка договоров, контрактов, соглашений и другие).

• Обработка входящей информации (телефонные звонки, почта).

• Организация командировок.

• Разработка и совершенствование системы мотивации (вознаграждения) сотрудников.

• Выполняет иные необходимые бизнес-роли.

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

Так в компании появляется повышенная ПЕРСОНАЛОЗАВИСИМОСТЬ.

Как избежать таких последствий?

Любые задачи можно делегировать другому исполнителю, если у задачи определена Бизнес-роль и ее Продукт, а сотрудники компании ознакомлены с ними и знают Бизнес-модель всей компании.

Возьмем, например, Бизнес-роль которая есть в любой компании “Подбор новых сотрудников”

Пример Задачи которая ставится в рамках этой Бизнес-роли: 

Принять и адаптировать менеджера по продажам на место уволившегося сотрудника. Срок: с 20 января по 6 марта 2023 года.

Продукт задачи бизнес-роли: 

Разработанное и утвержденное РОП и директором техническое задание на вакансию с учётом бизнес-ролей (и продуктов бизнес-ролей) должности “Менеджер по продажам”, публикация объявлений на “сервисах”, оценка кандидатов на соответствующие техническому заданию на собеседовании, приём на стажировку подходящего кандидата, адаптация менеджера в соответствии с планом адаптации компании.

Исходя из продукта задачи любой сотрудник сможет быстро расписать план действий по достижению продукта этой задачи:

1. Упаковка бизнес-ролей (продуктов бизнес-ролей) менеджера по продажам в должностные обязанности, например, работа с входящим трафиком по скрипту компании, составление договора, контроль оплаты в срок, контроль качества оказания услуги и т.д.

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

3. Составление технического задания на вакансию менеджера по персоналу, утверждение у РОП и директора.

4. Публикация объявления о вакансии на “сервисах” и самостоятельный поиск по резюме кандидатов с целью соблюдения сроков выполнения задачи.

5. Собеседование с приглашенными кандидатами.

6. Выбор кандидата соответствующего техническому заданию на вакансию, приём на стажировку.

7. Адаптация менеджера в соответствии с планом адаптации компании.

Мы прописали действия Бизнес-ассистента в рамках задачи конкретной Бизнес-роли. Имея подробно описанные Бизнес-роли, перед руководителем не возникнет проблем во время отсутствия Бизнес-ассистента поручить выполнение задачи другому сотруднику.

Бизнес-роли решают проблему ДЕЛЕГИРОВАНИЯ.

Также на примере Бизнес-роли “Подбор новых сотрудников” наглядно показано, что наличие формализованных Бизнес-ролей компании позволяют легко подбирать сотрудников под задачи необходимые в текущих процессах (текущей бизнес-модели).

Бизнес-роли позволяют эффективно и быстро составлять детализированную ВАКАНСИЮ.

От должности к отделу

А теперь рассмотрим как Бизнес-роли взаимодействуют между собой на примере HR-процессов, именно с него начинается построение и управление Своим Бизнесом.

Выделим пять Бизнес-ролей:

1. Управление кадрами.

2. Подбор и обучение кадров.

3. Анализ рынка труда.

4. HR-брендинг.

5. Управление кадровым документооборотом.

6. Бюджетирование HR-процессов.

В начале становления бизнеса эти роли может выполнять Бизнес-ассистент совместно с руководителем. По мере расширения бизнеса эти бизнес-роли делегируются отдельной должности – HR-директору или нанимается внешний HR-консультант под определенные задачи.

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

Руководители малого и среднего бизнеса нуждаются в хорошем HR, если решили:

— повысить конкурентоспособность и рентабельность организации;

— масштабировать бизнес;

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

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

Соответственно чем крупнее компания становится, тем выше нагрузка на каждую Бизнес-роль. И при масштабировании под каждую Бизнес-роль принимается отдельный сотрудник. 

Бизнес-Роли позволяют легко МАСШТАБИРОВАТЬСЯ.

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

Бизнес-Роли сокращают время АДАПТАЦИИ СОТРУДНИКОВ.

На схеме изображены Бизнес-Роли HR-отдела и показано их взаимодействие.

Формализованные Продукты Бизнес-ролей обеспечивают работу отдела как “единого механизма”. Зона ответственности каждой Бизнес-роли чётко определяется Продуктом Бизнес-роли, а значит исключается потеря времени на несогласованные действия, ошибки бизнес-процессов, конфликты на почве выполнения задач. Продукт Задачи Бизнес-роли позволяет объективно принимать решение о мерах поощрения или наказания.  

Бизнес-Роли позволяют эффективно УПРАВЛЯТЬ бизнесом.

Таким образом Бизнес-роли не являются организационно-штатной структурой с конкретным прописыванием должностей и не привязываются к личности или конкретному исполнителю. 

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

Так зачем компании прописывать Бизнес-роли?

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

2. Используя данные Бизнес-ролей Вы сможете подбирать целевых сотрудников под вашу бизнес-модель, без труда составите вакансию,  план адаптации, должностную инструкцию или иные документы.

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

4. Сотрудники будут чётко знать свои Бизнес-роли, критерии качества выполняемых обязанностей, исключается риск халатного отношения сотрудника к работе. Они работают как единый механизм, передавая свой Продукт Задачи другой Бизнес-роли.

5. С помощью анализа Бизнес-ролей можно трезво оценить загрузку сотрудников и  отделов, пересмотреть штат, рассмотреть необходимость расширения штата или сокращения. 

6. Бизнес-роли удобно масштабировать, что ведёт к естественному росту бизнеса. Бизнес-роли, принадлежащие к развитию, покажут вам пошаговый план  действий в сторону Бизнес-модели Будущего.

7. Бизнес-роли являются детализированной Бизнес-моделью и идут в неразрывной связке с ней. Описание Бизнес-ролей обеспечивает функционирование бизнес-модели без перебоев.

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

Имея бизнес-модель и описанные Бизнес-роли вы имеете карту движения к цели, вы чётко понимаете какое количество сотрудников вам необходимо, какой функционал они должны выполнять и как взаимодействовать. 

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

Об Ассоциации “Бизнес-Репетитор” 

Ассоциация “Бизнес-Репетитор” более 20 лет помогает предпринимателям решать управленческие задачи и приводить собственное дело в полноценный автоматизированный бизнес.

Наш опыт:

• Более 500 успешно выстроенных проектов в сегменте Малого и Среднего бизнеса. 

• В нашей команде 28 опытных экспертов, практиков бизнеса из разных областей – от общепита до консалтинга в сфере маркетинга и финансов.

• В нашем активе более 70 стартапов.

Во время программы бизнес-практикума вы:

• опишите Бизнес-роли участвующие в процессах вашей компании; 

• научитесь определять продукт каждой бизнес-роли (измеримый конечный комплексный результат процесса);

• сократите время вхождения в должность новых сотрудников, увеличите эффективность сотрудников за счет четкого понимания продукта своих бизнес-ролей (критериев результата работы) и слаженности в работе; 

• с помощью чётко определенного продукта бизнес-роли вы сможете объективно оценивать работу сотрудников, принимать решение о премировании, о распределении нагрузки; 

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

Эксперты Ассоциации «Бизнес-Репетитор» помогают собственникам малого и среднего бизнеса решить управленческие задачи. Мы обучаем технологии полного цикла бизнеса.

Подробнее о программах и услугах Ассоциации «Бизнес-Репетитор»

Мы поможем вам в решении всех этих задач!

«Бизнес-Репетитор» — это ваш персональный наставник, предприниматель, который обучает вас индивидуально и является владельцем бизнеса НЕ только в сфере тренингов и консалтинга.

Эксперты Ассоциации «Бизнес-Репетитор» помогают собственникам малого и среднего бизнеса решить управленческие задачи. Мы обучаем технологии полного цикла бизнеса.

Роли и ответственность участников бизнес-процесса

Участие
сотрудников в реализации бизнес-процесса
документируется в виде матрицы
ответственности бизнес-процесса
(таблица 5), в которой указываются:

• должность владельца
  бизнес-процесса;

• должности
  владельцев подпроцессов и их заместителей.

• должности
  всех сотрудников, участвующих в
  выполнении подпроцессов.

ОТ – ответственный
за выполнение подпроцесса;

УЧ — участвует в
выполнении подпроцесса;

ИН – получает
информацию о ходе и результатах
подпроцесса.

Количество
подпроцессов не должно превышать 7±
2.

Таблица
5 – Матрица ответственности сотрудников
за выполнение бизнес-процесса

Подпроцессы	Должности
Владелец бизнес-процесса	Должность …
Управление бизнес-процессом (обязательно указывается наименование)
1. Подпроцесс (указать название подпроцесса)
2. …

Если
руководитель лично выполняет какую-либо
деятельность (кроме контроля) по
выполнению подпроцесса, то в соответствующей
строке указывается «УЧ». Если владелец
бизнес-процесса осуществляет только
контроль выполнения подпроцесса, то
указывается «ИН».

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

а)
доведение до всех участников
бизнес-процесса информации о требованиях
клиентов и нормативных документов;

б)
установление целевых показателей для
бизнес-процесса и соответствие этих
целевых показателей с целями организации;

в)
регулярный анализ хода бизнес-процесса
и своевременная разработка корректирующих
и предупреждающих негативные тенденции
действий;

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

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

Владелец
бизнес-процесса ведет контроль за
входами, ходом и результатами (выходами)
бизнес-процесса по ряду количественных
показателей. Следовательно, необходимо
установить эти показатели для контроля
и задать периодичность их контроля
(таблица 6). Это позволяет определить
требования к периодичности вызова
функций ПП, которые рассчитывают и
предоставляют необходимую информацию.

Таблица
6 – Показатели качества для
контроля и управления

бизнес-процессом

№	Наименование показателя	Размерность	Описание	Периодичность контроля
	Показатели качества выходов бизнес-процесса
	……
	Показатели качества входов бизнес-процесса
	……
	Показатели удовлетворенности клиентов
	…….

Технология
управления бизнес-процессом

Владелец
бизнес-процесса:

• осуществляет
  управление бизнес-процессом, выполняя
  планирование, мониторинг, контроль,
  анализ и принятие управленческих
  решений;

• производит
  планирование на периоды и подаёт план
  вышестоящему руководителю;

• планирует ход
  бизнес-процесса на заданный период;

• фиксирует
  результаты планирования и контроля
  (учета) в плане работ (таблица 7).

Таблица 7 –
План управления бизнес-процессом

№	Наименование работы (задачи, задания, функции)	Срок исполнения / Периодичность контроля	Показатели
Плановое значение	Фактическое значение

Владелец
бизнес-процесса осуществляет контроль
показателей бизнес-процесса (параметры
из таблицы 6) путём сравнения полученных
фактических значений показателей с
плановыми значениями.

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

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

Моделирование
бизнес – процессов

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

SADT
диаграммы полнее, чем DFD описывают
функциональный аспект системы, так как
они определяют исполнителей процесса,
а также правила, в соответствии с
которыми выполняются процессы.

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

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

Чисто
функциональная ориентация этих диаграмм
важна, так как функции системы
рассматриваются независимо от объектов,
которые их выполняют, что в свою очередь
позволяет четко разделить сущность
(значение) системы от ее реализации
[9].

Над
активностью представленной на контекстной
SADT диаграмме (рисунок 1) может быть
проведена декомпозиция, т.е. быть
разложена на составляющие активности,
которые в свою очередь также могут быть
представлены в виде составляющих
активностей.

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

Разработка
структурно-функциональной модели
объекта

автоматизации

Следует
различать две модели бизнес-процесса.
Модель «как есть», демонстрирует
ситуацию до автоматизации. В этом случае
рассматривается соответствующее
состояние в предметной области. Для
графического документирования бизнес
– процессов рекомендуется применение
SADT –технологии.

Таблица
8 содержит описание подпроцессов
бизнес-процесса для формализованного
описания бизнес-процесса, представленного
в виде SADT диаграммы.

Выбор
функций системы для автоматизации
выполняется на основе анализа с
обоснованием преимуществ выбранного
решения (снижение трудоемкости расчетов,
учет и обеспечение контроля выполнения
и т.д.).

Рисунок
1 — SADT-диаграмма 0-уровня, демонстрирующая

функциональный (активностный) блок
и интерфейсные дуги (связи)

Таблица 8 –
Шаблон формы табличного описания
подпроцессов

бизнес-процесса (на
основе технологии SADT)

№	Наименование операции (активности, деятельности)	Управление активностью	Входы (документы, данные, материалы и др.)	Выходы (документы, данные, материалы и др.)	Исполнитель (ответственный за операцию, механизм реализации)
При каких условиях начинается	Чем регламентируется и завершается

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

Доктор Мередит Белбин разработал теорию ролей в команде на основе атрибутов поведения. Девять ролей участников команды, согласно модели Белбина, делятся на три категории: ориентированные на действия, ориентированные на размышления и социально ориентированные.

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

В этом руководстве мы обсудим девять ролей участников команды по Белбину и расскажем, как баланс в команде позволяет повысить её производительность.

1. Мотиватор

Мотиваторы — это участники, которые двигают команду вперёд. Они ориентированы на действия, мотивируют себя и других, несмотря на любые проблемы. Мотиваторы — прирожденные лидеры, поэтому они хорошо справляются с руководящими должностями. Если возникает кризис, они быстро смогут найти решение.

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

2. Реализатор

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

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

Читать статью «Эффективность и результативность в бизнесе — почему вашей команде нужно и то, и другое»

3. Педант

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

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

4. Генератор идей

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

Пример роли генератора идей: такие участники — очень творческие люди, поэтому они будут отличными дизайнерами продуктов.

5. Аналитик-стратег

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

Пример роли аналитика-стратега: аналитики-стратеги — это сверхорганизованные менеджеры проектов, которые используют стратегический подход при определении объёма проекта и координируют работу разных команд. 

6. Специалист

Последняя роль из категории «ориентированные на размышления» — это специалист. Такие участники обладают глубокими познаниями в своей области, чаще всего узконаправленными. Специалисты, как и другие представители этой категории, лучше работают в одиночку, чем в группе. Хотя эти участники более независимы, они вносят ценный вклад в работу группы благодаря специализированным навыкам.

Пример роли специалиста: специалисты могут быть программистами, SEO-аналитиками или техническими специалистами. Они обладают навыком, недоступным другим участникам, и, к счастью, хорошо разбираются в своём деле. 

7. Координатор

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

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

Читать 12 советов по эффективному обмену информацией на работе

8. Душа команды

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

Пример роли «Душа команды»: так как эти участники созданы для совместной работы, они будут прекрасными маркетологами в большой команде.

9. Исследователь ресурсов

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

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

Читать о секрете высокой динамики в работе коллектива

Как создать сбалансированную команду

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

Опирайтесь на сильные стороны вашей команды

У каждого участника команды есть свои плюсы и минусы. Их понимание поможет вам сделать команду более сбалансированной. Например, генераторы идей могут быть не очень коммуникабельны, но они знают, как решать сложные задачи. У педантов может быть мало опыта работы в команде, но они всегда сдают работу в срок. 

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

Оцените имеющиеся в команде пробелы

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

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

Регулярно пересматривайте командные роли

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

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

Читать о том, как эффективно управлять загрузкой своей группы

Инструменты управления командами

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

Управление загрузкой

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

Управлять загрузкой команд с помощью Asana

Распределение ресурсов

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

Матрица RACI

Матрица ролей и обязанностей (матрица RACI) помогает командам чётко определить роли в проекте и назначить ответственных за каждую задачу. Это сокращение расшифровывается как ответственные, подотчётные, эксперты и информируемые лица. Чтобы создать матрицу RACI, опишите каждую задачу проекта. Затем назначьте одну из четырёх меток каждому участнику команды для всех задач.

Канбан-доски

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

Читать руководство по Канбан-доскам для начинающих

Инструменты для совместной работы

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

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

Сбалансированные команды повышают производительность труда в коллективе

Используя девять роли участников команды по Белбину, вы сможете создать сбалансированную рабочую среду, в которой ваш коллектив будет трудиться продуктивно. Зная сильные стороны своих сотрудников, вы сможете назначить им оптимальные роли, в которых, они будут получать удовлетворение от работы и эффективнее выполнять поставленные задачи. 

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

Повысить эффективность командной работы с помощью Asana

Известный эксперт в области ITSM Рой Аткинсон (Roy Atkinson) в своей статье делится перечнем и описанием типовых ролей в ИТ-поддержке и в управлении услугами, которые использует в своих отчётах Ассоциация профессионалов в области технической поддержки HDI.

Первая линия поддержки / Аналитик Центра Поддержки

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

Вторая линия поддержки

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

Третья линия поддержки

Специалисты технической поддержки, которые создают, обслуживают и/или улучшают технические продукты и услуги. Этим специалистам требуются навыки проектирования и разработки. Они задействованы, когда заявка не может быть решена ни на уровне 1, ни на уровне 2, а также в случае значительного влияния на бизнес или срочности. Третья линия поддержки обычно обеспечивается либо внутренней командой инженеров / разработчиков, либо внешним поставщиком.

Старший группы центра поддержки

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

Менеджер центра поддержки

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

Директор центра поддержки

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

Специалист по технической поддержке рабочих мест

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

Старший группы поддержки рабочих мест

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

Менеджер поддержки рабочих мест

Управляют командами специалистов и / или супервайзеров в рамках реализации оперативных и тактических планов и обеспечения потребностей заказчиков. Обязанности могут включать управление производительностью, мониторинг и отчетность по установленным метрикам, аудиты, согласование закупок и прочие аналогичные должностные функции.

Владелец / менеджер ITSM-процесса

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

Менеджер услуг (Менеджер по предоставлению услуг)

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

Менеджер по взаимоотношениям с бизнесом

Специалисты по управлению услугами, которые отвечают за управление взаимоотношениями с одной или несколькими бизнес-единицами. Эти люди изучают потребности, выявляют болевые точки и дают рекомендации по проведению организационных преобразований и улучшению/ускорению предоставления услуг.

Источник: https://realitsm.ru/?p=31476