wms-app/sdlc/1-PM Process (10 Work Product)/2.Project Plan/2-Software Project Plan/200-WMS-26-001-00 Software Project Plan 25690213 V1.0 ApS.md

Software Project Plan

| Document No | Software Project Plan | Release, Version, By: | 25690213 V1.0 ApS | | Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด | | Project Code | 200-WMS-26-001-00 | | Title | แผนการดำเนินโครงการ | | Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 | Project Duration | 232 วัน | | Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) , คุณนพพงษ์ เจริญสุข (System Analyst) | | Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |

1 Manufacture

บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด เป็นบริษัทผู้ประกอบธุรกิจด้านเทคโนโลยีสารสนเทศ ซึ่งมีประสบการณ์ในการส่งมอบผลิตภัณฑ์และบริการด้านเทคโนโลยีให้แก่หน่วยงานภาครัฐและเอกชนอย่างต่อเนื่อง บริษัทประกอบธุรกิจหลัก 3 ด้าน ได้แก่

• พัฒนาซอฟต์แวร์ตามความต้องการของหน่วยงาน (Software Development)
• จำหน่ายผลิตภัณฑ์ซอฟต์แวร์สำเร็จรูป (Software Package) เช่น ระบบบริหารจัดการสินทรัพย์
• ให้บริการบำรุงรักษาระบบ (Service Maintenance: MA) ครอบคลุมโครงสร้างพื้นฐาน เครื่องแม่ข่าย และศูนย์ข้อมูล

2 Overview

เพื่อยกระดับการบริหารจัดการคลังสินค้าของบริษัทให้มีความถูกต้อง รวดเร็ว และตรวจสอบย้อนกลับได้ บริษัทมีความประสงค์จะพัฒนา ระบบบริหารจัดการคลังสินค้า (BRN WMS) ขึ้นใหม่ โดยมีวัตถุประสงค์เพื่อ

• รวมศูนย์ข้อมูลคลังสินค้า สินค้าคงคลัง และความเคลื่อนไหวของสินค้าไว้ในระบบเดียว
• เชื่อมโยงงานขาย งานจัดซื้อ งานการเงิน และการบันทึกบัญชีเข้ากับความเคลื่อนไหวของสินค้า
• ควบคุมสิทธิ์การเข้าถึงและแยกข้อมูลระหว่างบริษัทและคลังสินค้าอย่างชัดเจน
• ให้ผู้บริหารเห็นภาพรวมสถานะคลังสินค้าและสถานะทางการเงินได้ตามเวลาจริง

3 Goals and Scope

3.1 เป้าหมายของโครงการ

เป้าหมายด้านองค์กร

• ลดข้อผิดพลาดของยอดสินค้าคงคลังที่เกิดจากการบันทึกด้วยมือ
• เพิ่มความสามารถในการตรวจสอบย้อนกลับของสินค้าตาม Lot, Serial Number และวันหมดอายุ
• ทำให้ข้อมูลคลังสินค้าและข้อมูลบัญชีสอดคล้องกันโดยไม่ต้องบันทึกซ้ำ

เป้าหมายด้านผู้ใช้งาน

• ให้พนักงานคลังสินค้าบันทึกรายการรับเข้า จ่ายออก และโอนย้ายได้สะดวกจากอุปกรณ์หน้าคลัง
• ให้ฝ่ายขายและฝ่ายจัดซื้อจัดทำเอกสารและติดตามสถานะได้ในระบบเดียว
• ให้ฝ่ายบัญชีได้ข้อมูลรายการที่ผ่านการตรวจสอบแล้วโดยอัตโนมัติ

3.2 ขอบเขตของโครงการ (SOW)

ลำดับ	ระบบ	ระบบย่อย
1	ระบบบริหารจัดการผู้ใช้งานและสิทธิ์	ลงทะเบียนเจ้าของบริษัทและเชิญผู้ใช้งาน (Onboarding) / เข้าสู่ระบบและควบคุมสิทธิ์ตามบทบาท Owner / Admin / Staff / Viewer / กู้คืนรหัสผ่าน, OTP และควบคุม Session / ตั้งค่าบริษัท, SMTP, ผู้ใช้งาน และสิทธิ์การเข้าถึงแอปพลิเคชัน
2	ระบบข้อมูลหลัก (Master Data)	คลังสินค้า, พื้นที่จัดเก็บ, ช่องจัดเก็บ (Bin) / หมวดสินค้าและสินค้า / ประเภทผู้ติดต่อและผู้ติดต่อ (ลูกค้า/ผู้ขาย) / รองรับโครงสร้างคลังแบบชั้นเดียวและแบบหลายชั้น
3	ระบบควบคุมสินค้าคงคลัง (Inventory Control)	รับสินค้าเข้า (Stock-in) / จ่ายสินค้าออก (Stock-out) พร้อมตรวจสอบยอดคงเหลือ / โอนย้ายสินค้าระหว่างคลัง/ตำแหน่ง / ติดตาม Lot, Serial Number และวันหมดอายุ / พิมพ์บาร์โค้ดสินค้า/ตำแหน่ง และรองรับการสแกน / แนบไฟล์ประกอบรายการ
4	ระบบขาย (Sales)	ใบเสนอราคา (Quotation) / ใบสั่งขาย (Sales Order) / ใบแจ้งหนี้ (Invoice) / ใบรับคืน / ใบลดหนี้ (Return / Credit Note)
5	ระบบจัดซื้อ (Purchasing)	ใบขอซื้อ (Purchase Request) / ใบสั่งซื้อ (Purchase Order) / ใบแจ้งหนี้ซื้อ (Purchase Invoice) / ใบคืนสินค้าผู้ขาย (Supplier Return)
6	ระบบการเงิน (Finance)	ใบวางบิลรับ / ใบเสร็จรับเงิน / ใบวางบิลจ่าย / ใบสำคัญจ่าย
7	ระบบบัญชี (Accounting)	ผังบัญชี, แผนก, สูตรบัญชี / สมุดรายวันและบัญชีแยกประเภท (Journal / GL) / รายงานงบทดลอง, งบกำไรขาดทุน, งบดุล, ภาษีมูลค่าเพิ่ม
8	ระบบรายงานและแดชบอร์ด	แดชบอร์ดคลังสินค้าและบัญชี / รายงานสต๊อก, ความเคลื่อนไหว, ความจุคลัง, สินค้าใกล้หมด, สินค้าหมดอายุ, Lot / กรอง ดู พิมพ์ และส่งออกรายงาน
9	ระบบควบคุมเอกสาร	ออกเลขที่เอกสารอัตโนมัติตามลำดับที่กำหนด / ควบคุมสถานะและวงจรชีวิตของเอกสาร / บันทึกผู้สร้าง/ผู้แก้ไข/ประวัติรายการ
10	ระบบแจ้งเตือนและงานตามกำหนดเวลา	แจ้งเตือนแบบ Real-time ผ่าน Node.js / Socket.IO / งานสรุปยอดสต๊อก/GL และแจ้งเตือนสินค้าใกล้หมด, ใบแจ้งหนี้ค้างชำระ ตามกำหนดเวลา
11	ระบบติดตั้งและตั้งค่า	ติดตั้งแบบ Manual ผ่าน setup.php / ติดตั้งแบบ Container ผ่าน Docker Compose (php-apache, mariadb, node/pm2) / สร้างค่าตั้งค่าและความลับของระบบจาก .env โดยไม่เก็บใน Source Control

3.3 สิ่งส่งมอบ (Work Products)

รหัส	สิ่งส่งมอบ (Work Product)	รายละเอียด
WP 1.0	เอกสาร 200-WMS-26-001-00 Software Project Plan (พร้อม Work Schedule)	ส่งเอกสารจำนวน 1 ชุด
WP 2.0	เอกสาร 200-WMS-26-001-00 Customer Requirements	ส่งเอกสารจำนวน 1 ชุด
WP 3.0	เอกสาร 200-WMS-26-001-00 Software Requirements Specification	ส่งเอกสารจำนวน 1 ชุด
WP 4.0	เอกสาร 200-WMS-26-001-00 Software Design	ส่งเอกสารจำนวน 1 ชุด
WP 5.0	เอกสาร 200-WMS-26-001-00 Change Report	ส่งเอกสารจำนวน 1 ชุด (ทะเบียนการควบคุมการเปลี่ยนแปลง)
WP 6.0	เอกสาร 200-WMS-26-001-00 Test Case and Test Procedures	ส่งเอกสารจำนวน 1 ชุด
WP 7.0	เอกสาร 200-WMS-26-001-00 Validation Results	ส่งเอกสารจำนวน 1 ชุด
WP 8.0	เอกสาร 200-WMS-26-001-00 Software User Document	ส่งเอกสารจำนวน 1 ชุด
WP 9.0	ระบบ BRN WMS ที่ผ่านการทดสอบพร้อมนำไปใช้งานจริง	ส่ง Source Code (Git baseline 6c39700) และติดตั้ง
WP 10.0	เอกสาร 200-WMS-26-001-00 Product Operation Guide	ส่งเอกสารจำนวน 1 ชุด
WP 11.0	เอกสาร 200-WMS-26-001-00 Maintenance Document	ส่งเอกสารจำนวน 1 ชุด

3.4 Delivery Instruction

ในการส่งมอบตามสิ่งส่งมอบ (Work Product) เมื่อแล้วเสร็จและถึงกำหนดเวลา (Due Date) ผู้จัดการโครงการต้องจัดเตรียมเครื่องมือและสถานที่เพื่อให้ลูกค้าทำการทดสอบการยอมรับผู้ใช้ (Validation Result หรือ User Acceptance Test – UAT) โดยทดสอบตามข้อกำหนดในเอกสารความต้องการผู้ใช้ (Customer Requirements) ทีละข้อ และลงนามยืนยันเมื่อผ่านการทดสอบ

• กรณีสิ่งส่งมอบไม่แล้วเสร็จตามกำหนด (Delay) ผู้จัดการโครงการต้องนัดประชุมรายงานความคืบหน้าและอธิบายสาเหตุให้ลูกค้าทราบ พร้อมทั้งตกลงกำหนดวันส่งมอบใหม่อย่างเป็นทางการร่วมกัน
• การปิดโครงการ (Project Closure) เมื่อสิ่งส่งมอบทั้งหมดผ่านการตรวจรับและได้รับลายเซ็นอนุมัติจากลูกค้าครบทุกชุดแล้ว ผู้จัดการโครงการจัดประชุมปิดโครงการอย่างเป็นทางการ พร้อมจัดทำเอกสารสรุปผลการดำเนินงานเพื่อเก็บเป็นหลักฐาน

3.5 เกณฑ์คุณภาพ (Quality Criteria)

ด้านคุณภาพของระบบ

ลำดับ	หัวข้อ	เกณฑ์คุณภาพ	วิธีประเมิน
1.1	ความถูกต้องของฟังก์ชัน	ฟังก์ชันทั้งหมดทำงานตรงตาม Customer Requirements ครบ 100%	ทดสอบตาม Test Case และ UAT
1.2	ความถูกต้องของข้อมูลสต๊อกและบัญชี	ไม่พบยอดสต๊อกติดลบหรือรายการ GL ที่ไม่สมดุล	ทดสอบ Transaction และ Rollback (TC-UN08.002)
1.3	ความปลอดภัยของระบบ	ไม่พบข้อบกพร่องระดับวิกฤตด้านสิทธิ์และการแยกข้อมูล	ทดสอบสิทธิ์เชิงลบ (TC-UN12.001, TC-UN12.002)
1.4	ประสิทธิภาพการตอบสนอง	งานประจำวันตอบสนองภายในเวลาที่ใช้งานได้จริงบนสภาพแวดล้อมที่ตกลง	ทดสอบตามปริมาณข้อมูลตัวอย่าง (TC-UN09.001)
1.5	ความสามารถในการเข้าถึง	ใช้งานได้บน Desktop, Tablet และ Mobile (Responsive)	ทดสอบข้ามอุปกรณ์

ด้านการดูแลหลังส่งมอบ

ลำดับ	หัวข้อ	เกณฑ์คุณภาพ	วิธีประเมิน
2.1	การตอบสนองเหตุขัดข้อง	ตอบรับภายใน 4 ชั่วโมง และแก้ไขตามระดับความรุนแรงที่กำหนดใน SLA	บันทึกการให้บริการ
2.2	การสำรองข้อมูล	มีระบบสำรองข้อมูลอัตโนมัติรายวันและทดสอบกู้คืนได้จริง	Backup & Restore Test (TC-UN13.004)
2.3	การเฝ้าระวังระบบ	ตรวจสอบสถานะบริการทุก 5 นาที และแจ้งเตือนเมื่อล้มเหลว 2 ครั้งติดกัน	บันทึกการเฝ้าระวัง

4 Software Development Life Cycle Methodology

โครงการเลือกใช้แนวทาง Incremental / Evolutionary ภายใต้ขั้นตอนหลักของ Waterfall เนื่องจาก

• ขอบเขตและสิ่งส่งมอบกำหนดชัดเจนตั้งแต่ต้นโครงการ จึงวางแผนและตรวจรับเป็นงวดได้
• ระบบมีหลายโมดูลที่ส่งมอบต่อเนื่องกัน จึงพัฒนาและทดสอบทีละส่วนเพื่อลดความเสี่ยง
• เอกสารครบถ้วนตามมาตรฐาน ISO/IEC 29110 ที่เน้น Work Products และ Traceability
• ตรวจสอบย้อนกลับ (Audit) และตรวจรับงานได้อย่างเป็นทางการ

ขั้นตอน	แนวทางที่ใช้จริงในโครงการ
Requirements	เก็บความต้องการและตั้ง Baseline ก่อนเริ่มพัฒนา การเปลี่ยนแปลงภายหลังต้องพิจารณาตามเกณฑ์ใน Change Report ก่อนดำเนินการ
Design	ออกแบบสถาปัตยกรรม โครงสร้างฐานข้อมูล และ Software Unit ก่อนพัฒนาแต่ละโมดูล
Implementation	พัฒนาเป็นโมดูลต่อเนื่องระหว่าง 19 ก.พ. – 29 พ.ค. 69 พร้อมทบทวนและแก้ไขระหว่างทาง
Verification	ตรวจสอบ Work Products 4 รอบ ประมาณทุก 2 เดือน และรอบสุดท้ายก่อนส่งมอบ ตามแผนในหัวข้อ 8.1
Validation	ทดสอบระบบและ UAT ระหว่าง 10–14 ส.ค. 69 บนสภาพแวดล้อมที่กำหนด โดยใช้ Customer Requirements ทุกรายการเป็นตัวตั้ง
Closure	ตรวจรับ อบรม ปิดงานควบคุมปฏิบัติการ และปิดโครงการภายใน 24 ส.ค. 69

5 Organization

5.1 Role & Responsibility

ลำดับ	บทบาท	ชื่อ-นามสกุล (ชื่อย่อ)	อีเมล	รายละเอียดหน้าที่
1	Project Manager (ApS)	คุณอภิรัชช์ สุภัทรประทีป	apirach.s@brn.co.th	จัดทำ Project Charter และแผนโครงการ / วางแผน Timeline, Resource, Risk, Quality / จัดประชุมและติดตามความคืบหน้า / ควบคุมการเปลี่ยนแปลงและการปิดโครงการ
2	System Analyst (NoC)	คุณนพพงษ์ เจริญสุข	noppong.c@brn.co.th	เก็บและวิเคราะห์ความต้องการ / จัดทำ SRS และเอกสารออกแบบระบบ / ออกแบบฐานข้อมูลและความสัมพันธ์ของโมดูล / ตรวจสอบความสอดคล้องของงานพัฒนากับความต้องการ
3	Developer (ThS)	คุณธนกร สถิตวิทยากุล	thanakorn.s@brn.co.th	พัฒนาโมดูลและ API ตามการออกแบบ / จัดการฐานข้อมูลและประสิทธิภาพ / ดูแลความปลอดภัยและการติดตั้ง / แก้ไขข้อบกพร่องที่พบจากการทดสอบ
4	QA / Tester (PaNg)	คุณปริญ งามขำ	parin.n@brn.co.th	จัดทำ Test Case และ Test Procedures / ทดสอบระบบและบันทึกผล / ติดตามการแก้ไขข้อบกพร่องและทดสอบซ้ำ / สนับสนุนผู้ใช้งานช่วง UAT
5	Document Control (YaB)	คุณเยาวลักษณ์ บางชมภู	yaowalak.b@brn.co.th	ควบคุมรหัสเอกสารและเวอร์ชัน / จัดเก็บและตรวจสอบความครบถ้วนของเอกสาร / ประสานการทบทวนและอนุมัติ / บันทึกประวัติการเปลี่ยนแปลงเอกสาร
6	Project Sponsor (SeV)	คุณเสรี วิริยะสกุลธรณ์	seri.v@brn.co.th	อนุมัติขอบเขต งบประมาณ และการเปลี่ยนแปลง / ตัดสินใจเชิงกลยุทธ์ / ทดสอบการยอมรับและตรวจรับส่งมอบ / อนุมัติปิดโครงการ

6 Project Estimate

6.1 Size of the Software Work Products

ลำดับ	Work Product	ปริมาณ (ประมาณการ)
1	เอกสารบริหารโครงการ (PM Process)	10 รายการ
2	เอกสารกระบวนการพัฒนา (SI Process)	12 รายการ
3	ความต้องการลูกค้า (Customer Requirements)	80 รายการ (CR01–CR14)
4	ความต้องการซอฟต์แวร์ (SRS)	49 รายการ (SR01–SR09)
5	Software Unit	45 หน่วย (UN01–UN13)
6	Test Case	45 รายการ
7	ตารางฐานข้อมูล	ประมาณ 50 ตาราง ใน 2 ฐานข้อมูล

6.2 Effort Man-Day

ลำดับ	ตำแหน่ง	หน้าที่หลัก	ระยะเวลา (Man-Day)
1	Project Manager	ควบคุมงาน ประสานงาน ติดตามแผน	120
2	System Analyst	วิเคราะห์ความต้องการ ออกแบบระบบ	60
3	Developer	พัฒนาระบบและแก้ไขข้อบกพร่อง	100
4	QA / Tester	วางแผนทดสอบ ทดสอบระบบ UAT	40
5	Document Control	ควบคุมเอกสารและหลักฐานโครงการ	60

7 Project Resources

Human Resource

ลำดับ	Team	จำนวน (คน)
1	Project Management (PM, Document Control)	2
2	Software Implementation (SA, Developer, QA)	3
3	Project Sponsor / ตัวแทนลูกค้า	1

Computer Resource

ลำดับ	รายการ	จำนวน
1	Notebook สำหรับทีมพัฒนาและทดสอบ	5 เครื่อง
2	Git Server (Repository หลัก)	1 ระบบ
3	Internal Testing Server (PHP 8, MariaDB, Node.js)	1 เครื่อง
4	Production Server สำหรับใช้งานจริง	1 เครื่อง
5	เครื่องอ่านบาร์โค้ดสำหรับทดสอบ	1 เครื่อง

8 Work Schedule

แผนการดำเนินงานของโครงการ รวม 232 วัน ตั้งแต่ 5 มกราคม 2569 ถึง 24 สิงหาคม 2569 รายละเอียดกิจกรรม ผู้รับผิดชอบ และสิ่งส่งมอบรายกิจกรรม อยู่ในเอกสาร 200-WMS-26-001-00 Work Schedule ซึ่งเป็นส่วนหนึ่งของ Project Plan

Phase	ช่วงเวลา	ผลลัพธ์หลัก
Project Initiation	5 มกราคม 2569 – 23 มกราคม 2569	Statement of Work, Stakeholder Register, Project Charter
Project Planning	12 มกราคม 2569 – 18 กุมภาพันธ์ 2569	Customer Requirements, Software Project Plan, Work Schedule
Project Execution	19 กุมภาพันธ์ 2569 – 29 พฤษภาคม 2569	SRS, Software Design, ระบบที่พัฒนาแล้ว, Software Components
Verification & Validation	30 พฤษภาคม 2569 – 17 สิงหาคม 2569	Test Case, Test Report, Verification Results, Validation Results
Project Close	10 สิงหาคม 2569 – 24 สิงหาคม 2569	Acceptance Report, Training Report, List of Evidence

8.1 แผนการตรวจสอบ (Verification Plan)

โครงการมีระยะเวลา 232 วัน จึงกำหนดให้ตรวจสอบ Work Products ทั้งหมด 4 ครั้ง ประมาณทุก 2 เดือน (ทุก 60–75 วัน) ครั้งละ 3 ชั่วโมง และรอบสุดท้ายก่อนส่งมอบระบบ 6 ชั่วโมง เพื่อให้พบประเด็นตั้งแต่เนิ่น ๆ และแก้ไขได้ก่อนเริ่มงานขั้นถัดไป ผลการตรวจสอบแต่ละรอบบันทึกใน Verification Results และประเด็นที่พบบันทึกใน Correction Register

รอบ	วันที่ตรวจสอบ	เวลา	ชั่วโมง	หัวข้อการตรวจสอบ	Deliverables under Review
1	17 มีนาคม 2569	09:00 – 12:00 น.	3	ตรวจสอบเอกสารวางแผนโครงการและความต้องการ	WP 1.0, WP 2.0
2	29 พฤษภาคม 2569	09:00 – 12:00 น.	3	ตรวจสอบเอกสารความต้องการซอฟต์แวร์และการออกแบบ	WP 3.0, WP 4.0, WP 5.0
3	31 กรกฎาคม 2569	09:00 – 12:00 น.	3	ตรวจสอบชุดทดสอบและการสอบกลับ	WP 6.0
4	17 สิงหาคม 2569	09:00 – 16:00 น.	6	User Acceptance Test (UAT) และตรวจสอบเอกสารส่งมอบทั้งหมด	WP 1.0, WP 2.0, WP 3.0, WP 4.0, WP 5.0, WP 6.0, WP 7.0, WP 8.0, WP 9.0, WP 10.0, WP 11.0

หัวข้อ	รายละเอียด
ผู้ตรวจสอบ	คุณปริญ งามขำ (QA/Tester) ร่วมกับ คุณเยาวลักษณ์ บางชมภู (Document Control)
ผู้เข้าร่วมรับฟังผล	ผู้จัดทำ Work Product ที่ตรวจในรอบนั้น เพื่อแก้ไขได้ทันทีเมื่อพบประเด็น
ผู้อนุมัติผลการตรวจสอบ	คุณเสรี วิริยะสกุลธรณ์ (Project Sponsor)
รวมเวลาตรวจสอบตลอดโครงการ	15 ชั่วโมง
บันทึกผล	Verification Results แยกฉบับตามรอบ (V0.1–V1.0) และ Correction Register

Risk & Constraints Note

1. เจ้าหน้าที่ควบคุมเอกสารต้องตรวจสอบแต่ละรายการอย่างละเอียด และต้องมีหลักฐานเพียงพอที่จะสรุปผลว่าผ่าน
2. ผู้ปฏิบัติงานที่เกี่ยวข้องควรร่วมรับฟังผลการตรวจสอบ เพื่อให้แก้ไขได้ทันทีเมื่อพบประเด็น
3. การตรวจสอบแต่ละครั้งไม่ควรถูกขัดจังหวะ ซึ่งจะทำให้การตรวจสอบเลื่อนออกไป
4. ห้ามให้ผู้อื่นตรวจสอบแทนผู้ที่ได้รับมอบหมาย

9 Risk Management Plan

วัตถุประสงค์ของแผนบริหารความเสี่ยง คือระบุแนวทางจัดการความเสี่ยงของโครงการ เพื่อให้โครงการบรรลุเป้าหมายภายในเวลา งบประมาณ และคุณภาพที่กำหนด

ลำดับ	หมวด	รายการ	รายละเอียด
1	ขอบเขต	ครอบคลุมทุกกิจกรรมของโครงการ	ตั้งแต่ Initiation, Planning, Execution จนถึง Close
2	บทบาทผู้รับผิดชอบ	Project Manager (Owner), ทีมพัฒนา, Project Sponsor	PM ติดตามและควบคุมความเสี่ยง ทีมพัฒนารายงานความเสี่ยงให้ PM
3	รอบการทบทวน	ทบทวนทุกงวดรายงานความก้าวหน้า	บันทึกความเสี่ยงใหม่และการเปลี่ยนแปลงระดับความเสี่ยงใน Progress Status Record

ตารางระบุความเสี่ยงหลักของโครงการ

ลำดับ	ความเสี่ยง (Risk)	ประเภท	โอกาสเกิด	ผลกระทบ	ระดับความเสี่ยง	แนวทางป้องกัน (Mitigation)	แผนรับมือ (Contingency Plan)	ผู้รับผิดชอบ
R1	ความต้องการเปลี่ยนแปลงระหว่างพัฒนา	กระบวนการ	High	High	High	ตั้ง Baseline ความต้องการและทบทวนทุกงวด	จัดทำ Change Report และจัดลำดับความสำคัญใหม่	ApS / NoC
R2	ทีมพัฒนาไม่เพียงพอหรือขาดทักษะเฉพาะทาง	บุคลากร	Middle	High	High	ถ่ายทอดความรู้ภายในทีมและจัดทำเอกสารประกอบ	ขออนุมัติจัดหาผู้เชี่ยวชาญเพิ่มเฉพาะงาน	ApS
R3	ยอดสินค้าคงคลังไม่ถูกต้อง	เทคโนโลยี	Middle	High	High	ใช้ Transaction, ตรวจสอบข้อมูลนำเข้า และล็อกรายการ	ตรวจสอบและปรับปรุงยอดพร้อมบันทึก Correction Register	ThS / PaNg
R4	ข้อมูลรั่วไหลข้ามบริษัทหรือสิทธิ์ไม่รัดกุม	ความปลอดภัย	Middle	High	High	บังคับ Role Guard และขอบเขตบริษัทฝั่งเซิร์ฟเวอร์	ปิดช่องโหว่ทันทีและทดสอบสิทธิ์เชิงลบซ้ำ	ThS / PaNg
R5	ค่าตั้งค่าหรือความลับรั่วไหล	ความปลอดภัย	Middle	High	High	ยกเว้นไฟล์ตั้งค่าจาก Git และสร้างความลับตอนติดตั้ง	เปลี่ยนค่าความลับและตรวจสอบประวัติการเข้าถึง	ThS
R6	ข้อมูลสูญหายระหว่างพัฒนาหรือใช้งาน	เทคโนโลยี	Middle	High	High	สำรอง Git 2 Remote และสำรองฐานข้อมูลรายวัน	กู้คืนจากชุดสำรองตามขั้นตอนในคู่มือ	ThS
R7	หลักฐานการทดสอบและตรวจรับไม่ครบถ้วน	กระบวนการ	Middle	High	High	รักษาการสอบกลับสองทิศทางและบันทึกผลทุกครั้ง	ทดสอบซ้ำและบันทึกหลักฐานก่อนตรวจรับ	PaNg / YaB
R8	ผู้ใช้ไม่ยอมรับระบบ (UAT ไม่ผ่าน)	ผู้ใช้งาน	Middle	High	High	ให้ผู้ใช้ร่วมทบทวนความต้องการและสาธิตระบบระหว่างพัฒนา	ปรับปรุงตาม Feedback และทดสอบการยอมรับใหม่	ApS / SeV

10 Contingency Actions for Non-Completed Tasks

แผนรองรับสำหรับกรณีงานไม่แล้วเสร็จตามกำหนด (Non-Completed Task)

ลำดับ	สถานการณ์	สาเหตุที่พบบ่อย	ผลกระทบที่อาจเกิด	แผนรองรับเมื่อเกิดเหตุ	ผู้รับผิดชอบ
1	งานไม่เสร็จภายในกำหนด (Due Date)	ประเมินเวลาผิดพลาด หรือทรัพยากรไม่เพียงพอ	กระทบ Timeline และกำหนดส่งมอบ	ประชุมด่วนเพื่อประเมินสถานะ จัดลำดับความสำคัญใหม่ ปรับแผน และแจ้งลูกค้าอย่างเป็นทางการ	ApS
2	งานล่าช้าเพราะขาดบุคลากร	ลาป่วย ลาออก หรือไม่พร้อมปฏิบัติงาน	งานค้างสะสมและภาระงานกระจุกตัว	จัดทำเอกสารส่งมอบงาน ถ่ายทอดความรู้ให้ผู้ปฏิบัติแทน และขออนุมัติจัดหาผู้ช่วยเฉพาะงาน	ApS / ฝ่ายบุคคล
3	งานค้างเพราะรอข้อมูลจากผู้ใช้	ผู้ให้ข้อมูลส่งความต้องการหรือข้อมูลตั้งต้นล่าช้า	ไม่สามารถพัฒนาหรือทดสอบต่อได้	แจ้งเตือนเป็นลายลักษณ์อักษร แยกงานที่ยังไม่พร้อมออก และนัดยืนยัน Timeline ใหม่	ApS / SeV
4	งานไม่เสร็จเพราะพบข้อบกพร่องซ้ำซ้อน	ความซับซ้อนสูงหรือขาดการทดสอบระยะแรก	เกิดความล่าช้าในการพัฒนาและทดสอบ	จัดลำดับข้อบกพร่องตามความรุนแรง แยกงานแก้ไขออกจากงานพัฒนาใหม่ และทดสอบซ้ำ	ThS / PaNg
5	งานล่าช้าเพราะต้องแก้ความต้องการ	ขอบเขตเปลี่ยนหลังเริ่มงาน	กระทบแผนงานและสิ่งส่งมอบ	จัดทำ Change Report อย่างเป็นทางการ ประเมินผลกระทบ และขออนุมัติก่อนดำเนินการต่อ	ApS / SeV

11 Document and Repository

รูปแบบไฟล์ (File Format) การกำหนดชื่อไฟล์ให้ใช้รูปแบบดังนี้

[Project code] [Document name] [yyyymmdd] V[version] [editor name].[ext.]

หัวข้อ	รายละเอียด
[Project code]	รหัสโครงการตามส่วนงานบัญชี เช่น 200-WMS-26-001-00
[Document name]	ชื่อเอกสาร เช่น Progress Status Record
[yyyymmdd]	วันที่ของเอกสารตามปีพุทธศักราช เช่น 25690817
[version]	เวอร์ชันของเอกสาร เช่น 1.0
[editor name]	ตัวย่อของชื่อผู้จัดทำ เช่น ApS
[ext.]	นามสกุลไฟล์ เช่น pdf

การประกาศเวอร์ชัน (Version Declaration) เก็บเอกสารแต่ละเวอร์ชันแยกไฟล์เพื่อให้ตรวจสอบย้อนหลังได้ โดยใช้รูปแบบ Major.Minor

เวอร์ชัน (Version)	รายละเอียด
0.1 (Draft)	ร่างเอกสารฉบับแรก
0.2 (Draft)	ปรับปรุงตามผลการทบทวน
1.0 (Release)	อนุมัติใช้เป็นเอกสารทางการ
1.1 (Revision)	ปรับปรุงเอกสารหลังอนุมัติ

Project Repository ใช้ Git Server เป็นศูนย์กลางในการจัดเก็บและควบคุมเวอร์ชันของ Source Code และเอกสารทั้งหมดที่เกี่ยวข้องกับโครงการ

ลำดับ	หัวข้อ	รายละเอียด
1	ที่เก็บข้อมูล (Repository Location)	ทีมงานเข้าถึง Repository ผ่าน Git Server โดย Repository ของโครงการนี้เก็บทั้ง Source Code และเอกสาร ISO
2	สิทธิ์การเข้าถึง (Access Control)	สมาชิกโครงการได้รับสิทธิ์ตามบทบาท โดย Project Manager และ System Analyst มีสิทธิ์อนุมัติการ Merge
3	การจัดเก็บไฟล์งาน (File Storage Rules)	ไฟล์ที่เกี่ยวข้องกับโครงการต้องจัดเก็บใน Repository และไฟล์ที่สร้างจากเครื่องส่วนบุคคลต้องนำขึ้น Repository ภายในเวลาที่กำหนด

Project Repository Backup เพื่อป้องกันการสูญหายของข้อมูลใน Git Server

ลำดับ	หัวข้อ	รายละเอียด
1	ผู้รับผิดชอบ (Responsibility)	มอบหมาย Developer ตรวจสอบความถูกต้องของข้อมูลสำรองอย่างสม่ำเสมอ
2	วิธีการสำรองข้อมูล (Backup Methods)	ซิงก์ Repository ไปยัง Backup Remote และสำรองฐานข้อมูลด้วยการ Export อัตโนมัติ
3	รอบการสำรองข้อมูล (Backup Frequency)	ฐานข้อมูลสำรองทุกวันเวลา 02:00 น. และ Repository ซิงก์ทุกครั้งที่มีการส่งมอบ

ผู้จัดทำเอกสาร (Secretary)

ชื่อ	ตำแหน่ง	ลายเซ็น	วันที่
คุณอภิรัชช์ สุภัทรประทีป	Project Manager

ผู้ตรวจสอบเอกสาร (Reviewer)

ชื่อ	ตำแหน่ง	ลายเซ็น	วันที่
คุณเยาวลักษณ์ บางชมภู	Document Control

ผู้อนุมัติ (Approval)

ชื่อ	ตำแหน่ง	ลายเซ็น	วันที่
คุณเสรี วิริยะสกุลธรณ์	Project Sponsor