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

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

## [Как различается тип проводимых мероприятий между управлением доступностью и управлением непрерывностью?](https://cleverics.ru/digital/kb-qa/kak-razlichaetsya-tip-provodimykh-meropriyatiy-mezhdu-upravleniem-dostupnostyu-i-upravleniem-neprery/)

Управление доступностью (AVA) в основном использует технические решения для оптимизации работы систем: устранение единой точки отказа, повышение надежности компонентов, автоматизация процессов. Это позволяет повысить общий уровень доступности при разумном уровне затрат и является проактивным подходом. Управление непрерывностью (CONT) делает акцент на организационных мерах, создает избыточность: резервные площадки, подменный фонд оборудования, соглашения с поставщиками на случай ЧС. Это реактивный подход, который направлен на быстрое восстановление работы после серьезных сбоев или катастроф.

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

Рейтинг: 1006

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

## [Какие распространённые ошибки встречаются при внедрении системы управления конфигурациями в компаниях?](https://cleverics.ru/digital/kb-qa/kakie-rasprostranennye-oshibki-vstrechayutsya-pri-vnedrenii-sistemy-upravleniya-konfiguratsiyami-v-k/)

Одной из распространённых ошибок при внедрении системы управления конфигурациями является обращение самой CMDB (Configuration Management Database) в самоцель. Организации часто сосредотачиваются на создании и наполнении базы данных конфигураций, забывая о том, что её основное назначение – поддержка других процессов ИТ-управления. В результате CMS начинает работать как бы сама на себя, без чётко определённых потребителей информации. Такой подход приводит к избыточному сбору данных, которые никем не используются, и к неэффективному использованию ресурсов. Правильная практика предполагает, что построение CMS должно начинаться с определения потребностей бизнес-процессов и конкретных задач, которые эта система должна решать.

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

Рейтинг: 1006

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

## [Как команда может улучшить скорость обработки задач в потоке?](https://cleverics.ru/digital/kb-qa/kak-komanda-mozhet-uluchshit-skorost-obrabotki-zadach-v-potoke/)

Для улучшения скорости обработки задач команда должна сфокусироваться на принципе «заканчивайте начинать, начинайте заканчивать». На ежедневных митингах важно обсуждать, как завершить текущие задачи по плану, а не просто делиться статусами. Необходимо назначить ответственного за координацию (менеджера поставки), который будет отслеживать блокировки, синхронизацию с другими командами и внедрение улучшений процесса. Также важно анализировать потоковые метрики, такие как время выполнения задач и количество незавершённой работы.

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

Рейтинг: 1006

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

## [Как оценить эффективность менеджера при распределении задач внутри команды?](https://cleverics.ru/digital/kb-qa/kak-otsenit-effektivnost-menedzhera-pri-raspredelenii-zadach-vnutri-komandy/)

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

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

Рейтинг: 1006

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

## [Что включает в себя практическое применение сервисной экономики в ИТ и других отраслях?](https://cleverics.ru/digital/kb-qa/chto-vklyuchaet-v-sebya-prakticheskoe-primenenie-servisnoy-ekonomiki-v-it-i-drugikh-otraslyakh/)

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

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

Рейтинг: 1006

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

## [Какие риски возникают при использовании первого способа организации работы линий поддержки?](https://cleverics.ru/digital/kb-qa/kakie-riski-voznikayut-pri-ispolzovanii-pervogo-sposoba-organizatsii-raboty-liniy-podderzhki/)

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

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

Рейтинг: 1006

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

## [Какие риски возникают при отсутствии менеджера процесса управления проблемами?](https://cleverics.ru/digital/kb-qa/kakie-riski-voznikayut-pri-otsutstvii-menedzhera-protsessa-upravleniya-problemami/)

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

Автор: Михаил Тобурдановский

Рейтинг: 1006

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

## [Почему получение точной оценки загруженности сотрудников через учет трудозатрат является недостижимой целью?](https://cleverics.ru/digital/kb-qa/pochemu-poluchenie-tochnoy-otsenki-zagruzhennosti-sotrudnikov-cherez-uchet-trudozatrat-yavlyaetsya-n/)

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

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

Рейтинг: 1006

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

## [В каком процессе ITIL должен обрабатываться запрос на получение информации о текущем статусе инцидента, находящегося в работе?](https://cleverics.ru/digital/kb-qa/v-kakom-protsesse-itil-dolzhen-obrabatyvatsya-zapros-na-poluchenie-informatsii-o-tekushchem-statuse/)

Запрос на получение информации о текущем статусе инцидента должен обрабатываться в процессе Управление инцидентами (Incident Management, INC). Этот процесс несёт ответственность за обеспечение прозрачности работы с инцидентами, включая коммуникацию информации о статусе инцидента. В ITIL Service Operation явно указано, что обеспечение прозрачности является частью задач процесса INC. В примере критических факторов успеха упомянут KPI: «Среднее число звонков на Service Desk и прочих контактов со стороны бизнес-пользователей по поводу уже зарегистрированных инцидентов», что подразумевает необходимость минимизации таких запросов за счёт качественной коммуникации в рамках INC. Хотя процесс Управления запросами на обслуживание (Request Fulfillment Management, RFF) может использоваться как канал передачи информации, основная ответственность за организацию коммуникации и прозрачность лежит на INC, поэтому именно этот процесс должен отрабатывать запросы о статусе инцидента.

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

Рейтинг: 1005

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

## [Какие основные проблемы возникают при управлении микросервисной архитектурой?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-problemy-voznikayut-pri-upravlenii-mikroservisnoy-arkhitekturoy/)

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

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

Рейтинг: 1005

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