开贴说说老胡理解的核心系统，错误的地方多指正

wangqi1980

SAP的核心独特。有它的成长发展的过程。
但不能用它的方案设计诠释主流的核心系统。

偶忙去了。有空再聊。

家住海淀

老王，我们将来不会选择SAP的系统。
为啥我一来你就撤呢？伤心，老胡也走了

wangqi1980

没走。下回聊。

家住海淀

项目可能近期预热准备，如果可能会及时更新帖子，不方便的时候会更新围脖

janze

从核心系统的基本模型来看，帐务、价格（利息和收费）、合约和产品是中心，由于管理的需要，现在看起来趋势是会把客户和流程模型，加入到整个系统中（注意：未必是加入到核心系统）。而且，由于交付渠道的急剧增加以及管理数据采集的需求，也增加了要求集成核心和其他系统的需求。
从老胡（或者应该叫小胡？）提供的几张图来看，都没有解决一个根本的问题：产品、合约、客户和流程是贯穿在整个银行业务的生命周期的，换句话说，在核心系统对合约模型的一个改动因该会影响到客户网银操作的系统行为，会影响到BI系统的数据分析公式，如何创造一个足够弹性的系统架构（模型）来容纳如此高的灵活性要求，是未来核心建设需要解决的根本问题。
更大程度的集成，消灭信息孤岛，提供更加准确的控制，获取更加细致的数据，是信息系统建设的永恒的主题。银行IT建设中问题的根本也往往在于系统间集成的难度。
从传统行业来看，ERP 的道路就是集成的道路。那么，银行的道路是什么呢？
纯属个人见解，见笑。

kinghq

对于信息集成，我有朋友在电力是搞CIM的，按照OO的思路搞同源建模，在某局初见成效并得以推广支持。如果以数据模型为基础的，他这个实践也可以在其他地方推广。这样对大家来说可以共同努力于这个数据模型，这也是他在CIM上的努力方向。

至于说“模块化”和“功能单一化”，有这么几点想说：如果是“什么东西模块化”，“什么东西功能单一化”，这样可以凝聚大家的心力更好探讨，甚至解决实际问题；“模块化”作为建筑项目质量很重要的基础（事实上，即使作为建筑项目来说，其模块化的内容也是在变化的），在面向过程的时候经常会被提到，在面向对象的时候，经常会提到封装、接口、继承等这些的，这些个体现的是“功能单一化”；在实际项目中，更多的是一种取舍，但是对于整个事情来说，取舍什么不重要，取舍的原因才重要——因为知道了这个原因才能够在情况发生变化的时候知道需要做些什么。

其实，不管是数据模型还是知道取舍的原因，都在于有没有一个总体的把握在手——这样想统一就统一，想一统就一统，都是自己说了可以算的。能说明这个总体把握在手的，就是那些负责“规划”某部分落实的人是否时刻能够说出一致的总体“规划”来。其实只有这样才能对情况发生变化采取很灵敏但不过敏的反应。

家住海淀

原帖由 janze 于 2011-8-30 01:19 发表
从核心系统的基本模型来看，帐务、价格（利息和收费）、合约和产品是中心，由于管理的需要，现在看起来趋势是会把客户和流程模型，加入到整个系统中（注意：未必是加入到核心系统）。而且，由于交付渠道的急剧增加以及管理数据采集的需求，也增加了要求集成核心和其他系统的需求。
从老胡（或者应该叫小胡？）提供的几张图来看，都没有解决一个根本的问题：产品、合约、客户和流程是贯穿在整个银行业务的生命周期的，换句话说，在核心系统对合约模型的一个改动因该会影响到客户网银操作的系统行为，会影响到BI系统的数据分析公式，如何创造一个足够弹性的系统架构（模型）来容纳如此高的灵活性要求，是未来核心建设需要解决的根本问题。
更大程度的集成，消灭信息孤岛，提供更加准确的控制，获取更加细致的数据，是信息系统建设的永恒的主题。银行IT建设中问题的根本也往往在于系统间集成的难度。
从传统行业来看，ERP 的道路就是集成的道路。那么，银行的道路是什么呢？
纯属个人见解，见笑。

还没有展开，高阶和低阶两个层面，除了总体规划外，还要从不同的业务条线和主要系统分别进行专项规划，否则如何落地。
而你说的部分集中于专项规划中，新的核心系统设计的思想是以客户为中心的，产品销售为核心的，关于定价、产品规划与管理、销售、服务、渠道整合都会逐项进行描述。

kinghq

原帖由 家住海淀 于 2011-8-30 11:35 发表

还没有展开，高阶和低阶两个层面，除了总体规划外，还要从不同的业务条线和主要系统分别进行专项规划，否则如何落地。
而你说的部分集中于专项规划中，新的核心系统设计的思想是以客户为中心的，产品销售为核心的，关于定价、产品规划与管理、销售、服务、渠道整合都会逐项进行描述。

大量的Paper工作呀，希望多分享Papering中的收获和感受，这个可以是不保密的吧。至于“如何落地”，用GAP的方法是可以直接落地的；但是如果按照传统的PMO形式的话，估计这轮Paper完了，还有Paper——至于什么时候能落地，到时候免不了还得拍拍脑袋。这让我想起了之前经常开会到凌晨的恐怖岁月。

eliasyue

原帖由 janze 于 2011-8-30 01:19 发表
从核心系统的基本模型来看，帐务、价格（利息和收费）、合约和产品是中心，由于管理的需要，现在看起来趋势是会把客户和流程模型，加入到整个系统中（注意：未必是加入到核心系统）。而且，由于交付渠道的急剧增加以及管理数据采集的需求，也增加了要求集成核心和其他系统的需求。
从老胡（或者应该叫小胡？）提供的几张图来看，都没有解决一个根本的问题：产品、合约、客户和流程是贯穿在整个银行业务的生命周期的，换句话说，在核心系统对合约模型的一个改动因该会影响到客户网银操作的系统行为，会影响到BI系统的数据分析公式，如何创造一个足够弹性的系统架构（模型）来容纳如此高的灵活性要求，是未来核心建设需要解决的根本问题。
更大程度的集成，消灭信息孤岛，提供更加准确的控制，获取更加细致的数据，是信息系统建设的永恒的主题。银行IT建设中问题的根本也往往在于系统间集成的难度。
从传统行业来看，ERP 的道路就是集成的道路。那么，银行的道路是什么呢？
纯属个人见解，见笑。

一点自己的看法
1。价格也可以看成是合约的一部分吧。利息和收费通常也会在订立合约时确定。
2。账务的处理也应该独立于产品。比如贷款转让，资产证券化等业务，与客户签订的合约本身没有变化，但银行内部则需要进行帐务处理。

cavern1026

原帖由 wangqi1980 于 2011-8-29 15:29 发表


“功能组还在前端，后端系统都要功能单一化”, 这个特点有点像SAP的核心系统。

听说SAP的核心系统，把很多功能都拿到前端（or前置）上实现。

但是，这是SAP的核心的独到特点。其它厂商不然。

By the way, 老胡是民生行的吧？

这种思路是民生新系统的做法