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

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

## [Зачем нужен 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 должен функционировать как постоянно действующий орган для координации сложных проблем, а не как экстренная группа.

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

Рейтинг: 1903

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

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

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

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

Рейтинг: 1885

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

## [Что такое CMDB в ИТ-инфраструктуре компании?](https://cleverics.ru/digital/kb-qa/chto-takoe-cmdb-v-it-infrastrukture-kompanii/)

CMDB (Configuration Management Database) - это база данных управления конфигурациями, предназначенная для структурированного хранения информации об ИТ-инфраструктуре компании. В ней собирается информация о взаимосвязанных компонентах ИТ-инфраструктуры, их настройках и связях между ними. Поскольку запомнить всю эту информацию невозможно из-за ее объема и сложности, организации используют CMDB для управляемого и структурированного хранения конфигурационных данных, что позволяет эффективно управлять ИТ-услугами.

Автор: Анна Васильева

Рейтинг: 1876

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

## [Как меняется роль лидера при переходе команды через различные уровни осознанности?](https://cleverics.ru/digital/kb-qa/kak-menyaetsya-rol-lidera-pri-perekhode-komandy-cherez-razlichnye-urovni-osoznannosti/)

Роль лидера трансформируется от лидера-менеджера к лидеру-партнеру по мере развития команды. На уровне «Детский сад» лидера должен быть директивным, активно организовывать процессы, решать текущие проблемы и постепенно вовлекать команду, расширяя границы самостоятельности. На уровне «Пубертат» лидер выступает как посредник, помогающий в конструктивном взаимодействии и гашении конфликтов, «продавая» решения вместо директивного управления. На уровне «Яркая молодость» лидер становится «мотором-метрономом», поддерживающим скорость и ритмичность работы, востребован в роли лидера-слуги на 100%. На высшей стадии «Зрелость» лидера-слуги заменяет лидер-партнер, наделенный полномочиями для поддержки инициатив на высоких уровнях, обладающий достаточной осведомленностью и авторитетом для интеграции целей команды с целями компании.

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

Рейтинг: 1873

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

## [Какова разница между запросом на изменение (RFC) и предложением об изменении (Change proposal)?](https://cleverics.ru/digital/kb-qa/kakova-raznitsa-mezhdu-zaprosom-na-izmenenie-rfc-i-predlozheniem-ob-izmenenii-change-proposal/)

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

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

Рейтинг: 1871

Теги: управление изменениями, управление конфигурациями, CMDB, управление релизами

## [Что такое аллокация стоимости ИТ-услуг и почему она важна?](https://cleverics.ru/digital/kb-qa/chto-takoe-allokatsiya-stoimosti-it-uslug-i-pochemu-ona-vazhna/)

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

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

Рейтинг: 1846

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

## [Какой принцип одного изделия в потоке (one piece flow) проявился в практике DevOps при использовании канбана?](https://cleverics.ru/digital/kb-qa/kakoy-printsip-odnogo-izdeliya-v-potoke-one-piece-flow-proyavilsya-v-praktike-devops-pri-ispolzovani/)

Принцип одного изделия в потоке (one piece flow) проявился в том, что команда DevOps в процессе реализации проекта «Феникс» настолько овладела подходом, что в конце игры уже не использовала второй ряд столов. Это означает, что задачи проходили через весь процесс без скопления промежуточных запасов, каждая следующая задача могла начаться сразу после завершения предыдущей, что исключило простои и сократило время цикла выполнения задачи. Такой уровень отлаженности процесса позволяет максимально уменьшить время ожидания, избегать параллельного выполнения множества задач, что обычно приводит к снижению производительности из-за многозадачности и переключений контекста.

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

Рейтинг: 1829

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

## [Чем отличаются риски от проблем в контексте ITIL?](https://cleverics.ru/digital/kb-qa/chem-otlichayutsya-riski-ot-problem-v-kontekste-itil/)

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

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

Рейтинг: 1819

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

## [Какие уровни влияния инцидентов обычно выделяются в ИТ-службе?](https://cleverics.ru/digital/kb-qa/kakie-urovni-vliyaniya-intsidentov-obychno-vydelyayutsya-v-it-sluzhbe/)

Обычно выделяются четыре уровня влияния инцидентов: 1) Максимальный уровень (критический) - когда ИТ-услуга недоступна для всего отдела или компании, что приводит к полной остановке бизнес-процессов. 2) Высокий уровень - когда несколько сотрудников сталкиваются с полным отсутствием функционала. 3) Средний уровень - когда у группы пользователей доступна только часть функционала. 4) Низкий уровень (минимальный) - когда у одного сотрудника недоступна только часть функционала ИТ-услуги. Эти уровни могут варьироваться в зависимости от принятой в организации методологии и дополнительных критериев оценки, таких как VIP-статус пользователей или критичность системы.

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

Рейтинг: 1800

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

## [Как вычисляется доверительный интервал для результатов опроса в Excel?](https://cleverics.ru/digital/kb-qa/kak-vychislyaetsya-doveritelnyy-interval-dlya-rezultatov-oprosa-v-excel/)

Доверительный интервал для результатов опроса можно рассчитать в MS Excel 2010 следующим образом: стандартное отклонение вычисляется с помощью функции СТАНДОТКЛОН.В(...), доверительный интервал получается вызовом функции ДОВЕРИТ.СТЬЮДЕНТ(a; S; n), где a - уровень значимости, S - стандартное отклонение, n - размер выборки, а коэффициент Стьюдента - функцией СТЬЮДЕНТ.ОБР.2Х(a; n-1). Это позволяет определить границы, в которых с заданной вероятностью будет находиться истинное среднее значение всей генеральной совокупности.

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

Рейтинг: 1776