Внедрение проактивного управления проблемами может потребовать следующих организационных изменений: 1) Создание специализированных команд или выделение ответственных лиц за проактивную работу, которые будут фокусироваться на прогнозировании и предотвращении проблем, а не только на их устранении после возникновения. 2) Формирование кросс-функциональных рабочих групп, включающих специалистов из разных областей (инфраструктура, приложения, безопасность), для комплексного анализа потенциальных проблем. 3) Внедрение новых метрик и KPI, направленных на измерение эффективности проактивной работы, таких как количество предотвращенных инцидентов, снижение частоты повторяющихся инцидентов и т.д. 4) Изменение структуры отчетности и фокуса обсуждений на совещаниях - включение регулярного анализа трендов, потенциальных рисков и возможностей для улучшения. 5) Развитие компетенций сотрудников в области анализа данных, прогнозирования и управления рисками. 6) Интеграция проактивного управления проблемами с другими процессами, особенно с процессом управления изменениями и постоянным совершенствованием услуг. 7) Внедрение инструментов аналитики и мониторинга, способных выявлять аномалии и потенциальные проблемы до их превращения в инциденты. В крупных организациях может потребоваться создание выделенных структур, таких как отдел качества или управление методологии, которые будут координировать проактивную работу на уровне всей организации.

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

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

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

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

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

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

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

Определение оптимального объема ресурсов для задач технического улучшения в беклоге должно основываться на балансе между текущими бизнес-приоритетами и долгосрочным техническим здоровьем продукта. Рекомендуется ввести и выдерживать резерв или норму минимального выделяемого объема мощностей команды для задач технического экспериментирования и рефакторинга. Этот процент может варьироваться в зависимости от состояния текущего технического долга - чем больше долга, тем большая доля ресурсов может потребоваться для его сокращения. Обычно рекомендуемые значения колеблются от 10% до 30% времени команды. При определении конкретного объема следует учитывать: текущие риски, связанные с техническим долгом; прогнозируемую скорость роста технического долга без профилактических мер; исторические данные об эффективности предыдущих инвестиций в техническое улучшение; и способность бизнеса к терпению в отношении замедления темпов развития функциональности ради повышения качества и устойчивости продукта.

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