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

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

## [Как влияет текучесть кадров на реализацию успешного портала самообслуживания?](https://cleverics.ru/digital/kb-qa/kak-vliyaet-tekuchest-kadrov-na-realizatsiyu-uspeshnogo-portala-samoobsluzhivaniya/)

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

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

Рейтинг: 677

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

## [Почему даже при наличии региональной структуры поддержки может потребоваться классификация обращений?](https://cleverics.ru/digital/kb-qa/pochemu-dazhe-pri-nalichii-regionalnoy-struktury-podderzhki-mozhet-potrebovatsya-klassifikatsiya-obr/)

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

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

Рейтинг: 677

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

## [Как бизнес может изменить условия базового SLA после его введения?](https://cleverics.ru/digital/kb-qa/kak-biznes-mozhet-izmenit-usloviya-bazovogo-sla-posle-ego-vvedeniya/)

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

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

Рейтинг: 677

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

## [Как формируется ответственность в модели BPO?](https://cleverics.ru/digital/kb-qa/kak-formiruetsya-otvetstvennost-v-modeli-bpo/)

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

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

Рейтинг: 677

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

## [Зачем нужно разделять этапы жизненного цикла инцидента, если можно просто измерять общее время простоя?](https://cleverics.ru/digital/kb-qa/zachem-nuzhno-razdelyat-etapy-zhiznennogo-tsikla-intsidenta-esli-mozhno-prosto-izmeryat-obshchee-vre/)

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

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

Рейтинг: 677

Теги: управление инцидентами

## [Какие ошибки чаще всего допускаются при использовании метода 5-Why's?](https://cleverics.ru/digital/kb-qa/kakie-oshibki-chashche-vsego-dopuskayutsya-pri-ispolzovanii-metoda-5-why-s/)

Типичные ошибки при использовании метода 5-Why's включают преждевременное завершение анализа на поверхностном уровне, игнорирование множественных параллельных причин, субъективное построение цепочки без проверки фактов и уход за границы зоны влияния. Также распространена ошибка интерпретации симптомов как причин. Для избежания ошибок важно проводить анализ командно, с привлечением экспертов разных областей и использовать дополнительные данные для подтверждения каждой гипотезы причины.

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

Рейтинг: 677

Теги: командная работа

## [Каковы семь руководящих принципов ITIL?](https://cleverics.ru/digital/kb-qa/kakie-sem-rukovodyashchikh-printsipov-itil-upominayutsya-v-tekste/)

В тексте упоминаются следующие семь руководящих принципов ITIL: 1) Сфокусируйтесь на ценности (семь раз отмерь – один отрежь); 2) Сотрудничайте и поощряйте прозрачность (доверяй, но проверяй); 3) Простота и практичность (не усложняйте себе жизнь); 4) Действуйте итерационно, используя обратную связь (как аукнется – так и откликнется). Названо только четыре принципа из семи, но текст указывает, что полный список описан в статье Игоря Гутника.

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

Рейтинг: 677

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

## [Как термины «готовность» и «доступность» отражаются в международных и российских стандартах?](https://cleverics.ru/digital/kb-qa/kak-terminy-gotovnost-i-dostupnost-otrazhayutsya-v-mezhdunarodnykh-i-rossiyskikh-standartakh/)

В российских стандартах (ГОСТ 27.002-89, ГОСТ Р 53480-2009) применяется термин «готовность», заимствованный из теории надежности и ориентированный на технические характеристики. Международные стандарты ITIL и ISO/IEC 20000 используют термин «доступность» (availability), который в контексте ИТ-управления включает не только техническую работоспособность, но и организационные аспекты предоставления услуги. Это различие сохраняется в профессиональной литературе и требует адаптации терминологии при локализации документов.

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

Рейтинг: 677

Теги: ISO 20000, ITIL, управление доступностью

## [Почему некоторые компании всё же используют отдельные инструменты для учёта активов и экономических расчётов?](https://cleverics.ru/digital/kb-qa/pochemu-nekotorye-kompanii-vse-zhe-ispolzuyut-otdelnye-instrumenty-dlya-ucheta-aktivov-i-ekonomiches/)

Некоторые компании используют отдельные инструменты для учёта активов и экономических расчётов, потому что их программное обеспечение изначально разрабатывалось как разделённое — например, HP имеет отдельные продукты для ITSM (HPSM с CMDB) и для управления активами (HP Asset Manager с AMDB). Также некоторые разработчики продуктов не хотят, чтобы их инструменты зависели от наличия развитых ITSM-решений у заказчиков, поэтому они делают свои системы независимыми. Однако это обусловлено программно-архитектурными ограничениями конкретных решений, а не общими рекомендациями или лучшими практиками. Такие решения не всегда отражают наиболее эффективный подход к совмещению функциональности.

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

Рейтинг: 677

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

## [Как руководитель может создать эффективный канал обратной связи с командой в рамках DevOps?](https://cleverics.ru/digital/kb-qa/kak-rukovoditel-mozhet-sozdat-effektivnyy-kanal-obratnoy-svyazi-s-komandoy-v-ramkakh-devops/)

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

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

Рейтинг: 676

Теги: DevOps, CI/CD, командная работа, общие вопросы менеджмента, управление продуктами, продуктовый подход, управление процессами, ИТ-процессы