# Бесплатная экспертная база знаний по управлению ИТ Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего. Только сведения от консультантов и тренеров Cleverics. Включает ответы на **несколько тысяч вопросов** из **сотен источников**, а также детальный глоссарий с примерами, объяснениями и нюансами ## [Как системная структура объясняет проблему низкой доли обращений, решённых с применением базы знаний, и её влияние на риски?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-obrashcheniy-reshennykh-s-primeneniem-bazy/) Системная структура объясняет проблему низкой доли обращений, решённых с применением базы знаний (PSR), и её влияние на риски. Механизм: 1. PSR характеризует, какая доля обращений решается с применением базы знаний. 2. Низкая доля означает, что сотрудники не используют базу знаний при решении обращений. 3. Это влияет на риски: - Каждое обращение решается «с нуля» — повышается вероятность ошибок. - Качество решений снижается — сотрудники могут применять неоптимальные или неправильные решения. - MTRS растёт — время восстановления увеличивается. - Инциденты эскалируются на более дорогие уровни поддержки — повышается вероятность ошибок. - Инциденты повторяются — пользователи страдают от одних и тех же проблем. 4. Высокие риски, в свою очередь: - Увеличивают финансовые потери. - Снижают удовлетворённость пользователей. - Усиливают давление бизнеса на ИТ. - Формируют разрушительный цикл. Факторы, влияющие на низкую долю: 1. **Недостаточное содержание базы знаний.** Мало статей, они устарели. 2. **Низкое качество статей.** Статьи написаны непонятно. 3. **Неудобный поиск.** Сотрудники не могут быстро найти нужную статью. 4. **Недостаточная интеграция.** База знаний не интегрирована с системой обработки инцидентов. 5. **Отсутствие стимулов.** Сотрудники не мотивированы использовать базу знаний. Системная структура показывает, что PSR — это индикатор эффективности «лаборатории» и фактор, напрямую влияющий на риски. Улучшение PSR требует развития базы знаний, улучшения инструментов поиска и интеграции, обучения и мотивации сотрудников. Автор: Павел Дёмин, Дмитрий Исайченко Рейтинг: 60 Теги: бизнес, ценность, бизнес-заказчик, мотивация персонала, стимулирование, обучение сотрудников, учебные курсы, тренинги, поддержка пользователей, Service Desk, Help Desk, постоянное улучшение, совершенствование, CSI, PDCA, управление запросами на обслуживание, управление знаниями, управление инцидентами, управление рисками, эффективность, оптимизация ## [Какие технические решения используются для реализации машинного обучения в IT-поддержке?](https://cleverics.ru/digital/kb-qa/kakie-tekhnicheskie-resheniya-ispolzuyutsya-dlya-realizatsii-mashinnogo-obucheniya-v-it-podderzhke/) Для реализации машинного обучения в IT-поддержке могут использоваться как встроенные модули в ITSM-системах, так и внешние решения. Некоторые компании разрабатывают собственные решения на базе библиотек машинного обучения, таких как TensorFlow или FastText. Встроенные модули существуют у ряда вендоров ITSM-систем, однако при их использовании возникает вопрос гибкости настройки: для достижения высокой точности необходима тонкая настройка, включая очистку данных не только на этапе обучения, но и на этапе эксплуатации, а также специфическую настройку параметров алгоритма. Внешние модули обеспечивают большую гибкость, но требуют интеграции с ITSM-системой. Выбор между встроенным и внешним решением зависит от требований к гибкости настройки и готовности к интеграционным работам. Автор: Евгений Шилов Рейтинг: 58 Теги: AI, ML, LLM, ИИ, машинное обучение, ITSM, обучение сотрудников, учебные курсы, тренинги, поддержка пользователей, Service Desk, Help Desk ## [Какие риски связаны с прохождением «мусорного» обучения по ITIL?](https://cleverics.ru/digital/kb-qa/kakie-riski-svyazany-s-prokhozhdeniem-musornogo-obucheniya-po-itil/) «Мусорное обучение» — это курсы, проводимые непонятно кем (возможно, фрилансерами), с неясным содержанием, хотя в названиях могут использоваться слова из библиотеки ITIL. Риски такого обучения максимальны: слушатель с высокой вероятностью не получит никаких релевантных знаний, поскольку курсы фактически не имеют отношения к ITIL. Содержание таких курсов непредсказуемо, квалификация преподавателей не подтверждена, а сертификаты по итогам невозможны. Автор: Павел Дёмин Рейтинг: 52 Теги: ITIL, обучение сотрудников, учебные курсы, тренинги, управление знаниями, управление рисками ## [Какие стандарты и своды знаний содержат формулировки назначений ИТ-процессов?](https://cleverics.ru/digital/kb-qa/kakie-standarty-i-svody-znaniy-soderzhat-formulirovki-naznacheniy-it-protsessov/) Формулировки назначений для ИТ-процессов можно найти в стандартах и сводах знаний, предлагающих процессные модели, таких как COBIT, ITIL и ISO/IEC 20000. Назначение процесса, как правило, универсально и мало меняется от компании к компании. Эти стандарты предоставляют базовые формулировки, которые могут быть адаптированы для конкретной организации при проектировании системы управления. Автор: Павел Дёмин, Дмитрий Исайченко Рейтинг: 50 Теги: COBIT, ISO 20000, ITIL, обучение сотрудников, учебные курсы, тренинги, управление знаниями, управление процессами, ИТ-процессы ## [Как системная структура объясняет проблему низкой доли обращений, решённых с применением базы знаний, и её влияние на MTRS?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-obrashcheniy-reshennykh-s-primeneniem-bazy/) Системная структура объясняет проблему низкой доли обращений, решённых с применением базы знаний (PSR — Problem Solution Rate), и её влияние на MTRS (Mean Time to Restore Service). Механизм: 1. PSR характеризует, какая доля обращений решается с применением базы знаний. 2. Низкая доля означает, что сотрудники не используют базу знаний при решении обращений. 3. Это влияет на MTRS: - Каждое обращение решается «с нуля» — сотрудники тратят время на диагностику и поиск решения. - Время решения увеличивается — MTRS растёт. - Сотрудники могут применять неоптимальные или неправильные решения, что увеличивает время восстановления. - Инциденты эскалируются на более дорогие уровни поддержки, что увеличивает время обработки. 4. Высокий MTRS, в свою очередь: - Увеличивает время простоя сервисов. - Увеличивает финансовые потери. - Снижает удовлетворённость пользователей. Факторы, влияющие на низкую долю: 1. **Недостаточное содержание базы знаний.** Мало статей, они устарели. 2. **Низкое качество статей.** Статьи написаны непонятно. 3. **Неудобный поиск.** Сотрудники не могут быстро найти нужную статью. 4. **Недостаточная интеграция.** База знаний не интегрирована с системой обработки инцидентов. 5. **Отсутствие стимулов.** Сотрудники не мотивированы использовать базу знаний. Системная структура показывает, что PSR — это индикатор эффективности «лаборатории» и фактор, напрямую влияющий на MTRS. Улучшение PSR требует развития базы знаний, улучшения инструментов поиска и интеграции, обучения и мотивации сотрудников. Высокий PSR напрямую снижает MTRS. Автор: Павел Дёмин, Дмитрий Исайченко Рейтинг: 50 Теги: мотивация персонала, стимулирование, обучение сотрудников, учебные курсы, тренинги, поддержка пользователей, Service Desk, Help Desk, постоянное улучшение, совершенствование, CSI, PDCA, управление запросами на обслуживание, управление знаниями, управление инцидентами, эффективность, оптимизация ## [Как системная структура объясняет проблему низкой доли изменений, реализованных с первой попытки, и её влияние на удовлетворённость пользователей?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-izmeneniy-realizovannykh-s-pervoy-popytki-i/) Системная структура «конвейера» объясняет проблему низкой доли изменений, реализованных с первой попытки (FTI — First Time Implementation), и её влияние на удовлетворённость пользователей. Механизм: 1. FTI характеризует качество выполнения работы — какая доля изменений реализована без ошибок с первой попытки. 2. Низкий FTI означает, что значительная часть изменений требует переделок. 3. Это влияет на удовлетворённость пользователей: - Переделки задерживают реализацию изменений — пользователи долго ждут результатов. - Ошибки в изменениях могут вызвать инциденты — пользователи страдают от простоев. - Неполная реализация требований — пользователи не получают ожидаемого функционала. - Повторные изменения вызывают недоверие — пользователи разочарованы качеством ИТ. 4. Низкая удовлетворённость, в свою очередь: - Усиливает давление бизнеса на ИТ. - Приводит к жалобам и эскалациям. - Снижает доверие к ИТ. - Формирует негативное восприятие ИТ-услуг. Факторы, влияющие на низкий FTI: 1. **Недостаточное планирование.** Изменения выполняются без adequate анализа. 2. **Недостаточное тестирование.** Изменения не тестируются должным образом. 3. **Недостаточная квалификация.** Исполнители не обладают необходимыми навыками. 4. **Неполная информация.** Отсутствие данных о конфигурации и зависимостях. 5. **Давление сроков.** Спешка приводит к ошибкам. Системная структура показывает, что FTI — это не просто метрика качества, а фактор, напрямую влияющий на удовлетворённость пользователей. Улучшение FTI требует улучшения планирования, тестирования, квалификации и управления давлением. Автор: Павел Дёмин, Дмитрий Исайченко Рейтинг: 50 Теги: DevOps, CI/CD, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, обучение сотрудников, учебные курсы, тренинги, общие вопросы менеджмента, поддержка пользователей, Service Desk, Help Desk, постоянное улучшение, совершенствование, CSI, PDCA, управление инцидентами, эффективность, оптимизация ## [Как системная структура объясняет проблему низкой доли инцидентов, связанных с открытыми проблемами, и её влияние на удовлетворённость пользователей?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-intsidentov-svyazannykh-s-otkrytymi-problem/) Системная структура объясняет проблему низкой доли инцидентов, связанных с открытыми проблемами, и её влияние на удовлетворённость пользователей через эффективность «лаборатории». Механизм: 1. Доля инцидентов, связанных с открытыми проблемами, характеризует, насколько эффективно процесс управления проблемами выявляет и регистрирует корневые причины инцидентов. 2. Низкая доля означает, что многие инциденты не связываются с известными проблемами. 3. Это влияет на удовлетворённость пользователей: - Инциденты решаются без использования стандартных решений — MTRS растёт. - Инциденты повторяются — пользователи страдают от одних и тех же проблем. - Пользователи разочарованы качеством поддержки. 4. Низкая удовлетворённость, в свою очередь: - Усиливает давление бизнеса на ИТ. - Приводит к жалобам и эскалациям. - Снижает доверие к ИТ. - Формирует негативное восприятие ИТ-услуг. Факторы, влияющие на низкую долю: 1. **Недостаточный анализ инцидентов.** Инциденты закрываются без анализа корневой причины. 2. **Недостаточные ресурсы управления проблемами.** Аналитики не успевают. 3. **Отсутствие интеграции.** Система обработки инцидентов не связана с системой управления проблемами. 4. **Недостаточная квалификация.** Аналитики не обладают навыками. 5. **Отсутствие стимулов.** KPI фокусируются на MTRS, а не на связывании инцидентов с проблемами. Системная структура показывает, что доля инцидентов, связанных с открытыми проблемами, — это индикатор эффективности «лаборатории» и фактор, напрямую влияющий на удовлетворённость пользователей. Улучшение требует улучшения анализа инцидентов, выделения ресурсов на управление проблемами и развития интеграции между процессами. Автор: Павел Дёмин, Дмитрий Исайченко Рейтинг: 50 Теги: бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, мотивация персонала, стимулирование, обучение сотрудников, учебные курсы, тренинги, общие вопросы менеджмента, поддержка пользователей, Service Desk, Help Desk, постоянное улучшение, совершенствование, CSI, PDCA, управление инцидентами, управление проблемами, управление процессами, ИТ-процессы, эффективность, оптимизация ## [Как системная структура объясняет проблему низкой доли обращений, решённых с применением базы знаний, и её влияние на удовлетворённость пользователей?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-obrashcheniy-reshennykh-s-primeneniem-bazy/) Системная структура объясняет проблему низкой доли обращений, решённых с применением базы знаний (PSR), и её влияние на удовлетворённость пользователей. Механизм: 1. PSR характеризует, какая доля обращений решается с применением базы знаний. 2. Низкая доля означает, что сотрудники не используют базу знаний при решении обращений. 3. Это влияет на удовлетворённость пользователей: - Каждое обращение решается «с нуля» — MTRS растёт. - Качество решений снижается — сотрудники могут применять неоптимальные решения. - Инциденты эскалируются на более дорогие уровни поддержки — время обработки увеличивается. - Пользователи разочарованы скоростью и качеством поддержки. 4. Низкая удовлетворённость, в свою очередь: - Усиливает давление бизнеса на ИТ. - Приводит к жалобам и эскалациям. - Снижает доверие к ИТ. - Формирует негативное восприятие ИТ-услуг. Факторы, влияющие на низкую долю: 1. **Недостаточное содержание базы знаний.** Мало статей, они устарели. 2. **Низкое качество статей.** Статьи написаны непонятно. 3. **Неудобный поиск.** Сотрудники не могут быстро найти нужную статью. 4. **Недостаточная интеграция.** База знаний не интегрирована с системой обработки инцидентов. 5. **Отсутствие стимулов.** Сотрудники не мотивированы использовать базу знаний. Системная структура показывает, что PSR — это индикатор эффективности «лаборатории» и фактор, напрямую влияющий на удовлетворённость пользователей. Улучшение PSR требует развития базы знаний, улучшения инструментов поиска и интеграции, обучения и мотивации сотрудников. Автор: Павел Дёмин, Дмитрий Исайченко Рейтинг: 50 Теги: бизнес, ценность, бизнес-заказчик, мотивация персонала, стимулирование, обучение сотрудников, учебные курсы, тренинги, общие вопросы менеджмента, поддержка пользователей, Service Desk, Help Desk, постоянное улучшение, совершенствование, CSI, PDCA, управление запросами на обслуживание, управление знаниями, управление инцидентами, эффективность, оптимизация