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

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

## [Какие риски возникают при недостаточной компетентности первой линии поддержки в сфере прикладного ПО?](https://cleverics.ru/digital/kb-qa/kakie-riski-voznikayut-pri-nedostatochnoy-kompetentnosti-pervoy-linii-podderzhki-v-sfere-prikladnogo/)

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

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

Рейтинг: 867

Теги: автоматизация ИТ-процессов, ПО для ITSM и ESM, бизнес, ценность, бизнес-заказчик, поддержка пользователей, Service Desk, Help Desk, управление запросами на обслуживание, управление инцидентами, управление рисками

## [Как следует поступить руководителю, если в RACI-матрице за ним закреплены несколько задач с пометкой R?](https://cleverics.ru/digital/kb-qa/kak-sleduet-postupit-rukovoditelyu-esli-v-raci-matritse-za-nim-zakrepleny-neskolko-zadach-s-pometkoy/)

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

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

Рейтинг: 867

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

## [Как организовать координацию между ИТ-специалистами в процессе управления конфигурациями?](https://cleverics.ru/digital/kb-qa/kak-organizovat-koordinatsiyu-mezhdu-it-spetsialistami-v-protsesse-upravleniya-konfiguratsiyami/)

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

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

Рейтинг: 867

Теги: управление конфигурациями, CMDB

## [Нужно ли ждать годовой статистики по инцидентам для начала управления проблемами?](https://cleverics.ru/digital/kb-qa/nuzhno-li-zhdat-godovoy-statistiki-po-intsidentam-dlya-nachala-upravleniya-problemami/)

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

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

Рейтинг: 867

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

## [Какие преимущества дают регулярные встречи, связанные с SLA?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-dayut-regulyarnye-vstrechi-svyazannye-s-sla/)

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

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

Рейтинг: 867

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

## [Какие ошибки могут быть допущены при применении цикла Деминга в улучшении процессов?](https://cleverics.ru/digital/kb-qa/kakie-oshibki-mogut-byt-dopushcheny-pri-primenenii-tsikla-deminga-v-uluchshenii-protsessov/)

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

Автор: Степан Хрулёв

Рейтинг: 867

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

## [Почему расчет метрики времени реакции лучше проводить по отдельным назначениям инцидента, а не по инциденту в целом?](https://cleverics.ru/digital/kb-qa/pochemu-raschet-metriki-vremeni-reaktsii-luchshe-provodit-po-otdelnym-naznacheniyam-intsidenta-a-ne/)

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

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

Рейтинг: 867

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

## [Что означает код закрытия "Нет решения" в контексте управления ИТ-инцидентами?](https://cleverics.ru/digital/kb-qa/chto-oznachaet-kod-zakrytiya-net-resheniya-v-kontekste-upravleniya-it-intsidentami/)

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

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

Рейтинг: 867

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

## [Какие проблемы возникают при классификации услуг по модели ITIL V3 в современных условиях?](https://cleverics.ru/digital/kb-qa/kakie-problemy-voznikayut-pri-klassifikatsii-uslug-po-modeli-itil-v3-v-sovremennykh-usloviyakh/)

Основная проблема классификации услуг по модели ITIL V3 в современных условиях заключается в том, что жесткое разделение на бизнес-услуги и поддерживающие услуги не учитывает сложность современных цифровых экосистем, где границы между видами услуг часто размыты. Модель не учитывает, что одна и та же услуга может быть бизнес-услугой для одного потребителя и поддерживающей для другого. Кроме того, в ITIL4 термины 'бизнес-услуга' и 'информационная технологическая услуга' практически не используются, что создает неоднозначность при переходе от V3 к новой версии.

Автор: Артём Мукосеев

Рейтинг: 867

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

## [Что такое Major инцидент в контексте измерения доступности?](https://cleverics.ru/digital/kb-qa/chto-takoe-major-intsident-v-kontekste-izmereniya-dostupnosti/)

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

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

Рейтинг: 867

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