協作移動辦公平臺，從老版OA替換爲BPM。OA是國內特有的企業系統，爲了滿足公司粗放型管理。先富起來的企業，早早搭建信息化平臺，第一個企業級系統就是OA。但正因爲上的早，沉澱了十幾年的管理邏輯，OA變的十分冗餘。此外，用戶習慣了OA的操作邏輯，特別是老員工，本就難以改變其習慣，對於OA有着堅定地執着感，除了界面他們承認新系統變得簡潔外，反認爲新系統不如OA好用。經常在講一句話，用慣了牛犁地，給他開拖拉機反而不適應。因此早用上了OA，反而不是好事，在信息化建設上，可能存在後發先至的情況。
回到我司，幸而sponsor態度堅決，BPM項目進程還算順利。BPM本身適合迭代式快速上線，先把平臺搭起來，功能增量往裏搬。不同於業務性管理系統，爲了保證切換後業務流暢通，以及雙系統並準數據源不唯一情況，無法按照MVP原則上線（或者說業務系統的MVP是在保證架構合理以及業務流跑通前提下） 。平臺型及工具性產品，在傳統型公司，也適合以敏捷方式開展。
OA與BPM的本質區別是什麼，沒找到明白的解釋。打個比方，也許類似信息化與數字化的差異。OA從行政審批起家，發展到各個部門，不同部門基於內部管理要求，對IT提需求。企業內部不同部門、不同領域，有着不同的流程定義及操作規範。而BPM注重端到端的業務流程，連接上下游，保證與其他應用系統的集成性。功能上，由於技術的更新，同時BPM做流程的專業性，支持複雜的審批場景，如加簽、徵詢意見、超時跳過等，在BPM可通過配置實現；善於兼容端到端的複雜流程，對於同一父級不同流行的業務流程，OA往往要開發不同功能承載，而BPM可以用一個大流程兼容；可方便業務用戶查看流程配置，梳理流程，進行優化改進；報表監控，將流程績效指標要求落實到系統中。
低代碼開發，托拉拽方式配置流程，類excel操作創建表單，交由業務部門關鍵用戶完成。理念很美好，實際難落地。一是業務太“笨”，培訓的成本還不如技術人員直接完成開發。而且即使教會了這位用戶，沒有邊際效益的，關鍵用戶只會負責部門內部流程，沒幾個的。但凡涉及跨部門流程，還是要找IT實現。公司弊端在於流程沒有owner，或者owner不知道自己是owner，更別說流程manager。因此沒法由manager配置流程；二是無法保證功能、樣式的統一，例如要求駁回必須填寫備註，而同意默認意見爲“同意”。表單、頭信息在頂部，行信息在中部，審批人信息在尾部；三是容易造成流程的部門牆，業務變成流程管理員，缺乏業務整體運營考慮，侷限於本部門或業務的要求。
核心功能點
-
待辦事宜：按照類型進行篩選，倒序排列
-
已辦事宜
-
我的請求
-
審批
-
同意/駁回：可設置駁回必須填寫審批意見
-
轉發：轉給其他用戶，僅供查閱。可用於意見徵詢
-
轉辦：將該節點自己的審批權限轉給其他用戶
-
傳閱：轉給其他用戶，僅供查閱。目標用戶查閱後，會給使用該功能的人通知，對方已查閱
-
引用：基於審批意見回覆
-
-
相關信息查看
-
流程圖：全流程圖及各節點審批人。點擊節點，顯示該節點未操作者、已查看者、已操作者
-
流程狀態：各節點執行情況，審批耗時
-
相關資源：相關聯的附件、文檔及流程
-
-
提交流程：提交後，集成IM消息推送，可直接點擊完成審批
-
流程代理：委託他人代爲處理，可根據代理人、代理時間段及流程類型範圍設置。
-
流程督辦：申請人可發起督辦，通知當前節點人處理，同時流程狀態中，會記錄該條督辦。
-
流程監控：按照自定義查詢條件，監控流程狀態。
-
報表分析：選擇表單字段，自定義邏輯創建報表。最喜歡審批效率報表，以各種維度排序審批時長。哪個人處理審批花的時間最長。例如大部分員工在意的報銷流程，一直被詬病，if you don't measure, you can't manage.
-
OA應用模塊。類似商城APP，IM的工作臺，大同小異。要與專業系統做好定位，BPM不能太臃腫，重蹈OA的問題。
-
文檔管理。對流程中的附件、文檔歸檔，以及模糊搜索查詢。