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

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

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

Вывод о целесообразности внедрения управления уровнями ИТ-услуг зависит от стадии зрелости организации и её стратегических целей. Если компания не планирует расширять сервисный подход на разработку и останется на разделении ALM и ITSM как постоянном решении, то управление уровнями услуг может принести меньше пользы, чем ожидается. В этом случае организация может ограничиться реализацией операционных процессов управления на уровне зрелости «Controlled», что будет более адекватным решением. Однако для компаний, где зависимость от ИТ высока и требуется постоянное развитие систем, необходим переход к интегрированному подходу с полной сквозной ответственностью за услуги.

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

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

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

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

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

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