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

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

## [Почему заказчикам сложно понять ценность процессов управления ИТ?](https://cleverics.ru/digital/kb-qa/pochemu-zakazchikam-slozhno-ponyat-tsennost-protsessov-upravleniya-it/)

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

Автор: Роман Журавлёв

Рейтинг: 939

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

## [Когда применение подхода MVP может быть нецелесообразным?](https://cleverics.ru/digital/kb-qa/kogda-primenenie-podkhoda-mvp-mozhet-byt-netselesoobraznym/)

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

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

Рейтинг: 939

Теги: Agile и гибкие методы разработки ПО, бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, общие вопросы менеджмента, поток создания ценности (Value Stream), управление продуктами, продуктовый подход, эффективность, оптимизация

## [Какие рекомендации можно дать по эффективному использованию RBAC, чтобы избежать основных проблем?](https://cleverics.ru/digital/kb-qa/kakie-rekomendatsii-mozhno-dat-po-effektivnomu-ispolzovaniyu-rbac-chtoby-izbezhat-osnovnykh-problem/)

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

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

Рейтинг: 939

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

## [Что указано в примерах политик процесса Управления инцидентами (INC) относительно передачи информации?](https://cleverics.ru/digital/kb-qa/chto-ukazano-v-primerakh-politik-protsessa-upravleniya-intsidentami-inc-otnositelno-peredachi-inform/)

В примерах политик процесса Управления инцидентами (INC) прямо указано: «Информация об инцидентах и их статусах должна своевременно и эффективно передаваться. Это предполагает наличие хорошего service desk для координации коммуникации информации об инцидентах тем, кто работает над инцидентами». Это означает, что процесс должен быть организован так, чтобы обеспечивать непрерывную и понятную коммуникацию между всеми участниками процесса: пользователем, Service Desk и группами, работающими над устранением инцидента. Service Desk выступает центральным звеном в координации этой коммуникации и несёт ответственность за передачу информации пользователю.

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

Рейтинг: 939

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

## [Почему важно учитывать принцип 'Отталкиваться от текущей ситуации' при внедрении изменений в ITSM?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-uchityvat-printsip-ottalkivatsya-ot-tekushchey-situatsii-pri-vnedrenii-izmeneniy-v-it/)

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

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

Рейтинг: 938

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

## [Какой подход можно использовать для разработки процессных метрик согласно книге «ITSM. Руководство по измерению»?](https://cleverics.ru/digital/kb-qa/kakoy-podkhod-mozhno-ispolzovat-dlya-razrabotki-protsessnykh-metrik-soglasno-knige-itsm-rukovodstvo/)

Согласно книге «ITSM. Руководство по измерению» коллег Дмитрия Исайченко и Романа Журавлева, для разработки процессных метрик следует придерживаться следующего подхода: установить назначение процесса, разработать метрики соответствия назначению, установить ключевые практики, разработать метрики ключевых практик. Шаги по установлению назначения процесса обычно не вызывают сложностей, тогда как определение ключевых практик и связанных с ними метрик может представлять трудности, несмотря на наличие рекомендаций в таких фреймворках, как ITIL и COBIT5.

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

Рейтинг: 938

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

## [Какие критерии используются для назначения координаторов изменений?](https://cleverics.ru/digital/kb-qa/kakie-kriterii-ispolzuyutsya-dlya-naznacheniya-koordinatorov-izmeneniy/)

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

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

Рейтинг: 938

Теги: общие вопросы менеджмента, управление изменениями, управление конфигурациями, CMDB

## [Какие дисфункции возникают при наличии этапа 'Отложено' в потоке создания ценности?](https://cleverics.ru/digital/kb-qa/kakie-disfunktsii-voznikayut-pri-nalichii-etapa-otlozheno-v-potoke-sozdaniya-tsennosti/)

Наличие этапа 'Отложено' в потоке создания ценности приводит к следующим дисфункциям: размытой ответственности, так как команда перекладывает вину на внешние факторы; повышенным требованиям к контролю, поскольку процесс становится менее предсказуемым; управлению через жесткие дедлайны, что создает стресс и искусственно ускоряет работу; управлению дефектами как отдельной активностью, так как отложенные задачи теряют контекст и качество; смещению фокуса с создания ценности на простое выполнение работы без результативности. Все это приводит к тому, что команда может быть постоянно занята делами, но конечные результаты будут неудовлетворительными.

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

Рейтинг: 938

Теги: Agile и гибкие методы разработки ПО, бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, командная работа, общие вопросы менеджмента, поток создания ценности (Value Stream), разработка ПО

## [Какие риски возникают при игнорировании аналитики в отчетах процессов?](https://cleverics.ru/digital/kb-qa/kakie-riski-voznikayut-pri-ignorirovanii-analitiki-v-otchetakh-protsessov/)

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

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

Рейтинг: 938

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

## [Какой уровень детализации необходим для расчёта себестоимости ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kakoy-uroven-detalizatsii-neobkhodim-dlya-rascheta-sebestoimosti-it-uslug/)

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

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

Рейтинг: 938

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