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

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

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

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

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

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

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

Доступность как компонент Warranty означает, насколько часто услуга доступна для использования пользователями, когда в ней возникает необходимость. Это включает в себя минимальное время простоя, регламентные работы, время восстановления после сбоев. Например, для электрического света доступность определяет, может ли пользователь зажечь свет, когда захочет, и как часто происходят отключения электричества. Высокая доступность означает, что услуга постоянно или почти постоянно доступна в соответствии с ожиданиями пользователя. Доступность часто измеряется в процентах (например, 99,9% времени) и является критическим компонентом при определении уровня качества услуги и составлении SLA.

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

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