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

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

## [В чем разница между назначением и целями процесса в ITIL?](https://cleverics.ru/digital/kb-qa/v-chem-raznitsa-mezhdu-naznacheniem-i-tselyami-protsessa-v-itil/)

Назначение процесса определяет его базовую функцию и место в общей процессной модели без привязки ко времени, тогда как цели процесса – это конкретные измеримые результаты, которых нужно достичь в определённый период. Ключевые отличия: - Назначение формулируется как описание общей задачи (например, "обеспечение качества услуг через устранение инцидентов"). - Цели формулируются в формате SMART: с глаголами совершенного вида ("увеличить долю решённых инцидентов до 95%"), измеримы и привязаны к срокам (квартал, год). Цели регулярно пересматриваются, в отличие от назначения, которое стабильно. Ответственность за назначение несёт дизайнер процессов, за цели – владелец процесса.

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

Рейтинг: 1385

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

## [Как отличается определение инцидента в ITIL v3 и ITIL 4?](https://cleverics.ru/digital/kb-qa/kak-otlichaetsya-opredelenie-intsidenta-v-itil-v3-i-itil-4/)

В ITIL v3 определение инцидента включало два предложения: «Незапланированное прерывание или снижение качества ИТ-услуги. Сбой конфигурационной единицы, который еще не повлиял на услугу, также является инцидентом, как, например, сбой одного диска из массива зеркалирования». В ITIL 4 второе предложение отсутствует, и определение стало короче: «Незапланированное прерывание или снижение качества услуги». Однако в руководстве по управлению инцидентами ITIL 4 указано, что практика все равно включает в себя восстановление нормальной работы ресурсов даже если их сбой не виден пользователям. Таким образом, ключевые смыслы остались прежними, различие скорее терминологическое.

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

Рейтинг: 1385

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

## [Как жесткие лимиты штата влияют на решение о найме новых сотрудников?](https://cleverics.ru/digital/kb-qa/kak-zhestkie-limity-shtata-vliyayut-na-reshenie-o-nayme-novykh-sotrudnikov/)

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

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

Рейтинг: 1385

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

## [Как работает иерархия ролей в системе RBAC?](https://cleverics.ru/digital/kb-qa/kak-rabotaet-ierarkhiya-roley-v-sisteme-rbac/)

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

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

Рейтинг: 1385

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

## [Как различается подход к снижению вероятности сбоев и снижению ущерба от них в управлении доступностью и управлении непрерывностью?](https://cleverics.ru/digital/kb-qa/kak-razlichaetsya-podkhod-k-snizheniyu-veroyatnosti-sboev-i-snizheniyu-ushcherba-ot-nikh-v-upravleni/)

В управлении доступностью (AVA) основной акцент делается на снижение вероятности наступления нежелательных событий: устранение единой точки отказа, оптимизация систем, проактивное предотвращение потенциальных сбоев. В управлении непрерывностью (CONT) устранение вероятности сбоев не является целью, так как ЧС рассматриваются как неизбежные. Основной задачей CONT является снижение ущерба от наступления нежелательных событий за счет создания резервных площадок, альтернативных способов предоставления услуг и процедур восстановления. Таким образом, AVA проактивен, а CONT скорее реактивен.

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

Рейтинг: 1380

Теги: управление доступностью, управление инцидентами, управление непрерывностью, эффективность, оптимизация

## [Почему коммуникация между бизнесом и ИТ-отделом часто приводит к недопониманию и неэффективности?](https://cleverics.ru/digital/kb-qa/pochemu-kommunikatsiya-mezhdu-biznesom-i-it-otdelom-chasto-privodit-k-nedoponimaniyu-i-neeffektivnos/)

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

Автор: Сандра Урядова

Рейтинг: 1379

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

## [Как стандартизация помогает в управлении изменениями?](https://cleverics.ru/digital/kb-qa/kak-standartizatsiya-pomogaet-v-upravlenii-izmeneniyami/)

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

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

Рейтинг: 1379

Теги: управление изменениями, управление рисками

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

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

Автор: Игорь Фадеев

Рейтинг: 1379

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

## [Какие основные преимущества предоставляет ролевая модель управления доступом (RBAC) по сравнению с другими моделями?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-preimushchestva-predostavlyaet-rolevaya-model-upravleniya-dostupom-rbac-po-sravneniyu/)

Ролевая модель управления доступом (RBAC) имеет несколько ключевых преимуществ. Во-первых, возможность построения иерархии ролей с наследованием прав позволяет упростить модель управления, особенно в организациях со сложной инфраструктурой, избегая дублирования прав при создании новых ролей. Во-вторых, обеспечение одинаковых прав большому количеству пользователей достигается простым назначением им одной роли. В-третьих, при необходимости изменения прав для множества пользователей достаточно обновить набор прав в соответствующей роли. В-четвертых, RBAC позволяет реализовать принцип разделения полномочий (Segregation of Duties), что снижает риск предоставления пользователям избыточных полномочий, например, когда два конфликтующих набора прав не могут быть назначены одному человеку одновременно.

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

Рейтинг: 1378

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

## [Как процесс управления изменениями в ИТ связан с Time to market и Service Quality?](https://cleverics.ru/digital/kb-qa/kak-protsess-upravleniya-izmeneniyami-v-it-svyazan-s-time-to-market-i-service-quality/)

Time to market формируется из двух компонент: Process Time (время фактической работы над изменением) и Queue Time (время ожидания в очереди). Service Quality обратно пропорционально связана с Change Risk - чем выше риски, тем ниже качество услуг. Чем быстрее проводятся изменения (меньше Time to market), тем выше риски для качества услуг, и наоборот - увеличение требований к качеству (Service Quality) ведет к увеличению времени вывода решений. Release rate (частота внедрений) и Release size (размер релиза) также влияют на эту связь: высокая частота малых релизов снижает риски и способствует ускорению Time to market, тогда как редкие крупные релизы увеличивают риски и замедляют процесс. Также важны Change capability (способность команды проводить изменения) и Change Control Level (уровень контроля изменений), которые определяют, как эффективно и качественно проводятся изменения в системе.

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

Рейтинг: 1376

Теги: командная работа, общие вопросы менеджмента, разработка ПО, трансформация, ускорение, Time-to-Market, управление изменениями, управление релизами, управление рисками, управление уровнем услуг, SLM