幾周之前，數(shù)十位CFO齊聚加州Redwood，他們在此參加一個技術研討會，會議議題是探討財務轉型的策略。彼時，一位演講者向聽眾提問：“你們當中有多少人擔心你們的數(shù)據(jù)質量，并且明白它對于你們的業(yè)務意味著什么?”　　

與會者們紛紛舉起了手?！　?/p>

其實也沒必要感到驚訝，CFO們擔憂是因為臟數(shù)據(jù)長期以來給傳統(tǒng)財務規(guī)劃和企業(yè)績效管理(EPM)解決方案所造成的種種問題。他們擔心是因為這些解決方案不可避免的必須要與其他軟件集成，而當兩個不同的應用需要打交道時，便會產(chǎn)生數(shù)據(jù)的問題?！　?/p>

雖然已經(jīng)出席了這樣一個關于轉型的論壇，但這些CFO們?nèi)耘f感到這些年來與企業(yè)績效管理應用捆綁所帶來的巨大壓力。臟數(shù)據(jù)讓他們感到恐懼，因為在過去，軟件集成是一個艱難的過程，這個過程猶如一門黑暗藝術，需要由一位經(jīng)過特別訓練的先知指導長期而痛苦的集成過程。

在on-premise企業(yè)績效管理和分析平臺為主流的時代，軟件集成的任務通常都是由客戶自己完成。不要感到驚訝，因為這些軟件實現(xiàn)幾乎都是經(jīng)過了幾個月的周密調研而完成的硬編碼，這種私有定制不會在其他相似的系統(tǒng)上出現(xiàn)?！　?/span>

客戶沒有要求EPM提供商提供能夠輕松集成的環(huán)境，因為在這種軟件環(huán)境下，輕松集成這個目標實在是太不現(xiàn)實了。所以Oracle的客戶使用中間件，SAP的客戶使用IBM的客戶使用Websphere將他們的應用集成到一起?！　?/p>

這在應用開發(fā)之前就已經(jīng)完成了，服務和數(shù)據(jù)逐漸向云端遷移。根據(jù)InformationWeek最近一份針對云計算的調查顯示79%受訪者的業(yè)務依 賴了多種云服務。為了使得這些云應用能夠互相交互，三分之一的用戶部署了由云服務提供商提供的連接器，如SnapLogic，而41%的用戶通過編寫定制 化的腳本和利用服務商圍繞API提供的服務存根自己完成內(nèi)部和外部應用之間的連接。

我覺得這真是令人感到沮喪。云計算的非凡之處在于提供了一個越過on-premise平臺地域限制的機會。它不應該讓云服務的用戶自己去思考如何集 成他們的云服務解決方案。然而，現(xiàn)實是云服務的用戶仍舊被集成的事情所困擾。這就如同讓新買了電視機的用戶自己準備焊接工具去完成電視與機頂盒或錄像機之 間的連接，從而使電視正常工作一樣可笑。　　

當然，數(shù)據(jù)在不同的應用之間的交互必須經(jīng)過轉換。而且事實是目前在云應用集成領域沒有相關的數(shù)據(jù)識別標準。但云服務解決方案提供者能夠為用戶提供一種簡單地，甚至是透明的集成方式。正因如此，事實上軟件集成不應該是當今企業(yè)仍然需要考慮的問題?！　?/p>

換句話說，軟件集成也許曾經(jīng)在on-premise時代是令用戶頭疼不已的問題。但到了如今的云時代，應該由云服務提供商去解決這個問題。　

統(tǒng)一化，而不是集成　　

不像其他遺留系統(tǒng)，云應用使得軟件的統(tǒng)一而不是集成成為可能。統(tǒng)一化需要設計一個全新的方法，需要重新考慮不同軟件應用之間數(shù)據(jù)流的問題。并且這個過程需要對用戶隱藏實現(xiàn)細節(jié)，創(chuàng)造一個統(tǒng)一的，遵從人們工作需求的過程而不是阻礙產(chǎn)品體驗的額外的過程或步驟?！　?/p>

那么CFO們應該尋找什么樣的基于云的EPM解決方案呢?又如何構建易于統(tǒng)一的而不是集成的云應用?我想到了三個對于EPM平臺向云服務演變至關重要的屬性，并且我相信它們對于所有云應用的發(fā)展都將是具有指導性的?！?/p>

1. 不需要數(shù)據(jù)映射　　

十幾年來，數(shù)據(jù)和軟件的集成都被定義成類似的ETL(抽取Extract，變換Transform，加載Load)步驟。但是ETL天生就是受限的，因為變換(映射)的步驟需要使用一系列強制定義的規(guī)則或方法以確保數(shù)據(jù)在目標應用中仍然有效?！　?/p>

這種數(shù)據(jù)映射過程需要耗費幾個月的時間，并且一旦完成就不能改變。所以除非你能夠精確預測到未來你對數(shù)據(jù)所有可能的使用方式，或確保你的云應用不會變化或更新，再或者你的業(yè)務需求將在數(shù)年之內(nèi)都不會發(fā)生變化，否則你就不可避免的需要在未來重建數(shù)據(jù)的映射。好吧，你懂的…　　

數(shù)據(jù)映射不是一個能夠隨著業(yè)務變化而變化的過程。一個可選的方案是將數(shù)據(jù)或文件抽取出來放到一個基于云存儲的安全平臺上，例如BOX。當應用的執(zhí)行需要這些數(shù)據(jù)時，你能夠按照需求變換這些數(shù)據(jù)。而ELT(抽取Extract，加載Load，變換Transform)過程提供的是一種更流暢也更靈活的方案，讓你加載所需要的所有數(shù)據(jù)，并且按需進行變換，這樣就不需要數(shù)據(jù)映射了?！?/p>

2. 為協(xié)作而生　　

根據(jù)一份麥肯錫的全球調查顯示IDC的工作人員花費18%的工作時間用于內(nèi)部溝通和協(xié)作(如果算上通過郵件進行的溝通，這個數(shù)字將躍升至46%)。所以任何一個新的EPM解決方案必須從設計伊始就考慮協(xié)作的問題?！　?/p>

這與簡單地在云中發(fā)布一個電子表格數(shù)據(jù)使得相關人員能夠查看這樣一個任務不同。這里提到的協(xié)作指的是通過內(nèi)建機制共享非結構化的數(shù)據(jù)進行實時的協(xié)同工作，使得相關參與方能夠對同一份文檔同時進行更新、修正以及改進。這種協(xié)作能夠加快而不是阻礙業(yè)務流程。　

3. 工業(yè)級之強，卻非工業(yè)級之重　　

云服務的長處和靈活性并不能為EPM提供商免除支持復雜事務的需求。EPM應用仍舊需要經(jīng)受最嚴苛的、破壞性的、不斷增長的大量數(shù)據(jù)的挑戰(zhàn)。它們?nèi)?然需要對遺留的EPM系統(tǒng)保持不可妥協(xié)的可靠性及完整性。幸運的是，當你從經(jīng)典的軟件集成向基于云服務的一致化方向遷移的同時，能夠保留可靠性并且獲取效 率上的收益，這在on-premise策略中是不可能實現(xiàn)的?！　?/p>

基于假設的EPM實現(xiàn)方案的設計必須包含高級別的冗余性以保證在諸如電源故障或其他嚴重問題發(fā)生時良好的可用性，所以客戶必須要承擔這種冗余性所帶 來的額外建設和維護成本。而正相反，基于云服務的EPM應用天生就是被設計于正確響應可預見的或不可預見的云節(jié)點故障。所以即使是一個數(shù)據(jù)中心遭到毀滅性 的打擊也不會使你的EPM應用宕機?！　?/p>

當EPM提供商提供的云服務不需要強制用戶去關注軟件集成問題的時候，CFO們能夠更專心于他們需要真正關心的問題。不久之后，數(shù)據(jù)質量的問題將不會再令他們煩惱。這才是我所期盼的。