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

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

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

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

Authors
25

авторов

Sources
440+

источников

Original
100%

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

Основные проблемы при управлении доступом включают высокий уровень инцидентов безопасности из-за нарушения стандартных процедур выдачи прав, длительные сроки предоставления доступа новым сотрудникам (например, выдача прав может занимать несколько дней), постоянные замечания аудиторов по поводу непрозрачности системы предоставления прав (отсутствие записей о том, кто предоставил доступ, на каком основании и почему были внесены изменения). Эти проблемы приводят к уязвимостям в безопасности, замедлению бизнес-процессов и несоответствию требованиям внутреннего и внешнего аудита.
аудит безопасность бизнес, ценность, бизнес-заказчик управление доступом, IDM, ролевые модели, RBAC, ABAC управление инцидентами
Денис Денисов (источник). Рейтинг вопроса: 216
Плохие коммуникации в проекте могут привести к ряду негативных последствий: срывам сроков реализации проекта, дополнительным затратам на переделку выполненных работ, неудовлетворенности заказчика, сопротивлению сотрудников изменениям и конфликтам между участниками проекта. Неправильно поставленные задачи, искаженная передача информации или несвоевременное информирование об изменениях требований заказчика могут создать ситуацию, подобную басне «Лебедь, рак и щука», когда усилия участников направлены в разные стороны. Также недостаточная информированность людей о предстоящих изменениях может привести к сопротивлению переменам, так как люди предпочитают работать по сложившимся правилам, вместо того чтобы адаптироваться к новым условиям.
аллокация затрат, расчёт себестоимости услуг бизнес, ценность, бизнес-заказчик управление проектами, PRINCE2 экономика и финансы
Елена Колбей (источник). Рейтинг вопроса: 216
Модель Compass Model - это структурированный подход к анализу потребителя, разработанный Институтом Disney и упоминаемый в курсе ITIL 4 Drive stakeholder value. Модель представляет портрет потребителя в виде четырёх "сторон света": Север (потребности) - основные причины, побуждающие к выбору; Запад (желания) - менее конкретные, скрытые цели и пожелания; Юг (стереотипы) - предвзятость и установки потребителя, основанные на его опыте; Восток (эмоции) - чувства, которые проявляет или ожидаемо проявит потребитель в процессе взаимодействия с услугой. Практическое применение модели помогает структурировать понимание потребителя и определять, как создавать ценность для клиента, разделяя его ожидания на базовые потребности и дополнительные желания, а также учитывая стереотипы и эмоции.
ITIL бизнес, ценность, бизнес-заказчик обучение сотрудников, учебные курсы, тренинги управление отношениями, взаимодействие, BRM
Артём Мукосеев (источник). Рейтинг вопроса: 216
Для достижения требуемых показателей скорости изменения продукта необходимо выполнение двух условий. Во-первых, команда как черный ящик должна быть внутренне устроена корректно: уметь работать с потоком обрабатываемых объектов, иметь сбалансированную пропускную способность на всех этапах обработки. Во-вторых, команда должна иметь возможность управлять входом поступающих объектов: объекты должны иметь строгие границы для осознания и работы с ними, должны обладать определенной общностью в "размерах" (трудоемкость не должна сильно варьироваться), и команда должна управлять лимитом на количество объектов, обрабатываемых на первом этапе конвейера. Менее входящих объектов означает более быструю обработку каждого из них.
DevOps, CI/CD Канбан, WIP-лимиты командная работа управление продуктами, продуктовый подход
Андрей Труфанов (источник). Рейтинг вопроса: 216
Контроль имеет важное значение как компонент менеджмента, поскольку является основным гарантом достижения целей в заданных условиях. Он обеспечивает соответствие деятельности и результатов установленным стандартам и позволяет оперативно выявлять и устранять отклонения. Без эффективного контроля менеджмент теряет способность гарантировать выполнение задач в рамках требуемых параметров времени, стоимости и качества, что может привести к срыву проектов и снижению общей эффективности организации.
ISO 20000 общие вопросы менеджмента управление проектами, PRINCE2 эффективность, оптимизация
Роман Журавлёв (источник). Рейтинг вопроса: 216
Action Bias - это склонность к немедленным действиям и реакции даже в тех случаях, когда это не приведет к положительным результатам. Это убеждение проявляется в мысли, что лучше делать хоть что-то, чем ничего не делать. Такая склонность может быть вредной потому, что в условиях неопределенности и неполной информации действия могут привести к созданию ненужного продукта или перепроизводству, что вызовет заторы в рабочем процессе. Простой ресурса может быть сигналом о сбое на предыдущих участках, который следует изучить, а не маскировать дополнительной работой. Также создается иллюзия нагрузки ресурсов, когда фактически выполняется бессмысленная работа.
бизнес, ценность, бизнес-заказчик управление инцидентами управление продуктами, продуктовый подход
Олег Скрынник (источник). Рейтинг вопроса: 216
Автоматизация играет ключевую роль в определении завершения работы по концепции DevOps, так как она обеспечивает: 1) надежность и воспроизводимость процессов; 2) минимизацию человеческого фактора; 3) быстрое выявление и исправление ошибок; 4) непрерывную доставку изменений; 5) возможность частых и безопасных обновлений продукта. В финальной ступени Definition of Done автоматизация сборки, тестирования и развертывания является обязательным условием для признания работы завершенной, что позволяет командам сосредоточиться на улучшении продукта, а не на рутинных операциях.
DevOps, CI/CD командная работа общие вопросы менеджмента постоянное улучшение, совершенствование, CSI, PDCA управление продуктами, продуктовый подход управление процессами, ИТ-процессы управление релизами эффективность, оптимизация
Олег Скрынник (источник). Рейтинг вопроса: 216
Для проверки соответствия CMDB требованиям управления мощностями необходимо выполнить следующие шаги: во-первых, убедиться, что в CMDB построены логические модели приложений и услуг, включающие физические ресурсы и функциональные роли, такие как СУБД, web-сервер, файл-сервер. Во-вторых, проверить наличие в связях между элементами атрибутов и логики, которые переносят потребность в мощностях и стоимость обеспечения. В-третьих, проверить поддержку плановых объектов для моделирования целевой архитектуры. Эта проверка позволит не только определить, можно ли использовать CMDB для планирования мощностей, но и выявить конкретные области для улучшения системы.
архитектура ИТ, TOGAF и IT4IT общие вопросы менеджмента поддержка пользователей, Service Desk, Help Desk постоянное улучшение, совершенствование, CSI, PDCA управление конфигурациями, CMDB управление мощностями управление процессами, ИТ-процессы эффективность, оптимизация
Дмитрий Исайченко (источник). Рейтинг вопроса: 216
Аргументы: 1) Снижение количества повторных инцидентов через устранение корневых причин (данные статистики); 2) Экономия ресурсов за счёт сокращения 'тушения пожаров'; 3) Повышение качества сервисов через проактивные улучшения; 4) Соответствие лучшим практикам (ITIL, COBIT); 5) Конкретные кейсы: например, после внедрения отдельного процесса управления проблемами количество major-инцидентов упало на X%. Ключевая идея — управление проблемами не тратит ресурсы, а инвестирует в устойчивость системы.
COBIT ITIL бизнес, ценность, бизнес-заказчик постоянное улучшение, совершенствование, CSI, PDCA управление инцидентами управление проблемами управление релизами эффективность, оптимизация
Дмитрий Исайченко (источник). Рейтинг вопроса: 216
Ключевые аргументы против выделения управления доступностью как отдельного процесса заключаются в том, что его задачи практически полностью пересекаются с другими процессами ITIL. Например, создание плана доступности может быть частью SIP или управления мощностями, диагностика инцидентов относится к управлению инцидентами, оценка влияния изменений — к управлению изменениями, а отслеживание уровня доступности — к SLM. Кроме того, формулировки задач больше напоминают функции экспертной группы, чем последовательность процессных действий. В других стандартах управления ИТ управление доступностью не выделено отдельно, что подтверждает сомнения в его необходимости как самостоятельного процесса.
ISO 20000 ITIL измерение и оценка ИТ, метрики, KPI, отчётность, дашборды управление доступностью управление изменениями управление инцидентами управление мощностями управление уровнем услуг, SLM
Павел Дёмин (источник). Рейтинг вопроса: 216
« 1 ... 166 167 168 ... 617 »