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

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

## [Какие критерии обычно используются для оценки работы внутренних поставщиков ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kakie-kriterii-obychno-ispolzuyutsya-dlya-otsenki-raboty-vnutrennikh-postavshchikov-it-uslug/)

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

Автор: Денис Денисов

Рейтинг: 940

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

## [Как определить подходящий уровень детализации в конфигурационной модели ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kak-opredelit-podkhodyashchiy-uroven-detalizatsii-v-konfiguratsionnoy-modeli-it-uslug/)

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

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

Рейтинг: 940

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

## [Какие ограничения следует ввести на использование статуса 'Ожидание'?](https://cleverics.ru/digital/kb-qa/kakie-ogranicheniya-sleduet-vvesti-na-ispolzovanie-statusa-ozhidanie/)

Рекомендуется ввести следующие ограничения на использование статуса 'Ожидание': ограничить круг лиц, имеющих право перевода задач в этот статус (только руководители, только при наличии подтверждения от клиента/коллег); установить максимальный допустимый срок пребывания задачи в статусе (например, не более 3 рабочих дней без повторного согласования); требовать обязательного указания конкретной даты или условия выхода из статуса; разрешить использование статуса только после попытки решения задачи без ожидания (фиксация предпринятых действий); ввести автоматическое возвращение задачи в активный статус после истечения максимального срока ожидания с уведомлением ответственного. Такие ограничения предотвращают злоупотребление статусом и сохраняют его полезную функцию для объективных задержек.

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

Рейтинг: 940

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

## [Чем отличается согласованный 'внеплановый' простой от реального аварийного простоя?](https://cleverics.ru/digital/kb-qa/chem-otlichaetsya-soglasovannyy-vneplanovyy-prostoy-ot-realnogo-avariynogo-prostoya/)

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

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

Рейтинг: 940

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

## [Как соотносится среднее время решения проблем с установкой целевого значения для предложенной метрики?](https://cleverics.ru/digital/kb-qa/kak-sootnositsya-srednee-vremya-resheniya-problem-s-ustanovkoy-tselevogo-znacheniya-dlya-predlozhenn/)

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

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

Рейтинг: 940

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

## [Почему задачи по рефакторингу должны появляться в беклоге?](https://cleverics.ru/digital/kb-qa/pochemu-zadachi-po-refaktoringu-dolzhny-poyavlyatsya-v-bekloge/)

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

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

Рейтинг: 939

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

## [Почему предложенное решение считается оптимальным для текущих условий работы службы поддержки?](https://cleverics.ru/digital/kb-qa/pochemu-predlozhennoe-reshenie-schitaetsya-optimalnym-dlya-tekushchikh-usloviy-raboty-sluzhby-podder/)

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

Автор: Михаил Тобурдановский

Рейтинг: 939

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

## [Из каких видов деятельности состоит процесс управления знаниями в компании?](https://cleverics.ru/digital/kb-qa/iz-kakikh-vidov-deyatelnosti-sostoit-protsess-upravleniya-znaniyami-v-kompanii/)

Процесс состоит из трёх основных видов деятельности: создание статей для наполнения Базы знаний; проверка статей на актуальность, применимость и корректность; публикация и архивация статей (ввод и вывод из эксплуатации). Дополнительно существует механизм регулярного пересмотра статей по истечении срока жизни (TTL) и триггеры создания новых статей при определённых событиях.

Автор: Денис Денисов

Рейтинг: 939

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

## [Как влияние результатов аллокации может изменить поведение сотрудников и менеджеров?](https://cleverics.ru/digital/kb-qa/kak-vliyanie-rezultatov-allokatsii-mozhet-izmenit-povedenie-sotrudnikov-i-menedzherov/)

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

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

Рейтинг: 939

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

## [Как Service Owner взаимодействует с бизнесом в контексте SLA и OLA?](https://cleverics.ru/digital/kb-qa/kak-service-owner-vzaimodeystvuet-s-biznesom-v-kontekste-sla-i-ola/)

Service Owner активно участвует в обсуждении и разработке SLA (уровней сервиса) и OLA (внутренних уровней сервиса), выступая от имени бизнеса при переговорах. Он обеспечивает, что SLA корректно отражают бизнес-требования и ожидания, а OLA поддерживают достижение внешних SLA. При этом Service Owner контролирует выполнение SLA и OLA и выступает в роли посредника при возникновении расхождений между ожиданиями и реальным уровнем сервиса.

Автор: Константин Нарыжный

Рейтинг: 939

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