在前面一直在談數字化的時候一直談到連線，資料，智慧三大核心要素。即透過連線解決協同問題，同時在協同的同時完成資料的採集和集中化；其次是資料，圍繞資料驅動的運營和分析；再次是資料帶來的高層次價值，智慧化和智慧化。
前面幾年談智慧城市比較多，而當時我談智慧城市的時候，同意談到了三個關鍵點。其一是可感知，其二是可協同，其三是可智慧。感知解決萬物互聯的問題，協同解決基本的整合和業務場景聯動問題；而最後才是智慧，透過資料採集加工和分析，形成智慧。
實際你可以看到智慧城市和當前談的數字化，核心內容本質是一致的，如果再高度抽象實際是兩大關鍵內容。
其一是萬物互聯，其二是智慧化和智慧化
而在這兩者之間又有一個關鍵點，即資料，萬物互聯產生資料，而資料本身又為智慧化提供決策。資料在打通全場景中起到了承上啟下的關鍵作用。
今天準備拿智慧養老解決方案來思考下前面談到的數字化核心三要素的分析和落地過程，該文僅僅為一個參考思路，該思路你會看到在智慧城市很多細分垂直場景，類似智慧社群，智慧教育，智慧政務等同樣適用。
智慧養老概述對於智慧養老可以先看下百度上的一個簡單定義如下：
智慧養老是面向居家老人、社群及養老機構的感測網系統與資訊平臺，並在此基礎上提供實時、快捷、高效、低成本的，物聯化、互聯化、智慧化的養老服務。
如果在這個定義上做下擴充套件，則：
智慧養老應該是充分利用當前的物聯網，大資料，5G，雲計算等技術，面向居家老人或養老社群的，為老人提供生活，娛樂，飲食，健康起居全方位方便快捷，低成本，實時高效，自服務，無打擾，可預測的養老服務能力的平臺或系統。
其中最基礎的傳統資訊化軟體和工具基本基本的自動化，自服務等問題；而對於物聯網和泛終端的高效快捷，無打擾和實時快捷問題；大資料分析解決可預測等智慧化問題。
今天談智慧養老，並不是談一個智慧養老平臺需要提供哪些業務功能，而是希望從前面談到的連線，資料，智慧三要素來分析如何抓住智慧養老平臺構建的一些關鍵核心內容。
連線-萬物互聯和業務協同當談到連線這個詞的時候，很容易一下就跳躍思維到需要採用哪些物聯網技術，哪些硬體終端裝置，但是這個思路實際上並不太好。思考連線的時候仍然應該從業務角度出發，即首先應該思考清楚業務場景下的連線問題，其次再考慮如何透過物聯網技術或硬體來解決連線的固化，實時化，自服務化等問題。
我們還是拿一個養老院或養老社群，要規劃建設智慧養老解決方案談起。
我們先不思考外部協同，那麼對於養老社群來講，實際上你會看到本身分為三大類，一類是管理人員，一類是服務人員，最後是實際入住的老人。在服務人員中本身可能又包括了護工清潔類，健康保健類，後勤服務類等。
簡單畫下，即如下：
入住的老人提出具體的養老需求，管理人員規劃和安排，具體的服務人員按計劃執行，形成一個完整的閉環業務協同，解決了最基本的人和人的連線問題。
在這個過程中可以看到類似基礎設施管理，日常健康檢查管理，後廚用品採購和追溯，清潔管理，娛樂活動安排，外出管理等全部都可以納入最基本的資訊化範疇。對於最傳統的，一個養老院如果想建設一套MIS系統，基本就是上面這個思路，實現最基本的業務活動的資訊化，流程化和自動化管理。
當在談數字化和智慧城市的時候，實際上連線有兩個重點。
其一是連線範圍：就是這個連線不要侷限在企業或社群內部，應該打破傳統的邊界來看待連線，形成一種無邊界的協同能力。也就是說連線的範圍應該更加廣泛。
還是上圖，一個養老社群實際上一定涉及到了老人家庭子女，醫療保健機構，政府部門，物流後勤服務商，其它第三方服務結構間的協同，透過協同後構建了一個完整的去邊界化的大連線生態。
也就是說以後的業務資訊流應該是和外界之間無邊界觸達的，業務活動要協同，資料也要協同和整合，不能出現應用孤島或資料孤島。
老人的子女原來是定期電話詢問老人的情況，以後是直接可以實時地檢視到老人的日常起居，健康指標情況，整個資訊流應該完全貫通。包括類似養老社群的餐飲提供，從內部的餐飲管理，延伸到外部的後勤和物流提供商，形成全業務鏈協同和可追溯。
對於外部醫療機構同樣道理，老人出現什麼病症的時候，醫生可以實時，動態地查閱老人在養老社群的飲食情況，生活情況，歷史用藥情況，歷史類似血壓血糖測量情況等。
所有上面的內容都需要打破傳統邊界進行業務協同。
其二是連線的型別：也就是我們經常談的物聯網和移動終端的引入。其中終端包括了自助式的服務一體機，可移動穿戴裝置和健康檢查裝置，監控裝置，各種自動化檢測裝置，自動化採集裝置等。
各種物聯網裝置的引入解決了兩個層面的問題，一個是我原來談過的數字化中的時間和空間位移的高度統一。其二是資料採集的自動化，自服務，無干擾等。
舉個簡單的例子，你帶了一個可穿戴裝置，你每天的血壓，血糖，血氧濃度等都可以自動採集並上傳，方便後續的監控和資料分析。而這個過程全部對你沒有大的干擾。不會影響到你日常的生活起居。
特別是對於老人活動，提供無干擾的解決方案，同時透過下沉的終端裝置自動完成資料採集和錄入，是方案是否能夠落地的關鍵。
在很多傳統的資訊化解決方案裡面，都是提供大量的表單，需要人工去錄入，去跟蹤，這本身就是對規則和人的強要求，導致執行一段時間很難落地。而智慧化方案的思路應該是，你在不知不覺中就把資料採集和形成了，而不是你特意去手工錄入。
解決外部連線協同關鍵-雲平臺
在智慧城市，智慧社群等專案規劃建設裡面，一定會談到雲服務平臺。為何一定談到雲平臺，這不僅僅是簡單的智慧社群IT系統上雲的問題，而是透過雲平臺真正來實現了內外間的協同互動能力。
簡單來說，內部和外部之間不是直接連線互動，而是透過雲平臺作為核心的樞紐和中心來完成業務和資料的協同和互動。
還是拿上面的連線來說，整個架構變為如下：
當到這裡後，常說的智慧方案裡面的關鍵點就出來了。核心的IT應用和資料中心都在雲平臺上，在智慧養老社群配置了物聯網各種裝置和邊緣端閘道器或伺服器，在使用者端形成PC端，自服務機，手機端的泛終端應用。
資料-承上啟下的關鍵
在前面談數字化轉型的時候實際就在談，在透過業務系統建設，系統間整合解決了基本的連線問題，解決了核心業務價值鏈的業務流轉後。後續的重點就會轉移到資料驅動的持續最佳化改進上面。
即資料驅動的業務運作，資料驅動運營。
先談一下傳統資訊化建設的思路。
傳統的資訊化建設更多的是我有哪些業務流程和業務流程需要電子化或自動化，那麼根據這個需求開發了應用和業務功能，在功能的使用過程中逐步形成了業務資料，然後再來考慮這些資料如何進一步加工整合，勇於後續的決策分析。
即常說的業務驅動的思路。
那麼資料驅動的業務運作，整體思路就發生了改變。即我首先考慮的是我們需要什麼樣的資料來解決我們當前的運營或決策，其次再考慮資料如何透過業務或物聯網裝置材料落地。
那麼如何來採集這些資料，有些是需要傳統的業務活動或業務表單填寫來完成，有些是透過配套可移動穿戴裝置完成，有些是透過和原材料廠家供應鏈打通來完成等。
那麼我就需要按分解後的任務要求逐個去落地實施。
這就是典型的資料驅動業務。並不是說老人自己提出了我需要每天都採集血壓，我需要你每天記錄我的活動量，但是從我們最終的服務目標，我們需要這些資料。
其次就是資料驅動運營。簡單來說，同樣的道理，你的業務運作流程，業務的最佳化不是使用者提出的需求，同樣是你在資料分析和運營中發現了問題，需要改善。
還是拿前面例子來說，你會發現你最終監測的指標和資料分析結果不一致，比如血糖指標提升了很多，最終調查可能才發現是老人自己在一日三餐外攝入了大量的糖果等高熱量零食。那麼這個時候你就需要去最佳化你的業務運作。
包括我們可能給老人一個每天的活動量建議，但是這個活動量實際並不應該是一個所有老人都統一的KPI指標，而實際你應該是基於資料的分析，給出適合每個人的活動量建議。或者給出每個人的差異化飲食建議。
對於資料的問題，首先你解決的是資料採集，整合和儲存問題。
但是在很早以前在談6Sigma方法論的時候就談到，當你要使用資料的時候首先要確保你的資料本身是正確和合理的。即資料的度量系統，要先驗證資料是正確的，其次才是分析和應用。即錯誤的資料用於分析只能得到錯誤的結論。
因此解決了資料採集和儲存問題後，還不是馬上的資料應用，而是資料的加工，清洗整理，資料的規範化和標準化等。即對應我們經常說到的資料管控治理規範，標準和流程等。
在前面國資委釋出的《關於加快推進國有企業數字化轉型》一文就專門談到了資料治理的內容，而是單獨拿出一個部分來談，如下：
加快集團資料治理體系建設，明確資料治理歸口管理部門，加強資料標準化、元資料和主資料管理工作，定期評估資料治理能力成熟度。加強生產現場、服務過程等資料動態採集，建立覆蓋全業務鏈條的資料採集、傳輸和匯聚體系。
簡單來說就是構建資料治理體系是資料應用分析的大前提。
沒有好的資料治理體系，你有再多的資料也是白搭。沒有好的資料管控治理體系，那就無法形成基於資料的持續採集，處理，分析，運營的持續最佳化和改進機制。
在前面我專門寫過一篇文章，結合DCMM資料成熟度模型和各大IT諮詢公司的資料管控框架，重新給出了一個完整的資料治理框架模型，如下：
對應這篇文章詳細內容，可以參考：
也就是說當把最基礎的資料管控治理問題解決後，你才能夠說如何構建進一步的大資料平臺，進行資料建模，演算法建模和大資料分析。
當然，不論是當前談到的資料湖，資料中臺，還是大資料平臺。首先都在解決一個問題就是資料需要採集，整合，首先形成一個統一的資料儲存庫。
其次即對資料進行加工和清洗，形成可用的基礎資料資訊。
也就是說業務運作，物聯網應用等都可以有自己的資料庫，但是最終還是需要對資料按需求進行採集和集中化儲存，形成一個大的資料中心，作為後續資料建模和分析的基礎。這個和傳統的BI系統建設思路並沒有太大的區別。
只是傳統的資料庫ODS或資料倉庫，變成了當前主流的說法資料湖。
我們在這裡還是沿用資料湖的思路，但是要意識到資料在採集和整合中，要同時體現兩個方面的作用。其一是資料支援業務運作和運營；其二是資料支援分析決策。
如下圖：
可以看到大資料平臺或資料中心的構建本身就是一件相當獨立的事情。
不是你把業務類應用的資料庫統一管理起來就是資料中心或大資料平臺。同時更加不是你給一個Hadoop的技術架構就是一個大資料平臺。
當你真正思考資料這個層面的事情的時候，實際是兩個層面。
其一是資料如何支撐業務運作和運營
其二是資料如何支撐預測和決策
所以你在談到資料層面的時候，必須要去回答上面兩個問題。這兩個問題不是簡單的大資料技術平臺能夠回答的，技術平臺僅僅是工具和手段。
要回答這兩個問題，最重要的就是你的目標是什麼？圍繞這個模板你需要構建什麼樣的資料模型，然後你構建的資料模型為何能夠支撐你完成你的目標。
簡單總結就是基於目標驅動的資料建模。
強大目標驅動的原因是，你前期的大資料技術平臺可以構建得大而全，但是你的資料整合，儲存和分析一定不要大而全，而是要圍繞你的核心目標驅動逐步演進。
你越是希望構建一個大而全的資料中心和能力庫，就越是無法用起來。
智慧-從大資料分析到人工智慧
什麼叫大資料？
拿智慧養老社群來說，如果僅僅是一個社群，你即使積累很多年，包括了結構化，影片，影象各種型別的資料，哪怕是達到PB級甚至更高，你也無法叫大資料。
大資料的關鍵特徵裡面還有一個點，即你需要採集足夠多的樣本資料。我們希望採集儘量多的資料來進行分析，解決傳統機率方法中透過抽樣採集方式帶來的偏差問題。
如果你的資料僅僅侷限在單個的智慧養老院，那麼你永遠無法達到智慧和智慧的範疇。
當拿到資料後，實際我們可以做兩個方面的事情。
其一是從橫向維度進行對比，進行相關性分析。比如A社群和B社群的資料分析，60歲年齡段資料和70歲年齡段資料分析；山區資料和平原地區資料分析等等。
這些都需要大量資料採集獲取，才有相關性分析的基礎。
其二是動態時間維度分析，即我們持續地採集一個長週期數據後，進行資料的發展趨勢分析，進行相關的預測和建模。這個單一社群本身也可以做，不太受資料樣本量的影響。
第一種方式更多的是得出相關性，在你不清楚根源的情況下，給出了一些建議。而對於第二種方式則是希望對未來結果可預測，進行模型化表達，即：
y = f(x1,x2,x3....xn)
我們希望構建一個模型來表達，當影響因子明確的時候，y值本身是可以計算和預測的。這個就需要大量的資料採集，長週期的資料積累，否則無法進行建模。
還是回到智慧養老這個話題。可見的智慧化應用場景有哪些呢？
比如我們前面談到的透過資料採集和分析，自動化地調整老人的飲食搭配和運動量建議。這個就是典型的應用場景，需要進行資料採集，並基於已有模型進行分析給出建議。
而對於智慧養老裡面經常會談到的智慧穿戴裝置使用，自動健康資料採集，遠端問診，跌倒預警等等都不能算做智慧化場景，僅僅是自動化場景。
智慧化場景的重點一定是資料+模型驅動。
當從最基本的大資料分析，模型預測後，又會轉到人工智慧的高階階段。但是到了人工智慧階段並不是去執行已有的模型預測，這個模型本身隱性化了，從精確模型變成了統計學思維。
即計算機只會告訴你某個建議，但是並不告訴你基於哪個模型得出這個建議，或者說計算機本身也無法拿出一個精確模型。
還是前面的例子，我們希望將老人的血壓和血糖控制在某一個值的範疇裡面。當某天計算機給出的建議是要增加某個維生素藥片的攝入，如果從是醫生，從你以往的看病經驗邏輯，你完全搞不清為何要增加這個維生素，從微量元素檢測也不缺這個維生素，但是最終AI給出了這個結論。
當前我們談論智慧養老的時候，實際上更多的仍然是停留在大資料分析和決策層面，但是這個層面如果能夠應用好，已經可以解決很多問題。
真正要做好這個層面，需要專門的資料建模，資料分析，統計學人員，而不是要的計算機類的技術人員。也就是說資料分析和智慧化，技術平臺不僅僅是工具，更加重要的是資料模型和資料演算法的研究。
基於資料的持續分析和決策
任何一個平臺，搭建完成後更加重要的是運營，而運營核心思路是資料驅動。對於智慧養老這類應用同樣的道理。搭建平臺的目的就是為了採集和整合資料，然後在資料積累到一定量後充分利用大資料積累，進行資料分析和決策。
比如你能夠給出老人最佳的飲食和活動建議方案。其核心原因是你擁有上千萬乃至更大量的老人5年以上，乃至更長時間的資料積累。我的樣本資料足夠多，那麼我們最終的分析預測才可能足夠有效。
任何一個平臺要想持續發揮活力，最終拼的都是資料，基於資料產生的增值服務。