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

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

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

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

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

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

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

В управлении доступностью (AVA) основными показателями выступают: - MTRS (среднее время восстановления услуги) - MTBF (среднее время между сбоями) - MTBSI (среднее время между инцидентами) Эти показатели связаны со статистикой и тенденциями сбоев в работе ИТ-систем. В управлении непрерывностью (CONT) используются: - RTO (recovery time objective) — целевое время восстановления - RPO (recovery point objective) — целевая точка восстановления RTO показывает, за какое время после сбоя должно быть возобновлено предоставление услуги, а RPO указывает, какой период данных может быть потерян без критического ущерба для бизнеса.

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

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