Основные практические рекомендации по проведению опросов с точки зрения статистической значимости результатов: 1) Для опросов с пятибалльной шкалой достаточно собрать 40-50 ответов, чтобы получить статистически значимые результаты с ошибкой 0.25-0.5 балла при 95% доверительной вероятности. 2) Превышение этой выборки дает незначительный прирост точности по сравнению с затратами на сбор дополнительных ответов. 3) Если известно, что респонденты делятся на группы с разными паттернами ответов (например, различные филиалы или категории пользователей), необходимо собрать по 40-50 ответов для каждой группы. 4) При использовании более детализированных шкал оценок (например, десятибалльной) требуется увеличить размер выборки для сохранения той же точности.

Принципиальный компромисс в ITSM заключается в исключении из области охвата управления уровнями ИТ-услуг вопросов разработки новой функциональности информационных систем. Этот подход предполагает разделение зон ответственности: Application lifecycle management (ALM) используется для разработки, а IT service management (ITSM) — для эксплуатации и сопровождения систем. Такой компромисс позволяет сосредоточиться на поддержании существующих услуг и их доступности, не беря на себя обязательства по гарантии сроков и качества новых разработок.

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

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

«Известная ошибка» (Known Error) в рамках ITIL - это документально зафиксированная проблема, корневая причина которой уже выявлена, но для которой пока не разработано постоянное решение. Вместо постоянного решения может использоваться временный обходной путь (workaround) для минимизации влияния на бизнес. Известные ошибки документируются в базе данных известных ошибок (KEDB - Known Error Database), чтобы обеспечить информацию для быстрого реагирования на аналогичные инциденты в будущем.

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

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

Зоны ответственности нужно определить так, чтобы для каждой задачи была указана конкретная группа, отвечающая за ее выполнение, а также явно прописано, где заканчивается эта зона ответственности и начинается зона другой команды. Например, в случае с CMDB можно закрепить за прикладниками ответственность за создание и поддержание связей с ПО после установки, а за инфраструктурщиками — за настройку сервера и сети. Такая фиксация в регламенте предотвратит споры о том, кто должен был выполнить работу.

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

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