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

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

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

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

Authors
25

авторов

Sources
440+

источников

Original
100%

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

Доступность ИТ-компонентов напрямую влияет на выполнение бизнес-процессов, поскольку современные бизнес-процессы часто зависят от работы ИТ-систем. Недоступность критических ИТ-компонентов может привести к простоям или снижению эффективности бизнес-процессов. Однако, чтобы определить именно влияние на бизнес, необходимо установить связи между конкретными ИТ-компонентами и бизнес-функциями, а также понимать критичность этих функций для бизнеса. Только при таком подходе можно точно определить, как уровень доступности ИТ-компонентов влияет на конечные бизнес-результаты. Без этой связи остаётся только технический показатель доступности ИТ-систем без бизнес-контекста.
бизнес, ценность, бизнес-заказчик управление доступностью эффективность, оптимизация
Артём Мукосеев (источник). Рейтинг вопроса: 182
Часто недооценивается время реакции на инцидент, то есть период, в течение которого инцидент находится в очереди и ожидает назначения специалисту и начала работы над ним. Согласно оценкам, это время может составлять, как минимум, столько же, сколько и непосредственное решение инцидента, а в ряде случаев даже превышать его. Учет и оптимизация времени реакции крайне важны, так как их сокращение является одним из наиболее доступных и эффективных способов уменьшения общего времени решения инцидентов и повышения уровня сервиса.
измерение и оценка ИТ, метрики, KPI, отчётность, дашборды управление инцидентами эффективность, оптимизация
Дмитрий Исайченко (источник). Рейтинг вопроса: 182
Бесконечное повышение интенсивности труда невозможно из-за физиологических и психологических ограничений человека. Переутомление приводит к снижению концентрации внимания, росту ошибок, ухудшению качества работы. Со временем снижается устойчивость объёма выполняемых работ: сотрудник не может постоянно поддерживать высокий темп без перерывов. Это также увеличивает издержки на компенсацию перенапряжения — больничные, выплаты, снижение мотивации. В отличие от интенсивности, производительность труда теоретически может расти неограниченно за счёт технического прогресса и оптимизации процессов.
мониторинг мотивация персонала, стимулирование эффективность, оптимизация
Олег Скрынник (источник). Рейтинг вопроса: 182
Термин «футбол» в контексте управления инцидентами ИТ описывает ситуацию, когда инциденты быстро и бездумно перекидываются между различными рабочими группами без реального прогресса в их решении. Это приводит к увеличению общего времени восстановления сервиса, снижению эффективности процесса и ухудшению клиентского опыта, так как инцидент может долго оставаться нерешённым из-за несогласованности действий внутри ИТ-организации.
бизнес, ценность, бизнес-заказчик управление инцидентами эффективность, оптимизация
Дмитрий Исайченко (источник). Рейтинг вопроса: 182
Основное сходство между IT4IT и ITIL v3 заключается в использовании концепции жизненного цикла услуги. В IT4IT сервисная модель (Service Model) построена вокруг четырех основных столпов и представляет собой Service Backbone, что по сути соответствует этапам жизненного цикла услуги в ITIL v3 - от концепции до оказания услуги. Обе модели рассматривают ИТ-услуги в разрезе процессов, и многие функциональные компоненты в IT4IT (такие как управление инцидентами, проблемами, изменениями) напрямую соответствуют стандартным процессам ITIL v3. При переходе к ITIL v4 видно еще больше общего, в частности, использование цепочки создания ценности (Value Chain), впервые предложенной Майклом Портером. Обе модели стремятся описать целостную картину ИТ-управления, а не просто набор разрозненных процессов.
ITIL архитектура ИТ, TOGAF и IT4IT бизнес, ценность, бизнес-заказчик управление инцидентами
Игорь Гутник (источник). Рейтинг вопроса: 182
Роль тимлида напрямую противоречит некоторым принципам гибких методологий. Например, Scrum Guide не предусматривает существования тимлида в команде, так как он ориентирован на самоорганизованные кроссфункциональные команды, где ответственность распределена между всеми членами. Гибкие подходы подразумевают, что команды должны быть способны принимать решения самостоятельно, без назначения отдельного лидирующего лица для решения технических или управленческих вопросов.
Agile и гибкие методы разработки ПО командная работа общие вопросы менеджмента управление процессами, ИТ-процессы
Павел Капусткин (источник). Рейтинг вопроса: 182
Service Desk может быть не нужен организации в двух основных случаях: когда недостаточно ресурсов для его организации, так как потребность в них легко оценивается с использованием специальных формул (например, формулы Эрланга), или когда существуют отдельные узкоспециализированные группы пользователей, поддерживающих свои собственные ИТ-решения. В таких условиях каждая специализированная группа может выступать в роли SPOC (единой точки контакта) для своих пользователей, что делает централизованную точку контакта избыточной. Это особенно характерно для крупных организаций с разнообразными ИТ-услугами.
общие вопросы менеджмента поддержка пользователей, Service Desk, Help Desk управление процессами, ИТ-процессы
Дмитрий Исайченко (источник). Рейтинг вопроса: 182
Без прямого подчинения ресурсам менеджер процесса сталкивается с трудностями в принудительном управлении: невозможностью напрямую распределять задачи, контролировать исполнение, применять кадровые меры. Это приводит к необходимости выстраивать взаимодействие через убеждение, создание общих целей, поиск компромиссов между подразделениями. Также могут возникать конфликты приоритетов, когда задачи процесса конкурируют с оперативными задачами подразделений, и менеджер процесса не имеет рычагов для безусловного утверждения своих приоритетов.
общие вопросы менеджмента управление отношениями, взаимодействие, BRM управление процессами, ИТ-процессы
Дмитрий Исайченко (источник). Рейтинг вопроса: 182
Назначение руководителя отдела сопровождения прикладных систем в роли менеджера процесса управления инцидентами снижает риски, связанные с нарушением бизнес-операций из-за проблем с прикладным ПО. Поскольку основной поток обращений связан именно с этими системами, такой менеджер лучше осознает важность их бесперебойной работы и может оперативно координировать взаимодействие между внутренними и внешними участниками процесса: разработчиками, ИТ-инфраструктурой и первой линией. Это предотвращает появление «параллельных реальностей», когда обращения обходят стандартные каналы, и обеспечивает прозрачность в управлении инцидентами, что критически важно для снижения времени простоя и улучшения качества обслуживания.
бизнес, ценность, бизнес-заказчик Канбан, WIP-лимиты общие вопросы менеджмента постоянное улучшение, совершенствование, CSI, PDCA управление запросами на обслуживание управление инцидентами управление конфигурациями, CMDB управление отношениями, взаимодействие, BRM управление процессами, ИТ-процессы управление рисками эффективность, оптимизация
Дмитрий Исайченко (источник). Рейтинг вопроса: 182
Детализация классификатора изменений должна быть сбалансированной, избегая как избыточного упрощения, так и чрезмерной детализации. Нецелесообразно прописывать все возможные сценарии изменений «до последнего чих», что потребует значительных временных и трудовых ресурсов без реальной пользы. В то же время классификатор должен учитывать специфику различных типов изменений. Оптимальным подходом является разделение изменений на стандартные и нестандартные. Для стандартных изменений, имеющих предсказуемый характер и минимальные риски, допустима высокая степень детализации с чётким прописыванием последовательности действий, исполнителей и сроков. Стандартные изменения могут быть включены в каталог поддержки, и для них могут устанавливаться нормативы SLA. Для нестандартных изменений детализация должна быть менее жесткой, предполагая наличие анализа рисков, оценки влияния и управленческих решений на ключевых этапах. Структура классификатора при этом должна иметь матрично-иерархическую организацию, сочетающую общие типовые порядки обработки с возможностью их настройки под специфику конкретных систем и направлений.
SLA архитектура ИТ, TOGAF и IT4IT измерение и оценка ИТ, метрики, KPI, отчётность, дашборды поддержка пользователей, Service Desk, Help Desk управление изменениями управление рисками управление уровнем услуг, SLM
Артём Мукосеев (источник). Рейтинг вопроса: 182
« 1 ... 378 379 380 ... 617 »