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

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

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

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

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

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

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

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

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

CSI (Continual Service Improvement) может улучшить процесс управления проблемами несколькими способами: 1) Предоставление структурированного подхода к анализу - CSI предлагает методологию измерения, сбора данных и анализа, которая может быть применена к процессу управления проблемами для выявления его слабых мест и возможностей для улучшения. 2) Интеграция с другими процессами - CSI помогает устанавливать связи между управлением проблемами и другими процессами, такими как управление инцидентами, управление изменениями, позволяя создать более целостную систему управления. 3) Формирование культуры постоянного улучшения - CSI способствует созданию среды, в которой постоянный поиск способов улучшения работы становится частью повседневной практики. 4) Применение моделей улучшения - таки как PDCA (Plan-Do-Check-Act) или метод «Семи этапов» из ITIL CSI, которые помогают систематически подходить к улучшению процесса управления проблемами. 5) Измерение эффективности - CSI предоставляет инструменты для установления метрик и KPI, которые позволяют количественно оценить эффективность процесса управления проблемами. 6) Стимулирование проактивного подхода - CSI поддерживает сдвиг от чисто реактивного к проактивному и предиктивному управлению проблемами через анализ данных и выявление трендов.