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

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

## [Какие навыки становятся критически важными для ИТ-профессионалов в современных условиях?](https://cleverics.ru/digital/kb-qa/kakie-navyki-stanovyatsya-kriticheski-vazhnymi-dlya-it-professionalov-v-sovremennykh-usloviyakh/)

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

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

Рейтинг: 1513

Теги: Agile и гибкие методы разработки ПО, бизнес, ценность, бизнес-заказчик, командная работа, трансформация, ускорение, Time-to-Market, управление отношениями, взаимодействие, BRM

## [Какое преимущество дает комбинирование RBAC и ABAC по сравнению с использованием отдельных моделей?](https://cleverics.ru/digital/kb-qa/kakoe-preimushchestvo-daet-kombinirovanie-rbac-i-abac-po-sravneniyu-s-ispolzovaniem-otdelnykh-modele/)

Комбинирование RBAC и ABAC позволяет достичь значительного сокращения количества необходимых правил или ролей, сохраняя при этом гибкость системы. Например, в системе с 10 атрибутами (7 статическими и 3 динамическими) классическая ролевая модель потребовала бы 2^10 (1024) ролей, тогда как комбинированная модель требует всего 2^7 (128) ролей и 2^3 (8) атрибутных правил. Это существенное упрощение, так как большинство атрибутов в реальных системах (должность, подразделение и т.д.) являются статическими и редко меняются, а динамические атрибуты (например, время суток) требуют гораздо меньшего количества правил.

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

Рейтинг: 1512

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

## [Какие обязанности у менеджера изменений по ITIL?](https://cleverics.ru/digital/kb-qa/kakie-obyazannosti-u-menedzhera-izmeneniy-po-itil/)

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

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

Рейтинг: 1508

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

## [Как различаются понятия «проблема» и «инцидент» в рамках ITIL?](https://cleverics.ru/digital/kb-qa/kak-razlichayutsya-ponyatiya-problema-i-intsident-v-ramkakh-itil/)

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

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

Рейтинг: 1506

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

## [Что такое поток создания ценности (value stream) в контексте продуктового подхода?](https://cleverics.ru/digital/kb-qa/chto-takoe-potok-sozdaniya-tsennosti-value-stream-v-kontekste-produktovogo-podkhoda/)

Поток создания ценности (value stream) - это последовательность этапов, которая описывает решение задачи от начала до конца (сквозной процесс). Это конструкция, которая объединяет различные части организации во благо продукта(ов). В этом потоке ресурсы организации (включая людей) могут вовлекаться в выполнение работ на различных этапах. Отношение между организационными подразделениями и этапами потока является отношением многие-ко-многим: одно подразделение может участвовать в нескольких этапах потока, и для выполнения одного этапа может потребоваться несколько подразделений. Для структурирования анализа этих связей могут использоваться дополнительные слои сущностей, такие как практики в ITIL4 или 'способности' в TOGAF.

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

Рейтинг: 1504

Теги: архитектура ИТ, TOGAF и IT4IT, бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, поток создания ценности (Value Stream), управление продуктами, продуктовый подход

## [Как связаны предложенные показатели с такими метриками как MTRS, MTBF и MTBSI?](https://cleverics.ru/digital/kb-qa/kak-svyazany-predlozhennye-pokazateli-s-takimi-metrikami-kak-mtrs-mtbf-i-mtbsi/)

Предложенные показатели (суммарное время простоев, максимальный разовый простой, количество нарушений) тесно связаны с традиционными метриками надежности MTRS (Mean Time To Restore Service), MTBF (Mean Time Between Failures) и MTBSI (Mean Time Between Service Incidents). Например, суммарное время простоя связано с MTRS, количество нарушений - с MTBF, а средняя продолжительность работы без нарушений соотносится с MTBSI. Однако предложенные показатели сформулированы более приближенно к бизнес-эффекту и фокусируются на том, как именно простои влияют на бизнес-процессы, в то время как традиционные метрики носят более технический характер и не всегда напрямую связаны с бизнес-потерями.

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

Рейтинг: 1503

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

## [Почему важно, чтобы при возврате на доработку инцидент попадал на обработку той же группе, которая сообщила о решении?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-chtoby-pri-vozvrate-na-dorabotku-intsident-popadal-na-obrabotku-toy-zhe-gruppe-kotora/)

Важно, чтобы инцидент возвращался именно той группе, которая предоставила решение, потому что только эта группа может исправить свои собственные ошибки и доработать инцидент корректно. Если же инцидент возвращается на обработку другой группе (например, Service Desk), то теряется ответственность за качество решения, и создается риск некачественной доработки, так как вторая группа может не обладать полным пониманием проблемы. Это также искажает метрику результативности, делая её менее точной.

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

Рейтинг: 1500

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

## [Как можно измерить успешность сервисного подхода в ИТ без использования SLA?](https://cleverics.ru/digital/kb-qa/kak-mozhno-izmerit-uspeshnost-servisnogo-podkhoda-v-it-bez-ispolzovaniya-sla/)

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

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

Рейтинг: 1500

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

## [Что такое практика 'Поддержка изменений' в ITIL4?](https://cleverics.ru/digital/kb-qa/chto-takoe-praktika-podderzhka-izmeneniy-v-itil4/)

Практика 'Поддержка изменений' (Change enablement) в ITIL4 - это подход к управлению изменениями, ориентированный на быструю и безопасную доставку изменений в эксплуатацию при минимизации рисков. Она фокусируется на обеспечении того, чтобы изменения внедрялись эффективно и безопасно, при этом сохраняя необходимый уровень контроля. В рамках этой практики определен набор процессов, каждый из которых требует управления, а за практику в целом отвечает менеджер изменений как специфическая роль. Цель практики - поддержка бизнеса в адаптации к изменениям среды при сохранении стабильности сервисов.

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

Рейтинг: 1499

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

## [Что такое функциональная эскалация в управлении инцидентами?](https://cleverics.ru/digital/kb-qa/chto-takoe-funktsionalnaya-eskalatsiya-v-upravlenii-intsidentami/)

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

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

Рейтинг: 1498

Теги: SLA, общие вопросы менеджмента, поддержка пользователей, Service Desk, Help Desk, управление инцидентами, управление уровнем услуг, SLM