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

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

## [Какие технические решения используются для реализации машинного обучения в IT-поддержке?](https://cleverics.ru/digital/kb-qa/kakie-tekhnicheskie-resheniya-ispolzuyutsya-dlya-realizatsii-mashinnogo-obucheniya-v-it-podderzhke/)

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

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

Рейтинг: 154

Теги: AI, ML, LLM, ИИ, машинное обучение, ITSM, обучение сотрудников, учебные курсы, тренинги, поддержка пользователей, Service Desk, Help Desk

## [Что такое «спагетти-карта» в контексте процессного майнинга и как с ней бороться?](https://cleverics.ru/digital/kb-qa/chto-takoe-spagetti-karta-v-kontekste-protsessnogo-mayninga-i-kak-s-ney-borotsya/)

«Спагетти-карта» — это результат визуализации процесса, при котором на схеме отображается слишком большое количество связей и переходов между узлами, что делает невозможным выявление структуры, закономерностей и проблемных областей. Такая карта возникает из-за большого объёма данных и множества различных маршрутов, по которым проходят объекты. Для борьбы со «спагетти-картой» рекомендуется использовать алгоритмы машинного обучения, которые позволяют: сузить область анализа, выделив наиболее значимые параметры и маршруты; выполнить кластеризацию объектов, группируя обращения с похожими характеристиками обработки; выявить ключевые признаки, влияющие на результат процесса, и сосредоточить анализ на них. Таким образом, машинное обучение помогает перейти от хаотичной визуализации к целенаправленному анализу конкретных проблемных областей.

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

Рейтинг: 151

Теги: AI, ML, LLM, ИИ, машинное обучение, обучение сотрудников, учебные курсы, тренинги, управление запросами на обслуживание

## [Как системная структура объясняет проблему низкой доли инцидентов, связанных с открытыми проблемами, и её влияние на риски?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-intsidentov-svyazannykh-s-otkrytymi-problem/)

Системная структура объясняет проблему низкой доли инцидентов, связанных с открытыми проблемами, и её влияние на риски через эффективность «лаборатории».  Механизм: 1. Доля инцидентов, связанных с открытыми проблемами, характеризует, насколько эффективно процесс управления проблемами выявляет и регистрирует корневые причины инцидентов. 2. Низкая доля означает, что многие инциденты не связываются с известными проблемами. 3. Это влияет на риски:    - Инциденты решаются без использования стандартных решений — повышается вероятность ошибок.    - Инциденты повторяются — пользователи страдают от одних и тех же проблем.    - MTRS растёт — время восстановления увеличивается.    - Инциденты могут эскалироваться в критичные — TMR растёт.    - Пользователи разочарованы качеством поддержки. 4. Высокие риски, в свою очередь:    - Увеличивают финансовые потери.    - Снижают удовлетворённость пользователей.    - Усиливают давление бизнеса на ИТ.    - Формируют разрушительный цикл.  Факторы, влияющие на низкую долю:  1. **Недостаточный анализ инцидентов.** Инциденты закрываются без анализа корневой причины. 2. **Недостаточные ресурсы управления проблемами.** Аналитики не успевают. 3. **Отсутствие интеграции.** Система обработки инцидентов не связана с системой управления проблемами. 4. **Недостаточная квалификация.** Аналитики не обладают навыками. 5. **Отсутствие стимулов.** KPI фокусируются на MTRS, а не на связывании инцидентов с проблемами.  Системная структура показывает, что доля инцидентов, связанных с открытыми проблемами, — это индикатор эффективности «лаборатории» и фактор, напрямую влияющий на риски. Улучшение требует улучшения анализа инцидентов, выделения ресурсов на управление проблемами и развития интеграции между процессами.

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

Рейтинг: 140

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

## [Какова роль обучения персонала в применении DevOps?](https://cleverics.ru/digital/kb-qa/kakova-rol-obucheniya-personala-v-primenenii-devops/)

Необходимо не просто обучить, а именно постоянно обучать персонал, а также создать условия и механизмы обмена знаниями и опытом. Эти механизмы следует тестировать: работающие — поощрять, неработающие — убирать и заменять новыми. Нельзя допускать перекосов в сторону исключительно технических аспектов (например, только построение конвейера развёртывания). Следует уделять соизмеримое внимание идеологическим аспектам DevOps, созданию новой культуры организации и выполнения работ в ИТ.

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

Рейтинг: 134

Теги: DevOps, CI/CD, обучение сотрудников, учебные курсы, тренинги, общие вопросы менеджмента, управление знаниями, управление процессами, ИТ-процессы, управление релизами

## [Как измерить повторное использование знаний по поддержке?](https://cleverics.ru/digital/kb-qa/kak-izmerit-povtornoe-ispolzovanie-znaniy-po-podderzhke/)

Повторное использование знаний по поддержке измеряется показателем Percentage of Solutions Reused (PSR): PSR = K / N, где K — количество инцидентов и запросов, решённых с применением базы знаний, N — общее количество инцидентов и запросов, решённых за отчётный период. Для расчёта этого показателя ITSM-система должна уметь связывать инцидент или запрос со статьёй базы знаний, применённой при решении. На практике многие специалисты применяют известные решения без ссылок на базу знаний, занижая значение показателя. Для стимулирования использования ссылок можно, например, обеспечить подстановку в инцидент готового описания решения при ссылке на базу знаний — поскольку описывать решения ИТ-специалисты не любят, этой возможностью пользуются охотно, что даёт более точные значения PSR.

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

Рейтинг: 130

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

## [Как системная структура объясняет проблему низкой доли обращений, решённых с применением базы знаний, и её влияние на затраты?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-obrashcheniy-reshennykh-s-primeneniem-bazy/)

Системная структура объясняет проблему низкой доли обращений, решённых с применением базы знаний (PSR — Problem Solution Rate), и её влияние на затраты через взаимосвязь «конвейера» и «лаборатории».  Механизм: 1. PSR характеризует, какая доля обращений решается с применением базы знаний. 2. Низкая доля означает, что сотрудники не используют базу знаний при решении обращений. 3. Это приводит к тому, что:    - Каждое обращение решается «с нуля» — сотрудники тратят время на диагностику и поиск решения.    - Увеличивается Processing Time — решение без базы знаний занимает больше времени.    - Увеличиваются затраты — больше ресурсов тратится на обработку каждого обращения.    - Снижается продуктивность — сотрудники не используют накопленный опыт.    - Увеличивается нагрузка на вторую и третью линии — первая линия не имеет готовых решений. 4. Низкая доля, в свою очередь:    - Увеличивает Cost per ticket.    - Увеличивает MTRS.    - Снижает удовлетворённость пользователей.  Факторы, влияющие на низкую долю:  1. **Недостаточное содержание базы знаний.** Мало статей, они устарели или не покрывают типичные ситуации. 2. **Низкое качество статей.** Статьи написаны непонятно или не соответствуют реальным сценариям. 3. **Неудобный поиск.** Сотрудники не могут быстро найти нужную статью. 4. **Недостаточная интеграция.** База знаний не интегрирована с системой обработки инцидентов. 5. **Отсутствие стимулов.** Сотрудники не мотивированы использовать базу знаний.  Системная структура показывает, что PSR — это индикатор эффективности «лаборатории» и её интеграции с «конвейером». Улучшение PSR требует развития базы знаний, улучшения инструментов поиска и интеграции, обучения и мотивации сотрудников. Высокий PSR напрямую снижает затраты на управление инцидентами.

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

Рейтинг: 130

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

## [Как системная структура объясняет проблему низкой доли изменений, документированных в соответствии с требованиями, и её влияние на удовлетворённость пользователей?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-izmeneniy-dokumentirovannykh-v-sootvetstvii/)

Системная структура объясняет проблему низкой доли изменений, документированных в соответствии с требованиями, и её влияние на удовлетворённость пользователей через качество данных и его влияние на «лабораторию».  Механизм: 1. Качество документирования изменений — это ключевой фактор, влияющий на эффективность «лаборатории». 2. Низкая доля изменений, документированных в соответствии с требованиями, означает, что данные о изменениях неполные или некорректные. 3. Это влияет на удовлетворённость пользователей:    - PIR неэффективен — уроки не извлекаются, ошибки повторяются.    - Управление проблемами неэффективно — корневые причины не выявляются, инциденты повторяются.    - Стандартные решения не создаются — инциденты решаются индивидуально, MTRS растёт.    - База знаний не пополняется — сотрудники не имеют доступа к опыту. 4. Низкая удовлетворённость, в свою очередь:    - Усиливает давление бизнеса на ИТ.    - Приводит к жалобам и эскалациям.    - Снижает доверие к ИТ.    - Формирует негативное восприятие ИТ-услуг.  Факторы, влияющие на низкое качество документирования:  1. **Сложность процессов.** Обременительные требования демотивируют. 2. **Отсутствие автоматизации.** Ручной ввод данных. 3. **Непонимание ценности.** Сотрудники не видят пользы. 4. **Давление сроков.** Спешка приводит к формальному документированию. 5. **Отсутствие контроля.** Качество не проверяется.  Системная структура показывает, что качество документирования — это критический фактор удовлетворённости пользователей. Инвестиции в качество документирования окупаются через улучшение «лаборатории» и, как следствие, улучшение качества изменений, снижение количества инцидентов и повышение удовлетворённости пользователей.

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

Рейтинг: 130

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

## [Как системная структура объясняет проблему низкой доли изменений, реализованных с первой попытки, и её влияние на риски?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-izmeneniy-realizovannykh-s-pervoy-popytki-i/)

Системная структура «конвейера» объясняет проблему низкой доли изменений, реализованных с первой попытки (FTI), и её влияние на риски (Risks).  Механизм: 1. FTI характеризует качество выполнения работы — какая доля изменений реализована без ошибок с первой попытки. 2. Низкий FTI означает, что значительная часть изменений требует переделок. 3. Это влияет на риски:    - Переделки увеличивают вероятность новых ошибок — каждая переделка — это возможность допустить новую ошибку.    - Ошибки в изменениях вызывают инциденты — TMR растёт.    - Неполная реализация требований означает, что бизнес-требования не реализованы или реализованы не в полном объёме.    - Повторные изменения увеличивают вероятность конфликтов с другими изменениями. 4. Высокие риски, в свою очередь:    - Увеличивают финансовые потери от простоев.    - Снижают удовлетворённость пользователей.    - Усиливают давление бизнеса на ИТ.    - Формируют разрушительный цикл.  Факторы, влияющие на низкий FTI:  1. **Недостаточное планирование.** Изменения выполняются без adequate анализа. 2. **Недостаточное тестирование.** Изменения не тестируются должным образом. 3. **Недостаточная квалификация.** Исполнители не обладают необходимыми навыками. 4. **Неполная информация.** Отсутствие данных о конфигурации и зависимостях. 5. **Давление сроков.** Спешка приводит к ошибкам.  Системная структура показывает, что FTI — это не просто метрика качества, а фактор, напрямую влияющий на риски. Улучшение FTI требует улучшения планирования, тестирования, квалификации и управления давлением.

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

Рейтинг: 130

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

## [Как системная структура объясняет проблему низкой своевременности реализации изменений и её влияние на риски?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-svoevremennosti-realizatsii-izmeneniy-i-ee-vliya/)

Системная структура «конвейера» объясняет проблему низкой своевременности реализации изменений (TPI) и её влияние на риски (Risks).  Механизм: 1. TPI характеризует, насколько процесс справляется с соблюдением временных нормативов. 2. Низкая своевременность означает, что изменения реализуются позже ожидаемых сроков. 3. Это влияет на риски:    - Задержка изменений может привести к тому, что критичные обновления безопасности не применяются вовремя — увеличиваются риски безопасности.    - Задержка изменений может привести к тому, что бизнес-возможности упущены — финансовые потери.    - Задержка изменений может привести к тому, что инфраструктура устаревает — увеличиваются риски отказов.    - Давление бизнеса из-за задержек может привести к выполнению изменений «в обход» процесса — теневые изменения увеличивают риски. 4. Высокие риски, в свою очередь:    - Увеличивают финансовые потери.    - Снижают удовлетворённость пользователей.    - Усиливают давление бизнеса на ИТ.    - Формируют разрушительный цикл.  Факторы, влияющие на низкую своевременность:  1. **Рост бэклога.** Много изменений в очереди. 2. **Нехватка ресурсов.** Недостаточно персонала. 3. **Низкая продуктивность.** Недостаточная квалификация, отсутствие инструментов. 4. **Повторно выполняемая работа.** Ошибки приводят к переделкам. 5. **Внеочередная работа.** Экстренные изменения отвлекают ресурсы.  Системная структура показывает, что своевременность — это не просто «операционная метрика», а фактор, напрямую влияющий на риски. Улучшение своевременности требует комплексного подхода: управление спросом, увеличение ресурсов, повышение продуктивности, улучшение качества, контроль внеочередной работы.

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

Рейтинг: 130

Теги: DevOps, CI/CD, архитектура ИТ, TOGAF и IT4IT, безопасность, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, обучение сотрудников, учебные курсы, тренинги, общие вопросы менеджмента, поддержка пользователей, Service Desk, Help Desk, постоянное улучшение, совершенствование, CSI, PDCA, управление изменениями, управление конфигурациями, CMDB, управление рисками, эффективность, оптимизация

## [Как системная структура объясняет проблему низкой доли обращений, решённых с применением базы знаний, и её влияние на риски?](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 требует развития базы знаний, улучшения инструментов поиска и интеграции, обучения и мотивации сотрудников.

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

Рейтинг: 130

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