ผู้ช่วยศาสตราจารย์ ดร.อานนท์ ศักดิ์วรวิชญ์
อาจารย์ประจำสาขาวิชา Business Analytics and Intelligence
และ Actuarial Science and Risk Management
คณะสถิติประยุกต์ สถาบันบัณฑิตพัฒนบริหารศาสตร์
อาจารย์ประจำสาขาวิชา Business Analytics and Intelligence
และ Actuarial Science and Risk Management
คณะสถิติประยุกต์ สถาบันบัณฑิตพัฒนบริหารศาสตร์
โครงการพัฒนาระบบสารสนเทศภาครัฐแทบทุกระบบมักจบด้วยความล้มเหลว สาเหตุของความล้มเหลวนั้นมีหลายประการ
ประการแรก นักวิชาการคอมพิวเตอร์ภาครัฐ มีทักษะในการพัฒนาระบบที่ต่ำมาก และล้าหลัง คนเก่ง ๆ ถูกซื้อตัวไปภาคเอกชนกันจนหมด และที่มีอยู่ก็แทบจะไม่เคยพัฒนาระบบเอง เพราะใช้วิธีจ้าง vendor มาพัฒนาระบบให้จนกระทั่งทำอะไรเองแทบไม่เป็น การตรวจรับงานก็กลายเป็นการตรวจเอกสาร คำถูก คำผิด กั้นหน้า กั้นหลัง format มากกว่าเนื้อหาจริงว่าจะนำไปใช้ประโยชน์อะไรได้
หลายโครงการเมื่อพัฒนาเสร็จ vendor หลายเจ้าก็เบื่อหน่ายหน่วยงานนั้น ๆ ที่มีแต่การขอที่ไม่เป็นสาระ และทำงานไม่ได้ประโยชน์เท่าที่ควร ทำให้หลายเจ้าก็เลือกที่จะโบกมือลาแม้ว่าจะได้ค่าดูแลระบบ (Maintenance fee) ก็ยังไม่อยากได้ ไปทำงานให้ภาคเอกชนที่ทำงานแบบมืออาชีพ ทำงานด้วยแล้วสบายใจกว่ามาก
แม้กระทั่งเงื่อนไขในการจัดจ้าง (Term of reference) นักวิชาการคอมพิวเตอร์ในภาครัฐก็ไม่สามารถเขียนเองได้ ต้องให้ vendor เขียนให้ และการตรวจรับก็ต้องให้ vendor เขียนรายการตรวจสอบในการตรวจรับให้เช่นกัน
ในภาพรวมคือนักวิชาการคอมพิวเตอร์ภาครัฐที่อยู่ในระบบขณะนี้ หากไปทำงานภาคเอกชน จะไม่มีทางเอาตัวรอดหรือผ่านการทดลองงานได้เลย ทักษะทางด้านสารสนเทศและวิทยาการคอมพิวเตอร์นั้นโดยธรรมชาติก็ตกยุคอย่างรวดเร็ว แม้กระทั่ง software house หรือภาคเอกชนก็มีปัญหาเช่นเดียวกัน แต่ไม่หนักเท่าภาครัฐ เนื่องจากยังให้ออกได้ ในขณะที่ภาครัฐการให้ข้าราชการออกจากงาน หากความชั่วไม่มีความดีไม่ปรากฏนั้นทำไม่ได้
ประการที่สอง คือ การให้ความต้องการหรือการกำหนดความต้องการ (Get requirement) เป็นสิ่งที่มีปัญหาที่สุดในการพัฒนาระบบสารสนเทศภาครัฐ เนื่องจากมักจะเริ่มต้นอย่างเลื่อนลอย
คนกำหนดความต้องการมักเป็นฝ่าย IT มากกว่าเป็นผู้ใช้งานระบบจริง ๆ
หลายครั้งไม่อาจจะแยกแยะระหว่าง ความต้องการ (Want) กับความต้องการจำเป็น (Need) ซึ่งอย่างหลังสำคัญกว่ามากในการพัฒนาระบบ
หลายครั้งเป็นกระบวนการช้างขี้ขี้ตามช้าง จำคำ Buzz word มาให้มี โดยที่ไม่มีความรู้ความเข้าใจอย่างแท้จริง เป็นแค่แฟชั่นทางเทคโนโลยีสารสนเทศที่อยากมีตาม ๆ กันโดยไม่รู้ด้วยซ้ำว่าจะใช้อะไร ทำให้ซื้อ Software หรือ Hardware ที่ไม่ได้ใช้และใช้ไม่เป็นมากองไว้มากมาย แต่ไม่พัฒนา Peopleware ซึ่งสำคัญที่สุด
การไม่ทราบกระบวนการธุรกิจหรือ Business Process หรือบางหน่วยงานอาจจะไม่มี Business Process ที่ชัดเจนด้วยซ้ำ ยังไม่มีภารกิจ (Mission) ที่ชัดเจนของหน่วยงาน หรือตั้งหน่วยงานซ้ำซ้อนกันและแย่งงานกันทำเองของภาครัฐ ตลอดจนมีแต่งานชั่วคราวที่เข้ามาอย่างรวดเร็ว Ad hoc work ทั้งหลาย ที่ตีตราว่า ด่วนที่สุด ด่วนสุด ๆ ไปเลย ไม่รู้จะด่วนไปไหน สารพัดจะด่วน มาแบบวูบวาบ แล้วก็เลิก ไม่ได้ทำต่อเนื่อง มีแต่งานที่ได้รับมอบหมาย ก็ทำให้ไม่เข้าใจกระบวนการธุรกิจ เมื่อไม่เข้าใจกระบวนการธุรกิจอย่างผู้เชี่ยวชาญแล้วก็ทำให้การกำหนดความต้องการในการพัฒนาระบบสารสนเทศล้มเหลว ไม่ตรงกับที่ต้องการใช้งานจริง
หลายครั้งก็ไปลอกระบบจากที่อื่นหรือแม้กระทั่งจากต่างประเทศมาเป็นต้นแบบในการพัฒนาระบบสารสนเทศโดยปราศจากความรู้ความเข้าใจที่แท้จริงในการปรับเปลี่ยนระบบในสอดคล้องกับสังคมไทยและการทำงานหรือภารกิจของหน่วยงานของตน ทำให้การกำหนดความต้องการในการพัฒนาระบบเป็นงานลอกที่ไม่ลงตัวและไม่เหมาะที่จะนำไปใช้จริง
ประการที่สาม การไม่อาจปรับเปลี่ยนการกำหนดความต้องการได้ตามความจำเป็น
ตัวแบบในการพัฒนาระบบสารสนเทศของภาครัฐ ยังยึดมั่นถือมั่นกับตัวแบบน้ำตกหรือ Waterfall model ซึ่งใช้มากว่า 30 ปี แล้ว โบราณมาก ล้าสมัย และภาคเอกชนส่วนใหญ่เลิกใช้ตัวแบบนี้ในการพัฒนาระบบสารสนเทศแล้ว เพราะพบว่าตัวแบบแบบนี้ไม่เหมาะสมกับการพัฒนาระบบที่การกำหนดความต้องการไม่ชัดเจน ซึ่งเป็นสภาพความเป็นจริงของภาครัฐเสมอในข้อสอง
วิธีการของ Waterfall model เริ่มจาก 1. การกำหนดความต้องการ 2. การวิเคราะห์และออกแบบระบบ 3. การพัฒนาระบบ 4. การตรวจสอบระบบ และ 5. การบำรุงรักษาระบบ ซึ่งทำตามเอกสารที่ศึกษามาอย่างละเอียดเป็นเส้นตรง วิธีการนี้ง่ายต่อการตรวจสอบ โดยเฉพาะการป้องกันการทุจริต (แต่ถ้าจะมีข้าราชการทุจริตก็ยังเกิดการทุจริตอยู่ดี หนีไม่พ้น) ลดการใช้วิจารณญาณ หาก Term of reference เขียนอย่างไรก็ต้องทำตามนั้นเพื่อให้ตรวจรับได้ และส่งมอบงานได้ตามเงื่อนไข เพื่อความปลอดภัยของกรรมการตรวจรับงานทุกคน โดยไม่ค่อยจะใส่ใจว่างานหรือระบบที่ออกมานั้นจะตรงกับหน้างานหรือทำไปใช้งานได้จริงไหม
ในกรณีที่หน้างานหรือสภาพแวดล้อมหรือกฎหมายได้เปลี่ยนไปแล้วก็ยังต้องยึดตาม TOR เป็นสรณะ จะใช้งานได้หรือไม่ได้ เหมาะหรือไม่เหมาะกับหน้างานให้ยึดตาม TOR เป็นสรณะ แม้กระทั่ง TOR ที่แย่มากไม่ตรงกับหน้างานเลยก็ต้องยึด TOR เพราะการแก้ไข TOR ทำได้ยาก และเกรงว่าสำนักงานตรวจเงินแผ่นดินจะตีความเป็นอย่างอื่น เช่น อาจจะตีความว่ามีการเอื้อให้ vendor ได้เงินตรวจรับงานผ่าน ดังนั้นทุกอย่างจึงยึดตามเอกสารเป็นสำคัญ ทำให้งานส่วนใหญ่ไปอยู่ที่เอกสารมากกว่าอยู่ที่เนื้องานจริง ๆ
ประการที่สี่ ในภาคราชการ มักมีการแก่งแย่งชิงดีชิงเด่น การแทงกันข้างหลัง การขัดแข้งขัดขากัน ราวกับละครน้ำเน่าหลังข่าว ไม่ต้องการให้ใครได้ดีเกินกว่าใคร คนเขาอยากให้เราได้ดี แต่ถ้าเด่นขึ้นทุกทีเขาหมั่นไส้ จงทำดีแต่อย่าเด่นจะเป็นภัย ไม่มีใครอยากเห็นเราเด่นเกิน หลวงวิจิตรวาทการ ท่านว่าไว้เช่นนี้
แต่ในการพัฒนาระบบสารสนเทศให้ได้ผลดี ไม่ว่าภาครัฐหรือเอกชน สมัยนี้ใช้หลัก Agile development ซึ่ง 1. ไม่เน้นการทำเอกสาร 2. เปลี่ยนแปลง requirement ได้เสมอ 3. ทำงานเป็นทีม cross-functional team สามัคคี ช่วยเหลือเกื้อกูล ร่วมแรงร่วมใจให้ระบบสำเร็จ ซึ่งต้องมีทั้งผู้ใช้งานและฝ่ายสารสนเทศหรือผู้พัฒนาระบบมาทำงานร่วมกัน 4. เปลี่ยนแปลงเร็ว ล้มเหลวเร็ว เรียนรู้เร็ว และเริ่มต้นใหม่อย่างรวดเร็ว 5. ปรึกษาหารือ หันหน้าเข้าหากัน แลกเปลี่ยนความรู้ความคิดเห็น หาทางออกที่ดีที่สุด
กระบวนการนี้อาจจะเรียกว่า Scrum คือการมะรุมมะตุ้มกันช่วยทำงานให้เสร็จอย่างรวดเร็ว เรียนรู้เร็ว เลิกเร็วหากล้มเหลว และเริ่มต้นใหม่อย่างรวดเร็ว และแบ่งงานใหญ่ออกเป็นงานย่อยๆ ในแต่ละขั้นและฉลองยินดีกับความสำเร็จในขั้นตอนเล็กๆ
แต่ทั้ง Agile development และ Scrum process เมื่อเจอวัฒนธรรมแบบราชการได้ก็เลยกลายเป็นการรุมสกรัมตีกันกระจาย ไม่ได้เป็น Agile development และ Scrum process แต่อย่างใด ต่างคนต่างใหญ่ ต่างคนต่างเก่ง ไม่มีใครยอมใคร คิดแต่เรื่องผลงานของตนเอง มากกว่าผลงานของหน่วยงาน
ทั้งสี่ประการนี้เป็นสาเหตุสำคัญที่ทำให้โครงการพัฒนาระบบสารสนเทศในภาครัฐล้มเหลวเป็นประจำ ทางแก้คือ ต้องเลือกสรรและธำรงรักษา talent ของบุคลากรด้านเทคโนโลยีสารสนเทศ ให้ได้แสดงฝืมือ ให้ได้ทำงานจริงๆ ให้พัฒนาระบบด้วยตัวเองจริงบ้าง ไม่ใช่จ้างไปทั้งหมด ต้องมีเส้นทางอาชีพที่ชัดเจน มีผลตอบแทนที่จูงใจสู้กับภาคเอกชนได้ และเปิดโอกาสให้ทำงานข้ามหน่วยงาน ร่วมมือกันทำงานกับสายงานอื่นๆ นอกจาก IT นอกจากนี้ยังต้องแก้ไขกฎระเบียบในการตรวจรับงานระบบสารสนเทศ และพยายามออกกฎเกณฑ์และกฎหมายให้เอื้อต่อ Agile development โดยพิจารณาที่ผลสัมฤทธิ์ของเนื้องานมากกว่าลายลักษณ์อักษร นอกจากนี้ยังต้องเปลี่ยนวัฒนธรรมของราชการให้มองที่เนื้องานและผลประโยชน์ที่เป็นของแผ่นดินมากกว่าการเล่นพรรคเล่นพวกว่าเป็นคนของใคร ระบบคุณธรรมในการบริหารงานบุคคลจะช่วยแก้ปัญหาเหล่านี้ให้บรรเทาเบาบางลงไปได้