近段时间接到一项任务——策划一个集成平台用于承载多个独立业务系统的集成门户，这东西没玩过呀，有点刺激，没成想这是个坑啊，而且还是个大坑……

需求分析

1. 业务现状

根据我们调研发现，现在政府部门基本上是每个业务科室基都是多个业务系统并行（这个也是现阶段很多政府机关面临的现状，当然很多的企业也是这样的现状）处理业务。

我所从事的房产监管行业，现在的房管局现有的正在使用的由不同厂商提供的系统多达19个，这些系统分布在局里的业务科室里。因为这些系统是独立的不同的系统都是有自己独立的数据库的，同时这些数据也没有关联），往往处理一个业务需要切换到相应的系统去手动修改相关的信息，工作效率大大降低，用户体验大大降低。

2. 登录都是麻烦事儿

举一个登录场景：

小张是房管局审批处的业务员，早上吃过早餐，跟以往一样早到办公室30分钟，将开水烧好，看了一会新闻，开始工作了。

熟悉的打开最常用的审批系统，进入到登录页，快熟的输入账号和密码（有人会说，不是可以记住密码，不需要再输入吗？政府系统因保密性，极少会做记住密码之类的功能，账号和密码需要靠个人用脑子记住）。

……

碰到一个开发企业资质变更的业务，咦，这个好像需要在另一个系统去查询这个企业的信用考评是否有问题。在收藏夹里找到地址了，又是熟悉的登录界面等等，账号和密码不记得了（这个系统不经常用到），在笔记本翻了半天终于找到了，然后顺利的进入到系统……

多独立业务系统并行，记账号和密码都是麻烦事儿。

3. 信息孤岛

行内人士都应该知道，两个独立的系统，他们是需要建立自己的数据库的，并且如果客户的特色要求，这个两个系统的业务是不会有关联的，数据也是独立的。

以下是关于房屋交易的简易交易模型图，仅供参考。

从这个简易的交易模型图可以看出：

商品交易、二手房交易、房屋租赁等他们之间是有业务关联的，都是需要楼盘表对业务进行支撑，楼盘表是需要测绘系统导入测绘数据，这些又都需要与开发项目进行关联。实际上很多系统在业务上是有交叉的，数据上也需要相互支撑。

4. 交互规范不一致将增大误操作的几率

接触过系统的人都应该知道一个常识，就是不同的系统他们的交互规范是不一样的。交互规范的不一样会导致系统的操作也会不一样，这就会导致用户在使用不同的系统是会花费一定的时间去习惯各自系统的操作方式。

优劣势剖析

1. 项目时间紧

我在上一篇文章中有讲到过G端产品的一个特点：就是时间紧。

我们是做乙方的，甲方要求我们必须在一个月内与其中一个业务系统上线，达到统一的登录入口和通过集成门户进入到业务系统的目标。

2. 缺乏集成的经验

虽然我们公司已经做过很多大型平台型产品，但基本上集成的都是自家的产品（自家产品自己熟悉，接口文档这些都是现成的），集成别家的产品还是首次。

本人也是赶鸭子上架头一次做继承别家产品的事儿。

产品定位

产品定位：为各业务系统赋能，提供基础能力以及通用能力。

结合自身优劣势的分析和甲方的时间要求和目标，第一期需要达到的目标：

• 统一登录登出；
• 各业务系统主功能入口及菜单配置；
• 集成各业务系统的通知，待办，将通知和代办功能向其他系统开放，供其他子系统使用；
• 统一的用户体系，提供基础的用户用户组织架构以及用户管理，同时将这些基础功能向其他系统开放；
• 灵活性；
• 可扩展性。

功能边界

我们毕竟只是在做一个项目，而不是自己的产品，没有专属团队去不停的迭代更新运维，因此就决定了我们必须是一个既能满足客户现有需求，又是一个能够方便未来其他系统接入的集成平台。

我们的目标是快速高质量完成现有系统的集成，因此我们的集成平台不可能像商业平台一样（例如：钉钉）有非常全面的标准接口，也不会去这样做。

设计方案

1. 统一登录登出

集成平台首要解决的问题就是统一的登录登出，也就是用户只需要一次登录验证就可以访问其他的系统，解决了需要记多个账号和密码的麻烦。只有一个登出入口，即是一个退出全退出，避免系统A已退出，系统B还能使用，用户在离开后，没有将系统B也一并退出导致信息泄密的事故。

解决方案：平台将采用xxCAS登录实现单点登录。能够提供单点登录的厂商有很多，可以根据自身情况选择合适的厂商。

2. 通知

需求描述：集成平台集成来自党群系统的通知公告，并按照时间倒序排列，用户点击具体通知跳转进入到党群系统的详情页进行操作。

解决方案：集成平台提供接口，子系统调用接口将通知公告题目、时间、详情地址传给平台集成平台统一管理。

3. 待办事项

需求描述：集成平台集成来自党群系统的待办事项，并按照时间倒序排列。用户点击具体待办事项，跳转进入到党群系统的详情页进行操作。

解决方案：集成平台提供接口，子系统调用接口将待办事项相关内容、时间、详情地址传给平台集成平台统一管理。

4. 已办事项

需求描述：集成平台集成来自各子系统的已办事项，并按照时间倒序排列，用户点击具体已办事项跳转进入到相应子系统的详情页进行处理。

解决方案：集成平台提供接口，子系统调用接口将已办事项相关内容、时间、详情地址传给平台集成平台统一管理。

5. 子系统主功能入口

在做之前，调研过其他的集成系统，他们的门户基本只是子系统的入口，并没有做到将功能集成到门户上。我们本次做的是将功能子系统的主功能集成到门户，而且还能通过权限去控制，意思即是用户只能查看到他权限内的主功能，用户通过主功能入口进入到系统。

解决方案：

1. 平台建立系统一级功能管理，由平台维护一级功能的按钮。子系统需要平台提供一级功能的名称、图标、地址等；
2. 集成平台会建立集成平台的角色体系，用于配置集成平台的功能权限以及子系统一级功能菜单。

6. 用户体系

需求描述：为方便管理用户，由集成平台建立统一的用户体系来管理整个平台所有系统的用户。

解决方案：集成平台建立统一的用户管理体系，对组织结构和用户的增加、删除、修改、查询、禁用、启用等操作在集成平台进行维护操作。集成平台向子系统提供接口同步组织结构和用户管理，由子系统给用户赋予党群系统的角色权限。

7. 角色权限

其实集成平台对于其他子系统来说也是一个独立的子系统，只不过他的主要作用是向其他子系统赋能（提供集成能力），因此也是需要用权限进行管理的。

复盘总结

因为时间比较赶，这个方案还有很多可以进行优化。

1. 登陆登出

从用户体验上来说，我们的登陆现在用的登陆账号还是采用比较常用的注册账号+密码的方式，但是其实政府部门的领导多数的年龄是偏大的，让他们去记住较为复杂的账号以及密码还是有点不习惯的。如果我们的登陆账号可以是他们的名字的话，用户体验会好很多。如果再接入人脸识别技术，通过人脸登陆，体验上也会好很多。

2. 待办事项

1. 我们现有的待办事项其实只考虑了审批的待办，而没有任务的待办，而且审批的待办也只是简单的考虑了已审批、未审批，未考虑到用户撤回的情况。
2. 我们的待办事项的实际处理过程还是在子系统内，如果我们能够直接在集成平台内处理，那么体验上也会有一个提升。

3. 用户体系

我们现在向子系统只是简单的提供组织架构以及用户的查询，向子系统提供全部的组织架构和用户。实际情况是业务可是不需要这些全量的数据，他们只需要他们可是的架构以及用户。

4. 审批流程配置

经过不完全统计政府部门的业务大多数是通过审批来完成，而且他们的审批还是具有通用性的，我们现有的集成平台还不具备向子系统提供审批流程配置的能力。

总结

要将现有的集成平台完善成能够向其他业务系统赋能的平台型产品，路还很长……

本文由@啤酒配咖啡 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unspalsh， 基于CC0协议