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

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

## [В чем разница между назначением и целями процесса в ITIL?](https://cleverics.ru/digital/kb-qa/v-chem-raznitsa-mezhdu-naznacheniem-i-tselyami-protsessa-v-itil/)

Назначение процесса определяет его базовую функцию и место в общей процессной модели без привязки ко времени, тогда как цели процесса – это конкретные измеримые результаты, которых нужно достичь в определённый период. Ключевые отличия: - Назначение формулируется как описание общей задачи (например, "обеспечение качества услуг через устранение инцидентов"). - Цели формулируются в формате SMART: с глаголами совершенного вида ("увеличить долю решённых инцидентов до 95%"), измеримы и привязаны к срокам (квартал, год). Цели регулярно пересматриваются, в отличие от назначения, которое стабильно. Ответственность за назначение несёт дизайнер процессов, за цели – владелец процесса.

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

Рейтинг: 1222

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

## [Какой подход рекомендуется при работе с уровнями зрелости процессов в COBIT?](https://cleverics.ru/digital/kb-qa/kakoy-podkhod-rekomenduetsya-pri-rabote-s-urovnyami-zrelosti-protsessov-v-cobit/)

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

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

Рейтинг: 1222

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

## [Какова основная разница между обработкой сервисных запросов и управлением инцидентами в ITIL?](https://cleverics.ru/digital/kb-qa/kakova-osnovnaya-raznitsa-mezhdu-obrabotkoy-servisnykh-zaprosov-i-upravleniem-intsidentami-v-itil/)

Основная разница заключается в классификации обращений. Инциденты - это нарушения нормального функционирования ИТ-услуг, требующие восстановления работоспособности. Сервисные запросы представляют собой запросы новых или дополнительных услуг (например, запрос на новое программное обеспечение или оборудование). В ITIL v2 указывается, что на практике обработка сбоев инфраструктуры и сервисных запросов часто схожа, поэтому оба типа включались в процесс управления инцидентами. Однако в ITIL v3 появились отдельные процессы, хотя само понятие "процесс" в нем используется неоднозначно. Согласно ITIL v2, запрос на новую или дополнительную услугу часто рассматривается не как инцидент, а как запрос на изменение (RFC), но практика показывает схожесть в обработке как сбоев, так и сервисных запросов.

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

Рейтинг: 1222

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

## [В каких случаях SLA между ИТ-подразделением и бизнес-подразделениями действительно необходимы?](https://cleverics.ru/digital/kb-qa/v-kakikh-sluchayakh-sla-mezhdu-it-podrazdeleniem-i-biznes-podrazdeleniyami-deystvitelno-neobkhodimy/)

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

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

Рейтинг: 1220

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

## [Чем отличается поток создания ценности от бизнес-процесса?](https://cleverics.ru/digital/kb-qa/chem-otlichaetsya-potok-sozdaniya-tsennosti-ot-biznes-protsessa/)

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

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

Рейтинг: 1220

Теги: бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, командная работа, поток создания ценности (Value Stream)

## [Как интерпретировать значение метрики KPI группы поддержки в диапазоне от 0 до 1?](https://cleverics.ru/digital/kb-qa/kak-interpretirovat-znachenie-metriki-kpi-gruppy-podderzhki-v-diapazone-ot-0-do-1/)

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

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

Рейтинг: 1220

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

## [Что такое co-creation в контексте разработки продукта и почему это важно?](https://cleverics.ru/digital/kb-qa/chto-takoe-co-creation-v-kontekste-razrabotki-produkta-i-pochemu-eto-vazhno/)

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

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

Рейтинг: 1219

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

## [Какие стратегии реагирования на риски упоминаются в Risk Scenarios Using COBIT 5 for Risk?](https://cleverics.ru/digital/kb-qa/kakie-strategii-reagirovaniya-na-riski-upominayutsya-v-risk-scenarios-using-cobit-5-for-risk/)

В документе Risk Scenarios Using COBIT 5 for Risk упоминаются четыре основные стратегии реагирования на риски: уклонение, принятие, передача и снижение. Для каждого сценария риска в документе указывается, какие из этих стратегий применимы. Кроме того, предлагается использование семи факторов влияния для реализации мер по снижению рисков, при этом для каждой меры приводится оценка её эффективности воздействия как на вероятность возникновения риска, так и на потенциальный ущерб в случае реализации риска.

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

Рейтинг: 1219

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

## [В чем заключается основная ответственность владельца процесса управления уровнем услуг?](https://cleverics.ru/digital/kb-qa/v-chem-zaklyuchaetsya-osnovnaya-otvetstvennost-vladeltsa-protsessa-upravleniya-urovnem-uslug/)

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

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

Рейтинг: 1218

Теги: ISO 20000, SLA, аудит, бизнес, ценность, бизнес-заказчик, общие вопросы менеджмента, постоянное улучшение, совершенствование, CSI, PDCA, стратегия, управление отношениями, взаимодействие, BRM, управление уровнем услуг, SLM, эффективность, оптимизация

## [Как выбрать наиболее подходящий набор показателей доступности для конкретной ИТ-услуги?](https://cleverics.ru/digital/kb-qa/kak-vybrat-naibolee-podkhodyashchiy-nabor-pokazateley-dostupnosti-dlya-konkretnoy-it-uslugi/)

Выбор показателей доступности зависит от особенностей бизнес-процессов, которые поддерживаются данной ИТ-услугой. Необходимо проанализировать: 1) Как реагирует бизнес на простой - критичны ли для него кратковременные частые нарушения или только длительные простоя; 2) Насколько чувствительны бизнес-процессы к частоте прерываний (например, для вычислительных процессов каждое прерывание требует перезапуска); 3) Каковы финансовые и репутационные последствия простоев разной длительности. На основании этого формируется набор показателей: если бизнес чувствителен к частым простоям, включается показатель «количество нарушений»; если критичны длительные простои - показатель «максимального разового простоя» и так далее. Возможно, некоторые показатели будут иметь больший вес в агрегированной метрике.

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

Рейтинг: 1218

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