Для достижения требуемых показателей скорости изменения продукта необходимо выполнение двух условий. Во-первых, команда как черный ящик должна быть внутренне устроена корректно: уметь работать с потоком обрабатываемых объектов, иметь сбалансированную пропускную способность на всех этапах обработки. Во-вторых, команда должна иметь возможность управлять входом поступающих объектов: объекты должны иметь строгие границы для осознания и работы с ними, должны обладать определенной общностью в "размерах" (трудоемкость не должна сильно варьироваться), и команда должна управлять лимитом на количество объектов, обрабатываемых на первом этапе конвейера. Менее входящих объектов означает более быструю обработку каждого из них.

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

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

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

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

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

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

Инструменты Role mining автоматизируют процесс сбора информации о текущих правах сотрудников в информационных системах, анализируют повторяемость этих прав у сотрудников с одинаковыми атрибутами, объединяют права в роли и формируют базовую ролевую модель. Это существенно ускоряет начальный этап построения актуальной ролевой модели, которая отражает текущее состояние системы доступа, уменьшая время разработки с месяцев или лет до более коротких сроков.

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

Метрика First Time Resolution (FTR) в разрезе рабочих групп рассчитывается по формуле: FTR = (Nj - Sj) / Nj. Здесь Nj — количество обращений (инцидентов), обработанных j-той группой и закрытых без рекламаций (Cj), плюс количество возвратов на доработку в эту группу (Sj). Sj — это количество объектов, возвращенных на доработку в j-тую группу. Расчёт производится за период, когда завершена процедура проверки решения инцидента, а не фактическое решение задачи. Важно учитывать возвраты индивидуально по каждой группе, так как одно обращение может быть переназначено в другую группу или возвращено несколько раз в разные группы.