这一周一直做福建项目的标书，今天下班前却得到通知，不投了，白忙一场。顺便做做总结，也不枉熬过的几个寒夜，呵呵。
一、质量管理为什么总是成为鸡肋？
正是如此。国内不知出了多少所谓《质量管理系统》，每一套系统都鼓吹自己如何先进。然而我顺便从网上down了个试用版，却感觉功能太差，居然不支持稍复杂一点的分部分项工程划分，自然不能给出准确的汇总评分。给人的感觉是软件的制作者并不了解工程是如何划分的。
当然，这只是从软件的角度来看。从实际操作的角度来看，质量管理工作分为两大块：
1）质量表格的填报。包括原始表格、监表、质量评定。
2）质量流程控制。如开工、检验申请、中间交工等。
现实地看，软件只宜包括“表格填报”中的“评定”这一项。就连这一项，都面临不小的困难：软件除了能帮助汇总外（汇总通常工作量很小），并不能起到太大的作用。这个汇总工作，还跟软件功能有关，功能不强，就连汇总也不成。这种情况下，还要软件做什么？
同时，软件并没有实质地减小工作量，反而在某种程序上增大了工作量。监理签字本来是非常方便的，基本上可以达到2到3秒一张表格的速度。现在却必须耗尽时间，一张一张打开表格，然后一张一张签字，签字完成后，承包人打印后还得再签一道。个人认为，这是质量管理系统不能推广的本质原因。
这个问题如何解决？我在《质量管理系统科技申请》中已作了阐述，只有走电子签名之路，别无它途。而电子签名必须得到档案部门的认可。
二、进度管理为什么形同虚设？
进度管理系统同样较多，P3没用过，Project和梦龙有个协同工作概念，其余的好象一律是单机版。可惜协同工作也不过是几个人可以同时在一张进度图上进行工作。然后，这些软件无一例外地非常重视资源优化。
作为路桥行业，进度控制不是件太复杂的事，至少不会复杂到某几个人同时在一张图上工作的程度。从业主的角度来看，资源优化不过是承包人内部管理，也不用过多关心。
那么，是不是公路行业不需要进度管理了呢？
非也。不是不需要，而是重点转移了。
个人认为：公路工程进度管理的重点在于：让参与方随时掌握、控制工程进度本身，评估工期风险（而不是资源动态优化），同时对承包人上报的计划、完成情况进行确认。
基于这个思想，我在《建设项目动态管理系统科技申请》中提到如下观点：
1）采用C/S架构，一个项目设一个中央数据库。
2）既支持便于业主管理的总项目管理，也支持便于施工单位输入的子项目管理。总项目管理用于业主进行总体安排、调度，子项目管理则以施工标段为管理单位，每个施工标段作为一个子项目，标段之间不能互相查看，但业主可以查看所有标段。
3）基于工程分解结构WBS，能根据需要对工程项目进行任意层次的分解，适应不同的管理深度。WBS与工程量清单建立关联，由计算机自动根据当前进度计算完成产值；
4）多种多样的图形化显示方式，多层次的查询方式；
5）能随时汇总各标段、各标段中的重点监控对象、总项目的进度、完成产值等信息，利用前锋线技术显示当前进度；
6）完善的权限管理（群组及角色授权）机制、工作流管理机制。能灵活地定义每个组织机构、每个操作员的管理权限，也可自定义审批流程；
7）不仅能显示单项工程完成百分率，也能显示完成实物工程量（如墩柱完成多少米）；
8）支持地理位置查询，能直接从地图上点击某结构物，显示该结构物当前进度情况。既可以用图形显示，也可以显示施工照片。
至于同望在EasyPlan中，与其WCOST相关联，能将“预算成本”与WBS结合起来，随时根据计划产生挣值，个人觉得并无用处。首先：这样的架构是面向项目部的。其次：根据项目预算计算得到的“预算成本”与实际成本并无多大关系。
三、费用管理为何发展较好？
很简单，费用管理需要更多的计算，更好的准确性，更高的可靠性，而这正是计算机的长处。
四、公路工程项目管理引入“中间件”、“平台”概念的可能性
如果要我做一个平台，我一定只会将WBS管理逻辑和工作权限逻辑、工作流程逻辑、网络计划逻辑、质量评定逻辑作为平台的中间件。
原因嘛……计量规则变化太多，但计算简单，制表麻烦。质量管理与进度管理核心逻辑相对固定。
然后，呵呵，就把各种插件插上来吧，轻轻松松J
五、综合化管理是必然趋势
其实综合管理的概念早已不新鲜了，建筑、水电行业正炒得如火如荼，综合管理引入公路行业是迟早的事。
以前的项目管理系统基本上都是在计量支付上做文章，确实，这太简单。质量、进度管理软件基本都采用单机版。
综合化管理是必然趋势，不多说了，看看建筑方面的软件就知道了。当然了，底层还有一门沟通语言，它就是WBS。
展望一下吧：变更增加一根桩，输入WBS信息后，计算机就知道：这根桩是X合同段X特大桥X号墩承台下面的，它有I、II级钢筋多少吨，C30砼多少方，然后就是修正清单，接着提示输入进度信息。点击它还可以查看质量状况，甚至施工图片。多么美好啊J
六、项目群管理带来的新机遇
很早就预见了，这么快就碰见了，呵呵。
每条路都要一个解决方案，这样的成本太过高昂。于是肯定会要求一个软件尽量重用，用到多个项目上。
想法不错，嗯，好象缺点什么。
对了，不可能吧？以福建这三个项目的计量为例：计量表格不可能一样，所以视图层不一样；逻辑层也多少会有差异；数据层当然也不会相同了。
所以实际还是做三个项目，不过如果省里肯让这三个项目管理方式趋同的话，那可以尽量提高软件的复用度。
噫？业主不是要求我们进行多项目管理吗？如果数据库都不同，万一要我查三个项目今年完成多少计量，莫非我要先设定一种标准格式，将A、B、C项目数据转化为标准格式再进行统计吗？
那如果有十个二十个项目，这个小小的功能还不累死人也？
还有，这些异构数据库今后还有多大利用价值呢？里面可是什么都有，什么审批过程，什么附件。但作为历史数据，我只关心结果。
“……那把所有项目结果提取出来，转换成统一格式，放在另一个库里不就得了？”说得好，“另一个库”就是数据仓库。这个转换过程就叫ETL。
领导今天要我统计A、B两个项目三~七月计量额，明天要我统计B、C项目四~八月份重大变更总额。我的天，哪个做程序的能预料这些“莫名其妙的需求”？如果这也叫“潜在需求”的话，可能没有几个牛人能够发掘出来吧。
——现在，又该OLAP粉墨登场了。这玩意就是专门解决变化的需求的。
领导看到报表了，可是看了半天，看不懂，“什么污七糟八啊，小X，快，去画张柱状图来。”“柱状图来了”“哦，这好象用折线图能更好地表达意思啊？”“尊敬的领导，程序没有提供这个功能啊。”
——且慢，有数据前端展现工具，只有想不到的，没有办不到的。
哈哈，说了半天，就是想表达一个意思：项目群管理，迟早要结合商业智能BI技术。
七、关于体系架构
好累啊，不过还是得写完。
现在流行B/S。其实B/S用于项目管理并不太好，尤其是施工单位意见最大，交互性极差的B/S，显然不能满足大量的数据输入工作的要求。
但分析系统好象用B/S就相当好啊。
归结起来就是：数据采集系统：C/S架构。数据分析系统：B/S。
不过说真的，正阳帮我们的PB程序转B/S，也不知用的什么技术，反正转出来后，所有操作同C/S一模一样，既保留了C/S交互性强的优点，又保留了瘦客户端的优点。尽管有点剑走偏锋，但我个人认为这相当不错。
意犹味尽，尤其是架构这一部分。有空再来吧，熬了几夜了，眼都睁不开了。