如何实现项目管理软件的通用性的思考

项目天生就存在差异。实际的项目，由于诸多因素的影响，项目之间的差异是较大的。尤其实现项目承包制之后，即便是同一个公司的专业性质、规模相同的不同项目，也会存在很大的差异，项目的重心往往取决于项目经理和项目总工，有的重视技术，有的重视物资，有的重视成本。所以要想一个“成品”来满足大多数项目的需求，是很难的。
为此，我们来分析一下它难在什么地方，个人认为有两难：1）权限机制；2）满足管理思想。
1、如何满足管理思想？
目前的项目管理软件都将事务、分析一体化，而事务处理部分是满足日常事务的，分析部分是管理者用来进行管理的。
事务处理部分其实是最容易实现通用的。比如物资管理、进度管理、质量管理，大小项目都一个样，没多大差别，差别就在于数据量上。
分析处理部分则不同了。这是满足管理思想的关键。很难想象几个亿的大项目和几十万的小项目之间会存在相同的管理模式。
事务、分析混杂在一起，项目的差异将导致系统差异巨大，系统模块复用度也不会太高。
所以我认为，第一步，就是设置单独的事务处理子系统和单独的分析子系统。即便这样，分析系统也很难实现通用，但软件复用度、可扩展度却大大加强了。
2、权限机制
事务型系统实现通用，在事务处理本身没有多大问题，流程管理现在也很容易，问题就出在权限管理上。
权限分粗粒度和细粒度。粗粒度权限是类级的，实现起来没多大问题。细粒度权限是实例级的，跟具体业务绑定：比如有的规定合同制定者R1可以删除合同C1，有的却规定必须财务科长R2才能删除合同C1，更有的规定删除合同必须有一个流程。这种跟具体业务密切相关的权限，是不可能在使用中进行定制的，甚至是不可预见的。
3、业务基础平台
我们必须正视上面两个问题：分析系统的复杂性、细粒度权限机制与业务的紧密相关性——这两个问题是基本上无法解决的，所以只有做解决方案而不是产品。

真正达到这个目的，这里还是借鉴那个时髦概念：业务基础平台。可以认为，业务基础平台就是公共组件+内部脚本+接口（这个理解不知是否正确）。我们用它来组拼解决方案，而不需要动用高级语言来编程。其中脚本就是粘合剂，也是最难实现的。（就象SAP做的那样。）我一直认为，这可能才是最终的解决之道。