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

Согласно Business Continuity Institute Good Practice Guidelines 2010 (GPG), жизненный цикл системы управления непрерывностью бизнеса состоит из шести этапов: анализ организации, определение стратегии обеспечения непрерывности, разработка и внедрение планов обеспечения непрерывности, испытание и оценка планов, менеджмент программы управления непрерывностью бизнеса, внедрение управления непрерывностью бизнеса в организационную структуру. Каждый этап подробно описан в документе.

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

Стандарт ISO 31010 «Risk Management – Risk assessment techniques» подробно описывает метод анализа дерева отказов (FTA), предоставляя более развернутую информацию, чем другие источники. Этот стандарт не только объясняет теоретические основы метода, но и приводит конкретные примеры построения деревьев отказов с использованием булевой логики. В частности, в стандарте демонстрируется, как с помощью логических элементов («и», «или», «исключающее или», «не») можно представить различные пути возникновения конечного нежелательного события, создавая наглядную схему причинно-следственных связей, которая помогает в оценке рисков и принятии решений по их снижению.

За управление проблемами могут отвечать различные специалисты в зависимости от структуры организации. В некоторых случаях создается специальная роль менеджера по управлению проблемами, в других — формируются временные команды для расследования корневых причин. В продуктовых командах управление проблемами часто интегрировано в повседневную деятельность и автоматизировано. Менеджер по управлению проблемами должен обладать хорошими аналитическими навыками, знаниями в области архитектуры и конфигурации продуктов, а также умением координировать работу различных специалистов.

В современных ИТ-организациях, особенно при переходе на гибкие методы разработки, роль руководителя проектов существенно меняется. В простых случаях (до 5 команд, десятков сотрудников) управление проектами может быть избыточным или даже вредным. В крупных организациях (500+ сотрудников, сотни ИТ-систем) существует пять основных областей, где может быть полезен руководитель проектов: управление работами команды, построение работы команды, управление проектом создания продукта, управление результатами на более высоком уровне, и построение взаимодействия между старым и новым мирами. Однако ценность руководителя проектов проявляется главным образом в последней области - координации между традиционными и гибкими методологиями, особенно в бимодальных ИТ-средах, где часть систем переводится на новые методы, а часть остается в традиционном режиме работы.

Пользователи недовольны производительностью приложения из-за субъективного восприятия скорости работы: для одних приемлемо ожидание в 5 минут, для других уже 1 минута кажется вечностью. Кроме того, в ИТ-отделах происходит перекладывание ответственности между командами — разработчики обвиняют администраторов оборудования, а те, в свою очередь, ссылаются на программное обеспечение. Также проблема усугубляется тем, что не всегда четко определены критерии нормальной работы системы, что приводит к разночтениям в оценке её производительности.

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

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

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