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

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

Для создания системы оценки нужно построить матрицу взаимодействия функций и процессов. В этой матрице вертикаль представляет собой функции (отделы или группы), а горизонталь — процессы. Если функция участвует в процессе, руководитель этой функции отвечает за предоставление ресурсов. Для оценки используется система метрик, которые отражают эффективность работы сотрудников под руководством данного руководителя в контексте процесса. Например, для руководителя отдела в сфере управления инцидентами могут использоваться такие показатели как доля заданий, выполненных в срок; доля инцидентов, принятых в работу своевременно; доля инцидентов, решенных в срок и с первой попытки; коэффициент обновления по проблемам. Эти показатели приводятся к сопоставимому виду (шкала от 0 до 1), после чего формируется итоговый рейтинг руководителя с помощью арифметического, геометрического или взвешенного среднего. На более высоких уровнях управления агрегируются рейтинги нижестоящих руководителей.

Наличие буквы A (Accountable) в RACI-матрице означает, что человек является ответственным за конечный результат работы, что подразумевает наличие не только полномочий, но и реальных механизмов контроля. Без таких механизмов ответственность становится формальной, так как невозможно гарантировать качество и своевременность выполнения задачи. Поэтому при обнаружении символа A важно сразу определить, какими конкретными инструментами и ресурсами будет обеспечиваться контроль. Это может быть отдельная система отчетности, регулярные встречи, специальные программные инструменты мониторинга или другие методы. Если консультанты при составлении матрицы не предусмотрели эти механизмы, у руководителя есть возможность потребовать их предоставления до окончательного утверждения матрицы.

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

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

Потребности (Север) и желания (Запад) различаются по своей значимости и обязательности для клиента. Потребности - это базовые, необходимые условия, без которых услуга не будет считаться полезной или приемлемой. Например, для услуги такси необходимым является именно перемещение от точки А до точки Б. Желания же - это дополнительные элементы, которые при наличии повышают удовлетворённость, но их отсутствие не делает услугу непригодной. Например, вежливый водитель или приятная музыка в такси являются желаниями. Понимание этой разницы помогает правильно расставлять приоритеты в развитии сервиса: потребности должны быть обеспечены в первую очередь как основа, а желания могут быть использованы как дифференцирующие факторы для превосходства над конкурентами.

Управление инцидентами направлено на оперативное восстановление услуги после негативного события (реализовавшегося риска), тогда как управление проблемами фокусируется на выявлении и устранении корневой причины этого события, чтобы предотвратить его повторение. Таким образом, первое решает текущую ситуацию, второе — предотвращает будущие сбои.

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

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