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

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

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

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

Authors
25

авторов

Sources
440+

источников

Original
100%

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

Если не проводить разделение на инциденты и проблемы, организация может сосредоточиться только на оперативном устранении текущих сбоев (инцидентов), игнорируя анализ их корневых причин. Это приведет к постоянному возникновению одних и тех же инцидентов, увеличению нагрузки на службу поддержки и снижению удовлетворенности пользователей. В результате ИТ-инфраструктура станет менее надежной, а затраты на поддержку вырастут из-за необходимости многократно применять временные решения вместо внедрения стабильных долгосрочных решений.
аллокация затрат, расчёт себестоимости услуг поддержка пользователей, Service Desk, Help Desk управление инцидентами управление конфигурациями, CMDB управление релизами экономика и финансы
Александр Движков (источник). Рейтинг вопроса: 185
Аргументы за использование процедуры повторного открытия инцидентов включают упрощение автоматизированного расчёта некоторых показателей эффективности работы службы поддержки. Процедура позволяет явно отслеживать случаи, когда решение инцидента оказалось недостаточным, что может способствовать анализу причин повторных обращений и улучшению процесса первичного решения проблем. Однако в тексте подразумевается, что часто выбор в пользу повторного открытия обусловлен не операционной необходимостью, а функционалом конкретной системы автоматизации, используемой в организации.
автоматизация ИТ-процессов, ПО для ITSM и ESM поддержка пользователей, Service Desk, Help Desk постоянное улучшение, совершенствование, CSI, PDCA управление запросами на обслуживание управление инцидентами эффективность, оптимизация
Игорь Гутник (источник). Рейтинг вопроса: 185
В некоторых моделях, таких как COBIT 5, управление доступностью и мощностями объединено, так как эти аспекты близки по своей сути и часто взаимосвязаны. Модели, стремящиеся к упрощению и укрупнению процессов, могут объединять сходные функции для снижения сложности управления. Однако такой подход приводит к необходимости постоянного балансирования между противоположными требованиями — обеспечение высокой доступности за счет резервирования может негативно влиять на эффективное использование мощностей, и наоборот. ITIL же придерживается более детализированного подхода, разделяя эти процессы для более целенаправленного управления.
COBIT ITIL управление доступностью
Константин Нарыжный (источник). Рейтинг вопроса: 185
Бизнес смотрит на преодоление текущих ограничений ИТ-подразделения как на процесс, который требует времени и планирования. Представители бизнеса заинтересованы в том, чтобы сегодняшние договоренности в SLA содержали элементы будущих улучшений, понимают необходимость развития и готовы к постепенному устранению ограничений через определенные этапы, а не мгновенно.
SLA бизнес, ценность, бизнес-заказчик общие вопросы менеджмента постоянное улучшение, совершенствование, CSI, PDCA управление уровнем услуг, SLM эффективность, оптимизация
Дмитрий Исайченко (источник). Рейтинг вопроса: 185
Использование единой инфраструктуры в ИТ-подразделениях значительно ограничивает технические возможности по варьированию уровня услуг для разных заказчиков. Поскольку все сервисы построены на одной и той же платформе и ресурсах, создание существенно разных уровней обслуживания для различных групп заказчиков становится технически сложным или экономически нецелесообразным. Это приводит к ситуации, когда в случае внутренних ИТ-услуг с одним основным заказчиком (бизнесом) разделение на отдельные SLA для разных уровней обслуживания часто избыточно, и уровень сервиса интегрируется в сам каталог услуг.
SLA бизнес, ценность, бизнес-заказчик управление каталогом ИТ-услуг управление конфигурациями, CMDB управление уровнем услуг, SLM
Дмитрий Исайченко (источник). Рейтинг вопроса: 185
RFC может появиться раньше Change proposal в случае, когда бизнес-заказчик обращается с запросом через непрямые каналы (например, через службу поддержки), и выделенный ИТ-представитель (BRM) должен определить, насколько запрос значим. Однако для крупных изменений BRM будет инициировать создание Change proposal, тогда как операционные мелкие запросы обрабатываются через RFC без подготовки стратегического документа.
бизнес, ценность, бизнес-заказчик поддержка пользователей, Service Desk, Help Desk управление изменениями управление отношениями, взаимодействие, BRM
Артём Мукосеев (источник). Рейтинг вопроса: 185
В контексте Service Improvement понятия Continual и Continuous имеют принципиальное различие. Continual Service Improvement (CSI) подразумевает непрерывный, но не обязательно постоянный процесс улучшения, происходящий через регулярные, периодические мероприятия, тогда как Continuous предполагал бы непрерывный безостановочный процесс. В русском языке этот нюанс сложно передать, но точнее будет говорить о «непрекращающемся» совершенствовании, так как улучшения происходят итеративно, в рамках регулярных циклов, а не постоянно без перерывов.
постоянное улучшение, совершенствование, CSI, PDCA эффективность, оптимизация
Дмитрий Исайченко (источник). Рейтинг вопроса: 185
Основной минус среднего арифметического, устраненный в методике с динамическими весами, заключается в том, что при использовании обычного среднего арифметического полный провал одной из областей ответственности (KPI=0%) приводит к незначительному снижению общей оценки (на 10% при 10 показателях). Это создает стимул для сотрудника игнорировать некоторые задачи ("Черт с ними, с 10%, не буду делать эту дурацкую работу, займусь другим"). Методика с динамическими весами решает эту проблему, значительно усиливая влияние низких значений KPI на общий результат, так что провал по одной метрике приводит к существенному снижению общей оценки (например, до 50% вместо 90%), что делает игнорирование любой из областей ответственности экономически невыгодным.
измерение и оценка ИТ, метрики, KPI, отчётность, дашборды мотивация персонала, стимулирование общие вопросы менеджмента
Дмитрий Исайченко (источник). Рейтинг вопроса: 184
Основными критериями для определения, какие компетенции оставить внутри, а какие аутсорсить, являются степень критичности задачи для работы продукта, частота ее возникновения и степень специфичности требований. Если задача возникает редко и требует узкоспециализированной экспертизы (например, разовые работы по архитектуре UI), она может быть передана внешним специалистам. Если же компетенция напрямую влияет на стабильность и работоспособность продукта и требует постоянного внимания (мониторинг, настройка кастомизированного middleware), ее лучше сохранить внутри команды. Также важно учитывать возможность автоматизации процессов и стандарты SLA, которые могут гарантировать надежность внешних поставщиков услуг.
ISO 20000 SLA архитектура ИТ, TOGAF и IT4IT аутсорсинг, интеграция услуг командная работа мониторинг управление продуктами, продуктовый подход управление уровнем услуг, SLM
Андрей Труфанов (источник). Рейтинг вопроса: 184
Эксплуатационное подразделение должно опережать по скорости продуктовые команды, чтобы своевременно реагировать на запросы пользователей и поддерживать стабильность системы после внедрения изменений. Если эксплуатация отстаёт, пользователи сталкиваются с задержками, что ухудшает их опыт и снижает удовлетворённость продуктом. Быстрая обработка запросов и оперативное устранение инцидентов позволяют сохранить бесперебойную работу бизнес-процессов и поддерживать высокую скорость цифровой трансформации.
бизнес, ценность, бизнес-заказчик командная работа поддержка пользователей, Service Desk, Help Desk трансформация, ускорение, Time-to-Market управление инцидентами управление продуктами, продуктовый подход управление релизами
Андрей Труфанов (источник). Рейтинг вопроса: 184
« 1 ... 358 359 360 ... 617 »