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

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

## [Что такое сквозной процесс приоритизации в контексте ITIL 4?](https://cleverics.ru/digital/kb-qa/chto-takoe-skvoznoy-protsess-prioritizatsii-v-kontekste-itil-4/)

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

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

Рейтинг: 1020

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

## [Как понятие конфигурационной единицы связано с определением границы ответственности?](https://cleverics.ru/digital/kb-qa/kak-ponyatie-konfiguratsionnoy-edinitsy-svyazano-s-opredeleniem-granitsy-otvetstvennosti/)

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

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

Рейтинг: 1020

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

## [Почему не рекомендуется полностью полагаться на чужие примеры при организации изменений в ИТ-команде?](https://cleverics.ru/digital/kb-qa/pochemu-ne-rekomenduetsya-polnostyu-polagatsya-na-chuzhie-primery-pri-organizatsii-izmeneniy-v-it-ko/)

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

Автор: Светлана Сапегина

Рейтинг: 1020

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

## [Что такое системный подход в управлении ИТ-услугами?](https://cleverics.ru/digital/kb-qa/chto-takoe-sistemnyy-podkhod-v-upravlenii-it-uslugami/)

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

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

Рейтинг: 1019

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

## [Каковы особенности управления запросами на обслуживание в ITIL 4?](https://cleverics.ru/digital/kb-qa/kakovy-osobennosti-upravleniya-zaprosami-na-obsluzhivanie-v-itil-4/)

В ITIL 4 управление запросами на обслуживание рассматривается как отдельная практика, отличная от управления инцидентами. В отличие от инцидентов, запросы на обслуживание являются "обычной" частью предоставления услуг. Основные особенности включают создание моделей запросов на обслуживание во время проектирования продуктов и услуг, а не после возникновения запросов. Практика управления запросами на обслуживание задействована на всех этапах жизненного цикла услуг. Для удобства пользователей запросы на обслуживание обычно включаются в пользовательские представления каталога услуг. Каталог запросов содержит информацию о доступных запросах, предварительных требованиях, необходимой информации для инициирования запроса, процессе утверждения и целевом времени выполнения. Это позволяет стандартизировать процесс подачи и выполнения запросов, делая его более прозрачным и предсказуемым для пользователей.

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

Рейтинг: 1019

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

## [Почему важно учитывать склонность к риску организации при совершенствовании ИТ-услуг?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-uchityvat-sklonnost-k-risku-organizatsii-pri-sovershenstvovanii-it-uslug/)

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

Автор: Константин Нарыжный

Рейтинг: 1019

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

## [Почему важно различать управление доступностью и управление непрерывности при организации ИТ-сервисов?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-razlichat-upravlenie-dostupnostyu-i-upravlenie-nepreryvnosti-pri-organizatsii-it-serv/)

Важно различать эти процессы, потому что они решают разные задачи и требуют разных подходов, ресурсов и показателей. Управление доступностью ориентировано на повседневные операции и оптимизацию текущей системы, тогда как управление непрерывностью фокусируется на экстремальных ситуациях и требует создания дополнительной инфраструктуры и процедур. Смешение этих процессов может привести к нерациональному распределению ресурсов: излишней оптимизации там, где нужна избыточность, или наоборот, созданию сложных резервных схем для незначительных сбоев. Чёткое разделение позволяет целенаправленно распределять бюджет и усилия, учитывая специфику различных типов рисков.

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

Рейтинг: 1018

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

## [Как определить, что является дефектом, а что - частью функциональности?](https://cleverics.ru/digital/kb-qa/kak-opredelit-chto-yavlyaetsya-defektom-a-chto-chastyu-funktsionalnosti/)

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

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

Рейтинг: 1018

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

## [Почему нельзя полагаться только на цифры при оценке работы команды?](https://cleverics.ru/digital/kb-qa/pochemu-nelzya-polagatsya-tolko-na-tsifry-pri-otsenke-raboty-komandy/)

Цифры не отражают человеческого фактора: мотивации, качества взаимодействия, скрытых издержек. Например, показатель «100% задач выполнено в срок» может маскировать постоянные переработки сотрудников или откладывание проблем на будущее. Без анализа контекста руководство получает искаженную картину, которая не помогает в принятии решений и может привести к ухудшению эффективности в долгосрочной перспективе.

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

Рейтинг: 1018

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

## [Когда можно обойтись без отдельного процесса управления конфигурациями?](https://cleverics.ru/digital/kb-qa/kogda-mozhno-oboytis-bez-otdelnogo-protsessa-upravleniya-konfiguratsiyami/)

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

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

Рейтинг: 1018

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