业务架构

 

业务架构与业务流程

    大家好！我今天跟大家一块儿交流的题目是业务架构与业务流程。这是从业务的另一个角度来探讨业务流程，看它在业务架构中的作用和影响。今天跟大家交流的就这六个题目：第一，业务架构的概念；第二，业务架构的基本方法；第三，业务架构的基本目的；第四，业务流程的概念；第五，业务架构与业务流程；第六，数据库结构与数据流。
    其实这六个题目很简单，跟刚才那位老师所介绍到的是两件事，刚才介绍的是从应用层面上讲我们怎么优化业务流程，来使用它，来提高企业的效率呀，来用它。我介绍的层面呢，是信息化建设中做业务架构与业务流程它们之间的关系。
    今天只有流程管理一个主题。我给大家说，这东西的源起是什么，例如我搞了十五六年的地税。政府行业的信息化，但搞的结果呢，是这么一个情况：现在全国三十个省市，包括单列市，几乎都在运行信息化，但是每个省的做的都是做的税收业务、地税业务，他们每个省的应用软件的结构都不一样，而且都不能复用，各做一套。然后呢？数据库结构不一样，操作流程不一样；然后呢？这个归聚的数据不一样，甚至，同一部法律下，采集的数据也是五花八门。所以这东西呢，后来我搞了十几年后发现这事有点不对头。究竟是什么原因？然后我出来以后，现在离开了税务局，研究了两年。这算其中的第一个主题，跟大家来共享。
    我们看这其中有没有，就是在行业中通用的东西？我们可以不可以设计出行业通用的标准数据库结构？换言之，比如地方税收，只要它在一部法律下，同样的税种下，做的同样一件事的时候。它就应该有一个同样适用的数据库结构，我就研究这么一个问题，其它问题先不谈。
    第一、业务架构的概念，今天我不谈技术架构、不谈数据架构、也不谈应用体系架构，我们只谈一个业务架构。业务架构的直接目的只有一个：设计数据库结构，因为你这个问题解决不了，你将来设计所有应用软件，同一个行业的东西就会五花八门，各走各的路。我们分析一下，它究竟为什么是这样。
    首先，我把业务架构分为：广义的业务架构和狭义的业务架构。那么广义的业务架构呢，它就是指业务工作的基本结构。它很简单。就是说，比如税务行业，它的业务工作，它的基本结构是什么呀？那很简单，一个有内容：就是法律内容；然后呢，由什么构成呢，一个是工作内容，第二有机构设置：岗位与职责；还有这些业务工作的处理流程。这四个东西共同构成它的业务工作的基本结构。其实它很简单，但问题呢，刚才我说的问题就出在这里边。
    第二个概念是狭义的业务架构，概念的上边是指“开发管理系统软件时对业务工作的基本结构的设计”，就多了两字，因为你开发管理系统软件的第一环节就是业务架构，业务架构是它的基本设计，而不是它的原样的反映。我们看上边这四个内容：业务工作内容的分布、业务执行机构的设置、业务职责与岗位的设置、业务处理流程的确定。在这四个内容中只有业务工作的内容分布，它是什么呀？它是一个常量，我以地税为例，无论北京、广东、深圳、上海还是哪儿的，只要你在中国，只要你征税，那么你执行的是同一部法律，这是一个常量。而执行机构的设置、职责与岗位的设置、业务处理的流程的确定，这三个量全都是变量。它们四个内容共同够成基本结构，大家就记住这个。因为我整个说完这40分钟就是围绕这个来说的。
    我在这里边，把它的基本结构分为常量内容，业务工作内容的分布就是基本内容；底下三个：业务执行机构的设置、业务职责与岗位的设置和业务处理流程的确定，叫做变量或则叫矢量，它是可变的，一个省一个样，一个领导一个样，没关系的；这岗位这么设，那岗位那么设，他愿意让谁干就让谁干。
    我们往下看，我们这里说的主要只狭义的业务架构。在设计软件结构中你怎么做业务架构呢？做业务架够的基本方法现在有两种：一个也就是业界98%以上都使用的方法是业务摸块架构法；另一种就是我今天介绍的，有点新鲜的东西，就叫业务流程架构。
    我们先看业务模块架构法，它有两种办法，第一种办法呢，它由用户的工作模式做业务架构。用户的工作模式就是刚才说的四块内容，他是把它合到一块儿，那么用户怎么工作我就怎么给你归结业务，怎么给你做业务架构，然后怎么给你建数据结构，这是一种最典型的办法。所以现在这种办法做出来的数据库结构，统统是一个数据库内部N个孤岛，它一定是孤岛。这种做法带来什么样的基本问题呢？第一、中断了正常的业务关系，也就是对同一个管理对象所做的业务被中断在不同的摸块中，把我们的关系割断了。第二个最基本问题也很简单。孤岛式数据采集，它因为中断了关系，无法判断它的唯一性。另外呢，因为它的空间性被割断，事物的前言后语无法得到关联。然后数据采集又无法判断它的唯一性，就产生了大量的冗余。又由于我们的设计人员，他想在这个模块下支持输出，有自己在中间做了很多表的冗余。又由于我们的设计他想在这块模块下支持输出，又自己做了很多中间表。这样的结果使整个系统的唯一性遭到了极大的破坏。或者很简单一句话，事物在时空中正常运动的过程，你的设计没有正确的把它反映过来，就丢了一些属性，你日后要用的时候就没地找啦，所以这是它有的一点基本问题。
    第二个业务模块架构法的办法叫什么呢？就是依据它内容的不同划分。例如吧，同样是征营业税、所的税和个人所的税，这个局呢，他设置了所得税处、然后他把一个税种的事一块儿管；另一个局设置的是征管一处、征管二处。就是说对同一类他有不同的划分的时候，我们就依据用户的不同划分进行这种业务架构。这种架构的结果是什么呢？基本的问题就是把变量和长量混在一块，由用户的工作模式来支配了你 。你设计出的业务架构，不能够把一个业务对象基本过程通过数据表和业务流程把它的关系正常的建起来，也导致了犯刚才的错误。我刚才说的那个一个行业，同一个公司对同一个业务得出三个不同的结果。无法应用怎么办呢？就拼命买了一些工具抽取呀，数据仓库呀，折腾来折腾去，但是你这孩子生出来就缺半条腿，你怎么抽取你还是缺半条腿。就是很简单，问题不在后边，它在于前边。所以好多时候好多公司，他知道你这儿缺半条腿，他就不帮你整合，一给你抽取，我给你这，我给你那。结果呢？他就不告诉你缺半个腿。好，你花了很多冤枉钱，买了一大堆东西。
    我们往下走，看怎么解决呀？这是我这次交流的核心，就是业务流程架构法。本来讲到这儿的时候，我们应该定一个概念，就是业务流程。在我的分析方法论里边，它也分成广义的业务流程和狭义的业务流程。广义的业务流程是指大流程，就是一个事物从它在时空中发起，到它最终目标的实现，它由n个交易单据构成达到最终目标。这个过程有的时候是十天半个月也可能是一两年，比如地税部门的一个企业所得税减免这件事情，它可能横跨三年。在这个业务流程中，它跟机构、跟岗位、跟你处理具体事务的过程无关。无论你怎么做一定得达到这个结果才叫事务办完。所以我在这里区分。广义的业务流程，你比如任何一个行业依据法律来来做一件事情，它一定是有一个过程加一个内容。比如地税行业国税行业他是有个程序法，比如征一笔说，程序很简单，包括税务登记、纳税申报、税款征收，必须有这三个环节，也就是你办理了纳税登记、纳税申报，应征与入库遵循核算的规则即一减一等于零，借贷相等这么一个过程，这是法律规定的一个过程。那么实体法，是指什么呢？例如它有二十部实体法。这个东西是指某一个税种的具体的征收规则，流程这两个东西是不变的，也就是所谓的常量。在刚才第一部的四个内容中这个东西是上面的第一行内容-常量。 是什么意思呢？换言之三十个省、十多个单列市，只要你征地方税收。你一定是要这么办的，这个里边没有二义性。
    现在说的业务流程架构法，是指按照行业基本法规确定的基本业务流程做业务结构。行业的基本行规，第一它与职责岗位设置无关、与用户如何办理业务无关。你比如税法规定纳税人当你是残疾人而且是个体户办理营业税的时候，你免税。就这一条规定，那么无论你是哪个省市做，你一定是通过一个单据，内部怎么办它不管，它一定是申请审批，减免核算。第二点业务单元都是常量，也就是刚才业务流程架构中都是常量，由此而做的业务架构，行业只会有一个。
    业务流程架构法解决了当前业务架构方法所存在的问题。它把中断的过程和关系搭建起来，尤其是每笔业务的空间标示，也就是前言搭上后语。第二它在处理一笔业务的时候，因为业务关系保证了它的唯一性，你记录这东西它只记录一个增量，它不会记录第二次冗余。所以业务流程架构法就解决了我们前面模块架构法所产生的问题。
    业务架构的基本目的是什么呢？其实就是一个设计数据库结构。数据库结构实际上就是反映了你业务的本质过程，要正确的反映它的过程就是你的数据库结构就是合理的，如果你不能正确的反映它，或者丢失一些，这个属性或者参数，那么你的这个设计就是有缺陷的，在这里边这两个概念原则上说也是一个新概念。因为这个数据库结构和你的架构不同，所以数据库结构应该分成交易数据库结构和查询数据库结构。现在我们的数据库结构常是把交易数据查询数据放在一个表中，其实交易数据和查询数据是完全不同的数据，交易最终目标是要写入数据，而查询是发起式数据，结果是展示，它两个对数据库的设计，对数据的要求是完全不同的，对系统的要求也不一样。把完全不同的东西放一块来做设计的时候，结果是什么呢？什么都没搞好，当你需要写入的时候，慢慢的性能在下降呀，当你做查询的时候你又发现你作了这么多索引，怎么还不好使呢？因为它不是一回事，你非得把它当一回事来做。所以呢，我在这里提出来，业务架构在前面正确架构的基础上，它应该是一个交易功能的数据库结构和一个相对应的查询功能数据库结构。这两个东西在结构上是完全不同的，因为你写入的时候是按照交易单据，按照业务流程来完成，而你查询的时候是要按照业务的种属关系，按照它的种属关系它的这个概念，按照采集数据关闭的这种关系来做，所以它的结构要求完全不一样。现在我们把它当成一样的时候，你的结果就出现了很多的麻烦。
    那么你这种结构最好是什么呢？最好是按照数据库结构满格写，就是每个字段都是这么多字段，那查询效率是非常高的，但现在我们呢？如果你有五个交易，一个交易十个字段，另一个交易八个字段，另一个交易十六个字段，你想想，在时间、空间标实没法标记，大量的空格、空值。数据库在查询每一个空值是要N次匹配完毕才往下走呢，你说你那些空值使数据库的效率下降，我说一千倍都不止。第二个问题就是数据库模块中断了关系以后，数据库想在为你提供服务，没有办法提供服务啦。为什么，因为SQL语言执行的是数据库关系中可以按照你的关系给你抓出来，是非过程式语言。但是你把关系中断以后靠你自己去写，然后在把那种关系建起来的时候效率有下降了1000倍，所以我们后台数据库设计的时候，第一你没按照流程去做结构设计，然后数据库提供给你的大量的查询工具，所以依据数据查询的可以建立的虚拟视图和视图都无法视图，他给了你做所有数据的工具，但是我了解的开发出来的动辄几千上亿的结构都没使用数据库给他的性能功能，为什么？就是因为你在建立数据库结构的时候，没有遵循数据库的基本要求。比如说：开句玩笑，老师我们买了Oracle数据库，其实就相当于宝马机跑三百迈，现在不会用，中断了不会用，我们现在是怎么用这数据库呢，几乎当着硬盘，相当于套了一个驴拉这一个宝马车。你不按它的规矩办呀，然后又去买抽取数据仓库，环节一多，你的后台变得一塌糊涂，这个东西是一个通病。
    在这里我只提出这么两个概念，实际上交易数据库结构，按照流程设计完后是一个非常简单的结构，效率非常好。在这基础上你按照查询数据库所设计出来的结构完成同源复制的视图和虚拟视图，完全可以保证。
    第四业务流程的概念，要按照广义的概念，要按照法律法规的概念，从发起到实施到目标实现的全部法律过程，他有N个环节构成，每个环节有交易的单，其实很简单就是，注意我还强调一句，跟机构的设置，岗位的设置无关，岗位你让谁干没有关系，你只有这样按照基本常量来做的交易数据库结构，他才是行业唯一的。就依据法律过程，然后分析它得流程，确定他前言后语关系就可以了。狭义的业务流程刚才这位老师讲得很详细啦。
    最后我再说一个业务架构与业务流程，实际上业务架构要依据用户的业务流程也就是广义的业务流程来架构。正确来反映他的业务过程，然后你才能够得到一个好的数据库结构，否则就容易出现我们现在见到的那些问题。
    最后结论，流程设计架构方法是设计行业结构的方法，他是支持管理系统软件的开发产品的重要方法，也就是说容易掌握这种方法，你完全可以设计一个管理系统软件，在这个行业中一定是通用的，至少他的复用率在85%以上，那么你想他的市场价值，他的服务价值体现。
    我就交流这些，谢谢大家！