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

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

## [Как заказчик ИТ-услуги влияет на определение доступности?](https://cleverics.ru/digital/kb-qa/kak-zakazchik-it-uslugi-vliyaet-na-opredelenie-dostupnosti/)

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

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

Рейтинг: 959

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

## [Как определить, что инцидент вызван определенным изменением?](https://cleverics.ru/digital/kb-qa/kak-opredelit-chto-intsident-vyzvan-opredelennym-izmeneniem/)

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

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

Рейтинг: 959

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

## [Чем полезны деловые игры для отдельного участника?](https://cleverics.ru/digital/kb-qa/chem-polezny-delovye-igry-dlya-otdelnogo-uchastnika/)

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

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

Рейтинг: 959

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

## [Как различаются подходы к обработке запросов в HP OpenView Service Desk и в таких системах, как HP SM или BMC Remedy ITSM Suite?](https://cleverics.ru/digital/kb-qa/kak-razlichayutsya-podkhody-k-obrabotke-zaprosov-v-hp-openview-service-desk-i-v-takikh-sistemakh-kak/)

В HP OpenView Service Desk используется, по мнению автора, более рациональное деление по сравнению с HP SM или BMC Remedy ITSM Suite. В OpenView деление сделано по принципу различия между инфраструктурными инцидентами и обращениями пользователей, в то время как в других системах деление чаще проводится между инцидентами и сервисными запросами. В реальной практике разница в обработке инцидента, поданного пользователем, и сервисного запроса, поданного пользователем, не так велика, как разница между инфраструктурным инцидентом и обращением пользователя. Это подразумевает разную классификацию, разные процедуры выявления/регистрации и разные процедуры закрытия для этих двух основных типов случаев.

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

Рейтинг: 959

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

## [В чём основное отличие процесса управления проблемами от управления инцидентами?](https://cleverics.ru/digital/kb-qa/v-chem-osnovnoe-otlichie-protsessa-upravleniya-problemami-ot-upravleniya-intsidentami/)

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

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

Рейтинг: 958

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

## [Следует ли устранять дефекты сразу после их обнаружения?](https://cleverics.ru/digital/kb-qa/sleduet-li-ustranyat-defekty-srazu-posle-ikh-obnaruzheniya/)

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

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

Рейтинг: 958

Теги: Agile и гибкие методы разработки ПО, разработка ПО

## [Как определить, что необходимо инвестировать в уменьшение технического долга?](https://cleverics.ru/digital/kb-qa/kak-opredelit-chto-neobkhodimo-investirovat-v-umenshenie-tekhnicheskogo-dolga/)

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

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

Рейтинг: 958

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

## [Почему крупные компании предпочитают самостоятельно подготавливать агентов изменений, а не нанимать их извне?](https://cleverics.ru/digital/kb-qa/pochemu-krupnye-kompanii-predpochitayut-samostoyatelno-podgotavlivat-agentov-izmeneniy-a-ne-nanimat/)

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

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

Рейтинг: 958

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

## [В каких случаях можно отказаться от использования классификации при маршрутизации обращений?](https://cleverics.ru/digital/kb-qa/v-kakikh-sluchayakh-mozhno-otkazatsya-ot-ispolzovaniya-klassifikatsii-pri-marshrutizatsii-obrashchen/)

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

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

Рейтинг: 958

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

## [Почему необходимое количество ответов в опросе не зависит от общего числа пользователей?](https://cleverics.ru/digital/kb-qa/pochemu-neobkhodimoe-kolichestvo-otvetov-v-oprose-ne-zavisit-ot-obshchego-chisla-polzovateley/)

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

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

Рейтинг: 958

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