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

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

## [Какие процессные роли существуют в системе управления знаниями?](https://cleverics.ru/digital/kb-qa/kakie-protsessnye-roli-sushchestvuyut-v-sisteme-upravleniya-znaniyami/)

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

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

Рейтинг: 700

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

## [Сколько времени занимает сам процесс учета рабочего времени?](https://cleverics.ru/digital/kb-qa/skolko-vremeni-zanimaet-sam-protsess-ucheta-rabochego-vremeni/)

Процесс учета рабочего времени занимает значительно меньше, чем многие предполагают. За весь 2014 год на эту задачу потребовалось всего 6 часов 4 минуты, что составляет 0,32% всего рабочего времени за год. Это опровергает распространенное мнение о том, что учет времени может занимать от 5% до 10% рабочего времени.

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

Рейтинг: 700

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

## [Можно ли совместить управление конфигурациями и управление активами в едином процессе?](https://cleverics.ru/digital/kb-qa/mozhno-li-sovmestit-upravlenie-konfiguratsiyami-i-upravlenie-aktivami-v-edinom-protsesse/)

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

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

Рейтинг: 700

Теги: управление изменениями, управление ИТ-активами, ITAM, SAM, управление конфигурациями, CMDB

## [Какие сложности возникают при использовании метода «Пять «Почему?» для поиска корневой причины проблемы?](https://cleverics.ru/digital/kb-qa/kakie-slozhnosti-voznikayut-pri-ispolzovanii-metoda-pyat-pochemu-dlya-poiska-kornevoy-prichiny-probl/)

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

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

Рейтинг: 700

Теги: управление проблемами, управление рисками

## [Почему важно, чтобы опытные разработчики могли объяснять свои действия простым языком для нетехнических специалистов?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-chtoby-opytnye-razrabotchiki-mogli-obyasnyat-svoi-deystviya-prostym-yazykom-dlya-nete/)

Важность способности объяснять сложные технические аспекты простым языком обусловлена необходимостью эффективной коммуникации между IT и бизнесом. Опытные разработчики (миддл и сеньор) должны уметь излагать смысл своей деятельности, трудности, с которыми они сталкиваются, и обосновывать выбор решений, потому что: 1) это помогает бизнесу понимать ценность и стоимость технических решений; 2) предотвращает накопление технического долга из-за непонимания логической структуры системы; 3) современное программирование становится более верхнеуровневым и близким к человекопонятному языку, поэтому это должно быть проще. В тексте прямо указано, что это «the must», особенно учитывая, что части технического долга возникают из-за несостыковок в логической продуманности системы.

Автор: Сандра Урядова

Рейтинг: 700

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

## [Как влияет неправильное проектирование процесса на последующую автоматизацию?](https://cleverics.ru/digital/kb-qa/kak-vliyaet-nepravilnoe-proektirovanie-protsessa-na-posleduyushchuyu-avtomatizatsiyu/)

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

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

Рейтинг: 700

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

## [Какой подход помогает команде освоить новые практики при внедрении CI/CD?](https://cleverics.ru/digital/kb-qa/kakoy-podkhod-pomogaet-komande-osvoit-novye-praktiki-pri-vnedrenii-ci-cd/)

Одним из эффективных подходов к освоению новых практик при внедрении CI/CD является планомерное и ритмичное внедрение изменений в рамках выделенного времени, например, так называемого «налога в 20%». Это означает, что команда регулярно выделяет часть своего времени (примерно пятую часть) для постепенного внедрения необходимых технических изменений и улучшений процессов. Важно, чтобы команда сама проходила этот путь, возможно, с временной сторонней помощью, но при этом самостоятельно осваивала новые практики и отказывалась от старых. Такой подход позволяет команде не только технически реализовать изменения, но и глубоко понимать их ценность. Команда сама себе объясняет, почему теперь она делает что-то иначе — это создает внутреннее принятие новых процессов и устойчивость изменений в долгосрочной перспективе. Постепенное внедрение также снижает стресс от масштабных перемен и позволяет корректировать процесс на ходу, основываясь на получаемом опыте.

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

Рейтинг: 700

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

## [Какие проблемы возникают между разработчиками и тестировщиками в описанной ситуации?](https://cleverics.ru/digital/kb-qa/kakie-problemy-voznikayut-mezhdu-razrabotchikami-i-testirovshchikami-v-opisannoy-situatsii/)

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

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

Рейтинг: 700

Теги: Agile и гибкие методы разработки ПО, общие вопросы менеджмента, разработка ПО, управление процессами, ИТ-процессы

## [Каким образом можно интегрировать измеримые ресурсы в систему управления с использованием потоков создания ценности?](https://cleverics.ru/digital/kb-qa/kakim-obrazom-mozhno-integrirovat-izmerimye-resursy-v-sistemu-upravleniya-s-ispolzovaniem-potokov-so/)

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

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

Рейтинг: 700

Теги: DevOps, CI/CD, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, Канбан, WIP-лимиты, общие вопросы менеджмента, поддержка пользователей, Service Desk, Help Desk, поток создания ценности (Value Stream), управление отношениями, взаимодействие, BRM, управление процессами, ИТ-процессы

## [Почему метод EVM нельзя считать полноценной системой измерения успешности завершенных проектов?](https://cleverics.ru/digital/kb-qa/pochemu-metod-evm-nelzya-schitat-polnotsennoy-sistemoy-izmereniya-uspeshnosti-zavershennykh-proektov/)

Метод EVM нельзя считать полноценной системой измерения успешности завершённых проектов, прежде всего из-за недостатка показателя SPI, который теряет информативность к концу проекта, автоматически становясь равным 1, что не отражает реального соблюдения сроков. Хотя EVM предоставляет ценные метрики для текущего управления проектом, особенно в части контроля бюджета через CPI, его структура не позволяет провести адекватную пост-оценку проекта по временным показателям, что критично для комплексной оценки успешности проекта, включающей качество, сроки и соответствие бюджету.

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

Рейтинг: 700

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