讨论：我们是否真正的需要一个板块或者全行的产品目录？ - 第5页 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

一个是规则平台。
三个平台配合，银行IT系统的工作就都能完成了，但是做出来的系统就千上万了。
yulita 发表于 2014-9-1 10:34

是许多树，不是一颗树
视角不同，关注目的不同，看到的树就不一样，虽然最底层都是那些金融交易和客户
如果用树，根节点只会有一个：行内产品。
正如前贴所述，树状结构如何解决产品间的多重关联关系？
ygjygj 发表于 2014-9-1 14:00

如果用树，根节点只会有一个：行内产品。
正如前贴所述，树状结构如何解决产品间的多重关联关系？
是多套树
不同树之间的节点有对应关系，这个对应关系，就是部门之间的对话，也就是通常说的统计口径，业务口径。
这些对应关系可以通过由业务人员通过用户界面去维护，改变以前都是技术人员写SQL。
panjin11 发表于 2014-9-1 09:47

以客户为中心，实际上有三个核心平台就可以了。
一个是数据库平台，
一个是工作流平台，
可能不是这么简单，有些应用是很难通过规则配置来实现的。
而且这个涉及还没有考虑客户交易、灾备、安全等诸多要求
本帖最后由 ygjygj 于 2014-9-4 23:29 编辑
yulita 发表于 2014-9-4 08:15

是多套树
不同树之间的节点有对应关系，这个对应关系，就是部门之间的对话，也就是通常说的统计口径， ...
多套树？怎样解决多套树之间节点的关系？每套树的上下节点之间只能记录一种分类关系，那两者之间的多重分类关系怎样记录哪？
理论上，树状结构是可以描述产品关系，但金融产品尤其是带有各种复杂约束的产品之间，关联极其复杂，树只能描述一种分层关系，本质上是不足的。
口头描述、自由讨论是自然连接，这已经是网格管理模式了。
ygjygj 发表于 2014-9-4 23:17

多套树？怎样解决多套树之间节点的关系？每套树的上下节点之间只能记录一种分类关系，那两者之间的多重分 ...
举一个简单例子：
第一套树A，公司部门的客户条线产品树。
有两个产品”固定资产贷款“，“流动性贷款”
第二套树B，风险管理部门的风险职能树。
有一个产品“贷款”，可以将树A的两个产品对应归属到树B的这个产品
这是最简单的情景，复杂的情景，无法只用节点直接对应，需要加入其它的维度，如客户群文件夹和机构文件，用一个树的节点，再加上几个其它维度的组合，对应另外一个树的节点。
业务部门的人员对这个非常熟悉，这里面的业务专业知识要求很高。
这里还有金融工程，范围超过通常的产品管理，是组合头寸的管理。
将同一个产品拆成多个多产品，再汇总到各自的头寸。一个头寸又可以拆成多个产品。
家住海淀 发表于 2014-9-4 18:54

可能不是这么简单，有些应用是很难通过规则配置来实现的。
而且这个涉及还没有考虑客户交易、灾备、安全 ...
工作流负责展示层，规则平台负责业务逻辑，数据库平台负责交易的完整性与安全性，灾备及系统的安全性就是完全是另一个话题啦！
也是摸记的方案吧，C银行就是这么做的。业务上肯定得有一个这样的部门，C银行是产品创新部。
不但包括产品目录，也有产品配置，当然也有那些创新的流程了。
产品目录简单，即使都不在一个系统内，同步也能搞得定。还是产品配置是最难的。灵活与好用之间，不好取舍啊。
现在是数据模型上，我认为这块NGBS里面做的不好，模型简单，就得要求应用灵活，最后导致每种产品都很难配置出来。
其实我建议像很多package一样，存款配存款的、贷款配贷款的，代理配代理的，甚至可以更细。术语就是产品配置下沉。