近段時間接到一項任務——策劃一個集成平臺用于承載多個獨立業務系統的集成門戶，這東西沒玩過呀，有點刺激，沒成想這是個坑啊，而且還是個大坑……

需求分析

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協議