Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Согласно ITIL v3, экстренные изменения предназначены исключительно для решения серьезных инцидентов или установки критических обновлений безопасности. Для внедрения новых бизнес-требований или функциональности следует использовать нормальный процесс управления изменениями с высокой степенью срочности. Однако на практике многие компании, в силу реальных условий, используют экстренные изменения и для новых функций, что значительно повышает риски, связанные с некорректной реализацией изменений.
KPI при расчете комплексного показателя качества услуги можно группировать по категориям, отражающим различные аспекты услуги. Например, выделяют показатели производительности, доступности и поддержки. Для каждой группы рассчитывают отдельный интегральный показатель, используя подходящий метод агрегирования (среднее арифметическое, геометрическое и т.д.). Полученные результаты затем объединяют в общий показатель качества услуги, применив соответствующий метод агрегирования с учетом весов, если необходимо. Такой многоступенчатый подход позволяет более точно отражать качество услуги с разных сторон.
Практики управления рисками интегрируются в процесс управления проблемами, особенно в его проактивной составляющей, следующим образом: 1) Идентификация возможных событий - в процессе управления проблемами происходит выявление потенциальных проблем, которые могут привести к инцидентам. 2) Оценка вероятности и степени влияния - каждая выявленная проблема оценивается с точки зрения ее серьезности и вероятности возникновения, что позволяет приоритизировать проблемы. 3) Контроль реестра событий и актуальных оценок - ведется систематизированный реестр проблем с периодическим пересмотром их приоритетов и статусов. 4) Разработка и реализация мер по предотвращению рисков - для критически важных проблем разрабатываются проактивные меры по их устранению или минимизации влияния. Проактивная составляющая управления проблемами фактически представляет собой специфический вариант управления рисками, сфокусированный на технических и операционных рисках в сфере предоставления услуг. Эта интеграция позволяет не только реагировать на возникающие инциденты, но и предотвращать их возникновение.
Учет должен включать классификатор элементарных работ, с которым связываются фактические трудозатраты. Это позволяет сравнивать их с нормативными значениями и выявлять отклонения. Для ИТ-услуг учет должен учитывать не только поддержку, но и развитие системы, связывая затраты с конфигурационными единицами или запросами на изменение. Система должна быть интегрирована с различными источниками данных и обеспечивать консолидацию информации для комплексного анализа.
Для измерения результативности ИТ-процессов используются специальные наборы KPI (ключевых показателей эффективности) и методология формирования сбалансированных карт показателей. Эти методы позволяют измерить, насколько хорошо процессы удовлетворяют бизнес-требования и достигают поставленных целей. Сбалансированные карты показателей обеспечивают комплексный взгляд на эффективность процессов, учитывая различные аспекты их работы и влияния на бизнес. Такой подход позволяет не только измерить текущую результативность, но и определить пути её улучшения.
В ITIL 4 приоритизация инцидентов входит в факторы успеха практики управления инцидентами, поскольку является ключевым элементом для достижения основной цели практики — минимизации негативного влияния инцидентов на бизнес. Один из факторов успеха — умение решать инциденты быстро и эффективно, что напрямую зависит от корректной приоритизации. Правильная приоритизация позволяет определить порядок работы с инцидентами так, чтобы общее негативное влияние было минимальным, что и свидетельствует об эффективности работы практики. Приоритизация описана в контексте этого фактора успеха, а не как отдельный шаг процесса.
При ведении детального конфигурационного учёта возникают две основные проблемы. Во-первых, техническая сложность измерения и автоматизации учёта потребляемых ресурсов между всеми компонентами системы. Во-вторых, трудоёмкость формирования детальной карты взаимодействия компонентов, особенно в случае слабо документированных приложений. Это может потребовать проведения тотального рефакторинга для приведения реализации в соответствие с принятыми стандартами. Для компаний, использующих готовое ПО, детальный учёт внутренних компонентов обычно не требуется, так как они не управляют внутренней структурой приложения.
Примерами инцидентов являются: невозможность распечатать документ, отсутствие доступа к системе хранения данных (СХД), медленная загрузка страницы сайта и любые другие ситуации, связанные с прерыванием или ухудшением качества предоставляемой услуги. Инциденты представляют собой незапланированные события, требующие немедленного или максимально быстрого решения для восстановления нормальной работы.
При отказе от централизованной ИТ-стратегии каждое подразделение вынуждено самостоятельно определять задачи, инструменты, ресурсы, сроки и источники финансирования для достижения поставленных финансовых показателей. Это приводит к тому, что каждое подразделение создает собственную внутреннюю «ИТ-стратегию», что увеличивает вероятность ошибочных решений и неэффективного использования ресурсов. Позже, когда возникает необходимость сотрудничества с другими подразделениями, планы приходится пересматривать, что создает дополнительные сложности и замедляет процесс достижения целей.
Компании, придерживающиеся стратегии выживания, выделяют на 'развитие и управление ИТ' 4-8% от общего размера ИТ-бюджета. Это значительно выше, чем в других стратегических группах.