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

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

## [Какие подводные камни могут возникнуть при проведении Post-Implementation Review?](https://cleverics.ru/digital/kb-qa/kakie-podvodnye-kamni-mogut-vozniknut-pri-provedenii-post-implementation-review/)

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

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

Рейтинг: 1085

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

## [Какие риски необходимо указывать в методе ORBIT и как это делать?](https://cleverics.ru/digital/kb-qa/kakie-riski-neobkhodimo-ukazyvat-v-metode-orbit-i-kak-eto-delat/)

В разделе Risks (верхний правый квадрант) следует перечислить потенциальные сложности и угрозы, которые могут помешать достижению заявленных результатов. Риски нужно формулировать конкретно и детально, например: «Отсутствие средств мониторинга для контроля параметров предоставления услуг не позволит обеспечить достоверную отчетность», «Недостаточная квалификация персонала для работы с новыми инструментами», «Сопротивление сотрудников внедрению новых процессов». Чем более конкретно и понятно будут описаны риски, тем проще будет разработать стратегию их минимизации и подготовить запасные планы.

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

Рейтинг: 1085

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

## [Какие аспекты следует учитывать при проектировании архитектуры решения для автоматизации бизнес-процессов?](https://cleverics.ru/digital/kb-qa/kakie-aspekty-sleduet-uchityvat-pri-proektirovanii-arkhitektury-resheniya-dlya-avtomatizatsii-biznes/)

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

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

Рейтинг: 1085

Теги: ISO 20000, архитектура ИТ, TOGAF и IT4IT, бизнес, ценность, бизнес-заказчик, управление проектами, PRINCE2

## [Какие есть альтернативные подходы к первоначальному внедрению SLA помимо метода 'AS IS'?](https://cleverics.ru/digital/kb-qa/kakie-est-alternativnye-podkhody-k-pervonachalnomu-vnedreniyu-sla-pomimo-metoda-as-is/)

Классический подход предполагает полное согласование SLA со всеми бизнес-заказчиками до его введения в действие, что часто приводит к задержкам и сложностям с получением согласий. Альтернативный метод 'AS IS' заключается во введении базового SLA, отражающего текущее положение дел, без предварительного согласования со всеми сторонами. Такой подход позволяет быстрее запустить процесс управления сервисами, а бизнесу предоставляет возможность вносить изменения в соглашение по мере необходимости через механизм дополнительных соглашений.

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

Рейтинг: 1085

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

## [Почему не рекомендуется назначать начальника отдела поддержки пользователей (Service Desk) менеджером процесса управления инцидентами в ITSM?](https://cleverics.ru/digital/kb-qa/pochemu-ne-rekomenduetsya-naznachat-nachalnika-otdela-podderzhki-polzovateley-service-desk-menedzher/)

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

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

Рейтинг: 1084

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

## [Какие аспекты классификации инцидента влияют на его приоритизацию?](https://cleverics.ru/digital/kb-qa/kakie-aspekty-klassifikatsii-intsidenta-vliyayut-na-ego-prioritizatsiyu/)

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

Автор: Анна Васильева

Рейтинг: 1084

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

## [Что отличает сервисный подход в реальном ITSM от формального подхода, описанного в методологиях?](https://cleverics.ru/digital/kb-qa/chto-otlichaet-servisnyy-podkhod-v-realnom-itsm-ot-formalnogo-podkhoda-opisannogo-v-metodologiyakh/)

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

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

Рейтинг: 1084

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

## [Почему важно проверять корректность уровня влияния при закрытии инцидента?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-proveryat-korrektnost-urovnya-vliyaniya-pri-zakrytii-intsidenta/)

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

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

Рейтинг: 1084

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

## [Как повышение эффективности управления сложной ИТ-службой может быть связано с измерениями?](https://cleverics.ru/digital/kb-qa/kak-povyshenie-effektivnosti-upravleniya-slozhnoy-it-sluzhboy-mozhet-byt-svyazano-s-izmereniyami/)

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

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

Рейтинг: 1084

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

## [Какие основные недостатки классического показателя доступности ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-nedostatki-klassicheskogo-pokazatelya-dostupnosti-it-uslug/)

Классический показатель доступности, выражаемый как (AST - DT)/AST, имеет несколько существенных недостатков. Прежде всего, он не учитывает распределение простоев во времени: 9 часов непрерывного простоя в году эквивалентны 9-ти отдельным 1-часовым простоям с точки зрения процентного значения, тогда как бизнес-потери в этих случаях будут сильно различаться. Во-вторых, показатель не отражает влияние на бизнес-процессы, так как процент не показывает реальный ущерб от простоя. В-третьих, возникает неоднозначность при интерпретации: 99,9% может быть интерпретировано как 9 часов простоя в год или как 45 минут в месяц, что не всегда соответствует ожиданиям заказчика и провайдера.

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

Рейтинг: 1084

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