visualrules行业应用bpo数据处理.pptxVIP

大纲设计技术趋势设计思路基本原理总体架构接口设计实现要点技术特点产品优势应用设计用途应用范围最终用户工作变更数据处理应用输出程序变更预期效果后续扩展背景信息化现状通用问题通用突破现存问题尝试突破旗正解决方案规则引擎比较价值体现背景信息化现状通用问题通用突破现存问题尝试突破旗正解决方案规则引擎比较价值体现信息化现状基于数据库的信息化管理系统已渗透到企业运营的各个方面信息化系统需快速适应企业业务发展的变化，否则逐渐成为企业发展的障碍Excel表格数据在企业中大量使用单一系统难以支撑企业的全部业务需求，分布式的独立小系统成为企业信息化的现实通用问题需求是目前信息技术面临的最大问题需求沟通不畅。客户、管理人员、开发人员、测试人员理解可能不一致，容易误解。需求变更反应缓慢。客户理解上的小的需求变更，技术实现上可能影响巨大。对技术开发人员依赖过大。最详细的、精确的需求最终在程序员脑中或者在代码中。技术寄希望于限制需求或者预先封装变化点，但却总是对需求变化力不从心。通用问题-困惑及抱怨业务人员技术人员很难沟通技术老容易出问题需求变动总是被拒绝、或者被推迟技术人员需求总是要变动需求总是要求很急需求变动工作量太大当业务系统正式上线后，当业务需求变化时，业务部门总是希望技术可以马上实现业务需求的变化点，如果技术事先已经设计好并预留这种变化点，则可以很快对应。否则技术人员的工作量非常大，而且也容易出错。通用突破-原因及探索业务需求业务逻辑描述容易想当然采用Excel进行数据处理操作简单业务需求逻辑描述不够严谨技术实现程序语言与业务语言的差距太大技术需要多人分工处理数据层、逻辑层和界面层的实现技术人员容易误解业务采用尽可能和业务语言接近的方式来实现业务逻辑，采用技术人员、业务人员、管理人员都可以看得懂工具来定义规则。将数据层、逻辑层基础框架、界面层的实现自动化，技术人员只需要关注业务逻辑的实现，使得技术人员实现业务逻辑的工作量接近业务人员描述业务逻辑的工作量。让业务人员、管理人员也可以参与或负责业务逻辑的实现让技术人员可以减少做重复、琐碎、技术含量低的工作通用突破-优秀框架解决方法优点不足利用复用技术，重用了很多代码和组件。减轻了大量开发工作。充分利用设计模式中封装变化点的技巧，能快速适应预想的需求变化采用优秀的框架能制作出非常好的效果。业务组件的设计并实现，可以简化大量的工作。对框架的依赖大，框架的设计影响其适用面对架构师要求高，需要全面了解框架才能进行优秀的设计对业务熟悉要求高，需要预先设计并封装变化点设计模式的目的是为将来世界的模型提供变化点、处理变化的需求。好的系统设计必须考虑可扩展性、灵活性和可插入性。……通用突破-工作流解决方法优点不足实现业务上对工作流程的控制和管理。简化了流程控制逻辑的实现。简化了表单的设计和制作。粗粒度的流程图难以定义复杂的逻辑处理对于流程节点的逻辑处理，仍然需要编写代码实现用xxx开发应用软件，会具有前所未有的高效率、高质量、高适应性。其目标是让每个应用软件开发人员成为优秀的系统分析员，而不是代码的奴隶。不用写代码便能生成各种各样的应用程序。……通用突破-传统规则引擎解决方法优点不足Rete算法的复杂性决定了配置规则的学习曲线很高需要优秀的系统分析师规划设计实现规则的结构需要优秀的架构师来优化并考虑规则执行性能对数据结构的变化无能为力实现业务逻辑的可视化定义，增强了业务逻辑实现的可读性。实现了业务规则的独立管理，真正实现业务逻辑的分析。实现了业务逻辑的快速变更，与Office的配合使得业务人员可以参与业务逻辑的变更。人工智能（AI）Rete算法机器人视觉语音专家系统人工神经系统自然语言现存问题客户BPO对需求变更响应速度慢IT系统不稳定, 差错率很高(尤其是新产品上线时)；对客户业务或规则不够了解测试的时间长、联测的效率低。没有规范全面的业务规则文档、文档和程序不同步人员变动频繁（IT、运营服务都存在这样的情况），新的人员在短时间内很难对规则进行详细的了解。每个客户的规则差异大，需求变更技术改动工作量大没有统一业务规则处理流程文档，运营、开发、测试部门理解的客户业务规则不一定一致尝试突破尝试突破仍需改进从Delphi转到C#语言用设计模式思想采用新的系统结构采用新的分布式架构设计采用开源规则引擎来处理理赔规则采用新的工作流引擎业务规则实现仍然不够透明业务规则的规范化、标准化工作仍需强化保险行业数据结构和规则的共性分析仍需加强基于开源规则引擎和工作流引擎的性能仍成问题开源规则引擎实施工作量大，适用范围小旗正解决方案-实现目的业务技术将业务逻辑的实现白盒化，采用业务语言来展现业务逻辑的实现实现业务规则的完全配置化（无编码）实现增强对系统中应用的业务规则的控制和管理业务人员可以清晰了解已实现的规则，并且清楚变更规则所需要