在大多数情况下，表示一个组织、公司或个人所从事的商业活动、服务或工作，有相应的流程和规则。可以理解为达成某种目的（如盈利、增长、满足客户需求等）所进行的各种活动，涉及到如何创建价值、满足需求和实现目标。
支付业务从等价物交换，到货币支付，再进入电子支付，从单纯银行卡收单走向第三方支付平台。而第三方支付所研究的问题从起初的面向商业场景的收单，走向面向用户的电子钱包到面向企业及行业的资金运用效率的问题。
如果说央行支付清算体系是社会经济的大动脉，那么第三方支付就是连通全社会的分支血管和毛细血管。
支付产品服务的用户和目标组织，包含支付网络中连接到的个人、企业、商家和其他组织机构。
比如，线下或线上的各类商家、各行业的服务提供商、甚至政府机构，也比如小商户，或需要收付款的任何个体等。他们因在支付服务中获得价值而使用并提出各类需求。
产品是对解决方案的包装，支撑起解决方案的实现即系统（业务系统）。如：
公司向市场提供的每种产品都是执行各类活动的结果。而信息系统在业务流程管理中应发挥重要作用，因为公司执行的越来越多的活动都得到信息系统的支持。业务流程中的活动可以由公司员工手动或借助信息系统来执行。
还有一些业务流程活动可以由信息系统自动执行，无需任何人工参与。只有人与其他企业资源（例如信息系统）良好地协同工作，企业或组织才能高效、有效地实现其业务目标。
业务流程是促进这种有效协作的重要概念。在非科技行业的各类公司中，组织的业务方面与现有信息技术之间存在差距。缩小组织和技术之间的差距非常重要，因为在当今充满活力和竞争的市场中，公司必须得向客户提供更好的产品/服务才能生存。
而信息系统让公司和组织，甚至行业得以大幅提效。这里的信息系统，即面向业务改进所建设的软件系统，即业务开发所交付的“业务系统”。
再以支付为例，其业务边界和业务形态的演变，得力于信息系统逐步对业务流程不断改进（如信息流/资金流）。
其所形成的支付系统的形成过程，正是通过对支付业务的问题域不断研究的结果，通过流程改造、自动化和信息化替代人工流程，将支付解决方案不断提效、拓展、升级的过程。
只有当我们了解做出这些决策的背景时，我们才能确保信息系统以这种方式支持业务决策。业务开发，冠以“业务”前缀，要的是在技术通识的基础上，更要熟悉业务。是另一个维度的全栈（业务+技术）能力。业务开发团队，要承接并交付出“好”的业务系统，挑战在两点：
这也是大多数团队所面临的挑战：
洞察痛点：本质在于理解业务，能够定义边界/聚焦重点
动态进化：本质依托于业务系统的设计和实现
业务上“知其然知其所以然”，将有能力优化业务流程，准确评估需求甚至发现需求，甚至建立预判能力，为业务系统构建灵活运营能力，更好的提升产品市场地位。业务开发的挑战，这里探讨两点：1-理解业务，2-融入业务视角来设计/构建系统。
注：本篇先探讨第一部分。第二部分在下一篇继续。
理解业务，需要以全面透彻的视角看业务，了解涉众诉求、利益关系以及价值链。作为业务开发，读/写代码、转换用户视角使用产品功能外，要从行业发展过程和法规管控原因去理解业务。对于技术要承载的业务，要跳出单一代码视角，从两种视角拆开看：
区分这两部分的意义在于：提问题比解决问题更重要。提对问题，才能找对方向，给出多种方案，才能控制风险防止南辕北辙。
反之，轻则只理解表面上的交互流程，导致面向UI开发（例如，将领域逻辑和业务规则直接写到UI层或者写成TransactionScript，导致实则是应该被领域对象管控的业务规则被分散到各处而失去维护性）；重则方向性错误，前功尽弃。
动手之前，通过面向业务提好的问题，能帮助我们发现业务本质、覆盖全局且不留死角。初识业务，或者成熟业务上扩展出新需求，需要主动思考：
在探讨上述问题之后，还可进一步应用熟悉业务，比如：
需求不仅仅是TAPD上的表面的交互或说明，其本质是要基于业务背景为用户创造价值。功能需求是用户价值点，而非功能需求则为产品放大竞争力（对应的质量属性，如用户体验、性能、兼容性，安全性等）。
对于纯互联网C端产品，多以工具型产品为主，本身构建于数字化基础体系之上，且问题域的涉众相对角色少（开发者自身就是核心用户）。
其需求更多以点状出现，然后通过MVP和原型化的方法在过程中进行快速试错进行验证和提炼，这样的需求多会以交互/用户故事轻量化的管理和呈现。
但在B端或面向行业，其业务流程长且内禀逻辑复杂，业务场景下参与的角色众多，而且领域专家和解决方案团队大多并未重合，开发者需要跨领域学习业务知识，比如金融/证券/保险的业务，又或者是零售/消费电子制造等行业都有自身行话术语，以及产品内的特定业务流程和业务规则。
这种场景下，对于业务系统的建设团队的挑战有：
相信大型、跨多团队协作建设和运营的长生命周期业务系统会有同感。对于支付业务，在为不同行业的企业/商家提供有竞争力的在支付/资金解决方案过程中，更感受到透过产品表面形态穿透业务本身的意义和价值。
此处的不断实践，我们将上述挑战的解决方案落脚于业务建模方法上。来一起看看：业务建模。
几乎所有的创作者都会用模型来表达。当我们想要建造汽车桥梁和建筑物时，我们会先制作模型。当我们想要制作和定义电气设备时，我们会绘制电路图。我们用公式来理解物理、化学和数学。
几乎在每一个学科中，我们很自然的使用模型的表达方式来澄清我们在做什么。模型为我们阐明了某事物或某事件的某些方面或某些观点。为了实现这样的通用目的，模型主要分为静态和动态两种：静态模型呈现结构，动态模型呈现事件流。
广义的业务模型（BusinessModel），用以明确目标组织（公司/组织）的功能，显示其所处的环境以及在环境中的行为方式。此处的环境是公司为执行其业务流程与之交互的所有事物，如客户、合作伙伴、供应商等。业务模型能用于系统的管理公司的发展，帮助降低风险增加成功概率。
如：组织架构定义、业务活动的参与角色和执行流程等。这里打住，回到我们的业务开发语境下的业务建模，是面向业务交付信息系统的目标下所探讨的内容。
因此，我们探讨的业务建模（BusinessModeling）是指通过对目标用户/组织的业务需求、流程和规则进行分析和描述，并以抽象模型呈现出来，从而为软件系统的需求、分析、设计和实现提供基础的过程。
业务建模能帮助项目团队更好地理解用户的业务背景，发现用户可改进点，确保软件系统与实际业务需求保持一致，更好的提高用户满意度。
此外，业务建模还有助于提高项目团队和客户之间的沟通效率，降低项目风险。业务建模通常会通过创建一系列模型（如业务用例模型、业务分析模型等）来表示和组织这些业务需求、流程和规则的过程。
业务建模描述了如何评估当前组织并制定新组织的愿景。然后，以该愿景为基础，在业务用例模型和业务分析模型中定义该组织的流程、角色和职责。
可见，业务建模很好的应对了我们在做需求时所提到的挑战：理解业务，做对需求甚至洞察需求。
业务建模是一种技术，建模语言常见的有UML和BPMN等，基于通识我们主要使用了UML。业务建模的UML常用符号如下：
要达成上述目标，业务建模方法描述了如何评估当前组织并确定组织愿景，并以愿景为基础，在【业务用例模型】和【业务分析模型】中定义组织的流程、角色和职责。
因为仅靠目标组织的结构图不足以了解其运作方式。我们还需要业务的动态视图。业务模型提供组织结构的静态视图和组织内流程的动态视图。
模型类型及其关系
业务用例模型（BusinessUsecaseModel）
业务分析模型（BusinessAnalysisModel，也称业务对象模型）
其次，也需要以下输出做为补充：
参考RUP过程示例模型：
上图中，通过业务用例和业务流程，识别业务执行者和业务实体（注：BusinessObjectModel应用了ECB模式，一种承载业务执行者和业务工人以及实体之间的活动图，Iconix方法称之为robustnessanalysis），并提炼出系统用例和分析模型。建模、理解和改进业务非常类似于构建软件系统。
可以看成一次探索的过程，其中包括确定目标和范围，通过高维框架逐步细化，通过整体视角，细节部分去不断审视，基于新的理解和洞察来更新模型，基本也是迭代完善的过程。
说了很多，通过推演一个餐厅的小例子来熟悉下业务建模流程和效果。业务建模通过UML可视化业务流程，实践中我们通过用例图和序列图和输出业务模型。下面通过餐饮行业一个小例子来探讨业务建模过程。
1、目标组织：餐饮行业类商户
2、组织的业务
为消费者（即顾客）提供餐饮；
3、业务建模的目标
4、业务用例：组织提供了哪些价值
5、业务现状：当前的业务活动及执行流程
某饭店现有堂食的业务流程如上，涉及多位业务工人（领位/服务/收银）及业务实体（绿色部分）；消费者消费时，需要与各类业务工人交互，涉及纸质记录、现金等，存在易出错效率低成本高等各类问题。
（注：RUP/软件方法的建模方法在这一点上有规范上的差异见附录1）
6、业务改进：建模改进，通过业务系统实现自动化改进业务流程
7、确认业务系统的需求：从通过改进的业务序列图，确认餐厅运营系统对外提供的价值。这些价值即系统要对外提供的能力，如预订、查阅菜单等。系统用例如图：
8、确认系统需求，进入系统分析和设计阶段。
如上一个入门级的业务建模过程，当然还有更多进一步的完善流程这里不做细致描述。但我们可以看到，通过模型即可快速进行业务流程的确认和分析，甚至对原有业务流程进行改进，找出建设系统的需求并为进一步提升组织的业务竞争力打下基础。
这样的改进场景很多，使用自动化的系统代替人工实现降本增效最终提升竞争力，如扫码点餐，滴滴打车等。针对业务建模方法，下面的梳理提炼方便大家有个整体轮廓。
以经典的RUP过程为例，基本的业务建模的工作流如下图（注意，与《软件方法》有区别：
我们可以选择工作流的多种路径之一，选择的路径取决于的业务建模工作的目的以及开发阶段。
在第一次迭代时，需要评估组织状态并确定建模目标。再决定如何迭代。
另外，当业务不做变更，可以通过业务建模分析的内容导出软件需求。
上述核心路径描述如下：
一、业务建模（BusinessModeling）
1.描述业务现状：输出业务现状的业务用例模型、业务分析模型
①评估目标组织，识别业务目标（Goal）
组织结构：组织的静态结构与职责分工；
确认业务目标：定义了要达成可持续竞争地位必须做到什么，可以按组织结构分解。
②了解组织当前的流程和结构
找出业务执行者：从与业务交互的任何个人、团队、组织，公司中找；
找出业务用例：从业务执行者从业务中获得的价值来找；
找出业务工人：组织内的角色（人或系统），其履行相应的角色；
找出业务实体：组织内业务工人处理的重要且持久的信息；
收集公共业务名词：项目早期就通用业务术语达成一致非常重要；
③细化业务建模的目标
界定业务建模工作：面向整个组织，还是业务流程的子集；
确定业务建模目标：涉及不同的范围，包括：确认组织结构，输出领域模型，为业务构建系统，建立通用业务模型，构建新业务，业务改造。选择其中一种。
2.找出业务改进：以现状的业务模型为起点对业务流程改进或重新思考
①识别业务流程及优先级
明确术语、确定支持业务战略的业务目标；
输出业务用例模型；
确定各业务用例的优先级：寻找支持最重要业务目标的业务用例。
②完善业务流程定义：详细说明业务流程并描述其如何支持业务目标
③设计业务流程实现：描述如何在业务对象模型中根据协作对象（业务工人和业务实体的实例）实现特定业务用例
④细化角色和职责：详细说明业务实体、业务工人和业务事件，并验证业务建模的结果是否符合涉众的业务视角
3.研究流程的自动化：确认流程中哪些部分可以并应该自动化
①三类自动化方式
重新组织或排序业务流程的活动：对业务用例做创新型改进，改变现有工作方式；
监视、控制和改进工作方式。
②理解如何让软件系统满足组织需求
③定义自动化需求：导出目标要建设的软件系统的软件需求
二、领域建模（DomainModeling）：
识别业务领域中的概念，提供对业务运营和环境中的概念的共同一致的理解。
识别业务领域中的所有产出和可交付成果。
上述的简要流程每一步都有具体的定义，涉及内容很广，这里不做详细描述。总而言之，业务建模可以提炼为以下几步：选定组织，了解业务，描述业务现状，改进业务；这里需要的是让组织提供的价值更大。
上面看到业务建模输出的模型有两种：业务用例模型与业务分析模型（业务对象模型）。而上述的领域建模是业务建模中的“描述业务现状”的精简版，只识别“业务实体”。
（注意，此处的“领域模型”是业务级别的分析模型，非业务流程，也非DDD的领域模型）
另外要注意的是，需要让每个业务实体及使用到的任何业务术语都定义到业务术语表中，并且在业务模型中提炼业务规则（大部分业务规则都是结构约束）；过程中，拉通团队检查业务实体并达成共识。否则无法达成领域建模的目的。
在上述建模工作流中，领域建模是业务建模的一部分，也可以独立进行。但对于领域模型本身，业界有很多理解。我们追根溯源来整体看看领域建模。
以下领域建模（DomainModel）的出处和解释，做个汇总：
在我们实践的过程中，为了可视而通常用类图表达，而且我们发现它带来更多的价值和收益：
在支付团队的实际业务分析和软件系统构建过程中，领域建模活动跟随着开发周期进行，模型在过程中不断细化改进，可以贯穿从需求（概念）阶段，贯穿分析（分析类图）设计阶段（设计类图）。如下图：
可以看到，餐厅运营这个业务领域中，需要多种角色保证餐厅的有效运作。如果从改进和降本提效的角度看，信息系统可以提供大量改进。
实际上在上述模型中还可以补充更多的信息，以发现和优化业务场景下关于效率和成本的内容。进一步补充实体属性，如下图：
再进一步处理下，需要在上菜及出菜上分别管理，方便事后核对，如下图：
事实上，在更大的同类企业中，还有更多的涉及各环节的流程和信息（如采购，财务..），在这样的模型呈现出来之后，业务系统开发团队将能更好的从全局来优化和设计信息系统，聚焦改进点（如将人工用系统自动化替代），能更好的为目标组织降本增效提升竞争力。
通过流程改进，交付的目标系统实现对人工的优化，快速将思路简化后如下图。业务实体信息化后，由业务系统管理并组成了系统本身：
再进一步按目标业务系统进行抽象如下，我们提炼出顾客体系，增强顾客联系：
我们可以提炼出多个聚合，通过聚合管理一致性边界。同时对部分实体，有必要的话也可以通过状态机描述其状态迁移过程，以明确状态管理机制。如下，点菜单的状态图。
通过一系列建模，我们可以更直观的映射到实现过程，方便对齐需求和业务目标。这样，当运营系统（即业务系统）交付后，封装了人工处理流程，将业务实体由物流转为信息流，并实现自动化。当然，如果有机器人厨师，则可以成为全自动餐厅。
上述小例子主要有于呈现建模的价值，以及让团队对目标业务领域进行快速沟通。可能有一些不足或者不同的理解，也没有展示继续构建的数据模型，有想法的同事可以在Xwatt项目里创建自己的思想试验。
在工具化后可以不断进行迭代达成团队理想的效果即可。不过，从一个小型餐厅如果深挖也有大大优化空间可以看出，大型的企业/组织背后涉及的复杂业务流程，其背后同样可能可以找出巨大的优化空间。这就是业务建模的巨大价值。
针对RUP过程中的业务建模方法，国内书籍《软件方法》也给出了相应方法沉淀，其中对流程改进的模式提炼相应指导方法总结为三点：
业务建模是一个体系化的主题，不同的场景有其合适的用法。通常也不建议对每个项目都进行业务建模。只有当有更多角色直接参与使用该系统，并有更多不同业务信息由该系统处理时，业务建模才会增加更多价值。
例如，纯技术领域的问题中，与业务（Business）无关，可以无须业务建模，你的代码和数据结构就是你的模型抽象；例如，如果只是在现有业务系统的接入层网关中添加一项功能，则不会考虑业务建模，因为这不会从根本上改变用户/组织原本期望的功能，它仍是网关。
回顾软件开发行业，业务建模方法随着IT系统融入商业领域而蓬勃发展，因为在原有商业领域中通过信息系统对原有业务流程实施自动化改进能提供巨大的增益，这个过程和方法的应用能力，也形成了行业咨询面向业务领域提供业务再造/解决方案的核心竞争力。
业务建模相对其它方法论有完整的理论基础（OOAD）和支撑工具，其各环节的应用在面向行业深度定制解决方案时发挥价值（如金融业核心业务系统的解决方案）。
其后，在互联网巨浪中快速爆发的工具型产品，推动了以面向代码的社区型敏捷开发方法的流行，尤其是在数据建模由ER模式转向NoSQL，而这个过程中面向业务领域的开发方法，相对在互联网社区的影响力在减弱。
业务建模的价值在于，通过一场思想实验让团队以相对低成本、轻量的方式真实的还原业务流程；通过抽象模型提炼业务的核心领域知识以还原业务本质，提升团队对业务领域一致和深入的理解，来促进业务和技术更好的映射。
业务建模过程，帮助我们理解构建的业务系统背后所服务的目标组织（客户），理解其对业务系统功能的底层诉求，理解用户使用我们的业务系统/产品/服务的驱动因素。
流行在变，但经典永存。业务建模所融入的OO方法/领域建模方法/业务流程改进方法，仍在为业务开发带来的有力竞争力。
附录1
附录2
附录3
业务建模的ECB模式，经查最早由Objectory方法合入RUP过程（RatinalUnifiedProcess）
参考资料：
作者：stanleyluo，腾讯后台开发工程师
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。