Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Сервисно-ресурсная модель (СРМ) - это визуальное представление взаимосвязей компонентов ИТ-инфраструктуры, которая обычно дополняет базу данных управления конфигурациями (CMDB). СРМ отображает, как различные компоненты и ресурсы связаны между собой для предоставления ИТ-услуг. Это визуальное представление помогает лучше понять структуру ИТ-услуг, их зависимость от отдельных компонентов и ресурсов, что существенно упрощает управление ИТ-инфраструктурой и ИТ-услугами в целом.
Это происходит из-за отсутствия синхронизации между группами, выполняющими разные этапы. Например, подготовка стойки, сервера и сетевого сегмента может пройти безупречно, но если нет механизма для объединения результатов, итоговое решение не будет функционировать. Причина — отсутствие общего контроля и четких критериев того, что означает успешное завершение каждого этапа в контексте общего результата.
Управление рисками не выделено в отдельную практику в ITIL 2011, поскольку оно присутствует как сквозной элемент в различных процессах и группах практик. Риск-менеджмент интегрирован в процессы проектирования услуг, управления проблемами, постоянного совершенствования услуг, управления изменениями и релизами, а также в управление портфелем услуг. Согласно тексту, ITIL в целом можно рассматривать как систему управления рисками, поскольку управление ИТ-услугами в широком смысле является инструментом снижения бизнес-рисков, связанных с ИТ-сферой. Вместо отдельного процесса управление рисками распределено между различными практиками, что отражает идею о том, что управление рисками является частью работы любого менеджера на любом уровне.
Поток развития создает ценность по отношению к потоку эксплуатационной ценности за счет постоянного улучшения и расширения того, что потребитель получает при использовании продукта. В то время как поток эксплуатационной ценности отвечает за текущее потребление продукта и обеспечение получаемой ценности (например, покупка страхового полиса и получение компенсации при наступлении страхового случая), поток развития фокусируется на том, чтобы сделать эту ценность более значимой, добавляя новые функциональные возможности, улучшая пользовательский опыт или расширяя спектр услуг. Результатом работы потока развития становятся новые функции продукта, улучшенная инфраструктура, дополнительные компетенции и организационные изменения, которые в конечном итоге приводят к увеличению спроса и повышению рентабельности продукта.
При отсутствии согласования доступа к информационным системам возникают следующие риски: нарушение бизнес-процессов из-за неправильного использования ресурсов; несоответствие регуляторным требованиям, что может привести к штрафам и санкциям; нарушение принципа разделения обязанностей, повышающее риск мошенничества или ошибок; снижение производительности систем из-за непланируемых нагрузок; утечка или повреждение конфиденциальной информации; утечка данных; отсутствие контроля за тем, какие сотрудники имеют доступ к критически важным данным и системам. Все эти риски могут серьезно повлиять на эффективность и безопасность организации.
Различие между интенсивностью и производительностью важно в управлении проектами, потому что фокус на интенсивности может привести к кратковременному росту, но в долгосрочной перспективе снизит качество и увеличит издержки. При управлении проектами важно измерять реальный результат, а не только объём затраченного времени или энергии. Понимание этих понятий помогает выявлять неэффективные процессы, находить резервы для улучшения и принимать решения, направленные на повышение качества работы, а не только на ускорение временных показателей. Это способствует устойчивому развитию и предотвращает выгорание команды.
При проектировании процессов без чёткого понимания возможностей ITSM-системы возрастает риск создания «бумажного» регламента, который так и не будет внедрён в работу. Такой подход часто приводит к тому, что процесс через короткое время оказывается забыт и не используется в реальных операциях. Также есть вероятность, что при последующей автоматизации выявятся несоответствия между запланированной логикой процесса и возможностями системы, что потребует переработки регламента и увеличит затраты времени и ресурсов.
Gap-анализ при использовании объединенного радара результативности и зрелости приобретает новый, более содержательный смысл. Теперь он позволяет не только выявить разрывы между текущей и целевой зрелостью, но и учесть реальную результативность процессов. Это помогает определить не только где и как улучшать процессы, но и какие улучшения принесут наибольшую ценность для бизнеса. Например, если результативность низкая, но зрелость высока, это может свидетельствовать о том, что процессы строго соблюдаются, но не приводят к нужным результатам. И наоборот, высокая результативность при низкой зрелости означает, что процессы эффективны, но их результаты непредсказуемы и могут ухудшиться при изменениях в организации.
Удовлетворенность заказчика зависит не только от фактического качества услуг, но и от субъективного восприятия ситуации. Люди больше ориентируются на свои восприятие и эмоции, чем на объективные фактические данные. Критически важными для восприятия заказчика являются такие элементы, как компетентность сервис-провайдера, вежливость и отзывчивость сотрудников, способность четко демонстрировать достигнутые результаты. Это означает, что даже при временном отклонении от установленного уровня услуги (SLA), заказчик может остаться удовлетворен, если воспринимает сервис-провайдера как надежного и компетентного партнера. В то же время, безупречно соблюдая SLA, можно не достичь удовлетворенности заказчика, если он не видит ценности в предоставляемых услугах.
Системный подход важнее локальных улучшений в ITSM, потому что изменения в отдельном элементе системы могут вызывать непредвиденные негативные последствия в других её частях. Локальные доработки часто не решают корневых причин проблем и могут даже усугубить ситуацию, так как не учитывают взаимосвязи между компонентами системы. Системный подход позволяет оценить совокупное влияние и найти узкие места, на которые следует в первую очередь направить усилия для достижения максимального эффекта. Это подтверждается опытом применения модели, которая помогает увидеть общую картину и избежать решения проблем в изоляции, что часто приводит к краткосрочным результатам без долгосрочной устойчивости.