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

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

## [Какие факторы успеха важны для эффективного управления инцидентами?](https://cleverics.ru/digital/kb-qa/kakie-faktory-uspekha-vazhny-dlya-effektivnogo-upravleniya-intsidentami/)

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

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

Рейтинг: 889

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

## [Как диагностика продуктовой команды может помочь выявить и преодолеть эффект Даннинга-Крюгера?](https://cleverics.ru/digital/kb-qa/kak-diagnostika-produktovoy-komandy-mozhet-pomoch-vyyavit-i-preodolet-effekt-danninga-kryugera/)

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

Автор: Сандра Урядова

Рейтинг: 889

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

## [Почему компании, придерживающиеся стратегии выживания, выделяют больший процент бюджета на управление ИТ?](https://cleverics.ru/digital/kb-qa/pochemu-kompanii-priderzhivayushchiesya-strategii-vyzhivaniya-vydelyayut-bolshiy-protsent-byudzheta/)

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

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

Рейтинг: 889

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

## [Что такое сервис-интегратор в контексте модели SIAM?](https://cleverics.ru/digital/kb-qa/chto-takoe-servis-integrator-v-kontekste-modeli-siam/)

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

Автор: Дмитрий Хруслов

Рейтинг: 889

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

## [Какие роли и ответственности должны быть определены в рамках процесса управления сервисными активами и конфигурациями?](https://cleverics.ru/digital/kb-qa/kakie-roli-i-otvetstvennosti-dolzhny-byt-opredeleny-v-ramkakh-protsessa-upravleniya-servisnymi-aktiv/)

В рамках процесса управления сервисными активами и конфигурациями должны быть четко определены следующие роли и ответственности: ответственные за идентификацию и учет конфигурационных единиц, специалисты, отвечающие за поддержание актуальности данных CMDB, члены Совета по изменениям (CAB), ответственные за авторизацию базовых состояний, изменений и релизов, владельцы конфигурационных единиц, ответственные за проверку корректности и полноты информации. Также важно определить взаимодействие с другими процессами, например, с управлением изменениями, управлением релизами и службой Service Desk, чтобы обеспечить четкую передачу ответственности за обновление данных конфигурации на всех этапах жизненного цикла сервисов.

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

Рейтинг: 889

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

## [Какие проблемы возникают при игнорировании управления ИТ-архитектурой при создании системы управления задачами?](https://cleverics.ru/digital/kb-qa/kakie-problemy-voznikayut-pri-ignorirovanii-upravleniya-it-arkhitekturoy-pri-sozdanii-sistemy-upravl/)

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

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

Рейтинг: 889

Теги: архитектура ИТ, TOGAF и IT4IT, мониторинг, стратегия, управление процессами, ИТ-процессы, управление рисками, эффективность, оптимизация

## [Какой период следует использовать для расчёта FTR в разрезе рабочих групп?](https://cleverics.ru/digital/kb-qa/kakoy-period-sleduet-ispolzovat-dlya-rascheta-ftr-v-razreze-rabochikh-grupp/)

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

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

Рейтинг: 889

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

## [Как должна выглядеть правильная цепочка создания и внедрения KPI в управленческие процессы?](https://cleverics.ru/digital/kb-qa/kak-dolzhna-vyglyadet-pravilnaya-tsepochka-sozdaniya-i-vnedreniya-kpi-v-upravlencheskie-protsessy/)

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

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

Рейтинг: 889

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

## [Почему использование автоматической функциональной эскалации может негативно повлиять на мотивацию специалистов текущего уровня поддержки?](https://cleverics.ru/digital/kb-qa/pochemu-ispolzovanie-avtomaticheskoy-funktsionalnoy-eskalatsii-mozhet-negativno-povliyat-na-motivats/)

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

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

Рейтинг: 889

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

## [Как можно предотвратить ситуацию параллельной работы нескольких линий поддержки над одной заявкой?](https://cleverics.ru/digital/kb-qa/kak-mozhno-predotvratit-situatsiyu-parallelnoy-raboty-neskolkikh-liniy-podderzhki-nad-odnoy-zayavkoy/)

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

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

Рейтинг: 889

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