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

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

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

Nj не может включать все обработанные обращения, потому что в расчёт должна включаться только завершённая работа — обращения, по которым процедура проверки решения полностью завершена. Это могут быть закрытые без рекламаций инциденты или те, которые были возвращены на доработку (Sj). Если включить в Nj все обработанные обращения, в том числе те, где процесс проверки не завершён, это исказит метрику FTR, так как не отразит реальное качество работы группы.

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

Альтернативный алгоритм снижает влияние действий других групп путём нормировки не на общее время обработки инцидента Ti, а на установленный срок решения инцидента Ti0. Весовой коэффициент wi для просроченных инцидентов определяется как отношение времени обработки силами данной группы (ti) к сроку решения (Ti0), но не менее 1. Рейтинг ответственности ri рассчитывается по формуле: ri = (ti/Ti0) * (1 - 1/wi) для просроченных инцидентов и ri=0 для решенных в срок. Это позволяет точнее учитывать вклад конкретной группы в просрочку, исключая искажающее влияние задержек на этапах, где данная группа не участвовала.

99,9% доступности может быть недостаточно для бизнес-процессов по нескольким причинам. Во-первых, этот показатель не учитывает распределение простоя: 0,1% от года составляет около 8,76 часов, что может быть критично, если эти часы приходятся на пиковую нагрузку. Во-вторых, для некоторых бизнес-процессов (например, финтех, здравоохранение) даже короткие простои могут привести к серьезным последствиям. В-третьих, бизнес зачастую зависит от непрерывности процессов: если 8,76 часов простоев приходятся на один раз, это может привести к утрате контрактов и репутационному ущербу, чего не отражает процентный показатель. В-четвертых, заказчик и поставщик услуг могут по-разному интерпретировать этот показатель (в год, месяц, неделю), что создает неопределенность.

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

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

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