# Бесплатная экспертная база знаний по управлению ИТ

Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего. Только сведения от консультантов и тренеров Cleverics. Включает ответы на **несколько тысяч вопросов** из **сотен источников**, а также детальный глоссарий с примерами, объяснениями и нюансами

## [Что такое сопряженные метрики в управлении процессами?](https://cleverics.ru/digital/kb-qa/chto-takoe-sopryazhennye-metriki-v-upravlenii-protsessami/)

Сопряженные метрики (Tension Metrics в терминах ITIL V3) - это пары показателей, которые находятся в конфликте друг с другом. При улучшении одной метрики, при ограниченности ресурсов, неизбежно ухудшается другая метрика из этой пары. Пример: при увеличении доступности первой линии поддержки уменьшается количество обращений, решаемых на первой линии, так как операторы работают быстрее, но без должного анализа случаев, что приводит к низкому качеству решений.

Автор: Евгений Шилов

Рейтинг: 1473

Теги: ITIL, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, поддержка пользователей, Service Desk, Help Desk, постоянное улучшение, совершенствование, CSI, PDCA, управление доступностью, управление запросами на обслуживание, управление процессами, ИТ-процессы, эффективность, оптимизация

## [Что такое инфраструктурный инцидент и как он отличается от пользовательского?](https://cleverics.ru/digital/kb-qa/chto-takoe-infrastrukturnyy-intsident-i-kak-on-otlichaetsya-ot-polzovatelskogo/)

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

Автор: Евгений Шилов

Рейтинг: 1472

Теги: мониторинг, поддержка пользователей, Service Desk, Help Desk, управление запросами на обслуживание, управление инцидентами, управление конфигурациями, CMDB

## [Каким образом метрики помогают увидеть истинную картину работы процесса?](https://cleverics.ru/digital/kb-qa/kakim-obrazom-metriki-pomogayut-uvidet-istinnuyu-kartinu-raboty-protsessa/)

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

Автор: Олег Скрынник

Рейтинг: 1402

Теги: измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, управление запросами на обслуживание, эффективность, оптимизация

## [Какой баланс достигается в управлении инцидентами при использовании двух tension-метрик?](https://cleverics.ru/digital/kb-qa/kakoy-balans-dostigaetsya-v-upravlenii-intsidentami-pri-ispolzovanii-dvukh-tension-metrik/)

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

Автор: Дмитрий Исайченко

Рейтинг: 1391

Теги: измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, управление запросами на обслуживание, управление инцидентами

## [Что считается временем решения инцидента в SLA традиционно?](https://cleverics.ru/digital/kb-qa/chto-schitaetsya-vremenem-resheniya-intsidenta-v-sla-traditsionno/)

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

Автор: Евгений Шилов

Рейтинг: 1382

Теги: SLA, управление запросами на обслуживание, управление инцидентами, управление уровнем услуг, SLM

## [Какие этапы включает в себя обработка типовых ИТ-заявок?](https://cleverics.ru/digital/kb-qa/kakie-etapy-vklyuchaet-v-sebya-obrabotka-tipovykh-it-zayavok/)

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

Автор: Евгений Шилов

Рейтинг: 1365

Теги: поддержка пользователей, Service Desk, Help Desk, управление запросами на обслуживание

## [Что такое Incident Rate и как она рассчитывается?](https://cleverics.ru/digital/kb-qa/chto-takoe-incident-rate-i-kak-ona-rasschityvaetsya/)

Incident Rate — это метрика, показывающая количество пользовательских инцидентов в месяц на одного пользователя ИТ-системы. Для расчёта в числитель ставится количество обращений пользователей категории инцидент за месяц (рекомендуется брать годовую выборку с разбивкой по месяцам для исключения сезонности), а в знаменатель — количество активных пользователей ИТ (исключая уволенных сотрудников и технические учётные записи). Метрика измеряет поток пользовательских обращений, не учитываются инфраструктурные инциденты, инициированные ИТ-службой.

Автор: Дмитрий Исайченко

Рейтинг: 1346

Теги: измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, Канбан, WIP-лимиты, поддержка пользователей, Service Desk, Help Desk, управление запросами на обслуживание, управление инцидентами

## [Какие факторы необходимо учитывать при выборе способов контакта с первой линией поддержки?](https://cleverics.ru/digital/kb-qa/kakie-faktory-neobkhodimo-uchityvat-pri-vybore-sposobov-kontakta-s-pervoy-liniey-podderzhki/)

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

Автор: Евгений Шилов

Рейтинг: 1344

Теги: аллокация затрат, расчёт себестоимости услуг, бизнес, ценность, бизнес-заказчик, обучение сотрудников, учебные курсы, тренинги, поддержка пользователей, Service Desk, Help Desk, управление запросами на обслуживание, управление знаниями, управление конфигурациями, CMDB, экономика и финансы, эффективность, оптимизация

## [Каким образом пользователи адаптировались к работе с ИТ-поддержкой и какие навыки они приобрели?](https://cleverics.ru/digital/kb-qa/kakim-obrazom-polzovateli-adaptirovalis-k-rabote-s-it-podderzhkoy-i-kakie-navyki-oni-priobreli/)

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

Автор: Михаил Тобурдановский

Рейтинг: 1341

Теги: поддержка пользователей, Service Desk, Help Desk, управление запросами на обслуживание, управление продуктами, продуктовый подход, управление процессами, ИТ-процессы, управление релизами

## [Для чего используется статус 'Ожидание' в системах управления инцидентами и заданиями?](https://cleverics.ru/digital/kb-qa/dlya-chego-ispolzuetsya-status-ozhidanie-v-sistemakh-upravleniya-intsidentami-i-zadaniyami/)

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

Автор: Евгений Шилов

Рейтинг: 1326

Теги: DevOps, CI/CD, поддержка пользователей, Service Desk, Help Desk, управление запросами на обслуживание, управление инцидентами, управление процессами, ИТ-процессы