ประเด็นหารือ (Q&A)

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

ป้ายกำกับ: ต้องเคาะก่อนออกแบบ = กระทบสถาปัตยกรรม/ราคา   ควรเคาะ = กระทบรายละเอียด   เชิงเทคนิค = ตอบภายหลังได้

ข้อ 1 - ใครคือ “ผู้มีอำนาจอนุมัติ”? ต้องเคาะก่อนออกแบบ

นี่คือประเด็นสำคัญที่สุด เอกสาร 3 แหล่งให้คำตอบต่างกัน

สถานะ ณ 27 ก.ค. 2569 - ต้นแบบเลือกตามแผนภาพไปก่อนแล้ว
เพื่อให้เวิร์กโฟลว์เดินได้ครบวงและทดสอบได้จริง ต้นแบบยึด แผนภาพ "ขั้นตอนการใช้รถ" เป็นหลัก: ด่านที่ 1 (อนุมัติการใช้รถ) และด่านที่ 2 (อนุมัติให้ออกเดินทาง) เป็นของหัวหน้ายานฯ และ ตัดขั้นเห็นชอบของหัวหน้ากลุ่มงานออกจากระบบ (แผนภาพระบุว่าใบขอเข้ามาตอน "หน.งาน อนุมัติแล้ว")

แล้วช่องลายเซ็นที่ 4 ในแบบ 3 ล่ะ? ตัวแบบฟอร์มเขียนกำกับไว้เองว่า "ผู้มีอำนาจสั่งใช้รถยนต์ (ผอ.สคร.10 หรือผู้รับมอบอำนาจ)" - แบบฟอร์มจึงถามว่า ใครเป็นผู้สั่งใช้ ไม่ได้บังคับว่า ผอ. ต้องเซ็นเอง ในทางปฏิบัติของราชการ อำนาจนี้มอบต่อได้ ซึ่งอธิบายได้ว่าทำไม SOP เขียน "หัวหน้าพัสดุ" และแผนภาพเขียน "หัวหน้ายานฯ" - คนละคน แต่เป็นอำนาจเดียวกัน

ทางที่เลือก (27 ก.ค.): เก็บ ด่านอนุมัติเดียว ตามแผนภาพ และให้ระบบ บันทึกว่าใครเป็นผู้อนุมัติจริง แล้ว พิมพ์ชื่อคนนั้นลงช่องที่ 4 พร้อมบรรทัด "ปฏิบัติราชการแทน ผอ.สคร.10" เมื่อผู้อนุมัติไม่ใช่ ผอ. เอง

• ถ้า ผอ. กดอนุมัติเอง ช่องที่ 4 จะขึ้นชื่อ ผอ. โดยไม่มีบรรทัดปฏิบัติราชการแทน (ระบบเปิดสิทธิ์ให้ ผอ. กดได้อยู่แล้ว)
• ช่องที่ 2 (หัวหน้ากลุ่ม) พิมพ์ชื่อหัวหน้ากลุ่มงานของผู้ขอ พร้อมกำกับว่า "เห็นชอบก่อนบันทึกเข้าระบบ" ตามความจริงที่เซ็นบนกระดาษมาก่อน
• ช่องที่ 3 พิมพ์ เจ้าหน้าที่ผู้จัดรถ ไม่ใช่หัวหน้า เพื่อไม่ให้คนเดียวเซ็น 2 ช่อง

ทำไมไม่พิมพ์ชื่อ ผอ. ไว้เฉย ๆ: นั่นคือการใส่ลายเซ็นของการอนุมัติที่ไม่ได้เกิดขึ้นจริง ลงในเอกสารราชการ ส่วนการปล่อยว่างก็ทำให้แบบฟอร์มไม่ครบ - การพิมพ์ผู้อนุมัติจริง + ฐานอำนาจ จึงเป็นทางเดียวที่ทั้งครบและตรงกับสิ่งที่เกิดขึ้น

ยังเปิดให้ปรับได้: ถ้าผู้ใช้ยืนยันว่าต้องมีด่านของ ผอ. จริง ๆ การใส่กลับเป็นการ แก้ไฟล์นิยามเวิร์กโฟลว์ ไม่ใช่แก้โค้ด และ หัวหน้างานพัสดุ ที่ SOP ระบุ ยังต้องถามว่าคือผู้รับมอบอำนาจคนเดียวกันหรือไม่

แหล่ง	ผู้อนุมัติที่ระบุ
SOP สคร.10	หัวหน้างานพัสดุ (head of procurement)
แผนภาพ BPMN (ศิวะ)	หัวหน้ายานฯ (fleet chief)
แบบฟอร์มจริง	ผอ.สคร.10 / ผู้รักษาราชการ (ผู้มีอำนาจสั่งใช้รถยนต์)

การปรับให้สอดคล้องที่เป็นไปได้ (สมมติฐาน): อาจเป็น สายลำดับที่มีหลายจุด ไม่ใช่ผู้อนุมัติเดี่ยว

ผู้ขอ -> หัวหน้ากลุ่มงาน (เห็นชอบ)
      -> หัวหน้ายานพาหนะ (จัดรถ+คนขับ, บันทึกทะเบียน/เลขไมล์)
      -> ผอ. หรือผู้รับมอบอำนาจ (อนุมัติสั่งใช้)

โดย หัวหน้าพัสดุ อาจถือ อำนาจที่ได้รับมอบ (ผู้รับมอบอำนาจ) ในทางปฏิบัติ

ต้องเคาะ: สายอนุมัติจริงคือใครบ้าง ตามลำดับใด และจุดไหนคือ “ผู้อนุมัติที่มีผลผูกพัน”

คำถามที่ศิวะเขียนกำกับในแบบฟอร์มโดยตรง (ข้าง "หัวหน้ากลุ่ม/ผู้แทน"): "หัวหน้าของผู้ขออนุญาต? ในระบบเก็บไหมครับ?" -> ระบบควรเก็บ/บันทึกหัวหน้ากลุ่มงานที่เห็นชอบในแต่ละคำขอหรือไม่?
ข้อเสนอ: เก็บ - เพราะเป็นลายเซ็นจุดที่ 2 ในแบบฟอร์มราชการ และจำเป็นต่อ audit trail

อัปเดต (BPMN 24 + 26 ก.ค.): แผนภาพยังให้ หัวหน้ายานฯ เป็นผู้อนุมัติ และเพิ่มเป็น 2 จุดอนุมัติ (อนุมัติคำขอ + อนุมัติให้ออกเดินทาง) 27 ก.ค. ต้นแบบทำตามนี้แล้ว ดูกล่องสถานะด้านบน

ข้อ 2 - ชั้นความปลอดภัยอยู่เฟส 1 หรือแยกไปก่อน? ต้องเคาะก่อนออกแบบ

คำถาม: เช็คลิสต์คนขับ, เป่าแอลกอฮอล์, ถ่ายเลขไมล์, บันทึก Location - อยู่ใน Phase 1 (ตาม BPMN) หรือแยกไปเฟสถัดไป?

ทำไมสำคัญ: SOP ครอบคลุมแค่แกน “ขอใช้รถ -> จัดรถ -> เดินทาง -> ปิดเพื่อเบิกจ่าย” ส่วนชั้นความปลอดภัยมาจาก BPMN + โน้ตของ ผอ.สคร.10 มี “การปิดงาน 2 แบบ” ต่างกัน (ปิดเพื่อเบิกจ่าย vs ปิดเชิงความปลอดภัย)

ข้อเสนอของทีม: รวมชั้นความปลอดภัยไว้ใน Phase 1 ตามแผนภาพ BPMN (เอกสารชุดนี้ออกแบบตามแนวนี้) - ขอผู้ใช้ยืนยัน

ข้อ 3 - SOP นี้เป็น “แม่แบบเดียว” หรือเฉพาะ สคร.10? ต้องเคาะก่อนออกแบบ

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

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

ข้อ 4 - “Data Entry” เป็นสิทธิ์รายกลุ่มงาน หรือระดับสำนักงาน? ต้องเคาะก่อนออกแบบ

ทำไมสำคัญ: ตัดสินว่าข้อมูลรถ/ประวัติซ่อมเป็นของกลุ่มงานหรือส่วนกลาง กระทบว่าใครเห็น/แก้ไขประวัติรถของใครได้

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

ข้อ 5 - “Deploy รายจังหวัด” คือแบบไหน? ต้องเคาะก่อนออกแบบ

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

ทำไมสำคัญ: กระทบสถาปัตยกรรม การดูแล การรับประกัน และ PDPA อุบลฯ มีเซิร์ฟเวอร์อยู่แล้ว = อาจ host ฝั่งลูกค้า

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

ข้อ 6 - ยืนยันขอบเขตนำร่อง + โค้ดเบสเดียว ควรเคาะ

คำถาม: ยืนยันว่า รถราชการทั่วไปเป็นโปรเจกต์นำร่อง ทำก่อน ส่วน EMS เลื่อนเป็นเฟสถัดไป (ยังต้องทำ) และ ทั้งคู่อยู่ในระบบ/repo เดียวกัน (EMS = กองรถหนึ่งในระบบเดียว)

ข้อเสนอของทีม: ใช่ - สร้างเป็นระบบจองรถเดียว EMS เป็นกองรถที่เปิดใช้ในเฟสถัดไป ใช้ RBAC/tenancy ร่วมกัน

ข้อ 7 - หนึ่งกลุ่มงานมีผู้อนุมัติ/ผู้ขอกี่คน? ควรเคาะ

ข้อเสนอของทีม: รองรับหลายคนต่อบทบาทต่อกลุ่มงาน + ขอรายชื่อจริงเพื่อ seed ข้อมูล

ข้อ 8 - กลุ่มงาน A/B/C คือกลุ่มใดจริง? มีคำตอบแล้ว (BPMN 24 ก.ค.)

อัปเดต: แผนภาพ 24 ก.ค. ระบุ 13 กลุ่มงานจริงของ สคร.10 แทน A/B/C แล้ว (ดูรายชื่อที่ บทบาทและสิทธิ์) - เหลือเพียงยืนยันคำสะกด/ชื่อเต็มของข้อ 2 และ 6 ที่ตัดคำ

ข้อ 9 - ระบบต้องพิมพ์แบบฟอร์มราชการไหม? ควรเคาะ

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

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

ข้อ 10 - กติกาการจองกระชั้นชิด (< 10 วัน)? ควรเคาะ

SOP กำหนดจองล่วงหน้า 10 วัน ถ้าน้อยกว่านั้น ระบบควร บล็อก / เตือนแต่ให้ผ่าน / ต้องมีผู้อนุมัติระดับสูงขึ้น? (ดู การจองกระชั้นชิดในต้นแบบจริง - แจ้งเตือนตอนกดส่งใบขอ)

ข้อ 11 - กติกาการยกเลิกและการเปลี่ยนคนขับ? ควรเคาะ

• ยกเลิก ได้ถึงเมื่อไร (ก่อนอนุมัติ / ก่อนออกเดินทาง) ต้องระบุเหตุผลไหม?
• แอลกอฮอล์เกินเกณฑ์ -> ยืนยันว่าให้ เปลี่ยนคนขับในงานเดิม (ไม่ยกเลิก/ไม่เริ่มใหม่) - เป็นการตัดสินใจที่ทีมได้จากโน้ตแล้ว ขอผู้ใช้ยืนยัน (ในแผนภาพ 24 ก.ค. จุดนี้คือ “อนุมัติให้ออกเดินทาง” จุดที่ 2)

ข้อ 11.5 - ใครเป็นคนตรวจรับรถคืน? ข้อสันนิษฐาน - ต้องยืนยัน

เดิมต้นแบบให้ คนขับปิดงานเอง (อัปโหลดรูปเลขไมล์แล้วจบ) ซึ่งแปลว่าไม่มีใครยืนยันว่ารถกลับมาจริง และไม่มีใครตรวจตัวเลขที่ใช้เบิกจ่าย BPMN v2 มีกล่อง “บันทึกการรับรถ (รถกลับมาจริง)” ในเลนหัวหน้ายานฯ เราจึงแยกเป็น 2 ขั้น (ดู ขั้นตอนที่ 6)

ข้อเสนอของทีม (ตัดสินใจแล้ว ขอผู้ใช้ยืนยัน): ให้เป็นงานของ เจ้าหน้าที่งานยานพาหนะ หัวหน้ายานฯ กดแทนได้ - เพราะแผนภาพ v2 ไม่มีเลนของเจ้าหน้าที่ให้แยก (มี 3 เลน) เลน “หัวหน้ายานฯ” จึงหมายถึงงานยานพาหนะทั้งหน่วย เหมือนขั้นเลือกรถ/เลือกคนขับที่อยู่เลนเดียวกันแต่ SOP ให้เป็นงาน ของเจ้าหน้าที่ อีกทั้งการรับรถเป็นการ บันทึกข้อเท็จจริง ไม่ใช่การอนุมัติ และรถ 200 คัน ทยอยกลับตลอดวัน ถ้าผูกกับหัวหน้าคนเดียวจะเป็นคอขวด (ดู ขั้นตอนที่ 6)

ที่ยังต้องเคาะ:

• ต้องตรวจอะไรบ้างตอนรับรถ - แค่เลขไมล์ + รูป หรือมีเช็คลิสต์สภาพรถขากลับด้วย?
• ถ้าคนขับกลับนอกเวลาราชการ ให้ปิดงานย้อนหลังวันรุ่งขึ้นได้ไหม?
• ต้องให้ ผู้ขอ รับรู้/เซ็นรับด้วยไหม (SOP ให้ส่งใบขอฉบับจริงให้ผู้ขอไปเบิกจ่าย)?

ข้อ 12 - ตัวเลขและฟิลด์ที่ต้องยืนยัน เชิงเทคนิค

• ขนาดกองรถ: มีคำตอบแล้ว - BPMN v2 เรียกว่า รถราชการ 200 คัน (เดิม “รถศูนย์วิชาการ”) · รถ EMS 500 คัน · รถเช่า X คัน
• ฟิลด์สุดท้ายของฟอร์มจอง ในโน้ต: อ่านไม่ออกชัด - สถานที่เดินทาง (จุดหมาย) หรือ สถิติดำเนินการ? (จุดหมายน่าจะเข้ากับบริบทมากกว่า)
• ความสัมพันธ์ Case กับ Fleet หมายถึงอะไร?

ข้อ 13 - การเชื่อมระบบและ ThaID เชิงเทคนิค

• เชื่อมระบบเบิกจ่าย/การเงิน (เช่น GFMIS-adjacent) หรือแค่ผลิตข้อมูลให้เบิกเอง?
• ThaID จำเป็นในเฟสนี้ไหม? (ข้อเสนอ: ไม่ - ผู้ใช้เป็น staff ใช้ล็อกอินปกติ/SSO ได้ ThaID เป็น Phase 2)

ข้อ 14 - ความพร้อมและการพักคนขับ เชิงเทคนิค

BPMN ระบุปัญหา: อยู่เวรต่อเวร, นอนไม่เต็มที่, แลกเวรไม่บอก, เวรละ 12 ชม.

• ภาระงานคนขับคำนวณจาก เลขไมล์ (ยืนยันแล้วในโน้ต) - ต้องมีเพดานชั่วโมง/ระยะทางต่อวันไหม?
• ความน่าเชื่อถือของการเป่าแอลกอฮอล์ (ใครเป็นพยาน, กันการโกง) - ผอ.สคร.10 ขอเลื่อนไปหารือภายหลัง ยังไม่เป็นความต้องการในเฟสนี้