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

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

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

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

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

Для корректного учёта параллельных задач важно фиксировать начало и окончание совокупности действий, а затем оценивать реальное распределение времени между ними. Например, если сотрудник ведёт телефонный разговор и составляет документ, общее время разбивается на доли (изначально 50/50), после чего уточняется на основе личного наблюдения. Это позволяет избежать завышенных оценок и получить реалистичную статистику. Ключевой момент — отказ от восприятия одновременной работы над несколькими задачами как полного выполнения каждой из них за отведённое время.

В тексте приведены три основных примера неправильного поведения менеджеров. Первый пример: ИТ-руководитель в игре 'Grab@Pizza', который слишком долго пытается полностью разобраться в сценарии и предсказать будущее вместо того, чтобы начать работу. Второй пример: менеджер инцидентов в 'Apollo 13', который решает, что все инциденты должны проходить через него, и он будет всё регистрировать лично, что оказывается неэффективным уже ко второму раунду. Третий пример: менеджер проекта в 'The Challenge of Egypt', который основное время проводит на стройплощадке, командуя рабочими напрямую, игнорируя важные аспекты проекта вроде бюджета и сроков.

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

ITIL 4 предлагает решать проблему разобщенности через принцип 'Используйте целостный подход' (Think and work holistically) и через рассмотрение четырех аспектов управления ИТ-услугами. Этот принцип подразумевает необходимость понимания того, как все части организации работают вместе интегрированным образом. Вместо того чтобы фокусироваться на отдельных элементах (процессах без учета инструментов и компетенций, или наоборот), ITIL 4 предлагает рассматривать четыре взаимосвязанных аспекта: организации и люди, информация и технологии, партнеры и поставщики, потоки создания ценности и процессы. Для устранения разобщенности также необходимо формировать организационные структуры, ориентированные на сотрудничество, развивать культуру доверия и прозрачности, обеспечивать достаточные компетенции сотрудников и правильно определять взаимодействие с партнерами. Важно рассматривать процессы не изолированно, а как часть потоков создания ценности, что обеспечивает целостное преобразование входов в результаты, воспринимаемые клиентом.

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