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

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

## [В каких случаях можно отказаться от использования классификации при маршрутизации обращений?](https://cleverics.ru/digital/kb-qa/v-kakikh-sluchayakh-mozhno-otkazatsya-ot-ispolzovaniya-klassifikatsii-pri-marshrutizatsii-obrashchen/)

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

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

Рейтинг: 1125

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

## [Чем сложнее оценивать успех внутренних inhouse продуктов по сравнению с публичными B2C продуктами?](https://cleverics.ru/digital/kb-qa/chem-slozhnee-otsenivat-uspekh-vnutrennikh-inhouse-produktov-po-sravneniyu-s-publichnymi-b2c-produkt/)

Оценка успеха внутренних inhouse продуктов сложнее по нескольким причинам: во-первых, пользовательская база значительно уже, что затрудняет сбор репрезентативной обратной связи; во-вторых, между покупателем (спонсором) и непосредственным пользователем часто существует разрыв интересов и потребностей; в-третьих, цикл адаптации и внедрения продукта занимает значительное время (обычно 3+ месяцев); в-четвертых, отсутствует возможность многократного предложения продукта в случае неудачи; в-пятых, финансовая успешность продукта может не напрямую коррелировать с его функциональными характеристиками из-за дискретности продаж и специфики корпоративных решений. Также возникают сложности с получением данных об использовании продукта из-за организационных и технических ограничений внутри компании. Для объективной оценки успеха таких продуктов требуется создание отдельных каналов коммуникации с покупателем и пользователями, измерение TTV (Time-To-Value) - времени достижения ценности продуктом для заказчика, и учет специфики требований разных клиентов.

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

Рейтинг: 1125

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

## [Что включает в себя понятие двухскоростного ИТ и как оно возникает в компаниях?](https://cleverics.ru/digital/kb-qa/chto-vklyuchaet-v-sebya-ponyatie-dvukhskorostnogo-it-i-kak-ono-voznikaet-v-kompaniyakh/)

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

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

Рейтинг: 1125

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

## [Как постепенное 'протухание' отложенных задач влияет на качество работы?](https://cleverics.ru/digital/kb-qa/kak-postepennoe-protukhanie-otlozhennykh-zadach-vliyaet-na-kachestvo-raboty/)

Постепенное 'протухание' отложенных задач негативно влияет на качество работы тем, что с каждым днем пребывания в статусе 'Отложено' задача становится менее актуальной и нужной. Результат теряет ценность, что соответствует принципу бережливого производства: 'Незавершёнка есть потери!'. Кроме того, команда постепенно теряет контекст работы над задачей - забывает, что именно нужно было сделать, почему задача отложена, что осталось сделать и как исправить возможные проблемы. Это приводит к росту дефектов в конечном продукте и необходимости специализированного управления дефектами.

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

Рейтинг: 1125

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

## [Какие факторы влияют на мотивацию пользователя оставить обратную связь по услуге?](https://cleverics.ru/digital/kb-qa/kakie-faktory-vliyayut-na-motivatsiyu-polzovatelya-ostavit-obratnuyu-svyaz-po-usluge/)

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

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

Рейтинг: 1125

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

## [Почему важно разделять инциденты и проблемы в ITIL?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-razdelyat-intsidenty-i-problemy-v-itil/)

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

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

Рейтинг: 1125

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

## [Какие ошибки совершают поставщики при определении ценности для потребителей?](https://cleverics.ru/digital/kb-qa/kakie-oshibki-sovershayut-postavshchiki-pri-opredelenii-tsennosti-dlya-potrebiteley/)

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

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

Рейтинг: 1125

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

## [Как часто следует проводить аудит CMDB?](https://cleverics.ru/digital/kb-qa/kak-chasto-sleduet-provodit-audit-cmdb/)

Частота аудита CMDB определяется критичностью инфраструктурных компонентов и интенсивностью изменений. Для высоконагруженных систем (например, корпоративные серверы) рекомендуется проверять данные ежеквартально, для менее критичных компонентов (офисные ПК) — раз в полгода. При высоком уровне изменений (например, активная миграция в облако) частота увеличивается до ежемесячной. Также проводится внеплановый аудит после выявления системных ошибок, связанных с некорректными данными CMDB, или при изменении регуляторных требований.

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

Рейтинг: 1125

Теги: автоматизация ИТ-процессов, ПО для ITSM и ESM, аудит, управление конфигурациями, CMDB

## [Почему важно обучать персонал вопросам управления проблемами?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-obuchat-personal-voprosam-upravleniya-problemami/)

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

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

Рейтинг: 1125

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

## [Какие ограничения должны быть установлены для полномочий координаторов изменений?](https://cleverics.ru/digital/kb-qa/kakie-ogranicheniya-dolzhny-byt-ustanovleny-dlya-polnomochiy-koordinatorov-izmeneniy/)

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

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

Рейтинг: 1125

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