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

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

## [Как формируются модели стандартных изменений в ИТ-организациях?](https://cleverics.ru/digital/kb-qa/kak-formiruyutsya-modeli-standartnykh-izmeneniy-v-it-organizatsiyakh/)

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

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

Рейтинг: 783

Теги: DevOps, CI/CD, безопасность, управление запросами на обслуживание, управление изменениями, управление конфигурациями, CMDB, управление рисками, эффективность, оптимизация

## [Кто должен принимать окончательное решение о приоритетах ИТ-изменений согласно тексту?](https://cleverics.ru/digital/kb-qa/kto-dolzhen-prinimat-okonchatelnoe-reshenie-o-prioritetakh-it-izmeneniy-soglasno-tekstu/)

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

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

Рейтинг: 783

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

## [Какая роль заказчика в запуске потоков создания ценности?](https://cleverics.ru/digital/kb-qa/kakaya-rol-zakazchika-v-zapuske-potokov-sozdaniya-tsennosti/)

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

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

Рейтинг: 783

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

## [Как учитывать изменения организационной структуры при обновлении ролевой модели?](https://cleverics.ru/digital/kb-qa/kak-uchityvat-izmeneniya-organizatsionnoy-struktury-pri-obnovlenii-rolevoy-modeli/)

При изменениях структуры (слияние, разделение подразделений) нужно: 1) Определить тип изменений: 'старое-старое' (функции не меняются), 'старое-новое' (добавляются новые функции) или 'новое' (полностью новый набор функций). 2) Для 'старое-новое' комбинировать бизнес-роли основного и сливаемого подразделений (например, роли из объединяемых департаментов маркетинга и PR объединяются в единую модель). 3) Для 'новое' формировать уникальный набор ролей с нуля, если подразделение создаётся под новые задачи. Ключевой этап — перераспределение ролей между сотрудниками, учитывая новые зоны ответственности.

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

Рейтинг: 783

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

## [Как гибридные модели RBAC и ABAC повышают понятность управления доступом?](https://cleverics.ru/digital/kb-qa/kak-gibridnye-modeli-rbac-i-abac-povyshayut-ponyatnost-upravleniya-dostupom/)

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

Автор: Александр Омельченко

Рейтинг: 783

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

## [Каким образом можно обеспечить практическую пользу от использования CMDB для сотрудников организации?](https://cleverics.ru/digital/kb-qa/kakim-obrazom-mozhno-obespechit-prakticheskuyu-polzu-ot-ispolzovaniya-cmdb-dlya-sotrudnikov-organiza/)

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

Автор: Игорь Фадеев

Рейтинг: 783

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

## [Как определить, когда услуга становится ресурсом для другой услуги?](https://cleverics.ru/digital/kb-qa/kak-opredelit-kogda-usluga-stanovitsya-resursom-dlya-drugoy-uslugi/)

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

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

Рейтинг: 783

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

## [В чем отличие между терминами 'Critical Incident' и 'Major Incident' в практике управления инцидентами?](https://cleverics.ru/digital/kb-qa/v-chem-otlichie-mezhdu-terminami-critical-incident-i-major-incident-v-praktike-upravleniya-intsident/)

В практике управления инцидентами термины 'Critical Incident' и 'Major Incident' часто используются как синонимы, но имеют некоторые различия в трактовке. 'Major Incident' (Значительный инцидент) в ITIL определяется как инцидент с наивысшей категорией влияния, вызывающий существенные потери для бизнеса. Основной акцент делается на необходимости применения специальной процедуры управления, выходящей за рамки обычных процедур. Термин 'Critical Incident' может относиться к инцидентам, критическим для функционирования отдельных систем или компонентов, но не обязательно имеющим широкое влияние на весь бизнес. Таким образом, все Critical Incidents не обязательно являются Major Incidents, но Major Incidents всегда имеют критическое влияние на бизнес в целом.

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

Рейтинг: 783

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

## [Почему попытка определить точный срок поставки задачи в момент принятия решения является неблагодарной?](https://cleverics.ru/digital/kb-qa/pochemu-popytka-opredelit-tochnyy-srok-postavki-zadachi-v-moment-prinyatiya-resheniya-yavlyaetsya-ne/)

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

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

Рейтинг: 783

Теги: DevOps, CI/CD, управление процессами, ИТ-процессы

## [Как системное решение отличается от обходного в контексте исправления ошибок?](https://cleverics.ru/digital/kb-qa/kak-sistemnoe-reshenie-otlichaetsya-ot-obkhodnogo-v-kontekste-ispravleniya-oshibok/)

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

Автор: Александр Движков

Рейтинг: 783

Теги: управление проблемами