转自http://blog.csdn.net/g770728y/archive/2005/12/20/556720.aspx
这是我进入IT之前，发表在《项目管理者论坛》上的一个贴子。重新回顾了一下，并根据现在的理解作了整理，放到自己的家园里。由于见识少，仍有井蛙观天之感，但也算是体现了当前的认识吧。
一、探讨的对象
一直以来，都很奇怪：房建、水电行业的项目管理软件怎么都是倾向于施工单位内部项目部管理，而路桥行业的项目管理软件则倾向于从业主的角度来解决问题（几乎都是解决网络化计量的工具）。也许，房建、水电属“小结构”，施工点多、施工点单位成本小，施工的不同组合对成本有直接影响；而路桥行业属“大结构”，施工点少、施工点单位成本偏高，施工顺序一般均显而易见，粗放式的项目部管理不会有太多坏处。这个解释太过牵强，尤其是对桥梁项目的管理，其实非常类似于较大的房建项目。但对这种纯粹属于两个方面的项目管理，当然没有必要也没有可能整合。
当然，从学问上来考虑的话，当然是面向项目部的项目管理，更象项目管理。而面向业主的项目管理，怎么看都象是协调组织关系、简化工作流程的工具，没有对生产要素进行控制的概念。
我这里想讨论的，当然也是前者。
二、是什么促使我思考
促使我产生思考的，主要是如下几方面：
其一是项目管理软件的飞速发展和软件公司的各自为政。现在的项目管理软件公司太多了，每个公司都有一套成熟的理论，其实施工方对此考虑得倒是较少，所以只会被软件公司牵着鼻子走。多数是以进度计划为主线，还有一些是以成本管理为核心。在这里姑且不去评论哪一种理论更完美，我想说的是：软件只是软件，它提供的只能是一些功能，为用户的工作提供便利，真正的思想应该由用户选择。如果硬要套上一种思想，去约束用户的行为，是不是一定就是一种进步？所以我不想在这里谈思想，只想谈如何最大限度去给用户提供便利、提高单位生产力。
其二是CAD三维技术的发展，这在下面将有详述。作为工程行业，对CAD技术的发展对行业的冲击，绝对不应该视而不见。
三是当前项目管理软件的功能单一性。有些看似功能丰富，底层结合却不够好，连一个集成用户界面都没有。打开一个功能，弹出一个界面。这样似乎很合理。但总觉得象在单个软件中进行操作一般。
四是决策支持功能弱。不可否认，一般的软件都有一些分析功能。奇怪的是，我看了一些公司的产品简介，没有一家公司引入商业智能，决策支持也就无从谈起。尤其是当进行项目群管理的时候，商业智能——同时也是ERP的最后一根稻草，显得更是重要。
五是C/S与B/S的问题。就我所知，都还是C/S架构。现在流行B/S，可惜B/S的交互能力，实在是叫人不敢恭维，所以还出了个什么Bindows专门用于WEB程序界面设计，即便这样也比C/S差远了，还得付钱给人家。但C/S的部署能力、维护升级，让软件企业“可不是一般的苦哇”，经常可以看到哪怕是路桥行业最常见的同望WCOST（个人认为这个软件做得挺好），装在某台机器上居然不能运行，终级办法就是重装系统。
六是重复开发。这个毛病当然不止这个行业了。
三、关于三维图形技术
1、为什么引入3D
工业企业的终级目标是集成制造系统（是MIS、CAD、CAM、CAPP的集成，主要实现自动化控制与管理的集成），而建筑行业项目管理的发展方向，至少脱不开CAD。
原因很简单，施工中的一切工作，质量也好、进度也好、成本也好，都在围绕着施工图纸构造真实实体。我们讲以进度为中心，以成本、质量为目标，其实都逃不过工程的最终目的——构造真实实体。
不是引入了WBS吗？要CAD作甚？多数人会这么问。是，我承认：至少在较低的层面上，WBS已经解决了这个问题。但WBS的目的却显然不仅限于工程实体部位的分解，还可以包含诸多管理信息的分解。然而，最重要的，仍然是工程实体部位的分解。
之所以提出CAD，是因为认识到WBS只是一种编码，所谓编码，只能在“较低”的层次上解决问题。确切地说，CAD与WBS应用的目的，有一定的交叉。如下图：
可视化信息
工程部位详细信息
管理信息分解
实体部位分解
WBS虽有效地应用于工作分解，却无法形成自动化信息。我们心甘情愿地计算着图纸工程量（甚至用工程算量较件）、根据配合比计算着材料用量、根据施工高程用尺量/用CAD计算着当前挖方量，一遍又一遍。这还是个体。放大到全局，设计单位、监理单位、施工单位乃至业主，都在一遍一遍地重复着。这还算认真。放眼全国，有多少工程数量是认认真真算出来的？多数都“套用设计数量”，大家都认为这很正常。
外观展示方式十分溃乏。以进度管理为例，横道图、网络图都是给有经验的人、用很长的时间去分析的；质量管理也是如此。难道就没有一种更好的方式了吗？当然有——这个工具就是3D。
设计施工总承包离我们越来越近了，我们姑且不去讨论它是否合乎当前国情，它至少也会符合十年之后的国情吧。如果有一种方式，让图纸信息能够得到最大的共享，至少，在设计施工总承包这种模式下，其好处是显而易见的。
2、3D发展现状
任何一种理论，如果座落于空气中，显然只能是水中月，镜中花。我们来看一下3D在理论上带给我们的可行性吧。
目前的CAD三维技术已经发展到了一个很高的水平。机械行业的Inventor、Pro/E、solidwork等已较为成熟，建筑行业的xsteel钢结构、MicroStation等也发展得不错，这些软件都是三维实体造型软件，反映的是精度很高的真实模型，并且目前应用已经很广了，上述软件我多数亲自使用过，其智能化非常之高，完全可替代传统二维设计，并且设计速度更快。公路方面有三维数模软件，全面虚拟真实地形及各项设计参数，展示最终设计效果。CAD发展的趋势，必将由3D代替2D。
出于众所周知的原因，做路桥行业设计的同志喜欢套用老的设计图，除非是一座有影响的特大型桥梁才重新设计。上述3D软件多半是面向设计的，不是面向重用的，并且在钢筋混凝土结构的设计上还存在软肋，所以目前应用还不多。但随着路桥行业的真正成熟，相信这些软件会得到越来越多的应用。倒是建筑方面好象ArchCAD已投入实用了吧（是叫这个名吗？记不得了，上次差点买D版）。
3D要想真正应用于项目管理，在图形技术上主要是钢筋混凝土中“钢筋”“预应力筋”的表达，在实际应用中主要是设计单位要认可并使用这种设计模式。
3、3D给我们带来了什么
3D带来了令人振奋的丰富信息：每个部件包含了全部永久材料信息、质量信息；施工过程完全可视化，真实模拟施工过程；更易于避免各部分位置的矛盾，避免设计缺陷；等等。
与WBS、进度管理结合后，你可以根据横道图、网络输入进度计划，切换到3D显示，可以立即看到3D动态展示。这比死盯着屏幕钻研横道图不知要强出多少倍。
与施工方案模块结合后，你可以将施工方案直接体现在3D视图上，可以直接算出方案材料成本，并且方案完全可视——作过方案的人应该知道它的重要性吧。
质量报表一大堆，怎么办？切换到3D视图，通过设置，质量较差的部分用红色显示，一般的部分用黄色，优良部分用紫色，是不是比盯着一堆报表要中看得多？
算主材，好困难呀，天，这么多根柱，这么多根梁——不用算啦，3D已经包含了所有这些信息啦，而且精确到小数点后XX位。
编方案时，经常遇到计算结构自重，算得头晕眼花，有了3D模型，此何惧也！
就即便只用于工程部位分解，也比WBS要好用多了。这是理所当然的，必竟WBS只是编码。话又说转来，其实把3D的作业最小化，它就是工作包里的图形信息，尽管它的意义远超于此。
四、关于软件功能
1、要不要大而全
3D只是实现功能的一种更贴切的手段。下面来讨论一下软件的功能。
项目管理不外九大知识体系，所谓的行业差异不外文档不同，需要实现的精度不同，重心不同。抛开核心活动以外（即列入营业外收支的那部分）的内容，建筑行业的项目管理存在较多的通用性。
从实际的情况讲，软件不可能做得大而全，这一方面是为了适应当前建筑行业计算机水平较低的现状，另一方面所谓“言多必失”，在没有足够的实力支撑下，软件做大了也显得没了重心，而且总有些模块不能做精。这是现实，也是可以理解的。
从做软件的角度来讲，我们却还是希望能大而全。有公司经常讲（尤其做OA的）：我们什么都有，就看你要什么。虽有吹牛皮之嫌，然则确实如此，又有何不可呢？尤其是一些上规模的公司，本身就具有这个实力。SAP公司就是一个典型，他基本上可以对制造行业的任何公司说这句牛皮话，因为他确实什么都有，什么都做得好。
我在这里也卖了牛皮，因为我实际上并没接触多少类似软件，进入本行这不到四个月时间也不过在路桥软件上长了见识而已。但牛皮既然卖了，就卖到底吧。
2、功能层划分
这里准备把应用层分成两个截然不同的层面。一个是事务处理层，一个是决策支持层。
事务处理层主要进行数据的采集、简单的数据分析。决策支持层主要为领导服务。
2.1 为什么这样分
现在的系统经常会出现如下情况：领导要查询进度计划，没问题，请他到进度管理里看看吧。然后他忽然对质量状况感兴趣了，OK，退到主界面，选质量管理。
这样本来也没什么不好，问题在于：
1）如今的所谓集成系统实际上只是做了一个集成的壳，系统还是各自的系统。退出一个系统，重新打开另一个系统，和从桌面上运行另一个程序没有什么区别。换来换去，领导很不爽。
2）例如质量系统，既有数据采集功能，又有数据分析功能，菜单一大堆，领导又用得少，每次登录就得找半天，才找到自己想要的功能。领导很累，都快对系统失去兴趣了。
3）查询都是固化在程序中的，程序员说：你只能查某某项目，查询基准由我来给你定！领导就是领导，他是做决策的，他的要求都由程序员全部猜出来了，还要他干什么？当知道大多数情况下还是要手工计算时，领导真的晕了。
4）如何查询质量、进度的潜在关系？这可是跨功能模块的呀。
我这里要表达的意思是：事务处理层（主要是办事员和个别心细的领导用的）和决策支持层（主要是统计人员和领导用的）最好分开处理。
当然了，这是对特大型项目或项目群而言的。一般规模的项目没有必要这么复杂。
2.2 事务处理层
事务处理层也就是目前大多数项目管理软件所实现的功能。在这里仅仅把可以实现的功能再深入一点。
我们分析一下系统需实现的业务功能吧：
2.2.1 项目管理功能（九大知识体系与实际项目管理相结合）
1）范围管理：输入主合同界定的工作范围及合同变更。基础操作：输入3D模型；输入WBS；输入工程量清单；输入各项工程变更。
2）时间管理：实现网络计划功能；资源动态调配功能。
3）成本管理：财务管理；工程计量系统；概预算系统。
4）材料、设备管理：材料计划；采购管理；仓储管理；设备调配；设备折旧。
5）质量管理：试验检测；测量；质检资料。
6）人力资源管理。
7）沟通管理：网上视频会议；邮件系统。
8）安全管理。
9）文档管理。
2.2.2 3D模型编辑功能
2.2.3 协同工作功能
1）办公自动化系统
2）公告板
3）论坛
2.2.4 其它功能
1）知识库：如施工组织设计、各种规范、各种基础数据，等等。
2）多媒体生成功能。
2.3 决策支持层
上面的功能罗列了这么一大堆，不错，很全。但领导从中得到了什么？
一般规模的项目就不提了。如果是特大型的项目呢？如果是项目群呢？
首先，我们建一个数据仓库，数据仓库的数据自事务数据库（也就是事务型系统用的数据库）中抽取。这是一个规范化的、面向主题的、稳定的数据库。这个数据库主要存放的是结果数据。
有了这个数据库，我们就可以浮想翩迁了：我可不可以看三月份到五月份基础部分的资金完成情况？当然可以啦，前提是要建Cube。
然后，在数据仓库的基础上，我们建OLAP数据库，里面放Cube立方体。有了Cube，就有了无穷的变化，满足各种苛刻的、复杂的需求。
有了这些，计算机就可以对领导说：说吧！说你要啥吧！
最后，在OLAP的基础上，我们利用前端展示工具，既可以用报表，也可以用图形，甚至二者结合地展示我们的结果。
想想看，对有眼光的领导，这有多重要。
没错，这就是商业智能技术，上面提到的数据仓库、OLAP，正是其三大内容之二，还有一个内容就是数据挖掘，比如说可以根据历史数据挖掘质量与费用的关系，甚至进行风险评估。
刚做了一个项目群管理方面的东东，由于它数据量较大，在分析中又存在异构数据库的问题，感觉商业智能用处相当大。在单个项目的管理中，用商业智能是否恰当，值得商榷。但无论如何，如果SQL Server来实现的话，本身并不需要付出额外成本，又何乐而不为呢。（SQL Server的MS Analysis工具随SQL捆绑，免费）。
五、智能客户端架构
说实话，我对目前Java在企业级开发中流行的趋势不以为然。原因就在于它开发的低效率、高成本。据说同样的东西，用Delphi值几万，用XXX值几十万（不记得了），用Java值几百万，好象不无道理。配置复杂，却被认为是理所当然；高复用度早已被用户要求换更新的框架的噩梦淹没——谁叫它的框架太多呢。大多数理由指它可以跨平台，可惜到目前为止，可能很难找出有哪个企业先用Unix，然后换到Linux或Windows，至少在CSDN的Java论坛跨平台相关话题里，我没有发现。
也许是我不会用它，所以有成见吧。个人还是认为软件的本质是为用户的需求服务，这当中当然包括降低总体拥有成本，让用户少掏银子。所以我学.NET，因为我听说世界第三大银行就是用的WIN2K+SQL Server+.NET，这一辈子我是永远不可能参加这样的项目了。
呵呵，一点题外话，只是提醒各位做软件的大侠，不要忘了软件的本质，一味追求技术。
一句话，既不是C/S，又不是B/S，我推崇的项目管理软件，应是智能客户端。我认为，很明显地，这是在可以预见时期内的一个趋势。优点嘛，如下：
1）结合C/S的良好交互能力与B/S的良好部署及维护能力（这一点已经够了）；
2）尽大可能利用客户端资源。如果所有程序全是B/S的话，那我们的计算机只需要586就够了吧。这岂不又回到了类似无盘工作站的年代？客户机现在配置比以前服务器配置还要高，有什么理由不用呢？
3）支持离线应用。尤其是在网络时断时续的情况下，这一点尤其显得重要。比如在公路行业，线长面广，很多地方实际上不能上网，还有一些地方能够上网，信号也相当弱。传统应用中，一旦掉线就完了，没保存的就全掉了。在支持离线应用的情况下，可以随时保存在本机上，网络好的时候自动传到服务器上。
六、重复开发的问题
有没有必要成立建筑工程项目管理类软件的中间件公司？或者干脆做成一个可二次开发的平台产品。
七、后话
写这个贴子的时候，其实对项目管理软件这个行业根本不太了解。现在入行近四个月了，算是有了一点了解，再把它完善一下吧。自己还是感觉有诸多疑虑，不过王朔不是说了吗：无知者无畏。希望大家多提宝贵意见。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
