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

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

## [Как определить, может ли изменение быть стандартизировано и выполняться как запрос на обслуживание?](https://cleverics.ru/digital/kb-qa/kak-opredelit-mozhet-li-izmenenie-byt-standartizirovano-i-vypolnyatsya-kak-zapros-na-obsluzhivanie/)

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

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

Рейтинг: 1179

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

## [В чем заключается разница между операционной деятельностью ИТ и управлением ИТ-услугами?](https://cleverics.ru/digital/kb-qa/v-chem-zaklyuchaetsya-raznitsa-mezhdu-operatsionnoy-deyatelnostyu-it-i-upravleniem-it-uslugami/)

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

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

Рейтинг: 1179

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

## [Кто должен принимать решение об объявлении инцидента значительным?](https://cleverics.ru/digital/kb-qa/kto-dolzhen-prinimat-reshenie-ob-obyavlenii-intsidenta-znachitelnym/)

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

Автор: Роман Журавлёв

Рейтинг: 1179

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

## [Какие метрики должны использоваться для оценки выполнения целей процесса в ITIL?](https://cleverics.ru/digital/kb-qa/kakie-metriki-dolzhny-ispolzovatsya-dlya-otsenki-vypolneniya-tseley-protsessa-v-itil/)

Для оценки выполнения целей процесса в ITIL должны использоваться метрики, которые: - Непосредственно указаны в формулировке цели (например, для цели "увеличить долю решённых инцидентов до 95%" метрикой будет процент своевременно устранённых инцидентов). - Соответствуют критерию измеримости: имеют количественную шкалу и метод расчёта. - Привязаны к временным рамкам (ежемесячные, ежеквартальные отчёты). - Учитывают как количественные показатели (проценты, время выполнения), так и качественные аспекты в операционных задачах. - Связаны с цепочкой ценности: показывают влияние на качество услуг или бизнес-результаты. При этом метрики для задач процесса могут быть статичными (так как задачи редко меняются), тогда как для целей они переопределяются при каждом пересмотре целей.

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

Рейтинг: 1179

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

## [Как в условиях SLA описать взаимосвязь между инфраструктурными компонентами и ИТ-сервисами?](https://cleverics.ru/digital/kb-qa/kak-v-usloviyakh-sla-opisat-vzaimosvyaz-mezhdu-infrastrukturnymi-komponentami-i-it-servisami/)

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

Автор: Евгений Шилов

Рейтинг: 1179

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

## [Какие основные причины препятствуют достижению кратного ускорения в разработке программного обеспечения?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-prichiny-prepyatstvuyut-dostizheniyu-kratnogo-uskoreniya-v-razrabotke-programmnogo-ob/)

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

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

Рейтинг: 1178

Теги: архитектура ИТ, TOGAF и IT4IT, бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, командная работа, поток создания ценности (Value Stream), трансформация, ускорение, Time-to-Market, управление конфигурациями, CMDB, управление релизами

## [Какова основная цель внедрения гибких практик в разработке ПО?](https://cleverics.ru/digital/kb-qa/kakova-osnovnaya-tsel-vnedreniya-gibkikh-praktik-v-razrabotke-po/)

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

Автор: Павел Капусткин

Рейтинг: 1178

Теги: Agile и гибкие методы разработки ПО, DevOps, CI/CD, бизнес, ценность, бизнес-заказчик, разработка ПО, трансформация, ускорение, Time-to-Market, управление релизами

## [Как создать общий KPI на основе двух tension-метрик для оценки баланса в управлении инцидентами?](https://cleverics.ru/digital/kb-qa/kak-sozdat-obshchiy-kpi-na-osnove-dvukh-tension-metrik-dlya-otsenki-balansa-v-upravlenii-intsidentam/)

Для объединения двух tension-метрик в один общий KPI необходимо использовать геометрическое среднее (а не арифметическое). Если K1 — метрика своевременности, а K2 — метрика результативности, то итоговый K = √(K1 × K2). Это обеспечивает чувствительность к игнорированию одной из метрик (при значении одной из них в 0% общий KPI также будет равен 0%), в то время как при равных значениях обеих метрик итоговый KPI соответствует уровню их значений. Геометрическое среднее лучше отражает баланс между метриками, чем арифметическое, поскольку низкое значение одной метрики сильно влияет на общий результат.

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

Рейтинг: 1178

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

## [Какие основные элементы должны быть включены в модель процесса управления изменениями?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-elementy-dolzhny-byt-vklyucheny-v-model-protsessa-upravleniya-izmeneniyami/)

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

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

Рейтинг: 1178

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

## [Какие преимущества даёт использование DevOps в организации ИТ-процессов?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-daet-ispolzovanie-devops-v-organizatsii-it-protsessov/)

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

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

Рейтинг: 1178

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