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

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

## [Какие последствия имеет переход услуги из основной в дополнительную для бизнеса и пользователей?](https://cleverics.ru/digital/kb-qa/kakie-posledstviya-imeet-perekhod-uslugi-iz-osnovnoy-v-dopolnitelnuyu-dlya-biznesa-i-polzovateley/)

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

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

Рейтинг: 867

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

## [Каковы основные характеристики описания потока ценности по сравнению с классическими бизнес-процессами?](https://cleverics.ru/digital/kb-qa/kakovy-osnovnye-kharakteristiki-opisaniya-potoka-tsennosti-po-sravneniyu-s-klassicheskimi-biznes-pro/)

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

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

Рейтинг: 867

Теги: бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты

## [Почему аналогия с японскими свечами уместна для отчётов по управлению ИТ-услугами?](https://cleverics.ru/digital/kb-qa/pochemu-analogiya-s-yaponskimi-svechami-umestna-dlya-otchetov-po-upravleniyu-it-uslugami/)

Японские свечи на бирже отображают диапазон изменений цены (от минимума до максимума) за период, что напрямую сравнимо с анализом диапазона показателей качества ИТ-услуг (от минимального до среднего значения). В биржевой аналитике такие графики используются для оценки волатильности и стабильности актива. Аналогично, в ITSM диапазон между минимальным и средним показателем показывает, насколько стабильно выполняются SLA: узкий диапазон сигнализирует об однородно высоком качестве, а широкий — о наличии провалов в отдельных услугах. Это делает отчёт интуитивно понятным для руководителей, привыкших к финансовым метрикам.

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

Рейтинг: 867

Теги: ITSM, SLA, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, общие вопросы менеджмента, управление ИТ-активами, ITAM, SAM, управление уровнем услуг, SLM, экономика и финансы

## [Почему команды разработки ПО могут считать метрики бессмысленными или неуместными?](https://cleverics.ru/digital/kb-qa/pochemu-komandy-razrabotki-po-mogut-schitat-metriki-bessmyslennymi-ili-neumestnymi/)

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

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

Рейтинг: 867

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

## [Что делать, если бизнес-области и ИТ-системы имеют сложные взаимосвязи при определении границ продуктов?](https://cleverics.ru/digital/kb-qa/chto-delat-esli-biznes-oblasti-i-it-sistemy-imeyut-slozhnye-vzaimosvyazi-pri-opredelenii-granits-pro/)

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

Автор: Светлана Сапегина

Рейтинг: 867

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

## [Как можно объяснить суть концепции деления задач через пример слона?](https://cleverics.ru/digital/kb-qa/kak-mozhno-obyasnit-sut-kontseptsii-deleniya-zadach-cherez-primer-slona/)

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

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

Рейтинг: 867

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

## [Почему важна адекватная интерпретация термина DevOps при описании содержания курса?](https://cleverics.ru/digital/kb-qa/pochemu-vazhna-adekvatnaya-interpretatsiya-termina-devops-pri-opisanii-soderzhaniya-kursa/)

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

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

Рейтинг: 867

Теги: DevOps, CI/CD, обучение сотрудников, учебные курсы, тренинги, трансформация, ускорение, Time-to-Market

## [Почему сотрудники не уделяют достаточно внимания привязке инцидентов к изменениям?](https://cleverics.ru/digital/kb-qa/pochemu-sotrudniki-ne-udelyayut-dostatochno-vnimaniya-privyazke-intsidentov-k-izmeneniyam/)

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

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

Рейтинг: 867

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

## [Как определить, когда услуга становится ресурсом для другой услуги?](https://cleverics.ru/digital/kb-qa/kak-opredelit-kogda-usluga-stanovitsya-resursom-dlya-drugoy-uslugi/)

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

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

Рейтинг: 867

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

## [Как оценить экономический эффект от мер по повышению доступности ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kak-otsenit-ekonomicheskiy-effekt-ot-mer-po-povysheniyu-dostupnosti-it-uslug/)

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

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

Рейтинг: 867

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