IT2.0业务中台规划牵引客户IT基础设施投资随想 (九):识别业务对象的流程、方法和原则
上一节介绍了业务对象的内涵,以及与之相应的业务对象建模基本方法。本节接着上一节的内容,继续进一步介绍识别业务对象的流程、基本方法和原则。
识别业务对象可以大体上分成5个阶段:分析和识别业务对象、整理业务对象初稿、业务对象开发和验证、更新业务对象定义和描述、刷新业务对象。
在分析和识别业务对象阶段,可以有4种主要的工作模式:
- 架构驱动模式:主要的输入包括现有的业务战略、业务架构、业务能力模型、业务流程、业务管理要求/控制点等等,基于面向未来发展的业务战略,自上而下地规划需要构建或优化的业务能力、业务流程和业务对象,重点阐述战略目标与业务能力、业务能力与业务活动及活动的输入输出之间的联系,通过业务战略目标牵引出需要重点建设的关键业务对象,以对象为中心构建业务数字化运作、运营管理能力,例如研发数字化的MBSE(基于模型的系统工程)就是基于对象建模构建系统工程的技术过程和管理过程。
- 参考架构驱动模式:与架构驱动模式类似,只不过这里的架构并非源自于战略规划,而是业界先进实践,所以也叫参考架构。
- 软件包驱动模式:基于软件包现有的业务功能模块、对象模型以及数据标准,反过来适配业务,自下而上地识别软件包对应的业务对象。这种方式的好处在于能够快速地基于IT自身的知识引导业务识别业务对象,而且识别出的业务对象很好落地。坏处或局限性在于受制于软件包本身的限制,有可能没有与业务匹配的成熟软件包,又或者软件包无法满足业务未来的发展模式。
- 业务需求驱动模式:主要的输入包括业务需求说明、业务场景等等,基于业务实际提出的需求以及真实的作战场景,自下而上地提出业务用户需要的业务对象,重点阐述业务对象与业务需求及业务场景之间的联系,通过实际用户的交互需求分析其所需的业务对象,以用户的实际交互场景驱动整体交互框架的构建,例如多渠道营销(multi-channel marketing)以用户通过不同渠道的营销体验驱动业务中台建设。
自上而下和自下而上的业务对象分析和识别更多体现在组织方式的不同以及侧重点的不同,前者更加注重支撑业务战略目标的业务对象完整程度,后者则侧重于业务场景与业务对象的匹配度。两者各有优劣,最好能够结合起来,以平衡集团统筹的全面性、归一化、集成性,和一线实际作战场景的快赢性、个性化、独立性。
基于上述方式分析和识别业务对象,其本质都是要识别业务能力、业务流程、业务场景、业务活动、业务功能模块等业务处理单元的输入输出。对于业务对象的定义,本质上就是对输入输出的定义,也即是要说清楚业务处理单元间传递的信息是什么?要想准确做到这一点,就需要明确业务对象的内涵和外延。举个例子:当我们要描述一个新的物种的时候,可以采用分类的方式说明这个物种的“界门纲目科属种”,也可以采用枚举的方式说明这个物种尽可能多的个体(individuals)以形成个体的聚类,通过这两种方式都可以很好地界定清楚新物种的内涵和外延,能够让更多的人对新物种有更准确的认知。
在整理业务对象初稿阶段,重点是梳理候选的业务对象,并对候选的业务对象进行初步的合并和抽象,以初步输出业务对象清单。人工完成这个过程的方式和机器学习一样,包括“分类”和“聚类”,或者也可称之为“有监督学习”和“无监督学习”。通过分类或聚类的方式,可以对第一阶段分析和识别的业务对象进行适当的合并和抽象,形成更为普适的业务对象清单。
如下图所示,通过5W2H可以将业务处理和交互过程中所涉及的要素(主要涉及主数据和基础数据)和事务(主要涉及事务数据)进行有效的划分,这种划分的方式本身就是一种普适的认知,再结合分类、聚类这两种不同的业务对象定义方法或策略,就可以在更大的范围内获得对业务对象定义更广泛的认可。
分类是业务对象的最基本表现形式。对于分类策略而言,MECE(mutually exclusive collectively exhaustive)是普遍需要遵从的基本原则,即分类本身需要符合“相互独立,完全穷尽”的原则,不同分类所包含的个体彼此间是相互独立的,每一个个体在同一个分类方式下仅能归属到唯一的Class。
聚类则是业务对象最广泛的表现形式。我们通常说的数据集也是这个意思,我们可以将高度相似的个体聚合到一起作为同一业务对象,这种聚合方式比分类更具有灵活性,因此其更广泛地被用来定义业务对象。例如我们可以将符合某些特征的客户定义为“价值客户”,可以将非连续的时间聚合为某个统计口径的事件或报告对象,或者将连续样本离散化为业务想要的高聚合和低聚合对象。聚类相对于分类更加依赖于特定的业务规则,因此业务对象定义与业务流程中的业务规则关系密切,业务对象定义某种意义上反映的是业务模式以及业务管理策略。
在业务对象开发验证阶段,主要针对前一阶段输出的业务对象初稿,按照合规性、完整性、合理性、集成性等原则进行审核、验证、优化:
- 合规性验证:分析识别的业务对象,符合以下基本规范要求;
序号 |
原则 |
说明 |
1 |
业务对象指企业运作和管理中不可缺少的重要人、事、物信息 |
· 可以基于商业设计、价值流、BI识别业务对象,并和业务能力匹配。 · 针对业务对象,通常会建立相应流程、组织、IT进行管理。 · 业务对象的Owner明确且边界清晰。 |
2 |
业务对象有唯一身份标识信息 |
· 业务对象必须有身份标识信息,能区分不同业务对象。 |
3 |
业务对象相对独立并有属性描述 |
· 业务对象有描述自己某方面特征的属性。 · 业务对象可独立存在,可获取,传输,使用,并发挥价值,可以与其他业务对象关联,但不是从属关系;而逻辑数据实体依赖于业务对象。 · 即便随时间推移状态发生变化,业务对象也不会发生本质变化(至少身份标识不变)。 · 有生命周期,有状态变化。 · 事务数据类业务对象可以根据管理责任主体(Owner)差异进行拆分,主数据/基础数据/报告数据原则上不允许拆分。 |
4 |
业务对象可实例化 |
· 业务对象有具体实例存在,通常需明确owner、定义架构、标准、度量监控,才能有效管理。 · 基础数据、报告数据一般不视为业务对象。 |
- 完整性验证:与业务流程、 业务场景和业务管理需求适配,确保涵盖所有需要的业务对象;
- 合理性验证:从业务重要性、复杂性以及业务管理责任优化业务对象;
- 集成性验证:验证业务对象与相关领域的业务对象可对接。
通过验证的业务对象,基本上就可以定稿了。在更新业务对象定义和描述、刷新业务对象阶段,重点是要明确业务对象的业务责任人(Owner),由业务责任人来负责业务对象的演进、管理和发布,而这也与第七节中提到的基于业务对象定义的业务应用服务管理有着密切联系。
- 点赞
- 收藏
- 关注作者
评论(0)