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

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

## [Какие этапы можно выделить в процессе управления проблемами?](https://cleverics.ru/digital/kb-qa/kakie-etapy-mozhno-vydelit-v-protsesse-upravleniya-problemami/)

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

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

Рейтинг: 1088

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

## [Как связаны процессный и сервисный подходы в рамках фреймворка ITIL?](https://cleverics.ru/digital/kb-qa/kak-svyazany-protsessnyy-i-servisnyy-podkhody-v-ramkakh-freymvorka-itil/)

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

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

Рейтинг: 1088

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

## [Как построить дерево отказов для конкретной функциональности ИТ-услуги, например, «Обработка обращений» в ITSM-системе?](https://cleverics.ru/digital/kb-qa/kak-postroit-derevo-otkazov-dlya-konkretnoy-funktsionalnosti-it-uslugi-naprimer-obrabotka-obrashchen/)

Для построения дерева отказов для функции «Обработка обращений» следует выполнить следующие шаги: определить топ-событие (отказ функции обработки обращений); выявить прямые причины этого отказа на первом уровне (например: недоступность базы данных, ошибки в логике обработки, проблемы с сетью между компонентами); для каждой из этих причин определить более низкоуровневые события, пока не достигнуты базовые события, которые уже не требуют дальнейшей декомпозиции (сбои оборудования, программные ошибки, действия персонала). При этом следует использовать правильные логические операторы между событиями («И», «ИЛИ» и др.). Например, если для отказа обработки обращений необходимо одновременное отсутствие сетевой связности между сервером и БД, а также сбой в прикладном слое – используется оператор «И». Если же достаточно одного из этих условий – оператор «ИЛИ». Базовые события размещаются на листьях дерева и могут быть оценены количественно для последующего расчета вероятности топ-события.

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

Рейтинг: 1088

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

## [Как современные подходы ITIL 4 расширяют понимание приоритизации инцидентов?](https://cleverics.ru/digital/kb-qa/kak-sovremennye-podkhody-itil-4-rasshiryayut-ponimanie-prioritizatsii-intsidentov/)

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

Автор: Анна Васильева

Рейтинг: 1088

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

## [Как определить, какие обращения должны входить в состав Nj при расчёте FTR?](https://cleverics.ru/digital/kb-qa/kak-opredelit-kakie-obrashcheniya-dolzhny-vkhodit-v-sostav-nj-pri-raschete-ftr/)

В состав Nj при расчёте FTR должны входить только те обращения, обработанные j-той группой, по которым процедура проверки решения полностью завершена. К ним относятся: закрытые без рекламаций инциденты (Cj) и возвраты на доработку (Sj). Не включаются в Nj обращения, которые всё ещё находятся в процессе обработки или где проверка решения не завершена, так как они не могут быть учтены при определении качества работы группы.

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

Рейтинг: 1088

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

## [Может ли одна и та же услуга быть одновременно бизнес-услугой и поддерживающей?](https://cleverics.ru/digital/kb-qa/mozhet-li-odna-i-ta-zhe-usluga-byt-odnovremenno-biznes-uslugoy-i-podderzhivayushchey/)

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

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

Рейтинг: 1088

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

## [Какие проблемы возникают из-за высокой текучести кадров в ИТ-подразделениях?](https://cleverics.ru/digital/kb-qa/kakie-problemy-voznikayut-iz-za-vysokoy-tekuchesti-kadrov-v-it-podrazdeleniyakh/)

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

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

Рейтинг: 1088

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

## [Почему электронная почта постепенно перестает быть основным каналом взаимодействия с Service Desk?](https://cleverics.ru/digital/kb-qa/pochemu-elektronnaya-pochta-postepenno-perestaet-byt-osnovnym-kanalom-vzaimodeystviya-s-service-desk/)

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

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

Рейтинг: 1087

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

## [Какое экономическое обоснование проведения предпроектного обследования можно привести?](https://cleverics.ru/digital/kb-qa/kakoe-ekonomicheskoe-obosnovanie-provedeniya-predproektnogo-obsledovaniya-mozhno-privesti/)

Предпроектное обследование экономически оправдано, так как оно позволяет снизить проектные риски и точно определить объем работы, что в итоге приводит к значительной экономии средств. В конкретном примере, приведенном в тексте, предварительная бюджетная оценка проекта сократилась в 4 раза после проведения обследования, при этом стоимость самого обследования составила всего 1,5% от суммы сэкономленных средств. Для консультационных проектов обследование считается экономически эффективным, если его стоимость не превышает 5-10% от общей стоимости проекта, особенно учитывая, что стандартные риски при неопределенной постановке задачи обычно начинаются от 10%.

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

Рейтинг: 1087

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

## [Почему прозрачность результатов работы команды важна для участников разработки?](https://cleverics.ru/digital/kb-qa/pochemu-prozrachnost-rezultatov-raboty-komandy-vazhna-dlya-uchastnikov-razrabotki/)

Прозрачность результатов работы команды важна потому, что это помогает всем участникам процесса совместно и согласованно понимать, какую ценность они создают. Когда разработчики видят реальные реакции пользователей на их работу (негативные отзывы, запросы на новые возможности, положительный отклик на митапах), это значительно повышает их вовлеченность, по сравнению с абстрактными показателями типа "увеличение конверсии на 0,07%". Это позволяет команде осознанно определять приоритеты, оценивать результаты своих решений, понимать, почему одни задачи более важны, чем другие. Прозрачность предотвращает ситуацию, когда разработчик просто разрабатывает фичи по очереди и забывает о них, не видя их реального эффекта.

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

Рейтинг: 1087

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