应用业务规则管理技术（BRM）构建灵活的3G BSSOSS

《应用业务规则管理技术（BRM）构建灵活的3G BSSOSS》由会员分享，可在线阅读，更多相关《应用业务规则管理技术（BRM）构建灵活的3G BSSOSS（5页珍藏版）》请在装配图网上搜索。

1、应用业务规则管理技术（BRM）构建灵活的3G BSS/OSS 各位好，很荣幸今天有机会跟大家交流一个新的技术，就是业务规则管理技术在BSS跟OSS的应用，很巧的是，我们前面几位先生已经介绍了规划，第二介绍了3G支撑系统，现在我想着重谈一种技术，就是业务规则管理技术。这就是我发言的过程，第一个就是3G业务中BSS跟OSS最大挑战怎么样，最大的挑战，其实有很多挑战，我想强调的是灵活性，怎样构建非常灵活面向业务的系统。第二介绍业务规则技术在BSS和OSS的优点和特点，以及介绍什么叫业务规则管理，他的一些具体应用案例。我们都知道在3G一个新的技术出现以后，我们会面临很多问题，大家都心里清楚，我并不能想

2、象到，将来我的业务会怎么样，会用什么样的策略管理我的公司，获取利润。大家都有这个想法，我们一定要从产品为中心的思路转到以客户为中心的变化。这个情况下，其实里边有很多情况来决定了，到底在整个开发当中什么是最复杂的，最多变的因素呢？如果我们抓住这种最复杂、最多变的因素，并且很好控制他的话，也许我们将来开发这些系统就相对稳定，而且有很强的生命力。 我们可以看看，我们从技术角度来讲，解决业务问题有很多因素，我们首先想到要把数据大集中，整个公司，整个企业的数据集中起来，这样我就可以把系统做的很完美。下面把流程好好打造，今天上午到下午，我们谈业务流程打造，这样使系统有很多的适用性，也许我们用技术解决很多问

3、题。大家有没有想到，里面还有非常关键的因素就是业务规则。整个情况，整个业务问题当中，也许业务规则是最活跃的一个要素，他涉及到你所有整个系统的方方面面。而且它与你的业务是密切联系的，与运营商来讲，可能业务规则是他真正的资产，数据也许可以和不同的运营商共享，公司本身的策略也是他自己的，它的促销策略，套餐策略，往往决定了他的盈收非常重要的要素。业务规则是非常重要和活跃的要素。 我们开发系统有这样非常强的一个过程，而且大家都会经历、计费，现在的BOSS或者将来的情况，首先我们有操作系统，第二操作系统构建我的应用，过一段时间我发现数据必须提取出来，于是我们出现数据剥离，有一个数据库管理系统管理他的数据，

4、任何系统没有数据库管理，这个系统没有人敢用。现在2005年除了数据，应用系统还包括业务规则。影响把规则从程序里拿出来，做单独的要素进行管理。之后将来我们会看到更多的层面出现，比如流程、服务。所以我们现在业务规则在这个层面已经成熟了，在中国、在国外很多地方，很多系统都在用业务规则的管理技术。 我们可以看看，到底什么叫业务规则，我相信在座的每个人做不同的事，他对业务规则的理解是完全不一样，有的人站着高的位置，他是目标，是战略，有的人站在当中位置，这可能是战术。有的人做编程，他说这就是程序逻辑。每个人想法都不一样，我们业务规则，对我们来讲应该是这样一个概念，具有某种具体操作、执行的一种描述。我们可以

5、说目标，假设一个公司说我的目标要保持营运收入的增长，这不是规则，对我们来讲，我们不叫这个是规则，可能围绕他我们说3G业务是新的利润增长点，我们要努力开发，这也不是规则。到了下面细化，成了战术级，我说3G业务推出，我们要鼓励用户使用3G服务，这还不是规则。因为他还没有到一个具体操作，可执行的这个地步。到业务策略，业务部门说，我们要提出3G的优惠套餐，这是规模吗？这个已经非常细了，他还不是具体的规则，我们说的规则是非常具有操作力的。比如套餐，3G业务的使用者，我可以给他免六个月的使用费或者跟哪个产品捆绑，这就是规则，他有条件和描述，条件就是对某种现象的描述，执行就是做具体操作，这就是业务规则。 规

6、则，从业务角度来看都落在纸面上，如果什么样情况我该做什么样的操作，如果什么情况我给什么回扣，这是业务人员可以写在白纸黑字上。每当业务员把这个交给开发商就变了，所有规则落实了程序，脚本、数据存储等等，反正业务人员看不到，摸不着的东西。可以这样问，业务人员能看到系统跑多少条规则，你能查询到有多少规则在执行。你能够做我看规则过去有这样的记录吗。很多时候我相信运营商的计费部门说，我们所知道的就是我给他们的需求，我们所知道的，我可以看到原代码，我们所知道的就是这些东西。但是问题是，我想查询，我想管理没办法，因为都是程序。所以说业务规则从两种角度来看，他们有着矛盾。一个是业务人员的角度，另一个是IT角度，

7、这两种矛盾怎样用一种技术屏蔽掉，业务人员看到的规则是他的规则，IT人员使用实现的规则其实是一种业务影射过来的。 业务规则我们讲到这儿，他为什么多变？我们可以知道，所有的业务规则来自的因素很多，市场压力、竞争、企业的组织整合等等，都可以上你的业务规则在不停地变化，这种不停地变化，如果我们把业务规则写在原代码里，我相信大家都会知道，它的成本是太高了，而且是无法维护，将来简直是一个恶梦就是这样一回事，所以我们为什么面临这个问题？规则的易变性和多变性，决定我们要把这个事情重新思考一下，怎么思考呢？我们现在做的系统基本都有三层结构，接入层、应用层，计费、结算、客服他们可以共享数据，这种架构它解决了一个很

8、好的问题，用了一个很好的技术，这是数据库管理系统，他把数据提取出来了，但是规则还在里面、策略还在里面。你要改一个逻辑，改一个套餐，大家心里都很清楚，我需要改程序，需要花时间改程序，我可能还要测试，我还并不能保证这个规则是否能够比较正确的反映出来，业务部门也可能说，为什么我每次叫你做事情，都要改程序，难道不能配吗？这地方就是一个矛盾。这种矛盾我们现在就说，本质的症结在什么地方？就是硬代码的方式实现业务规则，使得业务规则没有办法被管理。正因为这样，使你的业务缺乏了一种灵活性，你改规则，事实上做了一个风险非常大的事情，你动了程序，而且改程序的人并不应该是IT人员，如果你太依赖IT人员管理和修改动你的

9、策略，对运营商来讲可能有风险，我的保密策略，一个促销策略也许不知道什么时候就到了竞争对手那里去。而且对运营商来讲也有一个风险，万一改程序的人离开怎么办，我是看程序，还是看我给他的文档，都不可能。所以这个症结就是我们一定要把业务规则，我前面介绍的业务规则把它从程序中拿出来，不能作为硬代码，技术脚本放在程序系统里。所以业务规则管理的基本思路就是说我把规则拿走，规则在系统之外，至于你的流程，你的展现，你的数据跟其它系统的集成还在系统里，用这样的方式，使得拿出来的规则就有很好的管理可能性。 我们举一个简单的例子，一个系统原来有很多硬代码在程序里，不同的模块，用硬代码固化的规则，现在我们提出一个概念，我

10、们应该把它放在规则库里，这个规则库和系统分开，这个是数据库还是文件系统，不是一个非常原则的问题，完全可以根据设计，但是一定在外面，有了规则库还不够，我应该再给他一个工具，管理的工具，让业务人员，让开发人员通过这个工具对规则库中的规则进行修改。在你的业务系统当中，你应该是用规则引擎，把你的固化规则在这个地方替换掉。所以业务规则管理系统有这样几个要素。规则引擎，目前在全球有很多公司都在做规则引擎，甚至有规则引擎API的标准，可以把他当做简单的JAVA和C对象，规则放在规则库，规则库是一个机制，可以是文件系统，也可以是数据库，反正是依托，我把规则放进去，规则怎样呈现呢？有一种工具，规则管理工具对他进

11、行修改。引擎做什么事？引擎的角色有两个，一个解析你定制的规则，从规则库里定制的规则解析他。整个业务规则管理系统就用这几个部分，引擎、规则库、工具，还有很重要的要素，这里没有呈现，就是规则语言，让业务人员看得到、摸得到的鬼子语言。 有了这样把业务规则技术引入来以后，我们马上发觉他的特点就出现了，首先业务人员有机会来接触他的规则，他可以通过工具来查询他的规则，修改他的规则，甚至部署他的规则，等等都可以做。第二，IT人员现在得到一个很大的解放，我们可以想象到，其实很多系统集成商为运营商做项目的时候，花很多经历是写逻辑，写什么操作逻辑、计费策略、结算策略等等，现在他这部分可以腾开，他只要把框架搭好，嵌

12、入好的引擎。至于复杂的逻辑在外面。这样他整个系统结构就会变得非常简单，而且维护性很强，对业务人员他就会说，我对IT人员的依赖少了，我有工具，可以改规则，可以查询规则，我的依赖很小。 我们就看看基于业务规则的应用系统内容是什么样？就是这张图，这个我用绿线在当中一分为二，绿线的下面就是原来的三层结构，接入层、应用层、数据层。绿线之上是规则层，把规则作为集中工具提升出来，这个对规则层中的规则进行处理，在应用层里我们对应用逻辑进行拆分，把需要规则处理的这部分用规则引擎嵌进去，规则引擎可以提供规则的执行和服务，他的基本逻辑就是这样，引擎嵌入在程序里，可以一个，也可以多个，然后数据来了以后，当你需要数据服

13、务的时候，引擎到规则库把规则加载，比如计费规则、渠道管理的规则，对你这部分数据进行处理，然后结果返回到数据库，也可能到前端。在规则这么改，改完以后，引擎可以热部署拿进来，下面的三层结构就会相对的稳定，基本我就是这样的结构，我要很好控制的是什么东西？怎样控制我的引擎，我给引擎什么规则，我给引擎什么数据，我让引擎什么时候操作，我把操作完的结果怎样拿走，导出，就是这样几个步骤。而更复杂的一些内容全部在外面，规则全部在外面，围绕他我可以进很多管理。现在可以想象得到了，规则脱离了程序，围绕着他，我们的管理有多少。首先我的规则可以被查询，可以按日期，按你所使用的类，按你创建时候的日期，创建人等等各种各样的

14、规则属性，这些内容进行查询。你可以有生命周期，规则有创建，有部署，有退休，都可以有，还有版本控制，我的规则可以一个版本，一个版本被放入规则库，我可以按某一个版本放入规则库，放到引擎里。我的模板可以就是大白话，面向业务人员的大白话，让他具有点击填数的方法解决问题，我还可以报告机制，当你规则被执行以后，我可以把执行结果的机制导入出去，这是涉及到规则管理。规则的上面可能会有工具，我有基于WEB的开发环境，我有JAVA的规则开发环境，他们共享一种规则语言或者规则语言的框架，可以为用户，业务人员定制他们所关心的规则语言，我有权限控制，有的人可以有管的权利，有的人只有看的权利，有的人对某种规则有控制权利。

15、下面可以看到，我可以调试他，我可以决定规则的关系，我可以让规则进行优化，哪些规则是经常会用到，我要进行优化。所谓的规则引擎其实一个普通的对象，他可以嵌入在不同的应用系统，你的C系统、JAVA系统，你的服务器，他让你来操作。这就是围绕规则整个的生命周期。 这种生命周期在用原代码实现的时候是没有办法想象，比如谁来创建、谁来编辑，存储在哪里，怎么报告，规则模板怎么组织，怎样付用都不可能，这是程序，现在有了，可以定义、部署、维护、退休，每个阶段都可以有很多的操作技能在上面，这样的话，我们可以出现BRMS，业务规则管理系统。我们有数据库管理系统，现在我们有业务规则管理系统，来管理运营商本身的资产，这是一

16、个规则引擎的操作，我就跳过。可能过会儿有兴趣可以了解一下。我们看到业务规则界面，那部分就是你的规则级，规则包，比如按区的计费包，批件规则包，按地区，杭州或者上海的，这是规则的组织包，他是按照你业务功能来组织他。当中可能是业务人员定规则时候，用点击的方式定义他的规则，他的规则可以是汉字、汉化的，右面可能是规则各种各样的属性，比如创建日期，规则的状态，规则的名称，规则属于谁的等等，这些属性可以在你查询中被使用到。而且可以在引擎被调入的时候使用到，也有基于WEB的开发环境，我现在规则可以注解，我可以在规则上有报告机制，作为规则，我们有这样几个模式，一种模式就是最简单的规则，如果、那么、这样的规则，什

17、么样的条件做什么样操作，比如有这样的规则，如果用户使用3G某种服务，并且又是固话用户，那么我给他固话用户多少折扣，这就是规则，如果那么。这是最简单单纯的规则。还有更复杂的规则，决策表，可能什么年龄段、婚姻什么状态，什么地区，我应该给他什么样的策略，这又是规则，组合型的。更有复杂的，规则可能有各种各样复杂的条件判断，我可能有决策数，让业务人员通过点击，拖拽选择等等方式来制定。还有规则怎么管理？规则有互斥，规则有顺序关系，规则有多选一，等等不是规则本身有的，如果我们写程序，这个规则和另一个规则有冲突，现在把规则提取出去以后，他的规则成了可以用决策流方式定义规则各种各样的关系，这个可以实现各种各样的

18、关系，有了基于规则的开发方式，我们基本有这样几个思路。第一提供工具，让用户改规则、开发规则，第二我们把规则可以保存在数据库或者文件系统里，这是用户自己决定，第三你开发自己的系统，这里不要包含复杂的逻辑，你把复杂的地方用逻辑替换，把规则用我们的方式描述出来放在规则库里，让引擎有机会拿他的规则进行处理。 这样我们开发方式发生了变化，现在我做项目开发第一定义完数据模型或者业务模型，开发人员构建他的架构、平台，怎样取数据，怎样操作引擎，怎样对引擎进行出发规则等等。另外涉及到业务人员，他可以做的，我来定规则，开发人员走了这样一个流程，从界面修改规则库，对数据进行导入等等，他涉及到编程这块，大家都很熟悉。

19、对业务人员，运营商这头，或者系统开发这头，对规则策略比较敏感的，他可以用工具直接对规则进行修改，现在我们就涉及到两个部分，一个是程序开发或者系统开发，还有一个是规则开发。两个部分可以并行进行。好处不言而喻，现在我要定规则，我原来需要运营商提出需求，然后我要进行修改程序，给IT人员编程测试，然后确认，返回来部署，最后上线，一个很长的流程，现在如果规则让业务人员直接能够操控，他只是修改、部署、上线，他的价值在这几个地方，不想强调了。 关键是我们的产品，IT整合力非常强，我可以嵌入各种不同体系架构的系统当中去，性能非常强，我后面有几张图片可以介绍。他的生产力，你的开发效率会非常高，因为你现在开发模块

20、和程序会非常简单，只是对引擎的控制。灵活性很强，是对业务方来讲，他规则可以在外面定制，而且对企业来讲，他有更强的特点，我可以把整个企业的规则集中起来。我有集中的数据库和集中的规则库。业务规则管理系统，他属于比较低级的层次，跟数据库管理系统在一个层面，他不是在上面，他是在底层，是一个基础技术。 我们看看一些案例，我们可以知道，其实一旦明白了业务规则是个什么样的概念，他是具有操作性的描述，他这种小的程序逻辑段，有这样的概念可以想象在你的应用系统中，业务规则的使用，规则引擎的使用是无所不在，到处都有，只要你觉得这个地方非常麻烦，业务策略老在变，我没有办法管理他，来查询他，也许这就是你应用的地方。所以

21、我们很多伙伴，他们在用我们引擎的时候，开始只是想到计费策略很多。但是计费有很多地方，最复杂什么地方，往往不约而同会想到从后端起来，帐务套餐很多，PTR、预处理已经死了，也许他的思路发散出去，我为什么做计费？大客户管理，客户太多，我的渠道管理，对运营渠道商怎么考核，这个都有思路，都是规则非常敏感的地方。所以这么讲，业务规则在我们今后3G业务系统当中，应该是无所不在，只是我们现在刚刚开始起步，在中国，在国外已经很成熟了，我们将来会有的事情，除了考虑流程和业务数据，我还考虑集中化规则库的机制。在计费领域，我们可以看看，传统的业务规则引擎，规则管理系统使用的地方，CDR的格式规则，CDR的相关性分析，

22、这是经常性会碰到，灵活计价和批价，现在最热门的促销、营销、欺诈、监控，这都是策略。有很多运营商，国内国外的，他们都在用到，有的运营商并不知道他自己已经用了规则引擎，比如中国移动已经在用了，可能他刚刚开始。我们有很多合作伙伴他们的沉淀当中已经使用了业务规则。他看业务规则引擎的性能有多高，目前我们有C的规则引擎，JAVA的规则激情，.NET的，电信用的比较多的C，法国电信每小时要处理400万个CDR的话单，做什么？做批价，他有150条规则在里面。Orange做计费的预处理，还有Vertel每秒1500，他做规则执行。MCI用1000条规则做告警管理和分析。 VODAFONE，他里面有一个使用我们的

23、产品，他用C的。法国电信很有意思，他使用第三方的内容计费，这个可能比较复杂，他使用我们的一个产品，对他的400万个话单进行详细的计价。这是法国电信的基本使用，他对第三方用户出具计费清单，他有一个灵活计费引擎使用我们的规则。Orange，为了解决他大性能的问题，规则引擎只是一个对象，我怎么用他由用户自己决定，他为了解决怎样使我的整个系统能够很强，他使用多引擎，多级的方式，也许不同引擎使用不同规则级，从外面加载一定的规则级，不同引擎做的角色不一样，处理数据不一样。用这种方式能够实现一天1.2个CDR话单的预处理过程。还有美国USHA，印度公司，他主要用我们的Rules做计费系统，这部分有很多案例。

24、SAMA也是，这些都是目前国际上比较知名的计费厂商。国内这张图片从我们合作伙伴那里弄来的。可以看到，国内他的计费可能有预处理、批价、分拣合帐，帐务优惠，最终帐单，我们可能在批价和帐务优惠和最终帐单用的比较多，而且他从后面往上推，为什么？后面可能优惠复杂度更高一些。帐务优惠你往上推，一个系统不可以每个地市，每个省市做一套专用定制的，最好做一套平台，把规则重新配一下，都是往前面推，这部分我们也跟比较大的系统开发商做了一些合作，好比说亚信、大唐等等做了这样的合作，也做了原形或者项目，这些都是从客户那里拿来的界面的方式，一些内容。 此外除了BSS，在电信网管上规则OSS也会用的非常多。这个不多说了，我

25、们主要看OSS网管我们规则引擎可以解决的问题，对你的故障管理进行很强的处理。目前惠普专门做故障管理，对告警的相关性处理，他里面使用的是我们C的ILOGRULES做故障管理。除此之外，我在这个地方没有解释的还有很多用户用我们的产品做渠道管理和KPI，就是考核，佣金考核、酬金计算等等，还有CRM大客户管理，都在这个方面。 如果用户有一些其他的问题，我们在外面有一个柜台，你们可以去问，更详细地了解一下业务规则管理系统的具体一些含义，一些内容，因为这方面由于时间问题，我们只能做短暂的介绍。 最后短暂介绍一下我们ILOG公司，因为毕竟这是一个跟很多公司比，我们还是一个比较小的公司。ILOG公司是一个法国

26、公司，在美国上市，也在法国上市，1987年成立，他去年才1亿美金收入，主要提供的是软件组件、业务规则管理系统，就是一个拳头产品。其实在电信行业还有其它的产品在被我们运营商使用或者系统集成商使用，目前有630多个员工，在全球有30多个分支机构，它的产品有三个，我们目前推的就是，今天说的业务规则管理技术，此外我们还有优化技术，在电信行业也会用到的优化技术，以及可视化技术在网管被中国广泛使用的产品。他的涵盖范围除了电信还有很多，供应链、电信、交通等等，这就简单的介绍。 我的总结，我们除了思考一下有了规划，我们有了项目以后，有了规划，有了系统，我们应该考虑新的技术来解决目前我们面临的一些问题，我们想提出这个概念，四层二库，除了有数据层、应用层、接入层，还应该考虑系统是否有规则层，我们除了考虑数据库，还应该考虑规则库，有了这样我们考虑用什么样的技术，其中最有名的技术应该是业务规则管理系统，BRMS。