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

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

## [Как определить достаточный уровень полномочий для владельца конкретного процесса?](https://cleverics.ru/digital/kb-qa/kak-opredelit-dostatochnyy-uroven-polnomochiy-dlya-vladeltsa-konkretnogo-protsessa/)

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

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

Рейтинг: 776

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

## [С какой периодичностью следует проводить диагностику продуктовой команды?](https://cleverics.ru/digital/kb-qa/s-kakoy-periodichnostyu-sleduet-provodit-diagnostiku-produktovoy-komandy/)

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

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

Рейтинг: 775

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

## [Что такое инциденты в контексте ИТ-услуг?](https://cleverics.ru/digital/kb-qa/chto-takoe-intsidenty-v-kontekste-it-uslug/)

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

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

Рейтинг: 775

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

## [Что такое функциональность 'приостановки таймера' в ITSM-системах и для чего она используется?](https://cleverics.ru/digital/kb-qa/chto-takoe-funktsionalnost-priostanovki-taymera-v-itsm-sistemakh-i-dlya-chego-ona-ispolzuetsya/)

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

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

Рейтинг: 775

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

## [Как дополняющие услуги могут быть использованы для повышения лояльности клиентов?](https://cleverics.ru/digital/kb-qa/kak-dopolnyayushchie-uslugi-mogut-byt-ispolzovany-dlya-povysheniya-loyalnosti-klientov/)

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

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

Рейтинг: 775

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

## [Как соотносятся метрики коэффициента готовности и доступности в телекоммуникационных сетях?](https://cleverics.ru/digital/kb-qa/kak-sootnosyatsya-metriki-koeffitsienta-gotovnosti-i-dostupnosti-v-telekommunikatsionnykh-setyakh/)

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

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

Рейтинг: 775

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

## [Как рассчитывается общее время вывода идеи на рынок (time-to-market)?](https://cleverics.ru/digital/kb-qa/kak-rasschityvaetsya-obshchee-vremya-vyvoda-idei-na-rynok-time-to-market/)

Общее время вывода идеи на рынок (time-to-market) начинается с момента возникновения идеи (желтый флажок) - когда у бизнеса появляется видение проблемы, решив которую можно получить преимущества или снизить риски. Это время включает период, пока идея проходит эволюционный отбор и превращается в задачу для разработки (зеленый флажок), период ожидания выполнения задачи (Customer Lead Time) и непосредственно время производства - от точки принятия обязательств (красный флажок) до момента поставки результата.

Автор: Павел Капусткин

Рейтинг: 775

Теги: DevOps, CI/CD, Lean, бережливое производство, бизнес, ценность, бизнес-заказчик, разработка ПО, трансформация, ускорение, Time-to-Market, управление рисками

## [Какой принцип ITIL подтверждается упрощением ролевой модели в ITIL 4?](https://cleverics.ru/digital/kb-qa/kakoy-printsip-itil-podtverzhdaetsya-uproshcheniem-rolevoy-modeli-v-itil-4/)

Упрощение ролевой модели в ITIL 4 подтверждает принцип 'Keep it simple and practical' (сохраняйте простоту и практичность). Эта эволюционная трансформация от ITILv3 к ITIL4 минимизирует вероятность избыточного усложнения системы управления и бесплодных споров о распределении задач между ролями. Принцип подчеркивает, что более простые и практические подходы к управлению ИТ-услугами приводят к более эффективной работе и лучшему пониманию обязанностей сотрудниками.

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

Рейтинг: 775

Теги: ITIL, общие вопросы менеджмента, трансформация, ускорение, Time-to-Market, управление доступом, IDM, ролевые модели, RBAC, ABAC, управление процессами, ИТ-процессы

## [Какие угрозы информационной безопасности возникают из-за накопления права у пользователей?](https://cleverics.ru/digital/kb-qa/kakie-ugrozy-informatsionnoy-bezopasnosti-voznikayut-iz-za-nakopleniya-prava-u-polzovateley/)

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

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

Рейтинг: 775

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

## [Почему совмещение ролей менеджера процесса управления проблемами и менеджера процесса управления инцидентами не рекомендуется?](https://cleverics.ru/digital/kb-qa/pochemu-sovmeshchenie-roley-menedzhera-protsessa-upravleniya-problemami-i-menedzhera-protsessa-uprav/)

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

Автор: Михаил Тобурдановский

Рейтинг: 775

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