เดินทางมาถึง ตอนที่ 18 แล้วนะครับ! ในตอนที่แล้ว (Ep.17) เราคุยกันถึงความเจ็บปวดของ “กับดักหอคอยงาช้าง” หรือการพัฒนาแบบรวมศูนย์ (Centralized) ที่คนทำไม่ได้ใช้ คนใช้ไม่ได้ทำ จนได้ระบบที่ “สวยแต่รูป จูบไม่หอม”
วันนี้ AdminTee จะพาไปดูทางออกที่ทั่วโลกกำลังมุ่งไป นั่นคือ Decentralized Development หรือ การกระจายอำนาจการพัฒนา ครับ แนวคิดนี้คือการเปลี่ยนบทบาทของหน่วยงานเจ้าของเรื่อง (Business Unit) จาก “ผู้รอคอย” ให้กลายเป็น “ผู้สร้าง” มันจะดีกว่าเดิมอย่างไร? และหน่วยงานที่ไม่ใช่สายไอทีจะทำได้จริงหรือ? มาหาคำตอบกันครับ
บทที่ 3: ยุทธศาสตร์การพัฒนาแบบมีส่วนร่วม (Co-Creation Strategy)
จุดประสงค์: แก้ปัญหา Bias และดึงเจ้าของงาน (Users) มาเป็นผู้ร่วมสร้าง
ตอนที่ 18/80: แนวคิด Decentralized Development: กระจายอำนาจการพัฒนาสู่หน่วยเจ้าของงาน
แนวคิดนี้เปรียบเสมือนการสร้าง “หมู่บ้านจัดสรร” ครับ แทนที่ส่วนกลาง (ผู้รับเหมาใหญ่) จะสร้างบ้านทุกหลังให้เหมือนกันหมด เราเปลี่ยนมาเป็น ส่วนกลางสร้างแค่ “เสาเข็มและหลังคา” (Core System) ส่วนการกั้นห้อง ทาสี หรือจัดวางเฟอร์นิเจอร์ (Module เฉพาะทาง) ปล่อยให้ “เจ้าของบ้าน” เป็นคนจัดการเอง
1. หลักการ: ผู้เชี่ยวชาญตัวจริง คือผู้สร้าง (Domain Expert as Builder)
- ความจริง: ไม่มีโปรแกรมเมอร์คนไหน เข้าใจกฎหมายแรงงานดีไปกว่า “กรมกำลังพลทหารเรือ” และไม่มีใครเข้าใจเรื่องบัญชีงบประมาณดีไปกว่า “สำนักงานปลัดบัญชีทหารเรือ”
- แนวทาง: เราจะมอบเครื่องมือ (Odoo Studio / Low-code tools) ให้หน่วยงานเหล่านี้ เข้ามาปรับแต่งหน้าจอ สร้างฟอร์ม และกำหนดขั้นตอนการอนุมัติ (Workflow) ด้วยตนเอง
- ตัวอย่าง:
- เดิม: กรมพลาธิการอยากเพิ่มช่อง “วันหมดอายุอาหารกระป๋อง” ต้องทำหนังสือแจ้งส่วนกลาง รอคิวแก้โค้ด 3 เดือน
- ใหม่: กรมพลาธิการ (โดยนายทหารที่มีทักษะไอทีประจำหน่วย) เข้าไปกดลากวาง (Drag & Drop) เพิ่มช่องนี้ใน Module Inventory ได้เอง เสร็จภายใน 10 นาที
2. บทบาทใหม่: Citizen Developer (นักพัฒนามือสมัครเล่น)
- โลกยุค AI เราไม่จำเป็นต้องจบนิศวกรรมคอมพิวเตอร์ถึงจะสร้างแอปฯ ได้ Odoo เอื้อให้คนทั่วไปที่เป็น Tech-Savvy (หัวไวเรื่องเทคโนโลยี) ในหน่วยงาน สามารถสร้างระบบง่ายๆ ได้
- สิ่งนี้จะช่วยลดภาระคอขวด (Bottleneck) ที่กองอยู่ที่ส่วนกลาง และทำให้ระบบตอบโจทย์หน้างานได้รวดเร็วทันใจ (Agile)
3. ข้อจำกัดและหลุมพราง (The Hidden Trap)
- Frankenstein Monster: ถ้าต่างคนต่างทำโดยไร้ทิศทาง ระบบอาจจะเละเทะ หน้าตาไม่เหมือนกันสักกรม ข้อมูลเชื่อมกันไม่ได้ กลายเป็นตัวประหลาด
- มาตรฐานความปลอดภัย: หน่วยย่อยอาจเผลอเปิดช่องโหว่ความปลอดภัยโดยไม่รู้ตัว เช่น เผลอตั้งค่าให้ใครก็ได้เข้าดูเงินเดือน
4. ข้อแนะนำและข้อเสนอแนะ: อิสระภายใต้กฎเกณฑ์ (Freedom with Guardrails)
- กฎเหล็กส่วนกลาง: สสท.ทร. (IT ส่วนกลาง) ต้องทำหน้าที่เป็น “ผู้คุมกฎ” (Regulator) กำหนดมาตรฐาน เช่น การตั้งชื่อตัวแปร, โทนสี, และมาตรฐานความปลอดภัย ใครทำผิดกฎ ระบบจะไม่ให้ผ่าน (Deploy)
- Sandbox First: ให้หน่วยงานลองทำใน “กระบะทราย” (ระบบทดสอบ) ก่อน จนกว่าจะมั่นใจและผ่านการตรวจสอบจากส่วนกลาง จึงจะอนุญาตให้นำขึ้นระบบจริง
- พี่เลี้ยงประกบ (Coaching): ในช่วงแรก ส่วนกลางต้องส่งผู้เชี่ยวชาญไปนั่งประกบ เพื่อสอนวิธีคิดเชิงระบบ (System Thinking) ให้กับหน่วยงานย่อย ไม่ใช่ปล่อยลอยแพ
บทสรุป
Decentralized Development ไม่ใช่การปัดความรับผิดชอบของฝ่ายไอที แต่เป็นการ “คืนอำนาจ” ให้กับผู้ที่รู้ดีที่สุด
การกระจายอำนาจการพัฒนา คือกุญแจสำคัญที่จะทำให้กองทัพเรือมีระบบที่ “ยืดหยุ่น” และ “ปรับตัวไว” (Resilience) โดยมี Odoo เป็นเวทีกลางให้ทุกคนได้แสดงฝีมือ ภายใต้กติกาเดียวกัน เพื่อให้เราได้บ้านที่ผู้อยู่อาศัยมีความสุข และโครงสร้างแข็งแรงปลอดภัยไปพร้อมๆ กันครับ
(อ้างอิง: Gartner Report: The Rise of the Citizen Developer และ แนวคิด Low-Code/No-Code Platform)
คำถามชวนคิด
- ในหน่วยงานของท่าน มี “น้องๆ รุ่นใหม่” ที่เก่งคอมพิวเตอร์ และมักจะช่วยแก้ปัญหาไอทีให้พี่ๆ เสมอไหมครับ? (คนนี้แหละ คือว่าที่ Citizen Developer)
- ท่านเคยหงุดหงิดที่ต้องรอส่วนกลางแก้ไขโปรแกรมเล็กๆ น้อยๆ นานเป็นเดือนหรือไม่? ถ้าทำเองได้จะทำไหม?
- ท่านคิดว่างานส่วนไหนของท่าน ที่คนนอก (โปรแกรมเมอร์) ไม่มีวันเข้าใจลึกซึ้งเท่าตัวท่านเอง?
ติดตามตอนต่อไป
เมื่อเรามอบอำนาจให้หน่วยงานทำเองแล้ว มาดูตัวอย่างจริงกันดีกว่า! ในตอนหน้า Ep.19/80 “ลด Bias ในการออกแบบระบบ: เมื่อกรมกำลังพลต้องเป็นคนสร้างระบบ HR เอง” เราจะไปเจาะลึกกรณีศึกษาการสร้าง Module ทรัพยากรบุคคล ที่ต้องมาแทนที่ HRMISS เดิม ว่า “เจ้าของงาน” จะออกแบบได้โดนใจแค่ไหน? ห้ามพลาดครับ!
Talk is cheap. Show me the code.