微软 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 月：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_01_01.jpg

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

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

• CRM

• 数据驱动管理

• 电子商务

• 业务流程重组

• ERP

• 协作与知识管理

• 云业务

• 社会组织

• 企业移动性

• 改进业务报告

• 可持续性

• 动态业务流程管理

• 跟踪性和供应链优化

• 产品成本分析

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

• 客户情报

• 竞争对手情报

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

• 监管信息

• 成本

• 内部财务信息和预测

• 行业趋势数据

• 劳动力和生产率信息

• 经济数据

• 实时数据

• 商业更优

• 地理市场数据

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

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

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

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

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

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

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

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_01_02.jpg

一座建筑始于地基。一旦奠定，除非出现一些重大的建筑需求，否则不太可能改变。同样，商业解决方案的根基是行政 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论文中也有描述。

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_01_03.jpg

方法论的重要性

一致的方法论对于客户项目成功至关重要。对于实施客户解决方案的服务提供商来说，一个可预测和可靠的方法论也同样重要。这在 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 项目也存在着相当大的差异。以下插图展示了微软产品组合中的部分产品。随着您从左到右浏览这个系列，如以下图表所示，预计的解决方案交付工作量以及配置、定制和复杂性将以指数级增长：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_01_04.jpg

在这个图形表示中，关键点是 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 解决方案的全套客户生命周期方法论。它为服务提供商提供从销售到交付的全面指导，项目管理的纪律对齐，以及基于现场的最佳实践，同时促进尽职调查过程和为客户提供高质量解决方案的交付。

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_01_05.jpg

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 作为数据库技术。

下图展示了时间线：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_01_06.jpg

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）、基线指标和测量频率后，可以设置解决方案交付流程，以确保价值实现得到加速和最大化。在解决方案部署并经过一段稳定期后，可以测量实际结果或指标。

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_02_01.jpg

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

解决方案中心化的含义

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

在他的著作《新解决方案销售》中，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 年，阿尔伯特·马斯洛撰写了一篇关于我们需求层次结构的经典论文，题为《人类动机理论》。马斯洛的需求层次从最低需求水平到最高需求水平，如下所示：

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

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

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

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

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

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_02_02.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

与买家保持一致

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

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

• 是否存在需求？

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

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

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

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

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

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

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

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

• 第一阶段：需求确定

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

• 第三阶段：风险评估

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_02_03.jpg

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

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

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_02_04.jpg

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

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

微软解决方案销售流程

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

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

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_02_05.jpg

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（决策加速器）流程。

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_03_01.jpg

正如 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 诊断阶段的应用。

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_03_02.jpg

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

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

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

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

展望未来状态的第一步

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

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

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_03_03.jpg

虽然问卷有助于本服务的要求部分，但此 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 工具的屏幕截图：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_03_04.jpg

使用 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 解决方案的适配度图示。

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_03_05.jpg

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

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

确定基础设施影响

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_03_06.jpg

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

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

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

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

就像整体分阶段或大爆炸方法一样，在解决方案交付的两种方法中，没有对错之分；这仅仅是一个组织偏好的问题。一些组织偏好瀑布方法的架构，因为它清晰地分解了每个阶段的活动，从而导致了解决方案的部署。而另一些组织则倾向于在开发活动中让解决方案的需求演变，这是敏捷方法的一个特点。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 工具的报告部分：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_03_07.jpg

服务提供商执行业务案例 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 的组织，以便根据其特定需求进行定制，包括必要的法律参考。

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_03_08.jpg

另一种方法，在更紧张的经济时期更为常见，是固定范围的合作。在这种方法中，客户和服务提供商在开始时就严格定义了范围内的需求，服务提供商随后负责以约定的费用交付所有需求。这种方法对于服务提供商来说通常风险更高，尤其是在较大的合作中。合作范围通常在实施过程中经过一些级别的修改。这通常导致服务提供商在其费用结构中构建一个风险系数，以确保在缓解情况下得到一定程度的保障。值得一提的是，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 的活动流程如下所示：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_03_09.jpg

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

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

• 领导捕获

• 领导分配/路由

• 机会管理

• 引用/合同开发

• 合同转换

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

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

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

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

当前 Dynamics 客户的诊断阶段

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_03_10.jpg

与潜在客户的流程类似，现有客户的流程从诊断准备开始。然而，在这种情况下，销售团队使用指南来解释对应 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 诊断阶段活动和决策加速服务应用于解决方案销售过程的方式，也符合客户的购买周期阶段：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_03_11.jpg

• 第一阶段：需求确定

  • 解决方案概述活动

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

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

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

  • 架构评估决策加速服务

  • 范围评估决策加速服务

• 第三阶段：风险评估

  • 概念验证决策加速服务

  • 业务案例决策加速服务

  • 提案生成活动

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

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

定义组织需求

买家通过理解组织的痛点并收集市场上可用的解决方案信息来开始他们的需求确定阶段。诊断准备活动中的指导链接到其他网站和其他信息源，可以帮助解决解决方案信息收集工作。如果客户的组织在 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 服务：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_03_12.jpg

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

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

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_03_13.jpg

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

• 行业/垂直解决方案

  • 制造业

  • 公共部门

  • 零售行业

  • 服务行业

• 跨行业/水平解决方案

  • 扩展 CRM 解决方案

  • 客户关怀

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

行业/垂直解决方案

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_03_14.jpg

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 名居民提供政府服务。委员会一直使用专有应用程序来管理服务请求，但该流程和解决方案未能很好地解决选民的需求。

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

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

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_03_15.jpg

委员会接受了该计划，并同意资助这项活动。预销售交付团队在几周的时间内执行每个决策加速器服务，并为每个 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 条 – 沟通需要互动

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_01.jpg

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

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

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

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

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

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

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

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

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

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

第 3 条规则——简洁

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

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

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

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

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

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

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

• 与谁进行沟通

• 谁将进行沟通

• 要沟通的内容

• 如何进行沟通

• 何时进行沟通

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

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

积极的态度是关键

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 项目持续时间：12 个月

• 花费的时间：六个月

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

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

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

创建指导性项目文化

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

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

• 项目目标

• 此特定项目的利益

• 工作方式

• 交流方式

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

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

• 实施此项目伴随的变化

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

• 将交付的范围

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

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

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

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

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

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

关闭的重要性

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

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

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

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

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

• 存在“收尾文化”

• 收尾练习的要素

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

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

项目管理要素

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

项目生命周期及其阶段

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_02.jpg

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_03.jpg

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_04.jpg

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

什么是阶段？

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_05.jpg

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_06.jpg

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_07.jpg

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

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_08.jpg

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

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

尊重基于阶段的处理方法

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

• 没有正式关闭阶段

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

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

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_09.jpg

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

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

项目管理流程

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_10.jpg

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

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

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

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

打破它！

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_11.jpg

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_12.jpg

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_13.jpg

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

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

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

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_14.jpg

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

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

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

从估算到跟进

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

WBS 作为一种估计工具

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

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_15.jpg

基于 WBS 的跟进

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

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

WBS 作为一个核心概念

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_04_16.jpg

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 基于瀑布的项目类型中体现：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_01.jpg

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

• 三个组织跨阶段是：

  • 项目管理

  • 培训

  • 业务流程分析

• 解决方案跨阶段是：

  • 需求和配置

  • 定制编码

  • 质量和测试

• 技术跨阶段是：

  • 基础设施

  • 集成和接口

  • 数据迁移

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

基于瀑布的实施项目类型

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

快速项目类型

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

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_02.jpg

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

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

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

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

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

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

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

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

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

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

标准项目类型

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

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

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_03.jpg

标准项目类型最适合那些发现他们的解决方案需求与相应的 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 中企业项目类型的屏幕截图。截图左侧导航树视图中包含分析阶段活动的部分视图，突出了仅针对项目治理所规定的深度和勤奋。

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_04.jpg

企业项目类型的典型使用场景包括以下内容：

• 解决方案的要求包括复杂的定制和/或多个 ISV（独立软件供应商）解决方案，以及核心 Microsoft Dynamics 解决方案。在大规模合作中，特别是在多站点项目中，看到多个开发团队分布在不同的洲，基于同一解决方案的特定要求进行建设并不罕见。这些团队都必须“同唱一首歌”，换句话说，他们都在朝着同一个目标努力。为了确保团队之间有紧密的协调，并且每个团队都理解相互依赖关系，使用企业项目类型是至关重要的。

• 定制代码开发工作可能包括复杂的集成或与第三方源接口，以及将数据从遗留系统或第三方系统迁移到预期解决方案中。再次强调，企业项目类型提供的勤奋工作在这里是必要的，以确保风险在前期就被识别出来，同时还需要开发缓解方案以减轻风险，如果需要的话。

• 由于解决方案的深远影响，客户需要集中精力进行 OCM（组织变革管理）。企业项目类型规定了 OCM 专家的活动，以便提前规划并制定管理组织内预期变化的策略和技术。

• 与 OCM 活动相伴随的是深入的业务流程分析活动，允许服务提供商和客户组织讨论和记录客户的未来或即将到来的工作流程。Sure Step 中提供的活动和模板有助于企业规模客户进行此操作。

• 大规模合作还需要安装和管理多个环境以开发解决方案。这不仅需要在该项目硬件上的更大投资，还需要进行规划、设置、维护和过渡这些环境的活动，包括为在移交后支持这些环境的团队提供的明确文档，正如企业项目类型所规定的。

• 多地点合作，特别是那些希望在组织内实现一致解决方案的情况，也需要企业项目类型所倡导的严格解决方案配置和开发活动。当每个地点也有一系列独特的需求需要考虑，而这些需求超出了组织内共同需求列表时，这些组织的解决方案开发可能会变得更加复杂。这些独特需求可能源于当地国家的法律、与当地国家相关的会计和报告法规，或源于当地市场的特定要求。

需要使用企业项目类型的组织特征是系统用户数量非常高——250 个用户以上。根据解决方案要部署的地点数量，协调所有用户需要一个精心计划和深思熟虑的方法，这正是该项目类型所提供的。这包括跨地点收集需求、为每个地点的超级用户和最终用户进行培训，以及在部署前在每个地点对解决方案进行彻底的用户验收测试。

该领域的组织还以业务和 IT 团队中经验丰富的用户数量众多为特征。由于解决方案的规模和范围，客户组织通常从这一经验丰富的群体中指定选定的资源作为解决方案交付合作期间的专用资源。实际上，这些资源是实施团队的延伸，这些高级用户通常成为解决方案运营后支持其他用户的内部主要联系人。

设置解决方案部署程序

在前面的章节中，我们讨论了使用 Sure Step 实施 Microsoft Dynamics 解决方案的不同选项。Sure Step 有三个瀑布项目类型（快速、标准和企业）以及一个敏捷项目类型。这些类型指导实施者通过解决方案开发和单个发布或组织单个地点的部署。然而，这些项目类型也可以在分阶段解决方案部署或多地点合作中使用，这将是本节讨论的重点。

分阶段解决方案部署

在上一章中，我们介绍了解决方案交付的阶段性方法概念。这种方法不应与瀑布型项目类型中的阶段混淆，它指的是将解决方案分多个版本逐步推广到客户组织。阶段性解决方案交付方法在实践中是通过在第一个版本中选择并启用解决方案功能的一个初始子集来执行的，然后通过后续版本中额外的功能来在此基础上构建。阶段性方法的替代方案是在单个版本中交付完整的解决方案，也称为解决方案交付的“大爆炸”方法，我们已经在前面的章节中讨论过。

Sure Step 项目类型可以一起使用，以促进阶段性解决方案的推广。本质上，每个版本都被视为一个子项目，每个版本中启用的需求复杂性将决定相应项目类型的适当使用。阶段性解决方案推广的一般概念在以下屏幕截图中展示：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_05.jpg

按照这个概念，下一张屏幕截图展示了其用于 ERP 解决方案实施的示例。在这个屏幕截图中，阶段性方法的版本 1使用标准项目类型来启用客户的财务运营。这随后是版本 2，使用快速项目类型来交付库存控制和订单履行功能。最后一个版本，版本 3，使用敏捷项目类型来部署高级规划和调度功能。

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_06.jpg

多地点合作

当你进入更大的组织领域时，ERP/CRM 解决方案的需求往往超越了客户的多地。多地点合作可能包括一个国家内的多个地点以及全球的多个地点。后者当然引入了更多的复杂性，例如特定国家的税收和会计规则。但在大多数情况下，客户的总体目标是部署一个跨所有地点的通用解决方案。

为了在多个地点开发通用解决方案，Sure Step 提供了与其企业项目类型一起的核心站点构建选项。在这种方法中，服务提供商与客户合作，进行需求收集研讨会，涉及来自组织所有相关地点的关键主题专家（SMEs）和业务负责人。这些研讨会的输出是企业的一个综合功能需求文档（FRD），它是核心构建的基础。

核心构建可以被视为一个共同分母的解决方案。在经典的 80-20 规则中，核心构建将包括支持企业大约 80%需求的功能。然而，核心构建只是一个已开发的解决方案，这意味着它不能单独部署。核心构建总是与站点构建一起部署，这构成了满足相应站点剩余 20%特定需求的功能。在特定站点上的实际部署可以在时间上错开，或者可以重叠部署。时间本身非常关键，并且取决于为该企业启用的特定需求。

下一个截图展示了核心站点构建的概念。该图显示了单个核心构建以及随后的站点构建（站点 1 构建、站点 2 构建和站点 n 构建）以及相应的站点部署（站点 1 部署、站点 2 部署和站点 n 部署）。

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_07.jpg

在某些情况下，客户在其投资组合中可能拥有多种多样的公司，每家公司都有非常独特的一套需求，因此最好将每个站点视为一个独立的项目。对于这些多站点实例，可以使用 Sure Step 项目类型组合，这与分阶段方法中采用的方法类似。下一个图例展示了这种情况的示例。该图显示了单个站点构建和相应的站点部署（站点 1 构建-部署、站点 2 构建-部署和站点 n 构建-部署）。

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_08.jpg

Sure Step 瀑布实施阶段

前几节提供了对 Sure Step 中提供的不同交付选项的整体概述，包括单次发布的不同项目类型以及结合项目类型进行分阶段或多站点部署的能力。鉴于这个背景，深入了解每个实施阶段，以获取方法论中提供的内容和模板的具体用例和实际场景是个好主意。我们将在本章的后续部分探讨这一点。

分析阶段

我们大多数人知道分析阶段是什么，我们通常将其解释为执行活动以更详细地揭示客户的需求和业务流程——换句话说，就是“详细内容”。这就是全部吗？

项目的开始

通过启动分析阶段，我们开始了项目的真正实施。一个好的开始将为我们的进一步实施定下基调。关于“分析阶段的目的”的问题，通常用以下答案来回答：为了进一步分析和记录客户的需求。听起来合理，还是不是呢？

启动你的引擎

这个答案相当不完整，因为它忽略了启动项目的重要功能。这就是我们启动引擎、设定航向并起飞的地方。在航空领域，起飞被认为是复杂且关键的。在软件实施项目中，情况也大致相同——开始阶段总是至关重要的。在分析阶段，我们不仅调查和记录客户需求和流程，还启动风险和问题管理、范围管理、变更管理、成本和时间管理、沟通管理以及质量和资源管理。正是在这里，我们为我们的项目文化和特定任务沟通定下了基调。因此，我们需要明白，除了调查需求和流程之外，还有更多的事情需要做，并且我们需要为此做出更多规划。

预计会有一些延误

在诊断阶段，我们努力争取客户的正式合同，即项目的正式批准。事实是，在提交和捍卫我们的提案之后，许多事情都可能发生。对我们来说，理想的情况是客户立即接受并签署我们的提案，并批准我们开始实施项目。如果我们幸运的话，事件可能会以这种方式展开，但替代方案也并非例外。客户的决策过程可能会消耗大量时间。可能需要几周甚至几个月才能获得批准。在经济困难时期，投资决策也可能推迟到下一个财年，导致进一步的延误。一旦我们通过批准的合同从客户那里得到正式的点头，我们仍然不能确定实施项目可以立即开始。实施活动的执行需要战略性和细致的计划，因此，在合同达成协议后，可能需要额外的时间才能真正开始。在制定分析阶段的飞行计划时，我们需要考虑诊断阶段和分析阶段之间的这种时间（不）连接。

建立项目文化的机会

在第四章《管理项目》中，我们讨论了为我们的特定项目建立指导性项目文化的重要性。实际上，我们将它定义为项目成功四大支柱之一。将客户和咨询团队连接到与该项目相关的价值观、信仰、优先事项和行为对于我们的成功至关重要。在我们投入项目的执行任务之前，我们需要确保所有利益相关者和团队成员都与我们的一致，并了解这个项目的所有关键要素。我们需要从实施项目的开始就践行我们所宣扬的原则。现在，实施项目何时开始？答案是，它现在就开始，就在分析阶段。

回顾

在我们定义和讨论下一步行动之前，让我们回顾一下我们现在所处的位置。以下图表描述了从决策加速器到最终提案的流程。此图表仅包括三个重要的决策加速器：需求与流程审查、适配差距与解决方案蓝图、范围评估。诊断阶段也可能包括其他决策加速器，但如前所述，您可以按需部署决策加速器。图表将工具和模板分为两类：工作和关键交付成果。工作交付成果是那些作为顾问工具箱的工具和模板，帮助顾问提高效率和品质。他们可以在需要时从盒子里挑选任何工具。有时，他们需要使用许多这些工具，在其他情况下，他们可能只需要少数几个。关键交付成果是面向客户的交付成果的一个子集。这些是我们将作为参与最终输出的文档交付给客户的。确保这些文档支持我们的沟通并正式化客户对所述主题的验证是很重要的。

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_09.jpg

当我们谈论将人们的愿景和我们的方法对齐，并创建一个指导性的项目文化时，我们需要意识到，通过执行决策加速器，我们确实产生了有价值的工具和丰富的信息。事实上，我们启动指导性项目文化所需的一切都已在项目章程中汇编，这是提案生成活动的一个关键交付成果。

一个好的项目章程是无价的

在 Sure Step 中，项目章程是在提案生成活动中生成的——这是微软解决方案销售流程（MSSP）证明阶段的关键组成部分。先前诊断活动中得出的结论成为提案生成活动的输入，其中关键任务包括得出结论和打包可用信息和文档。

Sure Step 项目章程回答了关于项目的基本和必要问题：

• 为什么：业务目标、关键成功因素和项目目标是什么？项目解决的价值主张是什么？为什么会有赞助？

• 什么：主要交付成果是什么？范围是什么，范围外是什么？

• 谁：谁将参与，他们在项目中将承担什么责任？他们将如何组织？谁是关键的利益相关者？

• 何时：项目进度表是什么，里程碑和交付成果将在何时完成？

• 如何：团队将如何参与？我们将如何应对变化、问题和风险？我们将如何执行、管理和控制项目？

以下截图是 Sure Step 项目章程的目录，它清楚地说明了所有诊断结论都汇集在这里：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_10.jpg

那么，你能想到一个更好的工具来协调所有利益相关者和团队成员在项目方法愿景和所有关键要素方面的看法吗？项目章程的价值是无价的。它将所有相关的项目信息（关于什么、谁、如何和何时）汇总成一份文件，作为所有利益相关者治理整个参与活动的稳固指南。

项目规划会议

我们之前讨论过，在诊断阶段结束和分析阶段开始之间可能存在时间差距。因此，我们可能需要在分析阶段开始时修订和更新我们的项目计划和项目章程。以下图表说明了在分析阶段开始时的规划会议中诊断输出的最终确定：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_11.jpg

项目规划会议是与客户一起进行的联合练习。会议议程包括项目概述、时间框架、可交付成果、建立项目结构、风险和利益相关者分析，以及沟通、变更控制、资源和质量的规划。

启动你的沟通文化

我们都知道启动会议的概念，但我们是否低估了它的重要性？我们有时倾向于将启动会议作为一项操作来执行，即通过重复交付完全相同的内容。我们通常介绍我们的公司、我们自己以及咨询团队，并要求客户也这样做。

然后我们讨论我们的阶段、时间和预算限制，以及我们即将实施的产品。最后，我们试图在积极气氛中结束这次会议。然后，这次启动会议的内容在我们的所有项目中都完全重新交付。但这足够好吗？为了回答这个问题，我们需要考虑以下两个重要因素：

• 项目本质上都是独特的

• 在诊断阶段结束和开始分析阶段之间可能存在时间差距

独特的项目需要独特的启动会议。是什么使每个项目独特？让我们列出一些重要的区分因素：

• 利益相关者、组织背景和复杂性

• 利益相关者的目标和期望

• 商业和项目目标

• 关键成功因素

• 范围内的区域和需求

• 范围外的区域和需求

• 客户和咨询实施团队

• 预算和时间限制

这些元素在我们实施项目中总是不同的。因此，我们需要在启动会议上解决这些问题。通过这样做，我们的启动会议将包括使它们独特的必要元素。我们需要将启动内容与每个实施项目的独特特征相连接。这意味着启动会议不能以操作的方式进行。启动会议需要根据每个具体项目量身定制，并在客户独特组织的背景下进行展示。

这正是为什么 Sure Step 建议在启动会议中推荐以下议程主题：

• 简介

• 项目定义和目标

• 关键可交付成果

• 成功标准

• 项目方法

• 项目团队和组织

• 职责和角色

• 培训和测试

• 控制、报告和批准

• 沟通

• 项目范围

• 问答环节，为顾客、利益相关者和团队成员提供一个表达任何担忧或疑虑的机会

总结

是的，准备这类启动会议会消耗一些时间，尤其是当你第一次需要创建此类内容，需要在各种文档和地方搜集信息时。回顾一下议程要点。我们可以在哪里找到这些信息？是的，你说得对；项目章程将所有这些信息汇编成一份文档。通过诊断活动生成的稳健项目章程是独特而有效的启动会议的起点。这就是为什么 Sure Step 列出了以下启动会议的先决条件：

• 初始项目计划已到位

• 确定项目利益相关者

• 项目章程已建立

• 项目准备就绪，可以执行

我们现在可以通过添加启动会议来进一步完成我们的图表。以下图表说明了从诊断活动中生成的信息如何在项目章程中汇编并作为启动会议的输入重新使用：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_12.jpg

在实施项目开始时，一个以价值为导向的启动会议对于协调所有利益相关者至关重要。在诊断阶段结束、合同签署和开始分析阶段之间，可能会出现许多情况。在咨询现场，参与特定项目诊断活动的团队可能已经解散，并已经开始计划其他任务。在客户现场，关键用户可能已经更换部门或离开公司。可能会有新的经理或部门负责人被雇佣，带来新的愿景和优先事项。由于新出现的商业机会，业务流程和需求可能已经经过审查和修改。在诊断阶段结束和分析阶段开始之间面临较长时间的情况下，可能出现许多新的情况。

那么，我们的使命现在是什么？在启动会议上，我们需要验证和确认我们是否仍然对项目章程中所述内容达成共识和支持。这对启动一个成功的合作至关重要。我们是否仍然拥有相同的利益相关者？他们是否仍然支持项目目标和优先级？我们是否仍然对范围达成共识？新的咨询团队成员是否与诊断结论一致？他们是否有关于范围和业务流程的问题？需要签署哪些文件，谁需要签署，签署究竟意味着什么？我们还需要展示和审查计划，并确定我们的下一步行动，包括期望从谁那里得到什么。

因此，启动会议不仅仅是小规模的聚会来展示自己和公司；它需要更多。我们不仅需要就什么、如何、何时达成一致，还需要寻找自诊断阶段结束以来出现的问题和变化。

培训还是不培训？

在启动会议之后可能考虑计划的第一项活动之一是培训。培训不仅是一种优秀的教育工具，也是一种管理感知的伟大工具。在 Sure Step 中，培训是跨阶段过程之一，有助于更好的项目生命周期规划。阶段不应仅限于其核心活动，但需要包含所有跨阶段活动的良好混合。在这个愿景中，培训不应仅限于部署阶段。为什么我们会考虑在分析阶段规划培训？我们如何从中受益？我们在分析阶段培训的目标非常重要。以下是我们应该牢记的一些理想目标：

• 提高对新解决方案的认识

• 介绍范围内功能领域的功能架构和标准概念

• 介绍应用的词汇

• 在客户和咨询团队中建立对流程和功能的共同理解

• 促进感知和组织变革

• 提高即将到来的分析研讨会效率和品质

如果在分析阶段进行培训实现了这些目标中的哪怕一小部分，这也将是值得的。那么，我们是否需要计划对最终用户的整个团队进行关于他们新解决方案的培训呢？答案是简单的，那就是不需要。我们不想在这个项目生命周期的这个时刻教育最终用户，因为这会太早，而且不会有效。研究清楚地表明，到 Go-Live 时间，最终用户会忘记大部分内容，我们的培训投资将不会产生任何回报。我们想要计划的是为针对特定群体的小型培训。我们希望我们的关键用户团队能够理解我们的解决方案的功能概述，以及与他们专业领域相关的内容。因此，我们需要向选定的受众展示并阐明适用于相关功能领域的标准化功能和流程。这可能会展开讨论，但这正是我们的目标——良好的客户互动、反馈和积极倾听可以为我们提供大量信息。

在这个阶段，我们可能已经发现了一些机会来展示，在保持相同或更好的结果的同时，可以通过稍微不同的顺序或方式执行现有流程。你做得对；我们应该在我们核心分析活动开始之前就着手管理人们的认知。组织变革管理不是你只在 Go-Live 之前启动的事情；它应该贯穿于你的项目生命周期规划中。你可能会问，这种培训可能存在哪些风险。最大的风险是针对错误的受众。这种培训，在 Sure Step 术语中被称为Conduct Solutions Overview，对于真正的最终用户来说是不合适的，因为他们只有一个目标：他们寻求答案，了解这个新解决方案将如何解决他们详细的日常工作。在这个解决方案概述培训中，他们找不到这些答案，可能会导致潜在的挫败感和消极情绪。而且正如你所知，坏消息传播得很快。这就是为什么我们需要妥善管理这些会议，并有效地与我们的客户沟通，这些会议是为他们而设的。

下面的图表说明了启动会议之后活动流程的延续：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_13.jpg

未受控制的分析阶段

项目管理状态报告通常在分析阶段不会披露许多问题。当我们询问我们的应用顾问在分析活动中的状态时，他们通常会回答说一切顺利。一些项目经理并不认为这个阶段是一个复杂的情况，他们将这个阶段的成功委托给涉及的业务分析师。他们安慰自己，当他们部署高度熟练和经验丰富的业务分析师和应用顾问进行业务流程分析研讨会时，他们不需要担心太多意外的问题。似乎这样的项目经理也不太关心这个阶段的可交付成果。他们只需要一份书面文档，描述并解释客户对业务流程所需的功能需求。现在看起来，在分析阶段唯一受到挑战的是业务分析师，而项目经理只是面对一个轻松的小任务，即规划研讨会并在研讨会活动中收集一些反馈。如果这是真的，我们在这个阶段就不需要项目经理了。让我们更仔细地看看，在这个阶段项目经理真正面临的挑战是什么。

我们已经在前面的章节中了解到，我们不仅需要计划纯粹的分析活动，分析阶段还代表着实施项目的开始。这将挑战项目经理启动项目文化和方法，而这不仅仅包括计划几场访谈会议。即使我们忽略这一点，真正的分析活动也要求良好的项目管理。

如果我们将责任限制在规划研讨会、询问我们的应用顾问进展情况以及等待最终文档交付上，我们就是在放弃所有控制权。我们首先失去的控制元素是进度报告。如果我们只能以最终文档交付的形式报告进度，我们实际上能做的事情很少，除了等待这份最终文档并从完成百分比的角度来推断进度。现在我们都知道这有多准确。我们将失去的第二个控制元素是质量控制。如果我们等待这份最终文档交付，我们只能在它准备好后评估质量。那时，可能已经太晚采取纠正措施了。大多数项目经理可能甚至不会阅读完整的分析文档交付，因为他们没有足够的时间去审查所有细节。

在项目生命周期的第一阶段放弃进度和质量跟踪能力并不是明智之举，这将为我们的整个项目定下基调。如果我们不关注这些重要方面，我们很可能也不会在以后关注。

不幸的是，还有其他一些东西可能会被忽视：为分析活动、范围管理和问题及风险管理设定优先级。这些元素在分析阶段的被动项目管理部署期间都处于危险之中。这些元素将在下一节中列出并讨论一些真实世界的分析场景。

真实场景分析

在一个不受控制的分析阶段，我们可以识别以下典型的场景。

回到起点

直接切入正题：应用顾问从头开始，重新分析一切——这有多明显？相当多的应用顾问在核心分析活动开始时完全脱离诊断结果，并且没有关于待分析范围优先级的指导。我们能否预测这种场景的结果？结果可能是涵盖了许多不太重要主题的详细信息的分析文档，同时缺乏关于更重要和复杂领域的良好信息。在许多情况下，客户也会感到沮丧，因为他们不得不再次提供相同的信息。看起来我们又回到了起点，我们之前执行的预研究分析活动并没有带来太多改变。客户将不明白为什么我们为此收费，并抱怨浪费了努力。表现得惊讶吧！

范围蔓延悄然而至

我们大多数人对于范围变更都了如指掌。它是导致项目失败最常见的原因之一。了解了这一威胁，我们便为此做好准备。手持变更请求，我们从发现范围蔓延的第一刻起就开始与之抗争。至少这是我们告诉自己的一句话。问题是，我们大多数人只是在项目生命周期的后期阶段才识别出范围蔓延，那时我们刚刚结束开发活动，开始参与测试活动，或者更糟糕的是，当我们正在为上线做准备时。不幸的是，在这个阶段我们赢得战斗的机会微乎其微。

我们需要意识到，范围蔓延很可能在分析阶段悄无声息地溜进来，尤其是在我们的分析师与良好的诊断结果脱节时。在这些研讨会中，我们的分析师团队将与几位部门负责人、关键用户和业务分析师等会面。他们都将对应该自动化什么以及如何自动化有自己的看法。他们可能会提供有关现有需求的新信息，甚至在这一阶段提出全新的需求。如果我们的分析师现在没有识别或报告这一点，我们的范围蔓延怪物将在后期阶段开始生长，并变成一个巨人。

没有问题，没有风险

在分析阶段进行被动项目管理不会为分析师团队提供很多关于其职责的指导，特别是当谈到问题和风险时。在分析阶段，项目经理经常询问他们的顾问团队事情进展如何，而且很少会报告问题和风险。在大多数情况下，一切都被报告为处于控制之下。这是因为应用顾问可能不会觉得在这个阶段识别问题和风险是他们的责任。在这个阶段，识别问题和风险通常被视为项目经理的责任。问题是项目经理并没有参与所有的研讨会和访谈，缺乏进行这个问题和风险识别所需的信息。因此，在这个阶段很少（如果有的话）报告风险和问题，这是一个错失的机会。有一点是肯定的：在分析阶段，我们将面临问题和风险，但如果它们没有被识别和报告，我们将在项目生命周期的后期面临后果。

我们可以通过指出项目经理应该控制分析阶段的原因有很多来总结。除了核心分析活动之外，还有更多的工作要做，甚至对这些分析活动的管理也需要项目经理有坚实的方法和清晰的愿景。在接下来的章节中，我们将讨论 Sure Step 如何帮助我们。

分析什么？

要知道哪些需要我们全神贯注，哪些可能需要我们较少的关注，我们需要回顾我们的诊断结果。以下图表说明了与诊断结果之间的联系：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_14.jpg

顾问可以通过回顾诊断结论和重新使用诊断工具和成果来为业务流程研讨会做准备。项目章程应该提供一个完整的图景，说明范围之内和范围之外的内容，业务优先级，关键成功因素，以及已知的问题和风险。如果这些在诊断阶段进行了建模，问卷和产品特定的流程图将是分析阶段的一个极好的起点。它们在整体客户业务环境中可视化了已经识别的瓶颈和复杂区域，并将为顾问团队规划分析活动提供明确的指导。分析团队也将从 Fit Gap 分析工作表中受益，它提供了以下非常有价值的信息：

• 与业务流程相关的需求

• 需求优先级

• 按照标准功能、配置、定制、工作流和 ISV 解决方案分类的需求

以下图表说明了 Fit Gap 工作表如何作为业务流程研讨会的一个输入工具：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_15.jpg

通过给定的优先级要求，包括通过类别估计的努力和复杂度排名，应用咨询师可以更好地规划和优先考虑可用的分析时间，从而在更短的时间内实现更高效和以质量为导向的分析工作。

追求中间分析交付成果

如果我们想在分析阶段跟进我们的应用咨询师在进度和质量方面的表现，我们应该计划中间交付成果。制作一个简单的文档，例如研讨会报告，因为它可以产生很大的影响。作为项目经理，你需要指导你的团队，每次研讨会后都需要制作研讨会报告。它包含标准化的部分，这样所有应用咨询师在记录研讨会结果时都使用相同的格式。这使得项目经理跟进起来更加方便，因为每份文档都可以以相同的方式进行阅读。一旦计划中的研讨会结束，咨询师需要提供研讨会报告。不充分的研讨会报告将被项目经理质疑，并可能导致纠正措施。在研讨会本身之后不久生成的研讨会报告，将防止重要信息被遗忘的额外风险。

与分析活动合作标准化中间文档交付成果的一个巨大额外好处是，可以明确结构和质量方面的期望输出。这也会为咨询师的交付设定明确的期望。

以下截图展示了一份研讨会报告的一页：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_16.jpg

这一页非常清楚地表明，应用咨询师不仅应该记录客户利益相关者在研讨会中告诉他们的内容，而且他们还负责生成结论，将信息与诊断范围联系起来，识别问题，并推动流程变化，以避免不必要的定制。作为项目经理，你现在可以通过提出两个问题来组织你的跟进：

• 研讨会结束时我们是否有研讨会报告？

• 应用咨询师是否以高质量的方式填写了第六部分？

这种方法与“等待最终交付成果”的方法有巨大的区别。

通过拟合差距分析在分析阶段管理范围蔓延

如前所述，未管理的分析阶段的一个后果是范围蔓延悄无声息地进入。在分析阶段活动中，关于现有需求的新信息变得可用，使原始请求在新的光线下显现，甚至允许制定新的需求。即使有坚实的实施方法，这些情况也是不可避免的。未能识别这些范围变化会影响所有利益相关者在持续时间、成本、质量和期望方面的利益，这使得识别它们成为我们的真正挑战。以下图表介绍了 Fit Gap 评估作为分析阶段的有价值工具：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_17.jpg

一旦所有业务流程和需求调查都已经完成，就是时候在功能需求文档（FRD）中记录所有发现和结论，为新的解决方案提供完整的需求描述。现在我们已经将所有范围定义到了所需的详细程度，我们可以重新评估 Fit Gap 情况。

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_18.jpg

Sure Step 倡导在分析阶段捕捉到需求后，重新评估 Fit Gap 情况的好处。这可以防止范围蔓延悄无声息地进入，它加强了所有利益相关者对预期解决方案的认识，并为项目经理提供警告信号，以解决多个问题。如果我们的评估揭示了新的需求、变更以及其他重要的范围挑战，我们需要接受这些宝贵的信息。这证明了我们的顾问团队对项目和业务范围的影响非常关注，并且我们被激发采取一些良好的项目管理行动，这是我们的真正工作。立即行动！那么我们能做什么呢？我们至少应该就这些确定区域进行沟通。咨询团队的意见是什么？客户团队对此有何感受？影响是什么？我们能找到替代的业务流程和解决方案吗？我们不应该对这些情况感到恐慌，也不应该忽视它们。这些情况在项目中无处不在，在分析阶段识别它们是正确方向的一步。推荐如何解决这些问题？由于项目是独特的，你应对这些挑战的方法和解决方案也将是独特的。你可能需要一个包含各种成分的配方，例如业务流程变更、拒绝一些新的不重要需求，以及接受一些真正的范围变更。你的配方需要在这个背景下味道好。它需要与目标、预算、时间和成本限制保持一致，同时也要得到大量利益相关者的接受。

我们刚刚提到范围变更了吗？Sure Step 明确指出，范围变更及其管理不能仅限于项目生命周期的最后阶段。在 Sure Step 中处理范围变更是提案管理的一个要素。Sure Step 实际上是这样说的：“提案管理是一项需要在项目实施生命周期的所有跨阶段执行的活动”。因此，我们可以在分析阶段开始提出变更请求。这意味着客户组织将在项目生命周期早期就熟悉这一过程。变更请求是一种有效的工具，可以控制范围蔓延，但需要谨慎处理。当仅在一个阶段操作并且变得过于频繁时，这个工具将失去所有的影响力。有时我们倾向于认为变更请求不仅是为了解决所有范围问题，也是为了解决所有质量问题。当明确的质量问题被不恰当地、厚颜无耻地作为变更请求提交，并且每个范围问题都转化为变更请求时，我们正在制造一堆文书工作。最佳实践告诉我们，在这些情况下，范围变更问题将保持未解决状态，因为客户不会批准这些变更。感到惊讶！专家级的使用变更请求意味着在整个项目生命周期内平衡使用，正如 Sure Step 所建议的那样。

我们现在可以进一步完成分析阶段的图示：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_19.jpg

不要忘记数据迁移

专注于功能性解决方案，数据迁移通常被视为次要问题。我们热爱设计功能性解决方案，连接业务流程和软件功能，对此如此专注以至于其他一切都不复存在。这实际上并不聪明，因为非功能性需求可能是一项艰巨的任务，消耗大量资源并带来相当大的风险。我们中的大多数人已经体验过数据迁移挑战如何影响项目持续时间甚至上线决策。这就是为什么 Sure Step 关注数据迁移。诸如现有数据状况、数据清理、要迁移的历史数据量、现有数据源的识别以及主数据管理等话题，需要从一开始就解决。他们需要确保这些话题在分析研讨会上得到处理。

与基础设施部门互动

良好的项目生命周期规划需要在每个阶段都包含跨阶段流程的良好组合。我们已经看到，分析阶段不仅仅是为核心分析活动保留的，它还需要积极的项目管理、强大的沟通、培训以及对数据迁移问题的关注。还建议开始与基础设施利益相关者互动，以构建沙盒和培训环境。这些环境需要允许客户培训和对核心微软 Dynamics 产品的熟悉，在配置或定制之前，这提供了一个建立与客户基础设施人员关系和沟通的绝佳机会。我们越早开始与他们互动，就有更多的时间为他们准备关键转折点。

设计阶段

解决方案设计是任何软件项目中的关键活动。即使涉及到的定制化不多，我们仍然需要设想项目的“如何”。

我们真的需要设计阶段吗？

我们真的需要一个独立的设计阶段来设计解决方案吗？ 这是一个经常被问到的问题。有些人声称在分析阶段就开始设计解决方案，而有些人则将其包含在开发阶段，甚至在方便的时候进行。从瀑布模型的角度来看，你可以在一个或多个阶段中规划你的设计活动，只要你在特定阶段执行了计划中的内容。因此，并没有真正的瀑布模型理由来特别设立一个设计阶段。然而，阶段代表了时间上的分解，以便更好地规划和管理工作流程。这就是为什么 Sure Step 计划在单独的设计阶段中实施主导的解决方案设计流程。在捕捉到范围基线之后，我们现在可以集中精力在管理良好的时间框架内进一步发展我们的解决方案概念。我们大多数人都熟悉“什么”和“如何”的常识规则：在诊断和分析阶段，我们专注于“什么”方面，而在设计阶段，我们则发展项目的“如何”方面。这表明了在这些阶段中主导流程将是什么，但不要被误导：项目管理跨阶段流程已经教会我们，在阶段中我们需要规划的内容要比核心活动更多。

被动设计阶段的风险

诊断和分析阶段的核心活动本质上都涉及客户互动。销售前活动，如需求评估、业务流程评估、概念验证演示、研讨会和访谈等，都需要客户互动。在设计和发展活动中，这一点并不那么明显。设计活动通常被设想为并缩小到记录“如何”方面。这意味着设计等同于撰写关于“如何”方面的文档，唯一的计划客户互动是验证文档。将这一点与对开发阶段的相同被动愿景结合起来，将严重危及我们的项目成功，因为我们实际上是在将客户排除在项目之外，直到真正的部署活动，并推迟许多实施活动。我们真的想承担这个风险吗？

确步设计阶段的所有活动

开始赞扬确步的好处，因为它将使我们摆脱被动的设计阶段。真正的实施活动就在设计阶段开始！确步告诉我们不要等到开发阶段结束时才开始实施活动。我们需要通过频繁与利益相关者互动来保持与客户组织的联系。我们需要提高我们的利益相关者对项目和解决方案的认识和知识水平，刺激组织变革，并继续识别和管理风险和问题。有许多事情要做，是的，我们也会记录一些“如何”，但不会限制自己只做这一点。

我们正在实施一个标准包解决方案

现在让我们思考一下这个问题。它说了什么？这意味着我们不是在交付一个纯开发项目。通过安装标准功能、配置或 ISV 解决方案，可以满足大量需求。那么为什么我们有时只在开发活动完成后才开始实施？一些标准功能将依赖于定制功能，而这些需求不能立即实现，但这并不适用于所有情况。包解决方案的一个关键优势是，与定制解决方案相比，我们可以非常快速地交付。我们需要通过尽早开始实施来利用这一点。实际上，推迟实施真的没有理由。我们将从解决方案早期交付的小部分中受益。

从需求到设计

在诊断阶段，我们收集了高质量的信息，将其分解为需求，并通过将它们分类到标准功能、配置、定制、ISV 解决方案和工作流程中与我们的标准解决方案进行映射。我们在分析阶段细化了这种理解，并再次与我们的标准产品进行核对。这意味着我们可以根据结构化信息开始设计阶段，这些信息将指导我们下一步做什么：文档和实施。

文档和实施

以下图表显示了要实施和记录的内容：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_20.jpg

从诊断和分析阶段出来，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 文档中设计的需求，在这一阶段得到开发。这不仅包括解决请求的功能性需求的功能性要求，还包括数据迁移和接口等非功能性要求。开发团队需要首先审查解决方案和技术设计文档，然后开始实际开发。他们应该遵守所有批准的质量和文档标准。在较大的开发团队中，由主开发人员协调开发工作也是至关重要的。产生的交付成果将经过多次单元和功能测试迭代。一旦成功通过，代码将被冻结，表示它不再开放修改。只有在数据验收、流程或集成测试中发现问题时，才能进行进一步的修改。不要忘记，当交付的定制与预期不同时，更新设计文档。

完成测试

一旦定制功能交付成果开始生产，我们就可以进一步完成在设计阶段启动的测试。现在我们可以通过测试越来越多的完整流程，将其提升到全面解决方案测试的水平。你说对了——测试是一个跨阶段的过程，它使我们能够在整个项目生命周期中继续与客户互动和沟通。现在是时候进行集成和数据验收测试了。到目前为止，我们的主要用户应该已经非常熟悉测试流程，并且他们正在不断加深对解决方案的了解。他们将微调测试脚本，并可以开始编写用户验收测试脚本，以便在部署阶段引导用户组织通过这些测试。感谢我们持续的测试努力和与用户组织的合作，我们将收集问题和疑问，并在关键用户团队中检测到不确定性和敏感性。我们必须利用这些信息！我们需要在这里解决这个问题，确保部署阶段达到最佳状态。

下面的图表说明了我们从设计阶段进展到开发阶段的情况：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_21.jpg

我们也可以继续在测试脚本开发上的合作，这是我们始于设计阶段的任务。与关键用户一起，我们现在可以准备用户验收测试脚本，这些脚本将在部署阶段引导用户验收测试（UAT）。UAT 是所有先前测试活动的最终成果。尽管可以利用先前的测试脚本，但 UAT 脚本应专注于系统用户执行的主要功能。

最后一次变更请求

在任何项目中，变更请求总是出现在地平线上，无论我们如何定义我们的范围，或者我们在组织变革管理方面做得多么好。在讨论的 Sure Step 生命周期规划中，我们试图在所有阶段与客户组织保持互动，以识别问题、风险和变更请求。这使我们能够尽早识别它们，并在整个项目中进行分散。这样，我们可以主动管理，防止问题成为部署阶段的真正负担。在开发阶段，我们仍然会检索和管理变更请求，但现在我们需要意识到，在这个阶段之后，我们需要将变更降低到较低水平，我们的最终用户组织需要对此有所了解。作为项目经理，我们有责任让我们的客户了解这一点。另一个沟通挑战！

流程模型还可以更改吗？

这个问题的答案是肯定的。由于我们在开发阶段计划的活动和互动，我们将从客户和咨询利益相关者那里收到反馈。我们的开发者可能会有关键的评论，应用顾问可能会提出重要的见解，我们的客户也可能提出问题。可以产生这种反馈的典型互动是测试，正如我们讨论的那样，测试活动在开发阶段继续进行。基于这种反馈，我们可能需要对我们的解决方案设计进行一些更改，或者说服我们的客户实施业务流程变更。业务流程模型的审查和更新是一个持续的过程，应该在项目生命周期的整个过程中迭代，包括设计和开发阶段的审查和更新。

开始最终确定

很明显，Sure Step 倡导良好的项目生命周期规划，这在开发阶段计划的活动和交付成果中再次得到强调。我们已经看到，这个阶段不仅仅是为核心开发活动预留的。细心的读者也会发现，我们需要在开发阶段开始最终确定大部分的实施活动。这意味着到这个阶段结束时，我们已经交付了大部分的成果，这将使我们能够专注于部署阶段的纯部署活动。

完成系统配置和 ISV 解决方案的设置

在设计阶段，我们开始安装和配置标准功能和 ISV 功能，以满足客户的需求。现在，随着本阶段定制功能的可用，我们可以完成这一配置工作。这意味着我们还可以实施和配置定制功能，同时，正如前文所述，将测试提升到解决方案测试水平。解决方案测试不可避免地会导致配置更改，在此过程之后，我们可以冻结新解决方案的配置设置。

完成设计更新

由于已识别的问题、变更和更新的业务流程模型，我们必须更新适当的设计文档。

将非生产环境移交给客户

本任务的目的是将非生产环境移交给客户的基础设施团队，并确保他们准备好接受和支持这些环境。这将使我们能够与基础设施资源互动，并围绕新解决方案的基础设施主题积累他们的知识。

以下图表将完成我们对开发阶段的概述：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_22.jpg

在开发阶段结束时，我们可以勾选以下内容表示完成：

• 定制开发

• 解决方案测试

• 标准和 ISV 解决方案的配置和设置

• 设计文档

• 测试脚本创建

这将使我们能够专注于部署阶段的部署活动。多么五星级的项目生命周期规划！

部署阶段

有些人认为部署阶段是项目生命周期的尾声，而另一些人则认为他们仍需要在本阶段开始大多数实施活动，包括产品的配置和测试。那么他们到目前为止都做了些什么呢？部署是成功交付项目的关键过程。它涉及为整个公司准备将全新解决方案投入运营使用。这可是相当重要的事情！

让我们找出这一阶段的关键活动。

成功部署的关键是什么？

毫无疑问，基础设施和解决方案的准备工作是良好部署的基础，但它们只代表了“一半的路”。另一半，甚至更大的部分，是客户的组织准备。用户组织内部是否有支持这个新解决方案的联盟？关键用户组织能否看到并欣赏这个新解决方案的好处，并且能否平衡他们所经历的付出和困难？他们能否将现有的批评和抵制放在正确的角度？他们能否预见下一步和挑战？这些都是任何项目经理在过渡到部署阶段时必须反思的重要问题。对这些问题的回答将指导我们如何组织部署阶段以及在哪里放置重点。这必须是我们部署时的关注点。

变革的传教士——培训师

足够的培训是成功实施中最重要的步骤之一。使用户在日常工作中的效率大大提高是任何业务解决方案实施项目中都会发现的关键目标。仅为此原因，用户需要对产品有深入的了解和洞察。但有效的培训不仅会赋予用户如何在日常公司流程中使用该系统的必要知识，还会引导他们对新事物产生感知和信任。对于大多数用户来说，这可能就是他们第一次接触这个全新的解决方案，而且你只有一次机会留下良好的第一印象。出于所有这些良好的原因，我们需要计划充分的培训，并抵制将培训减少到最低水平以降低成本的诱惑。

进行最终用户培训

Sure Step 设想在部署期间对最终用户的培训是短期的、有针对性的会话，从广泛的概述开始，逐步缩小到最终用户定义的工作任务。培训场景必须是基于角色的，以便每个用户都能完成他们日常工作中所需的具体活动和任务。可能需要在每个会话开始时进行一次业务流程（待执行）培训，以确保所有最终用户都对新的流程有足够的了解。

一个关键的成功因素是，最终的任务导向培训应尽可能接近部署进行，以防止知识侵蚀。

组成培训团队

这项培训可以由客户的关键用户、培训师或咨询实施团队中的顾问，或者由外部第三方培训供应商进行。这很可能是混合的，因为找到一个能够完成所有工作的培训师并不容易。让关键用户参与他们部门培训的交付是一个明智的做法。关键用户对最终用户了解得更好，对业务流程有很强的知识，并且与产品紧密相连，得到了管理层的加强。因此，他们可以比任何外部培训师更好地传播新解决方案及其不可避免的变化。然而，我们需要确保他们具备适当的产品知识和一个组织良好的方法。

正因如此，我们需要在事先为他们提供培训师培训课程。我们解决方案的一些领域可能需要培训师的高级专业知识，因此，可能有必要从咨询或学习组织部署专门的培训师。

数据怎么办？

到目前为止，所有数据迁移的设计、开发和测试都已经完成。我们将需要数据迁移执行以进行培训、测试和部署。最终用户培训需要模拟真实用例场景的测试数据。用户验收测试也需要来自客户指定的一天实际交易，这将提供他们业务的良好样本。因此，对于这两项活动，我们需要迁移数据，从某种意义上说，这将为我们最终将数据迁移到支持部署的生产环境做好准备。

Sure Step 建议最终迁移分两步进行：

• 数据初始迁移到生产环境：数据初始迁移到生产环境是为了避免系统过载，通常在真正的上线前一周进行。这些数据通常包括静态数据。

• 最终数据迁移到生产环境：最终的数据迁移最好在上线前的周末进行。由于大部分初始数据是在上线前一周加载的，因此最终的数据加载将考虑在初始数据加载后输入系统的数据。这个概念加速了迁移过程，并消除了可能危及切换的最后时刻的故障。

上线作为用户验收测试

你可能不会相信，但在某些情况下，上线流程是在没有先前的用户验收测试的情况下启动的。最常见的借口是“我们告诉客户去测试，但他们没有做”。你甚至可能会发现，UAT（用户验收测试）被用来补偿前期阶段的时间和预算超负荷。在没有 UAT 的情况下，上线将充当用户验收测试，而那次上线的成果是可以高度预测的。

不要忘记 UAT（用户验收测试）实现的重要目标：

• 验证新解决方案是否支持公司通过需求过程所设想的公司运营流程

• 通过减轻失败风险来获得对系统的必要信心

• 在之前的测试周期中幸运逃脱的问题的最后一次识别机会

• 激励上线决策

• 获得系统验收

• 生成支持项目收尾过程的结果

你持续的关键用户互动现在将得到回报

我们通过前几个阶段的内容了解到，在所有实施阶段安排与关键用户的互动是多么重要。跨阶段流程以及在整个项目生命周期中的规划是 Sure Step 中的关键要素。当涉及到 UAT 时，我们将真正享受到这种策略的好处。我们的关键用户在整个项目生命周期中都与产品保持联系。他们通过参与、培训和指导每个阶段，逐步建立起对我们产品的知识和认识。在前期参与测试使他们理解了流程和测试的重要性。现在，他们真的准备好在组织和执行 UAT 中支持你了。

你能想象到在分析后几个月都处于脱节状态的关键用户吗？他们现在才得到一些培训？仅仅要求用户组织在一个他们几乎不了解的系统上执行 UAT，这并没有太多意义。

早期规划和承诺做出差异

UAT 对客户组织的资源规划构成了严重负担。客户的大量员工需要腾出时间进行培训和用户验收测试。尽管如此，这家公司仍在运营模式中，因此他们的缺席需要提前仔细规划！至关重要的是，客户真正承诺投资这项努力，因此他们也需要提前得到激励。没有早期规划和真正的承诺，我们将遇到麻烦，而“没时间，以后再说”的借口将响彻我们的耳畔。好消息是，我们在设计阶段就已经与客户合作制定了部署计划。至少我们按照 Sure Step 的方式做了！

用户验收测试的重点

UAT 必须专注于测试完整的端到端系统，以确保新解决方案满足客户业务需求。测试场景的重点是不同部门的用户日常操作，支持上线后的运营使用。我们不是逐个测试需求，而是基于真实数据测试现实生活中的业务流程。这些测试还必须证明用户能够正确使用系统。

记录和分析结果

测试结果需要被汇编、分析和随后与测试标准进行比较。Sure Step 提供了高效的 UAT 测试脚本工作表和模板。这些工具是针对产品特定的，甚至包括基于角色的版本。它们还可以包含一些预配置的测试场景。

下面的截图给出了一个产品特定 UAT 测试工作表的示例，包括产品特定的测试内容：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_23.jpg

执行性能测试

许多变量可以相互作用，影响系统性能。可能会有大量用户、大量交易、配置不当的基础设施或环境变量；还有许多其他元素也可能影响性能。我们需要在上线前后仔细审查性能。因此，在这个阶段安排性能测试并非奢侈。

基础设施准备就绪

在这个阶段，我们需要确保我们将在上线期间和之后在一个稳定且性能良好的环境中运行我们的新解决方案。这就是为什么我们需要在部署阶段继续我们的基础设施工作，通过构建和配置生产环境和灾难恢复环境。

下图列出了可以初始化的可能环境：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_24.jpg

检查和交叉检查

乘务员，请准备交叉检查。您熟悉这些话吗？交叉检查是在飞机从登机口推出前和飞机着陆时乘务员执行的一个程序。检查门是否已经装备了紧急逃生滑梯的程序只是确保飞机可以安全滑行、起飞和着陆的一系列检查之一。这确保了符合客户期望的安全和质量服务。

当我们准备上线时，我们也应该执行一些检查。延迟和崩溃也不会给我们的业务留下好印象。这就是为什么我们需要评估最终系统准备情况，并确保所有必要的步骤和可交付成果都已到位。Sure Step 上线检查清单可以是一个有价值的工具，帮助我们与客户协作完成该程序。

准备起飞

上线启动了在新系统中成功处理日常业务交易和活动。到达这个阶段花费了时间、努力、汗水、泪水、会议、电子邮件、互动，尤其是大量的辛勤和智慧的工作。这是客户组织和咨询团队的起飞；这是一个宝贵的时刻，但如果计划不当，也并非没有危险。就像任何一次出发一样，我们需要保持专注并准备应对一些潜在的动荡。为了使上线切换成功，我们需要规划和记录我们的切换程序。我们甚至可能需要将切换过程作为彩排来运行。Sure Step 提供的上线切换计划可以帮助我们这样做。重新使用部署计划，并添加一个关于切换过程的单独部分可能也很有价值。

一旦进入天空，就鼓掌并打开那些香槟吧，因为这确实是一项成就！与客户一起庆祝这个特殊的时刻不仅有趣，而且加强了双方团队的成功感。这是应得的，享受吧！

运营阶段

打包好行李了吗？其实并没有。上线广播了我们的项目，但我们的表演还没有结束。上线不是项目的终点。现在是时候提供一些在船上的服务了。

提供上线后支持

在上线切换时刻之后，最终用户组织将面临关键挑战。他们现在真的需要放弃他们旧的和熟悉的流程，适应新的程序和软件的功能和特性——这对他们来说不是一件容易的事情，他们需要我们的支持。想象一下有人走进你的办公室，给你一台全新的电脑，里面装满了不熟悉的程序。那会是什么感觉？仅仅知道有专家在那里解答他们的疑问和担忧，就是一个令人安慰的想法，并且可以避免任何恐慌的情况。优质的现场支持也将使我们能够向关键用户建议如何解决具体问题以及一般支持的角色。一个优秀的关键用户团队还将筛选各种支持请求。在上线后支持的长时段内，咨询组织也可以从现场支持切换到远程支持，通过实时会议、电话或电子邮件通讯使顾问可用。这一步骤需要有一个成熟的关键用户组织，能够控制大部分支持请求——这也是在整个项目生命周期中投入时间和精力的另一个好理由。

假设在这个阶段你将不再收集问题和变更，就像押错了马。新系统运行的前几天甚至几周会产生大量的问题和变更请求。这些应该按照之前阶段相同的方式进行管理。然而，我们需要意识到，大量的投诉、问题和变更请求可能是由对变化的抵抗、恐惧和其他挑战引起的。这就是为什么我们可能需要考虑额外的沟通和培训，以帮助客户度过变化的现实。

一些需要做的事情

在方法论中包含运营阶段的好处是，它使我们能够在项目开始之前和期间向客户传达一些重要的事情。它清楚地表明，我们将在上线后继续提供服务，因为我们还有一些事情要处理。

清除挂起的项目

其中之一就是解决开放的问题。这些问题可能在上线切换时刻之前就已经被识别，但直到上线后才得到处理。我们将在上线时刻始终存在一些问题，这不能成为推迟上线的理由，除非这些问题确实非常关键，被认为是障碍。在你到达那个点之前让客户意识到这一点是明智的，Sure Step 将帮助你做到这一点。

现在我们已经到达了需要在运营阶段执行某些事情的时刻。这项活动可以在 Sure Step 中找到，称为清除挂起的项目，这表明我们需要与客户合作，找到我们开放问题的最终解决方案。在大多数情况下，并非所有问题都会得到解决，因为一些问题对业务运营没有影响。这是沟通和谈判的努力，以确保双方都满意。“不要把你的常识放在外面”是信息。

完成知识转移

我们需要确保在我们离开之前，客户将能够访问所有重要的资源，使他们能够接管控制权。他们需要知道所有文档存放的位置，管理员需要能够获取安全权限文档，实际的支持信息和日志需要转交给客户支持团队，并且他们需要知道如何登录到CustomerSource（一个微软门户的名称）。

进行性能调整和优化

一旦我们的解决方案运行了几天，就是时候衡量性能并提供额外的调整和配置了。真正的性能瓶颈可能只有在上线后才会显现出来。在这个阶段主动进行这项工作比等到性能下降到不可接受的水平，用户开始抱怨解决方案的性能，更为明智。

将解决方案过渡到支持阶段

是时候说再见了。实施顾问不可能永远驻场，客户组织需要对其新解决方案负责。他们可以完全自行组织支持，或者使用合作伙伴的运营支持服务。

要结束还是不要结束

要结束！项目按定义是临时的，因此它们需要一个结束日期。正式的结束是项目管理的一个基本组成部分。如果没有结束，我们就会陷入一个我们没有组织并且没有足够预算的运营。最终，不结束我们的项目将蒸发掉我们辛勤工作所获得的全部利润。

结束——这是一项不错的小工作吗？

我们希望如此，但不幸的是，我们都知道得更清楚。结束是所有事情汇聚的地方，当我们说所有时，我们的意思是所有。我们的项目沟通有多好？我们的项目文化有多强大？我们交付了什么质量？我们实现了什么时间和成本绩效？我们的工作说明书（SOW）是否良好？此时我们与客户的关系状况如何？我们的项目管理是否有效？客户现在是否熟悉签字程序？

逐步构建

项目关闭是通过在整个项目生命周期中工作逐步构建的。通过关卡评审报告、重要可交付成果的签字、项目状态报告、指导委员会会议和正式测试结果来结束阶段，只会使你的论点更加强大。在尝试获得签字时，需要跨越一座大桥梁，这现在代表了自 SOW 批准以来的第一次签字尝试。作为项目经理，我们需要理解项目关闭是我们工作的一个基本任务，而且这不是免费的午餐。我们需要在整个过程中努力实现关闭。

核心挑战

结束的核心挑战是对可交付成果与 SOW 的审查。我们需要证明我们交付了我们承诺在 SOW 中交付的内容，而当可交付成果在 SOW 中未指定时，这可能是一项艰巨的工作。这再次强调了可交付成果思维相对于活动思维的重要性。充斥着活动的 SOW 将难以与所交付的内容进行比较，并打开长期而耗时的讨论之门。购买一辆可以驾驶的东西指的是哪种类型的汽车？很难说，对吧？

请签字！

是的，你需要有一个正式的验收，代表这个项目的结束。为了实现这一点，我们必须提前很好地沟通，并组织一个有固定议程的正式会议，理想情况下由项目经理、执行利益相关者和赞助商参加。有了正式的签字，我们的旅程就结束了。我们现在可以下飞机，庆祝我们的成功之旅。

敏捷实施项目类型

在上一节中，我们详细讨论了 Sure Step 中瀑布方法的选项。现在，我们将转向敏捷方法，正如我们之前提到的，它代表了一种迭代式解决方案开发方法，该方法促进了拥有和指定解决方案需求的资源与负责解决方案开发和部署的资源之间的协作过程。

敏捷项目类型是在 Sure Step 2010 版本中引入的，主要是为了方便那些期望将 Microsoft Dynamics 作为平台并定制解决方案以满足其特定需求的客户。在这样做的时候，这些客户往往在开发过程中逐步调整他们的需求，这需要一种灵活和迭代的开发方法，这正是敏捷项目类型理想适用的地方。

下一个截图显示了 Sure Step 中的敏捷项目类型。左侧的导航树视图和右侧的方法论面板描绘了敏捷项目类型的冲刺周期：

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_25.jpg

虽然 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 中提供的固定范围提案和工作说明书作为起始模板，并据此定制合作内容。

https://github.com/OpenDocCN/freelearn-csharp-zh/raw/master/docs/ms-dyn-sure-step-2012/img/7027EN_05_26.jpg

实施采用快速项目类型，包括解决方案设计、安装、配置和数据转换的具体活动。还包括一个会议室试点（CRP）活动，使用户能够预览即将推出的解决方案，并有机会审查解决方案配置，以确保其符合拟议的设计。

用例：全球广告组织使用企业项目类型

一家全球广告组织发现自己由于过时的财务管理应用程序而无法满足不断增长的客户对详细信息的需求。为了提高其财务报告能力，公司决定选择微软 Dynamics AX 作为一流的财务管理软件，因为它具有其全球组织所需的可扩展性和本地化能力（包括语言和法规）。

由于解决方案交付的规模，客户需要一个具有全球影响力、能够理解当地需求、语言和法律的实施合作伙伴。客户选择了微软服务及其微软全球解决方案印度（MGSI）团队，与他们的企业项目团队合作，以在多个地点开发和部署解决方案。

使用 Sure Step 企业项目类型和指南，团队共同努力收集解决方案的功能性需求并设计解决方案。客户对交付方法印象深刻，以至于他们的副总裁和公司财务总监评论说：

与我们合作实施项目的微软服务顾问对产品了如指掌。顾问使用的项目管理方法最小化了范围蔓延，这在大型系统实施中非常常见，使我们能够按时并在预算内完成。

到本文写作时，已有超过 30 个机构正在使用微软 Dynamics AX，还有更多部署正在进行中。该公司还运行一个内部托管的微软 Dynamics AX 解决方案，以支持其较小的机构。提供的实施方法为这次成功的交付奠定了基础。客户的全球项目经理补充说：

Sure Step 是一种经过深思熟虑且灵活的方法，使我们能够提出符合我们全球战略的统一计划和途径。它有助于部署的资源规划，提供每个部署的持续财务状况，并使我们能够设定对所需员工时间承诺的预期。

摘要

在本章中，我们重点介绍了 Sure Step 的项目生命周期规划，并讨论了瀑布和敏捷项目类型、跨阶段流程以及如何设置解决方案推出计划。我们了解到 Sure Step 确实有助于参与智能项目，因为它通过智能生命周期规划使我们能够主动、目标导向、高效且灵活。Sure Step 教导我们，在处理项目需求时需要灵活，而不是在所有项目中采用相同的方法，同时也要关注与客户利益相关者的持续互动。

作为快速参考，以下项目类型为您在解决方案交付方面提供了所需的灵活性：

• 快速项目类型是为微软 Dynamics 解决方案的即用型实施而设计的，标准解决方案的定制为零或最小。

• 确步标准项目类型适用于大多数微软 Dynamics 项目，通常用于中等规模的单站点实施，需要适度的定制和附加解决方案。

• 企业项目类型是为与复杂需求和解决方案场景进行大规模合作而设计的，这些场景需要深入的治理和监督。

• 敏捷项目类型代表了一种迭代式解决方案开发方法，它促进了解决方案的开发和推广过程中的协作过程。

• 确步还包括基于瀑布的升级项目类型，将在后面的章节中介绍。

在下一章中，我们将学习到由确步支持的必要质量保证和控制原则。下一章还将介绍优化方案。