SAP项目的风险管理（转）

当我们的客户在决定上SAP项目时，也通过SAP来做应用管理、测试管理、功能管理，包括上线以后在运营里面也提供非常多的解决方案，来支持SAP后续的运行。在全球超过了1400多位的用户在实施SAP的时候使用了刚刚说的解决方案。回到刚才我所介绍的测试中心里，大家可以回想一下上一个SAP项目，有什么样的思考。

　　首先，任何软件都有生命周期。在生命周期里，首先会提出设想，再建立应用的蓝图，把用户的需求转化成IT需求，通过招标、定标来直线业务需求，最后上线，到升级淘汰，这是整个应用的生命周期。在整个生命周期里，需求提出来之后如何进行管理？如何把IT的需求转换成测试的需求？第二，优化功能。如何保证开发出来的项目里面符合用户需求的功能。如果要上线希望看一下上线以后系统的性能，IT的基础架构能否满足当时提出的业务系数的功能。比如说数据集中以后有500个并发用户，我们要上系统在软件上能否支撑。同时，在上线以后，我们的硬件、网络能否支撑业务需求？这一块叫优化、性能的评测，之后是上线。上线以后提希望提出可用性的管理，从不同的分支机构把业务的模拟请求汇总到中央。

　　同时，中间通过业务展示的数把业务的健康状况展示出来，一旦业务出现故障的时候，IT管理人员、SAP的应用人员第一时间知道我们的应用出现什么样的制造，这是我们流程管理内容。在整个HP系统评测领域里面，每个产品占有了77%的份额，是在本领域的领导者的地位。在可清晰发展的视图里面也占有一定的位置。在之后很长时间内，慢慢大家会发现梅特丽的品牌淡去。

　　首先看一下SAP的用户环境，之前大家一直用阿桑比较多，这里定义了很多业务流程，可以很快搭建起来。我们的目标用户所做得工作主要是选择什么样的积木、怎么样来搭？在SAP的试验里面，进行了压力测试，测试的工作量相对比较小，很多的功能、模块是在上线前就已经通过了很好的测试。大家如果用过阿桑的人就知道相对比较小，是非常开放的平台，可以进行整合，比较灵活。做接口时环节比较多，可以比较灵活的实现业务需求，同时出现错误的可能性比较大。在异构的环境里，手工测试显示出很多的弊端。比如说搭建一个业务模型，明天业务部门又提出新的业务需求，之后又要针对这个进行改变。软件系统是比较复杂的工程，改变A功能模块的时候可能会改变B的流程。在平时测试里，通常在A的时候只对A的业务流程进行测试，上线之后发现B受到了影响，这个叫做切线管理。它的覆盖量不充分，如果要充分测试会占用大量的时间和人力。通过我们的功能测试，把相应的功能录制下来，当我做业务流程更改的时候通过回放的方式对整个系统进行全覆盖的测试，减少了系统的压力。

　　在新的环境下，补丁会更多的。从版本之间的转换，业务流程的转换灵活度的转换，导致我们的测试、功能的完备性压力从SAP本身转移到了客户本身，既要求客户在每一个版本上线做很多大量的测试保证产品集成以后是一个比较有质量的软件产品。

　　下面看一下项目风险里面面临的挑战。最上角是业务的生命周期，在生命周期每个阶段的介入人力不一样。在第一个阶段很多人忽视了测试计划，跟系统的运行、开发的测试计划，常常会忽略掉。第二阶段是QA，开发人员会介入，这个阶段希望借助一些管理工具把各个TM之间的管理信息集中起来，希望涵盖需求测试。第三阶段就是性能管理，有性能的整合工具对基础架构的本身进行完整测试实现整个系统上线以后达到很好的容量，灵活性、容量都可以完备。在做期限管理等的时候改变现有的思路，通过一系列的测试软件管理方法论，保证上线之后有好的运营。最后，评审委员会会根据在测试所输出的成果决定整个系统是否上线，现在上线功能都出来了，有问题再调整，这些都有一些根据来决定系统是否上线。

　　接下来介绍一下HP的(ST)，把业务需求作为功能需求。比如说业务需求作为订单的需求，我们分成很多部，通过我们的工作进行，有切线的时候可以进行切线关系。这里所用到的管理工具就是原来(Mark英文)里面所命名的。我们所说的需求管理、测试的计划以及测试的实验室都统一管理起来，测试需求可以看到是否做完了，现在还有哪些缺陷与故障，最终的管理层可能看涵盖多少东西，进度能否保证项目进度，可以通过这些地方来看。

　　在整个SAP的应用生命周期管理里面，还有其他内容，比如说质量管理、服务台、服务提供、变更管理、知识传递、项目管理以及知识管理，这些都是整个HP的软件解决方案里面的部分。在Cuality Ceite里面，在做每次测试的时候可以回访Cuality Ceite录制的，这样就实现了从测试管理到整个测试流程管理的衔接。

　　如果说功能已经完备，下面该做什么？要考虑上线。在上线过程中，要评估当时提出业务模型时希望有多少用户量来使用我们系统。这时在后台实验室通过人工的方式来模拟，通过模拟用户的方式把刚才Cuality Ceite里面的功能进行访问，可以显示出功能，在2、3百用户压我的系统时，网络响应时间多少、主机响应时间多少、CPU的响应时间多少，之后给一个报告告诉我们业务系统支持多少客户，这样就会有比较客观的依据，要上这个系统需要多少硬件的平台。如果在性能管理以后，决定上线，上线之后会通过最终用户模拟访问的方式，把各个业务流程里面所涵盖的交易通过模拟的方式进行访问，访问之后把访问结果送到后端的SAP的业务数下面，在那里可以现实不同的业务流程。我们可以知道从10个、100个分部点看系统运行。业务数一旦发现红颜色、绿颜色的时候就要诊断，不是到系统不能用了才做补救，不能很好的管理。可用性里面，是用BAC的管理产品，通过模拟、后台资源监控可以给出系统的可用性。这些是遵循管理流程对整个项目的实施和风险进行有效的管理。

　　针对SAP又定制了很多产品，第一块是(英文)，可以对界面进行模拟访问。在这里可以自动的知道产品的模拟交易，可以快速把故障、性能问题在很多的交易里面隔离出来，最后一针见血的指出瓶颈。可用管理里面监控主机，同时使CCMS有效的定位出来交易，SAP业务流程的每个步骤，这是BAC所提出的方案。

　　在上线前，希望评估整个系统的风险，版本升级了，希望对业务流程进行测试，每个应用在做变更时也要对它进行相应的测试。大家在碰到性能问题时，希望通过诊断工具、业务流程、业务影响分析工具对它进行扫描和诊断。下面花几分钟时间看一下应用的案例，在这里案例里面是新加坡的制药企业，下属有4个工厂，有800个员工，这里有生产制造等业务系统，我们的管理超出了SAP的项目，对其他系统也进行了相应的测试。SAP里面标志出一些相应的模块，这些模块帮助它整个生产运作进行现代管理。

　　在测试目标里，对17个业务流程进行测试，测试各个业务流程响应的时间，在目标里希望能够很客观的评价出100个并发用户在高峰时间有50个并发用户，同时可以评价出性能，针对整个报告对IT架构进行优化。这是四大测试目标。在测试过程中，要做一个压力方面的测试，首先要把功能点拿出来，在功能点中首先要根据测试需求抽取两大类的交易，第一大类是业务流程比较重要的交易，第二类是访问比较频繁的交易。

　　同时要分析整个业务的环境或者说场景。也就是说，SAP上线以后，整个用户访问的可用性出现什么阶段？比如说早上登录比较频繁，中午什么交易比较频繁，下午什么交易比较频繁，我们运用上线以后的实际场景模拟出来。等实际场景定好以后，就会在不同时间段通过模拟并发用户对它不同的交易进行输入，看资源的监控。我们发现他们没有很好的进行分配，分配策略是基于访问的次数来分配的，压力的负载也不一样。或许在之后设均衡的时候一方面要考虑次数的分配，同时要考虑后端资源负载的因素。第二次进行398并发用户的访问，发现特定功能的用户已经不能使用、不能登录了。同时，内存存在一定程度的泄漏，在这方面也会提供相应的报告。我们发现500个用户使用时压力正常，最后的报告是可以同时处理430个英文，不同阶段可以做一个详细的中文报告，在这种压力下要配置什么样的IT架构做客观的依据。在全国很多大型的企业里面都采用了我们的解决方案作为软件的性能管理。这是在整个IT间里面所用到的SAP解决方案的大型客户的列表。在国内我参与了两个SAP的项目，其中一个是采用500用户的压力测试进行上线测试和上线的管理。

　　我的介绍大概就这些，如果说在座的是SAP的项目，面临一些性能问题，或者说有很多头疼的地方，不知道如何入手，不知道如何保户我们的投资，可以找今天的合作伙伴SAP，也可以找HP，也可以找到我，我会做相应的帮助。非常感谢各位嘉宾的时间，我的介绍到此结束，谢谢！