補充: 昨天和晴柔一起到佛光山幫忙，和現場社工聊了一下，他說他們後續會需要資訊志工的時間點，可能會是在組合屋興建好後，分配災民入住時需要大量名單統籌彙整，至於安置中心的社工離開日工作目前沒有時間表，不過災民異動減少後資訊志工的需求相對降低，未來社工也可能撤回高雄縣社會處，故之後的資訊志工若要協助或發現問題，可能也要轉往社會處。
by梓榕

補充2: 昨天凱元和社工也提到昨天發錢時最大問題是溢領，cbase可以匯出、並依所需條件造冊，但這部分社工應該還不知道，所以他們還是自己另外造冊，才導致溢領問題，也就是目前佛光山這邊的社工主要是使用 cbase查詢或建檔功能，其他功能或這個資料庫可以作的事，甚至這個資料庫的缺點，都不是現階段他們重視的問題。
by 梓榕

我們這邊都已經跟社工說明要查調CBASE內有相關災民資料才能發放慰問金
但是後續還要登打及補上災民身份證字號
也請大家協助提醒一定要補上身份證字號囉！謝謝

就我的觀察看來，其實會有補助金溢領的問題，是因為資料的key in與查核不夠即時，而且允許代領。
有些民眾一次幫許多家人或朋友領取、簽領據，但是未及通知這些人；另外則是由於cbase資料是發放補助金之後才key in資料庫，時間上會有落差。
如果民眾不曉得自己的補助金被領走而前來領取、而資料未及key in進來，那就會造成社工以為這些民眾的確未領到金額。

同時的確也有些民眾會利用這個資訊的時間落差，到不同的收容中心領取補助金。

如果發現的早，那還有追回金額的可能，發現的晚就比較麻煩；現在有些人是找都找不到。

理想的情況是，最好在發放補助金額之後，立刻將資料key in資料庫裡面，就可以減少這樣的問題發生。
不過前提是電腦的數量要夠多而且可以同時上網連線cbase，因為一旦講到要發錢，就會引來龐大的人潮。

這時候要問一個問題：CBASE 的資料是否適合、足夠用來記錄發慰問金，與解決溢領問題？

Tky 在工作日誌處用紅字標示出來的，也就是我問的問題：CBASE 資料庫是否堪用？Tky 與 Jimmy 或其他人可否提供一些你們的意見，讓紹成有多一些資訊參考？

我跟TKY討論的結果，針對補助金的溢領，大部分不是CBASE的問題。
原因是如此，理想的作業程序是，社工在發放慰問金，簽領收據時就直接在CBASE紀錄資料，而不是簽領收據後，再行用文字文件回來紀錄資料。
然而現實沒有這麼美好，其一，發放慰問金的場面之混亂，是前所未有；其二，社工即時更新的話，簽領的程序會拖很長。其三，社工在發放慰問金時並沒有比較organize的方法。

所以可改善的空間是：
最重要：發放慰問金的SOP程序，把時間拉長，電腦擺好，20個20個叫來。
次重要：CBASE可改善的空間是，查詢單一名字的時間縮短，可能機器的效能得提昇。（今天操作有點慢）
改善：佛光山館內硬體也得穩定，網路線和電腦得齊全。

我覆議jimmy的看法。

使用Cbase的經驗加上這幾天看到社工們遭遇到的問題，其實可以結論說，困難在於怎麼樣在一開始的時候就蒐集到最正確的資訊，並且能夠準確追查民眾後續的流向。由於cbase的資料欄位有限，雖能夠找到一個欄位填寫後續的異動資料（幾時進駐、何時離開），但天數一多或者異動頻繁，資料就會擠在一個小小的欄位中。而且只會顯示最後一個居住地點，之前到過的地方除非有紀錄，要不然就不清楚。

再者是目前社工們使用cbase，是以安置地點作為登錄的依據，也是以此作為發放補助金的基本資料。
然而問題是說，居住地點的流動問題嚴重，實際上居住的人口和資料庫的數量會有一兩成的差距。另一方面，只要一有風聲說哪裡會發放補助金，就容易有非居民回流要求領錢。這使得社工們為確保公平以及不確定民眾是否誠實，就很難開放全面補登記的作業。其結果就是有些早已居住在各據點的居民，因為錯過最早的登記作業或登記錯誤，反而無法領到補助金。
這是系統本身所無法改善的問題，而是收容流程設計上一開始就得注意地方。

（這回應功能好像有字數限制，我繼續回覆下去）

我認為後續如果有機會重新開始的話，應該要以「人員」作為登記的核心，並且有相關的欄位能夠紀錄他到過哪些地方、之後要去哪裡，在哪裡領過錢。
這樣就不會因為擔心因為以「居住地」為主的補助金發放問題而造成溢領的現象。
（今天聽說旗山的據點就因為傳聞「無居住地的災民能夠領到錢」而湧進大量的民眾與詢問電話，使得社工處被迫改變補助金發放的標準，造成社工與民眾雙方的抱怨。）

只要有登記就可以確保他們的權益不會因為更換居住地點而受損、不會影響他們的行動自由，民眾就會比較有意願主動填寫正確資料。
如果不會依據居住地來發放補助金，而且有辦法能夠透過即時的資訊來避免同一個人在不同地方多次領取，那麼就能夠避免掉民眾到處換地方住、只為了能夠在某個地方能夠領到補助金的問題。各個居住地點的社工才能夠放心普查當地居住民眾資料，免掉「投鼠忌器」的困難，確保資訊的正確與完整。

另一部份，補充說明一下，整個裡頭的難題不是系統爛還是不恰當，通常徵節點在於
1. 沒有時間想SOP
2. 不會合併列印（誰會舉手！）
3. 沒有電腦
4. 沒有網路線
5. 沒有網路！！！

至於系統，簡單好用瞬間明白，對這些人而言是最重要的。所以那會是Sahana開發的目標，亦或是難題。