Предложенная метрика решает проблему отсутствия адекватного способа измерения эффективности процесса управления проблемами. Традиционные метрики, такие как отношение количества решенных проблем к количеству открытых, имеют существенные недостатки: они не стимулируют регистрировать новые проблемы и не нормированы, что делает сложным определение целевых значений. Новая метрика является нормированной (изменяется в диапазоне [0;1]) и стимулирует выявление и регистрацию новых проблем, так как её значение увеличивается при увеличении количества новых зарегистрированных проблем.

Для определения владельца сквозного процесса необходимо проанализировать обязательные обязанности этой роли по каждому пункту из выбранного источника (например, ITIL), затем оценить степень критичности каждой обязанности для конкретной организации и процесса, используя, например, десятибалльную шкалу. Где 10 баллов означает, что процесс без выполнения этой обязанности 'не выживет' или уже вызывает проблемы. Полученный приоритизированный список требований покажет, какие полномочия и возможности должны быть у владельца процесса в данной организации. Важно учитывать, что для разных процессов и организаций эти требования могут существенно отличаться в зависимости от критичности процесса, уровня сложности, организационной структуры и культурных особенностей. Например, в организациях, только начинающих внедрять процессный подход, владельец часто должен обладать широкими полномочиями, охватывающими все задействованные подразделения.

Этап согласования - это процедура утверждения какого-либо решения или действия несколькими ответственными лицами перед его реализацией. Он часто становится проблемным по нескольким причинам: наличие цепочек согласования с множеством участников (руководители, владельцы ресурсов, служба безопасности), необходимость инициировать дополнительные согласования для принятия решений, частая необходимость напоминать участникам об их обязанностях, кадровые изменения сотрудников (увольнения, смена должностей), разные сроки согласования, особенно когда в цепочке согласования участвуют представители бизнес-подразделений, которые могут не придерживаться установленных временных рамок. Все это приводит к тому, что согласования превращаются в «черный ящик», который сложно контролировать и управлять им.

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

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

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

Руководителям рекомендуется следовать трём основным правилам при работе с RACI-матрицами: 1. Если в строке стоит символ A (Accountable), необходимо определить, какими инструментами и с чьей помощью будет обеспечен контроль исполнения функции, так как ответственность предполагает не только полномочия, но и механизмы контроля. При необходимости можно потребовать от консультантов предоставления соответствующих инструментов. 2. Если в строке стоит символ R (Responsible), следует подумать о том, кому можно делегировать эту работу - полностью или частично, так как время руководителя ограничено и его нужно тратить максимально эффективно. 3. Если в строке несколько R (то есть работу выполняет не только руководитель, но и другие люди), необходимо уточнить, кто именно отвечает за организацию работы (это может быть не ответственный за конечную результат), а кто просто участвует в исполнении. Это удобно фиксировать в расширенной RASCI-матрице, где S (Supports) означает тех, кто участвует в исполнении. Если вы находитесь в позиции S, рекомендуется делегировать непосредственное исполнение, сохранив за собой роль в контроле процесса (Informed/Consulted), чтобы избежать выполнения работы под чужим руководством без вашего контроля.

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

Правильная формулировка вопроса критична, так как напрямую влияет на направление анализа и выбор ветки причинно-следственной цепочки. На каждом шаге ответ на вопрос «Почему?» формирует основу для следующего вопроса, и неточность в формулировке может привести к упрощенному или ложному определению корневой причины. Кроме того, качество вопроса определяет, будут ли рассмотрены все факторы (не только технические) и учтены возможные ветки. Это особенно важно, так как «правильно сформулированная задача – это половина решения», поскольку задает точное направление поиска ответа.

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