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

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

## [Что часто является причиной неудач при внедрении ИТ-процессов?](https://cleverics.ru/digital/kb-qa/chto-chasto-yavlyaetsya-prichinoy-neudach-pri-vnedrenii-it-protsessov/)

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

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

Рейтинг: 1550

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

## [Зачем нужен PRB при управлении проблемами, если он упоминается в контексте major-инцидентов?](https://cleverics.ru/digital/kb-qa/zachem-nuzhen-prb-pri-upravlenii-problemami-esli-on-upominaetsya-v-kontekste-major-intsidentov/)

PRB (Problem Review Board) необходим для обсуждения сложных проблем с участием экспертов, но его роль не сводится к реакции на major-инциденты. PRB анализирует глубинные причины, планирует стратегии решений и утверждает временные обходные пути. Ошибочное применение PRB только после критических инцидентов (вместо регулярного анализа) искажает процесс — PRB должен функционировать как постоянно действующий орган для координации сложных проблем, а не как экстренная группа.

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

Рейтинг: 1533

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

## [Что такое FCR в контексте управления инцидентами и почему он важен?](https://cleverics.ru/digital/kb-qa/chto-takoe-fcr-v-kontekste-upravleniya-intsidentami-i-pochemu-on-vazhen/)

FCR (First Contact Resolution) — это показатель, измеряющий долю инцидентов, которые были решены с первого обращения пользователя, без необходимости дополнительных обращений или повторных контактов. Важность этого показателя заключается в том, что он напрямую влияет на удовлетворённость пользователей: чем меньше пользователю приходится повторно обращаться в службу поддержки по одному и тому же инциденту, тем лучше его опыт взаимодействия с сервисом. Высокий уровень FCR указывает на эффективность работы службы поддержки, её способность предоставлять полную и точную информацию с первого раза, что в свою очередь снижает нагрузку на систему и повышает общую удовлетворённость пользователей.

Автор: Игорь Гутник

Рейтинг: 1532

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

## [Каким образом 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 это становится проще благодаря более структурированному и конкретному описанию факторов успеха.

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

Рейтинг: 1515

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

## [Что представляет собой системный подход к управлению рисками в ИТ-организации?](https://cleverics.ru/digital/kb-qa/chto-predstavlyaet-soboy-sistemnyy-podkhod-k-upravleniyu-riskami-v-it-organizatsii/)

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

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

Рейтинг: 1489

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

## [Что такое causal loop diagram (CLD) и какие элементы в него входят?](https://cleverics.ru/digital/kb-qa/chto-takoe-causal-loop-diagram-cld-i-kakie-elementy-v-nego-vkhodyat/)

Causal loop diagram (CLD) - это инструмент системной динамики, который позволяет отражать влияние разных переменных, характеризующих работу системы, друг на друга для объяснения ее поведения. CLD включает в себя переменные (такие как Market Size, Potential Customers, People Buying Product), связи между ними, которые бывают двух типов: S (same) - прямо пропорциональная зависимость (например, чем больше людей купили продукт, тем больше клиентская база) и O (opposite) - обратно пропорциональная зависимость (например, чем больше людей купило продукт, тем меньше потенциальных клиентов). Также в диаграмме обозначаются циклы обратной связи: R (reinforcing loop) - усиливающие циклы, которые усиливают изменения, и B (balancing loop) - балансирующие циклы, которые стремятся к равновесию и стабилизируют систему. Эти элементы в совокупности помогают анализировать и визуализировать сложные взаимодействия внутри системы и объяснять часто контринтуитивное поведение системы.

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

Рейтинг: 1486

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

## [Как влияет уровень автоматизации на частоту успешных релизов в ИТ-командах?](https://cleverics.ru/digital/kb-qa/kak-vliyaet-uroven-avtomatizatsii-na-chastotu-uspeshnykh-relizov-v-it-komandakh/)

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

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

Рейтинг: 1479

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

## [Что такое RBAC-модель и какие основные преимущества она имеет по сравнению с другими моделями управления доступом?](https://cleverics.ru/digital/kb-qa/chto-takoe-rbac-model-i-kakie-osnovnye-preimushchestva-ona-imeet-po-sravneniyu-s-drugimi-modelyami-u/)

RBAC (Role-Based Access Control) — это ролевая модель управления доступом, в которой доступ предоставляется не напрямую к объектам и операциям, а к определённым группам прав, объединённым по функциональному признаку (например, 'администратор системы', 'пользователь модуля N'). Основные преимущества RBAC по сравнению с другими моделями: наглядность (права структурированы по бизнес-ролям), простота назначения (администраторы работают с целыми группами прав, а не с отдельными объектами), соответствие бизнес-процессам и организационной структуре, возможность запрета использования смежных ролей для разделения полномочий, иерархия ролей (построение связок 'родительская-дочерняя') для наследования прав. В отличие от мандатной модели (MAC), где доступ зависит от уровня допуска пользователей и классификации информации, RBAC не требует жёсткой привязки к грифам секретности, что обеспечивает большую гибкость. В отличие от дискреционной модели (DAC), где настраиваются разрешения для каждого пользователя отдельно, RBAC избегает избыточной детализации и упрощает администрирование за счёт группировки прав в роли.

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

Рейтинг: 1477

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

## [В чём разница между реактивным и проактивным управлением проблемами?](https://cleverics.ru/digital/kb-qa/v-chem-raznitsa-mezhdu-reaktivnym-i-proaktivnym-upravleniem-problemami/)

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

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

Рейтинг: 1474

Теги: архитектура ИТ, TOGAF и IT4IT, аудит, мониторинг, управление доступностью, управление инцидентами, управление проблемами

## [Что включает в себя план коммуникаций для проекта?](https://cleverics.ru/digital/kb-qa/chto-vklyuchaet-v-sebya-plan-kommunikatsiy-dlya-proekta/)

План коммуникаций для проекта включает несколько важных компонентов: определение заинтересованных сторон (стейкхолдеров), выяснение какая информация в какой форме, объеме, формате и с какой периодичностью нужна каждому стейкхолдеру, установление способов обратной связи, выбор типов коммуникаций (электронная почта, встречи, собрания, меморандумы и т.д.), учет возможных факторов, ведущих к конфликтам или недопониманию, а также разработку способов их решения. Согласно ITIL Practitioner, план коммуникаций должен отвечать на вопросы: кто и какую информацию должен получать, какова цель этой информации, какие форматы и средства передачи информации наиболее эффективны, кто и когда должен направлять информацию, как проверить её правильное понимание, и какой обратной связи необходимо добиться. План коммуникаций — это документ, который регулярно анализируется и совершенствуется на протяжении всего проекта.

Автор: Елена Колбей

Рейтинг: 1471

Теги: ITIL, управление продуктами, продуктовый подход, управление проектами, PRINCE2, управление процессами, ИТ-процессы