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

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

## [Какие проблемы возникают при учёте недоступности сотрудников в системах автоматического распределения задач?](https://cleverics.ru/digital/kb-qa/kakie-problemy-voznikayut-pri-uchete-nedostupnosti-sotrudnikov-v-sistemakh-avtomaticheskogo-rasprede/)

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

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

Рейтинг: 746

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

## [Почему важно различать организатора работы и участников исполнения при наличии нескольких R в RACI-матрице?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-razlichat-organizatora-raboty-i-uchastnikov-ispolneniya-pri-nalichii-neskolkikh-r-v-r/)

При наличии нескольких R (Responsible) в RACI-матрице важно четко различать, кто именно отвечает за организацию работы, а кто просто участвует в ее исполнении, чтобы избежать путаницы в обязанностях и ответственности. Если не провести это разделение, может возникнуть ситуация, когда несколько человек считают, что ответственность за организацию лежит на другом, что приведет к срыву сроков или низкому качеству выполнения задачи. Четкое определение организатора работы помогает выстроить правильную иерархию внутри задачи, определить центр принятия решений и точку ответственности за процесс. Это также позволяет руководителю контролировать именно те аспекты, которые критичны для конечного результата, не вникая во все детали исполнения.

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

Рейтинг: 746

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

## [Как найти оптимальный баланс между разработкой новых функций и поддержанием текущей системы?](https://cleverics.ru/digital/kb-qa/kak-nayti-optimalnyy-balans-mezhdu-razrabotkoy-novykh-funktsiy-i-podderzhaniem-tekushchey-sistemy/)

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

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

Рейтинг: 745

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

## [Какие основные проблемы возникают при отсутствии качественного плана отката?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-problemy-voznikayut-pri-otsutstvii-kachestvennogo-plana-otkata/)

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

Автор: Шамиль Бабаев

Рейтинг: 745

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

## [Каким образом IT4IT использует концепцию цепочки создания ценности Портера?](https://cleverics.ru/digital/kb-qa/kakim-obrazom-it4it-ispolzuet-kontseptsiyu-tsepochki-sozdaniya-tsennosti-portera/)

В рамках IT4IT Reference Architecture концепция цепочки создания ценности (Value Chain), впервые предложенной Майклом Портером в 1985 году, является основой архитектуры. IT4IT представляет ИТ как цепочку создания ценности, где каждый этап добавляет определенную ценность к конечному продукту или услуге. Эта Value Chain в IT4IT состоит из четырех основных потоков: Strategy to Portfolio (S2P), Requirement to Deployment (R2D), Request to Fulfill (R2F) и Detect to Correct (D2C). Каждый из этих потоков представляет собой последовательность действий, которые преобразуют первоначальные потребности бизнеса в предоставляемые ИТ-услуги и поддерживают их эксплуатацию. Таким образом, IT4IT адаптирует классическую концепцию цепочки создания ценности применительно к ИТ, организовывая все ИТ-активности в последовательность, направленную на создание ценности для бизнеса.

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

Рейтинг: 745

Теги: архитектура ИТ, TOGAF и IT4IT, бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, управление продуктами, продуктовый подход

## [Почему готовые решения могут быть вредны для развития мышления?](https://cleverics.ru/digital/kb-qa/pochemu-gotovye-resheniya-mogut-byt-vredny-dlya-razvitiya-myshleniya/)

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

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

Рейтинг: 745

Теги: эффективность, оптимизация

## [Какие недостатки имеют магические квадраты Гартнера при выборе ITSM-решений?](https://cleverics.ru/digital/kb-qa/kakie-nedostatki-imeyut-magicheskie-kvadraty-gartnera-pri-vybore-itsm-resheniy/)

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

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

Рейтинг: 745

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

## [Почему закрытие инцидентов на первой линии может быть неудобно для пользователей?](https://cleverics.ru/digital/kb-qa/pochemu-zakrytie-intsidentov-na-pervoy-linii-mozhet-byt-neudobno-dlya-polzovateley/)

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

Автор: Дмитрий Подольский

Рейтинг: 745

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

## [Как понять, что проблему необходимо рассматривать на уровне организации труда, а не только технической инфраструктуры?](https://cleverics.ru/digital/kb-qa/kak-ponyat-chto-problemu-neobkhodimo-rassmatrivat-na-urovne-organizatsii-truda-a-ne-tolko-tekhniches/)

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

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

Рейтинг: 745

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

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

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

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

Рейтинг: 745

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