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

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

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

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

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

Метод ORBIT помогает в экономическом обосновании ITSM-проекта за счет того, что четко разделяет результаты, бизнес-бенефиты и бенефиты для ИТ-департамента. Когда видно, какие конкретные результаты будут достигнуты, как они повлияют на бизнес (например, снижение простоев, повышение удовлетворенности клиентов, улучшение отчетности) и как это отразится на финансовых показателях, становится проще провести расчет ROI. Четкое понимание рисков также помогает в составлении более реалистичного бюджета и плана расходов, так как заранее известно, какие возможные проблемы могут привести к дополнительным затратам.

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

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

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

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