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

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

## [Какие типичные ошибки допускают компании при масштабировании своего сервиса через партнерские программы?](https://cleverics.ru/digital/kb-qa/kakie-tipichnye-oshibki-dopuskayut-kompanii-pri-masshtabirovanii-svoego-servisa-cherez-partnerskie-p/)

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

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

Рейтинг: 1043

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

## [Как создать эффективную ролевую модель для управления доступом?](https://cleverics.ru/digital/kb-qa/kak-sozdat-effektivnuyu-rolevuyu-model-dlya-upravleniya-dostupom/)

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

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

Рейтинг: 1043

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

## [Как организовать эффективную работу при ограничениях разграничения зон ответственности в распределенных командах?](https://cleverics.ru/digital/kb-qa/kak-organizovat-effektivnuyu-rabotu-pri-ogranicheniyakh-razgranicheniya-zon-otvetstvennosti-v-raspre/)

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

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

Рейтинг: 1043

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

## [Почему прямая выдача доступа без согласования невозможна?](https://cleverics.ru/digital/kb-qa/pochemu-pryamaya-vydacha-dostupa-bez-soglasovaniya-nevozmozhna/)

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

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

Рейтинг: 1042

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

## [Какая типичная структура взаимодействия клиента с банковским контакт-центром через IVR?](https://cleverics.ru/digital/kb-qa/kakaya-tipichnaya-struktura-vzaimodeystviya-klienta-s-bankovskim-kontakt-tsentrom-cherez-ivr/)

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

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

Рейтинг: 1042

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

## [Как определяется норма для системы при проектировании инцидентов?](https://cleverics.ru/digital/kb-qa/kak-opredelyaetsya-norma-dlya-sistemy-pri-proektirovanii-intsidentov/)

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

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

Рейтинг: 1042

Теги: SLA, управление инцидентами, управление уровнем услуг, SLM

## [Как влияет уровень компьютерной грамотности пользователей на определение функций первой линии поддержки?](https://cleverics.ru/digital/kb-qa/kak-vliyaet-uroven-kompyuternoy-gramotnosti-polzovateley-na-opredelenie-funktsiy-pervoy-linii-podder/)

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

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

Рейтинг: 1042

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

## [Когда не стоит применять продуктовый подход к управлению ИТ-системами?](https://cleverics.ru/digital/kb-qa/kogda-ne-stoit-primenyat-produktovyy-podkhod-k-upravleniyu-it-sistemami/)

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

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

Рейтинг: 1042

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

## [Что означает принцип 'Сохранять фокус на ценности' согласно ITIL Practitioner Guidance?](https://cleverics.ru/digital/kb-qa/chto-oznachaet-printsip-sokhranyat-fokus-na-tsennosti-soglasno-itil-practitioner-guidance/)

Принцип 'Сохранять фокус на ценности' означает, что ИТ-организации должны ориентироваться на предоставление ценности клиенту, а не просто технологий. Важно понимать, что ценность определяет заказчик, а не сервис-провайдер, и необходимо учитывать его интересы. На практике многие ИТ-специалисты не могут чётко ответить, какой вклад даёт внедрение процессов или доработка инструментов в создание ценности.

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

Рейтинг: 1041

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

## [Имеют ли метрики, измеряемые через экспертную оценку или опросы, такое же право на существование, как и автоматизированные метрики?](https://cleverics.ru/digital/kb-qa/imeyut-li-metriki-izmeryaemye-cherez-ekspertnuyu-otsenku-ili-oprosy-takoe-zhe-pravo-na-sushchestvova/)

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

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

Рейтинг: 1041

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