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

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

Атрибуты в ABAC — это характеристики субъектов (пользователей), объектов (ресурсов), среды (время, IP-адрес, местоположение) и действий, используемые для формирования правил доступа. Примеры: должность пользователя («Менеджер»), тип объекта («Заказ»), стоимость заказа (менее 1000 руб.), филиал (совпадение филиала заказа и менеджера). Эти атрибуты проверяются в условиях правил, например, «Менеджер может редактировать заказ, если его стоимость не превышает 1000 руб. и заказ в его филиале».

Операнд Nj при расчёте First Time Resolution (FTR) для рабочих групп включает два компонента: Cj — количество обращений (инцидентов), обработанных j-той группой и закрытых без рекламаций, и Sj — количество объектов, возвращённых на доработку в эту группу. Таким образом, Nj = Cj + Sj. В знаменатель формулы FTR (Nj) попадают только те обращения, по которым завершена процедура проверки решения, а не просто фактический этап решения задачи.

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

Для адаптации модели AARM к внутренним inhouse продуктам необходимо внести следующие корректировки: Acquisition (привлечение) - измерять не количество новых пользователей, а успешность продвижения продукта внутри организации, степень вовлечения ключевых стейкхолдеров и одобрение руководства; Activation (активация) - фокусироваться на скорости и простоте внедрения продукта в рабочие процессы, времени до первой полезной реализации; Retention (удержание) - оценивать стабильность использования продукта во времени, уровень удовлетворенности внутренних клиентов, продолжительность контрактов или обязательств по использованию; Monetization (монетизация) - заменить на измерение улучшения бизнес-процессов, снижения затрат или повышения эффективности. Важно создать отдельные метрики для различных ролей (владельцы процессов, конечные пользователи, руководство) и учитывать, что спонсоры и пользователи могут иметь разные интересы. Также необходимо уделять особое внимание метрике TTV (Time-To-Value), так как для внутренних продуктов быстрое достижение ценности критично для дальнейшего поддержки и развития решения.

Чтобы преобразовать продажу товара в продажу услуги, необходимо определить, какие риски и затраты клиент может переложить на поставщика. Например, простая продажа шоколадки - это товарная модель, где клиент сам решает вопросы ее приобретения и хранения. Чтобы превратить это в услугу, можно добавить компоненты: 1) Регулярная доставка (покупатель получает шоколадку к утреннему кофе без необходимости самому ее покупать); 2) Обеспечение доступности через автомат (ресурс - сам автомат, операции - его загрузка и обслуживание). Таким образом, клиент не просто получает товар, но и перекладывает на поставщика ответственность за обеспечение доступности и своевременности получения товара, что и составляет суть услуги.

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

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

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