許多大型企業（甚至一些較小的公司）的業務最終都存在功能孤島，其中一些孤島甚至影響到整個業務流程的完整。

因為有些不同的任務步驟通常由不同的部門執行，而這些部門可能有相互沖突的目標：例如銷售部門試圖將收入最大化，而信貸部門則試圖將壞賬降至最低。在客戶訂單流程缺乏端到端指標的情況下，每個部門都會嘗試最大化自己的目標，而不考慮（或不知道）對其他部門和整個流程的影響。每個部門只做自己的部分，然后把它扔到下一個部門，并放棄對成功完成訂單的任何責任；此外，他們通常對自己的數據是專有的，并且不想跨越這些內部邊界共享它。這種情況必然造成系統的孤島，導致端到端流程實際上不是一個流程，而是一組可能無法滿足客戶期望的脫節操作。

這是康威定律的體現：企業設計的系統反映了他們自己的通信結構。

換句話說，如果企業被構建為幾乎沒有交互的功能孤島，可能會為每個溝通不暢的部門購買或構建不同的系統。

康威定律并未說明系統反映了組織結構，而是溝通結構：職能孤島不是（必然）問題，因為它們可能體現了執行某些步驟所需的專業知識。相反，正是這些孤島之間的溝通導致了客戶不滿意和運營效率低下的企業與那些專注于優化端到端供應鏈的企業之間的差異。

修復功能孤島之間的通信首先要發現端到端的業務流程，為流程建立目標，并分配流程所有者以確保實現目標。因此，BPM是打破這種功能孤島最好的解決方案。

BPM繪制流程的高級功能視圖，為訂單到現金流程顯示功能塊。這可以通過觀察和采訪參與流程的人員來完成，也可以通過對直接測量（系統日志）的流程挖掘來完成，從而通過供應鏈跟蹤單個案例。

然后，您需要對底層系統進行一些分析，以解決存在的一些通信問題：

詳細繪制每個部門的流程，以了解信息在該部門內以及整個流程中的部門之間流動的方式。檢查每個系統中有哪些數據，以及這些數據如何在部門之間共享，例如直接集成或批量更新。單個數據存儲不一定是正確的方式，但系統需要能夠無縫訪問他們執行整個流程的一部分所需的所有信息。

由此，您可以開始重新設計端到端業務流程相一致的部門流程和系統，而不僅僅是關注單一職能部門的利益最大化。我們必須認識到，有時必需降低部門目標的優先級，以實現整個流程的最高性能。

最終結果將是一個流程：端到端的業務流程（例如訂單到現金），深入到各個部門流程。請注意，擁有端到端業務流程的模型并不意味著該流程是底層系統中緊密耦合的編排：實際實現可能是微服務的事件驅動編排，或者在業務之間使用消息隊列職能。

為了推動接受這些變化，有必要收集端到端流程的運營指標，并將它們提供給各個部門，并結合他們自己的KPI。這使上游部門能夠看到他們的工作對下游流程的影響，并衡量每個人的工作相對于整體流程成功的情況。