Затраты на персонал составляют 40-60% операционных затрат на ИТ в российских компаниях. В западных компаниях этот показатель ниже — 30-40%, что связано с более широким использованием аутсорсинга и в среднем более высокой эффективностью труда сотрудников ИТ-подразделений.

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

Три основных принципа, помогающие интегрировать деятельность по развитию в повседневную работу компании: 1) Деятельность по развитию должна быть обязательной и «встроенной» в обычную ежедневную работу почти каждого сотрудника, поскольку возможности для улучшений появляются каждый день. 2) Время на развитие должно быть чётко определено и выделено явным образом, как часть работы. 3) Необходимо не позволять сотрудникам заменять выделенное время на развитие операционными задачами, поскольку рутина стремится занять всё доступное время.

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

Для корректного отображения зависимости ИТ-сервиса от канала связи между площадками рекомендуется ввести логическую суррогатную конфигурационную единицу (например, 'App. Data Exchange'), которая будет ассоциироваться со всеми компонентами, участвующими в обмене данными: каналом связи, сетевым оборудованием и соответствующими интерфейсами ИТ-систем. Эта единица затем связывается с ИТ-сервисом, демонстрируя критически важную зависимость. Такой подход позволяет избежать перегрузки диаграммы прямых связей и четко выделить компоненты, влияющие на качество сервиса.

Интеграция ITIL и Agile требует понимания того, что эти подходы дополняют друг друга, а не противоречат. ITIL фокусируется на стабильности и качестве ИТ-услуг, а Agile - на скорости и гибкости разработки. Для успешной интеграции: во-первых, определите зоны ответственности - ITIL для управления эксплуатацией и поддержкой услуг, Agile для разработки и внедрения новых функциональных возможностей. Создайте совместные процессы для перехода разработки в эксплуатацию (DevOps-практики). Адаптируйте процесс управления изменениями ITIL, чтобы учитывать частые релизы Agile-команд, внедрив стратегию мелких, низкорисковых изменений. Синхронизируйте циклы планирования - совмещайте ритм ITIL (ежеквартальное планирование услуг) с спринтами Agile (2-4 недели). Используйте общий инструмент управления работой, поддерживающий как ITIL-процессы, так и Agile-методологии. Проведите обучение для обеих команд, чтобы они понимали принципы и ограничения друг друга. Внедрите общие метрики, оценивающие как стабильность, так и скорость внедрения изменений. Создайте мостовые роли, например, менеджер по внедрению, который будет координировать работу между Agile-командами и службой поддержки.

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

В PIR применяются количественные и качественные критерии: соблюдение бюджета и сроков, достижение целевых метрик (например, рост производительности на 15%), уровень удовлетворенности пользователей, соответствие требованиям и анализ рисков. Также оцениваются непредвиденные последствия и влияние на другие процессы. Для каждого критерия устанавливаются пороговые значения, и на основе их сравнения с фактическими результатами определяется успешность внедрения.

При переходе к гибкому управлению ИТ-разработкой необходимы стандарты, которые четко описывают, что организация считает нормальной работой. Это включает стандарты постановки запросов от бизнеса на ИТ-разработку, чтобы команда фокусировалась на создании решений с бизнес-ценностью. Требуются стандарты и KPI для оценки эффективности ресурсов, так как часто до 80% трудовых ресурсов расходуется впустую, а эти специалисты могли бы быть перераспределены между командами с дефицитом кадров. Также необходимы стандарты, определяющие допустимый уровень дефектов, так как часто показатель от 15% до 50% дефектов в объеме работ ошибочно считается нормой, что означает, что половина работы делается заново. Все сотрудники, как со стороны бизнеса, так и со стороны ИТ-департамента, должны стремиться к соблюдению этих стандартов.

TTV (Time-To-Value) - это метрика, измеряющая скорость и простоту всех шагов, необходимых для того, чтобы пользователь или заказчик получил ценность от продукта после проявления первоначального интереса. Эта метрика включает время на пробную версию, внедрение продукта и достижение первых результатов от его использования. TTV важен, потому что чем быстрее заказчик увидит пользу от продукта, тем выше вероятность его успешного внедрения и удержания. Для многих продуктов, особенно B2B и корпоративных, внедрение составляет значительную часть общей стоимости владения (TCO), поэтому оптимизация этого процесса становится критически важной характеристикой продукта. Сокращение TTV позволяет улучшить пользовательский опыт, увеличить удовлетворенность и повысить показатели Retention. Эта метрика особенно важна для enterprise-продуктов, где время внедрения может измеряться месяцами и значительно влиять на восприятие продукта заказчиком.