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

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

FTR (First Time Resolution) — это показатель, представляющий долю инцидентов, решенных с первого раза без необходимости переделок или доработок. Снижение FTR негативно влияет на процесс управления инцидентами,因为它 указывает на то, что решения не проходят достаточной проверки или не полностью устраняют проблему, что приводит к необходимости повторного рассмотрения инцидентов. Это увеличивает нагрузку на службу поддержки, снижает рациональность процесса, ухудшает показатели эффективности и может негативно сказываться на удовлетворенности клиентов.

PCF (Process Classification Framework) - это открытый стандарт, межотраслевая процессная модель, не привязанная к области деятельности предприятия или сектору промышленности, не зависящая от его размера и местоположения. Он представляет собой общую структуру процессов для любых предприятий, изначально задуманную для систематизации бизнес-процессов и определения общего языка. PCF позволяет идентифицировать процессы на предприятии, используя уже наработанный и накопленный опыт многих компаний; сравнивать между собой эффективность процессов, выполняющихся в разных организациях; заниматься реинжинирингом и совершенствовать процессы. Модель была разработана в 1992 году Американским центром эффективности и качества (APQC), который продолжает поддерживать и развивать её. Текущая версия PCF - 6.1.0 от марта 2014 года.

BPO (Business Process Outsourcing) — это вид аутсорсинга, при котором поставщику передаются исполнение и ответственность за целую бизнес-функцию или процесс. В отличие от обычного аутсорсинга задач, где на сторону передаются отдельные проекты с ограниченными сроками и бюджетом, BPO предполагает долгосрочное сотрудничество без жестких временных рамок и фиксированного бюджета. Организация передает аутсорсеру замкнутую функциональную область, а не отдельные задачи. Это более глубокая форма аутсорсинга, требующая тесного взаимодействия между заказчиком и исполнителем.

CAB (Change Advisory Board) - это комитет по изменениям, ответственный за информирование и governance в части проведения масштабных, сложных и многосвязных изменений в гетерогенной, территориально распределенной инфраструктуре. Основная функция CAB заключается в управлении и надзоре над выполнением изменений и проектов там, где в регулярных работах участвуют множество подрядчиков и развит аутсорсинг. В компаниях с использованием ресурсов различных юридических лиц, например, в рамках холдингов, CAB помогает обеспечить стабильность в сложном окружении через планирование, контроль и оценку изменений.

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

Среднее время поставки (Lead time) — это временной интервал, необходимый для выполнения запроса пользователя или внедрения изменения в систему, начиная с момента его поступления и до завершения обработки. Это ключевая метрика, так как она определяет скорость реакции системы на запросы клиентов и сотрудников, влияет на удовлетворённость пользователей и эффективность бизнес-процессов. Слишком длительное время приводит к потерям: клиенты уходят, сделки срываются, снижается конверсия. Эталонные команды разработки стремятся уложиться в часы, а хорошие — в дни, что подчеркивает важность минимизации Lead time.

Ролевое управление доступом (RBAC, Role Based Access Control) — это модель предоставления доступа, при которой весь доступ к информационным системам и ресурсам предоставляется только через роли. Роль представляет собой набор прав доступа. Пользователи получают доступ к системам и ресурсам исключительно через присвоенные им роли. Это означает, что права не закрепляются напрямую за пользователями, а устанавливаются через назначенные роли. Такая модель позволяет упростить управление доступом, особенно в крупных организациях, группируя права в логические наборы и привязывая их к должностям или функциональным обязанностям сотрудников.

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