ประเด็นที่ต้องเคาะกับผู้ใช้

ชุดคำถาม + ข้อเสนอของทีม เพื่อใช้เป็นจุดตั้งต้นในการหารือ

▶ เปิดต้นแบบระบบ 📋 ขั้นตอนงาน (SOP) 🖨️ พิมพ์ / PDF

สิ่งที่เราเข้าใจตอนนี้: ระบบนี้เป็น ระบบจอง/ขอใช้รถยนต์ราชการทั่วไป ของหน่วยงาน (ไม่ใช่เฉพาะรถพยาบาล EMS) ยึดตาม SOP งานยานพาหนะ สคร.10 · แกนหลักคือ การจองแบบปฏิทิน + การอนุมัติตามสาย + สิทธิ์ตามกลุ่มงาน (RBAC) · EMS และระบบบำรุงรักษา (PM) เป็น Phase 2 · ต้นแบบที่แนบมาสาธิตครบทั้ง 5 ขั้นตอนตาม SOP แล้ว · ด้านล่างคือจุดที่ยังต้องยืนยันกับผู้ใช้จริงก่อนสรุปขอบเขต

1ขอบเขตและการนำไปใช้

ต้องเคาะก่อนออกแบบ

SOP ของ สคร.10 นี้ ใช้เป็น "แม่แบบเดียว" สำหรับทุกหน่วยงาน/ทุกจังหวัด หรือเป็นเฉพาะของ สคร.10 (นำร่อง)?

ทำไมสำคัญ: ระบบตั้งเป้า deploy รายจังหวัด แต่ละหน่วยงานอาจมีขั้นตอน/ผู้อนุมัติต่างกัน ถ้าต้องรองรับหลายรูปแบบ = ต้องทำ workflow ให้ตั้งค่าได้ (configurable) ซึ่งกระทบเวลาและราคาอย่างมีนัยสำคัญ

ข้อเสนอ: เฟส 1 ยึด SOP สคร.10 เป็นมาตรฐาน (นำร่องที่อุบลฯ ซึ่งมีเซิร์ฟเวอร์อยู่แล้ว) · ทำ workflow ให้ปรับได้ในระดับพารามิเตอร์ (เช่น SLA, ผู้อนุมัติ) · รูปแบบที่ต่างมากค่อยเก็บเป็น Phase ถัดไป

ต้องเคาะก่อนออกแบบ

ยังต้องมีชั้น "ความปลอดภัย/บำรุงรักษา" จากโน้ตหมอจิน (เช็คลิสต์กลับฐาน · ผลเป่าแอลกอฮอล์ · PM · เช็คอุปกรณ์โดยพยาบาล) อยู่บนระบบนี้ด้วยไหม หรือแยกไปก่อน?

ทำไมสำคัญ: SOP สคร.10 ครอบคลุมเฉพาะแกน "ขอใช้รถ → จัดรถ → เดินทาง → ปิดงานเพื่อเบิกจ่าย" ยังไม่รวมชั้นความปลอดภัยจากโน้ตหมอจิน · มี "การปิดงาน" สองแบบที่ต่างกัน (ปิดเพื่อเบิกจ่าย vs ปิดเชิงความปลอดภัย)

ข้อเสนอ: เฟส 1 ทำแกนจอง+อนุมัติ (SOP) ให้ครบก่อน · ชั้นความปลอดภัย (checklist, alcohol, PM) เป็น Phase 2 ที่เสริมบนโครงเดิมได้ · ตอนปิดงานในต้นแบบเราเผื่อช่องเลขไมล์+สภาพรถไว้แล้วเป็นจุดต่อยอด

ควรเคาะ

ระบบต้อง "ออก/พิมพ์แบบฟอร์มใบขอใช้รถราชการ" ตามรูปแบบราชการที่กำหนด หรือแค่เก็บข้อมูลในระบบก็พอ?

ทำไมสำคัญ: ถ้าต้องได้เอกสารตามแบบฟอร์มราชการ (เพื่อให้ตรวจรับ/เบิกจ่ายได้) รูปแบบ ช่องข้อมูล และลายเซ็นถูกกำหนดไว้ เราออกแบบเองไม่ได้ · ขอ ตัวอย่างใบขอใช้รถจริง ที่ใช้อยู่

ข้อเสนอ: รองรับการออก PDF ใบขอตามแบบฟอร์มจริง (ขอไฟล์ต้นฉบับ) · พร้อมข้อมูลครบสำหรับแนบเบิกจ่าย

เชิงเทคนิค

ระบบต้องเชื่อมกับระบบเดินทาง/เบิกจ่ายที่มีอยู่ (เช่นระบบการเงินราชการ) หรือแค่ผลิตข้อมูลให้ผู้ขอนำไปเบิกเอง?

ทำไมสำคัญ: SOP ระบุชัดว่าใบขอเป็นเอกสารประกอบ "ประมาณการค่าใช้จ่าย" และ "เบิกจ่าย" · ถ้าต้องเชื่อม integration = งานเพิ่มและต้องคุยสิทธิ์เข้าถึงระบบปลายทาง

ข้อเสนอ: เฟส 1 ผลิตข้อมูล/เอกสารให้ครบเพื่อแนบเบิก (ยังไม่เชื่อมระบบการเงินโดยตรง) · การเชื่อมต่อเป็น Phase ถัดไปตามความจำเป็น

2ผู้ใช้ บทบาท และสิทธิ์ (RBAC)

ต้องเคาะก่อนออกแบบ

บทบาท "Data Entry" (ผู้บันทึกข้อมูลรถ/บำรุงรักษา) เป็นสิทธิ์ราย "กลุ่มงาน" หรือเป็นสิทธิ์ระดับ "สำนักงาน" (ดูแลทุกกลุ่มงาน)?

ทำไมสำคัญ: ตัดสินว่าข้อมูลรถ/ประวัติซ่อมเป็นของกลุ่มงาน หรือของส่วนกลาง · กระทบว่าใครเห็น/แก้ไขประวัติรถของใครได้ · จาก SOP เจ้าหน้าที่ยานพาหนะ (ปรีชา/วัชรพันธ์) ดูเหมือนเป็น Data Entry ระดับสำนักงาน

ข้อเสนอ: ตั้งต้นเป็นสิทธิ์ระดับสำนักงาน (สอดคล้อง SOP) แต่ขอยืนยันกับผู้ใช้ เพราะโน้ตวาดไว้นอกตารางกลุ่มงาน

ควรเคาะ

ในแต่ละกลุ่มงาน มีผู้อนุมัติ/ผู้ขอ ได้ "คนเดียว" หรือ "หลายคน"? และการอนุมัติเป็นสายลำดับ (หัวหน้ากลุ่ม → หัวหน้าพัสดุ) ใช่ไหม?

ทำไมสำคัญ: กำหนดโครงสร้าง RBAC และ workflow การอนุมัติ · จาก SOP เห็นเป็น "สายอนุมัติ 2 จุด" (หัวหน้ากลุ่มงานเห็นชอบ → หัวหน้าพัสดุอนุมัติ) ซึ่งต้นแบบทำตามนี้

ข้อเสนอ: รองรับหลายคนต่อบทบาทต่อกลุ่มงาน · อนุมัติแบบสายลำดับตาม SOP · ขอรายชื่อจริงของแต่ละกลุ่มงานเพื่อ seed ข้อมูล

เชิงเทคนิค

"กลุ่มงาน A/B/C" ในโน้ต = กลุ่มงานจริงของ สคร.10 ใช่ไหม? และ Login ผ่าน ThaID จำเป็นในเฟสนี้หรือไม่?

ทำไมสำคัญ: ผู้ใช้ทั้งหมดเป็นเจ้าหน้าที่ (ไม่ใช่ประชาชน) จึงใช้ username/password หรือ SSO ของหน่วยงานได้ · ThaID ต้องขออนุญาต DOPA + สัมภาษณ์ (เอกชน) ใช้เวลาไม่แน่นอน (ดู Issue #4)

ข้อเสนอ: เฟส 1 ใช้ล็อกอินปกติ (หรือ SSO หน่วยงานถ้ามี) · ThaID เป็น Phase 2 · ผู้ขอ ThaID ควรเป็นหน่วยงานรัฐ ไม่ใช่ ColabsCraft

3โครงสร้างและการติดตั้ง

ต้องเคาะก่อนออกแบบ

"Deploy รายจังหวัด" หมายถึง instance แยกต่อจังหวัด (บนเซิร์ฟเวอร์ของหน่วยงาน) หรือระบบเดียวรวมศูนย์ที่แยกข้อมูลรายจังหวัด?

ทำไมสำคัญ: กระทบสถาปัตยกรรม การดูแล การรับประกัน และความเป็นเจ้าของข้อมูล (PDPA) อย่างมาก · อุบลฯ (สคร.10) มีเซิร์ฟเวอร์อยู่แล้ว = อาจ host ฝั่งลูกค้า ซึ่งกระทบส่วน managed-hosting ในใบเสนอราคาเดิม

ข้อเสนอ: รองรับได้ทั้งสองแบบด้วย Docker · เฟส 1 นำร่องบนเซิร์ฟเวอร์อุบลฯ 1 instance · โครงสร้างผู้ดูแล 2 ระดับ (Super/Province Admin) เตรียมไว้แล้วในต้นแบบ

เชิงเทคนิค

ความสัมพันธ์ "Case ↔ Fleet" ในโน้ตหมายถึงอะไร (เคส/ภารกิจ ↔ กลุ่มรถ)? และมีการจัดกลุ่มรถแบบใด?

ทำไมสำคัญ: ช่วยกำหนด data model ของรถและการจัดสรร · ตอนนี้ต้นแบบใช้ "ประเภทรถ" (ตู้/กระบะ/เก๋ง) + สถานะ (ว่าง/ปฏิบัติงาน/ซ่อม) เป็นแกน

ข้อเสนอ: ขอคำอธิบายสั้น ๆ ของ Case/Fleet เพื่อยืนยัน model · เบื้องต้นออกแบบให้รองรับหลายประเภทรถและการเช่า

4สรุปขอบเขตที่เสนอ

เฟส 1 (นำร่อง สคร.10)

จองรถแบบปฏิทิน + ใบขอใช้รถ
อนุมัติตามสาย (หัวหน้ากลุ่ม → พัสดุ)
จัดสรรรถ + พขร. / รองรับการเช่ารถ
เตรียมรถ + ยืนยันล่วงหน้า 3 วัน
ปิดงาน + ข้อมูลเพื่อเบิกจ่าย
RBAC ตามกลุ่มงาน · Admin 2 ระดับ
แดชบอร์ด (การใช้รถ · ปัญหารถ · เช่ารถ)

เฟส 2 (ต่อยอด)

ชั้นความปลอดภัย: เช็คลิสต์กลับฐาน · ผลเป่าแอลกอฮอล์
ความพร้อมคนขับ (ชั่วโมงขับจากเลขไมล์)
ระบบบำรุงรักษา/PM · แจ้งซ่อม
EMS: เช็คอุปกรณ์โดยพยาบาล
Login ผ่าน ThaID
เชื่อมระบบเบิกจ่าย/การเงิน
Deploy หลายจังหวัด

เอกสารนี้เป็นจุดตั้งต้นการหารือ ไม่ใช่ข้อสรุปสุดท้าย · "ข้อเสนอ" คือค่าเริ่มต้นที่ทีมแนะนำ ปรับได้ตามความเห็นผู้ใช้ · ยังไม่ระบุราคา/คน-วัน (อยู่ในใบเสนอราคาแยก) · ColabsCraft · อ้างอิง SOP สคร.10 (21 ก.ค. 69) + โน้ตหมอจิน (18 ก.ค. 69)