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

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

## [Какие уровни приоритетов находятся между Sev-5 и Sev-1?](https://cleverics.ru/digital/kb-qa/kakie-urovni-prioritetov-nakhodyatsya-mezhdu-sev-5-i-sev-1/)

Между Sev-5 (самый низкий уровень) и Sev-1 (самый высокий уровень) находятся промежуточные коды приоритетов, порядок которых возрастает от наименьшей к наибольшей степени срочности. Хотя в тексте не указаны конкретные названия или описания каждого уровня, можно предположить, что они представляют собой плавную шкалу от условно-технических проблем до критически важных событий, требующих полной мобилизации ресурсов. Каждый следующий уровень предполагает увеличение скорости реакции и вовлеченности руководства.

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

Рейтинг: 875

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

## [Почему список ограничений проекта не должен включать риски?](https://cleverics.ru/digital/kb-qa/pochemu-spisok-ogranicheniy-proekta-ne-dolzhen-vklyuchat-riski/)

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

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

Рейтинг: 875

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

## [Какие четыре ключевых ограничения проекта наиболее важны для заказчика?](https://cleverics.ru/digital/kb-qa/kakie-chetyre-klyuchevykh-ogranicheniya-proekta-naibolee-vazhny-dlya-zakazchika/)

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

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

Рейтинг: 874

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

## [Как бизнес-подразделения могут создавать ИТ-риски?](https://cleverics.ru/digital/kb-qa/kak-biznes-podrazdeleniya-mogut-sozdavat-it-riski/)

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

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

Рейтинг: 874

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

## [Почему при анализе дерева отказов ИТ-услуг полезно разбивать систему на функциональные блоки?](https://cleverics.ru/digital/kb-qa/pochemu-pri-analize-dereva-otkazov-it-uslug-polezno-razbivat-sistemu-na-funktsionalnye-bloki/)

Разбиение ИТ-услуги на функциональные блоки (например, доступ инженера к базе обращений, обработка обращений, отправка уведомлений и др.) при анализе дерева отказов позволяет: определить различную критичность функций – некоторые функции могут быть жизненно важными, другие – второстепенными; упростить и ускорить анализ, так как полное дерево для всей комплексной системы может быть чрезмерно громоздким; четко сопоставить отказы конфигурационных единиц (КЕ) с отказами функциональности, что облегчает определение уровня ущерба и установление целевых показателей восстановления; проводить более точную оценку рисков и распределение ресурсов, фокусируясь на наиболее критичных функциях. Такой подход делает анализ управляемым даже для сложно структурированных ИТ-услуг и позволяет получить практические рекомендации, направленные именно на те компоненты системы, отказы которых ведут к самым серьезным последствиям.

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

Рейтинг: 874

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

## [Как парадигма ITSM соотносится с современными подходами DevOps и Agile?](https://cleverics.ru/digital/kb-qa/kak-paradigma-itsm-sootnositsya-s-sovremennymi-podkhodami-devops-i-agile/)

Парадигма ITSM традиционно воспринималась как более формализованный и структурированный подход, тогда как DevOps и Agile фокусируются на гибкости и скорости. Однако современные версии ITSM (такие как ITIL 4) активно интегрируют принципы Agile и DevOps, сочетая структурированное управление услугами с гибким подходом к развитию ИТ-систем. Это проявляется в упоре на сотрудничество между командами, непрерывное улучшение, автоматизацию процессов и сокращение времени вывода новых сервисов на рынок. Современное понимание ITSM не противоречит Agile и DevOps, а предоставляет рамки, в которых эти подходы могут эффективно функционировать, сохраняя контроль над качеством и стабильностью услуг.

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

Рейтинг: 874

Теги: Agile и гибкие методы разработки ПО, DevOps, CI/CD, ITIL, ITSM, командная работа, общие вопросы менеджмента, постоянное улучшение, совершенствование, CSI, PDCA, эффективность, оптимизация

## [Как связка стандартов RBAC помогает в проектировании систем управления доступом?](https://cleverics.ru/digital/kb-qa/kak-svyazka-standartov-rbac-pomogaet-v-proektirovanii-sistem-upravleniya-dostupom/)

Связка стандартов RBAC (INCITS 359-2012, INCITS 494-2012 и INCITS 459-2011) устанавливает общую терминологию и определяет элементы, множества, интерфейсы, команды и модели, которые можно использовать при проектировании систем управления доступом. Это обеспечивает единообразие в подходах к реализации RBAC, позволяет создавать совместимые системы и облегчает процесс анализа их функциональных возможностей. Первый стандарт определяет базовую модель, второй добавляет гибкость за счет поддержки динамических ограничений, а третий обеспечивает корректную комбинацию всех компонентов и их взаимодействие. Совместное использование этих стандартов помогает создавать эффективные решения для управления доступом, которые соответствуют современным требованиям безопасности и бизнес-процессов.

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

Рейтинг: 874

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

## [Как разделить роли в процессе обработки заявок?](https://cleverics.ru/digital/kb-qa/kak-razdelit-roli-v-protsesse-obrabotki-zayavok/)

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

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

Рейтинг: 874

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

## [Какие преимущества дает использование фиксированного маршрута эскалации?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-daet-ispolzovanie-fiksirovannogo-marshruta-eskalatsii/)

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

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

Рейтинг: 874

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

## [Какие элементы услуги обычно замечают заказчики при взаимодействии с ИТ-службой?](https://cleverics.ru/digital/kb-qa/kakie-elementy-uslugi-obychno-zamechayut-zakazchiki-pri-vzaimodeystvii-s-it-sluzhboy/)

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

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

Рейтинг: 874

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