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

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

## [Почему необходим регулярный аудит прав доступа пользователей в сочетании ролевой модели и системы запросов?](https://cleverics.ru/digital/kb-qa/pochemu-neobkhodim-regulyarnyy-audit-prav-dostupa-polzovateley-v-sochetanii-rolevoy-modeli-i-sistemy/)

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

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

Рейтинг: 1029

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

## [Какие преимущества имеет вариант с дочерней задачей для исправлений?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-imeet-variant-s-docherney-zadachey-dlya-ispravleniy/)

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

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

Рейтинг: 1029

Теги: командная работа

## [Как связаны каталог услуг и SLA в различных бизнес-сценариях?](https://cleverics.ru/digital/kb-qa/kak-svyazany-katalog-uslug-i-sla-v-razlichnykh-biznes-stsenariyakh/)

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

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

Рейтинг: 1029

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

## [Что такое трудность в построении ролевой модели управляемого доступа?](https://cleverics.ru/digital/kb-qa/chto-takoe-trudnost-v-postroenii-rolevoy-modeli-upravlyaemogo-dostupa/)

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

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

Рейтинг: 1028

Теги: управление доступом, IDM, ролевые модели, RBAC, ABAC, управление проектами, PRINCE2

## [Как можно наглядно объяснить разницу между Output и Outcome?](https://cleverics.ru/digital/kb-qa/kak-mozhno-naglyadno-obyasnit-raznitsu-mezhdu-output-i-outcome/)

Для объяснения используется пример заказа торта на день рождения: Output — сам торт, который готовит и предоставляет пекарня; Outcome — это восторг именинника и удовлетворённость гостей, которые съели торт. Также применяются другие примеры: Output таксиста — спортивный автомобиль, а Outcome — быстрая и комфортная доставка пассажира до места назначения.

Автор: Александр Движков

Рейтинг: 1028

Теги: управление уровнем услуг, SLM

## [Какие последствия имеет игнорирование дефектов в программном обеспечении?](https://cleverics.ru/digital/kb-qa/kakie-posledstviya-imeet-ignorirovanie-defektov-v-programmnom-obespechenii/)

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

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

Рейтинг: 1028

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

## [Почему в корпоративной среде сложно реализовать модель возмещения стоимости ИТ-услуг?](https://cleverics.ru/digital/kb-qa/pochemu-v-korporativnoy-srede-slozhno-realizovat-model-vozmeshcheniya-stoimosti-it-uslug/)

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

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

Рейтинг: 1028

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

## [Какие методы наиболее эффективны для предотвращения инцидентов через управление проблемами?](https://cleverics.ru/digital/kb-qa/kakie-metody-naibolee-effektivny-dlya-predotvrashcheniya-intsidentov-cherez-upravlenie-problemami/)

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

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

Рейтинг: 1028

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

## [Какие коммуникационные сложности возникают при переходе к частым релизам и как их преодолеть?](https://cleverics.ru/digital/kb-qa/kakie-kommunikatsionnye-slozhnosti-voznikayut-pri-perekhode-k-chastym-relizam-i-kak-ikh-preodolet/)

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

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

Рейтинг: 1028

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

## [Какие риски возникают при игнорировании аналитики в отчетах процессов?](https://cleverics.ru/digital/kb-qa/kakie-riski-voznikayut-pri-ignorirovanii-analitiki-v-otchetakh-protsessov/)

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

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

Рейтинг: 1028

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