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

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

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

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

Правильный подход к разработке KPI в области управления ИТ заключается в построении логической цепочки: Назначение ⇒ ключевые практики ⇒ метрики ⇒ целевые и граничные значения ⇒ KPI. Первый этап подразумевает четкое определение назначения процесса и его роли в организации. На следующем этапе формулируются ключевые практики, необходимые для достижения этого назначения. Затем определяются метрики, которые будут отслеживать выполнение этих практик. Далее устанавливаются целевые и граничные значения для каждой метрики, и только на завершающем этапе формируются KPI на основе всей этой информации. Этот подход противопоставляется попыткам найти готовые KPI в интернете или литературе (например, на kpilibrary.com с более чем 6500 примерами), которые часто не соответствуют конкретным целям и особенностям организации. Главный принцип: KPI должны разрабатываться специально для решения конкретных задач вашей организации, а не браться из общих примеров.

Процесс состоит из трёх основных видов деятельности: создание статей для наполнения Базы знаний; проверка статей на актуальность, применимость и корректность; публикация и архивация статей (ввод и вывод из эксплуатации). Дополнительно существует механизм регулярного пересмотра статей по истечении срока жизни (TTL) и триггеры создания новых статей при определённых событиях.

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

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

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

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