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

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

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

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

Authors
25

авторов

Sources
440+

источников

Original
100%

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

Инциденты тесно связаны с измерением доступности, так как они являются основным способом фиксации факта и периода недоступности. Классически инцидент недоступности регистрируется как любой инцидент, который затрагивает точку потребления услуги, особенно массовые инциденты, имеющие наибольший потенциал стать инцидентами недоступности. Однако при переходе на автоматизированный мониторинг важно дополнить регистрацию инцидентов четкими критериями недоступности для точного измерения и учета простоев.
измерение и оценка ИТ, метрики, KPI, отчётность, дашборды мониторинг управление доступностью управление инцидентами
Артём Мукосеев (источник). Рейтинг вопроса: 187
Проблема «княжеств» проявляется в том, что подразделения действуют как автономные структуры, отвечающие только за свои цели и показатели. Вместо того чтобы сотрудничать для достижения общекомпанийских целей, они соперничают друг с другом. Например, сокращая ИТ-бюджет для достижения своих плановых показателей, руководитель блока ИТ ухудшает возможности других подразделений, но увеличивает свои шансы на получение бонуса. Это приводит к снижению общей эффективности, внутреннему конфликту интересов и разобщенности в команде.
бюджетирование, планирование затрат командная работа общие вопросы менеджмента эффективность, оптимизация
Дмитрий Исайченко (источник). Рейтинг вопроса: 187
В классическом подходе коэффициент эффективности производственного потока рассчитывается как отношение времени, в течение которого в потоке фактически выполнялась полезная работа, ко всему времени, затраченному на производство единицы продукции. При этом большая часть времени в традиционных производственных системах приходится на ожидание — время, когда работающая деталь находится в состоянии простоя, ожидая следующей операции. Этот коэффициент в реальном производстве часто составляет всего несколько процентов, что подчеркивает значительную долю неэффективных затрат времени в большинстве процессов.
аллокация затрат, расчёт себестоимости услуг Канбан, WIP-лимиты экономика и финансы эффективность, оптимизация
Игорь Гутник (источник). Рейтинг вопроса: 187
В иерархической RBAC (Hierarchical RBAC) механизм наследования прав работает на основе организации ролей по принципу старшинства. Роли располагаются в иерархическом порядке, и нижестоящие роли наследуют все права доступа от вышестоящих ролей. Например, если роль 'Главный инженер' расположена ниже роли 'Сотрудник' в иерархии, то 'Главный инженер' автоматически получает все права, определенные для роли 'Сотрудник', плюс свои собственные дополнительные права. Это позволяет уменьшить дублирование прав при проектировании системы, так как общие базовые права можно вынести в одну роль, а специфические - в более специализированные нижестоящие роли. Механизм наследования значительно упрощает администрирование крупных систем с большим количеством пользователей и ролей.
общие вопросы менеджмента поддержка пользователей, Service Desk, Help Desk управление доступом, IDM, ролевые модели, RBAC, ABAC управление процессами, ИТ-процессы
Денис Денисов (источник). Рейтинг вопроса: 187
Чистый ABAC редко применяется из-за высокой сложности управления правилами. Большое количество атрибутов и условий приводит к трудночитаемым, запутанным политикам, которые сложно поддерживать и обновлять. Кроме того, отсутствие явных прав, как в RBAC, затрудняет аудит и анализ привилегий. Поэтому чаще используют гибридные подходы, где ABAC дополняет RBAC, например, добавляя контекстные ограничения к ролям.
аудит общие вопросы менеджмента управление доступом, IDM, ролевые модели, RBAC, ABAC управление процессами, ИТ-процессы
Александр Омельченко (источник). Рейтинг вопроса: 187
Единичные инциденты с высоким уровнем критичности, например, приводящие к полному простою сервиса, явно сигнализируют о наличии скрытой проблемы в инфраструктуре. Такие события требуют анализа корневой причины, чтобы предотвратить повторение, даже если схожие инциденты не фиксировались ранее. Например, ошибка в конфигурации критического сервера может парализовать бизнес-процессы, и ее решение становится приоритетной задачей управления проблемами.
бизнес, ценность, бизнес-заказчик управление инцидентами управление конфигурациями, CMDB управление проблемами
Евгений Шилов (источник). Рейтинг вопроса: 187
Основные проблемы сетевых сканеров: они фиксируют всё установленное ПО, включая программы, не требующие лицензирования; названия продуктов в результатах сканирования часто не совпадают с официальными наименованиями (требуется ручное сопоставление); сканеры не определяют тип лицензии и её коэффициенты (например, лицензия на два процессора при наличии восьмиядерного сервера). Это вынуждает операторов вручную классифицировать данные и корректировать отчёты, чтобы система могла правильно рассчитать объём необходимых лицензий.
измерение и оценка ИТ, метрики, KPI, отчётность, дашборды управление ИТ-активами, ITAM, SAM управление продуктами, продуктовый подход
Артём Мукосеев (источник). Рейтинг вопроса: 187
Использование заданий в качестве механизма функциональной эскалации может усложнить управление инцидентами, так как приводит к фрагментации информации. Вместо единой записи инцидента, которая перемещается между группами, информация о работе рассредоточивается между основной записью и несколькими заданиями, что затрудняет полное понимание хода решения проблемы. Это может привести к путанице в ответственности, потере контекста и увеличению времени на решение, особенно для сложных инцидентов, требующих участия нескольких специалистов. Кроме того, сотрудники первой линии вынуждены управлять не только непосредственной поддержкой пользователей, но и координацией заданий, что может увеличить их нагрузку.
общие вопросы менеджмента поддержка пользователей, Service Desk, Help Desk управление инцидентами
Дмитрий Исайченко (источник). Рейтинг вопроса: 187
Атрибутное формирование ролей не считается полноценной ролевой моделью, потому что в данном подходе роль перестает быть централизованным набором прав. Вместо этого роль становится всего лишь одним из атрибутов, что приводит к тому, что контроль над набором прав ускользает из-под центрального регулирования. Система фактически превращается в расширенную атрибутную модель, где сложность управления многократно возрастает с увеличением числа атрибутов, в отличие от классической ролевой модели, где управление правами осуществляется через четко определенные наборы ролей.
общие вопросы менеджмента управление доступом, IDM, ролевые модели, RBAC, ABAC управление процессами, ИТ-процессы
Александр Омельченко (источник). Рейтинг вопроса: 187
Команда-«семья» с сильными социальными связями более продуктивна в условиях неопределенности благодаря высокому уровню взаимного доверия, способности к быстрой неформальной коммуникации и готовности брать на себя ответственность. Сильные эмоциональные связи позволяют участникам лучше понимать намерения друг друга, что ускоряет принятие решений без необходимости в многочисленных формальных согласованиях. Члены такой команды чувствуют себя в безопасной среде, что стимулирует их к экспериментам и нестандартным решениям. В условиях, когда требуется выход за границы стандартных процедур и творческий подход, такие команды могут создавать решения, недоступные для групп отдельных профессионалов, даже при одинаковом уровне экспертизы.
командная работа общие вопросы менеджмента
Павел Капусткин (источник). Рейтинг вопроса: 187
« 1 ... 343 344 345 ... 617 »