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

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

## [Когда применение подхода MVP может быть нецелесообразным?](https://cleverics.ru/digital/kb-qa/kogda-primenenie-podkhoda-mvp-mozhet-byt-netselesoobraznym/)

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

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

Рейтинг: 1004

Теги: Agile и гибкие методы разработки ПО, бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, общие вопросы менеджмента, поток создания ценности (Value Stream), управление продуктами, продуктовый подход, эффективность, оптимизация

## [Какие рекомендации можно дать по эффективному использованию RBAC, чтобы избежать основных проблем?](https://cleverics.ru/digital/kb-qa/kakie-rekomendatsii-mozhno-dat-po-effektivnomu-ispolzovaniyu-rbac-chtoby-izbezhat-osnovnykh-problem/)

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

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

Рейтинг: 1004

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

## [Чем управление рисками отличается от управления ограничениями проекта?](https://cleverics.ru/digital/kb-qa/chem-upravlenie-riskami-otlichaetsya-ot-upravleniya-ogranicheniyami-proekta/)

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

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

Рейтинг: 1004

Теги: бюджетирование, планирование затрат, управление проектами, PRINCE2, управление рисками

## [Какие ошибки чаще всего возникают при расчёте Incident Rate?](https://cleverics.ru/digital/kb-qa/kakie-oshibki-chashche-vsego-voznikayut-pri-raschete-incident-rate/)

Наиболее часто встречающиеся ошибки при расчёте Incident Rate — это неверный учёт пользователей (например, включение технических учётных записей или уволенных сотрудников), игнорирование сезонных колебаний при анализе данных за короткий период, а также включение в числитель инфраструктурных инцидентов или сервисных запросов. Чтобы избежать искажений, рекомендуется использовать годовые данные с разбивкой по месяцам и проверять качество данных в ITSM-системе.

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

Рейтинг: 1004

Теги: ITSM, поддержка пользователей, Service Desk, Help Desk, управление инцидентами

## [Какие проблемы возникают при классификации услуг по модели ITIL V3 в современных условиях?](https://cleverics.ru/digital/kb-qa/kakie-problemy-voznikayut-pri-klassifikatsii-uslug-po-modeli-itil-v3-v-sovremennykh-usloviyakh/)

Основная проблема классификации услуг по модели ITIL V3 в современных условиях заключается в том, что жесткое разделение на бизнес-услуги и поддерживающие услуги не учитывает сложность современных цифровых экосистем, где границы между видами услуг часто размыты. Модель не учитывает, что одна и та же услуга может быть бизнес-услугой для одного потребителя и поддерживающей для другого. Кроме того, в ITIL4 термины 'бизнес-услуга' и 'информационная технологическая услуга' практически не используются, что создает неоднозначность при переходе от V3 к новой версии.

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

Рейтинг: 1004

Теги: ITIL, бизнес, ценность, бизнес-заказчик

## [Каковы основные различия между ролью владельца процесса и менеджера процесса в ITIL?](https://cleverics.ru/digital/kb-qa/kakovy-osnovnye-razlichiya-mezhdu-rolyu-vladeltsa-protsessa-i-menedzhera-protsessa-v-itil/)

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

Автор: Константин Нарыжный

Рейтинг: 1003

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

## [Как создать систему постоянного улучшения ИТ-услуг на основе ITIL?](https://cleverics.ru/digital/kb-qa/kak-sozdat-sistemu-postoyannogo-uluchsheniya-it-uslug-na-osnove-itil/)

Система постоянного улучшения на основе ITIL (Continual Service Improvement) строится по следующему алгоритму: во-первых, определите ключевые показатели эффективности (KPI) для каждой ИТ-услуги, ориентированные на бизнес-результаты. Затем регулярно (ежемесячно или ежеквартально) проводите анализ данных по этим KPI, сравнивая с целевыми значениями. Обеспечьте сбор обратной связи от всех заинтересованных сторон - бизнес-подразделений, пользователей и технических специалистов. Создайте циклический процесс из четырех этапов: Measure (измерение текущего состояния), Analyze (анализ данных и выявление проблем), Improve (внедрение улучшений), Review (оценка результатов изменений). Назначьте ответственных за CSI из руководителей ИТ-подразделений и бизнес-лидеров. Проводите регулярные сессии по выявлению возможностей для улучшения, используя техники мозгового штурма и анализ основных причин. Внедрите систему приоритизации улучшений на основе их влияния на бизнес и сложности реализации. Убедитесь, что результаты улучшений измеряются и доводятся до сведения всех заинтересованных сторон, что создаст мотивацию для дальнейших улучшений. Важно, чтобы процесс CSI был частью повседневной культуры организации, а не разовым проектом.

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

Рейтинг: 1003

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

## [Какие риски возникают при отсутствии процесса управления изменениями в управлении конфигурациями?](https://cleverics.ru/digital/kb-qa/kakie-riski-voznikayut-pri-otsutstvii-protsessa-upravleniya-izmeneniyami-v-upravlenii-konfiguratsiya/)

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

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

Рейтинг: 1003

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

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

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

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

Рейтинг: 1003

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

## [Какие преимущества даёт переход от проектного к продуктовому подходу в управлении ИТ-подразделением?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-daet-perekhod-ot-proektnogo-k-produktovomu-podkhodu-v-upravlenii-it-podrazdele/)

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

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

Рейтинг: 1003

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