究竟什么是业务？IT技术人员应该如何熟悉业务

对业务的基础理解

因为一说到“业务”这个词的时候，大家容易把它跟“业务流程”这个词划等号，但是我的理解是，这两个词仍然有差异。业务流程虽然是业务的核心组成要素，但不能说是业务的全部。因为对于一些管理类、支撑类的流程业务，它其实流程的特征没有这么明显，但它仍然是业务。这是第一种情况。

第二种情况是，随着整个数字化转型的过程中，对于数据驱动、数据要素的强调，大家看到数据仍然是业务里面一个核心的要素。虽然说在业务流程梳理分析里面，往往分析到最后一个层级，你仍然会有业务单据，但业务单据转到业务实体，包括对于业务实体怎么样进行数据建模，其实在业务流程里面它往往不会去详细分析。所以说基于以上两个原因，不要简单地将业务流程和业务划等号，这是我想说的第一个点。

还有一些人理解业务的时候，他认为只有为核心业务价值链创造端到端价值的才是业务。比如产品研发的流程、产供销的流程，他认为这些才是核心的业务，而对于很多类似于人力资源、公共办公、财务这些支撑的业务流程，他认为不是业务。

这其实也是不太合适的一个做法。

真正的业务它一定是包括了管理类的流程、支撑类的流程，包括上层的核心业务价值链的东西，这些我们都应该把它纳入业务的范畴。

还有一种说法是，因为“业务”这个词在英语翻译过来是“business”，但“商业”也是这个词，所以说你不能简单地把业务理解成商业。业务的范畴往往比商业的范畴更加广泛。这是对“业务”这个词的简单理解。

技术人员如何熟悉业务？

那么，对于一个技术人员，你应该怎么样去懂业务，怎么样去熟悉业务呢？其实它仍然有两个核心的做法。

第一个做法是，我们仍然从生命周期和动态的视角，首先去理解业务流程，基于你对业务流程的理解去熟悉业务。比如我们说到产品研发，它就有核心的市场驱动研发的流程，有整个集成产品开发里面的概念、计划、开发、验证、发布的五个阶段的流程，你完全可以从这个核心的流程入手去熟悉业务。

如果你涉及到市场营销销售管理，它本身又有从商机的获取到销售机会，到销售立项，到项目售前，到最终销售合同、订单的签订，到后面的订单执行跟踪，它也有完整的全生命周期的流程。

供应链也是一样的，从你采购需求的提出，到我要去做相关的采购溯源，供应商的认证，再到组织招投标，再到实际的进行采购，再到采购的执行和接收，这些所有的东西就是它动态的业务流程的线，你完全可以基于流程的线去熟悉业务。

当然，流程的不只是横向的端到端流程，有些流程的线它是纵向的，特别是类似于智能制造里面，我们谈从计划到执行到控制，到最底层的智能设备机台，它就是一个纵向的线。这条纵向的端到端的线它仍然是业务，这是熟悉业务重要的一条线。

还有一条线就是，你完全可以基于业务对象的分析和梳理，基于数据的维度去反向熟悉业务。比如我们说到市场营销、市场管理、客户关系管理，你就会看到它里面核心的业务对象或者是数据对象就是客户。

当我说到实际的供应链采购的时候，它的核心对象就是采购订单或者是采购合同。当我说到整个供应链的时候，它的核心对象就是供应链的计划，包括后续的计划的分解和执行。当我说到产品研发的时候也是一样的，它的核心对象就是Item和BOM，整个产品结构。

我去熟悉任何一个业务域的时候，我都可以先抓住它核心的这么一个业务对象或者是数据对象，然后再去考虑围绕这个数据对象展开到全生命周期。实现通过数据对象的关联映射来反向追随业务。

比如你是市场营销，你肯定要去关心客户关系管理和客户的全生命周期；你是产品研发，你会关心产品的生老病死的全生命周期；你是横向的供应链，你可能会关心实际的从投资项目计划立项到采购需求，到采购合同、采购订单，到采购执行、采购接收的横向的全生命周期。

所以说你完全可以以数据维度先找到核心的数据对象，把数据对象先分析梳理清楚，再去从静态维度拓展到动态的全生命周期的维度去熟悉业务，这些都是我们常用的熟悉业务的一些方法。

当然，原来我还专门讲过，如果你是一个技术人员，你在做某一类的业务系统，比如你在做 CRM 系统、MES系统、SCM供应链系统，如果你原来是做这些供应链系统的设计开发人员，那么你还可以基于这些系统的操作、用户手册的学习，通过系统的操作去反向熟悉业务。

这个时候熟悉业务的重点，它就一定要注意，它不是单个功能的操作。

比如采购订单的创建、采购接收，你如果仅仅局限在单个功能的操作，你没办法去熟悉业务，你更多的要去关心我们讲的一个完整的业务系统，它里面的各个业务功能之间是什么样的横向协同和连接的关系。

比如我现在要去做一个采购订单，我可能首先要走供应链供应商认证的流程、物料认证的流程，而我要有物料供应商，我可能首先要去招投标的流程，形成合格的供应商，而要去驱动我的招投标流程，可能首先我要有项目立项的数据或者是采购需求。

所以你围着这个思路，你把所有的业务功能串通，你把了解清楚这些业务功能的前后依赖关系，你把它串起来，这本身就是一个完整的业务的横向的端到端的流程。所以说，这也是作为技术人员，你通过业务系统的学习和了解反向学习业务的一个很重要的方法。

学习业务架构知识体系熟悉业务

业务架构是企业架构的核心，有专门的BABOK等规范指导体系。那该如何更好地理解业务架构涉及的核心知识点呢？

下面我围绕下面这个知识关系图来进一步说明。

图片

举个例子，业务架构有两个方向的展开。一方面围绕流程分解展开，形成流程体系；另一方面围绕能力分解展开。先看流程体系展开，即构建企业流程架构模型。流程体系强调流程内容，但还需上层流程管理，所以涉及流程质量管理方法论。流程体系源于核心价值链，价值链含核心活动和支撑活动，共同构成企业核心流程体系，而价值链又源于企业核心业务战略，业务战略源于更顶层的企业战略。

回到流程体系，核心流程如研发、生产、制造、供应链物流、市场营销、售后服务及支撑的人力资源、财务等，是学习业务流程的必备内容。流程架构建设是分级的，从 1 级到 7 级，熟悉企业核心业务你了解 3 - 4 级流程就差不多了。流程体系在流程建模时，会涉及 5 - 7 级分解，这里暂不展开。

业务架构里还有业务需求这一核心概念，它不同于软件开发中的软件需求，更像IPD中的理解市场和细分市场，偏用户和市场需求。业务需求与流程体系分解到 5 - 7 级后关联紧密。

我将其分解，业务需求和业务流程的关联映射，重点是业务建模与 5 - 7 级流程的关联，将流程和业务需求联系起来。业务需求下面还涉及软件需求，这里先不展开。

再看右边，业务架构还做能力分解，形成业务组件，业务组件再与应用架构挂钩，因为应用架构里的应用组件与之有映射匹配关系。对于业务需求分析，有业务对象，而在企业架构的数据架构中，分析核心是数据实体，业务对象和数据实体之间相互关联。

业务架构知识源于上层企业架构，企业架构服务于企业战略，应用架构有技术架构支撑，这些共同构成4 A 架构内容。对于软件需求，有了数据架构后，还会涉及软件里的数据库设计。应用架构和技术架构还会细化到软件架构设计，软件需求、数据库设计和软件架构设计最终聚合到软件工程知识里。

梳理完这个图，大家发现关键点了吗？

学任何知识都有父知识和下游知识，父知识最终聚合，下游知识分解后通过关键对象或实体完成知识点映射管理。

理解这个图后，是不是容易明白业务架构不是纯技术或纯业务词汇，而是涉及业务、技术、管理多方面知识。业务架构知识体系分三方面知识融合：企业架构知识、业务域知识、软件工程知识。业务人员学业务架构要补技术软件知识，技术人员要补企业流程、质量、业务价值链、业务战略等业务知识。

如何短期来快速熟悉一个新业务系统？

图片

如果你已经有IT行业的工作背景，那么对于原来你没有接触过的一个新业务领域或新的IT系统，你应该如何快速切入？在这里我们假设你已有有一定的IT行业工作经验，业务和技术双方的积累，在这种情况下的新系统快速切入可以从如下三个大步骤入手。

在这三个步骤中你可以明显看到和我在讲思维框架模型中谈到的认知模型，事物静态分析和动态分析，动静结合的分析逻辑的思路是一致的。

第一步：粗粒度的全局了解

接触一个全新的业务系统，首先要搞清楚这个业务系统主要是支撑什么样的业务？而对于支撑的业务本身又有两个核心内容，即核心的业务流程是如何的？核心的业务对象模型是如何的？在这个了解清楚后可以继续了解这个业务系统大致会有哪些核心的业务功能模块，业务模块之间的相互关系是如何的？已经如何衔接的。

有时候了解到这个层面可能还不够，你还需要了解这个业务系统可能是支撑端到端业务流程或共享业务数据的一部分，那么还需要了解到这个业务系统或支撑的业务在端到端流程中所处的位置，该业务系统和上游业务和下游业务的关系，相互间的协同和接口。

业务系统支撑了什么样的业务，存储了哪些核心业务对象和数据，这是对一个业务系统最基础的全局理解。

第二步：动态了解-流程模型

图片

在对业务系统有了一个全局的理解后，需要开始进一步考虑流程模型方面的内容。注意在这里指的流程模型不是指工作流或人工审批流模型，而是指业务流程模型。或者说了解业务系统本身在分析设计中所涉及到的业务建模方面的内容。

业务建模或业务流程模型的了解需要解决的问题是，一个业务系统为何会存在这些业务模块，这些业务模块之间是如何进行协同来支撑业务流程的。任何业务模块都会有输入和输出，了解清楚业务模块的输入输出后就能够比较清楚业务模块之间是如何串接和集成来支撑上层的核心业务的。

如果一个业务系统按SOA思想来建设，你可能会看到有哪些上层的核心业务模块，核心的领域服务层和底层的数据模型层，核心的业务模块本身是如何调用核心领域服务来进行协同和衔接的。只有清楚了业务流程才可能理解清楚业务模块之间的协同和集成关系，否则你看到的是孤立的业务模块，业务模块和业务流程之间出现断点而无法真正想清楚业务模块间如何协同来支撑业务的。

如果一个业务系统本身是流程型的业务系统，这些流程又大量是审批流为主，那么即使审批流定义再复杂，整个业务系统本身也是简单的，因为不存在上面所说的大量业务模块间协同情况。

第三步：静态了解-数据模型

图片

对于一个业务系统的复杂往往体现在两个方面，一个方面是本身业务模块间的协同和交互复杂，一个是底层的数据模型和关系复杂。在解决了第一个层面的动态分析问题后，就需要开始考虑第二个层面的数据模型了解层面的问题。

任何业务流程，模块间动态的协同最终都将持久化到数据库中，成为数据库中的数据表和数据表之间的关联依赖关系，映射关系。业务系统前面谈到过或者是以流程为中心的业务系统，或者是以数据为中心的业务系统，对于数据为核心的业务系统必须理解底层的数据模型。这种数据模型的理解首先是要理解元模型结构，这种结构不是简单的单个数据对象，而是多个数据对象之间的关联关系，映射关系，层次关系等。正是由于数据之间有这些关系，而形成了一个复杂的数据网络。

对于数据模型的理解基本可以分为如下几种，一种是单对象的结构，包括主从，层次等各种结构；然后才是对象和对象之间的关联依赖结构，如一对多，多对多结构等。对于较为复杂的业务系统，你可能还会看到为了保证底层数据模型的可扩展性和灵活性，往往在数据模型层会根据面向对象的思路做进一步的抽象，那么在这种情况下还必须等将OO的对象模型和面向结构的数据库模型共同来参考理解，以分析和了解清楚最终数据存储的方式，数据存储后最终呈现的方式。

第四步：动静结合-关键业务分析

个人理解，对于新切入一个新的业务系统，如果能够理解到这一步，基本就可以对一个业务系统有一个比较全面的理解和认识。首先是了解业务流程和模块间协同，然后是了解数据模型和数据间关系，最后则是真正的根据核心业务来进一步理解在流程协同过程中最终数据的落地存储。由动态的业务流程驱动的最终静态数据的存储落地和关系的建立。只有这样流程和数据的分析最终才会融合为一个整体。

对于关键业务的分析你会看到，对于这些关键业务需要理解清楚究竟涉及到哪些模块的协同，在模块的协同过程中最终会产生哪些核心的数据，或者说会更改哪些核心数据的状态或数据间的关系。真正你需要关注的往往不是单个数据对象中某些数据熟悉的变更和修改，而更多的是关注核心业务流程驱动下，数据对象状态的修改，数据对象间关联关系的修改，数据间映射模型的调整等。

对于一个完整的业务系统，按道理只要有基本的数据对象维护功能即可，但是要真正能够支撑业务，你会看到数据对象中的关键属性，关键依赖关系的变更，最终都是由上层的业务模块和流程来支撑的，那么你就必须要能够真正的理解所有的核心业务流程最终对底层数据模型造成的影响。

以上即熟悉业务的一些思考，供大家参考。