惠普销售经理初明阐述ERP项目风险管理

“协同共赢，做强制造”——源讯MMT全球制造企业峰会高科技论坛

中国惠普软件销售经理初明阐述ERP项目风险管理

主持人：好，相信大家对这个SAPBest Practices的实践有了比较好的了解，下面我们请中国惠普软件销售经理初明先生做这个惠普信息架构这方面的讲解。请大家欢迎。谢谢。

初明：刚才我得更正一下，刚才给我介绍，我们惠普有关架构的事，这个事情的确我们希望跟大家分享的内容，的确是信息架构方面的问题，但是我们这次的主题不是给大家讲SAP项目本身这个信息架构的设计等等这方面的，因为这个我们源讯他们也会有部分人给大家提供这方面的建议和方案，我这里主要给大家介绍一下在这个过程当中，主要是SAP项目这个事实过程中它们风险管理问题。当然是涉及系统风险管理系统的问题。IT系统如何保证风险的最小化，也是给大家提出重要的课题，比如我上线以后，比如我的性能达不到指标，或者说当功能不一定在时间内满足达到原来设计的要求，那么对整个生产制作这个过程会产生非常大影响，所以我在这里给大家介绍内容，主要是这个角度，就是如何把实施过程中这种风险降低到最低，主要是这个思路上给大家介绍。

　　我刚才给大家介绍了一下这个主题，我这里不再多说了。这个思路解决帮助大家如何能够最小化的把这个实施过程的风险降低到最低，我们通过什么手段来实现呢？这个主要的思路就是什么呢？你要测试所有的东西，在上线之前，通过这种测试来达到风险的最小化。我们惠普软件和SAP本身的合作，大家可以了解一下。这个图给大家一个非常全面的了解。大家也可以了解SAP从研发一直到整个的全球范围内的支持活动中，都使用了惠普的软件。

　　我们今天在这里讨论的主要是中间这块，中间这块主要是我们在具体的项目实施过程里面，在SAP这个项目如何运用这种技术，来达到事先能够对我们这个项目，对IT系统可以产生的冲击，以及可以产生的影响，以及我们能不能达到设计时候的思路的一个最重要的一个判断。有了这个判断，我们就可以评估这个项目的风险，从而最大程度的减少这个项目的实施风险。我这里主要从这个角度讲，而我们惠普和SAP在整个全球范围内，这个方面的合作，大家也可以看到从研发它就开始使用了我们整个的技术，从而保证它本身研制的产品，无论是在功能还是性能达到了各方面的要求。我们看到SAP为什么还要在我们的具体实施过程中，还要做一边这个事情呢？我就跟大家讲一下，主要给大家介绍这个思路是什么？那么它怎么样设计到的风险以及如何把这个风险降低到最低限度？

　　这个就是给大家看一下我们在SAP的项目整个实施过程中的测试过程，在里面合作的主要领域是什么？大家可以看一看，就说SAP项目的实施，基本上它是按照从整个生命周期来讲是这么个思路。我首先有项目计划，然后是这个蓝图，把这个业务的流程哪些用什么具体的运用，怎么客户化，把整个的所谓的营运能够客户化到我这个整个业务环境中，业务分析怎么对应到IT整个运用的功能上，怎么实现它，最后我们做整个的准备工作，最后上线。

　　上线以后，我们就要维护整个系统。我们一般有SAP整个的项目办公室完全这个东西，大家可以看到前半部分都是一个准备的阶段，让它能够在此前符合我们的要求，通过跟业务部门的交流沟通，对业务本身的功能等等做出相应的调整，一直到测试等等，到这点它就上线，上线以后，我就保证它的可用性，保证它的运行维护的成本这个方面，这个是从整个IT本身的规划角度来看，我怎么实现这个功能。我们惠普软件究竟在里面起到什么作用呢？主要从这几点，一个是你本身需求管理这部分，我们业务部门要更改这个本身需求，要客户化这个东西，涉及到大量的需求变更，包括后来使用的SAP这个过程，整个就是把我们需求怎么定义清楚？然后功能怎么进行优化，我要测试这个需求是不是我要达到业务方面本身的功能？在营运上怎么体现出来？我当时功能实现了，但是我可能用的时候好几百人在用，我怎么性能上满足它，最后上线以后，我要在技术上保证它完全百分之百的可靠，所以这个是整个它的思路。

　　这个领域大家可以了解，我相信大家过去如果在IT部门工作，如果软件开发这个部门，可能听说这个MERCURY这个公司，那么惠普公司是在去年的时候，花了45亿美元把这个公司收购了，所以现在惠普软件里它成了非常重要的部分。那个合作的主要内容就在这个部分，在SAT本身性能测试这个部分，很大程度是在这个领域里面，大家可以看到在全球范围内的市场占有率是77%，这个对软件成本来讲绝对属于主导型的。大家可以看到在这个上线分析里面，原来的产品大概处于什么样的阶段？这个非常有名的一个从它过去的历史和目前这个市场占有率该度来讲，是使用情况、使用率等等非常高的一个产品！如果大家过去做过软件开发的人一提肯定就知道，IT部门的人，如果做运行维护的人相对来讲对这部分相对了解少一点，但是开发测试这个领域里边，大家可以了解这是一个所谓非常非常主导型的产品。

　　下面我给大家介绍一下，这个东西究竟在测试里面怎么帮助大家实现这个东西？我就从SAP客户环境给大家看一看：

　　第一你看特别是我们看到新的SAP它推出的整个的产品，它是给予环境下，超越了原来的。过去大家知道SAP都是R3这个部分，新的情况下很大程度上转移到了Netweaver，为什么转移到？因为这个条件就是说我们这个市场的变化以至于我们这个需要客户化，和运用改变的次数越来越多，需要改变和客户化越来越多的情况下，原有的R3这种架构提供不了这种灵活性，而它就可以提供这种灵活性，同时带来更多的压力，我对它的管理要求就更高了，大家可以从这里看到原来的R3系统和NetWeaver系统在这个保证上有什么样的不同点？R3是定的，永远超过后定义的，你可以重新定义很多。

　　这个特别涉及到和其它平台的同时连接性，这个比R3要好的多，这个好的多导致的结果就是它的客户化的内容很多，所以R3事先可以做很多的测试，到实际的运用就不要太多的测试。而这个相反，NetWeaver在各环节下非常的不同，在你的生产环境下做出很大的相应的改变，在你的测试上的要求就提出更高的要求。所以你也看到相对来讲，这个测试角度来看，都是在SAP实验室里进行的。现在新的环境下，有关客户化和灵活性的要求，导致了特定的要求，很大程度下在你的环境下，每个人都是不同的。补丁会很多，可能每隔时段都有这方面的要求，每做一部分这种升级或者这个补丁方面的要求，在此之前都要做一个测试活动，这个保证可靠性。你就有一种赌博心理，没事，我稍微改一下，如果不成就算了。对于这种侥幸心理是非常危险的。

　　我们这里看到从过去我们的R3到新的环境下，到更多的我需要定制的业务流程越来越多，其实从测试方面的要求过去我们是说那我们SAP给我们测试好了，当然它是灵的了，到我这不灵我就找SAP算帐。但是新的环境不是这个概念了，随着你对应用本身的客户化，和它本身个性化的要求，特别是从第三方产品环节的要求，这测试的责任就要从SAP转移到你身上了，你在实施过程中，源讯给大家做这个服务本身，在你们的上面做测试这个要求就越来越高了，我们没有做这个测试，或者我们通过一个不规范的测试以后，投入生产产生的危害大家可想而知，而且你在此之前测试的不全面导致的问题，随后你要修改所付的代价远远大于原来的修改的代价。这里面最重要的概念，这件事好不好使在SAP的责任，但是新的体制下这个责任不在于SAP，其实是在大家的身上。

　　这里面介绍一下，究竟它这个风险产生在哪些地方？

　　我们刚才介绍过，它在上线之前，一般来说都会经过不同的阶段，第一个阶段大家可以看到，我们项目整个管理，和它往往在业务方面的蓝图，它要和业务方面的应用本身结合起来，这里面业务分析师工作很多。我这里面应该用业务，比方说我零件本身的管理，我需要什么样的功能？或者我本身库存的功能需要什么样的功能？我这些功能有哪些仓库，他应该打发票，这个方面业务本身分析这个过程的人，在这个阶段做了主导型的工作。他有一个现实问题，他不负责测试，就说你这个功能在SAP里我说了应该这么做？究竟最后测试能不能成他是不负责任的。测试本身的工作是由你随后实践过程中你应当测。随后底下有人说你做了客户化以后，我就得给你测试了。

　　我测试这个究竟灵不灵？有一个最重要的问题？我经常和业务部门的人这个链接，我必须得有一个地方让他们都知道我这个想法，从业务功能方面要求你到了什么程度，你给我测试出来这些方面的要求，这些连接点在哪？往往这些地方在我们过去经验来看都是非常缺失的。他就会被零散性地叫来，相对来讲测试得不是非常全面，导致的结果往往是这个范围内，你会发现它导致的结果，怎么最后测试的时候，那个功能怎么有缺陷呢？就是当时测试方面的问题，不能百分之百模拟业务用户怎么使用它这种行为。

　　这个结束以后，我就做性能测试。功能满足了以后，在很多人都用的情况下，这个系统能不能正常运用呢？因为测试的人，我们使用者都分布在很多地方，甚至在全国很多地方，甚至在全世界很多地方。他在使用的过程中，你想模拟一个最终用户去从不同的地方去模拟一个真正的仿真的，你可能很难模拟。这样的结果我实际很难从一个实际发生的角度去模拟，比如我一百个用户同时登录的时候会什么情况？这个在很多的测试场合下是并不能够做到的。导致了往往一开始这个性能方面的测试不圆满，导致最后一上线，数据压力一上来，导致的结果就特别慢，导致了业务用户的抱怨。从此回头来找这些方面的问题。

　　最后你会发现其实这只是我刚才讲的一套事。可能我新上一个模块，或者我改一点东西，我所有的东西都要重新走一遍。如果你现得有技术，你就会往往看到，一个真正项目的负责人，他到最后上线之前，他就非常担心。这个东西他们都测过了，好像有的人好好测了，有些就认真摸底过，有些没有认真模拟过。这究竟灵不灵？那我也不知道，到时候再看，这种回答在关键上线的时候这是非常危险的回答。无论最后我咬牙说可以上线了，但我那是咬牙说的。我也不知道。所以说在整个这个环境下，究竟怎么处理这个问题？对于这个项目整个的管理，究竟最后行不行？我们源迅说这个可以上线了，究竟行不行？我心里没有一个特别十足的把握。

　　我们惠普这个东西究竟和SAP结合在一起怎么解决这个问题。

　　首先一个它第一个解决的问题方式，我要把你要求做的业务应用的方面的改变，或者我要做的客户化，或者应用功能方面的所有的改变和变化，我都要记录下来，记录下来同时和底下做测试的人分享这个东西。所以我永远追踪到哪个测了，哪个没测，哪个遗址没测，我永远可以把它一直都记录下来，通过整个测试流程管理的角度。而且这个记录本身大家可以看到，在SAP本身的就是集成在一起的。它本身的在整个它这个项目的生命周期里面，或者它运行过程中生命周期里面，本身的测试方面，所以性能方面本身就是一个集成化，一起集成化的一个方式。这里大家也可以看到，所以我在SAP做需求变更的要求可以集成到惠普这个测试工具中，这个工具中通过它的对测试本身管理流程里面，就能够顺利完成，包括记录跟踪等等，顺利的完成。

　　第二个就是给大家看一看，就是性能，大家都比较容易理解。主要是降低风险，当时如果我们有很多人在用，这是一个最基本的测试，你比方说我功能上都满足了，但是我可能一开始有50个用户在用，我要模拟，并且使它的保证在一定的服务水准范围内，比方说我有50个用户在用，我得想象时间多少？大家可以看到在这个图标里，就是性能测试上，包含了很多这方面的思路，压力到什么程度这个系统就掉了，我在什么样的范围，我究竟用户数达到多少？第二我在一个平均的范围之内，我究竟能够达到的时间是多少？我相信我们企业范围内很多业务过程都是相对集中的，比如说在每个月底某个季度的月底这些东西，这些范围之内，它是怎么能够完成相应的一个高峰时期的调解这方面的问题。等等这些东西都是我们性能测试中所要解决的问题，性能测试就给大家一个我在这种压力下，我要能看到我的一个是硬件系统本身的情况，我数据系统本身的情况，其他应用希望的情况，从而看到每一项在不同压力水平下，究竟是什么样的问题？从这这个角度来讲我降低了风险。一旦上线以后我再有这样的问题我总不能把关了再重新开始。通过事前的测定，包括对它最高压力范围的一个了解来达到这个。

　　第三个大家可以了解在上线以后，我事先我都测定了一定的指标，上线以后我还有一个观测的过程，我要不断的模拟，最终用户的使用者他所遇到的情况是怎么样？这里面有一个监控概念，可以对底层系统的监控，模拟用户不断使用它这个监控。我在某一个桌面上不断模拟用户在使用的情况，一旦出现使用方面的问题，我马上报警，在最终用户使用之前我已经发现了这方面的问题，并且解决这方面的问题。这个对IT系统，整个运行维护，我相信一直是非常大的。这个就涉及到它使用过程中本身所带来的所谓的监控，这个维护方面的要求。特别是它要模拟一个最终用户不断的使用这个系统，是什么样的情况？从而在真的用户使用之前，出现问题以前，来保证这个问题。

　　所以我们这样就可以看到从惠普整个在周期里面，它的角色是什么呢？大家可以看到在上线之前这个部分，功能准备之前主要是我们从功能质量本身的角度，如何保证它的讯息。在上线之前还有性能方面如何使它达到一个合理的优化的范围，在上线解决它永远可得性的问题。所以我们和SAP整个的协作在这个领域。

　　最后的结果我相信主要从整个这一套方案下来，主要是风险降低的问题。大家可以了解很多都是高科技的产业的人，有一个很重要的一点你们的产品一定在走向市场以前都是测试过的，到客户那都是好用的。所以我相信所谓要模拟测试以后再上线，这种思想是孕育于大家在自己的高科技产品本身的这个范围之内的，那么它的思路应该同样运用你们使用外界给你们提供的高科技产品身上。

　　这是惠普软件针对这个部分，它专门对SAP这个项目定制了一些软件，客户化软件。从一个功能、性能整个可用性，这三个部分每个专门对SAP的运用做了客户化。特别是和SAP的固有的监控、需求管理等等这些体系的相结合。所以这样的结果保证这个特定的客户范围，非常有效方便使用这个产品。你什么只有必须测试，我在这里必须强调一遍，一个上线之前你应该测试过的，特别是在你的模拟生产环境下测试过。第二是升级，升级之前我想和上线没有什么区别，你要测试。还有一个应用的做改动，因为这个是在新的环境下，市场环境下这是非常正常的现象。我相信SAP使用维护者都在一段时间内都会了解，你们会受到性能方面的困扰，简单的来讲我再买几台大机器就解决这个问题，有很多人用大机器并不能解决这个问题。所以这些方面来讲对测试需求角度来讲你什么时候应该给自己提这个问题，在这些之前你应该给自己提这个问题。

　　　举一个例子，这是一个制药企业的例子。简单的测试都干些什么？这是个最简单的思想。因为这个客户他要的是什么？他说功能方面我这个客户化我本身是另外一种角度去的，就是性能方面的测试。这个是新加坡大型的制药企业，制药有四个工厂，从公司规模角度来讲也不是很大，制药企业绝大多数都是用自动化实现的，员工不是很多，从我们企业规模来相比这并不是大的企业，可以看到多元化的IT系统，包括财务等等这些东西，都是用不同的软件。那么SAP在这里面也有。这是从业务功能，这面你看到从我们模块上角度来讲，SAP从这里都有哪些模块上了SAP，哪些模块是用别人的。所以连接在一起的。这个是他使用的。你们肯定在自己的SAP项目下看到这种的。就是这种业务方面的视图的要求，对于这些方面它很简单，他说我要求做一个，测试的目标是什么呢？我就是要求测试这17个业务流程同时运行的情况下，响应的时间是什么？我可能测定我平常的用户是100，同时在用的，但是在月末高峰的时候客户达到250，还有我究竟需不需要扩大硬件，还有我这个数据库编写的问题，我是从这些角度来看，我能不能达到测试方面的要求。

　　测试过程它模拟最终实际用户的登录以后，使用等等这些情况以后，它每次都是分为很多不同的阶段，每个阶段有不同测试目标，这个阶段测完以后，我就在里面作相应的改动，优化以后再测。第一次测定他就蔚县了221个最大优化数，到那个阶段有很多的SAP项目做负载均衡解决性能问题。负载均衡当然有很多方面的不同的，它这个测定发现负载均衡并没有平均的分配它的负载，现在新的技术有很多原理，比方说我可以根据你现在不同的工作量来分配，而不是绝对保证这两个一样的负载。它也有不同的指标往不同的地方来分配这样的原则。在第一次测试里就发现这种现象，随后他就去作响应的优化，做第二遍测试，发现能够优化以后最大的访问数可以达到398个。

　　但到这个阶段以后，这个特定的功能用户已经不能登录了，有些功能就已经登录不进去了。不是说慢的问题，而是系统内存在用户退出以后，它就不再释放了，所以导致了整个性能方面越来越有问题。随后就这两项现象，就要作相应的调整做一个改进。第三次他就做按500个用户数给它模拟，给它施加压力，如果我们在安全的范围内，250个用户我们模拟了其实系统的资源是处于非常安全合理的范围内，不用担心了。经过这个优化以后，所以不用再改了，第二到430个用户的时候，这个已经达到满负载了，不能再增加了。

　　所以大家可以看到它的主要的意义在哪？通过整个过程，把整个的系统完全进行了优化，这个优化的过程导致结果，其实使我这个用户数处理增加了，原来我设计那么多，同时对所造成的风险作出了评估，这是其中的一个部分，我们只是负载方面的压力方面的测试。

　　其实SAP和惠普软件在全球范围内在这个领域有很多共同的客户，到目前为止已经有1400这样的用户，在SAP使用了这个测试功能。在我们这个上头。大家可以看看这个当然不乏和大家同行业的公司了。所以我们该给大家一个介绍本身的所谓从它上线的风险的控制问题，我就给大家介绍这么多。其实你会发现这里边很有意思，如果我们和SAP有全面的合作关系，SAP销售人员如果销售了我在它的项目运用了测试功能，并且销售了客户，这是算他完成的任务。为什么SAP干这个事呢？你会了解其实SAP对我们这个东西，所谓对客户价值的认可，其实任何人在我相信从风险管理的角度来讲，他都希望测试来做。

　　古时候皇帝吃饭之前还得拿筷子尝一下，我们也应该从这个角度来看，测试和模拟运行在这里是多么重要。导致的结果从我们风险角度来讲，已经完全认可这个东西，所以有了相应的这样一些共同的合作。我们也希望大家在自己的委任项目里，如果有什么样的这方面的要求和问题，就联系我没有问题，我会给大家相应的找。这就有我的邮箱。有什么事情希望跟大家更多的进行这个领域方面的交流。今天就到这里，谢谢大家。

主持人：谢谢初明先生精彩的讲解，相信惠普在项目风险管理这块也有一个比较深入的认识。