Методология ITIL V3 прямо рассматривает понятие Tension Metrics (Сопряженные метрики) в контексте управления ИТ-услугами. Также подобные концепции присутствуют в системном подходе, теории ограничений (TOC), Lean-менеджменте и шести сигмах, где анализируются взаимосвязи между показателями и ищутся оптимальные точки баланса между конкурирующими требованиями.

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

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

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

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

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

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

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

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

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