「業務要求」似乎是it程式設計師永遠無法越過的一道坎，輕飄飄一句「不滿足業務要求」，足以讓你從雲端自由落體；「業務邏輯」是it程式設計師心中無法言及的痛，它總是那麼「蠻橫得不講道理」。如果讓程式設計師評選「最不合邏輯的邏輯」，結果一定會是業務邏輯。當「不滿足業務要求」，或者「不符合業務邏輯」 時，年輕的程式設計師總會弱弱地問「能不能就這樣」，大抵是讓業務遷就程式，結果自然不斷碰壁。業務員樂此不疲，程式設計師傷心不已。
業務是什麼？業是指工作崗位，務是指事情，合在一起是工作崗位上的事情。我覺得業務的含義就是完成一項具體的工作，會涉及人員分工、工作步驟、時限要求、工作成果、驗收標準等潛在的屬性。比如上市公司研究業務，就是**研究員按一定的上市公司估值方法，在規定的時間內給出研究報告及投資建議，並接受公司的考核。業務分析的過程其實就是找全業務的屬性並賦值的過程，每個業務點都可以套用5w1h、腦圖等方法進行析構，複雜業務可以採用分類等方法進行簡化。這項工作做得越細緻，分析就越透徹。
業務分析是業務建模的基礎，它的首要成果應該是分析出業務中涉及的主體，有抽象的，也有具體的。這些主體的概念一經明確，就具有了活力，有特徵、有行為、有生命，所以需要反覆推敲。我一般套用資料庫中的概念，稱之為概念模型。業務建模領域有些成熟的方**：用例圖可以幫助固化場景、界定範圍，類圖可以明確主體的特徵、行為及關係，時序圖可以明晰不同主體間的協作等。主體的屬性、關係一旦確定，就會體現在庫表結構設計和程式邏輯中，在專案的中後期改變起來非常困難，所以要慎重。我們經常能夠聽到程式設計師抱怨說這個問題當時沒考慮到，現在不太好改。比如兩個主體原先是一對一的對映關係，在某種極其例外的情況下，需要變成一對多的關係，估計就會傷筋動骨。
業務分析的第二項成果是梳理出哪些是變化的，哪些是不變的。對變化進行封裝，讓變化所帶來的不確定性只影響區域性範圍，是程式設計師高階需要掌握的一項基本技能。程式在很多時候就是為了管理變化。比如乙個檔案備份業務，不變的是需要將檔案從乙個目錄拷貝到另外乙個目錄，變化的是到底需要拷貝哪些檔案。通過配置、解析來管理這個變化，程式也就有了足夠的通用性。
業務分析的第三項成果是需要分析出哪些工作應該機器完成，哪些需要人工完成。這個「度」很難把握，需要綜合權衡風險、便利、技術成熟度等。在考慮風險因素時，需要認清到底是消除了風險，還是轉移了風險。我們不能做風險的搬運工。隨著計算機應用技術的發展，機器能做的事情越來越多，本著「事務型工作自動化、管理型工作流程化、決策型工作智慧型化」的原則，一點點地提高業務運作效率。
在你認為已經將業務分析得很透徹之後，加入時間變數，借用有限狀態機的概念，讓業務模型在紙面上運轉起來。你可能會發現很多新的問題：這時候可能你還沒有考慮清楚每個概念主體到底有多少種狀態，狀態之間到底如何變化，當不同狀態重疊的時候又該如何處理。千萬不要輕易給主體新增狀態屬性。比如乙個主體已經有三個狀態字段，每個欄位有兩個值，則這個主體就會有八種狀態。如果你再隨手增加乙個狀態字段，則至少新增了八種狀態，會使問題大大的複雜化，但你的初衷可能只是為了解決乙個小問題。事實上很多狀態並沒有實際的物理意義。兩個原則：原則一是寧願擴充解釋，也不要新增屬性；原則二是沒有物理意義的分支一定要剪枝。
以上是我在業務建模過程中總結的一些理念、工具和方法，其中滋味不足道也。不見得通用，也不能一招鮮吃遍天，需要在實踐中不斷琢磨、提高。
以資訊披露業務為例。
第一步：分類。由於業務繁多，所以我首先對它進行分類，比如：公募**招募說明書更新、公募**定期報告、公募**公告、年金定期報告、專戶定期報告等。分類是否合理，需要根據實際業務判定。我在實際操作中，將人員分工和管理流程一致的業務分為同一類業務，因此現在的資訊披露系統中已經有十幾類業務了。
第二步：主體抽象。和大多數人一樣，我一開始覺得資訊披露業務比較簡單，無非牽扯到的業務部門多一點，後來的事實證明我錯得離譜。閒話不說，看結果：
1、人，要賦予不同的角色：報告建立人、資料維護人、資料審核人、部門負責人、審計人員、業務負責人等等。
2、模板：這是對報告結構的抽象。
3、元素：構成報告模板的基本要素，對應報告中的乙個內容，可以是乙個詞彙、換行符，也可以是乙個**、圖，甚至可以是乙個word文件。
4、資料：給元素賦予具體的值。
5、報告：最終要交付的文件。
6、產品：公司運作的產品。
7、報告期：資訊披露的報告期限，不同業務需要的資料不同。
8、業務：人員分工和管理流程一致的資訊披露子業務。
9、部門：公司組織架構的一部分。
梳理出所有主體之後，進一步梳理出主體的屬性，篇幅所限，略過。
第三步：主體間的關係，反覆推敲，從而形成類圖。略過。
第四步：用例分析。我以批量建立定期報告這個場景簡要說明一下。批量建立定期報告是指年金（養老金業務部）、專戶（機構業務部）或一對多專戶（客戶服務部）在每個月初、季初或年初的時候，需要批量建立上乙個報告期的定期報告。除了建立報告外，其餘隱含的業務邏輯包括：
1、哪些產品需要披露定期報告？新成立的產品怎麼辦？產品如果不需要披露報告的怎麼辦？
2、每個產品使用什麼報告模板來披露報告？忘了維護產品和模板對應關係怎麼辦？模板還沒有怎麼辦？
3、模板是不是都已經正確設定？有沒有被人修改過？
4、通用的資料是不是已經維護好？
看似簡單重複地呼叫「建立報告介面」即可完成的批量建立報告，其實需要考慮的問題點很多。
第五步：定義動作，形成功能，比較複雜時可以借助時序圖。以批量建立報告功能為例，需要處理：
４、通用資料維護檢查：返回模板中涉及的通用元素的最新資訊。
５、建立報告。
紙面推演時，在確保業務正常運作的前提下，重點考慮例外情況處理。舉例來講，在任務分發環節，部門負責人可能按子業務將分發許可權授權給不同的人員負責；在元素維護部門對應關係上，同一元素可能因發起部門不同，資料維護的職責歸屬不同等等。找到例外並修改之前的設定，如此反覆。
15 資料倉儲 建模步驟一 業務建模
業務建模是針對公司或者部門級的業務進行全方面的梳理和分解，主要解決業務層面的分解和程式化 業務建模也是按照層級逐層展開的，依次是頂層模型，業務域，業務流程，業務環節 1 頂層模型 頂層模型是從公司整體業務的角度，劃分業務模組，以及各個業務模組之間的互動關係。比如公司有交易，財務，營銷模組，財務模組跟...
SAP業務模式 之ICS（一） 業務詳述
sap系統自身功能非常強大，支援多種業務模式，通過前台後台的配置就可以實現多種效果了。本系列的主角ics，英文為inter company sales，中文常翻譯為公司間銷售或跨公司間銷售等。業務大概的意思是有兩家關聯公司，一家是專做接單主體，只跟客戶打交道，一家是生產產品的公司，產品從這裡出貨。在...
一 業務場景 隨機生成患者姓名
一 需求 患者姓名2 20位中英文本串 二 用到的知識點 1 隨機生成漢字 2 列表轉換成str 3 生成隨機字串 三 示例 1 coding utf 8 2import random 3import string45 6class genname 7 隨機生成患者姓名 中文 英文 預設長度2 20...