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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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