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

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

## [Что включает в себя система измерения и оценки в рамках практики управления инцидентами?](https://cleverics.ru/digital/kb-qa/chto-vklyuchaet-v-sebya-sistema-izmereniya-i-otsenki-v-ramkakh-praktiki-upravleniya-intsidentami/)

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

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

Рейтинг: 869

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

## [В чем заключаются минусы проектного управления при эксплуатации ИТ-систем?](https://cleverics.ru/digital/kb-qa/v-chem-zaklyuchayutsya-minusy-proektnogo-upravleniya-pri-ekspluatatsii-it-sistem/)

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

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

Рейтинг: 869

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

## [В чем различие между инициативами и пользовательскими историями в процессе разработки?](https://cleverics.ru/digital/kb-qa/v-chem-razlichie-mezhdu-initsiativami-i-polzovatelskimi-istoriyami-v-protsesse-razrabotki/)

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

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

Рейтинг: 869

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

## [Каким образом 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 адаптирует классическую концепцию цепочки создания ценности применительно к ИТ, организовывая все ИТ-активности в последовательность, направленную на создание ценности для бизнеса.

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

Рейтинг: 869

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

## [Что является более важным при внедрении процессов — содержание раздела KPI или культура измерения?](https://cleverics.ru/digital/kb-qa/chto-yavlyaetsya-bolee-vazhnym-pri-vnedrenii-protsessov-soderzhanie-razdela-kpi-ili-kultura-izmereni/)

Более важным при внедрении процессов является формирование культуры измерения и понимания её ценности среди сотрудников, нежели формальное заполнение раздела KPI. Разработка метрик без понимания их цели и применения приведет к созданию формальных показателей, которые не будут использоваться для принятия реальных решений.

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

Рейтинг: 869

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

## [Почему нельзя просто скопировать список качеств менеджера от Google?](https://cleverics.ru/digital/kb-qa/pochemu-nelzya-prosto-skopirovat-spisok-kachestv-menedzhera-ot-google/)

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

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

Рейтинг: 869

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

## [Почему традиционные метрики управления проблемами считаются неэффективными согласно данному описанию?](https://cleverics.ru/digital/kb-qa/pochemu-traditsionnye-metriki-upravleniya-problemami-schitayutsya-neeffektivnymi-soglasno-dannomu-op/)

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

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

Рейтинг: 869

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

## [Как учитывается время работы над инцидентом при использовании механизма остановки таймера?](https://cleverics.ru/digital/kb-qa/kak-uchityvaetsya-vremya-raboty-nad-intsidentom-pri-ispolzovanii-mekhanizma-ostanovki-taymera/)

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

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

Рейтинг: 869

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

## [Какие вопросы стоит задать практикам управления доступом для выявления пробелов в их процессах?](https://cleverics.ru/digital/kb-qa/kakie-voprosy-stoit-zadat-praktikam-upravleniya-dostupom-dlya-vyyavleniya-probelov-v-ikh-protsessakh/)

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

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

Рейтинг: 869

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

## [Какие новые акценты появились в описании практик ITIL 4 по сравнению с предыдущими версиями?](https://cleverics.ru/digital/kb-qa/kakie-novye-aktsenty-poyavilis-v-opisanii-praktik-itil-4-po-sravneniyu-s-predydushchimi-versiyami/)

В ITIL 4 руководства по практикам включают не только обновленные описания процессной деятельности, но и дополнительные элементы, таких как необходимые компетенции сотрудников, технические инструменты и информационное сопровождение, а также рекомендации по использованию аутсорсинга. Для практики Service Desk внедрены концепция омниканальных коммуникаций и понятие "Сервисная эмпатия" - способность понимать интересы и потребности пользователей. При управлении инцидентами делается акцент на автоматическое обнаружение и решение проблем до их влияния на пользователей. Управление запросами на обслуживание рассматривается во всей цепочке предоставления услуг, а не как отдельный процесс. Появился больший фокус на анализ данных и предиктивную аналитику для предотвращения проблем, а не только для их решения после возникновения.

Автор: Игорь Фадеев

Рейтинг: 869

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