如何?專案管理軟體的通用性的思考

項目天生就存在差異。實際的項目，由於諸多因素的影響，項目之間的差異是較大的。尤其實現項目承包制之後，即便是同一個公司的專業性質、規模相同的不同項目，也會存在很大的差異，項目的重心往往取決於專案經理和項目總工，有的重視技術，有的重視物資，有的重視成本。所以要想一個“成品”來滿足大多數項目的需求，是很難的。
為此，我們來分析一下它難在什麼地方，個人認為有兩難：1）許可權機制；2）滿足管理思想。
1、如何滿足管理思想？
目前的專案管理軟體都將事務、分析一體化，而交易處理部分是滿足日常事務的，分析部分是管理者用來進行管理的。
交易處理部分其實是最容易實現通用的。比如物資管理、進度管理、品質管理，大小項目都一個樣，沒多大差別，差別就在於資料量上。
分析處理部分則不同了。這是滿足管理思想的關鍵。很難想象幾個億的大項目和幾十萬的小項目之間會存在相同的管理員模式。
事務、分析混雜在一起，項目的差異將導致系統差異巨大，系統模組複用度也不會太高。
所以我認為，第一步，就是設定單獨的交易處理子系統和單獨的分析子系統。即便這樣，分析系統也很難實現通用，但軟體複用度、可擴充度卻大大加強了。
2、許可權機制
事務型系統實現通用，在交易處理本身沒有多大問題，流程管理現在也很容易，問題就出在許可權管理上。
許可權分粗粒度和細粒度。粗粒度許可權是類級的，實現起來沒多大問題。細粒度許可權是執行個體級的，跟具體業務綁定：比如有的規定合約制定者R1可以刪除合約C1，有的卻規定必須財務科長R2才能刪除合約C1，更有的規定刪除合約必須有一個流程。這種跟具體業務密切相關的許可權，是不可能在使用中進行定製的，甚至是不可預見的。
3、業務基礎平台
我們必須正視上面兩個問題：分析系統的複雜性、細粒度許可權機制與業務的緊密相關性——這兩個問題是基本上無法解決的，所以只有做解決方案而不是產品。

真正達到這個目的，這裡還是借鑒那個時髦概念：業務基礎平台。可以認為，業務基礎平台就是公用組件+內部指令碼+介面（這個理解不知是否正確）。我們用它來組拼解決方案，而不需要動用進階語言來編程。其中指令碼就是粘合劑，也是最難實現的。（就象SAP做的那樣。）我一直認為，這可能才是最終的解決之道。