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

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

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

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

Для определения опережающих показателей используется анализ причинно-следственных связей через Causal Loop Diagram. Опережающие показатели находятся на ранних этапах причинно-следственной цепочки и влияют на конечные результаты. Например, для прогнозирования успеха процесса изменений опережающими показателями могут служить Release size (размер релиза), Emergency change rate (доля аварийных изменений), Backlog size / Queue Time (управление бэклогом), Standard Change Rate (уровень стандартизации). Эти показатели позволяют прогнозировать такие конечные результаты, как Change Risk (риск изменений) и Time to Market (время выхода на рынок) до того, как эти результаты будут фактически достигнуты или проблемы проявятся.

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

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

При правильной организации учета трудозатрат по 20-25 работам, учитывая, что не все сотрудники участвуют во всех работах и не все задачи выполняются ежедневно, специалист тратит примерно 10 минут в день на учет своей деятельности, что составляет около 2% рабочего времени. Для линейного руководителя, который, кроме своих задач, осуществляет контроль за трудозатратами подчиненных, эта цифра составляет около 5% рабочего времени. Эти показатели вполне приемлемы в контексте управленческих расходов. Более того, регулярный онлайн-учет времени занимает меньше времени, чем попытки вспомнить и зафиксировать пройденные события в конце недели. Своевременная фиксация работы сразу после ее завершения или в конце рабочего дня обеспечивает не только большую точность данных, но и экономит время по сравнению с еженедельным учетом.

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

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