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

С управлением сервисными активами и конфигурациями тесно связаны следующие разделы процесса управления изменениями: идентификация конфигураций, управление версиями, управление интерфейсами, управление поставщиками, управление релизами и развертыванием, управление сборками ПО, создание и поддержка базовых состояний, сопровождение CMDB, закупка и списание конфигурационных единиц, верификация и аудит CMS. Кроме того, существует тесная связь с такими процессами как управление основными средствами, управление проектами, управление разработкой и тестированием, управление взаимоотношениями с поставщиками и подрядчиками. Эффективное управление изменениями невозможно без корректного отображения конфигурационных единиц и их взаимосвязей в CMDB.

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

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

ITSM изменяет роль первой линии поддержки, требуя от неё переподготовки по новой системе классификации обращений пользователей. Сотрудники первой линии должны понимать не только технические аспекты проблем, но и их влияние на уровень услуг, что требует более глубокого понимания сервисной модели и целей бизнеса.

Фокусировка на зоне влияния позволяет команде сосредоточиться на реальных действиях, которые могут улучшить ситуацию, вместо того чтобы искать объективные причины вне контура контроля. Проблемы, приписанные внешним факторам (например, «заказчик плохо формулирует требования»), часто скрывают внутренние дисфункции, такие как отсутствие обратной связи или неэффективные процессы согласования. Анализ внутри зоны влияния способствует быстрому внедрению изменений и снижает пассивность команды.

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

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

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

Для анализа услуги "ИТ-обеспечение процесса выдачи кредитов физлицам" с помощью модели Compass Model: Север (потребности): клиенту необходимо быстро и удобно подать заявку, получить прозрачные условия кредита, гарантированно защитить личные данные, оперативно получить решение. Банку необходимо обеспечить соблюдение регуляторных требований, точный скоринг, минимизацию рисков. Запад (желания): клиент хочет простой интерфейс подачи заявки, мгновенное предварительное решение, возможность выбора условий, онлайн-консультацию. Банк желает оптимиризировать процессы, повысить долю успешных заявок, улучшить клиентский опыт. Юг (стереотипы): клиенты боятся сложных процедур, утечки данных, скрытых комиссий; считают, что одобрение кредита занимает много времени. Эмоции (Восток): клиент может испытывать стресс из-за необходимости кредита, сомнения в безопасности, облегчение при оперативном решении, доверие при прозрачных условиях. Зная эти аспекты, ИТ-служба может сосредоточиться на создании системы, которая не только выполняет базовые функции, но и разрушает негативные стереотипы, обеспечивая позитивный эмоциональный отклик.