2016年2月15日 星期一

【轉貼】0206地震之後-資訊技術對於「救災組織的協調」、「物資需求協調」、「志工協調」可提供之協助


筆記:本文由究心科技執行長 莊國煜,就「救災組織的協調」,「物資需求協調」, 以及「志工協調」這三個面向來談談資訊技術 對於救災的現況與未來展望。

原文連結:http://geothings.tw/post/139329922145/after0206earthquake

作者:究心科技執行長 莊國煜

0206地震之後

經過這次地震, 我們感受到災害的無情, 也看到台灣的美好. 而防災救災可以研究與討論的議題真的相當廣, 甚至可以說是錯綜複雜. 或許我們就先從「救災組織的協調」,「物資需求協調」, 以及「志工協調」這三個面向來談談資訊技術 對於救災的現況與未來展望.
  • 救災組織協調
張教授在「國際救援,是否接受?」提到 “跨國團隊的溝通協調” 這個議題, 正是究心一直以來希望可以應用資通訊工具來協助的一個重要環節. 跨縣市的消防救難單位或許講著共同的語言 (或者說 protocol), 但加上民間救難單位, 甚至國際救難組織的參與. 如何把各個組織的人力能量 (包括技能與裝備) 以及任務負載狀況彙整給指揮單位了解, 也同時能讓指揮官的命令, 指派, 以及交辦任務完成狀態可以一目了然 (身於第一線的陳先生在 1050206支援台南地震維冠大樓倒塌搶救 說明了指揮系統的重要). 簡單來說, Who-is-doing-What-Where-When 這 4W 就是第一步最基本該彙整呈現的 (可以參考 UN OCHA 的 Nepal - 4W Resources) . 但這多少都牽涉到每個組織的習慣作法, 也考驗著資訊工具是否順手好用, 以及透過資訊平台所呈現的方式. 因此免不了要一個資訊團隊持續投入人力資源, 與救災組織夥伴們一起合作改進資訊工具.
而救災行動環環相扣, 筆者既然身為資訊宅, 關心且在意的部分也比較偏向防救災的 Information Management 環節. 這環節理論上較難單獨使用 Line 群組或是臉書社團來完成. 也因此, 或許可以跟著 UN OCHA 學習跨國際組織協調所遇到的難處, 或是參與 OSM Humanitarian Team (HOT) 來看基礎圖資應用於防災的能量建立, 也可以透過國際/區域銀行 (如 世界銀行 以及 亞洲開發銀行) 的力量了解各地政府如何建立防救災溝通管道. 這些看似零散的環節, 都會是發生重大災害時, 如何適時適當的運用資訊工具, 讓當地政府單位快速接入民間/國際救災組織的切入點. 
回到台灣, 建立救災即時訊息發布的資訊接口 與 協作翻譯機制, 就可以是納入本地/跨國救援能量的第一步. 而國內救災組織的協調起點, 或許就可以先從即時彙整各個組織 (包括民間組織) 的 4W 資訊做起. 因為做好這看似簡單的一步, 就可以讓台灣做得比世界上絕大部分的國家都要好了.
  • 物資需求協調
從批踢踢EarthQuake26板的「民間物資募集流向報告」來看, 政府的行動與民間的想法有著不小的落差. 既然地方政府對於救災責無旁貸, 那怎樣提供更好的工具來協助政府把這些事情做得更符合大家的期待呢? 在物資協調方面要做的事情很多, 我們先從 政府如何統計需求 以及 需求如何快速媒合 這兩點來看.
一般來說, 政府統計需求的方式大多會是透過在地的鄉里社區聯繫架構來往上反應. 國外如此, 台灣也如此. 而在發生災害的當下, 除了運用在地原本備災應急的物資, 若有不足, 則會反映給地方政府 (在台灣是由各地社會局協調). 因此建立可以迅速反應需求與狀況的資訊平台, 是很多國家都在進行, 也都會宣稱已經有建置的基礎建設.
目前台灣有消防署的 防救災雲端計畫 以及衛福部的 重大災害民生物資與志工人力整合網絡平台 的資訊系統, 希望把資訊從地方基層即時串接到中央, 從宏觀整合的角度去反應並調動, 以因應災情. 但在救災壓力與時間緊迫的情形下, “有工具”跟”有好用的工具”就會有很大的差別. 畢竟政府是救災行動的主導者, 若希望加強這些已存在的平台使用率, 不一定只能用威脅利誘 (法令規範或是經費補助) 的方法, 畢竟多如牛毛的查核項目會累死基層, 緊急的時候也不一定真的能派上用場. 轉個方向思考如何從「行動應用」的使用者經驗來讓上述的平台更加即時好用, 並且讓這個平台可以像我們常見的網路服務那樣持續根據使用者回饋而改善. 讓地方政府與社區基層做更有效率的回報並完成任務, 中央所需的綜觀資訊也就自然匯聚而成.
當然, 要用「服務營運」的執行方式, 在政府標案的架構限制下確實有所困難. 但換個方式想, 其實政府單位可以試著與救災資訊專業團隊合作, 結合有心的民間組織以及社群力量, 相信能事半功倍, 更見成效. 
至於「需求快速媒合」這點, 可以從 組織對組織 的需求媒合先談起. 因為從協調者來看, 打一通電話可以搞定 5000 件毛毯的需求缺口, 在時間與人力的成本就會比設立表單讓大家捐毛毯的方式來的快, 對於衍生運送成本與管理人力也較低. 因此需要大量物資的當下, 怎樣讓政府快速得把需求資訊傳遞給有能力快速滿足需求的協調窗口, 就是重點. 
在台灣由賑災基金會所協調成立的災害防救聯繫會報平台, 就是希望可以有效協調民間力量, 來協助政府救災. 目前已經有 50 個與防救災相關的 NGO 夥伴, 透過究心所開發的資訊平台來即時獲得政府最新的需求資訊, 並且回應可支援數目. 但政府的需求資訊如何主動即時並有系統的接入這個資訊平台, 而不是透過民間組織的詢問來觸發物資協調行動. 這除了靠資訊團隊持續與中央與地方專責窗口溝通並建立機制, 並且導入平常的防災演練教材, 才能真正在災時發揮效果.
當然除了像是簽訂開口契約這類組織/企業層級的協調, 還有物流, 盤點, 分配, 發放 等等與物資協調相關的工作. 其實每個環節都會有專業的團隊願意貢獻, 而資訊團隊則是要在這一項一項的環節去參與並觀察, 才能真正了解協調工作會遇到的困擾, 以及構思資訊工具所能改善的程度. 因此持續讓這些專業的團隊平時能演練並回饋, 緊急的時候就能根據專業來即時反應並採取行動. 這樣, 或許能把這盤根錯節的問題慢慢釐清, 讓大家不會覺得政府反應慢, 而在政府部門的夥伴卻又是累到趴.
  • 志工協調
雖然去年八仙塵爆所需要的多為醫療專業志工, 我們觀察到一般志工較難在嚴謹的醫療體系幫上忙. 但早從八八風災開始, 發生災害事件時民眾透過網路揪團的義舉也不會少. 大家應用自己熟悉的資訊工具與平台來聯繫, 並進一步做有系統的工作分派與排班協調. 這次0206地震, 我們從「助台南志工團」的成立與執行成效來看, 有組織的民間志工與政府的救災系統整合並發揮了效果, 這也發揮了 以在地協助在地 的精神. 即時以及快速反應就是民間志工團體的寫照.
其實台灣不管是政府或是民間的志工平台不少, 不過政府與民間組織 (包括非營利組織) 的志工募集方式, 仍傾向以事先已登記之志工優先. 其最主要的因素還是信任與合作默契. 但是不應該每次發生緊急事件都這樣從頭來一次. 因此, 如何聯繫各個已經在營運的志工平台, 規格化資訊接口 (可參考 UN OCHA: Humanitarian ID 對志工資料的描述建議), 並且讓有願意協助且有能力協助的志工夥伴可以即時收到需求通知, 在對的時間與地點貢獻己力, 相信這就會更能增加我們面對緊急事件的能量.
而講到志工協調, 也要提這幾年在重大災害時出現的資訊志工. 目前零時政府 (G0V) 以及開放街圖 (OpenStreetMap) 都是活躍的資訊志工社群. 我們從 2016.02.06 台南大地震災情整合平台 來看, 就可以理解資訊志工的反應速度與協作能量有多快. 如何把我們提到三個面向所需要的資訊, 與資訊志工快速反應的能量做結合, 同時系統化且摘要化的呈現給救災團隊與指揮系統, 這可以是資訊彙整平台的下一個課題 (或說 ). 
另外在海地震災, 海燕颱風, 對抗伊波拉病毒, 到尼泊爾震災等國際救災行動, 人道開放街圖小組 (HOT) 應用衛星空照圖, 為原本沒有地圖的地區建立救災所需的圖資資訊, 也讓 紅十字會 (Red Cross) 以及 醫生無國界 (MSF) 等人道救援組織可以在當地順利進行協助. 甚至也有開始有政府單位以及區域銀行針對開放街圖的社群與開放協作特性, 來建立開發中地區的防災能量. 這在過去是難以想像的, 但也透過網路以及資訊科技, 讓遠在其他國家的資訊志工得以貢獻一己之力.
  • 小結
0206地震之後, 我們看到傷痛, 我們也看到希望. 在面對災害的同時, 我們也看到政府單位與民間組織可以互補的可能. 藉由這篇看似落落長, 但實際可能只有碰觸到防救災生態皮毛的想法, 我們試著說明資訊科技與工具可能的角色, 而這也是究心公益科技持續努力的方向與目標.

    2016年2月14日 星期日

    【轉貼】防災專責單位,政府投資嗎?




    原文連結:https://www.facebook.com/notes/jieh-jiuh-wang/%E9%98%B2%E7%81%BD%E5%B0%88%E8%B2%AC%E5%96%AE%E4%BD%8D%E6%94%BF%E5%BA%9C%E6%8A%95%E8%B3%87%E5%97%8E/980084228728904
    防災專責單位,政府投資嗎?
    不要把設立新單位當成萬靈丹。
    但是,如果真的要討論防災專責機構,重點是內涵。單位角色要考量社經環境、體系脈絡和政策支援的力道,政府真的願意投資嗎?
    災害管理是人的管理、資源管理。大家老是喜歡舉美國聯邦緊急管理總署(Federal Emergency Management Agency , FEMA)的例子,我先提醒,美國每個州都等同於一個國家,美國聯邦單位著重於協調和協助功能,和台灣的中央政府是不同的,不要漠視體系脈絡的差異,亂套美國聯邦體制到台灣,但是美國政府對於防災工作的投資,我們的決策者可以想想,你們願意做嗎?
    美國聯邦緊急管理總署成立於1979年4月,是一個直接向總統報告,專門負責災害管理的獨立機構,融合了許多原本分散於各單位與災害相關的職責,合併了聯邦保險辦公室、國家消防辦公室、國家氣象局、聯邦救災組織等機構,並且民防工作也從國防部的民防署轉到了FEMA,很明顯的,這個單位納入的功能多,相對的權力也非常大。FEMA的基本編制有2500人,而且有5000個災害預備役人員隨時待命,2012年的全職人員已擴充至10,056人,組織預算超過135億美金,緊急事件發生時可以即刻動員超過32萬人,半秘密預算甚至高達上百億美元,美國總統不敢輕易任命此一職位的首長。說白了,這個單位首長必然是總統信得過的人。2002年11月25日,共和黨布希總統簽署了2002國家安全法案,授權聯邦政府改組行政機構,建立國土安全部(DHS),使人員增加至170000個,為僅次於國防部之第二大部,部長下設副部長,另有包括管理、科技、情報、整備等四個次長。其組織包含7個下轄機關與9個幕僚機關,基本預算就有355億美元。雖然讓FEMA由一級單位成為二級單位,但在時代更迭中依然維持其重要性,在不改變體制的前提下,依然維持直接向總統報告的權力,甚至民主黨總統更重視此一角色納入更多功能。
    專責單位不代表其他單位就沒有防災業務,全災害取徑並非沒有個別災害考量,這個單位要能回應3C (communication, cooperation, coordination)和 3 inters (interagency, interdiscipline interoperability)。FEMA不僅擔負災害管理的工作,甚至某些首長還將其作為風險管理和危機管理的幕僚單位。重點是,這個單位要具備足夠跨部會整合及有效運用資源的權力,位階就要夠高,領導能力更是關鍵。 FEMA在最初幾年面臨了包括運河污染、古巴難民危機以及1989年的Loma Pieta地震、1992年的安德魯颶風等挑戰。1993年,柯林頓提名James L.Witt擔任FEMA署長。Witt是第一個具有州政府緊急管理人員資歷的署長。他大幅簡化災害救濟和復原行動需求,主張將災害管理重點轉移為整備和減災,並將災害管理工作轉為顧客服務導向。冷戰結束也使Witt將資源投入災害救濟、具備減災思維的復建和更大規模減災計畫上。Witt的計畫通過了1993中西部大洪水和1994年1月加州北嶺地震的檢驗,使FEMA的轉變被認為是柯林頓政府政府改革的重要成就。
    沒錢沒人沒尊嚴,首長不懂,其他單位也漠視,平時減災整備不足,災時才忙著應變。災害政治學說,事故現場經常是政治人物危機處理的秀場,也是以勞力換取同情的告解室。消防不等於災防,防災科技不等於災害管理。把消防署改成消防及災害防救署,地方只是消防局人員兼辦災防辦業務,號稱有專責單位,有用嗎?根本問題不解決,無解。減災是無形的獲得!真的為人民生存著想的政府,會願意投資對於安全的保護。沒人沒權沒預算的政治遊戲,別玩吧!

    2016年2月3日 星期三

    【技術】水利防災作­業參考手冊(網站版),大推!!

    最近在整理國內外堰塞湖調查相關作業手冊時,意外發現水利署製作的「災害管理作業電子手冊」,呈現方式及架構上,有不少值得學習之處,特別筆記一下,也推薦給大家。

    連結https://derekya.gitbooks.io/disastermanagementmanual/


    版本
    首頁提供網頁版、平版、手機及kindle的電子書版本下載。



    內容
    本手冊的內容分成「水災篇」、「旱災篇」、「堰塞湖篇」、「震災篇」、「海嘯篇」,全書最後並附上各章節所提及之法令、附件等資料的索引。




    呈現方式
    網頁版採用 GitBook 線上電子書的方式架構。2014年柯P選市長時,就是用這個 GitBook 發表了「政策白皮書」,讓GitBook在台灣的知名度也爆增。整體而言,這個電子書的版面是蠻清爽的。



    心得與建議
    整體而言,我個人非常欣賞這個作法,公務機關應將相關的SOP及作業手冊公開。事實上,水土保持局在土石流防災這部份,早在94年時就已經是全文公開了,只是介面設計上只提供單純的pdf下載,且不太友善,預計今年會有全新的介面改善這個問題。

    水利署部份的手冊似乎並未完整地呈現在網頁版上,例如,「堰塞湖緊急應變作業手冊」(完整版pdf在此),裡面一些重要的流程圖及表單並未在網頁中呈現,或許是考量版面的問題有所取捨,其實有些可惜。