业务4W+H：关于业务，你想了解的都在这里

1 业务是核心所在，是价值所在，是区别（差异）所在，是变化所在，是顶层设计依据，是所有非技术层面人员都能够触摸到的，包括产品、项目、客户、设计、测试、运营、开发、维护、部署、外部资源等，都能够看到和理解的。公司所有职能部门都是围绕业务层面来展开的，需求也是围绕业务来挖掘的。

 

2 技术是支撑，为业务服务。是实现层面所在，是方案所在，是优化所在，是潜力所在。技术通过业务实现价值，如若不能为业务服务，则价值失去依附。

 

3 二者相互影响，业务对技术提出要求（如银行帐务对数据的要求，全局一致性），技术可影响业务（有些业务随技术进步才能实现，比如卫星电话，数字化城市，智能化业务等）。

 

4 所有技术架构、进步、发展，最终都体现到业务层面，业务处于上层，技术处于底层，自顶向下，自底向上，相互结合。

 

5 那业务是什么？是服务？是功能？是表现？都不是！业务应该是本质，是为什么这样做而不那样做的深层原因所在。实际中，需要真正理解需求，因为表现（表意）上可能想要做的A、B、C等需求，本质上却可能是因为另一个原因传导过来的。从本质原因再追溯，可能需求就会修改为D、E、F。比如，表现面上，想要一碗50到60摄氏度之间的汤，本质上的原因可能是因为赶时间，不想等待汤自己变凉，也可能是汤中某种成分在该温度区间功效最好，或者还有其他原因。如果知道了背后真正的需求，业务的设计自然可能就不做表现上的限定，从而具备一定的适应性了。

进一步的推广，该如何全面理解业务？如何梳理业务？

 

6 业务的4W+H。Why，为什么的问题。业务是价值的承载，一件事通过业务达成。生活中的诸多例子：娱乐购物，银行取款，医院看病，工厂生产，贸易签订，文化交流，生活的方方面面等都是业务的表现。业务是一种抽象，对人类活动的抽象，是一种承载，是一种实现。业务对标人类活动，就像技术对标业务。Why来自于人。

 

7 What，是什么的问题。业务表现千变万化，甚至可以说唯一不变的就是变化，那如何表达业务？虽然业务易变，但主线还是价值维持，目的不变。要说清楚What的问题，就需要总结，总结各种业务，抽取其中隐形的不变点，发掘其中的共同点，就跟生物学家对各种植物的分类一样，总要找出不变点、共同点，才能进一步研究，也才能研究。找的过程本身就属于研究，那对业务如何找出这些不变点、共同点？这需要梳理，梳理结果就是业务的特点。

A 业务需要有实体参与者

B 业务需要有数据，生成数据，传递数据，满足实体完整性约束要求的数据

C 业务需要规则约束，这也算不同业务的差异点所在。如果想怎样就怎样，也就不需要业务了。

D 业务是一个过程概念，有流程要求，可以看作业务有始有终，也属业务的特点、差异点所在。业务不是量子过程，瞬间同时完成多种状态。流程也是自然界活动的基本要求。

将上面的元素连起来，业务是实体依据规则，按照流程，满足数据要求下完成的活动（对比安卓中的activity抽象，也类比object的抽象概念，最顶层的抽象）。

 

8 Where，范围的问题。业务有范围，有边界，有上下文，说白了，业务有其所属的领域。举个例子，银行业有其一套流程规则，这些流程规则有其概念，像转账，交易，利率等等；建筑领域又有其特有的一套流程规则，比如工具车，混泥土，结构应力等。可以看见，在二者本身所属的业务领域，几乎是不相关的，没有交集。当然，它们也可能发生关系，比如涉及资金流通交易时，但这些并未脱离各自的领域范围，只是互相把对方看作领域参与者。技术上有一套设计原则，叫领域驱动设计，提出了领域实体，子领域，界限上下文，对象模型，主子流程等，其目的也是为了更好的把握业务本质，更好的让业务指导设计，更好的让设计回归业务本身，适应业务发展，同时又减少设计失误，无效设计，提高设计质量，设计效率等。

 

9 When的问题。显然，经过上面的论述，得出When的答案并不困难。一套系统所实现的业务与真实业务是有所差别的，真实的业务，人的参与度更大，更广泛，更深入一些。系统层面表现的业务，更多是为了更好的让人参与业务，管理业务，更大的发挥业务作用和价值。所以，严格来讲，系统实现的是狭义的业务，是人的活动的广泛的业务的一部分，与需求关系甚密。这样看来，When显然是早于设计，早于需求，它是源头活水，像基因一样，所有行为开展前，就存在了，随着设计深入，不断融入整个过程中。

 

10 How的问题。How的问题就涉及到如何提炼业务及其流程了。如何高效的设计流程，如何处理相似的同质的需求业务。比如，提供业务模板的方式等。这样做，也需要抽象业务的各种概念，从而构建业务的知识树，便于模板元素、流程要素、节点关系、实体、条件等等的设计，因为要有通用性。

借鉴计算机领域广泛使用的语言概念，人们设计了一种通用的语言模板，比模型模板表达力更强，更通用，更方便，但却又能转化为模板，有语言的一些限制，可能是一个有限状态机的设计，这样一种语言叫业务描述语言。在自然语言基础上进一步提炼，抽象，缩小范围，设定约束规则，加强描述的严谨性，减弱通用语言存在的二义性缺陷，方便可通过机器自动化处理。BPEL业务过程执行语言就是一种这样的语言。

基于语言建模，基于模型在通用化中提供差异，则模型就需要提供框架，提供概念，提供元素，提供支撑模型的上述条件规则，约束等等。下面列举一些供参考（其实，提供业务模型及业务描述语言，更需要对业务深入的理解与把握）。

首先，可定义参与者，实体范围，发起者，属性，行为

其次，可定义环节，流转，增删查改，起始结束，跳转，分流，合并，嵌套，循环，衔接，自定义流程

再次，可定义约束条件，大于小于，介于，逻辑判断，时间限制，权限限制，限定人员范围等

还有，可定义动作，批准，撤回，转发，打回，发布，公告，事件，抢单，派单，会签，驳回，传阅，生成报告等

  以上，基本对应了7中的A、B、C、D四项。为了更好的可实施，可计算机处理，还需要支持以下特性，包括但不限于可自定义内容，可拖拽，可可视化，可配置等。

  总体来看，包含了模型描述，模型生成，流程解析，流程驱动，流程流转，流程管理，执行，表单生成嵌入，自定义报表生成等。对于流程的驱动，又有流程引擎，逻辑引擎，工作流引擎等概念和应用产品。

 

11 四图看业务

通过四类图来把握业务。如下：

 

场景（业务）	银行、购物、政府、医院、企业、生活娱乐等等
图种类	业务逻辑图	业务流程图	业务功能图	业务表现图
说明	展现原始需求，属于高层抽象，总的来讲是稳定的不易变的核心价值，也是价值灵魂所在	在前一步业务逻辑图基础上对过程进行一定的补充细化，有判断、有分支、有范围的初步界定	进一步的对流程图丰富，考虑具体实现技术、限制、细节等，属于方案层面的支持	侧重用户体验部分，说明功能如何展示、用户如何使用，是需求的实现层面表达，可用于需求确认
是否考虑技 术实现因素	纯业务层面，不考虑技术，挖掘深层次的本质需求	包含一定技术内容	包含技术细节，依赖现有技术条件（比如，目前技术实现无法突破电磁波理论）	包含技术细节，依赖现有技术条件（比如，目前技术还需要借助物理屏幕，无法做到全息投影显示）