规则和升级

        一旦你定义了“当前”和“将来”流程，就应该将已定义的自动化用文档记录下来，并作为流程分析的一部分。此时，文档可以着眼于一个相对较高的层面，但需要记录下自动化的每个重要的特征。

        根据所选择的CRM应用程序，你可使不同类型的代码或CRM功能来实施特定的自动化功能。

        用例定义

        许多企业都选择围绕着一系列的用例展开设计流程。用例是以一种分步的方法，描述用户和应用程序之间为实现某些任务而进行的交互。定义用例可以使你的团队有机会就应用程序要处理的用户场景和流程达成一致。即使是一些简单的实施，也需要使用许多用例概述用户的任务和流程。较大的新型应用程序实施则可能需要很多个用例。用例和它们所描述的内容不应该与应用程序功能相混淆，因为它们之间差别很大。用例定义主要提供下列两方面的帮助。

        流程的一致性：用例的开发和完善，并进行详细的流程讨论和确保各方人员在步骤、参与者和流程的基本原理方面达成一致，提供了便捷的框架。在设计流程的早期，达成这种一致性可以使后续工作更顺利，并且在设计流程和后期偶尔出现流程不一致的情况时，可以帮助防止对此感到措手不及的情况。

        完全测试：在设计阶段开发用例将有助于确保在部署的测试阶段执行完全测试。端到端系统测试通常是基于已创建的内容来进行，而不是基于批准的设计（或计划要创建的内容），这是一个重要的区别。用例的设计将为实施的后期阶段开发测试计划，提供一系列基准信息。

        以下是用例文档中每部分所含信息的概要。

        业务需求：为用例所描述的业务流程提供高级概述或标题。

        描述：利用描述字段记录特定用例所描述的业务流程的详细说明。如果你能够提供用例的前期和后期视图，就能够利用这些信息评估实施工作的最终成功度。

        作者：编写用例的人。

        问题：当编写用例时，你可能会发现一些将影响系统实现方式的问题。而且，如果你能够在项目团队审查这个用例时发现并总结出一些问题，你就可以在这里对它们进行跟踪。

        假定：如果你对正在被处理或用户（通常在用例中称为参与者）参与的业务流程做出假定的话，可以在这里用文档记录此类信息。用文档把假定认真地记录下来是用例成功的关键。用例通常会被转化为用户测试计划，因此，用文档记录得出用例的假定，或作为用例的一部分出现的流程步骤，将更容易生成测试计划并进行更有效的测试。

前置条件：在用例中确定的流程被“允许”运行之前，前置条件可以使你对必然发生的事情进行定义，如某种类型的审批。

        触发条件：触发条件一栏可用于记录触发用例中所识别步骤的用户操作的用户操作或流程操作。以某学生报告参加大学课程为例，学期的开始和新课程的开课等都是完成报名过程的触发条件。

        成功的结束条件：模板的这个部分可以用于记录表示成功完成用例的标准。例如，同样以某学生报名为例，成功的结束条件是这个学生被允许使用我们设计的任一应用程序，成功地完成报名。

        失败的结束条件：模板的这部分可以用于记录表示用例失败的标准。例如，如果前面提到的学生不被允许或无法利用应用程序报名参加课程，这就可以被记录为一项失败的结束条件。

        备注：用例文档的备注部分可以用于跟踪所有其他不适合放在上述文档部分的信息。

        如果能够提供明确的步骤、这些步骤发生的位置，以及用户与应用程序如何交互的一个可视化示例，他们就能够对应用程序进行完全测试。