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

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

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

До перехода в консалтинг, когда автор работал на стороне заказчика, рабочая загрузка составляла примерно 70-80% — времени хватало на выполнение всех задач, и даже оставалось время на изучение новых технологий и управленческих методик. После перехода в консалтинг уровень рабочей загрузки вырос до 120-130%, в пиковые периоды достигая 160%. Это привело к тому, что возник острый вопрос о том, как всё успеть, и потребовало поиска решений в области управления временем и повышения личной эффективности.

Совет по руководству информационными технологиями и телекоммуникациями (ICTGC) Бахрейна сгруппировал 37 процессов COBIT5 в 8 блоков: Стратегия и руководство, Управление финансами, Люди и ресурсы, Инфраструктура и эксплуатация, Управление приложениями, Планирование услуг и архитектура, Управление рисками и безопасностью, Управление портфелем и проектами. Эта группировка была сделана для лучшего управления ИТ в контексте развития электронного правительства.

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

В контексте управления уровнем ИТ-услуг процесс SLM (Service Level Management) соответствует циклу PDCA (Plan-Do-Check-Act). Этот процесс ответственен за реализацию цикла PDCA над оперативной деятельностью в рамках жизненного цикла услуг, направленного на постепенное устранение несоответствий между ожиданиями заказчика услуг и реальными показателями предоставляемых услуг. Таким образом, SLM обеспечивает постоянное улучшение качества ИТ-услуг через планомерное выявление и устранение недостатков.

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

Формализм предотвращается через постоянный фокус на бизнес-целях, а не на соблюдении процедур. Ключевой приём — ответы на вопрос «Зачем?» для каждого этапа. Также важно вовлекать конечных пользователей в проектирование и обеспечивать их обучение так, чтобы инструменты воспринимались как средство решения рабочих задач, а не как дополнительная нагрузка.

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