Портал №1 по управлению цифровыми
и информационными технологиями

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

Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Questions and answers
6160+

вопросов и ответов

Authors
25

авторов

Sources
440+

источников

Original
100%

оригинальный контент

CMDB (Configuration management data base) - это специализированная база данных, предназначенная для хранения информации о компонентах ИТ-инфраструктуры и их взаимосвязях. CMDB служит центральным хранилищем данных конфигурационных единиц (КЕ), включая их атрибуты, статусы и зависимости. Эта система позволяет ИТ-организациям получить единую точку зрения на все элементы инфраструктуры, что критически важно для эффективного управления изменениями, инцидентами и проблемами. CMDB обеспечивает прозрачность и понимание того, как различные компоненты взаимодействуют между собой и поддерживают конечные пользовательские услуги.
управление изменениями управление инцидентами управление конфигурациями, CMDB
Анна Васильева (источник). Рейтинг вопроса: 237
Нагрузка на первую линию ИТ-поддержки снижается, когда пользователи сами регистрируют обращения через портал самообслуживания и предоставляют всю необходимую информацию в структурированном виде. Это происходит благодаря специализированным формам для разных типов запросов, которые автоматически направляют обращение на вторую линию или во внешние компании. Таким образом, первая линия получает меньше звонков и писем, и ее сотрудники могут сосредоточиться на тех обращениях, которые не могут быть автоматизированы, например, на универсальных запросах или сложных ситуациях, требующих человеческого вмешательства.
поддержка пользователей, Service Desk, Help Desk управление запросами на обслуживание
Евгений Шилов (источник). Рейтинг вопроса: 237
Инциденты лучше предотвращать, чем устранять, потому что проактивная работа по устранению потенциальных причин инцидентов позволяет избежать не только прямых затрат на их устранение, но и косвенных потерь от простоя и снижения производительности бизнеса. Каждый инцидент требует незапланированных ресурсов, отвлекает команду от стратегических задач и ухудшает восприятие качества ИТ-услуг со стороны пользователей. Системный подход через управление проблемами, анализ корневых причин и внедрение постоянных решений позволяет снизить частоту повторяющихся инцидентов, повысить стабильность систем и сократить долгосрочные затраты на поддержку.
аллокация затрат, расчёт себестоимости услуг бизнес, ценность, бизнес-заказчик командная работа мониторинг поддержка пользователей, Service Desk, Help Desk управление инцидентами управление проблемами управление релизами экономика и финансы эффективность, оптимизация
Игорь Фадеев (источник). Рейтинг вопроса: 237
Снижение инвестиций в ИТ напрямую приводит к замедлению или остановке реализации проектов, которые могли бы снизить издержки других подразделений — например, автоматизации процессов или аналитики данных для оптимизации цепочки поставок. В результате, краткосрочное уменьшение OPEX в ИТ может вызвать рост общих затрат компании в будущем или упустить возможности для роста выручки. Это особенно критично для ИТ-зависимых бизнесов, где отсутствие инновационных решений может привести к потере конкурентоспособности.
DevOps, CI/CD аллокация затрат, расчёт себестоимости услуг бизнес, ценность, бизнес-заказчик управление проектами, PRINCE2 управление рисками экономика и финансы эффективность, оптимизация
Дмитрий Исайченко (источник). Рейтинг вопроса: 237
DevOps расширил традиционное Agile понимание завершения разработки, сдвинув критерии завершения дальше в право по временной шкале процесса. Если в Agile работа считается завершенной после принятия ее владельцем продукта, то в DevOps критерий завершения переносится на момент, когда код успешно функционирует в продуктивной среде и, в идеале, когда весь процесс сборки, тестирования и развертывания автоматизирован. Это изменение отражает фокус DevOps на непрерывной доставке ценности конечным пользователям, а не на внутренних проверках и утверждениях.
Agile и гибкие методы разработки ПО DevOps, CI/CD бизнес, ценность, бизнес-заказчик поддержка пользователей, Service Desk, Help Desk разработка ПО управление продуктами, продуктовый подход управление релизами
Олег Скрынник (источник). Рейтинг вопроса: 237
Срывы сроков в проекте могут происходить по нескольким причинам: недостаточная оценка сложности задач при планировании, неправильная оценка доступных ресурсов, отсутствие учета потенциальных рисков, слишком оптимистичные прогнозы, плохая коммуникация внутри команды, частая смена требований со стороны заказчика, а также неумение команды адаптироваться к изменениям. Иногда срыв сроков происходит из-за того, что в начале проекта уделяется слишком много времени на разъяснение правил и установление связей, что отнимает время от выполнения основной работы, как это было в примере с деловой игрой, когда первые этапы заняли значительно больше времени, чем планировалось.
бизнес, ценность, бизнес-заказчик деловые игры, бизнес-симуляции измерение и оценка ИТ, метрики, KPI, отчётность, дашборды командная работа общие вопросы менеджмента управление проектами, PRINCE2 управление рисками
Олег Скрынник (источник). Рейтинг вопроса: 237
При переходе к гибкому управлению ИТ-разработкой необходимы стандарты, которые четко описывают, что организация считает нормальной работой. Это включает стандарты постановки запросов от бизнеса на ИТ-разработку, чтобы команда фокусировалась на создании решений с бизнес-ценностью. Требуются стандарты и KPI для оценки эффективности ресурсов, так как часто до 80% трудовых ресурсов расходуется впустую, а эти специалисты могли бы быть перераспределены между командами с дефицитом кадров. Также необходимы стандарты, определяющие допустимый уровень дефектов, так как часто показатель от 15% до 50% дефектов в объеме работ ошибочно считается нормой, что означает, что половина работы делается заново. Все сотрудники, как со стороны бизнеса, так и со стороны ИТ-департамента, должны стремиться к соблюдению этих стандартов.
Agile и гибкие методы разработки ПО ISO 20000 бизнес, ценность, бизнес-заказчик измерение и оценка ИТ, метрики, KPI, отчётность, дашборды командная работа разработка ПО эффективность, оптимизация
Светлана Сапегина (источник). Рейтинг вопроса: 237
Одной из распространённых ошибок при внедрении системы управления конфигурациями является обращение самой CMDB (Configuration Management Database) в самоцель. Организации часто сосредотачиваются на создании и наполнении базы данных конфигураций, забывая о том, что её основное назначение – поддержка других процессов ИТ-управления. В результате CMS начинает работать как бы сама на себя, без чётко определённых потребителей информации. Такой подход приводит к избыточному сбору данных, которые никем не используются, и к неэффективному использованию ресурсов. Правильная практика предполагает, что построение CMS должно начинаться с определения потребностей бизнес-процессов и конкретных задач, которые эта система должна решать.
бизнес, ценность, бизнес-заказчик поддержка пользователей, Service Desk, Help Desk управление запросами на обслуживание управление конфигурациями, CMDB управление процессами, ИТ-процессы управление релизами
Игорь Гутник (источник). Рейтинг вопроса: 237
Этап согласования необходим для снижения рисков выполнения несанкционированных операций, например, предоставления доступа не к тем ресурсам или не тем пользователям. На этом этапе заявка проходит через несколько уровней утверждения, которые могут включать согласование со стороны непосредственного руководителя пользователя, ответственного за запрашиваемый ресурс, и службы безопасности. В случае если в заявке запрошено несколько ресурсов или работ, только согласованные элементы переходят на этап реализации, что позволяет минимизировать потенциальные ошибки и обеспечивает более строгий контроль над процессом.
безопасность общие вопросы менеджмента поддержка пользователей, Service Desk, Help Desk управление доступом, IDM, ролевые модели, RBAC, ABAC управление запросами на обслуживание управление рисками
Евгений Шилов (источник). Рейтинг вопроса: 237
Парадигма ITSM охватывает все этапы жизненного цикла информационных систем, создавая единый подход к управлению на каждом из них. От этапа планирования и разработки до внедрения, эксплуатации и вывода из эксплуатации - парадигма определяет соответствующие процессы, методики и стандарты, которые обеспечивают непрерывность обслуживания, минимизацию рисков и согласованность действий. Это означает, что жизненный цикл ИТ-систем рассматривается не как последовательность разрозненных этапов, а как единый процесс, управляемый через призму сервисно-ориентированного подхода.
ISO 20000 ITSM общие вопросы менеджмента управление релизами управление рисками
Олег Скрынник (источник). Рейтинг вопроса: 237
« 1 ... 87 88 89 ... 617 »