• 我們就準時開始。

  • 這是我們第一次討論政府計畫科技資訊網的計畫審議功能的精進案,我在院裡面主持的會議,可能有一些朋友已經知道,但是我還是說一次,通常我會有一位速錄師會在旁邊把大家講的話打下來,之後會送給各位的email,不會對外,大家有十個工作天的時間,應該就是兩個星期的意思,我們線上有共筆修改自己的發言,可能把上了新聞不太好的地方拿掉,或者是講得不夠清楚,或者同音字加以修正,十個工作天之後會放在「pdis.tw」的網站上。

  • 如果大家都覺得ok的話,因為今天速錄師剛好有事,我會錄影,但只拍前面簡報的部分,所以請大家第一次發言的時候按鈕發言,然後稍微講一下希望怎麼稱呼或希望怎麼被記錄,就不多耽擱大家的時間。

  • 謝謝唐政委。

  • 簡單來講,科學預算現在走實質改變的路,在實體面上會增加專家評議的功能,會比較長期的方式來做。

  • 第二個是資訊系統要跟著改革,因此今天要討論的是第二個部分,也就是資訊的改革。

  • 資訊系統的精進這一個部分基本上我們要跟得上時代,所以基本上有兩個最主要方向的部分。

  • 我們希望追蹤是從一開始在立案之前有一個政策方向開始追蹤,一路追蹤到計畫結束,中間的修正及最後的評鑑,未來這一個單位要提計畫時都可以連結,我們希望可以在未來系統的time domain跟連結性可以整個建起來。

  • 第二,現在這個時代有很多AI跟機器學習的時代,因此希望這一個方式來提高審查委員在審查之前就有足夠的資料量來解讀,很多不需要用人工來解讀的部分就用機器來做,基本上是希望達到這兩個最高精神的指標。

  • 當然,你要連結的資料庫不希望只是在政策這一塊,還要到執行的計畫,大概就是有兩層的部分,簡單說明到此,謝謝。

  • 謝謝,今天看起來有兩份簡報,請國家實驗研究院開始報告,謝謝。

  • 政委、葉副執秘及在場先進,我代表國研院說明一下有關於政府科技計畫資訊網過去、現在的狀況,以及規劃當中要如何精進的部分。

  • 內容如剛剛葉副提到的,也就是有關於平台的精進,如何幫助審查委員提供一些資訊的工具。

  • 原來科技計畫資訊網一開始建立的目的是為了能夠節省科技部、科技會報辦公室在審議作業當中之作業時間、時間成本,因為以前都是紙本作業,因此我們把紙本作業變成線上作業。

  • 同時也能夠把歷年來的審議,因為是經濟部的線上作業,所以會比較容易保存,這對歷史軌跡的保存是有幫助的,當初是這樣的發想。

  • 我們中心是在97年時開始接受此任務,並開始建置這一個系統,因此現在系統當中所有的資料,也就是97年以後的綱要計畫資料與審查意見,也有一些是績效報告跟績效評估意見。

  • 因為從97年至現在,其實每一年或者是至少每一、兩年審議的作業有非常大的變動,從一開始審計畫摘要表、總體說明書、政策審、技術審,至現在是變成重要額度跟一般額度,所以每一面的變動非常大。

  • 另外,我們提供的內容是,我們建了這一些相關系統來支持業務進行,因為審查委員一直反應當他們一直在審查的時候,他們只看到綱要計畫書,這樣是不夠的,也就是他們見樹不見林,提供的意見非常片斷,期待我們提供更多、更豐富的資訊給他們參考。因此我們也就針對綱要計畫內容在部會上傳以後,其實只有很短的時間,我們只有針對綱要書的內容來分析。

  • 我們去年也完成了一個科技計畫統計與內容視覺化的分析系統,讓審查委員可以在線上直接查找資料幫助他們,預期成效就如剛剛所說的。

  • 這一個系統主要的使用對象包括科技部跟科技會報審議的作業人員、部會型窗口,以及部會底下的單位窗口,接著還有計畫聯絡人,這裡的「計畫聯絡人」還是部會層次。

  • 在政府科技計畫資訊網,就是只有到綱要計畫層,接下來推動會有細部計畫、執行計畫,這裡都是只有到部會的綱要計畫層,也就是說,資訊網裡面蒐集的綱要計畫,其實是部會年度科技預算計畫,不是執行計畫。

  • 我們目前現有的系統功能,一個是政策資訊的管理,一個是計畫的審議作業、績效評估作業,及新加入院列管計畫的管制作業。每一個功能模組其實都有一些查詢功能,大家都有提到是否可以查詢,其實有關於年度、計畫名稱、關鍵詞等查詢都是基本的功能,我相信每一個系統都會有的。

  • 我們今年準備重新改版,對於整個系統操作界面是否更親和或者是更方便,我想這個是比較操作面的,因此我們就不報告,我們只挑出比較關心、比較核心的精進項目。

  • 第一,原來的審議作業之效能提升,也就是經過這一次改版,我們希望能夠再新增一些其他的管考功能,因為原本的資訊網,科技部跟科技會報只管綱要計畫核定以後來提出申請並審查,接著是報績效評估,中間這一塊除了院列管計畫以外,其他並沒有管制措施,是最後到年度結束時再看執行成效。

  • 這一次因為葉副有提到,說要從建案一直到後面都要串起來,因此我們這一次會增加一些中間的管考,以及後續可能說不定一、兩年之後的這一些績效作業,我們都會把此機制給建立起來。

  • 有關於政策諮詢,像行政院公布的一些重要方案或是全國科技會議開完以後,會產出國家科學技術發展計畫,又或者是科技會報開一些SRB的會議。

  • 開完以後通常會有一些政策措施,我們會把這一些政策措施解構以後,會放到系統當中讓部會選擇這一個計畫是來自哪一些政策,也就是計畫的政策依據。 一般來說,這麼多年來部會在挑選的時候,其實沒有那麼精準。

  • 如果要講整個從建案到結束,對於政策方案的部分,現在目前來說,以我現在來看,大概只有國家科學技術發展計畫有此追蹤,像以前早年的追蹤機制,好像最近這幾年比較沒有看到,原來國發會有對總統政見有追蹤,因此這一次我們會對政策方案提出追蹤的建議。

  • 另外,讓審查委員看更豐富資訊的這一塊,也就是除了我們原來針對綱要計畫書第一部分概述表所做的量化統計及內容分析以外,我們也會再新增一些其他的國際資訊分析,還有提供計畫比對的工具,這個是主要的三大塊。

  • 這三塊我說明一下,如果從建案一直到後面的結案追蹤,黃色的部分主要是比較能夠著力的地方,最上面黑色的部分是部會自己執行層面的那一塊,因此我們是針對比較能夠著力的地方(處理)。

  • 政策資訊管理及年度綱要計畫審議績效評估,這是原來資訊網有的功能。因為這一次會導入以前沒有的角色之民意專家,因此民意專家會從審議績效評估報告中間的一些監測會去touch,評議專家會有自己的評鑑管理。 虛線的部分是原來沒有的,我們現在準備把這一些都串起來。

  • 細部計畫這一塊是指部會自己執行管控的那一個部分,我們也會同時考量進來、同時開發,對部會來說是選項的部分,除非是政府有強制要如何做,不然原來預估是選項。

  • GRB的部分是當部會拿到這一些預算以後,開始推動以後,可能對學校或對研究機構copy proposal以後,會有一些各個因此計畫,也就是現在的GRB。這中間只會串聯,但我們這一次的精進案是不含GRB這一塊。

  • 我們希望在11月完成,這一個部分一定會完成,另外一個部分我們會儘量,因為這裡面的功能非常地多。

  • 在政策分案這一塊,這個是我們的建議事項,這好多年前提出來,我也沒有改,所以就把圖片放上來。

  • 現在國家科學技術發展計畫,當成立了、行政院核定以後,是有將措施稍微分辦,也會定期追蹤,我們會填報,也會送到行政院核定,但是比較沒有再作更進一步的分析,因此我們當初曾經建議過像現在「5+2」成案以後,是不是應該要有一個管理機制去追蹤這一件事。

  • 我不知道國發會是不是有接,如果國發會有接的話,我們就不用重複做,如果沒有的話,是不是針對跟科技計畫比較有關的,應該要有這樣的機制來建立此系統。

  • 就審查工具的部分,我剛剛有提到一開始的時候,我們有針對科技計畫內容盤點,我們會針對國際趨勢執行及計畫來提供一些工具。

  • 就國際趨勢的部分,因為現在政府推動「5+2」的幾大產業,我們嘗試要從這一些政策裡面,我們會往上看哪一些標竿的國家有推動何方案與此有關,往下看有何技術架構及現行的成熟度如何,也就是哪一些可以讓我們參考哪一些可以投入,哪一些可能已經兩年後要商品化很成熟的,而不需要再投入的部分。

  • 我們會針對這樣的資訊來彙整額外的資訊,我們產出的報告是,如果審查委員在審查時,若長篇大論,審查委員也沒有時間看,因此我們這一些東西大致會歸納成4月左右的簡報檔,簡報檔接下來若有興趣的話,再看報告,也不會太長。

  • 這其實是很大的工程,所以我們也不敢保證在審查之前我們就會完成多少,反正我們就是陸續一直把它補起來。

  • 接下來這個只是範例,也就是會分析有什麼樣的核心技術及何國家。

  • 這一些東西除了國際的發展趨勢以外,到底國內已經累積何能量,我們就會介接到其他的地方看國內已經有投入哪一些技術,甚至可以再把我們的人力資料庫串在一起,也就是到底有哪一些人在執行這一些計畫,可以看到國內這一些研發的能量。

  • 有關於計畫內容盤點分析,我們去年有提供基本資料的概述表,有提供一些量化分析及質化分析,也有把這一些內容的計畫、各部會在國發會所填的科技施政目標來作一些串聯。我們今年會增加的是就計畫書的本文作相似性的比對。

  • 這是我們分析的材料,也就是概述表的內容,綱要計畫書其實是非常厚的一本,委員一開始在看的時候還沒有要看到那麼細,所以我們會摘錄一些重點,然後來作一些研究主題議題的分類。

  • 我們主要的分析項目包括量化分析,就是有這一些。內容的部分會針對這一些研究的性質或重大政策、議題,因為重大政策與議題非常多,我們不可能全做,所以我們只挑科技部跟科技會報辦在這一年的推動重點,我們會針對這幾個重點及現在社會上熱門的議題,針對這一些議題來作分析。

  • 後來因為審查委員看一本很厚的報告,他們還是覺得非常吃力,所以後來才會有視覺化的系統,操作非常簡單,這個是委員可以在線上看到的畫面,如果五大產業創新的話,像「亞洲‧矽谷」大概有哪一些計畫,這個都是計畫名稱,一點進去就可以看到計畫的檢索及哪一些部會參與,這個是原來的系統,也可以一路展開下去看其他的議題。

  • 如果是高齡化議題的話,可能主要部會所投入的綱要計畫、高齡化議題,可能都是討論或健康照護或輔具開發,看看有沒有什麼計畫功能在執行的。

  • 科技預算站也是一樣的,也就是針對每一個部會所提的綱要計畫及施政目標的關聯,然後去做一些統計。

  • 最後我們針對科技計畫相似度比對的部分,我們今年會增加三個功能,第一個功能是可以用文找文的外面非常成熟的一些技術,去查找一些相關的綱要計畫。G第二個是去查找相關的執行計畫。另外我們也會針對比對的方式,希望能夠把各年度,從最近這幾年的綱要計畫書去作抽取分析,然後提供一些相似度的接軌估算。

  • 這個是第一個部分,也就是查找綱要計畫與查找執行計畫,委員找到以後,可以直接再點進去看詳細的內容。

  • 這部分的資料正在跑當中,據說可能會讓委員看到的是,當下這一筆計畫是哪一筆計畫,跟哪一筆計畫的相似度是多少,點進去之後就可以看到底有什麼地方相似,我們希望在今年的審查之前,也就是現在正在跑的那一些分析資料可以跑完並連上線。

  • 當然這個是今年非常匆忙的做法,我們後續還會陸續找有無更合適的工具,能夠讓這一件事做得更精進。

  • 葉副有指示要將AI及機器學習導入,我們覺得這個在計畫相似度的部分,這個能夠執行,這個部分我們會持續追蹤,也會找學界的老師,看是否熟悉這一塊並開發。

  • 另外,希望建立關鍵詞的分析部分,其實有關於人、執行機構、計畫、議題的串聯,我們認為莊主任就指示這個是我們今年作重點,因此我們會把它做起來。

  • 另外,有關於基礎分析資料,像過去執行的績效及編列的情形,其實審查委員在審查單筆計畫的時候,其實可以看到過去的前期相關計畫,因為我們在事前都會作整理,因此都會知道這筆計畫前期是哪幾筆。

  • 其實原來的評估就可以看到前期的綱要計畫、審查意見、前期績效評估及負評意見。另外,因為我們又增加這一些功能,又可以直接查找過去的情形。

  • 另外,葉副有提到希望各部會在執行綱要計畫或在審查過程中的改變都能夠追蹤。

  • 我們建議在修正版綱要計畫書的時候,部會可能要提出一些修正說明,我們也會新增一些查看最終審查的意見,委員可能要看看之前的審查,因為很多計畫多半是三、四年一直執行下來,我們會一些小的細節功能,讓審查委員可以看到更多的資料,一身是我們的報告,後面的附錄供參考。

  • 非常感謝這一個報告。

  • 接下來還有一個報告,衛福部科發組報告,一起報告完,如果剛才有想詢問的部分,我們再統問統答。

  • 補充說明一下,其實今天邀請的四個部會,當初也都有麻煩各部會代表,大概就部內既有管理系統的現況作簡要介紹,只是衛福部大概有特別一份報告,另外其他部會也許透過口頭的方式來說明。

  • 請有簡報的先,說不定手機沒電,需要拍畫面的部分先說,然後另外兩個部會再口頭說明,謝謝。

  • 今天報告的內容大概是依據會報辦公室交代的兩個部分:第一個是有關於衛福部在整體科技計畫規劃方式跟大家作一個簡單的介紹。第二個部分,部內最近也建置完成自己的計畫管理資訊平台。

  • 第一個部分,有關於107年度配合行政院開始施作的整體施政計畫的規劃,事實上先講衛福部整體科技施政的藍圖,因為衛福部所轄範圍非常廣泛,所以過去提計畫的方式,事實上是由各單位提出來,在部裡面從衛生署時代開始到現在,大概有十多年的時間,我們都在把自己的綱要計畫送進科技部、國科會之前,做了很多的努力,是在弭平各個部、署裡面提出來的計畫之間是不是會有重疊的問題,這個是回應葉副想要詢問的其中一個重點。

  • 我們過去都是用人工的方式去看看各單位提出來的計畫會不會有相關或者是重疊的部分,然後再真正組合計畫出來之前先把那個處理完成。

  • 但是這樣的做法會很明確效率,也會顯得我們的研究事實上是沒有系統的。

  • 因此我們從104年底開始做一件事,我們花一點時間去擬訂一個衛福部至2025年為止科技發展的政策白皮書,我們花了一年多的時間,這一個政策白皮書在去年底完成,但是現在是在做最後的階段。

  • 簡單來講,衛福科技施政的願景、策略目標展開之後,看看科技要如何幫助部去達成其施政策略目標。

  • 我們後來討論完的結論大概有八個重點的科技施政目標,也就是從社會福利體系、照顧服務體系、健康幸福社會、醫療服務、相關疾病、安全生活環境、基礎建設及配合產業。

  • 在八個主題底下,我們知道有一些問題事實上跨主題間會發生連結及合作的,我們把它稱為是整合性的議題,大概是有三個議題,一個是跟高齡化有關、一個是跟少子化有關,最後一個是跟以人為中心整合性醫療照顧體系發展有關。

  • 事實上,衛福部嘗試把大藍圖畫出來,接著衛福部底下各單位要提科技計畫的時候,就應該要遵循這一個藍圖去作設計,規劃自己小單位要做的事情,這樣就避免前面講的可能會重複的問題。

  • 如果我們回過頭來看,這幾年政府科技發展的計畫類別及額度的演進,自97年至104年、106年及107年,名詞是五花八門,簡單來講這一個中間的紅線一分為二,上面的那一群計畫其實都是配合行政院的大政策,這個部分事實上都是各部會呈行政院的指示項目去做。

  • 提出來的計畫事實上是會回到院這邊,由科技會報辦公室作一個整體的檢視與盤點。

  • 至於下半部是各部會各自施政所需要的一些科技研發項目,在衛福部就是剛剛所講的,我們現在採取一個用最大的指導原則,從白皮書看整體的規劃,這邊希望避免掉主題選擇篩選或重複的問題。

  • 今年整個先期審議作業流程其實是非常多變化,左邊是原先在去年底的時候,科技部跟會報辦公室公告給各部會遵循的流程,右半邊是會報根據辦公室來作的一些配合,我們只講新興政策的部分。

  • 事實上從通知到各部會提送的中間時間總共有兩波的計畫提送,第一波的時間是一個月,第二波的提送是一個禮拜,到了會報這邊審議完成說這一個構想可行,大家開始寫計畫書、交出計畫書至科技部,事實上只有一個月。

  • 我們為什麼講這一件事?我們發現這整個流程中,就衛福部的觀點,我們有很多要再改進的地方,也希望院裡面可以給我們指導跟協助,共三件如下:

  • 第一,這一些新興政策計畫的醞釀、規劃時間其實是非常非常短,剛剛講了一個月或者是一個禮拜。

  • 第二,我覺得這是更大的問題,也回應到前面的報告。因為這一個時間的短暫,光部會自己內部提出一個計畫送出的時間就很短了,更不要說跟相關部會討論跨部會間需要合作的項目、該怎麼分工,在今年的作業流程中完全不存在。

  • 大家可以想見我們面臨的問題越來越嚴峻、多樣及複雜,已經很少有單一部會可以提出一個計畫並解決一個社會問題的簡單邏輯了,所以如何讓部會間可以有更多的時間及管道去針對相關的主題去提出計畫前真正有整合的作業發生,我們要再精進。

  • 再來,現在行政院要推「零基預算」,到時候跟整個作業流程或者是作業方式可能要如何搭配,這個也需要再更多的討論,這個是第一個部分。

  • 第二,跟大家簡單介紹衛福部最近新做的管理平台,整個系統架構——請看到最右邊這一排——我們嘗試從綱要計畫到細部計畫,再到最後的執行計畫,執行計畫很像剛剛講的GRB的部分,不管是包出去讓人家做的,或者是衛福部裡面具有研究能量的團體或者是機構可以做的研究計畫。

  • 目前的狀況是,最右邊的這個是我們委託一個公司建好的系統,資料的道路倒出其實還沒有完全自動化,包括年度綱要計畫的內容沒有辦法直接從剛剛所講的政府科技計畫資訊網直接導入到部內的系統,目前的折衷辦法是部裡面的管考同仁要把自己已經通過行政院核定的年度綱要計畫內容輸入進去這一個系統中。

  • 接著會到新聞計畫、執行計畫,讓主辦的同仁去檢查正確性,然後接下來要發包計畫以後進來的資料就會到最底層的執行計畫,讓計畫的主持人填進計畫所有的內容,以及將來追蹤期中、期末報告等等。

  • 我們也很感謝科政中心在GRB跟最底層的執行計畫中間讓我們介接,將來計畫主持人承接衛福部的計畫之後,事實上只要填衛福部的系統完之後,我們就可以匯入GRB去。

  • 但是一層層捲上來收合回來綱要績效的部分,則又落回到人工的階段,包括國發會跟科技部都會跟我們要管考的週期,月報或季報或績效報告等等,我們還是得人工式地從自己系統裡面搜來的資料撈出來,再回填回去,不管是GPMnet也好,或者是政府科技資訊網也好,因此現在系統的架構暫時是長這樣。

  • 因為我們的系統事實上剛做好而已,大概準備在去年前三季做一些部內單位的事情,希望在第四季的部內使用。

  • 我們也希望有一些精進的題目,其實還不曉得是否run得成或是否有問題。

  • 再者,剛剛也有提到這一個系統必須要跟科技部或者是國發會原來系統的介接,不知道有沒有辦法克服。

  • 另外,經由今天的討論,假設院裡面希望由科政中心整體政府科技資訊網接手所有工程的話,我們也很樂意配合。

  • 非常感謝。

  • 我們最基本的想法,葉副執祕很清楚,也就是任何事情只要任何兩個不同的人來做,結果都一樣的,那就應該要自動化掉。

  • 我們之前在前瞻基礎上已經規劃過很多類似的東西,終於那批已經送出去了,我們回過頭來想一下自己的使用者體驗。

  • 接著是農委會或者是經濟部?我們是按照順序嗎?

  • 不好意思,我是農委會的蔡偉皇,本來是沒有特別準備簡報,但是我想說要說明,還是用簡報跟大家報告會比較清楚。

  • 政委、葉副執秘大家好,我用三張簡報跟大家簡單說明一下,我們的架構跟衛福部滿像的。

  • 我們的計畫管理系統在90年初就已經建立了,我們跟大家報告一下農委會整個科技流程大概是從接續整個政府科技計畫流程下來之後,一直到我們去執行各個細部計畫。

  • 一開始會有一個總體說明,因為總體說明跟綱要計畫的變化性比較大,所以基本上這兩個文件我們並沒有把它正式做在系統裡面。

  • 正式有在系統裡面的是子項計畫開始,也就是綱要計畫子項是同一個位階,子項下面就會有各個執行的統籌單元計畫。

  • 接著右邊是規劃流程,我們就會從小到大把整個計畫的績效往上收合,整個會變成實體總和績效,整個流程是如此。

  • 我補充一下,整個作業流程在同一個年度大概會跨三個年度的作業,以今年來講的話,106年度的作業就會包含107年的先期及105年的績效作業。當然我們在進行各個執行計畫時,其實是年度計畫。

  • 配合整個流程,農委會有一個科技審議制度,基本上是會有三層架構,除了是三層在規劃面規劃外,同時第三層的推動小組肩負著銜接規劃與執行的角色,推動小組再往下是各個執行機關來執行。

  • 它當然是一個循環的作業,從最上面的政策規劃,包括是整體科技施政藍圖或是一些重大議題,往下交由評議會去針對各個領域有不同任務去推動所屬的綱要計畫。

  • 同時推動小組就會針對綱要計畫內要執行的各個項目去分工,最後由各個機關來執行,往上循環是把整個績效收合。

  • 最後跟大家報告的是,整個審議機制跟系統如何配合,基本上整個計畫的審議機制有兩個,一個是先期計畫、另外一個是年度計畫提升,也就是說,一個是規劃、一個是執行,當然我們的系統上設計就會有一個先期作業的規劃面的東西,還有一個年度計畫提升。

  • 但是原來在農委會的系統裡面,主要都是在年度計畫提升,並沒有先期作業的部分,它的功能並沒有那麼強,主要大概是資料彙整的功能,後續陸續把這一個功能強化,讓整個系統能夠在先期規劃與執行計畫及後續績效做出來。

  • 這邊顯示整個系統上會使用到的文件就是綱要計畫、子項計畫書及統籌或細部的計畫。綠色實線箭頭的部分是會在系統上填列,績效也會回饋。

  • 計畫的部分主要是提供彙整的功能,並不會實質作文獻的撰寫,因為畢竟在我們上傳計畫書到科技部網站的時候是分兩個部分,主要這個系統是做第一個部分的數據彙整。

  • 年度計畫的部分,其實在紫色的區塊我們就會上傳相關的文件到GRB系統。綱要計畫的部分,前並沒有直接上傳,我們還是用人工的方式key in。

  • 上傳GRB的部分,我們沒有直接作系統介接,我們主要是匯出Excel檔的方式,讓GRB系統作匯入的動作。這整個是農委會管理機制的簡單說明。

  • 非常感謝。

  • 我們接下來是不是請經濟部

  • 經濟部說明,目前部裡面就資訊系統的部分,因為我們主要是從細部計畫開始做起,所有成果、KPI、執行率的管考部分。

  • 我們今年也開始嘗試要做綱要計畫的管理系統,原本也希望能夠直接介接到科政中心的系統,因為今年科政中心太忙了,所以沒有辦法坐下來把系統談下來。

  • 這個是我們資訊系統的部分,至於整個計畫的作業流程,我主要說明的是綱要計畫的部分。就現有的機制來看,綱要計畫分成兩個,也就是重點政治計畫,像行政院公布施政的重要目標,我們來研提計畫。

  • 這個部分我們會依照院的政策需求,由各局處司來提案,因為我們局處司之間的分工是非常清楚的,因此我們原則上提的案子是不太可能重疊,但有可能合作,比如我們今年提的計畫是在材料開發的部分,我們就從技術處的技術研發做完以後,我們就會到工業局做量產的共同提案的部分。

  • 一般的計畫是由部裡面自己決定的計畫,這一方面的計畫剛剛也有提過,因為每一個局處司的定位分工是非常清楚的,所以原則上我們所提的計畫是不會有重複的情況。這一些部會的計畫,我們每一年都會開會檢視,並決定到底提案的計畫內容是哪一些,以上是我們經濟部的說明。

  • 有一個想要問的,您剛剛提到共同提案的部分,我們在跨部會的時候,這個是最大的痛點之一。

  • 你們自己的三級機關,好比兩個要互相搭配的時候,有無定期或者是線上或者是任何方式讓他們去協調?

  • 我補充一下,因為部內在每一個年度開始之前,就會就各局處提的案子在那邊做一些檢討。

  • 發現要整合的時候,就會在次長主持的平台上討論跟研擬,還有包含一些內容跟經費要協議。

  • 這個時程是配合預算提的時程,好比是在105年年底,大家之前就會啟動這樣的機制。

  • 瞭解,所以仍然是bottom up,也就是說只是bottom浮上來的時候,你看到性質類似,然後去併案,並不是上面要求底下?

  • 也有top down,比如說像「5+2」的新政策,top down下來的時候,那麼就會有一個大方向出來,技術處就要進入研發的部分,工業局或者是商業司等等就會搭配這樣子來進行,top down是以政策為主。

  • 所以兩個是不同的機制,應該這樣講,好,瞭解。

  • 不曉得科技部的朋友有沒有要補充的?

  • 主席、各位與會代表大家好,我先跟大家說明一下部內在整個科技計畫當中分兩個層面,其實跟農委會或者是經濟部,我覺得相似度滿多。

  • 第一個部分是top down,就是行政院或部長的政策,這一塊是這樣下來。

  • 第二個部分是bottom up,其實科技部有負責基礎研究、運用研究,其實有很多東西是從下面往上走,就是這兩個層面來走。

  • 我們走的是透過內部或者是外部的會議來形成共識,形成共識的時候一定會有外部的專家學者會進來討論,相關的會議中,一些資源上的整合或計畫上的合併,這個是資源或者是相關配置要有一些區別,又或者要針對政策性,或以bottom up的重點來處理,這個是我們的部分。

  • 其實我們跟衛福部一樣,在今年也是面臨到政策計畫形塑的時程,我們也一樣會遇到整合困難,也就是整合的時間點,其實我們跟衛福部有遇到同樣的困難,這個是做第一個部分的說明。

  • 第二個部分,其實我覺得重點在形成或整合的過程中,我們沒有透過什麼系統,我們後端用GPMnet來填報,像執行進度跟管考都是用GPMnet來填報。

  • 我覺得重點不是系統整合,而是我們在人,也就是計畫上面的一些溝通及會議上的協作及整合,以上先就科技部的部分說明。

  • 所以後面那一個,我如果快速綜整一下,意思是沒有一個很確定的workflow在top down的部分?

  • 每一次的規劃期間、什麼時候收單、什麼時候截稿之類的,是看狀況決定,並不是完全可預期的?

  • 你的意思是希望建立更好的作業流程系統,例如讓別的部會協作時一定約得到,或者定期檢視的機制嗎?

  • 應該是說政府所有東西的作業流程,其實都會有一個脈絡,像科技部就會跟科技會報辦公室來形塑,作一些安排。

  • 並不會說好像很隨機,這倒是不會,所有的流程都是跟著科技會報來做。

  • 所以是有流程。但是流程在執行的期間上,有時可能會壓得比較短,而因為這樣的關係,所以有些步驟被省略或者是簡化?

  • 因為我們都是配合科技會報這邊給我們的指示……

  • 不用講客氣話……(笑),我只是確認問題是什麼。是這樣嗎?

  • OK,好,瞭解,謝謝。

  • 我不曉得左側的朋友們有沒有什麼想法……對不起,我再問一個,這個可能是外行的問題。

  • 剛剛講的這一整套,從科技計畫資訊網輸入,然後整合,不管是手動收入或者是用Excel來整合,這個是科技計劃對不對?公建跟社發不是同一套系統,所以這邊講到無法介接的事情……

  • 因為我自己之前跟何老師合作關係,知道他們那一邊正在開發一套「全生命週期」的管理系統,這邊講到很多無法介接的地方,其實在那邊是有可介接之處,等一下也親何老師補充一下,謝謝。

  • 我補充一下,針對剛才衛福部講到綱要計畫承接,因為衛福部剛設計好,還沒有跟我要求要我導歷史資料給他,他如果要求,我們就會給。

  • 如果部會自己有自己的系統要餵進綱要計畫,也就是我們平台這一塊,經濟部之前有跟我提過,我說因為今年系統很滿,所以我們想說今年最後開發完成的東西,會有一個固定的模式,我們會提供固定的格式,讓他將來可以直接轉出來寄給我們。

  • 另外一個有關於GPMnet介接的部分,其實我們在去年底的時候,科技部有邀請國發會,因為國發會的GPMnet今年要全部重建,當初有一個共識……因為兩個部會在管制某些項目是不太一樣,而且那個計畫的層次是不太一樣的,因此沒有辦法合併在一起。

  • 我們那一次的共識是國發會是說以後有關於科技的這一個部分就全部由科技部來管理,所以變成是為統一在政府科技計畫資訊網填好了以後,我們會依照國發會的需求轉給國發會。

  • 我們在開發的過程當中也會去找他們,他們有一些欄位相同,也就是他們特殊原來資訊網,我們也會去follow他們的格式,到時候就可以整批轉給國發會,這個是去年底曾經有過的協商。

  • 去年底因為另外一個介接案,所以大概看了一些欄位,所以這個部分我大概瞭解。

  • 我先問一個問題,我們有沒有辦法像其他的系統,就像在協調的消防資訊,都是有一個統一的格式?也就是所有的部會都跟你介接GPMnet?也就是訂一個標準的格式去介接,訂一個日期,在那一個日期之前大家完成介接。這個一定要做得到吧!我們要把防救災消防雲那一塊搞了半天搞定,這個部分又比它簡單很多。

  • 是這樣子,就是說每一個部會在開發自己系統的時候,當然是有自己的考量,所以欄位之間會有一點差異,但共通性欄位一定是可以找得出來,也就是如果共通性欄位都討論好了,對於科技會報或者是科技部要看的是這一些,部會是在這一個基礎上增加他要的欄位,我覺得沒有關係。

  • 可是系統直接介接還牽涉到一個問題,也就是資安的問題,通常一般部會的資訊單位都不太願意設我的系統跟你的系統直接介接,因此後來有很多方法是用批次,也就是批次轉給我、我批次轉進去的方式,就是介接資安的問題,所以過去一直都沒有突破。

  • 這邊講一些原則性,像我們之前說Open Data的時候,大家都是講「匯出」,「匯出」沒有問題,不可能會有資安的問題。

  • 但是我們現在講API的時候,就會有匯入,確實就會有如果機器對機器接錯,或者是一個東西過來這邊變一筆,然後又有接回去,然後就迴圈了,那麼要怎麼辦的狀況。

  • 我覺得這兩個之間還是有中間的地方存在,也就是常常Open Data東西出去的時候,其實也是一個Excel檔,或者是一個CSV檔,本來就是一個試算表。

  • 葉副想要問的,是同一份試算表就是這麼多欄位,你匯出是這一些欄位,有沒有可能匯入欄位名稱,至少就叫這一些欄位,等於是共用資料的綱要。

  • 如果按照你說的,如果部會有額外的欄位,可能約定一個備註或附註欄,那個欄位可以是結構性的資料,可以把所有我們這邊沒有考慮到的,都還是納到額外的那一個欄位去,所以這樣的話,就還是可以用一張試算表就入。

  • 現在GRB就是這樣的做法,我們公布我們要的欄位是這一些,部會自己有系統的話,那麼就會轉出,他們就會把Excel給我們。

  • 但是你們這邊就沒有保留他們額外的欄位,就沒有用一個類似附註的方式進你們的系統?

  • 就像工業局的系統,非常複雜,裡面包括所有這一些預算的東西會科都有,其實對於科技會報或科技部是不需要這樣的資料,如果都要放進來的話……

  • 沒有,我不是都放進來,我是說好比在他的系統裡面有一個unique ID,假設是這個好了,我不曉得你們現在設計的時候,有沒有一個欄位是在原系統的unique ID?如果沒有的話,也許可以考慮真的是附註或者是來源的欄位。

  • 如果我們要細節資料或者是部會間跨部會討論時,還是回看到本來的系統裡,不可能所有的資料都倒上來。

  • 但是如果沒有一個回溯連結的話,我在這邊看到的時候,已經不知道本來是哪一筆了,你知道我的意思?

  • 我大概可以用年度加上中文計畫名稱去找,可是那個就必須人工,而不可能機器做。

  • 這個我覺得是有可能的,我相信資料庫裡面每一筆資料都有自己的unique ID,也許就是將來請他們再多提供一個Primary Key就可以了。

  • 就是提供一個Foreign Key就可以了。

  • 但是我的意思是,如果我們的資料格式或者是欄位長度限制太多,這樣就會變成某些部會其實納不進來,所以我們在做資訊設計的時候,是一個不限長度的欄位,也就是他們愛填什麼就填什麼,至少要填到本來系統的Foreign Key,這樣ok嗎?葉副還有沒有其他的(問題)?

  • 有沒有一個日期?就是整個這樣的可以?

  • 覺得什麼時候可以寫好……

  • 壓一個日期給我(笑)。

  • GRB本來就有這一個功能,我們再改變一下,再多一個Key。

  • 綱要計畫的部分,我們希望11月就要出來,因為10月不出來,108年就來不及了,所以今年底綱要計畫就會出來了,出來的時候,就會同時向經濟部技術處也期待他們自己系統建完以後,這個綱要計畫就可以列入,所以我們那時說我們今年會把它做出來,因此是在今年年底,為了108年就要上線。

  • 我們可以寫在會議紀錄裡面,也就是今年年底完成。

  • 至少用試算表的方式進行批次介接,就不需要單筆的匯入,但是批次匯入的那一個開口還是要開出來。

  • 不好意思,老師們有沒有什麼想法?

  • 我有一張slide,用slide來說明比較簡單。

  • 我是台大智慧社會科技中心的主任,我們中心比較擅長做這種使用者經驗的研究,所以我看這一些東西的時候,我由使用者的角度來看。

  • 碰巧我也是計畫審議系統過去是重度使用者,我說明一下,我們在看服務系統架構的時候,在當學校的老師比較喜歡什麼東西都喜歡有一個框架來看比較清楚,比較不會掛一漏萬。

  • 我們在看服務系統時,我是看HITACHI在談智慧運輸系統的服務架構當作例子,在看這一個事情的時候是分成四層,最上面是experience layer,接著是service layer,接著是information layer,接著是coordination layer。當然有很多人談IoT,還有一個感測層之類的,不過以我們現在科技計畫大概正好是談不上感測層,所以用這四層來看,其實是滿恰當的。

  • 他們在談智慧運輸的時候,experience layer是一天要上班時要如何導航,如何告訴你坐公車、接著坐火車的系統告訴你。

  • 接著service layer就會談你可能有一些票證系統,又或者是有一些控制紅綠燈的系統。

  • 接著是information layer比較清楚一點,也就是整個下面的資訊。

  • 接著是coordination layer,也就是把所有要提供服務的這一些資訊來串接、分析等等。

  • 如果以此對比到現在科技計畫管理平台的話,剛才我們在談的資訊網,其實我在看的時候,我就會說這一個資訊網,首先要問到底是要給誰用,不同的使用者,使用的目的、情境是不一樣的。

  • 以科技會報來講,可能會從前面的國家重點政策來看這一件事,然後看底下到底有多少的計畫在進行。中間也許不會管那麼細,可是到最後還要去驗收,也就是看看這一個計畫到底被執行的成果如何。

  • 以部會來說,剛才聽的結果是,可能部會有自己規劃管考的平台,所以對部會來講是要把計畫的內容導入,因此對部會的人員來說是填那一個東西。

  • 對審查委員來說,是要在其上審查,所以剛才談到一些量化或者是質化的工具,也許用得上,所以使用情境怎麼樣,大概都可以看得出來。

  • 在service這一層來看的話,不同的使用者要看的,或許是看趨勢、或許看政策、或許看計畫內容,可是也會看審查意見或者是過去的績效,或者是看整個政策有無缺口、有無何地方沒有執行到,又或者是計畫有無重疊及成果如何。

  • 接著是information,就是剛才談的趨勢、政策、內容及審查意見的raw data可以進去。

  • coordination是做一些交叉比對。

  • 如果這幾層來看的話,以現在的資訊網,如果未來要精進的話,我覺得可能對使用者或者是使用者的需求還沒有掌握到非常好,因為時間的關係,做好也不容易,我覺得可能有一些比較完整的思考。

  • 在virtualization的部分,其實也有一些可以improve的空間。

  • 在第二層service layer的部分,變成是要從上面的使用情境來看現在提供的服務,那一些模型是不是足夠。

  • 至於下面的information layer的部分,我覺得科政中心非常辛苦,必須要把整個概數表作很多的分析,剛剛葉副也有提到是不是可以引進AI等等,這當然都可以做的,但我其實覺得如果要我們先想好未來可能做什麼交叉分析的時候,事實上應該請這一個部會,當初填那一個欄位,不要到最後去mining,然後去撈出來,還不見得百分之百正確。

  • 舉一個例子來說,像經濟部工業局有非常多的計畫,剛才說這一些計畫都不會重疊,其實從人工來看,很難看得出來到底有沒有重疊。因為一個計畫表面上的產業看起來都是那一種產業,但做的事情其實不一樣,有的是在做人才培育、有的做趨勢分析、有的看法律是否修改、有的是做技術研發。

  • 不同的技術處、工業局的研發技術又是不同的level,整備度在不同的階段,因此要分析的時候,其實是困難的,也就是要用mining的技術去看這一些,所以像這一些,在裡面用的是什麼樣的措施,如果是技術研發是在哪一個階段的技術研發,像計畫的人自己填入,後面做一些交叉分析會比較容易得多。

  • 所以對information的部分,我建議未來想像要做什麼分析的時候,先想好讓部會去填。有時只是勾選而已,並不是真的花很大的功夫,執行的人自己知道,勾一勾,那麼後面就省事很多。

  • 另外,剛剛提到趨勢分析,正巧前幾天我聽到吳政委提到他希望IMC跟IEK有做一些整合,所以我不太知道這裡的趨勢分析跟未來的IEK或IMC所做的分析是不是有一些可以一起合作,不要再重疊。

  • information即各個部會的連結已經談了很多,我當然就沒什麼意見。

  • 接下來是交叉分析,交叉分析還是看最上面不同的user到底要看的是什麼。

  • 我提出以上的架構,讓大家可以一起來思考看看未來在發展、精進的時候,到底是哪一個地方缺了,看看是不是可以從使用者的觀點可以做得更完整一點。

  • 謝謝老師。

  • 如果沒有別的簡報,我們就掛在這邊,因為這張簡報滿不錯的。

  • 我自己進來之後,跟我之前在業界覺得差滿多的是,政府對內的系統很少做完整的服務設計。在業界那是標準配備,沒有做根本PM不會開專案的狀況。

  • 但是在這邊RFP(Request For Proposal)開出去之前,可能體驗設計有開過一些焦點團體,或者底下的資訊設計可能有做一些可行性評估,可是中間的服務設計確實是稍微少一些,這個是真的,所以我很感謝老師提出來這一些事,因為它是負責串接的一層,如果沒有的話,就會變成單點使用者體驗可以滿足或者是單一的information可以滿足,可是整個系統跟別的系統綜效就會看得比較不清楚,謝謝老師。

  • 不曉得其他老師們有沒有什麼想法?

  • 我想我們這邊是分兩個部分,一個是計畫審查、一個是績效評估的部分。其實績效評估應該是比較容易,因為成案之後有一個KPI,就是如何去追蹤這一些計畫執行及成果達成的情形。

  • 在計畫審議的部分,我想也許我們應該把這整個系統的背後理念稍微整理一下,我個人認為至少我審查的時候,我會想小的事情,好比這一個計畫是否值得做、執行的價值,這一個執行的價值就要看是否符合國際發展的趨勢,另外很重要的是不是符合科技發展的政策。

  • 尤其我的經驗比如是在審當時「五大創新產業」,後來又加了不少,審這一些旗艦計畫的時候,背後的方案,其實在審議的時候是看不到的,所以有一點見樹不見林,個別的計畫怎麼跟當初整個發展方案之間的配合情形是什麼樣是不清楚的,所以只能就內容來審查,是沒有辦法看到政策的契合度。

  • 剛剛科政中心也有提到會把世界發展的趨勢,比如五大創新產業發展方案的規劃書是不是也可以放在系統裡面,讓審查委員能夠很清楚瞭解國家這整個規劃的大picture。

  • 另外很重要的是,我們想要瞭解計畫是否有重複投資,也就是不同部會做同樣的事情,因此我們有設計相似度的比較,像這個當然是基本的。

  • 主要有兩點要考慮的,比如計畫相似度很高,但服務的對象可能不大一樣,也就是一個例子是智慧機械、人才培訓計畫,而這一個計畫其實在教育部有看到,在工業局也有看到,但對象當然不一樣,教育部是由學校來作相關的人才培訓,工業局是要對業界作這方面的輔導,然而這兩個計畫其實應該是要合作的,以後有這樣的比對之後,就可以知道這兩個計畫是類似的,也就是如何整合業界與學界作一個更好的結合。

  • 另外,一直以來我覺得是很難克服的地方,也就是跨部會的計畫,我們講說是鼓勵跨部會的計畫,可是一個計畫如何跨部會?因為經費配置的時候一定是放在一個部會,因此到時候跨部會如何合作一直有很大的問題,跟審議的平台不見得有關係,實質上我們鼓勵跨部會,可是合作的機制目前我覺得是不成熟的,至少我推動跨部會計畫是非常有挫折感。

  • 談到經費配置的時候,不曉得該怎麼辦,也就是一個計畫好比是科技部跟經濟部合作,假設經費放在經濟部之後,要思考如何部分的經回流到科技部等等,也許科技會報也可以想一下跨部會合作真正能夠運作的機制,然後再來檢討一下。

  • 像計畫執行應該是要看以前做的執行成效是怎麼樣,我不曉得現在這一個系統是不是能夠連結到計畫之前做了哪一些計畫、績效評估怎麼樣,因為如果績效跟計畫審議不能實質結合的話,其實那一個績效評估都是假的。

  • 當然實務上運作的時候還有問題,也就是績效評估在當年度做,計畫審議的時候是審後年的,中間總是差了一年,所以績效如何能夠比較即時反應,這個我們可以進一步思考的,以上。

  • 謝謝老師,確實,最後講的兩大部分,跨部會不只錢怎麼分,還有KPI的credit到底算誰的,三個部會分別答應負責找一個人,但其實是一個pipeline的關係,這樣難道一個人要算三個人嗎?

  • 在這樣的情況下,其實是非常常發生的,確實是這樣;績效評估的time gap要如何即時反應,這個是非常好的point。

  • 今天聽完報告以後很高興,以下兩點:

  • 第一,以前我想要做,但曾經失敗的事情,慢慢開始成型了。

  • 第二,因為不是我做的,所以下面講的東西,可能有些真的做不到,但是想像中可能可以從幾個角度來看。

  • 一、(一)我們要納進來的資訊很多,事實上是動態的大數據的系統,所以整個大data的管理機制,可能是在行政院或者是國家體系有一個同樣的機制,而不是個別作介接,介接完了以後,可能最後因需求改變,所以系統又改變,因此沒有這樣大架構的話,現在忙了半天,可能這樣的系統或者是機制可能維持了兩、三年,同時過程中會花非常多的人力在處理這一件事,因為系統一旦改變要重新學習跟訓練,因此中間會有一個過度期。

  • 我以前是政策中心的主任,每一個政策、每一個政黨的轉換都會有鎮痛期,等到快要成熟了,下一個人又來了、下一個長官又有新的想法,因此常常會非常同情他們(指承辦人員)(笑)。

  • (二)裡面可以包括一些資訊、一些很重要的專利資訊,各個主要公司的技術藍圖,還有其他國家的科技發展願景等等,這一些都是很重要的背景資訊。

  • 再者,很重要的是,我們這邊都講push,也就是提供什麼,但是民眾或者是產業界的需求,在這上面都看不到,因此審查委員在看的時候,都是從技術可行性或者是報告在看,但他們真的需要嗎?

  • 這部分的資訊可能有其他的資訊可以獲得,可能可以取得,這個是第一個大方向的建議。

  • (三)看起來各個部會都談到每一個系統需要整合,但是整合的方式都還是停留在資料的交換而已,事實上我們需要的是一個程序的整合,也就是如何使用這一個資料的程序,我們現在是在國家機器之下大體系的同一個系統,為何要在這一個系統創造資訊系統,然後再想辦法整合,乾脆是一個大體系,因為一個法規之下,所有的部會都應該這樣做,所以如果有一個大體系之下的話,各個看到不同面向的這一個系統而已,你只是管某部分的data,整個資訊是同時更新的,如果停在這一個層次的話,其實是有點可惜。

  • (四)我們用這一個體系或者是建構出來的系統來符合現有我們運作的方式,讓它更有效率,但更應該反思的是,包括規劃、執行及最後的管考,可能是太過依附於這一個系統。

  • 既然現在的科技可以發展,像政委或者整個新政府有考慮要更加精進的話,何必先放棄掉原來我們的框架,來看我們的科技及未來的需求可以有什麼樣的系統、什麼樣的架構,讓我們各個部會能夠做得更有效率——因為不是我做,所以可以亂講(笑)。

  • 二、科技是已經可行了,但我們在體系裡面的人都會說這一個架構不要變,然後在裡面微調,但現在這一個架構已四十年了,其他國家已經不知道更新到哪裡去了,我們還死守這一個架構的話,未來怎麼辦?這個可能是第二個可以想像的方向,不同的使用者在同樣體制下,就可以創造出不同的view、系統來serve不同的人,裡面的資訊是可以通透的,這個是第二個可以建議的方向。

  • 三、我們現在看得都是從資訊的填入,而我們處理的資訊是做計畫的人填的,所以再怎麼處理都是假的題目,如果亂填也沒有辦法check到底是什麼東西,因此在上面一直做處理,出來的結果還是會誤導決策,也就是你自己很高興,處理完很有效率,但是出來的東西,大家最後來檢討的時候,根本不符合國家發展的需要。

  • 因此資料的來源可能不能只是由提計畫、執行計劃的人填,還有其他的,是要提醒有第三方的審查機制,是不是能夠落實執行或者是有其他更多的資訊來確認這一個計畫,因為計畫不會是為計畫存在,一定是要跟社會的脈絡所連結,社會脈絡連結的部分是資訊進來的地方,因此目前來講都還是以審查委員的角度去思維,但我們應該看到從最後我們想達到的社會影響去看看如何連結,而這個部分應該是可以作思考的部分。

  • 很多處理可以自動處理,現在很多工具已非常成熟了,就不需要用人工在不同的地方一直處理,很多部分也不要讓審查委員去解讀。

  • 更重要的是,這個系統出來是要serve給最高決策者可以很快一目了然現在的狀況是怎麼樣、我們應該做什麼事,然後各個部會的首長或者是承辦人員可以知道我們在什麼地方,不要很精細,但是方向正確,知道我們的進展,如果能夠提供到這樣子,那麼就相當好了。

  • 四、最後一個建議是,因為你們太可憐了,會一直說我們在壓榨想要做事的人、能做事的人,有沒有想到他需要錢、需要人,有無到一個機制的轉換,好比我們需要政委強力的支持,其他人才能配合,不然很急也想做事,不然忙了半天,沒有power,沒有錢、也沒有人,即使有很好的人才,也做不了事情,以上。

  • 謝謝。都是政治性的建議,完全沒有含糊(笑),我具體回應一下好了。

  • 第一,其實前兩個建議可以合在一起,無論流程是不是國家級或以法律訂之,但當整個社會都知道我們是這樣制定科技政策的,自然在野黨也是政策制定的一環。無論未來是誰執政,都已經習慣這樣子的一套制定方法,就不會上來之後就推倒重練。

  • 第二,我們民間經常講的「Working Out Loud」或者是叫做「situation awareness」,我一面工作但是不排除讓其他部會的人知道我在做什麼,我在工作中間的這一些紀錄或者是這一些工作軌跡,不是我特別去寫報告或者是管考,而是機器在我工作的過程中就記錄下來,但是我不禁止其他部會的人看,自然跟我工作類似的人就知道我在做什麼,這有一個很廣闊的workspace的概念,讓流程的程序可以自然有機的整合。

  • 主要碰到的問題是,跟公部門事務官內部的reporting跟課責的機制目前是完全不是這樣子運作的,因此要如何說服公務員說讓任何隔壁部會知道做什麼或者勇於跟各部會老闆求救是很ok的,這個確實是文化上的工作,並不是我們寫任何資訊系統可以解決的,是要培養一個協作的文化。

  • 另外一個是,這一個系統還是以資料或者以檔案作為主要的centric的想法,我們現在會說是「工作區」或者是「以協作文件」當作基本的想法。

  • 可能我們底下的information層或者是coordination都在雲端,可是上面的感覺好像大家各自用各自檔案的感覺,確實這個是很有效的批評。

  • 最後一個,是不是需要上位的政策或資源的一些支援?我做逐字稿就是這樣的意思,我還是要讓大家看到我們有在想這個。

  • 然後社會上,包含公民社會或者是其他利益關係人,也會知道我們正在做這一件事,然後由他們來施加壓力。

  • 通常這樣是比較有用的,政府就能表現出很有承擔的樣子(笑)。不是說政府向公民社會或者是向私部門課責,沒有這樣的事情。

  • 這是大概具體回應的問題。

  • 主席、各位委員、各部會的同仁,我是國發會管考處的處長。

  • 就這一個議題我提供幾個經驗分享:

  • 第一,在做這一個系統的時候,可能上位要先拉回到整個國家對於施政計畫管理制度的看法,這個是最重要的。

  • 新政府上來以後跟過去有不一樣的方法,過去都是用中央集權的管制,可是現在慢慢會趨向分散式的治理,我想這個是很重要的原則。

  • 所以如此的話,目前國發會在發動是這樣且貫徹,我建議科技會報辦公室也能夠往這個方向來做,並不是所有的問題都課責在科技部或者是科技會報,因此應該回歸到最原始的部會治理及提案單位本來就應該把計畫做好,這是很大不一樣的思維,因此這一個思維會影響到整個系統的設計,而這個系統的設計並不是為科技會報來設計、也不是為科技部來設計——真正要把案子做好,並不是提案單位,而是管考單位。

  • 第二,政府整個施政作為除了從中央集權集中的績效管理變成分散式的治理以外,很重要的是:配合開放政府政策,即要有透明治理、民眾參與機制在其中。

  • 我用白話來講,我們需要公民管考機制在設計不管是公共建設計畫、科技計畫及社會發展計畫,過去是沒有這樣發展的設計,因此未來的考慮面做了很多的東西,如果民眾沒有感受、沒有參與的感覺等方式,很難跟立法委員或者是社會公民說我們做了很多事,因此這兩個理念的設計,似乎應該在系統當中表現出來。

  • 我舉一個例子,好比像NASA很多計畫的推動,除了NASA的工程師以外,也開放民眾參與,好像我們有兩千三百萬的同胞都是科技會報辦公室的公務員,因為有參與感,所以會提供很多的意見。

  • 我想唐政委在推開放政府的概念是這樣,我想這個是很不一樣的思維。

  • 我覺得管考系統是工具並不是目的,我們並不能花太多的時間、支援在此,因為解決不了我們剛剛所談的問題,我們必須同這個角度來談思維。

  • 真正重要的是,配合這樣的機制設計,如何讓提案的單位能夠把它管好,而具備何東西,因此開放政府、透明治理及全民監督是很重要的。

  • 這也可以解決科技會報辦公室、科技部,你們有辦法勾出看每一個計畫,也就是看每一個計畫,一定會有掛一漏萬,也就是靠公民來監督,我想說也不會想說為何這一個計畫老是由一個法人機構來做,且老是做不好,比較透明且邁向公平的支援分配角度,這是很重要的趨勢。

  • 第三,有關於管考的做法,科技部跟科技會報應該用抓大放小(方式),集中剛剛所講的總統、院長的幾個重大施政,必須把所有的人力、精力擺在這個地方,有做深度及專業的管考。

  • 像各部會的那個部分,也就是應該回歸到部會的機制,因此在未來的機制當中,也就是「抓大放小」。

  • 而且可以用多元管考的方法,現在所有的公務員都被灌輸一個觀念,也就是填系統,這是價值觀的措置,把目的、手段措置,因此我認為這一個部分是多元,也就是管考並不是填報考系統,實地查證也好,或者是走動式的管理,又或者是座談會到這邊來專報,會有很多種方式。

  • 另外,過去的管考或者是績效管理是從供給方來看,自我感覺良好,如「優等」、「甲等」、「乙等」;但是(反過來說),並沒有從需求方——需求方即民眾評價——企業對政府研發出來的科技成果無評價此研發是否對民眾有幫助,因此觀念思維的改變,也會影響到整個系統的設計。

  • 另外,因為國發會的管考會把政府的部分作第二波配合新政府的分散治理概念,也就是系統做很多設計的同時,因為管考的觀念改變了,而系統設計的功能就會改變了,因此看進度跟執行率已經不是我們最主要的目的。

  • 未來的管考有幾個重點:

  • 第一,是否能夠幫科技部,從系統發揮預警功能及風險管考,讓我們及早知道計畫是否會失敗,而不是等到最後面才來處理,那已經沒有辦法了,因此這一個部分是配合此理念,你的系統會有不一樣的設計。

  • 現在不管是工程會、國發會或科技部或科技會報的共同理念是,我們對於計畫的管考並不是只有在計畫執行完畢的管考,我們用的術語不管是全生命週期,像過去的提案計畫等等到計畫結束,甚至後面有一些是要做營運管理的,整個循環會回歸到先期作業及支援配置。

  • 如果那個機制沒有做的話,我想這一個績效管理是空的;甚至未來有沒有下車的機制,如果做得不好就砍斷。

  • 因此未來要特別著重,也就是從系統當中能否有一些預警性,讓我們能夠及早介入作跨部會的協調,管考的目的是讓計畫能夠順利完成,有的問題透過科技會報的平台、透過科技政務委員、透過院裡面及早幫他協調及解決,這個未來很重要的(部分)。

  • 像剛剛劉老師所說的,不同的使用對象,可能的情境也不一樣,如果是從科技會報辦公室或者是行政院的角度,要看:1.資源分配的結構是否合理,好比新政府要作「產業創新」;2.地區分配是否合理;3.法人有無過度集中。

  • 因此,此部分在將來的管理資訊必須要滿足此東西,包括我們投入地理的分布是否合理,過去這部分是沒有的。

  • 另外,我們也知道各部會科技預算會委託哪一些單位執行,是否會過度集中等等,這一個部分我知道將來包括執行的評價等等。

  • 一方面我們要滿足行政院或者是科技會報辦公室對於科技一千多億的預算需要這一個結果的呈現,到底系統能否提供。

  • 至於各部會的操作性,那不是問題,那比較容易來做;有沒有重複的單位,我想剛剛已經談了很多。因此,在此系統當中還沒有看到開放政府的透明治理。

  • 政委在推動這一個工作,我們也配合她的政策履歷,因此我們現在先做計畫履歷,3月29日之後我們就把院列管的六十項計畫都已經在「公共政策民眾參與平台(Join)」中,慢慢擴及到一千多項的計畫。

  • 這部分涉及到如果改版要精進我們的執行策略,而這個用英文講就是「Plan big, start small, quickly scale up」,因為太多的改革不太可能壓榨他們,剛剛林主任已經講了(笑)。

  • 既然做的話,幾個單位包含國發會——事實上過去都在做——跟政委報告,優先做的部分,現在已有共識的部分是把國發會的公共建設管考跟工程會將來要統一,也就是避免重複。

  • 未來是不是可以跟科技部談這一個東西,因為談API,以前有兩個策略,一個是統、一個是整合,整合的話,以現在來看,大部分是整合,很少統一,我想這一個技術變化很快,不應該排除統一,也就是使用單一的系統,以減少大家各自的成本。

  • 即使在短期內沒有辦法統一,這一個資料檔案的轉換,我們國發會也是配合唐政委的政策,是用Open API的方式。所以這一次國發會新改版中,我們會把Open API做出來。

  • 因此簡單來講,管考的系統是為了支持整個科技預算施政績效的目的,是手段、並不是目的。

  • 再者有很多新觀念,在未來系統當中可以逐步分階段來做,因為我們已有很多基礎。

  • 用白話來講,整個未來科技系統的改版,就是要符合白話,也就是透過確保這樣的機制,輔以資訊系統,能夠讓各部會提出來的科技計畫,叫各部會首長拍胸脯說既然說到、就要做到。

  • 我們過去只有談說到、做到,但未來管考系統除了說到、做到以外,更重要的是讓民眾看得到。

  • 再者是讓民眾用得到,包括這一些累積的成果資訊,這樣的好處是全民可以共享,從全民智慧當中可以輔助政府機關或學者專家來專案審查不足的地方。

  • 我剛好最近在做管考創新簡化,也配合政府在推的政策履歷、計畫履歷,也跟工程會談,因此未來會進一步(處理)。

  • 事實上我們之前也請同仁跟科技部談,這一個改革或者是系統並不是短期的,我們有長遠的目標分階段慢慢往前邁進,以上建議請大家參考,謝謝。

  • 非常謝謝何老師這一波完全是事務性的說明,和剛剛政務性的建議恰成對比。我快速兩、三分鐘之內回應一下。

  • 確實「分散式治理」的概念是全面的,不只在於區域創新、地方政府或者是對各部會。

  • 如果一開始上來就是bottom up的話,我們不要一半就跑到top down去,這樣子其實是讓它長不起來,這個跟「抓大放小」的概念是非常能夠銜接的。

  • 剛剛提到NASA,也就是透過透明跟參與的方式,也讓兩千三百萬人……像他們來這邊辦黑客松,NASA明明不是臺灣的單位,但也可以開放,讓地球上感興趣的人也參與到他們的太空計畫,這個之前是叫做「群眾外包」,現在是叫做「公民參與」。這和「開放政府」是非常類似的概念。

  • 剛剛何老師提到在「公共政策網路參與平台」把院列管的計畫放進去,目前看到除了國發會之外,主動願意上去說我們來回應網友的,目前只有經濟部技術處的一個案子,其他的人都說等季管考再來說(笑)。

  • 這個確實對同仁們是額外的系統,彷彿又多了一些額外的管考人員,又多了一些額外的負擔。

  • 一方面,我們可以說引進這一些系統可以省他一些力氣、達到先期預警的效果,這個是一個。

  • 但部會更關心的,是回應只是一個小編、一個編輯的作用。如果上面真的會有足夠的power,好比像國發會或者是科技部,如果有很多民眾的意見告訴你說這件事應該下車或者是改方向的話,真的可以讓他跟長官說這個計畫下一期的時候要改一下,這樣回應才有意義。

  • 如果這個是鎖死的,永遠沒有議程設定權,那就是看到越憤怒的民眾,工作只會越多,並不會越少。

  • 因此這是相互的,也就是要賦予業務執行單位更多的分散式的治理權,才會願意去處理民眾的意見。如果怎麼樣都還是被院綁住,面對民眾只能說「抱歉」,不然還能講什麼?所以這兩個概念是要放在一起。

  • 很高興聽到關於公共建設的部分,管考跟工程會會統一,這個是說要做「開放政府」之後,民間問得最多的題目之一,也就是工程會的Open Data之前做一半,但是現在用API的概念……像我們在「民生公共物聯網」用的精神是「前後分離,前端統一,後端整合」,意思是大家前端用的體驗是一樣的,後端還是三、四個系統在跑,沒有關係,它們中間介接起來就好了,這個是我們技術上的回應。

  • 謝謝我的好朋友們已經回答99%了(笑)。

  • 有幾個心得跟大家報告一下,因為今天談的是科技計畫,而科技計畫跟很多公共建設計畫是不太一樣,像蓋橋梁跟馬路基本上是沒有風險的。

  • 科技計畫本來就是要允許有很多自發性的冒險,這兩個不太一樣,因此將來如果要結合的話,就麻煩注意一下這兩者的差異。

  • 我的感覺是,理論上任何科技計畫應該要提出所謂的價值主張,我花這一筆納稅人的錢,到底代表何價值,這個是所有科技計畫的起點。

  • 目前格式的設計,一開始是政策依據,如果邏輯上來看的話,那就表示我們的政策必須領先科技發展,不然每做一件科技發展,都要說政策依據什麼,這樣邏輯上有一點怪。

  • 因此我有一個建議,所有的科技計畫最前面是要寫「價值主張」,如果剛好跟已經有的政策match最好,如果沒有的話,也要寫,不然很奇怪,我們要確定政府是偉大且賢能,事先都知道科技要什麼,然後再把政策擬出來夠打勾,這個是我的建議,應該從價值主張開始。

  • 中間執行的部分就不用再討論,最後是到底有沒有完成那一個價值,這一個部分平心而論,我們在績效計畫評估,其實多的是量化的東西,但是量化的東西一般來講是短期的,那一個部分有些是活動等等。

  • 至於這一個計畫會達成何價值,其實有很多還是人工進去作合理推估,因為計畫結案的時候,將來產生很多的影響還沒有出來,從專家進去作合理評估,我想這個是可以評估的。

  • 這一個部分老實講很難自動data,不過我們是有績效評估;然而平心而論,有時我們評審委員有時也需要……講教育有一點難聽,就是要協助一下,也就是他們如何進行對於這一些計畫合理評估其價值。

  • 計畫的績效評估已經有了,但計畫所呈現的價值面是什麼,這一個部分是我們可以請各位委員多協助的。

  • 再者是執行面的,像剛剛所講的是計畫cross check有無重複,那一個部分並不難,我想剛剛講的database有好處,因為至少第一層把字一樣的先挑出來或者是很接近的挑出來,確實是有幫助。

  • 其實我自己的經驗是因為我是當一個領域的召集人,那一個領域是七、八十個人,是用人工看的方式,也就是七、八十個cross check,檢查之後是沒有重複。

  • 但是慢慢得到一個心得,計畫重複執行的這一件事並不嚴重,也就是同一件事不該做而做的這一件事並不嚴重,真正嚴重的是該做的沒有人要做,真正麻煩的是這一個。

  • 不過這個是從我們在檢查計畫名稱裡面,事實上這個是沒有辦法呈現的,這就是我們所謂top down的價值,不過這一個部分葉副執秘很有辦法處理這一件事,所以我們就報告到這裡(笑)。

  • 葉副執秘有沒有對最後要回應(笑)?

  • (笑)沒有,沒有,這個我不敢回應,不然工作會做不完。

  • 我可不可以補問兩個問題:

  • 第一,我非常贊同何處長講的,但是我每一次跟博文兄講,他都不願意做。人家企業都會有「Business Intelligence」,其實project也可以建立「Project Intelligence」的index,其實我說這個,博文兄是專業的,其實是可以協助幫助我們建立這一些模型,每一個計畫選擇一些模型來做,其實是更有效度的,因為企業都可以這樣做了,為何我們沒有辦法這樣做,我們就不曉得,因此KPI跟「Business Intelligence」其實是相輔相成的。

  • 其實你看我要講這一個,博文兄的椅子就一直往後退、往後退、往後退(笑),每一次都來這一招。我是覺得我們真的需要專門一個做計畫管考的人來幫我們做index,不然到最後大家會亂填一通,其實是沒有意義的。

  • 另外一個何處長講的,計畫結束其實是要繼續分析,而這一個分析是要回饋這一個組織是否適合執行這一類的計畫,這個組織計畫很爛,為何要繼續做?其實我們看不出來這一個問題,合理的計畫是計畫執行有第一個層面,也就是選了四年期的計畫,我兩年之後就看這一個計畫後面衍生的效益到什麼程度,這個才會有道理,這個東西才會繼續活下去。

  • 像以前智慧生活的計畫裡面,一開始政府補助三年,最後剩下劉老師那一個,其他的是計畫結束,隔天就關掉了,另外一個是多撐兩年,因此這樣會看出真正的效益會不會延展下去,這一個follow up很重要,我們現在都沒有人做,其實我們現在可以選一些來follow,這個延展性就會出現,因此我們非常配合何處長所講的。

  • 另外,剛剛所講的index,我搞不清楚index如何設計。舉個例子:好比做一個計畫,而計畫是說會產生社會效益300億,我說:「如果會產生效益300億,我先投資好不好?」,他說:「沒有,這個是跟其他計畫連結的整合效果。」,我說:「到底是誰算誰的?」

  • 因此,我一直覺得大家寫績效指標的時候,真的要好好分類,到底是計畫直接產出,或者是計畫跟計畫間連結的產出,或者是計畫跟社會效益的直接產出,請大家直接分清楚,不然大家只寫兩頁,但是計畫直接產出是零,所以我看到很多計畫都寫後面的部分,因為不要commit,因為後面是沒有辦法查核的,現在就發生這一個問題。

  • 因此,我建議以後的指標就分這三種,也就是直接產出、其他連結產出及最後大家預期社會效益如何,這個沒有關係,因此可以分三層,但計畫還是有直接的效益;但是現在大家都不願意寫直接效益,而是畫一個很大的餅,因此根本沒有辦法查核這一個餅是真的或者是假的,這個才是執行計劃沒有辦法看到的問題。

  • 我真的建議我們的「價值主張」,任何一個「Business Model」,也會講「價值主張」這一件事,還是要很清楚把它寫一下。

  • 我之前從來沒有在績效管理的組織待過,行政院是第一個(笑),因為我之前在業界全部都是目標管理,大部分都是自行設定目標管理,所以那個「價值主張」對我來講是天經地義,因為我每一週就要回去看我的key results到底長什麼樣子,當然是明確可量測、可達成相關,因為我就做這個。

  • 但是我後來發現因為我工作大部分是科技公司,也就是這個在研發上面或者是科技上,也就是剛剛老師說冒險的部分,其實才比較make sense,因為設定這一些「價值主張」,隱含即使達不到(結果),但過程也有貢獻,像造橋鋪路也這樣玩,大概是不太可能(笑),我想社會沒有人可以接受橋垮,我們也有貢獻的想法(笑)。

  • 所以我同意確實科技計畫跟其他的建設計畫有差異,可是現在常常看到的問題就像葉副講的,當看在填KPI的時候,很像是蓋獨橋的方式在填,並不是設計橋或研發橋的方式在填。

  • 因此我很同意不管那個欄位怎麼分,但盡可能要告訴寫計畫的朋友們說可以提自己的價值主張,即使價值主張政策裡面沒有寫,那個可能更好,因為表示是有補上漏洞,如果「5+2」然後底下又「2+1」的部分有寫的話,基本上是沒有什麼太容易有漏洞的地方,因為至少邏輯上前後一致,但大部分的科技是發生在這一個交錯之處,或者是沒有cover到的地方,這個概念是非常感謝。

  • 有沒有什麼第二輪的說明?

  • 我回應一下,事實上江前院長,包括立法院、院長及張忠謀對於政府科技投資的績效跟是否有前瞻有很多疑慮,我記得那時我也有參與過,當時江前院長就請鐘嘉德,如果我沒有記錯的話,不曉得是中華還是誰來做報告。

  • 科技預算有時真的很難評估直接或者是間接,我們更應該重要重新思考科技計畫的KPI,像人次、交流規劃等通通不要,如果計畫可以做「價值主張」,像最重要的政府跟民間不一樣,成果會有地緣性,可能三、五年才會有影響。

  • 像我們從Apple來看,像過去的成敗變成之後可以做出iPhone跟iPad,所以我覺得更重要的是利用這一個機會,我們重新檢討,那一些做了,結果反而是增加各單位的paper work,辦了幾個場次的交流規劃報告,我們也不要增加同仁的工作負擔,因此如果可以的話,那麼「價值主張」是什麼?有些是須比較長的時間來作後評估,以上大概建議,謝謝。

  • 可能我們某些KPI unit就禁用了(笑)。

  • 我不曉得還有沒有朋友要發言?

  • 衛福部的朋友第二次代表發言,謝謝委員跟長官的指導,我們這邊補充兩個意見:

  • 第一,剛剛提到績效的部分,事實上不同部會的科技績效展現可能有不同的態樣。

  • 我非常同意剛剛何處長講的遞延,但現在現行科技計畫的任何追蹤機制中,是否有辦法追蹤到遞延何時產生,以及「價值主張」何時會展現出來?

  • 我舉一個例子來講:像我們關注兒童的健康與安全,有一些是做新生兒篩檢,但我們科技計畫可能某一種態樣是屬於新生兒篩檢的技術研發,事實上技術研發出來之後,在這一期科技計畫當中,充其量只能告訴你們技術研發出來了沒,比如經過學術界國際雜誌同儕評比,確立valuation這個技術是可行的,但問題是科技計畫到此就結束了。

  • 接下來要產生所謂的價值,必須要透過衛福部其他的工作計畫,比如要先做過經濟評估,因為篩檢總共有七個項目,我們要擴及補助到九個項目,也就是多兩個項目的時候,這時從預算支持的角度去看要投入多少的資源,產生的影響是多大,這裡面的cost benefit要不要先算過?我們什麼時候開始做全面的施行?

  • 這個東西事實上就會牽到後面,完全不是用科技計畫、科技預算的經費,但是整體施政的結果,而且必須要經過一段時間之後,會去monitor效益展現,我們促進了多少新生兒的健康,這個是需要後續研究跟工作投入。

  • 我們目前對科技計畫追蹤、績效追蹤有無辦法設計到這一個階段,也就是後續要追蹤多久、要如何monitor搭配的工作計畫之後所實施的效果,因此這一個部分還有一些討論的空間。

  • 第二,剛剛大家都有提到,原先在第一個報告裡面所講的政府科技計畫資訊網,目前所做的任何功能增進,使都還是著眼於管考的角度、著眼於在事前規劃時能否弭平重複的問題,但是沒有辦法更積極提出剛剛幾位委員點到的,也就是有無辦法做一個gap analysis,告訴我們國家目前有哪一些缺口,這一些缺口很可能是由哪一些部會來承接此任務。

  • 如果這個系統有辦法再更增進做到這個地步時,或許在決策層面可以將這個分析的結果散給各部會,形成真正部會top down的政策型計畫。

  • 非常感謝。

  • 不曉得還有沒有朋友們想要發言?

  • 我回應一下,因為各部會在填寫KPI的時候,說句老實話,他們通常會寫產出,不太會寫過程效益,所以有時有的計畫會覺得因為每一年都要做績效評估,會覺得這個才第一年,哪裡會有什麼成果,會不會審查委員就評得很低,因此我們一直想要推的是,教部會如何去解構效益。

  • 至於事後追蹤的部分,其實就像GRB一樣,我們讓人家填KPI的最早設計,希望老師執行的這一個計畫、產出什麼,過後可能還會有更多的效益,但是說一句老實話,沒有人要理我們,因為已經結案了,絕對不會願意再回頭來填,這個有一點困擾。

  • 因此我今天報告的是,政府科技計畫資訊網其實有關績效的部分我都沒有提,其實我們今年想要嘗試先做各類型計畫的績效群組評等系統,我們也許不看個別,但是是看群組,當然這到底要怎麼看、如何採用哪一些指標,還要找一些專家來討論。

  • 另外一個,對於某一些計畫事後的績效追蹤,這個機制比較適合用個案的研究方式,有就是挑重要的政策或重要的計畫來作個案的評估。

  • 因為這一次也有評議專家適合,其實這一個部分都有納入在裡面考量,不會有另外一個團隊來做,這個是我在資訊網裡面沒有辦法提出來的,因為那等於是審完以後發生的事情。

  • 不好意思,「缺口」這件事很難,因為沒有願景(笑)。

  • 確實。(笑)我想我們有做逐字稿,也不表示整個過程就完全透明,但是至少不透明的部分我們都看得到。

  • 所以同樣的道理,系統建出來不表示說就沒有缺口,只是哪裡有缺口,我們比較清楚而已,相信是這樣沒有錯。

  • 有沒有朋友要發言?

  • 主席、各位與會先進,剛才衛福部所提到的中長期績效評估的部分,也就是在延展性效益的部分,我們在去年有找過相關在做績效評估的一些老師去開會,也有討論這一個問題,其實我們當時在討論時,其實比較傾向這一個計畫在規劃時,其實應該做預評估,看一下這個計畫預期執行完的三、五年後會衍生哪一些效益。

  • 在計畫結束之後,我們當然只能做當年度評估,但是計畫真正再過三、五年以後,我們其實是期待由部會這一段,依照當時預評估的方法,來追蹤是否有達到當期效益。

  • 為何會期待各部會來執行?因為各個科技計畫的屬性其實是相對比較複雜的,因此這一件事很難由科技部統一來做共通性的處理,這跟當年度的績效追蹤是不一樣的,以上回應。

  • 剛剛提到一個實質的困難,也就是剛剛提到挑的量測,除非是可以被動量測的,好比像到某個網址、看某個數字就自動拿到那一個數據,不然還是要花他們的人力來進行填報。

  • 尤其如果是bottom up的話,其實是上千個,從部會的角度來看,這個會變成永遠不能結案的感覺,也就是要花非常多的人力來做這一件事。是這樣嗎?

  • 所以我們當初在討論的時候,其實也建議先擇重要的重點性政策,可能擇幾項來試行。

  • 暫時不太可能先做大規模的執行,這個部分耗費的人力跟資源實在是太龐大了。

  • 沒問題,不曉得老師們有沒有什麼可以想問的?

  • 我補充一下,現在國發會公共建設計畫已經在做後評估,但我們不是全面的,我們是挑一些重點,即使是失敗,也是很寶貴的經驗,因為後評估的效益,一方面回饋到資源分配,甚至有些不是到專案經費,而是到一般的經費,這個可以用。

  • 第二,經驗的分享可以避免大家犯同樣的錯誤,那就是我們非常重視的後評估價值,因此事實上在公共建設後面的營運評估已經在做,雖然不是全面性的,大概挑避免各部會造成比較多的資源投入,以上說明,謝謝。

  • 就我的理解,剛剛跟衛福部都有提到一點,也就是計畫績效評估的事情,我想政府科技計畫、公共建設計畫及公司治理是不太一樣的。

  • 第一,因為政府科技計畫是外延性,外延給廠商,所以價值是spillover出去,現在問題是spillover出去之後,那一段的價值很難有數學上很清楚的coordination。

  • 然後,不只是spillover,因為還有外面進來的,像剛剛衛福部提到的一件事,現在開發出來的technology,但是後面去implement的時候,還有政府其他的措施、廠商自己的投入,最後看到end result,這個是常常被挑戰的事情,也就是最後結果是這樣,所有的委員都會挑戰你說:「你跟我講coordination有多好?」,這個永遠講不出來,這一件事的特性是如此,就不要再想下去了,因為東西的特性就是這樣子。

  • 第二,剛剛講跟私人公司不太一樣,比較不會有外延性,也就是投入,然後賺錢回來,比較不會有這一個問題。所以,我覺得事情的特性就是長這個樣子,因此就接受它。

  • 我的意思是,為什麼最後那一段有需要人工進去作合理的推估?這個是無可避免的,這個是無可奈何。

  • 瞭解。就是面對它、接受它。

  • 後續我們就來處理它。

  • 我們再用一個工作小組,把今天委員的建議,各部會有一個人follow下去,看幾次的會議做比較完整的建議案,再請各位委員回來看,我們再提給政委。

  • 謝謝。如果沒有其他發言的話,今天非常感謝大家的時間,準時結束,謝謝大家。