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

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

25
авторов

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

100%
оригинальный контент
Определение задач для непрерывной поставки следует проводить через анализ стоимости задержки и рисков. Необходимо оценить, насколько высока стоимость потенциальных потерь для бизнеса при временных нарушениях работоспособности ИТ-продукта при установке изменений. Если стоимость задержки реализации конкретных требований выше стоимости предполагаемых рисков от временного нарушения работоспособности, такие задачи можно поставлять непрерывно, не задерживая их до релиза. Также важно учитывать, что в потоке создания ценности присутствуют задачи с разной природой: некоторые могут быть поставлены в любое время, тогда как другие требуют минимальной пользовательской активности или других особых условий. Выделение категорий задач и разработка системы правил по их поставке позволяет оптимизировать процесс и частично уйти от релизных циклов.
Определение доступности для конкретной ИТ-услуги формируется на основе анализа, что именно предоставляет услуга потребителю. Для ресурсных услуг это анализ функций ресурса (например, канал связи, API), их дефектов и времени отклика. Для услуг, связанных с выполнением работ, это оценка отзывчивости интерфейсов и соблюдения сроков по SLA. Определение формулируется совместно с заказчиком и фиксируется в соглашении, включая временные интервалы доступности и критерии нарушения.
Можно либо нельзя - это зависит от требований к скорости решения задач. Если требования к скорости невысоки, то можно обойтись без построения быстрого потока. Организация может перестроиться на продуктовую структуру, но задачи будут обрабатываться без равномерного и быстрого потока. Однако если требуется существенно повысить скорость решения задач (например, чтобы соответствовать требованиям бизнеса в быстром реагировании), то одного переименования ролей и создания продуктовых департаментов недостаточно. В этом случае необходимо построить быстрый поток, что требует радикальных изменений всей системы работы, включая системы управления очередями, распределение ресурсов, квалификацию сотрудников и т.д.
ITIL 4 рекомендует определять стратегию взаимодействия с поставщиками и партнерами на основе целей организации, ее культуры и бизнес-среды. При формировании такой стратегии необходимо учитывать несколько ключевых факторов: стратегическую направленность (что относится к основному бизнесу, а что можно получить от партнера), корпоративную культуру (предыдущий опыт сотрудничества с партнерами), нехватку ресурсов (возможность самостоятельно финансировать ресурсы), ценовую целесообразность (что экономичнее в среднесрочной и долгосрочной перспективе), профессиональную компетентность (наличие необходимого опыта внутри организации или необходимость привлечь внешних экспертов), внешние ограничения (существующие правила и нормативы) и спрос (сезонные колебания потребностей и их возможное сглаживание с помощью партнера). Стратегия может варьироваться от официальных контрактов с четким разделением обязанностей до гибких партнерских отношений с общими целями и рисками в зависимости от конкретных обстоятельств и ценностей организации.
Управление дефектами подразумевает системный, структурированный подход к выявлению, отслеживанию, приоритизации и устранению дефектов с четкими процессами и ответственностью. Простая работа над дефектами часто сводится к реактивному исправлению проблем по мере их обнаружения без стратегического подхода. В большинстве команд разработки отсутствует именно управление дефектами, так как нет четкого определения дефекта, процессов для их обработки и культуры немедленного устранения. Управление дефектами включает не только технические аспекты, но и коммуникацию между заказчиком и исполнителем, измерение влияния дефектов на бизнес и интеграцию работы с дефектами в общий процесс разработки.
Под "интерфейсом между ИТ и бизнесом" автор подразумевает четкие и эффективные каналы коммуникации и взаимодействия между ИТ-подразделением и бизнес-направлениями компании. Отсутствие этого интерфейса является проблемой, потому что без четких правил взаимодействия возникает недопонимание, срывы сроков, потерянные ресурсы и общая неэффективность. Когда руководители ИТ временно переходят в бизнес и становятся владельцами продуктов, этот недостающий интерфейс становится очевидным, что позволяет определить, как и где необходимо скорректировать методы работы для улучшения взаимодействия.
Формирование эффективных кросс-функциональных команд важно при использовании чат-ботов во внутренних процессах, потому что это позволяет улучшить взаимодействие между разными отделами организации, повысить качество обмена знаниями и понимание общей картины деятельности. Чат-боты могут служить инструментом для упрощения коммуникации между различными функциональными группами, обеспечивая быстрый доступ к необходимой информации и ресурсам, что приводит к более оперативному принятию решений и повышению общей эффективности работы организации.
Классические радарные диаграммы зрелости сосредоточены преимущественно на оценке уровня зрелости процессов без учета их реальной эффективности. Они показывают, насколько процессы соответствуют определенным стандартам, но не отражают фактическую пользу процессов для организации. При рассмотрении только зрелости можно не учитывать, насколько хорошо процессы справляются со своими задачами в реальных условиях, что снижает ценность таких диаграмм для принятия управленческих решений. В результате, диаграммы зрелости сами по себе не предоставляют полной картины для определения приоритетов улучшений.
MBO считается более эффективным, чем оценка зрелости процессов при планировании совершенствования, потому что он основывается на измерении текущего состояния через реальные данные и статистику, что позволяет построить более обоснованный и значимый для бизнеса план совершенствования. В отличие от абстрактной оценки зрелости, MBO фокусируется на конкретных достижимых результатах и вовлекает руководителей в процесс постановки и достижения целей, обеспечивая более практичный и бизнес-ориентированный подход к улучшению услуг.
При обсуждении структуры SLA бизнес учитывает текущие возможности ИТ-подразделения, понимает необходимость реалистичных требований и стремится спланировать будущие улучшения. Бизнес проявляет ответственность, не требуя всего сразу, но при этом четко формулирует свои ожидания и обсуждает пути их достижения в будущем с учетом возможного развития ситуации.