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

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

## [Как определить, когда услуга становится ресурсом для другой услуги?](https://cleverics.ru/digital/kb-qa/kak-opredelit-kogda-usluga-stanovitsya-resursom-dlya-drugoy-uslugi/)

Услуга становится ресурсом для другой услуги, когда она не предоставляется конечному потребителю напрямую, а используется как компонент для обеспечения более комплексной услуги. Определить это можно по следующим признакам: услуга не имеет прямого SLA с конечным клиентом, потребитель не взаимодействует с ней напрямую, она является частью внутренней архитектуры предоставления основной услуги. Например, услуга хостинга серверов может быть ресурсом для услуги предоставления веб-приложения конечному пользователю.

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

Рейтинг: 857

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

## [Какие ключевые показатели эффективности связаны с удовлетворенностью сотрудников сервис деска?](https://cleverics.ru/digital/kb-qa/kakie-klyuchevye-pokazateli-effektivnosti-svyazany-s-udovletvorennostyu-sotrudnikov-servis-deska/)

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

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

Рейтинг: 856

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

## [Какие факторы ограничивают использование чат-ботов для решения сложных проблем клиентов?](https://cleverics.ru/digital/kb-qa/kakie-faktory-ogranichivayut-ispolzovanie-chat-botov-dlya-resheniya-slozhnykh-problem-klientov/)

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

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

Рейтинг: 856

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

## [Какие типы изменений в организации могут требовать пересмотра ролевой модели управления доступом?](https://cleverics.ru/digital/kb-qa/kakie-tipy-izmeneniy-v-organizatsii-mogut-trebovat-peresmotra-rolevoy-modeli-upravleniya-dostupom/)

Пересмотр ролевой модели необходим при следующих изменениях: 1) Изменение ИТ-ландшафта — замена или вывод систем из эксплуатации, что ведёт к изменению набора системных ролей (например, при переходе от кастомного решения к дистрибутивному). 2) Изменение бизнес-процессов — появление новых операций или объектов, требующих корректировки ролей в нескольких системах одновременно. 3) Изменение организационной структуры — слияние, разделение подразделений или изменение их функций, что влияет на распределение бизнес-ролей между отделами. Например, при объединении департаментов бизнес-роли могут комбинироваться ('старое-новое'), а при создании нового подразделения формируется уникальный набор ролей ('новое').

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

Рейтинг: 856

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

## [Как устроена ролевая структура в управлении проблемами?](https://cleverics.ru/digital/kb-qa/kak-ustroena-rolevaya-struktura-v-upravlenii-problemami/)

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

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

Рейтинг: 856

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

## [Какие техники используются для изучения пользовательских путешествий?](https://cleverics.ru/digital/kb-qa/kakie-tekhniki-ispolzuyutsya-dlya-izucheniya-polzovatelskikh-puteshestviy/)

Для изучения путешествий применяют картографирование клиентских путей (customer journey mapping), наблюдение за реальными сценариями использования, глубинные интервью с акцентом на контекст и мотивы, анализ поведенческих данных (например, кликов в приложении), и составление persona-клиентов. Важно фиксировать не только точки взаимодействия, но и эмоциональные реакции, барьеры и неочевидные потребности. Также используют A/B-тестирование гипотез улучшений и сбор обратной связи через инструменты типа встроенных опросов в продукте. Ограничение таких техник в том, что они отражают лишь часть реального опыта, поэтому требуется постоянная итерация.

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

Рейтинг: 856

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

## [Какие методы используются для оптимизации использования лицензий ПО в организации?](https://cleverics.ru/digital/kb-qa/kakie-metody-ispolzuyutsya-dlya-optimizatsii-ispolzovaniya-litsenziy-po-v-organizatsii/)

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

Автор: Михаил Тобурдановский

Рейтинг: 856

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

## [Можно ли совместить функциональность CMDB и AMDB в одном инструменте?](https://cleverics.ru/digital/kb-qa/mozhno-li-sovmestit-funktsionalnost-cmdb-i-amdb-v-odnom-instrumente/)

Да, функциональность CMDB и AMDB можно совместить в одном инструменте, так как данные, необходимые для экономических расчётов, уже содержатся в CMDB. CMDB позволяет отслеживать не только физические активы, но и виртуальные компоненты, а также связи влияния между ними, которые являются основой для распределения стоимости. При использовании современных ITSM-инструментариев, которые не имеют жёстких ограничений, можно обойтись без создания отдельной базы данных для экономических расчётов. Это позволяет упростить архитектуру, сократить дублирование данных и повысить точность расчётов.

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

Рейтинг: 856

Теги: ITSM, архитектура ИТ, TOGAF и IT4IT, управление ИТ-активами, ITAM, SAM, управление конфигурациями, CMDB

## [Чем ITSM-проекты отличаются в плане планирования от проектов с гибкой методологией?](https://cleverics.ru/digital/kb-qa/chem-itsm-proekty-otlichayutsya-v-plane-planirovaniya-ot-proektov-s-gibkoy-metodologiey/)

ITSM-проекты редко реализуются по гибкой методологии из-за их комплексности и масштабов конечных целей, которые затрудняют детальное дробление задач ('шинковку'). Это приводит к периодам, когда требуется участие большинства заинтересованных сторон, например, для проведения интервью или детальной проработки концептов. В отличие от гибких методологий, где изменения внедряются малыми шагами, в ITSM необходим одновременный доступ к множеству сотрудников, что усложняется их плановыми отпусками.

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

Рейтинг: 856

Теги: ITSM, общие вопросы менеджмента, управление доступом, IDM, ролевые модели, RBAC, ABAC, управление проектами, PRINCE2

## [Почему в разработке ПО часто возникает проблема с классификацией дефектов?](https://cleverics.ru/digital/kb-qa/pochemu-v-razrabotke-po-chasto-voznikaet-problema-s-klassifikatsiey-defektov/)

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

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

Рейтинг: 856

Теги: Agile и гибкие методы разработки ПО, бизнес, ценность, бизнес-заказчик, разработка ПО