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

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

25
авторов

440+
источников

100%
оригинальный контент
Для работы с массовыми обращениями, вызванными крупными инцидентами, следует применять следующий подход: 1. Оценить текущую способность процесса справляться с такими ситуациями, проверив наличие и эффективность специализированных процедур для массовых обращений 2. Если такие процедуры отсутствуют или неэффективны, разработать стратегию работы с массовыми обращениями, включая приоритизацию и распределение ресурсов 3. Создать специализированные шаблоны и стандартные ответы для типовых ситуаций 4. Усилить критические участки процесса дополнительным персоналом и ресурсами 5. Рассмотреть возможность временного отказа от необязательных этапов обработки для ускорения основного процесса 6. Внедрить специальные инструменты для быстрой классификации и маршрутизации массовых обращений 7. Организовать оперативный информационный центр для координации действий всех задействованных групп 8. Провести пост-инцидентный анализ для выявления уроков и внесения изменений в процессы, чтобы избежать подобных ситуаций в будущем Ключевым является оперативная реакция и четкая структура действий, которая позволяет минимизировать время простоя и негативное воздействие на пользователей.
Для траектории "Падшая звезда" рекомендуется дать агенту более узкое поле деятельности с конкретными одной-двумя целями, постепенно расширяя его при успешном освоении. Для траектории "Боевой товарищ" важно не расслабляться и продолжать поддерживать развитие специалиста, предоставляя возможностей чуть больше, чем требуется в текущий момент. Для траектории "Заряженная пружина" необходимо искать способы качественного развития (разные типы команд, дополнительные виды деятельности), а не только количественного увеличения задач, чтобы не потерять талантливого сотрудника.
Gap-анализ при использовании объединенного радара результативности и зрелости приобретает новый, более содержательный смысл. Теперь он позволяет не только выявить разрывы между текущей и целевой зрелостью, но и учесть реальную результативность процессов. Это помогает определить не только где и как улучшать процессы, но и какие улучшения принесут наибольшую ценность для бизнеса. Например, если результативность низкая, но зрелость высока, это может свидетельствовать о том, что процессы строго соблюдаются, но не приводят к нужным результатам. И наоборот, высокая результативность при низкой зрелости означает, что процессы эффективны, но их результаты непредсказуемы и могут ухудшиться при изменениях в организации.
Если сотрудники понимают, что метрики помогают улучшить процесс, а не служат инструментом для выявления «провинившихся», они реже пытаются их обмануть. Это способствует созданию открытой культуры, где проблемы обсуждаются коллективно, а не скрываются. В итоге повышается общая эффективность работы и качество процессов.
Управление большой и сложной ИТ-службой может стать более эффективным, если будет основано на измерениях. Измерения позволяют выявить слабые места, определить цели и оценить прогресс. Однако из-за сложности задачи измерения и оценки они требуют тщательной настройки и интеграции в систему управления, чтобы результаты могли использоваться для принятия управленческих решений.
Первым шагом в процессе постоянного совершенствования услуг является понимание видения и целей бизнеса. Этот шаг важен, поскольку определяет направление дальнейших улучшений, позволяя ИТ-специалистам ориентироваться на потребности заказчика. Без понимания целей бизнеса оценка текущего состояния может оказаться нецелевой и неэффективной, так как разные организации имеют различные приоритеты: для больницы ключевой аспект — доступность и непрерывность услуг, тогда как торговая сеть сфокусирована на мощности, безопасности и функционале.
На конечной стадии визуализации убрали отдельный этап тестирования, потому что современные DevOps-принципы настаивают на встроенном качестве и непрерывной обратной связи. Выделенный этап тестирования в конце или середине процесса замедляет получение обратной связи и увеличивает цикл исправления дефектов. Вместо этого, тестирование и обеспечение качества распределены по всем этапам потока создания ценности, что соответствует четырнадцатому принципу Деминга о непрерывном улучшении качества. Такой подход позволяет выявлять и исправлять проблемы на ранних стадиях, снижает общую стоимость дефектов, ускоряет процесс доставки функциональности и лучше соответствует Agile и DevOps ценностям быстрой доставки ценности с гарантированным качеством.
Проблема разделения заказчика и плательщика в ИТ-отношениях решается через организационное изменение и аллокацию стоимости ИТ-услуг. Простое распределение стоимости ИТ-услуг недостаточно. Необходимо, чтобы руководители бизнес-подразделений отвечали не только за оборот, но и за прибыльность своего направления, при этом затраты на ИТ должны учитываться в расходной части их подразделений. Это означает трансформацию бюджета ИТ, который должен состоять из затратных частей бизнес-подразделений, напрямую связанных с потреблением и развитием ИТ-услуг. Такой подход описан в ITIL, но требует существенных организационных изменений и не всегда широко распространен на практике, несмотря на своё теоретическое описание.
Подход MVP тесно связан с потоками создания ценности в ITIL 4, так как именно на их основе формируется минимальная жизнеспособная практика. Потоки создания ценности описывают, как организация создает ценность для своих клиентов. MVP формируется путем сбора всех случаев вовлечения конкретной практики в этих потоках, что позволяет определить минимально необходимый охват практики для поддержки указанных потоков. Без четкого описания потоков создания ценности невозможно эффективно применять подход MVP.
Основная сложность современных ITSM-процессов связана с высокой сложностью современных ИТ-архитектур, организационных структур и схем привлечения подрядчиков. Эти факторы делают ИТ-процессы значительно сложнее других «тикетных» процессов, таких как административно-хозяйственная деятельность или претензионная работа. Особенно это касается процессов поддержки пользователей и управления изменениями, которые требуют учета множества дополнительных аспектов, включая интеграцию с другими ИТ-процессами, работу с CMDB и учет трудозатрат.