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

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

## [Почему в реальных условиях часто не соблюдается процедура фиксации приема заявки в работу перед началом ее решения?](https://cleverics.ru/digital/kb-qa/pochemu-v-realnykh-usloviyakh-chasto-ne-soblyudaetsya-protsedura-fiksatsii-priema-zayavki-v-rabotu-p/)

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

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

Рейтинг: 1170

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

## [Какие подходы рекомендуется использовать для дополнения ролевой модели управления доступом (RBAC), чтобы сделать управление доступом более эффективным?](https://cleverics.ru/digital/kb-qa/kakie-podkhody-rekomenduetsya-ispolzovat-dlya-dopolneniya-rolevoy-modeli-upravleniya-dostupom-rbac-c/)

Для дополнения ролевой модели управления доступом (RBAC) рекомендуется использовать управление доступом на основании запросов на предоставление прав доступа. Эта стратегия подразумевает, что пользователь самостоятельно запрашивает дополнительные права при возникновении потребности. Запрос проходит проверку, согласование и, при одобрении, приводит к выдаче прав. Такой подход можно автоматизировать через портал самообслуживания. Также полезно интегрировать ролевую модель с кадровой системой и обрабатывать изменения, связанные с кадровыми событиями, автоматически. Кроме того, регулярное проведение аудитов прав доступа помогает своевременно отзывать неиспользуемые права и поддерживать безопасность системы.

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

Рейтинг: 1169

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

## [Какова роль управления рисками в проектировании ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kakova-rol-upravleniya-riskami-v-proektirovanii-it-uslug/)

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

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

Рейтинг: 1169

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

## [Как проявляется отношение команды к руководству в условиях слаженной работы без явных лидеров?](https://cleverics.ru/digital/kb-qa/kak-proyavlyaetsya-otnoshenie-komandy-k-rukovodstvu-v-usloviyakh-slazhennoy-raboty-bez-yavnykh-lider/)

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

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

Рейтинг: 1169

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

## [Как группировать KPI при расчете комплексного показателя качества услуги?](https://cleverics.ru/digital/kb-qa/kak-gruppirovat-kpi-pri-raschete-kompleksnogo-pokazatelya-kachestva-uslugi/)

KPI при расчете комплексного показателя качества услуги можно группировать по категориям, отражающим различные аспекты услуги. Например, выделяют показатели производительности, доступности и поддержки. Для каждой группы рассчитывают отдельный интегральный показатель, используя подходящий метод агрегирования (среднее арифметическое, геометрическое и т.д.). Полученные результаты затем объединяют в общий показатель качества услуги, применив соответствующий метод агрегирования с учетом весов, если необходимо. Такой многоступенчатый подход позволяет более точно отражать качество услуги с разных сторон.

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

Рейтинг: 1169

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

## [Почему компромиссный подход в ITSM может быть временным решением?](https://cleverics.ru/digital/kb-qa/pochemu-kompromissnyy-podkhod-v-itsm-mozhet-byt-vremennym-resheniem/)

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

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

Рейтинг: 1169

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

## [Почему в реальных системах не используют чистый ABAC?](https://cleverics.ru/digital/kb-qa/pochemu-v-realnykh-sistemakh-ne-ispolzuyut-chistyy-abac/)

Чистый ABAC редко применяется из-за высокой сложности управления правилами. Большое количество атрибутов и условий приводит к трудночитаемым, запутанным политикам, которые сложно поддерживать и обновлять. Кроме того, отсутствие явных прав, как в RBAC, затрудняет аудит и анализ привилегий. Поэтому чаще используют гибридные подходы, где ABAC дополняет RBAC, например, добавляя контекстные ограничения к ролям.

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

Рейтинг: 1169

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

## [Какие проблемы возникают при классификации услуг по модели 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 к новой версии.

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

Рейтинг: 1169

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

## [Какие риски возникают при отсутствии контроля за консистентностью финансовой информации в CMDB?](https://cleverics.ru/digital/kb-qa/kakie-riski-voznikayut-pri-otsutstvii-kontrolya-za-konsistentnostyu-finansovoy-informatsii-v-cmdb/)

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

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

Рейтинг: 1169

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

## [Какие факторы следует учитывать при оценке влияния инцидентов на потребителей ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kakie-faktory-sleduet-uchityvat-pri-otsenke-vliyaniya-intsidentov-na-potrebiteley-it-uslug/)

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

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

Рейтинг: 1168

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