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

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

Для связи ИТ-метрик с бизнес-целями следует заменить показатели, фокусирующиеся только на выходах, на метрики, влияющие на результаты. Вместо 'времени ответа на запрос' измерять 'рост NPS клиентов', вместо 'количества релизов' - 'ускорение вывода продукта на рынок'. Хороший пример - компания Ford, которая заменила KPI 'количество строк кода' на 'снижение времени сборки авто', повысив эффективность ИТ на 200%. Необходимо всегда проверять, как технические метрики влияют на конечные бизнес-результаты и перестроить систему отчетности и поощрений вокруг этих результатов.

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

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

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

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

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

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

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