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

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

## [Каковы ограничения гибких методологий управления ИТ в контексте эксплуатации?](https://cleverics.ru/digital/kb-qa/kakovy-ogranicheniya-gibkikh-metodologiy-upravleniya-it-v-kontekste-ekspluatatsii/)

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

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

Рейтинг: 842

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

## [Какие проблемы возникают при измерении снижения числа инцидентов после внедрения изменений?](https://cleverics.ru/digital/kb-qa/kakie-problemy-voznikayut-pri-izmerenii-snizheniya-chisla-intsidentov-posle-vnedreniya-izmeneniy/)

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

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

Рейтинг: 842

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

## [Чем руководителям проще понять ценность ITIL по сравнению с рядовыми специалистами?](https://cleverics.ru/digital/kb-qa/chem-rukovoditelyam-proshche-ponyat-tsennost-itil-po-sravneniyu-s-ryadovymi-spetsialistami/)

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

Автор: Елена Колбей

Рейтинг: 842

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

## [Как влияет управление ветками в Git на успешность CI/CD?](https://cleverics.ru/digital/kb-qa/kak-vliyaet-upravlenie-vetkami-v-git-na-uspeshnost-ci-cd/)

Управление ветками в Git напрямую влияет на успешность CI/CD, поскольку конвейер развёртывания требует определенного уровня дисциплины и стандартизации подходов к работе с кодом. Если команда работает с Git «кое-как», создает десятки долгоживущих веток кода по каждому поводу и имеет постоянные проблемы с мержами, зависящие от одного «очень умного парня», это серьезно затруднит построение эффективного конвейера. У успешных CI/CD практик обычно используются стратегии ветвления, такие как Git Flow или его упрощенные варианты, с четкими правилами о том, когда и как создавать ветки и как их мержить обратно. Долгоживущие ветки затрудняют интеграцию изменений и увеличивают сложность выявления и устранения конфликтов, что противоречит принципам непрерывной интеграции, где изменения должны регулярно объединяться в основную ветку и проверяться автоматически.

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

Рейтинг: 842

Теги: DevOps, CI/CD, Канбан, WIP-лимиты, командная работа, стратегия, управление конфигурациями, CMDB, управление релизами

## [Как неожиданные бонусы от поставщика услуг влияют на формирование личного восприятия качества сервиса?](https://cleverics.ru/digital/kb-qa/kak-neozhidannye-bonusy-ot-postavshchika-uslug-vliyayut-na-formirovanie-lichnogo-vospriyatiya-kaches/)

Неожиданные бонусы от поставщика услуг значительно влияют на формирование личного восприятия качества сервиса, поскольку они нарушают стереотипы, сформированные у клиента на основе предыдущего опыта. Эти мелкие приятные сюрпризы становятся яркими точками в общем впечатлении, заставляя клиента пересмотреть своё мнение о качестве обслуживания. Даже если основные услуги оказаны на удовлетворительном уровне, дополнительные бонусы могут создать впечатление исключительно высокого качества сервиса и повысить вероятность повторного обращения.

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

Рейтинг: 842

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

## [Как определить Tmin и Tmax для конкретных ИТ-сервисов?](https://cleverics.ru/digital/kb-qa/kak-opredelit-tmin-i-tmax-dlya-konkretnykh-it-servisov/)

Tmin определяется как время, в течение которого простои не оказывают измеримого влияния на бизнес-процессы, и устанавливается совместно с заказчиком на основе анализа критичности сервисов. Tmax формируется как компромисс между максимально допустимым простоем для бизнеса (часто близким к Tmin) и реальными возможностями ИТ-подразделения с запасом (как правило, значительно дольше). Например, бизнес может требовать восстановления за 30 минут (Tmin), тогда Tmax устанавливается в 4 часа, учитывая текущие возможности ИТ.

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

Рейтинг: 842

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

## [Почему важно регистрировать все поступающие обращения в Service Desk?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-registrirovat-vse-postupayushchie-obrashcheniya-v-service-desk/)

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

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

Рейтинг: 841

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

## [Как правильно организовать процесс оптимизации затрат в компании?](https://cleverics.ru/digital/kb-qa/kak-pravilno-organizovat-protsess-optimizatsii-zatrat-v-kompanii/)

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

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

Рейтинг: 841

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

## [Какие критерии определяют применимость продуктового подхода?](https://cleverics.ru/digital/kb-qa/kakie-kriterii-opredelyayut-primenimost-produktovogo-podkhoda/)

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

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

Рейтинг: 841

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

## [Какое время в процессе управления инцидентами часто недооценивается и почему это важно учитывать?](https://cleverics.ru/digital/kb-qa/kakoe-vremya-v-protsesse-upravleniya-intsidentami-chasto-nedootsenivaetsya-i-pochemu-eto-vazhno-uchi/)

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

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

Рейтинг: 841

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