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

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

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

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

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

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

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

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

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

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