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

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

## [Какие методологии предусматривают работу со сопряженными метриками?](https://cleverics.ru/digital/kb-qa/kakie-metodologii-predusmatrivayut-rabotu-so-sopryazhennymi-metrikami/)

Методология ITIL V3 прямо рассматривает понятие Tension Metrics (Сопряженные метрики) в контексте управления ИТ-услугами. Также подобные концепции присутствуют в системном подходе, теории ограничений (TOC), Lean-менеджменте и шести сигмах, где анализируются взаимосвязи между показателями и ищутся оптимальные точки баланса между конкурирующими требованиями.

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

Рейтинг: 810

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

## [Какие типовые требования предъявляются к обработке ИТ-заявок в организациях?](https://cleverics.ru/digital/kb-qa/kakie-tipovye-trebovaniya-predyavlyayutsya-k-obrabotke-it-zayavok-v-organizatsiyakh/)

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

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

Рейтинг: 809

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

## [Почему в традиционной иерархической структуре ИТ-департамента возникают межгрупповые конфликты?](https://cleverics.ru/digital/kb-qa/pochemu-v-traditsionnoy-ierarkhicheskoy-strukture-it-departamenta-voznikayut-mezhgruppovye-konflikty/)

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

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

Рейтинг: 809

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

## [Почему безопасность и поддержка в команде не могут быть абсолютными?](https://cleverics.ru/digital/kb-qa/pochemu-bezopasnost-i-podderzhka-v-komande-ne-mogut-byt-absolyutnymi/)

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

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

Рейтинг: 809

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

## [Какова структура жизненного цикла системы управления непрерывностью бизнеса по Good Practice Guidelines 2010?](https://cleverics.ru/digital/kb-qa/kakova-struktura-zhiznennogo-tsikla-sistemy-upravleniya-nepreryvnostyu-biznesa-po-good-practice-guid/)

Согласно Business Continuity Institute Good Practice Guidelines 2010 (GPG), жизненный цикл системы управления непрерывностью бизнеса состоит из шести этапов: анализ организации, определение стратегии обеспечения непрерывности, разработка и внедрение планов обеспечения непрерывности, испытание и оценка планов, менеджмент программы управления непрерывностью бизнеса, внедрение управления непрерывностью бизнеса в организационную структуру. Каждый этап подробно описан в документе.

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

Рейтинг: 809

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

## [Почему важно, чтобы все изменения были включены в охват практики управления изменениями?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-chtoby-vse-izmeneniya-byli-vklyucheny-v-okhvat-praktiki-upravleniya-izmeneniyami/)

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

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

Рейтинг: 809

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

## [Какие технические роли выделены в процессе управления релизами ITIL V3 и чем они занимаются?](https://cleverics.ru/digital/kb-qa/kakie-tekhnicheskie-roli-vydeleny-v-protsesse-upravleniya-relizami-itil-v3-i-chem-oni-zanimayutsya/)

В процессе управления релизами ITIL V3 выделены следующие технические роли: Практик пакетирования и построения релизов, занимающийся сборкой и подготовкой компонентов релиза; Практик развёртывания релизов, отвечающий за внедрение релиза в производственную среду и подготовку документации; Практик первичной (early life) поддержки, обеспечивающий поддержку системы в начальный период эксплуатации после релиза. Эти роли сосредоточены на выполнении конкретных работ, а не на координации процесса в целом. Все они работают под управлением менеджера процесса и обеспечивают техническую реализацию отдельных этапов жизненного цикла релиза.

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

Рейтинг: 809

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

## [Как можно организовать поддержку пользователей без централизованного Service Desk?](https://cleverics.ru/digital/kb-qa/kak-mozhno-organizovat-podderzhku-polzovateley-bez-tsentralizovannogo-service-desk/)

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

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

Рейтинг: 809

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

## [Какие принципы вытягивающей системы (Pull System) демонстрирует описанная визуализация?](https://cleverics.ru/digital/kb-qa/kakie-printsipy-vytyagivayushchey-sistemy-pull-system-demonstriruet-opisannaya-vizualizatsiya/)

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

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

Рейтинг: 809

Теги: Канбан, WIP-лимиты, командная работа

## [Чем ценность замены отличается от бизнес-ценности?](https://cleverics.ru/digital/kb-qa/chem-tsennost-zameny-otlichaetsya-ot-biznes-tsennosti/)

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

Автор: Роман Журавлёв

Рейтинг: 809

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