# Бесплатная экспертная база знаний по управлению ИТ Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего. Только сведения от консультантов и тренеров Cleverics. Включает ответы на **несколько тысяч вопросов** из **сотен источников**, а также детальный глоссарий с примерами, объяснениями и нюансами ## [Как связаны между собой процедура приема заявки в работу и механизм автоматической эскалации?](https://cleverics.ru/digital/kb-qa/kak-svyazany-mezhdu-soboy-protsedura-priema-zayavki-v-rabotu-i-mekhanizm-avtomaticheskoy-eskalatsii/) Механизм автоматической эскалации напрямую зависит от четкой процедуры фиксации факта приема заявки в работу. Для корректной работы автоматической эскалации необходимо, чтобы специалист сначала явно отметил, что он взял заявку в работу, а только потом зафиксировал ее решение. Это важно потому, что автоматическая эскалация должна срабатывать только тогда, когда заявка не была принята в работу в течение отведенного времени. Однако в реальной практике специалисты часто пропускают этап фиксации приема заявки в работу, особенно в условиях срочной работы или при массовых обращениях, что делает механизм автоматической эскалации ненадежным и потенциально приводит к некорректным эскалациям. Автор: Дмитрий Исайченко Рейтинг: 1280 Теги: общие вопросы менеджмента, управление запросами на обслуживание ## [Какие группы конфигурационных единиц учитываются в CMDB и как они влияют на процесс оценки трудозатрат?](https://cleverics.ru/digital/kb-qa/kakie-gruppy-konfiguratsionnykh-edinits-uchityvayutsya-v-cmdb-i-kak-oni-vliyayut-na-protsess-otsenki/) В CMDB конфигурационные единицы можно разделить на четыре группы: ИТ-системы, бизнес-приложения, технологические элементы бизнес-приложений и инфраструктура. Эти группы обусловлены принципиальными различиями в характере выполняемых задач в отношении к этим категориям единиц. Разные группы конфигурационных единиц, как правило, обслуживают разные специалисты, чье время может стоить по-разному. Кроме того, структура информации и источники ее получения для разных групп также различны. Это делает необходимым оценивать трудозатраты в детальной разбивке по группам и учитывать требования к компетенциям исполнителей. Такая детализация позволяет более точно спланировать необходимые ресурсы для сопровождения CMDB. Автор: Артём Мукосеев Рейтинг: 1280 Теги: аллокация затрат, расчёт себестоимости услуг, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, управление конфигурациями, CMDB ## [Что такое work-in-progress limit в методологии Kanban и зачем он нужен?](https://cleverics.ru/digital/kb-qa/chto-takoe-work-in-progress-limit-v-metodologii-kanban-i-zachem-on-nuzhen/) Work-in-progress limit (лимит текущей загрузки) в методологии Kanban — это ограничение на максимальное количество задач, которые могут находиться в статусе "в работе" одновременно. Он необходим для предотвращения перегрузки сотрудников, повышения фокуса на текущих задачах и ускорения завершения работ. Такой подход минимизирует переключение между задачами, сокращает время выполнения и повышает качество результатов. Лимиты помогают выявить узкие места в процессе и оптимизировать поток работ. Автор: Дмитрий Исайченко Рейтинг: 1279 Теги: Канбан, WIP-лимиты, трансформация, ускорение, Time-to-Market ## [Чем отличаются понятия Utility и Warranty в управлении услугами?](https://cleverics.ru/digital/kb-qa/chem-otlichayutsya-ponyatiya-utility-i-warranty-v-upravlenii-uslugami/) Utility (Полезность) и Warranty (Гарантия) являются двумя основными характеристиками услуги. Utility отвечает на вопрос fit for purpose - пригодность к цели, помогает ли услуга пользователю достичь желаемого результата. Например, свет в темной комнате полезен для чтения книги. Warranty отвечает на вопрос fit for use - пригодность к использованию, представляет собой четыре компонента: доступность, мощность, безопасность и непрерывность. Услуга может иметь высокую полезность (помогает достичь цели), но низкую гарантию (например, свет мигает, что затрудняет чтение). Полезность определяет соответствие услуги цели, а гарантия - условия, в которых услуга может быть использована. Автор: Александр Движков Рейтинг: 1279 Теги: безопасность, бизнес, ценность, бизнес-заказчик, поддержка пользователей, Service Desk, Help Desk, управление доступностью, управление уровнем услуг, SLM ## [В чем заключается ценность ITIL для руководителей сервисных организаций?](https://cleverics.ru/digital/kb-qa/v-chem-zaklyuchaetsya-tsennost-itil-dlya-rukovoditeley-servisnykh-organizatsiy/) Для руководителей сервисных организаций в любой отрасли ITIL предоставляет понятную структуру для управления услугами. Это помогает в формировании стратегии, организации системы учета затрат, управлении изменениями и постоянном совершенствовании процессов. ITIL содержит ценную информацию, даже если язык описания в литературе может показаться сложным для обычных специалистов. Руководителям проще понять и применить эти принципы, особенно если компания имеет определенную зрелость в управлении. Автор: Елена Колбей Рейтинг: 1279 Теги: ITIL, аллокация затрат, расчёт себестоимости услуг, бизнес, ценность, бизнес-заказчик, общие вопросы менеджмента, постоянное улучшение, совершенствование, CSI, PDCA, стратегия, управление изменениями, управление процессами, ИТ-процессы, экономика и финансы ## [Как оценить, насколько команда готова к переходу на более частые релизы?](https://cleverics.ru/digital/kb-qa/kak-otsenit-naskolko-komanda-gotova-k-perekhodu-na-bolee-chastye-relizy/) Готовность команды к переходу на более частые релизы можно оценить по следующим критериям: уровень автоматизации процессов сборки и тестирования (чем выше, тем лучше); наличие стабильных и легко воспроизводимых тестовых сред; степень покрытия кода автоматическими тестами; способность команды обнаруживать и исправлять проблемы в течение короткого времени; размер типичных изменений в релизе (маленькие изменения предпочтительнее); зрелость процесса обратной связи от production; способность к быстрому развёртыванию отката в случае проблем; культура совместной ответственности за качество; опыт работы с практиками непрерывной интеграции. Также можно использовать метрики, такие как среднее время восстановления после сбоя (MTTR), процент прохождения автоматических тестов, время от коммита до развёртывания. Чем лучше выполнены эти критерии, тем выше готовность команды к частым релизам. Автор: Олег Скрынник Рейтинг: 1278 Теги: DevOps, CI/CD, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, командная работа, мониторинг, общие вопросы менеджмента, управление инцидентами, управление проблемами, управление продуктами, продуктовый подход, управление процессами, ИТ-процессы, управление релизами ## [Какие последствия возникают, когда руководитель не может правильно распределить задачи между членами команды?](https://cleverics.ru/digital/kb-qa/kakie-posledstviya-voznikayut-kogda-rukovoditel-ne-mozhet-pravilno-raspredelit-zadachi-mezhdu-chlena/) Неправильное распределение задач приводит к ряду негативных последствий: руководитель становится перегруженным рутинной работой, теряет контроль над стратегическими вопросами, снижается эффективность всей команды. В примере с деловой игрой Apollo-13 менеджер инцидентов, ставший маршрутизатором заявок, не смог обеспечить необходимый контроль за выполнением задач, в результате решено только 44% инцидентов, а среднее время решения увеличилось почти вдвое по сравнению с установленными SLA. Также может возникнуть хаос, потеря заявок и замедление работ, когда руководитель постоянно вмешивается в задачи сотрудников. Автор: Олег Скрынник Рейтинг: 1278 Теги: SLA, деловые игры, бизнес-симуляции, командная работа, общие вопросы менеджмента, управление запросами на обслуживание, управление инцидентами, управление уровнем услуг, SLM, эффективность, оптимизация ## [Почему в ITIL4 важно понимать, какие риски и затраты перекладывает на поставщика клиент?](https://cleverics.ru/digital/kb-qa/pochemu-v-itil4-vazhno-ponimat-kakie-riski-i-zatraty-perekladyvaet-na-postavshchika-klient/) В ITIL4 понимание рисков и затрат, которые клиент перекладывает на поставщика, является ключевым для определения ценности услуги. Услуга существует только тогда, когда клиент передает поставщику определенные риски и затраты, связанные с получением желаемой ценности. Без этого перекладывания ответственности продажа сводится просто к передаче товара. Например, при покупке автомобиля в салоне, если клиент просто получает машину и все дальнейшие риски по ее эксплуатации лежат на нем, это не услуга в контексте ITIL. Но если речь идет о каршеринге, где поставщик несет ответственность за страховку, обслуживание и ремонт, то это уже услуга, так как клиент перекладывает на поставщика определенные риски и затраты. Автор: Артём Мукосеев Рейтинг: 1278 Теги: ITIL, аллокация затрат, расчёт себестоимости услуг, аутсорсинг, интеграция услуг, бизнес, ценность, бизнес-заказчик, общие вопросы менеджмента, управление рисками, экономика и финансы ## [Почему результаты (Outcome) сложнее измерять, чем выходы (Output)?](https://cleverics.ru/digital/kb-qa/pochemu-rezultaty-outcome-slozhnee-izmeryat-chem-vykhody-output/) Outcome зависит от субъективного восприятия потребителя и часто выражается в нематериальных или долгосрочных эффектах, которые сложно зафиксировать количественно. В то время как Output обычно имеет чёткие количественные параметры (например, сроки доставки, объём функционала), что позволяет легко его измерять и отчитываться о нём. Для оценки Outcome необходимо собирать обратную связь, проводить опросы удовлетворённости или анализировать поведение клиентов. Автор: Александр Движков Рейтинг: 1278 Теги: бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, управление продуктами, продуктовый подход, управление процессами, ИТ-процессы, управление уровнем услуг, SLM ## [Почему внедрение SLA между отделом маркетинга и отделом продаж считается прогрессивным подходом в управлении бизнесом?](https://cleverics.ru/digital/kb-qa/pochemu-vnedrenie-sla-mezhdu-otdelom-marketinga-i-otdelom-prodazh-schitaetsya-progressivnym-podkhodo/) Внедрение SLA между отделом маркетинга и отделом продаж считается прогрессивным подходом, потому что оно устанавливает чёткие взаимные обязательства между этими подразделениями, которые часто работают в режиме 'кто виноват', когда цели и задачи не согласованы. SLA преобразует традиционные внутренние отношения в сервисные, где каждое подразделение воспринимается как поставщик услуг для другого. Это позволяет измерять эффективность работы каждого отдела объективно, выявлять узкие места и создавать основу для постоянного улучшения. Кроме того, практика использования SLA в маркетинге и продажах стала распространённой среди успешных компаний и стартапов, что подтверждает её эффективность. Автор: Олег Скрынник Рейтинг: 1278 Теги: SLA, аутсорсинг, интеграция услуг, бизнес, ценность, бизнес-заказчик, постоянное улучшение, совершенствование, CSI, PDCA, управление релизами, управление уровнем услуг, SLM, эффективность, оптимизация