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

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

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

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

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

Рейтинг: 60

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

## [Какие дополнительные контроли вводятся в банках при отсутствии полноценной системы ITSM?](https://cleverics.ru/digital/kb-qa/kakie-dopolnitelnye-kontroli-vvodyatsya-v-bankakh-pri-otsutstvii-polnotsennoy-sistemy-itsm/)

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

Автор: Лариса Будкова

Рейтинг: 58

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

## [Какова типовая ёмкость трудового ресурса для сотрудников, работающих в режиме 8×5, при годовом планировании?](https://cleverics.ru/digital/kb-qa/kakova-tipovaya-emkost-trudovogo-resursa-dlya-sotrudnikov-rabotayushchikh-v-rezhime-8-5-pri-godovom/)

Для сотрудников, работающих в режиме 8×5, ёмкость ресурса при годовом планировании часто принимается равной 1 830 часам в год, рассчитанной на основании утверждённого производственного календаря.

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

Рейтинг: 55

Теги: общие вопросы менеджмента

## [При каких условиях водопадная модель разработки позволяет получать качественные результаты?](https://cleverics.ru/digital/kb-qa/pri-kakikh-usloviyakh-vodopadnaya-model-razrabotki-pozvolyaet-poluchat-kachestvennye-rezultaty/)

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

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

Рейтинг: 50

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

## [Каково назначение процесса управления инцидентами и запросами пользователей?](https://cleverics.ru/digital/kb-qa/kakovo-naznachenie-protsessa-upravleniya-intsidentami-i-zaprosami-polzovateley/)

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

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

Рейтинг: 50

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

## [Какие показатели используются для оценки результативности процесса управления инцидентами и запросами пользователей?](https://cleverics.ru/digital/kb-qa/kakie-pokazateli-ispolzuyutsya-dlya-otsenki-rezultativnosti-protsessa-upravleniya-intsidentami-i-zap/)

Для оценки результативности процесса используются три показателя: TPI (Timely Processing Index) — своевременность обработки инцидентов и запросов по процессу в целом и с разбивкой по группам, оценивается менеджером процесса и руководителями групп поддержки; MTRS (Mean Time To Restore Service) — среднее время устранения инцидентов, оценивается менеджером процесса и руководителями групп поддержки; CSI (Customer Satisfaction Index) — удовлетворённость пользователей качеством поддержки, оценивается менеджером процесса и руководителями групп поддержки.

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

Рейтинг: 50

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

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

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

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

Рейтинг: 50

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

## [Как системная структура объясняет проблему низкой доли инцидентов, связанных с открытыми проблемами, и её влияние на удовлетворённость пользователей?](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-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-obrashcheniy-reshennykh-s-primeneniem-bazy/)

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

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

Рейтинг: 50

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

## [Каково назначение процесса управления уровнем IT-услуг (SLM)?](https://cleverics.ru/digital/kb-qa/kakovo-naznachenie-protsessa-upravleniya-urovnem-it-uslug-slm/)

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

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

Рейтинг: 50

Теги: аутсорсинг, интеграция услуг, общие вопросы менеджмента, постоянное улучшение, совершенствование, CSI, PDCA, управление уровнем услуг, SLM