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

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

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

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

Примеры неочевидных ограничений включают запрет установки Adobe Reader на сервер при бесплатном использовании, ограничение на использование Infranviewer только в некоммерческих целях (т.е. дома, а не в офисе), и другие неочевидные условия, которые могут быть обнаружены при подробном изучении лицензионных соглашений.

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

Задачи процесса в ITIL определяются менеджером процесса и закрепляются следующим образом: - Формулировка: описание конкретных функций, которые должен выполнять процесс для соответствия назначению и достижения целей (например, "организация накопления знаний по устранению инцидентов"). - Связь с метриками: указание показателей для контроля выполнения задач. - Документирование: задачи фиксируются в регламенте процесса, так как они меняются реже целей и отражают устоявшуюся технологию. - Ролевая ответственность: менеджер процесса несёт ответственность за актуальность задач, дизайнер процесса консультирует по их соответствию назначению. Пример: для процесса управления проблемами задачей может быть "предоставление обходных решений инцидентов в службу поддержки для сокращения времени простоя".

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

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

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