[转帖]《中外管理》：探秘技术项目管理
<br/><br/>“再造”、“e化”、“变革”……呼吁声，附和声，我们已经听得太多了，但总是说得多，做得少，做好的更少。然而狂热的呐喊之后，我们总要切实地实施。于是，真刀真枪的“技术项目管理”浮出水面。这里容不得任何花架子。原联想集成与北京三露厂“联合制作”的ERP噩梦足以让人在唏嘘中冷静下来。值此时刻，拥有30年实践经验的SAP公司，和20 年研究心得的信息系统教授贝内特，一语惊人，指点迷津。<br/><br/>**********文章一:SAP解析ERP悲剧***********<br/><br/>本刊记者 邓波<br/><br/>**中国ERP第一案，一塌糊涂！**<br/><br/>“现在很多企业或多或少都有一些系统和IT项目，但是，这其中有30%～45%在完成前就失败了，而且失败的项目还都是管理层所看重的关键项目。再有就是一半以上的项目都超出预算和进度200%甚至更多。……在一项调查中，超过60%的企业经理认为，他们已经错误地应用了购买的软件包，并且只有极少有收益甚至是没有收益。当失败发生时，直接的损失不用说了，在业务上的总的间接损失要多得多。”<br/><br/>美国加州大学信息系统教授贝内特得出的以上结论，真是触目惊心。然而在事先，我们又经常无法预见，一个技术项目的实施过程中，到底会存在哪些问题……直到最近媒体披露了“中国ERP第一案”。为了让读者一目了然，记者针对此案制作了以下表格。<br/><br/>案件时间表显示，联想承诺项目进度为一年，但到2000年7月的最后失败，可以看出实际进度为2年零4个月，而此案件的诉讼时间竟长达1年零2个月。原因是此案大量地涉及了技术问题，而且合同签订不严密不规范，在争论中双方无法说清ERP验收标准。计划书上没有双方当事人的签字，每一次业务修改双方负责人也没有签字。这些问题其实都暴露了技术项目管理人的法律认知缺失及实施经验的严重匮乏。<br/><br/>**联想集成的三大败笔**<br/><br/>那么，企业信息化的项目管理该如何实施？拥有“世界第一ERP”美誉的德国SAP公司依靠其30多年的成功实践，无疑有助于我们洞悉其中的奥妙。为此，记者专访了SAP大中华区执行副总裁黄骁俭。<br/><br/>面对记者的困惑，黄骁俭一脸轻松：“这样的事在我们业内已是见怪不怪了，比这更大的失败都有，只是你们不知道而已。从整个事件来看，从用户的购买、选型，以及合同的签定，到后面的实施控制，大家都是没有经验的。比较专业的做法是，用户在购买前就应该知道自己到底需要什么样的东西。为此，用户必须要请专业的公司或专家帮助你分析需求。从我看到的报道来看，至少三露厂没有很认真地做过这样的事情。”<br/><br/>那么，联想集成是不是应该有义务帮助用户分析需求？“理论上讲是这样的，但是联想只是代理商。如果请厂商做分析的话，他往往从自己的产品角度去分析你，把你引导到他现有的模式中去，这对客户是不公正的。而请第三方专门机构协助分析，就可以减少一些风险。这个项目实际一开始就给自己埋下了隐患。进而，实施方联想集成又犯了一系列错误。<br/><br/>“首先，他们刚刚开始做这类项目时，不是很专业，也不是很懂。为了卖掉产品，他们做了过度的承诺。比如他的后期服务，花6万元就去承诺长期的软件升级、24小时服务，没有哪个公司是能做到这一点的。第二，我感觉联想集成是吃了MOVEX的亏，他们并没有很好地对MOVEX产品进行非常深入的了解。第三，他们选择MOVEX做合作伙伴就是一个错误。在当时来讲，MOVEX在中国没有任何一个支持机构，而且没有本地化的强有力研发的支持团队。这种情况下，用他们的产品要想很有效地接近中国企业的需求，肯定会有问题。”<br/><br/>按理说，联想不应该出现这么低级的错误吧。黄骁俭指出：联想真正转向做服务，也就是这两年的事情。当时联想处于高速发展阶段，它可能对管理软件的概念并不是很清晰，因为联想自身是做硬件系统集成的，人员可能也更多是做纯粹技术系统集成的。因此，他们没有想到做管理软件不是技术上的工程，而是一项复杂的管理工程，更多的应该是管理专家帮助企业去做这种实施的工作，而不是一些计算机人员。<br/><br/>**技术，项目失败的替罪羊**<br/><br/>黄骁俭进一步认为：“从MOVEX的角度看，我觉得‘汉化不彻底’只是表面问题。问题是，像三露厂这样非常有特点的中国企业要清楚：你上这个系统的目的是什么？这绝不是简单地把一些手工的工作搬到电脑里去。如果目的真这么简单，就不必买国外的软件。我估计三露厂主要还是想利用国外软件引起管理模式上的重大变革。因此，汉化不汉化，只是一个技术问题。更深层次的原因是这个软件代表的管理思想是三露厂没办法接受的，比如它的财务管理系统和中国的财务要求有很大的差距。也就是说，本质是软件供应方本身没有做到本地化。而项目出现危机后，它只是做技术弥补的话，就很难改变这个局面。<br/><br/>“软件本身从技术角度来讲，永远都是可解决的，包括MOVX这种产品从技术角度也是可以解决的。那为什么技术人员没解决问题？是因为这个技术解决方案和三露厂的管理要求是截然不同的东西。软件本身不可能失败，你想让我改到什么程度，我就能改到什么程度。但是这个软件本身所遵循的一种规律被破坏的话，它就回天无力了。我感到媒体讲了很多三露厂ERP失败的原因，都没有抓到实质。”<br/><br/>**SAP的项目实施，步步为营**<br/><br/>在这个失败案例中，200万元的损失与补偿，其实都无法平息各方的内心哀叹与失望，更无法消除人们对中国乃至全球技术项目管理水平的质疑。如此，我们自然会饶有兴趣地回过头来深入地研究一下SAP，这个信息化“老手”在技术项目管理上的绝招。<br/><br/>SAP专门有三四张光盘以介绍它的ASAP的快速实施法。<br/><br/>第一阶段：项目准备。SAP首先和用户在售前共同讨论、共同制定项目实施目标，这个目标要求能量化、比较明确。在项目前期会花很多时间，和客户共同做用户需求分析，分析客户现有的企业经营状况和现有的管理模式，分析如果要改进的话，将改进到什么样的程度，这是SAP必须要做的一件事。在这个阶段，往往会有第三方机构加入到这个项目的定位中来。<br/><br/>同时，要确定项目组织结构及成员，制定实施计划和标准，准备并安排各方面资源。SAP软件有很多模块，所以在目标达成共识后，在产品采购过程时，SAP会和客户共同制定整个的实施方案，他们也要考虑客户逐渐投入的过程，不会让你一下子花很多钱来买他的产品。<br/>第二阶段：业务流程蓝本设计。期间要进行项目小组初级及中级培训，项目目标明细化，确定基本系统的范围，确定项目的详细实施计划，业务需求的确认，企业组织结构及业务流程的确定。<br/><br/>第三阶段：业务蓝图实现。这个阶段的目的是逐步实现业务蓝图，进行完整的系统测试，获得用户对系统的确认。主要任务要对项目小组进行高级培训，开发数据转换程序，开发应用接口程序，开发外挂或扩展程序，进行报表定义、格式定义、权限定义及管理，归档定义及管理系统集成测试，制作用户手册及用户培训资料。<br/><br/>第四阶段：投入运行准备。此阶段的目的是要完成系统上线的准备，以保证系统正确运转，同时要解决剩余问题。主要任务是进行用户培训、系统管理、正式运行技术环境的安装及测试，制定明细运行计划，制定系统切换计划，制定系统运行、支持计划。<br/><br/>第五阶段：系统投入运行及支持。正确移交系统，保证系统正常运转。主要任务是提供用户支持，确认正式业务流程的正确性，优化系统的使用，后续培训，制定后续长期计划，系统升级，系统日常维护，项目回顾。<br/><br/>**NO！道不同不相为谋**<br/><br/>当然，除了严谨而科学的项目管理流程外，在一个系统项目上马之前，客户是否对这个项目的深层意义有全面深刻认识，是项目成功的关键前提。作为一个优秀的企业，面对不同的客户时，一定要懂得去拒绝那些并不是真正意义上的客户。从拒绝客户中学习预先的问题管理，将后期可能发生的纠纷、风险降到最低，这是一种大公司必须具备的能力和品质。<br/><br/>因此，我们也不难知道，其实SAP也有距绝客户的时候。SAP软件代表的是一种管理思想，如果你不能接受这个思想，就不可能达成共识。黄骁俭语气坚决地说：“SAP软件绝不会模拟一个现有的管理模式和业务流程。”很多项目在投标的过程中，如果他们发现这个客户制定的目标和SAP有较大差异的话，他们就会退出竞标。<br/><br/>黄骁俭说：“首先我们提倡一体化的管理，不会简单地为一两个部门去实现信息化。ERP的核心思想就是要进行信息集成、共享、要以流程为单位来运作。有些客户，甚至很多大企业都说，你只要给他解决一个仓库管理或者你只要给他解决销售管理，这不是我们要做的，我们卖的是企业产品，而不是部门产品。这说明企业在确定一个项目时，它并不明白它要达到一个什么样的目标，它对ERP的含义并没有深刻的了解。如果只把ERP当成一个软件产品来做的话，而不是一个管理改革的过程，注定要失败。<br/><br/>“我们一直认为：客户对ERP的投入不是一个短期投入，它是一个长期的投入。你要做信息化就等于是上了‘贼船’，你可能在此后每年都会有不小的投入。在国外有个定律，企业至少要拿出总销售收入的6%做信息化的长期投入，中国企业很少有这样的概念。不这样，就很难保证这个项目会长期发生效益。为什么后期我们要维护？因为管理本身不是一成不变的。有些公司总想投入很少产出很多，这种情况我们也会退出。”<br/><br/>三露厂的叹息，联想的忧郁，和MOVX的无奈，都正在成为过去。但事情远没有结束。<br/><br/>由于市场交换的复杂性日益增大、IT业的迅猛发展，使得企业管理和业务从来没有像现在这样依赖于技术，虽然信息化历程中潜伏着巨大风险，但我们没有理由因此而拒绝信息化的潮流，因此对信息化敬而远之。我们现在所能做的是：尽量多地研究失败，吸取教训，并能从失败中找出一些实质原因。 □<br/><br/>责任编辑：孔龙<br/><br/>**********文章二:项目经理，就像支部书记？**********<br/><br/>本刊记者 邓波<br/><br/>ERP的失败其实只是技术项目管理失败的冰山一角，因此，为了深入地探讨技术项目管理，我们就必须抛开单纯ERP的是与非。在电子工业出版社今年主办的“中外项目管理论坛”会上，《突破技术项目管理》一书作者、美国加州大学信息系统教授贝内特·P·利恩兹接受了本刊记者的采访。<br/><br/>贝内特告诉本刊记者：在他20多年的项目管理生涯中，他最担心的不是项目经理本身的素质和经验，而是这些项目经理所接受的教育，早就注入了他们不成功的元素。因为现在讲项目管理的老师其实大部分没有从事过项目管理。而贝内特认为自己的研究成果最大的突破是，他注重实际的方法。<br/><br/>**项目经理的必备能力**<br/><br/>贝内特认为，一个项目经理最重要的特质就是辨识和解决问题的能力。在系统项目中，这种能力要求经理具备一些技术知识、业务知识、与别人合作的能力，以及良好的评价问题的技能。一个人可以是天才，但项目经理必须要有意愿和毅力将项目坚持到最后。过去，项目经理只意味着与技术人员一起共事。而在今天，同样重要的是还有与其他项目经理、直线经理和高层管理者合作的能力。<br/><br/>将90%的时间用于沟通与合作<br/><br/>此时，贝内特举了一个例子：他在一家高科技制造企业遇到过一位项目经理J，在他曾见过的几乎数百位的项目经理中，J是最出色的人之一。J有什么过人之处呢？J看到了对整个公司的项目管理过程进行更新的必要性。J开发了项目概念并且向管理层反复推荐他的想法达18个月之久，才最终获得了通过。他表现了开创性和创造力，自己开发了许多具体的创意。他挺过了项目最初那段艰难的日子，那时项目遇到了很大的抵触，他能够成功地与每个人，从技术人员到高层管理进行合作。他有过敌人吗？周围的环境有政治气氛吗？对这两个问题的回答都是肯定的，他总共花了超过一半的时间去交流和解决这些问题。到项目结束时，由于需要克服阻力，他完成自己任务的时间，总共还不到他全部时间的10%。<br/><br/>在关于技术项目经理的素质与能力的认识上，SAP与贝内特达成了共识。做了八年项目经理、并自认为做得“还可以”的SAP大中华区执行副总裁黄骁俭，用非常“中国”的语言，回答了他对技术项目经理的认识：<br/><br/>项目经理最重要的是做人的工作<br/><br/>“项目经理在组织工作中，遇到的最大的障碍是人的障碍。项目经理的角色实际上就和支部书记差不多，大部分时间是做人的思想工作。他要不断地将管理思想解释给别人听，他必须要和客户达成共识。并且，他还要有能力把握度，把握节奏，因为很多客户都有急于求成的心理。项目经理，首先要是一个管理咨询专家，而不是一个软件专家。他要能把握企业管理的命脉和主要问题，一眼能看出企业怎样改进才是最好的。所有这一切简而言之，就是：项目经理要有很好的沟通能力，对管理思想有清晰的认识，有非常强的分析能力。”<br/><br/>在如何处理好与高层管理者的关系上，SAP认为每一个项目都应有一个最高的项目指导委员会，公司的一把手担任项目组组长，一开始要签订一个项目章程，就像法律一样，项目经理只是一个执行者。因此SAP建议企业的高层一定要成为项目经理强有力的后台，因为在项目实施过程中，企业还有主导业务，项目会涉及到各部门，但项目经理不能要求他们停下工作参与到项目中来。当然，项目经理也必须要争取高层支持他在一定度上有权动用企业资源。<br/><br/>好了，谈了这么久关于项目经理的能力问题，“支部书记”们可能更想知道，在一个项目实施过程中，他到底有什么责任？有没有获得成功的明确道路？<br/><br/>项目管理实践家贝内特在给本刊发来的邮件中，列出了关于项目经理职责清单及成功方法。<br/><br/>**项目经理的职责清单**<br/><br/>项目的起始阶段 这一阶段以项目经理的任命开始，以项目计划和项目团队的获准和工作正式开始为止。<br/><br/>前整合阶段 这个阶段包括可行性研究、分析、设计、软件挑选，以及软件开发直至整合和调试。它还包括体系架构和基础结构工作。再有，就是与业务部门相关的工作。<br/><br/>整合和实施 这个阶段包括系统的整合、调试、业务部门的程序、政策、培训、转换以及彻底采用新系统。<br/><br/>后项目阶段 这一阶段包括终止项目，收集经验教训，并向下一个项目转达。虽然收集经验教训是本阶段的任务，但要注意，必须要在项目的进行过程中一直收集经验教训，如果你到最后结尾时才想到，大家可能都已转去做其他工作了。<br/><br/>**项目经理的成功法则**<br/><br/>● 继续学习，并在技术上与项目一起成长。许多项目经理任由他们的技术知识和技能慢慢荒废。不要让这种事情发生在你身上。<br/><br/>● 与直线经理和高层管理进行经常性的非正式沟通。这包括不仅仅是要讨论问题和机遇，还可以交流一些有趣的项目故事和情况。<br/><br/>● 始终对项目中所发生的事情了如指掌。包括人们正在做些什么，正面临什么问题，项目目前的状况以及预见即将面临的挑战。<br/><br/>● 与团队成员进行个别合作。尽管团队沟通和合作非常重要，系统工作中大部分内容还是由成员们各自独立完成的。注意要把每个人都当作一个个体来联系和接触。别忘了，定期到成员们的办公室去聊一聊。<br/><br/>● 利用团队去辨别问题。大部分问题分析工作都得由你来完成。但如果你允许成员们就一些可能引发难题和机会的问题提一些建议，他们就能在项目中发挥更大的作用，并能增强他对项目的承诺。但另一方面，当你将问题委派给团队成员时，也要小心谨慎，他们的视点可能太窄，并且缺乏组织和政治方面的知识。<br/><br/>● 项目管理是带有政治性的——别忘记这一点。记住，项目通常意味着变化，而变化可能令人恐惧和带有破坏性，很可能会有抵触。 □<br/><br/>责任编辑：孔龙<br/><br/><br/>*******文章三:系统项目管理的常见误区*******<br/><br/>贝内特·P·利恩兹 凯瑟琳·P·雷 张金成 杨坤/译<br/><br/>误区一：要成功，项目就需要专用的资源。<br/><br/>20年以前这是正确的，但是现在情况则不同了。系统项目要求在整个项目生命周期中，不同的人要具有不同的技能。对多数企业而言，要求大量的全职人员把全部时间都专注于项目的整个过程，是不可能的。<br/><br/>误区二：项目经理必须拥有足够的自主权。<br/><br/>这种想法是基于这样的理念，即项目具有独立的特点，项目经理要对项目全权负责。现在，这是不现实的。项目都是相互关联的，资源是共享的。甚至项目经理也是在多个项目之间进行共享和分配的。<br/><br/>误区三：项目成功的标志就是系统上线。<br/><br/>这是对成功的传统和狭隘的定义。这就是为什么许多系统人员认为项目是成功的，而业务经理却认为项目是失败的原因。这是视角的问题。许多系统人员认为当软件可以运行时，工作就结束了。但是，业务经理却认为当业务过程由于系统运行而得到改进时，项目才算结束。尽管项目成本大部分花在了系统上，但是收益却更多地体现在业务的变革和改进上。<br/><br/>误区四：项目成功依赖于清晰、稳定的需求。<br/><br/>传统的系统生命周期强调要正确地了解需求。如果这一步做到了，那么设计和开发就非常容易成功了。因为它们是可以满足需求的。这在理论上是对的，但是在实践中却很糟糕。业务经理可能直到他们看到些什么才知道需要些什么。当他们见到并使用了系统和技术时，他们的需求才会自然出现并且发生变动。这是项目周期的一部分。而且在任何长期的项目中，你确实必须为技术的改进和变化做好计划。<br/><br/>误区五：用项目完成的百分比和预算与实际结果的对比来测评。<br/><br/>这是学生们在项目管理课上所学到的传统的并且得到认可的方法。遗憾的是，在系统项目中，即使这是可能的，也很难清楚地识别项目完成的百分比。最能说明问题的变量就是人工时间。因此，预算就是一个预告性的指示器。你可以通过评估未解决的问题和难题来更好地测评项目。<br/><br/>误区六：每个系统项目都是独特的。<br/><br/>这看起来是一个直率的表述。然而，如果你接受了，你就会倾向于孤立地管理项目，并且不能从教训中学到什么。项目具有独特的属性，但是在新技术的外表下，它们还是有很多共同之处。<br/><br/>误区七：投入项目上的人力，多多益善。<br/><br/>在某些业务项目上确实如此。但在系统项目管理中却很少是这样的。人们的技能和知识是不能互换的。如果多一些人加入到系统项目中来，由于协调不利和要培训人员以快速适应工作，通常会减慢项目的进度。 □ <br/> <p>虽然时间久了点，但是好帖子还是应该经常拿来温习一下，温故而知新吗</p> 我也非常喜欢中外管理，结合东西方的优势，中西合壁。为我所用 好帖子，每次看每次都有不同的感受，感谢楼主分享！ 温故知新。 保存了。
页:
[1]