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

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

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

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

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

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

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

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

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

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