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

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

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

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

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

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

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

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

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

Мандатная модель (MAC) предполагает жёсткую привязку пользователей и информации к уровням допуска (например, 'секретно', 'совершенно секретно'). Все ресурсы одного уровня автоматически доступны всем, у кого есть мандат на этот уровень. Основной недостаток — негибкость: добавление новых классов секретности усложняет систему. Дискреционная модель (DAC) настраивает доступ на уровне отдельных объектов и операций для каждого пользователя через матрицу разрешений (таблицы доступа). Это даёт максимальную детализацию, но требует громоздкого администрирования при росте системы. Ролевая модель (RBAC) группирует права в бизнес-роли (например, 'бухгалтер', 'менеджер'). Пользователи получают доступ через назначение ролей, а не прямое управление объектами. Это сочетает структурированность (как в MAC) и управляемость (лучше, чем в DAC), так как изменения в правах вносятся на уровне ролей, а не пользователей. RBAC также поддерживает иерархию ролей и разделение полномочий, что недоступно в других моделях.