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

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

## [Как предотвратить злоупотребление кодом закрытия "Нет решения" в службе поддержки?](https://cleverics.ru/digital/kb-qa/kak-predotvratit-zloupotreblenie-kodom-zakrytiya-net-resheniya-v-sluzhbe-podderzhki/)

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

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

Рейтинг: 912

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

## [Какие дополнительные метрики необходимы для сбалансированной оценки деятельности групп поддержки?](https://cleverics.ru/digital/kb-qa/kakie-dopolnitelnye-metriki-neobkhodimy-dlya-sbalansirovannoy-otsenki-deyatelnosti-grupp-podderzhki/)

Для сбалансированной оценки деятельности групп поддержки необходима пара метрик: 1) Метрика своевременности – оценивает скорость обработки инцидентов с учётом доли ответственности за соблюдение сроков; 2) Метрика результативности – оценивает, насколько группа реально способствует решению инцидента при его обработке (предотвращает «футбол»). Только комбинация этих метрик позволяет объективно оценить как скорость работы группы, так и её реальный вклад в решение инцидентов, а не просто перемещение их между группами.

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

Рейтинг: 912

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

## [Как влияет повторное открытие инцидентов на показатель TCR (Ticket Closure Rate)?](https://cleverics.ru/digital/kb-qa/kak-vliyaet-povtornoe-otkrytie-intsidentov-na-pokazatel-tcr-ticket-closure-rate/)

Повторное открытие инцидентов негативно влияет на показатель TCR (Ticket Closure Rate), который представляет собой отношение количества решенных инцидентов к количеству назначенных инцидентов. Каждый переоткрытый инцидент рассматривается как новое назначение, что увеличивает знаменатель формулы TCR, тем самым ухудшая его значение. Это означает, что чем больше инцидентов переоткрывается, тем ниже становится TCR, что отражает снижение эффективности работы службы поддержки.

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

Рейтинг: 912

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

## [Как влияет смена состава команды на её эффективность в условиях отсутствия явного лидерства?](https://cleverics.ru/digital/kb-qa/kak-vliyaet-smena-sostava-komandy-na-ee-effektivnost-v-usloviyakh-otsutstviya-yavnogo-liderstva/)

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

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

Рейтинг: 912

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

## [Как определить, является ли проблема с интернетом локальной или общей для провайдера?](https://cleverics.ru/digital/kb-qa/kak-opredelit-yavlyaetsya-li-problema-s-internetom-lokalnoy-ili-obshchey-dlya-provaydera/)

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

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

Рейтинг: 912

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

## [Как связать ИТ-метрики с бизнес-целями согласно ITIL 4?](https://cleverics.ru/digital/kb-qa/kak-svyazat-it-metriki-s-biznes-tselyami-soglasno-itil-4/)

Для связи ИТ-метрик с бизнес-целями следует заменить показатели, фокусирующиеся только на выходах, на метрики, влияющие на результаты. Вместо 'времени ответа на запрос' измерять 'рост NPS клиентов', вместо 'количества релизов' - 'ускорение вывода продукта на рынок'. Хороший пример - компания Ford, которая заменила KPI 'количество строк кода' на 'снижение времени сборки авто', повысив эффективность ИТ на 200%. Необходимо всегда проверять, как технические метрики влияют на конечные бизнес-результаты и перестроить систему отчетности и поощрений вокруг этих результатов.

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

Рейтинг: 911

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

## [Почему управление проблемами часто остается в тени по сравнению с управлением инцидентами?](https://cleverics.ru/digital/kb-qa/pochemu-upravlenie-problemami-chasto-ostaetsya-v-teni-po-sravneniyu-s-upravleniem-intsidentami/)

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

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

Рейтинг: 911

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

## [Почему важно сохранять работоспособность продукта на каждом этапе разработки?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-sokhranyat-rabotosposobnost-produkta-na-kazhdom-etape-razrabotki/)

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

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

Рейтинг: 911

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

## [Какие ошибки чаще всего допускаются при внедрении системы категоризации инцидентов?](https://cleverics.ru/digital/kb-qa/kakie-oshibki-chashche-vsego-dopuskayutsya-pri-vnedrenii-sistemy-kategorizatsii-intsidentov/)

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

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

Рейтинг: 911

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

## [Почему возникает путаница с определением роли координатора в ITIL, например, в процессах управления изменениями и релизами?](https://cleverics.ru/digital/kb-qa/pochemu-voznikaet-putanitsa-s-opredeleniem-roli-koordinatora-v-itil-naprimer-v-protsessakh-upravleni/)

Путаница возникает по причине того, что стандарт ITIL V3 описывает процессы и общие подходы к управлению, но не детализирует организационные роли на уровне исполнения. Например, роль "Практик изменений" (Change practitioner) включает обязанности по мониторингу и проверке, но не прямо указывает на необходимость координации действий, которая скорее относится к процессу управления изменениями в целом. Аналогично, в процессе управления релизами координация формально не закреплена за конкретной ролью, хотя в обязанности менеджера процесса входит координация ресурсов и взаимодействие с другими процессами. Это приводит к неоднозначности в реализации процессов на практике и необходимости адаптировать стандарт под внутренние структуры организации.

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

Рейтинг: 911

Теги: ISO 20000, ITIL, мониторинг, общие вопросы менеджмента, управление изменениями, управление отношениями, взаимодействие, BRM, управление процессами, ИТ-процессы, управление релизами