本文總結了共用共性流程的幾點考慮，并給出了可判定為共用共性流程的幾點情況。

1. 為什麼要考慮共用問題？

前言：作者理解的共性是指有相似的内容，不是邏輯相似就是前端頁面相似。可以完全不改直接共用，也可以合并流程，優化現有流程後共用。

現在的OA系統基本都有流程引擎，創建流程簡單快捷，往往新創建流程比改流程快的得多。那創建流程如此快，為何還考慮共用問題？

1.1 用戶操作重複、繁瑣

幾乎每家公司都有OA系統，并且OA面向公司所有員工，使用頻率很高，如果多個流程的界面和操作都相差無幾，會給員工造成重複的錯覺，若共用，不僅簡化員工操作，也減少學習成本和培訓成本。

1.2 數據單一、無利用價值

人員規模大的公司，部門多，流程也多，各部門間的信息不暢通，可能A有的流程，B也有類似的，但他們互相不知道。雖說創建流程很快，但PM得合理規劃産品，需站在整合者的角度給需求方一定參考建議，減少冗餘單一數據。

1.3 使用頻率低、影響頁面布局

系統使用時間越長，流程就越多，有些流程設計簡單且使用頻率很低。為了頁面美觀和辦公效率也需要不斷精簡、優化流程。

2. 如何判斷能否共用呢？

舉個工作中遇到的例子：

兩個工作内容和職責很相似的技術部門，都做提成自動結算。A部門已經完成，在試用階段了，但B部門因為和A類似所以就希望直接融合在A裡。以此為例，來說說我是如何分析是否需要共用的。

首先，從表面上判斷流程是否能共用，是否是同樣的需求，共用的部分多否。

案例裡AB部門都明确做提成結算，雖後台涉及的數據源有不同，但前端頁面内容90%相似，可以考慮共用。

其次，從技術上判斷開發能不能做，技術能否實現，估算共用和獨立的開發難度及開發時間。若差異較大，根據投入産出比計算，看是否值得投入多餘的開發成本來實現共用。

案例裡獨立比共用的時間節約一半，上線時間沒強制要求，所以，可獨立可共用。

再次，從利弊上分析共用後是否真正帶來便利，是增加/減少工作量，增加哪些人的工作，減少哪些人的工作，根據使用人數及使用頻率判斷是否需要共用。

案例裡AB共用，減少了有交叉項目提成人員的申請時間，但增加了審核人員的工作，有交叉項目的人員比審核人員多，但交叉項目的使用頻率比審核人員低。

遇到這種情況，若共用，應該讓受影響的雙方知曉，根據雙方協商意見再确定是否共用。

如案例裡的AB部門，受益的是普通員工，但變得複雜的是管理者，雖說普通員工占比比管理者多，但管理者的話語權更高。所以，這隻能把利弊告訴雙方，讓雙方溝通清楚後再做确切決定，避免上線後因雙方分歧導緻換方案。

最後，最重要的要看共用是否影響後期延展，是否有其他隐性需求（比如業務需求或者管理需求），很多時候這都成為決定因素。

案例裡B部門是從A部門裡獨立出來的，雖然B部門經常協調做A部門工作，但兩個部門的業務發展方向不一緻，在管理上各成體系，後期發展難免不同，那個性化的需求也在所難免。

綜上，這兩個流程沒有共用，原因是共用的開發時間長了一倍，并且影響審核效率和審核結果，後期有個性化需求，所以獨立分開。以上是關于有共性的流程是否共用的個人見解！

本文由 @Rabbit 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

,