รายงานตัวประจำวันพุธที่ 31 ธันวาคม 2568 วันส่งท้ายปีเก่าต้อนรับปีใหม่ครับ! ขอให้ปีหน้าเป็นปีแห่งการเปลี่ยนแปลงที่ดีของพวกเราทุกคนนะครับ ในตอนที่แล้ว (Ep.19) เราได้เห็นภาพที่น่าตื่นเต้นเมื่อ ถ้า กพ.ทร. ลุกขึ้นมาเป็น “สถาปนิก” ออกแบบระบบ HR ด้วยตัวเองเพื่อลด Bias แต่ช้าก่อนครับ… ถ้าปล่อยให้ทุกกรม กอง ต่างคนต่างสร้างระบบกันเองโดยไม่มีกติกา กองทัพเรืออาจกลายเป็น “หอคอยบาเบล” ที่คุยกันไม่รู้เรื่อง หรือเกิดปัญหาระบบตีกันมั่วไปหมด
วันนี้ใน ตอนที่ 20 เราจะมาพูดถึงจุดเปลี่ยนสำคัญของ กรมสื่อสารและเทคโนโลยีสารสนเทศ (สสท.ทร.) และ ทีมพัฒนาส่วนกลาง (Dev Team) ที่ต้องถอยฉากจากการเป็น “ช่างก่อสร้าง” มาสวมหมวกใบใหม่คือ “ผู้กำกับดูแลมาตรฐาน” (Regulator) บทบาทนี้สำคัญอย่างไร? เปรียบเหมือนกรรมการห้ามมวย หรือตำรวจจราจร? มาหาคำตอบกันครับ
บทที่ 3: ยุทธศาสตร์การพัฒนาแบบมีส่วนร่วม (Co-Creation Strategy)
จุดประสงค์: แก้ปัญหา Bias และดึงเจ้าของงาน (Users) มาเป็นผู้ร่วมสร้าง
ตอนที่ 20/80: บทบาทใหม่ของ สสท.ทร. และ ทีม Dev : จาก “ผู้สร้าง” สู่ “ผู้กำกับดูแลมาตรฐาน” (Regulator)
ในยุค Decentralized Development ที่เรากระจายอำนาจให้หน่วยงานต่างๆ พัฒนา Odoo Module เอง หน้าที่ของฝ่ายไอทีส่วนกลาง (สสท.ทร. และ ทีม Dev) จะเปลี่ยนไปอย่างสิ้นเชิงครับ เปรียบเสมือนการเปลี่ยนจาก “คนพายเรือ” มาเป็น “คนถือหางเสือ”
1. จาก “เขียนโค้ดเอง” สู่ “การตรวจโค้ด” (Code Audit & Quality Control)
- บทบาทเดิม: สสท.ทร. ต้องรับโจทย์มานั่งพัฒนาโปรแกรม หรือรับความต้องการมาเพื่อให้ทีมพัฒนาดำเนินการ
- บทบาทใหม่: หน่วยงานเจ้าของเรื่อง (เช่น นขต.ทร.) เขียนโปรแกรมมา (หรือจ้าง Outsource เขียน) แล้วส่งให้ สสท.ทร. “ตรวจ” (Audit)
- หน้าที่ Regulator:
- ตรวจสอบความปลอดภัย: มีช่องโหว่ให้แฮกเกอร์เข้าไหม?
- ตรวจสอบประสิทธิภาพ: โค้ดนี้จะทำให้ Server กลางอืดไหม?
- ตรวจสอบมาตรฐาน: ตัวแปรตั้งชื่อถูกตามกฎ (Naming Convention) หรือไม่?
- ถ้าผ่าน: ประทับตรา “Approved” ให้นำขึ้นระบบจริง (Production)
2. ผู้คุมกฎจราจรข้อมูล (Data Traffic Controller)
- สถานการณ์: ยกตัวอยา่ง กง.ทร. จะสร้างตารางฐานข้อมูล “รายชื่อผู้เบิกเงิน” และ กพ.ทร. ก็จะสร้างตาราง “รายชื่อทหาร”
- บทบาท Regulator: สสท.ทร. ต้องเป่านกหวีดหยุดเกม แล้วบอกว่า “ห้ามสร้างซ้ำซ้อน!” ต้องมาชี้เป้าว่าให้ใช้ตารางกลาง (Master Data) ตัวไหนร่วมกัน เพื่อไม่ให้เกิดปัญหาขยะข้อมูล (Data Redundancy) และกำหนดมาตรฐานการเชื่อมต่อ (API Standard) ให้ทุกระบบคุยกันรู้เรื่อง
3. ผู้ดูแลโครงสร้างพื้นฐาน (Infrastructure Guardian)
- หน่วยงานย่อยรับผิดชอบแค่ “แอปพลิเคชัน” (Software) แต่ สสท.ทร. รับผิดชอบ “บ้าน” (Hardware/Cloud)
- ต้องดูแลรักษาความปลอดภัยของ Server, การสำรองข้อมูล (Backup), และการป้องกันภัยคุกคามไซเบอร์ (Firewall) ให้กับทุก Module ที่มาอาศัยอยู่
4. ข้อจำกัดและแรงเสียดทาน (Constraints & Friction)
- ตำรวจผู้ร้าย: บทบาท Regulator มักถูกมองว่าเป็น “ตัวถ่วง” หรือ “จอมจับผิด” ที่ทำให้งานของหน่วยย่อยล่าช้า เพราะต้องรอตรวจสอบความปลอดภัย
- Shadow IT: หน่วยงานบางแห่งใจร้อน ไม่อยากรอกระบวนการตรวจสอบของส่วนกลาง จึงแอบไปตั้ง Server เถื่อนทำกันเอง ซึ่งเสี่ยงต่อความมั่นคงปลอดภัย
5. ข้อแนะนำและข้อเสนอแนะ (Recommendations)
- Service Level Agreement (SLA): สสท.ทร. ต้องกำหนดเวลามาตรฐานในการตรวจสอบโค้ดให้ชัดเจน เช่น “ส่งมาตรวจวันนี้ รู้ผลภายในกี่วันวันทำการ” เพื่อไม่ให้เป็นคอขวด
- Developer Council: ตั้งคณะทำงานร่วมระหว่าง Dev ส่วนกลาง และ Dev ของหน่วยย่อย เพื่อประชุมแลกเปลี่ยนเทคนิคและอัปเดตมาตรฐานใหม่ๆ ทุกเดือน ไม่ใช่แค่สั่งการทางเดียว
บทสรุป
บทบาท Regulator ของ สสท.ทร. ไม่ใช่การเข้ามายึดอำนาจ แต่เป็นการเข้ามา “สร้างความมั่นใจ” ครับ
เพราะในทะเลดิจิทัลที่กว้างใหญ่ หากเรือรบแต่ละลำต่างคนต่างแล่นโดยไม่มีกฎแห่งความปลอดภัย อุบัติเหตุย่อมเกิดขึ้นได้เสมอ การมีผู้กำกับดูแลที่เข้มแข็ง จะทำให้ระบบ Open ERP ของกองทัพเรือเติบโตได้อย่างมีทิศทาง มีเสถียรภาพ และปลอดภัยสูงสุด แม้ว่าคนสร้างจะมีเป็นร้อย แต่มาตรฐานต้องมีเพียงหนึ่งเดียว (One Standard) ครับ
(อ้างอิง: กรอบมาตรฐาน DevOps สำหรับภาครัฐ และ IT Governance Framework)
คำถามชวนคิด
- ท่านอุ่นใจกว่าไหม? ถ้ารู้ว่าแอปพลิเคชันที่ท่านใช้ ถูกตรวจสอบความปลอดภัยจากผู้เชี่ยวชาญส่วนกลางอย่างละเอียดแล้วก่อนปล่อยออกมา?
- ท่านคิดว่า “ความเร็วในการพัฒนา” กับ “ความปลอดภัยของระบบ” อะไรสำคัญกว่ากันในบริบทของกองทัพเรือ?
- หากท่านเป็นทีมพัฒนา ท่านอยากได้ “พี่เลี้ยง” ที่คอยแนะนำเทคนิค หรือ “ตำรวจ” ที่คอยจับผิด? (สสท.ทร. ควรเป็นแบบไหน?)
ติดตามตอนต่อไป
ปีใหม่ ฟ้าใหม่! เมื่อมีทั้งคนสร้าง (User/Unit) และคนคุมกฎ (NCIT) แล้ว จะทำอย่างไรให้คนสองกลุ่มนี้ทำงานร่วมกันได้อย่างราบรื่น ไม่ตีกันตายก่อนงานเสร็จ? ในตอนหน้า Ep.21/80 “การจัดตั้งคณะทำงานร่วม (Cross-Functional Team): IT + Business Units” เราจะมาดูโมเดลการตั้งทีมแบบ “Avengers” ที่รวมคนเก่งจากทุกฝ่ายมาอยู่ในห้องเดียวกัน ห้ามพลาดครับ!
Talk is cheap. Show me the code.