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