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

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

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

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

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

Рейтинг: 1212

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

## [Почему рекомендуется запретить совмещение ролей менеджера и координатора изменений?](https://cleverics.ru/digital/kb-qa/pochemu-rekomenduetsya-zapretit-sovmeshchenie-roley-menedzhera-i-koordinatora-izmeneniy/)

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

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

Рейтинг: 1212

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

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

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

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

Рейтинг: 1212

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

## [Может ли экстренное изменение использоваться для внедрения новых функций?](https://cleverics.ru/digital/kb-qa/mozhet-li-ekstrennoe-izmenenie-ispolzovatsya-dlya-vnedreniya-novykh-funktsiy/)

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

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

Рейтинг: 1212

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

## [Почему в потоке создания ценности не должно быть этапа 'Отложено'?](https://cleverics.ru/digital/kb-qa/pochemu-v-potoke-sozdaniya-tsennosti-ne-dolzhno-byt-etapa-otlozheno/)

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

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

Рейтинг: 1211

Теги: бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, командная работа, поток создания ценности (Value Stream)

## [Как определяется заказчик в случае внутреннего ИТ-подразделения организации?](https://cleverics.ru/digital/kb-qa/kak-opredelyaetsya-zakazchik-v-sluchae-vnutrennego-it-podrazdeleniya-organizatsii/)

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

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

Рейтинг: 1211

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

## [Какие этапы включает методология формирования ИТ-бюджета по ITIL?](https://cleverics.ru/digital/kb-qa/kakie-etapy-vklyuchaet-metodologiya-formirovaniya-it-byudzheta-po-itil/)

Методология формирования ИТ-бюджета по ITIL состоит из пяти основных этапов: получение бизнес-планов через Business Relationship Management (BRM) и Service Level Management (SLM), согласование планов потребления услуг с клиентами (SLM и управление емкостью сервисов), подготовка планов по ресурсному обеспечению включая персонал (Resource Capacity Management), вычисление стоимости ресурсов и услуг с аллокацией косвенных затрат (Financial Management for IT), и окончательный расчет стоимости услуг на основе потребления, приводящий к обоснованному операционному бюджету ИТ.

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

Рейтинг: 1211

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

## [Как управлять эмоциями клиентов (Восток) в цепочке поставки услуги с помощью модели Compass Model?](https://cleverics.ru/digital/kb-qa/kak-upravlyat-emotsiyami-klientov-vostok-v-tsepochke-postavki-uslugi-s-pomoshchyu-modeli-compass-mod/)

Управление эмоциями клиентов (Восток) в цепочке поставки услуги с помощью модели Compass Model включает несколько ключевых этапов: 1) Идентификация ключевых точек взаимодействия, где эмоции наиболее выражены (например, первичный контакт, решение проблемы, завершение взаимодействия). 2) Анализ типичных эмоциональных реакций на каждом этапе (страх, разочарование, радость, облегчение). 3) Разработка стратегий для позитивного влияния на эти эмоции: создание положительных сюрпризов, минимизация стрессовых моментов, поддержка в критических точках. 4) Обучение сотрудников распознавать и эффективно реагировать на эмоции клиентов. 5) Внедрение системы обратной связи, позволяющей отслеживать эмоциональный отклик клиентов. Например, для ИТ-поддержки можно отправлять после решения проблемы сообщение: "Мы рады, что смогли помочь вам сегодня. Ваш запрос был важен для нас". Это управление эмоциями помогает создать позитивные воспоминания об услуге и увеличить лояльность.

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

Рейтинг: 1211

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

## [Какие последствия имеет игнорирование дефектов в программном обеспечении?](https://cleverics.ru/digital/kb-qa/kakie-posledstviya-imeet-ignorirovanie-defektov-v-programmnom-obespechenii/)

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

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

Рейтинг: 1210

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

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

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

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

Рейтинг: 1210

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