对项目管理软件多维结构模型的思考

申请免费试用、咨询电话：400-8352-114

　　前言 我从事建筑工程项目管理多年，在工作的经验基础上，有一些对项目管理的认识和想法，一直想与同行共享和实现……以下是我的文章。
　　1.问题的提出，及对项目管理的初步认识
　　1.1　项目
　　许多项目管理的课程、书籍、文章、软件，均对项目作了一些定义。到目前为止，还没有一个共认的简炼的定义。
　　我们可以从以下眼光看一个项目。
　　如果你从远处看一个项目，项目就像一个点、一个名称、一件事情……（例如，国家大剧院……）
　　当你向项目走近时，你可看到项目的轮廓，一个建筑工程建设、一个飞机制造、一个新药品的开发…..从项目管理的角度来看（例如，一个建筑工程的建设……），你看到项目的技术配置（例如，市政外线、室外场区外线、结构工程、建筑工程、机电工程、精装工程、装饰品工程…）此回答了我们一般想问的“是什么？做什么？WHAT？”
　　当你进入或参与或调查或指挥此项目时，你逐步发现此项目所发生的建设过程中事件――项目进度（例如，立项、设计、招标、施工、验收、开业…），此回答了我们一般想问的“怎样做？如何做？HOW？”
　　再进一步了解发现，项目所需要控制的目标……技术、进度、质量、安全、风险、成本、合同、资料……此回答了我们一般想问的“要求是什么？条件是什么？WHEN、WHERE？”
　　看一个项目，就如同分解项目，由远到近、由表至里、“循序渐细”的。
　　由此，我们可以给项目一个这样的定义：项目就是一个相对独立的事件（远看一个点），此事件出自一个设想（项目输入原点IN），――→需要一个组织（项目分级组织OBS）投入资源并进行实施过程（项目实施过程WBS），产生一定的功能（项目技术配置PBS）、满足某种条件（项目约束条件RBS）。――→从而实现并验证此设想（项目输出结果OUT）。
　　1.2　项目管理的基础：“循序渐细”
　　从上面的项目定义，我们就不难理解项目管理的定义。
　　项目管理就是控制并实现一个相对独立事件的工作，包括确定项目的设想（项目输入）、控制项目的实现过程（项目过程）、产生一定的功能（项目技术配置）、满足某种条件（项目约束条件）。实现并验证项目的目标（项目输出）。
　　项目一开始，誰也不知道项目的一些细节，而是随着项目的不断深入，逐步明确了项目的阶段、条件、子项目、工序……故，项目管理的基础着重在于，明确了“项目总目标”后，“循序渐细”地进行项目的分解工作，使项目从大目标分解成小目标（子项目）――→合同包――→步骤――→工序……使我们各控制部门、各参加建设单位、各专业工种在此项目上同时“并行协同”地进行各自的工作。
　　那么，如何将所有人的工作组织在一个有秩的计划中？如何分解项目？
　　以往的项目管理及软件均是按WBS（工作分解结构）进行项目的分解，是一维的。不知道是先按项目过程分解，还是按项目技术配置分解，或是相互穿叉，很多时候我们自己就将项目分解乱了…。
　　按上述我们所看项目的眼光，可以用三维对项目进行分解，而时间单位仅是一个测量尺而已。
　　A.　第一维，按项目产出物或产品分解，则为PBS（项目技术配置分解结构系统）。比如，
　　汽车可分为车身、发动机、底架结构、外壳；
　　建筑可分为室外、裙楼、主楼、结构、建筑、机电、装修等；
　　B.　第二维，是按工作过程流程分为WBS（项目过程工作分解结构系统）。比如，
　　汽车制造可分为概念、设计、采购、加工、组装、测试等；
　　建筑的流程可分为规划、立项、征地、场地、设计、招标、采购、施工、验收、试运行、交付等）。
　　C.　第三维，是按项目目标分解为MBS（项目目标分解结构系统）。比如，
　　产品技术配置（在制造行业中已经经常使用此概念，有PLM配置管理系统）、进度、质量、造价、合同……
　　D、当然，在一个项目中还有一些多级、多层、多组织的概念：
　　多级别：项目是由各级单位组成的――例如，项目管理层次有投资人、业主、项目经理、项目监理、设计单位、施工单位、供应商、分包商、物业管理使用单位等；对不同级别的使用者来说反映不同的重点，对于业主高层领导，多层计划是看见较高级别的问题，从宏观的角度看是否存在工期的滞后、费用超出的问题，而对于项目管理部的计划工程师来说，看见的是比较微观的问题，即工程计划的哪些WBS和哪些作业存在问题，应该如何去调整计划。
　　多层次：项目（例如，在P3软件中）在EPS、项目、WBS、作业、步骤上形成“从粗到细”的、按照项目“渐进明细”特征的层层细化的计划，项目被细分为总目标――→大目标――→小目标――→合同包――→步骤――→工序……成百、上千、上万个工序和步骤。
　　多组织：所有的项目，均是由多个组织共同“并行工作”完成的。各单位组织按照上述分解系统，分别完成不同项目产出物，或在不同的过程阶段，或控制不同的项目目标，或承担不同的管理级别任务，或处于不同的管理级别岗位，或承包不同的子项目合同任务……
　　由此，可将项目目标分成多级、多维分解结构系统：项目总目标――大目标――小目标――合同包――步骤――工序……成百、上千、上万个工序和步骤。这些众多的工作均是以时间为测量尺，以逻辑关系或组织关系的前后顺序编排而成。
　　1.3　现有一些项目管理及软件，在实际工作中的问题
　　现有的项目管理，一般都使用项目管理软件辅助进行WBS分解工作，（是按一维方式分解的）形成一个个工作包（合同包）。并以进度计划管理模块为基础，然后将资源、成本、组织责任、等信息放置到每个工作包上，再按时间坐标进行排列，从而形成一系列项目管理各种子目标随时间轴的目标计划安排和每个工作包上信息强度列表（例如，资源分布图表）。来源于考试大
　　在此种工作中，通常，进度计划管理模块的表现形式有甘特图、单代号网络图、单代号时标网络图、双代号网络图、双代号时标网络图等表现方式。
　　甘特图的最大优点是表格化，许多项目管理软件中预制了大量的项目管理表格，十分方便于统计报告。但是，其最大的不便之处是一维表格，所有的项目工作分解任务均在左侧单列，往往一个项目的分解表很长，而甘特图中的条条很稀，占用很多纸张图面空间，不能一目了然。
　　双代号网络图和其双代号时标网络图的最大优点是图形化表现形式，图面很紧凑；但其最大的缺点是不能形成表格化，虽是二维的，但不能按项目分解的思路进行排列成表格。而在项目管理实践中经常需使用各式各样大量的表格，故而双代号网络图在项目管理中的应用遇到了阻碍。
　　单代号网络图和其单代号时标网络图的优缺点同双代号网络图。同样，在项目管理中的应用遇到了阻碍。
　　那么，为什么不能将双代号网络图或单代号网络图的图形制成表格状？用表格嵌套的方式进行项目管理。………
　　题外话，单代号网络图与双代号网络图之间可以进行转换。把单代号网络图中的节点方框拉长，就得到双代号网络图的工序线。有一些项目管理软件已经实现了此种转换。
　　另外，我建议：我们在双代号网络图中引进第三节点――即除头尾二节点外，我们在双代号的中段引进第三节点，用来表示工作间的搭接关系，则双代号网络图同样可以表示FS、FF、SF、SS等工作间搭接关系。
　　2.解决方法――用表格嵌套方法进行项目管理，软件的思路
　　为了克服双代号和单代号网络图不能形成表格化的缺点，我本人有以下建议模型。
　　2.1、我们经常会遇到此种情况，即在进行编制WBS工作分解结构时，到底是以“项目阶段过程”为主线进行分解，比如建筑工程项目分解成立项、设计、招投标、施工、验收等阶段过程，还是以”项目产出物”的专业系统为主线进行分解，比如建筑工程项目分解成结构、建筑、机电、装修、外线、市政管线等专业系统？有时候拿不准，二者相互穿叉，自己就分解乱了，出来的分解表自然比较乱。
　　其实，我们发现，在进行WBS工作分解结构时，用矩阵表方式是最清楚的。我们可以将项目实施的阶段过程和步骤分解项列在表格的顶部行中，将项目产出物的专业系统分解结构项列在表格的左侧列中，这样就形成了一个二维WBS矩阵分解表。表中各单元格内的数据就是项目子项目、或是合同包（或称为工作包）、或是各工序，各单元格相当于单代号网络图中的节点，各工作包格中可以承载――子项目编号、工作编号、合同分解编码，工作名称、工期、资源、成本、责任单位人、等。
再者，如果将上述矩阵表中各单元放在我们一般编制进度计划网络图中，按工序的逻辑顺序連线起来，再加上时间坐标，就形成一张同我们一般思维相同的《单代号时标网络图》：横向看是每个工作过程各阶段各步骤，纵向看是项目每个并行工作着的各专业系统。而且，此图也符合我们平常的工作编排―――即从图的横向看，项目各系统专业均有一个实施过程，比如建筑、结构、机电、精装专业均有设计、招投标、施工、验收等过程，从图的纵向看，项目的设计、招投标、施工、验收的每个阶段过程中均有项目各系统专业的人们在并行工作。图中的节点，即为大项目的子项目，或为小项目中的合同包。
　　在时标网络图中，将时间坐标放大顶部项目过程维中，各单元项承载的数据也就随之被放置在时间坐标中。进而，我们随之得到了有时间坐标的人员计划、图纸计划、材料计划、设备计划、场地计划、资金计划、机械计划、施工计划、验收计划、……。我们可以按照矩阵表的纵横两方向进行统计，进而，得到了有时间坐标的设计、招投标、施工等《项目各阶段计划》，或者，有时间坐标的《项目各专业系统的分包实施计划》其中包括各专业系统的设计、招投标、施工等工作。