G端产品：信息化平台现有多个独立业务系统集成设计方案.docxVIP

G端产品：信息化平台现有多个独立业务系统集成设计方案 需求分析 1. 业务现状 根据我们调研发现，现在政府部门基本上是每个业务科室基都是多个业务系统并行（这个也是现阶段很多政府机关面临的现状，当然很多的企业也是这样的现状）处理业务。 我所从事的房产监管行业，现在的房管局现有的正在使用的由不同厂商提供的系统多达19个，这些系统分布在局里的业务科室里。因为这些系统是独立的不同的系统都是有自己独立的数据库的，同时这些数据也没有关联），往往处理一个业务需要切换到相应的系统去手动修改相关的信息，工作效率大大降低，用户体验大大降低。 2. 登录都是麻烦事儿 举一个登录场景： 小张是房管局审批处的业务员，早上吃过早餐，跟以往一样早到办公室30分钟，将开水烧好，看了一会新闻，开始工作了。 熟悉的打开最常用的审批系统，进入到登录页，快熟的输入账号和密码（有人会说，不是可以记住密码，不需要再输入吗？政府系统因保密性，极少会做记住密码之类的功能，账号和密码需要靠个人用脑子记住）。 …… 碰到一个开发企业资质变更的业务，咦，这个好像需要在另一个系统去查询这个企业的信用考评是否有问题。在收藏夹里找到地址了，又是熟悉的登录界面等等，账号和密码不记得了（这个系统不经常用到），在笔记本翻了半天终于找到了，然后顺利的进入到系统…… 多独立业务系统并行，记账号和密码都是麻烦事儿。 3. 信息孤岛 行内人士都应该知道，两个独立的系统，他们是需要建立自己的数据库的，并且如果客户的特色要求，这个两个系统的业务是不会有关联的，数据也是独立的。 以下是关于房屋交易的简易交易模型图，仅供参考。 从这个简易的交易模型图可以看出： 商品交易、二手房交易、房屋租赁等他们之间是有业务关联的，都是需要楼盘表对业务进行支撑，楼盘表是需要测绘系统导入测绘数据，这些又都需要与开发项目进行关联。实际上很多系统在业务上是有交叉的，数据上也需要相互支撑。 4. 交互规范不一致将增大误操作的几率 接触过系统的人都应该知道一个常识，就是不同的系统他们的交互规范是不一样的。交互规范的不一样会导致系统的操作也会不一样，这就会导致用户在使用不同的系统是会花费一定的时间去习惯各自系统的操作方式。 优劣势剖析 1. 项目时间紧 我在上一篇文章中有讲到过G端产品的一个特点：就是时间紧。 我们是做乙方的，甲方要求我们必须在一个月内与其中一个业务系统上线，达到统一的登录入口和通过集成门户进入到业务系统的目标。 2. 缺乏集成的经验 虽然我们公司已经做过很多大型平台型产品，但基本上集成的都是自家的产品（自家产品自己熟悉，接口文档这些都是现成的），集成别家的产品还是首次。 本人也是赶鸭子上架头一次做继承别家产品的事儿。 产品定位 产品定位：为各业务系统赋能，提供基础能力以及通用能力。 结合自身优劣势的分析和甲方的时间要求和目标，第一期需要达到的目标： 统一登录登出； 各业务系统主功能入口及菜单配置； 集成各业务系统的通知，待办，将通知和代办功能向其他系统开放，供其他子系统使用； 统一的用户体系，提供基础的用户用户组织架构以及用户管理，同时将这些基础功能向其他系统开放； 灵活性； 可扩展性。 功能边界 我们毕竟只是在做一个项目，而不是自己的产品，没有专属团队去不停的迭代更新运维，因此就决定了我们必须是一个既能满足客户现有需求，又是一个能够方便未来其他系统接入的集成平台。 我们的目标是快速高质量完成现有系统的集成，因此我们的集成平台不可能像商业平台一样（例如：钉钉）有非常全面的标准接口，也不会去这样做。 设计方案 1. 统一登录登出 集成平台首要解决的问题就是统一的登录登出，也就是用户只需要一次登录验证就可以访问其他的系统，解决了需要记多个账号和密码的麻烦。只有一个登出入口，即是一个退出全退出，避免系统A已退出，系统B还能使用，用户在离开后，没有将系统B也一并退出导致信息泄密的事故。 解决方案：平台将采用xxCAS登录实现单点登录。能够提供单点登录的厂商有很多，可以根据自身情况选择合适的厂商。 2. 通知 需求描述：集成平台集成来自党群系统的通知公告，并按照时间倒序排列，用户点击具体通知跳转进入到党群系统的详情页进行操作。 解决方案：集成平台提供接口，子系统调用接口将通知公告题目、时间、详情地址传给平台集成平台统一管理。 3. 待办事项 需求描述：集成平台集成来自党群系统的待办事项，并按照时间倒序排列。用户点击具体待办事项，跳转进入到党群系统的详情页进行操作。 解决方案：集成平台提供接口，子系统调用接口将待办事项相关内容、时间、详情地址传给平台集成平台统一管理。 4. 已办事项 需求描述：集成平台集成来自各子系统的已办事项，并按照时间倒序排列，用户点击具体已办事项跳转进入到相应子系统的详情页进行处理。 解决方案：集成平台提