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

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

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

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

В эксперименте Дэна Ариели участники двух групп по-разному справлялись с задачей сборки роботов LEGO Bionicle за деньги. В группе «Работа со смыслом» участники видели результат своего труда в виде выстроенных в ряд собранных роботов, что позволяло им осознавать ценность каждой следующей детали. В группе «Сизифов труд» роботы разбирались сразу после сборки, что уничтожало ощущение завершённости и ценности работы. Результаты эксперимента показывают, что участники первой группы собирали в среднем 10,6 роботов, а второй — всего 7,2. Кроме того, когда оплата снижалась ниже психологического барьера в $1, 65% участников первой группы продолжали работу, тогда как во второй группе эта доля составляла лишь 20%. Таким образом, эксперимент подтверждает, что когда люди видят смысл и результат своей работы, их продуктивность и мотивация значительно выше.

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

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

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

В управлении доступностью (AVA) основными показателями выступают: - MTRS (среднее время восстановления услуги) - MTBF (среднее время между сбоями) - MTBSI (среднее время между инцидентами) Эти показатели связаны со статистикой и тенденциями сбоев в работе ИТ-систем. В управлении непрерывностью (CONT) используются: - RTO (recovery time objective) — целевое время восстановления - RPO (recovery point objective) — целевая точка восстановления RTO показывает, за какое время после сбоя должно быть возобновлено предоставление услуги, а RPO указывает, какой период данных может быть потерян без критического ущерба для бизнеса.

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