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

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

## [Какие аргументы приводятся за учет времени ожидания ответа пользователя в общем сроке SLA?](https://cleverics.ru/digital/kb-qa/kakie-argumenty-privodyatsya-za-uchet-vremeni-ozhidaniya-otveta-polzovatelya-v-obshchem-sroke-sla/)

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

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

Рейтинг: 716

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

## [Какие качества должны быть у лидера для обеспечения стабильного развития ИТ-сервисов?](https://cleverics.ru/digital/kb-qa/kakie-kachestva-dolzhny-byt-u-lidera-dlya-obespecheniya-stabilnogo-razvitiya-it-servisov/)

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

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

Рейтинг: 716

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

## [Почему автоматизация управления доступом не решает всех проблем без дополнительного управления бизнес-процессами?](https://cleverics.ru/digital/kb-qa/pochemu-avtomatizatsiya-upravleniya-dostupom-ne-reshaet-vsekh-problem-bez-dopolnitelnogo-upravleniya/)

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

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

Рейтинг: 716

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

## [Чем отличается управление через дедлайны от потокового управления?](https://cleverics.ru/digital/kb-qa/chem-otlichaetsya-upravlenie-cherez-dedlayny-ot-potokovogo-upravleniya/)

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

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

Рейтинг: 716

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

## [Какие аспекты командного взаимодействия стоит анализировать после деловой игры?](https://cleverics.ru/digital/kb-qa/kakie-aspekty-komandnogo-vzaimodeystviya-stoit-analizirovat-posle-delovoy-igry/)

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

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

Рейтинг: 716

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

## [Какие последствия имеет выполнение работы «впрок» без понимания целей развития продукта?](https://cleverics.ru/digital/kb-qa/kakie-posledstviya-imeet-vypolnenie-raboty-vprok-bez-ponimaniya-tseley-razvitiya-produkta/)

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

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

Рейтинг: 716

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

## [Какие преимущества дает делегирование функций локальным командам в распределенных структурах?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-daet-delegirovanie-funktsiy-lokalnym-komandam-v-raspredelennykh-strukturakh/)

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

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

Рейтинг: 716

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

## [Какие основные типы регламентирующих документов необходимы для взаимодействия проектного офиса, разработчиков и эксплуатирующих подразделений?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-tipy-reglamentiruyushchikh-dokumentov-neobkhodimy-dlya-vzaimodeystviya-proektnogo-ofi/)

Для взаимодействия проектного офиса, разработчиков и эксплуатирующих подразделений необходимы следующие основные типы регламентирующих документов: 1) Документ, определяющий основные стадии создания новой автоматизированной системы (АС) или выполнения доработок, обычно называемый «Положение о разработке прикладного ПО». Он содержит описание состава работ, ответственных лиц, входных и выходных документов для каждой стадии. Важная особенность – вовлечение эксплуатирующих подразделений в определение требований и проектирование АС. 2) Документ, определяющий порядок приёмки новых АС в эксплуатацию, который может быть частью первого документа и обычно называется «Положение о внедрении информационных систем». Он включает определение порядка и охвата тестирования, подготовки тестовых сред, опытной эксплуатации и других аспектов. Может дополняться политиками релизов. 3) Документ, определяющий архитектурные и технологические стандарты, распространяющиеся на разработку новых решений. Включает определение допустимых языков и сред разработки, используемых платформ и СУБД, механизмов развёртывания, требований к интерфейсам, резервированию, мониторингу, журналированию и другим техническим аспектам. Эти документы образуют совокупный регламент управления изменениями и релизами в части разработки и внедрения прикладного программного обеспечения.

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

Рейтинг: 715

Теги: DevOps, CI/CD, ISO 20000, мониторинг, управление изменениями, управление отношениями, взаимодействие, BRM, управление процессами, ИТ-процессы, управление релизами

## [Какие принципы организации команд позволяют достичь баланса между скоростью и надежностью?](https://cleverics.ru/digital/kb-qa/kakie-printsipy-organizatsii-komand-pozvolyayut-dostich-balansa-mezhdu-skorostyu-i-nadezhnostyu/)

Для баланса между скоростью и надёжностью необходимо разделить ответственность: продуктовые команды фокусируются на разработке и улучшении приложений, а эксплуатационные подразделения — на их стабильной работе и поддержке пользователей. Важно внедрять методы SRE, автоматизацию тестирования и непрерывную интеграцию, а также следовать подходам ITIL для управления операционными процессами. Также критичны прозрачность процессов, чёткое распределение ролей и фокус на бизнес-цели вместо технических деталей.

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

Рейтинг: 715

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

## [Почему в DevOps недостаточно принятия работы владельцем продукта для определения завершения?](https://cleverics.ru/digital/kb-qa/pochemu-v-devops-nedostatochno-prinyatiya-raboty-vladeltsem-produkta-dlya-opredeleniya-zaversheniya/)

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

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

Рейтинг: 715

Теги: DevOps, CI/CD, поддержка пользователей, Service Desk, Help Desk, управление продуктами, продуктовый подход