前陣子台北的政治大學有個團隊,辦了一個到現在還讓我搞不清楚狀況的比賽,針對台北市的施政建設進行的創意選拔競賽[1]。總之,投稿一直是最容易的,便邊寫邊想的寄了一份施政建言企劃給該團隊參加比賽。後來收到一封信,原來是該團隊要求補充詳細的實施內容。我一向覺得可行性與創意才是最重要,舉辦活動的學術單位卻寧把資源耗費在假設的企畫書中,覺得怪麻煩,便沒再理會。

先說結論,當時提交的是一份關於市民與政府之間的合作管道改良方案

由於當前政府的耳朵,與人民的嘴巴,除了早期建立的電子信箱或紙本郵件的申訴與提問方式外,大概就只剩下所謂的找立委、找議員等救濟模式。近幾年來由台北市率先推的便民服務電話:1999,則進一步強化了政府與人民之間的合作關係。

但是前面提到的三種方案都有幾個共通缺點,包括不公開、無監督以及無驗證等。

試想,當一處馬路有破洞,同時有 10 個人寄信或撥打 1999 進行通知,就需要有 10 人次的人力接收郵件或接聽電話,並分案排入處理流程,接著再合併成一件事情,交由施工單位排入時程進行維護施工。然後這 10 個人開始痴痴等待施工單位進行處理、回報,甚至可能永遠不會知道是否曾經維修過,只能等下次經過相同路段時才回想起來(甚至又在同一個位置摔車)。如果報案人是採用寄信方式,那施工或管理單位還需要用公文回覆。

瞧,這是一件多麼沒有效率的行政流程。

於是我便想到現有的技術大可加以實用化,也就是利用智慧型手機的 APPs 應用程式技術,來加以改善這套協作流程。投稿當下隨便想了個名稱:全民報馬仔

顧名思義,這套 APPs 的目的,就是讓民眾可在智慧型手機上,針對「特定地點」及或「特定事件」,進行資訊登錄。之後,政府就需要針對民眾登錄的內容進行處理與回報。同時,從資訊登錄到結果回報這中間的所有流程,都是公開而透明,讓全體民眾都可查詢。

舉例來看,假設台北市的太原路 97 巷發生了路面塌陷意外,這時候民眾就可迅速用手機連上全民報馬仔 APPs,針對地點「太原路97巷」以及事件「路面塌陷」進行登錄後,政府端的系統可依照事件的危機權值(假設從 0 至 10,路面塌陷為7)自動發案,要求市府工務組第一優先安排養護車輛外,並自動通知鄰近警局率先派員到場進行管制[2]。

最棒的是,如果同時有二十個人通過太原路97巷,甚至是坍陷地點的房屋的五樓民眾,通通透過全民報馬仔 APPs 進行危險提報通知,系統便會將地點與事件進行分析運算後,得到一個事件在一個地點上發生的結論,大大降低誤通報與浪費行政資源。

另外,公開與歷史資料查閱也是必須提供的,讓民眾可以監督行政效率與維護結果的資訊。就像我前面提到的,如果有 20 路人加 1 羊同時通報,難道要發 20 次回文、回電嗎?所以不如讓報馬仔本人自己去確認自己的提交內容是否已獲得解決,甚至是解決的期限值。同時加以導入評分系統,民眾在誘惑下更有意願隨時檢視自己的周遭是否有需要協助政府改善的地方,之後,這樣的處理方式,只會帶來一個後果,也就是政府方被動的必須提升效率及務實度。

目前這套全民報馬仔 APPs 最大的弊端就是被民眾「濫用」,造成整套系統在意義上的崩潰。不過這點也很容易解決,只要透過身分認證與信用加值這兩套模組應用,就可以加以解決。重點是讓回報者尊重自己所提報的內容,即便民眾仍然亂報,系統的崩潰臨界點也可以迅速回歸常數,並透過時間驗證加以剔除負面因子,等同相對提高系統永久性的穩定度。

延伸閱讀:

[1] 搞不清楚的原因是比賽內容東牽西扯,不斷擴張到其他延伸項目,讓背後牽涉的內容變得相當複雜。

[2] 政府方系統可視危機權值的大小,自動判斷是否需要通知警方率先到場進行管制(假設權值 3 以上都需要),當然,處理時效也可依危機權值進行定義,雖然並非所有事件都需要及時處理,但會相對會針對事件危險狀況產生的最長處理時限,讓工務單位可自行決定人力的運用。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

推薦好書