目前，金融行业处在深度调整时期，在服务理念、服务方式、服务策略等方面也在进行着新的探索，以往简单的建立网站、OA和交易通道的做法已经不能适应现在全方位的应用需求。然而，在探索与调整阶段，任何一步到位、指导服务模式的想法和做法也都是不切实际的。
与此同时，各个厂商提供的产品也在发生着不同程度的变革。各个应用系统开发商在逐步拓展自己的业务领域，形成了各自的整体解决方案。例如：以前开发网站系统，现在开始实施服务平台；以前销售CRM系统，现在开始实施经纪人系统；以前分销OA产品，现在开始实施知识管理系统；以前销售财务软件，现在开始作办公和多种应用系统...
在这种趋势下，各个厂商的产品出现了以下的几个特点：
概念多
例如：CRM、ERP、OA、Portal、知识管理，和传统的网站、办公、信息发布系统的概念混在一起，分支功能同质化严重，不容易区分。
系统的核心功能较弱
例如：作CRM时不作数据分析、作ERP时不作质量（KPI）管理、作OA时没有工作流引擎，作Portal时没有权限配置接口 ...
存在大量的重复功能
例如：每个系统里都有信息发布、BBS、工作计划、工作汇报、工作日志、业绩考核、用户管理、机构管理、权限控制、数据整合、公共接口、安全模块
...
所以，在目前的市场条件下，整理各个概念点和功能点，理顺自己的思路，成为需要大家把握的关键问题。
中软万维在进入金融行业解决方案市场五年多的时间里，先后在银行、证券、保险和基金等金融行业，成功的实施了网站系统、网上交易系统、经纪人系统、办公系统、人力资源管理系统、研发系统、风险管理系统和投行项目管理系统等各类应用系统。我在参与实施项目的需求分析过程中，与客户进行了大量的了解、沟通和理顺双方对项目理解的工作。下面，对工作中的一些思路整理如下：
我在为客户进行规划建议时，对于金融行业总体业务架构，可以用下面的图示进行整理和描述：
在这里，交易系统和财务系统作为两个相对独立的数据源，成为公司整体服务与管理系统的一个功能性组成部分。与此相对应的，是建立在交易系统上的整体解决方案。这两种发展方向各有利弊。但是，从IT技术的角度上，交易系统与服务管理系统应当是相对独立的。依赖于某家交易系统提供商的整体解决方案对公司IT系统的发展不利。
Portal的主要作用在于提供统一的登录界面和身份认证机制进行权限控制。无论是客户还是员工，系统提供单点登录，根据用户的权限，进入相应的WEB界面：
- 客户登录后的主界面为外部门户（outside Portal）：CRM
- 员工登录后的主界面为内部门户（inside Portal）：ERP
在这个WEB界面当中，用户可以使用各个业务系统当中自己有权限操作的各个功能。如果增加新的业务系统，用户就可以自动的根据权限使用新系统。这是企业应用集成需要考虑的问题，即建立统一（独立）的用户管理与权限控制系统，对所有的应用系统进行角色和权限的分配与管理。这里提出的是两个层次的问题：
作为实现Portal的目标，使用统一用户管理子系统就已经可以实现单点登录。如果在此基础上使用统一权限控制子系统，就可以根据用户角色的变更自动实现权限的变更。
当然，Portal的目标还不仅限于以上的描述，因为仅仅实现单点登录并不能够真正实现“门户”。从概念上讲，Portal更侧重于数据流在各个业务系统当中的融会贯通，即：
- 信息流（统一的综合信息共享机制）
统一的存储机制
统一的共享机制（Publish）
- 业务流（统一的业务流程处理机制）
统一的存储机制
统一的流转机制（workflow）
目前，国内的一些开发商，纷纷使用BEA、Oracle等厂商销售的Portal产品来实施网站。他们的问题在于：把国外实施Portal产品，实现客户层面单点登录的最终效果，当成是在实施网站。这就曲解了Portal。并且在项目实施的过程中，出现了很多需求理解和工程实施方面的问题。
上图描述，系统建设主要是包括了以下四个部分：Portal、CRM、ERP和DB Center。这四者紧密结合，形成了一个有机的整体，缺一不可。但是这些在公司里往往会出现空缺。而每一个部分的空缺都会直接导致实施具体项目的失败。
所以，在实际的建设过程中，需要逐步建立四个部分的基础，然后才可以顺利实施一对一服务、经纪人等应用系统。这样，项目的必须支持已经存在，才能够保证系统的功能实现与成功实施。
具体的应用系统基础建设至少应包括以下四个部分：
- 单点登录（Portal）的基础（统一用户管理系统）
- 外部门户（CRM）的基础（网站系统）
- 内部门户（ERP）的基础（OA系统）
- 数据中心（DB Center）的基础（业务数据整合）
如开篇说述，在目前的市场条件下，整理各个概念点和功能点，理顺自己的思路，成为需要大家把握的关键问题。这主要体现在以下三个方面：
- 把握公司IT系统的发展规划
- 考察各个开发商的真正实力
- 监控各个项目的顺利实施
希望以上对于业务架构的探讨能够对大家理顺思路起到抛砖引玉的作用。由于个人的能力与经验的限制，上述观点肯定有大量偏颇之处，请读者多多批评指正。 |
