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

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

## [Как создать единую систему мониторинга для распределенных команд поддержки?](https://cleverics.ru/digital/kb-qa/kak-sozdat-edinuyu-sistemu-monitoringa-dlya-raspredelennykh-komand-podderzhki/)

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

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

Рейтинг: 849

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

## [Почему часто возникают конфликты между проектным офисом и подразделениями эксплуатации и преобразования услуг?](https://cleverics.ru/digital/kb-qa/pochemu-chasto-voznikayut-konflikty-mezhdu-proektnym-ofisom-i-podrazdeleniyami-ekspluatatsii-i-preob/)

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

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

Рейтинг: 848

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

## [Как связаны частота релизов и качество конечного продукта в современных ИТ-практиках?](https://cleverics.ru/digital/kb-qa/kak-svyazany-chastota-relizov-i-kachestvo-konechnogo-produkta-v-sovremennykh-it-praktikakh/)

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

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

Рейтинг: 848

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

## [Какие основные отличия подхода к ИТ-услугам при внедрении ITSM от традиционного подхода?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-otlichiya-podkhoda-k-it-uslugam-pri-vnedrenii-itsm-ot-traditsionnogo-podkhoda/)

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

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

Рейтинг: 848

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

## [Какие причины могут привести к закрытию инцидента с кодом "Нет решения"?](https://cleverics.ru/digital/kb-qa/kakie-prichiny-mogut-privesti-k-zakrytiyu-intsidenta-s-kodom-net-resheniya/)

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

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

Рейтинг: 848

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

## [В чем сходство между IT4IT и ITIL v3 в описании функционирования ИТ?](https://cleverics.ru/digital/kb-qa/v-chem-skhodstvo-mezhdu-it4it-i-itil-v3-v-opisanii-funktsionirovaniya-it/)

Основное сходство между IT4IT и ITIL v3 заключается в использовании концепции жизненного цикла услуги. В IT4IT сервисная модель (Service Model) построена вокруг четырех основных столпов и представляет собой Service Backbone, что по сути соответствует этапам жизненного цикла услуги в ITIL v3 - от концепции до оказания услуги. Обе модели рассматривают ИТ-услуги в разрезе процессов, и многие функциональные компоненты в IT4IT (такие как управление инцидентами, проблемами, изменениями) напрямую соответствуют стандартным процессам ITIL v3. При переходе к ITIL v4 видно еще больше общего, в частности, использование цепочки создания ценности (Value Chain), впервые предложенной Майклом Портером. Обе модели стремятся описать целостную картину ИТ-управления, а не просто набор разрозненных процессов.

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

Рейтинг: 848

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

## [Почему в ITIL роли менеджера изменений часто вызывают неоднозначность в понимании?](https://cleverics.ru/digital/kb-qa/pochemu-v-itil-roli-menedzhera-izmeneniy-chasto-vyzyvayut-neodnoznachnost-v-ponimanii/)

Роли менеджера изменений в ITIL часто вызывают неоднозначность, потому что в ITIL V3 эта роль не была описана как отдельная, а вместо нее упоминались другие роли, такие как владелец процесса и практик. В зависимости от контекста и организации роль 'менеджера изменений' могла включать в себя различные функции, иногда совмещая обязанности менеджера процесса, администратора изменений и председателя CAB. Даже в ITIL4, где роль менеджера изменений стала официальной, остается гибкость в распределении обязанностей: менеджер изменений может выступать как универсальный ролевой игрок, объединяющий несколько функций, или его обязанности могут быть распределены между менеджером изменений и координаторами, в зависимости от масштаба организации и сложности изменений.

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

Рейтинг: 848

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

## [Как Output и Outcome соотносятся с процессами Service Management?](https://cleverics.ru/digital/kb-qa/kak-output-i-outcome-sootnosyatsya-s-protsessami-service-management/)

В Service Management Output рассматривается как конечный результат процессов предоставления услуг, тогда как Outcome определяет ценность услуги с точки зрения потребителя. Service Management стремится к созданию и поддержанию услуг, которые не просто технически корректны, но и приносят реальную пользу клиентам. Это означает, что при разработке услуг необходимо учитывать, как output влияет на достижение целевого outcome.

Автор: Александр Движков

Рейтинг: 848

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

## [Почему второй вариант организации управления изменениями редко реализуется на практике?](https://cleverics.ru/digital/kb-qa/pochemu-vtoroy-variant-organizatsii-upravleniya-izmeneniyami-redko-realizuetsya-na-praktike/)

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

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

Рейтинг: 848

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

## [Какие ограничения существуют у первой линии поддержки при оценке влияния инцидентов?](https://cleverics.ru/digital/kb-qa/kakie-ogranicheniya-sushchestvuyut-u-pervoy-linii-podderzhki-pri-otsenke-vliyaniya-intsidentov/)

У первой линии поддержки существуют следующие ограничения при оценке влияния инцидентов: 1) Доступны только субъективные оценки пользователя, без технической диагностики. 2) Объем диагностической информации минимален на начальном этапе обращения. 3) Пользователь может не знать о проблемах других сотрудников. 4) Сложности в объективной оценке степени недоступности функционала ('совсем не работает' против 'частично не работает'). 5) Необходимость быстро принять решение об уровне влияния, имея ограниченную информацию. Эти ограничения делают важным разработку четких вопросов для пользователя, которые позволяют максимально объективно определить влияние инцидента.

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

Рейтинг: 848

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