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

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

## [Как обеспечить корректное восстановление ИТ-услуг после устранения инфраструктурного major-инцидента?](https://cleverics.ru/digital/kb-qa/kak-obespechit-korrektnoe-vosstanovlenie-it-uslug-posle-ustraneniya-infrastrukturnogo-major-intsiden/)

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

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

Рейтинг: 744

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

## [Какие стандартные этапы процесса управления изменениями могут быть нарушены при экстренных изменениях?](https://cleverics.ru/digital/kb-qa/kakie-standartnye-etapy-protsessa-upravleniya-izmeneniyami-mogut-byt-narusheny-pri-ekstrennykh-izmen/)

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

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

Рейтинг: 744

Теги: управление изменениями, управление релизами, управление рисками

## [Как влияет повышенная производительность системы на ее доступность?](https://cleverics.ru/digital/kb-qa/kak-vliyaet-povyshennaya-proizvoditelnost-sistemy-na-ee-dostupnost/)

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

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

Рейтинг: 744

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

## [Каковы последствия отсутствия гарантий на ключевые параметры услуг для бизнеса?](https://cleverics.ru/digital/kb-qa/kakovy-posledstviya-otsutstviya-garantiy-na-klyuchevye-parametry-uslug-dlya-biznesa/)

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

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

Рейтинг: 744

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

## [Что такое градуальное включение новых разрешений в ролевую модель RBAC?](https://cleverics.ru/digital/kb-qa/chto-takoe-gradualnoe-vklyuchenie-novykh-razresheniy-v-rolevuyu-model-rbac/)

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

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

Рейтинг: 744

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

## [Как решить проблему, когда разные группы участников одного процесса работают по своим правилам из-за специфики деятельности?](https://cleverics.ru/digital/kb-qa/kak-reshit-problemu-kogda-raznye-gruppy-uchastnikov-odnogo-protsessa-rabotayut-po-svoim-pravilam-iz/)

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

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

Рейтинг: 743

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

## [Что такое локус контроля в психологии?](https://cleverics.ru/digital/kb-qa/chto-takoe-lokus-kontrolya-v-psikhologii/)

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

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

Рейтинг: 743

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

## [Как определить успех продукта, если он ориентирован на государственного заказчика или является некоммерческим?](https://cleverics.ru/digital/kb-qa/kak-opredelit-uspekh-produkta-esli-on-orientirovan-na-gosudarstvennogo-zakazchika-ili-yavlyaetsya-ne/)

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

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

Рейтинг: 743

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

## [Как избежать ситуации, когда процесс остаётся «бумажным» и забывается на полке?](https://cleverics.ru/digital/kb-qa/kak-izbezhat-situatsii-kogda-protsess-ostaetsya-bumazhnym-i-zabyvaetsya-na-polke/)

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

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

Рейтинг: 743

Теги: бизнес, ценность, бизнес-заказчик, руководство ИТ (IT Governance), управление проектами, PRINCE2, управление процессами, ИТ-процессы, управление релизами

## [Как правильно учитывать рабочее время при выполнении обращений в условиях многочасовых поясов?](https://cleverics.ru/digital/kb-qa/kak-pravilno-uchityvat-rabochee-vremya-pri-vypolnenii-obrashcheniy-v-usloviyakh-mnogochasovykh-poyas/)

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

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

Рейтинг: 743

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