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

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

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

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

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

Стратегию плотного контакта с клиентами применяют компании, которые стремятся создать вовлечённость через прозрачность и взаимодействие. Например, Basecamp демонстрирует свои принципы работы и технологии, разъясняет решения и активно учитывает мнение клиентов. Такой подход помогает укрепить лояльность, даже если продукт не идеален.

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

Концепция ценности услуг в ITIL основывается на двух факторах: функциональности (utility) и гарантии (warranty). Предложенный подход к анализу процессов в ИТ-менеджменте полностью соответствует этой концепции. Результативность процессов является аналогом функциональности — она показывает, насколько процессы полезны и удовлетворяют требованиям бизнеса. Зрелость процессов выступает аналогом гарантии — она отражает уверенность в том, что процессы будут стабильно обеспечивать эту полезность в любых условиях. Таким образом, объединение результативности и зрелости на радарной диаграмме позволяет анализировать ценность процессов так же, как ITIL анализирует ценность услуг.

Термин OLA может быть избыточным, потому что содержательно OLA не отличается от SLA, а является всего лишь SLA с другой стороны. Если рассматривать цепочку создания ценности, то то, что для одного участника выглядит как OLA, для другого будет SLA. Примеры из ITIL Service Design показывают, что предлагаемые SLA и OLA очень похожи. Поэтому OLA как отдельная концепция не добавляет ценности и может только запутать при реализации, так как теряет четкое определение и аргументированное обоснование, что и приводит к путанице в практическом применении.

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