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

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

## [Почему важна информация о конфигурационной архитектуре для эффективного управления изменениями?](https://cleverics.ru/digital/kb-qa/pochemu-vazhna-informatsiya-o-konfiguratsionnoy-arkhitekture-dlya-effektivnogo-upravleniya-izmeneniy/)

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

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

Рейтинг: 837

Теги: архитектура ИТ, TOGAF и IT4IT, бизнес, ценность, бизнес-заказчик, управление изменениями, управление инцидентами, управление конфигурациями, CMDB, управление релизами, управление рисками

## [Почему многие производители ПО устанавливают нормативы на решение проблем через SLA, несмотря на их нецелесообразность?](https://cleverics.ru/digital/kb-qa/pochemu-mnogie-proizvoditeli-po-ustanavlivayut-normativy-na-reshenie-problem-cherez-sla-nesmotrya-na/)

Многие производители ПО устанавливают нормативы на решение проблем через SLA, поскольку эти рассуждения о природе управления проблемами не до конца известны или не принимаются во внимание разработчиками программного обеспечения. Это приводит к созданию инструментов, где нормирование устанавливается в разрезе всего процесса управления проблемами, включая этапы, которые не поддаются стандартной нормировке. Вероятно, такие решения принимаются для создания видимости количественного контроля процесса, несмотря на то что реальная сложность и вариативность решения проблем делают такое нормирование неэффективным и часто контрпродуктивным.

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

Рейтинг: 837

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

## [Почему сложно найти программные средства для ИТ-бюджетирования?](https://cleverics.ru/digital/kb-qa/pochemu-slozhno-nayti-programmnye-sredstva-dlya-it-byudzhetirovaniya/)

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

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

Рейтинг: 837

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

## [Как определяется разумный минимум ролей при использовании ролевой модели управления доступом?](https://cleverics.ru/digital/kb-qa/kak-opredelyaetsya-razumnyy-minimum-roley-pri-ispolzovanii-rolevoy-modeli-upravleniya-dostupom/)

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

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

Рейтинг: 837

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

## [Почему каталог услуг уделяется больше внимания, чем программе совершенствования услуг?](https://cleverics.ru/digital/kb-qa/pochemu-katalog-uslug-udelyaetsya-bolshe-vnimaniya-chem-programme-sovershenstvovaniya-uslug/)

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

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

Рейтинг: 837

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

## [В чем отличие между эскалацией с произвольным маршрутом и фиксированным маршрутом?](https://cleverics.ru/digital/kb-qa/v-chem-otlichie-mezhdu-eskalatsiey-s-proizvolnym-marshrutom-i-fiksirovannym-marshrutom/)

Основное отличие заключается в том, как определяется следующий шаг в обработке инцидента. При произвольном маршруте специалист самостоятельно принимает решение о дальнейшем направлении инцидента на основе результатов диагностики. Например, инцидент, связанный с отказом информационной системы, может быть направлен администраторам ЦОД или в сетевую группу в зависимости от выявленной причины. При фиксированном маршруте для каждой услуги заранее установлена четкая последовательность линий поддержки и их ответственность. Это означает, что инцидент последовательно передается от L2 к L3 и затем к L4, без возможности отклонения от установленного маршрута, даже если требуется привлечь смежные специалисты. В таком случае привлечение смежников происходит через отдельный инцидент или задание.

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

Рейтинг: 836

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

## [В чем заключается ценность потока развития по отношению к потоку эксплуатационной ценности?](https://cleverics.ru/digital/kb-qa/v-chem-zaklyuchaetsya-tsennost-potoka-razvitiya-po-otnosheniyu-k-potoku-ekspluatatsionnoy-tsennosti/)

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

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

Рейтинг: 836

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

## [Какие механизмы предлагаются для преодоления низкой отзывчивости клиентов при сборе обратной связи?](https://cleverics.ru/digital/kb-qa/kakie-mekhanizmy-predlagayutsya-dlya-preodoleniya-nizkoy-otzyvchivosti-klientov-pri-sbore-obratnoy-s/)

Для преодоления низкой отзывчивости клиентов рекомендуется упростить процессы сбора обратной связи: сократить длину форм, сделать их мобильными, добавить элементы gamification (например, розыгрыши призов). Также важно персонализировать запросы, обращаясь к клиенту по имени и указывая, как его отзыв поможет улучшить услугу. Критически важно, чтобы ответы на отзывы были видимыми — клиент должен видеть, что его мнение влияет на изменения. Это повышает вероятность дальнейшего участия и переводит взаимодействие из «Мертвой зоны» в более активные сценарии.

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

Рейтинг: 836

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

## [Какой принцип ITIL подтверждается упрощением ролевой модели в ITIL 4?](https://cleverics.ru/digital/kb-qa/kakoy-printsip-itil-podtverzhdaetsya-uproshcheniem-rolevoy-modeli-v-itil-4/)

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

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

Рейтинг: 836

Теги: ITIL, общие вопросы менеджмента, трансформация, ускорение, Time-to-Market, управление доступом, IDM, ролевые модели, RBAC, ABAC, управление процессами, ИТ-процессы

## [Почему релизные циклы часто становятся источником задержек в поставке ценности?](https://cleverics.ru/digital/kb-qa/pochemu-reliznye-tsikly-chasto-stanovyatsya-istochnikom-zaderzhek-v-postavke-tsennosti/)

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

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

Рейтинг: 836

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