起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識傳統企業的數字化之路：如何打造一款企業級的工作協同門戶平臺
本文從傳統企業工作協同過程當中的痛點入手，介紹了如何打造一款企業級的工作協同門戶平臺產品；列舉出了產品的核心特性，給出了產品功能的應用架構，并給出了產品成功的評價方法。
為什么要打造這樣一款產品
在傳統企業尤其是政府和大中型企業的信息化建設過程中，因頂層設計時并未兼顧或者是說當信息管理系統數量較少時，并無必要考慮各系統之間協同的問題，導致當企業所使用的信息系統的數量隨著時間的推移越來越多時（以本人曾經在某江工作的經歷為例，各業務系統的數量加起來會有37個之多），問題也隨之暴露：
各系統業務之間不能互相調用或協同工作，導致形成“信息孤島”（注1）；數據的復用性和業務的連續性大打折扣。
因信息管理系統太多造成網站Portal、賬號、密碼的存儲和管理對于個人的記憶能力形成挑戰；如果記于便簽紙上則存在著較大安全風險。
因系統過多導致的信息爆炸造成了“需要”我處理的信息和“不需要”我處理的信息混雜在一起，如何甄別和篩選出對“我”有用的信息、以及使信息不遺漏以免造成業務損失，是一件技術含量相對較低、但重復性較高的搜索和查詢類型的工作；需要耗費較多額外的“盯系統”的精力。
除以上可以直接感受得到的問題之外，打造這樣一款產品還會有以下三點好處：
- 節省空間：當信息系統較多時對于B/S架構的系統無明顯影響，但對于C/S架構的產品尤其是移動端上的應用來講，將形成挑戰?！耙苿愚k公”（BYOD，注2）早已成為現代社會職場人士流行的工作方式，但手機上安裝多個系統的APP將會占用巨量的存儲空間，且拖慢系統的運行速度，嚴重影響到軟件的使用體驗。
- 安全性的需求：在辦公移動化之后，應該設計一種方法將生活數據和工作數據分開，以避免“誤操作”將加密的工作內容誤發到私人聊天群，造成泄密事件；或者是將個人信息誤發到工作空間，給他人造成輕率、馬虎的負面影響。
- 破除溝通壁壘：在同一組織的上下級之間、部門之間，以及在各組織之間搭建溝通平臺（部門群、臨時群、外部群、業務群等），信息及時分享，以提升溝通效率和業務效率；同時避免因“屁股決定腦袋”，和自己業績相關的事務積極應對，和自己業績無關的事務敷衍了事，造成業務協同和辦事效率低下。
各信息管理系統之間因系統提供方不同、解決的具體業務問題不同，這就使各系統界面交互各異、同一事物的命名各異、流程各異，各角色你方唱罷我登場，繽紛繁雜，積重難返；迫切需要一個統一的“門戶”類產品將各系統做橫向間的有效連接，以解決廣泛的工作協同問題；同時采用統一的UI，提升品牌認知度，并降低系統的學習成本。
基于以上，一個統一的“工作協同門戶平臺”產品已呼之欲出。
工作協同門戶平臺產品相關定義
1. 工作協同
是指由人或系統發起協調兩個或兩個以上的行為主體共同完成同一流程或業務的過程。在協同的過程中，各行為主體目標一致，并在流程或業務的不同階段擔當不同的職責。以一個“學員退費工單”流程為例，涉及以下步驟：
- 由“一線客服”在客服平臺承接學員的退費請求并連接工單系統創建“退費”工單，工單保存后自動流轉至“學員督導”；
- 由“學員督導”在學員服務平臺審核學員的退費申請，并通過學員信息管理系統和訂單系統查詢學員信息、課程信息和訂單信息是否符合班級退費制度；若不符合，則填寫原因，并流轉至“一線客服”，由一線客服負責回訪以說明情況；若符合，則備注符合條款，計算退費抵扣及可退數額，流轉至“財務專員”；當數額超出設定數值時，流程抄送“督導主管”；
- “督導主管”在收到“大額”退費工單后，決定是否進行挽留干預；
- “一線客服”在客服平臺收到不符合退費規定的退費工單，組織話術，回訪客戶；
- “財務專員”在財務系統請款，將費用退至學員賬戶（這里為節省流程，省卻更高一級的審核環節）；
- 工單關閉并存檔。
可用以下泳道圖來描述以上步驟：
（學員退費流程泳道圖）
可以看到，以上退費流程經歷了客服平臺、工單系統、學員服務平臺、訂單系統、學員信息管理系統、財務系統6個系統，涉及的角色包含一線客服、學員督導、督導主管、財務專員4個角色，業務流程在做跨系統流轉的過程中，各角色在此退費處理的業務上目標一致，工作之間相互協同。
以上各角色在完成各自所屬業務時產生了跨系統的情形，如上述案例中的一線客服，除涉及客服平臺外，還至少需要用到工單系統和學員信息管理系統。
其作用是：查看工單系統以便于及時獲取工單進度，作為流程的發起人及所有者，掌控流程進度以便在利益相關者詢問項目進度時可以及時回復；查看學員信息管理系統以便在處理退費業務時依據學員的課程信息輔助決策。除業務系統外，作為公司普通成員還需要用到OA系統處理考勤業務以及使用財務系統處理報銷事宜等等。
隨著公司業務規模的不斷擴大，一線客服在處理以上業務的過程中還可能會用到倉儲管理系統，以查看是否可及時為學員寄送實物資料以及查看物流進度、需要IM工具的即時通訊能力以便當業務遇到問題需要溝通時，可及時聯系到業務相關人員（用QQ或微信也能解決問題，但在品牌建設、“歸屬感”以及信息安全上會有所顧慮）。面對眾多系統平臺，無疑降低了一線客服的工作效率，浪費了企業資源，給各角色之間的工作協同帶來了挑戰。
2. 工作協同門戶平臺
是一個匯聚了待辦中心、消息中心的工作門戶平臺，存在的目標是最大化地減少對各系統的訪問，使用戶在統一的工作門戶平臺上解決所有工作協同的問題，最終降低協同成本，增加辦事效率。
仍以上述案例為例：在工作協同門戶平臺上連接所有的信息和業務系統，各角色均在工作協同門戶平臺上相互協作；使用待辦中心處理所有的待辦業務，使用消息中心發起即時通訊，而無須再去分別訪問其他業務系統或使用其它IM工具發起溝通。
修改后的泳道圖如下所示：
（改進后的學員退費流程泳道圖）
可看到，系統改進后，所有的角色均在工作協同門戶平臺上處理退費工單業務，由工作協同門戶平臺自行處理與其它系統的接口對接問題，由消息引擎（Msg Center）驅動待辦中心的運作；工作入口高度集中化，用戶不再需要訪問其它系統平臺，極大地簡化了用戶業務操作體驗。
工作協同門戶平臺產品所應包含的特性
1. 核心特性
（1）可連接性
以工作協同門戶平臺為核心，連接用戶日常工作所涉及到的所有系統和系統業務，如郵件系統、OA、HRM、工單系統、公文系統、采辦系統、ERP系統、財務系統等等，使各系統業務均可以通過工作協同門戶平臺感知并處理。
（2）可擴展性
遵循MVP原則（Minimum Viable Product，最小化可行產品），鑒于所要連接的系統數量眾多，在產品的第一階段可優先連接核心系統和關鍵業務，并保證可用性、易用性和產品價值；后續跟隨產品迭代再加入更多的系統和業務，以相同的方法實現業務系統和業務流程的有序擴展，最終達成所有系統和所有業務流程的全面覆蓋。
（3）待辦中心
在工作協同門戶平臺上建立待辦中心，其關鍵能力是偵聽和感知所有與當前用戶關聯的業務流程的流程節點、流程狀態變更、會話消息和系統消息、業務通知等等，使當前用戶只需要在工作協同門戶平臺上就可以完成業務的完整生命周期的跟蹤和處理（創建、審核、會審、關閉等，依業務不同節點名稱會有所不同），并可查看業務處理的統計報表。
（4）消息中心
消息中心的作用是實現系統與人、人與人之間的及時連接，解決的是及時性（Instant）和發散性（Divergent）的問題，以直觀的、聊天會話（Conversation）的方式溝通和解決流程之外的隨機問題，以文字、語音、圖片等類型的消息以及消息上所附加的情感建立人與人之間的情感連接，在溝通中消弭理解偏差、澄清問題本質，促成業務最終達成。
2. 其他特性
（1）應用中心
包含應用和工具的創建和管理，如項目管理、日程管理、任務、投票助手、會議室管理、考勤等等，用輔助工具涵蓋用戶工作日常，提升用戶業務效率和管理效率。
（2）易用性
各類型客戶端設計遵循面向C端產品設計的原則，注重用戶體驗。各客戶端的設計使符合Windows、Mac、Android以及iOS通用產品設計規范，以降低用戶學習成本，使用戶更容易上手。管理平臺的設計使用成熟方案如基于Ant Design設計的React UI組件庫，兼顧易用性、低成本、規范化和高效率。
（3）移動化
在機場、餐廳、酒店或者是車站、大巴等非公司環境下的移動辦公場景，在收到協同請求時，為了可以做到即時響應，要求在移動設備上可即時處理業務請求，使不受時間、地點、人員、設備和網絡環境的影響。試想一個場景：員工請求正在外出的領導及時審核一個合同，合同金額千萬級別，如果未及時批復的話就有可能被競爭對手搶得先機。
領導說：“等我一下啊，我找一個有wifi信號、并可以使用筆記本電腦的地方登錄后再給你批復….”
——上不上火、刺不刺激？
設計思路
結合以上產品特性，我們來構建工作協同門戶產品所需要包含的產品能力，產品的應用架構如下圖所示：
（工作門戶協同平臺應用架構）
1. 產品前臺
（1）工作看板（Dashboard）
工作看板是用戶登錄客戶端后默認顯示的第一個界面，含義等同于HOME、First Page。工作看板承載了待辦中心、通知、數據看板、新聞推送以及其它系統訪問入口的功能。在消息引擎（Msg Center）的支撐下，要求具有承接待辦、通知、數據卡片消息推送并顯示的能力。
對于從工作看板訪問其他業務系統的情形，要求工作看板具有SSO一鍵登錄的能力，避免用戶重復輸入登錄賬號和密碼。
（2）待辦中心（Todo Center）
待辦中心集成在工作看板中，用于顯示用戶所有待辦和已辦的事項。要求在處理待辦事項時具有不跳轉至其它系統頁面而實現接收和處理所有業務流程、項目、日程、任務和工單的能力。
- 業務表單發起/查看/處理的能力：在收到業務信息時對業務表單解構，業務處理完畢后重構表單并回傳至原系統。還應具有表單自定義的能力，以便根據業務不同自定義不同的表單；以及預置通用的表單模板。
- 可視化工作流：流程可以自定義，人員可選擇、可加簽、可轉簽；審批可撤回、可退審；節點時效可定義。
- 業務信息調用的能力：除調用主數據（MDM）之外，還需要能夠調用業務信息比如工單處理時需要查看位于學員信息管理系統的學員信息、課程信息和位于訂單系統的訂單信息，以及位于學員服務平臺的服務軌跡信息，以便輔助決策。
在流程進度查看和業務信息調用時可自動登錄并做業務訪問權限判斷。
（3）消息中心（Message Center）
會話管理：管理所有單人會話和群會話。
會話交互：基于消息引擎，支持單人聊天和群聊天，具有文字消息、語音消息、表情符號、視頻會議、截圖、文件共享等業界通用的IM的能力。
除通用IM能力外，還應具有體現職場場景的特有的IM的特性，比如消息轉任務、已讀/未讀標識、消息回執等。
（4）組織架構（Organization）
以分層結構顯示組織和部門的組織架構；在組織查看和人員管理方面提供全局視圖。
（5）應用中心（App Center）
展示企業郵箱、項目計劃、日程、任務、投票助手、會議室、考勤等應用，在管理后臺進行應用的生命周期管理（創建、啟用、刪除，以及權限設定），在客戶端上使用應用，覆蓋用戶工作日常。
（6）個人中心（Personal Center）
個人資料設置、系統設置、關于信息等。
（7）管理平臺（Management Backend）
賬號管理：對成員賬號的增、刪、改、查、停用、啟用全生命周期管理；
應用管理：應用的創建、刪除、啟用管理和接收、發送、顯示權限的配置；
安全設置：包括水印功能、密碼管理等；
數據統計：數據指標的顯示如上線數、上線率、應用訪問統計等；
設備管理：對PC客戶端和移動客戶端進行登錄管理和本地數據管理等。
2. 支持中臺
（1）消息引擎（Msg Center）
消息隊列管理，支持點對點模型和發布/訂閱模型以滿足不同系統的消息對接能力需求。連接待辦中心和各業務系統接口，在系統之間實現語義準確的異步數據傳遞，并為消息中心接收方和發送方提供中間件支持。
（2）統一登錄（Passport）
用戶只需要登錄工作協同平臺，就可以直接訪問工作看板中所有已對接過的信任的系統，無須再次輸入賬號和密碼訪問。
（3）權限和認證（Auth）
權限管理和賬號統一身份認證；提供賬號在各業務系統的基于角色權限的訪問控制（RBAC：Role Based Access Ctrol）；提供功能權限和數據權限的權限管理和配置能力；在用戶訪問各業務系統時拉取權限配置Profile以決定能否訪問或僅訪問哪些功能和數據。
（4）組織架構（Org）
組織架構管理；供各業務系統調用統一的組織架構的能力。具有與賬號中心的組織架構保持單向或雙向同步的能力。
（5）賬號管理（Account）
對組織中所有賬號進行統一管理，包含賬號的創建、刪除、啟用、禁用等，賬號信息記錄于主數據（MDM）中，并依各系統的具體詳情，提供單向或雙向賬號同步的能力。
（6）郵件服務（Mail）
提供給各業務系統郵件配置和郵件收發的能力。
3. 數據底層
（1）BI
工作看板中當需要展示特定業務系統的數據圖表，如展示工單處理結果報表時，需要建立特定系統的數據倉庫（DW：Data Warehouse），并提供BI（Business Intelligence）能力，以便對工單數據和客戶資料進行全面分析。
（2）Data Mart
提供數據集市DM（Data Mart）能力，以便根據各業務系統數據需求的不同封裝出各數據子集：DM1/DM2/DM3……以滿足不同業務系統數據指標的需求，同時減少即時計算量，提升數據呈現的性能。
（3）MDM
解決信息孤島問題的經典策略就是建立主數據管理（MDM）。通過應用架構的拓撲設計，幫助各系統存儲和識別唯一關鍵數據，避免關鍵數據的冗余和非一致性的問題。
和主數據無關的各業務系統的業務數據可分別保留在各業務系統中，無須和MDM同步。各業務系統在做賬號管理時，賬號信息按照主數據域和業務數據域分別建設。
功能界面
以下我們來展示功能界面，大概的功能界面如以下草圖所示：
（1）Dashboard-工作看板
工作看板中放置Banner、新聞中心、待辦中心、數據報表、各系統入口卡片；并可根據個人喜好進行卡片排序。待辦中心匯聚了各業務系統需要我處理的待辦事務，包含應用下發的消息、業務流程消息、任務、日程、項目進度、新郵件等等。所有待辦事務均可點擊查看業務詳細，涉及流程進度的可點擊查看流程進展。
（2）Message Center-消息中心
包含會話列表管理和會話交互界面，采用類似于微信和QQ等通用的會話交互界面設計，以降低用戶學習使用成本。
（3）Organization-組織架構
以分層結構展示組織的組織架構樹。焦點選中賬號時，展示個人名片。
（4）App Center－應用中心
展示個人權限范圍內可見的各應用。APP STORE準許個人將更多的應用添加到應用中心以滿足個人工作需求。
（5）Individual center-個人中心
包含個人資料、系統設置和關于模塊。
（6）Management Backend－管理后臺
含數據首頁、設備管理、賬號管理、應用管理和安全設置模塊。
如何評價產品的成功
與C端產品關注用戶數、注冊數、活躍度等指標不同，作為B端產品解決方案，產品關注的是業務效率的提升、管理成本的降低以及信息和數據是否安全。B端產品往往為自上而下式或者以行政命令的方式進行推廣，因此代表C端產品成功的標志“用戶數量超過百萬”等并不意味著B端產品也是成功的。我們需要尋找其它代表B端產品成功的方法。
我們可以定義以下指標的增長來考察B端產品的價值，在制定指標時偏向于“結果性指標”以使指標結果可衡量：
- 業務系統覆蓋度（=已接入系統數/信息系統總數*100%）
覆蓋度越高，代表著系統的統一度越高、作為“門戶”的作用越明顯；隨著指標數值增加用戶訪問其它系統的數量也會減少，增加了業務處理的便捷度，節省了系統間的互操作時間。
- 核心業務覆蓋度（=已接入業務數/所有系統業務總數*100%）
最終的目標是要將所有系統的所有業務都通過工作協同門戶平臺來處理；與業務系統覆蓋度指標相同，體現了的是產品作為“門戶”的作用，通過業務處理的“匯聚”來提高體驗度和節約用戶的互操作時間。
- 業務響應效率
在產品部署之前及之后進行數據埋點。計算產品部署前后業務總體響應效率是否有所提升：從創建開始，到審核、批準、完結每一個環節的響應和執行時間是否有所提升。
要注意：
- 數據量比較小時是沒有意義的；
- 業務執行效率可能會受到其它因素影響（例如流程的優化和升級）。
因此建議做整體考量，以免以偏蓋全。
產品成熟度曲線如下圖所示：
（產品成熟度曲線）
在新產品引入之前，舊產品的易用度處于一個較低水平。在新產品引入伊始，因采用MVP策略以及初期產品可能只是集成了部分系統和部分業務，仍然會有跨系統處理業務的情形發生，甚至原系統中相類似的業務反而要在兩個系統中分別處理的情形，這個時候新產品的易用度反而是下降的。隨著產品的不斷更新迭代，易用度會呈現出一個上升曲線，直至產品進入穩定的成熟期。
所以，看到低谷時也不要灰心，尋找rootcause，保持產品初心，堅持迭代的目標不動搖，就一定會成功。
總結
如何做數字化轉型是每個傳統企業在數字化和信息化過程中所必須考慮的問題。轉型不僅僅是引入一兩個“表面光鮮”的系統，而是應該在業務流程、業務模式、工作協同、組織架構、人員管理、公司戰略等方方面面進行深入思索和重新定義，才能夠引領企業走向輝煌。
注：
- “信息煙囪（information silo）”： 又稱為“信息孤島（information island）”，是指一個“孤立”的計算機應用系統，與其他計算機系統在功能上不能關聯互動、信息不能共享以及業務流程之間相互獨立。
- “BYOD（Bring Your Own Device）”：指攜帶自己的設備辦公，這些設備包括個人電腦、手機、平板等，在機場、酒店、咖啡廳等非公司環境登錄公司郵箱和辦公系統，不受時間、地點、設備、人員和網絡環境的限制。
本文由 @神馬B端 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
織語