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

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

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

Эффективное обучение сотрудников новым ITIL-процессам должно быть многоступенчатым и ориентированным на практическое применение. Начните с обучения ключевых сотрудников, которые затем станут внутренними тренерами. Разработайте уровневую программу обучения: базовый уровень для всех сотрудников с фокусом на их конкретные роли в процессах; расширенный уровень для ответственных за процессы; продвинутый уровень для руководителей и архитекторов. Делайте упор на практические занятия - симуляции, ролевые игры, обработка реальных кейсов из вашей компании. Используйте различные форматы: очные тренинги, вебинары, онлайн-модули для самостоятельного изучения, чек-листы и шаблоны для повседневного использования. Разработайте индивидуальные планы обучения для разных должностей, так как требования к знаниям различаются для руководителей, менеджеров и исполнителей. Создайте систему проверки знаний через тестирование и практические задания. После обучения организуйте поддерживающую среду: регулярные коуч-сессии, сообщество практиков для обмена опытом, доступ к справочным материалам. Внедрите систему поощрения за успешное применение новых процессов. Проводите повторное обучение через 3-6 месяцев для закрепления знаний и внесения корректировок. Важно, чтобы обучение было не разовым событием, а частью постоянного развития навыков сотрудников.

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

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

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

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

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

Можно ли использовать существующую CMDB для планирования мощностей и сервисной экономики зависит от соответствия CMDB трём основным требованиям. Во-первых, в CMDB должны быть построены логические модели приложений и услуг, включающие функциональные роли ресурсов. Во-вторых, связи между элементами CMDB должны содержать атрибуты и логику передачи потребности в мощностях и стоимости. В-третьих, CMDB должна поддерживать операции с плановыми объектами для обсчёта целевой архитектуры. Проверка этих требований позволяет не только получить ответ в форме «да/нет», но и определить, что именно в CMDB потребует доработки для эффективного использования в управлении мощностями.