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这一功能的增强产品，可以直接集成使用。这意味着以前手头拥有的大量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，或者金蝶也许更好。