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

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

## [Какие основные области рисков выделяют авторы COBIT5 for Risk, связанные с инсайдерскими угрозами?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-oblasti-riskov-vydelyayut-avtory-cobit5-for-risk-svyazannye-s-insayderskimi-ugrozami/)

Основные области рисков, связанные с инсайдерскими угрозами, по мнению авторов COBIT5 for Risk, включают нарушение работы процессов со стороны сотрудников, модификацию клиентской информации, проведение фиктивных транзакций в финансовых системах, несанкционированные изменения и содействие утечкам конфиденциальной информации через сговор с внешними злоумышленниками. Основной причиной реализации этих рисков названы ошибки в разграничении доступа. Для минимизации таких рисков рекомендуется внедрение важных контролов: разделение полномочий, практики управления доступом и работа с персоналом.

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

Рейтинг: 860

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

## [Как определить, какие потоки запускаются на различных этапах путешествия заказчика?](https://cleverics.ru/digital/kb-qa/kak-opredelit-kakie-potoki-zapuskayutsya-na-razlichnykh-etapakh-puteshestviya-zakazchika/)

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

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

Рейтинг: 860

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

## [Почему важно начинать с Continual Service Improvement (CSI) с первых этапов внедрения ITSM?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-nachinat-s-continual-service-improvement-csi-s-pervykh-etapov-vnedreniya-itsm/)

Важно начинать с Continual Service Improvement (CSI) с первых этапов внедрения ITSM, потому что CSI является не просто надстройкой над базовыми процессами, а фундаментальным элементом системы управления. Если начать с CSI, то можно избежать ситуации, когда процессы внедряются формально и без возможности дальнейшего развития. Это позволяет органично 'достраивать' систему управления, ориентируясь на реальные задачи заказчика и используя непрерывное улучшение как основу для роста уровня зрелости процессов.

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

Рейтинг: 860

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

## [Почему менеджеру не нужно вникать в детали выполнения задач?](https://cleverics.ru/digital/kb-qa/pochemu-menedzheru-ne-nuzhno-vnikat-v-detali-vypolneniya-zadach/)

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

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

Рейтинг: 860

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

## [Каким образом соглашение об уровне предоставления (SLA) влияет на восприятие инцидентов?](https://cleverics.ru/digital/kb-qa/kakim-obrazom-soglashenie-ob-urovne-predostavleniya-sla-vliyaet-na-vospriyatie-intsidentov/)

SLA определяет конкретные параметры и условия, при которых услуга считается предоставленной в должном виде. Если в SLA не указаны сроки устранения неполадок или перечень технических средств, которые должны работать, то потребитель может столкнуться с проблемой при попытке требовать ремонта. Наличие детального SLA помогает избежать недоразумений и четко устанавливает, какие ситуации будут считаться инцидентами и каким образом они должны быть устранены

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

Рейтинг: 860

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

## [Какие проблемы возникают при одностороннем применении сервисного подхода?](https://cleverics.ru/digital/kb-qa/kakie-problemy-voznikayut-pri-odnostoronnem-primenenii-servisnogo-podkhoda/)

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

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

Рейтинг: 860

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

## [Как можно избежать конфликта «это не наша вина» при выполнении ИТ-проектов?](https://cleverics.ru/digital/kb-qa/kak-mozhno-izbezhat-konflikta-eto-ne-nasha-vina-pri-vypolnenii-it-proektov/)

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

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

Рейтинг: 860

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

## [Как связаны показатели доступности с соглашениями об уровне услуг (SLA)?](https://cleverics.ru/digital/kb-qa/kak-svyazany-pokazateli-dostupnosti-s-soglasheniyami-ob-urovne-uslug-sla/)

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

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

Рейтинг: 860

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

## [Как обеспечить управляемость структуры при переходе на самоорганизующиеся команды?](https://cleverics.ru/digital/kb-qa/kak-obespechit-upravlyaemost-struktury-pri-perekhode-na-samoorganizuyushchiesya-komandy/)

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

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

Рейтинг: 860

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

## [Какие ошибки чаще всего возникают при первоначальном внедрении SLM?](https://cleverics.ru/digital/kb-qa/kakie-oshibki-chashche-vsego-voznikayut-pri-pervonachalnom-vnedrenii-slm/)

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

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

Рейтинг: 860

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