ไอทีกับการจัดการภัยพิบัติ
ดูเผินๆ ไอทีมีลักษณะเสมือนจริงในแง่ที่ไม่ได้เกิดการกระทำในตัวเอง
ไอทีเป็นเพียงเครื่องมือเท่านั้น จะดีหรือไม่ ขึ้นอยู่กับผู้ใช้เข้าใจเครื่องมือหรือไม่ และนำไปใช้ประโยชน์ได้แค่ไหน ยกตัวอย่างเช่นเอาฆ้อนไปตอกตะปู ก็จะใช้งานได้ดีมีประโยชน์ แต่ถ้าเอาฆ้อนไปพรวนดิน ถึงจะทำได้ก็จะดูแปลกๆ ไปสักหน่อยนะครับ
ภัยพิบัติทุกครั้งแตกต่างกันเสมอ ทั้งสาเหตุ ผู้ประสบภัย ระยะเวลา พื้นที่ประสบภัย ความเสียหาย ความหนักหนา ทรัพยากร อาสาสมัคร ฯลฯ ยิ่งกว่านั้น การจัดการบรรเทาทุกข์และฟื้นฟูจากภัยพิบัติ ก็เป็นภัยพิบัติในตัวเองเสมอๆ เนื่องจากมีคนและหน่วยงานที่เกี่ยวข้องอยู่เป็นจำนวนมาก ทั้งที่มีหน้าที่โดยตรง ทั้งที่มาด้วยจิตอาสา ในเมื่อต่างคน ต่างฝ่าย ต่างมีความรู้ความชำนาญที่แตกต่างกัน เรื่องเดียวกัน ก็จะมีมุมมองและวิธีการที่แตกต่างกัน ในเวลาที่ชาวบ้านทุกข์ยาก ช่วยเหลือตัวเองไม่ได้ ไม่ใช่เวลาที่จะมากล่าวโทษหรือพิพากษาใครหรอกนะครับ เราต้องไม่ลืมว่ากำลังมีคนที่เดือดร้อนแสนสาหัสอยู่
ดังนั้นการประสานงานก็จะโกลาหลอยู่เป็นธรรมชาติ อาจจะต้องอาศัย connection ส่วนตัวกันมากหน่อย หรือไม่ก็ต้องอาศัยการระดมสรรพกำลังมาช่วยงานกัน ซึ่งจำนำไปสู่ความขลุกขลักต่างๆ อีกมากมาย — เรื่องนี้ไม่มีใครบ่นหรอกครับ เพราะว่าคนที่มาช่วยกัน ต่างก็ทนเห็นชาวบ้านเดือดร้อนโดยไม่ลงมือทำอะไรสักอย่างไม่ได้กันทั้งนั้น
แต่ว่ามันจะดีกว่าหรือไม่ หากมีเครื่องมือที่ช่วยทำให้การประสานงานส่งความช่วยเหลือลงพื้นที่ เป็นไปอย่างที่มีระบบมากขึ้น บันทึกนี้พยายามจะเขียนแนวคิดของการจัดการในเชิงระบบ ที่เชื่อว่าน่าจะจำเป็นสำหรับระยะฉุกเฉินนี้ครับ ขอมองอย่าง “คนนอก” ไม่อย่างนั้นเวลาลงไปคลุกแล้ว ผมจะเมาหมัดคือจะใช้ทุกอย่างเท่าที่มี แล้วมองข้ามสิ่งที่ควรมีแต่ไม่มีไปครับ
การรับแจ้งเหตุ
คนเดือดร้อนยังไงก็ต้องรับเรื่องไว้ก่อนครับ มีปัญหาว่าเขาจะโทรมาถูกเบอร์หรือไม่ ในขณะที่เดือดร้อน หาโทรศัพท์โทรได้หรือไม่ เบอร์โทรศัพท์ของศูนย์รับเรื่อง จำเป็นต้องประชาสัมพันธ์ให้รู้กันโดยทั่วไป — 1111 เป็นกระบวนการที่ดี รับเรื่องแล้ว มีติดต่อกลับไปติดตามเรื่อง แม้บางทีก็โดนบ่นใส่ว่าไม่เห็นมีใครมาช่วยเลย
เจ้าหน้าที่ 1111 หรือเจ้าหน้าที่ Call center จึงเป็นงานที่น่าเห็นใจนะครับ ลองนึกย้อนไปตอนที่โทรไปใส่อารมณ์กับ Call center เวลา “บรอดแบนด์” กลายเป็น “บอดแบน” ซิครับ เจ้าหน้าที่ผู้รับสายไม่ได้ทำให้มันเจ๊งหรอก แล้วเขาเองก็แก้ไขไม่ได้ด้วย ต้องส่งต่อเรื่องให้คนอื่นทำนะ
การแจ้งเหตุนั้น มองมุมหนึ่งเป็นงานแบบ reactive รอให้ผู้เดือดร้อนแจ้งเข้ามาเองหรือฝากเพื่อนแจ้งเข้ามา ถึงแม้ว่าลักษณะ reactive จะขัดกับทฤษฎีการจัดการซึ่งเชียร์ pro-active ยังไงก็ยังน่าจะมีครับ ช่างทฤษฎีเถอะ มีคนเดือดร้อนขอความช่วยเหลือมา ก็ต้องพยายามช่วยนะครับ
เรื่องการรับแจ้งเหตุนี้ สำคัญตรงความแม่นยำและคุณภาพของข้อมูล จะต้องรู้ว่าจะให้ทีมช่วยเหลือเข้าไปช่วยที่ใด (เดินทางอย่างไร หาผู้แจ้งพบได้อย่างไร ติดต่ออย่างไร ฯลฯ) ต้องการอะไร (จะต้องเตรียมอะไร ฯลฯ)
Logistics ของการบริจาค
การบริจาคคือการที่ผู้บริจาคให้ในสิ่งที่เห็นว่าสมควร
น้ำใจของคนไทยนี่ล่ะขึ้นชื่อเลย เราระดมบริจาคมาตั้งแต่คราวมหาวาตภัยแหลมตะลุมพุก ปี 2505 แล้วครับ ผ่านมาเกือบห้าสิบปีแล้ว สิ่งที่ควรมีก็ยังไม่มีเหมือนเดิม นี่ไม่ได้บ่นหรอกนะครับ เพียงแต่ชี้ตามที่เห็น ว่าที่ควรมีนั้นคือ
- บัญชีรับจากจุดรับบริจาคต่างๆ
- package manager คือกลุ่มคนที่แยกแยะจัดแบ่งของบริจาคเพื่อส่งลงพื้นที่ครับ ตรงนี้ขาดไปจริงๆ เพราะน้ำใจที่บริจาคมานั้นเป็นสิ่งมีค่า ควรจะส่งลงไปในพื้นที่ให้ตรงตามวัตถุประสงค์ของผู้บริจาค ให้ได้ประโยชน์กันผู้ประสบภัยจริงๆ อย่าส่งมากไปหรือน้อยไปเพียงเพราะระยะทาง
- การขนส่ง คือจัดการเรื่องว่าของอะไร ไปทางไหน ไปยังไง ต้องส่งภายในเวลาเท่าไหร่ ไปถึงปลายทางแล้วเอาอะไรลงเท่าไหร่ (ที่เหลือไปต่อยังที่อื่น) ติดต่อกับใคร ของบริจาคไม่จำเป็นต้องมาจากสถานที่รับบริจาคที่เดียว ดังนั้นทุกศูนย์ควรจะมีระบบที่ประสานกันได้
- ศูนย์กระจายความช่วยเหลือในพื้นที่ การส่งของบริจาคลงตรงยังพื้นที่ ไม่เหมาะกับการที่พื้นที่ประสบภัยอยู่ห่างกับสถานที่รับบริจาคหรอกครับ เพราะว่าการส่งของโดยตรงเข้าพื้นที่นั้น
แต่ที่เราไม่มีคือระบบจับคู่ระหว่างความต้องการและของบริจาคครับ (Pleas and pledges matching system) การให้จะเกิดผลสูงสุดเมื่อให้ในสิ่งที่จำเป็นทันต่อเวลา อย่างกรณีบูรณาการ อปท.ในพื้นที่ที่ไม่ประสบภัย “ให้ยืม” เรือและเครื่องจักรทำเขื่อนดิน หรือการเตือนเรื่องอาหารฮาลาลสำหรับกรณีน้ำท่วมทางใต้ ก็เป็นตัวอย่างที่ดีครับ
ความรู้เชิงแผนที่
มีการใช้กันบ้างแต่ยังไม่มากครับ เวลานี้พึ่งการแจ้งความเดือดร้อนเข้ามาที่ศูนย์ฯ แล้วก็ประสานความช่วยเหลือต่างๆ ลงไปช่วย ทีนี้ถ้าเกิดปัญหาติดต่อไม่ได้หรือไม่รู้จะติดต่อใคร ก็ไม่รู้จะแจ้งความเดือดร้อนอย่างไร
ที่ควรมีคือแผนที่สถานการณ์ เช่นเอาภาพถ่ายจากดาวเทียม มาซ้อนกับแผนที่ ก็จะเห็นขอบเขตของอุทกภัย ด้วยข้อมูลทะเบียน เราก็จะประมาณได้ว่ามีชาวบ้านอยู่ในพื้นที่ประสบภัยเท่าไหร่ จัดเตรียมความช่วยเหลือให้พอเพียงได้ไม่ต้องรอให้ร้องขอ หากมีคนอยู่แถวนั้นมาก ก็อาจพิจารณาตั้งศูนย์กระจายความช่วยเหลือในพื้นที่ได้เช่นกัน จะได้วิ่งเข้าวิ่งออกได้ถี่ขึ้น ช่วยคนได้มากขึ้น
คราวนี้ผมเสียดายที่ไม่มีใครถ่ายภาพทางอากาศไว้ ในภาคกลาง ลักษณะน้ำท่วมเริ่มเป็นน้ำขังแล้ว สังเกตน้ำไม่ไหลแล้วเริ่มเน่าเสีย หมายความว่าน้ำไม่ระบายออกแม้ระดับน้ำในแม่น้ำต่ำกว่าตลิ่งแล้ว อันนี้น่าจะเกิดจากน้ำเอ่อล้นข้ามสิ่งป้องกัน(ถนน)เข้ามาท่วมเทือนสวนไร่นา เราตะดูแค่แผนที่ระดับความสูง (DEM) ไม่ได้ เพราะว่ามันไม่ได้แสดงสิ่งกีดขวางน้ำไหล — แก้ได้ทางเดียวครับคือสูบออก แต่ในเมื่อไม่มีแผนที่ระดับความสูง ถ้าสูบผิดตำแหน่ง น้ำก็จะวนกลับมา แปลว่าเหนื่อยเปล่า
จะดีกว่าหรือไม่ ที่อาสาสมัครที่ลงพื้นที่หรืออยู่ในพื้นที่อยู่แล้ว เปิดดูแผนที่แล้ว “จอง” พื้นที่ที่ทีมของตนจะเข้าไปได้เองจากพีซีหรือมือถือ ทีมอื่นพอเห็นว่ามีคนเข้าพื้นที่นี้แล้วในวันนี้ ก็จะได้กระจายกันไปยังพื้นที่อื่นๆ
ถอดความรู้จากข้อมูลของหน่วยงานอื่น
ขอยกตัวอย่างนะครับ กรมป้องกันและบรรเทาสาธารณภัย มีรายงานสาธารณภัยรายวัน (ตอนนี้ออกวันละสองครั้ง) ในรายงานนั้นระบุข้อมูลว่าจังหวัดใด อำเภอใด ตำบลใด หมู่ใด กำลังประสบภัยอยู่ สถานการณ์เป็นอย่างไร ได้รับความช่วยเหลืออย่างไรแล้วบ้าง
แค่ข้อมูลว่าตำบลใดกำลังเกิดภัย เอามาวาดวงกลมในแผนที่ตามพิกัดของตำบล/อำเภอ (ชื่อตำบลเป็นภาษาไทยค้นได้ใน Google Maps; ตำบลใช้รัศมี 2.5 กม แต่ถ้าไม่มีชื่อตำบล ใช้ชื่ออำเภอก็ได้โดยใช้รัศมี 10 กม.) แบบนี้เราก็จะได้วงกลมหลายวงบนแผนที่ ซ้อนกันหรือไม่ซ้อนก็ได้ แสดงให้เห็นภาพใหญ่ของสถานการณ์ว่ากำลังเกิดเหตุที่ไหนบ้าง พื้นที่กว้างใหญ่แค่ไหน จะส่งความช่วยเหลือเข้าไปทางไหนดี ควรแบ่งกำลังเป็นกี่สาย ตั้งศูนย์ฯ กี่ศูนย์ ฯลฯ
เอาแค่นี้ก่อนก็แล้วกันครับ เรื่องอื่นๆ เขียนอธิบายยาก ขอเวลาหน่อย
ยังกินพญามือเหล็กของป้าจุ๋มอยู่เลยครับ ธรรมดากินคืนเดียวก็ฟื้น รอบนี้กินมาสามวันแล้ว ยังแย่อยู่เลย
« « Prev : น้ำท่วม ข้อมูลก็ท่วมด้วย
Next : น้ำท่วมกลับไม่มีน้ำดื่ม (1) » »
ความคิดเห็นสำหรับ "ไอทีกับการจัดการภัยพิบัติ"