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

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

## [Что такое главное различие между запросом и потребностью в контексте взаимодействия ИТ и бизнеса?](https://cleverics.ru/digital/kb-qa/chto-takoe-glavnoe-razlichie-mezhdu-zaprosom-i-potrebnostyu-v-kontekste-vzaimodeystviya-it-i-biznesa/)

Главное различие между запросом и потребностью заключается в том, что потребность - это то, что на самом деле нужно заказчику/потребителю, возможно даже неосознанное самим заказчиком. Например, бизнес может не видеть неэффективность в каких-то участках процесса или не представлять альтернативные решения. Запрос же - это конкретное выражение потребности после её осознания. То есть запрос возникает у заказчика в связи с осознанием потребности. Например, в истории с мылом постоялец хотел использовать своё мыло и попросил не класть отельное, тогда как его потребностью было комфортное проживание без лишних предметов в ванной. Бизнес-аналитик или ИТ-специалист должен уметь выявлять истинные потребности, а не просто слепо выполнять полученные запросы.

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

Рейтинг: 989

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

## [Каким образом BRM обеспечивает соответствие ИТ-стратегии бизнес-целям?](https://cleverics.ru/digital/kb-qa/kakim-obrazom-brm-obespechivaet-sootvetstvie-it-strategii-biznes-tselyam/)

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

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

Рейтинг: 989

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

## [Какие риски возникают при постоянной перегрузке сотрудников?](https://cleverics.ru/digital/kb-qa/kakie-riski-voznikayut-pri-postoyannoy-peregruzke-sotrudnikov/)

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

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

Рейтинг: 989

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

## [В чем разница между стандартными изменениями и нормальными изменениями в ITIL?](https://cleverics.ru/digital/kb-qa/v-chem-raznitsa-mezhdu-standartnymi-izmeneniyami-i-normalnymi-izmeneniyami-v-itil/)

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

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

Рейтинг: 989

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

## [Какое основное предположение делается при использовании метода расстановки приоритетов через веса инцидентов?](https://cleverics.ru/digital/kb-qa/kakoe-osnovnoe-predpolozhenie-delaetsya-pri-ispolzovanii-metoda-rasstanovki-prioritetov-cherez-vesa/)

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

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

Рейтинг: 989

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

## [Как определить, какой способ организации работы линий поддержки выбрать для конкретной организации?](https://cleverics.ru/digital/kb-qa/kak-opredelit-kakoy-sposob-organizatsii-raboty-liniy-podderzhki-vybrat-dlya-konkretnoy-organizatsii/)

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

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

Рейтинг: 989

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

## [Почему процесс Управления запросами на обслуживание (RFF) не является основным процессом для обработки запросов о статусе инцидента?](https://cleverics.ru/digital/kb-qa/pochemu-protsess-upravleniya-zaprosami-na-obsluzhivanie-rff-ne-yavlyaetsya-osnovnym-protsessom-dlya/)

Процесс Управления запросами на обслуживание (RFF) не является основным для обработки запросов о статусе инцидента потому, что ответственность за обеспечение прозрачности и коммуникацию информации о статусах инцидентов возложена на процесс Управления инцидентами (INC). Хотя RFF может использоваться в качестве канала коммуникации для передачи информации по запросу пользователя, он не несёт первичную ответственность за организацию такой коммуникации. INC должен спроектировать систему коммуникации и выбрать оптимальную комбинацию каналов (проактивные – автоматическое оповещение и реактивные – выдача информации по запросу), включая использование RFF в качестве одного из возможных механизмов. Использование RFF как основного процесса для подобных запросов приведёт к снижению ответственности INC за качество коммуникаций и, как следствие, к снижению общего качества обслуживания.

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

Рейтинг: 989

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

## [Какие альтернативы существуют для определения максимального числа параллельных задач?](https://cleverics.ru/digital/kb-qa/kakie-alternativy-sushchestvuyut-dlya-opredeleniya-maksimalnogo-chisla-parallelnykh-zadach/)

Альтернативные подходы к определению максимального числа параллельных задач включают использование эмпирических данных (например, анализ собственной продуктивности), методику Top 5-10, фокусирующуюся на самых критичных задачах, и принцип числа Миллера (7±2 элемента). Также практикуется гибкое реагирование на изменения: еженедельная оценка текущей загрузки и динамическое изменение лимитов. Некоторые применяют методы Agile, такие как Scrum, где количество задач определяется объемом спринта.

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

Рейтинг: 989

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

## [Какие преимущества дает многоступенчатый расчет интегральных показателей?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-daet-mnogostupenchatyy-raschet-integralnykh-pokazateley/)

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

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

Рейтинг: 989

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

## [В каких случаях использование RBAC наиболее оправдано и эффективно?](https://cleverics.ru/digital/kb-qa/v-kakikh-sluchayakh-ispolzovanie-rbac-naibolee-opravdano-i-effektivno/)

Использование ролевой модели управления доступом (RBAC) наиболее оправдано и эффективно в двух основных случаях. Первый случай — внедрение внутри одной информационной системы, где возможное количество комбинаций прав невелико, и управление небольшим количеством ролей не представляет сложности. На практике, RBAC является лучшей практикой при разработке приложений, серверов баз данных и операционных систем. Второй случай — в организациях, где большое количество пользователей имеют одинаковые права. Например, кассиры в банках, продавцы в розничной торговле, сотрудники бухгалтерии — в таких организационных структурах небольшое количество ролей достаточно для предоставления доступа тысячам пользователей, что делает использование RBAC очень эффективным.

Автор: Александр Омельченко

Рейтинг: 988

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