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

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

## [Почему для значительных инцидентов необходима отдельная процедура обработки?](https://cleverics.ru/digital/kb-qa/pochemu-dlya-znachitelnykh-intsidentov-neobkhodima-otdelnaya-protsedura-obrabotki/)

Для значительных инцидентов необходима отдельная процедура обработки, поскольку обычные процедуры управления инцидентами оказываются неэффективными в ситуациях с большим масштабом воздействия и сложной координацией между множеством подразделений. Стандарт ISO/IEC 20000:2011 требует, чтобы поставщик услуг разработал документированную процедуру для обработки значительных инцидентов, включая назначение ответственного лица, уведомление топ-менеджмента и проведение анализа после восстановления услуг. Это связано с необходимостью специальных мероприятий для восстановления работы большого числа пользователей, координации действий различных отделов (ИТ, административного, информационной безопасности, связи) и обработки массовых обращений.

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

Рейтинг: 1179

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

## [Какие примеры из IT иллюстрируют разницу между Output и Outcome?](https://cleverics.ru/digital/kb-qa/kakie-primery-iz-it-illyustriruyut-raznitsu-mezhdu-output-i-outcome/)

В IT примером Output может быть разработанное приложение или программный продукт, запущенный в эксплуатацию. Outcome — это удовлетворение потребности клиента за счёт использования этого приложения: например, повышение производительности или упрощение рабочих процессов. Если клиент не использует приложение, несмотря на его техническую готовность (output), то желаемый outcome не достигнут, и необходимо пересмотреть сам продукт.

Автор: Александр Движков

Рейтинг: 1179

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

## [Как комбинирование RBAC и ABAC улучшает управление доступом?](https://cleverics.ru/digital/kb-qa/kak-kombinirovanie-rbac-i-abac-uluchshaet-upravlenie-dostupom/)

Комбинирование RBAC и ABAC позволяет сохранить структурированность ролевой модели и добавить динамические условия проверки доступа. Например, роль «Менеджер» может быть дополнена правилом ABAC, ограничивающим редактирование заказов только при соблюдении условий: стоимость заказа не превышает 1000 руб., заказ находится в филиале менеджера. Это делает систему более гибкой, так как роли становятся контекстно-зависимыми, но при этом остаётся удобной для аудита благодаря явному разделению прав по ролям.

Автор: Александр Омельченко

Рейтинг: 1179

Теги: аудит, общие вопросы менеджмента, управление доступом, IDM, ролевые модели, RBAC, ABAC, управление процессами, ИТ-процессы

## [Какие основные недостатки классического показателя доступности ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-nedostatki-klassicheskogo-pokazatelya-dostupnosti-it-uslug/)

Классический показатель доступности, выражаемый как (AST - DT)/AST, имеет несколько существенных недостатков. Прежде всего, он не учитывает распределение простоев во времени: 9 часов непрерывного простоя в году эквивалентны 9-ти отдельным 1-часовым простоям с точки зрения процентного значения, тогда как бизнес-потери в этих случаях будут сильно различаться. Во-вторых, показатель не отражает влияние на бизнес-процессы, так как процент не показывает реальный ущерб от простоя. В-третьих, возникает неоднозначность при интерпретации: 99,9% может быть интерпретировано как 9 часов простоя в год или как 45 минут в месяц, что не всегда соответствует ожиданиям заказчика и провайдера.

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

Рейтинг: 1179

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

## [Как определить, может ли изменение быть стандартизировано и выполняться как запрос на обслуживание?](https://cleverics.ru/digital/kb-qa/kak-opredelit-mozhet-li-izmenenie-byt-standartizirovano-i-vypolnyatsya-kak-zapros-na-obsluzhivanie/)

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

Автор: Артём Мукосеев

Рейтинг: 1179

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

## [В чем заключается разница между операционной деятельностью ИТ и управлением ИТ-услугами?](https://cleverics.ru/digital/kb-qa/v-chem-zaklyuchaetsya-raznitsa-mezhdu-operatsionnoy-deyatelnostyu-it-i-upravleniem-it-uslugami/)

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

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

Рейтинг: 1179

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

## [Кто должен принимать решение об объявлении инцидента значительным?](https://cleverics.ru/digital/kb-qa/kto-dolzhen-prinimat-reshenie-ob-obyavlenii-intsidenta-znachitelnym/)

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

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

Рейтинг: 1179

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

## [Как измерить эффективность работы по управлению проблемами?](https://cleverics.ru/digital/kb-qa/kak-izmerit-effektivnost-raboty-po-upravleniyu-problemami/)

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

Автор: Игорь Фадеев

Рейтинг: 1179

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

## [Какие метрики должны использоваться для оценки выполнения целей процесса в ITIL?](https://cleverics.ru/digital/kb-qa/kakie-metriki-dolzhny-ispolzovatsya-dlya-otsenki-vypolneniya-tseley-protsessa-v-itil/)

Для оценки выполнения целей процесса в ITIL должны использоваться метрики, которые: - Непосредственно указаны в формулировке цели (например, для цели "увеличить долю решённых инцидентов до 95%" метрикой будет процент своевременно устранённых инцидентов). - Соответствуют критерию измеримости: имеют количественную шкалу и метод расчёта. - Привязаны к временным рамкам (ежемесячные, ежеквартальные отчёты). - Учитывают как количественные показатели (проценты, время выполнения), так и качественные аспекты в операционных задачах. - Связаны с цепочкой ценности: показывают влияние на качество услуг или бизнес-результаты. При этом метрики для задач процесса могут быть статичными (так как задачи редко меняются), тогда как для целей они переопределяются при каждом пересмотре целей.

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

Рейтинг: 1179

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

## [Как в условиях SLA описать взаимосвязь между инфраструктурными компонентами и ИТ-сервисами?](https://cleverics.ru/digital/kb-qa/kak-v-usloviyakh-sla-opisat-vzaimosvyaz-mezhdu-infrastrukturnymi-komponentami-i-it-servisami/)

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

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

Рейтинг: 1179

Теги: SLA, управление инцидентами, управление конфигурациями, CMDB, управление уровнем услуг, SLM