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

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

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

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

Authors
25

авторов

Sources
440+

источников

Original
100%

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

Стандарт INCITS 494-2012 решает проблему негибкости 'чистого' RBAC в условиях изменчивого окружения. Основной стандарт RBAC критиковали за отсутствие возможности работы с динамическими ограничениями, такими как зависимость прав доступа от времени суток, дня недели, местоположения и других контекстных факторов. Стандарт 494-2012 расширяет базовый RBAC, добавляя поддержку обработки этих динамических ограничений через интерфейс внешней политики. Он позволяет интегрировать внешние правила и данные в процесс принятия решений о доступе, делая систему управления доступом более адаптивной к меняющимся условиям и требованиям бизнес-процессов.
ISO 20000 бизнес, ценность, бизнес-заказчик поддержка пользователей, Service Desk, Help Desk управление доступом, IDM, ролевые модели, RBAC, ABAC управление процессами, ИТ-процессы
Денис Денисов (источник). Рейтинг вопроса: 164
Управление проблемами включает следующие ключевые процессы: проактивная идентификация проблемы — процесс выявления потенциальных ошибок в продуктах организации на основе источников, отличных от записей об инцидентах; реактивная идентификация проблемы — процесс использования информации о прошлых и текущих инцидентах для расследования их причин; контроль проблем — процесс, фокусирующийся на расследовании проблемы; контроль ошибок — процесс, направленный на мониторинг и контроль состояния известных ошибок (проблем, которые проанализированы, но не решены) и их решение. Эти процессы направлены на выявление и устранение коренных причин инцидентов.
мониторинг общие вопросы менеджмента управление инцидентами управление проблемами управление продуктами, продуктовый подход
Игорь Фадеев (источник). Рейтинг вопроса: 164
Sj в формуле First Time Resolution (FTR) определяется как количество объектов (инцидентов), которые были возвращены на доработку конкретно в j-тую группу. Этот показатель отражает неудачные попытки решения обращений, требующие повторной обработки. Важно учитывать, что возвраты должны отслеживаться именно на уровне отдельной группы, а не всего инцидента, чтобы гарантировать точность расчёта метрики для каждой отдельной рабочей группы.
измерение и оценка ИТ, метрики, KPI, отчётность, дашборды управление запросами на обслуживание управление инцидентами
Дмитрий Исайченко (источник). Рейтинг вопроса: 164
Диагностика инцидентов может увеличивать общий простой, так как требует времени на тщательное выявление причины сбоя. Однако это необходимо для предотвращения повторных сбоев. В отсутствие подробной диагностики, можно лишь временно исправить непосредственную проблему, но без решения корневой причины существует риск, что инцидент повторится. Таким образом, диагностика, хотя и добавляет время к текущему сбою, помогает снизить вероятность будущих простоях.
управление инцидентами управление проблемами управление рисками
Константин Нарыжный (источник). Рейтинг вопроса: 164
Работа технической поддержки и менеджеров уровня услуг связана тем, что они представляют ИТ-подразделение разным группам заинтересованных сторон. Техническая поддержка работает с конечными пользователями, обеспечивая им удобство и стабильность использования ИТ-решений. Менеджеры уровня услуг взаимодействуют с заказчиками, демонстрируя бизнес-ценность и выгоду от ИТ-услуг. Недовольство пользователей рано или поздно становится известно заказчикам, поэтому обе функции тесно связаны и нуждаются в координации для обеспечения общей удовлетворенности и достижения бизнес-целей.
бизнес, ценность, бизнес-заказчик общие вопросы менеджмента поддержка пользователей, Service Desk, Help Desk
Константин Нарыжный (источник). Рейтинг вопроса: 164
Чтобы отличить действительно необходимые элементы сервисно-ресурсной модели от избыточных «фишек», следует оценить их влияние на основные бизнес-процессы. Необходимые элементы напрямую способствуют решению конкретных задач организации, упрощают процессы управления инцидентами или изменениями и имеют четкие сценарии использования. Избыточные «фишки» обычно создаются с прицелом на «все случаи жизни», но на практике оказываются невостребованными или требуют значительных усилий для поддержания без явной отдачи.
бизнес, ценность, бизнес-заказчик управление инцидентами
Артём Мукосеев (источник). Рейтинг вопроса: 164
Владелец конфигурационного элемента не должен участвовать в непосредственном аудите собственных данных, так как это нарушает принцип независимости проверки. Однако он может предоставлять информацию, подтверждающую корректность данных, и участвовать в обсуждении результатов аудита. Для исключения конфликта интересов аудит проводится сторонними специалистами, а владелец CI отвечает за устранение выявленных расхождений в установленные сроки.
аудит управление конфигурациями, CMDB
Евгений Шилов (источник). Рейтинг вопроса: 164
Разделение этапов жизненного цикла необходимо, поскольку общий показатель простоя не даёт информации о том, на каком этапе возникают задержки. Например, если инцидент длился 1 час, но устранение проблемы заняло всего 5 минут, без разбивки невозможно определить, что 55 минут ушли на ожидание информации или диагностику. Детальный анализ каждого этапа позволяет целенаправленно оптимизировать слабые места процесса, что в совокупности сокращает общее время простоя и повышает надёжность предоставления услуг.
управление инцидентами
Константин Нарыжный (источник). Рейтинг вопроса: 164
Интеграция измеримых ресурсов в систему управления с использованием потоков создания ценности происходит через четкое определение их роли и метрик измерения. Сначала необходимо идентифицировать все работы и мероприятия, которые не укладываются в прямые потоки создания ценности, но необходимы для их поддержки (например, compliance, тестирование надежности). Затем результаты этих работ должны быть определены как конкретные, измеримые ресурсы. Для каждого ресурса устанавливаются ключевые метрики, которые позволяют оценить его готовность, качество и достаточность. Далее необходимо определить точку взаимодействия этого ресурса с основными потоками ценности - когда и как потоки будут потреблять этот ресурс. После этого выстраиваются правила поставки ресурсов, чтобы они всегда были доступны в нужном количестве и качестве, но без излишков, что соответствует бережливому подходу. Наконец, ресурсы интегрируются в общее описание потоков создания ценности, так чтобы их статус и готовность были видимы наравне с другими элементами потоков, что позволяет своевременно обнаруживать и устранять возможные узкие места.
DevOps, CI/CD бизнес, ценность, бизнес-заказчик измерение и оценка ИТ, метрики, KPI, отчётность, дашборды Канбан, WIP-лимиты общие вопросы менеджмента поддержка пользователей, Service Desk, Help Desk поток создания ценности (Value Stream) управление отношениями, взаимодействие, BRM управление процессами, ИТ-процессы
Андрей Труфанов (источник). Рейтинг вопроса: 164
В тексте упоминаются четыре классические функции менеджмента: планирование, организация, мотивация и контроль. Текст намекает на эти функции, когда говорит о том, что некоторые руководители объясняют команде, как выполнять работу ('планирование' и 'организация'), определяют приоритеты, дают обратную связь ('мотивация') и следят за результатами ('контроль'). Хотя название этих функций прямо не перечислено, их суть раскрывается через описания правильного и неправильного поведения менеджеров в игровых ситуациях.
командная работа мотивация персонала, стимулирование общие вопросы менеджмента управление продуктами, продуктовый подход управление процессами, ИТ-процессы
Олег Скрынник (источник). Рейтинг вопроса: 164
« 1 ... 484 485 486 ... 617 »