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

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

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

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

Модель 'as-a-Service' помогает четко разделить товар и услугу, акцентируя внимание на том, что клиент покупает не просто продукт, а доступ к функциональности с перекладыванием определенных рисков и затрат на поставщика. Например, если рассматривать Chocolate-as-a-Service, клиент получает не просто шоколадку, а регулярную доставку, обеспечение свежести, решение вопросов с доступностью - поставщик берет на себя ответственность за эти аспекты. Аналогично в ИТ: SaaS (Software-as-a-Service) означает, что клиент использует программное обеспечение без необходимости его установки и обслуживания - эти функции берет на себя поставщик. Основная идея в том, что при использовании модели 'as-a-Service' клиент получает конечную ценность без несения полной ответственности за поддержку инфраструктуры или процессов.

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

Роль "Практик изменений" в ITIL V3 частично соответствует понятию "Координатор изменений", используемому на практике, но не в полной мере. В описании обязанностей практика изменений упоминаются мониторинг и проверка (reviewing) корректности выполнения работ по изменению, но не прямо указана задача по координации действий участников. Координация изменений упоминается в ITIL не в разделе про роли, а в описании активностей процесса, и её выполнение может быть возложено на разные лица: менеджера процесса, практика изменений или участников CAB. Поэтому многие организации на практике выделяют отдельную роль координатора изменений для обеспечения сквозной ответственности, что не формализовано в самом стандарте ITIL.

Согласованность между бизнес-целями и целями процессов в ITIL обеспечивается через: - Чёткую связь при проектировании: цели процессов обязательно должны вытекать из бизнес-требований и проектного обоснования. - Единые KPI: выбор метрик, которые измеряют как выполнение бизнес-целей, так и оперативные результаты процессов. - Регулярный пересмотр: владельцы процессов должны сверять цели с бизнес-приоритетами перед каждым планирующим периодом. - Документирование взаимосвязей: в картах целевых показателей или матрицах ответственности фиксируется, как каждая цель процесса поддерживает стратегические задачи организации. - Диалог с заинтересованными сторонами: владельцы процессов взаимодействуют с бизнес-представителями для актуализации целей и оценки их соответствия текущим приоритетам.

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

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