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

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

## [Как в процессах ITIL решается вопрос выбора значимых рисков?](https://cleverics.ru/digital/kb-qa/kak-v-protsessakh-itil-reshaetsya-vopros-vybora-znachimykh-riskov/)

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

Автор: Константин Нарыжный

Рейтинг: 815

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

## [Какие различия существуют между понятиями Business-as-usual и форс-мажор в контексте управления ИТ-услугами?](https://cleverics.ru/digital/kb-qa/kakie-razlichiya-sushchestvuyut-mezhdu-ponyatiyami-business-as-usual-i-fors-mazhor-v-kontekste-uprav/)

Business-as-usual относится к обыденным, обычным операциям и сбоям, которые происходят в рамках обычной деятельности организации и рассматриваются в управлении доступностью (AVA). К ним относятся типичные технические проблемы, небольшие простои, отдельные сбои компонентов. Форс-мажорные обстоятельства — это экстремальные события, такие как пожары, наводнения, теракты или масштабные катастрофы, которые выходят за рамки обычной деятельности и рассматриваются в управлении непрерывностью (CONT). Эти события потенциально приводят к значительному ущербу и требуют специальных процедур и резервных ресурсов для восстановления бизнес-процессов.

Автор: Павел Дёмин

Рейтинг: 815

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

## [Какой аналогичный процесс используется для иллюстрации поэтапного внедрения SLM?](https://cleverics.ru/digital/kb-qa/kakoy-analogichnyy-protsess-ispolzuetsya-dlya-illyustratsii-poetapnogo-vnedreniya-slm/)

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

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

Рейтинг: 815

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

## [Что такое MS (Marginal Score) и какую роль он играет в агрегировании KPI?](https://cleverics.ru/digital/kb-qa/chto-takoe-ms-marginal-score-i-kakuyu-rol-on-igraet-v-agregirovanii-kpi/)

MS (Marginal Score) – это параметр, который определяет, какое значение должен получить интегральный показатель, если все KPI равны 100%, а один KPI равен 0% (то есть одна область ответственности полностью провалена). Например, если у сотрудника 10 KPI и руководитель выбрал MS = 50%, это означает, что при провале одного из показателей интегральная оценка снизится до 50%, а не до 90% как при среднем арифметическом. MS используется для настройки жесткости системы оценки и определяет, насколько серьезно учитывается провал по отдельному показателю.

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

Рейтинг: 814

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

## [В чем заключается основная проблема ручного вмешательства в запущенные узлы и как её решить?](https://cleverics.ru/digital/kb-qa/v-chem-zaklyuchaetsya-osnovnaya-problema-ruchnogo-vmeshatelstva-v-zapushchennye-uzly-i-kak-ee-reshit/)

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

Автор: Андрей Труфанов

Рейтинг: 814

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

## [Какие существуют критерии определения недоступности для услуг, связанных с работами или сервисными операциями?](https://cleverics.ru/digital/kb-qa/kakie-sushchestvuyut-kriterii-opredeleniya-nedostupnosti-dlya-uslug-svyazannykh-s-rabotami-ili-servi/)

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

Автор: Андрей Труфанов

Рейтинг: 814

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

## [Почему решения по экстенсивному привлечению ресурсов оказались неэффективными в данной ситуации?](https://cleverics.ru/digital/kb-qa/pochemu-resheniya-po-ekstensivnomu-privlecheniyu-resursov-okazalis-neeffektivnymi-v-dannoy-situatsii/)

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

Автор: Андрей Труфанов

Рейтинг: 814

Теги: архитектура ИТ, TOGAF и IT4IT, командная работа, управление отношениями, взаимодействие, BRM, управление проблемами

## [Стоит ли считать миграцию системой решения проблем в ИТ?](https://cleverics.ru/digital/kb-qa/stoit-li-schitat-migratsiyu-sistemoy-resheniya-problem-v-it/)

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

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

Рейтинг: 814

Теги: автоматизация ИТ-процессов, ПО для ITSM и ESM, обучение сотрудников, учебные курсы, тренинги, управление проблемами, эффективность, оптимизация

## [Какую роль играет документирование при закрытии инцидента?](https://cleverics.ru/digital/kb-qa/kakuyu-rol-igraet-dokumentirovanie-pri-zakrytii-intsidenta/)

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

Автор: Дмитрий Подольский

Рейтинг: 814

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

## [Как обеспечить бизнесу возможность влиять на условия SLA после его первоначального внедрения?](https://cleverics.ru/digital/kb-qa/kak-obespechit-biznesu-vozmozhnost-vliyat-na-usloviya-sla-posle-ego-pervonachalnogo-vnedreniya/)

Бизнесу предоставляется механизм взаимодействия, позволяющий по их собственной инициативе пересматривать соглашение. Конкретные заказчики могут заключать дополнительные соглашения по конкретным ИТ-сервисам, которые будут изменять положения общего SLA 'AS IS'. Это дает бизнес-подразделениям возможность выразить свои требования и скорректировать условия обслуживания под свои потребности, но при этом не блокирует старт процесса согласованием со всеми заинтересованными сторонами.

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

Рейтинг: 814

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