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

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

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

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

Authors
25

авторов

Sources
440+

источников

Original
100%

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

Value Streams (потоки ценности) в ITSM - это последовательность действий, которые создают ценность для клиента и бизнеса. Внедрение сквозных Value Streams помогает отслеживать все шаги от технической реализации до конечной ценности для клиента. Например, при внедрении чат-бота Value Stream включает: выход (сам бот), клиентское действие (самостоятельное решение проблемы за 2 минуты) и конечный результат (сокращение затрат на поддержку на 500 000 рублей в год и повышение уровня удовлетворенности клиентов). Это позволяет видеть, как техническая работа влияет на реальные бизнес-результаты, а не просто генерирует отчеты и выполненные задачи.
ITSM аллокация затрат, расчёт себестоимости услуг бизнес, ценность, бизнес-заказчик измерение и оценка ИТ, метрики, KPI, отчётность, дашборды Канбан, WIP-лимиты поддержка пользователей, Service Desk, Help Desk поток создания ценности (Value Stream) управление релизами экономика и финансы
Игорь Фадеев (источник). Рейтинг вопроса: 203
Некоторые элементы продуктового подхода полезны даже когда настоящего продукта нет. Сюда входит концентрация на ценности, а не на функциональности; четкое определение границ и зависимостей между командами; использование дорожных карт, даже если они изначально представляют собой просто планы релизов функциональности; организация рабочего процесса вокруг создания ценности, а не просто процесса разработки ПО; формирование продуктовых (а не проектных) команд; применение продуктовых метрик, даже если вместо стандартных MAU/DAU измеряется, например, уровень использования функциональности. Эти элементы могут принести пользу, даже если не все критерии продуктового подхода выполняются, и не имеют негативных последствий при правильной реализации.
Agile и гибкие методы разработки ПО бизнес, ценность, бизнес-заказчик измерение и оценка ИТ, метрики, KPI, отчётность, дашборды командная работа разработка ПО управление продуктами, продуктовый подход управление релизами
Олег Скрынник (источник). Рейтинг вопроса: 203
Определение доступности для конкретной ИТ-услуги формируется на основе анализа, что именно предоставляет услуга потребителю. Для ресурсных услуг это анализ функций ресурса (например, канал связи, API), их дефектов и времени отклика. Для услуг, связанных с выполнением работ, это оценка отзывчивости интерфейсов и соблюдения сроков по SLA. Определение формулируется совместно с заказчиком и фиксируется в соглашении, включая временные интервалы доступности и критерии нарушения.
Agile и гибкие методы разработки ПО SLA бизнес, ценность, бизнес-заказчик измерение и оценка ИТ, метрики, KPI, отчётность, дашборды разработка ПО управление доступностью управление уровнем услуг, SLM
Андрей Труфанов (источник). Рейтинг вопроса: 203
В процессе «Управление проблемами» выбор между полным решением проблемы и временным обходным путем (workaround) определяется на основе оценки ресурсов, требуемых для реализации каждого варианта, и ожидаемого бизнес-влияния. Процесс подразумевает, что не всегда целесообразно тратить значительные ресурсы на полное устранение проблемы, особенно если частота инцидентов низкая или влияние на бизнес незначительно. Если стоимость постоянного решения превышает выгоду от его внедрения, выбирается временный обходной путь с документированием в виде «известной ошибки». Решение принимается после анализа соотношения затрат и выгод для бизнеса в конкретной ситуации.
аллокация затрат, расчёт себестоимости услуг бизнес, ценность, бизнес-заказчик измерение и оценка ИТ, метрики, KPI, отчётность, дашборды управление инцидентами управление проблемами управление релизами экономика и финансы
Игорь Гутник (источник). Рейтинг вопроса: 203
Для эффективного управления проблемами необходимо: 1) Четко отличать проблемы от инцидентов и не смешивать эти понятия; 2) Сформулировать бизнес-ценность управления проблемами и оценить негативное влияние от инцидентов; 3) Сфокусироваться на проактивной деятельности, а не только на реактивной; 4) Обеспечить доступ сервисных команд к базе известных ошибок (KEDB); 5) Регулярно измерять эффективность работы в управлении проблемами; 6) Инвестировать в устойчивость систем и обучение персонала; 7) Постоянно анализировать эффективность обходных решений и оценивать целесообразность применения постоянных решений.
бизнес, ценность, бизнес-заказчик командная работа обучение сотрудников, учебные курсы, тренинги управление доступом, IDM, ролевые модели, RBAC, ABAC управление инцидентами управление проблемами эффективность, оптимизация
Игорь Фадеев (источник). Рейтинг вопроса: 203
Игнорирование управления ИТ-архитектурой при создании системы управления задачами приводит к критическим пробелам в процессе управления. Принятие решений по архитектуре, её документирование и развитие имеют непосредственное отношение к созданию эффективной системы управления задачами. Без чёткой архитектурной стратегии становится невозможно определить, как принимать решения по архитектурным изменениям, как документировать их и как поддерживать качество архитектуры в долгосрочной перспективе. Это приводит к несогласованности процессов, увеличивает риски возникновения ошибок и снижает производительность всей системы управления задачами. Следовательно, необходимо интегрировать управление архитектурой в процесс создания системы управления задачами для обеспечения её надёжности и эффективности.
архитектура ИТ, TOGAF и IT4IT мониторинг стратегия управление процессами, ИТ-процессы управление рисками эффективность, оптимизация
Олег Скрынник (источник). Рейтинг вопроса: 203
Для того чтобы время реакции на инциденты было показательной метрикой, необходимо фиксировать момент фактического начала работы над инцидентом. Это означает, что инцидент следует брать в работу только в тот момент, когда специалист действительно готов приступить к его решению, а не заранее из-за стремления показать хорошую статистику. Время реакции должно измеряться от момента назначения инцидента на сотрудника до фактического начала его обработки. Внедрение четких процедур регистрации начала работы и обучение сотрудников правильной практике регистрации помогут обеспечить достоверность этой метрики и ее полезность для анализа процессов управления инцидентами.
бизнес, ценность, бизнес-заказчик измерение и оценка ИТ, метрики, KPI, отчётность, дашборды обучение сотрудников, учебные курсы, тренинги управление инцидентами управление релизами
Дмитрий Исайченко (источник). Рейтинг вопроса: 203
Новые сотрудники, попадая в компанию с искаженной нормой, проходят определенную кривую принятия изменений. Сначала они удивляются несоответствию между заявленными процессами и реальным положением дел, затем отказываются верить в увиденное и начинают спорить с коллегами. После этого они пытаются договориться об улучшениях, но, сталкиваясь с сопротивлением, постепенно смиряются с существующим порядком. Далее возможны два варианта: либо сотрудник подстраивается под сложившуюся систему и теряет желание менять что-либо («болото его засасывает»), либо продолжает активно работать над улучшениями и постепенно влияет на культуру команды («осушает болото»).
командная работа постоянное улучшение, совершенствование, CSI, PDCA эффективность, оптимизация
Олег Скрынник (источник). Рейтинг вопроса: 203
При трансляции ожиданий заказчика в формальные требования к услугам возникает несколько серьезных проблем: 1) Часто заказчик затрудняется четко сформулировать свои реальные потребности и ожидания, выражая их в общих и расплывчатых формулировках; 2) Сервис-провайдер сталкивается с трудностями в правильной интерпретации и расшифровке этих нечетко сформулированных требований; 3) Ожидания заказчика часто завышены или не соответствуют реальным возможностям сервис-провайдера; 4) Отсутствие глубокого понимания бизнес-процессов заказчика у сотрудников сервис-провайдера приводит к неправильной интерпретации реальных потребностей.
аутсорсинг, интеграция услуг бизнес, ценность, бизнес-заказчик управление уровнем услуг, SLM
Павел Дёмин (источник). Рейтинг вопроса: 203
Активно расширяющиеся компании выделяют на 'развитие и управление ИТ' лишь 1-2% от общего размера ИТ-бюджета, что значительно меньше, чем компании, придерживающиеся стратегии выживания (которые выделяют 4-8%).
бюджетирование, планирование затрат стратегия эффективность, оптимизация
Дмитрий Исайченко (источник). Рейтинг вопроса: 203
« 1 ... 239 240 241 ... 617 »