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

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

## [Как группа 'б' влияет на значение метрики продуктивности](https://cleverics.ru/digital/kb-qa/kak-gruppa-b-vliyaet-na-znachenie-metriki-produktivnosti/)

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

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

Рейтинг: 883

Теги: измерение и оценка ИТ, метрики, KPI, отчётность, дашборды

## [Почему некоторые ИТ-организации выделяют обработку сервисных запросов и управление инцидентами в отдельные процессы?](https://cleverics.ru/digital/kb-qa/pochemu-nekotorye-it-organizatsii-vydelyayut-obrabotku-servisnykh-zaprosov-i-upravlenie-intsidentami/)

Основные причины выделения в отдельные процессы включают соответствие ITIL v3, конкурентные преимущества вендоров ITSM-продуктов (которые "меряются" количеством процессов) и особенности программных продуктов, где сервисные запросы и инциденты представлены как разные объекты со значительно отличающимися возможностями по обработке. Многие ITSM-продукты реализуют строгое разделение, что стимулирует организации следовать этой практике. Дополнительным фактором является стремление к более точной специализации процессов и потенциальная возможность оптимизации обработки разных типов обращений.

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

Рейтинг: 883

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

## [Какие рекомендации можно дать тем, кто сталкивается с терминологическими трудностями при изучении ITIL?](https://cleverics.ru/digital/kb-qa/kakie-rekomendatsii-mozhno-dat-tem-kto-stalkivaetsya-s-terminologicheskimi-trudnostyami-pri-izucheni/)

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

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

Рейтинг: 883

Теги: ITIL

## [Как интегрировать статус 'Ожидание' в систему мотивации сотрудников?](https://cleverics.ru/digital/kb-qa/kak-integrirovat-status-ozhidanie-v-sistemu-motivatsii-sotrudnikov/)

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

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

Рейтинг: 883

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

## [Как можно использовать метрики для оценки вклада руководителей подразделений в работу процессов управления услугами?](https://cleverics.ru/digital/kb-qa/kak-mozhno-ispolzovat-metriki-dlya-otsenki-vklada-rukovoditeley-podrazdeleniy-v-rabotu-protsessov-up/)

Метрики могут быть использованы для оценки руководителей подразделений через систему взаимосвязанных показателей, отражающих их вклад в процессы. Решение заключается в построении матрицы, где по вертикали расположены функции (отделы, группы), а по горизонтали — процессы. Пересечение функции и процесса означает участие данной функции в реализации процесса, соответственно функциональный руководитель отвечает за предоставление необходимых ресурсов. Процессные метрики сотрудников подразделения связываются с руководителем, назначаются целевые значения, и контролируется их соблюдение. Даже если руководитель формально не несет функциональных обязанностей в процессах (например, не является ответственным в матрице RACI), такой подход стимулирует его к взаимодействию с процессным управлением. На разных уровнях иерархии метрики могут агрегироваться: например, региональные руководители оцениваются по своим метрикам, а руководитель в HQ — по агрегированным метрикам региональных руководителей. Важно, чтобы все используемые KPI были сопоставимы между собой (единая шкала от 0 до 1, одинаковое направление оценки).

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

Рейтинг: 882

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

## [Как связана структура OLA и SLA в ИТ-управлении?](https://cleverics.ru/digital/kb-qa/kak-svyazana-struktura-ola-i-sla-v-it-upravlenii/)

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

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

Рейтинг: 882

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

## [Как минимизировать влияние человеческого фактора на данные в системах автоматизации?](https://cleverics.ru/digital/kb-qa/kak-minimizirovat-vliyanie-chelovecheskogo-faktora-na-dannye-v-sistemakh-avtomatizatsii/)

Влияние человеческого фактора снижается через: 1) обучение сотрудников стандартам оформления данных, 2) внедрение валидации полей на этапе ввода, 3) регулярный аудит случайных записей с обратной связью, 4) разделение ролей (например, один сотрудник вносит данные, другой проверяет). Для критически важных метрик можно использовать двухэтапное согласование. В случае классификации инцидентов проверка может выполняться ответственным менеджером перед закрытием обращения.

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

Рейтинг: 882

Теги: ISO 20000, автоматизация ИТ-процессов, ПО для ITSM и ESM, аудит, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, обучение сотрудников, учебные курсы, тренинги, общие вопросы менеджмента, управление запросами на обслуживание, управление инцидентами, управление продуктами, продуктовый подход, управление процессами, ИТ-процессы, управление релизами

## [Почему не всегда достаточно, чтобы ИТ-подразделение умело качественно отрабатывать ТЗ?](https://cleverics.ru/digital/kb-qa/pochemu-ne-vsegda-dostatochno-chtoby-it-podrazdelenie-umelo-kachestvenno-otrabatyvat-tz/)

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

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

Рейтинг: 882

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

## [Какие методы используются для анализа причин проблем в DevOps?](https://cleverics.ru/digital/kb-qa/kakie-metody-ispolzuyutsya-dlya-analiza-prichin-problem-v-devops/)

Для анализа причин проблем в DevOps применяются методы, такие как постмортем-встречи и ретроспективы. В таких мероприятиях участники команды совместно обсуждают причины возникновения ошибок, выявляют системные проблемы и определяют пути их решения. Может использоваться методика «Пять Почему» для поиска корневых причин и подход 8D из бережливого производства, в рамках которой отдельная команда, собранная лидером, анализирует конкретную проблему. Эти методы помогают не только исправить текущие ошибки, но и улучшить процессы в долгосрочной перспективе.

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

Рейтинг: 882

Теги: DevOps, CI/CD, Lean, бережливое производство, командная работа, лидерство

## [Как поставщик услуг может перейти на следующий уровень в предоставлении услуг?](https://cleverics.ru/digital/kb-qa/kak-postavshchik-uslug-mozhet-pereyti-na-sleduyushchiy-uroven-v-predostavlenii-uslug/)

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

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

Рейтинг: 882

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