所以你們有兩個點，也就是前鎮的點跟南港的點？

是，南港在育成中心。其實我們公司已經成立12年了，這也是發展的時間，研發中心在高雄，之前發展策略不是設定在市場運作上。

就是有軸轉過？是要解決社會問題為目的？

對，我們發展出一個資訊的方法，是方法的改變，直到去年，我們才認定真正可以開始投入市場運用。

目前，主要的客戶群是醫院，從2007年醫院評鑑制度推動開始，發展出企業內容管理的概念，協助他們做日常工作的資訊整合，這個是我們三大主軸技術的其中一個，也就是企業日常工作真正做到資訊化、自動化管理的那一部份。

除了企業管理之外，還有一個是決策支援，跟外面不一樣的是在技術突破，我們以全新專利工法發展出一個BI tool即時商業智慧，不同於Power BI之類工具。

所有的人都用Power BI。

對。但對我們來講，還是看到實務落差，因此我們從底層去改變，改變了傳統BI的資訊工法，發展出了一個，線接上去之後，所有的事情就完成。

你不用自己建模的意思嗎？

對。

資料模型是由使用者按照他的需求去拖拉，像物件的概念、形成資訊自動化，圖型化能力除了自主分析，已經可以做到探索分析，內建分析模型，方法都已經內建在裡面了，只要選擇我要的模型，然後套上連結上去的資料來源之後，就會開始進行像柏拉圖、回推24期、同儕管制圖、比較分析等等的交叉分析。

理解。

這是第二個部分。可以自動建模及探索分析依靠的是「資料走動管理模組」專利技術，傳統的方法需要有很多的技術投入，克服資料到資訊間的技術過程，但因為這個專利，中間的部份都被封裝起來，又可以達到自動化，就是這關鍵突破，才衍生出三個主軸服務。

理解。

第三個是資訊整合。資訊整合現在正在醫學中心進行中，從醫院的研究教學、個案管理的部分，然後到各種檢驗檢查，非常多分散的資料，需要藉由一個平台來把所有的資訊整合起來，這是我們目前在醫學中心一直持續驗證的，也都持續發展出成效來。

今天主要的目的是，說明整個發展的過程，十幾年的時間，為什麼我們還停留在育成，這中間有兩個主要考量，一個是堅持，也就是東西還沒有完整就推出去，會造成企業更大的困擾，第二是完整，企業經營管理多樣性、多變化，還有人的問題，原本是人工運作的流程，如果中間切一段資訊，但前後還是人工的話，就不是完整的資訊平台。

所以最終要打造的是CMS，也就是真正把企業日常工作，關於資訊的部份都在平台上運作，包含資料權限、工作指派分工、資料收集、稽核，還有管理規範、流程管理、決策支援、資訊整合。

以目前來看，產品、技術都已經到達一個階段，為什麼還在新創？資訊研發的投入，我們是以技術為核心來的作很多的發想，從接觸資訊到現在已經三十五年的時間，一直在做的事情很難說清楚，當然這不是今天主要的目的，今天談的是資訊分享，這整個發展的過程，希望結果能慢慢讓環境接受，越到後面階段，已經形成具體的解決方案，我們現在還持續在突破各種可能性，希望對產業發展帶來全新的服務能量。

今天的拜會行程，其實我一直在思考談的方向跟內容。從兩個部分：一個是技術研發核心；另外一個是發展技術過程所衍生出來的東西。因為委員在技術上的能力，今天就是來看…，好像也沒有訂目標，不知道目標該訂什麼。

沒有關係，就先互相瞭解。所以您剛剛所說的醫學中心，有跟哪一個或者是哪幾個合作？

一開始是高醫、奇美、成大，中間我們的策略開始轉型，因為我們主要是以研發為核心，所以開始跟原本提供資訊服務的系統廠商合作，他們做前端接觸客戶，我們開始做技術輸出，然後協助他用這個工具來做資訊整合服務的部分。

你們並不是派人去高醫、奇美、成大運行或者是導入，而是由SI來幫你們導入，是這個意思嗎？

還不到這個階段。因為既然是新的技術，原本市場上的技術人力都需要新的學習，儘管發展出新的資訊語言，可以非常快速做到前端異質資料、流程跟文件整合的部分，學習上還是會碰到一些困難。初期，我們會配合到前端支援技術服務，我們希望，也正在建立一個模式，如果是一個對的工具，可以提供給其他系統廠商或資訊單位都可以用這一種工具。

但我想問的是，還是一個查詢的語言，或是一個QL？因為我們現在有很多BI的工具，每一個人都有自己的查詢語言，當然我們知道結構化資料，一定是SQL，這個是所有的人都會的，但是像臉書自己推出圖像式查詢語言碼，W3C那邊有SPARQL，大概是關於邏輯推理等等，你們這種新的語言，還是一種查詢語言嗎？

資料庫查詢是原本的SQL語法，除了查詢之外，後面還有結果的部分，關於異質資料庫整合，那個其實是核心的部分，運作的方式跟R的概念比較相像，也就是做資訊整合之後，然後產出最後的結果。

所以你這個語言是叫做什麼？是ReSQL還是？

ReSQL是「資料走動管理模組」的名稱，可以將設定的語法自動轉換成需求查詢語法。使用者對於連接的資料庫來源無法控制語言查詢轉換的部分，ReSQL的動作，也就是傳統IT介入這一塊，全部被封裝起來。

這個我有聽懂。

所以那個ReSQL是負責到資料端擷取資料語法轉換的部分。

前面的ValueSQL是？

那個是異質資料庫的部分。

那個不是使用者去寫的，還是要工程師？

對，像水、電進來的時候，專業人員要把這一些插座、接孔等等……

對。所以ValueSQL還是比較像一般的通用性程式設計的那個範圍？

對，那邊是接點的部分，需要懂SQL的人來做設定，不需要程式設計。

你剛剛所說你的SI比較不容易學會的是哪一個部分？

其實這個是思維的問題。反而越不懂IT的人，他越可以接受這一種方式，像阿丹，她不懂程式設計的，經過一、兩天的訓練之後，就可以用這個工具在線上做出一套系統的操作手冊。

從技術出發，會用coding的方式思考解決問題的方法，但是這個設計方式，是經過三個階段轉換，從基礎、技術，然後到整合管理的思維，如果以我現在來看，解決管理的問題首要並不是靠技術，因為需求變換太快，你的技術解決速度跟不上，所以必須要把規則融入平台變成是另外一種思維，這個思維被我們釋放出來。

現在說明的是第三個部份，才是新程式語言，目前定義名稱為Portal Script，工法是一個蘿蔔一個坑，需求就像樂高積木一樣堆放，只要把需求定義在這邊，然後做好接線設定之後，就會形成在平台上的運作，結合剛剛所講的環境基礎工程能力。既然是語言，就會需要一些學習，但並不是用傳統coding的角度來思考，因此有越多的錯綜複雜的設計經驗，反而需要更多觀念釐清才能接受。

我再詢問一下，因為這個聽起來跟我入閣之前有一位同事，當年是設計系統有一點很像他叫做Dan Bricklin，他當年發展的那一套系統，應該叫做VisiClac，就是試算表，後來當然也有更多人做，Excel到現在Google Sheet，然後我也寫了一套，我們現在每天都還在用，這一些都是我們叫做「函數式的程式語言」，你不是打字，而是很直觀的，想要看到什麼，打一個等於號就好了，就把這一排拉起來，他就問你要幹麻，你就說要算平均，就幫你填入AVG，就是這個試算表，這當然也是一種程式設計，而且確實你寫過越少程式的人學得越快，這個我們都有觀察到。

我想問的是，你前面的這一個ReSQL，這是類似像試算表，要在特定的互動視覺環境裡比較好學的，或者甚至不能離開那個互動環境，像Scratch，你不能離開Scratch的環境，或者是有兩個部分，一個是用文字編輯器就可以做，另外一部分是有編輯的環境？

ReSQL本身是一個方法，COR(Commend of ReSQL)是中間的語法定義，比如當我下達一個需求的時候，傳統的部分是我希望IT的人員幫我找什麼的資料、用什麼樣的維度及條件，而在平台上這些需求會經過介面自動層層封裝形成COR，經過轉譯產生最終結果。

現在是用自然語言？

這個是語意商業智慧專利發展的目標。當語法的轉換已達到自動化，藉由介面輸入需求文字，把語意轉換成控制指令，就像當我告訴技術人員說我需要什麼樣的資料來源、我要轉換維度、我要做下探，然後回推分析等等，這個過程反覆由介面操作與平台來完成。

也可使用編輯器，像ReSQL一段語法，然後加一個條件，就可以產生一段新的SQL語法，這個是很簡單的概念。

你們先給他你的語意，這個部分是完全不用碰coding的，就會生成東西給他，生成不一定完全是你要的，所以你一定要改它，改參數、條件等等，這個時候就要會一點關鍵字，但那個時候還是在一般會SQL的人就會操作的範圍，我可以這樣理解嗎？

如果從資料本身來看是這樣子，因為資料探索的過程中間有一個叫做「參數傳遞」的部分，也就是溝通的介面、溝通的過程，從原來生成的部分，再加上這個介面設計，然後再加上我們剛剛所說的技術部份，會形成一些介面，以簡單的敘述就可以形成查詢，然後轉換成參數串連資訊流。

這個我理解，等於你的動詞減少了。

但是你的名詞等於……類似你的文法比較簡單，以前是放在各種不同的資料倉儲裡面，文法都不一樣，所以你要全部都找到的時候，你要非常複雜的文法才可以去表述，等於現在透過一致的文法介面，等於主詞、動詞、受詞裡面，動詞當作一個制定的標準化，所以既然有這一些動詞，反正剩下來都是要餵新的名詞進去，這是你剛剛所講系統接口的部分。

對。當中的資料來源不用有任何的事前匯整，就可以轉換成不同的分析角度，跟用不同的圖形呈現，那一些東西都在上面。

對，就是你封裝成一個有固定動詞操作的，但本來的內容不因此而喪失，不是說跑一個統計，只能對那一些統計操作，還是對原始資料來做操作，或至少原始資料的一份副本來操作。

傳統的方法，需要事前先規劃好要分析的資料來源，因為在做異質環境整合的時候，不知道這兩個共同的維度是什麼，所以需要資料彙整，而這個新的方法剛好避掉這個部份，因此ReSQL的第一個動作是形成自動化的過程，後面是解決所謂複雜環境底下的資訊整合的方法，只有兩招(就是EISTable跟ValueSQL)，他就可以解決傳統面對所謂的商業資料轉換成資訊這一段非常困難的事情，但是變成完全直覺性的連結上我的資料來源之後，事情就做完了。

簡單來講，不過ETL的「T」還是得做，該做的轉製還是會做，也就是封裝起來，然後不用浪費這麼多的時間，對每一個不同的資料需求做載入的動作，因為當你封裝起來之後，你反正載入的方法就這一些，可以自動把互相join的緯度找到，是這個意思嗎？

我們先分散運算之後，最後一定會做合併的動作沒有錯。

類似我分別去做，但是最後還是要有一個東西給我？

對。其實這一段會跟傳統差異的部分，那個差異是……我有一點忘詞了。

我聽起來是，因為以前我們分別建模的時候，本體論是最困難的，你沒有一個共通的本體論，每一個描述資料，其實看起來一樣，但意思都不一樣。

但是本體論，你要事前建成，幾乎是不可能的，因為你要預期未來的需求，要是可以這樣子，早就發了，所以通常都是互相影響的過程，這邊描述的資料多一點，改一下本體論，然後回來繼續改，但是每一版ETL導入的時候，那個時間就會變得非常久，非常緩慢，而且會系統上線，還沒有上線，還得兩套BI系統併存等等。

這一套我聽起來意思是詮釋資料，可以不需要人工去建本體論，可以自動對應到某種……我不知道，因為我不知道細節，但就是很厲害的一種本體論，你的描述資料不管怎麼建，都可以進入一個語意本體裡面，感覺上是這樣子。

現在企業因為資訊發展形成很多複雜且分散的資料，而這個方法上解決的是剛剛委員提到的部分，很多事情我們以IT的角度，希望使用單位應該要說明清楚，然後應該把需求的部分，資料來源都要確定清楚，一直都是困難的地方，這個方法剛好避掉這一些東西，你要的時候就接進來，你需要什麼內容或者是什麼條件都是討論的過程，以傳統prototyping的目的，這個定義完成之後，其實這個結果就已經生成了。

我瞭解了，這個研究方向在2007年的時候，西蒙尼（音譯）以前在微軟，我們現在用的很多變數方法，也就是西蒙尼匿名法，在2007年創了一個「意向式程式設計」，後面的想法跟您剛剛描述的是非常像的，但也因為領先時代太多，那很有教學功能，可以啟發學生對資安有不同的思考，但確實企業導入上，因為你要先忘記你本來學到的東西，才可以用這一套來進行工作。

我們剛好也發展出一種需求解決方法，在醫院以病人安全的要求下，通常他們會更多的資訊整合或者是圖形化介面所產生的需求，這個工具剛好也是在這個階段，藉由另外一個客戶關係，可以對醫院使用者跟資訊單位做了這個介紹，當把困難的需求拿出來，我們這邊突然隔天，或者是一天或者是兩天就可以把問題解決掉，就可以開始看到這個整合的結果。

我有聽懂。

其實兩年前因為西蒙尼（音譯）的團隊被微軟買回去了，所以這兩年來也開始看到office，尤其是Excel開始出現類似這樣的東西，會猜你的意向、會自動幫你填滿，不會只限於單一的橫軸或者是綜軸。

其實很多資訊都在資料或是內容本身，就應該善用這一些資訊，為何需要靠我們來做這個動作，當從我一開始在做這個東西的時候，應該有35年，那個是第一次接觸電腦，25年是真正開始進入社會、開始做就在思考這個問題。

這麼多年的時間以來，我只做這一件事，也就是把這個動作真正形成一個方法論，然後真正被釋放出來，進入現實環境之後的挑戰，都可以說類似優雅解決這一些問題，並不是大量工程來解決，否則就沒有辦法滿足需求端，像這個問題出來，很快的時間幫你把兩種異質的資料庫整合起來之後，然後又形成可分析或者是每日管控的內容。

等於是像一個工作台，有很多現成的東西，以前聽到這個，就拼這個樣子出來，但是並不是每一次都把工作台拆掉，然後CNC再切一個什麼模出來，等於損頭都自動接得上。

聽起來很像做了改變，對象轉換成資料庫，不管是資訊或是資料本身需要的那一段東西，接上去就結束了。

這個很不錯，這個很不容易。

其實整個發展的部分，我們前面都是在技術，後面加入這個團隊開始從市場跟行銷的角度來看，其實今天這樣的安排，這個是她（阿丹）的安排。

因為我們也才過不到半個小時，看您有沒有想要分享或者是詢問的？

我跟我們老闆這樣相處下來大概兩至三年，每一次只要跟他出去，如果合作的公司老闆談，都還可以談，但只要是遇到資訊室的技術人員，就會變得好像很難溝通，因為他們都會很疑惑直接問我「怎麼可能」。

你要指明有沒有學過perflog等等，這樣就會聽得懂。

而且又必須實作給他們看，我們有一個好處是資料外存，只要接上資料，還是在資料庫，就可以做。真的要實作，他們才會知道原來真的是這樣，但是很奇怪的是，還是不買單，這是我覺得很奇怪的地方，他們會覺得就這樣嗎？有的會覺得說那資訊室要幹麻？

因為太多的問題都被解決掉了。

確實，你把他們在ETL最麻煩的，也就是「L」的部分整個拿掉了，他們工作可能八成都在做維運，所以你要往好處想，他們可以早一點下班（笑）。

當初發展會從醫療環境開始，就是從需求出發，2007年台灣開始推動醫院評鑑制度，剛好一個家人是負責評鑑業務統籌部份，平常就在做的工作，到了評鑑查核的時候，往前推三個月至半年，就是他們瘋狂蒐集資料、討論，為了要應付這一種查核作業而人仰馬翻的時候，在那一段時間，經常加班到半夜才回家。

因此，開始把技術轉換成決解方案，但是從技術進入管理是很大的挑戰，因此花很長的時間從實務的經驗整合，然後重新調整技術的思維，後面才發展出以現在三個完全不同的面向，解決客戶端的這個部分。

這個我理解，像我剛剛提我的同事，他當年發明這個的時候，剛好是個人電腦出來的時候，本來的想像是在大型主機上運算，但是因為這種太簡單、方便了，如果用過當年的，其實小孩都會，因此忽然間就變成大型主機的那一些作業人員，那時還有打孔卡片這一些，也有一些被威脅的感覺，因為老闆一個指令下來，要很專業寫成專業的東西跑個半天才會跑出報表來，現在老闆自己或者是老闆的秘書拿一台iPad 2什麼打一下就有了，這樣還要資訊人員做什麼。

所以每個時代都會經歷這樣的情況，但事實上程式設計師也沒有失業，事實上試算表出來之後，程式設計師變很多，因為每個人都變成業餘的程式設計師，其實要往這個方向去想才是對的。

針對今天談的方向，也是剛好有這樣的機會，討論了新的方法，當我們開始在談企業數位轉型的時候，如果沒有新的資訊工法，而用傳統的思考模式或是資訊方法來面對這一種轉型的過程，原來的資訊人力瓶頸還會繼續存在，所衍生出來的可能是堆疊、累積的問題，還有後面的設計調整，其實那都是另外的成本與困境。

以現在來看，我們公司主要在做客戶端服務的部分，以年輕人大學畢業居多，之前我們跟學校有產學合作，學生在這邊實習，當完兵回來之後回到這裏做，有些從學校畢業就進來，既然技術已經被封裝，我們的重點就不在技術上、而是提高服務的滿意度，未來底層平台也會持續的研發

這個語言，也就是我如果想學的話，是線上已經有教材嗎？因為你是產、學，學校一定要有教材。

對。我們開始配合做產業輔導的企管系老師，的確在現場的會議上，一個小時之內，我們就幫企業把三個資料來源建立起來，型成資料分析模型，逐一變成範例。

老師輔導過程，通常結合理論，以往在真正執行時才會出現管理面問題，從老師的角度，這個工具上來之後，未來是長久資訊的模型，所以可以持續一直運作，已經開始在談未來學生的課程，也就是從基礎SQL的語言學習完成之後，培養未來思考是在於資料運用的模型訓練，而不只是技術，相同的東西在不同的人手上，會衍生出不同的結果出來，有好的工具固然重要，思維更重要。

你運用他的素養。

我們跟屏科大的老師談，就朝這個方向，課程、學習的部分，我們一直在準備中，開始建立線上的教材，像開始所說的，到去年技術真正到一個程度，所以接下來都是我們持續在準備的。

這樣的好處是，學校的老師可以幫你們做文件的工作，因為說真的，技術性文件是一個專業，我們這一些寫程式的人寫出來的，未必學生喜歡看，編教課書完全是另外一種專業。

所以一定程度把語言的規格，因為現在已經相對穩定了，等於開放出來讓老師自己發揮他的創意、做出教材教法，我覺得這個長遠看起來，比理念的推廣更有幫助，這樣一個高三的學生，從來沒有跟你們學過像C語言的東西，這樣至少第一次學到的時候，就是一個跟他實務會貼近的，不會一下子就覺得其實這邊是微控制器，要怎麼樣去碰那，那個也是有價值，那個非常有價值。

只是現在都已經封裝好了，在100個要寫程式設計科技領域的學生裡面，可能到最後也不會有兩個人去學組合語言跟C語言，所以我想大部分的人需要的還是運用端的東西，也就是建議盡可能把語言的標準、教材教法，看怎麼樣盡可能開放，因為沒有運用的know-how，其實也沒有辦法跟你競爭，所以這反而並不是核心競爭能力所在，因此這個部分是越開放越好，不然要顧太多寫技術文件的人，這其實沒有必要，因為老師背課就要寫這一些東西，並不是額外的工作。

另外一件事，回到你們的價值主張，聽起來有兩個不太一樣的價值主張，一個是專門針對醫學環境，也就是這一些處理上可以達到，甚至跨部門、跨醫院的資料理解，但是不需要把原始資料流出他的資料庫，甚至你也不需要做副本，因為那個是敏感個資，這樣聽起來非常困難，這個專門在敏感個資裡。

另外一個是讓資訊室的人做更有創造力的事，像結構簡單的事情都不需要資訊室的人來做，這個是聽起來第二個價值主張，這兩個聽起來不太相關，也就是你可以想像一種技術是只能解決一種，而不能解決另外一種，但是你們好像都可以解決。我現在聽到的主意是，這個價值主張好像只有跟五位領導人聽得懂，但是你真的下到資訊室的人，這個價值主張，他們不認為這是價值主張，我的理解是這樣。

對，的確要傳達這個部分，十幾年來的歷程，持續與企業組織合作，運作這麼久希望去相信這個東西的話，是需要一些時間磨合，以我們來看，像剛剛委員所提到的，比如釋放這一些教材、教法，既然是在研發的話，一定有很多東西還不足，這個不足的部分，會需要一段時間慢慢來達到目標。

就是這個意思。

這是我們逐步在進行，結合外在的力量跟有一些資源運用的部分。既然叫做「企業」的話，我們也必須要考量生存下來的必要條件，努力的做專案、維持研發、繼續準備。

當然，我建議開放不是你們賺錢核心的部分，事實上我們做開放原始碼，意思是哪一些你覺得一直砸錢進去，而沒有回收的，好比像最常見的例子是把軟體放到平台一致性，這個是要一直砸錢，而且其實賺不回錢的東西。

但是那個部分你願意開放，他就會幫你做這個工作，等於是幫你做志工，但是從他的角度是為了他的私利，但是就變成你的志工，我並不是賺錢的部分要開放出來，而是虧錢的部分要開放出來。

依公司現在實力，要兼顧這一些事項的執行，其實是力有未逮。雖然試著在做，但像剛剛提到跟其他的系統廠商合作，比如教育訓練的部份，都開始在進行，只因為一開始訂的題目就太大了，問題是，又必須要用維持這樣的方向，像剛剛提到的堅持跟整合，如果不是一連貫的資訊平台的話，有時也在想是否真能解決企業管理問題。

這個我完全瞭解。

當初在做設計的時候，並不一定知道最後發展的規模，有時越做越大，要轉到商業應用也還不可行，因此才會一直在做持續的研發。以現在核心比較穩定之後，才會開始做外圍資源整合的部分，像台北、台中、高雄都有這樣的對象在做一些轉移跟接口。

其實我的想法是，比較想要從幫助社會的方向去走，所以像我們上次跟台北廠商合作，我們的東西包在他們的公司裡面，就是為了分析社家署障別資源使用的情況，還有一些安置的問題，對我來說，我覺得這是很有意義的事情，所以可能會用比較沒有那麼高價位跟他們合作，讓他們可以看到資料面，到底出了什麼問題，因為我們的分析系統進去之後，其實對我們系統懷疑很多，想說資料面為什麼這個縣市這麼少人，怎麼可能障別的人數這樣，因此就開始找原因，發現其中之一是登記與使用資源地點的原故。

可以更快看到一些洞見。

一個對的工具可以真正讓你看到資料現象，而不是一個需求就等待技術的過程，然後形成資訊落差或者是無法取得資訊的部分，這個快速反應在整個實務上的確都有被驗證到，像我剛剛所說的，後面其實還有很多的東西需要去發展。

現在做的驗證，某些時候可能是幫助，像我們前幾個月做高公局的，高公局有一個競賽的案子，雖然競賽是一個目標，但我們並沒有一定要拿第一名或者是什麼，我只是想要知道是在什麼樣的情況下車禍比較多，會造成傷亡，就是在分析這個。

我在想你們的生態位，自從西蒙益被微軟買進去之後，他們現在有一個方向，也就是AI加BI，這個大家都很熟，你可以自己接到人工智慧的訓練去，可以自動去做好比像語意辨識及影像分析，你都得另外寫程式的，現在是直接放在Power BI的內建功能，他們幫你算，然後再回來。

如果不是個資，而是空氣品質，這當然沒有問題，因為空氣不能主張個資，如果是水污染，核也不能主張個資，所以丟給微軟，然後再算回來，這是天經地義的事情。但是在醫院並不是這樣，像在醫院用Power BI，開始用這一些認知服務，就必須把病人的個資給微軟再回來，所以很像哪裡怪怪的，因此很多醫院因此卻步，他們處理的並不是個資，而是敏感性的個資。

你們的技術，現在有人接到類似像這樣機器學習的前端運用嗎？

其實這個也是本來一開始要談的部分，我們要說的是，這幾年其實在做的是基礎工程，像剛剛丟到雲端，然後還有運算服務再回來，這都是在現有基礎環境底下未來要再整合的。目前合作伙伴已經開始使用這個工具成為AI前端資料來源準備作業，「NEWS 先期預警分數於心臟驟停的應用」結果及後續量測項目、觀察項目的呈現。

市面上有所謂的雲端商業智慧，只是企業需要把營運資料上傳到雲端環境，但是我們前面灌了一個即時，也就是企業的資料不出門，但是用雲端的運算資源，達到即時分析的目的。當然排除資安之外，傳統方法要達到即時分析在資料量傳輸的效率就是一個問題，但這個新方法讓資料在企業環境這裡，所有的需求會自動一直在做調整跟變換，只是取得我需要的資訊內容，所以所謂raw data的部分並不會到外面的環境，結合剛剛的方法，我們用另外一個專利的部分來敘述這一件事「雲端即時商業智慧」，為什麼傳統非得要把你的資料拋到雲端才可以做這樣的運算，牽涉到某一些個資資料的時候，這一些事就不可行，這個是一些方向。

未來整合AI，還有Big data，也就是雲端的服務中心，會經過很多運算，首先是資料蒐集，形成可用的資訊內容，然後再跟企業的資訊內容來作整合，意思是資料不出企業門，經過一些資料的整理，由領域專家進行分析模型設計，就會形成應用的部分。

反而是語意從「雲」到「端」，而不是資料從「端」到「雲」，大概是這個意思。

對。如果企業管理沒有完整的資訊流通平台，所有的都是分散式、點狀式的東西，就沒有辦法形成全面性、自動化管理，所以關鍵在於你需要先擁有一個完整的資訊平台，我們現在正是在打造這個，再來發展外面資訊整合的運用。

一直以來我們的發展都是反向思考，也就是從這個地方做到那個地方，並不是從需求端開始把這個東西做起來（而是從底層開始），因為從這個方向就會面臨到未來需求的挑戰，相較於平台式或者是整合的角度思考，就一定會有落差的地方。

像資訊調整並不是想調就調，那會面臨結構性的問題，也會面臨到一些資訊溝通的問題，所以當我們開始制定這一些東西的時候，希望朝簡化這些發展困境為方向，因此在現在這個環境底下，你要什麼東西，我就一直堆疊上來而已，就形成一種組合的概念。

剛剛對於架構師的價值主張，我們都很充分討論了，包含以後學生要怎麼這樣的方法來想，不要用30年前的狀況來想，我寫程式也30年了，這個部分應該很清楚。

另外一個部分是在個資上，我會建議你們對個資的價值主張可以參考一些國外的一些論述，因為我這次也有應邀參加「行政院生技產業策略諮詢會議」，我在上面有一個簡報：一個部分談資安，就不是這個話題了；但是第二個部分談的是所謂的個人資料自主權，跟您剛剛所講的社會公共利益，這兩個要如何同時滿足，這個在以前是很大的爭議，也就是一邊要放寬個資法的限制，才可以做大數據，另外一個是有事後拒絕權、事後拋棄權、事後解釋權，但是這兩個為什麼會打戰？因為以前的運算架構是要把個人的個資交給你信任，但病人不一定信任的運算單元去進行運算，而且天知道微軟的「雲」在哪裡，然後再算回來，你的資訊室相信、不代表你的個案相信，如果你的個案不相信，這一套就沒了。

因為我的簡報是公開的，整個都是公開的，我們之後逐字稿再提供給你們，提到一個比如開放資料，開放資料是像剛剛所講的空氣、水的資料，那當然開放，但是現在在倡導另外一套是國際上叫做「開放演算法」，剛好跟開放資料相反，也就是把你的語意，像你到底要調查什麼，比如像剛剛所講的障別，你先把這個東西用很簡單的方式，類似你們前面ReSQL的東西去把它講出來，講出來之後因為有很多的不同合作醫院，每一個都可以按照這個語意，因為每個的資料結構都不一樣，但你要的東西是一樣的，所以是翻譯成在當地可以執行的演算法，你再讓第三方的專家來證明，像白帽駭客的感覺，證明這個轉譯的過程，你絕對不會因為統計的關係而洩漏本來的個資。

像我們小時候學走路、講話，但事實上沒有人記得你3歲以前走到哪一步路的時候會走路，也沒有人記得聽到哪一句話會講話，因為我們累積的是智慧，不是raw data，其實3歲以前的raw data都丟掉了。

所以在這樣的情況之下，你的這一套運算方法，也就是用這個方式，就可以達到個資絕對不離開醫院，但是研究者可以做到跨院的分析，以前研究者很難做到跨院分析的，你不知道資料的好壞或者是資料品質的好壞或者是演算法的好壞。

現在既然演算法已經一樣了，而且是公開的，這樣很明顯是資料整合的差別，這樣哪一個人的資料整合得好，誰的貢獻就多，我覺得從這邊去逆推你的價值主張，資訊室不會有一種明天就要失業的感覺，因為也會覺得這是在保護他的醫院病患個資之虞，也讓醫院對公共利益有所貢獻，這時被老闆敘獎的機率就增加了，但是如果只是純粹省時間的話，好像其實很難說服資訊處的處長，我們都很瞭解的。

的確到最後，像工業4.0所說的、智慧感知工業世界，這一些方法在上面也能有一些詮釋的空間，這也是剛剛談的後面這一段，因為我們把這個東西拉到外面的環境來看這一些數據，跟在內部看自己資料時的感受不同。

分享完了。

很感謝這個分享，我覺得臺灣很不容易，其實我們是因為有這一種彼此尊重、個資法的這一些東西，我們才會坐在這邊聊這個，如果什麼東西都是國家的，其實我們不用聊這個（笑）。

的確。

所以我覺得像這樣子一種大家來參與，也就是對大家有好處，也就是社會創新，「眾人之事，眾人助之」，我覺得需要大家集思廣益，如果之後有更多的教材、教法，或者是有具體跟大學或者是高三的教材、教法出現，我也很樂意，不管是在網路上分享，或者是我自己也來學學看。

我們會持續做這樣的動作，如果有一些進展再請委員指教。

（參考附件： iGms-技術概述(PDF) ）

我們會努力。

謝謝。