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

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

## [Чем отличаются инцидент и проблема в ИТ-сопровождении?](https://cleverics.ru/digital/kb-qa/chem-otlichayutsya-intsident-i-problema-v-it-soprovozhdenii/)

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

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

Рейтинг: 1770

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

## [В чём разница между клиентами-заказчиками и пользователями в контексте ИТ-услуг?](https://cleverics.ru/digital/kb-qa/v-chem-raznitsa-mezhdu-klientami-zakazchikami-i-polzovatelyami-v-kontekste-it-uslug/)

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

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

Рейтинг: 1769

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

## [Какие этапы включает расширенный жизненный цикл инцидента и чем они характеризуются?](https://cleverics.ru/digital/kb-qa/kakie-etapy-vklyuchaet-rasshirennyy-zhiznennyy-tsikl-intsidenta-i-chem-oni-kharakterizuyutsya/)

Этапы расширенного жизненного цикла инцидента включают: 1) момент возникновения инцидента — момент, когда пользователь ощутил снижение качества сервиса; 2) обнаружение — промежуток времени от возникновения до информирования поставщика ИТ-услуг; 3) диагностика — поиск причины инцидента; 4) исправление — проведение работ по устранению сбоя или замене компонента; 5) восстановление — завершение ремонтных работ в инфраструктуре; 6) возобновление — период от окончания восстановления до полного возврата пользователя к нормальной работе. Каждый из этапов имеет определённую продолжительность, и анализ затраченного времени на них позволяет оптимизировать процессы управления доступностью ИТ-услуг.

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

Рейтинг: 1768

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

## [Какие существуют методы и стандарты для управления рисками в области IT?](https://cleverics.ru/digital/kb-qa/kakie-sushchestvuyut-metody-i-standarty-dlya-upravleniya-riskami-v-oblasti-it/)

Для управления рисками в области IT существуют различные методы и стандарты, такие как CRAMM, COSO ERM, ISO 27005, OCTAVE и MEHARI. Все эти методики описывают известный цикл управления рисками, состоящий из этапов: определение охвата, идентификация, анализ, оценка, реагирование и контроль. Этот цикл официально закреплен в стандарте ISO 31000 с 2009 года. Каждая методика предлагает свой подход к формулированию рисков. Например, ITSM-специалисты часто используют модель «актив-угроза-уязвимость», в то время как PMBOK рекомендует структуру «причина-событие-последствие». ISACA в своих публикациях, начиная с RiskIT и в частности в COBIT 5 for Risk, предлагает концепцию сценария риска, включающего источник угрозы, тип угрозы, событие, связанные активы и временной аспект.

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

Рейтинг: 1762

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

## [Каким образом ITIL 4 упрощает формулирование ключевых показателей эффективности (KPI) по сравнению с ITILv3?](https://cleverics.ru/digital/kb-qa/kakim-obrazom-itil-4-uproshchaet-formulirovanie-klyuchevykh-pokazateley-effektivnosti-kpi-po-sravnen/)

ITIL 4 упрощает формулирование ключевых показателей эффективности (KPI) благодаря подробному описанию каждого фактора успеха практики (PSF) и предоставлению сопровождающих примеров метрик, которые можно использовать в качестве KPI. Описания практик в ITIL 4 стали более практико-ориентированными, что позволяет легче определить, какие показатели следует измерять для оценки эффективности конкретных практик в контексте их вклада в потоки создания ценности. В ITILv3 подход был более процесс-ориентированным, и, хотя концепция CSF также позволяла формулировать KPI, в ITIL 4 это становится проще благодаря более структурированному и конкретному описанию факторов успеха.

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

Рейтинг: 1760

Теги: ITIL, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, Канбан, WIP-лимиты, поток создания ценности (Value Stream), управление процессами, ИТ-процессы, эффективность, оптимизация

## [Какие метрики следует использовать для оценки качества ИТ-сервисов?](https://cleverics.ru/digital/kb-qa/kakie-metriki-sleduet-ispolzovat-dlya-otsenki-kachestva-it-servisov/)

Для оценки качества ИТ-сервисов следует использовать метрики, которые напрямую связаны с бизнес-результатами и удовлетворенностью пользователей, а не только с внутренней эффективностью процессов. К таким метрикам относятся: доступность сервиса (доля времени, в течение которого сервис доступен для использования), время восстановления сервиса после сбоя, время отклика системы (скорость обработки запросов), процент соблюдения SLA по ключевым показателям, уровень удовлетворенности пользователей, а также бизнесовые метрики, такие как влияние инцидентов на выполнение бизнес-процессов. Например, для почтового сервиса ключевой метрикой может быть доступность не менее 99,5%, а для системы заказов - время обработки запроса не более 2 секунд. Важно, чтобы выбранные метрики были согласованы с потребителями сервиса и отражали их реальные потребности в ИТ-услугах.

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

Рейтинг: 1756

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

## [Как рассчитать метрику First Time Resolution (FTR) для инцидентов в разрезе рабочих групп?](https://cleverics.ru/digital/kb-qa/kak-rasschitat-metriku-first-time-resolution-ftr-dlya-intsidentov-v-razreze-rabochikh-grupp/)

Метрика First Time Resolution (FTR) в разрезе рабочих групп рассчитывается по формуле: FTR = (Nj - Sj) / Nj. Здесь Nj — количество обращений (инцидентов), обработанных j-той группой и закрытых без рекламаций (Cj), плюс количество возвратов на доработку в эту группу (Sj). Sj — это количество объектов, возвращенных на доработку в j-тую группу. Расчёт производится за период, когда завершена процедура проверки решения инцидента, а не фактическое решение задачи. Важно учитывать возвраты индивидуально по каждой группе, так как одно обращение может быть переназначено в другую группу или возвращено несколько раз в разные группы.

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

Рейтинг: 1756

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

## [Как понять, насколько успешно реализуется сервисное мышление в организации?](https://cleverics.ru/digital/kb-qa/kak-ponyat-naskolko-uspeshno-realizuetsya-servisnoe-myshlenie-v-organizatsii/)

Успешность реализации сервисного мышления в организации можно оценить через ответы на вопросы, структурированные по 7 принципам ITIL: 1) Фокус на ценности — получает ли клиент желаемую ценность? 2) Начало с текущего состояния — учитывается ли контекст и предыдущий опыт? 3) Постепенное развитие с обратной связью — есть ли система сбора и использования обратной связи? 4) Сотрудничество и видимость — прозрачны ли процессы и ясно ли распределены роли? 5) Целостный подход — учитывается ли связь услуг с целями клиента? 6) Простота и практичность — насколько хорош пользовательский опыт? 7) Оптимизация и автоматизация — идут ли постоянные улучшения процессов? Положительные ответы на эти вопросы свидетельствуют об успешной реализации сервисного мышления.

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

Рейтинг: 1755

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

## [Что такое проблема в контексте ITIL и как она связана с реализовавшимся риском?](https://cleverics.ru/digital/kb-qa/chto-takoe-problema-v-kontekste-itil-i-kak-ona-svyazana-s-realizovavshimsya-riskom/)

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

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

Рейтинг: 1748

Теги: ITIL, управление инцидентами, управление проблемами, управление рисками

## [Какую ценность представляет методология FAIR (Factor Analysis of Information Risk)?](https://cleverics.ru/digital/kb-qa/kakuyu-tsennost-predstavlyaet-metodologiya-fair-factor-analysis-of-information-risk/)

FAIR, разработанная независимым консультантом Jack A. Jones, представляет собой структурированный подход к анализу информационных рисков. Методология построена вокруг метафоры, которая демонстрирует, как один и тот же риск может выглядеть по-разному в различных контекстах и с разных точек зрения. В ядре FAIR находится ценная структура факторов, влияющих на вероятность возникновения нежелательного события и размер ущерба, что помогает провести количественную оценку риска. Помимо этого, автор приводит множество практических предостережений, о которых часто не задумываются при стандартных подходах к идентификации и оценке рисков, что делает методологию особенно ценной для практиков.

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

Рейтинг: 1746

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