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

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

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

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

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

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

Практика ведения каталога технических услуг и OLA не применима ко всем компаниям, потому что сервисный подход вообще реализован лишь в небольшом количестве организаций, и только к очень небольшой доле этих организаций применима именно практика ведения каталога технических услуг и OLA. Это связано с тем, что такие документы и практики значительно влияют на другие процессы, отношения между подразделениями и оргструктуру, и их введение может быть избыточным или неоправданным в компаниях с простой структурой или без четкого сервисного подхода. О необходимости быть осторожнее с внедрением таких практик уже писали Pink Elephant (около 2006 года) и IT Skeptic (около 2011 года).

Зону видимости для потребителей услуг можно определить, проанализировав, какие аспекты сервисных отношений клиенты могут видеть и оценивать, а какие происходят за кулисами. Для этого необходимо ответить на вопросы: Что мы делаем вместе с клиентом? Какие показатели должны быть видны клиентам и пользователям? Какие инструменты использовать для демонстрации прогресса? Какой культурный контекст наших сервисных отношений? Зона видимости должна быть широкой там, где клиенты ожидают прозрачности, и защищенной там, где требуются профессиональные знания, чтобы создать баланс между доверием и профессионализмом.

Основные направления развития современной системы управления ИТ в Enterprise включают: - Создание мощной службы HR внутри ИТ-подразделения, которая будет активно искать таланты, решать вопросы найма, вовлечённости, мотивации и развития персонала. - Переход от традиционных иерархических структур к альтернативным принципам управления, таким как продукты вместо проектов, самоорганизующиеся команды вместо отделов, коллективная ответственность вместо тим-лида, управление задачами вместо управления людьми. - Развитие внутренних сообществ по ролям и по интересам, организация митапов, обмена находками и идей, совместной работы над исследованиями и разработками (R&D).

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