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

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

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

Иерархические структуры управления особенно проблематичны для ИТ-подразделений в современных условиях, так как они требуют большого количества квалифицированных руководителей всех уровней. Для среднего ИТ-департамента из 1000 человек может потребоваться 100-120 руководителей, из которых 30-50 должны быть высококвалифицированными управленцами. Однако на рынке труда отсутствует достаточное количество таких специалистов, так как нет действующих институтов по их подготовке. В результате надстройка из руководителей, которые часто не обладают необходимой квалификацией, снижает эффективность всей системы.

Если инцидент решён в срок, увеличение времени обработки конкретной группой не влияет на её KPI, так как для этих инцидентов vi=0 и их вклад в формулу равен 1. Если же инцидент просрочен, увеличение времени обработки группой (ti) приведёт к росту её доли в общем времени (ti/Ti), что уменьшит её KPI, так как формула для просроченных инцидентов выглядит как 1 - (ti/Ti). Таким образом, метрика специально спроектирована так, чтобы время обработки влияло на показатель только в случае, когда инцидент оказался просроченным.

Если все старые проблемы были решены, а новые зарегистрированы, то метрика принимает значение 1. Это происходит потому, что в этом случае количество открытых проблем по итогам периода (O) будет равно количеству новых проблем (N), так как все старые проблемы закрыты. Подставляя в формулу (N + C)/(N + C + O) и учитывая, что O = N, а C равно количеству закрытых старых проблем, получаем, что значение метрики будет равно 1. Это максимальное значение, которое показывает идеальную работу процесса управления проблемами за отчетный период.

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

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

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

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