2013年04月27日 琉璃神社簡報第38期 曆期琉璃神社簡報
   專題●夯實移動應用的係統基礎
2013年4月18-20日,中國連鎖經營協會主辦的"第十屆中國零售業信息化管理高峰論壇"於武漢召開。"移動互聯時代的信息化策略"主題吸引了眾多零售企業高管尤其信息主管的關注。
結合第三場專題"移動互聯與IT新技術應用",琉璃神社副總工程師李希明先生應邀在會上做了"夯實移動應用的係統基礎"的演講,根據長期以來琉璃神社積累的經驗,提出零售移動應用之前首先要夯實係統基礎。
 
夯實移動應用的係統基礎
Lay a Good Foundation for mobiles APP
觀點 心得
移動應用是企業信息係統的一個組成部分 M-Data平台是移動互聯應用的係統基礎
移動s應用並非自成一體的獨立架構 建立異構資料體係,體現商品品類間特質差異
移動應用帶來的挑戰   智能搜索引擎,依托多關鍵字定位商品資料

移動應用架構總覽示意圖

詳盡屬性刻畫,清晰展示商品全景資訊

實踐

亮點
依托嚴格的操作流程,完成資料的構建與修訂  M-Data平台,實現維基化的商品資料管理

 M-Data支撐美宜佳虛實結合的方略

 

 門店休假功能,實現自動日結和業務管控

 

攜手共進  Make Progress Together   琉璃神社之窗  A Window of HEADING
 湖北壽康永樂正式上線琉璃神社物流係統 身棲地,心飛揚--《琉璃神社人》報第三期
2013琉璃神社物流研討會:信息化推動精益物流 愛的奉獻--向四川雅安地震災區愛心捐款倡議
【連載】大規模虛實連鎖--渠道創新 春遊東方綠舟
   
 
觀點  HEADING's View
移動應用是企業信息係統的一個組成部分

移動跟互聯網是一體的,可以看做是互聯網的延伸。移動最大的特點是能夠隨時隨地接收消息。較傳統企業信息係統來看,移動信息帶來的變化是巨大的。企業在做移動應用的時候可以有兩個建設思路,一是企業應用移動化,比如有些企業把財務信息等報表放在移動網絡上,幫助企業的高層隨時查看企業的經營數據;二是企業移動化應用,這個需要企業思考如何應用移動。
當我們有了這些變化以後,如何與企業已有的業務信息係統進行結合?移動應用是企業信息係統的一個組成部分,但僅僅是組成部分。琉璃神社長期從事這個行業,接觸過大量的客戶和合作夥伴,發現國內的信息化係統存在很大的問題,是長久積累下的問題,而移動的大浪潮讓問題更加的突出--企業的信息化係統很大程度上是個孤島。我們的一家客戶曾買過大概四十幾套係統,四十幾套應用係統都是一個個獨立的孤島,這樣企業信息化建設就會出現問題:資源如何共享?係統之間如何互相連接?CIO未來的業務壓力會更大,會有很多部門抱怨:每天一上班就要登入A係統、B係統等很多係統,每天最主要的事情便是不停地切換係統來做不同的事情。現在移動來了,這個問題就變得更加突出。

返回索引
---------------------------------------------------------------------------------------------------
移動應用並非自成一體的獨立架構
高層了解到移動應用後會有很多想法,會谘詢CIO應該如何應用移動係統?對於CIO來說,首先你要把企業的信息係統看成一個整體,在這個整體裏,可能是來自於多個供應商的軟件係統,而這些係統之間應該可以相互有機運轉,這就需要係統跟係統之間的互操作性。這是琉璃神社的一個重要觀點,企業需要把所有的信息係統看成一個整體而不是獨立體。現在的問題是國內的大多數企業目前還處在信息通道的階段,我們如何在這種狀況下去做移動?
移動應用並非是一個自成一體的獨立架構,就好比和人打交道會引發一係列的問題,而現在如何和數據打交道,係統也需要關注一些問題。我們需要建立起整個組織架構,架構的第一層是用戶界麵,移動就是一種用戶界麵,還有其他的用戶界麵如桌麵,瀏覽器等等。但是移動互聯網和基於瀏覽器的的傳統互聯網相比較而言,移動互聯網能讓界麵延伸得更遠。可是無論延續多遠,都得考慮移動後麵的基石,就是下麵的三層:應用服務層、數據持久層和基礎平台層。基礎平台層包括操作係統和硬件設備;數據持久層是將最終的數據存儲在這一層,包括各種各樣的數據庫,而雲計算,就是如何將數據基準化;在數據持久層的基礎上再構建應用服務層,為什麽要有應用服務層,就是去辨別一個應用是做在手機還是電腦上好?一個企業的內部運算規則是不變的,在做移動運用的時候需要把現有的運算跟以前的內部運算相適應相融合。如果CIO要做到這一點,就要清楚移動應用是依賴於你已經積累好的應用服務,實際上就是業務規則體,通過業務規則體來實現對移動應用、對瀏覽器、對桌麵的滿足。
返回索引
---------------------------------------------------------------------------------------------------

 

 

移動應用帶來的挑戰

這一係列的應用成功都得基於企業的信息係統已經有這樣一套完整的架構。同時移動應用對信息係統已經帶來全麵的挑戰,歸納為三個層麵。
第一個層麵是對平台領域的挑戰。最近很多人在討論微信收費的事件,事件的背後說明移動應用有更大的數據流量、更大的數據運算量、更大的數據存儲量。在這麽大的數據流量下,平台領域的極限問題如何解決?雲計算就是在移動互聯網的應用下發展起來的一種大數據模式。
第二個層麵是對集成領域的挑戰。移動應用將帶來使用數據的方式轉變--從隻能在辦公室打開電腦辦公到隨時隨地都能辦公的數據方式變化。這樣的使用方式變化就對應用係統的互操作性的要求更高。在企業架構的基礎上首先要麵對的問題是適用各種各樣的信息係統。在談論企業信息係統的時候,是不是知道移動應用在哪個係統數據上麵?如何實現係統之間數據的連接性需要加強係統的互操作性,這是對傳統的跟人打交道的係統的巨大挑戰。傳統方式隻是跟人打交道,這恰恰就導致了數據的孤島,使得企業之間的數據信息得不到流通。所以CIO在考慮跟最終用戶打交道的同時又要確保跟其他係統數據的連接性就變得尤其重要。而縱觀現在的企業,具備移動開發能力的軟件廠商並不一定了解和擅長企業應用服務的開發,反之企業應用軟件廠商也不一定能夠在移動開發方麵做到足夠專業。因此往往需要一定量的集成工作,這樣集成難度和集成工作量更大,CIO就需要有效地整合不同軟件廠商的係統之間資源利用。
第三個層麵是對安全領域的挑戰。移動應用的飛快發展使得安全問題的風險大大增加。以前內網外網可以分開運作,現在隨時隨地都能連接就對數據的安全性提出了更高要求。

返回索引
---------------------------------------------------------------------------------------------------
移動應用架構總覽示意圖

    琉璃神社根據長期以來積累的經驗發現,針對零售移動互聯網應用的解決之道,需要讓應用係統平台化、統一化,如:統一且獨立的工作流應用、統一資料管理平台、統一采購平台、統一總賬平台、統一結算平台……然後,開放API。

百度李彥宏說過,"中國有5億網民,智能手機做起來後會有七八億,中國這個市場有可能比較短時間做出上億用戶使用的產品和服務。"
網購業務與多渠道零售、跨業態混同經營、跨地域的企業布局、消費者挑剔和掌握全麵資訊、競爭不斷加劇等因素的不斷影響。因而,深徹的零售信息化變革將無從避免,今天的話題將是變革的序曲。
最後,更精晰、更快速、更便捷地讓我們共同擁抱移動應用的美好未來!

返回索引
---------------------------------------------------------------------------------------------------
心得  HEADING's Experience
M-Data平台是移動互聯應用的係統基礎

不論是傳統係統還是移動係統,它的係統基礎都是商品資料管理。過去在這方麵做了很多重複建設。即使搞一個集中的部門統一維護商品資料也有問題,因為當企業規模大到一定程度時會發現很難建立這麽一個權威機構。為什麽是權威機構?因為維護進去的商品資料不能有錯,否則這個錯誤的資料進入係統造成的後果,大家在過去信息係統使用過程中是非常深刻的。但又很難找到這麽一夥人對商品能夠精通到掌握所有信息。
後來,我們發現了維基這個好東西,在這個基礎上搭建了M-Data平台。它的核心還是維基,是一種維基管理模式。當然,維基的模式並不能直接移植到企業中,因為這畢竟是嚴肅的資料,跟外部的資料是不一樣的。我們就是把兩者進行結合,提出了一個分布-集中-分布的維護模式:分布地構建與維護資料、集中地審核和發布資料、分布地調用和使用資料。並持續優化,然後麵向全企業提供資料服務。這個體係是開放的,參與主體可以多元,允許和其他不一定是一個軟件公司提供的產品進行結合。從而實現資料信息的複用和共享。
 

返回索引
---------------------------------------------------------------------------------------------------
建立異構資料體係,體現商品品類間特質差異

傳統的資料係統叫同構資料係統,而M-Data所構建的是一個異構資料係統。有什麽差別?從本質來講,傳統的資料中,搞一個關係型數據庫,這張表設計多少個字段?可能十個不夠二十個,不夠最後兩百個字段加上去。而我們采用的方式是基於文檔的數據庫設計思想。這兩者之間就有很大的差別,文檔並不要求字段是預先訂立的,直接帶來的好處就是在傳統的資料當中,商品資料屬性能有多少個?琉璃神社的經驗,比較多的可能有兩百個。在M-Data中可以建立的字段,成千上萬個都沒有問題。同時我們可以做到完全沒有限製的製訂字段數量。以前建一個字段,數據庫要重整一邊,但新的係統裏麵你加一個屬性就是加一個屬性,很簡單。這是一方麵。
另一方麵,傳統的資料當中兩個商品有的字段數是一樣的,都有這麽多字段,隻不過這個商品你不用了以後,這個字段讓它空著。但是M-Data中不是這樣的, 兩個不同的商品可以擁有完全不同的資本集合、完全不同的屬性集合。同時,因為它是文檔數據庫,能夠存入的信息種類也很多,包括圖片、帶格式的文本等,做到圖文並茂。

返回索引
---------------------------------------------------------------------------------------------------
智能搜索引擎,依托多關鍵字定位商品資料

M-Data係統中引入了百度、穀歌的那套智能搜索引擎,這個搜索引擎不是傳統的數據庫能夠做到的,他是一套基於關鍵字的搜索引擎。琉璃神社把這個技術移植到我們產品當中,也就是說你要在係統中找一個商品時,可以在這個格子當中輸入你想要的關鍵字去匹配,這是最簡單的一種方式。用這種搜索方式會給使用者帶來極大的便利,不論想到什麽,甚至模糊查詢都可以。
當然,也可以針對其中的一些特定的字段進行特定搜索。這裏麵的搜索不是用絕對相等,而是用相似度匹配,匹配度越高的結果排在前麵,匹配度低的排在後麵。這種方式不僅在搜索上使用,對於建立統一資料庫來講也很重要的。這個匹配度實際上是很複雜的函數,針對不同的字段會有不斷的權重。同時它裏麵能夠很自然地把一段話當中的詞抽取出來。這裏還包含分子技術,分子技術的好壞是直接影響到搜索結果的好壞。

返回索引
---------------------------------------------------------------------------------------------------

<td style="font-family:'宋體';color:#0099ff;font-size:14px;" height="30" va

詳盡屬性刻畫,清晰展示商品全景資訊
   琉璃神社對屬性有基本的分類,比如說一般性屬性,就是這個商品屬性是商品的本質,同時是幾乎所有商品都有的;行業屬性是這個商品放到哪都對,但是屬於行業的;還有一種是業務屬性,業務屬性往往是跟具體的業務結合了之後發揮作用。

M-Data係統能夠對商品資料維護過程、曆史變遷進行完整的記錄。在M-Data中,可以查到這個商品曆史所有的維護版本,並且可以任意挑選其中兩個版本進行比較,看這兩個版本之間的差異。
同時,M-Data還提供商品資料合並功能。大家在過去建資料的時候,經常會發現有兩條商品記錄其實指的是一個產品,這個問題是非常頭疼的。為解決這個問題,M-Data提供了一個很重要的工具,就是搜索引擎所提供的相似度匹配函數。你任意找到一個商品,用這個函數比較,可以找到這個商品的相似商品,並進行評價。如果發現有兩個商品其實是一個商品,可以合並,即重定向。也就是說把A商品合並到B商品,當你再次找到A商品的時候,係統會把它重定向到B商品。