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

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

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

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

Authors
25

авторов

Sources
440+

источников

Original
100%

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

Согласно COBIT, уровни зрелости процессов имеют исключительно иллюстративный смысл. Они используются для наглядного представления текущего состояния процесса или разницы между текущим и целевым состояниями, но не предназначены для точной количественной оценки. Уровень зрелости является побочным продуктом обследования, а не основной метрикой. Его не следует воспринимать чересчур серьезно, поскольку один и тот же процесс может проявлять признаки нескольких уровней зрелости одновременно, и разные аудиторы могут давать разные оценки одному процессу, даже используя одни и те же контрольные показатели.
COBIT аудит измерение и оценка ИТ, метрики, KPI, отчётность, дашборды управление продуктами, продуктовый подход управление процессами, ИТ-процессы
Дмитрий Исайченко (источник). Рейтинг вопроса: 240
Первый способ, при котором обращение остается на первой линии, а на вторую назначается задание, может быть менее эффективным из-за нескольких факторов. Возникает риск потери важной информации между основным обращением и заданиями, усложняется отслеживание полного статуса решения инцидента, так как информация рассредоточена между основной записью и заданиями. Кроме того, ответственность за решение может быть нечетко распределена, что может приводить к замедлению процесса решения проблемы. Этот метод требует более сложной координации при работе со сложными инцидентами, требующими участия нескольких групп.
общие вопросы менеджмента поддержка пользователей, Service Desk, Help Desk управление запросами на обслуживание управление инцидентами управление рисками
Дмитрий Исайченко (источник). Рейтинг вопроса: 240
Основная ответственность роли менеджера уровня услуг в ITILv3 связана с обеспечением достижения договоренностей об уровне услуги и их соблюдением. Это этакий интерфейс между поставщиком и заказчиком, который действует как представитель заказчика при общении с ИТ-персоналом и как представитель ИТ-поставщика при взаимодействии с клиентами. Эта роль, описанная в библиотеке ITILv3 (2011 г.), фокусируется на управлении услугой, а не на процессе как таковом.
аутсорсинг, интеграция услуг бизнес, ценность, бизнес-заказчик общие вопросы менеджмента управление отношениями, взаимодействие, BRM управление процессами, ИТ-процессы
Игорь Гутник (источник). Рейтинг вопроса: 240
Да, Incident Rate может использоваться для повышения доступности ИТ-услуг. Снижение значения метрики через оптимизацию процессов, улучшение качества сервиса и профилактику проблем приведёт к сокращению количества инцидентов. Например, внедрение автоматизации обработки стандартных запросов, повышение уровня документации и обучение сотрудников поможет снизить количество обращений, что положительно отразится на доступности систем.
измерение и оценка ИТ, метрики, KPI, отчётность, дашборды обучение сотрудников, учебные курсы, тренинги постоянное улучшение, совершенствование, CSI, PDCA управление доступностью управление запросами на обслуживание управление инцидентами управление релизами эффективность, оптимизация
Дмитрий Исайченко (источник). Рейтинг вопроса: 240
CMDB связана с управлением мощностями и производительностью ИТ-услуг, предоставляя информацию о текущих компонентах и их характеристиках. Это позволяет своевременно оценивать потребности в увеличении ресурсов при росте нагрузки на услуги. Зная структуру услуг и взаимосвязи компонентов, можно прогнозировать, как изменение объема потребления повлияет на отдельные части инфраструктуры и какие ресурсы потребуется увеличить в первую очередь. Это помогает оптимизировать инвестиции в инфраструктуру и обеспечивать необходимый уровень мощности и производительности ИТ-услуг.
мониторинг управление конфигурациями, CMDB управление мощностями экономика и финансы эффективность, оптимизация
Анна Васильева (источник). Рейтинг вопроса: 240
Измерение востребованности фичи только по статистическим показателям, таким как увеличение конверсии на 0,07% или количество пользователей, открывших меню и сразу закрывших его, может быть недостаточным, потому что такие абстрактные цифры не создают эмоциональной связи у разработчиков с результатом их работы. Для большинства разработчиков это просто бессмысленные числа, которые не мотивируют и не показывают реального влияния их труда. Вместо этого важно демонстрировать живые реакции пользователей: негативные или позитивные отзывы, появление новых запросов связанных с новой опцией, реакции на презентации продукта. Такой подход позволяет разработчикам понять, что их работа имеет значение и действительно влияет на пользовательский опыт, что значительно повышает их вовлеченность и мотивацию.
измерение и оценка ИТ, метрики, KPI, отчётность, дашборды мотивация персонала, стимулирование поддержка пользователей, Service Desk, Help Desk управление продуктами, продуктовый подход
Андрей Труфанов (источник). Рейтинг вопроса: 240
В ITIL4 стандартное изменение определяется как изменение с низким риском, низким уровнем влияния, заранее авторизованное и выполняемое по утвержденной процедуре без необходимости дополнительной авторизации для каждого отдельного случая. Основные критерии включают: низкий уровень риска, предсказуемость результатов, наличие утвержденной методики выполнения, возможность выполнения без дополнительной оценки рисков для каждого экземпляра и предварительную авторизацию модели выполнения изменения. Стандартные изменения также отличаются тем, что их оценка рисков проводится один раз при создании или пересмотре процедуры выполнения.
измерение и оценка ИТ, метрики, KPI, отчётность, дашборды управление изменениями управление рисками
Артём Мукосеев (источник). Рейтинг вопроса: 240
Масштаб не является основной причиной трудностей при организационных изменениях, потому что даже небольшие улучшения (например, добавление нового способа взаимодействия с Service Desk) могут быть реализованы относительно легко, тогда как крупные преобразования часто сталкиваются со сложностями, несмотря на наличие ресурсов. Основные проблемы кроются не в размере изменений, а в трех глубинных причинах: противоречии между требованиями менеджмента и лидерства, индивидуальном сопротивлении сотрудников и системном сопротивлении самой организации. Эти факторы присутствуют при любом масштабе изменений, но проявляются особенно сильно в крупных проектах, где задействовано много людей и процессов.
лидерство организационные изменения, агенты изменений поддержка пользователей, Service Desk, Help Desk постоянное улучшение, совершенствование, CSI, PDCA управление отношениями, взаимодействие, BRM управление проектами, PRINCE2 эффективность, оптимизация
Олег Скрынник (источник). Рейтинг вопроса: 240
Команда не может выделить все свое время на новые разработки по нескольким причинам. Во-первых, появление багов, которые становятся приоритетом, поскольку нестабильное или нефункциональное приложение приводит к прямым финансовым потерям, снижает конверсию, отпугивает лояльных пользователей и вызывает недоверие клиентов. Во-вторых, необходимость участия в upstream-активностях, таких как оценка задач, формирование гипотез и принятие архитектурных решений. В-третьих, требуется время на коммуникацию внутри команды, обсуждение решений и код-ревью. Также наличие технического долга, снижающего производительность и повышающего количество дефектов, требует внимания. Наконец, переработки и постоянный стресс ведут к выгоранию и снижению эффективности команды.
Agile и гибкие методы разработки ПО бизнес, ценность, бизнес-заказчик измерение и оценка ИТ, метрики, KPI, отчётность, дашборды командная работа мониторинг поддержка пользователей, Service Desk, Help Desk разработка ПО управление процессами, ИТ-процессы эффективность, оптимизация
Андрей Труфанов (источник). Рейтинг вопроса: 239
Цифровая компания использует в производственном процессе технологии, которые дают преимущества сразу по нескольким направлениям: сокращение производственных затрат за счет исключения операций, выполняемых людьми (что снижает число дефектов и потери времени); повышение эластичности производства (скорость и возможность реагирования на изменения спроса); повышение эффективности сбыта через расширение каналов приобретения, маркетинговую поддержку и сокращение дистанции между поставщиком и потребителем; повышение эффективности управленческих решений за счет объективной информации о процессах.
Agile и гибкие методы разработки ПО аллокация затрат, расчёт себестоимости услуг аутсорсинг, интеграция услуг бизнес, ценность, бизнес-заказчик поддержка пользователей, Service Desk, Help Desk разработка ПО экономика и финансы эффективность, оптимизация
Андрей Труфанов (источник). Рейтинг вопроса: 239
« 1 ... 78 79 80 ... 617 »