寿险核心业务系统设计的问题 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

仁者见仁，智者见智。这些是困扰我的问题，可能对于其他公司，这都不是什么难题。而他们另外有一些比较困惑的问题。
一、分散处理还是批处理
集中处理是基于简化一般交易的原则。但是，如果系统中有大量的批处理，协调这些批处理本身就是一个很复杂的算法。
二、如何处理冲正
对于系统设计而言，最好的方式是不用冲正，所有的错误通过流程的控制来限制。因为一个反向交易可能比同一个正向交易复杂好多倍。
但是，任何人都不可能不犯错误，复核只能限制错误过多的发生，不能杜绝错误。如果我们不希望总是要在发生错误的时候修改数据，就需要考虑冲正的问题。虽然着比较痛苦。
当然，一个前提条件是一个录入错误不应该导致不可控制的后果，例如一张保单的份数倍扩大了一百倍，随后就发生了退保，然后才发现错误。这种情况可能要考虑人为因素了。
三、如何对外围系统提供数据接口
在这方面有很多的尝试，不过感觉上成功的经验不多。最普遍的情况是提供数据的时候必须要在功能和性能之间权衡。
事实上，作为核心系统的设计，以前很少考虑外围系统的需要。如果这种需要在核心系统设计的初期得到重视，情况可能会好很多。
四、如何处理历史上的不规范数据
可能起步比较早的公司都会遇到类似的问题。
不规范的数据是隐藏在系统中的随时可能爆炸的炸弹。对这些数据清理的工作量会大到不可估量。
同时，这些数据对统计等造成的影响几乎是必然的。
五、如何校验数据
一个数据是否正确，除了涉及比较可靠的安全级别，使这些数据不会得到不谨慎的修改，在技术上是否还有其他手段校验呢？
这样的校验问题同样存在于基础数据的校验和业务数据的校验。
六、如何提供财务接口
业务系统的核心是流程，但是对于一个公司而言，财务永远是至关重要的。
七、如何适应个性化的需求
中国是一个幅员辽阔的国家，上海的情况和乌鲁木齐显然有很多不一样的地方。作为系统设计，不能指望全国在业务流程上是完全一样的。
但是这种区别会给系统的设计造成很多的影响。
最初由 iampole 发布
[B]仁者见仁，智者见智。这些是困扰我的问题，可能对于其他公司，这都不是什么难题。而他们另外有一些比较困惑的问题。
一、分散处理还是批处理
集中处理是基于简化一般交易的原则。但是，如果系统中有大量的批处理，协调这些批处理本身就是一个很复杂的算法。
批处理一定要放在空闲时间跑
二、如何处理冲正
对于系统设计而言，最好的方式是不用冲正，所有的错误通过流程的控制来限制。因为一个反向交易可能比同一个正向交易复杂好多倍。
但是，任何人都不可能不犯错误，复核只能限制错误过多的发生，不能杜绝错误。如果我们不希望总是要在发生错误的时候修改数据，就需要考虑冲正的问题。虽然着比较痛苦。
当然，一个前提条件是一个录入错误不应该导致不可控制的后果，例如一张保单的份数倍扩大了一百倍，随后就发生了退保，然后才发现错误。这种情况可能要考虑人为因素了。
提供修正程序
三、如何对外围系统提供数据接口
在这方面有很多的尝试，不过感觉上成功的经验不多。最普遍的情况是提供数据的时候必须要在功能和性能之间权衡。
事实上，作为核心系统的设计，以前很少考虑外围系统的需要。如果这种需要在核心系统设计的初期得到重视，情况可能会好很多。
这个可以通过标准的程序接口来处理
四、如何处理历史上的不规范数据
可能起步比较早的公司都会遇到类似的问题。
不规范的数据是隐藏在系统中的随时可能爆炸的炸弹。对这些数据清理的工作量会大到不可估量。
同时，这些数据对统计等造成的影响几乎是必然的。
这个，基本上只能考虑单独处理，通过数据转换到新的系统做统一了，或者单独处理。
五、如何校验数据
一个数据是否正确，除了涉及比较可靠的安全级别，使这些数据不会得到不谨慎的修改，在技术上是否还有其他手段校验呢？
这样的校验问题同样存在于基础数据的校验和业务数据的校验。
六、如何提供财务接口
业务系统的核心是流程，但是对于一个公司而言，财务永远是至关重要的。
做接口程序阿
七、如何适应个性化的需求
中国是一个幅员辽阔的国家，上海的情况和乌鲁木齐显然有很多不一样的地方。作为系统设计，不能指望全国在业务流程上是完全一样的。
但是这种区别会给系统的设计造成很多的影响。 [/B]
集中系统只提供基本的功用的功能，提供接口让分公司个性化
最初由 pullor 发布
[B]你说的这个集中系统是指只是数据集中，还是系统也集中？业务应用系统能集中吗？ [/B]
能，但先想好为什么？ 谁会干？
最初由 pullor 发布
[B]你说的这个集中系统是指只是数据集中，还是系统也集中？业务应用系统能集中吗？ [/B]
应用系统为什么不能集中？
看到过很多银行/保险公司的集中方案，但是了解下来，公开发表的东西和实际的情况并不一样，即使不涉及保密也有很多信息是这样的。
一、分散处理还是批处理
集中处理是基于简化一般交易的原则。但是，如果系统中有大量的批处理，协调这些批处理本身就是一个很复杂的算法。
这两个根本不是一个层面的问题。入单，承保可以分散处理，一些分红交易动作和报表可以批次处理。批次处理要配合合理的业务流程。
二、如何处理冲正
对于系统设计而言，最好的方式是不用冲正，所有的错误通过流程的控制来限制。因为一个反向交易可能比同一个正向交易复杂好多倍。
但是，任何人都不可能不犯错误，复核只能限制错误过多的发生，不能杜绝错误。如果我们不希望总是要在发生错误的时候修改数据，就需要考虑冲正的问题。虽然着比较痛苦。
当然，一个前提条件是一个录入错误不应该导致不可控制的后果，例如一张保单的份数倍扩大了一百倍，随后就发生了退保，然后才发现错误。这种情况可能要考虑人为因素了。
如果系统支持冲正就很简单了，每一步的操作都有严谨的日志记录，和妥善的日志查询机制。
现在主要问题是系统不支持冲正，然后再来改就比较困难。但如果愿意花很大精力和意愿的话还是有可能达到要求的。
三、如何对外围系统提供数据接口
在这方面有很多的尝试，不过感觉上成功的经验不多。最普遍的情况是提供数据的时候必须要在功能和性能之间权衡。
事实上，作为核心系统的设计，以前很少考虑外围系统的需要。如果这种需要在核心系统设计的初期得到重视，情况可能会好很多。
这个是确实存在的问题。太保设计了一IDC项目，就是外围系统集中从IDC取数据。设计思路应该问题不大。但难点是如何做好一个IDC项目。这就涉及到投入的人和资金了。
四、如何处理历史上的不规范数据
可能起步比较早的公司都会遇到类似的问题。
不规范的数据是隐藏在系统中的随时可能爆炸的炸弹。对这些数据清理的工作量会大到不可估量。
同时，这些数据对统计等造成的影响几乎是必然的。
这个问题非常笼统，我的经验是碰到问题一定要提出来，由核心小组讨论解决。非常快速的正确的给出处理方案。假以时日系统会越来越完善。不要惧怕问题。
五、如何校验数据
一个数据是否正确，除了涉及比较可靠的安全级别，使这些数据不会得到不谨慎的修改，在技术上是否还有其他手段校验呢？
这样的校验问题同样存在于基础数据的校验和业务数据的校验。
任何系统在于操作的人（使用者）和系统的限制（开发者），和一种修复机制（数据维护者）这三者一起来保证数据的正确完整性。新人和老手效果大相径庭
七、如何适应个性化的需求
中国是一个幅员辽阔的国家，上海的情况和乌鲁木齐显然有很多不一样的地方。作为系统设计，不能指望全国在业务流程上是完全一样的。
但是这种区别会给系统的设计造成很多的影响。
归纳共性，分析个性，协调业务。开发实施。
总之我觉得LZ的问题都是每家公司都日常遇到的问题。任何问题必然都是有解决的方案。问题老解决不了无非投入的问题尔。
原帖由 iampole 于 2005-1-7 08:50 发表

仁者见仁，智者见智。这些是困扰我的问题，可能对于其他公司，这都不是什么难题。而他们另外有一些比较困惑的问题。
一、分散处理还是批处理
集中处理是基于简化一般交易的原则。但是，如果系统中有大量的批处理，协调这些批处理本身就是一个很复杂的算法。
目前的批处理是最好的途径了，按业务顺序排序
二、如何处理冲正
对于系统设计而言，最好的方式是不用冲正，所有的错误通过流程的控制来限制。因为一个反向交易可能比同一个正向交易复杂好多倍。
但是，任何人都不可能不犯错误，复核只能限制错误过多的发生，不能杜绝错误。如果我们不希望总是要在发生错误的时候修改数据，就需要考虑冲正的问题。虽然着比较痛苦。
当然，一个前提条件是一个录入错误不应该导致不可控制的后果，例如一张保单的份数倍扩大了一百倍，随后就发生了退保，然后才发现错误。这种情况可能要考虑人为因素了。
冲正一般都是sql，搞一个冲正程序出来未必满足得了需求 错误无奇不有
三、如何对外围系统提供数据接口
在这方面有很多的尝试，不过感觉上成功的经验不多。最普遍的情况是提供数据的时候必须要在功能和性能之间权衡。
事实上，作为核心系统的设计，以前很少考虑外围系统的需要。如果这种需要在核心系统设计的初期得到重视，情况可能会好很多。
目前见得最多的还是写程序到核心里抓数据出来生成文件
、
六、如何提供财务接口
业务系统的核心是流程，但是对于一个公司而言，财务永远是至关重要的。
处理方式同数据接口 抓数据
七、如何适应个性化的需求
中国是一个幅员辽阔的国家，上海的情况和乌鲁木齐显然有很多不一样的地方。作为系统设计，不能指望全国在业务流程上是完全一样的。
但是这种区别会给系统的设计造成很多的影响。
还谈不上个性化 计划赶不上变化
一、分散处理还是批处理
集中处理是基于简化一般交易的原则。但是，如果系统中有大量的批处理，协调这些批处理本身就是一个很复杂的算法。
集中和分散是物理和应用层面的问题，而不是 业务处理原则的问题 。 批处理应该只系统的自动的批量处理的过程，这个不管是那个软件开发商都都有好的处理方案。
二、如何处理冲正
对于系统设计而言，最好的方式是不用冲正，所有的错误通过流程的控制来限制。因为一个反向交易可能比同一个正向交易复杂好多倍。
但是，任何人都不可能不犯错误，复核只能限制错误过多的发生，不能杜绝错误。如果我们不希望总是要在发生错误的时候修改数据，就需要考虑冲正的问题。虽然着比较痛苦。
当然，一个前提条件是一个录入错误不应该导致不可控制的后果，例如一张保单的份数倍扩大了一百倍，随后就发生了退保，然后才发现错误。这种情况可能要考虑人为因素了。
冲正的概念主要针对财务而言的。 对于业务操作产生的错误进行弥补，主要通过业务的审核制度及纠错方式来处理，这个通常在系统中也有表现。
三、如何对外围系统提供数据接口
在这方面有很多的尝试，不过感觉上成功的经验不多。最普遍的情况是提供数据的时候必须要在功能和性能之间权衡。
事实上，作为核心系统的设计，以前很少考虑外围系统的需要。如果这种需要在核心系统设计的初期得到重视，情况可能会好很多。
因为是核心系统，所以外围系统都应该围绕 核心系统来进行开发。 不过在设计核心系统中要考虑核心本身的性能问题。
四、如何处理历史上的不规范数据
可能起步比较早的公司都会遇到类似的问题。
不规范的数据是隐藏在系统中的随时可能爆炸的炸弹。对这些数据清理的工作量会大到不可估量。
同时，这些数据对统计等造成的影响几乎是必然的。
这个问题每个公司都存在，所有的数据不可能都是理想化的。
五、如何校验数据
一个数据是否正确，除了涉及比较可靠的安全级别，使这些数据不会得到不谨慎的修改，在技术上是否还有其他手段校验呢？
这样的校验问题同样存在于基础数据的校验和业务数据的校验。
六、如何提供财务接口
业务系统的核心是流程，但是对于一个公司而言，财务永远是至关重要的。
呵呵，不同业务类型对应财务的科目这一规则明确化，是影响接口好坏的主要因素。
七、如何适应个性化的需求
中国是一个幅员辽阔的国家，上海的情况和乌鲁木齐显然有很多不一样的地方。作为系统设计，不能指望全国在业务流程上是完全一样的。
但是这种区别会给系统的设计造成很多的影响。
没有绝对化的集中，大集中最后的结果就是 多个区域化的集中。根据不同地区的相似程度的集中 （本人推断：））