作者 ｜ Mike Fitzmaurice
譯者 ｜ 劉雅夢
策劃 ｜ 丁曉昀
不久前，我的同事們表示有興趣使用我公司的數字業務流程平臺來構建一個應用程式，以管理他們正在考慮做的籌款活動的贊助商。當他們透過遠端網路聊天向我展示初步嘗試成果時，我被兩件事情震驚到了：
大量的欄位。
在他們的工作流程中只有很少的幾個步驟。我指出了這一點，問他們為什麼會有額外的欄位來記錄誰批准了什麼以及何時批准了什麼，許多額外的多行文字欄位，以及許多標記為“狀態”的欄位。他們回答說，他們需要知道步驟是否已經完成，是誰做的，每一步都發生了什麼，等等。
我感到既困惑又好笑，回答說：“你是知道每個流程例項都有一個內建的審計跟蹤，對吧？工作流的當前狀態已經給了你想要跟蹤的狀態？內建的註釋維護了一個執行緒，每個人的免費註釋記錄都帶有時間戳？”
還不止這些。對於那些似乎超出了範圍的資料，還有額外的列。當我問“你真的需要這個欄位嗎？它似乎與贊助沒有任何關係”時，他們回答說：“我想不是，但我通常會在其他應用程式中為一個組織收集這些資料，而贊助商就是組織。”
有三件事情變得顯而易見了：
他們工作得太辛苦了，得讓應用程式對平臺已經提供的東西負責。
結果，他們要求使用者更加努力地工作。
他們可能還有連他們自己都沒有想到的資料需求，但由於他們在考慮使用資料流程之前對資料進行了建模，因此我們暫時還無法發現這一點。我的同事們並不愚蠢（過去不是蠢，現在也不是蠢）。恰恰相反。但是他們長期以來一直以某種方式構建應用程式，以至於換其他方式會感到不自然。
這是“工具法則”在起作用，就像一個拿著錘子的孩子認為一切都是釘子一樣。
1
業務流程解決方案通常是怎麼構建的
以下的方式太常見了：
建立一個數據模型。
構建一些表單來編輯這些資料。
建立一些觸發自動化指令碼 / 流程 /zaps/ 方法來響應資料更改。換句話說，業務流程解決方案和任何其他應用程式一樣。如果我們回顧過去幾十年的業務應用程式，其中大多數都是圍繞著資料管理展開的。如何處理這些資料是系統之外的事情，通常由管理部門的集體負責人來完成。
2
為什麼要從資料開始，這是個問題
最明顯的問題是它本末倒置了。想想看……
在對流程本身建模之前，你如何知道需要哪些資料呢？
人們不編輯資料，而是執行任務。表單應該能適用於使用者被要求執行的操作。
你如何知道該活動確實會以你所期望的方式被觸發呢？就此而言，你怎麼知道這是正確的活動呢？不管怎麼說，這種偏見是真實存在的；我們中有多少人（如果不是大多數人的話）都接受過這樣的教育。事實上，許多業務問題的核心就是資料管理問題。但還有很多不是；它們是流程問題，以資料為中心的方法並不能很好地解決它們。
3
它應該如何發生
很長一段時間以來，我們將應用程式分為多個層（通常至少三層）。有一個表示層負責使用者介面，一個數據層負責訪問和儲存資料，還有一個邏輯層位於它們之間，決定向使用者顯示什麼以及應該讀取 / 儲存哪些資料。它有助於重用，有助於支援利用相同邏輯和資料的多個 UI 選項。它有助於讓 UI 專家、資料庫管理員等承擔專案，而不是每個專案都需要有全棧開發人員。
問題是，很多人傾向於從資料層開始，然後從資料層開始構建。相反，如果我們從邏輯層開始呢？事實上，如果我們在進入邏輯層之前，先從管理所有這三層的大圖出發，會怎麼樣呢？它看起來是這樣的：
確定我們想要的結果是什麼。
找出實現這一結果所需的步驟。
評估每個步驟需要參與的人員和方式。
檢視每個步驟將使用哪些資料以及由誰使用。有時候他們是需要檢查資料。其他時候他們需要提供資料。
建立表單和報告，將任務和結果展示給需要它們的人。這幾乎與常規方式背道而馳，但這是構建成功流程解決方案的方式。公平地說，一個從資料模型開始的人可能已經在頭腦中完成了前三個步驟，除了表模式和表單佈局之外，他不必費心寫下任何東西。這是可以理解的，但也很危險。
4
為什麼“資料優先”思維不適合
首先，資料優先的方式不會檢查（更不用說質疑）流程本身；它立即開始自動化活動。如果流程不理想，甚至無效怎麼辦呢？
我們經常對流程進行建模，以記錄它們，與利益相關方一起驗證它們，並將其傳授給其他人——最重要的是，改進它們。在太多的公司裡，他們所做的事情以及他們為什麼這樣做是含蓄的，沒有很好地溝通，並且就其真正含義引發了大量的相互競爭的觀點。
在嘗試自動化任何任務之前，你需要先處理流程。不這樣做的話，就像是用起重機而不是鏟子挖洞，但卻沒有考慮這些洞是否挖在了正確的位置上（或者根本不應該挖）。
光考慮節省時間和金錢是不夠的。自動化一個流程（不僅僅是它的活動）記錄它，使它具有可教性和可伸縮性，並有助於大大地減少或消除錯誤（引人注目的錯誤可能是流程自動化的主要催化劑）。它還能使流程更易於稽核和監控，並且有助於更容易地弄清楚如何改進你所看到的流程……
改進是必須的；如果說在流程自動化方面有一件事情是可以期待的，那就是更改。從一開始就完美是不可能的。異常會被忽略。假設會被省略。可以自動化的步驟仍然是手動的。這還不錯，順便說一句，持續的改進允許早期的不完美。即使今天一切都很完美了，需求也會隨著時間而改變。流程自動化的座右銘應該始終是“釋出、審查、修改、重複”。
5
高階使用者經常犯類似的錯誤
高階使用者，或者公民開發人員，如果你願意的話，也會遭遇“我擁有一個錘子，所以一切都是釘子”的問題。在他們的案例中，他們首先考慮的通常是他們想要檢視的表單以及他們可能需要收集的資料。
對於許多（如果不是大多數）高階使用者來說，表單就是資料（而不是進入其他地方獲取資料的視窗）。儘管如此，他們很少會在一開始時就花一點時間來思考為什麼表單會首先存在，以及我們將用它做什麼。直到解決方案開發週期的後期，才會考慮該表單應該發生什麼。
6
當我們做的時候，首先應是流程自動化，其次是活動自動化
流程邏輯會考慮流程決策，比如將請求路由到哪裡、應該獲取哪些資訊以做出決策、如果請求被批准 / 拒絕會發生什麼，等等。例如，處理休假時間請求的流程類似於“向員工經理傳送提出批准或拒絕的請求。確保經理知道員工是否已節省了足夠的假期來滿足請求的時間。如果經理批准，則從使用者節省的假期中扣除該時間，並讓所有人都知道他將在這段時間內離開。”。
這就是我們應該做的。還有怎麼做的問題。活動自動化，與流程自動化相對。比如：
透過使用特定的服務帳戶呼叫特定的 API 以訪問儲存休假餘額的人力資源業務線應用程式來檢查休假餘額。
計算請求中的小時數，忽略週末和節假日。
根據所請求的小時數來評估可用餘額。
使用 Microsoft Graph API 訪問 Microsoft 365 中的使用者和團隊日曆，同樣使用特定的詳細資訊。
格式化請求以新增或更新日曆項，並使用正確的憑據進行正確的 REST 呼叫以執行更新。
使用 Trello 簡訊閘道器向管理員傳送 SMS 請求。流程邏輯和活動邏輯都很重要。但是資料優先的思維方式，我們中的許多人對每個業務問題都帶有的偏見，幾乎都要求我們首先解決活動邏輯。這將是一個錯誤。
如果你從活動開始，那麼在應用程式快完成之前你無法對其進行測試。使用者必須等到一切都完成。幸運的是，在這段時間內，情況沒有太大的改變，但如果發生了改變，你可能只是把工作浪費在了不再合適的活動上。
但是，如果你從流程開始，你就可以讓使用者進行快速測試。即使最初的步驟仍然是手動的，這個流程也可以自動化。任務得到分配和監控。通知會發出。步驟不再被遺忘，錯誤也會越來越少。
現在，當用戶嘗試整個流程邏輯時，你可以自動化活動，在活動準備就緒時將其摺疊到整個解決方案中。使用者和利益相關方看到了一些即時的結果和穩定的改進，而不是為他們不確定是否合適的東西等待很長時間。
相反，從流程的框架開始。一份大綱。甚至是一份清單。即使這些步驟仍然是手動的，這個流程也可以更快地得到管理和自動化。早在你能夠自動化每個步驟之前，你就能夠跟蹤正在進行的工作的狀態，確保不會遺漏步驟，減少錯誤，並在事後稽核幾乎所有內容。
事實上，大多數航空業的飛機維修都是這樣工作的；即使許多步驟仍然是手動的，流程也是自動化的。在引入術前檢查清單之後，手術室的“意外結果”開始減少了。
當然，在時間允許的情況下，各個步驟也可以而且通常也應該實現自動化。但時間就是一切，如果你從一開始就只考慮如何連線到資料以及如何自動化手動活動，那麼你就沒有抓住要點。
7
流程優先的方法對更改更友好
如果你首先設計流程，並透過手動步驟儘早開始測試，那麼你將獲得可以用於更好地自動化活動的資訊。如果你從資料建模開始，你就不一定會擁有這些資訊。早期的航向修正並沒有那麼困難。
特別是當工作從資料建模和應用程式整合開始，並且在這些步驟上投入了大量的時間時，這些元件很可能在以後被視為約束。更改會被認為是代價高昂的。由於它們是首先完成的，所以整個應用程式被認為是很難更改的。
流程驅動的解決方案可以保持這樣的觀念前置：條件將會更改，應用程式將需要適應它們。我們實際上應該希望它以這種的方式工作，因為當用戶和業務利益相關方需要審查、批評和編輯時，我們可以從他們那裡得到更好的資訊。它每次都能勝過抽象的想象。
8
流程驅動的 UI 也更有意義
使用者考慮的不是維護資料——他們考慮的是執行任務。我們給他們的申請應該是有目的的，以適應真實的使用者故事。
當你開啟一個表單時，你有一項工作要做。該表單應該提供你需要了解的資訊，並收集你需要提供的資訊。然後它就應該消失了。
雖然你可能只是想瀏覽一條記錄，但通常有一個原因。如果你說你只想知道某人的電話號碼，我明白了。但我也知道，如果你這樣做，我們可能會記錄下你要打的電話，讓你記下發生了什麼，這樣我們就有了你下次打電話的記錄。事實上，這就是公司投資客戶關係管理技術的原因。
更重要的是，顯示什麼資訊，哪些欄位是隻讀的，哪些是必需的，等等？這因任務和使用者而異。表單或任何使用者體驗都應該適應使用者當前的需求，而不是他們將要接觸的資料。
表單可以獲取和釋出資料，但表單是用於任務的。活動，它們代表動詞，而不是名詞。是方法，而不是物件。
流程是思考這個問題的一個好方法，也是構建它的一個好方法。
9
有時，資料管理解決方案仍然有意義
這並不意味著每個應用程式基本上都是流程應用程式。資料優先的方法絕對可以最好地滿足許多業務需求。例如，任何涉及商業智慧的東西。很多特殊的客戶關係管理都可以透過這種方式進行。在某些案例管理場景中，如果沒有兩個案例彼此相似，那麼最好將資料提供給參與者，然後讓他們自己處理。
在這種情況下，沒有流程可以自動化。它太特殊，太特定於情況了，甚至看不到模式，更不用說嘗試建模和重複它們了。
在這種情況下，我們在構建解決方案時所能做的最好的事情就是找出如何最好地呈現使用者可能需要的資料（這正是我的同事在構建籌款應用程式時所做的）的方式。
如果我們擅長這類工作，我們就會與他們保持聯絡，尋找任何新興的可重複流程，這些流程將會成為自動化的良好候選項。
10
結論
形式應該遵循功能。資料和 UI 應該遵循流程。並且應該在適當的時間部署適當的工具、技術和專業知識，以便按照這種方式構建解決方案。
組織和團隊最好記住，當涉及到流程自動化時，這一切都與流程相關。正確使用工作流邏輯，資料活動和展示就會自然而然地隨之而來。
作者介紹：
Mike Fitzmaurice 是 WEBCON 的首席佈道師兼北美副總裁，他擁有超過 25 年的產品、諮詢、佈道、工程和 IT 管理經驗，在工作流 / 業務流程自動化、公民開發、低程式碼 / 無程式碼解決方案平臺和策略方面擁有豐富的經驗。他在微軟工作了十年，為 SharePoint 產品和技術建立了技術產品管理以及開發人員佈道。
https：//www。infoq。com/articles/data-application-process/