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

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

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

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

Концепция сценария риска в COBIT 5 for Risk включает пять основных компонентов: источник угрозы (внутренний или внешний), тип угрозы (злоумышленные действия, ошибки, природные катастрофизмы и т.д.), событие (раскрытие информации, модификация, кража, уничтожение и т.д.), связанные активы (люди, оргструктуры, процессы, ИТ-инфраструктура и т.д.) и временной аспект, учитывающий прогнозируемую длительность негативного влияния и критичность события в зависимости от календарного периода или времени суток. COBIT 5 for Risk также предоставляет более ста различных сценариев рисков, разделенных на 20 категорий, от управления ИТ-инвестициями до рисков, связанных с поставщиками и атаками, с рекомендациями по снижению рисков, сгруппированными по семи факторам влияния.

Традиционную схему оценки влияния инцидентов можно улучшить следующими способами: 1) Ввести специальные правила для критичных периодов, например, повышать уровень влияния для отчетности в конце месяца. 2) Определить функциональных VIP-пользователей, чьи обращения всегда имеют повышенный приоритет. 3) Установить особые правила оценки влияния для отдельных ИТ-услуг, которые имеют стратегическое значение для бизнеса. 4) Сформулировать более четкие критерии различия между 'частичным' и 'полным' отсутствием функционала. При этом важно сохранять баланс между детализацией правил и их практической применимостью для сотрудников первой линии поддержки.

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

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

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

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