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

Time in Process — это общее время, в течение которого задача находилась в потоке, от начала до конца обработки (также называемое Lead Time). Формально он рассчитывается как разница между моментом завершения работы (Done) и моментом начала работы (Start). Однако важно учитывать, что это не просто календарное время, так как в большинстве ИТ-процессов работа ведется только в рабочее время, а не круглосуточно. Правильный расчет предполагает учет именно рабочего времени, а не общего календарного, чтобы избежать искажений результата (например, задача, выполненная за 24 рабочих часа в течение трех календарных дней, будет иметь неадекватно низкую эффективность при учете полных суток).

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

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

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

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

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

Принцип "Действуйте итерационно" (Progress iteratively), описанный в ITIL Practitioner Guidance 2016 года, был дополнен в ITIL 4 2019 года до формулировки "Действуйте итерационно, используя обратную связь" (Progress iteratively with feedback). Это изменение подчеркивает важность не просто итерационного подхода к работе, но и обязательного сбора и учета обратной связи на каждой итерации. Авторы ITIL 4 таким образом делают акцент на том, что обратная связь является ключевым элементом успешных итераций, позволяющим корректировать дальнейшие шаги и улучшать результаты.

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

Для повышения эффективности анализа проблем метод «Пять «Почему?» часто используется в сочетании с другими техниками. Диаграмма Ишикавы («рыбий скелет») помогает визуализировать ветвление причинно-следственных связей. Метод Кепнера-Трего (включая его описание в ITIL) систематизирует анализ через этапы описания и определения проблемы. Дерево текущей/будущей реальности из теории ограничений Э. Голдратта позволяет структурировать причинно-следственные отношения. Эти методы помогают упорядочить процесс формулирования вопросов и минимизировать риски одностороннего анализа.