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

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

## [Какова основная идея подхода Tipu в контексте управления ИТ-услугами?](https://cleverics.ru/digital/kb-qa/kakova-osnovnaya-ideya-podkhoda-tipu-v-kontekste-upravleniya-it-uslugami/)

Основная идея подхода Tipu заключается в том, что Continual Service Improvement (CSI) нужно организовывать не после внедрения базовых процессов управления ИТ-услугами, а с самого начала, в рамках первых инициатив. Это позволяет постепенно и органично «достраивать» систему управления, отталкиваясь от реальных задач заказчика и используя набор процессных элементов, которые можно внедрить в относительно короткие сроки. Подход предполагает создание не идеальных процессов, а работающих решений с последующим наращиванием уровня зрелости через интегрированный CSI подход.

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

Рейтинг: 834

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

## [Какие распространенные ошибки возникают при измерении доступности?](https://cleverics.ru/digital/kb-qa/kakie-rasprostranennye-oshibki-voznikayut-pri-izmerenii-dostupnosti/)

Распространенные ошибки включают: использование длительности инцидентов как интервалов недоступности (не все инциденты связаны с недоступностью), усреднение доступности для отдельных пользователей (может скрывать влияние простоев на небольшие группы), отказ от измерения доступности на конечной точке потребления (нельзя убедиться в реальном доступе пользователя), и использование примитивных средств мониторинга (например, проверка доступности через ping, которая не отражает возможности выполнения критических операций).

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

Рейтинг: 834

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

## [Почему достижение выгод (Benefits) не может быть ответственностью только проектной команды?](https://cleverics.ru/digital/kb-qa/pochemu-dostizhenie-vygod-benefits-ne-mozhet-byt-otvetstvennostyu-tolko-proektnoy-komandy/)

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

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

Рейтинг: 834

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

## [Как адаптировать модель AARM для оценки внутренних inhouse продуктов?](https://cleverics.ru/digital/kb-qa/kak-adaptirovat-model-aarm-dlya-otsenki-vnutrennikh-inhouse-produktov/)

Для адаптации модели AARM к внутренним inhouse продуктам необходимо внести следующие корректировки: Acquisition (привлечение) - измерять не количество новых пользователей, а успешность продвижения продукта внутри организации, степень вовлечения ключевых стейкхолдеров и одобрение руководства; Activation (активация) - фокусироваться на скорости и простоте внедрения продукта в рабочие процессы, времени до первой полезной реализации; Retention (удержание) - оценивать стабильность использования продукта во времени, уровень удовлетворенности внутренних клиентов, продолжительность контрактов или обязательств по использованию; Monetization (монетизация) - заменить на измерение улучшения бизнес-процессов, снижения затрат или повышения эффективности. Важно создать отдельные метрики для различных ролей (владельцы процессов, конечные пользователи, руководство) и учитывать, что спонсоры и пользователи могут иметь разные интересы. Также необходимо уделять особое внимание метрике TTV (Time-To-Value), так как для внутренних продуктов быстрое достижение ценности критично для дальнейшего поддержки и развития решения.

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

Рейтинг: 834

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

## [Почему рефакторинг кода может не привести к ожидаемому результату?](https://cleverics.ru/digital/kb-qa/pochemu-refaktoring-koda-mozhet-ne-privesti-k-ozhidaemomu-rezultatu/)

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

Автор: Сандра Урядова

Рейтинг: 834

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

## [Как учитывать изменения организационной структуры при обновлении ролевой модели?](https://cleverics.ru/digital/kb-qa/kak-uchityvat-izmeneniya-organizatsionnoy-struktury-pri-obnovlenii-rolevoy-modeli/)

При изменениях структуры (слияние, разделение подразделений) нужно: 1) Определить тип изменений: 'старое-старое' (функции не меняются), 'старое-новое' (добавляются новые функции) или 'новое' (полностью новый набор функций). 2) Для 'старое-новое' комбинировать бизнес-роли основного и сливаемого подразделений (например, роли из объединяемых департаментов маркетинга и PR объединяются в единую модель). 3) Для 'новое' формировать уникальный набор ролей с нуля, если подразделение создаётся под новые задачи. Ключевой этап — перераспределение ролей между сотрудниками, учитывая новые зоны ответственности.

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

Рейтинг: 834

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

## [В чем заключается подход «marketing mindset» в работе BRM?](https://cleverics.ru/digital/kb-qa/v-chem-zaklyuchaetsya-podkhod-marketing-mindset-v-rabote-brm/)

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

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

Рейтинг: 834

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

## [Как изменяется значение метрики при увеличении времени обработки инцидента конкретной группой?](https://cleverics.ru/digital/kb-qa/kak-izmenyaetsya-znachenie-metriki-pri-uvelichenii-vremeni-obrabotki-intsidenta-konkretnoy-gruppoy/)

Если инцидент решён в срок, увеличение времени обработки конкретной группой не влияет на её KPI, так как для этих инцидентов vi=0 и их вклад в формулу равен 1. Если же инцидент просрочен, увеличение времени обработки группой (ti) приведёт к росту её доли в общем времени (ti/Ti), что уменьшит её KPI, так как формула для просроченных инцидентов выглядит как 1 - (ti/Ti). Таким образом, метрика специально спроектирована так, чтобы время обработки влияло на показатель только в случае, когда инцидент оказался просроченным.

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

Рейтинг: 834

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

## [Какие инструменты автоматизации рекомендуются для процесса управления изменениями?](https://cleverics.ru/digital/kb-qa/kakie-instrumenty-avtomatizatsii-rekomenduyutsya-dlya-protsessa-upravleniya-izmeneniyami/)

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

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

Рейтинг: 834

Теги: командная работа, управление изменениями

## [Как предложенная метрика учитывает как закрытие старых проблем, так и регистрацию новых?](https://cleverics.ru/digital/kb-qa/kak-predlozhennaya-metrika-uchityvaet-kak-zakrytie-starykh-problem-tak-i-registratsiyu-novykh/)

Предложенная метрика учитывает как закрытие старых проблем, так и регистрацию новых через свою формулу. Количество закрытых проблем (C) напрямую входит в числитель формулы, что увеличивает значение метрики за счет решения старых проблем. В то же время, количество новых проблем (N), зарегистрированных за период и оставшихся открытыми, тоже входит в числитель, что увеличивает метрику за счет регистрации новых проблем. Таким образом, метрика отражает оба аспекта эффективного процесса управления проблемами: решение существующих проблем и своевременное выявление новых, не искажая картину, как это происходит в традиционных метриках.

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

Рейтинг: 834

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