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

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

## [Чем проблема отличается от инцидента в контексте ИТ-управления?](https://cleverics.ru/digital/kb-qa/chem-problema-otlichaetsya-ot-intsidenta-v-kontekste-it-upravleniya/)

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

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

Рейтинг: 1414

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

## [Какие изменения в подходе к релизам необходимы для эффективного CI/CD?](https://cleverics.ru/digital/kb-qa/kakie-izmeneniya-v-podkhode-k-relizam-neobkhodimy-dlya-effektivnogo-ci-cd/)

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

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

Рейтинг: 1413

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

## [Почему традиционное управление проектами может быть вредным в гибкой разработке ИТ-продуктов?](https://cleverics.ru/digital/kb-qa/pochemu-traditsionnoe-upravlenie-proektami-mozhet-byt-vrednym-v-gibkoy-razrabotke-it-produktov/)

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

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

Рейтинг: 1413

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

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

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

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

Рейтинг: 1411

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

## [Какие факторы могут помешать внедрению методологий вроде Scrum или Kanban?](https://cleverics.ru/digital/kb-qa/kakie-faktory-mogut-pomeshat-vnedreniyu-metodologiy-vrode-scrum-ili-kanban/)

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

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

Рейтинг: 1411

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

## [Какие преимущества дает использование итерационного подхода при внедрении ITSM?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-daet-ispolzovanie-iteratsionnogo-podkhoda-pri-vnedrenii-itsm/)

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

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

Рейтинг: 1406

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

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

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

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

Рейтинг: 1405

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

## [Как влияет сложность сервисных отношений на определение состава заказчиков ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kak-vliyaet-slozhnost-servisnykh-otnosheniy-na-opredelenie-sostava-zakazchikov-it-uslug/)

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

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

Рейтинг: 1403

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

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

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

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

Рейтинг: 1399

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

## [Что подразумевает релевантность (R) метрики в системе оценки?](https://cleverics.ru/digital/kb-qa/chto-podrazumevaet-relevantnost-r-metriki-v-sisteme-otsenki/)

Релевантность метрики означает её соответствие и полезность для достижения поставленных целей. Это проверка, действительно ли нужно измерять данный показатель, чтобы принимать управленческие решения. Если данные не используются для конкретных решений или действий, метрика теряет смысл и не соответствует критерию R из SMART. Например, отчётность без последующих действий — нерелевантна.

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

Рейтинг: 1397

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