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

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

## [Что такое доменная структура в контексте управления ИТ-услугами?](https://cleverics.ru/digital/kb-qa/chto-takoe-domennaya-struktura-v-kontekste-upravleniya-it-uslugami/)

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

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

Рейтинг: 1354

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

## [Что такое work in progress лимит и как он влияет на скорость работы команды?](https://cleverics.ru/digital/kb-qa/chto-takoe-work-in-progress-limit-i-kak-on-vliyaet-na-skorost-raboty-komandy/)

Work in progress (WIP) лимит - это ограничение на количество элементов (историй, задач), которые команда может одновременно обрабатывать на первом этапе конвейера разработки. WIP лимит влияет на скорость работы команды следующим образом: уменьшение количества элементов, допущенных в обработку одновременно, уменьшает переключение контекстов, увеличивает фокусировку на текущих задачах и позволяет элементам быстрее проходить через весь конвейер разработки. Это явление иногда называют "меньше впустим - быстрее пролетит". WIP лимиты помогают выявить узкие места в процессе, улучшают поток работы и увеличивают общую производительность команды, предотвращая перегрузку.

Автор: Андрей Труфанов

Рейтинг: 1353

Теги: DevOps, CI/CD, Канбан, WIP-лимиты, командная работа, мониторинг, эффективность, оптимизация

## [Когда целесообразно использовать специализированные группы вместо единой точки контакта?](https://cleverics.ru/digital/kb-qa/kogda-tselesoobrazno-ispolzovat-spetsializirovannye-gruppy-vmesto-edinoy-tochki-kontakta/)

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

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

Рейтинг: 1353

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

## [Какие ключевые правила необходимо соблюдать при реализации проекта по построению модели аллокации ИТ-затрат?](https://cleverics.ru/digital/kb-qa/kakie-klyuchevye-pravila-neobkhodimo-soblyudat-pri-realizatsii-proekta-po-postroeniyu-modeli-allokat/)

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

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

Рейтинг: 1350

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

## [Что означает аббревиатура SLA в контексте бизнес-процессов?](https://cleverics.ru/digital/kb-qa/chto-oznachaet-abbreviatura-sla-v-kontekste-biznes-protsessov/)

SLA (Service Level Agreement) означает Соглашение об уровне обслуживания (сервисное соглашение). Это документ, в котором фиксируются обязательства одного подразделения перед другим по количественным и качественным показателям предоставляемых услуг. SLA определяет, что конкретно должно быть поставлено, в какие сроки, в каком объеме и качестве. Такие соглашения изначально применялись в ИТ-сфере между ИТ-отделом и бизнес-подразделениями, но сегодня распространились на многие другие области бизнеса.

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

Рейтинг: 1349

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

## [Какой баланс достигается в управлении инцидентами при использовании двух tension-метрик?](https://cleverics.ru/digital/kb-qa/kakoy-balans-dostigaetsya-v-upravlenii-intsidentami-pri-ispolzovanii-dvukh-tension-metrik/)

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

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

Рейтинг: 1346

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

## [Чем отличаются инцидент и проблема в ИТ-сопровождении?](https://cleverics.ru/digital/kb-qa/chem-otlichayutsya-intsident-i-problema-v-it-soprovozhdenii/)

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

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

Рейтинг: 1345

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

## [Почему сложно определить причину снижения производительности системы?](https://cleverics.ru/digital/kb-qa/pochemu-slozhno-opredelit-prichinu-snizheniya-proizvoditelnosti-sistemy/)

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

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

Рейтинг: 1344

Теги: мониторинг, управление конфигурациями, CMDB, эффективность, оптимизация

## [Какие основные принципы управления рисками описаны в ISO 31000?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-printsipy-upravleniya-riskami-opisany-v-iso-31000/)

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

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

Рейтинг: 1344

Теги: ISO 20000, мониторинг, управление рисками

## [Как определить, какие события системы мониторинга требуют реагирования?](https://cleverics.ru/digital/kb-qa/kak-opredelit-kakie-sobytiya-sistemy-monitoringa-trebuyut-reagirovaniya/)

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

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

Рейтинг: 1340

Теги: мониторинг