是讓實體票有一些紀念價值。

有發證的時間、行政區、日期。

會不會給百分比也是好的做法，像2,800是一個分母，然後分子是人數。

我要補充一下，目前我理解的狀況是一個子區域可能會有二至三個節點，其實或許如果真的關閉資訊，也許一站式可以做一些檢查機制，也就是在申請的路線當中，不可以有比如像某個子區域，像A至C點，我們在檢查申請單的時候，如果裡面有A至C的點，就直接在檢查當中說不通，就不會有送到林務局去，然後有再被打槍的問題。

我再提一下有關於資料結構的東西。剛剛有提到這兩個設計，也就是我們用這樣的方式紀錄，也許可以從歷來申請的路線再找出一些熱門的路線給使用者。

我們補充一下這邊想要建議拆單透明化系統的另外一個理由，因為剛剛說拆單機制，我們建路線資料庫、節點資料庫幫我們算出來，因為基本上工程師不一定是爬山的山友，所以不一定可以建出完全百分之百對的資料庫，所以拆單透明或許有一個機會讓他們回饋拆單是拆錯或者是比較不好的東西，因此才會想說讓拆單的這一件事可以讓民眾看得到。

我目前看API的狀況資料，並沒有非常好的動態random，兩邊可能要再協調一下，也就是API回應的Schema如何描述新的欄位會比較好一點，這邊還沒有到OpenAPI的標準來描述。

我這邊提異動 webhook，目前只會有每個管處的變動可以回來（一站式），但 A 管處變動不會到 B 管處去，如果異動的話，可以同步回一站式整理之後，我們下一步想要怎麼樣把一站式的資料Sync到各系統去，以上報告。

第一步是在一站式這邊建立 webhook，也就是在各管處的系統進行異動時，管處的系統也有機會回饋回來給一站式系統，在這一步做完之後，再建置讓一站式的資料改變的時候，再 sync 到各管處系統。

接著是申請單的同步機制，剛剛有提到遇到山屋要退部分人的狀況。現行的狀況是，要減少成員或者是修改成員的資料，民眾透過電話請管處異動，異動完的結果不會回到一站式，兩邊的資料不會一致，會有越來越重的落差，來回涉及的廠商不只有一間。

我們在合乎規定的時間內，像時間到了，比如民眾兩個月之內申請，到了倒數45天就轉送警政署的單，甚至在這個機制底下，如果發現有單點失敗的狀況，可以設計一定次數的重送，如果假設可能在三天之內可以重送成功之後就不會衍生其他問題，如果一直重送失敗，一站式也要有機制，也就是批次把部分管處失敗的單匯出，然後透過人工的方式轉送申請單，也就是讓管處來作處理。

另外一個建議一站式收單與轉發機制，這個跟剛剛前面簡報有提到所謂「等待轉送」是有一點關係，先講一下現行的做法，現行的做法是如果一站式收到單之後，會回拋給各系統來檢查，檢查都成功之後，然後開始發送，然後才會回一個申請單號給民眾，但是這樣會有一個問題，像剛剛前面提到的避免單點失效，先前有小段時間警政署的部分API壞掉了，整個申請就沒有辦法做了；另外剛剛也提到現行制度有所謂日期不統一的狀況，像警政署45天前，國家公園是可以到兩個月甚至是120天的狀況，這樣民眾也沒有辦法送單，所以會建議改成這樣的狀況，我們在做一站式收單的話，我們只要日期符合其中一個管處的規則，然後就會收下來產生單號。

但是現在這個比較大的問題是自然保護區的狀況，像林務局就有反映從後台更動保護區的申請表，一站式沒有辦法即時反映的狀況，這邊會有一個狀況是，假設今天林務局調動的欄位，一站式還是沒有辦法做很好的自動響應，像欄位是從A變成B欄位，那他可能會有一些 mapping (對應)關係，比如只是填的格式改動了，但是自然保護區給API的資訊可能是不一樣的欄位，但一站式也沒有辦法透過程式化知道這個欄位原本是要對到之前的什麼欄位，因此自然保護區的廠商要幫忙想一個比較完整、比較好理解，如何 render (繪製)動態表單的API結構。

雖然剛剛說我們講了比較好假設的部分，我們假設可以做拆單，但還是會面臨一個問題，每個管處欄位還沒有到一致的狀況，這一些欄位可以分成兩種，一種是相較固定，像國家公園、警政署、林務局山屋的這些系統，他們欄位是相對比較不變動，一站式系統在設計的時候可以先設計好直接撰寫在程式碼中。

同時如果有這樣的概念之後，管處對於被一站式拆出來的申請單有哪一些奇怪或者是看不懂，有疑慮之後，也可以藉由這樣的方式回來一站式看這個使用者申請的完整歷程，到底要怎麼樣走，釐清為何在某個管處只有申請某個部分的狀況。

上面會有一些概覽，也就是 Summarize 各個申請的狀態，這邊有一個「等待轉送」的部分，我後面會再解釋後面的東西是什麼。之前有蒐集到的資訊是，民眾會把一站式的單號拿去管處詢問，管處反而會對不到申請單，我會期待的是，如果有這樣的東西呈現給使用者，他們會知道在一站式申請單，其實是拆了很多單到各系統裡面去，民眾也可以在這個畫面上找到各系統的單號是哪一些。

途中上半部就是像剛剛有提到送警政署、太魯閣及天池山莊，下面就會看到相應有四個頁籤一站式填的資料，以及額外分別對應到太魯閣、警政署入山的申請資料。

如果要調成這樣後，一站式查詢畫面建議也一起調動，（如簡報之示意圖）同時也要讓民眾很清楚知道在一站式是填了一張單，然後一站式協助拆成哪一些單送到哪一個單位去，這個是我畫的 Prototyping 示意圖。

既然有像剛剛那樣拆單的動作，針對申請單資料結構，我這邊會建議的是，一站式的申請單要有類似這樣的觀念，一站式的申請單可能會有各個單位的申請單，假設民眾申請，比如大縱走之類的，甚至可能會有橫跨同一國家公園兩條路線，這個申請單就會有兩張國家公園申請單的狀況，所以會建議申請單的處理方式要調成這樣。

如果要做到像一步步剛剛那樣將節點挑出來看的方式，將管理單位從樣板單位的路線註記到節點，這樣就可以比較程式化的方式，從民眾提出來的路線，來計算哪一些點要轉送哪一些單位來做申請。

接著比較複雜的是所謂南峰岔路口營地，因為國家公園系統上有看到奇萊南峰的登山口，這個變成登山口宿營地，如果使用者是用這樣的單來做申請的時候，系統最好可以做到的是可以幫他辨識，進行拆單的動作，也就是這邊先拆成先上宿營地，然後再上登山口，也就是把國家公園的部分擷出來然後再做申請的動作，接著是送天池山莊。

像圖的上半部，也就是我在國家公園看到的路線，像林務局提供給路線我看到的是卡東營地，而國家公園系統上則是卡東木屋，就像剛剛皓婷提的，我們對於路線名稱要做一致性的統合。

第一個建議的是，可能一站式之後，幫路線的資料庫設計方式來做一些調整。現行的做法是，會有一些樣板路線，樣板路線會註記這個路線會涉及什麼管轄單位，如果民眾選擇什麼樣板路線，就用樣板路線所記的管轄單位做送出的動作。簡報上的節點就是剛剛講到的途徑點的概念。我舉一個比較實際的案例，也是林務局提供給我的路線，這個路線是奇萊群峰經屯原登山口，在這個路線底下我們可能會要申請警政署的入山，第二個部分還要再就屬於太魯閣國家公園部分來做拆單，我在簡報上綠色底的部分就屬於太魯閣的國家範圍。

這一份簡報的初衷是增加大家之後的靈活度跟便利性，增加一站式服務可靠性，避免單點失效。前兩週警政署的API突突然失靈，所以會讓所有的路線沒有辦法申請，會基於這兩個方向來做簡報。

我這邊就系統和技術面來報今天的建議。

最後，我幫大家整理一下這一案的時間軸，從6月開始推動，中間經過兩次技術協調會與協作會議後，9月開發工作啟動系統開發，歷經兩個月之後會再本週五系統即將上線公開 Beta 測試。然而上線後，並不是就此結束。如前面所提，系統會持續滾動修正與改進。以上分享。

11月1日系統上線後，我們仍然會保留著測試站，進行像是圖上的循環，山友回饋意見就反映給廠商，部署於測試站進行測試，測試沒問題後 更新到一站式網站中，這也是數位服務準則 9 持續測試與快速部署的範例。

除了前面一開始對於既有系統的易用性測試外，於 10月1日 與 10月16日開發期間，我們邀請協作會議的參與者，針對廠商所開發的系統也進行的易用性測試，將所收集到的意見回饋給廠商進行修改。

最後，數位服務準則4也有提到要持續精進作業程序採用迭代與漸進式方法進行軟體開發改善服務。

最後，在基於易用性原則下，以使用者為出發重新設計的一站式服務網。

這裡採用OAS 3技術標準來作為一站式網站跟系統介接的方法，部會可以單獨發包與自己系統界接的 API，進而降低專案發包金額，此部分也是達成跨機關整合很重要的關鍵，因為共通的標準之後，我們可以讓大家有一致的標準來介接資料，這也是數位服務準則「跨域合作」很重要的部分，採用同一的標準跟加上分別發包，讓開發平行的進行，加快專案開發速度，統一標準也能夠為將來實踐「數位服務準則8」，建立 OpenAPI 打下基礎。

我們分別於8月28日和9月6日與部會、廠商進行了兩次技術協調會議，最後提出這樣的系統架構來作處理，可以看到，我們並不將現有系統砍掉重做的狀況，即便民眾不適應新的系統，也能夠回到現有系統進行操作這也是數位服務準則 3「規劃多元服務管道」的精神。同時，因為是單純界接現有系統，對現有的申請制度影響降到最低，對第一線公務員而言，不需重新學習新的系統操作方式，就可以進行原本的公務。

協助跨部會資訊統協作相較於故宮案，本案橫跨了內政部營建署、警政署、農委會、林務局，需要處理不同部會間的資訊系統界接，加上本案有時程壓力、部會預算的限制，同時必須保有現行系統的狀況下，所以其實挑戰滿大的。

使用起來情境可能會像是這樣，山友們向單一窗口詢問，然後單一窗口向後詢問，回收各部會的回應，再答覆給民眾。

同學們針對現行系統進行易用性測試與訪談，透過會設計關鍵任務，請使用者們完成任務，於過程中記錄使用者們的反應，比如在畫面上卡住或者是有一些疑問的時候我們會把它記錄下來，在測試結束之後，我們會找出系統可能的改進方向，從上述兩種手段收集的民眾意見並進行歸納後，猜想使用者希望是類似這樣的流程，有一個單一窗口遞交申請表，再由單一窗口進行轉發看到哪裡去。

從左邊開始納入數位服務準則納進來，還有關鍵字搜尋、欄位簡化、一站式填寫由系統判斷申請單位。此外，本次RAY的見習生也一起加入這次專案，協助進行使用者訪談與使用者介面設計，稍微介紹一下RAY，RAY是由教育部青年署的大專生公部門見習計畫而來，PDIS與青年署合作讓大專生到行政院實習協助體檢政府網站，自 2017 年起已是第三年，今年著重於數位服務改造，這也是為什麼 RAY 的見習生也參與本次專案。

協作會議後我們整理出一張超大的心智圖，不論是系統設計面、制度、甚至山難救助等相關意見都被納入了。而本案重點將著重於資訊系統的改善，我們挑出了幾項山友們普遍覺得重要的項目納入這次的系統改造目標。

6月30日的時候，整合資訊網上線了，解決的第一個問題，但似乎還不夠好，於是我們在9月6日時我們舉辦了一場協作會議，邀請山友以及相關部會參與討論。除了收集山友們的意見外，部會的同仁也能夠及時回饋資訊給予山友。

這一案我們做了那些嘗試與突破？跟故宮案一樣，我們以使用者為本出發，對使用者而言，現行的登山申請必須自行到各部會系統提出申請，對於不熟山林管轄權責的民眾而言，可能會有疑問，例如我該向那些單位申請？怎麼好像規則都不太一樣？為什麼要填寫好多次資料？實際系統看起來像這樣，四個部分系統要上去田資料。

8月PO月會，由內政部的PO俊凱透過自提案提出，因而有了登山系統改造案 來到 PDIS 辦公室來。

大家好我是秉倫，先講一下這案緣起，6月30日行政院於六月份 啟動「開放山林政策」，6月30日臺灣登山申請整合資訊網上線後，有許多民眾對於登山申請的資訊系統提供許多改善意見。

可以。

開始到結束有很多不同路徑，把所有路徑都列下來。

我需要知道的圖就是每個申請表資料狀態怎麼調，有時候可能抽籤要知道等待抽籤，每個表之間的狀態怎麼跳動會比較容易理解，而且是非行政流程，我有看到有些部會有放行政流程，但我需要的是機器可以判讀是什麼狀態的狀態表。

業務單位需要幫我整理，我會需要各個申請表的狀態圖的狀況，假設申請山屋有三個步驟，申請表、抽籤、繳費，我會需要狀態圖是送表單之後等抽籤狀態，中籤等待付款，付款完成功有資格，中間有些不是我們預期，例如沒有繳錢、取消，這個狀態圖要麻煩業務單位給我。

現在是一個列表，但我意思是像國家公園填南二段，那我要確認對照的事情，這東西是還沒有對不對？

我們在國家公園系統只會填向陽，只會填一條線一個欄位，但警政署要填四個點，是可以轉換的嗎？

有收到Schema，有跟老師通過訊息，目前沒有開API，我可能要請各部會幫忙做一件事，可能需要各系統申請表狀態。

申請表，因為我要知道怎麼串，Primary Key，申請表相關Schema就好。這部分就這樣，再來是自然保護區，我有收到回信會給東西，但沒有收到。

有兩個廠商的資料，有問能否提供API跟Schema，昨天有打電話要，但還沒給我，要麻煩林務局幫忙催一下廠商。我只是要確定Schema能不能今天給出來，之前電話是說可以馬上給但還沒收到。