Закон Конвея и сквозные бизнес-процессы


Оригинал: Conway’s Law and End-To-End Business Processes
Автор: Сэнди Кемсли (Sandy Kemsley)

В прошлой заметке мы говорили о проблемах, вызываемых нестыковками по вертикали бизнес-архитектуры, а именно, несовпадением целей и KPI на разных уровнях организации. Но заботиться надо и о стыковке по горизонтали: если никто не отвечает за сквозной «от и до» бизнес-процесс, то некому будет позаботиться об удовлетворенности клиентов.

Многие крупные организации (и даже некоторые поменьше) в итоге приходят к функциональным анклавам, и для завершения бизнес-процесса в целом требуется участие нескольких анклавов. Рассмотрим, например, процесс «от заказа до отгрузки и оплаты»:

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

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

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

Так проявляется закон Конвея:

Системы, которые проектируют организации, являются отражением структуры их коммуникаций.

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

Обратите внимание: закон Конвея не говорит, что системы являются отражают организационную структуру – скорее структуру коммуникаций: функциональные анклавы как таковые не являются (не обязательно являются) проблемой, поскольку в них аккумулированы специализированные компетенции, необходимые для выполнения определенных шагов. Коммуникации между подразделениями – вот то, что отличает организации, клиенты которых недовольны, а операции неэффективны, от организаций, нацеленных на оптимизации сквозных цепочек.

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

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

Затем надо будет провести некоторый анализ информационных систем с целью исправления существующих проблем взаимодействия:

  • Составьте схемы процессов каждого подразделения, достаточно подробно показывающие, как информация протекает внутри подразделения и между подразделениями в рамках процесса в целом.
  • Выясните, какие данные содержатся в каждой системе и как эти данные передаются между подразделениями – например, с помощью прямой интеграции или пакетных обновлений. Единое хранилище данных – не всегда лучший путь (особенно с точки зрения масштабируемости), но у систем должен быть легкий доступ ко всей информации, необходимый для выполнения своей части процесса.
  • И снова, опираясь на проработанную ранее структуру целей, определите цели для процесса каждого подразделения, согласованные с целями процесса в целом и высокоуровневыми бизнес-целями.

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

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

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