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

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

## [Почему получение точной оценки загруженности сотрудников через учет трудозатрат является недостижимой целью?](https://cleverics.ru/digital/kb-qa/pochemu-poluchenie-tochnoy-otsenki-zagruzhennosti-sotrudnikov-cherez-uchet-trudozatrat-yavlyaetsya-n/)

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

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

Рейтинг: 946

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

## [Как часто рекомендуется проводить пост-имплементационный обзор (PIR) после внедрения изменений?](https://cleverics.ru/digital/kb-qa/kak-chasto-rekomenduetsya-provodit-post-implementatsionnyy-obzor-pir-posle-vnedreniya-izmeneniy/)

Рекомендуется проводить пост-имплементационный обзор (PIR) через 30-90 дней после завершения внедрения изменений. Этот период позволяет оценить краткосрочные и среднесрочные эффекты, включая стабилизацию процессов и реакцию пользователей. Для критических изменений может быть назначен дополнительный экспресс-обзор через 1-2 недели для оперативного выявления проблем.

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

Рейтинг: 946

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

## [Почему невозможно установить нормативы обработки проблем в ITSM?](https://cleverics.ru/digital/kb-qa/pochemu-nevozmozhno-ustanovit-normativy-obrabotki-problem-v-itsm/)

Невозможность установить нормативы обработки проблем в ITSM объясняется несколькими факторами. Во-первых, для решения проблемы часто требуется реализация нетипового изменения, срок которого определяется индивидуальным планированием. Во-вторых, у проблемы может существовать несколько вариантов решений, различающихся по надежности, стоимости и срокам реализации, что требует выбора оптимального варианта. В-третьих, время тестирования результативности решения не поддается нормировке, так как зависит от частоты проявления проблемы - если проблема проявляется ежедневно, тестирование можно завершить за 2-3 дня, а если она связана с квартальной отчетностью, придется ждать до следующего квартала (от недели до трех месяцев).

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

Рейтинг: 945

Теги: ITSM, архитектура ИТ, TOGAF и IT4IT, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, общие вопросы менеджмента

## [Каковы основные различия между двумя подходами к управлению релизами?](https://cleverics.ru/digital/kb-qa/kakovy-osnovnye-razlichiya-mezhdu-dvumya-podkhodami-k-upravleniyu-relizami/)

Основные различия между двумя подходами к управлении релизами: первый подход (в подразделении разработки) рассматривает управление релизами как отдельный процесс, который самостоятельно обрабатывает нестандартные изменения, отвечает за авторизацию изменений на CAB'е и имеет дело только с изменениями в приложениях; второй подход (в подразделении эксплуатации) рассматривает управление релизами как часть процесса управления изменениями, который объединяет несколько изменений в релиз, но не отвечает за авторизацию изменений (это делает управление изменениями), и применяется как к приложениям, так и к инфраструктуре. Первый подход соответствует модели BMC SMPM, второй - ITIL и IBM Tivoli Unified Process.

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

Рейтинг: 945

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

## [В чем состоят ключевые аргументы против выделения управления доступностью как отдельного процесса?](https://cleverics.ru/digital/kb-qa/v-chem-sostoyat-klyuchevye-argumenty-protiv-vydeleniya-upravleniya-dostupnostyu-kak-otdelnogo-protse/)

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

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

Рейтинг: 945

Теги: ISO 20000, ITIL, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, управление доступностью, управление изменениями, управление инцидентами, управление мощностями, управление уровнем услуг, SLM

## [Какие алгоритмы агрегирования метрик существуют и как их выбрать?](https://cleverics.ru/digital/kb-qa/kakie-algoritmy-agregirovaniya-metrik-sushchestvuyut-i-kak-ikh-vybrat/)

Существуют различные алгоритмы агрегирования метрик, такие как среднее арифметическое, среднее геометрическое и другие. Выбор метода зависит от специфики бизнес-требований и характера данных. Для большого количества KPI рекомендуется разделять их на группы, рассчитывать интегральные показатели для каждой группы (возможно, разными методами), а затем объединять полученные результаты. Например, при оценке качества 30+ услуг можно выделить группы mission-critical, business-critical и обычные услуги, рассчитав интегральные показатели для каждой группы своими методами, а затем объединить их средним арифметическим или геометрическим (возможно, с разными весами). Аналогично при расчете показателя качества для одной услуги можно разделить KPI на категории (производительность, доступность, поддержка), рассчитать групповые индексы и затем объединить результаты.

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

Рейтинг: 945

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

## [В чём заключается эволюционный подход к внедрению канбана?](https://cleverics.ru/digital/kb-qa/v-chem-zaklyuchaetsya-evolyutsionnyy-podkhod-k-vnedreniyu-kanbana/)

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

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

Рейтинг: 945

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

## [Почему количество обращений зависит от отрасли бизнеса?](https://cleverics.ru/digital/kb-qa/pochemu-kolichestvo-obrashcheniy-zavisit-ot-otrasli-biznesa/)

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

Автор: Анна Васильева

Рейтинг: 945

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

## [Сколько вопросов рекомендуется включать в опрос для оценки удовлетворенности после решения инцидента?](https://cleverics.ru/digital/kb-qa/skolko-voprosov-rekomenduetsya-vklyuchat-v-opros-dlya-otsenki-udovletvorennosti-posle-resheniya-ints/)

Для получения качественных ответов рекомендуется ограничиться 2-3 вопросами. Большое количество вопросов повышает риск отсутствия ответов или получения случайных, невнимательно заполненных ответов, так как пользователи часто не хотят тратить много времени на такие опросы.

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

Рейтинг: 945

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

## [Кто может менять плановый срок устранения инцидента?](https://cleverics.ru/digital/kb-qa/kto-mozhet-menyat-planovyy-srok-ustraneniya-intsidenta/)

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

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

Рейтинг: 945

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