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

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

## [Как руководящие принципы ITIL Practitioner связаны с другими методологиями, такими как Agile, DevOps и Lean?](https://cleverics.ru/digital/kb-qa/kak-rukovodyashchie-printsipy-itil-practitioner-svyazany-s-drugimi-metodologiyami-takimi-kak-agile-d/)

Руководящие принципы ITIL Practitioner являются логичным продолжением вектора AXELOS на 'выравнивание' и совместное использование ITIL с другими сводами знаний, методологиями и подходами. Многие принципы ITIL Practitioner пересекаются с идеями Agile (действия небольшими шагами), DevOps (культура совместной работы и открытости) и Lean (минимизация потерь и оптимизация потока ценности). Это свидетельствует о том, что принципы ITIL не противоречат, а дополняют другие современные методологии управления.

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

Рейтинг: 1203

Теги: Agile и гибкие методы разработки ПО, DevOps, CI/CD, ITIL, бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, обучение сотрудников, учебные курсы, тренинги, управление знаниями, эффективность, оптимизация

## [Почему стандартное понимание SLM как процесса создания двух каталогов услуг, SLA и OLA является ограниченным?](https://cleverics.ru/digital/kb-qa/pochemu-standartnoe-ponimanie-slm-kak-protsessa-sozdaniya-dvukh-katalogov-uslug-sla-i-ola-yavlyaetsy/)

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

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

Рейтинг: 1203

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

## [Как связаны между собой процедура приема заявки в работу и механизм автоматической эскалации?](https://cleverics.ru/digital/kb-qa/kak-svyazany-mezhdu-soboy-protsedura-priema-zayavki-v-rabotu-i-mekhanizm-avtomaticheskoy-eskalatsii/)

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

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

Рейтинг: 1202

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

## [Почему важно разделять Output и Outcome в управлении услугами?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-razdelyat-output-i-outcome-v-upravlenii-uslugami/)

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

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

Рейтинг: 1201

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

## [Что такое major-инцидент и почему он требует специального подхода в управлении?](https://cleverics.ru/digital/kb-qa/chto-takoe-major-intsident-i-pochemu-on-trebuet-spetsialnogo-podkhoda-v-upravlenii/)

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

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

Рейтинг: 1201

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

## [Как соотносятся практики управления изменениями и управления запросами на обслуживание?](https://cleverics.ru/digital/kb-qa/kak-sootnosyatsya-praktiki-upravleniya-izmeneniyami-i-upravleniya-zaprosami-na-obsluzhivanie/)

Практика управления изменениями и практика управления запросами на обслуживание взаимодействуют, но не заменяют друг друга. Управление изменениями отвечает за оценку рисков, авторизацию и мониторинг всех изменений, включая те, что реализуются через запросы на обслуживание. Управление запросами выполняет стандартные операции, такие как установка ПО или изменение прав доступа. Ключевое отличие: запросы на обслуживание — это средства выполнения определенного типа работ, а изменения как таковые требуют оценки и контроля по специальной процедуре. Стандартные изменения могут инициироваться как запросы на обслуживание, но сами по себе запросы не равны изменениям. Важно, чтобы все изменения (даже выполняемые через запросы) попадали в общую систему контроля, что обеспечивается разработкой предопределенных моделей стандартных изменений.

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

Рейтинг: 1200

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

## [Почему первая линия поддержки считается ключевой для качества ИТ-услуг?](https://cleverics.ru/digital/kb-qa/pochemu-pervaya-liniya-podderzhki-schitaetsya-klyuchevoy-dlya-kachestva-it-uslug/)

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

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

Рейтинг: 1200

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

## [Что такое иерархическое управление и в чем его особенности?](https://cleverics.ru/digital/kb-qa/chto-takoe-ierarkhicheskoe-upravlenie-i-v-chem-ego-osobennosti/)

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

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

Рейтинг: 1199

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

## [Что представляет собой расширенный жизненный цикл инцидента (the Expanded Incident Lifecycle)?](https://cleverics.ru/digital/kb-qa/chto-predstavlyaet-soboy-rasshirennyy-zhiznennyy-tsikl-intsidenta-the-expanded-incident-lifecycle/)

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

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

Рейтинг: 1198

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

## [Какие преимущества имеет организация поддержки без единой точки контакта (Service Desk)?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-imeet-organizatsiya-podderzhki-bez-edinoy-tochki-kontakta-service-desk/)

Организация поддержки без единой точки контакта (Service Desk) позволяет снизить нагрузку на центральную службу, так как большая часть обращений напрямую попадает к профильным группам. Например, по данным описанных кейсов, около 81% обращений через электронные каналы взаимодействия, таких как электронная почта и веб-интерфейс, сразу направляются в соответствующие технические группы, а телефонные обращения, проходящие через первую линию, составляют лишь 19% всех обращений. Это обеспечивает более быстрое решение задач и оптимизацию процессов за счет специализации каждой группы.

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

Рейтинг: 1197

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