在过去10年中，SAP Solution Manager----用以集中支持和系统管理的独特产品。不用说，跨国企业中的典型SAP系统景观一般包括了大量的SAP和非SAP系统。“复杂”的SAP环境（或者也叫多种多样的IT景观）常常由庞大的跨国企业在全球范围内使用的SAP ERP组成，在不同的部门可能使用不同的版本（这对于手动管理或半自动管理来说简直就是噩梦）。一些第三方企业资源计划（ERP）系统在情境假设中供远程部门、工厂和第三方最出色的解决方案使用的所谓的“第二层级ERP”（如Microsoft Dynamics AX, SAP Business One, SYSPRO, Epicor, QAD等），它们当中很多都得到SAP赞同甚至转售（例如在供应链管理SCM领域的SmartOps, Llamasoft, Vendavo等），然后，“复杂性”很快便成了轻描淡写。
在没有任何系统性的帮助下，普通人如何能管理所有的数据和流程（无论是在一个实况的系统操作还是从旧版本迁移到更新版本）？为此，SAP Solution Manager试图减少和集中管理各种不同的系统。在这样的IT景观中，SAP Solution Manager是一套管理系统（也可以称作“大脑”），SAP Business Suite则是应用系统，诸如SAP ERP, SAP CRM, SAP PLM, SAP BI, SAP SCM等则是被管理系统（犹如各个“器官”）。
SolMan到底能做什么？
Solution Manager是出于功能和技术目的的一系列工具。在不考虑管理系统数量的情况下，技术方面涉及到了对整个IT景观的实时监控、支持和维持（譬如支持请求和相关的笔记等）。对于他们来说，功能工具是为支持大量的文档和各种SAP目标而服务的，并提供对一个实施项目的所有阶段的集中控制。此外，Solution Manager 是在SAP系统内管理任何项目的日常工具。
• 文档库：一个可以单独存放需求描述、技术规范和其它Microsoft Word或者Adobe PDF文档的地方。
• 桌面帮助：一个允许打开案例、跟踪进程、插入相关文档和关闭案例（已经解决的案例）等功能的工具。该以外处理工具指导SAP员工和用户定义模块和流程，能够有效地管理特殊情况，以及在日常操作过程中发生的错误。
• 运输：是指从一个SAP系统到另一个SAP系统的配置和发展目标，例如，从一套开发系统到一套测试系统；从测试系统到生产（实况）等。
• 安全管理：允许用户确定在企业内部将有什么样的配置文件，也就是说，他（她）可以进入“创建或更改”模式还是只能拥有“显示或视图”模式。
• 状态报告：综上所述，包括归档、桌面帮助案例、配置文件等（一般来说，这是SolMan最常用的功能）。
该产品还能帮助您进行以下操作：
• 查明为企业服务导向架构的技术和组织准备是否就绪。
• 启用远程客户解决方案支持
• 监视业务流程和界面，以及监督关键任务的业务流程。
• 支持数据完整性，以避免在终端到终端的解决方案的蓝图的数据不一致。
• 管理大量的数据，以支持不可避免的数据增长。
• 管理背景工作的规划、调度和监控。
• 提供数据一致性服务，确保在分布式系统景观应用之间的数据同步。
SolMan支持以下应用程序生命周期管理（application lifecycle management, ALM）13种流程，从项目和解决方案（业务配置和持续性）的整个生命周期的两方面。
1. 解决方案文档----维护中央资料库文件和有关SAP和非SAP解决方案的业务流程和技术信息，以确保透明度、有效维护和协作性。
2. 解决方案实施----包括对新的和加强的不会过时的业务和技术情景假设的设别、适应和实施。此流程涉及从技术创新方面的业务系统的安装分离，利用SAP Solution Manager在系统景观内部进行创新解决方案实施。
3. 模板管理----允许多点SAP安装的客户能够有效地管理跨地理区域，如全球推广的方法的一部分：从最初的模板定义到模板实施和模板优化。
4. 测试管理----在变化影响分析的基础上，定义集成测试要求和测试范围变化，用来开发自动和手动测试案例，管理测试人员以及报告进展和结果。
5. 变更控制管理—提供基于工作流的业务管理，技术驱动解决方案提高变更，并与项目管理、质量管理和同步部署能力，与风险相关的解决方案实施相结合来实现最佳管理，因此，必须确保技术和功能的坚固性。变更控制管理包含了部署和分析软件及变更配置。
6. 应用事件管理----使得企业内部对多个各级组织的集中和共同的发布消息的处理成为可能，并且为所有利益相关者提供沟通渠道。流程包括业务用户、SAP客户端专家、SAP服务与支持伙伴雇员。该流程与SAP所有SAP Solution Manager ALM流程相统一，并且内置于任何SAP Business Suite解决方案，还能与非SAP帮助桌面应用程序相连接。还有跟进活动的功能，比如知识搜索、根源分析或者是变更管理----对终端至终端的不同等级和不同技术的支持。
7. 技术操作—代表了用于监测预警、分析、管理和Sap解决方案的所有功能，并允许客户通过为SAP Solution Manager预定义的内容和集中化的工具来减少总体拥有成本（TCO），还提供了终端到终端的开箱即用的报告或单独由客户创建功能。
8. 系统管理----为了高效地运行客户解决方案，介绍如何管理SAP技术。系统监控覆盖了IT解决方案的技术状态监测和报告。
9. 业务流程操作----包括最重要的应用相关业务所必须的核心业务流程，以确保平稳可靠的流量，达到公司业务需求。
10. 维护管理包含了从发现和探索软件校正套件中测试范围优化，其中可能包括了可选的自动部署到生产环境。
11. 景观改造（LT）--捆绑软件和服务，以满足全面的方式来改造方案。SAP LT软件第一个版本已经涵盖了一系列的支持执行转换项目的解决方案。另外，SAP LT包含的系统环境优化（SLO）组，以支持各种额外的要求，在改造目的互补性的服务产品。产品功能与未来发布的新功能。
12. 自定义代码管理----从SAP的自定义代码管理提供了全面了解企业如何才能切实有效地管理其自定义代码的功能。
13. 升级管理----代表识别、适应和新的和扩展业务和技术方案的实施，与SAP Solution Manager全面和有效地终端到终端项目的管理升级。它允许SAP客户更好地理解和管理重大技术升级项目带来的风险和挑战，使升级改造项目成为非业务事件。
对于Solution Manager的真正需求
Solution Manager已经很自然地成为了SAP过去10多年历史的一部分。该产品最初是为客户提供一个以上的系统（例如，用户监控多个系统）支持而诞生的。之后，它与AcceleratedSAP (ASAP) 实施工具来创建完整的应用程序生命周期管理解决方案。如今，Solution Manager支持技术人员（例如，技术操作）、质量管理经理（如系统测试）、项目团队和经理（如实施中）、流程经理和业务专家（如业务监控和分析）、项目管理办公室团队（如组合项目管理）、团队（如票务和根源分析）、IT管理（利用仪表盘）。
最新版的NetWeaver （SolMan毕竟是NetWeaver的一部分）的发布能够处理所有不同版本的SAP产品，只要是NetWeaver平台，所有这些产品都可以兼容。而且，NetWeaver Process Integration (PI) 组件提供在各种非SAP系统蓝图内的交流。
SAP 标准客户被允许在基本范围内使用SolMan（大部分功能已经在本文中介绍）。SAP在企业支持（Enterprise Support，以下简称ES）的客户被赋予了该产品的所有功能使用权，而且还有 Custom Development Management Cockpit, Business Process Change Analyzer, and Quality Gate Management额外的功能。更重要的是，SolMan不仅仅是只对于SAP组件，同样包括了完整的客户解决方案（意味着所有的IT组件都将作为文档归类在SAP Solution Manager中）。
明确标准的和ES支持的益处
SAP企业支持包括了所有的标准支持外加一些高级元素，诸如可修改行动承诺的服务水平协议，访问解决方案架构服务，充分利用SAP和非SAP解决方案的Solution Manager。还有24小时全日制访问SAP支持建议中心以及完全访问SAP Support Academy，同样包含了Expert Guided Implementation和Guided Self Services。它具有非常强健的服务组合，称作持续质量检测，能被利用在整个项目实施和以及生产运作中。访问SAP在线服务社区、文档和支持门户网站，还提供错误修正、产品/技术更新以及法律条文变化（如果适用）。
正如早前提到的，SAP Solution Manager是SAP为ALM提供的平台，可以使用户管理他们的整个SAP解决方案景观以及促进SAP Enterprise Support支持服务的进一步增加值的实现。任何SAP Enterprise Support用户都能赋予了使用SAP Solution Manager 的所有功能的权力，在应用程序管理支持项目和解决方案双方面 （业务配置和业务持续性）贯穿整个生命流程。其中一个例子便是SAP’s Business Process Change Analyzer，帮助用户降低回归测试的成本。此外，SAP Enterprise Support 顾客能够在他们的整个顾客解决方案中使用SAP Solution Manager，这意味着所有的IT组件（包括SAP和非SAP）都被用作与SAP业务流程和文档的连接。例如，一个客户能够使用IT Service Desk应用程序包括SAP Solution Manger作为基本的IT票务工具（不需要额外的许可费用）在使用移动设备来输入订单来支持一套业务流程。图1和图2提供了更详细的关于Solution Manager赋予用户的能力。
SAP Standard Support将包括基本的支持元素，诸如问题解决（在没有服务协议的情况下），错误修正，产品/技术更新，从服务的角度来说，包含了两项基本健康检查。一项是在整个实施项目中意图使用（Go Live），另一项是在Go live环境之后交付。同样提供访问SAP在线服务社区、文档和支持门户网站的服务。
Standard Support 的用户要注意了，Solution Manager的使用只对SAP组件。并不是SAP Solution Manager的所有功能都对Standard Support 的用户开放。特定的ALM和Run SAP功能无法被SAP Standard Support 客户使用。总结如下：
• Custom Development Management Cockpit
• 业务流程变更分析器
• 质量门户管理
• 管理仪表盘
• 自动测试框架
• 更新/加强业务流程文档能力
• 更新/增强系统监控能力（技术和业务流程为基础）
Solution Manager对纯英文的需求
任何经验丰富的SAP实施者都可以告诉您为何SolMan被使用多种SAP系统的企业所需要。例如，永远都不会忘记，任何给定的SAP系统能够有多个实例，这可能意味着在公司的
不同部门使用SAP软件的不同版本----那不过是变得越来越不现实。但是，往往不是，SAP实例是指多个SAP系统内的一个用户公司，如下：
• 沙箱系统----顾名思义，任何用户在没有任何控制的情况下都可以对系统进行任意操作（输入和删除虚拟数据、更改配置等），该系统的理念是为了让用户熟悉系统，并不会对系统造成不良后果。规模较小的企业也许有1个或者最多2个沙箱，约三分之一的规模和生产系统的电源硬件明智。大型企业（例如西门子和Caterpillar）有能力拥有最多8个沙箱，其中一些大小与他们的生产同行相等。
• 开发系统----有权力的用户执行系统配置和开发。此例子通常具有多个子例子，最常见的是“黄金顾客”的字实例保存系统，以避免出现任何开发问题。由于是与上述的沙箱实例的情况下，较大公司的IT预算，越大的公司拥有不同目的和情景假设的子实例的可能性就越大。
• 质量保证系统（简称“质量”）----有权限的用户用来进行系统测试。此例子偶尔（但在严格控制的方式下）获得来自生产（实况）的数据刷新。该实例往往会有一些子实例（或者是在SAP lingo中的SAP“顾客”），如：更新质量、改善新业务质量、批量测试质量、质量预分期（在实况系统更新之前加载大量数据，作为额外的测试步骤）等等。通常来说，QA是实况系统的最后一个实例。
• 生产（实况）系统----顾名思义，此实例用于企业数据和交易的日常运作。从硬件方面，实况系统可以跨越物理服务器，取决于企业可以负担的灵活性，但是从商业逻辑角度来说，生产实例应该只有一个SAP客户端本身。我意识到只有西门子拥有两个实例，但是伴随了一系列两个系统之间的日常数据同步和交易问题。我不确定这种“永远不能过于小心”的态度（以防万一两个系统之一出现故障）值得额外的努力和痛苦。
当现场SAP系统正在配置功能，工作处于开发实例阶段，或缺运行到QA实例，据此，成功和彻底测试后，一切变得现场实例。类似的路径在开发环境中被遵循（如所有支持
Advanced Business Application Programming [ABAP] 和Java）。即使是规模相对较小的企业为保持所有这些实例和系统只有3个SAP服务器可能纠缠时，视图来管理所有的程序和配置要求。
过去如何被完成
想象现在的环境，在一个大型国际性企业，如果没有灵活的工具加以管理，那么对这些工作任务进行排序就成了无法完成的任务。这也是SAP要发明Solution Manager的原因。
在SolMan之前，类似的管理都是通过人工（纸张）或者是利用Microsoft Excel，这是既繁琐又容易出错的方法（想象一下如果有人记录了错误的信息，或者更糟，删除了一
些至关重要的信息，那将会发生什么）。
毋庸置疑，每家公司都有自己的管理制度，正如SAP成长一样，就像用户在这些公司的数量（这将转化为更多的要求、开发和配置等），最终意识到需要想出一些可以促进所有选区的努力。SAP因此向顾客推出了免费的Solution Manager，在顾客已经激活维护的合同，这是很公平的。因此，一套SAP ERP系统为了可以满足企业和行业的需求而变得非常复杂，SAP应该免费赠送顾客一些服务。
SolMan管理大量来自配置和开发SAP系统的文档的能力是无可争议的。事实上，雇员需要进行以下文档处理：触发了新的请求配置，商业案例证实了该请求，要做什么，要求哪些人员，所需要的平准和签名，规范用户参考手册（一旦配置完成），用户验收测试，您将命名其它任何可能的文档。
一些制药企业，例如，拥有整个部门的员工只利用SolMan来生成文档：哪些文档需要由谁批准，如何批准，文档需保存在哪里（电子版本或者纸张版本），采购，流程……这更有针对性，as Sarbanes-Oxley Act of 2002 (SOX)根据要求生成文档。我们对于加航的支持将一如既往。
谁在使用SolMan?
在9月份的SAP TechEd2011活动中，SAP发布了SAP Solution Manager 7.1，为用户提供了检修等新功能以及更简单的用户界面，新功能如下：
• 整个解决方案的新检测和警报基础设施（SAP和非SAP应用程序）
• 增强的开放性和集成的第三方产品，如IBM Rational测试管理
• 自动记录现有业务流程使业务流程文档能轻松被保存和更新
Solution Manager涵盖了以下SAP重要平台：NetWeaver（包括了SAP Business Suite、SAP All-in-One 和SAP Business ByDesign），业务目标，Sybase和HANA记忆应用程序。唯一例外是，相比之下，只有少数用户使用SAP Business One，并因此通过SAP服务市场服务。鉴于十多年前成立以来（见Solution Manager 7.1发布的最新功能如图4），人们不禁要问，许多SAP客户如何真正利用该解决方案。
正如SAP所言，如今已经有超过70%的SAP顾客使用SAP Solution Manager，管理着总量超过25000 SAP生产系统。SAP已经看到了通过SAP Solution Manager作为支持协议的一部分的需求正在不断上升。
或许应该这么问：有多少SAP顾客正在使用SolMan，并且使用比例占了整个SolMan功能的多少？毕竟，所有前面提到过的SolMan的功能都能被独立使用，但并不是必须被使用。准确地说，Solution Manager 7版本，所有SAP顾客都要求通过工具创建支持票务，如SAP的活跃的全球支持（Active Global Support, AGS）全球员工使用SolMan来向外部顾客和SAP内部交付支持和修改活动。另外，顾客和SAP员工都有直接访问Solution Manager 7发布记录的权限。因此，支持和报告功能一般都得到了100%的利用。
一些规模较小的公司最有可能因使用该系统的转换功能，而往往忽视了文档的功能（或者只使用最基本的文档，如要求和规格表格）。另一方面，大型企业往往受到政策和法规的限制（例如美国食品和药物管理局）或者有内部需要，为自己的控制权将使用更多的SolMan功能。不明显的成本不应该被忽略：当SolMan成为SAP的免费产品时，企业也许要聘请一支军队来执行所有的SolMan流程，维护它的文档等等，这就需要花费更多的资金。
SAP坦诚地列举了为什么有些企业没有充分使用该工具的原因：
• 某些功能需要更多的时间适应（例如变更请求管理），因为需要完整的顾客项目。
• SAP Solution Manager 7功能缺损（如对非SAP应用程序的支持度非常低）已经使顾客将SAP Solution Manager 7作为他们的标准管理解决方案变得困难。这些缺陷在SAP Solution Manager 7.1版本中已经被根除。
• 很多顾客无法获得来自SAP足够的支持来保障采用该系统。不过，SAP现在开始提供SAP Solution Manager的路线图、知识转移和技术服务。
一些美好的愿景
尽管SAP看到其客户群对SolMan的不断普及，因此在路线图中并没有太多的牵引力。路线图是SAP Solution Manger的一部分，包含了标准SAP实施方法论和SAP实施最重要的方面
和阶段（最佳实践、项目管理、解决方案路线等）。路线图提供了完成项目的加速器和工具。
可惜的是，用户并不认为这些是必要的工具，而且还觉得会使情况复杂化。SAP已经试图说服用户在SolMan中链接ARIS流程到已有的SAP Business Suite交易。从理论上来说这些
都非常有吸引力：从采购到支持所有的流程步骤，使所有图块逻辑地链接到各自的SAP ERP交易周期的流程图。当终端用户点击图表的块，会激发一个特定的SAP屏幕。
现实生活中，并没有如此多的的最终用户使用。甚至是在实施阶段，我们谈论的是早期创建流程图阶段，用户并不会对交易的链接太在意（如果他们不知道在最后的阶段流程将会如何）。但是当流程已经决定并且敲定，终端用户并不真正关心地图，而是关心创建坚实的用户说明，始终随着时间的推移而改变。通过SolMan来处理发生在不必要的维护工作中的所有的流程变化。即使是大型企业能够将文档处理发放到成本更低的取悦，他们也不会感激那些不必要的额外工作和额外成本，即使并没有很贵。
麻烦的是雇员的心里和态度。规模较大的企业通常有较大的预算来承担SAP实施，还不如支付知名的咨询公司的雇员，并与他们交谈计划，并不像SAP所建议的需要通过一些套件流程地图。换句话说，小型企业期望项目能够简单成功地交付，而不必去考虑诸如“我们需要全自动或者半自动的软件供应商评估服务吗？”或者是“我们需要多久进行一次完整的物料需求计划（MRP）”等一些令人头疼的问题和决定。可悲的是，许多公司对这些问题的意义以及众多复杂而又难以预料结果的答案毫无头绪。
换句话说，Solution Manager生成需要的项目文档的能力，系统提前配置和系统测试建议（基于用户对实施问题的回答）的能力常常无法让困惑的用户印象深刻。大型企业通常对
套件和自动化的方法持怀疑态度，正如他们通常采用“开箱即用”的方式（尤其是在他们可以承担这种方法的情况下）。对于他们来说，小型企业望而却步于阅读手册并评估他们的配置参数所需要的巨大努力，特别是如果他们的印象中该系统只是在较差的环境下工作。
SolMan的独特之处
正如在那篇名为ZDNet’s博客中讨论的，SolMan是被用来集中管理使用频率最高的软件，包括用户安全维护（除了上述状况的报告能力）。SolMan已经成为IT景观集中访问所有需要管理系统的网关。当这篇文章发布时，也许已经无法赶上该产品快速发展的步伐。
换句话说，由于SAP的不懈努力和不断投资，SolMan已经能被视为IT界的奇迹，尤其是没有其他软件供应商的产品能够涵盖如SolMan可以涵盖的所有功能。多数ERP产品都有实施方法论并带有自己的名称（如QuickStep, SureStep, Accelerated Something之类的）。有些产品具有强大的配置管理功能（如Infor ERP SyteLine），有些产品则拥有流程建模能
力，例如QAD，Sage ERP X3和Infor ERP LN。Oracle提供自己的巨大的ERP不可知的Enterprise System Manager。
而且，市场上众多数据中心管理与SolMan具有类似的功能。很多诸如此类的产品帮助软件公司跟踪哪些功能是他们的顾客用来支持员工看某种形式的安装或者其它（如Sage
Advisor）。大多数公司通过软件包在客户端的安装来进行升级（即，顾客只有通过他们的软件包下载更新）。
换句话说，具有讽刺意味的是可以视SolMan为一个复杂的证明，在几十年前（主机和client-server/4GL时代）企业应用程序出了何种错误。有些人可能认为该套件缺乏真正的竞争
，无法为企业带来有意义的信息和真正的价值。事实上，对于SolMan的使用需要投入很大的努力，并且还会给用户带来无计划的附加成本。SolMan因此被视为SAP用来限制复杂性的必要的恶魔。
公平起见，在SOA、云、社交、移动和虚拟技术横行的时代，没有一家拥有几百个开发人员的小型软件供应商能够像SAP那样，可以完全满足财富500强的超过上万员工的大型跨国企业的需求（即使与复杂性作为副产品）。Salesforce.com, Workday, 和UNIT4 能够自豪地谈论他们在大型跨国企业实施和实施后的成功，并不需要控制哪些顾客使用的是哪个版本（毕竟，所有的公有云多租户都在使用最新版本）。但是这些供应商只相当于SAP Business Suite套件覆盖的功能范围的一小部分，它们更像是部门解决方案，而非企业级解决方案。
最终，当客户做出了足够的投资时，Solution Manager可以证明是一套可以减轻客户日常系统管理痛苦的非常实用的工具。但是很多顾客还没有完全了解解决方案，这便是SAP的义务对顾客进行教育，也许通过解释他们自己的员工如何内部和外部地使用该解决方案。
