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

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

## [Как определяется потребитель ИТ-услуг в SLA?](https://cleverics.ru/digital/kb-qa/kak-opredelyaetsya-potrebitel-it-uslug-v-sla/)

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

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

Рейтинг: 734

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

## [Почему в управлении уровнями обслуживания важно учитывать как полезность, так и гарантию?](https://cleverics.ru/digital/kb-qa/pochemu-v-upravlenii-urovnyami-obsluzhivaniya-vazhno-uchityvat-kak-poleznost-tak-i-garantiyu/)

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

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

Рейтинг: 734

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

## [Какие организационные изменения необходимы для улучшения управления доступом?](https://cleverics.ru/digital/kb-qa/kakie-organizatsionnye-izmeneniya-neobkhodimy-dlya-uluchsheniya-upravleniya-dostupom/)

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

Автор: Денис Денисов

Рейтинг: 734

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

## [Почему не рекомендуется переносить все данные из внешних источников в CMDB?](https://cleverics.ru/digital/kb-qa/pochemu-ne-rekomenduetsya-perenosit-vse-dannye-iz-vneshnikh-istochnikov-v-cmdb/)

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

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

Рейтинг: 734

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

## [Почему учет времени в конце дня по памяти считается менее эффективным?](https://cleverics.ru/digital/kb-qa/pochemu-uchet-vremeni-v-kontse-dnya-po-pamyati-schitaetsya-menee-effektivnym/)

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

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

Рейтинг: 734

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

## [Какие роли задействованы в управлении проблемами?](https://cleverics.ru/digital/kb-qa/kakie-roli-zadeystvovany-v-upravlenii-problemami/)

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

Автор: Игорь Фадеев

Рейтинг: 734

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

## [Какие решения по уменьшению технического долга являются наиболее эффективными?](https://cleverics.ru/digital/kb-qa/kakie-resheniya-po-umensheniyu-tekhnicheskogo-dolga-yavlyayutsya-naibolee-effektivnymi/)

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

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

Рейтинг: 734

Теги: ISO 20000, архитектура ИТ, TOGAF и IT4IT, постоянное улучшение, совершенствование, CSI, PDCA, управление релизами, управление рисками, эффективность, оптимизация

## [Какое влияние оказывает организация процесса управления уровнем ИТ-услуг на управление проблемами?](https://cleverics.ru/digital/kb-qa/kakoe-vliyanie-okazyvaet-organizatsiya-protsessa-upravleniya-urovnem-it-uslug-na-upravlenie-problema/)

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

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

Рейтинг: 734

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

## [Какие задачи решает ретроспектива в процессе DevOps?](https://cleverics.ru/digital/kb-qa/kakie-zadachi-reshaet-retrospektiva-v-protsesse-devops/)

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

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

Рейтинг: 734

Теги: DevOps, CI/CD, командная работа, эффективность, оптимизация

## [Какие риски могут возникнуть при неполном соблюдении лицензионных соглашений?](https://cleverics.ru/digital/kb-qa/kakie-riski-mogut-vozniknut-pri-nepolnom-soblyudenii-litsenzionnykh-soglasheniy/)

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

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

Рейтинг: 734

Теги: управление ИТ-активами, ITAM, SAM, управление рисками