Заказчики не любят платить за 'гарантию' услуг, потому что это невидимая часть сервиса, которая сама по себе не создает прямой полезности для бизнеса. Люди склонны ценить и готовы платить только за то, что они видят и непосредственно используют - например, за работоспособное приложение или доступ в интернет. Гарантия, обеспечивающая надежность, безопасность, соответствие SLA и другие параметры, проявляет себя только тогда, когда чего-то не происходит (сбоев, нарушений безопасности), и поэтому ее ценность сложно оценить. Кроме того, для оценки гарантии нужны знания и опыт, которые обычно отсутствуют у заказчиков, что делает эту часть услуги менее понятной и менее ценной в их глазах, даже несмотря на то, что без нее полезность не может быть стабильно предоставлена.

Для решения проблем требуются координаторы, отвечающие за конкретную проблему и взаимодействие со смежными группами (разработчики, архитекторы, администраторы). Координатор назначается при регистрации проблемы и отслеживает этапы диагностики, согласование решений и внедрение изменений. Эта роль отсутствует в стандартном управлении инцидентами, где ответственность обычно лежит на L2/L3 поддержке. Также в процессе прописывается контроль за деятельностью координаторов через регулярные отчёты и проверки.

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

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

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

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

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

Risk Scenarios Using COBIT 5 for Risk является расширенной версией основного документа COBIT5 for Risk и тесно связана с процессной моделью из COBIT5 Enabling Processes. Основная ценность этого документа – невероятное количество деталей, структурированно представленных в табличном формате и раскрывающих риск-сценарии, упомянутые в основной публикации. Документ предоставляет подробные описания, которые трудно найти в других источниках, и бережно раскрывает специфику каждого риск-сценария в контексте процессов управления. Такой структурированный подход позволяет глубже понять практическое применение риск-менеджмента в ИТ-среде.

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

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