11/12/2025
จาก Requirements กองใหญ่กลายเป็น Flow ที่ทีมเข้าใจร่วมกัน
ช่วงหนึ่งผมมีโอกาสได้เข้าไปออกแบบระบบบริหารงานวิจัยและนวัตกรรมขององค์กรแห่งหนึ่ง
โจทย์คือ “แปลงจากงานเอกสารและ word กองมหาศาล ให้กลายเป็นระบบดิจิทัล”
ไม่ถึงกับ Digital Transformation ทั้งองค์กร แต่สำหรับกระบวนการวิจัย บอกเลยว่าแทบจะ 100%
ทุกอย่างต้องย้ายมาอยู่ในระบบใหม่ ตั้งแต่ขอทุน พิจารณา ติดตามความคืบหน้า สรุปผล เก็บเป็นฐานความรู้
วันแรกที่เข้าไปฟัง Requirements
วันนั้นผมนั่งฟังทั้งเช้า ทั้งบ่าย
เอกสารเต็มโต๊ะ บอร์ดเต็มไปด้วย Post-it และชื่อเอกสารยาว ๆ เต็มไปหมด
สิ่งที่ผมคิดในหัวคือ
“ระบบใหญ่ขนาดนี้…จะเรียง Flow ยังไงให้ทุกคนเห็นภาพเดียวกัน แล้วทำงานได้จริงวะ”
ที่ยากไม่ใช่แค่จำนวนขั้นตอน
แต่คือ จำนวนคนที่เกี่ยวข้องในแต่ละขั้นตอน ซึ่งมี Actor หลัก ๆ แบบนี้เลย
นักวิจัย – คนขอทุนหลัก ต้องกรอกข้อมูลเยอะมาก และต้องกลับมาอัปเดตความคืบหน้าเรื่อย ๆ
สมาชิกในทีมนักวิจัย – แต่ละคนต้อง “ยินยอม” ให้ใช้ข้อมูลตัวเองในโครงการก่อนด้วย
ผู้บริหารองค์กร – ไม่ลงรายละเอียด แต่ต้องเห็นภาพรวมว่า “ตอนนี้งานวิจัยทั้งองค์กรไปถึงไหนกันแล้ว”
เจ้าหน้าที่ปฏิบัติงาน – ประสานงาน, ตรวจเอกสาร, เช็คความครบถ้วน เรียกได้ว่างานเยอะสุดในระบบ
หัวหน้าฝ่าย – มีหน้าที่อนุมัติขั้นตอนสำคัญ ๆ ให้โครงการเดินต่อได้
ผู้ทรงคุณวุฒิ – 1 โครงการ มี 3 ท่าน ตรวจข้อเสนอ/รายงานวิจัย ถ้าไม่ผ่านก็ต้องวนกลับไปแก้
และความท้าทายคือ บางท่านอายุเยอะ บางท่านไม่ถนัดระบบออนไลน์ ก็ยังอยากอ่านเอกสารแบบเดิม
อ่านมาถึงตรงนี้น่าจะพอจินตนาการได้ว่า
ถ้าเรา “โดดไปเขียน SRS เลย” โดยไม่มี Flow กลางที่ทุกคนเห็นร่วมกัน โอกาสงงคือ 100% 😅
แล้วผมเริ่มจากตรงไหน?
เวลาเจอ Requirements กองใหญ่แบบนี้ สิ่งที่ผมทำ ไม่ใช่ การเปิด Word แล้วเริ่มเขียนข้อ 1, 2, 3
แต่ผมจะพยายาม “จับภาพรวมให้เหลือ 1 แผ่น” ก่อนเสมอ
ผมใช้วิธีประมาณนี้ครับ
1. เริ่มจาก Actor + เป้าหมายของแต่ละคนก่อน
ผมจะถามตัวเองก่อนว่า
นักวิจัย อยากทำอะไรให้เสร็จ ในระบบนี้
เจ้าหน้าที่ กลัวอะไร มากที่สุดถ้าระบบทำงานพลาด?
ผู้บริหาร อยากเห็นอะไรบนหน้าจอเดียว?
พอเราเข้าใจเป้าหมายของแต่ละคน Flow มันจะเริ่มมีทิศเอง
2. แตกเป็น Journey แยกตามมุมมอง
ผมจะไม่พยายามวาด Flow ใหญ่ทีเดียว แต่จะแยกเป็นก้อน ๆ เช่น
นักวิจัย จาก คิดหัวข้อ ขอทุน ส่งรายงาน
เจ้าหน้าที่ รับเรื่อง ตรวจเอกสาร ตามแก้
ผู้ทรงคุณวุฒิ รับเอกสาร อ่าน ให้ความเห็น/ผ่าน/ไม่ผ่าน
3. เอาเอกสารมาเรียงตามเวลา
เอกสารเยอะโคตร
ตั้งแต่แบบฟอร์มขอทุน, สัญญา, รายงานความก้าวหน้า, รายงานสรุป
“เอกสารนี้เกิดขึ้นเมื่อไหร่, ใครเป็นคนกรอก, ใครเป็นคนอ่าน, ใครเป็นคนอนุมัติ”
ตรงนี้แหละที่ทำให้ Flow เริ่มชัด
4. วาด Flow ใหญ่แบบ เข้าใจง่าย แต่มี Lane แยกตามคน สุดท้ายผมจะวาด Flow ใหญ่เป็นแบบ “Swimlane”
เวลาเอาไปคุยกับทีม ทุกคนจะเห็นเลยว่า “ช่วงนี้ใครกำลังทำอะไรอยู่” และ “งานไหลไปหาใครต่อ”
5. ยืนยันด้วยการเล่า Flow ให้คนที่ไม่เคยอยู่ในห้องประชุมฟัง ถ้าเราเล่า Flow นี้ให้คนที่ไม่เคยเข้าประชุมวันแรกฟัง แล้วเขา “ตามทัน” แปลว่า Flow นี้พร้อมเอาไปต่อยอดเป็น SRS, UI, และ Data Model ต่อแล้ว
สำหรับผม
การออกแบบระบบจาก Requirements กองใหญ่ ไม่ได้เริ่มที่ “หน้าจอ” หรือ “ตารางฐานข้อมูล”
แต่มันเริ่มจากการทำให้ทุกคนเห็น “ภาพเดียวกัน” ผ่าน Flow ง่าย ๆ ก่อน
“เรามี Flow กลาง ที่ทุกคนเข้าใจตรงกันแล้วหรือยัง?”
