讨论，保险行业佣金计算系统 - 第2页 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

从性能和可管理的角度来讲，分开是最好的。
至于分开的之后的数据同步共享问题，很简单的，因为做佣金的时候，这些数据已经固定了不会变化了，简单的根据时间戳同步一下就ok了。
而且这样做可以有效的减少核心系统的压力，增加系统的灵活性，对于大集中的业务系统，这样做最好。
我给一家保险公司设计的方案就是采用佣金人管系统分开的方式，而且据我所知，平安就是这样做得。
原帖由 feiyun3 于 2008-7-18 11:04 发表

佣金系统，需要从各个业务系统接收数据，另外根据企划案需要临时的改变定义，需要做的比较灵活。
从2003年做佣金系统的维护工作，感觉最关键的还是业务部门是否能按照基本法执行，执行的好系统数据质量高，计算佣金就准确；执行的不好，数据质量差，表间关联都不能维持，佣金计算就更不用提了
我现在就负责佣金计算系统维护工作，是独立的佣金系统，可以很灵活支持基本法，但是用户部门的数据质量，包括核心系统的数据质量不可控制，对佣金计算影响特别大。
原帖由 wzy25 于 2008-8-26 11:33 发表

从性能和可管理的角度来讲，分开是最好的。
至于分开的之后的数据同步共享问题，很简单的，因为做佣金的时候，这些数据已经固定了不会变化了，简单的根据时间戳同步一下就ok了。
而且这样做可以有效的减少核心系统的压力，增加系统的灵活性，对于大集中的业务系统，这样做最好。
我给一家保险公司设计的方案就是采用佣金人管系统分开的方式，而且据我所知，平安就是这样做得。
赞同这个说法，佣金系统和我们传统意义上的以运营流程和产品模块为代表的核心系统最大的区别就是它的易变性，在这里的“原则”是经常要为“业务”让步的。所以从全局的眼光看这里要最大限度的降低与其他模块的耦合性，在佣金系统内部进行以实现“最大灵活性”为主要目的进行构架设计。
一个不能灵活定义基本法的佣金模块（或者组件）在现今是没有生命力的，我想这也是楼上的那位老大的前任东家舍弃我的前任东家的佣金、人管模块的根本原因。（具体我不了解情况，只是个人的猜测）
[ 本帖最后由 hackjack 于 2008-8-27 11:45 编辑 ]
佣金系统暂时不可能完全灵活定义,可以定义的也就是同一基本法内按照不同地区之类定义不同指标,也就是说,新基本法出台,不可能做到定义就可以支持,复杂的在于每个佣金项的算法.不同时期制定基本法的人希望建立的团队是不一样的,这些都会直接体现在佣金的发放上.
原帖由 monicker 于 2008-8-27 10:21 发表

我现在就负责佣金计算系统维护工作，是独立的佣金系统，可以很灵活支持基本法，但是用户部门的数据质量，包括核心系统的数据质量不可控制，对佣金计算影响特别大。
这种事情没办法的，数据质量不高，和独立不独立的佣金的系统都没啥关系。。。。
佣金计算系统，分开做比较好，核心问题是系统间的借口处理好即可，对于数据来说，从核心系统中提取都没问题，关键是保证核心系统的数据的精确。整体考虑将来业务的发展，分开设计比较好。
原帖由 Rossmary 于 2008-12-3 15:22 发表

从目前的情况来看，可行性不高，因为基本法不变的主题就是不断地变化。
因为基本法不断变化，是否可以考虑用规则引擎呢？大家有谁用过规则引擎处理类似问题么？