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

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

## [Какая роль заказчика в запуске потоков создания ценности?](https://cleverics.ru/digital/kb-qa/kakaya-rol-zakazchika-v-zapuske-potokov-sozdaniya-tsennosti/)

Заказчик играет ключевую роль в запуске потоков создания ценности. Заказчик предъявляет требования к услуге - новой или существующей, что запускает соответствующие потоки. При создании или изменении услуги заказчик запускает потоки, связанные с согласованием и фиксацией новых условий услуги и требований к уровню обслуживания (SLA) на этапах Offer и Agree. В рамках этих взаимодействий сбор требований осуществляется в виде деятельности потока Engage. Таким образом, заказчик является инициатором определенных потоков, когда предъявляет спрос на изменение или создание новых услуг.

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

Рейтинг: 783

Теги: SLA, бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, общие вопросы менеджмента, поток создания ценности (Value Stream), управление отношениями, взаимодействие, BRM, управление процессами, ИТ-процессы, управление уровнем услуг, SLM

## [Как учитывать изменения организационной структуры при обновлении ролевой модели?](https://cleverics.ru/digital/kb-qa/kak-uchityvat-izmeneniya-organizatsionnoy-struktury-pri-obnovlenii-rolevoy-modeli/)

При изменениях структуры (слияние, разделение подразделений) нужно: 1) Определить тип изменений: 'старое-старое' (функции не меняются), 'старое-новое' (добавляются новые функции) или 'новое' (полностью новый набор функций). 2) Для 'старое-новое' комбинировать бизнес-роли основного и сливаемого подразделений (например, роли из объединяемых департаментов маркетинга и PR объединяются в единую модель). 3) Для 'новое' формировать уникальный набор ролей с нуля, если подразделение создаётся под новые задачи. Ключевой этап — перераспределение ролей между сотрудниками, учитывая новые зоны ответственности.

Автор: Денис Денисов

Рейтинг: 783

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

## [Как гибридные модели RBAC и ABAC повышают понятность управления доступом?](https://cleverics.ru/digital/kb-qa/kak-gibridnye-modeli-rbac-i-abac-povyshayut-ponyatnost-upravleniya-dostupom/)

Гибридные модели сохраняют структуру RBAC с явным разделением прав по ролям, что упрощает аудит и управление. При этом ABAC добавляет гибкость через динамические условия, например, ограничение прав менеджера редактировать заказы только в рабочее время. Это делает систему более адаптивной без потери прозрачности: права остаются привязаны к ролям, а контекстные правила не нарушают базовую структуру.

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

Рейтинг: 783

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

## [Как определить, когда услуга становится ресурсом для другой услуги?](https://cleverics.ru/digital/kb-qa/kak-opredelit-kogda-usluga-stanovitsya-resursom-dlya-drugoy-uslugi/)

Услуга становится ресурсом для другой услуги, когда она не предоставляется конечному потребителю напрямую, а используется как компонент для обеспечения более комплексной услуги. Определить это можно по следующим признакам: услуга не имеет прямого SLA с конечным клиентом, потребитель не взаимодействует с ней напрямую, она является частью внутренней архитектуры предоставления основной услуги. Например, услуга хостинга серверов может быть ресурсом для услуги предоставления веб-приложения конечному пользователю.

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

Рейтинг: 783

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

## [В чем отличие между терминами 'Critical Incident' и 'Major Incident' в практике управления инцидентами?](https://cleverics.ru/digital/kb-qa/v-chem-otlichie-mezhdu-terminami-critical-incident-i-major-incident-v-praktike-upravleniya-intsident/)

В практике управления инцидентами термины 'Critical Incident' и 'Major Incident' часто используются как синонимы, но имеют некоторые различия в трактовке. 'Major Incident' (Значительный инцидент) в ITIL определяется как инцидент с наивысшей категорией влияния, вызывающий существенные потери для бизнеса. Основной акцент делается на необходимости применения специальной процедуры управления, выходящей за рамки обычных процедур. Термин 'Critical Incident' может относиться к инцидентам, критическим для функционирования отдельных систем или компонентов, но не обязательно имеющим широкое влияние на весь бизнес. Таким образом, все Critical Incidents не обязательно являются Major Incidents, но Major Incidents всегда имеют критическое влияние на бизнес в целом.

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

Рейтинг: 783

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

## [Почему попытка определить точный срок поставки задачи в момент принятия решения является неблагодарной?](https://cleverics.ru/digital/kb-qa/pochemu-popytka-opredelit-tochnyy-srok-postavki-zadachi-v-moment-prinyatiya-resheniya-yavlyaetsya-ne/)

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

Автор: Павел Капусткин

Рейтинг: 783

Теги: DevOps, CI/CD, управление процессами, ИТ-процессы

## [Как системное решение отличается от обходного в контексте исправления ошибок?](https://cleverics.ru/digital/kb-qa/kak-sistemnoe-reshenie-otlichaetsya-ot-obkhodnogo-v-kontekste-ispravleniya-oshibok/)

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

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

Рейтинг: 783

Теги: управление проблемами

## [Какие методы описания последствий рисков предлагает PMBOK?](https://cleverics.ru/digital/kb-qa/kakie-metody-opisaniya-posledstviy-riskov-predlagaet-pmbok/)

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

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

Рейтинг: 783

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

## [Как доказать заказчику необходимость отдельного управления проблемами?](https://cleverics.ru/digital/kb-qa/kak-dokazat-zakazchiku-neobkhodimost-otdelnogo-upravleniya-problemami/)

Аргументы: 1) Снижение количества повторных инцидентов через устранение корневых причин (данные статистики); 2) Экономия ресурсов за счёт сокращения 'тушения пожаров'; 3) Повышение качества сервисов через проактивные улучшения; 4) Соответствие лучшим практикам (ITIL, COBIT); 5) Конкретные кейсы: например, после внедрения отдельного процесса управления проблемами количество major-инцидентов упало на X%. Ключевая идея — управление проблемами не тратит ресурсы, а инвестирует в устойчивость системы.

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

Рейтинг: 782

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

## [Почему измерение Flow Efficiency важно для процессов производства ценности?](https://cleverics.ru/digital/kb-qa/pochemu-izmerenie-flow-efficiency-vazhno-dlya-protsessov-proizvodstva-tsennosti/)

Измерение Flow Efficiency важно потому что оно позволяет выявить долю времени, когда над задачей фактически ведется работа, по сравнению со временем, проведенным в ожидании или в очередях. Это помогает командам понять, сколько времени теряется из-за простоя и ожидания, и сконцентрировать усилия на сокращении этих потерь. По утверждениям авторов 'DevOps Handbook', поскольку именно Lead Time воспринимается заказчиком как время выполнения работы, оптимизация именно этого показателя должна быть приоритетной. При этом соотношение времени обработки к общему времени выполнения является важной мерой эффективности процесса.

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

Рейтинг: 782

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