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

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

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

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

Основные критерии для подтверждения связи включают: временной фактор (инцидент произошел в определенный период после выполнения изменения, обычно 24-72 часа), затронутые конфигурационные элементы (совпадение CIs, на которые влияет изменение, и CIs, по которым зарегистрирован инцидент), соответствие симптомов инцидента ожидаемому воздействию изменения, наличие технических доказательств (логи, конфигурации, скриншоты). Также важно учитывать отсутствие других факторов, которые могли бы вызвать подобный инцидент. Использование формализованной матрицы оценки с весовыми коэффициентами для каждого критерия помогает принимать объективные решения.

В 1990-х годах на рынках России популярные рекламные надписи включали такие фразы, как «Золото, доллары куплю» или «Доллары куплю / продам». Один из ярких примеров — надпись «Рассмотрю любые предложения» на лобовом стекле автомобиля около Горбушки, демонстрирующая гибкость и открытость предпринимателя к потребностям клиентов.

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

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

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

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