林爾迅
(廣東電網有限責任公司中山供電局,廣東 中山 528400)
主數據構成了業務流程的基礎,在業務數據處理的整個過程中,主數據代表了公司在特定時間段內保持不變的基本數據[1],這些數據包括客戶、員工、材料以及供應商的各類信息,一旦其相關主數據不一致,則會使得業務流程發生錯誤,從而導致更高的成本輸出。但是由于目前許多公司通常使用各種應用程序來支持其服務流程[2],因此在實際處理過程中,主數據不僅缺乏一致性,而且缺乏即時性。在這種背景下,便出現了跨系統和公司邊界管理主數據的特殊解決方案和標準,各種軟件供應商如SAP、Siebel和Oracle等皆在為跨系統和集成主數據管理開發新的解決方案。
如何確保數據質量的一致性和即時性[3]是組織間主數據管理所面臨的一個普遍挑戰,相關數據的不一致使得對應的操作常常出現錯誤的響應,從而造成流程效率低下的結果,而對該現象進行人工修正的成本往往更高,基于此,不一致的主數據集通常會造成一個公司的經濟劣勢[4]。
但是在服務領域,除了主數據不一致的一般缺點外,通常還需要考慮其他挑戰,主要有以下幾個方面:(1)客戶服務必須依賴上一個服務流程的信息,如客戶主數據、保修協議和產品配置等;(2)只有通過標準化流程和唯一的客戶標識才能有效實現面向客戶的多單位一體化展現;(3)工廠的機器組成日益復雜,只有擁有完整的主數據(如產品配置、維護歷史、正確的手冊版本),工程師才能快速有效地進行維修;(4)如果要得出有關服務質量和產品改進的結論,就需要對顧客的投訴和關注進行有效地評估;(5)客戶查詢的快速響應(特別是在呼叫中心進行應答的情況下)需要具備所有客戶聯系人的最新信息和透明度。
因此,在客戶服務中,不一致的主數據會導致不正確的決策,并且會降低客戶的滿意度以及產生較高的成本。
針對此情況,可以通過將現有數據集重新協調組織成為一致的、當前的、全公司范圍的主數據來挖掘出巨大的收益潛力,例如在數據一致性的前提下節約成本;提高生產力(如通過改善電子分布節省主數據創建的時間)[5];改善客戶服務,從而提高客戶滿意度;對可能出現的錯誤報告進行及時改進。
在本節中,主要對主數據分布的架構備選方案進行簡要說明,同時對方案下的主數據系統和跨系統存儲庫進行介紹。
首先必須通過集成底層信息系統來支持分布式服務流程,因為這是跨系統邊界交換主數據的核心條件。為了有效創建分布式的主數據,可以在與信息管理組合作的實際項目的基礎上確定4種架構方案[6],同時在實踐中也可以組合不同的方案。這4種方案可以從兩個方面進行分類,一是全局主數據屬性;二是數據的創建、維護和分布。架構方案的分類如圖1所示。從圖中可以看出,中央主數據系統數據的創建、維護和分布確保了預定義流程可以正常有效地響應,但是靈活性較差。
圖1 架構方案分類Fig.1 Classification of architecture approaches
基于這種方案特點,建立一個可以將全局主數據從一個應用程序分發到各個應用程序的主數據系統,該系統下的所有子系統將全部使用相同的主數據,繼而通過全局主鍵[7]來實現對主數據的唯一標識。
由于主數據集的全局屬性總是在中央主數據系統中創建,所以數據將始終以相同的方式進行唯一創建,而且以往不在中央系統中維護的附加(本地)屬性將必須在接收系統中完成。基于這種情況,中央主數據系統將只負責核心主數據的傳輸,其系統底層中間件則主要對密鑰進行管理,因此由中央主數據系統主導發起的數據分發存在著一定程度上的異步響應,表1所示為對這種方案下主數據系統的特征進行了簡要概述。
表1 中央主數據系統的特征
根據以上說明,可以知道此方案可以對數據進行集中、標準化地創建,因此,所有鏈接的應用程序都可以擁有相同的全局主數據。但是通常情況下,修改后的更新數據只能在一段時間后才可以獲得。
對此架構方案下的主數據系統運用較為成熟的有SINFOS,其通常會提供一個中央數據池,業務合作伙伴可以通過該數據池對產品數據進行訪問,然后成員可以在SINFOS數據庫中創建主數據,并使用自己的系統對其進行校準,從而為公司范圍內的主數據池提供更好的服務方案。
接下來,對方案下的跨系統存儲庫進行簡單介紹。由于需要為所涉及的所有數據配置合理的跨系統存儲庫,因此主數據集存儲包中應該包括各種主數據集到它們的源系統之間的分配數據。例如,如果應用程序需要訪問某個客戶的具體數據信息,其便向存儲庫發送一個查詢請求,繼而接收數據庫關于該客戶數據所在系統位置的反饋,最后,其相關數據將直接從對應的系統中被調用。
同時,由于分布式數據在所有涉及的系統中都是冗余的,且每個數據集都有不同的主鍵,因此需要通過屬性的映射來確保數據可以正確傳輸到接收系統。通常,只有存儲庫接收系統中需要的屬性才可以被傳輸,其數據集中的修改也通常是異步分布的,過程如圖2所示。
圖2 存儲庫數據調用Fig.2 Repository data invocation
方案下的存儲庫可以在各個應用程序中對數據集進行分散式地創建和維護,因此在系統連接過程中,數據存儲是相對分散的。如果在運行場景中沒有數據分布,則數據訪問直接由訪問系統發起。通常各個應用程序中,主數據的主鍵是不同的,而存儲庫中則擁有每個數據集的全局鍵,并可以對其下各個應用程序的所有主鍵進行管理,因此每次的數據訪問都可以使存儲庫對主數據集進行即時性地更改訂正,從而滿足非常大的數據集訪問需求。
通過上述介紹可知,存儲庫中數據的存儲、創建和維護都在各個系統中分散進行,由于需要確保全局屬性的標準化在每個系統中具有相同的含義,且創建的屬性最少,因此需要即時向存儲庫進行數據的調用和反饋,從而有效避免因不能跨系統一致性檢查而導致的各種應用程序響應誤差,其特征如表2所示。
表2 存儲庫的特征
存儲庫方案的優點是保留了應用程序自身的自主權,使得其自身對中央系統僅有少量依賴,但是該方案仍然存在著一個問題,即不同運行過程下,數據的創建和修改是分散式的。
對跨系統存儲庫方案運用較為熟練的是全球商業計劃的全局注冊中心,該注冊中心是一個國際數據庫,其中包含了存儲在世界各地的主數據池中的全部信息。只要接收到訪問申請,便可以在各自對應的主數據池中執行對具體主數據集的訪問。
為了更高效率地讓計量數據、營銷數據快速接入業務對賬平臺,同時減少對應用帶來的性能損耗和代碼侵入,本系統通過事件模式,把業務數據變化觸發的消息(如DB變更日志數據,消息中間件消息)轉換成響應業務的事件,放入到事件執行隊列進行規則的檢查,事件監聽框架采用了通用的架構設計,實現了消息的對接,而DB日志又可以轉接到消息上,實現數據庫變更的實時監聽。
本系統平臺主要實現以下4個目標:
(1)高實時性地發現線上業務臟數據或者錯誤邏輯,第一時間發現并及時通知技術保障,而不是等客戶反饋;
(2)方便地接入各種業務規則,通過腳本規則編寫的方式,讓各應用快速接入平臺;
(3)整合訂正工具,形成規范的臟數據訂正流程;
(4)業務上線的實時監控,新上線業務可以很方便地進行校驗。
本文重點描述了在服務流程中進行主數據管理所面臨的具體挑戰,概括了協調的主數據具有提高客戶滿意度以及增強流程效率等的好處,同時以某企業的案例研究為基礎,說明了客戶和產品主數據管理是如何支持創新服務流程的。通過本文的介紹,了解了由于軟件供應商提供的產品很大程度上依賴中央主數據系統,因此主數據交換效率較慢,盡管軟件供應商針對此情況為主數據的管理提供了各種體系結構方法和解決方案,以期保證主數據的一致性和即時性,但卻仍不足以在不同系統之間“無故障”地交換主數據對象。因此,有必要促進各組織間的相互協作,使得主數據的組織間交換可以有效實現。