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

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

## [Какая типовая структура предусмотрена для плана управления сервисными активами и конфигурациями в соответствии с ITIL?](https://cleverics.ru/digital/kb-qa/kakaya-tipovaya-struktura-predusmotrena-dlya-plana-upravleniya-servisnymi-aktivami-i-konfiguratsiyam/)

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

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

Рейтинг: 891

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

## [Какие роли в ITIL V3, согласно разделу 6.4.8 книги Service Transition, выполняют функции координации в рамках процесса управления релизами?](https://cleverics.ru/digital/kb-qa/kakie-roli-v-itil-v3-soglasno-razdelu-6-4-8-knigi-service-transition-vypolnyayut-funktsii-koordinats/)

В разделе 6.4.8 книги Service Transition описаны следующие роли, участвующие в координации процесса управления релизами: менеджер процесса управляет ресурсами для построения, тестирования и развёртывания релизов, контролирует авторизацию и координирует взаимодействие с другими процессами; практик развёртывания отвечает за подготовку документации по релизу и организацию обучения. Все остальные роли, такие как практик пакетирования и построения, практик первичной поддержки, являются техническими и сосредоточены на исполнении конкретных работ, а не на координации. Таким образом, основная «сквозная» ответственность за релиз лежит на менеджере процесса.

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

Рейтинг: 891

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

## [Какие конкретные показатели можно использовать для оценки эффективности процесса управления изменениями?](https://cleverics.ru/digital/kb-qa/kakie-konkretnye-pokazateli-mozhno-ispolzovat-dlya-otsenki-effektivnosti-protsessa-upravleniya-izmen/)

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

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

Рейтинг: 891

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

## [Почему RBAC не является универсальной моделью управления доступом для всех ситуаций?](https://cleverics.ru/digital/kb-qa/pochemu-rbac-ne-yavlyaetsya-universalnoy-modelyu-upravleniya-dostupom-dlya-vsekh-situatsiy/)

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

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

Рейтинг: 891

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

## [Как следует учитывать внеплановые простои, связанные с внесением безотлагательных изменений, в отчётности по доступности ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kak-sleduet-uchityvat-vneplanovye-prostoi-svyazannye-s-vneseniem-bezotlagatelnykh-izmeneniy-v-otchet/)

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

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

Рейтинг: 891

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

## [Почему нельзя полностью автоматизировать процесс управления лицензиями?](https://cleverics.ru/digital/kb-qa/pochemu-nelzya-polnostyu-avtomatizirovat-protsess-upravleniya-litsenziyami/)

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

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

Рейтинг: 891

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

## [Какой способ агрегирования показателей предлагает CLD для управления изменениями?](https://cleverics.ru/digital/kb-qa/kakoy-sposob-agregirovaniya-pokazateley-predlagaet-cld-dlya-upravleniya-izmeneniyami/)

CLD предлагает способ агрегирования показателей для управления изменениями, позволяя сгруппировать метрики по ключевым областям управления. Например, для контроля своевременности реализации (Time to Market) можно использовать метрики Lead Time и Percentage of changes timely implemented. Для управления затратами (Cost per change) подходят Process Time и Standard Change Rate. Для оценки негативного влияния от изменений (Change Risk) можно использовать как прямые метрики (Percentage of Changes Without Recurring incidents, Total time of Major incidents caused by Releases), так и опережающие индикаторы (Release size, Emergency change rate). Такое структурирование помогает формировать комплексную картину эффективности процесса изменений.

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

Рейтинг: 891

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

## [Почему бизнес может противиться изменению правил учета активов для нужд ИТ?](https://cleverics.ru/digital/kb-qa/pochemu-biznes-mozhet-protivitsya-izmeneniyu-pravil-ucheta-aktivov-dlya-nuzhd-it/)

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

Автор: Михаил Тобурдановский

Рейтинг: 891

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

## [Как изменение системы поощрений может повлиять на фокусировку ИТ-команд на результатах?](https://cleverics.ru/digital/kb-qa/kak-izmenenie-sistemy-pooshchreniy-mozhet-povliyat-na-fokusirovku-it-komand-na-rezultatakh/)

Изменение системы поощрений с фокуса на выходах на фокус на результатах кардинально влияет на поведение команд. Например, вместо премирования за 99,9% uptime сервера (выход), который может не учитывать реальный пользовательский опыт, поощрения привязываются к результату: «95% пользователей не сталкиваются с задержками > 2 сек». В компании Ford замена KPI «количество строк кода» на «снижение времени сборки авто» повысила эффективность ИТ на 200%. Такие изменения стимулируют команды думать о конечной ценности своей работы, а не просто о количестве выполненных задач или технических показателях.

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

Рейтинг: 891

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

## [Как можно оценить First Time Resolution без использования процедуры повторного открытия инцидентов?](https://cleverics.ru/digital/kb-qa/kak-mozhno-otsenit-first-time-resolution-bez-ispolzovaniya-protsedury-povtornogo-otkrytiya-intsident/)

Если в процессе не используется понятие 'переоткрытый инцидент', показатель First Time Resolution (FTR) можно получить, анализируя долю инцидентов, с которыми связаны более поздние инциденты, при условии, что система автоматизации процесса управления инцидентами позволяет связывать инциденты друг с другом. Если связь инцидентов используется и для других целей, анализ может стать несколько сложнее, но остается возможным. Также можно формировать полную систему оценки, в которой FTR не учитывается отдельно, поскольку переоткрытые инциденты влияют на другие показатели, например TCR (Ticket Closure Rate).

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

Рейтинг: 891

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