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

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

## [Что подразумевается под "сквозной" ответственностью за релиз в контексте ITIL?](https://cleverics.ru/digital/kb-qa/chto-podrazumevaetsya-pod-skvoznoy-otvetstvennostyu-za-reliz-v-kontekste-itil/)

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

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

Рейтинг: 1061

Теги: DevOps, CI/CD, ISO 20000, ITIL, командная работа, общие вопросы менеджмента, управление изменениями, управление процессами, ИТ-процессы, управление релизами

## [Как определить, подходит ли конкретная методология управления ИТ для вашей организации?](https://cleverics.ru/digital/kb-qa/kak-opredelit-podkhodit-li-konkretnaya-metodologiya-upravleniya-it-dlya-vashey-organizatsii/)

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

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

Рейтинг: 1061

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

## [В чем заключается принцип разделения полномочий в контексте RBAC?](https://cleverics.ru/digital/kb-qa/v-chem-zaklyuchaetsya-printsip-razdeleniya-polnomochiy-v-kontekste-rbac/)

Принцип разделения полномочий в контексте RBAC заключается в том, что критически важные операции должны выполняться разными людьми, чтобы предотвратить мошенничество или ошибки. Например, в банковской системе один сотрудник (роль "Операционист") может инициировать платеж, но его проведение должно быть одобрено другим сотрудником (роль "Контролёр"). Эти полномочия не могут быть объединены в одной роли и не могут быть назначены одному сотруднику. Это обеспечивает взаимный контроль и повышает безопасность операций, минимизируя риски, связанные с злоупотреблением полномочиями.

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

Рейтинг: 1061

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

## [Какие практические выводы можно извлечь после участия в деловой игре?](https://cleverics.ru/digital/kb-qa/kakie-prakticheskie-vyvody-mozhno-izvlech-posle-uchastiya-v-delovoy-igre/)

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

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

Рейтинг: 1061

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

## [Какова роль менеджера процесса в организации?](https://cleverics.ru/digital/kb-qa/kakova-rol-menedzhera-protsessa-v-organizatsii/)

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

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

Рейтинг: 1061

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

## [Почему не рекомендуется использовать термин Service Capacity Management как фиксированное название подпроцесса?](https://cleverics.ru/digital/kb-qa/pochemu-ne-rekomenduetsya-ispolzovat-termin-service-capacity-management-kak-fiksirovannoe-nazvanie-p/)

Термин Service Capacity Management не рекомендуется использовать как фиксированное название подпроцесса, потому что понятие «услуга» может относиться к разным уровням: бизнес-процессам, ИТ-системам или ресурсам. Это приводит к путанице в терминологии и не позволяет четко определить уровень, на котором происходит управление мощностями. Вместо этого предлагается использовать термины, отражающие конкретный уровень: Business, System или Resource Capacity Management.

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

Рейтинг: 1061

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

## [Почему задача измерения работы ИТ-службы является сложной?](https://cleverics.ru/digital/kb-qa/pochemu-zadacha-izmereniya-raboty-it-sluzhby-yavlyaetsya-slozhnoy/)

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

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

Рейтинг: 1060

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

## [Чем опасно, если команда игнорирует метрики поставки?](https://cleverics.ru/digital/kb-qa/chem-opasno-esli-komanda-ignoriruet-metriki-postavki/)

Игнорирование метрик поставки приводит к потере объективной картины состояния процессов. Команда начинает полагаться на субъективные ощущения, что замедляет реакцию на проблемы. Например, снижение скорости поставки может быть ошибочно приписано сезонным факторам, в то время как реальная причина — рост технического долга или накопление блокировок. Без данных невозможно выявить деградацию на ранних стадиях, что ведёт к критическим срывам сроков и увеличению дефектов.

Автор: Светлана Сапегина

Рейтинг: 1060

Теги: Agile и гибкие методы разработки ПО, DevOps, CI/CD, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, командная работа, разработка ПО

## [В чём заключается отличие стандарта INCITS 494-2012 от INCITS 359-2012?](https://cleverics.ru/digital/kb-qa/v-chem-zaklyuchaetsya-otlichie-standarta-incits-494-2012-ot-incits-359-2012/)

Стандарт INCITS 494-2012 представляет собой расширение основного стандарта INCITS 359-2012, разработанное для устранения критики 'чистого' RBAC за его негибкость в условиях изменчивого окружения. В то время как INCITS 359-2012 описывает базовую модель RBAC с её компонентами, INCITS 494-2012 расширяет возможности RBAC в части обработки динамических ограничений. Он позволяет внешним политикам и правилам создавать ограничения на уровне ядра RBAC, которые могут применяться к базовым множествам (пользователям, ролям, операциям, объектам и правам доступа). Стандарт 494-2012 вводит обработку не только разделения обязанностей, но и других типов ограничений, таких как время суток, местоположение и т.д.

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

Рейтинг: 1060

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

## [В чем сходство между IT4IT и ITIL v3 в описании функционирования ИТ?](https://cleverics.ru/digital/kb-qa/v-chem-skhodstvo-mezhdu-it4it-i-itil-v3-v-opisanii-funktsionirovaniya-it/)

Основное сходство между IT4IT и ITIL v3 заключается в использовании концепции жизненного цикла услуги. В IT4IT сервисная модель (Service Model) построена вокруг четырех основных столпов и представляет собой Service Backbone, что по сути соответствует этапам жизненного цикла услуги в ITIL v3 - от концепции до оказания услуги. Обе модели рассматривают ИТ-услуги в разрезе процессов, и многие функциональные компоненты в IT4IT (такие как управление инцидентами, проблемами, изменениями) напрямую соответствуют стандартным процессам ITIL v3. При переходе к ITIL v4 видно еще больше общего, в частности, использование цепочки создания ценности (Value Chain), впервые предложенной Майклом Портером. Обе модели стремятся описать целостную картину ИТ-управления, а не просто набор разрозненных процессов.

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

Рейтинг: 1060

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