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

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

## [Как правильно организовать привлечение смежных специалистов в схеме фиксированной эскалации?](https://cleverics.ru/digital/kb-qa/kak-pravilno-organizovat-privlechenie-smezhnykh-spetsialistov-v-skheme-fiksirovannoy-eskalatsii/)

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

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

Рейтинг: 876

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

## [Сколько времени занимает сам процесс учета рабочего времени?](https://cleverics.ru/digital/kb-qa/skolko-vremeni-zanimaet-sam-protsess-ucheta-rabochego-vremeni/)

Процесс учета рабочего времени занимает значительно меньше, чем многие предполагают. За весь 2014 год на эту задачу потребовалось всего 6 часов 4 минуты, что составляет 0,32% всего рабочего времени за год. Это опровергает распространенное мнение о том, что учет времени может занимать от 5% до 10% рабочего времени.

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

Рейтинг: 875

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

## [В чём заключается ошибка сервис-провайдера при работе "проактивно" без понимания целей заказчика?](https://cleverics.ru/digital/kb-qa/v-chem-zaklyuchaetsya-oshibka-servis-provaydera-pri-rabote-proaktivno-bez-ponimaniya-tseley-zakazchi/)

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

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

Рейтинг: 875

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

## [Почему внедрение чат-ботов может быть оправданным, несмотря на имеющиеся проблемы?](https://cleverics.ru/digital/kb-qa/pochemu-vnedrenie-chat-botov-mozhet-byt-opravdannym-nesmotrya-na-imeyushchiesya-problemy/)

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

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

Рейтинг: 875

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

## [Почему недостаточно создать CMDB разовым проектом?](https://cleverics.ru/digital/kb-qa/pochemu-nedostatochno-sozdat-cmdb-razovym-proektom/)

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

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

Рейтинг: 875

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

## [Как правильно объяснять сотрудникам цель использования метрик?](https://cleverics.ru/digital/kb-qa/kak-pravilno-obyasnyat-sotrudnikam-tsel-ispolzovaniya-metrik/)

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

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

Рейтинг: 875

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

## [Какие методы используются для корректного определения общего количества релевантных обращений для расчёта метрик?](https://cleverics.ru/digital/kb-qa/kakie-metody-ispolzuyutsya-dlya-korrektnogo-opredeleniya-obshchego-kolichestva-relevantnykh-obrashch/)

Для корректного определения общего количества релевантных обращений для расчёта метрик FLR и FCR применяются несколько методов. Один из распространённых подходов предполагает, что специалисты второй или третьей линии при закрытии инцидента отмечают, мог ли он быть решён на первой линии. Для запросов на обслуживание заранее определяется, какая линия должна их решать, или применяется аналогичный подход с отметками специалистов. Также используется более "красивое" решение – применение моделей инцидентов, в которых заранее определяется, на какой линии должны решаться подобные инциденты. Этот атрибут затем используется для фильтрации инцидентов при формировании отчётности.

Автор: Дмитрий Хруслов

Рейтинг: 875

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

## [Каковы риски выхода за пределы согласованных технологических окон при внедрении изменений?](https://cleverics.ru/digital/kb-qa/kakovy-riski-vykhoda-za-predely-soglasovannykh-tekhnologicheskikh-okon-pri-vnedrenii-izmeneniy/)

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

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

Рейтинг: 875

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

## [Почему прямой наем сотрудников может быть выгоднее аутстаффинга?](https://cleverics.ru/digital/kb-qa/pochemu-pryamoy-naem-sotrudnikov-mozhet-byt-vygodnee-autstaffinga/)

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

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

Рейтинг: 875

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

## [Какие основные типы регламентирующих документов необходимы для взаимодействия проектного офиса, разработчиков и эксплуатирующих подразделений?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-tipy-reglamentiruyushchikh-dokumentov-neobkhodimy-dlya-vzaimodeystviya-proektnogo-ofi/)

Для взаимодействия проектного офиса, разработчиков и эксплуатирующих подразделений необходимы следующие основные типы регламентирующих документов: 1) Документ, определяющий основные стадии создания новой автоматизированной системы (АС) или выполнения доработок, обычно называемый «Положение о разработке прикладного ПО». Он содержит описание состава работ, ответственных лиц, входных и выходных документов для каждой стадии. Важная особенность – вовлечение эксплуатирующих подразделений в определение требований и проектирование АС. 2) Документ, определяющий порядок приёмки новых АС в эксплуатацию, который может быть частью первого документа и обычно называется «Положение о внедрении информационных систем». Он включает определение порядка и охвата тестирования, подготовки тестовых сред, опытной эксплуатации и других аспектов. Может дополняться политиками релизов. 3) Документ, определяющий архитектурные и технологические стандарты, распространяющиеся на разработку новых решений. Включает определение допустимых языков и сред разработки, используемых платформ и СУБД, механизмов развёртывания, требований к интерфейсам, резервированию, мониторингу, журналированию и другим техническим аспектам. Эти документы образуют совокупный регламент управления изменениями и релизами в части разработки и внедрения прикладного программного обеспечения.

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

Рейтинг: 874

Теги: DevOps, CI/CD, ISO 20000, мониторинг, управление изменениями, управление отношениями, взаимодействие, BRM, управление процессами, ИТ-процессы, управление релизами