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

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

## [Для чего нужно разделять анализ customer journey на четыре аспекта по модели Compass Model, а не использовать более простую методологию?](https://cleverics.ru/digital/kb-qa/dlya-chego-nuzhno-razdelyat-analiz-customer-journey-na-chetyre-aspekta-po-modeli-compass-model-a-ne/)

Разделение анализа customer journey на четыре аспекта по модели Compass Model необходимо потому, что потребительский опыт многогранен и включает в себя не только рациональные факторы (потребности), но и эмоциональные, подсознательные компоненты (желания, стереотипы, эмоции). Более простые методологии часто фокусируются только на основных потребностях и явных пожеланиях, упуская важные аспекты, которые могут сделать разницу между удовлетворённым клиентом и лояльным адвокатом бренда. Модель Compass Model позволяет глубже понять клиента, выявить точки для превосходства ожиданий, разрушить негативные стереотипы и управлять эмоциями, что в совокупности создаёт уникальную ценность и конкурентное преимущество. Четырёхаспектный анализ обеспечивает более полную картину клиентского опыта и позволяет создавать более целостную стратегию взаимодействия.

Автор: Артём Мукосеев

Рейтинг: 1083

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

## [Можно ли поддерживать актуальность CMDB без процесса управления изменениями?](https://cleverics.ru/digital/kb-qa/mozhno-li-podderzhivat-aktualnost-cmdb-bez-protsessa-upravleniya-izmeneniyami/)

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

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

Рейтинг: 1082

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

## [Почему совещания часто заканчиваются безрезультатно?](https://cleverics.ru/digital/kb-qa/pochemu-soveshchaniya-chasto-zakanchivayutsya-bezrezultatno/)

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

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

Рейтинг: 1082

Теги: общие вопросы менеджмента

## [Как определить, за какой ИТ-сервис отвечает конкретный сотрудник?](https://cleverics.ru/digital/kb-qa/kak-opredelit-za-kakoy-it-servis-otvechaet-konkretnyy-sotrudnik/)

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

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

Рейтинг: 1082

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

## [Какие метрики следует использовать для отслеживания прогресса в снижении Time to Market?](https://cleverics.ru/digital/kb-qa/kakie-metriki-sleduet-ispolzovat-dlya-otslezhivaniya-progressa-v-snizhenii-time-to-market/)

Для отслеживания прогресса в снижении Time to Market должны использоваться следующие ключевые метрики: непосредственно время от формирования идеи до выхода на рынок (Time to Market) в абсолютных значениях и относительном сравнении периода к периоду; процент задач, взятых в работу и успешно завершённых (для оценки эффективности процесса); объём выполненной работы, измеряемый количеством завершённых задач за фиксированный период; циклическое время (cycle time) - среднее время выполнения одной задачи; и обратная связь о влиянии выпущенного функционала на бизнес-показатели (доход, удовлетворённость пользователей, рост показателей использования). Важно, чтобы метрики фокусировались на конечных результатах, а не на процессных активностях, таких как количество спринтов или поставленных в задачу часов.

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

Рейтинг: 1082

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

## [Что такое управление проблемами в контексте ITIL и как оно связано с инцидентами?](https://cleverics.ru/digital/kb-qa/chto-takoe-upravlenie-problemami-v-kontekste-itil-i-kak-ono-svyazano-s-intsidentami/)

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

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

Рейтинг: 1081

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

## [Какие риски связаны с полным отказом от ИТ-стратегии в крупной организации?](https://cleverics.ru/digital/kb-qa/kakie-riski-svyazany-s-polnym-otkazom-ot-it-strategii-v-krupnoy-organizatsii/)

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

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

Рейтинг: 1081

Теги: ISO 20000, стратегия, управление проектами, PRINCE2, управление процессами, ИТ-процессы, управление рисками, экономика и финансы, эффективность, оптимизация

## [Как процесс управления инцидентами обеспечивает своевременность решения инцидентов в ITSM?](https://cleverics.ru/digital/kb-qa/kak-protsess-upravleniya-intsidentami-obespechivaet-svoevremennost-resheniya-intsidentov-v-itsm/)

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

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

Рейтинг: 1081

Теги: ITSM, архитектура ИТ, TOGAF и IT4IT, мотивация персонала, стимулирование, поддержка пользователей, Service Desk, Help Desk, управление инцидентами

## [Как оценить, насколько команда готова к переходу на более частые релизы?](https://cleverics.ru/digital/kb-qa/kak-otsenit-naskolko-komanda-gotova-k-perekhodu-na-bolee-chastye-relizy/)

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

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

Рейтинг: 1081

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

## [Как определить целевые значения показателей ИТ-сервисов?](https://cleverics.ru/digital/kb-qa/kak-opredelit-tselevye-znacheniya-pokazateley-it-servisov/)

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

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

Рейтинг: 1081

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