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

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

## [Какие ключевые аспекты канбана обсуждались на мастер-классе?](https://cleverics.ru/digital/kb-qa/kakie-klyuchevye-aspekty-kanbana-obsuzhdalis-na-master-klasse/)

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

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

Рейтинг: 1007

Теги: Канбан, WIP-лимиты, управление релизами

## [Какие ключевые метрики DevOps рекомендуется измерять в первую очередь?](https://cleverics.ru/digital/kb-qa/kakie-klyuchevye-metriki-devops-rekomenduetsya-izmeryat-v-pervuyu-ochered/)

Основной базовый набор ключевых метрик DevOps включает: время нахождения идеи в бэклоге (пока не взяли на реализацию), время прохождения задачи от начала работы до выпуска в продуктивную среду, долю выполненных задач, которые принесли ожидаемую пользу, и предсказуемость выполнения взятых на себя задач за определенные временные периоды. К этому базовому набору можно добавить дополнительные метрики, такие как velocity, MTTR (среднее время восстановления), MTBF (среднее время наработки на отказ) и расход ресурсов на устранение дефектов и инцидентов. Однако важно не количество метрик, а то, что они дают объективную картину ситуации и помогают в принятии решений для уменьшения времени выпуска продукта (lead time).

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

Рейтинг: 1007

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

## [Какие последствия могут быть, если запросы поступают мимо первой линии поддержки в системе ITSM?](https://cleverics.ru/digital/kb-qa/kakie-posledstviya-mogut-byt-esli-zaprosy-postupayut-mimo-pervoy-linii-podderzhki-v-sisteme-itsm/)

Если запросы поступают мимо первой линии поддержки без регистрации в системе автоматизации, возникает «параллельная реальность» в управлении инцидентами. Это приводит к снижению ценности процесса управления инцидентами, так как нарушается прозрачность и полнота данных об инцидентах. Без регистрации обращений невозможно отслеживать их статус, анализировать корневые причины или формировать отчеты. Основные риски связаны с тем, что значительная часть инцидентов, связанных с нарушениями работы прикладного ПО, остается вне системы, что увеличивает общее время восстановления и снижает качество обслуживания бизнес-операций.

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

Рейтинг: 1007

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

## [Как внедрить SMART-подход в управление ITSM-процессами?](https://cleverics.ru/digital/kb-qa/kak-vnedrit-smart-podkhod-v-upravlenie-itsm-protsessami/)

Для внедрения SMART-подхода в управление ITSM-процессами необходимо для каждого процесса сформулировать цели, соответствующие критериям Specific (конкретность), Measurable (измеримость), Achievable (достижимость), Relevant (релевантность), Time-bound (ограниченность сроками). Например, цель для процесса управления инцидентами: 'Сократить среднее время устранения инцидентов с критическим приоритетом до 2 часов к концу квартала'. Эти цели должны быть привязаны к назначению процесса и измеряться через влияние на качество ИТ-услуг.

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

Рейтинг: 1007

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

## [Зачем необходимы критерии приемки на этапах ИТ-процессов?](https://cleverics.ru/digital/kb-qa/zachem-neobkhodimy-kriterii-priemki-na-etapakh-it-protsessov/)

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

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

Рейтинг: 1007

Теги: командная работа, управление доступностью

## [Как определить, какой ИТ-проект принесет компании наибольшую пользу?](https://cleverics.ru/digital/kb-qa/kak-opredelit-kakoy-it-proekt-prineset-kompanii-naibolshuyu-polzu/)

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

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

Рейтинг: 1007

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

## [Когда может потребоваться переопределение приоритета уже обрабатываемого инцидента?](https://cleverics.ru/digital/kb-qa/kogda-mozhet-potrebovatsya-pereopredelenie-prioriteta-uzhe-obrabatyvaemogo-intsidenta/)

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

Автор: Анна Васильева

Рейтинг: 1007

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

## [Какие риски возникают при недостаточном контроле за процессом управления конфигурациями?](https://cleverics.ru/digital/kb-qa/kakie-riski-voznikayut-pri-nedostatochnom-kontrole-za-protsessom-upravleniya-konfiguratsiyami/)

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

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

Рейтинг: 1007

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

## [Почему невозможно создать универсальное определение ценности?](https://cleverics.ru/digital/kb-qa/pochemu-nevozmozhno-sozdat-universalnoe-opredelenie-tsennosti/)

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

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

Рейтинг: 1007

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

## [Как изменился принцип "Упрощайте" из ITIL Practitioner Guidance в ITIL 4?](https://cleverics.ru/digital/kb-qa/kak-izmenilsya-printsip-uproshchayte-iz-itil-practitioner-guidance-v-itil-4/)

Принцип "Упрощайте" (Keep it simple), описанный в ITIL Practitioner Guidance 2016 года, был расширен в ITIL 4 до формулировки "Простота и практичность" (Keep it simple and practical). Это изменение отражает важность не только простоты решения, но и его практической применимости. В ITIL 4 подчеркивается, что слишком сложные решения затрудняют внедрение и эксплуатацию, однако простота ради простоты тоже не имеет смысла, если решение не решает поставленные задачи. Таким образом, акцент смещен с простого упрощения на поиск оптимального баланса между простотой и практической пользой.

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

Рейтинг: 1007

Теги: ITIL, управление релизами