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

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

## [Как системная структура объясняет проблему низкой доли инцидентов, связанных с открытыми проблемами, и её влияние на удовлетворённость пользователей?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-intsidentov-svyazannykh-s-otkrytymi-problem/)

Системная структура объясняет проблему низкой доли инцидентов, связанных с открытыми проблемами, и её влияние на удовлетворённость пользователей через эффективность «лаборатории».  Механизм: 1. Доля инцидентов, связанных с открытыми проблемами, характеризует, насколько эффективно процесс управления проблемами выявляет и регистрирует корневые причины инцидентов. 2. Низкая доля означает, что многие инциденты не связываются с известными проблемами. 3. Это влияет на удовлетворённость пользователей:    - Инциденты решаются без использования стандартных решений — MTRS растёт.    - Инциденты повторяются — пользователи страдают от одних и тех же проблем.    - Пользователи разочарованы качеством поддержки. 4. Низкая удовлетворённость, в свою очередь:    - Усиливает давление бизнеса на ИТ.    - Приводит к жалобам и эскалациям.    - Снижает доверие к ИТ.    - Формирует негативное восприятие ИТ-услуг.  Факторы, влияющие на низкую долю:  1. **Недостаточный анализ инцидентов.** Инциденты закрываются без анализа корневой причины. 2. **Недостаточные ресурсы управления проблемами.** Аналитики не успевают. 3. **Отсутствие интеграции.** Система обработки инцидентов не связана с системой управления проблемами. 4. **Недостаточная квалификация.** Аналитики не обладают навыками. 5. **Отсутствие стимулов.** KPI фокусируются на MTRS, а не на связывании инцидентов с проблемами.  Системная структура показывает, что доля инцидентов, связанных с открытыми проблемами, — это индикатор эффективности «лаборатории» и фактор, напрямую влияющий на удовлетворённость пользователей. Улучшение требует улучшения анализа инцидентов, выделения ресурсов на управление проблемами и развития интеграции между процессами.

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

Рейтинг: 50

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

## [Как связать модель работы ИТ-команды с бизнес-целями компании?](https://cleverics.ru/digital/kb-qa/kak-svyazat-model-raboty-it-komandy-s-biznes-tselyami-kompanii/)

Модель работы ИТ-команды следует связывать с бизнесом компании через таблицу в стиле «что, если». Например: что, если не наблюдать за нагрузкой? Что, если не обрабатывать инциденты? Такой подход позволяет наглядно показать бизнесу последствия отсутствия тех или иных процессов и обосновать необходимость определённых ИТ-активностей. Общая картина работы команды должна быть доведена до сведения всех сотрудников: рекомендуется сделать плакат и поместить его на видном месте, ссылаться на него при решении организационных вопросов.

Автор: Роман Журавлёв

Рейтинг: 48

Теги: бизнес, ценность, бизнес-заказчик, командная работа, управление инцидентами

## [Что такое время реакции на инцидент и почему его важно измерять?](https://cleverics.ru/digital/kb-qa/chto-takoe-vremya-reaktsii-na-intsident-i-pochemu-ego-vazhno-izmeryat/)

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

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

Рейтинг: 40

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