# Бесплатная экспертная база знаний по управлению ИТ Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего. Только сведения от консультантов и тренеров Cleverics. Включает ответы на **несколько тысяч вопросов** из **сотен источников**, а также детальный глоссарий с примерами, объяснениями и нюансами ## [Какой уровень вовлеченности внутренней команды необходим для успешного управления слоем middleware при частичном аутсорсе инфраструктуры?](https://cleverics.ru/digital/kb-qa/kakoy-uroven-vovlechennosti-vnutrenney-komandy-neobkhodim-dlya-uspeshnogo-upravleniya-sloem-middlewa/) Для успешного управления слоем middleware при частичном аутсорсе инфраструктуры внутренней команде необходим высокий уровень вовлеченности в процесс настройки, автоматизации и контроля. Требуется, чтобы команда обладала глубокой экспертизой по настройке middleware под специфические потребности продукта, включая оптимизацию под текущую нагрузку, обеспечение безопасности и интеграцию компонентов. Кроме того, важно, чтобы внутренние разработчики умели эффективно работать с системами управления конфигурациями и контроля версий, чтобы все изменения фиксировались в коде и могли быть воспроизведены. При этом внутренняя команда должна принимать решения о конфигурации и контролировать процесс деплоя, оставляя внешним исполнителям только запуск и поддержку базовой инфраструктуры. Автор: Андрей Труфанов Рейтинг: 956 Теги: безопасность, командная работа, общие вопросы менеджмента, поддержка пользователей, Service Desk, Help Desk, управление конфигурациями, CMDB, управление продуктами, продуктовый подход, управление процессами, ИТ-процессы, эффективность, оптимизация ## [Какая роль первичной классификации инцидентов в схеме фиксированной эскалации?](https://cleverics.ru/digital/kb-qa/kakaya-rol-pervichnoy-klassifikatsii-intsidentov-v-skheme-fiksirovannoy-eskalatsii/) Первичная классификация инцидентов играет ключевую роль в схеме фиксированной эскалации, так как от нее напрямую зависит правильность выбора маршрута эскалации. В схеме с фиксированным маршрутом инцидент должен быть корректно отнесен к конкретной ИТ-услуге уже на первой линии поддержки, чтобы он был направлен по заранее определенной цепочке L2-L3-L4. Неправильная классификация приведет к тому, что инцидент будет обработан не теми специалистами, что значительно увеличит время его решения и может нарушить соблюдение SLA. В крупных компаниях с развитым каталогом ИТ-услуг обеспечение высокой точности первичной классификации является сложной задачей, требующей тщательной подготовки первой линии поддержки и хорошо структурированного каталога услуг. Автор: Дмитрий Исайченко Рейтинг: 956 Теги: SLA, общие вопросы менеджмента, поддержка пользователей, Service Desk, Help Desk, управление инцидентами, управление каталогом ИТ-услуг, управление процессами, ИТ-процессы, управление уровнем услуг, SLM ## [Как разрешать ситуации, когда требования не полностью описаны, но возникает спор о дефекте?](https://cleverics.ru/digital/kb-qa/kak-razreshat-situatsii-kogda-trebovaniya-ne-polnostyu-opisany-no-voznikaet-spor-o-defekte/) В ситуациях, когда требования не полностью описаны, но возникает спор о дефекте, решение зависит от выбранной парадигмы работы. При использовании продуктового подхода важно построить такие отношения между владельцем продукта и командой, чтобы команда понимала и учитывала подразумеваемые требования из контекста и здравого смысла. При работе в парадигме 'заказчик-исполнитель' необходимо максимально четко специфицировать все требования, так как исполнитель не обязан думать за заказчика. В идеале команда должна быть настолько погружена в продукт, чтобы понимать логичные требования без явного их описания, что уменьшает количество споров. Автор: Олег Скрынник Рейтинг: 956 Теги: Agile и гибкие методы разработки ПО, бизнес, ценность, бизнес-заказчик, командная работа, разработка ПО, управление продуктами, продуктовый подход ## [Как определить Time in Process, если поток производства работает не круглосуточно?](https://cleverics.ru/digital/kb-qa/kak-opredelit-time-in-process-esli-potok-proizvodstva-rabotaet-ne-kruglosutochno/) Если поток производства не работает круглосуточно (как это обычно бывает в ИТ), Time in Process должен рассчитываться только с учетом рабочего времени, а не полных календарных дней. Это означает, что период времени от начала до завершения задачи должен быть исчислен в рабочих часах или рабочих днях. Например, задача, которая начала обрабатываться в пятницу вечером и завершилась в понедельник утром, должна учитывать только рабочее время между этими временными точками, исключая выходные дни и нерабочие часы. Для этого необходима автоматизация или специальные правила обработки данных, учитывающие календари сотрудников, что значительно усложняет расчет по сравнению с простым вычитанием времени начала из времени завершения. Автор: Олег Скрынник Рейтинг: 956 Теги: Канбан, WIP-лимиты, общие вопросы менеджмента, экономика и финансы ## [Почему важно различать прямые и косвенные методы измерения ценности работы?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-razlichat-pryamye-i-kosvennye-metody-izmereniya-tsennosti-raboty/) Прямые методы (например, скорость прохождения задач) подходят только для конвейерных работ, тогда как для других направений (исследования, гарантия) требуется косвенное измерение через результаты и влияние на общий результат. Непонимание этого приводит к тому, что задачи «нежестких» направлений недооцениваются, что нарушает баланс и снижает общую ценность. Например, игнорирование исследований может увеличить риски и снизить качество решений. Автор: Андрей Труфанов Рейтинг: 956 Теги: бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, управление рисками ## [Почему в ИТ-проектах особенно важно следить за балансом между активностью и аналитикой?](https://cleverics.ru/digital/kb-qa/pochemu-v-it-proektakh-osobenno-vazhno-sledit-za-balansom-mezhdu-aktivnostyu-i-analitikoy/) В ИТ-проектах особенно важно следить за балансом между активностью и аналитикой, потому что работа в этой области часто носит совместный характер и состоит из множества взаимосвязанных этапов. Непродуманные действия на одном этапе могут создать серьезные проблемы на последующих этапах, что приведет к дорогостоящим переездам и задержкам. Из-за высокой сложности и изменчивости требований в ИТ важно тратить время на анализ и уточнение задач, чтобы не создавать ненужного продукта. Кроме того, иллюзия загруженности ресурсов, создаваемая Action Bias, может замаскировать реальные проблемы в процессе и помешать их своевременному выявлению и решению. Автор: Олег Скрынник Рейтинг: 956 Теги: управление продуктами, продуктовый подход, управление проектами, PRINCE2 ## [Какие методы позволяют эффективно измерить Outcome?](https://cleverics.ru/digital/kb-qa/kakie-metody-pozvolyayut-effektivno-izmerit-outcome/) Для измерения Outcome используются методы, учитывающие субъективное восприятие клиента: опросы удовлетворённости, интервью, метрики NPS (Net Promoter Score), анализ поведения пользователей, изучение бизнес-результатов клиента (например, рост продаж после внедрения ИТ-решения). Важно сочетать количественные и качественные подходы, чтобы получить полную картину. Автор: Александр Движков Рейтинг: 956 Теги: бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, поддержка пользователей, Service Desk, Help Desk, управление релизами, управление уровнем услуг, SLM ## [Какие факторы учитываются при установлении срока диагностики проблемы в управлении проблемами?](https://cleverics.ru/digital/kb-qa/kakie-faktory-uchityvayutsya-pri-ustanovlenii-sroka-diagnostiki-problemy-v-upravlenii-problemami/) При установлении срока диагностики проблемы учитываются главным образом уровень влияния проблемы на бизнес-процессы и ее операционную важность. Например, для проблем с высоким уровнем влияния устанавливается более короткий срок диагностики (например, 1 неделя), тогда как для проблем со средним и низким влиянием сроки могут увеличиваться (например, 2 недели и более). Такая дифференциация обоснована тем, что чем выше влияние проблемы на бизнес, тем более срочной является необходимость ее диагностики и поиска решений, чтобы минимизировать ущерб для организации. Автор: Дмитрий Исайченко Рейтинг: 956 Теги: бизнес, ценность, бизнес-заказчик, управление инцидентами, управление проблемами ## [Как оценить необходимость введения OLA в конкретной организации?](https://cleverics.ru/digital/kb-qa/kak-otsenit-neobkhodimost-vvedeniya-ola-v-konkretnoy-organizatsii/) Для оценки необходимость введения OLA в конкретной организации необходимо провести детальный анализ целесообразности. Нужно проверить, действительно ли введение OLA добавит ценность в управление внутренними процессами или просто создаст дополнительный административный груз. Следует оценить возможные последствия: изменится ли организационная структура, насколько сложным будет контроль выполнения обязательств, и действительно ли внутренние подразделения готовы работать в режиме, близком к отношениям с внешними поставщиками. Также важно проверить, будет ли введение OLA упрощать взаимодействие или вносить путаницу, и есть ли уже существующие SLA и UC, которые покрывают необходимые аспекты без дублирования вводом OLA. В большинстве случаев оказывается, что OLA не требуется, и достаточно SLA и UC. Автор: Дмитрий Исайченко Рейтинг: 956 Теги: SLA, аутсорсинг, интеграция услуг, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, общие вопросы менеджмента, управление отношениями, взаимодействие, BRM, управление уровнем услуг, SLM ## [Как связаны понятия 'Ценность' из ITIL 4® и 'Выгоды' из PRINCE2®?](https://cleverics.ru/digital/kb-qa/kak-svyazany-ponyatiya-tsennost-iz-itil-4-i-vygody-iz-prince2/) Понятия 'Ценность' из ITIL 4® и 'Выгоды' из PRINCE2® тесно связаны, так как оба они фокусируются на том, ради чего создается продукт или услуга. В ITIL 4® ценность определяется как результат, который удовлетворяет потребности заинтересованных сторон, тогда как в PRINCE2® выгоды представляют собой измеримые положительные эффекты, которые организация получает от использования результата проекта. Оба понятия подчеркивают важность сфокусироваться не только на создании продукта, но и на том, как он будет использоваться и какие преимущества принесет в дальнейшем. Однако выгоды в PRINCE2® требуют более четкой количественной оценки, чем общее понятие ценности в ITIL 4®. Автор: Игорь Гутник Рейтинг: 956 Теги: ITIL, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, управление продуктами, продуктовый подход, управление проектами, PRINCE2