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

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

## [Какие сложности возникают при управлении организационными проблемами по сравнению с техническими?](https://cleverics.ru/digital/kb-qa/kakie-slozhnosti-voznikayut-pri-upravlenii-organizatsionnymi-problemami-po-sravneniyu-s-tekhnicheski/)

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

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

Рейтинг: 913

Теги: бизнес, ценность, бизнес-заказчик

## [Из-за чего происходят срывы сроков в проекте?](https://cleverics.ru/digital/kb-qa/iz-za-chego-proiskhodyat-sryvy-srokov-v-proekte/)

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

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

Рейтинг: 912

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

## [Как ITIL 4 предлагает решать проблему разобщенности в предоставлении ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kak-itil-4-predlagaet-reshat-problemu-razobshchennosti-v-predostavlenii-it-uslug/)

ITIL 4 предлагает решать проблему разобщенности через принцип 'Используйте целостный подход' (Think and work holistically) и через рассмотрение четырех аспектов управления ИТ-услугами. Этот принцип подразумевает необходимость понимания того, как все части организации работают вместе интегрированным образом. Вместо того чтобы фокусироваться на отдельных элементах (процессах без учета инструментов и компетенций, или наоборот), ITIL 4 предлагает рассматривать четыре взаимосвязанных аспекта: организации и люди, информация и технологии, партнеры и поставщики, потоки создания ценности и процессы. Для устранения разобщенности также необходимо формировать организационные структуры, ориентированные на сотрудничество, развивать культуру доверия и прозрачности, обеспечивать достаточные компетенции сотрудников и правильно определять взаимодействие с партнерами. Важно рассматривать процессы не изолированно, а как часть потоков создания ценности, что обеспечивает целостное преобразование входов в результаты, воспринимаемые клиентом.

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

Рейтинг: 912

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

## [Почему простого обсуждения технического плана проекта может быть недостаточно для успешной реализации задачи в ИТ-команде?](https://cleverics.ru/digital/kb-qa/pochemu-prostogo-obsuzhdeniya-tekhnicheskogo-plana-proekta-mozhet-byt-nedostatochno-dlya-uspeshnoy-r/)

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

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

Рейтинг: 912

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

## [Как учитывать специфику различных информационных систем в едином процессе управления изменениями?](https://cleverics.ru/digital/kb-qa/kak-uchityvat-spetsifiku-razlichnykh-informatsionnykh-sistem-v-edinom-protsesse-upravleniya-izmeneni/)

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

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

Рейтинг: 912

Теги: управление изменениями, управление процессами, ИТ-процессы

## [Как решить проблему несоответствия обещаний бизнесу и возможностей внешних поставщиков ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kak-reshit-problemu-nesootvetstviya-obeshchaniy-biznesu-i-vozmozhnostey-vneshnikh-postavshchikov-it/)

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

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

Рейтинг: 912

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

## [Какие риски связаны с отсутствием четкой иерархии в организациях?](https://cleverics.ru/digital/kb-qa/kakie-riski-svyazany-s-otsutstviem-chetkoy-ierarkhii-v-organizatsiyakh/)

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

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

Рейтинг: 912

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

## [Какие метрики следует использовать для оценки успеха продуктов в условиях ограниченной пользовательской базы?](https://cleverics.ru/digital/kb-qa/kakie-metriki-sleduet-ispolzovat-dlya-otsenki-uspekha-produktov-v-usloviyakh-ogranichennoy-polzovate/)

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

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

Рейтинг: 912

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

## [Какие последствия могут возникнуть при временной остановке конвейера CI/CD?](https://cleverics.ru/digital/kb-qa/kakie-posledstviya-mogut-vozniknut-pri-vremennoy-ostanovke-konveyera-ci-cd/)

Временная остановка конвейера CI/CD может привести к серьезным негативным последствиям. Во-первых, это разрушает культуру дисциплины и ответственности, создавая прецедент, когда конвейер можно игнорировать в угоду сиюминутным задачам. Во-вторых, команда начинает искать обходные пути, например, производить развертывание вручную, что нарушает целостность процесса и повышает риски ошибок. В-третьих, однажды приостановив конвейер, команда может столкнуться с трудностями при его возобновлении: за время простоя процессы могут быть забыты, настройки устареть, а некоторые элементы конвейера (например, автотесты) перестать работать корректно. В-четвертых, временная остановка часто становится постоянной, так как «потом разберемся» обычно не приводит к реальному возврату к процессу. В конечном итоге, все усилия по внедрению и настройке конвейера оказываются напрасными, и команда возвращается к старым практикам, теряя время, ресурсы и доверие.

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

Рейтинг: 912

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

## [Как организована ответственность за управление рисками в предложенной модели?](https://cleverics.ru/digital/kb-qa/kak-organizovana-otvetstvennost-za-upravlenie-riskami-v-predlozhennoy-modeli/)

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

Автор: Константин Нарыжный

Рейтинг: 912

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