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

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

## [В чём разница между «срочным» и «экстренным» изменением в ITIL?](https://cleverics.ru/digital/kb-qa/v-chem-raznitsa-mezhdu-srochnym-i-ekstrennym-izmeneniem-v-itil/)

Срочное изменение предполагает определённый временной приоритет, но допускает относительную градацию (например, «очень срочно» или «не так срочно»), что часто ведёт к злоупотреблению термином. Экстренное изменение (emergency) в ITIL — это категория, не подразумевающая градаций: оно требует немедленного выполнения без отлагательств, так как связано с критическими сбоями или угрозами безопасности. Например, если сервис полностью недоступен для клиентов, это emergency — все ресурсы переключаются на его исправление, тогда как «срочное» изменение может укладываться в запланированные сроки.

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

Рейтинг: 1278

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

## [Почему менеджеры ИТ-процессов часто совмещают свои обязанности с другими должностями?](https://cleverics.ru/digital/kb-qa/pochemu-menedzhery-it-protsessov-chasto-sovmeshchayut-svoi-obyazannosti-s-drugimi-dolzhnostyami/)

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

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

Рейтинг: 1278

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

## [Какие основные типы процессов выделяются в менеджменте согласно распространенной классификации?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-tipy-protsessov-vydelyayutsya-v-menedzhmente-soglasno-rasprostranennoy-klassifikatsii/)

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

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

Рейтинг: 1278

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

## [Чем отличается System Lead Time от Customer Lead Time в гибкой разработке?](https://cleverics.ru/digital/kb-qa/chem-otlichaetsya-system-lead-time-ot-customer-lead-time-v-gibkoy-razrabotke/)

System Lead Time (время в системе) считается от точки принятия обязательств (красный флажок) до момента поставки результата заказчику, тогда как Customer Lead Time считается от момента принятия решения о реализации задачи (зеленый флажок) до момента поставки. System Lead Time является одной из ключевых характеристик эффективности разработки, по которой можно с высокой вероятностью предсказывать сроки выпуска для новых задач, выявлять риски и классифицировать задачи.

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

Рейтинг: 1278

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

## [В чем отличие обработки заявок от обработки инцидентов?](https://cleverics.ru/digital/kb-qa/v-chem-otlichie-obrabotki-zayavok-ot-obrabotki-intsidentov/)

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

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

Рейтинг: 1278

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

## [Как определяется допустимый размер штрафных санкций при разработке SLA?](https://cleverics.ru/digital/kb-qa/kak-opredelyaetsya-dopustimyy-razmer-shtrafnykh-sanktsiy-pri-razrabotke-sla/)

Допустимый размер штрафных санкций при разработке Соглашений об уровне обслуживания (SLA) определяется в зависимости от типа поставщика и характера услуги. Для внешних поставщиков (Тип III) штрафы обычно составляют 20-30% от суммы контракта, но могут быть ограничены законодательством, как в случае с 44-ФЗ, где максимальный размер штрафа составляет 2,5% от суммы контракта. Для внутренних поставщиков размер штрафов, как правило, не выражается в денежном эквиваленте, а влияет на премии сотрудников. При этом важно учитывать, чтобы размер штрафов мотивировал поставщика на улучшение качества услуги, но не превышал разумные пределы, чтобы не привести к убыточности сотрудничества.

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

Рейтинг: 1276

Теги: SLA, аутсорсинг, интеграция услуг, мотивация персонала, стимулирование, постоянное улучшение, совершенствование, CSI, PDCA, управление уровнем услуг, SLM, эффективность, оптимизация

## [Когда проводится оценка рисков для стандартных изменений в ITIL?](https://cleverics.ru/digital/kb-qa/kogda-provoditsya-otsenka-riskov-dlya-standartnykh-izmeneniy-v-itil/)

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

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

Рейтинг: 1270

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

## [Можно ли использовать геометрическое среднее для более чем двух tension-метрик?](https://cleverics.ru/digital/kb-qa/mozhno-li-ispolzovat-geometricheskoe-srednee-dlya-bolee-chem-dvukh-tension-metrik/)

Да, геометрическое среднее легко обобщается на произвольное количество tension-метрик. Для N метрик K = N√(K1 × K2 × ... × KN). Однако на практике случаи с тремя и более tension-метриками встречаются редко, так как сложность балансировки между большим количеством конфликтующих показателей затрудняет управление и анализ. Обычно ограничиваются парой ключевых метрик, которые наиболее точно отражают критические аспекты процесса.

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

Рейтинг: 1270

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

## [Как отличается подход к ответственности за инциденты между внешними сервис-провайдерами и внутренними ИТ-подразделениями?](https://cleverics.ru/digital/kb-qa/kak-otlichaetsya-podkhod-k-otvetstvennosti-za-intsidenty-mezhdu-vneshnimi-servis-provayderami-i-vnut/)

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

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

Рейтинг: 1270

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

## [Почему важно понимать цель использования терминов в ITSM?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-ponimat-tsel-ispolzovaniya-terminov-v-itsm/)

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

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

Рейтинг: 1269

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