微软-Dynamic-Sure-Step-2012-指南-全-

微软 Dynamic Sure Step 2012 指南（全）

原文：zh.annas-archive.org/md5/81e0bb05d2e6277a3cf77fb541c74b21

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

企业资源规划（ERP）和客户关系管理（CRM）解决方案支持组织广泛的业务流程。这些流程包括核心财务和会计、产品工程、销售自动化、销售订单管理、供应链规划、订单履行和物流，以及售后服务和支持。其中许多对公司的运营至关重要，因此这些组织在确保找到满足其需求正确解决方案的过程中必须非常严谨。

微软认识到客户的需求，并着手开发了一种名为微软 Dynamics Sure Step 的方法论，以帮助客户实现他们的目标。这些目标中最重要的是提供流程，以实现一致和可重复的解决方案部署。然而，在这个过程中，还需要确保客户和销售团队能够以有意义的方式进行互动，选择正确的解决方案，并确保项目范围界定得当，以满足客户的目标。

本书涵盖内容

第一章，背景和概念，介绍了在 ERP 和 CRM 解决方案的选择和实施中方法论的重要性。选择不当的过程可能导致任何解决方案部署失败，因此读者了解如何防止这种情况的发生非常重要。许多实施也因范围界定不当、风险和变更管理不善而出现问题，我们将从这一关键方面开始讨论。我们还通过简要介绍微软 Dynamics 解决方案的历史背景，从收购到其演变为当前世界领先的组合，来设定上下文。

第二章，解决方案销售和推动尽职调查，专注于销售商业解决方案的理论和方法。我们还讨论了买家在解决方案获取周期中的进展。从解决方案提供商的角度来看，解决方案销售要求他们与客户建立关系并建立信任。我们还讨论了在帮助推动客户愿景和范围的同时，建立关键绩效指标和解决方案的价值衡量，以及完成销售。从客户的角度来看，我们讨论了成为以解决方案为中心的组织，在选择满足其需求的正确解决方案时进行适当的尽职调查，并确保交付活动的范围设定能够实现组织的目标。

第三章, 《使用 Sure Step 进行解决方案构思》, 建立在上一章销售理论和概念的基础上，并具体说明了 Sure Step 如何帮助销售 Microsoft Dynamics 解决方案。我们讨论了活动，并详细介绍了有助于加速销售周期并使其结束的决策加速方案，同时帮助客户完成尽职调查过程。我们还讨论了诊断阶段如何通过概述涉及的风险为高质量实施奠定基础。我们讨论了选择正确部署方法的选择，以及合作伙伴和客户团队将扮演的角色。

第四章, 《项目管理》, 专注于介绍项目管理的价值主张，并从结果驱动和现实生活的角度讨论项目管理。本章揭示了项目管理的阻力以及通过释放项目管理的真实价值来克服这些阻力的方法。在向读者介绍项目成功的四个支柱并解释项目管理的基本要素的同时，我们引导他们了解智能项目的益处。我们还从组织角度讨论了项目管理的采用情况。

第五章, 《使用 Sure Step 实施》, 专注于解决方案部署和实施生命周期。我们讨论了 Sure Step 提供的水晶瀑布和敏捷方法。在瀑布方法中，我们讨论了实施 Microsoft Dynamics 解决方案的不同实施阶段和跨阶段，包括上线后阶段。在此过程中，我们展示了实施者和客户在实施 ERP 和 CRM 软件解决方案时面临的现实挑战以及解决这些挑战的方法。在敏捷方法中，我们讨论了这种灵活和迭代的组织方式以及它如何支持解决方案交付。

第六章, 《质量管理与优化》，讨论了合作伙伴和客户确保高质量实施的一些选项。我们还介绍了 Sure Step 优化方案，并讨论了构成这些方案的前瞻性和上线后审查服务。

第七章, 《使用 Sure Step 升级》, 专注于帮助现有 Microsoft Dynamics 客户将解决方案升级到最新产品版本。我们讨论了决策加速方案中的升级评估服务，以确定正确的途径，然后解释了 Sure Step 升级项目类型用于技术升级。我们还建议在升级过程中添加新功能的方法。

第八章, 《项目和组织变更管理》专注于 Sure Step 中的项目管理与变更管理学科。我们讨论了项目管理的关键子学科，如风险、范围、问题和沟通管理。我们还解释了为什么在 ERP 和 CRM 合作中，组织变更管理是客户和合作伙伴需要考虑的关键领域。在本章中，我们还涵盖了 Sure Step 中内置的 SharePoint 功能，以协助解决方案交付团队有效协作。

第九章, 《采用 Sure Step 的实际指南》专注于在 Microsoft Dynamics 合作伙伴组织中采用 Sure Step。我们讨论了组织如何使其实施方法成为其核心竞争力之一。我们还涵盖了独立软件供应商（ISV）的视角，并讨论了 ISV 解决方案提供商如何利用 Sure Step。

第十章, 《总结与收获》旨在提供本书的总结视图。我们还提供了读者可以在短期内执行的关键行动项。

您需要为本书准备什么

本书的唯一软件先决条件是能够访问 Sure Step 方法。您可以通过 PartnerSource（如果您是合作伙伴）或 CustomerSource（如果您是客户）在线访问 Sure Step 或下载 Sure Step 客户端。

本书面向对象

如果您是一位经验丰富的从业者，但新进入 Microsoft Dynamics 领域，或者刚开始接触 ERP/CRM 解决方案，那么《使用 Microsoft Dynamics Sure Step 实现客户成功》这本书将为您提供资源，以提供满足或超出客户期望的商业解决方案。如果您参与以下所述的一个或多个角色，那么这本书就是为您准备的：

• 如果您是参与交付 Microsoft Dynamics 解决方案的项目经理、项目经理、解决方案架构师或顾问，学习您如何可以通过一致、可重复的过程提高您实施的质量。

• 如果您是客户项目经理、领域专家、关键用户或最终用户，参与为您的组织选择正确的业务解决方案并交付 Microsoft Dynamics 解决方案，确定该方法如何促进交付与您的愿景一致解决方案。

• 如果您是参与 Microsoft Dynamics 解决方案销售的销售主管、服务销售主管、技术销售专家、售前顾问或项目经理，了解您如何可以加速您的销售周期，并使其圆满结束。

• 如果你是在你的业务解决方案需求选择过程中参与决策的客户决策者、C 级高管、采购人员或项目经理，确定这个过程如何帮助你进行尽职调查，并为解决方案的高质量实施奠定基础。

如果你是一位变革管理专家，了解你如何在业务解决方案交付过程中帮助客户管理其组织变革，以及/或者帮助解决方案提供商采用销售和交付解决方案的流程。

术语约定

在这本书中，你会发现许多不同风格的文本，用于区分不同类型的信息。以下是一些这些风格的示例，以及它们含义的解释。

新术语和重要词汇将以粗体显示。你在屏幕上看到的单词，例如在菜单或对话框中，将以这种方式显示：“点击下一步按钮将你带到下一屏幕”。

文本中的代码单词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 处理方式如下所示：“一旦添加，SureStepProjectWizard.xap 应该作为 Silverlight 网页部件添加到库中的新页面。”

注意

警告或重要提示将以这样的框显示。

小贴士

小技巧和窍门将以这样的形式出现。

读者反馈

我们始终欢迎读者的反馈。告诉我们你对这本书的看法——你喜欢什么或可能不喜欢什么。读者反馈对我们开发你真正从中获得最大收益的标题非常重要。

要向我们发送一般反馈，只需发送电子邮件到 <feedback@packtpub.com>，并在邮件主题中提及书名。

如果你在一个主题上具有专业知识，并且你对撰写或为书籍做出贡献感兴趣，请参阅我们的作者指南www.packtpub.com/authors。

客户支持

现在你已经是 Packt 书籍的骄傲拥有者，我们有许多事情可以帮助你从你的购买中获得最大收益。

下载本书的彩色图像

我们还为你提供了一个包含本书中使用的截图/图表彩色图像的 PDF 文件。彩色图像将帮助你更好地理解输出的变化。你可以从以下链接下载此文件：www.packtpub.com/sites/default/files/downloads/7027EN_Graphics.pdf。

错误清单

尽管我们已经尽最大努力确保内容的准确性，错误仍然可能发生。如果您在我们的书中发现错误——可能是文本或代码中的错误——如果您能向我们报告这一点，我们将不胜感激。通过这样做，您可以避免其他读者感到沮丧，并帮助我们改进本书的后续版本。如果您发现任何勘误，请通过访问www.packtpub.com/submit-errata，选择您的书籍，点击勘误提交表单链接，并输入您的勘误详情来报告它们。一旦您的勘误得到验证，您的提交将被接受，勘误将被上传到我们的网站，或添加到该标题的勘误部分下的现有勘误列表中。您可以通过从www.packtpub.com/support选择您的标题来查看任何现有勘误。

侵权

互联网上对版权材料的侵权是一个跨所有媒体的持续问题。在 Packt，我们非常重视我们版权和许可证的保护。如果您在互联网上发现我们作品的任何非法副本，无论形式如何，请立即提供位置地址或网站名称，以便我们可以寻求补救措施。

如果您在本书的任何方面遇到问题，请通过 <copyright@packtpub.com> 联系我们，并提供疑似侵权材料的链接。

我们感谢您在保护我们的作者和我们为您提供有价值内容的能力方面提供的帮助。

咨询

如果您在本书的任何方面遇到问题，可以通过 <questions@packtpub.com> 联系我们，我们将尽力解决。

第一章：背景和概念

对 ERP 系统（或基于最佳实践功能的任何集成应用套件）的最大批评之一是它们缺乏灵活性，不支持业务变化。Gartner 发现，在太多情况下，任何感知到的缺乏灵活性更多是由于 ERP 应用程序的采购和部署方式，而不是技术本身的固有缺陷。

Gartner, Inc., 2012 年 1 月

商业解决方案的成功，尤其是企业资源规划（ERP）和客户关系管理（CRM）解决方案的成功，并不仅仅关乎技术。经验告诉我们，它同样关乎人和流程，就像它关乎软件一样。软件只是使能者，成功的钥匙在于制定一个适合公司短期和长期目标的组织解决方案策略，将需求与适当解决方案相匹配，然后管理实施以满足既定目标。

当组织考虑 ERP 和 CRM 系统时，他们通常想到的是核心财务和簿记功能，或者基本的客户联系管理活动。虽然这些系统确实可以并支持这些功能，但了解这些解决方案的现代版本开始为公司及其用户群提供的能力也同样重要。这些系统已经远远超出了这些基本基础，涵盖了组织在多个功能、部门和跨部门方面的需求。当前一代的商业解决方案能够提供支持包括产品工程、销售自动化、营销自动化、客户关怀、销售订单管理、供应商关系管理、供应链规划、订单履行和物流，以及售后服务和支持的复合应用。

考虑到现代系统提供的广泛功能，组织在构建策略时必须系统化，并调整他们的方法来了解可用的解决方案功能，并将它们与公司特定领域的具体需求相匹配。近年来，帮助组织构建成功解决方案策略的最佳研究模型之一是Gartner Pace Layer Model。本章将向读者介绍这个模型，并解释它如何帮助组织调查其业务系统需求。

微软一直明白，只有当解决方案与客户需求良好匹配，并且解决方案的实施能够满足用户需求时，其客户才能从他们的软件投资中获得最大价值。带着这种愿景，微软开发和推出了微软 Dynamics Sure Step 方法，以帮助服务提供商正确定位和部署微软 Dynamics ERP/CRM 产品套件——AX、CRM、GP、NAV 和 SL。Sure Step 是一个促进咨询和客户资源合作的平台，代表了软件供应商、实施者和客户之间合作的重要三角关系，实施方法成为实施应用的关键元素。

在本章中，我们将介绍本书中使用的概念和定义，并为后续章节奠定背景。我们还将概述微软 Dynamics Sure Step，以及帮助实施者和客户的不同方法方面。

商业解决方案市场

过去几年，全球大多数经济体经历了经济衰退或相对低迷的活动。然而，根据国际货币基金组织（IMF）的数据，我们开始看到 2012 年第三季度出现了一些微小的改善，并且他们预测 2013 年将出现全球增长。有趣的是，IMF 指出，“加速的主要来源是新兴市场经济体，那里的活动正如预期那样普遍回升，以及美国，那里的增长超出预期，金融状况稳定。”以下图表说明了这一点——左边的图表来自 2012 年 1 月，右边的图表来自 2013 年 1 月：

分析师将 2013 年的 ERP 和 CRM 商业解决方案市场规模量化为接近 630 亿美元。这个数字中有许多零，说明了市场潜力。尽管许多地区的经济体继续对销售周期产生影响，从而抑制了这些解决方案的采用，但商业解决方案仍然是商业领导者在追求为利益相关者创造价值的过程中首要考虑的事项。

在他们的 2012 年 CEO 调查中，高德纳（Gartner）对 200 位 CEO 和商业高管进行了市场预期和优先事项的访谈。当被问及在接下来的五年中，哪种新类型的信息将对其行业最具颠覆性时，技术排名第一，其次是法律和监管、可持续性和环境、消费者行为和数字媒体指标。对于哪项技术赋能的能力将是未来五年提高业务的重要投资领域的问题，CEO 们将以下内容列为他们的首要任务：

• CRM

• 数据驱动管理

• 电子商务

• 业务流程重组

• ERP

• 协作与知识管理

• 云业务

• 社会组织

• 企业移动性

• 改进业务报告

• 可持续性

• 动态业务流程管理

• 跟踪性和供应链优化

• 产品成本分析

CEO 们为了更好地管理业务而希望获得的信息的前几类如下：

• 客户情报

• 竞争对手情报

• 销售信息（管道/增长）

• 监管信息

• 成本

• 内部财务信息和预测

• 行业趋势数据

• 劳动力和生产率信息

• 经济数据

• 实时数据

• 商业更优

• 地理市场数据

国际货币基金组织和 Gartner 的分析告诉我们，尽管经济形势如此，但商业领袖仍然继续投资于技术，作为提高其商业盈利能力和地位的手段。在技术组合中，包括 CRM 和 ERP 在内的商业解决方案仍然是这些领导者的首要任务。因此，为组织开发适当的解决方案策略成为整体战略的关键部分，我们将在下一节中讨论。

使用分层速度构建解决方案策略

迈克尔·波特是商业战略领域的主要作者和思想家之一。波特认为，运营效率不是战略，它是必要的但不是充分的。他陈述说：

问题的根源在于未能区分运营效率和战略。对生产力、质量和速度的追求催生了大量管理工具和技术：全面质量管理、基准测试、基于时间的竞争、外包、合作伙伴关系、再造、变革管理。尽管由此产生的运营改进往往非常显著，但许多公司因无法将这些收益转化为可持续的盈利能力而感到沮丧。而且，几乎不知不觉地，管理工具取代了战略。"他继续补充说，运营效率“意味着比竞争对手更好地执行类似的活动。运营效率包括但不限于效率。 ....相比之下，战略定位意味着与竞争对手执行不同的活动或以不同的方式执行类似的活动。

广受赞誉并推荐的 Gartner 分层速度模型帮助公司通过分解组织变化速度对应的系统和解决方案套件，来确定适当的解决方案策略。在其分层速度模型中，Gartner 将系统分为三个类别：

• 变化速度最慢的系统——记录系统

• 变化速度中等的系统——差异化系统

• 变化速度最快的系统——创新系统

Gartner 的分类基本上决定了组织中相应系统的变化率，并据此提出关于如何进行评估和更换过程的建议。理解速度分层模型的一个好方法是将系统应用程序架构与建筑的建筑和设计联系起来。以下图表展示了这种关联：

一座建筑始于地基。一旦奠定，除非出现一些重大的建筑需求，否则不太可能改变。同样，商业解决方案的根基是行政 ERP 系统，这些系统支持公司的财务和人力资源需求。这些记录系统通常一经设定就保持不变，长达二十到三十年，当然，这并不包括对总账和账户表的持续修改和维护。在他的关于模型驱动开发和分层速度的博客中，Butti 将这些描述为：

支持核心交易处理并管理组织的关键主数据的系统。变化率较低，因为这些流程已经确立，并且对大多数组织来说是共同的，并且通常受到监管要求的影响。

然后是建筑的墙壁、供暖、通风和空调（HVAC）、管道、电气和其他区分建筑与其他建筑的核心方面。这些方面比地基更快地经历变革。从应用程序架构的角度来看，这些类似于差异化系统。这个领域包括运营系统，如供应链管理系统、销售自动化系统和车间控制系统。组织在遇到其生态系统的变化时，每三到十年就会寻求新的或更新的系统。Butti 将这些描述为：

能够实现独特公司流程或行业特定能力的应用程序。

它们需要频繁重新配置，以适应不断变化的商业实践或客户需求。

最后，你会在建筑中看到室内装饰和家具。墙面涂料可以更换，或者家具、画作、图片等都可以定期移动。同样，创新系统可能需要快速更新，几个月到一年内。社交商务、商业智能和报告系统等都需要对现有平台进行快速更改。Butti 暗示了这些：

基于临时构建的新应用程序，用于解决新的商业需求或机会。这些通常是生命周期较短的工程项目……使用部门或外部资源以及消费级技术。

在他的研究文章《将 Pace Layering 应用于 ERP 战略》中，Nigel Raynor 讨论了这种方法如何帮助减少 ERP 供应商在组织应用战略中的主导地位，并创建一个更具差异化的业务解决方案治理模型。他还讨论了如何通过分层策略帮助组织将应用组合分解成更小的组，从而帮助他们的业务用户识别差异化和创新的机会。

Pace Layer 模型帮助组织弥合业务和 IT 团队之间的差距。业务用户迫切需要易于使用和部署的现代系统，并满足一组特定的要求。另一方面，IT 部门有一个更战略性的目标，即管理有限的应用程序，以最小化集成和系统管理成本。Pace Layer 模型帮助公司制定一个既能满足业务对差异化和创新系统的需求，又能满足 IT 团队对支持核心业务流程的安全系统的目标的战略。

两层方法、云计算和工作负载

Gartner Pace Layer 模型提倡根据相应的组织需求采用适当的系统。Gartner 以及许多其他分析师现在都在宣扬公司需要为他们的应用组合构建一个更敏捷的战略，以便他们能够快速适应其生态系统中不断变化的情况。因此，旧有的单一实例业务系统涵盖组织所有方面的口号在当今时代已不再相关或可行。

现在在设计应用战略和部署到组织中的两层方法越来越受到重视。两层方法通常由两个解决方案组成；一个解决方案支持组织的行政职能，包括财务和人力资源，第二个解决方案支持组织的运营职能，从产品工程到销售和采购，订单履行，维护和售后服务。通常，在传统系统中投入大量资金的组织发现这是一种保护这些投资的方法，同时还能使他们的运营中的应用现代化，并提供用户所需的灵活性和对重要信息的访问。

在研究文章《两层战略：重振 ERP 的方法》中，作者 Drew Robb 讨论了两层战略的好处以及为什么公司越来越采用它。文章引用了一位首席执行官的话：

我还没有遇到一个在全球范围内仅运行一个 SAP 实例的企业。它不存在。运行的实例从未低于个位数。最佳情况是，它有几十个。

阿伯丁集团将考虑采用两级架构的公司数量定为 25%，而恒星研究公司在其研究中发现，48%的组织正在考虑采用该架构。然而，阿伯丁也指出，他们预计这一数字将会上升。无论实际数字如何，很明显，这已经成为公司中越来越受欢迎的策略。

文章列举了以下适合两级策略的场景：

• 具有非常具体的地方性关注——单一地点或单一国家或地区的多地点——因此对多货币或多语言支持的需求较少

• 专注于特定行业的业务运营，可能是一个在总部或组织内部其他地方不太突出的垂直行业

• 新收购的运营，存在多个不匹配的过时、不受支持的 ERP，需要单一的小型或中型 ERP

• 没有正式 ERP 的初创公司或小型子公司，企业渴望使用二级 ERP 来实施业务严谨性

• 在第二级的小型运营，不需要使用企业级 ERP 软件，但随着运营的增长，它可能会更多地融入企业体系

还值得注意的是，随着云计算和软件即服务（SaaS）模式的兴起，两级方法甚至获得了更多的关注。在 SaaS 中，SaaS 提供商几乎完全管理解决方案，用户对技术基础设施的访问最小或没有，也不需要。越来越多的提供商，包括微软，正在为用户提供在线和本地选项，以支持端到端或特定点的解决方案，从而允许客户利用两级方法作为逐步将技术转移到云的手段。公司可以选择将支持一个或多个子公司的应用程序迁移到云，或者选择将特定的功能，如费用报告或间接采购，迁移到云。

为了实现这种方法，像微软这样的公司正在吹嘘能够在工作负载中实施解决方案的能力。工作负载可以是一个单独的业务流程，如费用管理，也可以是一个功能内的多个业务流程，如供应商关系管理、供应链管理、人力资本管理或销售、营销或客户服务。在这方面，工作负载可以包括ERP 和 CRM 工作负载。工作负载还可以解决组织垂直功能的运营需求，如其制造或零售运营。本质上，工作负载方法将系统分解成多个块，使公司能够选择那些特别适合其需求的块，并使他们能够在最符合其短期和长期商业目标及用户需求的时间表上部署这些块。工作负载方法还使实施周期更短、成本更低。

下面的图示说明了微软 Dynamics 工作负载方法。该模型在 2013 年 3 月的微软 Dynamics Convergence 2013活动中向客户和合作伙伴展示，并在Dynamics Business 2.0 Vision论文中也有描述。

如以下图所示，微软将其工作负载分为三个层级——适用于企业功能的管理核心、适用于多个行业且可以针对其中任何一个行业进行定制的横向运营工作负载，以及涵盖特定垂直领域（如分销或制造）业务流程的行业运营工作负载。

方法论的重要性

一致的方法论对于客户项目成功至关重要。对于实施客户解决方案的服务提供商来说，一个可预测和可靠的方法论也同样重要。这在 CRM 和 ERP 解决方案部署中尤其如此，其持续时间可以从几个月到几年不等，具体取决于实施的范围，并且交付团队通常由来自服务提供商到客户的多个人组成。在这些合作中，方法论提供了一个统一的分类法，这样所有个人都可以说是在同一张乐谱上工作。

方法论可以定义为以下之一：

• 某一学科所采用的方法、规则和假设，以及其背后的理论

• 对学科内应用的方法和过程进行系统研究。

methodology 也可以被描述为与特定学科或领域相关的理论、概念和过程的集合。方法论不仅仅是一系列方法的汇编，它指的是科学方法及其背后的原理，以及方法定义和组成部分的假设。

这些定义提供了构建、设计和构建方法论的结构，包括一个适应 CRM 和 ERP 业务解决方案交付的方法论。对于 CRM 和 ERP 解决方案，一个可行的 methodology 应该为用户提供工作流程和流程，并且它还应该提供与项目执行中涉及的各种学科和角色的连接。它应该提供详细的指导和假设，以便为每个活动提供灵活性，使用户能够通过采用方法论的所有或仅相关方面来适应相应的 engagement。

一种可持续的方法不仅提供了解决方案部署的一系列流程。对于服务提供商，一个可行的 methodology 可以提供：

• 解决方案开发和部署的端到端流程，创建一个可重复的过程，有助于执行卓越

• 能够将 shell 和样本模板、参考架构和其他类似文档链接到关键活动

• 创建一个有效的知识管理（KM）系统的结构，便于更容易地收集、存储、检索和重复使用在客户 engagement 中创建的内容

• 能够为咨询团队成员的培训制定一个合理的结构，包括对新员工的培训

• 能够将质量保证方法与部署过程对齐——对于使用独立 QA 流程作为咨询工作监督的组织来说非常重要

• 能够为解决方案开发和部署制定结构化的估算流程

• 创建一个用于项目范围控制和管理的结构，以及早期风险识别和调解的流程

对于客户，一个可行的 methodology 可以提供：

• 清晰的端到端流程，用于解决方案开发，可以由客户的关键用户和分配给项目的主题专家（SMEs）遵循

• 一致的术语和分类法，特别是在 SMEs 可能没有先前实施此类规模系统的经验的情况下，这使得每个人都更容易达成共识

• 能够开发一个良好的知识管理系统，以捕获未来项目/升级的经验教训

• 能够为最终用户培训和新人入职制定合理的结构和文档

• 创建一个确保项目在范围内进行的结构，包括早期风险识别和调解的流程

包含上述方面和特性的方法论可以证明对服务提供商和客户都有益。对于服务提供商的好处包括：

• 咨询团队与销售团队的更好协调

• 一种更科学的交易管理和审批流程，考虑到潜在的风险

• 更好的流程促进在销售周期中确定的客户知识向解决方案交付团队的转移

• 能够向客户展示服务提供商“以前是如何做的”，并有效地建立他们能够交付预期解决方案的信任

• 清晰地展示解决方案对客户的商业价值

• 能够将多个软件包集成到为顾客提供的整体解决方案中

• 能够在范围内、按时、在既定的预算内交付最初设想中的解决方案

对于客户来说，以下是一些好处：

• 能够理解和阐述解决方案对组织内所有利益相关者的商业价值

• 确保已经建立了一个清晰的解决方案蓝图

• 确保解决方案按照最初设想在范围内、按时、在既定的预算内交付

• 确保整体解决方案能够集成多个软件包

总结来说，一个好的方法论为组织创造了一个更好的整体生态系统。这里提到的只是一些在组织中观察到的益处；当你在自己的组织中利用方法论时，你可能会发现其他益处。

解决方案选择方法论的重要性

通常而言，业务解决方案的交付，尤其是 CRM 和 ERP 咨询，与其他解决方案（如电子邮件系统）的部署非常不同。电子邮件通信无疑对公司来说很重要，尽管在今天的环境中，社交方面似乎对内部沟通同样重要。然而，一家公司完全可以在可预见的时期内没有电子邮件运作——人们可能实际上不得不求助于现在看起来似乎是过时的通信方式，拿起电话与其他方交谈。虽然这听起来可能很幽默，但这并不离现实太远，一些员工可能会争论说，在电子邮件中断期间，他们的效率实际上可能会提高，因为他们实际上能够专注于他们的核心工作要求。

与基础设施解决方案相比，CRM 和 ERP 系统通常构成了公司的骨架。这些系统支持核心功能，如从报价到订单录入、订单履行、收付款、人力资源和薪酬、库存管理、分销/生产计划、需求预测以及销售管道管理等。如果这些系统长时间中断，公司将会受到严重损害。这就是为什么 CRM 和 ERP 系统通常被视为关键任务系统，而基础设施系统则通常被视为业务关键系统。

从解决方案交付的角度来看，与基础设施项目相比，CRM 和 ERP 项目也存在着相当大的差异。以下插图展示了微软产品组合中的部分产品。随着您从左到右浏览这个系列，如以下图表所示，预计的解决方案交付工作量以及配置、定制和复杂性将以指数级增长：

在这个图形表示中，关键点是 CRM 和 ERP 解决方案需要特定的配置和定制，这远超典型的基础设施解决方案。当您考虑这些解决方案如何应用于众多不同行业和垂直领域的组织多个功能时，这一点是可以理解的。随着定制需求的增加，努力和复杂性也随之增加。这并不是说所有基础设施项目都将直接采用现成解决方案，或者所有 CRM 和 ERP 项目都将高度定制。任何解决方案都将具有一系列的复杂性，从快速部署到更长时间、更复杂的解决方案开发和部署。强调的重点是，这种更高的复杂性意味着在解决方案交付过程中需要有一个实施方法论，以确保适当的项目和质量管理。本质上，这正是微软 Dynamics Sure Step 所提供的，我们将在下一节中介绍。

正如我们之前提到的，CRM 和 ERP 解决方案通常支持组织的核心业务功能。因此，客户在选择满足他们需求的正确解决方案之前，会花费很长时间进行必要的尽职调查。鉴于这种重要性，如果一种方法论不仅有助于解决方案交付生命周期，而且超越这一点帮助客户进行选择过程，那么这种方法对客户来说可能具有极高的价值。从销售者的角度来看，这也是重要的——鉴于这种重要性，客户在选择解决方案提供商或实施者时，就像他们在业务应用本身上所做的那样进行尽职调查。如果解决方案提供商向客户提供一种方法论，帮助他们选择满足他们需求的正确解决方案，然后交付预期的解决方案，那么客户肯定会更愿意与该合作伙伴建立长期关系。

在解决方案选择/尽职调查过程中，Sure Step 指导客户完成需求收集过程，包括确认他们当前的（“现状”）流程和确定他们未来的（“目标”）流程。然后客户能够确定每个需求如何适应所提出的解决方案。此外，客户还能够确定必要的基础设施组件（硬件和任何第三方软件），以及发布时间表（包括咨询和客户组织资源需求的整体计划）。尽职调查阶段的关键输出是一个解决方案蓝图，它阐述了为客户提出的解决方案，以及一份工作说明书，解释了如何执行解决方案蓝图。

介绍 Microsoft Dynamics Sure Step

在上一节中，我们讨论了在选择和部署 CRM 和 ERP 解决方案时拥有一个稳固的方法的重要性。Microsoft Dynamics Sure Step 为用户提供了这样的服务——既适用于客户也适用于服务提供商。我们将在本节中介绍 Sure Step，并在本书的其余部分讨论它是如何设计来履行这些承诺给组织的。

Microsoft Dynamics Sure Step 是适用于所有 Microsoft Dynamics 解决方案的全套客户生命周期方法论。它为服务提供商提供从销售到交付的全面指导，项目管理的纪律对齐，以及基于现场的最佳实践，同时促进尽职调查过程和为客户提供高质量解决方案的交付。

Sure Step 的首个版本于 2007 年发布，自那时起，Sure Step 已发展以满足 Microsoft Dynamics 生态系统的需求。现有的工作流程已被修改和简化，并引入了新的工作流程。该方法也被扩展为一个完整生命周期方法，包括客户的尽职调查生命周期作为解决方案交付过程的先导。此外，更多内容正在提供给用户，当前版本提供了超过一千个内容项，从指导页面到模板到一般项目管理库。以下是一些 Sure Step 的关键特征，包括 Sure Step 2013 版本的亮点。

使用六个阶段，Sure Step 不仅涵盖交付，还包括解决方案定位和销售。第一阶段诊断为服务提供商提供指导和建议，以帮助客户在选择满足其需求的正确解决方案时进行尽职调查。其余阶段，分析、设计、开发、部署和运营，提供了解决方案交付的工作流程和内容。

Sure Step 为整个 Microsoft Dynamics 解决方案套件提供覆盖，包括 Microsoft Dynamics AX、Microsoft Dynamics CRM、Microsoft Dynamics GP、Microsoft Dynamics NAV 和 Microsoft Dynamics SL。最近的 Sure Step 版本还扩展了该内容的通用覆盖范围，涵盖了特定行业和跨行业解决方案领域。

Sure Step 提供了一种非常灵活的解决方案交付方法，包括瀑布式和迭代式方法。标准、快速和企业是瀑布式项目类型，可以根据客户合作情况进行扩展或缩减，而升级项目类型也是一种瀑布式方法，专门针对升级现有解决方案。Sure Step 还为那些适合迭代式解决方案交付方法的合作提供了敏捷项目类型。

Sure Step 中的项目类型具有一种结构，将每个合作分解为跨阶段或泳道。Sure Step 的跨阶段包括 项目管理、培训、业务流程分析、需求和配置、定制编码、质量和测试、基础设施、集成和接口以及 数据迁移。这些跨阶段为用户提供了一个功能性的活动或步骤的旋转，以交付相应的解决方案领域。

Sure Step 包括对 Microsoft Dynamics 合作中优化方案的覆盖。这些方案包括在实施过程中的主动质量保证审查，以及上线后的审查，以帮助维护已运行一段时间系统的持续维护。

其他 Sure Step 功能包括涵盖项目管理和组织变革管理学科的关键流程指导，以及参与项目中涉及的典型角色，无论是来自咨询组织还是客户组织。Sure Step 应用程序还允许用户在适当的文件夹中创建项目，无论是在他们的本地机器上还是在 SharePoint 服务器上，以帮助多个项目团队之间的协作工作。

可以通过两种方式访问 Sure Step：

• 传统选项是Sure Step 客户端，可以下载到用户选择的机器上，并允许用户在离线模式下访问指导、工具和模板。

• 第二个选项是较新的Sure Step 在线。用户需要互联网连接才能利用这个访问选项，但好处是他们可以更快地获取 Sure Step 团队提供的更新，而 Sure Step 客户端可能更新频率较低。

微软 Dynamics 概述

如前文所述，Sure Step 涵盖了整个微软 Dynamics 解决方案系列。在本节中，我们将对这些解决方案进行概述，这主要旨在提供一个快速参考，或者为那些可能不熟悉该系列所有解决方案的读者提供一个起点。

微软 Dynamics 是微软的业务管理解决方案系列，提供企业资源规划（ERP）和客户关系管理（CRM）功能。该系列包括四个 ERP 解决方案，这些解决方案是通过收购产生的，以及一个 CRM 解决方案，其开发是在微软开始的。

微软 Dynamics GP（以前称为 Great Plains）和微软 Dynamics SL（以前称为 Solomon）都是在 2001 年从位于美国北达科他州 Fargo 的 Great Plains Software 公司收购的。Great Plains 开发了一套在中美市场流行的中型企业会计软件包，而 Solomon 则提供了一套具有项目管理功能的项目会计 ERP 系统。微软 Dynamics AX（以前称为 Axapta）和微软 Dynamics NAV（以前称为 Navision）都是在 2002 年从丹麦的 Navision A/S 公司收购的。Axapta 和 Navision 是流行的 ERP 解决方案，尤其是在欧洲的制造和分销中型企业中。这些 ERP 系统成为了微软新成立的一个部门——微软商业解决方案（MBS）的起点，而微软 CRM 也被添加到 MBS 产品组合中。正如之前所述，微软 CRM 主要是自产的，并于 2003 年首次发布（版本 1.0）。

2005 年，微软重新命名了产品，并创建了一套名为 Microsoft Dynamics 的业务解决方案。这个套件包括四个 ERP 解决方案——Microsoft Dynamics AX、Microsoft Dynamics GP、Microsoft Dynamics NAV 和 Microsoft Dynamics SL，以及一个 CRM 解决方案——Microsoft Dynamics CRM。整个套件使用 Microsoft SQL Server 作为数据库技术。

下图展示了时间线：

Microsoft Dynamics 解决方案被设计成让用户感到熟悉，与客户已经部署的现有系统轻松协作，赋能个人和团队提高生产力，并帮助组织推动业务成功。ERP 套件提供了帮助企业在财务规划、会计、产品工程和数据管理、供应商关系和采购、供应链、生产、分销和物流、项目会计、现场服务和人力资源流程等领域的功能。CRM 解决方案允许公司通过销售自动化、客户服务和营销等功能，简化员工与客户沟通和协作的方式。

Microsoft Dynamics AX 是为全球企业提供的一套业务解决方案，它支持行业特定的和运营业务流程，以及财务和人力资源管理方面的全面核心 ERP 功能。

Microsoft Dynamics CRM 通过组织和自动化那些能够培养客户满意度和忠诚度的业务流程，帮助降低成本并提高盈利性。

Microsoft Dynamics GP、Microsoft Dynamics NAV 和 Microsoft Dynamics SL 是为小型和中型企业提供的一套业务解决方案，它们提供开箱即用的业务管理功能。

除了全面的 Microsoft Dynamics 解决方案套件之外，独立软件供应商（ISV）合作伙伴还提供了一系列集成和专业的解决方案，这些解决方案针对特定行业和更深入的功能需求。

理解什么是项目

这似乎是一个简单的问题，但我们是否曾想过对我们业务至关重要的是什么？在我们开始制定如何管理和销售项目策略之前，我们需要了解什么是项目，更重要的是，它不是什么。

大多数人回答问题时会提到活动、计划、会议、截止日期、文档、人员和目标。这是我们很多人对项目的看法，但我们可以把所有通过计划活动试图达成目标的活动都称为项目吗？答案可能是，不一定。例如，在汽车公司的生产工厂中，人们通过计划活动实现目标并协作，但我们不会将这些活动归类为项目。

在我们能够谈论一个项目之前，我们需要确定我们努力的独特性和临时性。项目按定义是临时的，因为它们有明确的开始和结束日期。我们大多数人都很清楚我们项目的开始日期；结束日期可能更令人担忧，并且常常与全新软件解决方案的上线日期混淆。项目也是独特的，不仅因为它们产生独特的可交付成果，还因为执行的环境是独特的。独特可能意味着它以前从未做过，或者可能以前以非常相似的方式做过，但从未完全以同样的方式做过。因此，根据定义，没有两个项目是相同的。

在我们可以在文献中找到的大多数项目定义中，这些关键要素都得到了很好的吸收。

项目管理知识体系（PMBOK）将项目定义为：

一个旨在创造独特产品、服务或结果的临时努力。项目的临时性质表明它有一个明确的开始和结束。当项目目标实现或项目因目标无法实现或无法实现而终止，或者当项目不再需要时，项目结束。

通过实施 Microsoft Dynamics 解决方案，我们实施 ERP 或 CRM 软件功能，从产品的角度来看，许多这些实施看起来很相似。那么，是什么使这些实施变得独特呢？

尽管我们正在实施典型的 ERP 或 CRM 功能，但我们需要为每个客户实施独特的业务需求。每个客户都有对特定可交付成果的独特需求，例如内部报告和定制功能，以匹配他们独特的业务流程组织。但更重要的是要注意，人们使这些实施变得独特。在客户环境中实施解决方案总是独特的，因为我们总是与不同的人合作。他们总是有不同的背景、知识水平、期望、目标和他们自己独特的工作方式。我们还与不断变化的咨询实施团队合作，这取决于我们顾问的可用性，从而产生一个独特的环境。所以，是的，Microsoft Dynamics 的实施是项目，因为它们是独特的，并且它们旨在是临时的。我们总是需要在有限的时间内交付我们的项目，而且没有任何两次合作是相同的。然而，这涉及很多不确定性，因此我们的 Microsoft Dynamics 合作以不确定性与风险并存为特征（在 ISO 31000:2009 中，风险被定义为不确定性对目标的影响）。

现在我们已经理解了什么是项目，我们也需要了解它不是什么。项目不是持续和重复的；项目不是运营。由持续重复的过程驱动的业务承担的风险较小，因为环境控制得更好。在我们的项目中，我们没有这样的控制环境。我们可能了解一些我们的关键用户，但我们可能不知道系统的所有关键和最终用户，也不知道他们可能对业务流程和业务解决方案的熟悉程度。我们不知道他们的沟通能力如何，也不知道他们在团队中的表现如何。在规划新的合作时，我们不知道的事情太多了。

重要的是要意识到这些风险，并意识到我们所从事的业务与以运营驱动的业务完全不同。只有在这种情况下，我们才能真正开始制定如何管理和销售项目的策略。因此，我们应该审查我们的未来提案和计划，考虑到我们正在规划的是一个项目，这最终意味着在规划风险。我们应该规划这些计划和策略如何覆盖不确定性。

大多数项目的定义都包括独特性和临时性的要素，但并没有具体说明。以下是一些需要回答的其他问题：

• 理解合同和商业事务同样重要吗？

• 我们是否在交付项目？

• 我们如何参与项目？

• 我们有项目责任吗？

• 我们承担了多少项目风险？

这些问题的答案规定了如何销售和管理我们的项目。仅仅外包资源来完成项目任务，并不需要与承担固定价格项目所有项目风险的管理相同。

实施解决方案

向软件供应商询问他们对商业解决方案的定义，你可能会收到一些专注于帮助自动化业务流程、赋能业务各个方面并最终加速组织成功的功能性的答案。诸如洞察力、效率、灵活性、成本降低、响应性等词语被用来展示投资回报的证明。

但当你向客户提出同样的问题时，你会得到什么答案？客户的回答通常不太确定，并且相当不一致。大多数决策者都有自己的理由，解释为什么他们想在组织中拥有软件解决方案。他们想要实现的目标与该公司的独特历史、他们无可比拟的做法以及他们所属的行业部门有关。他们的目标也与公司的商业计划和战略目标直接相关。这意味着客户对商业解决方案的定义永远不会是普遍的，而总是具体的。

尽管商业解决方案旨在在组织内实现相同的结果，但客户通常寻求非常具体的解决方案来解决他们独特的难题，并支持他们所设想的商业挑战。无论解决方案的功能多么丰富，独特的客户期望不能只是现成交付。这个差距需要通过实施过程来弥合。

有些人可能会认为，在小型和中等规模的公司中实施商业解决方案，与在大公司中的大规模实施相比要简单得多。在这里，不要急于下结论。一般来说，小企业的业务流程可能不太标准化。但你会发现，有许多丰富而有趣的程序代表了他们独特的工作方式。这使得需要一个独特的商业解决方案的需求更加迫切，并要求实施过程更加高效。

到现在为止，你已经明白实施过程是整体解决方案的关键部分。但在你进入客户的场所开始实施之前，考虑一下这一切对客户的意义是明智的。想象一下自己处于客户的位置，不要想当然。你的实施策略将如何影响这个组织？他们能否构想出实施过程是什么，更重要的是，它对他们意味着什么额外的价值？他们是否意识到风险，并且知道成功实施项目需要双方共同努力？他们是否清楚自己的角色是什么？

商业解决方案的实施充满了挑战。即使是已经交付这些解决方案多年的顾问，在项目中也可能会遇到他们以前未曾遇到的问题。无论培训了多少年，无论有多少经验丰富的同事作为影子，独特的挑战总会出现。考虑到这一点，我们的客户有时无法估计他们需要投入多少努力来实施，并且没有意识到他们的参与的重要性。因此，对于咨询团队来说，确保客户理解他们在整体解决方案交付过程中的期望是非常重要的。

ERP 和 CRM 实施及统计数据

技术评估中心（TEC）是一个研究机构，它有几篇关于 ERP 和 CRM 解决方案的出版物。在他们题为《确保软件顺利实施的 5 大最佳实践》的研究白皮书中，他们提出了客户实施团队的一些关键点。强调的最佳实践包括：适当的规划、持续监控、更新利益相关者、预防范围蔓延以及协商额外的产品或服务。

管理层的支持也被认为是成功实施的关键之一。TEC 认为，企业管理层必须积极参与系统选择决策，指定一名执行赞助人参与并提供项目所需的支持。高级管理层赞助人积极推动预期的组织变革，被强调为“成功实施的关键、必须采取的步骤”。

确保跨职能团队的参与是 TEC 提到的另一个成功的关键。由组织内部所有职能部门和管理层组成的团队，有助于整个用户社区积极承担项目责任。这也确保了实施团队能够反映用户的需求，从而最大化解决方案带来的价值。

这些是客户团队需要记住的好点子，以便他们了解自己在实施解决方案中的责任。以下统计数据将说明，忽视这些教训的团队将自食其果。

近年来，关于 CRM 和 ERP 实施的报告通常强调客户期望与实际结果之间存在差距。研究还指出，时间和成本绩效仍然是客户和服务提供商之间争议的焦点。在解释这些统计数据时，必须谨慎。在将研究结果与自己的组织相关联之前，重要的是要了解研究测量的是什么，不同类型的受访者以及他们的方法论方法。

展示软件开发失败的最受欢迎的报告之一是 1994 年的 Standish 的混沌报告。当混沌报告报告软件开发项目成功率为 16%时，Standish 混沌报告震惊了行业。同一报告称，53% 的项目在实施上面临挑战，31% 的项目失败。尽管被认为具有争议性，但这份报告成功吸引了全球对解决方案交付问题的关注。

几年后，我们仍然有混沌报告，但现在我们还有许多其他研究。混沌报告 2009 年的统计数据表明，32% 的项目成功，24% 的项目失败，44% 的项目面临挑战。根据 Panorama Consulting 2011 年对 ERP 实施的研究：

54% 的公司表示他们的 ERP 项目耗时超过了预期，56% 的公司花费超过了预期。

与他们上一年度的研究相比，统计数据实际上有所改善——70% 的项目报告称上一年度项目耗时更长。研究发现，43% 的公司超出了预期的预算：

提到了项目控制不足和预期不切实际。他们还倾向于关注与软件相关的成本，而忽视了与组织变革管理相关的成本。

不论统计数据如何，几乎所有的研究都得出结论，我们有机会改进，因为我们的大多数 ERP 和 CRM 项目比预期花费的时间更长，成本更高。在承担 ERP 和 CRM 项目时，这些值得记住，并据此进行规划。组织应该从失败和有挑战性的项目中学习，并且解决方案实施中的利益相关者应将它们作为持续改进努力的输入。

似乎也很容易将所有失败的实现责任归咎于服务提供商。但正如我们在前面的章节中提到的，一个解决方案由许多组件组成，包括产品（软件供应商）、服务提供商以及解决方案的使用者（客户）。虽然责怪实施者所有的失败可能很容易，但这并不完全合理。例如，看到客户政治和组织低效阻碍他们自己的项目并不罕见。

微软自己对客户升级 Microsoft Dynamics 合作的研究表明，几乎一半的升级是由于实施问题。进一步的研究表明，缺乏团队内的正式流程、沟通问题和范围管理等因素，证实了需要一个良好的解决方案交付方法的需求。

许多因素决定客户是否将项目视为成功。时间和成本是两个最重要的标准，但还有一个重要的参数有时被忽视——商业价值。最近的研究声称，ERP/CRM 的实施未能提供足够的商业价值，并且解决方案的组织变革报告为无效管理。这再次强调了需要一个良好的交付流程，这个流程从组织在开始项目之前明确确定成功因素开始。例如，微软服务要求在项目章程或类似的项目文件中注明满意度条件（COS），并在合作开始时由客户签字。COS 可以是非常好的项目成功指标，但衡量这个指标的关键是明确建立：

• 基线指标——项目启动之前存在的值

• 预测指标——合作的目标

当在前期建立基线指标时，项目指标在合作之后进行测量；团队可以清楚地确定项目的成功或失败。

核心研究公司（Nucleus Research）于 2009 年发布了一本名为《最大化交付 Microsoft Dynamics 成功》的指南手册，该手册至今仍提供了有价值的参考点。根据指南手册：

当正确部署时，微软 Dynamics ERP 和 CRM 解决方案可以为客户带来显著的回报——然而，这通常取决于选择一个能够按时、按预算完成项目，并且与初始项目范围和规划变化最小的合作伙伴。

核心集团还指出：

尽管结构化的实施方法为微软合作伙伴带来了最大的成功，但合作伙伴也需要足够灵活，以满足客户的具体需求，并随着商业动态的变化而不断发展……像 Sure Step 这样的结构化方法可以帮助合作伙伴平衡对客户诊断、实施和优化解决方案的方法。实施合作伙伴的技能和指导是微软 Dynamics 客户成功的关键因素，而那些最成功的合作伙伴已经超越了临时的诊断、沟通和项目管理，转而采用更结构化的实施方法，如 Sure Step。他们通过改进沟通、提高客户满意度，最终通过提高盈利能力和增长来获得这些好处。

摘要

本章作为本书的引言。我们首先讨论了商业解决方案市场的需求和优先级。然后解释了根据使用场景，CRM 和 ERP 解决方案如何对客户组织至关重要。这种关键性强调了选择满足客户需求可靠方法的需求，这种方法建立在愿景阶段获得的知识基础上，以提供满足要求的解决方案。我们还介绍了微软 Dynamics Sure Step 作为一种旨在满足这些需求的方法。

本章还包括了对微软 Dynamics 解决方案组合的简要概述。我们还介绍了商业解决方案领域中的项目概念，并讨论了实施这些解决方案以及从过去的实施中吸取的教训。

下一章将涵盖解决方案销售背后的知识体系以及它如何与客户的尽职调查过程很好地对齐。我们将展示这种方法对服务提供商和客户的益处。

第二章. 解决方案销售和推动尽职调查

在上一章中，我们讨论了拥有业务解决方案选择和交付方法的重要性。我们讨论了拥有方法对服务提供商和客户的好处。不仅方法通过工作流程和流程提供了一致和可重复的方法，而且还提供了与各种学科的连接，以及涉及解决方案交付执行的多重角色的协调。

对于商业解决方案，特别是对于 ERP/CRM 解决方案，我们也引入了全生命周期方法的概念。客户生命周期方法包括解决方案发现阶段、解决方案交付阶段，并继续到解决方案的运营和任何未来的升级。从发现阶段开始，全生命周期方法提供了一个结构化的解决方案评估流程，以及从诊断阶段到解决方案交付阶段的适当知识传播，从而确保最终解决方案设计与原始解决方案愿景保持一致。

诊断/发现阶段为成功奠定了基础，在这个阶段，客户和合作伙伴不应走捷径。有许多研究出版物和分析师报告都恳请公司在选择满足其组织需求的正确解决方案时进行彻底的审查过程。在本章中，我们将重点关注发现/诊断阶段的解决方案选择和尽职调查方面。

在本章中，我们将讨论以下内容：

• 诊断过程如何为客户和解决方案提供商创造价值

• 为了成为以解决方案为中心的组织，一个组织需要做些什么

• 解决方案销售对服务提供商的销售周期和客户的尽职调查过程意味着什么

• 微软支持解决方案销售过程的方法

为客户和解决方案提供商创造价值

商业解决方案应该关于在客户组织中创造价值。就这么简单！正如我们在第一章中讨论的那样，背景和概念，ERP 和 CRM 解决方案由于它们支持的核心功能而至关重要，包括从报价到订单录入、订单履行、收付款、人力资源和薪酬、库存管理、需求预测和销售管道以及客户关系管理。基于与这些解决方案接口的组织功能数量以及它们对这些系统的依赖程度，很容易看出系统对组织的影响。一个好的销售团队将在销售周期中阐述这一价值，并以客户能够相关联的指标来定位解决方案。

当解决方案与价值相关联时，在客户的组织中推动项目执行支持会更容易。对于如此规模的项目，执行支持在解决方案选择阶段以及解决方案交付期间都是绝对关键的。在解决方案的实施过程中，解决方案交付团队不可避免地会经历高峰和低谷。当存在明确的价值预测时，这些将成为团队在困境中继续前进的驱动器和激励因素。

为客户创造价值最重要的方面是确保正确的解决方案被定位以满足组织需求。一个好的销售团队总是将客户的需求放在首位。始终努力为客户及其组织做最好的事情，即使这意味着如果你确定它不适合你的解决方案，你将放弃这个机会。这就是道德发挥作用的地方，但当一个销售团队遵循这种思维方式时，他们将拥有欣赏和忠诚的客户。从长远来看，他们最终会站在胜利的一方，并且能够为自己的成就感到自豪。

史蒂芬·柯维在 20 世纪 90 年代出版了一本名为《高效能人士的七个习惯》的杰作。这本书因其易于遵循的方法而受到世界范围内的赞誉，该方法可以帮助我们解决日常生活中的道德和道德问题。柯维提倡的一个习惯是双赢思维，这与我们的当前讨论相关。高效的销售人员会努力实现双赢的交易，因为双方都会变得更好，最终都会获利。那些有短期眼光的人可能会通过欺骗客户在某些交易中取得成功，但长远来看，这会追上他们。

业务解决方案销售不应该只是为了填补销售期间的配额，而应该是帮助客户组织。当然，不能否认配额和奖金对销售行为的影响。然而，通过为客户匹配正确的解决方案，销售人员可以在帮助组织实现其潜力的同时实现个人目标。这应该给他们带来超越期末奖金的满足感。通过在销售过程中参与和告知客户，可以通过尽职调查过程实现长期价值。建立这种文化和在其组织中培养这些价值观的解决方案提供商最终会取得长期的成功。

价值实现和衡量

在客户的尽职调查过程中，服务提供商努力了解客户组织目前所处的位置以及他们对未来的愿景。拟议的解决方案将填补客户从现状到待实现状态的差距——有效的价值实现过程在这个周期早期开始，并与解决方案愿景和交付过程同步执行。

作为服务提供商为拟议的解决方案制定蓝图时，他们应该开始定义该解决方案将提供的价值。虽然这将在一定程度上包括确定客户满意度的条件，但确定价值的临界组件将是理解组织对拟议解决方案进行变革的业务驱动因素。

微软在其培训课程中定义业务驱动因素为：

“一个简短声明，明确具体地定义了组织期望的业务成果以及实现这些成果所需的必要活动。”

业务驱动因素有助于传达组织的愿景和战略。它们清楚地阐述了将组织从当前（现状）状态转移到期望的未来（待实现）状态的目标和目标。

业务驱动因素还可以帮助将业务优先级与组织战略对齐。反过来，它们可以明确地将每个倡议与组织的战略目标对齐，同时帮助衡量期望的结果。

简而言之，业务驱动因素是应该为组织带来可量化节省的东西。因此，业务驱动因素应具有SMART属性：

• 具体明确

• 可衡量

• 既有挑战性又可实现

• 以结果为导向

• 时间限制

微软提供了一种直接的技术来定义或编写业务驱动因素。从动词开始，并添加要测量的元素和重点或强调领域。

Business Driver = Verb + Element to Measure + Focus or Area of Emphasis

使用前面的定义，以下是一些业务驱动因素的示例：

• 提高 ABC 产品的销售额

• 降低 Plant XYZ 的平均库存

• 提高区域办公室的应收账款周转天数（DSO）

• 加速新产品推出的上市时间

一旦定义了业务驱动因素，重要的是要捕捉将使价值可衡量的指标。这也就是前面的定义也很有帮助的地方，因为“要测量的元素”转化为指标或关键绩效指标（KPI）。

微软定义 KPI 为：

“一个用于监控、预测和管理以实现特定目标所需绩效的仪器。”

价值测量声明随后包括关键绩效指标（KPI）和“阈值值”。

Value Measurement = Key Performance Indicator (KPI) + Threshold Value

以下是一些包含业务驱动因素的指标或 KPI 的价值测量声明的示例：

• ABC 产品的销售额增加 500 万美元

• Plant XYZ 的平均库存减少 15%

• 地区办公室的 DSO 将改善 5 天

• 新产品上市时间缩短了 30 天

在定义了业务驱动因素和 KPIs 之后，下一步是测量和捕获基线指标——当前（现状）下 KPIs 的值。这很重要，因为没有建立基线指标，您将无法量化新解决方案对驱动因素的影响，从而确定解决方案产生的实际节省。

与 KPIs 的确定相关，定义测量的时间和频率也同样重要。实际执行测量结果通常只在解决方案实际运行一定时期后进行，但团队应提前决定何时进行测量。他们还应决定相应 KPIs 的测量频率。

在确定了业务驱动因素、关键绩效指标（KPIs）、基线指标和测量频率后，可以设置解决方案交付流程，以确保价值实现得到加速和最大化。在解决方案部署并经过一段稳定期后，可以测量实际结果或指标。

以下图表总结了在业务解决方案背景下的价值实现和测量过程：

在接下来的章节中，我们将讨论如何通过以解决方案为中心的方法实现识别可衡量的痛苦和价值实现这一概念。我们还将讨论解决方案销售如何帮助客户识别正确的解决方案，并为解决方案的实施奠定基础，从而实现该解决方案预期的价值。

解决方案中心化的含义

让我们首先从“解决方案”的定义开始讨论。简单来说，“解决方案”一词意味着对问题的回答。但英语同义词词典还提供了其他术语，如关键、阐明、阐明、解释、解决和结果。所有这些定义都很好地融入了业务解决方案销售的框架中，这也是问题的关键所在——“解决方案”对不同的人可能有不同的含义。因为解决方案可以应用于多个情境，所以它是在组织中常用且有时被滥用的词汇；因此，有必要明确定义该术语的使用。

在他的著作《新解决方案销售》中，Sales Performance International（SPI）组织的创始人Keith Eades讨论了解决方案的定义。他描述解决方案为“对已识别问题的共同认可的答案，特别强调问题需要双方，即买家（客户）和卖家（解决方案提供者）的认可”。书中强调的解决方案的第二方面是它应该“提供一些可衡量的改进”。基于此，Eades 提出了以下关于解决方案的定义：

对已识别问题的共同答案，并且这个答案提供了可衡量的改进。

对于某些组织来说，声称他们拥有“解决方案”并且是“以解决方案为导向”的已经变得非常流行，因为这显然消除了与“产品”一词相关的负面含义。产品被视为销售公司强加给市场的产品，而解决方案则被视为市场积极寻求的东西，解决方案是卖家可以向买家提供的答案。那么，产品是不是解决方案的对立面呢？远非如此！在许多情况下，尤其是在商业解决方案的背景下，产品是解决方案的主要驱动力。但真正定义解决方案对客户成功或失败的是该产品的使用或交付。解决方案的前期定位是成功交付的关键，这就是以解决方案为中心的方法发挥作用的地方。

Eades 解释说，要真正以解决方案为导向，组织需要“不仅仅是表面的包装操作或捆绑产品和服务”。以解决方案为中心不应该被视为组织可以随意抛出的时髦词汇。在名为《以解决方案为中心的组织》的书中，Eades 表示，“以解决方案为中心的组织通过解决客户的问题来定义自己，而不是通过它们制造、销售或提供的产品或服务”。以解决方案为中心应该是一种渗透整个组织的哲学，这样销售、营销、产品开发和服务的团队都可以围绕一个共同的方法和模型进行协调。

在成熟的市场，如 ERP/CRM 解决方案市场，真正以解决方案为中心的需求更为重要。在这个市场中，许多顶级解决方案提供商提供的产品已经存在一段时间，并被许多组织使用。这些产品中的每一个都包含一套基础功能和特性，可能难以与竞争对手区分。计划绩效指数（SPI）将这种称为差异化模糊，这是由于产品被视为商品化，或者产品变得过于复杂和功能丰富，以至于行业无法将其与其他产品区分开来。为了应对这个问题，公司开始将他们的产品与服务捆绑在一起，并将这些视为解决方案。但他们真正实现的是创造了 SPI 所称为的“伪解决方案”。

这种方法既不能帮助寻找解决方案的客户，也不能帮助解决方案提供商发展出一套一致的销售方法。这一点进一步得到了行业分析师的市场调研的证实，他们发现这些解决方案提供商的价值定位只有 10%的有效率。研究还指出，在所谓的解决方案公司中存在的一些其他问题。在这些公司中，高达 70%至 80%的市场营销材料未被使用，这突显了销售和营销团队之间的脱节。研究还发现，这些公司随后将销售培训作为解决问题的手段，但他们常常发现未经加强的销售培训的有效期大约只有六到八周。

那么，一家公司如何才能真正以解决方案为中心呢？正如 SPI 所说，为了真正以解决方案为中心，组织需要采用持续的业务模式来营销、销售和交付客户转型。他们需要确定他们解决的问题，而不是他们提供的产品，将他们营销的所有方面与解决方案框架对齐，并在整个组织中系统性地采用和加强解决方案销售和以解决方案为中心的纪律。这样做的公司会发现，他们能够持续地向客户定位其解决方案的价值，明确区分与竞争对手的价值，并创造一个可持续增长的业务模式。

解决方案销售概念

在上一节中，我们讨论了公司在其整体组织中需要做什么才能成为以解决方案为中心。现在，我们将重点转向解决方案销售。我们将看到解决方案销售不仅如何帮助这些公司的销售团队，而且如何确保解决方案提供商帮助他们的客户实现并最大化其解决方案的价值。

解决方案销售和推动尽职调查是相互依赖的行动方案。虽然前者是服务提供商销售人员的更好流程，但后者是客户在产品选择过程中的更好机制。因此，一个好的解决方案销售流程有助于解决方案提供商，同时内在地帮助客户并确保尽职调查过程的彻底性，这反过来又为良好的解决方案交付流程奠定了基础。诚然，过程可能会偏向于解决方案提供商所代表的产品，然而，如果过程得到正确执行，客户应该能够清楚地确定其需求与解决方案之间的匹配程度，以及他们未来的解决方案将是什么样子。

让我们从解决方案提供商或解决方案销售员的视角开始探讨解决方案销售。在他的著作《新解决方案销售》中，Eades 讨论了解决方案销售如何帮助销售员——作为一个哲学、路线图、方法和管理系统。

解决方案销售是一种哲学，它能够渗透到组织的文化中，因为它将客户及其痛点作为焦点。解决客户的企业问题和取得积极成果是该哲学的关键要素。

解决方案销售提供了一张路线图，列出了实现销售组织最终目标的步骤。这包括识别和评估机会、诊断客户的问题和痛点、分析需求、制定解决方案愿景以及管理流程以实现成功的关闭。

解决方案销售可以被视为一种提供一系列工具、工作辅助、技术和程序的方法。当正确使用时，这种方法将导致更高的客户满意度和增加的销售生产力。

解决方案销售还创建了一个销售管理系统，通过在销售组织中建立高性能的销售文化，为销售和执行管理提供指导技能。因此，它也为整体销售绩效提供了一个有效的衡量工具。

解决方案销售 – 买家的视角

在最后一节中，我们从销售员的视角探讨了解决方案销售。现在，让我们从买家的视角来看解决方案销售。之前提到的四个领域中的三个直接影响到客户。

正如我们之前提到的，一个好的解决方案销售哲学将客户置于首位。任何使用这种技术的销售员都会自动考虑到客户的利益。这种方法在买卖双方之间建立了一种信任关系，并朝着实现预期解决方案结果的方向提供了一个更一致的方法。

解决方案销售流程中的步骤包括诊断问题或痛点、分析客户需求，以及制定与业务价值相匹配的解决方案愿景。这些步骤本质上帮助客户在挑选合适的解决方案以满足其需求时进行尽职调查。

解决方案销售提供了一种提高客户满意度的方法论。使用一致且经过时间考验的流程有助于销售团队利用他们在类似情况下的先前经验，客户可以利用这些经验为自己谋利。

在接下来的章节中，我们将讨论解决方案销售的两个关键方面：建立买卖双方的信任以及构建解决方案的愿景。

建立信任

通常，当买家认为他们所获得的产品或服务是他们问题的最佳解决方案，并且以最佳价格获得时，购买过程是最优的。随着购买规模的增加，买家在市场上进行研究的倾向也会增加，以寻求满足他们需求的正确解决方案和价格。本质上，买家的尽职调查过程的长度会随着其需求的重要性呈指数级增加。然而，还有一个因素可以影响买家的尽职调查过程，那就是信任——信任解决方案将满足他们的需求，信任卖家提供的最佳价格，信任卖家将交付承诺的解决方案，以及信任卖家在交付后出现任何问题时能够支持解决方案。

信任对于商业解决方案尤其重要。正如我们之前所指出的，商业解决方案是至关重要的任务，因此，本质上，任何错误的步骤或解决方案实现中的失败都伴随着高风险。因此，很容易理解建立信任的买卖双方关系的重要性。

更多的时候，信任是需要赢得的。在商业解决方案领域，拥有系统化流程的组织将更一致地取得成功。通过向买家展示你有一个经过深思熟虑、可重复的过程，你给予他们这样的舒适感：你已经与其他客户一起取得了成功，从而建立起信任。

解决方案销售流程就是这样一种流程，它允许你通过将注意力从“交易式销售”转向“关系式销售”来在客户中培养信任因素。

信任也可能具有经济影响。在《信任的速度》一书中，史蒂芬·M·R·柯维讨论了建立信任，并说明了信任如何成为经济驱动力。他的公式基于观察：信任总是影响两个结果——速度和成本。

当信任下降时，决策速度也会下降。这会使成本上升：

↓Trust = ↓Speed ↑Cost

当信任度上升时，决策速度加快，相应地，成本降低：

↑Trust = ↑Speed ↓Cost

柯维接着谈论信任的影响，将其比作税收或股息。他将信任融入传统的商业公式，并扩展如下：

(Strategy x Execution) Trust = Results

应该非常明显，信任的影响对于销售人员来说是一个重要的考虑因素。除了道德原因外，信任还对组织的销售成本产生经济影响。柯维用以下话语总结了信任的影响：

"与所有利益相关者——客户、商业伙伴、投资者和同事——建立、增长、扩展和恢复信任的能力是全球经济的关键领导能力。"

我们也可以在我们的客户交易中看到信任的影响。当新的卖家带着解决方案接近客户时，买家会寻求证明他们的解决方案已经成功，否则买家会转向更成熟的供应商。为什么是这样呢？这是因为客户对新的供应商的信任程度不如对成熟的供应商。这就是销售组织采用解决方案销售作为哲学的更加重要的原因。解决方案销售是卖家与买家建立信誉和信任的最佳技术之一，正如我们所看到的，它可以积极影响他们的成功率。

构建愿景

解决方案销售的关键方面之一，也是其最普遍和渗透性的主题之一，是卖家与买家共同构建解决方案愿景的观念。当解决方案真正从买家的角度阐述时，客户对解决方案感知的风险要低得多，因此他们更容易接受该解决方案。

迈克尔·博斯沃斯是解决方案销售的原始先驱之一。他撰写了名为《解决方案销售》的书籍，也是目前由基思·伊德斯运营的组织的原始创始人。博斯沃斯在他的书中详细讨论了创造愿景的观念，并将很高的重要性赋予了愿景创造过程。在博斯沃斯看来，人们从那些能为他们创造愿景的人那里购买，解决方案等同于买家的愿景。

对于像商业解决方案这样的大宗商品，人们从人那里购买的观点很常见。这些不是你期望某人通过互联网或通过其他“未见其人”的方法做出的交易。客户将希望确立解决方案是可信的，提供解决方案的团队是值得信赖的，支持解决方案的组织将长期存在。但让我们假设所有事情都是平等的或足够接近，以至于差异不明显——例如，竞争者也有成熟的解决方案以及值得信赖和亲切的销售人员。博斯沃斯观点的关键点在于，当卖家能够使买家感觉到解决方案属于他们并符合他们的愿景时，买家会感觉到他们控制着这个过程，并且他们获得了授权。

博斯沃斯的教学将买家的需求与解决方案愿景过程联系起来。随着客户在购买周期中的移动，他们的关注点会随着时间的推移而改变。因此，卖家与客户保持一致并同步推进愿景变得非常重要。当买家能够清楚地可视化和阐述卖家解决方案的未来结果时，销售过程变得更加简单，从而缩短销售周期并提高成交率。

1943 年，阿尔伯特·马斯洛撰写了一篇关于我们需求层次结构的经典论文，题为《人类动机理论》。马斯洛的需求层次从最低需求水平到最高需求水平，如下所示：

• 生理需求：这是第一级，包括基本的人类需求，如空气、水和食物。

• 安全需求：第二级的特点是个人和财务安全、健康和福祉。

• 爱和归属感需求：第三级涉及社会和情感需求，如友谊、家庭和亲密关系。

• 尊重需求：第四级是关于被尊重的需求，包括自尊（他人的尊重）和自尊（内在力量）。

• 自我实现需求：这一级涉及个人充分实现其潜能。

这个层次结构的关键点之一是从第一级到第二级以及更高级别的需求发展。根据马斯洛的理论，如果一个人无法满足其基本需求，如食物和住所，他们就不太可能追求更高的需求，如声望和地位。有些人批评了这个层次结构，但它也已成为许多学科的基础，并且这个层次结构已经应用于许多领域。例如，市场营销在马斯洛需求层次的基础上，有许多关于理解消费者购买行为的教导。在商业和销售管理中，这种相关性也很明显，包括通过如超个人商业研究等领域的应用。

博斯沃斯还以马斯洛的需求层次为基础，从解决方案销售的角度发展了买家需求周期。下图描述了这一需求周期从潜在需求到解决方案愿景的进展：

• 在零级，买家对产品或解决方案没有需求，卖家也认识到这一点——例如，你不会在撒哈拉地区寻找销售暖灯。这一级别显然超出了解决方案销售的范畴。

• 在第一级，卖家看到了市场上的需求，但买家尚未意识到这种需求。因此，解决方案的潜在需求存在于卖家而非买家的脑海中。或者换句话说，这是买家的潜在痛苦。处于这一级别的卖家通过向买家投射他们对解决方案需求的愿景来进行操作。

• 在第二级，买家意识到他们的需求或痛苦，但不知道问题的解决方案。在这个阶段，由于需求或痛苦被认识到但未得到满足，买方和合适的卖方之间有潜在的销售解决方案的可能。如果买家相信存在潜在的解决方案，他们将会积极寻求解决方案，需求就变成了主动需求。然而，如果买家认为他们的问题没有解决方案，需求可能会被压制并回到第一级作为潜在需求。

• 在第三级，买家看到了解决方案的愿景。买家的需求已经从潜在需求发展到主动需求，到了他们可以预见解决他们问题的解决方案的程度。在这个阶段，买家正在考虑购买解决方案，并且有一个非常成熟的愿景，包括四个组成部分——谁将采取什么行动，何时采取行动，以及通过卖方的产品或服务的哪种能力来实现。

在买家需求发展的这个过程中，一个关键点是，在第二级，买家理解解决方案的潜力，但这些需求尚未被卖家采取行动，因此它们是“未开发的需求”。如果在这个阶段，卖家将自己的愿景强加给买家，就会产生一个次优情况，买家不得不信任卖家来解决问题。因此，对于卖家来说，在这个阶段让买家承认他们的痛苦非常重要。这是卖家证明买家认为他们是值得信赖的，并且有能力提供正确解决方案的证据。

另一个关键点是，为了使机会被视为合格，买家必须同意积极参与共同开发解决方案愿景。买家必须能够阐述解决方案的要求或同意参与需求评估过程。

如果销售员发现自己处于一个愿景已经形成，他们只是在比较自己的产品与竞争对手的情况，那么他们有成为买家决策过程中另一个勾选的风险。很可能买家已经与一个帮助他们制定需求的竞争对手达成一致，并且只是在完成购买前寻找额外的证据点或价格优势。

当买家能够看到针对他们需求的特定解决方案能力时，他们就能够明确解决方案的愿景并采取行动解决问题。

确定演示解决方案的最佳时机

另一个在《高效能人士的七个习惯》一书中，史蒂芬·柯维讨论的习惯是“先求理解，再求被理解”。这个习惯是解决方案销售的核心观念之一：通过首先理解客户试图解决的问题，耐心地培养对解决方案的兴趣。为了与客户建立双赢的关系，你必须理解对他们来说胜利意味着什么，换句话说，一个成功的解决方案对他们来说意味着什么。通过从客户的需求和愿望的角度概述目标，遵循“同理心沟通的原则”。这使你能够在客户的目标下制定解决方案愿景，从而促进更容易地接受你的解决方案。

对于解决方案销售，迈克尔·博斯沃斯有一个简单的信息：“诊断后再开处方”。开处方是指销售员以公司、产品或服务的演示作为开场。而不是关注客户的组织需求和利益，销售员的信息应该表述为“你需要……”。销售员不应假设买家已经了解他们的产品或服务将带来的价值。因此，他们应该首先尝试了解买家的需求，然后根据买家的价值指标定位他们的解决方案。

说到先听后说，这比实际生活中更容易说难做。因为我们常常缺乏耐心。当我们知道答案时，我们很难抑制住自己或对那些不知道我们信息的人表示同情。博斯沃斯称这种销售员的急躁为“过早的详细说明”，他认为这是导致销售失败的主要原因之一。此外，急躁对建立买家和卖家之间关系的解决方案销售目标是有害的。

当销售员以功能特性为开场时，他们正中竞争对手的下怀。记住，除非你在一个非常独特的行业运营，并且在该市场上拥有垄断地位，否则你的竞争对手很可能有一套令人信服的功能和特性。博斯沃斯认为，在销售中产品的角色应该是证明——不是在引起兴趣、教育或需求发展。

产品应该被用来证明解决方案确实符合客户的愿景。

这种方法以多种方式使卖家受益。早期产品演示可能会导致买家感觉他们正在被“推销”。如果客户尚未详细说明他们的需求，与客户讨论产品特性可能会被视为卖家试图将自己的解决方案强加给买家，更不用说这还会给随后的竞争者提供可乘之机。

早期展示产品也可能导致卖家不得不讨论客户根本不感兴趣的功能。然而，在演示过程中，可能会出现需要销售团队为其产品辩护的问题——如果卖家已经确定买家感兴趣的确切功能，并只专注于那些解决方案组件，这些问题本可以避免。

另一个推迟进行全面解决方案演示的原因是，在解决方案愿景开发完成后，客户可能会要求进行概念验证。此外，卖家可以避免在演示过程中讨论可能出现的任何具体定价问题。直到客户接受解决方案愿景，卖家最好避免详细定价讨论，而应保持在粗略的数量级。当客户看到解决方案愿景和解决方案的价值时，定价谈判可以更加顺利，你可以避免任何不必要的争执。

那么，如何防止一开始就急于展示和讲述的冲动呢？答案在于解决方案销售，在这里你系统地诊断客户的需求，并与买家一起构建解决方案蓝图，当然，这个蓝图将偏向于你的解决方案。此外，采用这种方法，你将开发出一个解决方案销售的利益声明，这是一个关于解决方案特性、优势和利益的复合声明。这并不是说客户会在甚至不知道卖家提供的解决方案的情况下，跳到需求评估阶段。这是要区分早期“愿景”演示和定制“证明”演示。早期的愿景演示通常是预先编排的演示，用于阐述解决方案的能力，并帮助阐述解决方案特性，为买家构建解决方案愿景。当买家和卖家达到共享共同愿景的阶段时，那就是证明演示的时候了。证明演示可能会触发卖家组织的时资源和约束，因此只有在存在联合买家-卖家愿景的情况下，才应该采取这种做法，这可以通过解决方案销售的利益声明来展示。

解决式销售的利益声明告诉买家，销售人员的解决方案解决了通过买家和销售人员积极参与而形成的愿景。正如博斯沃斯所说，这个声明将表明潜在客户：谁将做什么，何时通过产品或服务来完成。因此，实际上，销售人员已经与买家确认了存在第三级需求，这意味着买家已经参与了解决方案愿景的开发。如果买家仍然处于第二级或更早的阶段，并且需求或痛苦尚未发展或处于潜伏状态，销售人员能做的最好的事情就是制定一个优势声明。优势声明只能列出销售人员眼中的利益，因为他们仍然不知道买家的详细痛苦点。这是优势声明与解决式销售方法产生的利益声明的根本区别。

与买家保持一致

解决式销售提供的一项基本技巧是确保销售人员与买家的战略保持一致。为了保持一致，销售人员必须能够理解买家的思维过程，以便能够预测他们的行为。

基于他多年的销售经验，迈克尔·博斯沃斯能够将买家经历的过程分解为一系列步骤。随着买家的需求从潜在需求转变为主动需求到解决方案愿景，博斯沃斯发现买家有四个主要关注点：

• 是否存在需求？

• 这是否是满足需求的正确解决方案？

• 解决方案的成本是多少？

• 与获取解决方案相关的风险是什么？

需求的存在启动了购买周期。需求必须出现在买家的脑海中，他们才能启动这个周期。然而，在这个阶段，销售人员通过给买家施加过多压力可能会对销售产生不利影响。为了避免这种情况，销售人员应该让买家承认他们的需求。一旦买家承认了他们的痛苦，他们就会进入下一个关注点——成本。

成本是大多数买家的一个关键关注点。然而，对于销售人员来说，认识到买家处于哪个阶段非常重要。如果在购买周期的早期阶段，销售人员最好避免所有成本讨论，因为他们还没有确定是否与他们的解决方案相关联的需求。当买家达到解决方案愿景并能够理解解决方案对他们组织的价值时，成本影响转变为价格关联，销售人员在这个讨论中处于更有利的地位。

在典型的市场中，买家有很多选择，从这些选择中挑选出正确的解决方案对买家来说是一个紧迫的问题。这就是价值证明的作用所在。那些做了功课的卖家已经准备好了解决方案的商业驱动因素，并且可以为客户进行投资回报率（ROI）分析，以证明解决方案的价值。卖家可以利用客户案例研究作为这一阶段的额外证据点。此外，对于有耐心的卖家来说，这是他们向客户展示全面证明产品演示的阶段，以突出其功能如何满足客户需求。

任何举措越重要，在购买周期的后期阶段，买家关注的潜在风险就越高。这包括没有选择最佳解决方案的感知风险以及获得最佳解决方案价格的风险。风险也可能扩展到解决方案支持——即服务提供商倒闭且无法支持运营中的解决方案的感知风险。卖家应使用包括风险管理学科在内的销售方法和技巧，及时识别、分析和应对感知风险。

在进一步分析这四个关注点时，博斯沃斯还发现，它们在购买周期中明显分为三个阶段：

• 第一阶段：需求确定

• 第二阶段：评估替代方案

• 第三阶段：风险评估

在以下图中，博斯沃斯描绘了四个买家关注点如何在三个购买周期阶段中转移。这个工具在解决方案销售中广泛使用，作为一种预测买家行为的方法，以便卖家能够与期望保持一致。

如前图所示，在购买周期的早期阶段，买家的主要关注点是需求和成本。随着买家向周期的尾声迈进，需求和解决方案已经确定，风险和价格成为更高关注点。

对于卖家来说，第一阶段是帮助客户确定他们的需求，但偏向于卖家的解决方案。在第二阶段，卖家通过产品展示、客户证据、ROI 分析等方式展示他们的解决方案满足客户需求。最后，在第三阶段，卖家寻求减轻买家感知到的任何和所有风险因素，并转向完成销售。通过充当“购买促进者”，卖家让买家感觉到他们拥有这个过程，同时确保他们的销售流程高效执行。

视觉处理——创建和再工程

有许多销售工具和技术可供销售员使用，以帮助买家在解决方案愿景的发展过程中进行引导。例如，Bosworth 提倡一种称为9-块视觉处理模型的技术，通过一系列逐渐建立的问题，销售员将买家从痛苦引导到愿景。如图所示，销售员从开放问题开始——这些开放式问题以使买家在整个过程中有控制感的方式设计。开放问题随后引导到控制问题，允许销售员深入特定主题领域。最后一组问题，即确认问题，导致对买家的需求和痛苦进行总结，确保销售员对情况有良好的理解。以下是对 Bosworth 的 9-块视觉处理模型的描述。

在9-块视觉处理模型中的开放、控制和确认问题以垂直方式标注。从左到右，该模型引导销售员进行诊断原因、探索影响和可视化能力。在左侧垂直块中，销售员使用其开放、控制和确认问题来诊断客户的潜在痛苦，并使他们承认痛苦。在中间垂直块中，销售员确定组织间的相互依赖关系及其对问题的影响。销售员能够确定哪些问题是更关键的，以及谁是需求方面的权力玩家或影响者。最后一个垂直块通过让买家承担解决其需求的责任（最好是偏向销售员的解决方案）来帮助销售员明确解决方案销售的好处和愿景。

虽然到目前为止我们的讨论大多关于在卖家与买家开始新合作时创造愿景，但重要的是要理解这些技术也适用于买家已经有一个初步愿景的情况。这在业务解决方案领域是一个关键点，因为解决方案提供商在提案请求（RFP）或信息请求（RFI）阶段介入变得越来越普遍。在这个阶段，客户可能已经与一个独立的第三方咨询团队合作，以提出他们的初步需求。他们也可能已经与竞争对手合作。显然，后一种情况并不理想，因为需求已经被设计成偏向竞争对手的解决方案，卖家需要做一些调查以确认在那个点上确实还是公平竞争。记住，如果买家只是通过分析预设数量的解决方案来向管理层展示他们已经完成了尽职调查的必要步骤，那么卖家可能最好不要浪费太多时间。但如果仍然是开放竞争，卖家仍然可以使用这里提供的技术，包括 9-方块模型，来“重新设计愿景”。

微软解决方案销售流程

在前面的章节中，我们看到了解决方案销售概念如何有效地使卖家与客户的需求保持一致。解决方案销售帮助解决方案提供商与买家建立信任关系，并促进卖家与买家之间的合作关系，共同制定一个对双方都有益的解决方案愿景。作为一个公司，微软自豪地确保客户的需求始终放在首位，并反过来帮助其庞大的合作伙伴生态系统也按照这个信条运营。为了实现这一使命，微软采用了解决方案销售方法，并在其内部和合作伙伴销售机制中进行了调整。这种方法被称为微软解决方案销售流程（MSSP），是本节的主题。

在 ERP 和 CRM 业务解决方案领域，MSSP 已经系统化，旨在帮助 Microsoft Dynamics 合作伙伴和微软内部团队在其销售周期中。这种方法为销售团队在每个销售周期的步骤中创造和交付价值提供了一个结构。销售团队得到了一个有效的过程来理解客户的需求和关键业务问题。该过程还促进了销售资源与客户的主题专家紧密合作，以确定和开发适合其需求的正确 Microsoft 解决方案愿景。

MSSP 将账户团队与客户在购买周期中的决策过程相一致，并强调通过微软解决方案驱动真实业务价值。它帮助销售团队评估他们在销售周期中的进展，并为销售和领导团队提供一种制定业务计划、推动资源分配和利用以及为有效决策制定可行的预测的手段。

下图显示了 MSSP 的各个阶段。图中还显示了 MSSP 与解决方案销售概念部分中描述的购买周期的映射，我们将在下一节中讨论。

MSSP 的第一阶段（0%）是潜在客户阶段。这一阶段的目标是将通过销售电话、邮件、互联网营销、会议或其他方式识别出的业务解决方案潜在客户转化为机会管理周期中的潜在客户，以激发对解决方案的兴趣。销售团队制定账户计划，并研究行业中的典型客户痛点。他们还收集客户成功案例作为该领域过去成功的证据。

下一个阶段（10%）是资格阶段，在这个阶段，销售团队验证潜在客户对解决方案有真实需求。在这个阶段，客户将确定他们的痛点，而销售团队也可能发现潜在的潜在需求。销售团队通过确定业务驱动因素，开始致力于发展共同愿景。这也是销售团队确保有业务发起人支持该计划，并寻求与有权力的发起人谈判获取访问权限的阶段。

潜在客户和资格阶段对应购买周期的第一阶段。销售团队的行为帮助客户挖掘对解决方案的需求。

开发是 MSSP 的下一个阶段（20%）。销售团队了解高级解决方案需求，并开展详细的需求收集会议来制定解决方案愿景。客户已经承认他们的业务痛点，并意识到不实施解决方案部署的后果。在这个阶段，销售团队还希望亲自与有权力的发起人会面。他们还希望评估涉及的竞争对手，以及了解客户的决策过程。

下一个销售阶段（40%）是解决方案。这个阶段的目标是制定一个符合客户需求的解决方案蓝图。销售团队已经将解决方案与业务需求联系起来，并确定了解决方案的价值测量所需的业务指标或 KPIs。还确定了解决方案所需的硬件和任何第三方软件需求，以及/或者对于基于云的部署，确定了将访问系统的用户类型。开发了一个高级成本，并与客户共享并得到认可。销售团队也开始计划在下一阶段可能预期的任何证明-解决方案演示。

开发和解决方案阶段对应于购买周期的第二阶段。在这些阶段，销售团队协助客户了解解决方案如何满足他们的需求。它还提到，客户团队可能将与竞争对手并行进行练习，以评估替代方案。

下一个 MSSP 阶段（60%）是证明。在这个阶段，销售团队通过详细的证明产品演示来减轻客户感知到的任何风险，展示解决方案满足要求。还进行了详细的解决方案价值主张分析，以帮助客户阐述与解决方案相关的预期节省以及他们何时可以收回投资的计划。在这个阶段，销售团队还向客户提供了初步的提案。

关闭是解决方案部署开始前的销售周期的最后一个阶段（80%）。这个阶段的目标是最终确定并得到所有合同的签字——这包括软件合同和解决方案交付的工作说明书（SOW）。值得注意的是，一些客户及其解决方案提供商可能选择从实施的前两个阶段，分析和设计，开始使用 SOW。然后，他们将在设计阶段结束时，完成剩余阶段的 SOW。解决方案实施计划被客户展示并得到认可。解决方案团队也开始为解决方案交付最终确定适当的资源。

证明和关闭阶段对应于购买周期的第三阶段。销售团队采取的措施有助于减轻客户识别出的任何风险，从而导致解决方案的最终批准。

MSSP 的最终阶段（100%）是部署阶段。这个阶段从销售团队向交付团队的知识转移开始。交付团队随后承担起解决方案的责任。销售团队对销售周期进行内部审查，并记录关键的学习经验以备未来机会使用。

摘要

在本章中，我们介绍了并讨论了解决方案销售的概念。解决方案销售通过建立信任关系和满足客户需求的解决方案的共同愿景，帮助销售者与买方保持一致。我们还介绍了我们可以采用的不同的技术，以实现解决方案销售，包括价值衡量、愿景处理和购买周期的各个阶段。最后，我们介绍了 MSSP，这是微软设计的解决方案销售流程，旨在帮助其合作伙伴和内部销售团队。

持续有新的理论宣扬解决方案销售的发展。它们当然值得调查，并形成你自己的观点，了解如何调整你的销售技巧。无论你的方法如何，我们都在销售商业解决方案，这些是运行公司业务的至关重要的系统。因此，销售者的责任是通过发现过程了解客户的需求，并将解决方案与他们的需求相匹配。这个发现过程的时间跨度当然会根据客户在评估和购买周期中的位置而变化。但这并不能免除我们遵循解决方案愿景过程的需求。CEO/CFO/COO/CIO 级别是最终的决策者——所以你不仅仅走进去告诉他们如何经营他们的业务。但他们确实期望你能提供你在其他类似业务中的经验最佳实践，以及适合他们业务的解决方案。

在下一章中，我们将解释解决方案销售是如何通过微软 Dynamics Sure Step 方法论实现的。

第三章：使用 Sure Step 进行解决方案构思

在前几章中，我们回顾了一般方法论概念，包括商业解决方案的全生命周期方法论的概念。简而言之，客户生命周期方法论始于解决方案发现阶段，接着是解决方案交付阶段，然后是运营阶段以及解决方案的任何未来升级。Microsoft Dynamics Sure Step 方法论是客户生命周期方法的一个优秀例子，并包括所有这些领域的指导。

在第二章《解决方案销售和推动尽职调查》中，我们深入探讨了解决方案发现阶段。我们讨论了在这一阶段解决方案提供商采用解决方案销售以及他们从这种系统方法中获得的好处。对于客户，我们看到了这一阶段如何帮助他们进行尽职调查，以及为什么这一阶段不仅对于选择符合其组织需求和愿景的解决方案至关重要，而且也为预期解决方案的高质量交付奠定了基础。

本章基于这些概念，深入探讨 Sure Step 方法论中被称为诊断阶段的解决方案发现阶段的具体内容。本章将涵盖以下主题：

• Sure Step 诊断阶段的概述

• 诊断阶段的解决方案销售指导如何引导销售员形成可重复的过程，包括对 Sure Step 决策加速器提供的详细分析

• 将解决方案销售流程应用于现有客户

• 诊断阶段如何支持客户的尽职调查过程

• CRM 在线解决方案的加速概念验证

• 对行业和跨行业解决方案的 Sure Step 诊断阶段指导

Sure Step 诊断阶段

Sure Step 诊断阶段是 Sure Step 方法的第一个阶段，构成了该方法的预实施阶段。诊断阶段的设计旨在实现以下双重目标：

• 为销售员提供一个一致且可重复的过程，以加速并关闭他们的销售周期

• 为客户提供全面的过程，帮助他们验证和选择满足其需求的正确解决方案

除了之前讨论的之外，彻底执行诊断阶段中规定的步骤还提供了额外的益处。遵循这一阶段的重点步骤和指导确保双方对业务需求和解决方案愿景有一个共同的理解，以满足需求，从而为预期解决方案的高质量交付奠定基础。

Sure Step 诊断阶段流程包括活动、决策加速器产品和服务。在 Sure Step 中，活动是流程中的特定行动或步骤。活动可能产生可交付成果作为步骤的输出，或者它可能是导致后续结果的过程中的规定步骤。相比之下，决策加速器（DA）产品本身就是一个小型项目，每个 DA 产品可能包括多个服务，每个服务都需要多个行动来实现产品声明的目标。Sure Step 有以下三个决策加速器产品：

• 对新 Dynamics 客户进行诊断，包括需求和服务流程审查

• 通过利用 CRM 在线服务的加速概念验证对新 Dynamics CRM 客户进行诊断

• 从升级评估开始对现有 Dynamics 客户进行诊断

我们将在以下章节中详细介绍这些 DA 产品。

记住 Sure Step 的目的是帮助卖方和客户选择正确的解决方案非常重要，因此，遵循这一理念，Sure Step 并不旨在成为卖方的潜在客户生成工具。Sure Step 从微软解决方案销售流程的潜在客户阶段开始，这意味着它不会涉及营销、活动和其他旨在提高解决方案知名度或为潜在客户细分市场进行画像的活动。Sure Step 在机会管理阶段发挥作用，因此它是在确定潜在客户之后开始的，并为协助和验证客户的解决方案选择提供指导，同时为卖方提供执行该解决方案销售的重复性流程。

决策加速器（DA）产品的概念

决策加速器产品是一组旨在吸引客户并在短时间内向他们提供所需信息的具体行动，以便客户可以继续进行其决策过程的下一阶段。对于卖方来说，决策加速器产品旨在帮助他们加速或缩短销售周期，以实现成功的交易。对于客户来说，这些产品是快速互动的，旨在帮助他们寻找他们需要的信息，以便进入决策过程的下一阶段。

一个 DA 产品本身可能包括多个服务，每个服务都包括多个构成其自身流程或一系列步骤的行动。DA 产品可能从启动或小型互动的启动开始，通过规定的行动逐步推进，以产生声明中的可交付成果或可交付成果，以实现预期的结果。DA 产品通常以向客户展示结果和关闭小型项目结束。

每个 DA 都有特定的目的，并包含多个服务，旨在为客户提供和解决方案提供商提供灵活性。根据客户的需求，解决方案提供商的销售团队能够选择合适的诊断 DA 服务组合。

新 Dynamics 客户的诊断

通过与微软解决方案销售流程（MSSP）的协同，诊断阶段天生支持解决方案提供商的销售周期，提供指导性和活动，引导销售员通过一个规定的销售周期。您可能还记得，在第二章中介绍的 MSSP，即解决方案销售与推动尽职调查，是为了使微软的内部和合作伙伴销售机制得以实现。正如我们讨论的，MSSP 基于解决方案销售概念，这是一种帮助解决方案提供商及其买家之间建立信任关系的哲学，同时促进双方之间建立合作关系，共同制定一个对双方都有益的解决方案愿景。

以下图表展示了 Sure Step 诊断阶段流程以及与 MSSP（托管服务提供商）的协同。图表中具体展示了如何支持潜在客户或新客户的销售周期。Sure Step 诊断阶段同样为现有客户提供了类似的流程，我们将在后续章节中进行讨论。潜在客户的决策加速器包括六个服务，我们将在本节中进行介绍。接下来几节我们将讨论 CRM Online 潜在客户和现有客户的 DA（决策加速器）流程。

正如 MSSP 一样，Sure Step 诊断阶段被分解为销售周期的七个阶段。对于销售员来说，这些阶段对应着销售完成的概率。活动和决策加速器产品随后与这些阶段对齐，以便加速销售周期，使其尽快完成。此过程最后的阶段是引入解决方案交付，即实施阶段和相应的 Sure Step 活动。

• 潜在客户 0%至合格 10%：

  • 解决方案概述活动

• 开发 20%：

  • 需求与流程审查决策加速器服务

• 解决方案 40%：

  • 适配差距与解决方案蓝图决策加速器服务

  • 架构评估决策加速器服务

  • 范围评估决策加速器服务

• 证明 60%：

  • 概念验证决策加速器服务

  • 业务案例决策加速器服务

  • 提案生成活动

• 关闭 80%：

  • 最终许可与服务协议活动

• 部署 100%：

  • 项目动员活动

开始发现过程

Sure Step 诊断阶段始于解决方案概述活动，以用于发现或诊断准备。在本节中，Sure Step 提供了关于 Microsoft Dynamics ERP 和 CRM 解决方案的功能信息，以及针对选定行业及其相应子行业的解决方案指南。

在潜在客户 0%阶段进行的解决方案概述活动旨在为销售团队提供客户信息。内容可以用作销售员与潜在客户面对面会议的准备，作为与客户电话交谈的脚本的一部分，或作为可能为未来会议奠定基础的客户简介或介绍信。Sure Step 还包括指向相关网站的链接，这些网站将提供最新的解决方案材料，包括 Microsoft Dynamics 网站。

Microsoft Dynamics 生命周期服务工具与 Sure Step 的对齐

Microsoft Dynamics 研发生命周期服务工具正在开发和发布一种新的工具类型，以帮助客户和解决方案提供商。以下图表显示了在解决方案生命周期中提供的工具概述。您还可以找到工具与 Sure Step 阶段/项目类型的映射，以了解生命周期服务工具将在未来的 Sure Step 版本中如何被利用。随着这些工具的开发，Sure Step 将继续提供关键链接到这些工具，以及在特定活动/产品中可以调用的说明。在后续章节中，我们将讨论这些工具在 Sure Step 诊断阶段的应用。

如前图所示，解决方案销售团队可以在解决方案概述活动中利用 Microsoft Dynamics 信息源工具。信息源是销售团队响应客户关于信息请求（RFI）或提案请求（RFP）的宝贵工具。该工具提供了从数百份 RFP 中精选的问题和答案，旨在提高销售团队的效率和响应率。

行业定位指南和解决方案是该活动涵盖的另一个重要领域。在 Sure Step 2010 版本中，该方法被扩展到涵盖 Microsoft Dynamics 针对部分行业和跨行业解决方案。行业和跨行业解决方案的议题将在后续章节中更详细地介绍。

当销售团队向合格 10%阶段迈进时，他们需要评估客户组织是否已经定义了选择流程并指派资源来评估解决方案和替代方案，以及确定客户是否已经为近期获取解决方案分配了高级预算。他们还希望确保客户的评估是公平的，这意味着它没有偏向于特定的竞争对手，他们只是按照公司标准或规则走形式。当资格得到确认后，销售团队可以开始利用决策加速器服务来帮助客户展望他们的未来解决方案。

在接下来的部分中，我们将从销售组织的角度讨论决策加速器服务的使用。在随后的部分中，我们将提供客户对其使用的观点。

展望未来状态的第一步

Sure Step 中的第一个决策加速器服务是需求与流程审查。这项服务旨在帮助客户确定其未来状态的业务需求，以及可视化与其相关组织功能的待执行流程。

该决策加速器方案的第一部分允许销售员使用针对客户正在探索的 ERP 或 CRM 解决方案的详细、角色定制问卷模板来确定客户的需求。这些模板中问题的角色定制特性使得销售员能够针对组织中特定群体的功能需求进行回应，例如会计经理、市场营销人员、库存经理、产品规划师或生产经理。这是解决方案销售的关键推动因素，因为销售员能够以与客户产生共鸣的方式与他们互动。而不是直接向客户介绍产品特性和功能，并可能因此使他们感到厌烦，销售员有能力与客户进行有意义的讨论，讨论他们的日常职能和岗位职责，从而挖掘客户的痛点和其他有价值的信息，例如当前系统的限制和影响其性能的因素。

一个优秀的解决方案销售员和/或服务与销售执行人员应该能够利用这些问题与客户建立关系。根据潜在合作的规模和范围，销售团队还可能涉及解决方案架构师、高级顾问或项目经理参与这些讨论，为客户带来现实生活中的信誉和经验。通过有系统地处理这些问题，销售员记录下这些客户会议的发现。这些发现成为解决方案业务需求的基础。

以下是从 Sure Step 中截取的角色定制问卷内容的屏幕截图，适用于 Microsoft Dynamics AX。AX 问卷包含问题，旨在与组织的行政人员，如总裁或 CEO，以及个人角色，如会计经理、应付账款协调员和物料经理等进行对话。

虽然问卷有助于本服务的要求部分，但此 DA 服务还提供对特定业务流程图的访问，以实现本服务的流程目标。业务流程图构成了使用解决方案功能时的标准流程，并且可以作为设想客户组织未来状态工作流程的起点。值得注意的是，业务流程图练习在实施阶段也会被调用，始于分析阶段。

Sure Step 为每个 Microsoft Dynamics ERP 和 CRM 解决方案都包含几个流程图。这一直是 Sure Step 用户群中最广泛使用的模板集之一。在即将发布的版本中，用户可以期待这个区域将进行翻新，从 AX 流程图开始。即将推出的新生命周期服务工具之一是业务流程建模器（BPM）。BPM 工具是流程图的一个优秀进化——它与行业最佳实践保持一致，包括美国生产力与质量中心（APQC），为用户提供一个共同的框架和分类法，以便将他们自己的组织功能流程与之相关联。正如 APQC 所描述的，他们的“流程分类框架（PCF）”是一个业务流程分类法，允许组织客观地跟踪和比较其内部和外部与任何行业的组织绩效。它还构成了与业务流程相关的各种项目的基石。APQC 还解释了 PCF 的开发原因及其组织效益。“最初设想为辅助绩效改进项目的工具，该框架已经发展成为今天广泛分类法。组织可以使用 PCF 的通用术语来命名、组织和映射他们的流程。”

当前的 BPM 工具包含几个跨职能流程，未来还将有更多加入。当 BPM 工具扩展到包括所有 AX 功能区域时，它将包含 Sure Step 中的现有 AX 流程图。在那个阶段，Sure Step 流程图将被移除，并替换为指向 BPM 工具的指针。以下是 BPM 工具的屏幕截图：

使用 BPM 工具，解决方案提供商可以与客户合作，了解他们即将实施的解决方案需求和流程。此外，他们还可以确定需求与标准 Dynamics AX 解决方案之间的 Fit Gap。预计 BPM 工具也将与另一个研发工具 RapidStart 在不久的将来保持一致。有了这种同步，客户和解决方案交付团队将获得使用在 Fit Gap 练习中被认为是标准解决方案匹配的需求来生成实施起始设置的额外好处。

BPM 工具提供的另一个好处是将行业 关键绩效指标 (KPIs) 与相应的行业业务流程联系起来。我们将在关于从解决方案中估算投资回报率的章节中讨论 KPIs 的使用和重要性。

从服务提供商的角度来看，他们在这次需求分析中正在帮助客户。虽然 Sure Step 为此提供的服务中包括的模板——包括问卷和流程图——是按照相应的 Microsoft Dynamics 产品独特设计的，但客户组织将此输出用作其他解决方案评估的基础并不困难。在这种情况下，客户也有可能决定选择替代 Microsoft Dynamics 的解决方案。考虑到这一点，服务提供商期望获得公平的补偿是可以理解的——服务提供商正在提供他们组织中的经验丰富的资源，以帮助客户展望其组织的未来状态，并记录满足这一愿景的解决方案需求。在严格意义上，提供的服务类似于商业咨询，即使存在对特定解决方案的偏见。

因此，服务提供商可以合法地将他们的服务定位为客户补偿。当然，服务提供商也可以选择将这项合作视为一项商业投资，并提供全部或部分服务作为无偿服务；然而，在他们将其视为公平竞争并且他们认为他们与竞争对手一样有机会赢得客户业务的情况下，这样做才是他们最好的利益所在。

还应指出，需求与流程审查并不总是必须执行的，有些情况下，例如当客户已经独立进行了全面的需求分析并将它们记录在 RFP 中时，就不需要执行。然而，如果客户已经制定了 RFP，那么可能还有其他竞争对手或供应商帮助客户制定需求，在这种情况下，您可能至少需要在某种程度上执行需求与流程审查 DA。这一讨论在“决策加速器的其他使用场景”部分进行了详细阐述。

确定合适的解决方案

在确定并记录了新解决方案的需求之后，流程的下一步是确定所提出的解决方案如何满足这些需求以及它如何与客户组织的愿景相一致。Sure Step Fit Gap 和解决方案蓝图决策加速器服务已被“设计”来满足这一目的。这也很好地符合 MSSP 的一个主要原则：在使自己与众不同之前，先使自己平等。

Fit Gap 分析是客户和销售团队在解决方案评估阶段应进行的重要练习。分析的前提是逐一审查为新解决方案定义的每个需求，并确定它们是否可以通过所提出的解决方案得到满足。为此，第一步包括销售团队将之前练习中收集到的业务需求转化为解决方案需求。正如前文所述，销售团队也可能在生成 RFP 或报价请求（RFQ）之后介入，在这种情况下，能够将一般业务需求转化为具体解决方案需求变得更加重要。

功能性解决方案架构师和/或经验丰富的功能性顾问通常参与将更大的业务需求分解为更小的解决方案需求。一个例子可能是当客户表明，对他们的销售和运营计划（S&OP）流程进行彻底改革是他们的一项业务需求。S&OP 涉及许多领域，包括销售计划和预测以及供应和库存计划等。虽然这是一个极端的例子，但它只是表明，业务需求可能是一个更大的目标，但解决方案需求需要更加细分，以确保解决方案交付团队能够真正地将需求程度映射到解决方案上。

如果一个需求可以通过现成的解决方案功能或通过配置标准解决方案来实现，则该需求被认为与所提出的解决方案相“匹配”。也有可能客户组织的当前流程或工作流程的微小变化会导致与解决方案的匹配。然而，如果基础解决方案需要定制，换句话说，需要编写一些代码来实现需求，那么该需求被认为与所提出的解决方案存在“差距”。

理解构成解决方案的内容也同样重要。通常，拟合度分析是在基础微软 Dynamics 解决方案的基础上进行的。然而，如果预期微软 Dynamics 解决方案的附加独立软件供应商（ISV）解决方案将成为整体解决方案的一部分，那么“解决方案”一词应包括基础微软 Dynamics 解决方案以及相应的 ISV 解决方案。因此，如果一个需求可以通过组合解决方案满足，而不需要任何额外的定制代码组件，那么该需求将被视为符合。

符合整体解决方案的需求数量占总需求数量的百分比，表示为建议解决方案的拟合度。

注意

建议解决方案的拟合度（以百分比表示）= 符合建议解决方案的需求数量 / 新解决方案的总需求数量。

其中，符合建议解决方案的需求数量 = 由解决方案的标准功能满足的需求 + 由解决方案的配置满足的需求 + 由客户组织中的工作流程/流程变更满足的需求。

关于通过简单改变客户的业务流程或工作流程以满足特定要求的重要性不容忽视。在实践中，这种选择往往没有被考虑；相反，你可以看到服务提供商提出昂贵的定制设计或附加解决方案作为替代方案。但第一步始终应该是检查客户组织的当前工作流程。我们需要找到答案，例如：“他们目前是否因为现有系统的限制或可能是因为过去某个时候设置的创造性解决方案（现在不再必要）而正在执行这些步骤？”以及“是否存在其他任何微小的原因，简单的流程变动可能导致公司使用解决方案的标准功能来实现他们的目标？”如果这些问题的答案是肯定的，那么双方考虑将工作流程变更作为替代方案是更可取的，这不仅从降低解决方案交付成本的角度来看，而且从长期角度来看——客户能够使用解决方案的标准功能越多，他们升级到未来版本就越容易。从长远来看，这会导致总拥有成本（TCO）的降低，从而为客户提出的解决方案带来更高的价值。如果卖家真正在实践解决方案销售理念，他们也会努力降低客户的 TCO，而不是通过定制化来扩大解决方案的范围。此外，服务提供商应始终努力设计最简单的解决方案来满足客户的需求，从而降低所提解决方案的整体风险状况。这也应该是卖家在可能的情况下避免复杂定制的一个考虑点。

回到适配性分析，该练习的输出是确定所提解决方案对客户需求的适配度。然而，解决方案应该具有多少适配度值才能被接受是一个具体问题。一些组织可能需要至少 75%的适配度来实现较低的 TCO 目标。其他组织可能由于业务的具体性质，无法使用现成功能来满足需求，可能会评估是否应该开发自己的应用程序，或者从现有的代码库开始，并扩展以满足其需求，它们可能对适配度值的要求较低。

下面的屏幕截图显示了 Sure Step 对 Microsoft Dynamics CRM 项目进行适配性分析的一个示例输出。这只是包含五个需求映射到类别的简单截图，但它展示了客户对 CRM 解决方案的适配度图示。

如前文所述，新的生命周期服务将有助于在未来增强这一领域。对于适配性差距练习，解决方案提供商在未来可以利用 BPM 工具与客户合作，了解他们的待实施解决方案需求和流程，然后确定需求与标准 Dynamics AX 解决方案之间的适配性差距。

在完成适配性差距分析后，适配性差距和解决方案蓝图决策加速服务的第二部分是开发解决方案蓝图。解决方案蓝图是一份文档，用于传达服务提供商对其提出的解决方案的概念设计，以满足客户的需求。该文档应包括销售方对客户业务需求的理解，以及整体解决方案，包括任何附加解决方案、所需定制以及被认为满足客户未来状态愿景所必需的集成组件。

确定基础设施影响

购买打包应用作为其业务解决方案的客户，对三个成本视角感兴趣——软件成本（以及任何相关的维护成本）、解决方案交付的服务或实施成本，以及硬件或基础设施成本。

Sure Step 架构评估决策加速服务主要处理业务解决方案获取成本的第三部分。值得注意的是，无论解决方案是在本地部署，即物理位于客户的某个地点，还是由第三方提供商托管，或者是否为在线解决方案，都会产生基础设施成本。对于本地、托管或在线解决方案，需求显然会有所不同；例如，前者可能需要更多的硬件或服务器组件，而后两者可能需要更高的带宽和延迟。

该服务将在 Sure Step 的未来版本中通过参考新的生命周期服务工具得到增强，特别是基础设施规模估算器工具。

在理解客户需求和提出的解决方案蓝图以满足客户需求的基础上，销售团队能够在本练习中开发解决方案的概念架构。这项通常由技术解决方案架构师或技术应用顾问执行的练习，包括制定高级硬件和基础设施计划。除了上一活动中的业务需求和解决方案蓝图外，本活动考虑的其他输入还包括预期的交易量、关键用户场景以及任何其他基准测试活动。

本练习产生的基础设施和硬件推荐由客户用于获取支持其业务解决方案的基础设施估算。

架构评估 DA 服务还提供更深入的服务，以帮助客户在其他领域，如性能预测和基准测试、高可用性和灾难恢复规划。客户可能在业务的一个特定领域有担忧，该领域产生高使用率或解决方案的流量模式。或者由于解决方案的关键任务性质，他们可能需要基础设施计划包括故障转移机制，以最小化或消除停机时间。客户还可能希望计划包括灾难恢复，以确保他们的数据得到适当的保护，并在发生故障时可以恢复。对于这种情况，可以进行像概念验证基准测试这样的技术深入研究服务，这些服务由非常资深和经验丰富的技术资源执行，可以为客户提供所需的答案，并消除对系统操作的任何担忧。这些服务通常是昂贵且耗时的，可能需要特定的实验室设置等。这些服务通常也由客户支付。

估算交付成本、方法、计划和角色

Sure Step 范围评估决策加速器服务处理上一节中提到的业务解决方案获取成本的第二个组成部分——解决方案交付的服务或实施成本。但这项服务提供的不仅仅是成本；它还提供了确定整体解决方案交付方法的决策点，从而制定了高级时间表和交付团队结构。

执行范围评估 DA 服务的第一步是确定整体解决方案的部署方法。在这个练习中，解决方案交付团队和客户一起确定解决方案是否可以以更小、更易于管理的版本发布，或者是否希望在解决方案上线时立即实现所有功能。将解决方案分多个版本发布被称为解决方案交付的分阶段方法；在这里，每个版本中只启用选定的解决方案功能，每个版本都是在前一个版本的基础上构建的。分阶段方法的替代方案是在单个版本中交付完整解决方案，这通常被称为解决方案交付的大爆炸方法。读者需要注意的一个关键点是：不要将分阶段方法与瀑布式解决方案交付方法的阶段混淆。瀑布式阶段将整体项目或发布分解成更小的部分，而分阶段方法是将整体合作分解成多个项目或发布的技巧。

项目范围越大，或解决方案在客户组织中的影响范围越广，分阶段方法相对于大爆炸方法就越受欢迎。以下是一些支持性原因：

• 分阶段方法使客户组织能够更早地开始使用解决方案，从而促进系统更平滑的采用。由于每个发布的范围有限，交付团队可以更快地将该部分解决方案推送到生产，从而使用户能够比大爆炸方法更早地开始使用系统。

• 由于范围有限，解决方案测试也可能更容易管理，这意味着对解决方案的测试可能更加集中，并且受影响的流程更少。

• 客户还可以通过选择对他们重要但可能更容易或更快用新解决方案解决的问题，更早地开始从解决方案中受益。

• 对于复杂解决方案，客户还可以通过早期采用系统获得对项目的宝贵支持，从而为交付团队带来快速胜利，这在销售/咨询术语中通常被称为“摘取低垂的果实”。

• 从整体风险管理角度来看，分阶段方法通常被视为一种风险较低的策略，原因如上所述。

当然，分阶段的方法并不总是最佳选择。有时，客户组织可能需要在开始使用系统之前启用所有功能。在这种情况下，大爆炸方法可能是唯一的替代方案。大爆炸方法也有其他优点：

• 如果相同的用户群将使用新增功能，他们不需要在每次发布时都重新培训。

• 解决方案测试将涵盖所有可能的场景，因此客户组织可以最终确定整体解决方案是否满足他们的需求。这也有可能降低整体测试成本。在分阶段方法中，您首先测试第一版的情况，然后在测试第二版时可能需要与其它情况一起重新测试这些场景。

• 在某些情况下，如果正在使用的系统的一部分可能需要将外部源临时连接到新系统，则不需要创建废弃的界面或集成代码。

多站点部署的分阶段方法和分阶段选项

分阶段交付方法还有一个方面——其在向多个站点交付解决方案中的重要性及其使用。具有多个分支机构或站点的大型组织可以以两种方式来描述：

• 在多个国家/地区设有分支机构的组织，每个分支机构都拥有高比例相似的业务模式和流程

• 在多个国家/地区设有站点且每个站点具有独立功能的组织，例如企业、销售、研发和制造

当具有类似流程的组织考虑其业务解决方案的部署时，他们会在其各个站点寻找一个核心解决方案。这种方法在 Sure Step 的企业项目类型中有所描述，它使用核心构建来开发所有站点的通用解决方案，并添加一个站点构建来满足特定站点的需求。这两种构建类型随后合并以部署到相应的站点。另一方面，对于具有独特需求的站点的解决方案部署，每个站点都需要自己的交付方法。以下截图显示了这两种选项：

无论整体解决方案是使用分阶段还是大爆炸方法来部署，客户和解决方案交付团队还需要为单个发布选择交付方法。

解决方案交付有两种不同的方法——瀑布和敏捷，具体描述如下：

• 瀑布： 这是一个顺序过程，描述了从一阶段到另一阶段的线性活动流程，最终以解决方案被提升到生产状态并投入运营结束。

• 敏捷： 这是一个迭代式解决方案开发方法，它促进了拥有和指定解决方案需求的资源与负责解决方案开发和部署的资源之间的协作过程。

就像整体分阶段或大爆炸方法一样，在解决方案交付的两种方法中，没有对错之分；这仅仅是一个组织偏好的问题。一些组织偏好瀑布方法的架构，因为它清晰地分解了每个阶段的活动，从而导致了解决方案的部署。而另一些组织则倾向于在开发活动中让解决方案的需求演变，这是敏捷方法的一个特点。Microsoft Dynamics Sure Step 方法论通过提供标准、企业、快速和敏捷的工作流程（以及为现有客户部署的升级工作流程）来支持这两种方法。我们将在专注于解决方案交付的后续章节中更详细地介绍这一方面。

在执行范围评估决策加速服务时，销售和解决方案交付团队的下一步是与客户合作，使用解决方案蓝图作为输入来了解他们的解决方案优先级。为此，交付团队需要识别固有的限制以及项目中的任何施加的限制。固有的限制通常由系统施加；例如，一个系统需要一定的逻辑配置顺序，例如从账户表开始，然后移动到 ERP 系统的一般账簿。另一方面，施加的限制通常是外部限制；例如，客户可能拥有需要续订的特定许可软件，而客户不希望续订，并且更希望在新解决方案的相应模块在第三方软件的许可证到期之前启用。了解这些限制使解决方案交付团队能够制定出满足客户对新解决方案目标的时间表。

执行范围评估决策加速服务的下一步是确定解决方案部署活动所需的努力。这包括解决方案的设置、配置和开发、环境设置以及用户培训需求等方面。许多服务提供商开发成本计算电子表格和数据库来支持他们在这些任务中，通常根据他们在类似过去项目中的经验来填写这些电子表格。其他组织使用包括启用特定功能的基础值的估算工具。这些基础值可能来自过去的历史，但通常构成多个顾问在多个项目中的经验平均值。因此，这些估算工具为估算解决方案交付努力提供了一个一致、可重复的框架。当然，估算工具也可能提供一种方法来覆盖给定的估计，例如，在风险较高的合作中添加可能需要的提升。

带着关于整体解决方案实施方法、单个发布交付方法、固有和施加的限制以及解决方案部署活动所需努力的信息，销售和交付团队可以在下一步确定解决方案的实施时间表。

降低风险感知

虽然 Sure Step 需求与流程审查、适配差距和解决方案蓝图、架构评估以及范围评估决策加速服务旨在帮助客户构想其未来的解决方案以及交付该解决方案的成本，但概念验证 DA 服务提供的是缓解客户在解决方案特定领域的任何潜在担忧，同时继续以解决方案构想的主题进行。

概念验证决策加速服务需要利用解决方案交付资源来设置、配置和定制解决方案以满足客户特定需求的一个子集。由于客户尚未购买软件许可证，交付团队通常会构建自己的演示环境来执行此解决方案设置，例如在虚拟 PC（VPC）程序中虚拟化标准 PC 及其硬件。在完成解决方案设置后，交付团队将在会议室环境中设置解决方案演示，客户的业务和技术决策者将能够预览和批评解决方案功能。

当客户在经过需求审查和流程审查、差距分析和解决方案蓝图、架构评估和范围评估 DA 服务之后，对 Microsoft Dynamics 解决方案相当满意，但在某些特定领域仍存在疑虑时，概念验证 DA 是一项适当的服务。这里有两个关键点。第一个是客户相当确信拟议的 Microsoft Dynamics 解决方案将满足他们的需求，第二个是销售团队确定了客户寻求额外证据点的特定领域。这些是需要记住的重要观点，因为概念验证练习应该是一个时间有限、范围有限的参与活动，帮助客户在系统采购前做出最终决定。从服务提供商的角度来看，如果概念验证 DA 服务定位为无偿参与，那么这些点变得至关重要，因为可能本来在账单客户参与中工作的资源被要求为潜在客户的需求工作。

如果客户决定继续推进拟议的解决方案，概念验证 DA 练习的输出也可以成为起点。如果交付团队和客户团队的事先尽职调查包括系统配置和/或编写满足特定要求的自定义代码，这些应该被贯彻到系统的实施中。这是另一个方面，拥有客户生命周期方法，如 Sure Step，允许团队在销售周期中构建前一个阶段的工作。

关于概念验证参与的一个另一点是，在完成这项练习之后，项目范围或解决方案愿景可能会发生变化。客户团队可能会想到额外的应用，或者要求不同的解决方案功能集以满足他们的需求。在这些情况下，销售团队需要回过头来更新解决方案蓝图和相应的交付估计，甚至可能需要重新设计拟议的系统架构。

估算投资回报

Sure Step 业务案例决策加速服务旨在为解决方案提供投资回报率（ROI）分析，帮助客户高管了解解决方案的价值主张并证明他们的投资是合理的。业务案例 DA 服务确定了给定投资的量化商业价值以及他们新系统的总拥有成本（TCO）。

回到第二章的讨论，解决方案销售和推动尽职调查，确定解决方案对客户组织的影响，并阐述其价值，对于客户和销售团队来说是一项非常重要的活动。当解决方案具有价值时，推动高管支持变得更加容易，这对于项目至关重要。此外，明确的价值预测将有助于在实施解决方案的过程中克服不可避免的挑战时激励团队。在某些情况下，公司可能不愿意分享某些财务信息，但鉴于他们即将在资金、资源和时间上的投资，他们进行这项练习是合理的，这样他们可以清楚地了解新系统可能带来的组织收益。

在业务案例 DA 练习中，客户和服务提供商团队共同工作，以确定与所提议解决方案相关的直接和间接效益。直接效益对预算或成本有可衡量的影响。新系统产生的直接效益示例包括：

• 库存周转率提高，导致库存成本降低

• 完成任务所需人员减少

• 在特定时期内通过系统处理的订单增加

• 由于错误发货导致的回报减少

相反，间接效益不易量化。可能需要观察和预测估计的影响。尽管如此，这些因素仍然很重要。新系统产生的间接效益示例包括：

• 通过更好的可见性获得的生产力提升

• 降低行政开销成本

• 降低沟通成本

• 客户保留率提高

业务案例 DA 服务分析了之前讨论的效益与获取解决方案相关的总成本之间的关系，使客户能够了解他们新系统的总拥有成本（TCO）。TCO 成本要素包括解决方案获取成本、运营成本以及任何额外的长期成本。

如前所述，解决方案获取包括三个组成部分——软件成本（以及任何相关的维护成本）、解决方案交付的服务或实施成本，以及硬件或基础设施成本。软件成本直接来自许可协议。范围评估 DA 服务产生服务交付的成本估计，而架构评估 DA 服务产生确定硬件或基础设施成本的输入。

运营成本可能包括客户组织员工培训和再培训的成本；参与解决方案测试的客户资源的成本；以及其他成本，如保险、电费和其他物理基础设施需求。另一方面，长期成本可能包括定期解决方案审查的成本以及解决方案升级和扩展的成本。

利益和成本是确定解决方案投资回报率的基础。Sure Step 提供了一个由独立分析公司Nucleus Research开发的有效的 ROI 计算工具。该标准化工具提供了一种系统地捕捉利益和成本的方法，从而允许团队预测预期的 ROI、回收期和/或净现值（NPV）。为 ERP 和 CRM 解决方案的分析提供了单独的 ROI 工具。以下截图显示了 Nucleus Research 为 Microsoft Dynamics AX 提供的 ROI 工具的报告部分：

服务提供商执行业务案例 DA 服务的先前步骤，以开发财务结果并报告。财务结果包括对风险评估领域的见解，如资本回收和潜在差异。然后，根据需要将这些结果提供给客户的高级管理人员。

除了之前提到的财务分析外，业务案例 DA 还有助于组织确定新解决方案的关键绩效指标（KPI）和满意度条件（COS）。建立 KPI 和 COS 是确保该倡议长期健康的重要练习，因为它们提供了一种跟踪持续进展的手段，最终确定解决方案的成功（或失败）。与建立 KPI 的同时，还需要确定这些 KPI 的基线指标，这将帮助团队了解他们在合作开始时的位置以及他们通过新解决方案所取得的成就。

正如我们在前面的章节中讨论的那样，新的 BPM 工具基于 APQC 的过程分类框架，并且客户和解决方案提供商也可以利用它来确定他们解决方案的适当行业 KPI。正如 APQC 所描述的，“PCF 也被用作 APQC 开放标准基准的基础，组织可以将其绩效与其他组织的绩效进行比较。APQC 根据 PCF 中列举和定义的过程跟踪响应。”

制定项目章程和提案

确步提案生成活动是在执行客户参与的相关决策加速器服务之后的下一步。提案生成活动的一个关键输出是项目章程，它是总结从决策加速器服务以及客户的前期诊断准备活动中得出的结论的载体。项目章程包括高级项目范围、解决方案交付方法、工作流程、时间表、活动和依赖关系。它还包括将参与解决方案交付的角色，包括服务提供商和客户团队，以及他们相应的技能要求。

项目章程的开发始于总结高级范围。为此，销售团队将审查需求与流程审查决策加速器服务以及适配差距和解决方案蓝图 DA 服务的输出。基于在这些练习中确定、定义和记录的需求，项目章程将确定范围，包括新解决方案的业务需求和功能需求以及待执行的业务流程。

项目章程还将包括非功能性需求以及任何其他技术需求，例如与外部系统的集成和接口。任何性能需求，如系统响应、延迟、系统停机时间和故障转移要求，也将记录在提案中。为此，团队将总结架构评估 DA 服务的发现。

项目章程还应讨论在范围评估 DA 服务中确定的解决方案交付方法。这包括决定我们是否将进行多次发布或单次发布。它还涉及决定每个发布的合适实施方法——瀑布或敏捷。

项目章程应附有高级项目计划。虽然整体实施方法将在项目章程中涵盖，但解决方案交付的高级时间表、活动和依赖关系将在项目计划中记录。

项目章程中涵盖的另一个方面是对提议的角色和职责以及项目团队技能和要求的评估。这一评估的起点可以是范围评估 DA 活动的输出。然后，项目计划应指定下一级别的细节，包括指明哪些活动和何时相应的角色将参与实施。对于涉及多个发布的较长期活动，项目章程还应定义整体的项目治理模型。治理模型应明确阐述每个发布的项目管理及关键角色。该模型还应定义在项目层面上升起沟通和问题的结构，例如成立一个指导委员会，该委员会将包括来自客户组织各层面的关键业务利益相关者以及交付团队的关键利益相关者。

项目章程还可以包括项目沟通计划和日程安排，包括从个人发布资源团队到指导委员会的项目状态的时间表和信息结构。

对于参与活动所确定的假设、范围界定和风险是项目章程中应突出的关键区域。列出任何进入解决方案定义的假设，以及明显超出参与范围的要求，以避免任何误解或错误理解，这一点非常重要。项目章程还应记录已识别的风险，并尝试为每个风险识别和概述缓解策略。任何客户拥有的且超出直接项目控制范围的依赖项也应明确突出。

建议生成活动通常在微软解决方案销售流程的验证阶段执行。如果概念验证和/或业务案例练习作为参与活动的一部分执行，则建议生成通常是下一步。销售团队在这个活动中试图影响客户的解决方案决策，并努力获得客户的口头批准。在收到其建议的口头批准后，销售团队可以继续进行预算估算的开发和制作工作说明书。

销售周期结束

确定步骤最终许可和服务协议活动建立在提案生成活动之上，以正式化客户与销售方之间的协议。销售方可能是多个实体，或者在某些情况下，是一个单一实体。从软件许可和持续软件维护的角度来看，这可能包括微软、微软合作伙伴和独立软件供应商，为微软 Dynamics 核心解决方案提供附加解决方案。同样，它也可能包括服务交付方面的多个当事人，包括微软认证的实施合作伙伴和微软咨询服务（MCS）。

新的生命周期服务工具可以从许可的角度用于微软 Dynamics AX 解决方案。许可证大小估算工具帮助解决方案提供商和客户确定服务器和用户许可，包括允许多少用户以及允许哪些类型的用户访问系统。

从服务提供商的角度来看，在这个练习中的一个关键步骤是为客户提供服务交付的预算估算。预算估算本质上总结了范围评估决策加速服务的成果，并包括服务提供商和客户之间可能提出的任何费率折扣。如果客户在整个诊断阶段活动中积极参与，预算估算不应让他们感到意外。然而，服务提供商可以预期在费率讨论和时间框架方面会有一定程度的对话；这就是为什么需要向客户提供估算的原因，因为它有助于通过谈判最终确定正式协议的开放沟通。

在双方满意的一轮谈判之后，服务提供商启动工作说明书，作为开始实施解决方案的正式协议。工作说明书基于提案生成活动中启动的项目章程和项目计划文件。这是一项正式的法律协议，需要客户和服务提供商签署，因此它将包括项目章程的许多组成部分，包括项目范围、任何超出范围的要求、假设、风险因素、方法、时间表和资源。

工作说明书还将包括服务交付和支付计划方面的法律条款和条件。

工作说明书本身可以采取不同的方法。最常见的方法是时间和材料（T&M）格式，其中客户预计将在解决方案实施过程中产生的所有服务和费用在约定的间隔内支付。双方的项目经理负责确保项目保持在范围和预算内，通常有变更订单控制和流程来管理偏差。合作的范围和持续时间越大，双方就越有可能同意 T&M 格式，这将允许降低风险系数，尤其是对于服务提供商。

以下是在 Sure Step 中标准项目类型工作说明书模板的目录截图。工作说明书（SOW）已作为模板提供给使用 Sure Step 的组织，以便根据其特定需求进行定制，包括必要的法律参考。

另一种方法，在更紧张的经济时期更为常见，是固定范围的合作。在这种方法中，客户和服务提供商在开始时就严格定义了范围内的需求，服务提供商随后负责以约定的费用交付所有需求。这种方法对于服务提供商来说通常风险更高，尤其是在较大的合作中。合作范围通常在实施过程中经过一些级别的修改。这通常导致服务提供商在其费用结构中构建一个风险系数，以确保在缓解情况下得到一定程度的保障。值得一提的是，Sure Step 包括指导和建议来管理不可避免的范围修改——这包含在项目管理学科的项目管理部分中的提案管理部分。

除了工作说明书之外，提供给客户的另一个组件是软件许可和维护协议。如前所述，这可能仅适用于 Microsoft Dynamics，也可能包括任何相关的 ISV 解决方案。

业务解决方案交付的第三个组成部分是硬件和基础设施需求。这通常由客户的采购部门根据架构评估 DA 服务提出的建议来处理。

启动交付周期

在 Sure Step 诊断阶段中的最后一个活动是项目动员活动，这是解决方案实施开始的先导。这对于销售和咨询团队来说是一个关键活动，特别是在大多数情况下，销售周期涉及的资源与将交付解决方案的人员不同。

项目动员活动在客户签署工作说明书（SOW）之后进行。它确保销售资源和交付资源之间对客户需求和预期解决方案有清晰的知识转移。在这个活动中，服务交付经理还锁定将执行解决方案实施的咨询资源。如果资源在实施开始前需要额外的培训，经理负责确保培训计划得到安排并执行，不会影响解决方案交付的开始。

决策加速器服务其他方面

在前几节中，我们详细讨论了 Sure Step 决策加速器服务中每个服务的定位和用法。每个服务都是为了解决特定领域而设计的，并且它们相互补充，帮助客户展望他们的未来解决方案以及解决方案的交付方式。正如之前所提到的，DA 服务是各自独立且可选的，因此只需要使用那些满足客户参与需求的服务。尽管如此，有三个关键的 DA 服务应以某种形式执行，以确保解决方案符合愿景和需求。这三个关键 DA 服务是适配性差距和解决方案蓝图、架构评估和范围评估。

第一个 DA 服务，需求与流程审查，如果客户对新解决方案或新解决方案的未来流程没有全面了解，也是非常重要的。客户似乎越来越多地以请求提案（RFP）开始他们的业务解决方案选择过程。如果 RFP 包含了组织需求及未来流程的详尽组成，卖家可以开始进行适配性差距练习，以确定需求是否与他们的解决方案很好地匹配。然而，正如之前所提到的，即使客户已经有一个 RFP，也可能有其他竞争对手或供应商帮助客户制定需求。在这种情况下，你可能需要执行需求与流程审查的 DA 服务，至少在一定程度上。

确定解决方案的匹配程度至关重要，同样重要的是确定解决方案蓝图、未来基础设施、方法、时间表和交付所提议解决方案的成本。这就是为什么匹配差距和解决方案蓝图 DA、架构评估 DA 和范围评估 DA 被认为是关键的 DA 服务。如果在执行这些服务之后，客户确信他们拥有满足其需求的正确解决方案，销售团队可能能够直接进入最终许可和服务协议活动，并跳过概念验证和业务案例 DA 服务。然而，业务案例 DA 确实提供了重要的价值证明以及 KPI 识别。因此，业务案例仍然是一个高度推荐的活动。

对于较小的交易，销售团队经常会提出关于 Sure Step 决策加速器服务是否仍然适用的问题。无论 DA 服务定位为付费服务与否，它们仍然适用，因为它们降低了客户以及确保在提案中已记录和考虑所有需求的供应商的风险因素。重要的是要记住，每个 DA 服务的持续时间由销售和客户团队决定。因此，对于较小的合作，解决方案提供商至少应利用 Sure Step 提供的模板，并在必要时以简化的方式完成步骤。这将确保他们不会做出任何错误的假设，并且他们也能清楚地向客户传达他们对需求的理解和解决方案的愿景。通过这个过程还可以降低低估交易的风险，因为销售团队可能会发现他们在这一过程中没有考虑到的点。因此，至少，销售团队应使用 Sure Step 模板来记录他们的假设和解决方案愿景，并向客户传达。执行此过程的一个选项是将必要的服务结合起来，特别是三个关键服务，并以一系列步骤执行服务，在工作说明书中产生总结性文件。

利用 CRM 在线服务进行加速 POC 的诊断

对于考虑 Dynamics CRM 解决方案的客户，无论是在线还是本地部署，Sure Step 推出了一项名为“CRM 在线加速 POC”的服务。这项服务旨在利用可提供给潜在客户的免费试用许可证，使他们能够在决定继续进行解决方案愿景和解决方案获取之前，在自己的环境中“试驾”CRM 在线解决方案。Microsoft Dynamics 是世界上为数不多的同时为本地和在线解决方案提供相同基础代码库的独特解决方案提供商之一。因此，客户可以在 CRM 在线上验证功能，同时仍然可以选择部署本地解决方案。因此，这项 Sure Step 服务被称为“CRM 在线加速 POC”，而不是仅针对 CRM 在线解决方案。

CRM 在线加速 POC 的活动流程如下所示：

该服务的概念设计旨在为客户提供一些标准场景。客户随后将能够上传他们自己的数据集用于这些场景，从而能够快速验证相应的 CRM 功能，并对 Dynamics CRM 产品有一个舒适的感觉。

首先，Microsoft 服务团队开发了五个现成的销售自动化（SFA）场景，涵盖了以下基本工作流程：

• 领导捕获

• 领导分配/路由

• 机会管理

• 引用/合同开发

• 合同转换

SFA 场景通过 CRM 市场以快速入门包的形式提供给 Dynamics 合作伙伴生态系统。除了为场景设置解决方案外，该包还包括交付指南、演示脚本和样本数据，这些数据可以作为客户针对相应场景进行 Proof of Concept 的构建块。

使用之前讨论的材料，解决方案提供商可以在该服务的第一步执行高级需求分析和差距分析。如果一个或多个场景符合客户需求，解决方案提供商可以进行初步的业务价值评估，以初步了解解决方案的好处，以及进行架构评估，以确定客户的用户如何访问系统。随后，提供商的团队将使用客户数据设置系统，并将其转交给客户指定的用户，他们可以使用剩余的免费试用许可证来测试系统。为客户提供带有自己数据的设置的想法是为了使他们在测试和评估新系统时更加直观。

如果解决方案提供商在客户互动中遇到其他预定义场景，并遵循之前提到的流程，则除了五种已提到的场景之外，还可以利用加速 POC 概念。加速 POC 场景还可以作为 CRM 解决方案客户演示的起点。

还应提及的是，加速 POC 旨在通过让销售团队在 CRM 功能的一个有限子集上获得实际操作经验，从而为销售团队赢得快速胜利。当客户对解决方案的这一方面感到舒适时，解决方案提供商可以利用之前讨论的其他决策加速服务，包括需求和流程审查、适配差距和解决方案蓝图、架构评估和范围评估，以确定客户所需完整解决方案的范围。

当前 Dynamics 客户的诊断阶段

在前面的章节中，我们介绍了针对新或潜在 Dynamics 客户的 Sure Step 诊断阶段指南。诊断阶段也支持现有 Dynamics 客户尽职调查和解决方案销售流程，这是本节讨论的主题。

以下图表展示了现有客户决策加速服务中活动和服务的流程。该流程与潜在客户的流程非常相似，唯一的区别在于升级评估 DA 服务取代了需求和流程审查 DA 服务。

与潜在客户的流程类似，现有客户的流程从诊断准备开始。然而，在这种情况下，销售团队使用指南来解释对应 Microsoft Dynamics 解决方案新版本的特性和功能。当客户表示有兴趣将现有解决方案迁移到当前版本时，下一步是升级评估 DA 服务。

评估升级需求

在执行升级评估 DA 服务时，服务交付团队有两个主要目标。首先，交付团队评估当前解决方案以确定拟议升级的影响。其次，他们确定将解决方案升级到当前版本的最佳方法。

升级评估 DA 服务从解决方案交付团队与客户会面开始，以了解升级需求。解决方案交付团队通常由解决方案和/或服务销售主管以及解决方案架构师和高级应用顾问组成，以便向客户提供现实世界的视角。

Sure Step 提供了针对特定产品的问卷，这些问卷可以用于升级评估练习，包括针对 Microsoft Dynamics AX、CRM、CRM Online、GP、NAV 和 SL 的升级问卷。在未来版本中，AX 的升级问卷可能会被来自新 Microsoft Dynamics R&D 生命周期服务的升级分析工具所取代。

在下一步中，解决方案架构师和/或应用顾问将审查客户现有解决方案的配置、自定义、集成、物理基础设施和系统架构。然后团队将突出那些可以通过新功能增强来满足的要求，并确定在新产品版本中是否还有可能不再必要的自定义配置。

团队还会审查需要升级到新解决方案的自定义配置，并识别与升级解决方案相关的任何复杂性和风险。最后，团队将明确区分那些由当前功能满足的要求和那些需要实现新功能的要求。对于新功能，交付团队可以利用需求与流程审查 DA 服务中的相应产品问卷。

升级评估 DA 服务的最后一步是就升级的交付方法达成一致。如果没有新的功能被认为作为升级的一部分是必要的，解决方案可以使用技术升级项目类型指南、工作流程和模板。另一方面，如果认为需要新的功能，建议采用分阶段的方法，其中第一个发布是技术升级，将解决方案提升到当前产品版本，然后随后的发布或多个发布使用其他 Sure Step 项目类型（快速、标准、企业或敏捷）来实现新功能。

将其他决策加速器产品服务应用于升级项目

如果升级严格是为了将解决方案提升到产品的当前、受支持的版本，解决方案交付团队可以跳过适配差距和解决方案蓝图练习，直接前往架构评估 DA 服务以确定新的硬件和基础设施需求，以及范围评估 DA 服务以估算升级的工作量。团队还可以选择将这些服务合并为一个单一的产品，并仅使用其他产品提供的模板和工具来向客户提供工作说明书和升级估算。

如果升级将引入新的功能，根据新需求的重要性，客户和销售团队可能认为执行或组合适应性差距和解决方案蓝图、架构评估和范围评估决策加速服务是必要的。这确保了双方共同讨论并达成一致，以制定适当的蓝图、系统架构和整体发布方法。

在这两种情况下，概念验证决策加速服务和业务案例决策加速服务可能不是必需的，尽管根据升级中引入的新功能范围，客户和销售团队可能决定使用业务案例工具来确保项目合理性得到建立。

在完成必要的决策加速服务之后，销售团队可以继续进行提案生成活动，以建立项目章程和项目计划。接下来的步骤是完成最终许可和服务协议活动中的销售，包括就产品许可的新条款和解决方案升级的工作说明书达成一致。最后，在项目动员活动中，交付团队被动员起来，以确保升级合作能够顺利启动。

支持客户的购买周期

如我们在本章开头所述，Sure Step 诊断阶段旨在帮助解决方案提供商组织中的销售人员和客户组织中的买家。在前一节中，我们讨论了该阶段对销售方的适用性；在本节中，我们将讨论如何通过选择合适的解决方案来满足他们的愿景和需求，从而通过一个彻底的过程来启用客户的尽职调查工作。

在第二章“解决方案销售和推动尽职调查”中，我们讨论了与客户购买周期相对应的阶段。以下图表显示了我们将相同的 Sure Step 诊断阶段活动和决策加速服务应用于解决方案销售过程的方式，也符合客户的购买周期阶段：

• 第一阶段：需求确定

  • 解决方案概述活动

  • 需求和流程审查决策加速服务

• 第二阶段：备选方案评估

  • 适应性差距和解决方案蓝图决策加速服务

  • 架构评估决策加速服务

  • 范围评估决策加速服务

• 第三阶段：风险评估

  • 概念验证决策加速服务

  • 业务案例决策加速服务

  • 提案生成活动

让我们先从从客户的角度来探讨决策加速器服务和其服务的应用开始。从销售者的角度来看，术语“服务”可以被视为一个可销售的单元。但另一方面，“决策加速器”这个术语不仅超越了销售者，也扩展到了客户，因为这些单元的目的是帮助他们迅速获得问题的答案，并以逻辑和结构化的方式推进他们的决策过程。在这种情况下，“决策加速器服务”这个术语对客户来说同样适用。

下文将讨论活动与决策加速器服务与客户购买周期的对齐。如果读者尚未这样做，建议他们回顾前面的章节，以了解决策加速器服务的结构，因为这部分内容在本节中未重复。

定义组织需求

买家通过理解组织的痛点并收集市场上可用的解决方案信息来开始他们的需求确定阶段。诊断准备活动中的指导链接到其他网站和其他信息源，可以帮助解决解决方案信息收集工作。如果客户的组织在 Sure Step 覆盖的行业中运营，他们还可以在行业部分中获得有关解决方案如何满足其特定需求的更多信息。

虽然诊断准备活动中的指导为客户提供了对可用解决方案的外部认识，但 Sure Step 需求与流程审查决策加速器服务有助于客户理解他们自己的内部需求。使用此服务中的角色定制问卷模板，客户团队中的领域专家（SMEs）可以针对每个角色进行“一天的生活”场景分析，从而从用户的角度量化部门和组织的需求，而不仅仅是从产品角度。

客户还可以使用详细的过程图作为起点，特别是使用新的 BPM 工具开始可视化组织的新解决方案的工作流程。同样，这有助于客户从用户的角度描述他们的需求。最终，解决方案的成功或失败取决于其与用户的适用性或相关性，这一点不能过于强调。

需求和待执行流程的文档是未来解决方案愿景的基础。根据其开发方式，客户组织可以利用这些文件对解决方案备选方案进行彻底评估，并选择满足其需求的最佳解决方案。

确定合适的解决方案

在确定需求之后，买家开始评估解决方案的替代方案。这正是 Sure Step 适配差距和解决方案蓝图、架构评估和范围评估决策加速器服务可以帮助客户确定 Microsoft Dynamics 解决方案是否适合他们的地方。

如前文所述，适配差距和解决方案蓝图 DA 练习首先确定解决方案对每个需求的适配度。一些客户可能希望适配度值更高，以最小化定制，而另一些客户可能在需要相当定制化解决方案的专业环境中运营，因此他们可能对较低的适配度值感到满意。然而，在两种情况下，客户都希望确保解决方案的 TCO 是可接受的。

在确定解决方案适配度之后，客户主题专家将与解决方案提供商合作，制定未来解决方案的蓝图。解决方案蓝图通常呈交给客户的执行者或业务赞助者。因此，该文档应使用商业语言编写，并清楚地解释业务需求或痛点将通过拟议的解决方案得到满足或解决。

拥有解决方案蓝图后，买家随后获取其他关键信息以评估解决方案是否符合他们的成本标准。架构评估 DA 服务将向客户提供拟议的硬件和架构，客户的采购部门可以据此确定物理基础设施成本。如果客户对解决方案的性能、可扩展性和可靠性有任何担忧，他们也可以通过要求在相应领域进行更详细的分析，从服务提供商那里请求更多技术验证。

最后，范围评估 DA 服务向客户业务赞助者提供了解决方案交付的努力估计和相关成本。这项练习还向客户提供了对交付解决方案的整体方法的了解，包括时间表、预测资源、角色和责任。

理解和缓解风险

在购买周期的最后阶段，客户将希望确保预期的解决方案利益远大于相关的风险。Sure Step 概念验证决策加速器服务可以帮助缓解客户主题专家或部门领导对解决方案某个特定领域的任何具体担忧。解决方案交付团队将设置、配置和定制解决方案，并在可能的情况下使用客户数据来展示解决方案的应用符合客户的要求。在此提供方案中执行的任何解决方案努力都将转移到实施中，并成为解决方案交付的起点。

Sure Step 商业案例决策加速器服务也帮助客户在其购买周期的这一阶段，但更多的是从管理解决方案的执行和组织认可的角度来看。使用独立分析师开发的 ROI 工具，这项服务可以帮助客户团队向组织中的其他关键利益相关者（如首席执行官、首席财务官或董事会）证明解决方案的收购是合理的。这可能是对抗组织政治的关键一步，在解决方案交付周期的起伏不定中也非常重要。

最后，Sure Step 提案生成活动为客户赞助者和客户项目经理提供整体项目章程和项目计划，确保他们有明确的文档记录了买方和卖方之间达成的协议，以避免任何后续的假设或误解。项目章程还将确定与解决方案交付相关的风险，并为每个风险概述缓解策略。解决方案提供商制定的项目章程也可能指出客户拥有的任何依赖项或假设；客户应确保他们有必要的资源，以便这些依赖项不会成为交付团队的障碍。

升级现有解决方案的方法

与对新解决方案的评估过程类似，Sure Step 诊断阶段也支持寻求升级其解决方案的现有客户的尽职调查过程。以下图表显示了一个与新的解决方案评估非常相似的流程，唯一的区别是升级评估 DA 服务现在取代了需求和流程审查 DA 服务：

如前文所述，Sure Step 升级评估决策加速器服务捕捉了客户更改或增强其当前解决方案的业务需求，并确定升级到解决方案最新版本的最好方法。如果当前解决方案包含可能因新功能而不再被认为是必要的自定义功能，交付团队将识别这一点。他们还将评估整体升级的复杂性以及升级的发布流程。

升级评估 DA 练习的发现也将决定客户应承担 Fit Gap 和解决方案蓝图、架构评估、范围评估、概念验证和商业案例决策加速器服务的程度。根据所需新功能的重要性，客户赞助者和主题专家可以决定根据需要跳过或合并这些服务。无论如何使用 DA 服务，都应在提案生成活动中为客户制定项目章程和项目计划。

针对特定行业的解决方案定位

Sure Step 为解决方案提供商和客户提供行业和跨行业解决方案的指导。Sure Step 提供了涵盖行业和跨行业的微软 Dynamics 解决方案能力的概述，并包括选定行业垂直领域的业务痛点，解决方案提供商可以使用这些痛点来定位潜在客户。

如前述截图所示，Sure Step 目前为以下领域提供指导：

• 行业/垂直解决方案

  • 制造业

  • 公共部门

  • 零售行业

  • 服务行业

• 跨行业/水平解决方案

  • 扩展 CRM 解决方案

  • 客户关怀

我们将在以下章节中讨论这些解决方案。

行业/垂直解决方案

自从微软 Dynamics AX 2009 版本发布以来，微软 Dynamics 一直为客户提供广泛的行业场景或工作负载的核心解决方案功能和能力，并继续在 AX 2012 版本中提供。您可能还记得我们在第一章中介绍了工作负载的概念，背景和概念。作为一个快速回顾，工作负载可以是一个单独的业务流程，如费用管理，也可以是一个功能内的多个业务流程，如供应商关系管理、供应链管理、人力资本管理、销售、营销或客户服务。

从系统角度来看，工作负载包括 ERP 和 CRM 系统。相应地，微软的行业解决方案也涵盖了操作和行政 ERP 工作负载以及 CRM 工作负载。以下截图显示了微软 Dynamics 对行业解决方案的愿景和方法：

Sure Step 行业/垂直解决方案部分旨在描述标准微软 Dynamics AX 和 CRM 解决方案在之前讨论的行业中的功能。还为特定行业内的特定垂直领域提供了额外的观点。

制造业

根据制造商品的方式，制造业被广泛分为两个领域——流程制造业和离散制造业。流程制造业是一个制造业分支，其中商品的生产是通过公式和配方实现的，从而产生加工品或库存单位（SKU）。相比之下，离散制造业的生产过程是通过物料清单和路线的指定来实现的，从而产生组件、子组件和/或组装 SKU。

对于流程制造业，Sure Step 包括以下行业的客户需求和 AX 解决方案的匹配：

• 食品和饮料行业

• 化学品

• 生物科学和制药业

• 非耐用品消费品

• 主要金属

• 纸浆和造纸

• 肉类、猪肉和家禽

Sure Step 指南包括针对特定客户需求的具体内容，例如食品和饮料行业的计重和基于配方的计量单位，或生命科学和制药行业的集中质量控制与合规支持，这些内容在相应的页面上。

制造行业垂直领域的额外内容和指南也可在诊断阶段的决策加速服务中找到。在需求与流程审查 DA 服务下，Sure Step 为流程制造行业提供补充问卷，帮助确定客户需求如何与批量制造流程相匹配。对于离散制造，通用的针对微软 Dynamics AX 的角色定制问卷提供了与离散生产流程相关的具体问题，包括针对生产计划和经理的问题。这些问卷还可以帮助确定客户的流程是否在混合模式制造环境中包括离散过程。

Sure Step 还提供了涵盖先前提到的流程制造行业的流程图，以及离散制造流程图，例如微软 Dynamics AX 的生产流程图。

未来发布的 Sure Step 可能会参考来自微软 Dynamics 生命周期服务（LCS）工具的相应制造内容，例如制造流程图和行业配置。

公共部门行业

公共部门行业指的是由国家或政府控制和运营的操作和业务。公共部门行业覆盖范围广泛，包括几个子行业和垂直领域。该行业在垂直层面具有非常具体的企业需求，以及在国家层面的监管差异。

在 Sure Step 2010 中，包括了针对公共部门的指南。虽然 Sure Step 中的指南描述了选定公共部门行业垂直领域的组织需求，但迄今为止，仅针对微软 Dynamics CRM 解决方案功能进行了解决方案对齐。未来的版本可能包括与 Dynamics AX 功能的对齐——至少，将提供对微软 Dynamics Lifecycle Services 工具中相应内容的适当引用。目前，Sure Step 公共部门指南分为以下领域：

• 政府

  • 公民服务平台（政府服务中心）

  • 政府工作场所现代化

  • 司法案件和记录管理

• 健康

  • 共享服务

  • 医疗保健和记录管理

• 教育

  • 学生咨询和招生

  • 学生注册和入学

  • 学生管理

  • 教育案例管理

• 非营利组织

Sure Step 内容包括面向特定公共部门解决方案领域的业务需求问卷和流程图，为选定解决方案领域的适配性差距分析工作表，架构评估考虑事项的附录，范围评估提供的范围指南附录，以及概念验证提供的样本演示幻灯片。此内容的一个例子是针对政府组织经济发展需求的“需求和流程审查决策加速服务”问卷。

在接下来的部分中，我们将讨论决策加速服务的用例以及先前引用的内容，以帮助公共部门客户在选择适当的解决方案以满足其需求时进行尽职调查。

用例 - 地方政府委员会的决策加速

本案例研究说明了服务提供商通过执行决策加速服务组合来帮助客户通过其决策过程的例子。客户是一家拥有 300 名员工和 6 人 IT 团队的澳大利亚地方政府委员会，为大约 40,000 名居民提供政府服务。委员会一直使用专有应用程序来管理服务请求，但该流程和解决方案未能很好地解决选民的需求。

为了实现其战略计划中概述的服务标准，委员会确定他们需要更换现有的客户访问请求系统。他们需要一个解决方案来通过减少呼叫等待时间来提高选民满意度。他们需要一个能够帮助他们在第一次接触点回答更多选民请求的解决方案。他们还希望为选民提供更多联系委员会的选择。最后，该解决方案还预期能够通过易于使用的工具提供每个选民的综合视图，从而通过委员会系统用户提供更一致的服务，并帮助他们快速解决问题。

对现成系统进行初步调查以解决其需求，结果导致委员会陷入僵局。在目睹了委员会成员见证的解决方案演示后，委员会决定让微软参与打造一个全面的政府服务中心解决方案。

在初步资格活动之后，销售执行人员组建了一个由微软服务和微软合作伙伴资源组成的预销售交付团队。该团队的任务是了解委员会的需求，以开发和展示预期的解决方案。

预销售交付团队向客户展示了一个计划，该计划包括执行三个决策加速服务，即适配性差距和解决方案蓝图、概念验证和范围评估，如下所示：

委员会接受了该计划，并同意资助这项活动。预销售交付团队在几周的时间内执行每个决策加速器服务，并为每个 DA 服务分配一到两名资源。一个 DA 服务自然地流向下一个 DA 服务，这进一步增强了委员会成员对过程的信心。

交付团队花时间了解委员会的要求，制定了一个愿景解决方案，构建并演示了一个概念验证解决方案，并最终交付了一个评估和计划以结构化解决方案交付。这个过程超出了委员会的预期，导致以下一位成员的评论：

通常在地方政府，我们会得到一个产品并被告知围绕它工作流程。这可能意味着改变人们的工作方式，这会花费时间和金钱。所以与微软合作是一种令人耳目一新的体验，因为他们采取了相反的方式。他们询问我们的流程，并据此工作，调整他们的产品以使其适应。他们真正倾听业务，并让我们来决定。结果是，一个非常适合地方政府的解决方案。

本案例说明了彻底的诊断过程的有效性，该过程为客户和服务提供商都带来了双赢的局面。它还展示了 Sure Step 中决策加速器产品结构的灵活性，允许账户团队选择要采用的服务以及执行它们的特定顺序。记住，离客户最近的人是制定满足客户需求正确流程的最佳人选。因此，他们也应该是决定遵循什么流程以实现他们目标的人。拥有灵活且一致且可重复的流程允许现场团队做到这一点。

零售行业

Sure Step 在 2010 年版本中引入了对零售行业的覆盖，以与最初的 Dynamics AX 零售解决方案发布保持一致。该指南的结构沿着以下零售价值链支柱：

• 规划（包括预测和商品销售）

• 销售（包括忠诚度计划、促销活动和营销活动）

• 管理（包括商店补充和仓库管理）

• 采购（包括采购和供应商管理）

• 维护（包括退货和销售点工作流程）

零售价值链随后扩展到特定的子行业，包括以下：

• 专业零售

• 一般商品

• 健康与个人护理

• 食品和饮料（杂货连锁店等）

Sure Step 还在决策加速器产品部分提供了内容，包括针对零售价值链支柱的定制零售问卷补充和业务流程图。

与制造和公共部门行业一样，用户应期待 Sure Step 的未来版本将参考来自 Microsoft Dynamics 生命周期服务工具的相应零售内容，例如零售流程图和行业配置。

服务行业

与零售覆盖范围一样，Sure Step 为服务行业沿着服务行业价值链支柱提供指导。以下包括以下内容：

• 开发（包括关系管理）

• 销售（涵盖账户和机会管理）

• 交付（包括参与管理）

• 资源（包括人才管理）

• 维护（包括非项目收入）

• 管理

服务行业价值链随后扩展到特定的子行业，包括以下内容：

• 专业服务，包括政府承包商和法律服务

• 建筑和工程，以及建筑行业

• 媒体和娱乐，包括广告

同样，Sure Step 还为决策加速器提供内容，包括为之前讨论的子行业和垂直行业提供的角色定制零售问卷附录。

与其他行业一样，用户可以期待 Sure Step 的未来版本将参考来自 Microsoft Dynamics 生命周期服务工具的相应服务行业内容，包括流程图和行业配置。

跨行业/横向解决方案

前一节讨论了 Sure Step 对选定行业和垂直行业的覆盖范围。Sure Step 还提供关于跨行业解决方案的指导，这些解决方案可以被视为一组核心 Microsoft Dynamics 解决方案能力，适用于多个行业的客户组织；这些也可以适应特定行业或垂直行业。

跨行业客户关怀解决方案

随着 Microsoft Dynamics CRM 2011 的发布，客户通过利用 Microsoft Dynamics CRM 的客户关怀加速器（CCA）获得了构建客户关怀解决方案的灵活平台。CCA 可以作为以下不同业务线解决方案的基础：

• 通过聚合来自不同业务应用的信息到集成桌面，提供组织对其客户信息和互动的 360 度视图。客户服务代表通过立即访问业务关键信息来快速有效地服务客户，从而提高客户满意度和忠诚度。

• 通过创建桌面自动化工作流来消除重复数据输入，这些工作流简化了业务流程，消除了代理在多个应用程序中重新输入相同数据的需要，从而减少了人为错误并确保一致的客户服务体验。

• 计算机电话集成（CTI）为组织提供一个一致的框架，以连接 CTI 系统与关键业务线应用。

• 活动报告可以帮助接触中心经理通过访问代理桌面交易报告来识别潜在的过程瓶颈。

Sure Step 包括由微软服务团队开发的多个客户关怀内容模板，包括微软 Dynamics CRM 的 CCA 问卷、架构规划指南、基础设施规模表和 CCA 架构评估问卷。还提供了 CCA 的概念验证交付指南和业务案例客户报告模板。

xRM 或扩展 CRM 解决方案

扩展 CRM，或 xRM，指的是将微软 Dynamics CRM 作为一个平台，以及任何与之集成的其他外部应用程序，用于管理交易关系。本质上，xRM 中的“x”代表由解决方案启用的相应业务实践。关系管理解决方案扩展的例子包括医疗保健关系管理（HRM）、媒体关系管理（MRM）、学生关系管理（SRM）等。xRM 解决方案可以扩展到多个行业或垂直领域的事实是 Sure Step 内容定位在跨行业部分的原因。

微软 Dynamics CRM 平台组件的灵活性使其能够被许多不同组织以多种方式利用。该产品能够在单个平台上快速创建和部署大量关系型业务线（LOB）应用程序，共享资源和技术，使用户在业务线应用程序中拥有一致的使用体验，这些技术对他们来说已经熟悉。这些应用程序具有高度的可扩展性，可以快速适应用户和企业的独特需求，同时最大限度地降低总拥有成本。

在 Sure Step 中提到的定位扩展 CRM 解决方案的一些关键好处包括以下内容：

• 熟悉的微软办公软件类型用户界面，它推动了用户熟悉度和解决方案的采用

• 预定义的安全组织管理模式

• 内置用户驱动报告和分析功能

• 声明式数据建模，具有即时网络服务数据操作

• 平台已知性能和可用性指标

• 使用标准微软.NET 技术易于扩展和集成

• 使用多租户和扩展配置提供可扩展的交付

Sure Step 还包括额外的模板，例如微软 Dynamics CRM 2011 应用程序框架功能，以说明支持扩展 CRM 业务解决方案的关键功能和主题。

未来行业和跨行业解决方案内容

正如我们在前面的章节中讨论的，并在前面的部分中引用的，Microsoft Dynamics 研发生命周期服务为用户提供了一系列广泛的工具。随着这些工具的不断构建和发布，用户可以期待在这些工具中获取更多针对行业和跨行业解决方案的内容和相关性。因此，未来的 Sure Step 版本将包括链接到工具的特定区域，以及它们在解决方案销售周期中可以如何被利用。

快速参考

在本章中，我们介绍了几个关键的诊断活动和决策加速器服务。以下是一个快速参考。

• 针对新 Microsoft Dynamics 客户的诊断：从 Microsoft Dynamics 解决方案和行业/跨行业定位指南开始。利用决策加速器服务，从需求与流程审查服务开始。在之后要考虑的三个关键 DA 服务是适配性差距和解决方案蓝图、架构评估和范围评估服务。考虑业务案例服务，并且至少确定参与项目的预期解决方案效益和客户成功因素。

• 针对新 Microsoft Dynamics CRM 客户的诊断：如果标准场景适用且可以获取试用许可证，则从 CRM 在线服务的加速验证概念开始。在获得初步客户认可后，利用其他 DA 服务，包括需求与流程审查、适配性差距和解决方案蓝图、架构评估和范围评估服务。

• 针对现有 Dynamics 客户的诊断：根据需要利用 Microsoft Dynamics 解决方案和行业/跨行业定位指南。从升级评估 DA 服务开始，以确定将现有解决方案升级到当前产品版本的正确方法。如果在升级过程中要引入新功能，则利用其他 DA 服务，包括适配性差距和解决方案蓝图、架构评估和范围评估服务。

摘要

在本章中，我们专注于 Sure Step 的诊断阶段。我们讨论了这一阶段是如何被设计成双重目的的——既帮助销售者定位解决方案并完成销售，又帮助客户进行尽职调查过程并选择满足他们需求的正确解决方案。我们涵盖了为新 Dynamics 客户在诊断阶段使用决策加速器服务的情况，为利用 CRM 在线服务进行加速 POC 的 Dynamics CRM 客户进行诊断阶段的情况，以及为现有 Dynamics 客户进行的诊断阶段。我们还讨论了制造业、公共部门、零售和服务行业的行业/垂直解决方案，以及客户关怀和扩展 CRM 的跨行业/横向解决方案。

诊断阶段非常重要。如果尽职调查活动执行不当，实施过程可能会受到影响，客户的满意度也会较低。如果做得正确，它可能导致有效、成本效益高、按时和高品质的解决方案交付。它还为顺利的解决方案交付过程奠定了基础。

在本章中，我们介绍了几个关键的诊断活动以及决策加速服务——请参阅快速参考部分以获取简要描述。

在接下来的章节中，我们将探讨解决方案交付方法。我们将从项目管理讨论开始，然后详细介绍 Sure Step 提供的实施工作流程、模板和工具。

第四章：管理项目

在前面的章节中，您已经通过 Sure Step 考察了解决方案销售、尽职调查概念和解决方案展望。本章将带您进入管理项目的迷人领域。项目管理领域正在兴起，因为多年来质量已经成为一种竞争工具。项目管理协会（PMI）将项目管理定义为应用知识、技能、工具和技术到项目活动中以满足项目需求。担任负责软件实施项目的项目经理是一项具有挑战性和要求很高的职责。优秀的项目经理以平衡的方式结合各种技能。他们需要在独特和临时环境中实践领导力、沟通、谈判、问题解决和影响能力。当事情出错时，项目经理通常发现自己处于风暴的中心。然而，管理项目带来了巨大的回报。成功实施业务解决方案意味着您的客户组织将因其团队的辛勤工作和质量而受益于日常运营的更高效率。同时，您创建并管理一个环境，使顾问能够实现他们的职业抱负。

在本章中，您将了解：

• 项目与项目管理

• 项目成功的四大支柱

• 项目管理要素

• 项目管理采纳

• 项目管理不可或缺的组织效益

关于项目与项目管理

在本节中，我们将讨论和反驳一些对项目管理的普遍抵制，并就项目管理需求和选项等话题为您提供思考。

传说与抵制

我们需要承认怀疑论者对其坚定抵制的贡献。对项目管理的抵制无处不在，有时甚至根深蒂固于难以打破的神话中。举证责任在原告一方，因此我们需要为每个任务辩护项目管理的原因，这与对无结构方法的容忍形成鲜明对比。现在我们面临什么样的抵制？普遍的观点是项目管理有很多开销。同时，它通常被视为灵活性的障碍。许多人认为项目管理是理论家做事的方式，这与管理的首要指令——完成任务——截然相反。

项目管理也被贴上不可销售、如死库存的标签。这类论点让你在向全世界宣扬您的项目管理抱负之前三思而后行。但怀疑论者的论据有多强呢？

项目管理是开销吗？

什么是额外开销？从成本会计的角度来看，额外开销是指运营业务产生的成本，但这些成本不会直接产生收入或利润。典型的额外开销包括会计、广告、折旧、保险、利息、法律费用、租金、维修、供应、税收、电话费、差旅和公用事业费用。按照这种逻辑，关于项目管理支出是否是额外开销的问题引出了另一个问题：我们是否向客户开具项目管理服务的发票？然而，这是关键问题吗？根据这种推理，我们应该将我们的销售成本归类为额外开销，并且不应该向我们的销售团队开具服务发票。如果我们部分向项目经理开具发票，这会使额外开销问题变得多余吗？

当怀疑论者将项目管理称为额外开销时，他们通常想到的是与项目管理学科相关的一大堆文件和许多程序和行政任务。当他们的项目管理实践没有根据项目的大小和复杂性或他们的组织结构进行扩展时，这种批评可能是合理的。这些失败的项目管理程序通常基于无知。

为了回答这个问题，我们需要评估我们项目管理实践的好处。它是否有助于我们项目的利润和质量？它是否为我们的客户和团队增加了价值？如果这两个问题的答案是肯定的，那么它显然不是一项额外开销。如果你无法提取这些好处，你的项目管理支出可能被标记为额外开销。项目管理是你和你所在组织如何定义的，它可能变成额外开销，也可能变成增值服务。

因此，当怀疑论者声称项目管理增加了额外开销时，他们可能是对的。但这更多地反映了他们的项目管理实践，而不是一般意义上的项目管理。

项目管理是灵活性的障碍吗？

你经常会遇到声称支持项目管理实践的人，但他们立刻补充说他们担心对组织灵活性的影响。他们认为项目管理程序会降低他们应对不可预测变化的能力，并且他们的推理很快就会将项目管理与实用方法对立起来。那么，项目管理不是关注实际问题吗？我们是否失去了改变的能力，项目管理是否阻碍了我们项目的发展？在测试这个命题的准确性时，这些问题是需要回答的。

如果这一切都是真的，项目管理学科将面临巨大的困难。谁会考虑实施项目管理实践，明知这将使组织的有效性瘫痪？数百万的项目管理实践者是否在误解中挣扎？这似乎是一个无法站得住脚的假设。

大多数情况下，这种对项目管理的不适应源于无法区分主要问题和次要问题。那些在这场困境中挣扎的人们过分强调所有描述的项目管理工具、文档和方法步骤的重要性。他们花费太多时间在管理和描述项目上，从而失去了对项目真正管理和实际事务的宝贵时间。官僚主义的项目管理观念与“让我们直接开始工作”的方法形成了鲜明对比。

良好的项目管理实践全在于管理变化、实际事务和灵活性。通过保持以结果为导向、精简和高效，它将赋予你使项目成功实施的能力。一个好的项目经理不是一个官僚主义者，而是一个走钢丝的人，在每一个项目中平衡管理、步骤和工具的需求。这听起来容易做起来难，需要一位经验丰富的项目经理，他对项目管理学科有深入的了解，才能实现结构化的灵活性。尽管缺乏技能和经验的项目经理倾向于掌握僵化的程序，但在谈论灵活性的障碍时，公司高管也不能免责。他们负责公司的文化，而这种文化代表了公司能够实现的目标的极限。

项目管理不可行吗？

前一章关于解决方案销售的内容可能会让你自己回答这个问题。能够为顾客释放价值和利益的项目管理实践必须是可销售的。如果你无法将其销售出去，你将难以销售你的方法论的价值，或者无法说服客户其必要性。这可能与你的方法论的内生价值有关，或者与销售流程的失败有关。我们习惯于销售我们的软件、商业咨询服务和开发专业知识，但我们对于销售项目管理服务的熟悉程度如何？我们是否为这种服务制定了良好的定价策略？如果你想销售项目管理，它必须成为你适应价值主张的一个真实元素，这对于良好的桥梁销售是必要的。你的客户或潜在客户可能不熟悉实施项目的景观和项目管理需求，他们可能对此感到紧张，甚至害怕去探索。你的项目管理服务价值主张需要灵活且适应每个机会的变化。一个值得注意的是，那些声称无法销售项目管理的人，对于它没有适应性的价值主张，却将项目经理定价为团队中最昂贵的人。通过这种方式，他们为自己设置了障碍。

为什么是项目管理？

这是我们甚至在考虑实施项目之前需要提出的关键问题。良好的项目管理实践需要解决或改进我们希望看到的问题。一般来说，只有一个共同的目标需要实现：使项目盈利并取得成功。你希望并且需要从你的项目中获得利润，同时，按照预期向客户交付价值。这是一个经济生存的问题。

你可能之前已经听说过这个，但你有没有认真思考过？交付亏损的软件项目相对容易。你所需要的就是客户的认可，一些资源，然后就可以开始了。有些人甚至直到财政年度结束时才意识到他们的项目并不盈利，当会计师向高管问责时。项目是风险的代名词，如果你想实现盈利和客户满意度这两个基本目标，你需要管理风险。这就是为什么你需要项目管理，而不仅仅是一个次要问题，而是你项目商业的一个基本工具。

我们现在知道你需要项目管理，因为你的项目需要按时、在预算和范围内交付。但这些目标是否足够SMART（具体、可衡量、可实现、相关和有时限）？如果你想有一个务实的项目管理实践，你也需要定义务实的目标。在你的组织和具体项目中，它需要成功的是什么？它如何对你的员工和客户有价值？对此要具体说明。大多数公司都有基于深思熟虑和具体目标的销售、营销、财务和运营系统及服务的特定指标。如果项目是服务业务的基本组成部分，你也需要为你的项目管理实践设定这些目标。没有它们，提高项目的利润和客户满意度将是一条艰难的道路。是的，“按时”和“在预算内”是可衡量的，但你能否在没有设定规范的情况下衡量“在范围内”和“满足质量期望”？你当前的项目管理实践是如何贡献于这些目标的？如果暂停你当前的项目管理程序，会有什么影响？你如何在将来改进你的项目管理实践，或者你将在几年后仍然使用完全相同的程序？如果你真正寻求增值的项目管理实践，那么就有空间设定更明智的目标。所以，在你开始绞尽脑汁如何实施项目管理方法之前，先定义你需要它以及它需要实现什么。现在，你从哪里开始？

当然，定义你的项目管理实践如何贡献于公司的成功并不容易。它需要对你服务交付策略、公司的优势和劣势、客户组合和行业、员工组合和项目历史有一个强烈的愿景。你的项目管理目标需要嵌入这个背景中，同时，它们在不同学科中需要非常具体。你可以从开发一个分解开始，在这个分解中，你将定义要实现和衡量的目标领域。

一个好的起点可以是描述在项目管理知识体系（PMBOK）中，并在 Sure Step 中采用的九个知识领域。它们如下：

• 项目整合管理

• 项目范围管理

• 项目时间管理

• 项目成本管理

• 项目质量管理

• 项目人力资源管理

• 项目沟通管理

• 项目风险管理

• 项目采购管理

将前面的知识领域作为你的目标类别，并对其进行优先排序。哪些领域与你的SWOT（优势、劣势、机会和威胁）分析结果相匹配，并与你的服务策略要点保持一致？在每个这些类别中设想什么将帮助你的组织改善你的服务。已知的问题是什么，需要解决什么？你需要哪些工具和程序来实现这一点，以及这将带来哪些业务改进？谁将从中受益，以及受益程度如何？这只是你目标分解的一个例子。你可以以任何方式来做，只要它对你和你的公司有价值。关键点是，如果你想适应一个有用的项目管理方法，你需要确切地知道你需要项目管理的确切原因。

替代方案

假设你希望在没有任何标准项目管理方法的情况下交付你的项目。你最终会怎样？第一个症状就是大多数同事会以自己的方式填写他们的项目角色。每位顾问、开发人员和项目经理都会有他们自己的工具、模板、步骤、质量标准和甚至他们自己的术语。你会发现很难与同事和谐共事，因为很难想象他们将会如何交付。你如何以积极主动的方式管理团队的活动和交付成果？团队成员将如何知道对他们有什么期望？你公司中的不同项目经理可能在他们的项目中设定完全不同的目标、质量标准和交付成果。

想象一下，你被聘为顾问或开发者，在两个项目中工作，这些项目的项目经理对交付什么和如何交付有完全不同的期望。这有多么困难和低效？你如何向客户传达他们可能期望的内容？

以这种方式操作，你项目的成功将是一场赌博。有些项目可能会成功，而其他项目则可能陷入普遍的不满。作为一个公司，你将你公司项目成功的概率完全留给个人，而且将无法以结构化的方式改善你整体的质量和利润。以这种方式工作的公司通常只有一种提高质量的方法：替换资源。他们从这样的想法中找到安慰，即少数人负责项目的失败，并安慰自己，如果有其他资源，这种情况就不会发生。通常不会花很长时间，他们就会在新项目中再次面临同样的问题。在这些公司中，混乱在统治，这对所有相关人员都是一种打击。

一些公司把正式的项目管理应用与薪酬挂钩。如果客户愿意为其参与的服务付费，实施工作将由项目经理指导。在这些情况下，他们把在项目上实施项目管理原则的部署依赖于能否推销项目以及客户是否理解项目管理需求的重要性。未能获得客户的项目管理预算意味着实施工作将不受管理。你当然知道那些销售经理表示几乎没有（如果有的话）项目管理预算的情况。那么接下来会发生什么呢？一个引人注目的事实是，在这些情况下，会指派一个项目经理。没有预算意味着缺乏项目管理，但项目经理还是被指派了。谁愿意站在这个人的位置上呢？通常，一位有良好产品经验记录的资深顾问会荣幸地承担这项管理任务。这个人需要既是执行者又是管理者，这要求在即使有大量时间可用的情况下也难以完成的复杂平衡。现在这位可怜的项目经理需要完成这项练习，同时知道没有官方的项目管理时间可用。别忘了，风险并不依赖于回报。我们的资深产品专家将面临与有显著项目管理预算时相同水平的风险。在这些大多数情况下，关于项目风险没有明确和正式的协议。客户将在可能的情况下将风险转嫁给供应商，你将被迫按照预期交付。

我们可以期待什么样的结果？除了常规的应用顾问任务外，我们这位经验不足的应用顾问在履行项目经理角色的同时，可能会排着队参加众多内部和客户会议、谈判、额外的分析活动、范围变更、规划、调度等等。

到目前为止，我们的顾问已经忙得不可开交，无法足够关注常规顾问的任务。这将会带来质量问题，导致更多的会议、谈判和返工。要摆脱这个恶性循环，你可能需要销售技能和项目管理指导的混合。所以最终，你做了一些没有预算的工作，并且没有将其作为服务提供给客户。不幸的是，这并不真正高效或主动，最终成本远高于一个经过深思熟虑的项目管理职位所应承担的成本。在最佳情况下，组织意识到在特定项目上花费的额外时间，但在许多情况下，人们试图通过创意报告在他们的工时表中掩盖这一点。在这种情况下，你可能会在财政年度结束时发现，你的项目并没有像预期的那样有利可图，这无疑是一个不太愉快的惊喜。

客户也不会从这个场景中受益。他们开始了一个企业资源规划（ERP）或客户关系管理（CRM）的实施，旨在改进他们的业务流程，并赋予他们高效工具，使他们能够在工作中更加高效。最终结果是众多会议、无果的讨论和抱怨的员工，这与预期的目标相去甚远。他们应该意识到风险因素是实施项目的一个基本要素。客户对项目的积极结果有明确兴趣，并且必须接受项目管理的重要性。

那么，真正的替代方案是什么？别忘了，风险并不依赖于回报。

使用我们自己的方法论

给那些投入时间开发自己实施方法的公司打满分。为项目设想一个质量策略并不明显，更不用说在鼓励组织适应的同时，将这一愿景转化为一套可行的程序、指导和工具的工作量了。然而，看到这一艰难的旅程引导整个公司走向项目成功、盈利和满意的客户和员工，是一件令人愉快的事情。对于这些合作伙伴来说，实施的结构化项目管理方法将是持续改进的起点和关键工具，也是他们竞争优势的中心。

在所有公正的前提下，我们需要补充说，并不是所有声称拥有自己项目方法的公司真的拥有。一些是意识到的，而另一些则看不到他们所实施的东西并没有增加任何价值，不能被视为项目管理方法。让我们关注最后一个类别——那些认为自己有稳固方法论的人。他们为什么走错了路？首先要检查的是谁在组织中真正在使用它。如果没有人使用这个方法论，无论其内在价值有多好，它都没有价值。如果你的方法论只存在于纸面上和演示文稿中，那么它实际上并不存在。你怎么知道呢？这是一个简单的问题，答案也很简单：通过检查或（更好的是）通过控制。像“你使用这个方法论吗？”这样的问题不会给你答案。你需要通过定期检查谁在使用方法论以及他们使用的是哪些部分来深入挖掘。这种质量控制将揭示你方法论的真正使用情况。

你需要问的第二个问题是你的方法论提供了什么价值。它真的有所改变吗？它的内在价值是什么？有时看起来有些人对基于阶段的方法感到满意。“只要我们定义了阶段，我们就在安全的一边”是他们的推理。阶段象征着公司在项目管理方面的专业知识，并保证不是所有工作都同时进行。它们表明规划和里程碑是公司实施方法的关键要素。这种方法可以总结为三个词：阶段、规划和里程碑。我们都知道这些都是项目管理方法论的有价值元素，但它们并不构成方法论完整的价值提供。当你只实现了建筑的外壳时，你不能说你有一座房子。在这个阶段，建筑还没有提供我们期望的房子功能。它不能保护，也不能提供任何舒适。只包括这三个元素的方法不能称为项目管理方法。这是因为它不能提供实现我们项目目标所需的基本主动功能和有效的程序和工具。

为什么以质量为导向的公司更喜欢项目管理

以质量为导向的公司寻求持续提高其服务和产品的质量水平。在这个过程中，他们已经走了很长的路，利用了现代的质量控制和改进方法。你可能遇到过使用诸如ISO（国际标准化组织）、全面质量管理（TQM）、六西格玛、精益生产或戴明循环等方法的客户组织。如今，质量意识已成为常态而非例外，因为多年来质量已成为一种竞争工具。其中一个最好的例子是丰田。他们成为了世界上最大的汽车制造商，其中很大一部分成功归功于他们的质量管理策略及其品牌化。许多其他公司也效仿，要么是受到丰田等成功质量公司的榜样启发，要么是因为他们被迫这样做。如今，许多供应商别无选择，但需要遵守如 ISO 等标准。作为 IT 专业人士，我们无需远观，就能在我们的日常工作中看到质量管理正在兴起。信息技术基础设施库（ITIL），它是广泛采用和一致的IT 服务管理（ITSM）最佳实践的文档，以及能力成熟度模型集成（CMMI），一种帮助组织提高其绩效的过程改进方法，都是描述今天 IT 部门如何运作的模型。

近年来，质量控制和质量保证流程的焦点也发生了转变。质量经理们希望预防缺陷，而不仅仅是检测它们。他们希望通过不断从以往的经验中学习来主动管理。因此，当你计划在这个类型的公司中实施一个软件解决方案时，如果他们正在寻找一种展现主动能力的质量方法，这并不令人惊讶。为此，你不仅需要有一个良好的实施方法，还需要能够捕捉、展示和实现这一方法的真正价值。仅仅几页关于阶段、会议和计划表的幻灯片将不再足够。让我们直言不讳——质量管理正在兴起，这将对客户期望你如何管理项目产生重大影响。你不能再通过个人的努力和英雄行为来销售质量。相反，你需要展示一个可重复、集成和标准化的方法。

项目成功的四个支柱

在上一节中，我们讨论了为什么我们需要项目管理以及我们如何克服对它的抵制。在本节中，我们将讨论构成项目方法论内在价值的最重要要素。

当评估支持项目交付策略的不同方法时，人们很容易在细节中迷失方向。面对众多程序、步骤、活动和文档，他们在黑暗中摸索，寻找真正的内在价值。本节将为您提供在寻找支持实施方法过程中的四个宝贵指标。

沟通很重要

我们都知道沟通在项目成功方面的重要性。当我们思考一些不太成功甚至失败的项目（当然，只是一小部分）时，我们经常将它们归咎于沟通不良。我们通常不会四处责怪项目失败是由于我们的电子表格中的公式错误，或者我们的规划软件产品中的系统错误，但沟通不良始终是一个有效的理由。那么，我们这是什么意思呢？这是否意味着我们没有说够？我们是否有足够的会议，或者我们应该更多地联系我们的客户？实际上什么是良好的沟通？

沟通无处不在，存在于我们做的每一件事中。据估计，我们一天中有四分之三的时间以某种方式在沟通。通过沟通，我们引导和管理我们所做的事情。其中大部分时间用于说话和倾听，而只有一小部分时间用于阅读和写作。

同意，阅读和撰写项目文档很重要，但这并不意味着我们真正在沟通，因为这还涉及到说话和倾听。做一个好的倾听者是良好沟通的必要要素。希腊斯多葛哲学家爱比克泰德曾经说过：“大自然给了我们一张嘴和两只耳朵，这样我们就能听到两倍于我们所说的话。”

我们中的大多数人已经在日常的项目工作中体验过这一点。我们通过沟通来管理项目。电话、电子邮件、会议、现场会议和聊天都是我们项目管理工具集中的关键要素。通常没有人会提到这一点，但关于那些似乎没有人阅读的项目文档的抱怨却很多。有时，这感觉就像是在图书馆里放书，而没有人来访问。

在规划有效的项目沟通时，我们需要考虑哪些因素？当然，我们需要沟通技巧，但即使是最有天赋的演讲者或积极的倾听者，在无法有效沟通的项目中也无法满足沟通需求。

下述四个部分中涵盖的实用规则对于有效的沟通是必不可少的。

规则第 1 条 – 沟通需要互动

沟通是两个人或更多人之间的双向活动。它通常由互动或事件触发。为了使良好的沟通成为可能，您需要相应地规划项目互动。没有客户互动，良好的沟通将难以实现。以下图表展示了在实际实施中典型的计划客户互动水平：

在销售过程中，我们通常与客户或潜在客户有很多互动。会议、后续电话、演示、客户访谈和账户管理访问都是计划中的互动管理的一部分，目的是达成交易。正因为这些互动，我们也有可能与客户的利益相关者进行良好的沟通。与他们互动意味着我们必须与他们交谈并倾听他们，这是有效沟通的基本条件。

当实际实施项目进入分析阶段时，我们通常仍然通过启动会议、研讨会和面试会等方式保持足够的计划互动。然而，在这些活动之后，互动水平可能会显著下降。在设计和发展阶段，我们在进行技术和功能设计以及执行开发活动时，往往会将自己孤立起来。有些人将这种现象归咎于项目生命周期这些阶段涉及技术顾问。这是由于人们对技术顾问的典型看法。这些顾问在设计和发展活动中开始变得非常活跃，并且以不是最好的沟通者而闻名。如果你是这样想的，你可能需要重新思考。问题不在于有些人以集中的方式完成任务，他们需要隔离的环境。相反，问题在于没有计划其他触发客户互动的活动。这种缺乏充分计划客户互动水平的规划，会危及你的项目沟通。这会创造一个“沟通黑洞”，如果设计和开发阶段的持续时间很长，这个黑洞可能会相当大。想想看：没有客户互动意味着没有沟通和客户参与。

当我们开始为新系统准备上线时，客户互动水平突然再次上升。这是因为我们通常过度计划了部署阶段。在设计和开发阶段没有计划的所有事情都需要在部署阶段完成，这导致了大量的客户互动。现在，在经历了数月的客户互动和沟通水平较低之后，我们突然需要不断地沟通和互动。这对咨询和客户团队来说不会容易，因为他们现在缺少沟通惯例和文化。在这种场景下，你也需要在短时间内进行大量沟通。你的沟通接收者可能会在继续理解所有内容时遇到问题，并可能因此产生一些（额外的）抵抗。

互动沟通必须在整个项目生命周期中均匀分布，而不是集中在几个时刻。这种沟通的存在取决于你的规划。项目沟通失败的原因不一定在于你人们的沟通技巧不足，但可能是项目生命周期的组织本身。

第二条规则——电子邮件不等于项目沟通

你可能会认为人们使用电子邮件沟通是因为这让他们可以待在自己的舒适区。传递坏消息、通知决策和请求问责，从舒适的椅子和桌子前进行要比面对面交谈容易得多。没有必要改变位置。你只需写下你想说的话（你的机器不会批评你的信息），然后你可以按照你的意图发送信息：轻松、快速、高效。

是的，电子邮件沟通在所有可能的方式上都是无与伦比的方便。这使得它变得不可或缺，使用电子邮件进行沟通没有错。然而，由于其便利性，它也有已知的陷阱。电子邮件是会上瘾的，我们倾向于在所有情况下、为所有沟通都使用它。这种上瘾不会使我们的项目沟通变得更好。良好的项目沟通还需要定期的互动，包括积极的倾听和说话，以及非言语沟通。

面部表情、肢体语言和语调可以为你提供关于人们情绪、动机、压力水平等方面的宝贵信息。研究表明，当我们沟通时，我们接收到的 80%的信息都是以非言语沟通的形式出现的。这也体现在一句中国谚语中：“笑不露齿，必有深意”。如果你只使用电子邮件作为沟通手段，你就无法识别这类信息，从而错失了适当回应的机会。卡尔·波普尔爵士指出，不可能以任何方式说话而不会被人误解。在使用电子邮件时，被误解的可能性肯定更高。作为项目经理，你需要激励利益相关者和团队成员，推销你的观点和愿景，传达决策，并带来好坏消息，而且你需要持续这样做。在这些情况下，你的沟通效果将决定你作为项目经理的成功。你需要确保你被充分理解。

你还需要意识到，人们可能比你计划的时间晚得多地阅读你的电子邮件。即使标记为重要或紧急，你的信息也可能最终出现在一长串未读电子邮件中。因此，尽管电子邮件的传递是即时的，但你的电子邮件沟通实际上并不真正发生在实时。

是的，电子邮件很方便，有时也很有效，但并非总是如此。你需要定期走出你的舒适区，面对你的团队成员和利益相关者，而且你需要从一开始做到项目结束。

第 3 条规则——简洁

文档是项目沟通组合中的重要元素。它们支持会议，向团队成员和利益相关者提供信息，为项目决策提供依据，并促进验证和关闭过程。项目文档是沟通的重要输入，但遗憾的是，并非所有文档都具有实现这些目标的内在质量。正如之前所说，有很多关于那些似乎没有人阅读的项目文档的投诉。这些类型的文档不支持或促进任何事情。它们只是作为所谓质量方法的借口，但通常只是通往文件柜的单程票。大多数人将这些文档视为浪费时间，并导致人们错误地将项目管理视为官僚活动。那么，什么样的内在元素构成了好的项目文档？

最重要的事情之一是确保你文档的可读性。进行项目文档编写并不是一场写最多页数的比赛。一篇长篇大论，说些无意义的话，比一篇简洁的文档要容易得多。大多数这些长篇的项目文档都是无结构的，缺乏好的结论，包含太多的灰色地带。它们也往往在内容上失去平衡，包括过多地关注引言和简单话题，而在更复杂且重要的问题上缺乏好的内容。这使得这些文档不仅难以阅读，而且内容也不完整。我们为什么需要这么多纸张来承载微不足道的内容？现在，假设你站在客户的角度，一分钟。这些类型的文档没有仔细阅读是否令人惊讶？你会愿意阅读一份五十页的文档，缺乏细节和结论吗？

你还应该考虑到，所有软件项目都会产生大量各种类型的项目文档。这意味着你的客户在整个项目生命周期中需要审查大量文档。他们需要在日常工作的基础上完成这些工作。所以，不要期望他们会阅读你所有的华丽辞藻。出于所有这些良好的理由，你需要保持简洁。

直接切入要点需要真正的努力。大多数项目利益相关者都会仔细审查项目文档以寻找行动和结论，但通常会发现未经请求的分析、背景和论点。现在我们能做什么？

首先，你需要让所有参与项目文档的团队成员都意识到这个问题。为每种文档类型指定一个推荐的最大页数将有所帮助。预先定义文档的结构，包括行动、问题和结论等部分，并确保面向客户的文档不包含过多的术语和冗长的技术描述。使用客户使用的语言进行沟通。最后但同样重要的是，一定要包括图表元素，如图表和流程图。这些元素显著提高了可读性，并将使你的内容对读者更具吸引力。

第四条规则——设定明确的期望

如果你希望在整个项目过程中让你的客户和团队参与其中，你需要努力设定关于谁将按何种方式在何时交付什么的明确期望。如果你想确保项目中的良好沟通，你需要以同样的方式向利益相关者提供关于你的沟通方法的建议。以下是我们需要解释的内容：

• 与谁进行沟通

• 谁将进行沟通

• 要沟通的内容

• 如何进行沟通

• 何时进行沟通

这有时也被称为“沟通计划”，有些人常用，但对其他人来说可能是一个令人畏惧的想法。无论你对沟通计划有何感受，都不要低估定义和解释这些沟通元素的重要性。没有这些灯塔，项目团队的沟通将不受控制且无指导。同时，你的沟通策略需要与你的整体项目生命周期组织相一致。例如，客户何时可以期待收到包含建议解决方案的需求或设计的文档的交付？你是否组织会议来讨论这份文档？如果是这样，谁应该参加？你是否需要验证这份文档，以及谁有权限签字？所有文档都需要签字吗，还是只有少数需要？客户在签字前有多少时间？如果他们不签字会有什么后果？这与基于阶段的做法有何关系？在客户能够参与你的游戏之前，他们需要相当多的信息。

一旦客户知道可以期待什么以及如何沟通，你需要实践你所宣扬的。

积极的态度是关键

项目成功高度依赖于你的主动性能力。有时，项目经理表现得更像是一个电子表格大师而不是管理者。他们使用并维护复杂的电子表格，其中集中了所有项目数据。这些电子表格包含复杂的公式，为项目生成各种趋势和结果。这些电子表格本身并没有问题，但仅凭这些工具并不能管理任何事情。这些工具需要为项目经理提供指示和早期预警信号，表明某些事情需要引导或纠正。它们需要触发主动的和纠正性的项目管理行动。这正是项目管理的核心——主动和纠正性地引导项目。作为一名项目经理，你需要管理你的团队，这需要一种由电子表格等工具提供的洞察力指导的实用方法。什么可以帮助我们部署主动式项目管理？我们将在以下小节中探讨。

第 1 条规则——前瞻性思考，预防为主

主动的态度需要前瞻而不是回顾。作为一名主动的项目经理，你需要专注于预防而不是检测。你需要确保你的项目报告和工具不会详细解释你过去的失败，而是帮助你预防和解决即将出现的问题和问题。你需要做的第一件事是改变你的思维方式，从过去转向未来，从问题识别转向问题预防，从被动转向主动。

第 2 条规则——在互动中保持主动性

主动与客户和咨询团队保持持续的互动。在项目中，我们面临的问题、风险、变更、质量、范围等等，都可能影响我们的时间和成本绩效。因此，如果我们想在其他方面提供关于时间和预算的保证，我们需要主动管理这些日常风险和问题。首先，这种方法要求我们了解我们的问题和风险。我们只能通过与客户互动来识别它们。测试、验证解决方案和概念、会议以及评估时刻通常揭示我们项目的问题和风险。在互动水平较低的时候发现问题和风险的可能性非常小。其次，我们需要确保我们尽早识别我们的挑战。

采取主动意味着始终领先一步。这意味着当你已经为项目生命周期的末期规划了大部分客户互动时，你的主动管理能力将显著下降。同样，当你和你的团队将所有客户互动推迟到项目生命周期的末期时，你将失去主动管理的能 力。因此，在项目周期的开始和结束时专注于客户互动不会给你提供必要的主动机会。你如何规划和执行你的项目生命周期是成为一个主动的项目经理的关键。

第三条规则——早期预警信号的衡量标准

如果你想了解即将发生的事情，你需要识别可能出现的早期预警信号。这些信号并不总是自行引起我们的注意。如果我们没有为此做好准备，它们可能会被忽视。如果你想在你自己的项目中采取主动，你需要深思熟虑你想要衡量的内容。一个主动的管理者会阅读他们在项目中对未来活动的影响。你想要知道你当前的表现是否会导致成本和时间超支，你需要知道原因。所以，如果你正在使用高级电子表格来衡量你的表现，你需要问自己它是否告诉你关于你项目未来的某些信息，或者只是通知你这个项目过去的绩效。只有在你不是在报告空话时，你的衡量才能揭示早期预警信号。你的衡量需要基于范围、进度和成本的整合。因此，如果你没有定义你的范围、进度和相关的成本，你不能期望测量早期预警信号。

在你开始衡量之前，你至少需要以下项目基本要素：

• 将工作范围分解成更小的单元

• 为每个这些工作单元制定的时间框架计划

• 用于完成这些工作单元的资源及批准的成本

只有在那时，你才能开始考虑如何衡量绩效。早期预警的识别必须从你项目的开始就进行，并且应该定期进行。当项目完成超过一半时才开始衡量绩效不能被认为是主动的。

一些项目经理满足于二维的项目报告。他们深入研究项目数据，他们的报告看起来可能像这样：

• 预算：100 万（欧元、美元等）

• 项目持续时间：12 个月

• 花费的时间：六个月

• 已花费的成本：40 万（欧元、美元等）

在这六个月之后，项目经理向公司高管和客户报告说，他们在预算方面进展顺利。他们可能还报告说，团队表现良好，质量可以，没有重大问题即将出现。多么出色的进度报告！或者，它是吗？

这个项目经理忘记做的是将成本和时间与要交付的范围结合起来。让我们假设在这六个月里，计划交付六个单位。这里的关键问题是，在 400 万的预算下，六个月内交付和接受了多少单位？如果只交付和接受了三个单位，这个项目将遭受巨大的时间和成本超支。你需要确保你不会用不适当的测量来误导自己和你的利益相关者。如果你想主动，你需要建立一个能够检测早期预警信号的测量系统。

创建指导性项目文化

当谈到不太成功的实施时，关于客户参与的投诉如洪水般涌来。一些项目经理也表达说项目往往会获得自己的生命。在这些情况下，项目被缩小到个人执行计划和执行。客户和咨询团队似乎与任何应与此项目相关的态度、价值观、信仰、优先级和行为脱节。在这种脱节的情况下，推动团队的能量和承诺，从最初的想法到部署，将是一个难以解决的问题。作为项目经理，创建指导性项目文化值得你特别注意。

你需要确保所有利益相关者和团队成员都同意以下内容：

• 项目目标

• 此特定项目的利益

• 工作方式

• 交流方式

• 质量的定义以及如何实现它

• 在这个项目中每个人的角色和责任

• 实施此项目伴随的变化

• 与此特定项目相关的风险

• 将交付的范围

• 被视为范围之外的那些部分

这可能已经是陈词滥调，但当你把它视为理所当然时，可能会陷入陷阱。不要假设所有参与这个项目的人都是一致的。使人们一致并让他们致力于目标、利益和方法将消耗你大量的精力，但这对于你的成功至关重要。

文化是一套由一个群体共享的明确和含蓄的信念和假设，这些信念和假设塑造并协调所有成员的行为。

如果客户对目标不热情，对方法一无所知，你不能假设他们承诺你的计划。他们如果对这种方法的原因和好处一无所知，如何支持你的方法？他们需要知道对他们有什么期望，以及他们需要为计划做出多少承诺。

这同样适用于你自己的内部团队成员。他们需要同样一致，才能满足期望。无疑，采用和内在的、强大的实施方法是正确的方向。这将使团队成员能够深入了解公司是如何实施以及为什么以这种方式实施。有了这一点，将节省你宝贵的时间来调整咨询团队成员与你的方法，因为他们已经分享了这些价值观和信念。剩下的是对特定客户案例和即将到来的项目的具体总结。如果你梦想着拥有更多自我驱动的团队，你需要确保他们分享你公司的价值观和方法。

因此，在你跳入项目执行任务之前，你需要确保所有利益相关者和团队成员在信念和愿景方面以及特定项目的所有关键要素上保持一致。你需要评估这种一致性是否足够强大，能够作为你项目车辆的坚固底盘。道路将会变得崎岖，一个坚固的底盘将是一个必需品，而不是奢侈品。

关闭的重要性

对于许多人来说，关闭项目证明是一个真正的挑战。乍一看，这似乎很简单且直接。上线后和一些额外的支持，你要求客户签署项目交付的确认，一旦签署，你的项目就结束了。不幸的是，我们大多数人都有过这样的经历，那就是关闭通常不会那么顺利。事实上，许多项目永远都没有关闭。

第一个值得注意的发现是，项目团队成员没有关闭项目的实践。分析师专注于提供良好的业务流程描述和捕捉需求，开发者想要展示他们优越的技术解决方案，而项目经理则努力实现按时和按目标的关键绩效指标（KPIs）。作为一个团队，他们的主要目标是部署一个新的解决方案，然后是成功的上线。这基本上是他们关注的焦点。但是，谁负责推动项目关闭呢？对于项目经理来说，关闭并不像销售人员那样显而易见。关闭是销售周期中的关键要素，能够关闭交易是销售经理的关键优势。他们意识到这个关键过程，并不断改进自己的关闭技巧。如果我们想在项目关闭方面更加成功，我们需要开始在项目团队中实现一种关闭文化。为什么我们需要关闭，我们如何促进关闭过程，以及谁负责关闭，这是我们必须要找到答案的一些关键问题。

将项目定义为临时努力意味着项目收尾。不收尾项目将使其从项目转变为运营。不幸的是，我们没有为该运营提供预算，也许我们也没有在客户网站上管理运营的明确方式。这可能会成为一种真正的负担。如果项目未收尾，客户将继续要求各种更改、增强和各种服务，这些服务的资金将处于讨论中。你将不得不参加很多会议，试图找到妥协，以确定项目范围内和范围外的内容，并且你需要这样做，直到项目收尾。也许你的项目在 Go-Live 之前是盈利的，但在这个时候，你的利润开始被榨干。与收尾相关的还有重要的心理因素。成功的收尾会加强成功的感觉。人们在职业生涯中需要成功以保持动力，成功会激励他们继续努力，在未来项目中追求最终的成功。客户团队成员将分享为公司实现重要事物的感觉，并将这些好处与整个组织分享。毕竟，经过所有辛勤的工作和努力，他们有权享受这一刻的荣耀。当我们不收尾我们的项目时，其他心理效应将会展开。由于没有明确的隧道尽头，人们可能会对项目产生负面看法，并感到气馁。

客户团队成员不会宣扬他们新解决方案的好处。相反，他们甚至会对最小的不可避免的问题感到烦恼。你的顾问和开发人员保持对即将到来的项目动力的可能性很小，尤其是当他们已经有一系列未收尾的项目记录时。出于这些和许多其他原因，你需要持续努力提高你项目收尾的能力，就像销售人员一样。

现在什么使得项目收尾如此困难？让我们关注两个重要元素，即：

• 存在“收尾文化”

• 收尾练习的要素

客户组织需要熟悉收尾和签字确认。在部署项目后，如果你要求客户签字确认收尾，而这将是他们真正需要签字的时刻，你实现这一点的可能性很小。签字确认可能会让客户有点怀疑和不安全，尤其是当他们不了解这个过程时。通过从项目开始就应用签字确认程序，这些障碍将变得很小，因为你的客户已经熟悉了收尾流程。

结束练习本身将使一切归拢。您需要证明您的团队交付了承诺的内容，质量符合标准，并且组织可以在日常工作中使用它所定义的好处。这种证明负担需要良好的准备、强大的文件和与客户的良好关系。当您的文件已经通过长期验证周期创建时，您将获得最佳成功机会。诸如批准的范围描述文件、验证的变更请求、确认的测试结果和签发的里程碑审查文件等将使您的案例更强。此时，您可以评估您的方案有多强，在整个项目生命周期中您的沟通有多好。您能想到一种在没有这些基本要素的情况下关闭项目的好方法吗？

项目管理要素

开发和实施智能项目管理实践需要对该学科有深刻的了解。项目管理学科不能一口吃掉，因为它涵盖了各个领域和学科的知识。它处理复杂的专业领域，如范围管理、成本和时间管理、质量管理、人力资源管理、沟通管理和集成及风险管理，并且可能与其他管理学科重叠。本章并不旨在探讨所有这些领域，而是将带您踏上发现项目管理最基本要素的旅程。

项目生命周期及其阶段

当谈到项目管理和实施方法时，人们会自发地谈论他们的基于阶段的方法。如果您查看实施合作伙伴网站的内容页面，通常可以看到将项目生命周期分解为不同阶段的图表，并且当您参加合作伙伴与其潜在客户之间的商业会议时，实施方法的解释通常也是以阶段为依据的，如下所示：

该合作伙伴基于阶段的这种方法灵感来源于微软解决方案框架（MSF）。项目运行由五个不同的阶段执行和管理。每个阶段都以明确定义的里程碑交付结束，例如范围和项目计划的批准、范围执行的完成、发布准备的批准和部署的完成。

以下图表展示了这些阶段：

以下图表展示了基于阶段的更复杂变体，提供了八个阶段来管理项目：

因此，在大多数合作伙伴实施方法中，阶段很重要；但我们真的理解什么是阶段，并且我们在日常项目中是否真正尊重基于阶段的做法？让我们尝试找到答案。

什么是阶段？

阶段代表将项目生命周期分解成更小的时序单位。在瀑布模型中，通常以顺序方式从一个阶段过渡到下一个阶段。瀑布模型的目标是通过单独的阶段，在项目生命周期的早期就定义需求和设计。只有当该阶段计划的所有工作都已完成，并且所有必要的可交付成果都已生产并得到接受时，才能从一个阶段过渡到另一个阶段。以下图表展示了典型的瀑布方法：

阶段的核心在于，它们基于这样一个理念：你不能一口吃掉一条鲸鱼，而必须将其分解成小块来消化。以下图表展示了两种项目方法的示例：

项目 A被组织成四个计划阶段。活动被分组并计划在相应的阶段执行。每个阶段的执行进度都将被监控和控制。当所有里程碑可交付成果都生产出来时，阶段将关闭。

项目 B被组织成一个阶段。所有活动都计划在这个阶段执行。当所有可交付成果都生产出来或与项目收尾一起时，阶段将关闭。

假设项目 A 和项目 B 具有完全相同的目标、利益相关者、风险、时间框架、预算和范围。项目 A 和项目 B 之间有什么区别？两个项目都需要执行完全相同的活动，在相同的时间框架和预算内产生相同的可交付成果。唯一的区别是，项目 A 被组织成四个阶段，而项目 B 只在一个阶段内执行。在项目 A 中，团队只能在计划中的访谈、研讨会和文档活动完成，并且所有可交付成果都生成后，才能开始进行技术和功能设计。这将由咨询和客户项目经理进行控制和验证。在项目 B 中，团队可能在技术设计准备就绪之前就已经开始开发，并且在活动和可交付成果之间没有真正正式的评估时刻。因此，工作的性质没有改变，但通过使用阶段，你可以在定义的时刻控制和验证进度。这种方法的目的是组织和控制你的时间线，从而提高管理控制。因此，项目经理真正管理进度的能力在项目 A 中显著提高，因此项目 A 的成功几率比项目 B 高得多。

下图展示了一个典型的场景，这种情况很可能是由于项目 B中阶段过渡没有受到控制而发生的：

当不按阶段工作的时候，这种典型场景可能会发生。这里的危险在于活动和可交付成果可能会系统地被推迟。这会导致项目生命周期末尾待办事项的高度集中，并给规划和实现良好的部署带来困难。在这种情况下，直到部署阶段才报告重大问题也是很常见的，当大多数关键活动都推迟到项目生命周期末尾时，这并不令人惊讶。

到项目结束时，项目经理将诊断出越来越多的问题。知道一个阶段可能隐藏另一个阶段，项目经理很快就会意识到项目现在正进入一个风险阶段。一个典型的问题是：“我们为什么之前不知道这一点？”你只需查看这样一个项目生命周期的规划就能找到答案——你试图一口吃掉这条鲸鱼，而这口吃得太糟糕了。

尊重基于阶段的处理方法

如果你的实施方法包括基于阶段的处理方法，并且你真的支持这种方法，确保你也实施了真正的基于阶段的实践。仅仅在演示文稿上命名阶段并不能真正为你的实际项目做出贡献。不尊重基于阶段的处理方法会通过以下特征表现出来：

• 没有正式关闭阶段

• 在完成前一阶段计划的可交付成果之前启动新阶段

• 计划不足和计划过度阶段

如果你没有正式关闭你的阶段，并在未完成前一阶段的工作的情况下转向即将到来的阶段，你就没有尊重阶段的基本功能。这意味着你将失去这种方法的益处。这不仅会剥夺你按阶段跟踪进度能力，你还会错过与客户一起在沟通和关闭文化上工作的绝佳机会。实施阶段可以逐步引入关闭文化，带来巨大的益处。如果你与客户一起使用标准程序关闭每个阶段，他们将在整个项目生命周期中非常熟悉关闭过程。围绕这些正式时刻建立沟通只会对你有利。

下面的图展示了某个阶段计划不足而其他阶段计划过度的项目生命周期：

上述图清楚地显示了活动在阶段间规划上的不平衡。你可以从这个图中得出结论，项目是在两个阶段而不是四个阶段中管理的，存在一个计划过度的部署阶段。

因此，如果你真的想使用基于阶段的方法工作，你需要确保你尊重这种方法的功能，并以平衡的方式规划你的阶段。如果你忽视这些基本规则，你必须得出结论，你的实施实践不是按阶段管理的。

项目管理流程

项目管理流程代表了一组逻辑上相关的活动，这些活动旨在产生一组特定的可交付成果。每次你需要产生可交付成果时，你都需要验证目标，规划你将如何执行，在执行的同时控制这一执行，一旦准备就绪，就通过促进这一关闭的过程正式关闭任务。

在下面的图中，你可以找到由 PMBOK 定义的项目管理流程：

启动流程帮助你定义并获得对新项目或阶段的授权。规划流程帮助你确定项目的范围，细化目标，并定义实现项目或阶段的目标和可交付成果所需的方法。执行流程代表了完成计划的可交付成果所执行的活动。这涉及到协调人员和其它资源以执行计划。跟踪和审查进度和状态所需的流程，以及识别与计划偏差的流程，都汇集在控制流程下。一旦完成，每个任务、阶段或项目都应通过促进这一关闭的过程正式关闭。这些流程被称为关闭流程。

这些过程与你的项目时间线阶段分解不同。实际上，项目管理过程在每个阶段都会发生（或应该发生）。根据阶段的不同，占主导地位的过程将得到实施。在项目准备阶段，例如在诊断和分析阶段，启动和规划过程可能更为突出，但这并不意味着那些将是该阶段唯一的过程。你还需要在分析阶段有执行、控制和收尾过程。

重要的是要注意，你始终需要关注收尾过程。收尾过程需要在每个阶段或迭代中发生。收尾不是你专门需要为项目生命周期的结束保留的事情。

上一张图表传达了你的规划结果将指导执行和控制过程，就像双向交通一样。你如何执行这些过程将影响你的规划，控制可以揭示规划变更的必要性。一旦你开始执行产生该阶段计划交付成果所需的工作，你就需要开始监控和控制这个过程。然而，这需要通过纠正措施对你的执行产生影响。如果你的监控对执行没有影响，你可能会白费力气。

打破它！

如果你需要做一件事情来使你的项目变得可管理，那将是将其分解。你应该意识到你的项目生命周期分解成更小的时间单位，如阶段，但分解你的范围同样重要。最好的项目计划基于良好的分解。当你为孩子（或自己）买玩具时，你可以找到优秀的项目计划。一个很好的例子是乐高中的紧急医生车。这包括教科书或理想的项目计划。

以下图表显示了世界上最好的项目计划：

上一张来自建筑说明图的图表为你提供了范围的明确定义。你将立即知道要建造什么，不要建造什么。下一张图表说明了乐高精通制作坚如磐石的项目计划。建筑说明图由步骤和子交付成果组成。这个建设项目将在十三步中执行，每一步都会产生明确定义的子交付成果。

例如，在第5步中，你需要生产上一张图表中显示的子交付成果。你只能在完成第4步，并且子交付成果1、2和3已经组装完毕后才能开始做这件事。

每一步都采用相同的方法。要完成第 6 步，你需要完成第 5 步并产生第 6 步中的额外子交付成果。乐高建筑说明计划是基于瀑布方法和子交付成果分解与创建的项目管理技术的优秀项目计划。你是否意识到你的孩子已经掌握了这些技术？

大多数项目管理方法论都提倡使用工作分解结构（WBS）。WBS 是基本的项目管理技术，通过使用分层树结构定义和组织项目的总范围。

在 1976 年，由Russell D. Archibald所著，John Wiley & Sons, Inc.出版的《管理高科技项目和计划第三版》一书中，将 WBS 定义为项目的一种图形表示，通过逐级探索，直至达到有效规划和控制所需的详细程度。它必须包括所有可交付的最终产品和必须执行的主要功能任务。

WBS 的前两级定义了一组代表项目范围 100%的计划结果。一个设计良好的 WBS 描述的是计划的可交付成果，而不是计划的活动。这些重要的可交付成果比活动更容易控制。我们需要关注已经产生的内容，而不仅仅是努力；活动不是成就。未包含在 WBS 中的可交付成果或工作不属于项目范围。

以下图表展示了一个 Dynamics ERP 项目的可能 WBS 结构：

你的 WBS 可能看起来像前面的图表，但可能以完全不同的方式构建。PMI 的 WBS 标准化委员会传达了以下信息：

“项目经理可能会遇到许多不同的情况，PMI 对他们的选择施加限制是不恰当的。WBS 是一种可以根据项目经理的需求以不同方式使用的项目管理工具。因此，不应随意设定 WBS 创建的限制。”

WBS 代表了项目经理计划如何管理项目的方式。这包括规划、估算和控制，所有这些都基于 WBS。这样，WBS 是你整合范围、成本和时间的终极工具。它也是一个在项目内部实施“通用项目语言”的优秀工具，使项目沟通更加顺畅。

从估算到跟进

我们无需解释良好估计对于任何项目成功的重要性。时间和成本估计定义了你在即将到来的项目中的舒适区，而我们大多数人，在某个时候，都曾经历过低估项目的情况。研究表明，大部分成本超支都是由不良的估计技能引起的。此外，当被要求对新项目的时间或成本估计时，人们通常倾向于低估，而我们通常需要在项目详细信息尚未可用时提出估计。尽管如此，利益相关者更喜欢在不确定性是唯一确定性的情况下获得准确的成本和时间估计。更高的准确性需要更多的努力，从而增加了时间和成本。为了使其完整，项目估计过程不能现成购买。没有共同的行业标准来估计软件包实施规模。快要绝望了吗？等等，有很多良好的估计技术被记录下来，你可以找到大量关于这些问题的文献。

WBS 作为一种估计工具

我们想引起你注意的一个要素是，我们大多数人倾向于低估项目的原因之一。可用性是一种认知启发式方法，决策者依赖于 readily available 的知识，而不是检查其他替代方案或程序。换句话说，人们难以想象事件可能展开的所有方式，而看不见等于忘记。因此，我们倾向于假设一切都会按预期进行，这使得我们在项目生命周期开始时对自己的估计过于自信。

现在我们能做什么呢？我们可以尝试很多事情，比如为项目可能的发展情况编写替代脚本，绘制所有可能出错的事件的层次图，明确假设，并要求他人对我们进行挑战。WBS 是你估计工具集中的一个优秀工具，它将防止你在估计过程中假设和忘记太多事情。创建 WBS 将使你思考项目中的许多可能事件。更好的是使用 WBS 模板。这些是基于以前项目开发的 WBS。如果你结合使用你有关联模板 WBS 的项目类型，你的估计准确性肯定会提高。

我们还想引起你注意的另一个要素是估算的主题。我们通常估算解决方案的大小或包的复杂性，包括如满足业务流程要求的配置工作，以及为解决应用程序中的差距而生成定制对象的努力。在这种情况下，我们还评估实施和业务复杂性，但我们有时会忘记考虑组织复杂性。最近的研究表明，实施努力不仅随着为实施所选模块和子模块数量的增加而增长，而且每个用户还会增加一个组织成本成分。我们需要确保我们在估算范围内包括所有复杂性。当我们在我们客户的组织中的不同部门实施我们的解决方案时，这也可能非常相关。不同的部门将会有不同的用户，他们可能在软件解决方案和程序方面拥有不同的经验和技能。以下图表说明了如何组织你的 WBS，以便它将有助于估算不同部门的复杂性：

基于 WBS 的跟进

你只能跟进你所计划并估算的内容。在某些情况下，项目报告与计划估算的内容脱节。用于估算和初始报价的分解可能完全不同于后来计划和控制的活动。看起来估算、规划和监控似乎各自为政。你不能期望在这些情况下取得出色的管理成果，成本和时间超支的可能性很高。WBS 用于定义工作包以及开发和跟踪项目的成本和进度。一旦你定义并计划了可交付成果和工作包，你可以轻松地使用不同的可能监控技术来跟进它们。

你可以考虑使用的一种技术是“挣值”概念。在 Quentin W. Fleming 和 Joel M. Koffleman 合著的《挣值项目管理第二版》一书中，项目管理协会，Inc.描述了挣值关注的重点是准确测量实际绩效与详细计划的对比，以便准确预测给定项目的最终成本和进度结果。他们还指出，WBS 是挣值概念的一个组成部分。原因在于，挣值概念需要将技术工作范围与时间承诺和授权资源整合起来。

WBS 作为一个核心概念

以下图表说明了 WBS 在你项目中的好处：

WBS（工作分解结构）是你在制定估算和计划时的起点和控制点，它来源于活动列表。它是实现活动监控和报告的必要整合工具，并在整个项目中充当全球沟通工具。这些是从易于使用的工具中获得的显著好处，因此值得在你的实施实践中使用。

采用项目管理

正如你可能听说的，没有免费的午餐。适应新的方法，包括新的愿景、新的程序、步骤、文件和工具，需要持续的努力和管理。本节将向您介绍项目管理采用方面的变化，并解释为什么变革倡议会失败。

不懈追求完美的浓缩咖啡

我们或许可以从咖啡豆中学到一些东西。当我们提到咖啡时，你可能想到的是Illy。1933 年由弗朗西斯科·伊利创立的伊利咖啡生产和销售独特的优质咖啡混合物。埃尔内斯托·伊利在巴西和其他地方的咖啡种植上进行了革命。在他的不懈追求完美浓缩咖啡的过程中，他鼓励生产高质量的咖啡和持续的研究投资。伊利先生在 2001 年对《纽约时报》说：

"我们的目标是完美的豆子，零缺陷，我们认为我们接近了这个目标。"

他还说：

"制作一盎司浓缩咖啡需要 50 颗豆子。一颗坏的豆子，我保证你会尝到它的味道。就像煎蛋卷中的一颗坏鸡蛋。"

微软合作伙伴不做咖啡；他们从事各种项目，这是他们的业务。如果你有一个糟糕的项目，你肯定会尝到它的味道。利润下降，客户满意度下降，更重要的是，员工的满意度也不会变得更好。那些几个失败的项目是你公司煎蛋卷中的坏鸡蛋。

因此，这应该是你的目标：完美的项目，零缺陷，并尽可能接近这个目标。这可能是显而易见的，但再次强调，这并不容易。你需要确保你所有的项目在所有时候都取得成功。这是一个持续的努力，涉及到你团队中的每个人。每个人（销售、项目管理、顾问和开发者等）都需要保持一致，知识渊博，目标导向，并积极主动。你和你的流程是你那杯浓缩咖啡中的豆子。

接受变化

适应项目管理方法并不容易。马克·吐温说：

"我完全支持进步，我不喜欢变化。"

这需要一支大团队持续且真诚的努力。除了持续的努力，还有变化的因素，正如我们所知，变化并不容易。它要求人们改变他们目前的工作方式，适应新的程序和工具。你需要从基本要素开始，比如获得高管的认同，来准备面对强烈的阻力。如果没有高管和管理的支持，你的变革计划注定会失败。因此，高管团队必须确认有需求和适应新或改进方法的紧迫理由。他们需要有一个强烈的愿望来解决已知的业务痛点，并且他们必须与整个组织分享和传达适应新程序的重要性。《我们的冰山正在融化》第一版，由约翰·科特著，圣马丁出版社出版，描述了变革倡议失败的原因有十个。具体如下：

• 低估了对明确变革愿景的需求

• 没有建立实质性的联盟

• 没有清楚地传达愿景

• 没有产生与改进绩效相关的紧迫感

• 没有制定短期胜利的计划

• 没有领导和指导商业行为的变革

• 管理者未能运作在并超越日常执行之上

• 没有践行你所宣扬的

• 允许对愿景的阻碍

• 没有在企业文化中确立变革

这不应该阻止你开始你的变革计划，因为回报是巨大的，你的业务、客户和员工都将从质量改进的举措中受益。但你应该意识到，成功实施变革需要巨大的努力。

不可或缺的组织利益

在上一节中，我们发现我们在采用坚如磐石的项目管理方法的过程中会遇到许多陷阱。涉及到的变革过程将需要整个组织的持续和显著的努力。现在让我们专注于收获果实。对我们来说，这有什么好处？为什么我们要为所有这些努力做计划？

你公司的一项核心竞争力

通过成功适应内在的、强大的实施方法，它成为你公司的一项核心竞争力。这意味着你的公司在理解客户需求、按时按预算管理项目以及设计和开发超出客户期望的解决方案方面表现出色。这将使你的公司在市场中独树一帜，同时以竞争对手难以模仿的方式为你的客户提供独特的利益。

有利可图的计划

项目是独特且暂时的努力，面临持续的风险和许多不确定性。有效的、深思熟虑的项目管理是实现和维护项目利润的必要条件——对于通过提供项目服务赚取收入的公司来说，这是一种经济上的必要条件。根据 Gartner 等独立研究公司的研究，那些将实施方法论发展到一个核心竞争力的水平的企业，将获得以下好处：

• 表现优异的合作伙伴能够以更快的速度与新客户达成交易

• 表现优异的合作伙伴在提供的服务中保持高质量的形象，同时，赚取更多的利润

• 表现优异的合作伙伴致力于提供可重复的服务交付，享受着较低的项目积压和有利的利用率

满意的客户和快乐的员工

在服务公司中，员工是至关重要的资产。这就是为什么人力资源部门投入时间来招聘合适的员工，考虑到他们的知识和他们对公司的承诺。快乐的员工通常更有动力，他们将自己的动力与公司目标对齐的程度与客户的满意度相关联。每位员工都需要在日常工作中有成功的体验。排队等待未完成和失败的项目是对员工动力的啃噬。不用说，客户满意度也与你的项目成功直接相关。坚实和有效的项目管理实践将显著提高你的项目成功率，这一点已被许多独立的咨询调查和报告所证明和说明。当你的公司发展到一个实施方法论成为核心竞争力的水平时，你的客户和员工将会更加快乐。

摘要

在本章中，我们探讨了项目管理领域的兴起和变化。我们发现，一些基本且必要的项目管理技术可以轻易地在我们对项目管理的处理方式上产生巨大差异。明智规划的项目生命周期和阶段，以及尊重基于阶段的处理方法和如 WBS 等简单技术，将为你的项目服务链带来即时价值。我们还了解到，通过保护项目成功的四个支柱，可以为你的项目车辆提供坚实的底盘，这是应对坎坷道路的完美保障。不要被怀疑者的项目管理批评所误导。我们了解到，他们的论据不足以削弱对项目管理的需求。然而，我们必须考虑并将新方法的实施视为一项组织变革管理倡议。

在下一章中，我们将了解并体验 Microsoft Dynamics Sure Step 如何赋予你销售新实施项目的力量，以及它如何为你即将到来的项目提供高效的准备。

第五章：使用 Sure Step 实施

在上一章中，你发现了项目管理学科，并了解了项目管理的基本要素、项目成功的四个支柱、项目管理的采用和组织利益。你还发现，通过执行诊断阶段的既定活动，其中一个结果是客户和服务提供商对业务需求和所需解决方案的愿景达成共识；从而为预期解决方案的高质量交付奠定了基础。

本章基于我们对客户情况的学习，讨论了 Sure Step 如何帮助服务提供商按时、按范围和按预算交付预期解决方案。在本章中，你将发现：

• Sure Step 中的实施方法，包括阶段和跨阶段的概念

• 基于瀑布的实施项目类型，包括快速、标准和企业项目类型

• 如何设置解决方案推广计划

• 对 Sure Step 瀑布实施每个阶段的详细描述

• 灵活的实施项目类型

Sure Step 中的实施方法

Sure Step 方法论为解决方案交付提供了两种不同的实施方法：瀑布和敏捷。解决方案交付的瀑布方法是一个顺序过程，描述了从一阶段到另一阶段的线性活动流程，最终将解决方案提升到生产并投入运营。相比之下，敏捷方法代表了一种迭代解决方案开发方法，它促进了拥有和指定解决方案需求资源的资源与负责解决方案开发和推广的资源之间的协作过程。

阶段和跨阶段的概念

保持瀑布方法的原理，Sure Step 提供了基于瀑布的项目类型，这些类型将活动组合在五个垂直实施阶段中：分析、设计、开发、部署和运营。这些阶段及其活动将在本章后面详细说明。Sure Step 还将其活动分为横向泳道，或称为 Sure Step 中的跨阶段流程，我们将在本节中详细讨论。

跨阶段流程是 Sure Step 的关键方面，因为它们允许对跨越项目多个阶段的相关活动进行逻辑分组，突出实施努力特定方面的活动流程。跨阶段流程突出了分组中活动之间的依赖关系，以及与其他跨阶段之间的相互依赖关系。这种分组还可以为方法论的用户提供角色视图或旋转点，例如描绘项目经理、培训师或开发者将领导的活动系列。

敏捷项目类型将活动分组到冲刺周期中。冲刺周期的活动包括解决方案的分析和规划、解决方案设计以及解决方案的开发。在开发之后，敏捷项目类型利用基于瀑布的方法的部署和运营阶段，以帮助以一致的方式推出解决方案。我们将在后面的章节中讨论敏捷项目类型中阶段和跨阶段的使用。

下面的截图显示了阶段和跨阶段过程如何在 Sure Step 基于瀑布的项目类型中体现：

Sure Step 将活动划分为九个跨阶段流程，这些流程被分为三个区域：组织、解决方案和技术。

• 三个组织跨阶段是：

  • 项目管理

  • 培训

  • 业务流程分析

• 解决方案跨阶段是：

  • 需求和配置

  • 定制编码

  • 质量和测试

• 技术跨阶段是：

  • 基础设施

  • 集成和接口

  • 数据迁移

每个跨阶段可以包括多个活动；然而，根据项目类型的不同，跨阶段流程可能被使用也可能不被使用。例如，在快速项目类型中，定制编码或集成和接口的跨阶段没有列出任何活动，因为快速项目类型旨在提供现成的解决方案交付。这将在下一节中更详细地解释。

基于瀑布的实施项目类型

为了应对客户实施合作的规模和复杂性，Sure Step 为用户提供三种基于瀑布的实施项目类型和一种基于瀑布的升级项目类型的选择。本节的重点将是三种基于瀑布的实施项目类型：快速、标准和企业。Sure Step 提供的升级项目类型将在第七章 使用 Sure Step 进行升级 中介绍。

快速项目类型

快速项目类型在 Sure Step 基于瀑布的项目类型中代表了最简单的交付方法。快速项目类型旨在实现 Microsoft Dynamics 解决方案的现成实施，这本质上意味着对标准解决方案的零或最小定制。

快速项目类型为上线解决方案指定了十四个活动，因此它在 Sure Step 中被定位为一个精益或加速交付的方法。当然，活动数量相对较少并不直接转化为更少的实施小时数，但它确实意味着一种简约的方法，需要客户和咨询团队极端的纪律和辛勤工作。这是因为这种精益方法不考虑任何失误的时间——它在项目的预算和资源配置结构中没有余地。

以下是对快速项目类型的截图，包括左侧导航树中显示的活动：

在选择快速方法之前，在诊断阶段，服务提供商和客户确定标准微软 Dynamics 解决方案与客户需求高度匹配，并且不需要进行重大定制或附加独立软件供应商（ISV）解决方案来补充标准解决方案，这一点也非常重要。如果经过适当的尽职调查确定存在高度匹配，快速项目类型确实可以名副其实，提供快速解决方案的交付。如果咨询团队或客户团队中的任何一方明知需要额外的严谨来开发解决方案，却故意选择这种项目类型，那可能会成为灾难的导火索。

以下是在使用快速项目类型时的理想条件：

• 客户需求与所选微软 Dynamics 产品功能之间存在非常高的匹配度。一般规则是寻找大约 90%或更高的匹配度来证明使用快速项目类型的合理性。

• 为了满足客户需求，可能不需要或只需要极少的定制，解决方案也不包括任何 ISV 解决方案。如果他们的需求被归类为与规定解决方案的差距，他们只需要进行简单的定制代码开发工作。

• 业务流程分析不在快速合作范围内。快速合作需要客户承担这项工作，这不是咨询团队的要求。

• 显著的集成或与第三方源接口不在服务范围之内。为集成外部来源编写代码可能充满超出交付团队控制的因素。因此，如果解决方案需要集成和接口开发，采取简约方法是不推荐的。

• 从遗留系统或第三方系统迁移到预期解决方案的过程是直接的，或者它不在服务范围之内。就像与第三方源的集成一样，从外部来源提取数据引入了超出交付团队控制的因素，因此不推荐这样做。

从一般客户概况的角度来看，快速项目类型通常用于部署 Microsoft Dynamics 解决方案的小到中型企业。这些公司中解决方案的典型用户数量较少——最多 25 人。解决方案的使用场景可能包括公司从自建遗留系统或不再支持其增长的小型系统中移除。这些客户必须在诊断阶段完成选择过程，以确定与 Microsoft Dynamics 解决方案的良好匹配，并且会寻找在相对较短的时间内以有限的功能投入生产的解决方案，以便快速实现解决方案的价值。

此外，符合快速项目类型配置的客户可能在业务和 IT 方面都有相对较少的用户，并且有实施或使用 ERP/CRM 解决方案或涵盖组织大部分领域的解决方案的先前经验。在这个领域的相对缺乏经验要求客户选择一个了解他们愿景并能提供满足其需求的解决方案的良好合作伙伴。对于客户来说，向更标准化的解决方案部署倾斜也是明智的。因此，选择快速项目类型更为可取，这样他们可以从一个更直接的解决方案开始，并在跳入复杂解决方案场景之前积累经验。

虽然快速项目类型的典型用途是针对小型企业，但重要的是要注意，这种项目类型不应仅限于客户规模。当你超越组织规模，观察使用模式和需求时，你可能会发现其他适用于此项目类型的用例。例如，快速项目类型也可能适用于多站点部署，其中解决方案已经开发并交付到第一个站点，并且非常相似的解决方案正在被交付到其他站点。

标准项目类型

Sure Step 标准项目类型适用于大多数 Microsoft Dynamics 项目，因此是最广泛使用的。此项目类型包括所有九个跨阶段的活动，以支持定制、集成、接口以及业务流程分析。因此，标准项目类型适用于典型的中规模、单站点实施。

下一个截图是 Sure Step 中的标准项目类型。截图包括左侧导航树中显示的活动部分视图，表明每个跨阶段都有额外的严重性：

标准项目类型最适合那些发现他们的解决方案需求与相应的 Microsoft Dynamics 解决方案有相当高匹配度的中等至大型企业。匹配度的经验法则大约在 70%到 80%，但更重要的是，所需的定制不应过于复杂，在这种情况下，企业项目类型可能提供一种更严格的方法来管理自定义代码开发过程。

标准项目类型的用法场景包括以下内容：

• 客户的需求可以通过选定的 Microsoft Dynamics 解决方案得到相当高的满足度（大约 70%到 80%的匹配度），这可能包括也可能不包括除核心 Microsoft Dynamics 解决方案之外的 ISV 解决方案。标准项目类型中的活动为服务提供商提供了更多关于如何与 Microsoft Dynamics 解决方案一起设置 ISV 解决方案的指导，因此标准项目类型比快速项目类型更合适。

• 业务流程分析活动包括在内。Sure Step 最广泛使用的功能之一是包含的广泛业务流程图。这些流程图为客户和服务提供商提供了一个极好的起点，从使用标准 Microsoft Dynamics 解决方案功能的角度来映射他们未来的工作流程。流程图不仅允许客户的最终用户以图形方式理解解决方案功能是如何设计的来操作，而且也允许他们可视化他们的当前流程如何适应新系统，以及是否有机会通过简单调整流程来减轻对复杂定制的需求。这一点对于解决方案的长期前景和总拥有成本（TCO）的重要性不容小觑。

• 组织变革管理（OCM）被确定为与客户互动的关键学科，尽管其需求不如大规模合作那样严格。

• 对于被归类为差距的需求，需要自定义代码开发，规定的解决方案从简单到复杂，但不是过于复杂，如前所述。对于高度复杂的定制，企业项目类型中额外的严格性可能对客户和服务提供商更有利。

• 自定义代码开发可能包括与第三方源集成的集成或接口，以及从旧系统或第三方系统迁移数据到预期的解决方案。同样，建议不要使这些编码工作过于复杂。

标准项目类型的客户特征是拥有相当数量的系统用户——通常多达 250 人。随着组织各部分用户数量的增加，解决方案不仅需要考虑每个业务单元的多样化需求，还需要处理这些单元之间的相互依赖。因此，可以预期对标准解决方案进行适度到复杂的定制，以适应客户的业务流程。该解决方案还可能需要从数据集成、报告和商业智能系统或数据仓库的角度与几个子系统进行接口。

中等至大型段的客户通常也拥有相当数量的经验丰富的业务和 IT 用户，他们使用并部署了其他非遗产业务解决方案。在这个领域，平均可能有 20 年的全职业务经验，以及 10 年的 IT 经验，包括 ERP/CRM 和通用业务解决方案。对于客户来说，重要的是这些用户是帮助制定整体解决方案要求的团队不可或缺的一部分，在选择最符合他们需求的解决方案以及在交付解决方案（包括配置以及用户验收测试）方面发挥作用。这些用户很容易被日常活动所包围，没有时间参与项目，因此，确保这些用户从日常任务中获得某种形式的缓解，以便能够参与并做出有意义的贡献，是客户组织管理的责任。

标准项目类型的用法也可以扩展到中等规模的组织之外，到大型企业。例如，一个大型多站点组织可能希望在其整个组织中实施一个共同的解决方案，可能希望提供一个已经在试点站点部署的类似解决方案。虽然试点站点的解决方案可能已经使用更健壮的企业项目类型开发，但未来将解决方案推广到后续站点时，可以使用标准项目类型。此类解决方案推广的用法场景将在后续章节中描述。

企业项目类型

企业项目类型是所有 Sure Step 项目类型中最严格的。它专为大型、复杂场景设计，企业项目类型的特点是需要客户和服务提供商在整个合作期间保持专注和纪律，进行深入的项目管理工作。大规模合作通常涉及复杂的需求和解决方案场景，这要求在所有学科领域进行彻底的治理和监督，包括项目管理、解决方案配置和设置、定制代码开发以及测试。为了满足这些类型的用法场景，提供了企业项目类型。

以下是在 Sure Step 中企业项目类型的屏幕截图。截图左侧导航树视图中包含分析阶段活动的部分视图，突出了仅针对项目治理所规定的深度和勤奋。

企业项目类型的典型使用场景包括以下内容：

• 解决方案的要求包括复杂的定制和/或多个 ISV（独立软件供应商）解决方案，以及核心 Microsoft Dynamics 解决方案。在大规模合作中，特别是在多站点项目中，看到多个开发团队分布在不同的洲，基于同一解决方案的特定要求进行建设并不罕见。这些团队都必须“同唱一首歌”，换句话说，他们都在朝着同一个目标努力。为了确保团队之间有紧密的协调，并且每个团队都理解相互依赖关系，使用企业项目类型是至关重要的。

• 定制代码开发工作可能包括复杂的集成或与第三方源接口，以及将数据从遗留系统或第三方系统迁移到预期解决方案中。再次强调，企业项目类型提供的勤奋工作在这里是必要的，以确保风险在前期就被识别出来，同时还需要开发缓解方案以减轻风险，如果需要的话。

• 由于解决方案的深远影响，客户需要集中精力进行 OCM（组织变革管理）。企业项目类型规定了 OCM 专家的活动，以便提前规划并制定管理组织内预期变化的策略和技术。

• 与 OCM 活动相伴随的是深入的业务流程分析活动，允许服务提供商和客户组织讨论和记录客户的未来或即将到来的工作流程。Sure Step 中提供的活动和模板有助于企业规模客户进行此操作。

• 大规模合作还需要安装和管理多个环境以开发解决方案。这不仅需要在该项目硬件上的更大投资，还需要进行规划、设置、维护和过渡这些环境的活动，包括为在移交后支持这些环境的团队提供的明确文档，正如企业项目类型所规定的。

• 多地点合作，特别是那些希望在组织内实现一致解决方案的情况，也需要企业项目类型所倡导的严格解决方案配置和开发活动。当每个地点也有一系列独特的需求需要考虑，而这些需求超出了组织内共同需求列表时，这些组织的解决方案开发可能会变得更加复杂。这些独特需求可能源于当地国家的法律、与当地国家相关的会计和报告法规，或源于当地市场的特定要求。

需要使用企业项目类型的组织特征是系统用户数量非常高——250 个用户以上。根据解决方案要部署的地点数量，协调所有用户需要一个精心计划和深思熟虑的方法，这正是该项目类型所提供的。这包括跨地点收集需求、为每个地点的超级用户和最终用户进行培训，以及在部署前在每个地点对解决方案进行彻底的用户验收测试。

该领域的组织还以业务和 IT 团队中经验丰富的用户数量众多为特征。由于解决方案的规模和范围，客户组织通常从这一经验丰富的群体中指定选定的资源作为解决方案交付合作期间的专用资源。实际上，这些资源是实施团队的延伸，这些高级用户通常成为解决方案运营后支持其他用户的内部主要联系人。

设置解决方案部署程序

在前面的章节中，我们讨论了使用 Sure Step 实施 Microsoft Dynamics 解决方案的不同选项。Sure Step 有三个瀑布项目类型（快速、标准和企业）以及一个敏捷项目类型。这些类型指导实施者通过解决方案开发和单个发布或组织单个地点的部署。然而，这些项目类型也可以在分阶段解决方案部署或多地点合作中使用，这将是本节讨论的重点。

分阶段解决方案部署

在上一章中，我们介绍了解决方案交付的阶段性方法概念。这种方法不应与瀑布型项目类型中的阶段混淆，它指的是将解决方案分多个版本逐步推广到客户组织。阶段性解决方案交付方法在实践中是通过在第一个版本中选择并启用解决方案功能的一个初始子集来执行的，然后通过后续版本中额外的功能来在此基础上构建。阶段性方法的替代方案是在单个版本中交付完整的解决方案，也称为解决方案交付的“大爆炸”方法，我们已经在前面的章节中讨论过。

Sure Step 项目类型可以一起使用，以促进阶段性解决方案的推广。本质上，每个版本都被视为一个子项目，每个版本中启用的需求复杂性将决定相应项目类型的适当使用。阶段性解决方案推广的一般概念在以下屏幕截图中展示：

按照这个概念，下一张屏幕截图展示了其用于 ERP 解决方案实施的示例。在这个屏幕截图中，阶段性方法的版本 1使用标准项目类型来启用客户的财务运营。这随后是版本 2，使用快速项目类型来交付库存控制和订单履行功能。最后一个版本，版本 3，使用敏捷项目类型来部署高级规划和调度功能。

多地点合作

当你进入更大的组织领域时，ERP/CRM 解决方案的需求往往超越了客户的多地。多地点合作可能包括一个国家内的多个地点以及全球的多个地点。后者当然引入了更多的复杂性，例如特定国家的税收和会计规则。但在大多数情况下，客户的总体目标是部署一个跨所有地点的通用解决方案。

为了在多个地点开发通用解决方案，Sure Step 提供了与其企业项目类型一起的核心站点构建选项。在这种方法中，服务提供商与客户合作，进行需求收集研讨会，涉及来自组织所有相关地点的关键主题专家（SMEs）和业务负责人。这些研讨会的输出是企业的一个综合功能需求文档（FRD），它是核心构建的基础。

核心构建可以被视为一个共同分母的解决方案。在经典的 80-20 规则中，核心构建将包括支持企业大约 80%需求的功能。然而，核心构建只是一个已开发的解决方案，这意味着它不能单独部署。核心构建总是与站点构建一起部署，这构成了满足相应站点剩余 20%特定需求的功能。在特定站点上的实际部署可以在时间上错开，或者可以重叠部署。时间本身非常关键，并且取决于为该企业启用的特定需求。

下一个截图展示了核心站点构建的概念。该图显示了单个核心构建以及随后的站点构建（站点 1 构建、站点 2 构建和站点 n 构建）以及相应的站点部署（站点 1 部署、站点 2 部署和站点 n 部署）。

在某些情况下，客户在其投资组合中可能拥有多种多样的公司，每家公司都有非常独特的一套需求，因此最好将每个站点视为一个独立的项目。对于这些多站点实例，可以使用 Sure Step 项目类型组合，这与分阶段方法中采用的方法类似。下一个图例展示了这种情况的示例。该图显示了单个站点构建和相应的站点部署（站点 1 构建-部署、站点 2 构建-部署和站点 n 构建-部署）。

Sure Step 瀑布实施阶段

前几节提供了对 Sure Step 中提供的不同交付选项的整体概述，包括单次发布的不同项目类型以及结合项目类型进行分阶段或多站点部署的能力。鉴于这个背景，深入了解每个实施阶段，以获取方法论中提供的内容和模板的具体用例和实际场景是个好主意。我们将在本章的后续部分探讨这一点。

分析阶段

我们大多数人知道分析阶段是什么，我们通常将其解释为执行活动以更详细地揭示客户的需求和业务流程——换句话说，就是“详细内容”。这就是全部吗？

项目的开始

通过启动分析阶段，我们开始了项目的真正实施。一个好的开始将为我们的进一步实施定下基调。关于“分析阶段的目的”的问题，通常用以下答案来回答：为了进一步分析和记录客户的需求。听起来合理，还是不是呢？

启动你的引擎

这个答案相当不完整，因为它忽略了启动项目的重要功能。这就是我们启动引擎、设定航向并起飞的地方。在航空领域，起飞被认为是复杂且关键的。在软件实施项目中，情况也大致相同——开始阶段总是至关重要的。在分析阶段，我们不仅调查和记录客户需求和流程，还启动风险和问题管理、范围管理、变更管理、成本和时间管理、沟通管理以及质量和资源管理。正是在这里，我们为我们的项目文化和特定任务沟通定下了基调。因此，我们需要明白，除了调查需求和流程之外，还有更多的事情需要做，并且我们需要为此做出更多规划。

预计会有一些延误

在诊断阶段，我们努力争取客户的正式合同，即项目的正式批准。事实是，在提交和捍卫我们的提案之后，许多事情都可能发生。对我们来说，理想的情况是客户立即接受并签署我们的提案，并批准我们开始实施项目。如果我们幸运的话，事件可能会以这种方式展开，但替代方案也并非例外。客户的决策过程可能会消耗大量时间。可能需要几周甚至几个月才能获得批准。在经济困难时期，投资决策也可能推迟到下一个财年，导致进一步的延误。一旦我们通过批准的合同从客户那里得到正式的点头，我们仍然不能确定实施项目可以立即开始。实施活动的执行需要战略性和细致的计划，因此，在合同达成协议后，可能需要额外的时间才能真正开始。在制定分析阶段的飞行计划时，我们需要考虑诊断阶段和分析阶段之间的这种时间（不）连接。

建立项目文化的机会

在第四章《管理项目》中，我们讨论了为我们的特定项目建立指导性项目文化的重要性。实际上，我们将它定义为项目成功四大支柱之一。将客户和咨询团队连接到与该项目相关的价值观、信仰、优先事项和行为对于我们的成功至关重要。在我们投入项目的执行任务之前，我们需要确保所有利益相关者和团队成员都与我们的一致，并了解这个项目的所有关键要素。我们需要从实施项目的开始就践行我们所宣扬的原则。现在，实施项目何时开始？答案是，它现在就开始，就在分析阶段。

回顾

在我们定义和讨论下一步行动之前，让我们回顾一下我们现在所处的位置。以下图表描述了从决策加速器到最终提案的流程。此图表仅包括三个重要的决策加速器：需求与流程审查、适配差距与解决方案蓝图、范围评估。诊断阶段也可能包括其他决策加速器，但如前所述，您可以按需部署决策加速器。图表将工具和模板分为两类：工作和关键交付成果。工作交付成果是那些作为顾问工具箱的工具和模板，帮助顾问提高效率和品质。他们可以在需要时从盒子里挑选任何工具。有时，他们需要使用许多这些工具，在其他情况下，他们可能只需要少数几个。关键交付成果是面向客户的交付成果的一个子集。这些是我们将作为参与最终输出的文档交付给客户的。确保这些文档支持我们的沟通并正式化客户对所述主题的验证是很重要的。

当我们谈论将人们的愿景和我们的方法对齐，并创建一个指导性的项目文化时，我们需要意识到，通过执行决策加速器，我们确实产生了有价值的工具和丰富的信息。事实上，我们启动指导性项目文化所需的一切都已在项目章程中汇编，这是提案生成活动的一个关键交付成果。

一个好的项目章程是无价的

在 Sure Step 中，项目章程是在提案生成活动中生成的——这是微软解决方案销售流程（MSSP）证明阶段的关键组成部分。先前诊断活动中得出的结论成为提案生成活动的输入，其中关键任务包括得出结论和打包可用信息和文档。

Sure Step 项目章程回答了关于项目的基本和必要问题：

• 为什么：业务目标、关键成功因素和项目目标是什么？项目解决的价值主张是什么？为什么会有赞助？

• 什么：主要交付成果是什么？范围是什么，范围外是什么？

• 谁：谁将参与，他们在项目中将承担什么责任？他们将如何组织？谁是关键的利益相关者？

• 何时：项目进度表是什么，里程碑和交付成果将在何时完成？

• 如何：团队将如何参与？我们将如何应对变化、问题和风险？我们将如何执行、管理和控制项目？

以下截图是 Sure Step 项目章程的目录，它清楚地说明了所有诊断结论都汇集在这里：

那么，你能想到一个更好的工具来协调所有利益相关者和团队成员在项目方法愿景和所有关键要素方面的看法吗？项目章程的价值是无价的。它将所有相关的项目信息（关于什么、谁、如何和何时）汇总成一份文件，作为所有利益相关者治理整个参与活动的稳固指南。

项目规划会议

我们之前讨论过，在诊断阶段结束和分析阶段开始之间可能存在时间差距。因此，我们可能需要在分析阶段开始时修订和更新我们的项目计划和项目章程。以下图表说明了在分析阶段开始时的规划会议中诊断输出的最终确定：

项目规划会议是与客户一起进行的联合练习。会议议程包括项目概述、时间框架、可交付成果、建立项目结构、风险和利益相关者分析，以及沟通、变更控制、资源和质量的规划。

启动你的沟通文化

我们都知道启动会议的概念，但我们是否低估了它的重要性？我们有时倾向于将启动会议作为一项操作来执行，即通过重复交付完全相同的内容。我们通常介绍我们的公司、我们自己以及咨询团队，并要求客户也这样做。

然后我们讨论我们的阶段、时间和预算限制，以及我们即将实施的产品。最后，我们试图在积极气氛中结束这次会议。然后，这次启动会议的内容在我们的所有项目中都完全重新交付。但这足够好吗？为了回答这个问题，我们需要考虑以下两个重要因素：

• 项目本质上都是独特的

• 在诊断阶段结束和开始分析阶段之间可能存在时间差距

独特的项目需要独特的启动会议。是什么使每个项目独特？让我们列出一些重要的区分因素：

• 利益相关者、组织背景和复杂性

• 利益相关者的目标和期望

• 商业和项目目标

• 关键成功因素

• 范围内的区域和需求

• 范围外的区域和需求

• 客户和咨询实施团队

• 预算和时间限制

这些元素在我们实施项目中总是不同的。因此，我们需要在启动会议上解决这些问题。通过这样做，我们的启动会议将包括使它们独特的必要元素。我们需要将启动内容与每个实施项目的独特特征相连接。这意味着启动会议不能以操作的方式进行。启动会议需要根据每个具体项目量身定制，并在客户独特组织的背景下进行展示。

这正是为什么 Sure Step 建议在启动会议中推荐以下议程主题：

• 简介

• 项目定义和目标

• 关键可交付成果

• 成功标准

• 项目方法

• 项目团队和组织

• 职责和角色

• 培训和测试

• 控制、报告和批准

• 沟通

• 项目范围

• 问答环节，为顾客、利益相关者和团队成员提供一个表达任何担忧或疑虑的机会

总结

是的，准备这类启动会议会消耗一些时间，尤其是当你第一次需要创建此类内容，需要在各种文档和地方搜集信息时。回顾一下议程要点。我们可以在哪里找到这些信息？是的，你说得对；项目章程将所有这些信息汇编成一份文档。通过诊断活动生成的稳健项目章程是独特而有效的启动会议的起点。这就是为什么 Sure Step 列出了以下启动会议的先决条件：

• 初始项目计划已到位

• 确定项目利益相关者

• 项目章程已建立

• 项目准备就绪，可以执行

我们现在可以通过添加启动会议来进一步完成我们的图表。以下图表说明了从诊断活动中生成的信息如何在项目章程中汇编并作为启动会议的输入重新使用：

在实施项目开始时，一个以价值为导向的启动会议对于协调所有利益相关者至关重要。在诊断阶段结束、合同签署和开始分析阶段之间，可能会出现许多情况。在咨询现场，参与特定项目诊断活动的团队可能已经解散，并已经开始计划其他任务。在客户现场，关键用户可能已经更换部门或离开公司。可能会有新的经理或部门负责人被雇佣，带来新的愿景和优先事项。由于新出现的商业机会，业务流程和需求可能已经经过审查和修改。在诊断阶段结束和分析阶段开始之间面临较长时间的情况下，可能出现许多新的情况。

那么，我们的使命现在是什么？在启动会议上，我们需要验证和确认我们是否仍然对项目章程中所述内容达成共识和支持。这对启动一个成功的合作至关重要。我们是否仍然拥有相同的利益相关者？他们是否仍然支持项目目标和优先级？我们是否仍然对范围达成共识？新的咨询团队成员是否与诊断结论一致？他们是否有关于范围和业务流程的问题？需要签署哪些文件，谁需要签署，签署究竟意味着什么？我们还需要展示和审查计划，并确定我们的下一步行动，包括期望从谁那里得到什么。

因此，启动会议不仅仅是小规模的聚会来展示自己和公司；它需要更多。我们不仅需要就什么、如何、何时达成一致，还需要寻找自诊断阶段结束以来出现的问题和变化。

培训还是不培训？

在启动会议之后可能考虑计划的第一项活动之一是培训。培训不仅是一种优秀的教育工具，也是一种管理感知的伟大工具。在 Sure Step 中，培训是跨阶段过程之一，有助于更好的项目生命周期规划。阶段不应仅限于其核心活动，但需要包含所有跨阶段活动的良好混合。在这个愿景中，培训不应仅限于部署阶段。为什么我们会考虑在分析阶段规划培训？我们如何从中受益？我们在分析阶段培训的目标非常重要。以下是我们应该牢记的一些理想目标：

• 提高对新解决方案的认识

• 介绍范围内功能领域的功能架构和标准概念

• 介绍应用的词汇

• 在客户和咨询团队中建立对流程和功能的共同理解

• 促进感知和组织变革

• 提高即将到来的分析研讨会效率和品质

如果在分析阶段进行培训实现了这些目标中的哪怕一小部分，这也将是值得的。那么，我们是否需要计划对最终用户的整个团队进行关于他们新解决方案的培训呢？答案是简单的，那就是不需要。我们不想在这个项目生命周期的这个时刻教育最终用户，因为这会太早，而且不会有效。研究清楚地表明，到 Go-Live 时间，最终用户会忘记大部分内容，我们的培训投资将不会产生任何回报。我们想要计划的是为针对特定群体的小型培训。我们希望我们的关键用户团队能够理解我们的解决方案的功能概述，以及与他们专业领域相关的内容。因此，我们需要向选定的受众展示并阐明适用于相关功能领域的标准化功能和流程。这可能会展开讨论，但这正是我们的目标——良好的客户互动、反馈和积极倾听可以为我们提供大量信息。

在这个阶段，我们可能已经发现了一些机会来展示，在保持相同或更好的结果的同时，可以通过稍微不同的顺序或方式执行现有流程。你做得对；我们应该在我们核心分析活动开始之前就着手管理人们的认知。组织变革管理不是你只在 Go-Live 之前启动的事情；它应该贯穿于你的项目生命周期规划中。你可能会问，这种培训可能存在哪些风险。最大的风险是针对错误的受众。这种培训，在 Sure Step 术语中被称为Conduct Solutions Overview，对于真正的最终用户来说是不合适的，因为他们只有一个目标：他们寻求答案，了解这个新解决方案将如何解决他们详细的日常工作。在这个解决方案概述培训中，他们找不到这些答案，可能会导致潜在的挫败感和消极情绪。而且正如你所知，坏消息传播得很快。这就是为什么我们需要妥善管理这些会议，并有效地与我们的客户沟通，这些会议是为他们而设的。

下面的图表说明了启动会议之后活动流程的延续：

未受控制的分析阶段

项目管理状态报告通常在分析阶段不会披露许多问题。当我们询问我们的应用顾问在分析活动中的状态时，他们通常会回答说一切顺利。一些项目经理并不认为这个阶段是一个复杂的情况，他们将这个阶段的成功委托给涉及的业务分析师。他们安慰自己，当他们部署高度熟练和经验丰富的业务分析师和应用顾问进行业务流程分析研讨会时，他们不需要担心太多意外的问题。似乎这样的项目经理也不太关心这个阶段的可交付成果。他们只需要一份书面文档，描述并解释客户对业务流程所需的功能需求。现在看起来，在分析阶段唯一受到挑战的是业务分析师，而项目经理只是面对一个轻松的小任务，即规划研讨会并在研讨会活动中收集一些反馈。如果这是真的，我们在这个阶段就不需要项目经理了。让我们更仔细地看看，在这个阶段项目经理真正面临的挑战是什么。

我们已经在前面的章节中了解到，我们不仅需要计划纯粹的分析活动，分析阶段还代表着实施项目的开始。这将挑战项目经理启动项目文化和方法，而这不仅仅包括计划几场访谈会议。即使我们忽略这一点，真正的分析活动也要求良好的项目管理。

如果我们将责任限制在规划研讨会、询问我们的应用顾问进展情况以及等待最终文档交付上，我们就是在放弃所有控制权。我们首先失去的控制元素是进度报告。如果我们只能以最终文档交付的形式报告进度，我们实际上能做的事情很少，除了等待这份最终文档并从完成百分比的角度来推断进度。现在我们都知道这有多准确。我们将失去的第二个控制元素是质量控制。如果我们等待这份最终文档交付，我们只能在它准备好后评估质量。那时，可能已经太晚采取纠正措施了。大多数项目经理可能甚至不会阅读完整的分析文档交付，因为他们没有足够的时间去审查所有细节。

在项目生命周期的第一阶段放弃进度和质量跟踪能力并不是明智之举，这将为我们的整个项目定下基调。如果我们不关注这些重要方面，我们很可能也不会在以后关注。

不幸的是，还有其他一些东西可能会被忽视：为分析活动、范围管理和问题及风险管理设定优先级。这些元素在分析阶段的被动项目管理部署期间都处于危险之中。这些元素将在下一节中列出并讨论一些真实世界的分析场景。

真实场景分析

在一个不受控制的分析阶段，我们可以识别以下典型的场景。

回到起点

直接切入正题：应用顾问从头开始，重新分析一切——这有多明显？相当多的应用顾问在核心分析活动开始时完全脱离诊断结果，并且没有关于待分析范围优先级的指导。我们能否预测这种场景的结果？结果可能是涵盖了许多不太重要主题的详细信息的分析文档，同时缺乏关于更重要和复杂领域的良好信息。在许多情况下，客户也会感到沮丧，因为他们不得不再次提供相同的信息。看起来我们又回到了起点，我们之前执行的预研究分析活动并没有带来太多改变。客户将不明白为什么我们为此收费，并抱怨浪费了努力。表现得惊讶吧！

范围蔓延悄然而至

我们大多数人对于范围变更都了如指掌。它是导致项目失败最常见的原因之一。了解了这一威胁，我们便为此做好准备。手持变更请求，我们从发现范围蔓延的第一刻起就开始与之抗争。至少这是我们告诉自己的一句话。问题是，我们大多数人只是在项目生命周期的后期阶段才识别出范围蔓延，那时我们刚刚结束开发活动，开始参与测试活动，或者更糟糕的是，当我们正在为上线做准备时。不幸的是，在这个阶段我们赢得战斗的机会微乎其微。

我们需要意识到，范围蔓延很可能在分析阶段悄无声息地溜进来，尤其是在我们的分析师与良好的诊断结果脱节时。在这些研讨会中，我们的分析师团队将与几位部门负责人、关键用户和业务分析师等会面。他们都将对应该自动化什么以及如何自动化有自己的看法。他们可能会提供有关现有需求的新信息，甚至在这一阶段提出全新的需求。如果我们的分析师现在没有识别或报告这一点，我们的范围蔓延怪物将在后期阶段开始生长，并变成一个巨人。

没有问题，没有风险

在分析阶段进行被动项目管理不会为分析师团队提供很多关于其职责的指导，特别是当谈到问题和风险时。在分析阶段，项目经理经常询问他们的顾问团队事情进展如何，而且很少会报告问题和风险。在大多数情况下，一切都被报告为处于控制之下。这是因为应用顾问可能不会觉得在这个阶段识别问题和风险是他们的责任。在这个阶段，识别问题和风险通常被视为项目经理的责任。问题是项目经理并没有参与所有的研讨会和访谈，缺乏进行这个问题和风险识别所需的信息。因此，在这个阶段很少（如果有的话）报告风险和问题，这是一个错失的机会。有一点是肯定的：在分析阶段，我们将面临问题和风险，但如果它们没有被识别和报告，我们将在项目生命周期的后期面临后果。

我们可以通过指出项目经理应该控制分析阶段的原因有很多来总结。除了核心分析活动之外，还有更多的工作要做，甚至对这些分析活动的管理也需要项目经理有坚实的方法和清晰的愿景。在接下来的章节中，我们将讨论 Sure Step 如何帮助我们。

分析什么？

要知道哪些需要我们全神贯注，哪些可能需要我们较少的关注，我们需要回顾我们的诊断结果。以下图表说明了与诊断结果之间的联系：

顾问可以通过回顾诊断结论和重新使用诊断工具和成果来为业务流程研讨会做准备。项目章程应该提供一个完整的图景，说明范围之内和范围之外的内容，业务优先级，关键成功因素，以及已知的问题和风险。如果这些在诊断阶段进行了建模，问卷和产品特定的流程图将是分析阶段的一个极好的起点。它们在整体客户业务环境中可视化了已经识别的瓶颈和复杂区域，并将为顾问团队规划分析活动提供明确的指导。分析团队也将从 Fit Gap 分析工作表中受益，它提供了以下非常有价值的信息：

• 与业务流程相关的需求

• 需求优先级

• 按照标准功能、配置、定制、工作流和 ISV 解决方案分类的需求

以下图表说明了 Fit Gap 工作表如何作为业务流程研讨会的一个输入工具：

通过给定的优先级要求，包括通过类别估计的努力和复杂度排名，应用咨询师可以更好地规划和优先考虑可用的分析时间，从而在更短的时间内实现更高效和以质量为导向的分析工作。

追求中间分析交付成果

如果我们想在分析阶段跟进我们的应用咨询师在进度和质量方面的表现，我们应该计划中间交付成果。制作一个简单的文档，例如研讨会报告，因为它可以产生很大的影响。作为项目经理，你需要指导你的团队，每次研讨会后都需要制作研讨会报告。它包含标准化的部分，这样所有应用咨询师在记录研讨会结果时都使用相同的格式。这使得项目经理跟进起来更加方便，因为每份文档都可以以相同的方式进行阅读。一旦计划中的研讨会结束，咨询师需要提供研讨会报告。不充分的研讨会报告将被项目经理质疑，并可能导致纠正措施。在研讨会本身之后不久生成的研讨会报告，将防止重要信息被遗忘的额外风险。

与分析活动合作标准化中间文档交付成果的一个巨大额外好处是，可以明确结构和质量方面的期望输出。这也会为咨询师的交付设定明确的期望。

以下截图展示了一份研讨会报告的一页：

这一页非常清楚地表明，应用咨询师不仅应该记录客户利益相关者在研讨会中告诉他们的内容，而且他们还负责生成结论，将信息与诊断范围联系起来，识别问题，并推动流程变化，以避免不必要的定制。作为项目经理，你现在可以通过提出两个问题来组织你的跟进：

• 研讨会结束时我们是否有研讨会报告？

• 应用咨询师是否以高质量的方式填写了第六部分？

这种方法与“等待最终交付成果”的方法有巨大的区别。

通过拟合差距分析在分析阶段管理范围蔓延

如前所述，未管理的分析阶段的一个后果是范围蔓延悄无声息地进入。在分析阶段活动中，关于现有需求的新信息变得可用，使原始请求在新的光线下显现，甚至允许制定新的需求。即使有坚实的实施方法，这些情况也是不可避免的。未能识别这些范围变化会影响所有利益相关者在持续时间、成本、质量和期望方面的利益，这使得识别它们成为我们的真正挑战。以下图表介绍了 Fit Gap 评估作为分析阶段的有价值工具：

一旦所有业务流程和需求调查都已经完成，就是时候在功能需求文档（FRD）中记录所有发现和结论，为新的解决方案提供完整的需求描述。现在我们已经将所有范围定义到了所需的详细程度，我们可以重新评估 Fit Gap 情况。

Sure Step 倡导在分析阶段捕捉到需求后，重新评估 Fit Gap 情况的好处。这可以防止范围蔓延悄无声息地进入，它加强了所有利益相关者对预期解决方案的认识，并为项目经理提供警告信号，以解决多个问题。如果我们的评估揭示了新的需求、变更以及其他重要的范围挑战，我们需要接受这些宝贵的信息。这证明了我们的顾问团队对项目和业务范围的影响非常关注，并且我们被激发采取一些良好的项目管理行动，这是我们的真正工作。立即行动！那么我们能做什么呢？我们至少应该就这些确定区域进行沟通。咨询团队的意见是什么？客户团队对此有何感受？影响是什么？我们能找到替代的业务流程和解决方案吗？我们不应该对这些情况感到恐慌，也不应该忽视它们。这些情况在项目中无处不在，在分析阶段识别它们是正确方向的一步。推荐如何解决这些问题？由于项目是独特的，你应对这些挑战的方法和解决方案也将是独特的。你可能需要一个包含各种成分的配方，例如业务流程变更、拒绝一些新的不重要需求，以及接受一些真正的范围变更。你的配方需要在这个背景下味道好。它需要与目标、预算、时间和成本限制保持一致，同时也要得到大量利益相关者的接受。

我们刚刚提到范围变更了吗？Sure Step 明确指出，范围变更及其管理不能仅限于项目生命周期的最后阶段。在 Sure Step 中处理范围变更是提案管理的一个要素。Sure Step 实际上是这样说的：“提案管理是一项需要在项目实施生命周期的所有跨阶段执行的活动”。因此，我们可以在分析阶段开始提出变更请求。这意味着客户组织将在项目生命周期早期就熟悉这一过程。变更请求是一种有效的工具，可以控制范围蔓延，但需要谨慎处理。当仅在一个阶段操作并且变得过于频繁时，这个工具将失去所有的影响力。有时我们倾向于认为变更请求不仅是为了解决所有范围问题，也是为了解决所有质量问题。当明确的质量问题被不恰当地、厚颜无耻地作为变更请求提交，并且每个范围问题都转化为变更请求时，我们正在制造一堆文书工作。最佳实践告诉我们，在这些情况下，范围变更问题将保持未解决状态，因为客户不会批准这些变更。感到惊讶！专家级的使用变更请求意味着在整个项目生命周期内平衡使用，正如 Sure Step 所建议的那样。

我们现在可以进一步完成分析阶段的图示：

不要忘记数据迁移

专注于功能性解决方案，数据迁移通常被视为次要问题。我们热爱设计功能性解决方案，连接业务流程和软件功能，对此如此专注以至于其他一切都不复存在。这实际上并不聪明，因为非功能性需求可能是一项艰巨的任务，消耗大量资源并带来相当大的风险。我们中的大多数人已经体验过数据迁移挑战如何影响项目持续时间甚至上线决策。这就是为什么 Sure Step 关注数据迁移。诸如现有数据状况、数据清理、要迁移的历史数据量、现有数据源的识别以及主数据管理等话题，需要从一开始就解决。他们需要确保这些话题在分析研讨会上得到处理。

与基础设施部门互动

良好的项目生命周期规划需要在每个阶段都包含跨阶段流程的良好组合。我们已经看到，分析阶段不仅仅是为核心分析活动保留的，它还需要积极的项目管理、强大的沟通、培训以及对数据迁移问题的关注。还建议开始与基础设施利益相关者互动，以构建沙盒和培训环境。这些环境需要允许客户培训和对核心微软 Dynamics 产品的熟悉，在配置或定制之前，这提供了一个建立与客户基础设施人员关系和沟通的绝佳机会。我们越早开始与他们互动，就有更多的时间为他们准备关键转折点。

设计阶段

解决方案设计是任何软件项目中的关键活动。即使涉及到的定制化不多，我们仍然需要设想项目的“如何”。

我们真的需要设计阶段吗？

我们真的需要一个独立的设计阶段来设计解决方案吗？ 这是一个经常被问到的问题。有些人声称在分析阶段就开始设计解决方案，而有些人则将其包含在开发阶段，甚至在方便的时候进行。从瀑布模型的角度来看，你可以在一个或多个阶段中规划你的设计活动，只要你在特定阶段执行了计划中的内容。因此，并没有真正的瀑布模型理由来特别设立一个设计阶段。然而，阶段代表了时间上的分解，以便更好地规划和管理工作流程。这就是为什么 Sure Step 计划在单独的设计阶段中实施主导的解决方案设计流程。在捕捉到范围基线之后，我们现在可以集中精力在管理良好的时间框架内进一步发展我们的解决方案概念。我们大多数人都熟悉“什么”和“如何”的常识规则：在诊断和分析阶段，我们专注于“什么”方面，而在设计阶段，我们则发展项目的“如何”方面。这表明了在这些阶段中主导流程将是什么，但不要被误导：项目管理跨阶段流程已经教会我们，在阶段中我们需要规划的内容要比核心活动更多。

被动设计阶段的风险

诊断和分析阶段的核心活动本质上都涉及客户互动。销售前活动，如需求评估、业务流程评估、概念验证演示、研讨会和访谈等，都需要客户互动。在设计和发展活动中，这一点并不那么明显。设计活动通常被设想为并缩小到记录“如何”方面。这意味着设计等同于撰写关于“如何”方面的文档，唯一的计划客户互动是验证文档。将这一点与对开发阶段的相同被动愿景结合起来，将严重危及我们的项目成功，因为我们实际上是在将客户排除在项目之外，直到真正的部署活动，并推迟许多实施活动。我们真的想承担这个风险吗？

确步设计阶段的所有活动

开始赞扬确步的好处，因为它将使我们摆脱被动的设计阶段。真正的实施活动就在设计阶段开始！确步告诉我们不要等到开发阶段结束时才开始实施活动。我们需要通过频繁与利益相关者互动来保持与客户组织的联系。我们需要提高我们的利益相关者对项目和解决方案的认识和知识水平，刺激组织变革，并继续识别和管理风险和问题。有许多事情要做，是的，我们也会记录一些“如何”，但不会限制自己只做这一点。

我们正在实施一个标准包解决方案

现在让我们思考一下这个问题。它说了什么？这意味着我们不是在交付一个纯开发项目。通过安装标准功能、配置或 ISV 解决方案，可以满足大量需求。那么为什么我们有时只在开发活动完成后才开始实施？一些标准功能将依赖于定制功能，而这些需求不能立即实现，但这并不适用于所有情况。包解决方案的一个关键优势是，与定制解决方案相比，我们可以非常快速地交付。我们需要通过尽早开始实施来利用这一点。实际上，推迟实施真的没有理由。我们将从解决方案早期交付的小部分中受益。

从需求到设计

在诊断阶段，我们收集了高质量的信息，将其分解为需求，并通过将它们分类到标准功能、配置、定制、ISV 解决方案和工作流程中与我们的标准解决方案进行映射。我们在分析阶段细化了这种理解，并再次与我们的标准产品进行核对。这意味着我们可以根据结构化信息开始设计阶段，这些信息将指导我们下一步做什么：文档和实施。

文档和实施

以下图表显示了要实施和记录的内容：

从诊断和分析阶段出来，Sure Step 不仅带来了信息，还带来了优先级、指南、结论以及对即将实施解决方案的深刻理解。标准或 ISV 解决方案中的标准功能可以立即实施，同时满足直接的配置要求。我们的实施团队现在必须启动他们的引擎，将这个项目加速到超光速。一些功能可能需要等待安装或配置，因为它们可能依赖于定制功能。不要为此感到恐慌，因为我们可以在稍后完成实施。好消息是我们已经交付了解决方案的一部分，而且还没有找到第一个对此抱怨的客户！

文档也是游戏的一部分。拥有文档化的解决方案设计很重要，但我们不需要包括一切。我们不记录标准功能，但将专注于配置设置和定制功能。我们使用功能设计文档（FDD）来记录我们的配置和定制概述。配置设置应在 FDD-FIT 中记录，而定制则在 FDD-GAP 中记录。

Sure Step 还提供了技术设计文档（TDD）以及解决方案设计文档（SDD）。TDD 是 FDD-GAP 技术术语的翻译。该文档的目标是定义和记录每个系统修改或增强的技术细节。这可能是我们在与初级开发者合作或在海外开发环境中进行开发活动时即将到来的开发活动的一个关键组成部分。

SDD 的目的是让业务决策者和其他利益相关者能够以业务语言清楚地了解所提出的解决方案设计。这可能是在组织复杂性高的公司中所需的文件。FDD 文档对所有瀑布项目类型都有益，而 SDD 通常用于企业项目类型。

应用顾问将与适当的关键用户携手合作，实施和记录。这就是为什么在这个阶段，我们应该向我们的关键用户提供一些关于产品功能和特性的培训和指导。这不仅将使我们的关键用户在产品知识上达到新的水平，还将避免误解并从关键用户那里获得更多的承诺。与关键用户紧密合作将提高两个团队的协作，这对于成功至关重要。

启动测试

一旦我们实现了功能和特性，我们就可以释放每个项目中关键成功因素的力量——测试。测试将使我们能够与关键用户互动，识别问题，工作并引导感知，并更新业务流程模型。在这个阶段启动测试还将使我们的关键用户为即将到来的项目阶段中安排的用户测试做好准备、组织和控制。他们可以在这里开始使用新解决方案的愿景过程。他们将了解测试涉及的内容，并增加他们的产品知识。信息充分且投入的关键用户对于项目成功至关重要，但我们不能期望关键用户一夜之间达到我们的知识水平。我们需要确保他们能够逐步建立起他们的知识和理解，以便在需要时做好准备。这就是为什么我们在这里通过在设计阶段启动测试和测试脚本开始。我们将从测试我们与关键用户一起实施的功能和特性开始，这些特性得到了可用的 Sure Step 测试脚本的加强。之后，关键用户可以继续为即将到来的测试准备测试脚本。

由于测试活动的开始，我们也将遇到问题。再次，欢迎这些问题，因为这是一个极好的机会来沟通和解决这些问题，并计划纠正措施。这正是我们想要的：现在揭示问题，这样我们就可以克服它们，而不是通过不识别它们而将它们留到后期。

与基础设施部门互动

安装和配置核心产品以及组织测试也将涉及基础设施的元素，即测试环境。这是一个继续与基础设施利益相关者互动的好机会。所有这些需要什么？我们需要做什么才能将培训转化为真正的测试环境？我们可以与基础设施人员携手合作，使他们更好地理解这个新产品的基础设施后果；这种互动也可能揭示一些新的问题或风险。正如你所知，这正是我们想要的，因为它将允许采取纠正措施。

不要放弃数据迁移

我们需要继续我们在分析阶段开始的数据迁移工作，通过设计迁移流程和将现有遗留系统与微软 Dynamics 应用程序之间要迁移的字段进行映射。由于我们在设计阶段启动了测试，我们也可以在这里创建一个用于测试的数据子集。

开始规划部署

一个优秀的项目经理能够超越当下，明白一个组织良好的部署阶段对于成功的上线至关重要。这位项目经理也知道，部署的成功取决于用户组织的承诺。同时，我们需要认识到，我们的部署活动将对该组织造成沉重的负担。培训、用户验收测试、性能测试和基础设施准备将消耗他们大量的时间和精力。我们需要通知我们的客户这一点，并请求他们的承诺和规划，而且我们需要提前做好这一点。设计阶段是启动这一过程的理想时机。到目前为止，两个团队都对即将发生的事情有了很好的理解，因此我们应该在这里着手处理。Sure Step 为我们提供了一个部署计划，概述了项目部署阶段需要发生的流程和活动。它将要求客户对这些活动表示理解和承诺。这不仅仅是安排部署。部署计划必须成为你围绕部署范围、部署策略、部署资源、培训和测试组织以及部署时间表等主题进行沟通的输入。我们的目标是获得客户对部署活动的认可。底线不仅仅是文档，而是沟通，沟通，再沟通。

开发阶段

这可能是软件公司最擅长的：开发。它主要依赖于我们的信息技术商业生态系统，因此我们处于主场。太阳之下无新事，或者有吗？

仅限开发者？

开发阶段通常被组织成一个“仅限开发者”的时间段，并不罕见的是，它遵循相同的理念。这就是应用顾问的负担显著减轻的地方，我们的开发团队接管了工作，他们甚至可能完全隔离在服务提供商的场所。这是最佳策略吗？毫无疑问，开发活动将在这一阶段占据突出位置。是的，开发者可能需要一段时间不受打扰地工作，以便最大限度地集中精力。但正如我们从其他阶段的组织中学到的，还有更多需要考虑。

我们需要保持警惕，关注项目生命周期规划，并确保按照计划包括足够的客户互动和参与。我们需要确保与所有利益相关者的沟通水平，并保持应用顾问和关键用户之间的协作。最后但同样重要的是，我们还需要继续为客户的部署基础设施部门做好准备。总之，在这一阶段，开发力量将发挥关键作用，但他们不应是这场球赛的唯一参与者。

开发并冻结定制代码

在 Fit-Gap 练习期间映射为定制需求并在 FDD-Gap 和 TDD 文档中设计的需求，在这一阶段得到开发。这不仅包括解决请求的功能性需求的功能性要求，还包括数据迁移和接口等非功能性要求。开发团队需要首先审查解决方案和技术设计文档，然后开始实际开发。他们应该遵守所有批准的质量和文档标准。在较大的开发团队中，由主开发人员协调开发工作也是至关重要的。产生的交付成果将经过多次单元和功能测试迭代。一旦成功通过，代码将被冻结，表示它不再开放修改。只有在数据验收、流程或集成测试中发现问题时，才能进行进一步的修改。不要忘记，当交付的定制与预期不同时，更新设计文档。

完成测试

一旦定制功能交付成果开始生产，我们就可以进一步完成在设计阶段启动的测试。现在我们可以通过测试越来越多的完整流程，将其提升到全面解决方案测试的水平。你说对了——测试是一个跨阶段的过程，它使我们能够在整个项目生命周期中继续与客户互动和沟通。现在是时候进行集成和数据验收测试了。到目前为止，我们的主要用户应该已经非常熟悉测试流程，并且他们正在不断加深对解决方案的了解。他们将微调测试脚本，并可以开始编写用户验收测试脚本，以便在部署阶段引导用户组织通过这些测试。感谢我们持续的测试努力和与用户组织的合作，我们将收集问题和疑问，并在关键用户团队中检测到不确定性和敏感性。我们必须利用这些信息！我们需要在这里解决这个问题，确保部署阶段达到最佳状态。

下面的图表说明了我们从设计阶段进展到开发阶段的情况：

我们也可以继续在测试脚本开发上的合作，这是我们始于设计阶段的任务。与关键用户一起，我们现在可以准备用户验收测试脚本，这些脚本将在部署阶段引导用户验收测试（UAT）。UAT 是所有先前测试活动的最终成果。尽管可以利用先前的测试脚本，但 UAT 脚本应专注于系统用户执行的主要功能。

最后一次变更请求

在任何项目中，变更请求总是出现在地平线上，无论我们如何定义我们的范围，或者我们在组织变革管理方面做得多么好。在讨论的 Sure Step 生命周期规划中，我们试图在所有阶段与客户组织保持互动，以识别问题、风险和变更请求。这使我们能够尽早识别它们，并在整个项目中进行分散。这样，我们可以主动管理，防止问题成为部署阶段的真正负担。在开发阶段，我们仍然会检索和管理变更请求，但现在我们需要意识到，在这个阶段之后，我们需要将变更降低到较低水平，我们的最终用户组织需要对此有所了解。作为项目经理，我们有责任让我们的客户了解这一点。另一个沟通挑战！

流程模型还可以更改吗？

这个问题的答案是肯定的。由于我们在开发阶段计划的活动和互动，我们将从客户和咨询利益相关者那里收到反馈。我们的开发者可能会有关键的评论，应用顾问可能会提出重要的见解，我们的客户也可能提出问题。可以产生这种反馈的典型互动是测试，正如我们讨论的那样，测试活动在开发阶段继续进行。基于这种反馈，我们可能需要对我们的解决方案设计进行一些更改，或者说服我们的客户实施业务流程变更。业务流程模型的审查和更新是一个持续的过程，应该在项目生命周期的整个过程中迭代，包括设计和开发阶段的审查和更新。

开始最终确定

很明显，Sure Step 倡导良好的项目生命周期规划，这在开发阶段计划的活动和交付成果中再次得到强调。我们已经看到，这个阶段不仅仅是为核心开发活动预留的。细心的读者也会发现，我们需要在开发阶段开始最终确定大部分的实施活动。这意味着到这个阶段结束时，我们已经交付了大部分的成果，这将使我们能够专注于部署阶段的纯部署活动。

完成系统配置和 ISV 解决方案的设置

在设计阶段，我们开始安装和配置标准功能和 ISV 功能，以满足客户的需求。现在，随着本阶段定制功能的可用，我们可以完成这一配置工作。这意味着我们还可以实施和配置定制功能，同时，正如前文所述，将测试提升到解决方案测试水平。解决方案测试不可避免地会导致配置更改，在此过程之后，我们可以冻结新解决方案的配置设置。

完成设计更新

由于已识别的问题、变更和更新的业务流程模型，我们必须更新适当的设计文档。

将非生产环境移交给客户

本任务的目的是将非生产环境移交给客户的基础设施团队，并确保他们准备好接受和支持这些环境。这将使我们能够与基础设施资源互动，并围绕新解决方案的基础设施主题积累他们的知识。

以下图表将完成我们对开发阶段的概述：

在开发阶段结束时，我们可以勾选以下内容表示完成：

• 定制开发

• 解决方案测试

• 标准和 ISV 解决方案的配置和设置

• 设计文档

• 测试脚本创建

这将使我们能够专注于部署阶段的部署活动。多么五星级的项目生命周期规划！

部署阶段

有些人认为部署阶段是项目生命周期的尾声，而另一些人则认为他们仍需要在本阶段开始大多数实施活动，包括产品的配置和测试。那么他们到目前为止都做了些什么呢？部署是成功交付项目的关键过程。它涉及为整个公司准备将全新解决方案投入运营使用。这可是相当重要的事情！

让我们找出这一阶段的关键活动。

成功部署的关键是什么？

毫无疑问，基础设施和解决方案的准备工作是良好部署的基础，但它们只代表了“一半的路”。另一半，甚至更大的部分，是客户的组织准备。用户组织内部是否有支持这个新解决方案的联盟？关键用户组织能否看到并欣赏这个新解决方案的好处，并且能否平衡他们所经历的付出和困难？他们能否将现有的批评和抵制放在正确的角度？他们能否预见下一步和挑战？这些都是任何项目经理在过渡到部署阶段时必须反思的重要问题。对这些问题的回答将指导我们如何组织部署阶段以及在哪里放置重点。这必须是我们部署时的关注点。

变革的传教士——培训师

足够的培训是成功实施中最重要的步骤之一。使用户在日常工作中的效率大大提高是任何业务解决方案实施项目中都会发现的关键目标。仅为此原因，用户需要对产品有深入的了解和洞察。但有效的培训不仅会赋予用户如何在日常公司流程中使用该系统的必要知识，还会引导他们对新事物产生感知和信任。对于大多数用户来说，这可能就是他们第一次接触这个全新的解决方案，而且你只有一次机会留下良好的第一印象。出于所有这些良好的原因，我们需要计划充分的培训，并抵制将培训减少到最低水平以降低成本的诱惑。

进行最终用户培训

Sure Step 设想在部署期间对最终用户的培训是短期的、有针对性的会话，从广泛的概述开始，逐步缩小到最终用户定义的工作任务。培训场景必须是基于角色的，以便每个用户都能完成他们日常工作中所需的具体活动和任务。可能需要在每个会话开始时进行一次业务流程（待执行）培训，以确保所有最终用户都对新的流程有足够的了解。

一个关键的成功因素是，最终的任务导向培训应尽可能接近部署进行，以防止知识侵蚀。

组成培训团队

这项培训可以由客户的关键用户、培训师或咨询实施团队中的顾问，或者由外部第三方培训供应商进行。这很可能是混合的，因为找到一个能够完成所有工作的培训师并不容易。让关键用户参与他们部门培训的交付是一个明智的做法。关键用户对最终用户了解得更好，对业务流程有很强的知识，并且与产品紧密相连，得到了管理层的加强。因此，他们可以比任何外部培训师更好地传播新解决方案及其不可避免的变化。然而，我们需要确保他们具备适当的产品知识和一个组织良好的方法。

正因如此，我们需要在事先为他们提供培训师培训课程。我们解决方案的一些领域可能需要培训师的高级专业知识，因此，可能有必要从咨询或学习组织部署专门的培训师。

数据怎么办？

到目前为止，所有数据迁移的设计、开发和测试都已经完成。我们将需要数据迁移执行以进行培训、测试和部署。最终用户培训需要模拟真实用例场景的测试数据。用户验收测试也需要来自客户指定的一天实际交易，这将提供他们业务的良好样本。因此，对于这两项活动，我们需要迁移数据，从某种意义上说，这将为我们最终将数据迁移到支持部署的生产环境做好准备。

Sure Step 建议最终迁移分两步进行：

• 数据初始迁移到生产环境：数据初始迁移到生产环境是为了避免系统过载，通常在真正的上线前一周进行。这些数据通常包括静态数据。

• 最终数据迁移到生产环境：最终的数据迁移最好在上线前的周末进行。由于大部分初始数据是在上线前一周加载的，因此最终的数据加载将考虑在初始数据加载后输入系统的数据。这个概念加速了迁移过程，并消除了可能危及切换的最后时刻的故障。

上线作为用户验收测试

你可能不会相信，但在某些情况下，上线流程是在没有先前的用户验收测试的情况下启动的。最常见的借口是“我们告诉客户去测试，但他们没有做”。你甚至可能会发现，UAT（用户验收测试）被用来补偿前期阶段的时间和预算超负荷。在没有 UAT 的情况下，上线将充当用户验收测试，而那次上线的成果是可以高度预测的。

不要忘记 UAT（用户验收测试）实现的重要目标：

• 验证新解决方案是否支持公司通过需求过程所设想的公司运营流程

• 通过减轻失败风险来获得对系统的必要信心

• 在之前的测试周期中幸运逃脱的问题的最后一次识别机会

• 激励上线决策

• 获得系统验收

• 生成支持项目收尾过程的结果

你持续的关键用户互动现在将得到回报

我们通过前几个阶段的内容了解到，在所有实施阶段安排与关键用户的互动是多么重要。跨阶段流程以及在整个项目生命周期中的规划是 Sure Step 中的关键要素。当涉及到 UAT 时，我们将真正享受到这种策略的好处。我们的关键用户在整个项目生命周期中都与产品保持联系。他们通过参与、培训和指导每个阶段，逐步建立起对我们产品的知识和认识。在前期参与测试使他们理解了流程和测试的重要性。现在，他们真的准备好在组织和执行 UAT 中支持你了。

你能想象到在分析后几个月都处于脱节状态的关键用户吗？他们现在才得到一些培训？仅仅要求用户组织在一个他们几乎不了解的系统上执行 UAT，这并没有太多意义。

早期规划和承诺做出差异

UAT 对客户组织的资源规划构成了严重负担。客户的大量员工需要腾出时间进行培训和用户验收测试。尽管如此，这家公司仍在运营模式中，因此他们的缺席需要提前仔细规划！至关重要的是，客户真正承诺投资这项努力，因此他们也需要提前得到激励。没有早期规划和真正的承诺，我们将遇到麻烦，而“没时间，以后再说”的借口将响彻我们的耳畔。好消息是，我们在设计阶段就已经与客户合作制定了部署计划。至少我们按照 Sure Step 的方式做了！

用户验收测试的重点

UAT 必须专注于测试完整的端到端系统，以确保新解决方案满足客户业务需求。测试场景的重点是不同部门的用户日常操作，支持上线后的运营使用。我们不是逐个测试需求，而是基于真实数据测试现实生活中的业务流程。这些测试还必须证明用户能够正确使用系统。

记录和分析结果

测试结果需要被汇编、分析和随后与测试标准进行比较。Sure Step 提供了高效的 UAT 测试脚本工作表和模板。这些工具是针对产品特定的，甚至包括基于角色的版本。它们还可以包含一些预配置的测试场景。

下面的截图给出了一个产品特定 UAT 测试工作表的示例，包括产品特定的测试内容：

执行性能测试

许多变量可以相互作用，影响系统性能。可能会有大量用户、大量交易、配置不当的基础设施或环境变量；还有许多其他元素也可能影响性能。我们需要在上线前后仔细审查性能。因此，在这个阶段安排性能测试并非奢侈。

基础设施准备就绪

在这个阶段，我们需要确保我们将在上线期间和之后在一个稳定且性能良好的环境中运行我们的新解决方案。这就是为什么我们需要在部署阶段继续我们的基础设施工作，通过构建和配置生产环境和灾难恢复环境。

下图列出了可以初始化的可能环境：

检查和交叉检查

乘务员，请准备交叉检查。您熟悉这些话吗？交叉检查是在飞机从登机口推出前和飞机着陆时乘务员执行的一个程序。检查门是否已经装备了紧急逃生滑梯的程序只是确保飞机可以安全滑行、起飞和着陆的一系列检查之一。这确保了符合客户期望的安全和质量服务。

当我们准备上线时，我们也应该执行一些检查。延迟和崩溃也不会给我们的业务留下好印象。这就是为什么我们需要评估最终系统准备情况，并确保所有必要的步骤和可交付成果都已到位。Sure Step 上线检查清单可以是一个有价值的工具，帮助我们与客户协作完成该程序。

准备起飞

上线启动了在新系统中成功处理日常业务交易和活动。到达这个阶段花费了时间、努力、汗水、泪水、会议、电子邮件、互动，尤其是大量的辛勤和智慧的工作。这是客户组织和咨询团队的起飞；这是一个宝贵的时刻，但如果计划不当，也并非没有危险。就像任何一次出发一样，我们需要保持专注并准备应对一些潜在的动荡。为了使上线切换成功，我们需要规划和记录我们的切换程序。我们甚至可能需要将切换过程作为彩排来运行。Sure Step 提供的上线切换计划可以帮助我们这样做。重新使用部署计划，并添加一个关于切换过程的单独部分可能也很有价值。

一旦进入天空，就鼓掌并打开那些香槟吧，因为这确实是一项成就！与客户一起庆祝这个特殊的时刻不仅有趣，而且加强了双方团队的成功感。这是应得的，享受吧！

运营阶段

打包好行李了吗？其实并没有。上线广播了我们的项目，但我们的表演还没有结束。上线不是项目的终点。现在是时候提供一些在船上的服务了。

提供上线后支持

在上线切换时刻之后，最终用户组织将面临关键挑战。他们现在真的需要放弃他们旧的和熟悉的流程，适应新的程序和软件的功能和特性——这对他们来说不是一件容易的事情，他们需要我们的支持。想象一下有人走进你的办公室，给你一台全新的电脑，里面装满了不熟悉的程序。那会是什么感觉？仅仅知道有专家在那里解答他们的疑问和担忧，就是一个令人安慰的想法，并且可以避免任何恐慌的情况。优质的现场支持也将使我们能够向关键用户建议如何解决具体问题以及一般支持的角色。一个优秀的关键用户团队还将筛选各种支持请求。在上线后支持的长时段内，咨询组织也可以从现场支持切换到远程支持，通过实时会议、电话或电子邮件通讯使顾问可用。这一步骤需要有一个成熟的关键用户组织，能够控制大部分支持请求——这也是在整个项目生命周期中投入时间和精力的另一个好理由。

假设在这个阶段你将不再收集问题和变更，就像押错了马。新系统运行的前几天甚至几周会产生大量的问题和变更请求。这些应该按照之前阶段相同的方式进行管理。然而，我们需要意识到，大量的投诉、问题和变更请求可能是由对变化的抵抗、恐惧和其他挑战引起的。这就是为什么我们可能需要考虑额外的沟通和培训，以帮助客户度过变化的现实。

一些需要做的事情

在方法论中包含运营阶段的好处是，它使我们能够在项目开始之前和期间向客户传达一些重要的事情。它清楚地表明，我们将在上线后继续提供服务，因为我们还有一些事情要处理。

清除挂起的项目

其中之一就是解决开放的问题。这些问题可能在上线切换时刻之前就已经被识别，但直到上线后才得到处理。我们将在上线时刻始终存在一些问题，这不能成为推迟上线的理由，除非这些问题确实非常关键，被认为是障碍。在你到达那个点之前让客户意识到这一点是明智的，Sure Step 将帮助你做到这一点。

现在我们已经到达了需要在运营阶段执行某些事情的时刻。这项活动可以在 Sure Step 中找到，称为清除挂起的项目，这表明我们需要与客户合作，找到我们开放问题的最终解决方案。在大多数情况下，并非所有问题都会得到解决，因为一些问题对业务运营没有影响。这是沟通和谈判的努力，以确保双方都满意。“不要把你的常识放在外面”是信息。

完成知识转移

我们需要确保在我们离开之前，客户将能够访问所有重要的资源，使他们能够接管控制权。他们需要知道所有文档存放的位置，管理员需要能够获取安全权限文档，实际的支持信息和日志需要转交给客户支持团队，并且他们需要知道如何登录到CustomerSource（一个微软门户的名称）。

进行性能调整和优化

一旦我们的解决方案运行了几天，就是时候衡量性能并提供额外的调整和配置了。真正的性能瓶颈可能只有在上线后才会显现出来。在这个阶段主动进行这项工作比等到性能下降到不可接受的水平，用户开始抱怨解决方案的性能，更为明智。

将解决方案过渡到支持阶段

是时候说再见了。实施顾问不可能永远驻场，客户组织需要对其新解决方案负责。他们可以完全自行组织支持，或者使用合作伙伴的运营支持服务。

要结束还是不要结束

要结束！项目按定义是临时的，因此它们需要一个结束日期。正式的结束是项目管理的一个基本组成部分。如果没有结束，我们就会陷入一个我们没有组织并且没有足够预算的运营。最终，不结束我们的项目将蒸发掉我们辛勤工作所获得的全部利润。

结束——这是一项不错的小工作吗？

我们希望如此，但不幸的是，我们都知道得更清楚。结束是所有事情汇聚的地方，当我们说所有时，我们的意思是所有。我们的项目沟通有多好？我们的项目文化有多强大？我们交付了什么质量？我们实现了什么时间和成本绩效？我们的工作说明书（SOW）是否良好？此时我们与客户的关系状况如何？我们的项目管理是否有效？客户现在是否熟悉签字程序？

逐步构建

项目关闭是通过在整个项目生命周期中工作逐步构建的。通过关卡评审报告、重要可交付成果的签字、项目状态报告、指导委员会会议和正式测试结果来结束阶段，只会使你的论点更加强大。在尝试获得签字时，需要跨越一座大桥梁，这现在代表了自 SOW 批准以来的第一次签字尝试。作为项目经理，我们需要理解项目关闭是我们工作的一个基本任务，而且这不是免费的午餐。我们需要在整个过程中努力实现关闭。

核心挑战

结束的核心挑战是对可交付成果与 SOW 的审查。我们需要证明我们交付了我们承诺在 SOW 中交付的内容，而当可交付成果在 SOW 中未指定时，这可能是一项艰巨的工作。这再次强调了可交付成果思维相对于活动思维的重要性。充斥着活动的 SOW 将难以与所交付的内容进行比较，并打开长期而耗时的讨论之门。购买一辆可以驾驶的东西指的是哪种类型的汽车？很难说，对吧？

请签字！

是的，你需要有一个正式的验收，代表这个项目的结束。为了实现这一点，我们必须提前很好地沟通，并组织一个有固定议程的正式会议，理想情况下由项目经理、执行利益相关者和赞助商参加。有了正式的签字，我们的旅程就结束了。我们现在可以下飞机，庆祝我们的成功之旅。

敏捷实施项目类型

在上一节中，我们详细讨论了 Sure Step 中瀑布方法的选项。现在，我们将转向敏捷方法，正如我们之前提到的，它代表了一种迭代式解决方案开发方法，该方法促进了拥有和指定解决方案需求的资源与负责解决方案开发和部署的资源之间的协作过程。

敏捷项目类型是在 Sure Step 2010 版本中引入的，主要是为了方便那些期望将 Microsoft Dynamics 作为平台并定制解决方案以满足其特定需求的客户。在这样做的时候，这些客户往往在开发过程中逐步调整他们的需求，这需要一种灵活和迭代的开发方法，这正是敏捷项目类型理想适用的地方。

下一个截图显示了 Sure Step 中的敏捷项目类型。左侧的导航树视图和右侧的方法论面板描绘了敏捷项目类型的冲刺周期：

虽然 Sure Step 的瀑布方法有五个阶段的活动流动，但 Sure Step 敏捷项目类型有冲刺周期来涵盖分析、设计和开发阶段。敏捷项目类型确实有两个阶段，即部署和运营，在冲刺周期结束时。因此，在这种情况下，敏捷项目类型偏离了严格的敏捷方法，被设计为 ERP/CRM 部署的混合方法。

敏捷项目类型从一系列构成敏捷准备阶段的活动开始。从项目启动活动开始，敏捷准备以实现其主要目标——创建初始解决方案待办事项而告终。这个待办事项代表了解决方案需求的初始子集，它将被用于下一阶段开始开发过程。

敏捷执行阶段紧随敏捷准备之后。这个阶段以两个冲刺周期为特色。冲刺周期，也称为敏捷，指的是一个最长持续四周的时间段，在这个时间段内，团队对已识别的待办事项集执行解决方案的开发。Sure Step 敏捷项目类型有两个冲刺周期——一个包含在 30 天冲刺周期内的每日冲刺周期（如前一个截图所示）。开发活动每天进行，包括计划、分析、设计、开发和测试。这些活动针对冲刺待办事项进行，这是一个从解决方案待办事项中编译出来的需求列表，它被分解为更小的产品特性增量。在冲刺规划会议期间，冲刺待办事项中的需求进一步分解为可管理的任务。

在冲刺周期结束时，有一个冲刺技术预览活动，在此期间，实施团队和客户团队将审查为需求开发出的解决方案。这是一个关键活动，其中需求被批准或拒绝，并反馈到解决方案待办事项中，以便可能包含在未来的冲刺周期中。还进行冲刺后审查，以评估团队的表现并讨论任何改进的机会。在最终的冲刺周期之后，进行整体解决方案测试，并最终确定客户生产环境的规格。

在敏捷执行阶段结束时，解决方案随后进入部署和运营阶段的相关活动，包括用户培训和 UAT。这些活动在《Sure Step 瀑布实施阶段》部分中已有讨论。这两个阶段和活动也标志着从经典敏捷方法向业务应用程序解决方案交付的混合方法的转变。

敏捷项目类型的典型使用场景包括以下内容：

• 选定的 Microsoft Dynamics 解决方案与客户需求有相当程度的匹配——大约 50%到 75%。为了使解决方案符合客户的解决方案愿景，所需的定制预计将是中等至复杂的，以便开发工作可以封装在冲刺周期内。此外，预期的解决方案可能包括也可能不包括 ISV 解决方案，以及核心的 Microsoft Dynamics 解决方案。

• 定制代码开发可能包括与第三方源集成的接口或集成，以及从遗留系统或第三方系统迁移数据到预期的解决方案。再次建议，这些编码工作不应过于复杂。

• 业务流程分析活动和 OCM 活动可能包含在合作范围内。这些活动将与敏捷项目类型中的开发活动并行执行。

• 敏捷项目类型通常适用于单点实施，但它可以扩展到大约三个地点的小型多地点合作。

使用敏捷项目类型需要项目团队采取非常严谨的方法来控制项目的整体范围并管理其实现。强烈建议选择此方法的组织拥有经验丰富的 Scrum Master 或冲刺周期经理——这些人对敏捷学科非常熟悉。

与标准项目类型相似，使用敏捷项目类型的客户组织也应该拥有在部署和使用业务解决方案方面拥有多年经验的业务和 IT 用户。同样重要的是，经验丰富的用户应被选入解决方案交付团队，并在实施过程中积极支持服务提供商。

敏捷项目类型也可以用于开发多站点部署的试点解决方案。此类解决方案推广使用场景在前面一个标题为“设置解决方案推广计划”的章节中描述。

在下一节中，我们将描述敏捷、快速和企业项目类型的一些用例。

用例：敏捷项目类型用于跨国化学品客户

在完成尽职调查后，一家化学制造商选择了微软 Dynamics CRM 作为他们的解决方案。客户选择微软 Dynamics CRM 解决方案，因为它可以作为平台使用，并且可以将扩展 CRM 或 xRM 功能作为构建满足他们特定需求的解决方案的起点。

在客户和实施合作伙伴通过解决方案需求的过程中，他们感觉到虽然他们对整体需求有很好的理解，但在开发周期中很可能会发现解决方案的更多用例。客户和合作伙伴都有基于冲刺周期解决方案开发方法的经验，并且有经验的项目经理来以迭代方式管理解决方案交付。因此，他们决定敏捷项目类型为他们提供了最佳的定制解决方案交付方法。

SOW（解决方案工作说明书）的结构设计包括九个月度冲刺周期，用于解决方案的第一版发布。解决方案需求构成了初始解决方案待办事项列表，并成为确定冲刺待办事项的起点。

用例：快速项目类型用于 GP 客户

在中小企业领域的一个分销商选择了微软 Dynamics GP 解决方案来支持他们的财务需求。客户正在使用一个过时且不受支持的 ERP 解决方案，无法满足他们增长和系统额外用户需求。公司决定与获得金牌认证的微软 Dynamics GP 合作伙伴合作，快速安装一个有限的解决方案，用于财务报告、客户和应收账款老化、供应商和应付账款跟踪。

合作伙伴使用 Sure Step 中提供的固定范围提案和工作说明书作为起始模板，并据此定制合作内容。

实施采用快速项目类型，包括解决方案设计、安装、配置和数据转换的具体活动。还包括一个会议室试点（CRP）活动，使用户能够预览即将推出的解决方案，并有机会审查解决方案配置，以确保其符合拟议的设计。

用例：全球广告组织使用企业项目类型

一家全球广告组织发现自己由于过时的财务管理应用程序而无法满足不断增长的客户对详细信息的需求。为了提高其财务报告能力，公司决定选择微软 Dynamics AX 作为一流的财务管理软件，因为它具有其全球组织所需的可扩展性和本地化能力（包括语言和法规）。

由于解决方案交付的规模，客户需要一个具有全球影响力、能够理解当地需求、语言和法律的实施合作伙伴。客户选择了微软服务及其微软全球解决方案印度（MGSI）团队，与他们的企业项目团队合作，以在多个地点开发和部署解决方案。

使用 Sure Step 企业项目类型和指南，团队共同努力收集解决方案的功能性需求并设计解决方案。客户对交付方法印象深刻，以至于他们的副总裁和公司财务总监评论说：

与我们合作实施项目的微软服务顾问对产品了如指掌。顾问使用的项目管理方法最小化了范围蔓延，这在大型系统实施中非常常见，使我们能够按时并在预算内完成。

到本文写作时，已有超过 30 个机构正在使用微软 Dynamics AX，还有更多部署正在进行中。该公司还运行一个内部托管的微软 Dynamics AX 解决方案，以支持其较小的机构。提供的实施方法为这次成功的交付奠定了基础。客户的全球项目经理补充说：

Sure Step 是一种经过深思熟虑且灵活的方法，使我们能够提出符合我们全球战略的统一计划和途径。它有助于部署的资源规划，提供每个部署的持续财务状况，并使我们能够设定对所需员工时间承诺的预期。

摘要

在本章中，我们重点介绍了 Sure Step 的项目生命周期规划，并讨论了瀑布和敏捷项目类型、跨阶段流程以及如何设置解决方案推出计划。我们了解到 Sure Step 确实有助于参与智能项目，因为它通过智能生命周期规划使我们能够主动、目标导向、高效且灵活。Sure Step 教导我们，在处理项目需求时需要灵活，而不是在所有项目中采用相同的方法，同时也要关注与客户利益相关者的持续互动。

作为快速参考，以下项目类型为您在解决方案交付方面提供了所需的灵活性：

• 快速项目类型是为微软 Dynamics 解决方案的即用型实施而设计的，标准解决方案的定制为零或最小。

• 确步标准项目类型适用于大多数微软 Dynamics 项目，通常用于中等规模的单站点实施，需要适度的定制和附加解决方案。

• 企业项目类型是为与复杂需求和解决方案场景进行大规模合作而设计的，这些场景需要深入的治理和监督。

• 敏捷项目类型代表了一种迭代式解决方案开发方法，它促进了解决方案的开发和推广过程中的协作过程。

• 确步还包括基于瀑布的升级项目类型，将在后面的章节中介绍。

在下一章中，我们将学习到由确步支持的必要质量保证和控制原则。下一章还将介绍优化方案。

第六章. 质量管理和优化

在上一章中，我们学习了 Sure Step 支持的瀑布和敏捷实施方法。我们讨论了基于这些方法的不同的项目类型，以及这些项目类型跨越的实施阶段和跨阶段流程。我们还学习了 Sure Step 提供的活动、模板和指导，以实现解决方案交付。

在本章中，我们关注 Sure Step 的质量方面，这包括在解决方案交付期间可以采取的主动行动，以及确保解决方案持续维护和成功实施的 Post Go-Live 步骤。以下将涵盖以下主题：

• 质量管理在 Sure Step 不同领域的体现

• 如何在瀑布式和敏捷式项目类型中嵌入质量控制

• Sure Step 优化产品路线图——对服务提供商的意义，特别是那些刚开始在 Microsoft Dynamics 领域工作的，以及客户如何从中受益

理解 Sure Step 中的质量管理体现

质量管理实践，包括质量控制和质量保证，是确保正在开发的解决方案符合客户期望的解决方案交付过程中的基本方面。W. 爱德华兹·戴明博士是质量革命的先驱之一，首先在日本，然后在美国，最后在全世界。戴明博士的教诲和哲学起源于制造业，但随时间扩展到多个学科，他的作品通过多本书籍和文章被生产和复制。戴明博士强调，通过创建“一个旨在推动组织向产品和服务的改进并持续永久地改进系统的目的一致性”，质量和效率可以同时提高。

在 Sure Step 方法论中，质量控制和质量保证体现在许多领域，包括实施项目类型的每个跨阶段的活动。以下是一些质量控制和管理被强调并特别指出的领域：

• 在 Sure Step 项目类型中，项目管理跨阶段包括针对质量控制的具体活动和模板。

• 在 Sure Step 项目类型中，质量和测试跨阶段专注于尽职调查，以确保解决方案按照约定的标准和要求进行配置和定制。

• Sure Step 在优化框架下提供几个产品。优化产品包括从技术和治理方面对实施进行主动监督，以及在生产期间可以执行的操作，以确保解决方案继续有效运行。

• Sure Step 还包括在项目管理库中展示质量管理内容的参考内容。

我们将在本章中更详细地审查前三个主题。我们将把关于项目管理库及其质量管理内容的内容留到下一章讨论。

在项目类型中控制质量

在 Sure Step 实施项目类型中，质量管理的执行通常被强调并委托给高级角色，如项目经理、解决方案架构师和测试员。这些角色负责领导解决方案交付过程，因此监督解决方案交付的质量被视为他们角色的自然延伸。因此，项目管理和质量和测试跨阶段的关键活动被特别指出，以监控实施的质量，项目经理、解决方案架构师等作为可交付成果执行的负责人。在项目管理跨阶段，关键的质量关注活动包括满意度条件（CoS）的记录和关卡评审的执行。质量和测试跨阶段包括在交付周期早期确保建立质量标准的活动。此外，监控和测试活动是这个跨阶段的关键要素，每个阶段都有具体的活动。

程序管理中嵌入的质量活动

满意度条件是项目成功的衡量标准，以及允许团队明确确定项目成功或失败的合作目标。Sure Step 中的指南要求在合作开始时确定 CoS 的要素，并在项目章程或类似的项目文档中注明。项目经理负责与客户合作确保执行此活动，并确保客户签署文件，从而表示他们的接受。

在实施过程中的质量控制的关键组成部分是关卡评审。对于瀑布项目类型，关卡评审的执行在每个阶段结束时进行。对于敏捷项目类型，关卡评审以冲刺回顾的形式出现，在每个冲刺周期结束时执行。

水落石出项目类型的关卡评审通过回顾相应阶段实现的关键里程碑和完成的关键可交付成果来评估项目的当前健康状况。任何项目问题和风险也会被识别、记录，并确定缓解措施。这可能包括要启动的项目范围和变更请求，以及请求客户的批准。在此活动期间还会执行对项目整体时间表的任何调整。关卡评审还用于评估项目在解决客户识别的满意度条件方面的表现。

最后，为了客户和项目团队的利益，记录了经验教训，这在项目运营阶段结束时尤其关键，因为它们可能产生对未来相关合作的重要指导方针。

在敏捷项目类型中，项目团队成员使用冲刺周期评审来讨论每个冲刺周期结束时流程的相对成功和失败。团队专注于在冲刺周期中遵循的过程和工作实践，包括团队如何协作以及是否需要在下一个冲刺周期开始之前进行任何改进。

关键质量和测试跨阶段活动

在实施早期建立质量和测试标准可以减少在解决方案配置、开发和测试中的任何歧义。这些标准收集并记录在测试计划中，传达了进行软件测试和验证时应遵循的一般程序。计划可能包括特定的测试用例或场景及其预期结果。它还可能包括客户组织中的预期业务流程和工作流程变更。

测试计划还提供了在实施过程中将执行的一般监控和测试活动的概述。在 Sure Step 方法中，测试活动特别受到强调——合作的范围越大，推荐的严格性和测试数量就越多。以下图表显示了大规模合作推荐的测试：

在项目合作初期，实施团队确定了解决方案需求，并进行了适应性-差距分析，以确定符合标准解决方案的需求、差距以及所需的定制。测试活动从解决方案开发阶段的解决方案适应性和解决方案差距开始，然后在部署阶段测试整体解决方案。

在解决方案开发过程中进行的头三个测试是在开发团队内部执行的。这些测试不需要客户团队参与。尽管如此，在下一个测试系列中客户团队将需要参与，但如果在开发过程中，例如，需要澄清某个需求，开发团队可能需要根据需要查询客户的主题专家（SMEs）。

功能测试

此测试由交付团队中的应用顾问执行，专注于系统的配置和设置。此测试的目标是确保系统配置符合在功能需求文档（FRD）和功能设计文档（FDD）中描述的要求。

让我们以一个客户需求为例，该需求涉及对超过一定数量或金额的订单进行审批的特定工作流程。该需求的设计在 FDD 中定义，系统配置为遵循此审批工作流程。首先由应用顾问执行功能测试，以验证是否满足要求。在稍后的阶段，客户 SME 也将验证此配置。

单元测试

单元测试是对为系统修改编写的自定义代码进行的独立测试。它由开发者执行，并基于在技术设计文档（TDD）中描述的解决方案设计。

例如，假设客户的营销部门需要在客户的总表中添加一些自定义字段，以便他们能够对客户进行分类和细分。可以使用 TDD 来描述系统中需要修改的特定表。在系统相应地定制后，开发者将执行单元测试，以验证字段是否已按要求创建。

功能测试

功能测试是单元测试之后的测试。与单元测试一样，它也专注于自定义代码，但与单元测试不同的是，功能测试由应用顾问执行，并基于 FDD。目标是确保系统修改与客户的功能或业务需求一致。

在我们之前的自定义字段示例中，在客户的总表中，在单元测试之后，应用顾问将执行功能测试，以验证营销部门的业务需求是否通过定制得到满足。这可能包括，例如，验证字段是否放置在相应的表单的正确位置，以及营销人员是否有适当的值可用。

从这里提到的例子中可以看出，这种测试的严格性是显而易见的。然而，如果读者认为测试的数量似乎对较小的项目来说过多，他们可以考虑在可行的情况下合并测试。但是，对于可能包含数百个简单和复杂要求的大型项目，这种严格性是必要的；因此，强烈建议读者不要采取任何可能带来不必要风险的捷径。跳过个别测试可能会导致在流程下游发现问题。正如任何经验丰富的顾问会告诉你的，测试解决方案的较小子集以隔离任何潜在问题更好。另一种方法，即更耗时和费力的方法，是测试所有设置，以尝试确定问题是否在于单个代码子集，或者是否由于与其他代码元素的交叉。从这个意义上说，你可以将其与制造过程进行比较。在多部件制造中，在组件制造过程中检测质量问题是至关重要的。等到组装时发现不匹配的部件可能会关闭组装线并导致昂贵的延误。正如在制造过程中一样，在整体测试解决方案之前，在解决方案开发期间测试单个代码组件同样重要。

上文所述的测试是在实施团队内进行的。剩余的测试是在客户参与解决方案实施的人员直接参与下进行的。这些测试的成功取决于这种参与，以确保解决方案按原设想开发。

子流程测试

子流程测试包括对公司整体业务流程子集的测试，以确保新解决方案的用户将获得一个按原设想执行的系统。这项测试由应用顾问执行，客户领域专家参与、验证并签署解决方案子集。

客户订单处理流程的测试是子流程测试的一个例子。新的解决方案在测试环境中设置，客户领域专家与应用顾问合作运行系统，检查订单处理工作流程是否直观且符合约定的设计。

流程测试

虽然子流程测试关注公司工作流程的子集，但流程测试是对构成定义业务流程的相关功能和功能的完整测试。这项测试也由应用顾问与客户领域专家一起执行。

从 ERP 解决方案的角度来看，订单到现金工作流程或采购到付款工作流程的测试是流程测试的例子。在订单到现金流程测试中，客户行业专家验证系统是否按预期执行客户订单输入、订单履行和订单付款，包括在付款逾期时提醒适当的客户服务人员。在采购到付款流程测试中，行业专家验证他们能否按照设计向供应商下采购订单，能否接收和记录供应品的交付，以及他们能否在组织适当的付款惯例内支付供应商的货物。

从 CRM 解决方案的角度来看，流程测试的例子包括报价到订单工作流程，其中 CRM 系统中捕获的报价可以追踪到转换为订单，或者像自助服务门户工作流程这样的用户获取文档或对特定查询或请求状态的答案。

数据接受测试（DAT）

DAT 是业务解决方案交付的重要测试。DAT 的第一个目标是验证从现有系统迁移到新系统的数据是正确的数据子集，并且数据已经按需清理。DAT 的第二个目标是验证所有用于交易、查询和报告所需的数据都可用。DAT 应由客户的数据所有者和最接近数据元素的关键用户执行，他们可以识别任何不足之处。如果需要在测试过程中验证数据源，DAT 也可能涉及客户的 IT 人员。

DAT 的重要性不容忽视，因为新系统的行为取决于其数据库中填充的数据。如果数据不正确，无论新系统有多好，用户只能更快或更轻松地获得错误信息。

假设客户的一个供应商是 ABC 公司。由于旧系统中缺乏数据输入检查和规则，发现多个记录中输入了相同的供应商名称（如 ABC、ABC Corp 或 ABC Corporation）的情况并不少见。为什么会有这个问题？采购经理没有对 ABC 公司所有订单的真正概览，没有这些，他或她可能没有足够的谈判折扣的筹码。

集成测试

集成测试是对特定业务流程的端到端测试，包括系统设置、开发、报告以及对任何外部子系统的集成或接口的测试。集成测试由公司的行业专家、关键用户和应用顾问执行。公司的 IT 人员也可能参与此测试，尤其是在与外部系统接触点相关的情况下。

在流程测试的订单到现金和采购到付款工作流程测试示例中，如果流程需要连接到外部系统或数据库进行报告或其他原因，集成测试将解决并验证这些场景。

集成测试通常执行不足，因为模拟实时集成环境存在困难。这些测试需要大量的前期规划，通常涉及其他系统供应商。

性能测试

性能测试是一项技术测试，侧重于系统在高峰时段预期的交易量中的表现。这项测试由公司的 IT 人员、领域专家、应用和技术顾问进行。

性能测试可以利用预制的脚本填充系统并模拟高负载。然而，根据对标准系统进行的定制数量，脚本的开发可能需要数小时的人工。但根据对应业务流程的系统响应速率的重要性，这项测试可能非常重要，以验证在负载下配置的系统是否符合业务需求和商定的性能指标。

性能测试的一个例子是监控系统对多个订单输入的响应，这包括验证客户的信用和未付款项。

用户验收测试 (UAT)

UAT（用户验收测试）是客户领域专家、关键用户和应用顾问为系统验收而进行的最终测试。UAT 是客户接受新解决方案进行上线的重要指标。

UAT 使用从客户现有系统迁移的数据，并使用客户指定的特定时期（如一两天）的实际交易作为其业务代表性的样本。测试侧重于完整的端到端测试，以确保系统符合业务需求和实施初期设定的测试标准。UAT 通常在测试或预生产环境中进行。UAT 利用预先填充测试步骤和预期结果的脚本，并将测试的实际结果记录下来供未来参考和客户批准。以下截图显示了 Sure Step 提供的许多 UAT 脚本之一：

如果测试被判定为成功，客户将签署系统以进入生产。然而，客户可能仍要求对某些功能、数据迁移或集成流程进行更改。这些更改将通过在合作初期建立的变更管理流程进行。

在前面的章节中，我们看到了 Sure Step 如何在项目类型的活动内嵌入指导和模板，以确保提供高质量的解决方案。现在，我们将讨论确保客户对整体解决方案和交付过程满意的其它途径。

The Sure Step Optimization Offerings

Encarta 词典对优化的定义是：提高某物的有效性，使某物以最佳或最有效的方式运行，或充分利用某物。优化可能因观点不同而意味着不同的事情。从系统的角度来看，优化可能意味着提高系统易用性或响应速度的过程。对于程序来说，它可能意味着尝试减少运行时间、带宽或内存需求，而对于计算机代码，优化可能包括提高编译代码的性能或效率。对于业务流程，优化可能意味着提高该流程的效率，包括降低成本或通过时间。对于 Sure Step 中的优化产品，所有这些定义都在一定程度上适用。

Sure Step Optimization Offerings 包括一系列旨在积极帮助降低实施或升级风险的解决方案，同时协助客户确保其系统在生产时表现最佳。根据产品的复杂性和优化需求，优化产品以不同的方式打包和捆绑。以下是一个概念图，但请参考各个产品的具体产品提供图，以确定该产品提供的具体服务：

优化产品包括两种类型的服务：主动服务和上线后服务。主动服务在解决方案交付期间以及与解决方案交付团队一起提供；因此，它们涵盖了 Sure Step 的分析、设计、开发和部署阶段。上线后服务在 Sure Step 的操作阶段执行，通常在解决方案投入生产一段时间后。

主动服务可以进一步分为技术主动服务和项目治理服务。技术主动服务通常由架构师或同等高级资源在解决方案交付期间执行。这些服务的例子，将在接下来的章节中进一步解释，包括架构审查、功能和技术设计审查、定制审查和性能审查。另一方面，项目治理服务是由项目经理或同等高级项目管理资源在整个合作生命周期中执行的管理监督服务。项目治理和交付审查服务是这个类别的典型例子。

上线后服务本质上是技术性的，因为实施已经完成。这些服务通常由高级支持工程师、架构师或同等高级资源执行，并在解决方案投入生产时执行。例如，包括健康检查和性能调整服务。

Sure Step 为每个 Dynamics 产品提供五个优化方案。优化方案因产品而异，包括分组和/或单个的主动服务和上线后服务。这种结构为客户和解决方案提供商提供了灵活性，以便为特定合作选择一个或多个优化方案服务。

Microsoft Dynamics AX 的优化方案

Microsoft Dynamics AX 项目通常代表最复杂的实施，因此，AX 的优化方案包括许多分组和单个服务，这些服务可以捆绑起来以满足特定的客户需求。

下面的屏幕截图显示了 AX 优化方案的概述：

AX 优化方案包括分组的服务架构审查，它包括多个单个服务，如基础设施设计审查、功能设计审查、技术设计审查、定制审查和性能审查。项目治理和交付审查（PGDR）——它包括生命周期（分阶段）审查和项目关闭审查——以及升级审查也是分组服务。分组服务用灰色带虚线的框标出，以包括构成这些分组服务的单个服务。

本 AX 优化方案中还包括的其他单个服务有数据库存储、集成设计审查、性能基准、健康检查和性能调整。

客户可以选择选择一组或多个分组或单个服务，这些服务可以捆绑在一起或作为独立服务。如果它们是捆绑的，它们通常按照前一个屏幕截图中的顺序执行，以提供更稳健和全面的服务体验给客户。

微软 Dynamics CRM 优化方案

CRM 优化方案的服务打包方式与 AX 不同。所有 CRM 优化方案服务都是个别服务，不包括分组的项目治理和交付审查以及升级审查服务。

以下截图是微软 Dynamics CRM 的优化方案图：

CRM 方案提供包括架构审查、设计审查、定制审查、性能审查、健康检查和性能调优在内的技术服务。

微软 Dynamics GP 优化方案

GP 优化方案包括适用于 AX 和 CRM 的几个个别服务，包括基础设施设计、报告服务研讨会、管理员研讨会，以及 Proactive Services 的性能审查，以及 Post Go-Live 服务的健康检查和性能调优。

以下截图是微软 Dynamics NAV 的优化方案：

注意，GP 没有独立的架构审查，因为这种合作和复杂性通常不需要这种分组服务。它也没有定制审查，因为这些类型的实施通常不涉及大量的定制代码。

它也不需要 PGDR，因为那只是对更复杂合作的一个强烈建议。然而，GP 确实有一个升级审查服务。

微软 Dynamics NAV 优化方案

与 GP 方案类似，适用于 AX 和 CRM 的 NAV 优化方案包括个别服务，如基础设施设计、Proactive Services 的性能审查，以及 Post Go-Live 服务的性能调优和健康检查。

以下截图显示了微软 Dynamics NAV 的优化方案：

与 GP 类似，NAV 没有独立的架构审查，因为这种合作和复杂性通常不需要这种服务。它也没有定制审查，因为这些类型的实施通常不涉及大量的定制代码。

它也不需要 PGDR，因为那只是对更复杂合作的一个强烈建议。目前，NAV 没有升级审查优化方案。

微软 Dynamics SL 优化方案

SL 优化方案包括两个适用于 AX 和 CRM 的个别 Proactive 服务，基础设施设计和性能审查。它还包括一个 Post Go-Live 服务，以及性能调优。

以下截图显示了微软 Dynamics SL 的优化方案：

与 GP 和 NAV 类似，SL 没有独立的架构评审，因为这种参与和复杂性通常不需要这种服务。它也没有定制评审，因为这些类型的实施通常不涉及大量的定制代码。

它也不需要 PGDR，因为那只是对更复杂参与的一种强烈建议。SL 也没有升级评审优化方案。

理解 AX 和 CRM 的关键主动和上线后服务

如前所述，Sure Step 提供技术主动评审服务、项目治理服务和技术上线后服务。这些评审服务通过在实施过程中适当的检查点使客户或服务提供商能够访问 Microsoft Dynamics 专家，从而促进质量管理。这些专家可以审查业务和行业解决方案的提议架构和设计，以及性能、可扩展性、与其他系统和第三方软件的集成等技术领域。

技术主动评审服务包括对新 Microsoft Dynamics 解决方案实施进行的架构评审、设计评审、定制评审和性能评审，以及现有解决方案升级的升级评审。技术上线后服务包括健康检查，用于审查已经运行一段时间的服务解决方案。项目治理服务包括 PGDR。我们将在本节中描述这些精选服务。

架构评审

CRM 的架构评审为客户的 Microsoft Dynamics CRM 解决方案的整体技术设计提供评估，并涵盖包括性能、可扩展性、安全性和发布管理在内的解决方案设计。此服务的目标是确保客户解决方案所设想的基础设施与最佳实践保持一致，并且该服务在分析阶段的后期执行。

在此示例中执行的关键任务包括：技术分析和评审 FRD、服务器架构评审、Fit Gap 和解决方案蓝图评审、集成和接口要求的高级评审以及交易量的高级评审。作为评审的输出，客户和服务提供商的实施团队将获得对提议架构的客观、第三方观点以及它如何与客户需求保持一致。

与 AX 的架构评审不同，AX 的架构评审是一项组合服务，包括基础设施设计评审、功能设计评审、技术设计评审、定制评审和性能评审等多个单独的服务。

设计评审

设计审查服务用于检查 Microsoft Dynamics 解决方案的设计，主要在两个主要领域。对于 CRM，该服务检查 Microsoft Dynamics 系统的定制以及 Microsoft Dynamics 系统与其他第三方系统之间的集成场景，并在实施设计阶段的后期执行。对于 AX，设计审查由两个服务组成，即功能设计审查和技术设计审查。

设计审查项目的目标可能包括以下内容：

• 评估客户 Microsoft Dynamics 解决方案的定制需求

• 评估 Microsoft Dynamics 应用程序与其他系统的集成需求

• 审查功能设计文档差距（FDD-Gap）和相应的 TDD（测试驱动开发）以验证提出的定制和集成设计

• 提供评估，以确定定制设计是否与之前完成并签署的适配性差距分析和解决方案蓝图一致

• 提供优化 Microsoft Dynamics 解决方案架构和集成设计的建议，以提高性能、可用性和可靠性

项目交付成果是设计审查和评估报告，其中包含基于最佳实践开发自定义组件的最佳实践优化集成和定制设计建议。

定制化审查

定制化审查服务专注于分析自定义代码以提高性能、增加稳定性、提高安全性以及降低运营和升级成本。对于 CRM，这是一项独立服务，而对于 AX，这是架构审查组合服务的一部分。定制化审查服务在开发阶段结束时执行，其目标可能包括以下内容：

• 识别自定义编码中的任何最佳实践偏差，包括服务器端和客户端代码

• 审查与标准的符合性，早期发现代码开发错误，并记录偏差

• 确保符合必要的质量指南

• 审查系统组件的接口

项目最终报告提供建议和行动计划，以实施最佳实践并修复发现的问题，以确保 Microsoft Dynamics 系统的最佳长期运行。

性能审查

性能审查服务分析解决方案设计和定制对性能的影响。该服务从审查现有的 Microsoft Dynamics 解决方案和当前及拟议的客户使用指标开始，例如用户数量、数据集大小和交易量。输出是针对 Microsoft Dynamics 服务器（服务器）和将支持 Microsoft Dynamics 解决方案的 Microsoft SQL Server 数据库的性能建议。

对于 CRM，性能审查是一项独立的服务，而对于 AX，这属于架构审查组合服务的一部分。性能审查服务在部署阶段执行，在解决方案开发冻结任何新增内容之后。审查应在解决方案转移到生产之前进行，以便捕捉崩溃、泄漏、性能和其他不符合最佳实践的非架构性问题。性能审查还应考虑在先前解决方案测试表明解决方案某些区域存在潜在的性能影响时。性能审查可以解决以下问题：

• 成本：基础设施运行正常，但成本过高，导致投资回报率不足

• 敏捷性：基础设施运行正常，但缺乏足够的灵活性，无法快速适应业务需求的变化

• 性能：基础设施未能满足用户的期望，要么是因为期望设置不正确，要么是因为基础设施的性能表现不佳

• 安全性：基础设施未能提供足够的数据和资源保护，或者通过过度实施安全措施导致合法用户无法高效访问数据和资源

合作伙伴关系的最终报告提供了针对系统环境、网络拓扑、延迟数字和带宽的系统环境建议。

升级审查

虽然先前的优化服务针对新的解决方案实施，但升级审查服务作为指导，帮助客户将现有的 Microsoft Dynamics 解决方案升级到当前产品版本。升级审查服务在整个升级项目生命周期中提供对客户升级解决方案的监督，包括设计、定制、集成、物理基础设施和架构。

升级审查服务在整个升级项目生命周期内提供以下一系列咨询活动或服务：

• 升级架构审查和升级设计审查：这些服务与升级项目类型中分析和设计阶段的活动相一致，包括升级准备、需求收集、测试计划和环境设置。审查团队评估现有 Microsoft Dynamics 解决方案中的定制化，分析代码组件的升级，并记录问题以及解决方案和建议。此活动的输出可能包括一份升级估算报告给客户。

• 测试升级：这项服务遵循升级架构和设计审查活动，并与升级项目类型的开发阶段相一致。测试升级的目标是为客户提供带有客户现有数据的测试或沙盒环境，这些数据已推广到新的 Microsoft Dynamics 产品版本。然后，可以使用此环境在推广到生产之前验证和基准测试数据。

• 生产升级：这项服务在升级项目类型的部署阶段执行，为将升级后的解决方案推广到生产环境提供现场协助。

升级审查服务与 Microsoft Dynamics Sure Step 中升级项目类型的流程相一致。升级项目类型在相应的升级章节中有详细说明。

健康检查

当解决方案投入生产，并在初始稳定期之后，重新审视解决方案以确保其高效运行是个好主意。在解决方案运行阶段进行定期检查也是一项推荐的最佳实践。这两个目标都可以通过 Sure Step 中的健康检查上线后服务实现。

健康检查服务分析客户的 Microsoft Dynamics 解决方案，并衡量该解决方案在运行中的有效性。解决方案监控允许主动识别任何潜在问题，并为选定的组件提供建议的解决方案。值得注意的是，这些服务通常被纳入企业产品中，例如 Microsoft Premier 提供的 Dynamics AX 服务。

下面的屏幕截图显示了健康检查报告的示例：

项目治理和交付审查

本节中突出显示的前述服务是通常由解决方案架构师和高级应用或技术顾问提供的技术服务。Sure Step 还提供另一项服务，称为项目治理和交付审查（PGDR），通过项目监督和整体项目治理来推动质量。这项服务由经验丰富的项目经理和参与经理提供，通过客户 Microsoft Dynamics 参与的整个生命周期，为客户提供主动的项目治理和交付执行指导。在较高层次上，这些资源执行以下三项任务：

• 分析和评估拟议的参与结构和既定成果

• 监控项目治理与客户和实施团队之间的沟通

• 分析和评估成果的质量，以确保其完整性和相关性

PGDR 包含两个组件——生命周期阶段审查和项目关闭审查。在分析到部署解决方案实施阶段，PGDR 服务作为对交付团队活动的指导和监督，通过主动识别风险和积极管理整个合作范围，帮助他们保持与解决方案约定的愿景一致。一旦解决方案投入运营且合作进入关闭阶段，PGDR 服务评估项目是如何与初始愿景相匹配的，并确定项目进度和质量的表现。

在项目开始时，PGDR 提供服务启动了两个关键活动。客户、审查人员和实施团队共同工作，建立客户的 CoS（客户服务目标）以进行合作。这些 CoS 是项目章程的关键组成部分，章程中还讨论并明确记录了其他关键领域，包括治理、风险、沟通、状态报告和问题管理。

在合作期间，PGDR 服务产生阶段性的推荐和项目健康状况仪表板，以帮助客户在问题成为问题之前识别风险并解决问题。审查人员配备了诸如科布悖论工具等工具，这是一个有效的风险评估工具，提供问卷以检测和监控整体项目风险因素。以下截图显示了科布悖论工具的图形输出样本：

在项目结束时，PGDR 用于共同讨论成就和挑战，并记录经验教训。以下列出了项目结束时执行的一些关键任务。

• 记录经验教训，包括成就、挑战、团队可以不同方式做的事情等。这有时被视为微不足道，但它可以成为未来项目的重要参考资料。

• 审查 CoS 以确定它们是否已经实现。

• 汇总未解决的问题和开放项目，并确定项目关闭后如何解决它们。

• 为未来的项目和与客户部署的 Microsoft Dynamics 解决方案相关的后续工作提供推荐。

PGDR 和技术审查服务对客户和实施团队都有极大的益处，它们可以增强关键领域的资源，提供有价值的独立观点。

还要注意，为了最有效地提供优化服务，应由独立的第三方提供——这意味着，提供者不是解决方案的主要实施者。

优化服务及其益处

提供业务解决方案，尤其是 ERP 解决方案，需要一个行业经验丰富的实施团队，换句话说，就是情境流利。团队必须有能力将系统功能转化为满足客户特定需求的解决方案。当客户选择服务提供商进行解决方案实施时，他们通常会给予行业知识额外的权重。那么，如果服务提供商在特定行业或行业垂直领域非常了解，但对微软 Dynamics 解决方案不太熟悉怎么办？这就是技术审查服务可以大大造福服务提供商和客户的一个领域。经验丰富的行业老将与技术微软 Dynamics 专家的结合可以提供一个强大的团队，为客户解决深层次、具体的需求。

另一个可以利用优化服务中的技术支持，尤其是主动审查服务，从中受益的领域是对于刚开始使用微软 Dynamics 的新 ERP/CRM 服务提供商。经验不足的服务提供商可以通过使用这些服务，在其团队中加入有经验的资源，并且随着团队成员对有经验的资源进行“影子”跟踪，他们可以提升对微软 Dynamics 解决方案的理解。

当服务提供商已经拥有深厚的专业技术知识，但缺乏项目管理专业知识，尤其是在大规模合作中，项目治理和交付审查服务可以带来极大的好处。微软 Dynamics 资源池包括一些在微软收购之前就了解解决方案的个人。虽然这些技术资源对产品本身非常了解，但他们有时缺乏管理复杂、多地点解决方案部署的范围、沟通和风险的经验。利用 PGDR 服务，这些资源可以与经验丰富的项目经理合作，为未来的合作培养这种技能集。他们可以反过来，引导他们的组织扩大其服务范围，以应对更大的客户群。

对于客户来说，包括健康检查和性能调优服务在内的 Post Go-Live 服务非常推荐。鉴于在获取和部署微软 Dynamics 解决方案中投入的大量投资，客户定期获取专家资源来监控应用程序的健康状况是很有必要的。根据使用行为，应用程序可能会随着时间的推移而变得缓慢，系统响应可能对用户来说会显得更慢。此时，Post Go-Live 服务可以用来审查应用程序，随后提出的建议可以帮助清理系统，使其更高效地运行。

从服务提供商的角度来看，可以使用 Post Go-Live 服务来继续维护与客户的合作关系。行业中的一个常见模式是，获得新客户比保持现有客户更难。一旦客户流失给竞争对手，几乎不可能重新获得客户。因此，服务提供商应利用健康检查方案来进一步与客户建立关系。在这样做的同时，他们也可能发现新的相关或不相关的机会，他们可以在这些机会上协助客户。

用例 - 全球广告组织使用技术审查服务

在前一章中，我们讨论了一个使用 Sure Step 的全球广告组织，特别是企业项目类型，用于他们的 Microsoft Dynamics AX 解决方案交付。在Microsoft Consulting Services (MCS)和Microsoft Services Global Delivery (MSGD)资源的帮助下，客户成功地在特定地点部署了初始解决方案。

为了在更多地点推出解决方案，客户决定结合使用内部和合作伙伴资源。客户还决定利用优化方案的技术审查服务，特别是架构、设计、定制和性能审查服务，并让 Microsoft 资源作为独立的第三方审查员执行这些服务。这种方法提供了连续性和一致性，从而降低了相应地点解决方案推出的成本。

用例 - 合作伙伴使用项目治理和交付审查服务

一家大型零售商选择了 Microsoft Dynamics AX 作为他们的解决方案，并选择了一位熟悉他们行业垂直领域的合作伙伴来协助他们交付解决方案。合作伙伴在 Microsoft Dynamics AX 方面很熟练，他们也对其咨询资源的解决方案交付技术能力感到满意。然而，他们对其资源管理整个合作范围的能力表示担忧，尤其是在客户要求的紧张时间表下。

与 MCS 资源在其他合作中成功合作后，合作伙伴认为一个 Microsoft 资源可以帮助降低与激进的时间表固有的整体项目风险。因此，他们建立了一个 PGDR 合作，其中一位经验丰富的 MCS 项目经理对整个合作进行了定期的独立评估。结果是解决方案按时并符合规格的推出，客户和合作伙伴双赢。

摘要

在本章中，我们从在解决方案交付期间可以采取的主动行动以及上线后的步骤来确保解决方案的持续维护和成功，讨论了 Sure Step 的质量方面。我们还讨论了质量如何嵌入到 Sure Step 实施项目类型中，以及通过 Sure Step 优化方案提供的专业技术和管理审查服务中。

在下一章中，我们将学习使用 Sure Step 进行升级，包括评估现有解决方案和确定升级的正确方法，以及执行升级本身的指导。

第七章. 使用 Sure Step 进行升级

在上一章中，我们讨论了在解决方案交付期间以及解决方案运行时，质量如何嵌入到 Sure Step 中。我们涵盖了项目活动中的质量管理作为优化提供。

在本章中，我们将介绍 Sure Step 升级 Microsoft Dynamics 解决方案的方法。以下主题将涵盖：

• 以升级评估服务开始的现有 Dynamics 客户诊断决策加速提供，以确定升级范围

• 确定升级方法是技术升级，还是作为功能升级的一部分提供额外功能

• 使用 Sure Step 升级项目类型进行升级交付

• 向现有解决方案实施额外功能

决策加速提供和诊断阶段

在第三章中，使用 Sure Step 进行解决方案设想，我们介绍了针对当前 Microsoft Dynamics 客户的 Sure Step 诊断阶段流程和模型，无论是从客户的尽职调查角度还是从销售方的解决方案销售角度。在本节中，我们将更详细地讨论该流程，特别是升级评估服务。

我们首先重新介绍展示现有客户 Sure Step 诊断阶段活动流程和决策加速（DA）提供的图表。在 Sure Step 中，一个活动是流程中的特定动作或步骤。一个活动可能产生步骤的可交付成果，或者它可能是导致后续结果的过程中的规定步骤。相比之下，决策加速提供是一个迷你项目，每个 DA 提供可能包含多个服务，每个服务都需要多个动作来实现提供的目标。你可能还记得，流程与潜在客户的流程非常相似，唯一的区别是升级评估服务取代了需求和流程审查服务：

如前所述，现有客户的流程也始于诊断准备，类似于潜在客户的流程。如图所示，典型方法将包括以下三个阶段：

第 1 阶段：需求确定

• 解决方案概述 活动

• 升级评估 决策加速服务

第 2 阶段：备选方案评估

• 适配差距和解决方案蓝图 决策加速服务

• 架构评估 决策加速服务

• 范围评估 决策加速服务

第 3 阶段：风险评估

• 概念验证 决策加速服务

• 商业案例 决策加速服务

• 提案生成 活动

第 1 阶段 – 需求确定

解决方案概述活动是初始阶段的主要活动，围绕确定客户升级的兴趣水平，并提供澄清一些基本要求的机会。此类示例包括：

• 客户是否已在他们的生产环境中部署了他们的 Microsoft Dynamics 解决方案？

• 客户是否表示了对升级到更近版本的 Microsoft Dynamics 的兴趣？

• 是否存在进行升级评估的合格机会？

• 客户是否希望升级到受支持的 Microsoft Dynamics 版本？

当客户对将现有解决方案迁移到当前版本的 Microsoft Dynamics 表示兴趣时，下一步是进行升级评估服务，这是此过程中的关键步骤。在启动升级评估之前，服务交付团队应与客户会面，确认他们有兴趣进行升级。特别是在交付资源需求很高的情况下，这是销售团队在涉及解决方案架构师和高级应用顾问等交付资源之前需要执行的重要步骤。销售人员可以使用 Sure Step 诊断准备活动中的资源来了解和定位相应 Microsoft Dynamics 解决方案的当前能力。

升级评估决策服务

升级评估服务是现有 Microsoft Dynamics 客户在升级过程中的最重要步骤。升级评估服务由服务交付团队执行，以了解客户正在使用的现有解决方案，确定需要升级到产品当前版本的组件，并确定是否需要启用其他功能作为升级合作的一部分。

一旦确定客户对升级的兴趣，服务交付团队就可以进行升级评估服务。升级评估服务的目的是确定现有解决方案升级的复杂性，并突出功能增强、复杂性和风险区域。执行升级评估服务时采取的步骤如下所示：

交付团队通过了解升级的整体目标开始升级评估服务。团队可以利用 Sure Step 为 Microsoft Dynamics AX、CRM、GP、NAV 和 SL 提供的特定产品问卷。这些问卷还包括针对接口、基础设施等的具体部分和问题；因此，它们也可以通过以下步骤利用：

1. 在一开始的重要任务之一是审查 Microsoft Dynamics 的升级路径以及任何相关的 ISV 软件，以确定从客户现有产品版本升级到 Microsoft Dynamics 的目标版本是否得到支持。这将影响升级的执行方式——您是否可以遵循支持的升级路径，或者基本上需要完全重新实现解决方案？

2. 执行升级评估服务的下一步是评估现有解决方案的配置和自定义。在此步骤中，交付团队能够审查为客户启用了哪些 Microsoft Dynamics 功能，包括哪些已配置以满足客户需求，以及哪些已进行自定义。这将使交付团队能够考虑升级的整体目标，并确定哪些配置和自定义需要迁移到新解决方案，哪些应该被淘汰。例如，较旧版本可能需要在解决方案没有相应功能的地方进行自定义。或者，解决方案可能需要特定的 ISV 解决方案来满足需求。如果当前产品版本提供这些功能作为标准功能，那么这些自定义或 ISV 解决方案就不再需要成为新解决方案的一部分。必须将数据迁移（如果需要）从旧版本迁移到新版本作为此步骤的一部分考虑。

3. 升级评估服务的下一步是检查现有解决方案的自定义接口。这包括评估为将解决方案与第三方解决方案（如用于报告目的的外部数据库）接口而编写的任何自定义代码。此步骤之后是审查现有的基础设施和架构配置，以便交付团队能够了解可用于新解决方案的硬件组件。交付团队能够确认现有基础设施是否能够支持升级应用程序，或者是否可能需要额外的基础设施组件。

4. 升级评估服务的最后一步是交付团队对客户的现有解决方案进行详细分析，并生成一份发现报告。这份报告将提交给客户审批，并将包括以下主题：

   • 升级的范围，包括在新解决方案中将得到增强的功能和技术领域的列表。

   • 应用程序功能区域的列表，按类别划分以显示升级它们所涉及预期的复杂性。如果现有实施中有需要进一步检查或需要额外努力才能成功升级的区域，因为其固有的复杂性，它们必须被突出显示。

   • 当前解决方案中可能重新映射到基线 Microsoft Dynamics 产品当前版本中新的功能性的区域。

   • 一个整体推荐的升级方法，包括解决任何所需新功能的替代方案。Dynamics 许可的成本影响也必须考虑。

升级评估服务为客户提供早期识别升级过程中可能出现的问题和风险，以便可以相应地启动适当的缓解措施。客户还可以通过了解升级项目治理的适当水平以及交付团队将采取正确的升级方法来获得一定的信心。

在以下各节中，我们将讨论升级评估服务如何成为完成客户尽职调查的基础，并为客户解决方案的质量升级奠定基础。

第二阶段 – 额外服务和何时获取它们

在执行升级评估服务之后，现有微软 Dynamics 客户的尽职调查过程中可能还需要 DA 产品提供的其他服务。在本节中，我们将讨论可能需要使用其他 DA 服务的场景以及哪些服务适用于特定场景。

从升级评估服务中，交付团队确定需要升级到新版本的业务功能和需求。使用适配差距和解决方案蓝图服务，他们可以确定并记录这些需求如何迁移。如果满足需求不仅仅是实现标准功能，那么方法可能包括重新配置、自定义代码重写或工作流程设置。此外，如果升级需要新的功能，这些需求也应归类到适配差距工作表中，要么作为适配，要么作为差距。根据情况，它们还应进一步归类为标准、配置或工作流程，对于差距则归类为定制。

范围评估服务可用于确定执行升级所需的工作量、时间表和资源。如果通过升级评估服务确定将引入新功能，交付团队和客户还必须确定发布计划。我们将在下一节中更详细地讨论升级方法和发布规划。

架构评估服务可用于确定升级解决方案的新硬件配置。它还可以通过执行概念验证基准子服务来提前解决任何性能问题。

由于许多 Dynamics 产品提供基于云的解决方案，无论是通过托管还是自托管模式，了解将实施迁移到云的潜在影响对于所有或部分实施来说都很重要。Fit Gap 和解决方案蓝图以及架构评估应相应反映。一个例子是新的 Dynamics GP 2013 网络客户端。这可以由 Azure 的合作伙伴托管，也可以自行托管。最近的例子表明，许多企业选择自行托管，本地财务用户选择经典客户端，而供应链或远程用户则使用网络界面。

重要的是要注意，之前讨论的所有三个决策加速服务——Fit Gap 和解决方案蓝图、架构评估和范围评估——如果需要，可以与升级评估服务作为一个客户合作执行。本节的目的不是让每个服务都单独定位给客户。相反，根据范围，交付团队可以轻松地并行执行这项练习。本节对读者的重点强调是，如果你正在评估客户的升级，你应该能够利用每个服务中的模板，并根据你的合作需求进行组合。

第三阶段 – 风险评估

最后，概念验证服务提供和业务案例服务提供也可能适用于升级合作，但通常仅针对一小部分客户。例如，可能使用非常旧版本的 Microsoft Dynamics 解决方案的客户，这意味着他们基本上需要使用产品的新版本重新实施解决方案，或者需要将复杂功能作为升级的一部分启用。在这两种情况下，客户可能要求交付团队在全面升级之前对解决方案进行概念验证服务，在这种情况下，可以执行概念验证服务。他们也可能要求交付团队协助评估升级解决方案的投资回报，在这种情况下，可以采用业务案例。

确定升级方法和发布计划

如前文所述，在升级诊断过程中，客户和交付团队应共同选择合适的升级方法。Sure Step 推荐以下两种升级方法：

• 技术升级：如果升级主要适用于应用程序组件，例如可执行文件、代码组件和 DLL，请使用此方法。只要应用程序功能和业务流程保持相对不变，此方法可以用于将定制解决方案带到最新版本。

• 功能升级：如果在升级过程中希望实现新的应用程序功能或对现有业务工作流程进行重大更改，请使用此方法。在复杂的升级过程中，这种升级方法固有的额外规划、测试和现有解决方案的重工作是内在的，因此更符合功能升级。功能升级通常在多个发布中执行。

以下图表描述了两种升级方法和发布时间表：

根据升级的范围，客户参与可能有一个或多个交付发布。例如，如果客户的解决方案位于受支持的升级路径上，技术升级可能使用 Sure Step 升级项目类型在一个发布中交付。如果新解决方案需要启用几个新流程，功能升级可能需要两个或更多发布来交付。例如，如果客户需要启用高级供应链功能，如生产调度和/或高级仓储作为升级的一部分，则两步升级是推荐的方法。首先，使用 Sure Step 升级项目类型完成技术升级，将现有功能迁移到发布 1的新产品版本。完成后，在发布 2中使用快速、标准、敏捷或企业项目类型添加高级供应链功能。

如前所述，DA 服务可以根据客户参与情况单独执行或组合执行。无论它们如何执行，客户和交付团队选择正确的方法并制定必要的计划（如项目计划、资源计划、项目章程和/或沟通计划）至关重要。这些文件应成为升级交付提案的基础。当提案和工作说明书（SOW）获得批准时，就是开始执行解决方案升级的时候了。

升级交付

在上一节中，我们讨论了如何为升级设置解决方案交付流程。现在，我们关注升级本身的交付，使用 Sure Step 升级项目类型。

在上一节中，我们讨论了使用 Sure Step 进行升级的两种方法：技术升级和功能升级。这两种方法的共同点是 Sure Step 升级项目类型——对于技术升级，这提供了唯一发布的底层工作流程；对于功能升级，这构成了第一个发布的流程。Sure Step 升级项目类型的截图如下：

如截图所示，Sure Step升级项目类型遵循瀑布方法，包括以下五个阶段：分析、设计、开发、部署和运营。就像在标准、快速和企业项目类型中一样，这些阶段的活动被归类为九个跨阶段流程（有关跨阶段流程的回顾，请参阅第五章，使用 Sure Step 实施）。在接下来的部分中，我们将讨论升级项目类型每个阶段的一些重要活动。

分析和设计阶段

分析阶段建立在诊断阶段进行的发现工作之上，目标是最终确定需求（即“是什么”）和差距分析（即“如何做”），并启动数据升级，而设计阶段则用于在开始开发之前最终确定并获得解决方案设计的批准。

正如你在典型项目中预期的那样，升级合作从项目启动开始。这个活动的目的是确保团队成员理解升级合作的总体目标，以及他们在整个旅程中的角色和责任。例如，沟通计划是什么，谁负责让团队和利益相关者了解情况，以及将使用什么方式来实现这一点，这些都是在这个阶段需要明确的一些重要事项。

这之后是解决方案概述活动，为那些未参与评估阶段的团队成员介绍 Microsoft Dynamics 解决方案。这为最终确定需求和范围并进入设计活动奠定了基础。

接下来的两个活动，需求最终确定和差距分析最终确定，非常重要，但有时也会引起质疑。问题通常涉及为什么这些活动在诊断阶段和分析阶段都被提及。简单地说，答案是，根据发现工作的深度，这个阶段的工作可能主要涉及对范围的确认。但与之相关的一些非常重要的条件。

• 如果所有关键用户都参与了诊断活动

• 如果在诊断阶段考虑了所有需求

• 如果在执行决策加速方案时所有问题都得到了回答，问题都得到了解决

如果对任何问题的回答是否定的，那么在分析阶段执行这些活动并最终确定可交付成果是非常重要的。

对于需求最终确定活动，通常通过开展需求研讨会来最终确定功能需求文档（FRD）。FRD 应清楚地注明现有业务功能和需求，这些将在新版本中升级，以及作为升级的一部分将提供的新增需求（换句话说，新功能）。适配差距最终确定基于需求，使用适配差距工作表来确定这些需求将通过实施标准功能、配置或重新配置、工作流程设置或新/重写的自定义代码来交付。

再次强调，根据升级评估 DA 所进行的努力，功能需求文档（FRD）和最终适配差距分析可能很容易完成。但这两份文件都是分析阶段结束时必须由客户业务赞助商批准的关键文件。

数据升级准备是分析阶段的关键活动之一。该活动标志着数据迁移活动的开始，包括识别现有数据源，如现有的 Microsoft Dynamics 解决方案、任何 ISV 解决方案以及任何接口程序。还包括识别额外的数据源及其访问方式。需要考虑的其他事项包括源数据的状态（所需数据清洗的量、谁、如何、在哪里、何时进行数据清洗等），数据保留的任何法律要求，以及 Microsoft Dynamics 解决方案之外的数据存储策略。根据源数据的状态，团队还可能需要确定是否需要提取、转换和加载（ETL）工具来进行数据清洗和迁移工作。还应确定数据迁移的哪些部分将自动化，哪些部分（如果有的话）需要手动执行。

虽然分析阶段的目标是理解需求以确定升级项目的整体范围，但设计阶段用于定义技术升级将如何实施。目标包括规划执行升级的步骤，并确定升级自定义代码的冲突。它还包括积极规划潜在的升级后问题，并审查微软 Dynamics 与第三方解决方案之间现有的集成和接口，以确定它们是否需要升级以与微软 Dynamics 解决方案的新版本兼容。因此，关键的设计阶段活动包括数据升级清单以规划和执行升级，现有代码审查以分析和识别现有解决方案自定义产生的任何冲突，以及现有集成和接口审查以确定哪些现有的集成和接口需要升级。如果产品工具可用于支持这些活动，Sure Step 中会引用相应的工具链接。例如，微软 Dynamics AX 提供了一个升级清单实用程序，以顺序方式标记了必需和可选步骤，以在升级过程中提供指导和帮助，以及一个用于微软 Dynamics AX 的比较工具，以帮助确定和解决解决方案自定义的代码冲突。微软 Dynamics AX 具有独特的架构，代码可以保存到不同的层中（例如，USR 层用于客户用户，VAR 层用于合作伙伴）。比较工具还提供了在升级单个层时或同时在所有层中同时比较和检测代码冲突的能力。

设计阶段的完成意味着所有针对解决方案的客户需求都已分析完毕，并且功能性和/或技术设计已完成，以便启动升级开发工作。建议在每个阶段结束时进行阶段审查，这对于任何规模的项目都是推荐的，但对于更大规模的项目来说尤为重要。除了从客户那里获得对阶段完成的同意外，这还允许交付团队记录经验教训、未解决的问题和风险，以及针对这些问题的缓解措施。

开发、部署和运营阶段

开发阶段的目标是为升级设置应用程序，这可能包括 ISV 解决方案以补充标准的微软 Dynamics 产品。这个阶段还包括升级任何自定义、集成和接口以及相应的数据元素。部署阶段是升级交付努力的最终成果，导致客户过渡到新解决方案。运营阶段包括解决方案上线后的稳定性和过渡到支持。

升级项目类型的关键开发阶段活动包括应用程序和独立软件供应商（ISV）升级、定制升级、生产环境设置、集成和接口升级，以及数据验证和基准测试。与先前阶段一样，这些活动可能包括链接到产品工具或白皮书，例如微软 Dynamics CRM 的定制代码最佳实践。活动还提供模板，如测试脚本和环境规范文档，这些模板可以作为交付团队记录其工作的起点。

在升级 ISV 解决方案时，在尝试 ISV 升级之前完成微软 Dynamics 核心应用程序的升级非常重要，以确保已满足 ISV 解决方案的所有先决条件。请注意，作为分析和设计的一部分，如果需要从现有 ISV 解决方案中获取新的增强功能，ISV 解决方案可以被分解为多个技术升级和功能升级的阶段。

虽然开发阶段代表了升级合作中大量工作，但部署阶段是努力成果显现的地方。用户培训是这个阶段的关键活动，其中最终用户在上线前对新系统进行实际操作培训。根据组织规模的大小，培训可能以小组形式进行——通常，交付团队将培训关键用户或一组核心用户，然后他们将成为剩余最终用户的培训师。同时，还必须在此阶段纳入与更新技术相关的技术培训；例如，SQL 管理或报告服务的更新通常被忽视为“最好有”。这很重要，以确保客户充分利用新的技术改进。

在完成用户培训后，组织可以开始用户验收测试（UAT）。UAT 是客户组织对新解决方案的关键验证点——解决方案的用户接受表明客户已准备好上线新解决方案。Sure Step 提供了几个针对产品和行业的 UAT 脚本模板，交付团队应加以利用。这些详细的脚本引导用户执行给定流程或功能的步骤。在许多情况下，交付团队还利用这些脚本中的详细信息来开发前一项活动的培训指南。

在企业项目中，还应考虑将性能测试作为部署的一部分。

一旦获得此验收，上线前的最后一个活动是数据迁移到生产环境，其中将现有系统中的清洗数据迁移到新系统。

为了准备这一过程，生产环境设置必须与升级活动并行进行，从而能够从测试中获取信息以验证在架构设计中的需求收集和适配差距分析阶段所做出的初步假设。关键活动包括确认硬件、负载/压力测试、用户地理分布、集成需求、冗余和安全。

解决方案上线后，项目进入运营阶段。此阶段的关键活动包括过渡到支持解决方案，将解决方案从交付团队转移到支持团队，以及项目关闭，以最终完成和总结项目。

用例 - 非耐用品制造商的微软 Dynamics 升级

在本用例中，我们讨论了一家非耐用品制造商和分销商如何对其微软 Dynamics 解决方案进行多地点升级。

该制造商总部位于美国，并在全球拥有多个制造和分销机构。该组织的总部运行着较旧的微软 Dynamics AX 版本，即 Axapta 3.0，而其他通过收购的制造实体则运行着不同的遗留 ERP 系统。公司决定不仅将其系统整合以从其 IT 运营中获得规模经济，而且还要在整个组织的子公司中实现一致的业务流程。

该公司与一家金牌认证的微软合作伙伴合作，并经历了彻底的升级评估和解决方案愿景规划过程。通过这些流程的发现，公司意识到其总部正在运行一个高度定制的 Axapta 版本，这不仅会使升级过程变得复杂，而且也不是在多个实体中标准化的可持续解决方案。在此阶段，公司决定改变其整体解决方案和 IT 战略。他们首先审查了最新版本的微软 Dynamics AX，即微软 Dynamics AX 2009 中的标准功能，然后考虑在可行的情况下用标准功能替换修改，即使这意味着改变他们的一些业务流程。由合作伙伴顾问和客户的流程和技术专家共同执行的诊断练习导致确定，他们可以用微软 Dynamics AX 2009 中的标准功能替换大约 40%的定制功能。

该组织在以最小化每个运营特有的业务流程定制为核心目标的情况下，继续向前推进解决方案升级交付。由于公司的一些业务流程本质上是独特的，例如处理特定产品的政府法规，该组织意识到，尽管他们可以分享针对通用解决方案的最佳实践；但他们也需要考虑独特的站点需求。因此，联合客户和合作伙伴团队决定利用 Sure Step 方法的升级和实施项目类型，以跨站点开发和推广解决方案。

下图显示了联合团队采用的 Sure Step 方法。

该团队将 Sure Step 升级项目类型和企业管理项目类型的指导和建议结合起来，以开发在总部及其子公司之间推广一致解决方案的方法。团队从一次包括来自商业和 IT 职能的跨职能和跨组织分析师的规划会议开始。他们设计了一个核心解决方案，考虑了组织内的共同需求，这构成了核心构建的基础。核心构建最大限度地利用了标准功能，并在必要时进行了轻微的定制代码修改。团队还开发了针对总部和子公司的站点构建，考虑了该站点的特定需求。然后，将相应的构建合并到总部和子站点推广中。

联合团队能够在一年内完成这项合作。公司的运营副总裁将 Sure Step 方法归功于帮助项目保持正轨。他引用说：“通过使用 Sure Step 方法，我们对从一项任务过渡到下一项任务充满信心。一旦每个人都离开了启动会议，他们需要确切知道要处理什么。该方法帮助我们明确地阐述了我们将如何完成每一项任务。”公司的 IT 总监也表示同意，说：“这并不是我们第一次经历 ERP 实施。但，这无疑是我们的最佳实施，从上线运行的顺利程度来看。”

提供的联合解决方案为商业用户提供了流畅且一致的界面，为他们提供了重要的节省时间的能力。客户看到了员工生产力的提升以及缩短了报价到销售订单周期的收益。他们还能够建立适当的再订购点，这使他们有了更好的可见性，从而提高了库存周转率。公司的流程专家也对管理公司定价结构等领域的简化复杂性和减轻负担的过程表示热情。

从 IT 角度来看，该解决方案还在许可、基础设施和持续维护方面带来了显著的成本节约。通过将所有业务部门迁移到 Microsoft Dynamics AX 2009，该组织消除了其他遗留 ERP 系统的软件许可费用，从而实现了显著的年度节约。此外，公司将其服务器基础设施从 110 台物理服务器大幅减少到仅运行在五台物理服务器上的 60 台虚拟服务器。综合解决方案还使组织能够将所需的开发人员数量减少到原来的三分之一。

最后，Sure Step 方法论还使 IT 部门能够最小化升级成本，这在组织决定升级到 Microsoft Dynamics AX 2009 Service Pack 1 时表现得尤为明显。公司的 IT 总监对升级过程发表了以下评论：“以前，一个大型团队需要数月时间才能推出升级。但当我们升级到 Microsoft Dynamics AX 2009 Service Pack 1 时，我们只需要抽出我们的一些员工，他们仅用了三周时间就完成了升级。”

摘要

在本章中，我们学习了将现有 Microsoft Dynamics 升级到最新产品版本的方法，包括评估现有解决方案和执行升级。

在下一章中，我们将学习 Sure Step 中的项目和变更管理库。我们还将学习如何使用 Sure Step 中的 SharePoint 功能在线设置项目，例如升级项目，以便在解决方案交付团队中与其他人有效协作。

第八章。项目和组织变革管理

在最后四章中，我们涵盖了尽职调查和解决方案销售、解决方案交付、解决方案优化和解决方案升级。支撑这些领域的都是项目和变革管理学科，它们为成功的合作和满意的客户提供基础。这些学科将是本章的重点，另一个重要方面——Sure Step 如何使项目团队能够在非集中式协同工作时有效协作，也将被探讨。

在本章中，我们将涵盖以下内容：

• Sure Step 库中的项目管理学科，为项目经理提供基础和指导

• Sure Step 中强调解决员工观点和担忧的组织变革管理学科，这些观点和担忧可能源于用新系统替换现有系统

• Sure Step 中的“项目”功能，它简化了在本地驱动器、共享驱动器或 SharePoint 服务器上自动设置项目的操作

Sure Step 项目管理库

Sure Step 包括一个被称为项目管理库的内容部分。从项目管理基础的角度来看，这一部分应被视为项目经理的指南手册。它提供了对项目管理学科、项目管理流程和组织变革管理的内部视角。它提供了知识和最佳实践，旨在作为寻求持续提高项目管理技能的项目经理的持续灵感来源。您可以将其与项目管理协会（PMI）的《项目管理知识体系指南（PMBOK 指南）》进行比较，该指南为许多项目经理提供了项目管理的基石。

我们，作为项目经理，是否需要了解项目管理基础？这个问题可能看起来微不足道，但事实并非如此。项目管理是一个真正的职业；这不仅仅是你作为副业可以做的事情。多年来，专业项目经理的社区显著增长，这表明越来越多的专业人士确实理解了成功项目管理的真正本质和重要性。但尽管这种积极的演变，一些管理者似乎仍在忽视这一点，继续在忽视最佳实践的情况下管理他们的项目。对于那些将项目管理视为真正的职业并寻求提高技能、渴望学习新事物并找到将项目管理知识提升到更高水平灵感的项目经理来说，项目管理库是一个优秀的知识中心。

Sure Step 中的企业项目类型与项目管理库中讨论的不同学科的流程、活动、工具和模板完全一致。Sure Step 中的其他项目类型仅包括学科中描述的一部分；您如何利用项目管理方法与每个学科相结合，取决于您对特定项目质量保证的设想。

理解项目管理学科

你是否曾想过项目经理需要做什么？只需在 Sure Step 项目管理库中点击一下，就可以获得项目经理真正需要管理的鸟瞰图。项目管理学科涵盖了以下八个与项目经理职责相关的管理领域：

• 风险管理

• 范围管理

• 时间和成本管理

• 资源管理

• 沟通管理

• 质量管理

• 采购管理

• 整合管理

项目经理需要在始终独特且临时性的背景下管理所有这些领域。项目永远不可能相同，我们总是时间紧迫，尽管如此，我们仍必须管理所有这些学科。这是一项相当艰巨的任务！在一个以运营为导向的公司中，这些管理领域中的每一个都由专门的经理控制，而我们的项目经理需要结合他们的技能和知识，因此所有最佳实践和指导都将非常受欢迎。这正是 Sure Step 在项目管理库中提供项目管理学科所有基础的原因。

风险管理

风险管理学科教导我们关于初始和持续风险管理的 fundamentals。在这里，我们可以寻求关于如何处理风险识别、风险分析和如何建立有效的风险应对计划的指导。除了宝贵的指导外，我们还可以找到有助于我们在风险管理练习中变得更加高效的宝贵工具，例如以下内容：

• 项目风险登记册：此登记册允许我们列出、描述和分类我们已识别的风险，并根据我们的概率和影响估计生成风险评级。它还允许我们制定应急计划和响应措施。真正有趣的是，这个风险登记册模板还包括一个已填充已知风险的检查表标签，这些风险适用于 Dynamics 实施。

• 风险识别清单：这个已填充风险的清单可以作为项目经理风险评估的有效起点。风险识别清单是一个围绕环境、人员、程序和技术风险因素构建的问卷，并作为风险识别的有效工具。

范围管理

你熟悉范围蔓延吗？相信你一定熟悉！我们能否在我们的项目中预防范围蔓延？不，我们不能，但我们能更好地管理它。周到的范围管理可以提高我们实现客户满意度和接受实施解决方案的成功概率。范围管理学科提供了关于项目团队如何规划、定义、记录、验证、管理和控制项目范围的建议。这些指导在项目管理流程中得到了强调，如下面的图所示：

在本节中，我们将找到有关如何为我们的项目范围制作工作分解结构的具体信息，以及我们需要在良好的范围声明中包含哪些要素，等等。

除了提供对范围管理基础知识的有益见解外，Sure Step 还提供了工具和模板，帮助我们提高效率。其中之一是变更请求表单，有两种版本可供选择。

第一个变更请求表单将我们的注意力引向权衡矩阵。变更请求似乎主要只关注对客户成本的影响。然而，变更的影响远不止预算；它可能影响范围复杂性、技能和资源的部署以及进度。我们需要调查这些其他影响要素，并监控一系列变更可能对我们产生的影响。

第二个可用的模板比之前的模板提供了更详细的变更描述和权衡分析。因此，当我们面临具有重大影响且需要广泛深入文档的大规模变更时，我们可能会考虑使用这个模板。这个模板不仅教导我们调查变更的所有影响是一个好主意，而且还表明分析不进行变更的影响同样有价值。客户组织需要意识到，在实施过程中，愿景和想法可能会改变，导致变更和额外的需求。然而，增量范围的好处并不总是值得实施。有些请求可能不会对公司的效率或决策者的目标产生重大影响，但会对项目和其风险产生巨大影响。分析不实施这些变更的影响可以降低潜在风险和范围蔓延。

时间和成本管理

在这个学科领域，Sure Step 提供了指导和技巧来设置和管理初始和持续的时间及成本管理。任何参与项目的经理都将并且必须关注任务的时程和预算限制。从某种意义上说，即使他们没有对这个学科的基本原则和最佳实践的了解，他们也会管理它。这种活动无处不在，有些人甚至（不公正地）将项目管理缩小到时间和成本管理。所以，是的，这很重要。而且，我们越提高管理时间和成本的能力，我们就越有可能控制我们的时间和成本绩效。

需要学习的第一个教训是，初始的时间及成本管理必须与持续的时间及成本管理保持一致。初始和持续的时间及成本管理都需要一个共同的基础；这就是工作分解结构（WBS）的作用所在。WBS 定义了向客户提供所需价值所需的所有可交付成果和活动。它是我们项目估算和后续工作的基础，并允许在项目利益相关者之间建立一种共同的语言。如果我们在开始时对可交付成果的分解与持续项目中的后续分解有显著差异，我们可能会遇到问题，因为我们将难以将时间和成本绩效与我们所计划的绩效对齐。在 Sure Step 内容中进行简单的搜索指令可以揭示 WBS 的重要性。在 WBS 上进行搜索会产生超过 30 个 Sure Step 活动的结果，如下面的截图所示：

这个学科还将提供关于估算过程的信息。估算通常被认为是一个真正的挑战。在充满不确定性的时刻，我们需要估算成本和时间持续时间。如果我们能够在所有范围和风险都确定的时候进行估算，那将是极好的。但不幸的是，我们没有获得这种特权。因此，我们需要依赖我们的估算效率。一个好的估算对于咨询公司和客户组织都至关重要，使良好的估算过程成为不可或缺的。这个 Sure Step 学科向读者介绍了普遍接受的估算技术，例如使用咨询专家、类似项目的估算、参数估算以及自下而上和自上而下的估算。它还关注敏捷环境中估算的挑战，并提供了一些坚实的建议，例如使用三点分析和让客户参与估算过程。

我们还可以在这个学科中找到关于如何制定项目进度计划和如何准备项目跟踪和报告的指导。Sure Step 强调了结构化和良好记录的估算和跟踪技术的的重要性。我们不仅可以从这些技术中受益于单一项目，而且作为历史参考，它们对未来估算也将具有很高的价值。我们还可以从提供的挣值概念内容中获得灵感，这是一种将项目范围、成本和进度整合在一起的方法，通过项目跟踪产生早期预警信号。这种方法确定了根据我们已花费的金额我们所交付的内容，并计算在保持相同绩效的情况下，我们还需要多少时间和成本。

资源管理

资源管理学科探讨如何在项目背景下组织和管理人力资源、设备和物资资源。对于人力资源规划来说，区分角色和资源非常重要。项目角色是指完成项目工作所需的功能性职位类别或名称，例如，技术顾问、开发顾问或业务分析师。资源是指具体的小组或个人，他们完成项目工作。一个资源可能执行多个角色。角色和责任通常使用资源分配矩阵（RAM）来描述。RAM 的一种特定形式是RACI 矩阵。RACI 矩阵根据以下标准将责任分配给每个角色：

• 负责：此角色涉及努力完成任务，并交付完成工作所需的时间和技能。

• 负责：此角色包括对交付成果或任务正确且彻底完成的最终责任。负责角色下的人员将向负责角色汇报。

• 咨询：此角色涉及提供主动和咨询性的帮助。

• 知情：此角色涉及通过报告任务进度来保持最新状态。

Sure Step 使用 RACI 矩阵的扩展版本，提供了以下两个额外的角色：

• 验证：此角色涉及对定义的范围和质量标准执行检查

• 签字确认：此角色体现了审查、验证和接受的行为

以下截图是使用 RACI 矩阵映射责任与角色的一个示例：

此学科还涵盖了如何开发、管理和发布项目团队，并得到了如以下截图所示的角色和责任模板等有用工具和模板的支持：

沟通管理

在 Sure Step 中，一个重要的主题是沟通的重要性。正如我们在前面的章节中所述，Sure Step 的生命周期在设计时就非常注重互动，旨在促进客户与实施者资源之间的沟通。此外，项目管理库将整个学科领域都致力于项目沟通的艺术。这一学科讨论了如何进行团队会议，例如指导团队会议、项目管理会议和项目团队会议。该学科还向我们介绍了如何执行项目绩效报告以及如何管理我们的利益相关者。我们还可以从这一学科中学到如何制作一份好的项目章程以及如何进行有效的启动会议。这一学科得到了以下模板的支持：

• 项目状态报告

• 沟通计划

• 启动会议演示和会议议程

• 项目章程

它还指出，项目的成功或失败是由利益相关者决定的，而不是由项目经理决定的，因此，我们需要关注项目利益相关者的分析。

质量管理

质量管理学科解决的是如何确保、控制和提升质量以达到所需和平衡水平的问题。质量保证（QA）被视为满足项目需求和质量标准的总体规划。它通常被定义为在质量体系中实施的有计划、系统的活动，以确保产品或服务的质量要求得到满足。从某种意义上说，由 Sure Step 流程指导的实施可以被视为质量保证的一个要素。然而，这还远远不够，因为我们必须根据客户的具体质量期望和需求调整我们的计划方法。这意味着我们首先需要了解质量对我们客户意味着什么，然后才能进一步细化我们的主动质量方法。质量保证关乎我们为满足要求而实施的过程。质量保证不是关注可交付成果本身，而是关注我们计划如何交付它们。质量控制（QC）活动集中于可交付成果，并关注这些项目可交付成果的验收。现在假设你是客户项目经理，负责签署你实施项目的功能需求文档。在签署之前，你可以检查这份文档的每一页，以确保其正确性、准确性和与未来业务流程和需求的一致性。这将是质量控制的一个例子。你也可以验证这份文档是如何创建的过程。通过这样做，你将获取有关组织的工作坊、参加人员、关键用户如何验证这些信息、是否经过 Fit Gap 评估的双检查等信息。这是一个关注文档创建过程的质保例子。以下图表说明了 Sure Step 如何将质量保证和质量控制整合到项目管理过程中：

采购管理

这一学科讨论了如何管理从项目团队外部采购服务和可交付成果以满足定义的项目需求。分包可能涉及某些项目风险，但也提供了避免、减轻或转移风险的可能性。采购管理的重要输入和输出是考虑和定义约束、假设和边界。这一学科通过涵盖分包的计划、监控和关闭来解释如何做到这一点。

集成管理

集成管理本质上将所有学科整合在一起。这是因为它在整合从项目构思到关闭的各个方面时跨越了所有学科。集成是连接所有学科的粘合剂（范围、时间、成本、质量、资源、沟通、风险和采购）。

集成管理的第一部分是准备项目章程。这是一个关键文件，正式承认项目，赋予项目经理权限，提供高级要求，建立业务案例，并将项目与客户或组织目标联系起来。它还作为衡量成功的方式的定义。

一旦项目章程获得批准，项目经理和团队（以及适当的其他人员）必须采取项目章程中概述的指导方向，并确定规划细节：项目将如何被管理和控制。几乎每个学科领域都会被分析，以确定其定义、规划、管理和控制的方式，然后汇总到项目管理计划中。此计划包括项目的策略和方法，以及管理和控制项目的措施和流程，以确保满足项目章程的目标和成功标准。

在达成项目管理计划协议后，项目工作开始，并从此处开始，必须进行监控和控制。项目经理随后必须将所有执行过程整合成一个协调一致的努力，以实现项目管理计划并产生项目成果。

监控和控制项目工作是一个从项目启动到项目关闭的集成控制功能。项目经理需要监控过程进展情况，通常并不实际执行工作。监控和控制项目工作的集成功能包括分析跟踪风险、执行质量检查、接收变更以及采取纠正措施等活动。

项目范围可能已经完成，但质量是否可接受？进度可能已经满足，但我们是否在预算范围内？项目经理必须平衡不同学科领域的需求，以控制项目。

监控和控制项目工作的结果可能需要变更请求和对项目管理计划以及其他项目文件的更新。这些变更在接受或拒绝后，在执行集成变更控制（PICC）过程中进行处理。可能需要请求影响项目任何部分的变更，集成变更控制过程确定了所有学科领域的影响。

最后一个流程是关闭项目阶段。此流程在每个阶段结束时以及项目结束时被调用。如果项目在完成前被终止，此流程将确保所有文档被收集和归档。此流程最终确定所有项目管理学科的所有活动，并正式完成项目、阶段或合同义务。

组织变革管理

组织变革管理（OCM）是一门学科，它提供了一种结构化的方法，将个人、团队和组织从当前状态过渡到期望的未来状态，同时最小化阻力并最大化采用。

OCM 是业务解决方案交付合作成功的关键，有时也容易被忽视。正如本书多次讨论的那样，业务解决方案包括组织的多个流程和工作流程，对这些系统的任何更改都可能影响许多个人的日常运营和行为。在较小的组织中，由于 CEO 或总裁通常是此类大型项目的推动力，公司往往可以通过相当粗暴的力量或来自顶层的压力来“接受或否则”。但随着组织的规模扩大，以及项目范围和影响扩大，项目团队将 OCM 视为交付活动的组成部分就变得至关重要。这将确保及时消除采用障碍，并且员工支持是解决方案部署方法的一个组成部分。

在他们题为《变革管理对商业影响》的文章中，作者们汇集了多项研究，以了解组织变革管理（OCM）对项目的影响和重要性。作者们解释了 OCM 的目的：

“...以减轻项目风险，包括成本、进度和性能。”

OCM 通过以下方式实现这一点：

“...通过有效地开发、部署和调整公司资产以实现特定项目的更快经济价值。”

文章引用了麦肯锡公司的一项研究，该研究考察了许多项目变量，特别是 OCM 项目对项目投资回报率（ROI）的影响。结果令人震惊！包括良好 OCM 项目的项目产生了 143%的 ROI，这意味着公司从每花费一美元的项目中获得了 43 美分的收益。另一方面，没有或 OCM 项目较差的项目产生了 35%的 ROI，这意味着公司每花费一美元就损失了 65 美分。

作者们还突出了一篇题为《CRM 项目成功六大障碍》的研究，列举了以下 CRM 项目失败的原因：

• 缺乏指导

• 集成难题

• 缺乏长期战略

• 脏数据

• 缺乏员工支持

• 没有责任

作者们还描述了由公认的变化管理研究领导者 ProSci 进行的一项研究。为了有效地管理项目在组织中产生的变化，组织需要以下条件：

• 有效的强大高管支持

• 获得一线经理和员工的支持

• 优秀的团队

• 持续和有针对性的沟通

• 计划和组织的方法

作为一种流程，OCM 的目标是赋予员工接受和拥抱当前商业环境变化的权力。Employee's Survival Guide to Change的作者Jeff Hiatt谈论了谈论发生在他人身上的变化是多么容易和有趣，但当变化发生在他们自己的环境中时，个人会变得多么担忧和不舒服。Hiatt 将变革管理领域描述如下：

两个思想领域的融合……一个工程师改善业务绩效的方法和一个心理学家管理变革中的人性方面的方法。

在由The Anton Press出版的名为Integrating People with Process and Technology的书中，Jon Anton和其他人探讨了组织的科技获取并不一定转化为其员工的使用。以下是从作者那里得出的一个引人注目的观察：

关于技术实施的真相是，尽管技术实现了供应商承诺的功能，但如果变革管理没有被纳入整体技术项目预算的一部分，就会引发 ROI 问题。在技术实施包括变革管理的情况下，实施过程成为一种令人兴奋的经历，它提高了公司的效率和效果。

为了成功部署解决方案，作者的建议是公司应该

...以这种方式整合他们的员工、流程和技术...使变化得到接受并被看作是好的。

他们将“好的”变革定义为技术：

...使员工更容易完成工作并提高效率，使员工为服务客户更具有操作上的有效性，并使公司的产品和服务易于访问。

这些讨论强调了在项目管理中管理变革管理方程中的人性方面的重要性。最终，是系统用户最终定义了解决方案的成功或失败。如果没有用户的认可，如果用户看不到使用它的必要性，那么解决方案再好也没有用。因此，在实施过程中让用户紧密参与，听取并考虑任何担忧，这一点非常重要。公司进行变革研讨会来传达对即将到来的变革持开放态度的重要性也并不少见。

关于人和变革主题的更受欢迎的书籍之一是 Spencer Johnson 的《谁动了我的奶酪？》。这本书以两个老鼠和两个小人物为寓言，讲述了一个角色如何能够穿越迷宫找到奶酪，而另一个角色则因为不愿改变而挣扎。这个故事可以与公司环境联系起来，其中“迷宫”是员工工作的组织，而“奶酪”则是组织试图实现的目标。这个启发性的故事帮助许多员工应对不可避免的变化，并已被用作变革研讨会指南。

到目前为止，我们已经讨论了 OCM 的一般概念。在下一节中，我们将探讨 Sure Step 如何在实施过程中启用并支持组织变革的概念。

在 Sure Step 中的组织变革管理

在 Sure Step 中，组织变革管理被描述为一个综合的沟通、培训、赞助和组织对齐的方法，以帮助员工有效地过渡到新的工作方式。Sure Step 方法描绘了以下四个关键组织变革管理领域的成功策略——回顾上一节可以看出，这些策略与变革管理研究分析师的方法非常一致。

• 高管和利益相关者参与：此策略需要业务发起人的所有权和责任，通过要求组织的业务单元领导者创造一个环境，使 ERP/CRM 解决方案带来的流程变化被接受并拥有。该策略包括开放沟通、设定适当的期望、及时协助解决关键项目问题，并提供适当的强化水平以确保项目成功。

• 组织对齐和动员：为了使此策略成功，交付团队需要分析劳动力影响，并以当前业务实践为基准，过渡到未来的流程。需要积极参与适当的业务利益相关者，以了解解决方案的能力，并评估其各自领域的解决方案有效性。

• 沟通：这个关键成功领域侧重于解决方案设计、实施时间表和进度、利益相关者所需参与的沟通，以及接受新的工作方法。沟通包括在适当的时间以适当的形式通过适当的方式传递正确的信息，以及通过定期调查和迭代经验教训讨论的反馈和响应策略。

• 培训：此策略侧重于确保最终用户对新业务流程感到舒适，拥有在设计的流程中工作的所需技能集，并且已经对应用程序的使用进行了充分培训。该策略涵盖了初始和持续的用户培训，以确保新流程和工具的成功采用。

OCM 的 Sure Step 指引沿着五个支柱进行对齐。以下各节将描述这些支柱。OCM 领域内提供的指导被分解为活动，如下面的截图所示：

还应指出，这些活动反过来又与 Sure Step 项目类型集成，这意味着它们在相应的项目工作流程中被作为规定的步骤进行说明。

定义 OCM 策略

OCM 策略定义了项目或程序中各种变更管理组件的整体愿景、目标和活动，以确保解决方案的成功采用。OCM 策略的子组件包括以下内容：

• 组织风险和准备度评估：这评估了组织进行此类规模项目的准备情况，了解可能存在的风险，并定义缓解策略以克服项目成功的障碍。

• 组织变更管理策略：这定义了特定变更管理活动、资源以及相互依赖关系的性质和顺序，以促进变更过程

• 沟通策略：这定义了信息传递和沟通的内容、方法和时间，以使管理层、利益相关者和业务部门保持一致

• 培训策略：这定义了培训受众和将新流程和解决方案同化到用户群体中使用的策略

• 数据分类：这定义了所需的数据实体以及任何可选的数据元素

• 主数据管理策略：这定义了在解决方案投入生产后管理和维护主数据的整体策略和流程

如前所述，Sure Step 中 OCM 领域部分的活动也实施在 Sure Step 项目类型中，特别是企业项目类型。例如，进行组织风险和准备度评估是企业项目类型程序管理跨阶段的一个活动。项目活动还包括优秀的工具和模板，例如组织风险准备度分析工具。

对齐和动员领导力

定义了策略组件后，为该子领域的商业高管和赞助者创建了整体变更管理行动计划，包括以下活动：

• 领导行动计划：通过定义所有级别的沟通，从高管和中级经理到受新解决方案影响最大的人，推动变革策略。计划应包括定期检查点，以审计绩效，并在必要时进行必要的课程修正。

• 领导沟通：这确保项目业务高管和赞助人在项目期间定期与利益相关者沟通。

对于领导沟通活动，Sure Step 包括一个现成的 Outlook 电子邮件模板，可以根据组织的消息风格进行调整。

吸引利益相关者

本 OCM 子领域的目的是确保通过以下活动在整个项目生命周期中识别项目利益相关者，并积极参与：

• 利益相关者沟通：这包括为领导层和项目团队制定适当的沟通方案，获取反馈，并在必要时创建行动计划来解决提出的问题

• 解决方案故事板演示：这涉及在设计完成之前向利益相关者展示解决方案故事板，以获得对解决方案的积极反馈和承诺

• 解决方案原型演示：这涉及在解决方案开发期间向利益相关者展示配置好的解决方案，以获得对解决方案可用性的积极反馈。

与之前的子领域类似，这些活动与 Sure Step 项目类型活动保持一致，包括用于沟通、创建故事板等的模板。

调整组织

本 OCM 子领域的关键目标是确保利益相关者充分准备采用新解决方案。这是通过实施对未来流程的预期解决方案，定义角色和职责，以及为组织准备和执行培训来实现的。

• 未来状态业务流程模型：基于新解决方案开发未来状态业务流程，这反过来又为培训和对利益相关者采用新解决方案进行对齐提供了基线。

• 工作影响分析：这是确保利益相关者拥有理解项目倡议对其工作表现、工作描述和职业道路影响所需信息的关键步骤

• 角色和职责：这基于工作影响分析，以定义由新解决方案产生的新角色和修改后的职责

• 培训师培训：这确保组织培训师熟悉新解决方案，并准备好培训最终用户。

• 主数据管理流程：这确保主数据管理流程由数据所有者实施，并建立适当的数据所有权和问责制

如前几章所述，Sure Step 提供了一个庞大的流程模型库，可以用来开发未来的业务流程流程。还包括其他模板，例如工作影响分析电子表格，这些模板也包含在相关项目类型活动中。

使组织具备能力

这个子领域确保新解决方案的部署，用户的培训，以及适当的支持流程的运营。

• 终端用户培训：这确保了为终端用户提供充足且持续的培训，以促进用户对新解决方案的采用

• 过渡解决方案支持：参与适当的支持组织，并将解决方案移交给将提供持续支持的团队。

• 主数据管理流程移交：这确保了数据管理流程被移交给数据所有者，以便在新解决方案中保持数据完整性和准确性

数据管理有时对用户来说可能令人困惑，为什么它属于组织变革管理。在 ERP/CRM 解决方案部署中，顾问经常使用的一个老话是，“垃圾进，垃圾出。”虽然听起来很严厉，但即使新解决方案很好，如果提供的数据仍然很差，它只会导致解决方案用户更快地获得错误信息。因此，管理数据元素是一个重要的变革组件，可能会影响利益相关者。

在上述章节中，我们介绍了 OCM 的概念，并从 Sure Step 的角度探讨了 OCM。正如我们所学的，OCM 是一个关键的学科，在解决方案交付过程中不应被忽视。鉴于公司在解决方案上的投资，包括 OCM 专家来指导组织成功采用新解决方案应该是理所当然的。

与其他项目方法论对齐

项目经理有多种项目方法论可供选择，以确保业务软件的成功交付。在本章早期，我们探讨了 Sure Step 与项目管理协会（PMI）的项目管理库之间的联系。在世界的许多地区和许多行业，其他项目实施方法论被视为标准。例如包括微软解决方案框架或PRINCE2。

PRINCE2 和 Sure Step

PRINCE2 是一个框架，最初在 20 世纪 80 年代末为英国政府创建，用于管理其 IT 实施。如今，它不仅在公共部门组织中高度流行，而且在私营部门中也越来越有影响力，尤其是在澳大利亚和英国。这种偏好的原因部分在于 PRINCE2 的关键流程属性以及框架提供的控制层的感知好处。PRINCE2 是以流程驱动的，同时具有七个指导原则和七个主题，在每个项目流程阶段提供控制。

原则如下：

• 持续的业务合理性

• 从经验中学习

• 明确的角色和责任

• 分阶段管理

• 异常管理

• 专注于产品

• 量身定制以满足特定项目环境的需求

这些原则在 Sure Step 中有所体现。

七大主题如下，所有这些都与 Sure Step PM 库有间接相似之处：

• 商业案例

• 组织

• 质量

• 计划

• 风险

• 变更

• 进度

由于每个实施都可以根据许多因素（无论是地理、行业部门还是客户的管理团队）指定其自己的方法论要求，因此了解其他方法论或框架可以与 Sure Step 互补，确保不会忽略微软研发团队共享的最佳实践是非常重要的。

Sure Step 的项目功能

在第四章至第七章中，我们介绍了五种瀑布和敏捷 Sure Step 项目类型，包括为项目活动提供的模板。这些模板包括我们在上述部分讨论的一些项目和变更管理模板。在本节中，我们现在将注意力转向使用适当的交叉部分模板启动项目，这些模板根据用户的选择预先填充。

Sure Step 提供了一个名为项目的功能，用于轻松设置项目模板和与项目团队成员的高效协作。此功能可在 Sure Step 应用程序的第二标签下找到，或在 Sure Step Online 的左下角，标题为项目，如下一个截图所示：

作为参考，我们之前提到的指南、模板和工具位于 Sure Step 应用程序的第一个标签下，并标记为Sure Step 方法论，如前一个 Sure Step 应用程序截图所示。

创建和管理项目的流程由所使用的 Sure Step 应用程序决定，如果使用 Sure Step 的桌面版或在线版，则会有所不同，具体细节将在以下部分中详细说明。

Sure Step 项目创建向导

Sure Step 项目功能可以执行，以在本地驱动器（或共享驱动器）或 SharePoint 服务器上启动项目。启动这些项目的流程将在以下部分中描述。

为了创建项目，Sure Step 提供了一个直观的Microsoft Dynamics Sure Step 项目创建向导，该向导引导用户完成设置。以下截图显示了向导的一个屏幕：

如果项目是为特定行业（如流程或公共部门）的客户，或者如果解决方案是跨行业解决方案（如 xRM），则解决方案下拉菜单提供这些选择。选择这些选项之一后，将关联到创建的项目中的相应模板。另一方面，如果客户项目不是这些行业或跨行业解决方案之一，将提供一个通用解决方案值，该值附加与标准产品相关的模板。

产品下拉菜单是您选择项目基于的适当 Microsoft Dynamics 产品的位置。向导根据所选解决方案缩小选择范围——这意味着，例如，如果您选择公共部门，则只提供 CRM 作为产品值，因为 Sure Step 目前只为公共部门提供 CRM 解决方案指导。在未来的某个时刻，当为特定行业提供更多产品覆盖时，解决方案过滤器将提供相应的产品值。

参与类型下拉菜单提供了 Sure Step 支持的以下三种参与类型的多个选择。

• 如果参与活动与预售/尽职调查相关，用户将选择诊断阶段产品，这是我们之前章节中描述的决策加速产品。对于这个选择，向导将允许用户选择多个决策加速产品，以支持需要服务提供商在尽职调查过程中结合多个产品的客户场景。

• 如果参与活动是为了解决方案交付，用户将选择实施。在下一个选择中，用户被要求选择四种瀑布项目类型之一，或敏捷项目类型，作为实施的基础。

• 如果参与活动是为了优化或审查，用户将选择优化产品。就像诊断阶段产品选项一样，优化产品选择允许用户选择多个优化或审查产品。

向导还提供了选择项目是否应在本地驱动器或 SharePoint 服务器上创建的选项。

在本地驱动器上创建项目

在本地驱动器上创建项目的用例通常限于实施团队资源有限的小型项目。在这些情况下，项目通常在顾问的个人计算机上设置并驻留，并且交付成果在适当的时候与客户共享。然而，Sure Step 确实允许用户将默认驱动器从C:\更改为共享驱动器，以便更多资源可以共同工作在同一项目上。Sure Step 还提供了其他协作选项，例如导出和导入这些项目。

当查看项目时，重要的是要注意，当用户点击特定的阶段，例如本例中的分析阶段时，视图将变为更详细的一个，显示文档描述、此成果的所有者角色以及参与咨询角色和客户角色，提供更以角色为中心的体验。

在 SharePoint 服务器上创建项目

Projects 功能更常见的用例是在 SharePoint 服务器上启动项目。在项目设置流程结束时，项目创建向导为用户提供选择基于 SharePoint 的项目的选项。指定 SharePoint 站点的相应 URL 后，Sure Step 将运行检查以确保用户有创建站点的适当权限，检查结果为正时，将自动将相应的 Sure Step 模板填充到站点。以下截图显示了此过程中的步骤：

以下截图显示了结果 SharePoint 站点的示例。此示例是使用企业项目类型为 CRM 项目创建的 SharePoint 站点。

Sure Step Online 项目创建向导

当使用 Sure Step Online 的项目创建向导时，创建项目的流程与上述描述不同。Sure Step Online 只能创建 SharePoint 文档库站点的项目。为了将选定的 SharePoint 站点与 Sure Step 的内容存储链接起来，必须完成以下一次性设置：

1. 通过在 Sure Step Online 中导航到项目标签（左下角）并按照以下截图中的链接下载 Microsoft Dynamics Sure Step Online 项目向导（SureStepProjectWizard.xap）来完成此操作：

2. 下载后，导航到 SharePoint 站点，并选择将.xap文件作为文档添加，如下截图所示：

3. 添加后，SureStepProjectWizard.xap应作为 Silverlight 网页部件添加到库中的新页面，从而使向导显示如下：

   现已安装和配置，Sure Step Online 项目向导将以与 Sure Step 桌面版本类似的方式工作。完成项目信息（如前述截图所示）后，选择下一步将打开向导中的下一个窗口。在这里，必须选择项目类型。选项包括企业、标准、快速、升级和敏捷，如下截图所示：

   

4. 向导的第三步将确定项目创建的 SharePoint 站点位置（如下截图所示）。为了继续操作，用户必须在相关的 SharePoint 站点上创建权限。

5. 下一步将要求用户选择项目将驻留的站点名称。向导将创建此步骤，因此无需提前创建页面。最后一步确认项目需求，然后启动项目创建。

使用 Sure Step 在线版相对于桌面版 Sure Step 的一个主要优势是值得注意的。每次使用在线向导创建项目时，都会从 Microsoft 的内容数据存储中下载最新更新的内容，从而始终确保在项目中使用的是最新内容。这是因为在线环境相对于桌面版本的简单性。Microsoft 能够以最少的延迟在线部署新内容。部署到桌面版本需要更多时间，需要分配给正式发布计划的内容构建。

一旦创建项目，向导将显示一个链接到新项目站点。打开链接将用户导航到新项目，其中包含所有相关的 Sure Step 文档以及菜单栏上项目阶段的快捷方式，如下截图所示：

使用项目功能自定义 Sure Step 模板

在可下载的 Sure Step 版本中，Sure Step 项目功能还为用户提供了一些其他有用的选项。更改标志功能是一个很好的例子。

Sure Step 模板预先填充了 Sure Step 标志，该标志也受元数据控制。元数据允许用户通过在项目属性下使用更改标志功能，快速地在所有文档中统一更改标志。更改标志功能支持多种用例，例如，对于特定项目将 Sure Step 标志替换为客户标志，或者将标志更改为服务提供商的标志以创建他们自己组织的定制模板集。

最后一点对于服务提供商尤其关键。项目功能允许保存、导入和克隆现有项目，从而通过行业、参与规模、参与方法等方式促进项目文件夹的创建。因此，服务提供商可以决定创建一系列项目文档，例如，他们的咨询团队可以作为所有汽车制造客户起点使用的 Microsoft Dynamics AX 标准项目类型模板。或者他们可以为使用快速项目类型的 Microsoft Dynamics SL 的离线部署创建另一个文件夹。或者，他们可能为更喜欢敏捷方法的 CRM 客户创建另一个项目文件夹。每个模板都可以预先填充组织的标志和从以往合作中汲取的关键经验教训。

Sure Step 将其称为 60-20-20 规则，这意味着 Sure Step 提供了模板的起始 60%，服务提供商随后根据其在特定领域的专业知识进行定制，并增加其 20%。在最后的 20% 中，咨询团队将模板转化为针对客户环境的特定可交付成果。

摘要

在本章中，我们介绍了 Sure Step 项目管理库，其中包括项目管理和组织变革管理学科。我们还讨论了 Sure Step 中的项目功能，该功能允许轻松设置项目模板，并使团队在离线和 SharePoint 环境中与其他团队成员高效协作。

在下一章中，我们将从服务提供商和独立软件供应商的角度讨论 Sure Step 方法的采用。我们将讨论 Sure Step 采用路线图以及它如何帮助组织采用该方法作为自己的方法。

第九章。采用 Sure Step 的实用指南

在前几章中，我们讨论了 Sure Step 的各种特性，包括尽职调查和解决方案销售启用、高质量解决方案实施和升级的方法、审查和优化的选项，以及项目和变更管理学科。现在，我们将把我们的重点转移到另一个重要领域——组织如何采用 Sure Step 方法论，并使用它来持续地向客户交付解决方案。

在本章中，我们将涵盖以下内容：

• 采用 Sure Step 的策略开发和执行，包括在组织内部管理变革

• 如何为您的组织制定 Sure Step 采用计划

• 来自真实 Sure Step 采用计划的快速胜利

• 你如何从 Sure Step 在线中受益

• 独立软件供应商（ISVs）如何从采用 Sure Step 中受益

不要把你的大脑停在门外

微软 Dynamics 合作伙伴和客户都可以通过 PartnerSource 和 CustomerSource 轻松访问 Sure Step 应用程序，分别。从这些微软门户中，Sure Step 可以轻松下载并安装，几分钟内即可释放所有 Sure Step 内容和工具。项目经理和顾问还可以通过微软官方课程资料（MOC）、微软在线学习和由微软认证学习解决方案合作伙伴（CPLS）提供的讲师指导培训（ILT）课程熟悉并了解 Sure Step。这意味着，只需投入适量的时间，组织就可以获得 Sure Step 方法论工具、内容和知识。那么，将您的组织置于 Sure Step 轨道上是否像吃馅饼一样简单？正如我们许多人所知，这离事实相去甚远。任何希望调整其流程以采用新的实施方法组织的组织都注定要面临一系列挑战。为了成功，他们需要有效的策略，并且必须正确执行，同时管理组织变革，而这并不是小事！

执行策略

	"计划只有当它们立即转化为辛勤工作时才是好的意图。"
	--彼得·德鲁克

战略执行不同于战略制定，但它们需要相辅相成。战略执行可以定义为“将你的策略转化为成功所需的所有行动”。一个伟大的策略不能弥补糟糕的执行，反之亦然。《战略执行英雄》一书，作者Jeroen De Flander，《绩效工厂》，在比较战略执行与战略制定时列出了四个重要的区别。战略执行涉及组织中的每个人，而战略制定主要保留给选定的执行团队。战略执行所需的时间比战略制定长得多——这是一场马拉松而不是短跑。执行需要短期和长期思考，因为短期胜利是使执行成功所必需的。战略执行还需要与战略制定不同的技能集。成功的策略制定者是分析思维和机会识别的冠军，而执行者则是沟通和辅导技能的大师。

合作伙伴组织的关键关注领域之一是提高他们在 Microsoft Dynamics 实施中的质量、满意度和盈利水平。在制定战略时，我们可能会考虑定义我们的质量目标，并制定使用 Microsoft Dynamics Sure Step 作为工具来实现这些质量卓越目标的计划。但仅仅拥有战略计划本身并不能保证成功。一个策略，即使是伟大的策略，也不会自行实施！为了将 Sure Step 策略转化为执行，组织需要制定一个公司范围内的计划，利用管理辅导支持来详细说明实现快速胜利所需的逐步步骤，从而实现更大规模的转型。与成功获取具有成功实施知识资源的资源相比，这一过程的执行是完全不同的游戏。

管理变革

在第四章《管理项目》中，我们已经介绍了变革作为适应 Sure Step 的挑战。这并不令人惊讶，因为我们大多数人必须熟悉改变我们个人和职业生活中那些陈旧习惯的巨大困难。现在，花一些时间思考一下你在职业生涯中的某些变革倡议。它们是否完全成功，达到了你计划的程度？如果没有，试着列出它们失败的三种原因。它们是否与以下图表中的那些相似？

这个插图仅突出了一些反思变革项目失败原因的常见痛点。大多数公司确实有失败的变革倡议记录。这些失败中的大多数是由典型的变革管理挑战引起的。如果我们想要成功适应 Sure Step，我们需要有一个强大的执行计划来克服这些变革管理挑战。而且，意识是这一方向的第一步。人们是习惯的动物，在做已知的事情时感到最安全。

为什么变革倡议会失败

在第三章中，Solution Envisioning with Sure Step，我们已经提到了书籍Our Iceberg Is Melting first edition，John Kotter，St. Martin's Press。他描述了变革倡议失败的十个原因。让我们在以下章节中更详细地看看这些原因。

低估了对期望变革的清晰愿景的需求

我们为什么需要变革？结果会是什么，它与我们的目标和公司战略有何关系？我们会卖出更多并变得更盈利吗？实施这一变革的令人信服的理由是什么？它的商业理由是什么？我们需要确保我们的变革倡议与目标承诺和公司目标相连接，并且在我们期望的变革背后有一个强大的愿景。就像在足球中，除非我们知道球门在哪里，否则我们不会走得太远。所以，首先要做的是理解我们想要实现什么！

没有清晰地传达愿景

在不知道为什么要改变做事方式的情况下，你是否感到舒适？当然你不会，这适用于大多数人。当我们向员工引入变革时，他们需要知道组织真正想要和需要变革的原因。我们想要解决哪些问题？这将提高我们的绩效和质量水平吗？解释这个倡议如何与战略计划相符。这将帮助我们实现目标吗？如何？引入组织变革的领导必须向将执行变革的人推销愿景。他们需要通过良好的沟通和信息使整个公司相信这个愿景是可信和可实现的。缺乏这种必要的沟通是战略与执行之间的脱节。

没有建立一个实质性的联盟

我们的变革倡议需要得到我们组织内一个庞大群体的支持，以克服传统和惰性。他们需要对引入的变革充满信心、受到鼓舞和兴奋。因此，他们将向团队传播新的程序，并帮助他人过渡到新的工作方式。他们还将与那些不相信和抵制变革的人进行辩论，并克服他们的批评。这个支持者的联盟将作为你在更有效和以质量为导向的公司运动中的竞选伙伴。这个联盟需要强大，包括公司不同部门和学科中权威的执行和非执行角色的混合。我们必须在强制使用任何新工具或程序之前，投入时间来创建这样一个信仰者的群体。我们需要在我们的组织中识别推动者和潜在的推动者。他们两者都对变革持有积极的普遍态度；他们不害怕变革，比其他人感到更少的不安全。真正的推动者会立即欢迎特定的变革，并以光速寻求新工作方式的优势。潜在的推动者对变革并不持负面态度，但他们不会很快找到优势。他们只需要额外的鼓励来发现变革的真实价值。我们需要在变革之旅中，让这两种类型的推动者都参与进来。

允许对愿景的阻碍

人们不喜欢改变他们的做事方式，新的程序使他们感到不安全。这对大多数人来说都是如此，即使是那些推动变革的人也是如此。然而，有些人比其他人更害怕变革，我们这里说的是一般意义上的变革。这可能导致对任何变革的抵制。我们需要了解我们的对手，并从第一天开始管理他们的抵制。真正的对手通常并不难识别。他们对任何变革都持有强烈的负面态度，而且还有强烈的个人原因反对这种特定的变革。

这些对手将试图否认变革，并引发愤怒和抵制。我们需要为此做好准备，并通过探索接受来管理他们。以下图表描绘了这一现象的各个方面：

我们还需要预见隐藏的对手或机会主义者。识别他们将会更具挑战性。尽管他们表面上似乎支持变革，但他们对于变革持有负面的普遍态度。他们在推动者和反对者之间保持平衡，这意味着我们的挑战是给他们提供足够的信息和鼓励，让他们理解变革的好处。

我们需要关闭反对者领导的对改进计划的任何反抗，并且我们需要确保反对者的人数不超过支持变革的联盟。

没有产生与改进绩效相关的紧迫感

即使整个团队有最好的意图，变革项目也会因为缺乏紧迫感而受到威胁。即使我们支持新的流程和工具，实际操作它们通常会被推迟。有一些普遍的借口，比如“是的，我们支持它，因为它很好，但现在我们没有时间，因为还有其他更高优先级的事情。”我们以前听过这些，但很快，“总有一天”就会变成“没有那一天”，我们的变革项目就会结束。这就是为什么我们需要将我们的变革目标与公认的紧迫感联系起来。

人们需要理解为什么我们需要快速变革以及整个组织将如何从中受益。没有时间可以浪费，因为这至关重要；我们需要立即行动。约翰·科特表示，公司管理层的 75％必须确信当前的商业实践是完全不可接受的。如果没有对变革的紧迫感，变革过程就会受到威胁。

没有制定短期胜利的计划

探索变革的第一结果和好处是至关重要的。这将激励人们适应任何新引入的程序或工具，并且体验这些好处将鼓励他们继续我们的改进和变革追求。我们让组织等待第一结果和胜利的时间越长，我们失去的支持和热情就越多，我们的对手获得的弹药就越多。看着锅永远不会沸腾。

没有领导并指导商业行为的变革

如前所述，变革并不容易发生，策略的执行也不会自行实施。在每一个成功的变革项目中，我们都会找到个人。我们的员工需要意识到变革，因此，他们需要被指导和引导进入这个变革。实际上，这是管理和领导的责任。我们的挑战是在我们的组织中创造对变革的认识并建立对变革的责任感。实际上，“照我说的做”的方法不太可能在我们转型的努力中带来即时成功。我们需要真正愿意承担变革和绩效责任的人，使指导成为更好的选择。本质上，这就是通过变革进行领导——将人力与新的愿景对齐并激励他们在障碍中实现它。通过指导，我们可以让我们的员工参与到变革中，而不是将变革强加给他们。人们会做他们认为和感觉的事情，而不是被强加的事情。

管理者无法在日常执行中及之上进行操作

改变日常执行实践是管理层的责任。管理者需要与新的愿景的价值观和信念相联系，并在他们部门的日常实践中引入新的行为。这话说起来容易，但尽管管理者负责这项工作，但一大群管理者发现自己很难超越日常执行。这把我们引到了下一个部分——言行不一。

言行不一

“说一套做一套”显然是无效的，但却是非常常见的管理方法。管理者可能已经与新的愿景建立了联系，并抓住每一个机会表达他们对它的支持，但在实践中，他们仍然在部署那些陈旧的习惯和商业实践。如果管理者不支持新行为的实践和执行，那么他们的员工很可能也不会支持。新的程序显然不在他们的心中，任何人员组织都会立即感觉到这一点。

未将变革锚定在企业文化中

大多数在不止一家公司工作过的人一定都经历过，有一种叫做公司或企业文化的东西——某种存在于公司氛围中的东西，使得这个组织与众不同。我们也一定经历过，这种独特的文化对我们在这个公司中的行为、表现、互动以及感受产生了影响。关于什么是企业文化，有许多定义，它们都指向组织内部人们和群体所共享的价值观和规范。由于这种文化影响着我们的行为和与同事、供应商、客户互动的方式，它代表了在该公司内所能达到的极限。这就是为什么我们的变革项目，我们对更多质量的追求，需要坚持公司的文化。我们必须加强新的规范和价值观，并向组织展示它们是文化的重要组成部分。新员工应立即融入这些新价值观，为此，激励和晋升可能成为有价值的工具。

制定你的 Sure Step 采用计划

之前关于战略执行和变革管理的章节清楚地表明，采用任何实施方法都是一个重要但复杂且耗时的任务，它影响着整个合作伙伴组织。要成功采用，你需要一个指导性的采用计划，这个计划被构建和设想得如此之好，以至于它将帮助你克服典型的变革和战略执行陷阱。你必须包括这些基本要素：

• 确认商业需求和愿景

• 高管沟通

• 评估你当前的商业实践

• 识别和沟通风险与回报

• 目标设定和辅导模型

在战略执行以及变革管理理论中，强调团队需要了解他们将要经历的变革过程。我们的人都将在这个变革中扮演关键角色，因此他们需要理解这个场景。

创建路线图

采纳路线图是一种有组织的引导您的组织走向变革的方法。它必须包括每一步推荐的职责和角色，强调高管沟通的重要性及时机、实施团队活动、销售和 IT 的参与，以及在整个公司中最终部署变革。有了路线图作为您的指南，您将能够保持动力，实现采纳 Sure Step 的全部好处。

路线图可以按照以下图中所示的 Sure Step 的六个阶段进行管理，分为六个阶段：

让我们以下面的章节更详细地看看每个阶段。

诊断

这是对商业领导者的一项行动呼吁，以确定实施 Sure Step 的令人信服的理由。为什么我们需要 Sure Step？我们是否有战略上的理由这样做？它的商业需求是什么？我们背后的愿景是什么？确定那些推动我们在日常实践和行为中使用 Sure Step 的信念和价值观。目标在哪里，我们想要实现什么，以及如何衡量？

在这个阶段，我们还想开始建立我们的强大联盟。我们需要一个对变革持一般积极态度的团队，他们可以通过产生快速结果和激励他人探索新程序来在组织内部领导和促进变革。他们将鼓励并帮助他们的同事找到他们自己的个人利益和适应这种变革的理由。这是一个想要承担新绩效责任的团队——我们期望输出背后的支柱。现在是时候计划指派 Sure Step 的倡导者和胜利团队（V 团队）了。

Sure Step 的倡导者

倡导者是变革的日常领导者。他们负责制定和执行公司的采纳计划。理想的倡导者是一个具有专业知识、分量和信誉的高级人员，能够促进、领导和指导公司范围内的变革倡议。这个人必须深刻理解业务，得到公司最高层成员的支持，同时，在公司等级制度中上下都受到尊重。倡导者需要理解人们的恐惧，并能够指导他们探索和接受。一个在公司或竞争性公司中担任过多种角色的倡导者可能更有可能将自己置于另一个位置。倡导者需要清楚地意识到他/她为他人树立了榜样。因此，倡导者需要践行所宣扬的。

V 团队

我们的冠军的首要任务是识别和招募 V 团队候选人，他们将分别负责评估、配置和部署 Sure Step。这必须是一个经过深思熟虑的行动，涉及到识别一个良好的支持者混合体。

V 团队需要成为我们整个公司的强大代表，包括所有角色和部门。考虑至少包括以下角色：

• 一位销售经理

• 一位高级应用顾问

• 一位高级开发顾问

• 一位高级项目经理

一个理想的 V 团队还将有来自 IT、市场和人力资源部门的兼职参与，因为我们希望将我们的变革倡议与公司的文化紧密结合，而且我们的倡议也可能影响工作角色。

通过分配冠军和 V 团队，我们已经形成了我们的实质性联盟。在流程的这个阶段，我们需要通知和培训我们的冠军和团队关于这个新的 Sure Step 世界。Sure Step 是什么，以及这种方法的真正基本要素和好处是什么？这次培训需要鼓舞人心和提供信息，而不是详细和超负荷。我们希望我们的联盟感受到好处，而不是让他们被详细的技术方面超负荷。

在这个阶段，你还应该安排进行高管沟通——这是改变成功的一个真正重要的活动。高管们需要沟通为什么这个改变如此重要，并解释其令人信服的原因。他们需要明确指出，这不仅仅是一项强加的任务，而是涉及到每个人的主动性。他们需要提供关于成功模样的共同图景。你的员工需要理解策略，并受到激励和承诺采取行动。

下一个图表总结了诊断阶段的步骤：

完成这一阶段平均估计需要 30 天。

分析

这是我们将用细齿梳子仔细检查我们的习惯性实施过程，以详细了解为什么这种转型如此迫切需要的地方。我们需要关注哪里，在哪里可以找到快速胜利，以及哪些需要更多重新设计的时间？我们需要准备进行一次深入和诚实的自我评估，包括我们的流程、技能和组织结构。所有这些都会受到影响。最后，我们需要正确的输入来制定我们的采用计划。

这项调查通常是通过组织一个或多个评估研讨会来进行的。利用外部专家 Sure Step 采用促进者来管理这些研讨会及其产出可能是个好主意。

来自研讨会的输出必须被转换成行动计划，以便在采用计划的执行中进行实施。

注意

只执行这个计划一次将错过持续改进的机会。如 Kaizen 等质量改进理念表明，质量改进应该是一个持续的努力，而不是一次性引入小改进和标准化的举措。因此，我们希望多次通过路线图，每次都提高我们的一般质量和 Sure Step 采用的特定水平。

通过我们评估的结果，我们可以确定个人 V 团队成员需要哪些专业技能培训来履行他们的职责。例如，这可能包括销售方法或项目管理培训。行动计划还将指导我们如何进一步发展 V 团队在 Sure Step 方面的技能。

此阶段需要 V 团队和公司的重要利益相关者进行强有力的合作。我们需要他们的输入和真诚的意见，并且我们真的需要倾听他们。实践表明，提供输入并共同推动这一变革机会的机会确实能够激励他们。以前项目的经验告诉我们，大多数 V 团队的反馈极为积极，并导致了在执行 Sure Step 实践方面的高度承诺。

与 V 团队一起，冠军必须保持警惕，关注此采用过程中附带的潜在风险和陷阱。以下是一些需要提出的重要问题：

• 什么可能会成为障碍？

• 对于组织来说，什么会过于雄心勃勃？

• 什么是可实现的，什么又是不可能的？

不要过于雄心勃勃，也不要把所有东西都推倒。你的改进计划需要是可实现的，并且得到你组织的接受。

我们还需要在这里最终确定我们的商业案例，并向 CEO 报告我们的采用计划和投资回报率（ROI）案例。然后 CEO 将确认继续推进的决定。

完成此阶段平均预计需要 30 天。

设计

在这一点上，我们已经从分析阶段进行的评估和研讨会中收集到了宝贵的信息。我们想要改进和改变我们当前的销售和实施流程的目标就在我们的雷达上。我们也知道目标在哪里，因为我们已经确定了我们的短期和长期目标以及回报。我们现在准备开始通过将它们与 Sure Step 模板中我们公司可实现的方面进行映射，来重新设计我们当前的流程，使其成为我们公司的理想流程。

我们的倡导者必须领导 V 团队根据 Sure Step 原则和指南重新设计销售流程、项目实施流程和绩效管理流程。我们将关注那些在前一阶段确定需要我们关注的方面。这个过程设计的一部分是一个概念验证探索，检查常见的销售和实施场景，并规划如何使用 Sure Step 来应对它们。在设计过程中，我们需要在 V 团队中就我们新的工作方式达成共识。我们甚至可能需要在公司内部更广泛的范围内进行检查，因为这些新流程需要被接受并可实现。我们需要寻找对所有利益相关者的增值。这正是路线图建议运行一些潜在客户的新流程试点的原因。基于这个试点的结果，我们应该重新审视我们的设计，进行必要的调整。这是一个互动过程，允许利益相关者与我们新的执行计划合作。

一旦我们对新的流程设计达成共识，我们就可以开始将其记录为新的工作指导。这些记录的指导将引导我们的组织进行实施，并快速提升新员工的技能。同时，我们需要意识到这些新程序可能对工作角色产生影响，因此，我们应该通知人力资源部门我们的结果。我们还需要检查新流程对 IT 基础设施可能产生的影响。

在销售团队能够参与到包括新流程的试点之前，他们需要全面了解我们的组织将以 Sure Step 的方式进行工作。因此，我们需要为参与试点的销售团队组织基于 Sure Step 和新的程序的基于角色的培训。试点之后，V 团队会整理并吸收试点反馈，并根据这些反馈调整流程。

那时，就是高管们向公司通报这些新程序和试点结果的时候了。这次至关重要的沟通将推动公司接受这些新程序。

下面的图表总结了设计阶段的步骤：

完成这一阶段平均估计需要 30 天。

开发

在定义了新流程之后，下一步是开发它们。这不仅涉及到使用 Sure Step 中找到的资源，还包括完成任何所需的定制工作。正如我们在前面的章节中所发现的，Sure Step 包括一套令人印象深刻的工具和模板，可能对您有所帮助。其中一些是关键的且必需的，一些是可选的且有帮助的，而有些可能对我们的特定需求没有立即的用处。在前一阶段，我们设计了一套这些工具和模板来支持我们的新流程。其中一些工具和模板可能需要一些定制，以适应我们的特定需求。我们可能还需要配置和设置我们的 SharePoint 协作基础设施。以下是这一阶段我们需要做的事情。

在前一阶段由销售团队启动的试点项目继续进行。营销捕捉客户对我们基于 Sure Step 的新合作的反应，而人力资源部门将彻底研究角色定义和组织结构的变更。根据我们的试点项目和客户接受度测量的结果，现在是时候对我们的 Sure Step 流程进行最终修改了。

以下图表总结了开发阶段的步骤：

完成这一阶段所需的时间取决于需要完成的工作量。

部署

现在是时候确保公司全面使用 Sure Step 的上线准备。所有员工都需要具备相关知识，以便他们能够执行任务，并且所有面向客户的角色都需要理解 Sure Step 的精髓，以便在他们的客户和潜在客户中传达 Sure Step 的价值。

这种准备需要有效的沟通。我们的首席执行官应向公司发送一项全面沟通，表明我们准备使用 Sure Step 上线，履行在流程开始时做出的承诺和目标。首席执行官需要认识到公司范围内的努力以及每个人对达到这一伟大成果的贡献的重要性。这种沟通需要激发兴奋和对此新工作方式的极大信心。

确保我们的团队准备就绪需要关注在部署 Sure Step 培训之前，对我们人员进行必要的技能培训，如项目管理。销售和实施团队的所有成员现在都需要相信并宣扬 Sure Step 的巨大好处。他们需要能够通过在日常工作中实践这些新程序并帮助客户充分协作来承担这些新程序的责任。

以下图表总结了部署阶段的步骤：

完成这一阶段平均所需的时间估计为 30 天。

运营

您的员工现在正在日常工作中实践新的程序、工具和模板。这意味着新的工作方式是基于并受到 Sure Step 原则和工具的启发。通过讨论结果、展示改进和从日常工作中学习，强化这种使用方式非常重要。我们需要通过详细说明迄今为止取得的进展、每个人的努力成果以及 Sure Step 合作伙伴采用的未来目标，继续在公司内部保持沟通的链条。

Sure Step 采用路线图建议我们对实施采用成熟度进行第二次健康检查。自从我们开始这段旅程以来，它有了怎样的改进？建议将我们的再评估与作为我们的基准的深入和诚实的自我评估进行比较。我们正在寻找任何仍然存在的差距，以便我们可以计划如何解决它们。

这不是我们的变革倡议停止的地方；事实上，恰恰相反。我们负责确保通过指导我们的管理者不断强化和管理流程，持续确保 Sure Step 的有效性和采用。成熟的顾问和管理者将需要持续指导。他们的自然倾向将是回归他们已经知道的东西。

将客户满意度调查结果传达给已接受 Sure Step 合作伙伴采用型实施的客户，将推动我们组织的学习曲线。

我们新获得的、以质量为导向的价值观，以及我们员工参与质量改进项目的经验，是进行第二次采用程序的良好基础。记住，第一轮的目标可能不是全面采用 Sure Step。相反，我们在那些我们发现了改进机会的领域重新设计了我们的流程，这促使我们采取行动。我们总会找到改进的机会。因此，规划第二次改进周期的第二轮是前进的正确方式。

采用程序的价值

上一节仅揭开了一部分变革程序伴随的挑战的面纱。采用程序提供了一个基于最佳实践的预定义框架，以克服典型的陷阱。它还允许您向员工传达和可视化公司如何实施期望的变革。对于所有涉及和受影响的员工来说，提前知道他们的旅程是如何组织的非常重要。为了使其更加完善，这个程序教会我们如何通过可重复的变革过程将转型转化为实际绩效。对于我们业务中的任何策略执行者或变革经理来说，这样的程序是无价的！

GROW 成新的行为

作为一位深思熟虑的读者，你已经注意到辅导被定位为你在转型之旅中最有效的管理工具。每个转型项目的核心都是人，人们做的是他们感觉和思考的事情，而不是强加给他们的事情。GROW 模型是最著名的辅导模型之一，是一个成为更好的教练的框架。GROW 这个名字代表：

• G: 目标设定

• R: 现实

• O: 选项

• W: 意愿

目标设定包括定义目标。最终用户想要实现什么？这个人在这项转型过程中短期和长期的目标是什么？教练和最终用户需要就实现的目标达成一致。现实指的是最终用户的真实当前情况。这个人当前的工作方式或提议的转型中遇到了什么问题？他或她感知的现实是什么？选项代表选择。作为教练，我们需要帮助人们找到对感知问题的不同可能解决方案。意愿承诺采取行动。最终用户做出了什么决定？他或她将做什么，以及何时完成？

现在你可能想知道为什么基于这些 GROW 原则的辅导在本章关于 Sure Step 采用中受到强调。答案很简单：因为这个模型在产生你员工的意识和责任感方面最为有效。我们希望人们在我们的转型项目中承担责任，因为只有他们才能实现预期的变革。只要人们在事情出错或不符合预期时责怪他人，他们就不会对结果做出承诺。

责任与选择相辅相成。当人们做出选择时，他们会因为感到责任而承诺于这些选择。这正是我们想要执行我们的变革策略时的情况。我们的员工需要感到在他们的日常专业现实中执行 Sure Step 原则的责任。一个重要的细节是他们需要做出选择。通过提问和探索他们日常感知的现实，教练可以帮助承诺采取行动，以实现达成一致的目标。教练不应做出选择；我们希望得到真正的承诺。一个好的教练是一个积极的倾听者，提供观点，是能够让他们的同伴思考的人，也是能够使他们接受新的输入并因为这一点看到新选项的人。

关键文档 Visio 图

当个人或组织首次审视 Sure Step 时，许多人的初步反应是 Sure Step 包含的信息太多，难以实际应用。这种初步判断实际上是由于 Sure Step 中可用知识的深度和广度而导致的误解。

为了帮助用户轻松适应该方法，Sure Step 包括一个关键文档 Visio 图，列出了需要关注的 21 个主要活动以及任何相关的工具或模板。这个框架是任何成功的 Sure Step 项目所需的最低、理想、关键路径。以下截图显示了关键文档流程图：

从这个图表开始，您可以轻松检查和评估列出的文档，并最终评估您是否想在采纳的方法中使用它们。文档的需求取决于项目类型的选择。瀑布式和敏捷式项目管理确实有不同的文档标准。在瀑布式管理中，对快速、标准、企业型和升级型项目类型的文档需求不同。项目的独特性也决定了所需的文档集。

来自真实、已实施的 Sure Step 采纳计划的几点建议

每个采纳 Sure Step 的过程都是独特的，包括一套针对参与公司的特定挑战，但有些挑战是反复出现的且普遍存在的，例如以下内容：

• 范围识别挑战：许多客户和实施合作伙伴在与良好、可靠的范围定义的复杂性作斗争

• 沟通：在许多情况下，缺乏基本的、正式化的沟通基础

• 项目生命周期规划：许多组织缺乏一个默认的、标准化的项目生命周期规划，这个规划被所有项目经理所熟知并使用

Sure Step 包括良好的、易于使用的指导、工具和模板，以及帮助您克服这些挑战的想法：

• 用于范围识别的效率工具，例如问卷、特定产品的流程图和 Fit Gap 分析表格

• 现成的沟通文档，如项目章程和项目状态报告

• 一种标准化的项目生命周期方法，该方法通过可视化的活动和成果，适用于瀑布式和敏捷式项目类型

实践证明，这些工具在公司范围内的实施和使用为许多公司提供了比以往任何时候都更大的翅膀，并提升了项目绩效。

如何访问 Sure Step

访问 Sure Step 有两种方法。第一种是传统的桌面下载版本，第二种是 Sure Step 在线版。两者提供非常相似的功能，并允许用户执行类似的过程，但有一些差异。在本节中，将详细说明这些差异。

Sure Step 2012

可下载版 Sure Step 的最新版本被标记为 Sure Step 2012。这可以从 PartnerSource 或 CustomerSource 以 328 MB 的下载大小获得。此下载将包括所有英文内容。还有其他语言的下载可用，其中一些是完整的，而另一些则是部分语言包。可用的语言包括中文、丹麦语、法语、德语、葡萄牙语、俄语、西班牙语和土耳其语。每个下载的大小约为 350 MB，并且对客户端应用的语言包数量没有限制。

预计从现在起，Sure Step 的下载版本发布周期将受到限制。

Sure Step 在线版

基于云的 Sure Step 在线版是用 Silverlight 创建的，需要在宿主计算机上安装 Silverlight。访问 Sure Step 在线版可以通过 PartnerSource 或 CustomerSource。所有语言包都包含在在线版本中。

微软的发布周期是临时的，由于其架构，新内容可以提供给最终用户，而无需下载或重新安装内容包。

Sure Step 2012 与 Sure Step 在线版之间的关键区别

Sure Step 2012 与 Sure Step 在线版之间的关键区别如下：

• 搜索：在可下载客户端中，搜索将在工具和模板、内容名称、标签以及每个文档内进行。在 Sure Step 在线版中，情况相同，只是搜索结果不会包括文档内的内容。

• 创建项目：在可下载客户端中，项目可以本地创建，用于特定机器，或创建在 SharePoint 网站上，以便项目团队访问。现有的本地项目可以克隆以在其他项目中重复使用。在 Sure Step 在线版中，项目只能创建在 SharePoint 上。没有复制功能；然而，可以在 SharePoint 中创建项目模板以满足这一需求。

• 创建新项目：在 Sure Step 在线版中创建新项目时，总是下载最新内容以确保使用最新的项目内容。Sure Step 在线版通过在运行项目创建向导时连接到微软的在线数据存储来实现这一点。相反，使用 Sure Step 2012 客户端，新内容仅在新内容包中可用，并受限于微软的有限发布周期。

• 使用标志和默认项目属性自定义模板：这仅在 Sure Step 的下载版本中可用（如第八章项目和组织变更管理所述），项目和组织变更管理。

准备参加 Sure Step 认证考试

阅读这本书当然是迈出的一个好第一步。

Sure Step 认证考试针对以下两个原因针对项目管理受众：

• 项目经理具备必要的项目管理知识背景

• 项目经理可能会忽视整个项目生命周期

如果你缺乏项目管理基础知识，建议你通过参加项目管理基础课程来获取这些知识。

Microsoft Dynamics MVP，Vjekoslav Babic（MCP、MCT、PMP）在他的博客 www.vjeko.com 上记录了获得 Sure Step 认证所需的七个步骤。它们如下：

1. 参加一个 Microsoft Dynamics Sure Step 课程。

2. 学习文档流程。

3. 阅读指导材料。

4. 在 Microsoft Dynamics PartnerSource 站点的可用性评估测试中进行测试。

5. 阅读更多指导材料。

6. 重新进行性评估测试。

7. 参加考试。

Sure Step for ISVs

在上一节中，我们讨论了服务提供商如何从采用 Sure Step 方法以及采用过程本身中受益。现在，我们将注意力转向 ISVs，他们开发解决方案来增强 Microsoft Dynamics 核心解决方案。

分类 ISVs

在 Microsoft Dynamics 生态系统中，ISVs 提供的解决方案可以大致分为三个领域，如下所示：

• 垂直解决方案

• 水平解决方案

• 补充解决方案

行业-垂直和跨行业-水平解决方案在第三章，“使用 Sure Step 进行解决方案构想”中介绍，这一概念也适用于 ISVs。垂直解决方案是行业的子类别，其特征是具有类似产品或服务的企业。例如，汽车、化工和电子是制造业的子类别或垂直。垂直解决方案通常涵盖端到端流程，因此它相应地设计来满足垂直导向企业的特定需求。

与垂直解决方案相反，水平解决方案旨在满足广泛的业务流程或需求，可能需要一些变化来涵盖多个垂直或行业。例如，簿记、工资单和人力资源应用程序是水平解决方案。

第三类，补充解决方案，也可以被视为横向解决方案，因为这些解决方案也可以用于多个垂直或行业。但是，虽然横向解决方案可以解决多个垂直或行业的多个流程，补充解决方案是一个“点解决方案”，它针对垂直或水平市场的一个特定功能，因此，它补充了垂直或水平解决方案。补充解决方案的例子包括信用卡验证、地址查找或条形码解决方案。

ISVs 如何从 Sure Step 计划中受益

作为 ISV，无论您在哪个类别中开发解决方案，您都可以从将您的解决方案文档与 Sure Step 方法对齐中受益。由于解决方案固有的范围，如果您是垂直或水平解决方案提供商，这种对齐尤其有帮助。在本节中，我们将了解您如何从中受益。

正如您所知，Sure Step 旨在协助客户解决方案的需求收集。这进而引出一次适配性差距练习，以确定标准解决方案中有多少部分符合客户的需求，以及是否存在必须通过其他方式解决的差距。在适配性差距练习期间，增值经销商（VAR）和/或服务提供商可能会确定，部分需求最好通过 ISV 解决方案来满足。如果这一判断发生在诊断销售前阶段，拥有适当文档，如需求问卷和适配性差距工作表，将有助于 VAR 或服务提供商选择正确的 ISV 解决方案。作为 ISV 提供商，这是您的首要利益，因为它使您能够选择您的 ISV 解决方案。即使这一判断仅发生在实施阶段，预计在分析阶段的职能需求与适配性差距研讨会期间，这些文档将再次帮助服务提供商确认他们正在做出正确的 ISV 选择。

显然，确保您的 ISV 解决方案是被选中的，这是您的首要目标。我们将讨论您可以提供其他工件以增加 VAR 或服务提供商的信心水平。现在，让我们继续讨论您作为 ISV 提供商，通过与 Sure Step 方法对齐可以获得的额外好处。

您的 ISV 解决方案在 Microsoft Dynamics 生态系统中的知名度越高，您对产品的需求就越大，这无疑是一个好问题。但随之而来的是组织规模问题。您是否有资源协助多个销售机会，或者您是否有资源支持出现的实施问题？将您的流程和文档与 Sure Step 对齐可以帮助您解决这些问题。

Sure Step 对齐的其它内在好处包括缓解项目风险和提高解决方案交付时间。正如我们在前面的章节中学到的，拥有一个 Sure Step 提供的持续、可重复和端到端的生命周期方法，可以帮助服务提供商降低在合作过程中可能出现的整体风险和问题。这反过来也可以减少部署时间，从而降低客户整体解决方案交付成本。如果你的 ISV 应用程序是客户部署的整体解决方案的一部分，确保它也符合 Sure Step 将只会帮助实施团队的生活更加轻松。他们能够找到适当活动的工件，从而减少该组件的整体交付时间。他们还将使用单一分类法来描述和实施整体解决方案，这是不容忽视的。在企业资源规划（ERP）或客户关系管理（CRM）解决方案实施过程中，客户用户基础本身就经历了足够的波动；他们确实需要弄清楚多个术语来描述相同的任务。

拥有良好的基于 Sure Step 的文档也可以减少服务提供商成为你的 ISV 解决方案专家所需的时间。随着这些顾问进入其他合作，他们成为你产品的传教士，从而产生更多需求。此外，文档可以帮助顾问为整体解决方案的这一部分向客户用户提供高质量的培训。

这些只是 Sure Step 为 ISVs 带来的潜在好处中的一些。总的来说，这对 ISV、VAR/服务提供商，最重要的是客户，都是一个双赢的局面。

ISV 的 Sure Step 工件

我们已经讨论了需求问卷和适配差距工作表作为 ISV 提供商应提供的核心工件。以下列表中列出了你可能提供的其他重要文档。

将它们考虑为诊断阶段，以协助解决方案销售和客户的尽职调查。

• 产品概述：这是不言而喻的！一个好的产品需要一个强大的概述文档来描述解决方案的功能。

• 需求问卷和适配差距工作表：这已经在前面讨论过，但在此处添加以完成列表。这些文档可以与需求与流程审查决策加速器提供方案和适配差距与解决方案蓝图决策加速器（DA）提供方案一起使用。

• 基础设施和第三方软件要求：这些规范将由技术顾问在架构评估 DA 中使用，以确定附加解决方案的基础设施需求。技术顾问需要确定现有硬件是否足够，或者是否需要额外的硬件组件来满足综合解决方案的需求。例如，如果您的 ISV 应用程序还需要任何第三方组件，则应提前了解，以便团队可以提前规划采购。

• 成本估算工作表：使用这些工作表指导服务提供商在范围评估练习中开发预算估算、时间表和资源需求，作为整体解决方案部署的一部分。

• 演示数据：如果销售团队在概念验证 DA 或销售周期的任何其他阶段需要向客户展示解决方案附加功能，这是一个重要的需求。此数据集应易于安装，因为在销售周期中时间通常至关重要。还应指出，演示数据在实施过程中也可能有所帮助，例如在解决方案概述或为用户培训目的设置沙盒环境时。

虽然诊断文档的目的是帮助销售团队为客户定位和构想整体解决方案，但以下实施子集将帮助咨询团队向客户交付承诺的解决方案。以下列出的 ISV 推荐工件与 Sure Step 实施项目类型中的九个跨阶段流程相对应。这些阶段如下：

• 项目管理跨阶段：如果您的 ISV 解决方案在部署期间可能需要额外的活动，请考虑提供项目计划补充说明。您还可以考虑其他文档来描述与您的解决方案相关的满意度条件（COS）或关键绩效指标（KPI）。

• 培训跨阶段：如果适用，请包括对您的 ISV 解决方案的培训指导。

• 业务流程分析跨阶段：用例场景提供了产品实际使用的示例，这对正在开发整体解决方案愿景的解决方案架构师非常有帮助。业务流程图，特别是针对垂直 ISV 解决方案——在一定程度上，对于水平 ISV 解决方案——也可以在这方面提供帮助。这些内容在销售周期中也可能被利用。

• 需求和配置跨阶段：提供设置/配置模板将极大地帮助实施团队在参数设置等领域的实施，以便顾问可以正确配置针对客户需求的特定解决方案。

• 定制编码跨阶段：例如，用于定制的功能设计文档（FDD）和技术设计文档（TDD）模板可以帮助咨询团队的开发资源设计和记录任何所需的解决方案定制。

• 质量和测试跨阶段：用于用户验收测试（UAT）和其他相关测试的脚本对于测试您的 ISV 解决方案非常重要。这些将有助于确保综合解决方案的质量交付。如果可行，您还可以考虑其他模板，例如技术审查和项目治理合规性检查清单。

• 基础设施跨阶段：该领域的关键文档以安装指南的形式存在，描述了 ISV 应用程序应如何与核心 Microsoft Dynamics 解决方案协同安装。请记住在这些指南中包含卸载程序，这可能在切换环境时有所帮助，以及其他方面。

• 集成和接口跨阶段：使用这个区域来解释您的产品如何与核心解决方案集成。如果适用，您还可以包括有关您的产品如何与客户行业或垂直领域通常使用的其他第三方解决方案集成的指导。

• 数据迁移跨阶段：如果适用，提供数据迁移脚本和特定映射模板的指导，用于将数据从其他第三方解决方案迁移到您的产品中。

Sure Step 为您提供了起始模板，包括需求收集模板、成本计算工作表模板、用户验收测试脚本模板等，这些可以帮助您开始与 Sure Step 保持一致！以下截图显示了这些模板中的一些：

前一截图所示的 ISV 工件列表可能一开始看起来令人不知所措，因此非常重要的一点是，您不需要一次性开发所有这些文档。这份列表应帮助您考虑哪些领域将有助于代表和部署您产品的销售和实施团队。使用判断力来决定哪些领域需要立即着手工作，哪些领域可以在您的业务发展过程中开发和提供。在下一节中，您还可以找到一个表格，其中包含针对认证为 Microsoft Dynamics（CfMD）计划的模板推荐，这可能也有助于您确定从哪些开始，以及随着时间的推移构建哪些。

Sure Step 和 CfMD 计划

微软推出的 CfMD 项目将高质量和严格的测试标准应用于合作伙伴开发的商业管理解决方案。CfMD 解决方案由独立公司进行测试，并经过客户验证。通过承诺 CfMD 项目的质量要求，ISV 解决方案为分销商和客户提供更高的可见性和更大的市场推广机会。这些解决方案为客户和分销商提供了较低的风险特征，因为它们被行业中的其他公司使用并推荐，经过彻底测试并证明符合微软对合作伙伴解决方案的最高标准，并且非常重要的一点是，它们经过测试，与微软 Dynamics 和微软技术解决方案兼容和集成。

认证解决方案的主要目标之一是提供可信赖的、风险较低的解决方案，这些解决方案在解决方案投入生产时可以更快地实施并更容易维护。因此，随着 Sure Step 2010 版本的发布，CfMD 项目为微软 Dynamics ISV 解决方案提供商要开发的 Sure Step 工件引入了最佳实践指南。CfMD 项目还规定了 ISV 组织必须拥有一个或多个获得 Sure Step 方法认证的资源，以确保与 Sure Step 保持一致。

以下表格从 CfMD 的角度说明了 ISV 提供商的文档要求。在 ISV 软件测试列下带有勾选标记的文档是 CfMD 测试过程所必需的，而其他文档则是推荐的。

建议的文档	ISV 软件测试	CfMD
诊断阶段
产品概述	√
收集需求问卷	√
具体考虑 ISV 解决方案的 Fit Gap 分析工作表	√
为 ISV 考虑的 Fit Gap 和解决方案蓝图增强		√
ISV 基础设施和第三方软件要求	√
关于 VAR 如何准确界定范围、确定资源和估算相应 ISV 解决方案成本的指南	√
简短演示视频		√
中等演示视频		√
产品定位和独特卖点（USPs）		√
案例研究	√
通过运营阶段进行分析
安装、配置和卸载程序	√
ISV 样本项目计划和如何将这些计划纳入标准 Sure Step 计划的指南，例如提供示例	√
集成指南	√
操作指南		√
可安装的演示数据	√
训练计划		√
ISV 特定的业务用例场景	√
ISV 的设置/配置要求	√
FDD 和 TDD 考虑事项，包括安全要求	√
用户验收测试	√
所有相关测试、单元、功能、性能、数据或集成测试的测试脚本示例		√
交付审计清单		√
为 ISV 基础设施需求添加环境定义和部署计划		√
指导特定动态解决方案和 ISV 集成		√
ISV 数据迁移指南		√

CfMD 计划还创建了一个认证的 Microsoft Dynamics 合作伙伴到合作伙伴连接网站作为额外的好处，允许经销商直接联系认证的解决方案提供商。这为 ISV 提供了一个额外的论坛来展示他们的解决方案，并有机会招募最佳的转售合作伙伴。

作为 ISV 解决方案提供商，考虑 CfMD 计划，并利用其业务增长的好处。

用例 - 小型 Dynamics 合作伙伴采用 Sure Step

在这个案例研究中，我们关注一个小型 Dynamics 合作伙伴（让我们称他们为 Partner1）采用 Sure Step 方法论的过程。Partner1 的客户群主要集中在中小企业（SME）领域。Partner1 是一家增值经销商和解决方案实施者，其主要关注点不仅限于 Microsoft Dynamics CRM 解决方案，还承担较小的 ERP 项目。Partner1 有 24 名员工，包括 6 名销售人员，15 名顾问，以及 3 名行政/会计/基础设施岗位的员工。

Partner1 在两个领域遇到了困难：在追逐的机会上，胜负比不均衡，以及解决方案交付的不一致性导致客户满意度不高。从某种意义上说，这两个问题相互关联：缺乏良好的客户参考导致它经常输给竞争对手。

Partner1 的首席执行官首次在合作伙伴会议上了解到 Sure Step，在那里他还看到了该方法论的演示。他对这些能力印象深刻，并认为这可以帮助他的组织解决当前的两大难题。但在开始评估练习之前，他希望得到他组织内其他人的确认，认为这是值得追求的，因此他要求他的咨询总监评估 Sure Step 是否适合他们。

Partner1 的咨询总监和高级项目经理审查了通过 PartnerSource 可访问的 Sure Step 100 级在线培训课程。他们也确信进一步评估 Sure Step 的时间和精力将是一笔值得的投资，咨询总监甚至认为这对他们组织的生存至关重要。

作为第一步，他们从微软的 PartnerSource 网站上下载了 Sure Step，以更好地了解他们可用的指导、工件和工具。第二步是实施培训师培训模式，其中高级项目经理将进行深入的、讲师主导的课堂培训，然后回来教育组织中的其他成员关于 Sure Step 的知识。在其他关键咨询资源接受了 Sure Step 的培训之后，公司将评估是否以及如何需要定制该方法论以适应他们的流程。他们还将选择一个项目，并试用 Sure Step。

虽然计划相当合理，但执行并没有像 Partner1 所期望的那样顺利进行。首先，虽然项目经理参加的培训传达了 Sure Step 的知识，但 Partner1 仍然需要通过将他们的流程和交付成果映射到 Sure Step 方法论中进行练习。这需要专门资源和时间。这是一个项目经理的任务，他的主要工作是确保他/她的当前客户项目保持正确的轨道，他没有这样的奢侈时间去完成。Partner1 还觉得 Sure Step 中他们认为需要的文档有点令人不知所措，并且在与销售和交付之间的内部分类法对齐方面遇到了困难。最后，由于销售团队没有参与这项练习，销售动作以及更重要的是销售团队承诺的交付成果并没有与交付团队想要采取的新方法保持一致。项目陷入了停滞，对于 Partner1 来说，一切照旧。问题是他们的销售和交付困境还在继续。

在这个阶段，CEO 能够在一个活动中与一位微软高管和另一位合作伙伴会面。讨论和交换的后续笔记证实了他对 Sure Step 能够帮助缓解其公司困境的信念，并引导他追求一个更稳健的采用方法。

Partner1 决定使用 Sure Step 采用路线图作为指导。在已经确定了一个采用 Sure Step 的令人信服的理由之后，Partner1 的第一步是为项目指定一个 Sure Step 的倡导者。项目经理被指定为 Sure Step 的倡导者，并且她也被从一些日常压力中解脱出来，以便能够专注于采用。Partner1 提名了一个由销售经理、咨询总监和其他顾问组成的 V 团队。团队利用 Sure Step 在线自我评估来分析他们作为一个组织所处的位置以及他们需要采取哪些步骤来改进他们的流程。

在 CEO 批准了计划之后，团队着手重新设计他们的流程，以使其与 Sure Step 保持一致。Partner1 决定从销售和交付流程中重要的文档子集开始——如以下截图所示，这些是 Sure Step 指定的关键文档：

对于他们的 CRM 实施，Partner1 决定围绕敏捷项目类型构建他们的模板，而他们选择了标准项目类型进行 ERP 实施。使用 Sure Step 的项目功能，团队调整了 Sure Step 模板，并为他们的 CRM 和 ERP 解决方案创建了以 Partner1 为中心的可交付文档。在销售周期结束时提供给客户的工作说明书（SOW）模板也被重新创建并与其新的 Sure Step 可交付成果对齐。

Partner1 对这些文档进行了 CRM 和 ERP 项目的试点，并根据需要进行了微调，在所有项目上使用之前。他们还建立了定期审查项目和流程的制度，以确保他们的经验教训被转移到未来的合作中。

Partner1 已经能够简化他们的流程，并利用 Sure Step 向客户展示他们有可行的解决方案来交付承诺的服务。他们不仅关闭了更多的机会，而且客户满意度很高，员工士气和留存率也都很高。

摘要

在本章中，我们从服务提供商和 ISV 的角度介绍了 Sure Step 方法的采用。我们了解了为帮助他们采用这一过程而提供的资源，以及他们如何管理组织中的变化。

我们将在下一章总结我们对 Sure Step 的学习，并讨论一些读者在短期内需要关注的重点领域。

第十章。总结和要点

	大多数服务提供商都有经过良好培训和/或经验丰富的项目经理，使用经过验证的项目管理方法论来指导计划，并且有纪律和严谨性来执行项目计划。那些严重延迟的项目往往伴随着严重的问题，以及需求和范围失控的变化——所有这些都是服务提供商必须有所计划并准备好应对的问题。精明的服务提供商将突出其项目管理方法论的经过验证的业绩记录，并展示其有效性。
	--Gartner, Inc.

恭喜！如果你一直在跟随前面的章节，你现在对 Microsoft Dynamics Sure Step 方法论的原则和架构有了很好的理解。你理解了全生命周期方法论对于企业解决方案合作的重要性，以及 Sure Step 如何提供深入覆盖以帮助你在这一领域取得成功。

在本书的最后一章，我们将做以下事情：

• 总结前几章的学习内容

• 讨论 Sure Step 的短期计划和其未来的可能发展方向

• 提供你可以立即执行的要点

我们现在所了解的 Sure Step

自 2007 年首次发布以来，Sure Step 已经超越了仅仅关注部署 Microsoft Dynamics 解决方案的范畴。随着 Sure Step 的每一次发布，工具和方法论的设计都得到了扩展，以涵盖包括最近行业/垂直和跨行业/水平解决方案在内的更多用例。Sure Step 的潜在目标始终是帮助客户在选择和成功交付他们的 Microsoft Dynamics 解决方案，但 Sure Step 的使用价值已经超越了这一点。

Sure Step 的价值主张

Sure Step 的首要价值主张仍然是它提供的持续解决方案交付框架。Sure Step 中的流程是可重复和可扩展的，这使组织能够建立在过去学习的基础上，从而实现高质量的互动，最大化客户资源并加快客户的价值实现时间。Sure Step 在整个合作生命周期中提供了稳健的项目范围控制和管理的途径，早期风险识别和调解，以及质量保证和控制。当然，这些途径对于交付组织来说是有价值的，但对于参与解决方案交付的客户团队来说也非常有价值。

对于咨询组织来说，Sure Step 在各个团队之间提供了一个共同的主线。在 ERP/CRM 解决方案部署方面，顾问们往往有着不同的背景。经验丰富的顾问可能部署过其他竞争性系统，他们可能各自有自己的参与偏好。虽然不同的观点当然是一件好事，但当涉及到减轻业务解决方案参与中固有的组织变革时，一个团队协同工作对于客户来说至关重要。这就是为什么，让咨询团队使用 Sure Step 的相同分类法和术语，有助于他们作为一个组织共同成熟，并紧密合作。

Sure Step 的第二个关键价值主张是，它为顾客和销售者提供了一个详尽可行的流程，用于产品选择和解决方案销售。Sure Step V2 向用户介绍了扩展的诊断阶段，包括决策加速方案。决策加速方案和服务随着每个后续版本的发布而不断建立，Sure Step 提供了强大的指南、流程和内容，以支持客户和解决方案提供商。鉴于业务解决方案的重要性，我们在前几章中多次强调，这一价值主张的重要性不容忽视。与 Microsoft Solution Selling Process (MSSP) 的结合及其内在的客户尽职调查重点，如果按照提供的指导执行，可以减轻客户和销售组织面临的风险。

从诊断阶段到实施阶段的连接和流程也促进了销售和交付团队之间的信息流动。在销售周期之前，由销售资源获得的知识可以被捕捉并过渡到实施团队，以避免销售周期中设定的期望与实施期间交付的解决方案之间的不一致。这有助于销售和咨询团队，以及在某种程度上，实施后的支持团队，在客户最佳利益的基础上共同工作，而不是孤立无援。

随着时间的推移，Sure Step 还增加了多种实施项目类型，以支持客户和实施者偏好的方法。这些项目类型构成了 Sure Step 实施产品的基础。除了决策加速器和实施产品外，该方法还提供优化产品。这些优化产品包括技术主动审查服务，以在实施的生命周期中提供额外的质量保证，项目治理服务，以确保实施的范围和质量，以及技术上线后服务，如健康检查和性能调整，以确保解决方案在生产中的最佳运行。有了这些产品，Sure Step 也发展成为一个完整的客户生命周期方法。客户和合作伙伴从诊断阶段开始建立关系，继续通过解决方案的实施，通过上线后产品维持关系，并通过共同工作在解决方案升级上恢复合作关系。

Sure Step 的另一个非常重要的价值主张是其固有的促进知识管理的能力。您可能还记得之前的讨论中提到，Sure Step 项目类型工作流程中的活动是编号的，这些数字也延续到产生的项目计划和交付成果中。因此，任何文档，例如功能需求文档或用户验收测试脚本，都遵循一个数字序列，这使得跟踪、存储、检索以及在未来的合作中潜在地收获变得容易。这可以成为任何良好知识管理系统（KM）的基础。一个良好的 KM 系统有助于服务提供商在执行合作中更加高效，但它也可以帮助他们向客户证明他们在特定领域的经验，从而建立客户对他们的服务的信心。当然，KM 不仅仅是服务提供商的领域；客户也维护 KM 系统。Sure Step 的分类法还可以帮助客户在明确了解已实施的内容及其实施方式方面。它还可以为他们提供未来在整个组织内进行业务解决方案合作的良好参考。

最后但同样重要的是，Sure Step 为服务提供商和客户提供了培训价值主张。我们听到许多合作伙伴组织谈论 Sure Step 如何为他们提供一个为新的咨询资源创建培训/快速入门计划的良好结构。我们都在职业生涯的某个时刻开始过新的工作，我们记得当我们开始新工作时，尽管我们可能对自己是适合这个角色的信心满满，但胃里还是会感到紧张。知道有一个结构化的流程可以遵循，只能减轻最初的紧张感，并有助于在角色中建立信心。

这也扩展到了客户的组织。客户将有多位主题专家（SMEs）和关键用户参与其中。其中一些资源可能有过部署 ERP/CRM 解决方案的经验，而其他人可能对这种合作是新手。Sure Step 为这些资源提供了对方法的理解，以及他们自己角色中可以期望对流程做出什么贡献。

从客户培训的角度来看，另一个好处是组织变革方面。引入新的商业解决方案可能会给员工在即将到来的组织工作流程中的角色带来不必要的紧张和担忧。能够提供对新流程的可见性可以帮助缓解客户组织中这些关键资源的恐惧，而培训可以帮助他们对自己在新系统中如何履行角色充满信心。

当然，培训不仅针对新的咨询或客户资源。我们之前讨论了经验丰富的顾问，每个顾问都有自己的技巧袋。对 Sure Step 方法进行培训确保他们每个人都遵循一致的过程，并且整个团队对页面对齐，这对客户和咨询组织都有益。

总的来说，Sure Step 为咨询和客户组织创造了一个更好的整体生态系统。

重新审视 Sure Step – 摘要和快速参考

在本书的前几章中，我们提供了使用 Sure Step 成功部署您的 Microsoft Dynamics 商业解决方案的构建模块。以下图表展示了 Sure Step 中的关键方面，这些方面在本书中也有涉及：

我们从第一章“背景和概念”中介绍了方法论的概念及其在 ERP/CRM 解决方案选择和实施中的重要性。我们讨论了彻底的选择过程作为解决方案部署的基础的重要性。我们还讨论了由于范围、风险和变更管理不善而导致实施失败的情况。

第二章, 解决方案销售与尽职调查，以及第三章，使用 Sure Step 进行解决方案构想，专注于针对销售人员的解决方案销售以及它如何也推动买方的尽职调查。在第二章, 解决方案销售与尽职调查中，我们涵盖了理论和概念，并讨论了解决方案销售不是一次性的交易销售，而是销售人员需要与客户建立关系并建立信任的过程。我们在第三章，使用 Sure Step 进行解决方案构想中，基于这些概念，详细介绍了 Sure Step 如何帮助微软 Dynamics 解决方案的销售和尽职调查。我们详细介绍了 Sure Step 诊断阶段的决策加速方案及其服务，重点关注它们如何帮助加速销售周期并使其结束，同时帮助客户进行解决方案选择过程。我们还讨论了诊断阶段如何通过概述涉及的风险来为高质量的实施奠定基础，以及它如何推动选择正确的部署方法，并确定咨询团队和客户团队将涉及的角色。

第四章, 管理项目和第五章，使用 Sure Step 实施，讨论了项目的本质和预期解决方案的成功交付。在第四章, 管理项目中，我们介绍了项目管理概念，从结果驱动和现实生活的角度讨论了如何管理项目。我们讨论了项目管理中的阻力，涵盖了项目成功的四个支柱，并解释了项目管理的基本要素。在第五章，使用 Sure Step 实施中，我们专注于实施生命周期，涵盖了 Sure Step 中的瀑布和敏捷解决方案交付方法。我们介绍了构成 Sure Step 项目类型的实施阶段和跨阶段。我们还讨论了实施 ERP 和 CRM 软件解决方案时实施者和客户面临的真实挑战，并展示了 Sure Step 方法论在支持工具和模板方面的真正价值。

在第六章，质量管理与优化中，我们讨论了优化产品中的主动和上线后服务作为服务提供商和客户确保质量实施的选择。我们介绍了 Sure Step 优化路线图，并讨论了技术主动和上线后产品，以及项目治理和升级审查产品。

在第七章，使用 Sure Step 进行升级中，我们专注于使用 Sure Step 帮助现有的 Microsoft Dynamics 客户将他们的解决方案升级到最新的产品版本。该方法从升级评估决策加速器产品开始，以确定正确的方法，然后是 Sure Step 升级项目类型进行技术升级。我们还建议在升级过程中添加新功能的方法。

在第八章，项目和组织变更管理中，我们介绍了 Sure Step 中的项目和组织变更管理（OCM）学科。我们讨论了项目管理下的子学科，如风险管理、范围管理、问题管理和沟通管理。我们还解释了为什么组织变更管理是客户和合作伙伴在 ERP/CRM 合作中需要考虑的关键领域。我们还介绍了 Sure Step 中内置的 SharePoint 功能，以帮助解决方案交付团队有效协作。

在第九章，采用 Sure Step 的实际指南中，我们转换了方向，为 Microsoft Dynamics 合作伙伴组织提供 Sure Step 方法论采用的实用指南。我们讨论了组织如何使其实施方法成为其核心竞争力之一。

Sure Step 更新

从 Sure Step 的初始版本到最新版本，我们投入了大量工作来构建 Sure Step 的基础元素；这包括解决方案愿景、瀑布和敏捷解决方案交付以及解决方案优化方面，这些我们在本章的前几节和章节中进行了详细阐述。当然，每个版本也产生了新的和更新的内容元素，这将继续是近期和未来 Sure Step 更新的重点。随着工作流程和其他基础元素的建立，Sure Step 团队现在主要专注于确保在 Sure Step 中呈现的内容，包括指导和模板，与最新的 Microsoft Dynamics AX、CRM、GP、NAV 和 SL 产品版本相对应。

Sure Step 在线

Sure Step 平台的主要变化之一是几年前发布了 Sure Step Online。这在方法和发布流程上都是一个重大变化，因为它允许更快的内容更新。随着 Sure Step Online 在用户基础中的日益成熟，Sure Step 客户端正在逐步淘汰，未来的投资将继续集中在 Sure Step Online 内容更新上。以下是 Sure Step Online 的截图：

到本文写作时为止，Sure Step 团队最近为以下领域发布了新的内容更新：

• Microsoft Dynamics NAV 2013：Sure Step 中的旧角色定制实施内容已被新的 NAV 2013 快速启动指南所取代，并包括指向在线资源的额外链接。

• Microsoft Dynamics GP 2013：Sure Step 中的所有 GP 内容都已更新，以与最新的 GP 2013 产品版本保持一致，包括 GP 2013 Web 客户端的实施指南，以及其他专注于新 Web 客户端的内容。

• Microsoft Dynamics AX 2012：Visio 业务流程流程图，这是最广泛使用的文档集之一，已更新到 AX 2012 产品版本。

• Microsoft Dynamics Connector：Sure Step 提供了有关 Connector 工具的指南和链接到支持文档，该工具在 Microsoft Dynamics CRM 和 Microsoft Dynamics ERP 解决方案之间。

• Microsoft Dynamics Management Reporter：Sure Step 现在提供了包含指向 Management Reporter 的多个在线资源的内容，通过各种 ERP 解决方案实施材料引用 Management Reporter，并为 Management Reporter 提供了一个专门的职能需求文档（FRD）。此外，还提供了指向实施工具和视频的链接。

Sure Step 的更新继续由 Microsoft Business Solutions (MBS)研发团队和 Microsoft Dynamics 产品团队提供支持，以确保客户和服务提供商能够获得他们所需解决方案的适当指导。自 2007 年起步以来，Sure Step 已经取得了长足的进步，其发展将与新的研发工具保持一致，包括 Microsoft Dynamics 生命周期服务（LCS）。

确步和生命周期服务

正如我们在第三章中讨论的那样，使用 Sure Step 进行解决方案构想，Microsoft Dynamics 研发部门正在开发和发布一系列新的生命周期服务工具，以帮助客户和解决方案提供商获得一系列服务，包括业务流程建模、基础设施规模评估、快速配置、定制分析、系统诊断和升级分析。以下是如何在第三章中展示的工具和服务概述，以及它们与 Sure Step 的对应关系：

关于 LCS 工具的更多信息，请参阅第三章，使用 Sure Step 进行解决方案设想。随着这些工具的建立，Sure Step 将继续提供关键链接到这些工具，以及在特定活动和/或服务中可以调用的调用。通过这种方式，Sure Step 演变为协调者的角色。用户将能够利用 Sure Step 执行端到端工作流程以执行相应的服务，在每个服务中，Sure Step 将提供关于调用哪些工具的指导；这包括 LCS 工具。

关键要点

当我们接近这本书的结尾时，我们利用这个机会总结一些关键要点，您可以使用 Sure Step 在短期内执行，并在您的组织中实现快速胜利。

客户尽职调查和解决方案销售的要点

销售和实施业务解决方案应该关于在客户组织中创造价值。通过遵循这五个要点，努力实现双赢的交易，使双方都变得更好、更有利可图：

• 将 Sure Step 的诊断阶段作为一个机会，提出一个可适应的价值主张，而不是从预分析阶段销售一个模糊的价值主张。这代表了一个独特的开始与客户合作的机会，并确保相关各方进行适当的尽职调查工作。

• 在预分析活动中，不要将自己局限于对现状的书面复制。要专注于设想未来流程以及它们如何映射到解决方案。建筑设计公司不会仅仅根据旧房子的描述来规划、设计和预算客户的新房子，你们也不应该基于现有信息来架构客户的解决方案。使用 Sure Step 产品、行业特定的流程以及众多其他工具和资源，尽可能早地确定未来状态流程和解决方案需求。

• 从一开始就管理客户的感知，确保客户在签署合同时了解他们将获得的解决方案。这包括解释和可视化如何使用新解决方案执行关键业务流程。诊断阶段通过决策加速器提供的 Fit Gap 和解决方案蓝图评估服务帮助您管理这种感知，并在实施阶段继续这一努力。

• 通过利用相应的 Sure Step 指导，确保客户和合作伙伴利益相关者就新解决方案的真正目标和满意度条件达成一致。

• 在合同完成前，使用 Sure Step 实施选项，并选择最适合向客户交付解决方案的方法。与您的客户设想、沟通和验证您最有效的方法，因为它会影响预算、时间表和风险。

实施要点

以下要点关注 Sure Step 在实施中的影响和价值，无论是从启动和交付项目，还是从以往合作中学到的经验教训：

• 利用 Sure Step 项目生命周期计划的现成优势，结合项目类型选项。项目越长，解决方案交付过程中的不确定性就越大。拥有预定义的 Sure Step 项目生命周期工作流程和计划将帮助您快速启动实现项目目标的愿景、规划和预算。

• 确保按照 Sure Step 中的说明，重视您的项目启动会议。每个项目都是独特的，因此将这项活动视为启动团队沟通和协调的机会。

• 使用 Sure Step 项目章程，通过一个全面性的文件将所有利益相关者对齐。

• 利用 Sure Step 模板来为您的组织开发参考模型。这不仅有助于提高您实施工作的效率，而且还能帮助您的咨询团队以目标为导向，同时帮助新员工快速上手。

• 专注于为客户创造价值，并远离包含多页模糊分析的范围文档。文档很重要，但只有当它包含当前情况分析、结果和解决方案愿景的实际价值时。使用 Sure Step 工作流程、活动、研讨会和报告，确保交付团队避免这些陷阱。首先，捕捉解决方案需求（需要交付的内容），然后通过 Fit Gap 练习在此基础上构建，以达成对解决方案交付的早期共识。如果在早期阶段彻底执行这些练习，输出可以作为在整个参与过程中的指南。

• 利用 Sure Step 跨阶段流程提供的可见性，进一步促进参与项目中的各种角色和团队之间的跨职能协调和整合。

• 在项目生命周期中，使用 Sure Step 模板和指南持续与关键用户互动，让他们了解解决方案的进展，并在每个实施阶段适当的时间点建立他们对解决方案的了解。

• Sure Step 是一种帮助进行打包解决方案部署的方法。使用提供的指南进行解决方案的配置、设置和定制，以及开发期间解决方案的相应测试。

• 利用在每个实施阶段结束时提供的模板和指南进行关卡审查。在关键客户面向文件上获得签字可以提高您交付绩效的可见性和客户的信心。

Sure Step 采用要点

采用任何实施方法论是一项重要但具有挑战性的任务。以下要点将帮助您理解这一挑战：

• 不要混淆 Sure Step 的知识与公司范围内方法论的应用。将方法论作为核心竞争力采用涉及正式变革计划的制度化。将其视为在您的组织中持续改进的机会。

• Sure Step 不必与您自己的内部实施方法论竞争。利用 Sure Step 作为基准，通过适当的指导、模板和工具来增强您的实施流程。

• 不要低估采用方法论所需的努力。利用 Sure Step 采用路线图，执行一个针对您的需求、行业重点、客户和项目的逐步方法。

• 专注于在 Sure Step 中寻找可以推动您组织的价值，并确保您的团队理解这一点。

一般要点

在本节中，我们强调了一些关于 Sure Step 的一般观察：

• 记住，您的提供物应该完全关于交付价值。审查您的实施流程，确保它们旨在为您的客户交付价值。

• 与将 PMBOK 或 Prince2 等标准项目方法论视为 Sure Step 的替代品相比，您可以将它们视为补充框架。Sure Step 是一种针对 Microsoft Dynamics 合作的客户参与方法论，而 PMBOK 和 Prince2 为广泛的工程项目分类提供了一个通用的项目管理框架。

• 改进是一种态度，如果一开始没有成功，就尝试，尝试，再尝试。将所学到的经验教训作为基础，汇集任何可以用于未来项目的有用见解。

摘要

当 ERP/CRM 领域的新手接触到 Sure Step 时，他们往往会感到不知所措。鉴于内容量很大，即使是经验丰富的顾问也无法完全理解他们可用的所有资源。因此，我们编写这本书的一个目标是为那些刚开始在 Microsoft Dynamics 解决方案领域工作的人提供更多的清晰度，同时，将老练的顾问们武装起来，为他们提供额外的技巧。

因此，这本书远不止是一本关于项目管理的一步一步指南。我们的目标是解决不同利益相关者的日常挑战，而不仅仅是项目经理的挑战。我们将这本书打造成一本易于遵循的指南，供那些将 Sure Step 作为交付 Microsoft Dynamics 解决方案基础的优秀团队成员使用。

我们希望您已经对 Sure Step 的设计和架构有了深入的了解，以及对该方法论在您的工作中的应用有了认识。Sure Step 是一种由行业开发、为行业服务的方法论，其成功将继续由您，即方法论的使用者，来推动。

附录 A. 参考文献列表

第一章

• All, Ann. 企业仍面临 ERP 实施挑战, 2012. www.enterpriseappstoday.com.

• Butti, Stefano. 模型驱动开发与分层, 2011. Web Ratio Blog.

• Convergence. 微软 Dynamics 客户大会演示, 2013.

• 高德纳. 2012 年 CEO 调查：犹豫不决的一年, 2012. 高德纳, Inc.

• Genovese, Yvonne. 通过采用分层应用战略加速创新, 2012. 高德纳, Inc.

• Hestermann, Christian. 如何选择合适的云 ERP, 2012. 高德纳, Inc.

• 国际货币基金组织. 世界经济展望更新, 2013. www.imf.org.

• 国际货币基金组织. 世界经济展望更新, 2012. www.imf.org.

• 微软公司. 动态商业 2.0 愿景论文, 2013.

• Nucleus Research. 最大化交付微软 Dynamics 的成功, 2009. www.NucleusResearch.com.

• 波特, 迈克尔·E. 什么是战略? 哈佛商业评论, 1996.

• 项目管理知识体系. PMBOK®指南—第五版, 2012. www.pmi.com.

• 雷纳, 内维尔. 将分层应用于 ERP 战略, 2012. 高德纳, Inc.

• Robb, Drew. 双层战略是重振 ERP 的一种方式, 2012. www.enterpriseappstoday.com.

• TEC. 确保软件实施顺利的 5 个最佳实践, 2010. www.tec.com.

第二章

• Bosworth, Michael. 解决方案销售, 1994. 纽约, NY: 麦格劳-希尔.

• 柯维, 斯蒂芬·R. 高效能人士的七个习惯, 1989. 纽约, NY: 自由出版社.

• 柯维, 斯蒂芬·M. R. 信任的速度, 2006. 纽约, NY: 自由出版社.

• Eades, Keith M. 新解决方案销售, 2003. 纽约, NY: 麦格劳-希尔.

• Eades, Keith M. 和 Robert E Kear. 以解决方案为中心的组织, 2006. 纽约, NY: 麦格劳-希尔.

• 马斯洛, 亚伯拉罕. 人类动机理论. 心理评论, 第 50 卷(4), 370–396, 1943.

第三章

• Convergence. 微软 Dynamics 客户大会演示, 2013.

• 微软案例研究：www.microsoft.com/casestudies/.

• 微软公司. 动态商业 2.0 愿景论文, 2012.

第四章

• Archibald, Russel D. 管理高科技项目和计划, 2003. 约翰·威利 & Sons; 第 3 版

• 科特, J. 我们的冰山正在融化, 2006. 圣马丁出版社; 第 1 版

• Flemming, Q.W. 和 J.M. Koppelman. 挣值项目管理. 项目管理协会; 第 2 版

第五章

• 微软案例研究：www.microsoft.com/casestudies/.

第六章

• 戴明, W. 爱德华兹. 走出危机, 2000. 麻省理工学院出版社.

• 微软案例研究: www.microsoft.com/casestudies/.

第七章

• 微软案例研究:www.microsoft.com/casestudies/.

第八章

• 安东, 乔恩, 娜塔莉·L. 佩图霍夫, 和丽莎·M. 施瓦茨. 人与流程和技术的整合, 2003. 圣玛丽亚, CA: 安东出版社.

• 海特, 杰弗里·M. 员工变革生存指南, 2004. 学习中心出版物 (ISBN 1-930885-20-2).

• 约翰逊, 斯宾塞 和 肯尼斯·布兰查德. 谁动了我的奶酪?, 2002. 纽约, NY: G.P. 普特南出版社.

• 佩图霍夫, 娜塔莉·L., 塔姆拉·钱德勒, 和贝丝·蒙塔格-舒尔茨. 变革管理对业务的影响, 2006. 格拉齐亚多商业报告, 第 09 卷, 第 3 期: 格拉齐亚多商学院和企业管理学院, 佩珀代因大学.

第九章

• 德·弗兰德, 杰罗恩. 战略执行英雄, 2010. 绩效工厂.

• 科特, J. 我们的冰山正在融化, 2006. 圣马丁出版社; 第一版.

第十章

• 苏珊·谭. 调查分析：咨询项目团队的七个高效习惯和七个致命罪, 2010 年 7 月 26 日. Gartner 出版物, Gartner Inc.