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

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

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

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

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

Менеджеры проектов чаще выделены, чем менеджеры ИТ-процессов, потому что проекты имеют четкие сроки, цели и результаты, что делает их более заметными и контролируемыми для бизнеса. Организации часто сосредотачиваются на краткосрочных задачах и достижении конкретных результатов, тогда как управленческая работа над процессами воспринимается как фоновая и менее приоритетная. Кроме того, реализация проектов может напрямую коррелировать с доходами или конкурентными преимуществами, что приводит к выделению ресурсов на управление проектами. В то же время процессное управление часто рассматривается как поддерживающая функция без явного «кейса» для бизнес-лидера.

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

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

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

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