5 L公司IT项目管理应用研究
L汽车集团是最早在中国销售梅赛德斯-奔驰汽车的经销商，经过十余年的发展，L汽车集团已成为奔驰在中国最大的经销商之一，同时也是中国汽车流通行业着名的汽车经销商。目前L汽车集团已经形成了以香港集团为总部，北京管理公司为管理层，下辖东区、西区、北区三个大区，超过60家分销商的四级经营管理机构。目前L汽车集团下属员工为5000余人，预计2015年将会增长到8000人左右。
L集团近年一直以主营业务目标为主，并没有特别重视企业信息化。随着业务规模的不断扩大，员工人数的不断增长，对信息化的需求也越来越迫切。3年前，公司成立了信息系统部门，隶属于企业事务部管理，属于公司二级部门，负责管理和实施公司内部信息化项目。由于信息系统部门成立的时间较短，集团公司还没有成型的IT项目管理管理体系，公司项目管理属于典型的弱矩阵型，项目管理人员在项目中属于协调者和沟通者的角色，项目实施较多的依赖于高层领导对项目的支持程度，以及项目经理的个人能力。
5.1 L公司IT项目管理案例背景
公司集团管理公司高层和经销商领导查看的所有业务运营报表数据，是由各部门和经销商的业务人员从现有运营系统中导出，然后设计excel报表，呈报给企业高层领导。另外，部分部门并没有自己的应用系统，数据是由经销商业务人员手工填写excel模板，来汇总数据之后提交报表。实际操作中会出现以下问题：
管理公司和经销商业务人员手工管理和汇总各类报表，效率较低，工作重复而繁琐，消耗了大量的人力成本。
报表数据来源分散、不易查找。
报表和数据版本不易管理。
历史数据无法进行对比分析。
跨部门数据不一致，无法进行横向对比。
无法更充分的利用数据辅助决策。
为了适应企业业务发展的需要和公司日益增长的商业分析能力的需要，使企业管理层更快、更好地了解各个经销商的业务运营状况和关键业务指标，充分利用和发掘现有业务数据，同时，为了改善基层业务人员重复且低效的工作状况，以有效节约人力成本，管理公司企业事务部的高层领导S,提出企业应当实施一套商业智能系统，来解决企业信息化当前的问题，满足企业发展需求。
BI （Business Intelligence）即商业智能，是一套完整的解决方案，用来将企业中现有的数据进行有效的整合，快速准确的提供报表并提出决策依据，帮助企业做出明智的业务经营决策。商业智能的概念最早在1996年提出。当时将商业智能定义为一类由数据仓库（或数据集市）、查询报表、数据分析、数据挖掘、数据备份和恢复等部分组成的、以帮助企业决策为目的技术及其应用。目前，商业智能通常被理解为将企业中现有的数据转化为知识，帮助企业做出明智的业务经营决策的工具。商务智能系统中的数据，通常来自企业现有的其他业务系统。
上述BI解决方案的特点，正好和企业的当前需求吻合，因此，S作为项目发起人和关键决策者，积极倡导这一项目的实施。项目经理D根据经验，选择了市场上一款比较成熟的BI产品，作为本项目的技术解决方案，并组建了技术实施团队。
项目开始前，项目经理D找到老板S做了初步的沟通。老板S提到了这个项目的目标：希望做成管理公司、各经销商高层统一的业务分析系统，满足企业高层的需求，同时节省基层业务人员的人力成本。对于项目实施范围，S指出这个系统应该涉及管理公司和各经销商的销售、售后、市场、金融&保险、财务、企业事务这六大核心部门的关键业务指标数据。同时也提到了自己最关注的一些KPI（KeyPerformance Indicator,关键绩效指标），例如销量、库存、利润、成本等，并提到目前企业事务部有一套excel报表，正是汇总了几大部门每月的数据，提供给管理公司高层的报表，可以用作项目参考。对于项目进度的要求是，项目必须在6个月之内，即2013年年底之前正式上线运行。
由于项目的时间比较紧张，项目经理D在拿到初步的需求范围之后，并没有跟相关部门做足够的沟通，就开始做了项目实施进度表。完成进度表之后，D草草组织召开了项目启动会，几位关键用户没有参加。项目经理D开始组织项目的实施，但是却在实施过程中，却出现了一些列问题。
在进行需求调研阶段，销售部门要求增加8套报表，不然系统对于销售部门实际运营没有太大意义。这个变化，让D措手不及。他马上安排重新了调整项目计划，压缩了项目开发时间，增加了需求调研时间。原本比较充裕的项目时间，一下子变得紧张起来。
在进行跟各个部门关键用户做需求调研时，发现各部门的经销商编码并不一致，S要求系统必须统一成同样的经销商编码。D重新组织跟各部门关键用户做沟通，终于统一了大家的意见。D随即通知设计人员调整了设计和编码，系统编码时间比原计划多花了一周的时间。
同时，由于售后部门的基础数据是从另外一套系统中导出的，这套系统的厂商前期承诺可以提供系统接口，当系统开始设计之后，技术人员发现第三方厂商提供的接口文档中，数据库结构逻辑相当复杂，且基础数据量非常庞大，要实现数据的抽取，系统必须采用更为复杂的设计，以保证数据质量和抽取性能。项目经理D只能安排技术人员深入研究数据结构并指定更好的技术方案。由于对前期技术风险预估不充分，最终导致设计工作延迟了三周的时间。
在项目实施编码接近尾声的时候，市场部门提出，2014年要求的指标和2013年的指标有一部分发生了变化，原来的数据模板不再适用。这样，项目需求范围又一次发生了变更。但是由于公司没有成文的项目需求变更流程，项目经理D不知道应该找谁签字。
由于需求频繁变更，项目组成员加班加点的工作，项目终于在2014年5月份上线，比原计划延期了 4个多月。上线之后，销售部门领导在使用中，发现很多数据质量问题，业务部门领导对系统的报表数据很不满意，直接发邮件给IT经理，要求IT部门解决这些问题。
通过对以上案例的描述，分析项目案例的特点如下：
1.项目有高层领导的绝对支持和重视。
2.项目需求来自于多个部门和经销商，因此项目需求收集难度较大，需求范围的界定和把握，成为项目关键。
3.项目涉及利益相关者众多，上至各职能部门高层、中层，下至各经销商基层业务人员。因此，对利益相关者的管理和沟通，是项目成败的重要因素。
4.与其他系统的对接存在着技术风险。
5.项目时间要求相对紧张。项目范围的不确定性，可能出现时间进度不可控的风险。
通过这个项目的案例的叙述和分析，我们发现L集团公司在实施这个项目时，暴露了很多项目管理上的问题。在后续章节内容中，我们将对案例进行详细分析，以结合上一章内容，优化L公司的项目管理方案。
5.2项目管理中存在的问题
5.2.1项目集成管理问题分析
本文认为案例中出现的很多问题，涉及到项目集成管理的几项主要过程，包括如下方面：没有明确的项目章程、项目初步范围界定不甚严谨、项目管理计划不够完善、没有完善的项目整体变更控制过程；首先，项目经理在还没有做好项目启动之前的准备工作时，就“草草组织召开了项目启动会”,这样做不符合项目集成管理的要求，这样做会导致项目后续实施工作面临巨大的风险。根据上一章的理论体系研究，在项目启动阶段，应当做一系列必要的启动前准备工作：1.需要制定项目章程2.创建初步的项目范围说明书。
项目章程的制定，包括项目目标、项目成功标准、主要风险、总体预算和总体里程碑进度计划等内容，同时，明确项目的参与者（即项目干系人），并最终组建一个项目团队，同时明确规定项目组各成员的职责。初步的项目范围说明书的建立，要依据项目干系人需求，进行初步的需求评估，与项目干系人就需求范围边界达成初步的一致。做完上述准备工作之后，才能正式的启动项目。案例中项目经理D并没有做好以上两项工作，就草草启动项目，并进入计划阶段，这样做的结果是，项目幵始需求调研时，“销售部门要求增加8套报表，不然系统对于销售部门实际运营没有太大意义”,一大部分的潜在需求被遗漏了，此前制定的项目进度计划必然面临调整。
“上线之后，销售部门领导在使用中，发现很多数据质量问题，业务部门领导对系统的报表数据很不满意，直接发邮件给IT经理，要求IT部门解决这些问题。”
这里也集中体现了项目干系人职责不明确的问题。项目干系人的职责分配，应该体现在项目管理章程中。同时，在项目进行的不同阶段，项目经理要不断回顾、继续明确和细化项目干系人的责任，并及时沟通汇报，获取干系人的承认和高层的支持。对于案例而言，在项目中后期，项目干系人的责任分工需要进一步的明确，随着项目的进展，去更新和确认项目维护人员的职责，明确了职责，这类问题将不会发生。
其次，在项目计划阶段，并未制定详细的项目管理计划。而项目管理计划的详细程度，应当根据项目规模和项目的实际情况适当灵活的进行调整。在案例中涉及的这个项目中，项目经理只是制定了项目进度计划，而对于其他计划并未涉及。
从实际项目情况来看，没有预先制定风险管理计划，在设计过程中出现技术风险时，没有与之对应的规避策略去应对和解决风险，是本案例项目计划的一个缺陷。另外，项目沟通管理计划并不明确，也导致了项目出现问题时，不能及时层报给项目决策者以获取支持。另外，本文案例中提到的“市场部门提出，2014年要求的指标和2013年的指标有一部分发生了变化，原来的数据模板不再适用。这样，项目需求范围发生了变更。但是由于公司没有成文的项目需求变更流程，项目经理D不知道应该找谁签字”.这个问题属于集成管理中整体变更控制的问题。因此，组织在执行项目实施的过程中，首先一定要有一个明确的可遵守的变更管理流程，来约束和规范化项目需求变更。这样做，才能避免出现当需求发生变更时，“不知道应该找谁签字”的问题。
5.2.2项目沟通管理问题分析
本文认为从项目沟通管理的角度来看，案例中存在以下问题：没有建立项目沟通管理计划、信息发布和绩效汇报机制不健全、没有进行项目干系人（即利益相关者）管理，导致沟通范围和方式不清晰。
案例中，在做需求调研时，出现了各部门经销商编码不一致的问题，这个问题表面上看是由于企业各部门之间横向交流不够，而导致的信息差异问题，是企业管理问题，并非IT系统的问题。但是，任何IT系统的建设的初衷，正是要帮助解决企业管理中存在的种种矛盾和弊端。项目经理D应该在发现问题之后，通过项目会议的形式，跟Project Management Office （PMO,项目管理办公室）反应这个情况，以获取PMO的意见。同时，这个问题涉及到多个部门，在会议上需要有高层领导参与，对是否统一编码，需要由高层领导或PMO作出决策，并达成一致意见。项目经理作为处理项目问题的协调人和管理者，应当本着对企业对项目负责的态度，及时反馈和沟通，尽早找到解决问题的方法。因此，在项目管理中，良好的信息发布和绩效报告机制，将使项目顺利的运转，起到事半功倍的效果。
5.2.3项目风险管理问题分析
从项目风险管理的角度看，本文认为案例中，几乎没有体现任何项目风险管理过程，存在以下问题：没有制定风险管理计划、风险管理意识淡薄、没有对风险进行识别和评估、没有对潜在的风险的制定应对计划、没有进行风险监控；结合本文案例和项目特点，项目至少存在着与其他系统对接的技术风险，同时，也存在着项目范围、项目干系人成员不确定性风险。这些风险最终可能导致项目进度不可控、项目成本上升的风险。为了避免风险最终演变成“灾难”,就应当遵循项目风险管理的各个过程。对于案例中的各类风险，项目经理D应当在项目计划阶段，制定完善的项目风险管理计划。同时，组织项目实施团队对风险进行识别和评估，并制定相应的解决、缓解或规避计划。对已经找到的或潜在可能出现风险，制作一份风险管理清单，并随着项目的进展，不断更新风险清单，随时监督问题进展状态。同时，风险清单和对应的解决方案必须及时做好信息发布，及时汇报给项目组或项目高层，以获取支持。
根据以上章节对IT项目管理体系的研究，以及对L集团公司IT项目案例情况的分析，我们需要针对性的对L集团公司IT项目管理体系进行进一步的应用研究。
后续章节我们将从IT项目管理的3个角度：集成管理、沟通管理、风险管理进行针对性的应用研究。
