Ролевая модель в бизнесе это

Ролевая модель – актуальность, безопасность и эффективность сопровождения доступа

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

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

Построение ролевой модели

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

Роли, как правило, создают для определенных должностей или подразделений, включают в них все необходимые полномочия для выполнения сотрудниками должностных или функциональных обязанностей. Матрица, где хранится вся информация по созданным ролям и отношение их к различным должностям и подразделениям называется ролевой моделью (англ. RBAC – role Based Access Control).

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

Важным преимуществом ролевого управления доступом является разделение несовместимых полномочий (англ. SoD – Segregation of Duties). Сотрудник, имеющий определенную роль в системе, не может иметь одновременно другую роль, права которой не должны сочетаться с правами в первой.

Например, кассир, который вводит финансовый платеж не должен иметь возможности подтвердить (проконтролировать) этот платеж. Функция контроля должна быть в руках другого сотрудника: менеджера или руководителя. Создание, внедрение и поддержание ролей в актуальном состоянии может быть сложным.

Функционально-ролевая модель в бизнесе

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

Основные шаги по созданию ролевой модели

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

• Начать нужно с разработки концепции RBAC. На этом этапе нужно определить и донести до всех подразделений почему нужно внедрить ролевую модель, каковы долгосрочные планы по её использованию, какую пользу это принесёт компании, подразделениям и сотрудникам.
• Затем нужно собрать требования всех заинтересованных сторон. Опросить руководителей и бизнес-лидеров, чтобы понять их ожидания от процесса использования ролевой модели.
• Также нужно обратиться к владельцам ИТ-систем, чтобы зафиксировать как на данный момент хранится, предоставляется и аннулируется доступ в конкретное приложение. Зафиксировать какие роли существуют в самом приложении. Составить бизнес-ориентированное описание всех возможных прав доступа в конкретной системе, чтобы любому руководителю было понятно какие возможности предоставляет каждое полномочие и в каком режиме работает: просмотр или проведение активных операций (ввод, изменение, удаление).
• Применить процедуру Role-Mining – автоматическое объединение полномочий в роли, на основании обнаружения повторяющихся прав у сотрудников одной должности или подразделения. Полученные результаты могут быть использованы для выработки рекомендаций по созданию ролей.

• Затем проводится интеллектуальный анализ ролей. Автоматически созданные роли должны будут пройти процедуру согласования у руководителей, сотрудников информационной безопасности, внутреннего контроля или других регулирующих подразделений. На этом этапе роли могут быть скорректированы: дополнены необходимыми правами или будут исключены лишние полномочия.
• Следующий важный этап – это сертификация ролей. Сертификацию, т.е. утверждение роли проводит владелец роли. Это, как правило, руководящий сотрудник бизнес-подразделения, который отвечает за то, чтобы роли, которыми он владеет были всегда актуальными, соответствовали бизнес-процессам и в них не было чрезмерных полномочий.
• В завершение утвержденные роли вносятся в общую матрицу – ролевую модель и далее будут назначаться сотрудникам подразделений компании на основании кадровых назначений.

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

На что обратить особое внимание

«Подводные камни», которые следует учитывать при разработке ролей. Создание ролевой модели – это не только Role-Mining и интеллектуальный анализ ролей. Очень многое зависит от состояния данных, на которых выстраивается система:

• Например, данные, поступающие из HR-системы. Роли мы создаем для конкретных должностей и подразделений, назначаем их работникам, приятым на эти позиции. Во многих организациях качество и количество кадровых данных оставляет желать лучшего. Например, могут отсутствовать или быть не полными такие данные, как атрибуты пользователя: географическое положение, код должности, код отдела. Иногда нет единой кадровой базы данных. Или данные в кадровой базе обновляются с большой задержкой: сутки и более. Эти моменты нужно заранее проработать, а данные привести к консистентному виду.
• В некоторых системах может быть многоуровневая структура доступа, права могут быть слишком детализированы или связаны в определенные структуры. Например, сложная структура каталогов Active Directory или слишком детализированные полномочия системы SAP. Исходя из этого нужно определить на каком уровне погружения осуществляется управление ролевой моделью. На уровне атомарных (детально гранулированных) прав или же на основании групповых объединений. Кроме того, для корректной работы иногда предоставление одного полномочия требует обязательного предоставления дополнительного второго полномочия. Например, чтобы предоставить доступ к определенной группе закрытых счетов, учетная запись сотрудника должна быть внесена в определенную таблицу разрешений, которая хранится в отдельном файле, отдельной библиотеке. Здесь будет полезно дополнительное участие в разработке ролевой модели сотрудников, которые непосредственно занимаются выдачей прав вновь принятым работникам и удалением прав уволенных сотрудников. Только они обладают полной информацией о том, как предоставляется доступ, чтобы он был корректным и работоспособным.

Не нужно стремиться построить 100% ролевую модель

Надо понимать, что построить 100% ролевую модель, обеспечив всеми необходимыми правами сотрудников каждой должности в крупной компании просто невозможно. Да это и не нужно. Ведь ролевая модель не может быть статичной потому, что она зависит от:

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

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

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

Актуализация ролевой модели

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

• Изменение организационно-штатной структуры. Например, было два отдела и их объединили в один. Естественно, что полномочия у сотрудников должны поменяться и соответственно роли должны обновиться.
• Изменение бизнес-процессов компании. В организацию внедряются новые процессы, которые совершенствуют работу персонала и помогают достижению стратегических целей. Например, появилась новая должность в подразделении с новым функциями – администратор по улучшению хозяйственной деятельности в отделе АХО. Для новой должности должна быть создана новая роль с необходимым набором полномочий в системах компании. Или же разработали новый перспективный отчет для руководителей операционных офисов банков и менеджеров. Отчет нужно включить в соответствующие существующие роли, созданные для этих должностей.
• Изменение ИТ-архитектуры. На предприятиях периодически происходит вывод из эксплуатации старых систем и ввод в эксплуатацию новых. Допустим, старая система выводится из эксплуатации. Соответственно функционал, который в ней выполняли сотрудники должен быть переведен в новую систему. Для этого придется провести ревизию всех ролей старой системы и их актуальности, проанализировать созданные роли новой системы, сделать матрицу сопоставления старых и новых ролей. Вполне возможно, что на какой-то переходный период эти роли будут существовать параллельно, пока весь нужный функционал не перенесут в новую систему и ролевая модель не будет доработана. Затем использование ролей старой системы можно будет прекратить, доступ пользователей аннулировать, а данные старой системы отправить в архив.

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

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

Источник: rt-solar.ru

Строим ролевую модель управления доступом. Часть вторая, «строительная»

Пост, который вы сейчас читаете, – продолжение статьи о том, как правильно выстроить в крупной компании ролевую модель управления доступом пользователей к различным системам. Напомним: построение ролевой модели – это скорее процесс, чем результат, и первую часть нашей дилогии мы посвятили подготовке к «строительству». В ней мы рассказали, как создать функциональную модель каждого подразделения и должности, провести аудит ИТ-систем и расставить их по приоритетам, создать бизнес-ориентированное описание прав пользователей и о других важных подготовительных шагах. Сегодня же поговорим о способах построения ролевой модели, ролевых матрицах, чем здесь поможет внедрение автоматизированных систем управления доступом (IdM/IGA), и что вы получите на выходе.

Для построения ролевой модели в информационной системе есть два способа.

Первый подход

Роли разрабатываются на основании функциональной модели. Этот подход возможен, когда в организации есть специальное подразделение технологов, назовём его «Организационно технологический отдел (ОТО)». У нас в банке такой отдел был в составе ИТ-департамента. Отдел будет переводить потребности бизнеса, описанные в функциональной модели, на язык ИТ: язык прав/опций/полномочий, которые нужно предоставить в системе для выполнения конкретного функционала.

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

Второй подход

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

Если система не очень большая и в ней немного разнообразных прав, то выделить общие совпадающие права у сотрудников одной должности несложно. Из них можно составить роль, а затем направить её на согласование и утверждение руководителю, владельцу ресурса и далее по цепочке, как в первом случае. Если же в системе очень много прав (полномочий), и ее использует большое число сотрудников из разных подразделений, то задача усложняется. В этом случае на помощь приходят специализированные утилиты, именуемые Role mining, которые облегчают задачу. Они собирают совпадающие права для определённой должности в стандартную роль, которая анализируется и утверждается заинтересованными сторонами.

Строим ролевую модель по второму подходу

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

Разработали шаблон заполнения ролевой матрицы для каждой системы: напомним, ролевая матрица – это роли (набор прав) в привязке к подразделениям компании и должностям в них. Шаблон направили владельцам этих систем для заполнения. Те в свою очередь собрали информацию с подразделений, в которых использовалась система, и вернули уже заполненный шаблон для дальнейшего согласования со службами ИБ и внутреннего контроля. Заполненный шаблон, а именно ролевая матрица затем используется в предоставлении доступа на основе ролей, а также включения в будущий проект автоматизации.

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

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

Пример шаблона для заполнения ролевых матриц

Наш шаблон выглядел так. На первом листе слева (по вертикали) были перечислены должности и подразделения, а сверху (по горизонтали) – роли. На пересечении необходимо было установить маркер, указав, для какого подразделения необходима какая роль/роли. Цветной заливкой мы отмечали: зелёным – роли, которые должны быть предоставлены по умолчанию, при назначении на должность; жёлтым – роли, которые могут быть запрошены для конкретной должности или подразделения по отдельной дополнительной заявке.

На втором листе мы разместили справочник, который показывал наполнение ролей отдельными правами (полномочиями).

На третьем листе – матрицу SOD-конфликтов (запрета на возможное сочетание ролей).

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

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

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

В этом случае автоматизированная система будет помощником или подспорьем в построении ролей. Внедрение автоматизированных систем управления доступом (IdM/IGA) нужно начинать с подключения кадровых источников и целевых систем для выгрузки данных и их мапинга и анализа. Используя специализированные инструменты, встроенные в решения по управлению доступом, можно с самого начала достаточно эффективно выстроить нужные процессы на основе автоматизации. Это значительно сократит трудозатраты и исключит шоковую терапию в будущем. Например, гораздо быстрее и эффективнее пройдёт процесс работы с учётными записями, а именно на первом этапе:

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

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

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

Претворяем в жизнь новый регламент прав доступа

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

1. Связь уровня вовлеченности и взаимоотношений в команде. Связь уровня вовлеченности и результативности команд

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

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

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

Участие в командной работе как фактор вовлеченности

В июле 2018 г. Исследовательский институт ADP (ADP Research Institute) провел оценку уровня вовлеченности работников в 19 странах мира. Наиболее значимым показателем высокой вовлеченности оказалась работа в команде.Сотрудники, которые работают в команде, в 2,3 раза чаще максимально вовлечены.Этот результат справедлив для всех стран, участвовавших в исследовании.

«Например, в Бразилии среди тех, кто выполняет только индивидуальные задачи, процент максимально вовлеченных составил 5, а среди командных работников — 15. В Сингапуре среди тех, кто не работает в командах, максимально вовлечены в своей работе 4%, а среди тех, кто работает в командах — 22%» (Маркус Бакингем, Эшли Гуделл. «Это так не работает!»)

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

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

2. Вовлеченность и продуктивность команд

Однако сам факт участия в командной работе не является гарантией высокой вовлеченности сотрудников. В рамках исследования ADP 83% работников заявили, что они работают в командах, но в одних командах вовлеченность выше, чем в других.

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

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

По мнению Ф. Сандала и А. Филлипса (книга « Потенциал команды » ), успешные команды могут быть определены через два измерения:

• продуктивности и
• позитивности.

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

• командное лидерство
• умение распоряжаться ресурсами
• эффективный процесс принятий решений
• проактивность
• подотчетность
• целевое управление
• согласованность.

Факторы позитивности включают:

• доверие
• уважение
• дух товарищества
• открытое и эффективное общение
• конструктивное общение
• уважение к различиям
• оптимизм.

В зависимости от выраженности факторов продуктивности и позитивности команды можно разделить на 4 категории (см. рисунок 1):

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

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

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

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

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

3. Модели командных ролей. Диагностика по командным ролям

В управленческий психологии сосуществует несколько конкурирующих моделей командных ролей. Для диагностики командных ролей в предлагаемой нами методике используется дополненная модель ролей Ицхака Адизеса:

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

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

4. Изменение понятия команда. Временные проектные команды, кроссфункциональные команды, участие во многих командах одновременно

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

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

• определение сущности командной работы как таковой и
• определения границ команд внутри компаний.

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

Из тех, кто заявил, что работает в командах, 65% сказали, что они работают более чем в одной команде и что эта команда не представлена в штатном расписании.

Организации не знают, сколько у них команд, кто в них состоит и какие команды самые лучшие и заинтересованные (Маркус Бакингем, Эшли Гуделл. «Это так не работает!»).

Любая компания сегодня имеет:

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

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

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

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

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

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

Одним из таких инструментов может быть анализ взаимодействия сотрудников внутри компании на основании цифрового следа – организационно-сетевой анализ (ONA)

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

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

Карты коммуникаций позволяют увидеть:

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

Как пишет Greg Newman , ONA позволяет собрать данные о динамичном
« социальном капитале » в дополнение к статичному
« человеческому капиталу » , на который обычно полагаются HR и people-аналитики.

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

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

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

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

что даст новое представление о командах, реально работающих в компании.

6. Диагностика команд с использованием ролевой модели

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

Ролевая диагностика может проводиться по нескольким ракурсам:

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

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

На основании полученных данных могут планироваться корректирующие действия, которые могут включать:

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

Работа с командой имеет циклический характер, соответствующий управленческому циклу Деминга:

• диагностика командного взаимодействия,
• определений препятствий к росту позитивности и продуктивности команды,
• проведение корректирующих мероприятий,
• повторная диагностика для определения эффективности проведенной работы.

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

Ситуация №1. Перегруженность сотрудника ролями.

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

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

Ситуация 2. Чужая роль.

Сотрудник считает, что наиболее подходящими для него ролями являются роли Эксперта и Инноватора.

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

Решение: перераспределение обязанностей. Командный коучинг посвященный работе с различиями и ценности разных ролей в команде.

Ситуация 3. Пробелы в ролевом репертуаре команды.

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

Решение: очевидно, что здесь нужны Администратор и Интегратор для развития команды и ее вывода на новые уровни успеха.

Ситуация 4. Неумение переключаться с роли на роль, низкая чувствительность к командному контексту.

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

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

Более подробно о программном продукте «Управлению командной вовлеченностью и эффективностью» вы можете узнать здесь

Источник: neohr.ru