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

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

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

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

«Палочная система» — это ситуация, когда показатели и метрики, используемые для оценки и мотивации, на самом деле стимулируют поведение, противоположное изначальным целям. Проблема состоит в том, что измеряемые показатели формально соответствуют критерию измеримости («M»), но не являются релевантными («R»). Например, показатель может поощрять сотрудников действовать в свою пользу, игнорируя долгосрочные задачи организации.

В иерархической RBAC (Hierarchical RBAC) механизм наследования прав работает на основе организации ролей по принципу старшинства. Роли располагаются в иерархическом порядке, и нижестоящие роли наследуют все права доступа от вышестоящих ролей. Например, если роль 'Главный инженер' расположена ниже роли 'Сотрудник' в иерархии, то 'Главный инженер' автоматически получает все права, определенные для роли 'Сотрудник', плюс свои собственные дополнительные права. Это позволяет уменьшить дублирование прав при проектировании системы, так как общие базовые права можно вынести в одну роль, а специфические - в более специализированные нижестоящие роли. Механизм наследования значительно упрощает администрирование крупных систем с большим количеством пользователей и ролей.

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

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

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

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