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

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

## [Какой критерий Коттер предлагает для оценки успешности первого шага внедрения изменений?](https://cleverics.ru/digital/kb-qa/kakoy-kriteriy-kotter-predlagaet-dlya-otsenki-uspeshnosti-pervogo-shaga-vnedreniya-izmeneniy/)

Джон Коттер рекомендует использовать такой критерий успешности первого шага: более 75% руководителей должны согласиться с тем, что текущие практики необходимо менять как можно скорее. Это означает, что создание ощущения срочности достигнуто, когда большинство руководителей осознают необходимость немедленных действий и готовы поддерживать последующие этапы изменений.

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

Рейтинг: 805

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

## [Что представляет собой деловая игра Grab@Pizza?](https://cleverics.ru/digital/kb-qa/chto-predstavlyaet-soboy-delovaya-igra-grab-pizza/)

Деловая игра Grab@Pizza - это интерактивное упражнение, проводимое компанией Cleverics, которое симулирует реальные бизнес-ситуации, связанные с управлением ИТ и бизнес-процессами. Участники играют роль антикризисной команды, которая должна решить задачи, связанные с неопределённостью, инцидентами технической поддержки, финансовым кризисом компании и другими проблемами. Игра демонстрирует важные аспекты взаимодействия бизнеса и ИТ, помогает участникам лучше понять, как выстраивать процессы и взаимодействие между различными отделами для достижения общих целей.

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

Рейтинг: 804

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

## [Какие примеры конфликта интересов в работе можно привести?](https://cleverics.ru/digital/kb-qa/kakie-primery-konflikta-interesov-v-rabote-mozhno-privesti/)

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

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

Рейтинг: 804

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

## [Какие усиливающие петли обратной связи связаны с проблемами в ИТ?](https://cleverics.ru/digital/kb-qa/kakie-usilivayushchie-petli-obratnoy-svyazi-opisany-v-tekste-svyazannye-s-problemami-v-it/)

В тексте описаны несколько усиливающих петлей обратной связи, связанных с проблемами в ИТ. Первая отрицательная: увеличение числа проблем и обходных решений (Workarounds) приводит к росту сложности инфраструктуры (IT Infrastructure Complexity), что повышает хрупкость системы (увеличивает Change Risk) и затрудняет планирование (снижает Change Control Level), что в свою очередь ведет к новым ошибкам и проблемам, замыкая цикл. Вторая отрицательная: высокий Time to market вызывает давление со стороны бизнеса на срочные изменения (Emergency changes), которые проводятся с нарушением процессов (низкий Change Control Level), что приводит к новым ошибкам и росту бэклога, еще больше увеличивая Time to market. Третья отрицательная: постоянные провалы приводят к настороженности и страхову, усложнению коммуникаций, увеличению бюрократии (Bureaucracy), что замедляет изменения и усиливает проблемы. Также описана положительная усиливающая петля: высокий Release rate приводит к накоплению опыта (возрастанию Change capability), что позволяет еще чаще внедрять изменения, образуя позитивный цикл развития.

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

Рейтинг: 804

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

## [Как стимулировать функциональных руководителей к участию в процессном управлении через систему метрик?](https://cleverics.ru/digital/kb-qa/kak-stimulirovat-funktsionalnykh-rukovoditeley-k-uchastiyu-v-protsessnom-upravlenii-cherez-sistemu-m/)

Функциональных руководителей можно стимулировать к участию в процессном управлении через систему метрик, связывая их оценку и вознаграждение с результатами процессов, в которых участвуют их подразделения. Даже если руководитель формально не несет функциональных обязанностей в процессах (не является R в матрице RACI), его оценка строится на основе процессных метрик его подчиненных. Например, руководитель отдела может оцениваться по таким показателям как доля заданий, выполненных в срок, доля инцидентов, принятых в работу своевременно, и другие показатели эффективности. Это создает мотивацию для руководителя уделять внимание процессам, предоставлять необходимые ресурсы и контролировать выполнение задач. Система метрик должна быть четко определена, со сопоставимыми показателями (шкала от 0 до 1) и понятным способом агрегации результатов для формирования итогового рейтинга.

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

Рейтинг: 804

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

## [Как организовать эффективные циклы обратной связи между бизнесом и ИТ-разработкой?](https://cleverics.ru/digital/kb-qa/kak-organizovat-effektivnye-tsikly-obratnoy-svyazi-mezhdu-biznesom-i-it-razrabotkoy/)

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

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

Рейтинг: 804

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

## [Что нужно учесть при проектировании эффективной системы управления событиями?](https://cleverics.ru/digital/kb-qa/chto-nuzhno-uchest-pri-proektirovanii-effektivnoy-sistemy-upravleniya-sobytiyami/)

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

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

Рейтинг: 804

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

## [В каких случаях полный аутсорс Ops является нецелесообразным решением для продукт-ориентированной команды?](https://cleverics.ru/digital/kb-qa/v-kakikh-sluchayakh-polnyy-autsors-ops-yavlyaetsya-netselesoobraznym-resheniem-dlya-produkt-orientir/)

Полный аутсорс Ops является нецелесообразным решением в случаях, когда продукт требует специфической настройки middleware, высокого уровня интеграции компонентов и постоянного вмешательства для поддержания стабильности. Например, если продукт включает кастомизированный middleware или высоконагруженные СУБД, требующие тонкой настройки под конкретную нагрузку, привлечение внешней команды может привести к потере контроля и замедлению процессов разработки и эксплуатации. Также полный аутсорс не подходит, если эксплуатационная активность требует 100% вовлечения и тесной связи с продуктом, например, при постоянном мониторинге здоровья сервиса или управлении тысячами узлов. В таких ситуациях важно сохранить эксплуатационную экспертизу внутри команды или использовать гибридный подход, когда внешние специалисты выполняют часть работы под контролем внутренних сотрудников.

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

Рейтинг: 804

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

## [Должен ли срок выполнения задачи приостанавливаться при переводе в статус 'Ожидание'?](https://cleverics.ru/digital/kb-qa/dolzhen-li-srok-vypolneniya-zadachi-priostanavlivatsya-pri-perevode-v-status-ozhidanie/)

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

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

Рейтинг: 804

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

## [Какие вопросы стоит задавать на ретроспективе для анализа поставки?](https://cleverics.ru/digital/kb-qa/kakie-voprosy-stoit-zadavat-na-retrospektive-dlya-analiza-postavki/)

Ключевые вопросы: объём поставки уменьшился по сравнению с предыдущими периодами? Количество дефектов и доработок стремится к нулю? Скорость обработки задач удовлетворяет заказчиков? Если ответы отрицательные, необходимо искать корневые причины внутри команды: не хватает ли стандартов работы, есть ли системные риски или блокировки, эффективны ли инструменты. Важно переходить к обсуждению процессов только после оценки результатов поставки.

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

Рейтинг: 804

Теги: Agile и гибкие методы разработки ПО, DevOps, CI/CD, ISO 20000, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, командная работа, разработка ПО, управление проблемами, управление рисками