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

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

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

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

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

Рейтинг: 70

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

## [Что делать, если бизнес задаёт вопрос «сколько стоит среднестатистическая фича»?](https://cleverics.ru/digital/kb-qa/chto-delat-esli-biznes-zadaet-vopros-skolko-stoit-srednestatisticheskaya-ficha/)

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

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

Рейтинг: 62

Теги: бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, командная работа