[ZZ] 关于SAP Solution Manager
最近一直基于ARIS7.1结合SLM和NW,对涉及企业的业务流程进行建模,于是也对SLM的知识给予总结与收藏,发现有个网友写得不错,转摘过来,感谢原作者:
Solution Manager主要分两部分应用（这里不包括在Hosting， 或者说Basis方面，比如安装时License的生成等）: In Implementation 和 In Operation. 从目前应用来讲，可能In Operation部分的应用有更多需求，但换个角度，长远一点，还是先In Implementation后In Operation。 何谓In Implementation，又什么是In Operation。 前者主要是指SAP Solution Manager在SAP项目实施方面的应用，包括项目的有效管理，项目实施的文档管理，变更管理，测试，培训等等。而In Operation则更多是对SAP 系统运行过程的诸多参数，性能，运行中业务数据错误，系统问题的监控与解决。另外，Service Desk能有效地集成到SAP Solution Manager 中，并能够与Consulting Partner（SAP Service Partner）或者直接与SAP Service Market Platz相连接。
除去Project Management(In Implementaion)的部分，SAP Solution Manager 更可以看成是一个Application Management工具。
In Implementation
首先看In Implementation.
一直以来，SAP项目实施，基本上没个咨询公司都有各自一套管理方法。数年之前SAP就提出了ASAP（AccelerateSAP）的方法论； 有效地将SAP的项目实施从框架上给出了一个纲领性的指导方案。但也只是一个框架性的，具体的实施过程到底有多少按照这个系统化的方法来做就不得而知了。个人而言，对于过去的实施过程不是百分百满意，因为问题不断。即使在这样一个以严谨著称的纯德国公司，情况也不是100%。虽然我并没有，也不能统计出公司的SAP项目成功率。但就公司的文档和资料看来，应该有个更好的解决方案或者工具。 当然，我们不能说每个项目按照模板来。不然，又有人会说特色了。确实每个企业，每个项目都有自己的特色，但是我想有些项目实施根本性的东西就无所谓特色的东西了。比如项目文档管理，变更管理，项目状态控制等等
曾经有一个客户，他们在2001年德国总部实施了SAP项目，公司内部也有完整的SAP支持团队。集团公司现在希望能够做Global Roll out. 首先需要做的是一个Global Template。但是在做Global Templeate时，却找不到太多有实际用途的文档，缺少足够详细的模块设计文档。虽然几乎每个流程都有被定制过的enhancement或者Customer Exit， 却几乎没有enhancement的文档。所有的都只有ABAP注解。Template的唯一解决方案，就只有依靠Consultant的经验数据整理，而且不得不将所有Customer enhancement和自定义参数排除在外。在Rollout过程中，也遇到很多的问题。 比如发现Item Category的status profile丢失，或者必须routine的不全等等。这些问题只能发现一个解决一个，而且需要不同的两边的团队沟通。恶梦。
SAP Solution Manager存在的理由，就正如项目管理存在的理由。简单一点，SAP Solution Manager就是SAP的项目管理工具和手段。它应该是SAP项目实施过程的最好的助手之一，个人认为比现有其他SAP项目管理手段都更来得有效。
就Implementation而言，SAP Solution Manager 按照ASAP的方法论推进项目。将项目每个阶段的任务，所发生的动作加以规范化，并记录。From Project Roadmap to Project definition, Business Blueprint, Configuration, Testing, Training, Go Live, 给出了一条通往项目成功的保障之路。你可以采用SAP已经发布的各种现有流程，吸取数十年来SAP在各行业优秀流程积累，极大程度减少项目人力，金钱的投入。
项目管理的理论与实际应用之间总存在不大不小的差距，你可以使用MS Project作项目计划，做进度控制和资源分配，你还需要MS Visio和Word来做项目文档和流程图，需要Powerpoint制作PPT演示文稿，需要SAP系统作演示和教学。你也需要一个Content Server来保存这些文档，IT 部门或者顾问团队会帮你建立起Directory hierarchy来管理文档。但你更需要一个说明文档，来说明该如何使用项目文档，来提供各种内容的模版。你还需要Change Management，来保证项目内容的更新......
规范一点的顾问公司，会有几年，十几年的经验，已经形成自己的一套体系；而更多的时候，大部分的内容还是保存在Consultant的PC中，或者头脑中。而SAP Solution Manager的目的就是将所有这些分散的内容的集中起来，以一种系统的，结构化的方式安排，并直接与SAP系统集成，项目的变更首先在Solution Manager中加以记录，然后再反映到系统中。你可以在Business Scenario中定制你的业务流程，然后再从这个流程去修改系统。然后由Solution Manager建立测试计划进行测试。
如果借用SAP的名字，我觉这个是不是也可以叫做All in One，当然不是那个A1了。
SAP从上世纪90年代就推出ASAP的方法论，无非也一直是在寻找一条有效保证项目成功的途径。对一家ERP厂商而言，每一个客户都是一个全新的项目。这与卖汽车不一样，一条大街上也许有百两同一型号的汽车。但全世界绝对找不到两个一样的ERP系统。但ASAP推出以来，虽然在4.X（4.7以前版本）的版本中也相应的Transaction有类似的功能，并提供Q&A DB。但个人估计很少有公司去应用，因为太繁杂，也没有太多实践意义。确切的讲， SAP一直缺少有效的工具来支持它。其所能提供的只是一套方法论。而Solution Manager的推广，则是对ASAP的继承与实现。一方面它提供了一个有效的工具，另一方面SAP也可通过它继续更有效的吸收行业流程，这应该是SAP大力推广Solution Manager的一个理由。SAP之所以能站在行业的顶端，其核心正在于其拥有世界上最完美的流程库。如果从这个方面将SAP和Oracle对比，后者更应该看成是一个软件，而前者则是一种系统。
Solution Manager开始试着将流程管理与企业的实际系统相结合。
记得还在学校的时候，一直做ARIS的应用与研究，东西学了不少，项目也作过。包括所谓的Business Process Modeling， analyzing etc. 甚至曾经得出一个我自己至今也无法相信的一个结果，竟然在软件中算出了某大发动机厂流程的工时，成本，消耗等。虽然那是一个并不精确，甚至有点搞笑的结果，但从意义上来讲，如果能加上一个经验修正参数，我想应该还是能够反映实际，并用来知道流程改造的。 可惜之后没能继续相关的工作，当年的那点雄心不在，有关ARIS应用的那本书，从开始的完全创作，到后来的半翻译半创作，直至今也只完成了四分之一。 现在想起仍是无限遗憾，不过兴许那天高兴，一口气完成也可能。
原来使用ARIS时，就一直带着这样一个疑问，作为一个流程建模软件而言，如果单单用来建模，或者单单用来说流程文档的管理，也未免太过于浪费。企业的任何应用都应该能够为企业带来实际的，或者是潜在的短期或长远利益。SAP Solution Manager 已经开始尝试着在流程建模与实际SAP系统之间进行集成。在Business Scenario阶段，你可以直接在Process Flow Graphic中建模，而直接在你的Scenario中得到反映，并生成相应的系统配置功能。是不是很方便，你不必先去用Visio画图，再去SAP IMG中一点一点地挑出所有需要的配置。你所要做的只是画图，系统自动生成大部分的配置菜单，在一个地方就可以完成。
之所以对这个功能这么兴奋，是因为发现，ARIS工具作为SAP这一功能的增强产品，可以直接集成使用。这意味着以前手头拥有的大量ARIS流程，终于有发挥威力的时候了。2004曾经作过某发动机厂的刀具外包流程，其将原来自己完成的从采购到检验，维修，仓库流程全部外包，这难道不是一个很好的应用案例。
不足
SAP Solution Manager对Implementaion的帮助应该是显著的。但个人认为应该加上一个前提，这种帮助的效果应该是与项目复杂度成正比的。也就是公司越大，系统越多，其所能带来的好处才会越明显。对于一个只有一个系统的公司来讲，这种提升也可能是在五年或者十年以后才会感觉到。对于大部分跨国企业而言，或者比如众多的德国企业而言，他们通常都会有三个四个，甚至几十个SAP系统。Solution Manager所能提供的在系统管理，系统集成测试等等，好处是显而易见的。比如你需要搭建SAP CRM 5.0，通过SAP Solution Manager，将SAP R/3 Sysem, BW System集中到一个Project中，你无需分个去登陆每个系统，然后再一个一个配置。在Solution Manager中你可以直接按照设计好的流程（比如标准订单销售），去配置CRM和BW系统，你可以比较和同步各个系统中设置，不如Order Type是否一致，新版CRM与旧版R/3设置的Language Abbrievation or Currency是否相同等等。
But for a small size company, it only has one ERP system. If it can find a good consultant team, everything can be done perfectly.And that's all. 项目越小，个体的因素就越大。可惜SAP从来不是小项目，所以最好还是使用Solution Manager。也许有一天SAP也会有正对B1的解决方案。但个人不觉得那是个好的选择。对于小公司，选择Salesforce，或者金蝶也许更好。
In Operation
接上部。在前部门讲述了SAP Solution Manager在SAP项目实施阶段的应用之后，接下来的部门会继续就其在SAP项目生命周期的另一重要部分——日常运营，SAP Operation中应用稍加描述。 如果简单一点描述，Solution Manager的第一部分是系统Productive之前的内容，第二部分则是正对Production System的内容。
从一个ＩＴ的项目的成本角度考虑来讲，如果选择保守估计，其60%的费用是化在日常运营阶段，30%的费用可以算在前期，通常能有10%的经费预算化在系统的Innovation上就应该算是一个不错的状况了。当然10%的经费对于Innovation来讲肯定是不够的，但是在预算有限的情况之下，能找到的解决方案就只有Reduce Maintenance Costs。
不妨假设这样一个例子。一个1 million $的SAP项目，系统没有外包给Hosting服务商，一切自行维护，同时保留有自己的支持团队。在系统上线后，按照每个月50 thousand dollar的水准支持运营(including human resource, infrastructure costs etc)，系统生命周期为5年，也即在五年之内无须进行大规模的更新或者升级。可以算出生命周期内运营支持费用大约为3 million dollar。 初期投入与运营费用之比为300%。所以，60%的运营开支已经是一个较低水平。
作为几个集中化的管理平台，你无须单独或者通过各种各样昂贵的第三方工具去进行系统管理。因为这不仅需要专业的人员，同时也带来了更多的繁杂工作。SAP Solution Manager在Operation阶段的应用，一方面可以有效地提高SAP的可控性， 降低系统的维护难度，当然相应的也会同时降低系统的维护成本。比如你可以很方便的提交Service Level Report，可以提供集成Service Desk，进行Change Management等等。 并为将来的流程改变，系统升级等等提供有效的支持。你还可以与其他Application Management的专业工具集成，提供更为有效的管理。
当然，肯定有更优的解决方案，比如外包系统给专业的Hosting提供商。但这暂时不在讨论之列。一方面是因为许多客户对于这一观念接受还不够；另一方面对于超大型的客户，他们往往也不愿意。也许有机会，可以对SAP Hosting的优劣可以进行以下比较。
对于运营阶段的支持。SAP Solution Manager的无非从如下几个方面入手，应该说这也是日常运营工作的大部分内容。
首先是Monitoring，这主要包括EarlyWatch Alert，System Monitoring and Adminstration, 甚至提供了对Business Process Monitoring的支持。我想对于这里大部分的内容应该不难理解。
EarlyWatch Alert 和System Monitoring作为一种预警与诊断服务，作为Solution Monitoring的一部分，能够提供对SAP and non-SAP系统, 软件甚至部分硬件性能的诊断，including System availability, Database, Error status, CPU Utilization, Filesystem, Paging, Network etc。你还可以按照需要自定义所需内容。
Administration提供了一个Central Administration Platform，you can access all systems that you want to admin. 并完成大部分的系统维护工作，对于有多个系统的客户而言，这将有效的降低工作量。
而对流程的管理，则是提供包括系统Change Request Management, Configuration Management等功能。能够将日常事务中，流程某一部分出现的问题，比如某一Transaction，通过相应的手段提交Message，并借助Service Desk等进行管理和解决。当然这部分在此不能说清楚。
从一个比较易解得角度来讲，SAP Solution Manager是SAP将自己在系统管理方面多年的经验推介给客户，通过有效地工具，减轻客户的负担，提升客户的管理水平。
其次，则是对各种Operations的Recording和Report。这包括Support 和 Service Desk的集成，实现对Open Issue/message的跟踪管理，Change Management，Monitoring部分各种功能的Reporting等等。
如果对SAP Service Marktplatz 或者SAP OSS稍加熟悉的话，我想你也不会对此太陌生。完全借助SAP OSS的经验，将所有的问题，包括状态，解决办法等等都加以组织，记录。很难想象，如果没有OSS，SAP如何对如此漫长的产品线，如此长久的产品周期进行有效的管理。同样的道理也在于客户的SAP项目。SAP希望这一切都变得可控。
如果单纯从软件的角度来讲，这应该是一个完美的软件工程案例。SAP对如此多的产品，提供了几乎能发现的所有Program Bug和解决方法的信息。这种维护是通过SAP自己，客户无数的积累得以完成。你对客户系统也应该如此。为什么不了?
对于SAP Solution Manager的应用，我个人认为暂时还处于一个非理想状态。大部分的项目并没有实施。原因可能因为一方面顾问的缺少，另一方面产品推出时间还不够长。当前版本是在4.0。不过既然是一个不错的选择，谁又能说以后。而且确实已经在很多客户那儿看到了需求。