B类产品的科学化设计与分析流程_供货引发的主、变、支流程-CSDN博客

转载：https://mp.weixin.qq.com/s/PsCXS6xgwkOSF7aBsMJ-YA

众所周知，企业级的2B（to Business）项目涉及到的业务复杂，模块繁多，那么此类项目要如何去系统地做产品设计与分析呢？

本文会把我在学习和工作中习得的2B类项目的产品分析流程分享给大家，希望能给大家带来一些启发。

序：由业务驱动的需求思想

在面对2B类型的项目中，核心是要具备业务驱动需求的思想，能准确识别出客户/用户的问题级需求。

有时，企业级的利益相关者提出的一些所谓“需求”都是一些方案级别的，比如：“帮我们做一个平面图的展示功能”、“协助制作一个详细数据的报表”、“这个界面增加一个查询工具”等等，这些都是客户/用户提出的方案，有时照客户/用户的意思做出来也未必能够解决他们的实际问题。

而问题级需求则是站在客户/用户的角度展开的。要通过客户/用户访谈，澄清方案级需求背后的问题本质，深入了解此问题是在什么使用背景下发生的，并在这些的基础上，提出准确的解决方案。

比如上述“帮我们做一个平面图的展示功能”的需求，其本质可能是客户/用户在某些特殊情况下才遇到的问题，通过了解该问题，可能只需提供一个查询分组功能就能轻松解决。

一、项目目标分析

项目目标是2B类项目的灵魂，是对于各干系人价值的一种体现，只有前期明确了解项目的目标/愿景，项目才能走在正确的道路上。

1.1 问题访谈

通过与各利益相关者/干系人访谈，了解他们对项目的预期和现状之间的差异，就可以定义出项目要解决的“问题”。

在该阶段，通常会有两种情况：外部触发的和内部提出的。

1.1.1 外部触发

此类是项目项目的发起人因为受到外部的一些因素而提出的一个项目，此时通常只是有一个宏观的大方向，但具体的要解决的问题不够清晰。

对于此类项目，我们要明确识别产生该项目的触因，并且选择出相应的策略。

比如，老板去参加了一个研讨会，会议上看到了其他企业做到的成果，回来会要求我们做一套达到国内领先水平的某某系统。

这种情况是典型的外部触发——参考观察引起的项目目标，此时我们应该尽量还原领导观察的内容，让老板分享会议的收获给我们，使问题场景化，以便理解他的目标。

上述是通过参考观察其他项目产生的需求，有时还会遇到竞争对手的新动向引出的项目升级。比如，企业高层看到了竞争对手的项目有了某某功能，也会要求自家的项目做同样的功能等。

此时，可能并没有梳理出清晰、完整的思路。我们要做的就是帮助他们提供一份竞品分析，通过竞品分析使其找到此次项目改进的要点。

1.1.2 内部提出

有时项目的起源是企业内部的发起人，其考虑到了目标与现状的差异。针对此种情况，最有效的方式就是访谈，还原表象、分析原因、共商决策。

1.2 定义问题

通过上一步的有效访谈，接下来就要清晰的定义要解决的问题。

有效的描述一个问题，要从其业务态、客观性和匹配性去把握。从业务的角度去阐述问题，而不是系统的角度，让读者可以从实际业务角度更好的理解问题。

同时描述问题时避免主观因素，要尽量从客观的角度出发，不评判、不推断，只阐述问题本身。匹配性则指的是问题的阐述要与读者（高层）的关注视角相匹配，比如经营方向、管理模式和业务模式等方面。

比如：

业务态描述：“当前借助系统生成的数据报表，存在业务相关数据不一致的现象。”

客观性描述：“当前操作流程下，不按找流程操作的现象时有发生，如未按时间规定上传报表、未接到上层数据就产出报表等。”

1.3 分析问题并确定解决方案

当我们清晰地定义了问题，就可以对问题原因进行分析，然后制定相应的解决方案。此时制定的解决方案是一个概括级的，并不是要展示出解决方案的细节。

在此阶段，要一句话阐述出解决方案，一般会采用“措施+效果”的结构。比如：“基于XXX问题，为企业增加XXXX系统。”

了解了项目的目标/愿景，我们大体知道了要做一个什么项目，接下来就要去明确都有哪些人去用这个项目——干系人。

二、各类干系人角色的分析

对于大多数2B类项目/项目而言，都会涉及到各种干系人角色，他们会有不同的需求点、关注点，因此识别与分析各干系人要素是十分重要的。

2.1 各干系人的识别

要分析各干系人角色的需求，首先要准确识别出各干系人。我们首先要收集企业的组织架构，根据项目的目标把所有涉及的部门都标识出来，每个部门及各分支机构的的负责人就是主要的干系人，有时企业的副职负责人也会是相关干系人。

另外，涉及到项目风险的角色，也会是项目的相关干系人，比如：项目对一类客户/用户产生负面的影响，此类客户/用户也是干系人。

2.2 各干系人的分析

识别出了项目设计的各干系人，接下来就要分析出他们对于项目的需求点和关注点。

我们首先要选择出各干系人，如果一类干系人有很多位，就要选择出一个干系人代表，我们要确切的了解他的职业角色和工作联系信息，做到对每一类干系人都了若指掌。

在这里，分析干系人最常用的方式还是访谈。根据干系人的具体工作主题分解、工作阶段分解去了解其在项目中的需求点与关注点，明确他们在项目中的位置。

我们可以从两个角度出发：

一是他们希望项目解决什么问题、提供什么业务支持；

二是他们希望避免出现什么样的负面影响。这样就能完成比较立体的干系人分析。

现在，我们也明确了各干系人通过项目可以完成哪些工作了，接下来我们就要去拆分一下这个大项目了——业务模块分解。

三、业务模块的分解

2B类的项目有时很复杂，会涉及到不同的业务，为了控制其分析的复杂度，我们通常会先将其分解成更小的部分，在这里推荐根据业务来进行划分。

通常采用的策略如下：

3.1 按业务职能分解

对于管理业务的项目，最典型的业务子模块划分就是按照业务职能进行的。

在划分之前，可以先绘制出与其相关的组织架构图，然后根据组织/部门之间的关系，划分出各个业务子模块即可，部门职能最典型的是产（生产/产出）、销（销售）、供（供给/供应）、管（管理）四部分。

如下图体检中心的项目系统划分：

3.2 按项目、服务分解

此时可以梳理出业务结构树，然后以不同的项目/服务作为划分的线索。比如，项目中涉及到不同的审批类型，而此时不同的干系人需要在不同的类型中扮演不同的角色，此时就应按照项目/服务进行划分“资金审批”“物资审批”“行政类审批”等。

3.3 双维度分解

对于一些更加复杂的系统，有可能需要采用上述双维度进行划分，先用其中一个维度做一级划分，再用另一个维度做二级划分。

比如，对于一个医院系统，可以先通过项目/服务划分，将其划分成门诊、住院、体检等子模块，再在各子模块中利用职能分解对其进行二次划分。

通过对项目的分解，我们有效的将项目划分成了一个个小的模块。

接下来，就要整理出各业务模块之间的业务关系和服务关系，可考虑的维度如下：

本子模块需要其他模块提供什么服务？
本子模块能够为其他模块提供什么服务？
这些服务由谁负责提供？
这些接口哪些是现有的？哪些需要开发/修改？

好了，已经得到了不同的业务子模块，接下来就要对各个模块进行业务流程的分析了——业务流程的分析。

四、业务流程的分析

4.1 识别出相关的业务流程

2B项目的核心价值之一就是支持业务，而业务支持的核心是对业务流程的设计、固化、优化和重构。

所以，识别出项目的相关业务流程是很关键的。

4.1.1 什么是业务流程

业务流程是项目的核心，任何一款项目都有自己的业务流程（不管2B还是2C）。

在2B类的项目中，业务流程尤为重要。

业务流程通常是一个多人协作的过程，而且需要一定的有效规则进行控制，才能达到预期的效果。

如何才能有效识别出项目中的业务流程呢？企业或组织的核心价值在于响应外部客户/用户的服务请求，通过一系列的协作满足其服务请求，为客户/用户带来价值，同时为企业/项目带来价值。

也就是说：业务流程的起点就是这些外部服务的请求。企业中每个成员的工作都是属于某个流程的，而且会是多个流程。我们应该寻找其源头，即服务请求，这样也就识别出了业务流程。

寻找到源头只是起步，因为业务流程是要有一个合适的结束点的。这个结束点体现在服务请求从提出到满足的全过程，也就是要判断这个服务请求是否被满足或被拒绝。同时，也要考虑业务流程的边界，不要跨越到未涉及的业务域或者是系统未关注的部分。

4.1.2 如何识别出业务流程

在实践中，我们需要对各个业务子模块逐一进行业务流程的识别。我们可以按照一定的顺序去操作，一般会通过先外部（外部客户/用户请求）后内部（内部员工请求）的顺序进行，具体步骤如下：

（1）识别出外部引发的主、变、支流程

先识别出由外部客户/用户的服务请求，大部分业务流程会来自外部。

在此阶段，要明确子模块有哪些外部的客户/用户以及其他部门的员工会发起服务请求。

在此基础上，识别出主业务流程：主服务请求；主服务请求的变体流程：变体业务流程；支撑业务流程：更好服务客户/用户的辅助支持业务。

比如一个酒店住宿系统，主业务流程就是“办理住宿流程”，变体业务流程是“换房流程、续费流程”，支撑业务流程是“投诉流程、房内消费流程、行李寄存流程等”。

（2）识别出内部引发的主、变、支流程

有些服务请求是由内部员工发起的，如审批流程，还有的会在特定时间、特定状态下发起的，因此内部请求要作为补充。

在此阶段，要明确有哪些内部员工会发起流程，以及有哪些特定时间或状态下会引发的流程。将员工最核心的业务请求识别为主业务流程，将业务诉求的变体识别为变体业务流程，将辅助支持业务识别为支撑业务流程。

（3）识别管理流程

有一些业务流程是为了实现控制、监督和管理，要单独识别。

管理流程的识别通常会是一个难点，比较好的方式就是通过与客户/用户沟通交流获得。在此阶段，要注意几个维度的思考：是否需要业务的审批控制流程；是否需要人、财、资源的管控流程；进度及异常的控制。

（4）判断业务流程优先级

对业务流程做优先级判断，有利于做出合适的迭代计划。

业务流程是系统项目交付的最小单元，只有实现了完整的业务流程支持，对客户/用户来说才是有增量价值的。在识别完所有的业务流程之后，应对其进行优先级判断以支持项目迭代。

这里推荐从是否为主营业务与发生频率高度两个维度进行分析：

4.2 业务流程的分析

在识别出业务流程之后，就要对每一个业务流程进行分析，绘制业务流程图。

在分析之前，需要掌握两个关于业务流程的关键点:

4.2.1 业务流程是分级的

组织级流程：展现各部门间的协作，以部门为泳道/职能带区，读者对象一般是管理视野。
部门级流程：展现岗位间的协作，以具体岗位为泳道/职能带区，与部门协作无关。
个人级流程：定义岗位的操作规程，通常没有泳道，尽量细化具体流程。
子流程：个人级流程如果过于复杂，可继续拆分子流程。

层级关系：组织级流程>部门级流程>个人级流程>子流程。

4.2.2 业务流程的八要素

五个基本要素（分工，活动，协作，产物关系，分支）

分工（各部门、岗位间的分工）是流程中极其重要的要素，当一个流程中有了分工，就必然会将前一个人负责的事拆成一系列更小的、相对独立的工作任务，这就是“活动”。

当我们分析分析一个业务流程时，首先要明确出整个流程中涉及哪些分工、每个角色负责执行什么活动，然后选择合适的流程图将其表示出来。当然，这些活动之间不是相互独立的，它们之间存在顺序执行、并行执行以及异常执行多种可能，这就是“协作关系”，在流程图中就是各个活动之间的连线。

而且协作过程不是一成不变的，还需要根据实际情况进行处理，这就是流程中的“分支”。这也是流程图中的一个重要因素。

最后，在协作过程中，各分工之间需要传递工作产物（数据），管理者可能会制定一些表单、数据表，这就是“产物关系”。在流程图中通常是数据流或文档等形式。

三个管理要素（审核、规则、异常）

审核通常对应着审批流程，在分析流程时，应识别出审批内容和审批意图，这样才能分析到位，并且在命名时不要采用“岗位名称+审批”的格式。

比如经理审批，科长审批，这样实在是太含糊不清，应该采用“审批意图/内容+审批”的格式命名，比如设备选型合理性审批、预算审批、采购渠道审批等，这种命名可以有效的将审批意图展示清晰。

规则则是流程中涉及到的一些限制性的事务。比如在某种前提下，才能进行某某操作；库存数小于10时，不能再接受订单等。

异常比较好理解，在流程执行过程中总有可能出现一些意外，事先要针对其制定一些备案措施。在流程图中可以附加文字进行说明，如果处理过程复杂，可以另外增加异常流程的流程图。

4.2.3 业务流程的分析步骤

（1）选择流程图的描述方式

如果我们分析的是业务流程图，大部分时候我们需要强调的不仅是分工，还包括每个角色所要执行的活动，因此应该选择泳道图/活动图：

如果涉及到的是系统之间的业务流程，如“银行转账”等，这时通常需要强调的是系统之间的交互过程，此时最好采用UML时序图：

（2）勾勒流程主体。厘清业务流程中的分工、活动、协作、分支、产物关系五要素，搭出流程的主体框架。

在这一步要注意：分工应平级。要么全是岗位名称，要么就全是部门名称，不要混着使用。

并且，应该绘制出业务全过程，不要考虑系统的边界，以免在后续的分析中遗漏。

最后，业务流程要从服务请求者开始画，谁发起的服务请求就从这里开始画起，保证流程的完整性。

（3）补充管控点。厘清业务流程中的异常、审批、规则。

首先，要和干系人代表就“异常”进行交流。重点的思考方向是“是否存在完全不能够按这个业务流程执行的情况？如果存在，应该如何处理？”可以用文字或异常流程图进行说明。

其次，要把重点放到“审批”上，可以询问相关干系人“现在有哪些审批点？还有哪些环节存在执行风险？需要增加怎样的审批流程？由谁进行审批？”等问题。

最后，再沿着流程，思考一下是否需要设置规则。

可以从下面几个角度着手思考：

协作间规则：用于控制流程协作的规则，比如“仓库管理员应该在每月5号前向采购部门上报采购申请订单”；
业务活动执行规则：在执行各个业务步骤时需要遵循的规则，比如“只对有审批盖章的文件进行处理”；
数据规则：针对表单、文档等生成产物的格式、内容进行限制的规则，比如“金额取小数后两位”。

（4）分析流程执行过程中的监控需求。从高层管理者的角度，对流程进度、异常等方面的管控、识别，补充一些辅助的相关需求。

在这一步骤中，我们要通过管理者获得相应的管理需求，可以在进度与效率、执行异常和其他管控三个维度进行收集。

（5）检查、优化流程。

在完成了业务流程的分析、绘制后，我们要回过头来，重新跑一遍各个业务流程，看一下是否有可以进行优化的地方。优化的策略如下：

清除无效（删除）。找到流程中浪费的、低效的环节，想办法清除。
简化高频（简化）。对于使用频率最高的流程进行优化，提升流程效率。
整合依赖（组织）。将相互依赖度高的环节整合到一起，提高效率。
自动化（转移）。将人做起来麻烦的事让机器去做，提示使用效率。

现在，各业务流程已经分析出来了，接下来就要识别出这些流程中存在哪些和项目/产品相关的业务场景了——业务场景分析。

五、业务场景的分析

用例、用户故事是我们耳熟能详的需求分析技术。它们的精髓在于“用户视角、业务场景/使用场景”。要求我们不再关注系统提供什么功能，而是用户在什么场景下需要项目/产品提供支持。

5.1 业务场景的识别

有了对业务流程的分析，识别项目/产品所支持的业务场景将变得很简单，只要基于流程图来识别出角色、场景，然后补充一些时间、状态触发的场景，最后将其呈现出来即可。

1. 基于流程图识别角色

明确以下维度：

要对这个流程提供支撑，至少要涉及到哪些用户？
对于项目/产品而言，这些用户扮演的是什么角色？
从权限角度如何抽象出这些角色？

2. 基于流程图识别业务场景

沿着流程过程，对每个活动、分支、判断点进行分析和思考：哪些业务活动要系统支持、哪些是不分支持，审批点是否属于系统内，判断点是否为独立环节。

3. 补充业务场景

除了由人触发的业务场景之外，还存在特定时间、特定状态触发的业务场景，它们有可能没有在流程图中体现出来。因此在完成前两步之后，还需要花费时间补充出这类易于遗漏的业务场景。

4. 绘制用例图并概述业务场景

当所有业务场景都识别出来后，我们可以使用用户图来呈现结果，并对涉及的业务场景做一些说明。用例图中最为核心的就是actor（参与者）与用例。

我想强调一下用例的概念：用例即业务场景（用户的使用场景），一个完整的业务场景应该是独立的、可汇报的、可暂停的单元。

用例图的表示方式如下：

5.2 业务场景的分析

5.2.1 概述业务场景

（1）该业务场景中，用户要实现什么样的业务目的？

用一句话概述用户执行该业务场景所要完成的业务目的是什么。要使用用户语言，重在传达用户的意图。

（2）执行该场景有什么前提条件？结束前需要保证何种状态？

对于一个业务场景而言，有时是需要执行条件的，有时则是在业务场景执行完成之前必须确保满足某个状态。分别称之为前置条件和后置条件。

前置条件是用户在执行该业务场景之前，系统/产品需要检查什么状态。例如用户在操作查阅合同报表之前，必须已经上传该合同信息。

后置条件是用户在结束该业务场景之前，系统/产品需要检查以确保什么状态。例如，在电商网站下单的业务场景，其后置条件是要检查下单数量要小于库存数量。

（3）除了场景的执行者之外，还有谁关心它？关心什么内容？

在一个业务场景中，除了执行它的用户之外，还可能涉及上游、下游、管理者、协作者等其他关心该场景的其他角色。对于一些关键的业务场景，还有必要思考他们有什么关注点，是否需要提供一些功能来满足这些需求等。

5.2.2 细化业务场景的业务步骤

细化业务场景的业务步骤时，可以通过访谈干系人代表、观察他们的工作、或者直接收集他们的操作规程作为输入。

在执行该过程中，可以思考三个维度：最典型的、用户预期内的业务步骤时怎样的；针对各个步骤，有哪些潜在的变化情况；针对各个步骤，有误异常的情况，异常如何处理。

5.2.3 重复步骤分析困难，导出功能

我们要针对每一步骤与客户/用户了解存在的困难、挑战，然后构思系统的解决方案。在这个步骤中，一般从两个角度来思考：

首先是执行这些步骤时会遇到什么困难，也就是思考“在这个业务步骤、变化及异常情况下会遇到何困难？针对这些困难，系统/产品需要提供什么样的功能支持”两个问题。

其次，分析是否存在一些关键的例外，会带来执行的麻烦，也就是思考“是否存在不能按以上步骤处理的情况？这种情况需要系统/产品提供什么样的功能支持？”

5.2.4 识别环境与规则

在分析一个业务场景时，还应该考虑环境、业务特点给系统/产品实现带来的要求和影响。

通常可以通过以下几个维度进行：

性能相关：主要包括执行该业务场景的人数、典型的业务量、峰值情况的业务量、密度。
易用性相关：主要是用户相关系统的使用经验，这对于系统易用性设计有着指向性的作用。
部署环境相关：说明用户所在的网络、软硬件等相关环境。

5.2.5 分析实现方式，完成初步的交互设计

此时的交互设计不是详细的交互设计，是初步的交互设计，通常包括以下几方面的内容：

交互过程：界面的跳转图，用来表达我们希望系统/产品如何实现该场景的所有业务步骤。
静态快照：即每个页面上的具体内容，通常可以使用纸面原型表达。
设计说明：针对于每个页面内容、界面跳转做一些描述，核心在于说明为什么这样考虑，以及这是一种建议还是必须如此。

截至当前，我们已经完成了业务流程与业务场景的分析，接下来，我们要为以后考虑，通过数据分析可以优化我们的系统/项目，这就要引出接下来的要点——数据指标的识别预分析。

六、数据指标的识别与分析

2B类项目重要的价值之一就是要支持管理，而支持管理的核心就是通过数据指标分析管理系统/产品，和通过数据分析完成后续的项目迭代。

准确的识别与分析出数据指标，能帮助我们很好的实现支持管理。

识别与分析出数据指标的核心在于：把握用户想要得到什么信息，明确他的管理意图是什么。

6.1 标识管理者

在这一步骤中，应该首先在子系统模块寻找到相关的决策层（高管）、管理层用户，然后在流程层级寻找相关的管理层用户，最后应该在整个系统层级寻找相关的决策层用户。

找到了整个系统所涉及的管理者之后，还应该继续判断他是属于哪种类型，比如管理型还是经营型，不同类型的管理者所关注的重点也是不一样的。企业级2B项目中涉及到的管理者通常有六级：

管理自我型：这一级别准确地说应该是员工，作为一个员工，也应该做好个人的一些管理，比如时间管理、计划管理等。
管理团队型：通常负责带领一支小团队完成上级交给的任务，比如组长、队长等都是此类管理者。他们关注团队管理、人员管理。
管理事务型：项目经理就是典型的这一类管理层。他们将对一件事负责，人、进度、资源都会涉及到。
管理职能型：此类管理层关注于多事务，也会关注人、进度和资源。
管理业务型：他们将涉及经营性指标，更加关注客户、产品、供应商等经营性主题，对具体的执行性事务关注较少。
管理事业群型：他们将管理多业务，一般对于资本、均衡等方面更加重视，想法会更宏观，通常他们关注的都是决策相关的内容。

6.2 识别管理意图

标识出所有的相关管理者之后，接下来可以通过访谈，侧面了解其职位职责及考核指标，标识出其希望通过项目/产品来实现的管理意图。

如果是管理型的管理者，建议从管理问题着手，比如事务管理、人员管理、财务管理等方面；如果是经营型管理者，则可以从经营性问题着手，比如客户、产品、供应商等方面。

6.3 分析所需指标

分析数据指标时，可以从正反两面进行。正面就是要思考分析业务设置合理性需要哪些数据信息，反面就是思考如果业务设置不合理会出现哪些情况，这些情况又可以通过哪些数据反映出来。

比如，业务设置合理性分析就是要看业务的受欢迎程度，比如业务量、利润等数据，再确定可以通过什么样的形式去展现这些数据。而业务设置不合理性的分析，就是分析出在项目服务中有哪些反面的指标，比如排队时间等。

数据指标是介于管理意图和数据报表之间的断层，分析出具体数据指标可以有效的连接这个断层。另外，管理意图和数据指标之间是多对多的，一种意图可以对应出不同的数据指标，同时，一个数据指标也可以反馈出不同的管理意图。

6.4 确定实现方式与数据内容

最后就要分析出数据指标展现的实现方式，即分析出数据源是否固定、查询条件是否固定、数据库查询出该指标是否复杂等。

在确定数据内容时需要明确以下几点：

生成数据所需的输入条件：可以是界面呈现，也可以是基于查询条件。
数据来源：明确该数据是由哪些数据表中获得的基础数据，说明要对哪些数据进行统计。
数据报表中数据的格式与计算方法：逐一列举出每个数据项的格式及计算方法。

至此，一个企业级2B项目的分析与设计的流程就差不多了，但是还没有完，接下来要明确在项目投入使用之后，涉及到的维护性需求——维护性需求分析。

七、维护性需求分析

在维护性需求阶段，要抛开功能性思考，识别出有哪些维护性场景，以及维护场景需要提供什么支持。

7.1 标识配置性维护场景

对于企业级2B项目，第一种典型的维护场景就是各种配置，用来应对变化带来的影响。

那么，标识配置性维护场景应该从变化入手。

系统通常会遇到以下几方面的变化：

用户群变化：使用项目/产品的用户发生改变，比如他们的职位发生改变，他们的权限发生改变等。因此，要想维护用户、维护角色、维护权限，就需要一些相应的配置功能。比如，功能权限、数据范围权限、分配权限的权限。
流程变化：企业流程会根据自身发展过程中关注点的改变而不断进行调整，以满足阶段性的管理目标。因此，如何应对流程的变化带来的影响，是需要提前考虑的。
数据变化：随着企业业务的壮大，会需要在项目/产品中引入更多的数据项或更多的数据细节。因此，应该提前考虑如何应对未来增加的数据或数据构成的调整与变化。
法规变化：企业在经营过程中，有时会涉及法律法规的要求，而法律法规会在一定的时间周期内变更或出台新的条例。因此也需要考虑当法规变化时，如何有效应对。

因此，在该阶段，应该列举出项目/产品生命周期中可预见的变化，通过配置功能提前应对。

7.2 标识项目运行阶段的维护场景

项目在运行过程中，要确保其安全、可靠、稳定的运行。此方面，可以从正常和故障两方面进行分析。

正常时：系统正常运行时，要对运行状态进行监控，通过服务、网络通信、数据库等方面进行运维。

故障时：在系统出现故障时，需要及时有故障排查、故障修复等措施的支持。

7.3 其他维护场景

除了上述的维护之外，还包括以下其他维护场景：