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

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

25
авторов

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

100%
оригинальный контент
Измерение Flow Efficiency важно потому что оно позволяет выявить долю времени, когда над задачей фактически ведется работа, по сравнению со временем, проведенным в ожидании или в очередях. Это помогает командам понять, сколько времени теряется из-за простоя и ожидания, и сконцентрировать усилия на сокращении этих потерь. По утверждениям авторов 'DevOps Handbook', поскольку именно Lead Time воспринимается заказчиком как время выполнения работы, оптимизация именно этого показателя должна быть приоритетной. При этом соотношение времени обработки к общему времени выполнения является важной мерой эффективности процесса.
BRM может использовать несколько ключевых инструментов для повышения удовлетворенности заказчика: 1) Работа над наглядностью и содержательностью отчетов, демонстрирующих достижения сервис-провайдера; 2) Внедрение и организация эффективных механизмов подачи и обработки жалоб; 3) Регулярное проведение опросов удовлетворенности с обязательным предоставлением обратной связи по результатам; 4) Активное участие в ключевых встречах заказчика для своевременного получения информации о планах и изменениях в бизнесе заказчика; 5) Помощь в точном формулировании и переводе бизнес-ожиданий в технические требования с учетом возможностей сервис-провайдера.
Конфликт возникает из-за разного понимания требований бизнеса и возможностей продуктовых команд. Бизнес стремится закрепить сроки для планирования бюджета и стратегии, тогда как команда сталкивается с непредсказуемостью разработки. При этом команды могут формально следовать гибким методологиям, но на практике работать в рамках дедлайнов, что противоречит принципам организации равномерного потока и снижает эффективность.
Понимание контекста имеет критически важное значение для эффективного взаимодействия ИТ и бизнеса, поскольку оно позволяет ИТ-специалистам видеть за формальным запросом реальную бизнес-проблему, которую нужно решить. Контекст включает в себя знание бизнес-процессов, целей компании, отраслевой специфики и даже культурных особенностей организации. Без контекстного понимания ИТ-служба может создать технически грамотное, но неэффективное с бизнес-точки зрения решение. Понимание контекста позволяет: правильно интерпретировать запросы, выявлять скрытые потребности, оценить приоритетность задач, предложить оптимальные альтернативные решения. Например, в истории с отелем сотрудники, понимающие контекст (что постоялец привез своё мыло и его цель - комфортное проживание), сразу бы изменили стандартный регламент для этого конкретного случая. Аналогично, ИТ-специалист, понимающий, что срочный запрос на реализацию отчёта связан с подготовкой к встрече с инвесторами, может перераспределить ресурсы для ускорения выполнения задачи, понимая её стратегическую важность.
Для организаций, где услуги постоянно меняются, особенно важны рекомендации ITIL по управлению изменениями. Этот процесс помогает структурировать, оценить и реализовать изменения в контролируемой среде, минимизируя риски и негативное воздействие на пользователей. Также полезен процесс постоянного совершенствования (CSI), который способствует регулярному анализу и улучшению услуг. Если изменения связаны с технологическими аспектами, будут полезны процессы управления выпусками, конфигурациями и релизами. В целом, ITIL предоставляет структурированный подход к управлению динамичной средой, что особенно ценно в условиях постоянного развития услуг и технологий.
В трёхдневный формат курса были добавлены следующие новые темы: расширенное рассмотрение микросервисов с обсуждением их преимуществ и недостатков по сравнению с монолитной архитектурой; изучение технического совершенства, включая взаимосвязь таких практик, как Continuous Integration, автоматический откат и обратно-совместимые программные интерфейсы; а также рассмотрение местоположения DevOps-команд в структуре ИТ-подразделения, правил взаимодействия и определения зон ответственности.
Ключевыми факторами успешного восстановления проваливающегося проекта являются: воля и желание ключевых участников, слаженная работа всей команды, готовность к кардинальным изменениям, четкое распределение обязанностей без вмешательства в работу других ролей. Важно наладить коммуникацию с заказчиком, чтобы понимать его реальные потребности, избегать поиска виноватых и перейти в высокоскоростной режим работы, способный за короткое время достичь максимального результата. Упрощение отчетности и фокусировка на основных задачах также способствуют спасению проекта.
Включение функциональных руководителей в процессное управление важно, так как процессы часто пересекают функциональные границы организации и требуют сотрудничества между различными подразделениями. Если функциональные руководители не вовлечены в процессное управление, это может привести к несогласованности действий, недостаточному выделению ресурсов и, как следствие, к снижению эффективности процессов. Использование системы метрик для оценки руководителей, связанных с процессами, даже если они формально не несут функциональных обязанностей в этих процессах (например, не являются ответственными в матрице RACI), создает стимул для руководителей уделять внимание процессам, предоставлять необходимые ресурсы и контролировать выполнение задач. Это способствует созданию более гибкой и ориентированной на процессы организационной структуры, что критически важно для достижения бизнес-целей.
Если в SLA не указаны сроки восстановления сервиса после инцидента, это может привести к задержкам в устранении неполадок и увеличению простоя. Поставщик может не ощущать необходимости срочного ремонта, в то время как потребитель зависит от восстановления услуги. Это создает неопределенность в ожиданиях и может вызвать конфликты между сторонами из-за отсутствия четких временных рамок для устранения проблем
Крупные компании предпочитают самостоятельно подготавливать агентов изменений, а не нанимать их извне, потому что внешние специалисты все равно требуют глубокого погружения в контекст конкретной организации: принятые стандарты разработки, качества, особенности корпоративной культуры и исторически сложившийся ИТ-ландшафт. Наличие собственных агентов изменений, подготовленных с учетом стратегических целей компании, позволяет достичь единого видения целей развития на системном уровне и избежать деятельности ради деятельности без измеримого результата. Это также более экономически эффективно в долгосрочной перспективе, несмотря на первоначальные затраты на подготовку.