開環流程如何破壞業務中的信息流

在我的職業生涯中，我進行了大量的業務流程重新設計，而我發現的最大問題始終是相同的：開環業務流程。 開環流程的出現主要是因為責任分散在多個人之間，並且通常跨越多個部門。 從研發開始請求新設備的信息流可以通過財務和採購，然後超出組織邊界到達供應商（它將依次通過幾個部門），然後最終返回接收和採購。 ，幸運的是，發起流程的研發組。

在每個步驟中，都有可能導致溝通中斷，項目經理需要降低這些風險。 如果構建到業務流程中的信息流沒有明確地構造為捕獲然後處理任何異常，那麼直到很久以後才會檢測到故障，或者可能根本不會檢測到故障。 雖然某些信息流故障只會導致相對不重要的項目無法正確訂購或交付，但其他故障可能會使組織損失大量資金或延遲關鍵任務活動。

開環可能會花費數百萬美元

為了說明這一點，我首先要談談一家大型製藥組織，該組織正在為數億美元的設備納稅，它不再可以追踪，並希望消除這種不必要的開支。 我們的項目發現了許多基本的流程缺陷，所有這些缺陷每年都增加了數千萬美元的不必要的稅收，並且更多地用於錯誤地多次訂購相同的東西。

責任區域之間的單向溝通

像所有大型組織一樣，職責是孤立的。 製造部門的某個人需要設備 X，因此他們通知財務部，並生成採購訂單 (PO)。 訂購將採購訂單發送給供應商。 最多在未來一年，X 由 Receiving 交付和接受。 接收通知製造和財務。 財務發出資產標籤，收貨人將其貼在 X 上。X 被放入生產線，一切正常。

除了，一切都不好。 首先，員工來來去去，很容易訂購 X，而不會意識到九個月前同一角色的其他人訂購了 X。 財務部不知道這個訂單是重複的：他們假設您只需要另一個 X，因此會生成另一個 PO 並下達另一個訂單。 除此之外，即使您沒有意外地過度訂購，您也會很快忘記您擁有的東西。

讓我們假設 X 是一個複雜的設備，也許是一條填充線。 它由 20 個主要部件組成，在其使用壽命期間將多次更換。 隨意貼在 X 的一部分上的資產標籤會因磨損而消失。 更糟糕的是，資產標籤甚至可能不會被應用，因為它沒有及時到達接收。 在那之後，沒有人知道如何跟踪 X，因此也不知道如何在生命週期結束時將其退役。 從稅收的角度來看，X 仍然是一個有效的應稅項目。

在 20 多年的過程中，這將開始以一種不小的方式損害底線。 此外，財務部門正在使用其 ERP 系統的一部分和一組資產標識符，而製造部門則使用完全獨立的 ERP 模塊和一組不同的資產標識符。 到年底，沒有人能調和這兩組數字，審計人員質疑為什麼你的資本設備有數千萬或數億美元的差異。

這些都是由一組開環業務流程引起的經典問題。 開環是指您沒有在工藝流程線上建立明確的確認點。 在上面的例子中，有太多的開環過程，保證失敗。

創建雙向信息流

以下是我們解決問題的方法。 我們從頭到尾對每個重要的流程進行了建模。 我們確定了所有的開環。 然後我們設計了簡單的方法來關閉這些循環，一次一個，從一開始就開始。

第一步

製造業需要 X，所以他們要求財務部門開一個採購訂單。 財務部門現在與製造部門核對以確認，提供 X 的先前訂單的詳細信息可追溯到 24 個月。 避免意外重複訂單。

第二步

製造向財務部門提供了 X 組件的明細，這些組件將在工作壽命期間被更換。 Finance 為每個組件創建資產標籤並通過 Manufacturing 進行確認。 兩個 ERP 模塊都為每個組件填充了匹配的資產標籤，允許在整個資產生命週期中進行跟踪。

第三步

接收通知財務，財務通知製造。 資產標籤的放置由製造部門的負責方完成，以確保每個標籤都放置在其正確的組件上。 然後為兩個 ERP 模塊重新確認所有標籤/組件。

第四步

每次更換一個組件時，製造部門都會通知財務部門，製造部門會生成該組件的新資產標籤並將其放置在新組件上，然後在兩個 ERP 模塊中進行確認。 財務部門隨後開始從賬簿中刪除舊組件的過程，而製造部門則通過良好實踐指南 (GMP) 的退役過程。 在退役結束時，製造部門會通知財務部門，以便將資產從賬簿中刪除。

細節比這個簡化的例子要復雜一些，但要點很清楚：在沿途的每個階段，都有明確的檢查和確認。

確保應急行動

在另一個項目中，我被要求幫助一家服務公司提高其客戶滿意度。 他們的業務全是索賠處理，他們擔心自己未能中標。 此外，在他們的中標中，隨後客戶的不滿意味著他們的失賬率太高。

只用了幾天時間就確定了問題的核心，這又是一個開環流程。 當潛在客戶要求出價時，客戶經理將使用他們的內部系統將客戶需求大綱發送給負責組合出價的人員。 然後，投標創建者將創建投標並將其轉發給客戶。 希望客戶最終會做出響應，通常會進行所需的修改，出價創建者會將其構建到下一個版本中。 在某個時候，客戶會接受投標，會計將創建一個新的客戶帳戶，開具發票，並向入職團隊介紹情況。

第一個問題是投標創建者沒有向客戶經理明確確認，因此有時投標沒有按時創建和發送，而且沒人知道。 這是可能的，因為內部系統沒有顯示投標截止日期的字段，並且由於投標創建者永遠過度勞累，這導致投標提交得太晚。 由於業務中信息流通不暢，這些情況從未浮出水面。

之後，對出價的修改不會傳送給客戶經理。 這很重要，因為當客戶最終在虛線上簽字時，是客戶經理向入職團隊介紹了情況。 簡報通常是基於客戶經理的初步理解，而不是客戶實際接受的出價。

一旦開始參與，客戶文件就會到達並轉發給處理池中當週被分配來處理它們的任何團隊成員。 由於沒有明確的收據確認，文件可能會在沒有人知道的情況下丟失，直到客戶開始詢問他們為什麼沒有收到處理工作的結果。

當處理過的文件被發回給客戶時，收到後沒有確認，因此任何丟失的文件都丟失了，直到有人開始抱怨他們的缺席。

確認關鍵事件

在投標過程的每一步，我們都建立了明確的確認。 我們針對系統缺陷創建了解決方法，以便捕獲所有關鍵信息，包括要求的日期和後續的投標修改。 我們對公司內部以及公司與客戶之間的所有業務信息流實施了明確的檢查和確認。

例如，當客戶發送文件包時，他們現在會向客戶客戶經理髮送電子郵件通知他們。 客戶客戶經理會將其轉發給索賠處理中的責任方。 如果在三天內未收到文件，則會發出警報。 收到文件後，會向客戶發送一封電子郵件，確認收到。 當公司將處理後的文件發回給客戶時，情況也正好相反。

由於大多數客戶使用美國郵件來回移動硬拷貝文件，因此在每個步驟使用明確檢查的閉環流程意味著可以快速識別任何丟失的文件並採取措施糾正這種情況。

設計異常處理程序

為了了解如何以合理的輕量級但有效的方式構建異常處理程序，我們將看看我在職業生涯中遇到的另一個真實示例，當時我是一家專注於調查原因的科學研究組織的 CIO衰老和與年齡有關的疾病的誘因。

所有 NIH 資助的研究機構都包含許多單獨的實驗室，每個實驗室都由一名首席研究員 (PI) 運營，並配備各種下屬科學家和博士後。 在某些時候，PI 需要一個新的多室試劑托盤，因此他們要求其中一位博士後創建必要的請求。 博士後創建請求並將其通過電子郵件發送給財務部門，要求提出 PO，抄送 PI 以確保 PI 知道請求已發送。 同時，PI 設置了自動日曆通知，以提醒他們在某個日期未收到確認時檢查請求狀態。 這確保了故障安全機制，以防博士後忘記創建或發送必要的請求。

現在，如果博士後在設定的時間段內沒有收到關於提出 PO 的確認，他們同樣有一個自動日曆通知來與財務部簽到。 當財務部確實提出 PO 時，博士後會收到確認已發送給供應商的電子郵件，然後博士後會將此確認轉發給 PI。

在這個階段，PI或博士後設置另一個自動日曆通知，以確保如果在設定的時間內沒有收到供應商的任何回复，有人會與供應商核對以確保收到PO並發送已訂購的設備。

假設供應商確認收到採購訂單並發送項目以及發送通知，這將被發送到 PI 或博士後。 然後，他們在預定收貨日期後三天設置最終日曆通知，以確保如果物品沒有出現，他們知道要聯繫供應商以跟踪發生的事情並正確交付物品。 如果項目確實按計劃到達，博士後通知財務，如果組織使用資產標籤，則可以啟動這組流程。

在此過程的每一步，都需要明確的確認，並且有一個子流程可用於確保在主流程中斷時採取補救措施。 沒有任何東西是懸空的、未經證實的或不受支持的。 不需要特別行動，因為每個人都知道需要什麼以及如果出現問題該怎麼辦。

學習從 SQL 創建閉環流程

良好流程的本質與設計基於 SQL 的關係數據庫以確保事務一致性的方式非常相似。 任何行動都必須經過確認才能被認為已完成。 所有雙向通信都需要作為流程的一部分內置明確的確認，並開發下級流程以確保如果未收到確認，則採取正確的行動。 成功的項目經理應該創建閉環流程來改善業務中的信息流並為組織節省大量時間和金錢。