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

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

## [Почему гибкие методологии не всегда подходят для всех типов задач?](https://cleverics.ru/digital/kb-qa/pochemu-gibkie-metodologii-ne-vsegda-podkhodyat-dlya-vsekh-tipov-zadach/)

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

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

Рейтинг: 828

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

## [Как в классическом подходе рассчитывается коэффициент эффективности производственного потока?](https://cleverics.ru/digital/kb-qa/kak-v-klassicheskom-podkhode-rasschityvaetsya-koeffitsient-effektivnosti-proizvodstvennogo-potoka/)

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

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

Рейтинг: 828

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

## [Что такое домены простоты, сложности, и хаоса в контексте управления ИТ-системами?](https://cleverics.ru/digital/kb-qa/chto-takoe-domeny-prostoty-slozhnosti-i-khaosa-v-kontekste-upravleniya-it-sistemami/)

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

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

Рейтинг: 828

Теги: архитектура ИТ, TOGAF и IT4IT, поддержка пользователей, Service Desk, Help Desk, управление инцидентами, управление отношениями, взаимодействие, BRM

## [Что такое роль координатора/менеджера в процессе анализа проблем DevOps?](https://cleverics.ru/digital/kb-qa/chto-takoe-rol-koordinatora-menedzhera-v-protsesse-analiza-problem-devops/)

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

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

Рейтинг: 828

Теги: DevOps, CI/CD, командная работа, общие вопросы менеджмента, управление проблемами, управление процессами, ИТ-процессы

## [Какие шаги следует предпринять после устранения major-инцидента?](https://cleverics.ru/digital/kb-qa/kakie-shagi-sleduet-predprinyat-posle-ustraneniya-major-intsidenta/)

После устранения major-инцидента необходимо: оперативно оповестить ИТ-специалистов, чтобы они могли завершить обработку всех связанных обращений и проверить восстановление ИТ-услуг; уведомить конечных пользователей о восстановлении сервисов; провести мини-расследование (major incident review) с формированием отчета, направленного на предотвращение повторения инцидента; оценить действия по обработке инцидента и при необходимости зарегистрировать проблему, известную ошибку или новые мероприятия по улучшению ИТ-услуг (например, в рамках service improvement plan или реестра CSI).

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

Рейтинг: 827

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

## [Почему на практике работа часто отличается от имеющихся регламентов и инструкций?](https://cleverics.ru/digital/kb-qa/pochemu-na-praktike-rabota-chasto-otlichaetsya-ot-imeyushchikhsya-reglamentov-i-instruktsiy/)

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

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

Рейтинг: 827

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

## [Как можно улучшить измерение доступности ИТ-услуг для лучшего отражения бизнес-влияния?](https://cleverics.ru/digital/kb-qa/kak-mozhno-uluchshit-izmerenie-dostupnosti-it-uslug-dlya-luchshego-otrazheniya-biznes-vliyaniya/)

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

Автор: Павел Дёмин

Рейтинг: 827

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

## [Как рассчитывается интегральный показатель BS (Balanced Score) в методике с динамическими весами?](https://cleverics.ru/digital/kb-qa/kak-rasschityvaetsya-integralnyy-pokazatel-bs-balanced-score-v-metodike-s-dinamicheskimi-vesami/)

Интегральный показатель BS (Balanced Score) рассчитывается с помощью метода взвешенного среднего, но с ключевым отличием: веса KPI являются динамическими и зависят от значений показателей. Чем ниже значение KPI (чем больше отклонение от целевого), тем выше его вес. Формула включает параметр Wmax, который определяется через выбранное руководителем значение MS (Marginal Score). Для случая с N равнозначными KPI, если 9 из них равны 100%, а один – 0%, интегральный показатель будет равен MS. Это обеспечивает более значительное снижение оценки за провал одного показателя, чем при стандартных методах.

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

Рейтинг: 827

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

## [Какие примеры сопряженных метрик можно привести, кроме доступности первой линии и решения обращений на первой линии?](https://cleverics.ru/digital/kb-qa/kakie-primery-sopryazhennykh-metrik-mozhno-privesti-krome-dostupnosti-pervoy-linii-i-resheniya-obras/)

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

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

Рейтинг: 827

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

## [Почему поиск виноватых ведет к провалу проекта?](https://cleverics.ru/digital/kb-qa/pochemu-poisk-vinovatykh-vedet-k-provalu-proekta/)

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

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

Рейтинг: 827

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