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

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

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

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

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

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

Наличие дефектов негативно влияет как на бизнес, так и на процесс разработки. Со временем дефекты приводят к экспоненциальному росту потерь - в примере из деловой игры 'Проект Феникс' потери составили 2 000 долларов в первом раунде, 26 000 во втором и 39 000 в третьем. Наличие дефектов замедляет разработку новых функций, так как разработчики вынуждены тратить время на исправление ошибок, и создает технический долг, который становится все дороже в исправлении. Для бизнеса это трансформируется в прямые финансовые потери и ухудшение качества продукта, что отражается на удовлетворенности клиентов.

Service Owner активно участвует в обсуждении и разработке SLA (уровней сервиса) и OLA (внутренних уровней сервиса), выступая от имени бизнеса при переговорах. Он обеспечивает, что SLA корректно отражают бизнес-требования и ожидания, а OLA поддерживают достижение внешних SLA. При этом Service Owner контролирует выполнение SLA и OLA и выступает в роли посредника при возникновении расхождений между ожиданиями и реальным уровнем сервиса.

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

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