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

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

## [Почему использование минимального норматива времени в 15 минут для учёта трудозатрат может привести к искажению данных?](https://cleverics.ru/digital/kb-qa/pochemu-ispolzovanie-minimalnogo-normativa-vremeni-v-15-minut-dlya-ucheta-trudozatrat-mozhet-privest/)

Применение минимального норматива в 15 минут, даже для задач, выполняемых за 1–2 минуты (например, отправка простого электронного письма), приводит к многократному завышению суммарных трудозатрат. Это создаёт ложную статистику, где за рабочий день на 8 часов может быть зафиксировано 12 часов работы. Такой метод часто является скрытым сопротивлением сотрудников внедрению учёта, так как искажает реальную загрузку и мешает анализу эффективности. Подобная практика подрывает доверие к системе и затрудняет планирование ресурсов.

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

Рейтинг: 1115

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

## [Как Warranty связана с соглашением об уровне услуг (SLA)?](https://cleverics.ru/digital/kb-qa/kak-warranty-svyazana-s-soglasheniem-ob-urovne-uslug-sla/)

Warranty напрямую связана с соглашением об уровне услуг (SLA), поскольку компоненты гарантии (доступность, мощность, безопасность и непрерывность) являются основой для определения количественных и качественных показателей SLA. SLA фиксирует ожидаемые уровни характеристик Warranty, которые поставщик услуги обязуется поддерживать. Например, SLA может определить, что услуга должна быть доступна 99,9% времени (доступность), иметь достаточную пропускную способность для 1000 одновременных пользователей (мощность), соответствовать определенным стандартам шифрования (безопасность) и иметь план восстановления после сбоев (непрерывность). Именно через эти показатели оценивается пригодность услуги к использованию, что позволяет потребителю понимать, на какие характеристики качества он может рассчитывать.

Автор: Александр Движков

Рейтинг: 1115

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

## [Каким образом в разных ИТ-моделях объединяются процессы управления доступностью и непрерывностью?](https://cleverics.ru/digital/kb-qa/kakim-obrazom-v-raznykh-it-modelyakh-obedinyayutsya-protsessy-upravleniya-dostupnostyu-i-nepreryvnos/)

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

Автор: Константин Нарыжный

Рейтинг: 1115

Теги: ITIL, управление доступностью, управление инцидентами

## [Какие метрики помогают оценить предсказуемость выполнения задач в DevOps?](https://cleverics.ru/digital/kb-qa/kakie-metriki-pomogayut-otsenit-predskazuemost-vypolneniya-zadach-v-devops/)

Метрики, которые помогают оценить предсказуемость выполнения задач в DevOps, в основном связаны с регулярностью и стабильностью работы команды. Ключевая метрика предсказуемости - это последовательность выполнения взятых на себя задач за определенные отрезки времени. Если команда регулярно выполняет запланированный объем работы в установленные сроки, это говорит о высокой предсказуемости. Дополнительно могут анализироваться показатели отклонения от плана, частота срывов сроков, стабильность velocity (скорости выполнения задач) и улучшение точности оценок. Предсказуемость является важным компонентом качества работы DevOps-команды, так как позволяет более точно планировать релизы и управлять ожиданиями заинтересованных сторон, что в конечном итоге способствует уменьшению времени выпуска продукта (lead time).

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

Рейтинг: 1115

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

## [Что такое главное различие между запросом и потребностью в контексте взаимодействия ИТ и бизнеса?](https://cleverics.ru/digital/kb-qa/chto-takoe-glavnoe-razlichie-mezhdu-zaprosom-i-potrebnostyu-v-kontekste-vzaimodeystviya-it-i-biznesa/)

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

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

Рейтинг: 1114

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

## [Как предотвратить отставание от графика реализации проектов?](https://cleverics.ru/digital/kb-qa/kak-predotvratit-otstavanie-ot-grafika-realizatsii-proektov/)

Чтобы предотвратить отставание от графика, необходимо ежедневно контролировать состояние проекта, особенно критически важных этапов. Как показывает практика, опоздания начинаются с самых ранних этапов, поэтому важно выявлять даже небольшие задержки сразу же. Для этого следует установить ежедневные проверки прогресса по ключевым проектам, фиксировать отклонения и оперативно принимать корректирующие меры. Также важно четко определить контрольные точки по календарю и не пропускать их ни при каких условиях.

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

Рейтинг: 1114

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

## [Почему лидер-слуга не всегда достаточно эффективен для управления командами?](https://cleverics.ru/digital/kb-qa/pochemu-lider-sluga-ne-vsegda-dostatochno-effektiven-dlya-upravleniya-komandami/)

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

Автор: Павел Капусткин

Рейтинг: 1114

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

## [Какие основные факторы определяют успешное внедрение гибких методологий в ИТ-команде?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-faktory-opredelyayut-uspeshnoe-vnedrenie-gibkikh-metodologiy-v-it-komande/)

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

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

Рейтинг: 1113

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

## [Как инструменты Role mining (анализа ролей) помогают в управлении доступом?](https://cleverics.ru/digital/kb-qa/kak-instrumenty-role-mining-analiza-roley-pomogayut-v-upravlenii-dostupom/)

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

Автор: Александр Омельченко

Рейтинг: 1113

Теги: общие вопросы менеджмента, управление доступом, IDM, ролевые модели, RBAC, ABAC, управление процессами, ИТ-процессы

## [Какие риски связаны с переходом на микросервисную архитектуру без должного планирования?](https://cleverics.ru/digital/kb-qa/kakie-riski-svyazany-s-perekhodom-na-mikroservisnuyu-arkhitekturu-bez-dolzhnogo-planirovaniya/)

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

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

Рейтинг: 1113

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