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

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

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

Результаты 67% (зеленый вариант) и 56% (красный вариант) при одинаковом KPI своевременности 95% демонстрируют, что первый сценарий предполагает значительно более быстрое устранение инцидентов. Хотя в обоих случаях 5% инцидентов просрочены, в зеленом варианте большая часть решена вблизи Tmin (30 минут), в то время как в красном — ближе к Tmax (4 часа). Это показывает, что новый метод оценки более точно отражает реальный уровень сервиса и оперативность команды.

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

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

Система постоянного улучшения на основе ITIL (Continual Service Improvement) строится по следующему алгоритму: во-первых, определите ключевые показатели эффективности (KPI) для каждой ИТ-услуги, ориентированные на бизнес-результаты. Затем регулярно (ежемесячно или ежеквартально) проводите анализ данных по этим KPI, сравнивая с целевыми значениями. Обеспечьте сбор обратной связи от всех заинтересованных сторон - бизнес-подразделений, пользователей и технических специалистов. Создайте циклический процесс из четырех этапов: Measure (измерение текущего состояния), Analyze (анализ данных и выявление проблем), Improve (внедрение улучшений), Review (оценка результатов изменений). Назначьте ответственных за CSI из руководителей ИТ-подразделений и бизнес-лидеров. Проводите регулярные сессии по выявлению возможностей для улучшения, используя техники мозгового штурма и анализ основных причин. Внедрите систему приоритизации улучшений на основе их влияния на бизнес и сложности реализации. Убедитесь, что результаты улучшений измеряются и доводятся до сведения всех заинтересованных сторон, что создаст мотивацию для дальнейших улучшений. Важно, чтобы процесс CSI был частью повседневной культуры организации, а не разовым проектом.

Раздел Outcomes (верхний левый квадрант) заполняется конкретными результатами, а не названиями процессов. В этом разделе следует указать, что именно будет сделано или получено в ходе проекта. Например, вместо формулировки «внедрение управления изменениями» необходимо написать конкретные достижения: «Сформирован каталог услуг, который включает в себя...», «Заключены SLA с такими-то контрагентами, определяющие такие-то условия», «Организован мониторинг параметров предоставления услуг». Чем конкретнее будут формулировки, тем проще будет впоследствии оценивать успех проекта и принимать решения по его развитию.

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

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