業務規則引擎平臺如何降低程式設計師工作量？ - brcommunity

banq發表於2022-03-08
程式設計師Unity

目前自動化運營業務決策做得相當好，可以業務邏輯的編碼從程式設計師轉移到專門規則引擎平臺，從而顯著提高 IT 生產力。
但是程式設計師仍然要對另一種與規則相關的編碼負責，這種型別得編碼不僅消耗大量資源，而且對服務質量和資料質量都有深遠的影響。
 
讓我們透過一個示例規則來探討這個問題。

規則：如果客戶已下訂單，則必須將客戶分配給代理。


正如我一直推薦的業務規則一樣，該規則以純粹的宣告方式表達。因此，規則宣告並未指明任何特定的流程、程式或其他方式來執行或應用它。
現在問自己這個基本問題：為什麼我需要任何流程模型來執行它？！
人類無需參考任何流程模型即可正確理解和執行規則。那為什麼機器不能呢？！

在當今世界，大量的程式設計師工作量來自於構建流程模型和編寫程式碼來執行規則。
這是一個巨大的工作量，在任何規模或複雜性的企業中，實際上都有 1,000 條這樣的規則。

這裡的規則並沒有說：請觀察“當客戶下訂單時”，然後 [做XXX]。(它是說：如果客戶已下訂單，而不是：當客戶下訂單時)
（banq注：當然，跟蹤“客戶已下單”這個事件，一般是在動作“客戶下訂單時”命令發出的時候，但不只是在這個命令動作，還有另外一命令：代理辭職）
“當客戶下訂單時”並不是唯一可能違反本規則並因此需要評估的事件。
還有一個可能違反此業務規則的事件：
“當代理離開我們公司時……”。
當代理離開時，他被分配的客戶可能會被擱置一旁，這也違反了本規則。
因此，業務規則也需要在後一種事件中進行評估。
 
換句話說，在兩種截然不同的運營業務事件中可能會違反此規則：
  • 第一個，“當客戶下訂單時……”，這類事件發生機率相當大。
  • 第二個，“當代理人離開我們公司時……”這類事件發生機率可能要少得多。

儘管如此，這兩個事件都很重要，因為任何一個都可能產生違規行為。我把這些明確的事件稱為規則的閃點。
 
如果你喜歡從決策的角度思考，問問自己第二個閃點對應的業務決策是什麼。
也許您可以為此目的發明一個，但從商業角度來看，這不是很自然。
現在問自己這個後續問題：當前 IT 方法和工具中的哪些內容可以確保您在所有可能出現規則閃點的所有流程、程式和用例中獲得一致的規則結果？
不要忘記臨時事件；也就是說，輕量級甚至無指令碼的業務事件。
不幸的是，今天的答案是幾乎沒有。
如果這項工作完成了，那就是程式設計師的工作，換句話說，這變成了程式設計師的工作量。
 
而且由於這是程式設計師的責任，因此很容易出錯。它會產生難以維護的脆弱系統，尤其是當您的規則發生變化時。
順便說一句，這個程式設計黑洞是許多組織的資料質量如此糟糕的一大原因。
  

定義性規則與行為規則
回過頭來看整個規則空間，這個例子表明，從業務（和邏輯[1]）的角度來看，實際上存在兩種不同型別的規則，而不僅僅是一種。

  • 定義性規則

這種規則不能被打破。一條“定義性規則”可能是壞的或錯誤的，但它不能被違反。當然，您可以選擇忽略結果，但那是完全不同的事情。
示例：如果客戶在一個日曆年內下達超過 12 個訂單，則該客戶必須被視為黃金客戶。
決策規則和決策表屬於第一類。
  • 行為規則

行為規則可能會被違反或破壞。它們管理持續活動的行為，因此對人員、組織和業務活動至關重要。非常粗略地，您可以將行為規則視為業務約束。
示例：如果客戶已下訂單，則必須將客戶分配給代理。
通常，行為規則可能會在多個閃點被違反。
 

觀察者
讓我們用足球來說明和分析行為規則的執行情況。眾所周知的足球行為規則包括越位和禁止從背後剷球。
這些規則是由觀察正在進行的比賽活動的裁判進行評估的，並實時判斷是否有違規行為。

踢足球不需要任何流程模型。這將是一個多麼奇怪的概念啊

相反，為了執行行為規則，足球運動有一個裁判，我稱之為觀察者，他是事件活動的外部人員，能夠在任何時候打斷事件活動。
對違反行為規則的檢測和反應都是實時發生的。

對行為規則的執行進行實時干預的概念是至關重要的。
就像在足球比賽中，你不能等到事件活動的後期才執行許多或大多數行為規則，因為那時已經太晚了。
違規行為所造成的傷害可能是其本身的許多倍。
 

行為規則的來源
在我們捕獲的所有規則中，有超過50%是行為規則。

行為規則的自然來源包括法律、行為、法規、條例、合同、協議、諒解備忘錄、交易、許可證、證明、契約、保證、引證、收據、通知等等。最後但同樣重要的是大多數商業政策。

我們 "發現 "這麼多行為規則的事實讓決策界的一些人感到驚訝。恕我直言，這是因為我們的方法並不侷限於只看決策模型和決策表。
相反，我們認為適當的焦點是更大的商業治理和知識協調問題。

 

相關文章