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

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

## [Какие ключевые компетенции необходимы для специалиста BRM?](https://cleverics.ru/digital/kb-qa/kakie-klyuchevye-kompetentsii-neobkhodimy-dlya-spetsialista-brm/)

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

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

Рейтинг: 1047

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

## [Почему модель Value chain недостаточно подходит для описания внутренних ИТ-отношений в компании?](https://cleverics.ru/digital/kb-qa/pochemu-model-value-chain-nedostatochno-podkhodit-dlya-opisaniya-vnutrennikh-it-otnosheniy-v-kompani/)

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

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

Рейтинг: 1047

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

## [Почему важно учитывать получателя при составлении делового письма?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-uchityvat-poluchatelya-pri-sostavlenii-delovogo-pisma/)

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

Автор: Андрей Носов

Рейтинг: 1047

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

## [Почему компании часто выбирают комбинацию нескольких способов контакта с первой линией поддержки?](https://cleverics.ru/digital/kb-qa/pochemu-kompanii-chasto-vybirayut-kombinatsiyu-neskolkikh-sposobov-kontakta-s-pervoy-liniey-podderzh/)

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

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

Рейтинг: 1047

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

## [Какова основная идея ITIL 4 по сравнению с предыдущими версиями?](https://cleverics.ru/digital/kb-qa/kakova-osnovnaya-ideya-itil-4-po-sravneniyu-s-predydushchimi-versiyami/)

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

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

Рейтинг: 1047

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

## [Почему первая линия поддержки часто не справляется с поддержкой прикладного ПО в ITSM?](https://cleverics.ru/digital/kb-qa/pochemu-pervaya-liniya-podderzhki-chasto-ne-spravlyaetsya-s-podderzhkoy-prikladnogo-po-v-itsm/)

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

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

Рейтинг: 1047

Теги: ITSM, поддержка пользователей, 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, где количество задач определяется объемом спринта.

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

Рейтинг: 1047

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

## [Почему использование термина «проблема» в бытовом смысле может привести к путанице в ITIL?](https://cleverics.ru/digital/kb-qa/pochemu-ispolzovanie-termina-problema-v-bytovom-smysle-mozhet-privesti-k-putanitse-v-itil/)

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

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

Рейтинг: 1047

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

## [Какие основные ошибки допускаются при формировании потоков ценности?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-oshibki-dopuskayutsya-pri-formirovanii-potokov-tsennosti/)

Основные ошибки при формировании потоков ценности включают: 1) Попытку описать всю ценность продукта одним потоком даже для сложных продуктов; 2) Фокусировку на внутренних процессах компании вместо ценности для потребителя при определении потоков; 3) Создание одного универсального бэклога, игнорируя различия в природе создаваемой ценности; 4) Неправильное определение границ потока, когда один поток отвечает за принципиально разные виды ценности; 5) Игнорирование необходимости информационного взаимодействия между потоками; 6) Попытки измерять разные по природе потоки одинаковыми показателями; 7) Непредусмотрение механизма разрешения конфликтов между потоками за ресурсы. Эти ошибки приводят к неэффективному управлению, конфликтам и недостаточной фокусировке на создании реальной ценности для потребителей.

Автор: Андрей Труфанов

Рейтинг: 1047

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

## [Какие основные аспекты управления проектами определены в методологии PRINCE2®?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-aspekty-upravleniya-proektami-opredeleny-v-metodologii-prince2/)

Методология PRINCE2® определяет шесть основных аспектов управления проектами: Сроки (Timescales), Затраты (Costs), Объем работ (охват), Качество (Quality), Выгоды (Benefits) и Риск (Risk). Эти аспекты представляют собой параметры, которые необходимо контролировать в рамках проектного управления, и образуют взаимосвязанную систему, где изменение одного из параметров может повлиять на другие.

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

Рейтинг: 1046

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