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

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

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

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

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

Рейтинг: 1134

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

## [Как следует принимать решение о приоритизации задач по рефакторингу перед бизнес-задачами?](https://cleverics.ru/digital/kb-qa/kak-sleduet-prinimat-reshenie-o-prioritizatsii-zadach-po-refaktoringu-pered-biznes-zadachami/)

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

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

Рейтинг: 1133

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

## [Как определить источники проблем с соблюдением сроков обработки запросов?](https://cleverics.ru/digital/kb-qa/kak-opredelit-istochniki-problem-s-soblyudeniem-srokov-obrabotki-zaprosov/)

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

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

Рейтинг: 1133

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

## [Чем методология ITIL 4 отличается от подходов ITIL v3 в оценке характеристик услуг?](https://cleverics.ru/digital/kb-qa/chem-metodologiya-itil-4-otlichaetsya-ot-podkhodov-itil-v3-v-otsenke-kharakteristik-uslug/)

ITIL 4 расширяет подходы ITIL v3, добавляя фокус на управление опытом (experience) помимо полезности и гарантии. Если в ITIL v3 акцент делался на разделении функциональных и нефункциональных характеристик услуг, то в ITIL 4 основное внимание уделяется совместному созданию ценности для заинтересованных сторон, что включает анализ эмоционального и функционального взаимодействия с услугой. Это отражено в практике Drive stakeholder value (DSV), которая уделяет особое внимание CX и UX.

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

Рейтинг: 1133

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

## [Что такое CAAS в контексте ITIL и как это связано с продажей услуг?](https://cleverics.ru/digital/kb-qa/chto-takoe-caas-v-kontekste-itil-i-kak-eto-svyazano-s-prodazhey-uslug/)

CAAS - это условная аббревиатура (Choco-as-a-Service), используемая для объяснения концепции сервиса в ITIL. Она демонстрирует, что при продаже услуги клиенту предоставляется не просто товар, а комплексное решение, включающее сам товар, ресурс и сервисные операции. 'C' в CAAS означает 'chocolate', а 'aaS' (as-a-Service) указывает на то, что клиент получает не просто физический продукт (шоколадку), а доступ к услуге, которая включает в себя доставку, обеспечение регулярности поставок, решение проблем с доступностью и т.д. Это помогает понять, что в случае с услугой клиент перекладывает на поставщика определенные риски и затраты, что не происходит при простой покупке товара.

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

Рейтинг: 1132

Теги: DevOps, CI/CD, ITIL, аллокация затрат, расчёт себестоимости услуг, аутсорсинг, интеграция услуг, бизнес, ценность, бизнес-заказчик, управление доступностью, управление доступом, IDM, ролевые модели, RBAC, ABAC, управление продуктами, продуктовый подход, управление рисками, экономика и финансы

## [Какие компоненты ИТ-услуг учитываются при определении влияния изменения инфраструктуры?](https://cleverics.ru/digital/kb-qa/kakie-komponenty-it-uslug-uchityvayutsya-pri-opredelenii-vliyaniya-izmeneniya-infrastruktury/)

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

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

Рейтинг: 1132

Теги: управление конфигурациями, CMDB

## [В чем отличие подхода к измерению эффективности в ITIL v3 и IT4IT?](https://cleverics.ru/digital/kb-qa/v-chem-otlichie-podkhoda-k-izmereniyu-effektivnosti-v-itil-v3-i-it4it/)

Главное отличие в подходе к измерению эффективности между ITIL v3 и IT4IT заключается в объектах измерения. В ITIL v3 критические факторы успеха (CSF) и ключевые показатели эффективности (KPI) определены для каждого из 26 процессов, что делает акцент на измерении отдельных процессов. В IT4IT же CSF и KPI относятся к целым Value Stream'ам (потокам создания ценности), а не к отдельным функциональным компонентам внутри этих потоков. Это означает, что IT4IT имеет более целостный взгляд на измерение эффективности, фокусируясь на том, как весь поток создает ценность для бизнеса, тогда как ITIL v3 предоставляет более детализированные измерения по отдельным процессам. Хотя и в ITIL v3 есть упоминания о ключевых факторах успеха для фаз жизненного цикла, в IT4IT этот аспект проработан более системно и детально для каждого Value Stream.

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

Рейтинг: 1131

Теги: ITIL, архитектура ИТ, TOGAF и IT4IT, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, Канбан, WIP-лимиты, поток создания ценности (Value Stream), эффективность, оптимизация

## [Какие преимущества дает эффективное управление проблемами в ИТ-инфраструктуре?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-daet-effektivnoe-upravlenie-problemami-v-it-infrastrukture/)

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

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

Рейтинг: 1131

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

## [Можно ли внедрить стандарты управления ИТ 'как есть', без каких-либо изменений?](https://cleverics.ru/digital/kb-qa/mozhno-li-vnedrit-standarty-upravleniya-it-kak-est-bez-kakikh-libo-izmeneniy/)

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

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

Рейтинг: 1131

Теги: ISO 20000, бизнес, ценность, бизнес-заказчик

## [Какие факторы влияют на формирование технического долга в процессе разработки?](https://cleverics.ru/digital/kb-qa/kakie-faktory-vliyayut-na-formirovanie-tekhnicheskogo-dolga-v-protsesse-razrabotki/)

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

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

Рейтинг: 1131

Теги: ISO 20000, архитектура ИТ, TOGAF и IT4IT, бюджетирование, планирование затрат, командная работа, обучение сотрудников, учебные курсы, тренинги, управление знаниями, управление продуктами, продуктовый подход, эффективность, оптимизация