Для некоторых бизнес-процессов более критичны частые кратковременные простои из-за особенностей их работы. Например, в вычислительных процессах, требующих длительного времени на выполнение (научные расчеты, моделирование, сложные аналитические операции), каждое прерывание вынуждает перезапускать процесс, теряя все достигнутое прогресс. Если такой процесс требует 10 часов непрерывной работы, то два простоя по 5 минут в начале и середине процесса могут сделать его невыполнимым, тогда как один 10-минутный простой в конце может быть менее критичен. Аналогично, в системах автоматизации производства перезапуск конвейера после каждого кратковременного простоя снижает общую производительность больше, чем один длительный перерыв, после которого система работает безостановочно.

SIAM (Service Integration and Management) представляет собой подход к управлению услугами в условиях множества поставщиков. Его основная концепция заключается во введении уровня управления, называемого «сервис-интегратор», который располагается между организацией-заказчиком и её поставщиками услуг. Сервисный интегратор отвечает за управление, интеграцию и координацию различных поставщиков, чтобы клиент получал наилучшее качество сервиса и сокращал накладные расходы на управление множеством поставщиков. SIAM описывается в документе «SIAM Foundation Body of Knowledge», который предоставляет методологию для организации потребления услуг в моделях с несколькими внешними и внутренними поставщиками.

По мнению текста, научно обоснованными из всего исследования являются только два вывода: что более объективной самооценке можно научиться и что эксперты оценивают свои навыки точнее, чем неэксперты. Все остальные популярные интерпретации, такие как кривая, на которой люди с низкой компетентностью имеют самую высокую самооценку, а затем, по мере роста знаний, самооценка снижается, а потом снова растет, основываются на математических ошибках в оригинальной работе и последующих публикациях.

При управлении процессом резервного копирования следует отслеживать следующие ключевые показатели: - Успешность выполнения резервных копий: процент успешных операций резервного копирования от общего числа запланированных. - Время, необходимое для выполнения резервного копирования: продолжительность процесса резервирования данных. - Объем данных, включенных в резервное копирование: соответствие плановому объему данных, которые должны быть заархивированы. - Время восстановления данных: фактическое время, затрачиваемое на восстановление данных из резервных копий. - Точность восстановления данных: соответствие восстановленных данных исходному состоянию. - Частота проверок резервных копий: насколько регулярно проводятся тесты восстановления. - Количество ошибок и сбоев в процессе резервного копирования. - Время устранения проблем со сбоями в процессе резервного копирования. - Соответствие количества сохраняемых точек восстановления требованиям бизнеса. - Занятость хранилища резервных копий и эффективность использования ресурсов. - Удовлетворенность заинтересованных сторон процессом резервного копирования. Регулярный мониторинг этих показателей позволяет определить эффективность процесса резервного копирования и внести необходимые коррективы в соответствии с бизнес-требованиями.

Помимо общих управленческих компетенций (планирование, делегирование, контроль), менеджер процесса должен обладать: пониманием методологий процессного управления (BPMN, методологии моделирования процессов), навыками анализа и оптимизации процессов, умением выстраивать коммуникации между разными подразделениями, способностью работать в условиях ограниченного административного влияния, пониманием взаимосвязей между процессами и бизнес-целями компании, знанием метрик и KPI процессов. Эти специфические требования выделяют процессного менеджера среди других управленческих ролей.

Эффективный подход предполагает, что дефекты следует устранять как можно быстрее после их обнаружения. Концепция Zero Known Defects утверждает, что ИТ-система должна в любой момент времени быть полностью работоспособной. Экономически наличие дефектного кода обходится дороже, чем поддержание работоспособности, особенно с учетом постоянного усложнения программного кода. Откладывание устранения дефектов приводит к накоплению проблем и увеличению стоимости их решения в будущем, а также создает препятствия для дальнейшей разработки.

Процесс управления изменениями остается важным, потому что современная ИТ-инфраструктура представляет собой многосвязную систему взаимодействующих компонентов. Наибольший риск возникает при изменениях, которые влияют на совокупность приложений и сервисов комплексно. Даже при итеративном развитии приложений необходима коммуникация знаний об изменении, его влиянии и совместной подготовке к преобразованию, чтобы снизить риски возникновения инцидентов.

Один из эффективных методов - стажировка разработчиков в поддержке продукта или непосредственно у пользователей в точке потребления. Такое "погружение в реальность" позволяет разработчикам увидеть, как используется продукт в реальных условиях, столкнуться с проблемами пользователей и лучше понять их потребности. Это переживание "живого опыта" часто кардинально меняет взгляд разработчика на свою роль и работу. Также полезно вовлекать разработчиков в исследовательские активности на этапе формирования бэклога, чтобы они могли непосредственно участвовать в выявлении новой ценности, которую приносит продукт. Важно показывать команде не только статистические данные об использовании фич, но и реальные реакции пользователей - отзывы, запросы, обсуждения на митапах.

Отсутствие культуры автоматизированного тестирования серьёзно препятствует внедрению CI/CD, потому что конвейер развёртывания требует надёжной и быстрой проверки изменений перед их выпуском в продакшен. Без достаточного количества актуальных автотестов невозможно гарантировать, что каждое изменение кода не нарушает существующую функциональность. Если команда до сих пор ведет дебаты о том, 'стоит ли', 'нужно ли' или 'можем ли мы себе позволить писать автотесты', это указывает на фундаментальную неготовность к CI/CD. Автотесты являются неотъемлемой частью конвейера, они должны запускаться автоматически на каждом этапе и блокировать дальнейшее продвижение изменений при обнаружении ошибок. Отказ от постоянного обновления автотестов приведет к тому, что со временем они перестанут быть актуальными, будут «краснеть» и вынуждать команду вручную обходить проблемы, что полностью разрушает идею непрерывной интеграции и развертывания.

Для специалиста BRM необходимы несколько ключевых компетенций. BRM должен обладать стратегическим партнерством – способностью строить долгосрочные отношения с заказчиком и выступать его представителем внутри ИТ-организации. BRM должен иметь бизнес-интеллект – глубокое понимание бизнес-процессов и целей заказчика. BRM должен быть лидером при преобразованиях – уметь вести за собой в условиях изменений и управлять сопротивлением. BRM также должен обладать навыками убеждения и коммуникации, чтобы эффективно работать как «мост» между бизнесом и ИТ. BRM сочетает в себе качества грамотного бизнес-аналитика, эффективного ИТ-менеджера и психоаналитика, что позволяет ему понимать как бизнес-требования заказчика, так и технические возможности ИТ.