业务建模之一:业务分析

“业务要求”似乎是IT程序员永远无法越过的一道坎,轻飘飘一句“不满足业务要求”,足以让你从云端自由落体;“业务逻辑”是IT程序员心中无法言及的痛,它总是那么“蛮横得不讲道理”。如果让程序员评选“最不合逻辑的逻辑”,结果一定会是业务逻辑。当“不满足业务要求”,或者“不符合业务逻辑” 时,年轻的程序员总会弱弱地问“能不能就这样”,大抵是让业务迁就程序,结果自然不断碰壁。业务员乐此不疲,程序员伤心不已。

业务是什么?业是指工作岗位,务是指事情,合在一起是工作岗位上的事情。我觉得业务的含义就是完成一项具体的工作,会涉及人员分工、工作步骤、时限要求、工作成果、验收标准等潜在的属性。比如上市公司研究业务,就是股票研究员按一定的上市公司估值方法,在规定的时间内给出研究报告及投资建议,并接受公司的考核。业务分析的过程其实就是找全业务的属性并赋值的过程,每个业务点都可以套用5W1H、脑图等方法进行析构,复杂业务可以采用分类等方法进行简化。这项工作做得越细致,分析就越透彻。

业务分析

业务分析是业务建模的基础,它的首要成果应该是分析出业务中涉及的主体,有抽象的,也有具体的。这些主体的概念一经明确,就具有了活力,有特征、有行为、有生命,所以需要反复推敲。我一般套用数据库中的概念,称之为概念模型。业务建模领域有些成熟的方法论:用例图可以帮助固化场景、界定范围,类图可以明确主体的特征、行为及关系,时序图可以明晰不同主体间的协作等。主体的属性、关系一旦确定,就会体现在库表结构设计和程序逻辑中,在项目的中后期改变起来非常困难,所以要慎重。我们经常能够听到程序员抱怨说这个问题当时没考虑到,现在不太好改。比如两个主体原先是一对一的映射关系,在某种极其例外的情况下,需要变成一对多的关系,估计就会伤筋动骨。

业务分析的第二项成果是梳理出哪些是变化的,哪些是不变的。对变化进行封装,让变化所带来的不确定性只影响局部范围,是程序员进阶需要掌握的一项基本技能。程序在很多时候就是为了管理变化。比如一个文件备份业务,不变的是需要将文件从一个目录拷贝到另外一个目录,变化的是到底需要拷贝哪些文件。通过配置、解析来管理这个变化,程序也就有了足够的通用性。

业务分析的第三项成果是需要分析出哪些工作应该机器完成,哪些需要人工完成。这个“度”很难把握,需要综合权衡风险、便利、技术成熟度等。在考虑风险因素时,需要认清到底是消除了风险,还是转移了风险。我们不能做风险的搬运工。随着计算机应用技术的发展,机器能做的事情越来越多,本着“事务型工作自动化、管理型工作流程化、决策型工作智能化”的原则,一点点地提高业务运作效率。

在你认为已经将业务分析得很透彻之后,加入时间变量,借用有限状态机的概念,让业务模型在纸面上运转起来。你可能会发现很多新的问题:这时候可能你还没有考虑清楚每个概念主体到底有多少种状态,状态之间到底如何变化,当不同状态重叠的时候又该如何处理。千万不要轻易给主体新增状态属性。比如一个主体已经有三个状态字段,每个字段有两个值,则这个主体就会有八种状态。如果你再随手增加一个状态字段,则至少新增了八种状态,会使问题大大的复杂化,但你的初衷可能只是为了解决一个小问题。事实上很多状态并没有实际的物理意义。两个原则:原则一是宁愿扩充解释,也不要新增属性;原则二是没有物理意义的分支一定要剪枝。

以上是我在业务建模过程中总结的一些理念、工具和方法,其中滋味不足道也。不见得通用,也不能一招鲜吃遍天,需要在实践中不断琢磨、提高。

举例

以信息披露业务为例。

第一步:分类

第一步:分类。由于业务繁多,所以我首先对它进行分类,比如:公募基金招募说明书更新、公募基金定期报告、公募基金公告、年金定期报告、专户定期报告等。分类是否合理,需要根据实际业务判定。我在实际操作中,将人员分工和管理流程一致的业务分为同一类业务,因此现在的信息披露系统中已经有十几类业务了。

第二步:主体抽象

第二步:主体抽象。和大多数人一样,我一开始觉得信息披露业务比较简单,无非牵扯到的业务部门多一点,后来的事实证明我错得离谱。闲话不说,看结果:

1、人,要赋予不同的角色:报告创建人、数据维护人、数据审核人、部门负责人、审计人员、业务负责人等等。

2、模板:这是对报告结构的抽象。

3、元素:构成报告模板的基本要素,对应报告中的一个内容,可以是一个词汇、换行符,也可以是一个表格、图,甚至可以是一个Word文档。

4、数据:给元素赋予具体的值。

5、报告:最终要交付的文档。

6、产品:公司运作的产品。

7、报告期:信息披露的报告期限,不同业务需要的数据不同。

8、业务:人员分工和管理流程一致的信息披露子业务。

9、部门:公司组织架构的一部分。

……

梳理出所有主体之后,进一步梳理出主体的属性,篇幅所限,略过。

第三步:梳理关系

第三步:主体间的关系,反复推敲,从而形成类图。略过。

第四步:用例分析

第四步:用例分析。我以批量创建定期报告这个场景简要说明一下。批量创建定期报告是指年金(养老金业务部)、专户(机构业务部)或一对多专户(客户服务部)在每个月初、季初或年初的时候,需要批量创建上一个报告期的定期报告。除了创建报告外,其余隐含的业务逻辑包括:

1、哪些产品需要披露定期报告?新成立的产品怎么办?产品如果不需要披露报告的怎么办?

2、每个产品使用什么报告模板来披露报告?忘了维护产品和模板对应关系怎么办?模板还没有怎么办?

3、模板是不是都已经正确设置?有没有被人修改过?

4、通用的数据是不是已经维护好?

看似简单重复地调用“创建报告接口”即可完成的批量创建报告,其实需要考虑的问题点很多。

第五步:形成功能

第五步:定义动作,形成功能,比较复杂时可以借助时序图。以批量创建报告功能为例,需要处理:

1、产品检查:返回报告期内新增的、未在信息披露系统中维护的相关产品。

2、模板检查:返回报告期内相关模板变更记录。

3、产品模板对应关系检查:返回报告期内新增的、尚未指定定期报告模板的相关产品。

4、通用数据维护检查:返回模板中涉及的通用元素的最新信息。

5、创建报告。

第六步:纸面推演

第六步:纸面推演。比如报告生命周期管理:创建报告、发起流程、任务分发、数据维护、数据审核、稽核审核、报告下载、报告归档。

纸面推演时,在确保业务正常运作的前提下,重点考虑例外情况处理。举例来讲,在任务分发环节,部门负责人可能按子业务将分发权限授权给不同的人员负责;在元素维护部门对应关系上,同一元素可能因发起部门不同,数据维护的职责归属不同等等。找到例外并修改之前的设定,如此反复。

阅读更多
个人分类: 其他
所属专栏: 业务建模
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭