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

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

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

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

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

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

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

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

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

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

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

coordination是做一些交叉比對。

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

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

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

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

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

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

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

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

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

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

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

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

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

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