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

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

## [Что представляет собой система управления конфигурациями (CMS) в контексте ITIL?](https://cleverics.ru/digital/kb-qa/chto-predstavlyaet-soboy-sistema-upravleniya-konfiguratsiyami-cms-v-kontekste-itil/)

Система Управления Конфигурациями (Configuration Management System, CMS) определяется как набор инструментов, данных и информации, которые используются для поддержки процесса управления сервисными активами и конфигурациями. CMS является частью общей системы управления знаниями по услугам и включает в себя инструменты для сбора, хранения, управления, обновления, анализа и представления информации обо всех конфигурационных единицах и их взаимоотношениях. CMS может также содержать информацию об инцидентах, проблемах, известных ошибках, изменениях и релизах. Кроме того, CMS поддерживается процессом управления сервисными активами и конфигурациями и используется всеми процессами управления ИТ-услугами.

Автор: Игорь Гутник

Рейтинг: 1169

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

## [Какие данные должны быть включены в информацию о major-инциденте, чтобы первая линия поддержки могла эффективно информировать пользователей?](https://cleverics.ru/digital/kb-qa/kakie-dannye-dolzhny-byt-vklyucheny-v-informatsiyu-o-major-intsidente-chtoby-pervaya-liniya-podderzh/)

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

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

Рейтинг: 1169

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

## [Какие преимущества имеет модель RBAC перед другими моделями управления доступом?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-imeet-model-rbac-pered-drugimi-modelyami-upravleniya-dostupom/)

Модель RBAC имеет ряд преимуществ перед другими моделями управления доступом, такими как DAC (Discretionary Access Control) и MAC (Mandatory Access Control). Во-первых, RBAC обеспечивает более высокую масштабируемость, что особенно важно для организаций с большим количеством сотрудников. Во-вторых, она повышает прозрачность управления доступом, так как права привязаны к ролям, соответствующим должностям и бизнес-процессам. В-третьих, RBAC обеспечивает легкость администрирования - добавление или удаление пользователей не требует перенастройки всего механизма доступа, достаточно назначить или отозвать соответствующую роль. Также RBAC позволяет лучше соблюдать принцип разделения обязанностей, что повышает информационную безопасность организации.

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

Рейтинг: 1168

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

## [Как строятся каталоги услуг в некоторых ИТ-службах?](https://cleverics.ru/digital/kb-qa/kak-stroyatsya-katalogi-uslug-v-nekotorykh-it-sluzhbakh/)

Каталоги услуг в некоторых ИТ-службах строятся на основе сущности «доступ к ресурсам». В таких каталогах услуга определяется как информационная система (программно-аппаратный комплекс), и описываются правила предоставления доступа к этой системе. Например, для учетной системы может быть указано, что доступ к ней гарантируется с определенного времени до определенного времени. При таком подходе поставщик услуг фокусируется только на предоставлении доступа к ресурсу, а то, как потребитель будет использовать этот ресурс, уже не является заботой поставщика. Это упрощает описание услуг и управление ими, особенно когда поставщик не обладает информацией о деталях деятельности потребителя или не желает в нее вникать.

Автор: Игорь Гутник

Рейтинг: 1167

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

## [Что такое бимодальные ИТ и какие преимущества они дают организации?](https://cleverics.ru/digital/kb-qa/chto-takoe-bimodalnye-it-i-kakie-preimushchestva-oni-dayut-organizatsii/)

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

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

Рейтинг: 1167

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

## [Как избежать путаницы между Output и Outcome при работе с клиентами?](https://cleverics.ru/digital/kb-qa/kak-izbezhat-putanitsy-mezhdu-output-i-outcome-pri-rabote-s-klientami/)

Чтобы избежать путаницы, необходимо постоянно фокусироваться на потребностях клиента и его целевых результатах. Следует задавать вопросы: «Какой эффект должен быть достигнут?», «Как клиент оценит успешность услуги?». Также важно внедрять в процессы измерение удовлетворённости клиентов и анализировать, как выходы влияют на конечные результаты. Необходимо помнить, что output — это инструмент, а outcome — цель.

Автор: Александр Движков

Рейтинг: 1167

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

## [Какие каналы обратной связи наиболее эффективны для пользователей?](https://cleverics.ru/digital/kb-qa/kakie-kanaly-obratnoy-svyazi-naibolee-effektivny-dlya-polzovateley/)

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

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

Рейтинг: 1166

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

## [Какие примеры emergency-изменений приводятся в ITIL?](https://cleverics.ru/digital/kb-qa/kakie-primery-emergency-izmeneniy-privodyatsya-v-itil/)

В ITIL указано два конкретных примера emergency-изменений: первое — изменение, необходимое для устранения массового инцидента, когда, например, сервис перестал обслуживать большое количество пользователей; второе — установка патча для закрытия критических уязвимостей в системе безопасности. Эти случаи требуют немедленного реагирования, так как их игнорирование приведёт к значительному ущербу для бизнеса, включая финансовые потери или репутационный риск.

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

Рейтинг: 1166

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

## [Может ли первая линия ИТ-поддержки решать все обращения, и если нет, то почему?](https://cleverics.ru/digital/kb-qa/mozhet-li-pervaya-liniya-it-podderzhki-reshat-vse-obrashcheniya-i-esli-net-to-pochemu/)

Превращение первой линии ИТ-поддержки в структуру, которая решает 99,9% всех обращений, на практике редко является оптимальным решением и может фактически перестать быть «первой линией» в традиционном понимании. Это связано с несколькими причинами: необходимостью наличия глубоких и разнообразных технических знаний у сотрудников первой линии, что делает их квалификацию и стоимость существенно выше; вероятностью возникновения сложных, нестандартных проблем, требующих специфических знаний и опыта; риском снижения качества решения сложных задач из-за расширения спектра обязанностей сотрудников; экономической нецелесообразностью использования высококвалифицированных (и более дорогих) специалистов для решения самых простых проблем. В идеале, первая линия должна решать тот объем обращений, который соответствует ее квалификации и позволяет эффективно использовать ресурсы разных уровней поддержки.

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

Рейтинг: 1166

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

## [Как организовать структуру классификатора изменений?](https://cleverics.ru/digital/kb-qa/kak-organizovat-strukturu-klassifikatora-izmeneniy/)

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

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

Рейтинг: 1166

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