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

Полезность (utility) — это функциональность, предлагаемая продуктом или услугой для удовлетворения конкретной потребности. Это отвечает на вопрос «то, что услуга делает». Например, услуга может обеспечивать формирование отчетов или возможность проведения видеоконференций. Гарантия (warranty) — это гарантия того, что продукт или услуга будут соответствовать согласованным требованиям. Это отвечает на вопрос «то, как услуга предоставляется». Например, это могут быть такие параметры, как скорость формирования отчетов, максимальное количество пользователей, использующих услугу, доступность услуги и другие нефункциональные характеристики.

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

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

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

Особо важными soft skills для успешного агента изменений являются широта ума, открытость, чёткость мысли и готовность к диалогу. Специалист должен быть гибким для встраивания в организацию, достаточно умным, чтобы понять сложные процессы во всех их аспектах, и достаточно мотивированным для проведения изменений. Знание методологий (таких как agile) и опыт работы важны, но могут не компенсировать отсутствие необходимых социальных навыков, таких как чуткость к команде и внимательность к реальным проблемам организации.

К CMDB в контексте управления мощностями и сервисной экономики предъявляется три основных требования. Во-первых, в CMDB должны быть построены логические модели приложений и услуг, которые включают не только физические ресурсы (оборудование и сети), но и функциональные роли ресурсов, такие как СУБД, web-сервер, файл-сервер и другие. Функциональные роли важны, так как с ними связаны единицы объёма потребления, специфичные затраты и зависимости мощности. Во-вторых, связи между элементами CMDB должны содержать атрибуты и логику, которые переносят потребность в мощностях от ресурсов верхнего уровня к поддерживающим ресурсам, а также стоимость обеспечения в обратном направлении. В-третьих, для обсчёта целевой архитектуры CMDB должна уметь оперировать не только существующими объектами и связями, но и плановыми, создавая, храня и логически отделяя сервисно-ресурсные модели, которые ещё проектируются.

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

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

Ключевые качества для агента изменений - гибкость для встраивания в общий поток изменений компании, умение осознать этот поток во всех его гранях и проявлениях как единое целое, и мотивация для проведения этого потока. Особое внимание уделяется soft skills: широта ума, открытость, чёткость, готовность к диалогу. Даже наличие знаний методологий и опыта является второстепенным, если специалист закрыт к диалогу, невнимателен к реалиям компании и не чуток к команде.