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

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

## [В чем заключается проблема наличия нескольких заказчиков у одной ИТ-услуги?](https://cleverics.ru/digital/kb-qa/v-chem-zaklyuchaetsya-problema-nalichiya-neskolkikh-zakazchikov-u-odnoy-it-uslugi/)

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

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

Рейтинг: 1061

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

## [Какие примеры emergency-изменений приводятся в ITIL?](https://cleverics.ru/digital/kb-qa/kakie-primery-emergency-izmeneniy-privodyatsya-v-itil/)

В ITIL указано два конкретных примера emergency-изменений: первое — изменение, необходимое для устранения массового инцидента, когда, например, сервис перестал обслуживать большое количество пользователей; второе — установка патча для закрытия критических уязвимостей в системе безопасности. Эти случаи требуют немедленного реагирования, так как их игнорирование приведёт к значительному ущербу для бизнеса, включая финансовые потери или репутационный риск.

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

Рейтинг: 1060

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

## [Почему результаты (Outcome) сложнее измерять, чем выходы (Output)?](https://cleverics.ru/digital/kb-qa/pochemu-rezultaty-outcome-slozhnee-izmeryat-chem-vykhody-output/)

Outcome зависит от субъективного восприятия потребителя и часто выражается в нематериальных или долгосрочных эффектах, которые сложно зафиксировать количественно. В то время как Output обычно имеет чёткие количественные параметры (например, сроки доставки, объём функционала), что позволяет легко его измерять и отчитываться о нём. Для оценки Outcome необходимо собирать обратную связь, проводить опросы удовлетворённости или анализировать поведение клиентов.

Автор: Александр Движков

Рейтинг: 1060

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

## [Как организовать развитие взаимосвязанных процессов ИТ-управления для максимальной эффективности?](https://cleverics.ru/digital/kb-qa/kak-organizovat-razvitie-vzaimosvyazannykh-protsessov-it-upravleniya-dlya-maksimalnoy-effektivnosti/)

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

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

Рейтинг: 1060

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

## [Каким образом в разных ИТ-моделях объединяются процессы управления доступностью и непрерывностью?](https://cleverics.ru/digital/kb-qa/kakim-obrazom-v-raznykh-it-modelyakh-obedinyayutsya-protsessy-upravleniya-dostupnostyu-i-nepreryvnos/)

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

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

Рейтинг: 1060

Теги: ITIL, управление доступностью, управление инцидентами

## [Как часто должны проводиться актуализации планов непрерывности ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kak-chasto-dolzhny-provoditsya-aktualizatsii-planov-nepreryvnosti-it-uslug/)

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

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

Рейтинг: 1060

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

## [Какие характеристики крупных организаций усложняют внедрение изменений?](https://cleverics.ru/digital/kb-qa/kakie-kharakteristiki-krupnykh-organizatsiy-uslozhnyayut-vnedrenie-izmeneniy/)

Крупные организации имеют ряд характеристик, усложняющих внедрение изменений: 1) Инерция, поддерживающая текущий порядок и снижающая ощущение срочности перемен. 2) Сложные коммуникации в подразделениях, где работает более 100-200 человек, что мешает быстрому распространению информации об изменениях. 3) Среда, не поощряющая риски, особенно в компаниях, прошедших стадию стартапа, так как существует страх, что изменения могут привести к ухудшению ситуации. 4) Хроническая нехватка различных ресурсов - трудовых, финансовых, временных и волевых, что ограничивает возможности для экспериментов и корректировок. 5) Сопротивление как система, проявляющееся не через отдельных людей, а через саму структуру и культуру организации, что делает его менее очевидным и более сложным для преодоления, чем индивидуальное сопротивление сотрудников.

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

Рейтинг: 1060

Теги: управление релизами, управление рисками

## [Какие преимущества дает применение картирования потока создания ценности в ИТ-разработке?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-daet-primenenie-kartirovaniya-potoka-sozdaniya-tsennosti-v-it-razrabotke/)

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

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

Рейтинг: 1059

Теги: DevOps, CI/CD, бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, командная работа, общие вопросы менеджмента, постоянное улучшение, совершенствование, CSI, PDCA, поток создания ценности (Value Stream), эффективность, оптимизация

## [Почему важно разделять понятия запроса на обслуживание и изменения в ИТ-управлении?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-razdelyat-ponyatiya-zaprosa-na-obsluzhivanie-i-izmeneniya-v-it-upravlenii/)

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

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

Рейтинг: 1058

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

## [Какие документы необходимы для успешной работы технического эксперта в проекте?](https://cleverics.ru/digital/kb-qa/kakie-dokumenty-neobkhodimy-dlya-uspeshnoy-raboty-tekhnicheskogo-eksperta-v-proekte/)

Для эффективной деятельности технического эксперта и разработчика требуются: актуальный проектный план, список текущих задач, список открытых вопросов, контактные лица, процессное описание решения, технические требования, информация об источниках данных и их владельцах, шаблоны документов, стандарты разработки, вендорская документация, информация об ошибках и накопленный know-how. Эти материалы необходимы для корректного технического проектирования, разработки, настройки платформы и организации интеграций.

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

Рейтинг: 1058

Теги: ISO 20000, управление проектами, PRINCE2