timeline การจัดซื้อจัดจ้าง, milestones & ระยะเวลา implementation

RFP กำหนด High Level Schedule ของวันที่ milestone "to guide the tenderers on the project timeline till the project starts" (RFP p4) โดย SCCC สงวนสิทธิ์ในการเปลี่ยนแปลงวันที่พร้อมแจ้งผู้เข้าประมูลทุกราย อย่างชัดเจน (RFP p4) — ดังนั้นกำหนดการนี้เป็นเพียงตัวบ่งชี้ ไม่ใช่ข้อผูกพันตามสัญญา

ปฏิทิน milestone การจัดซื้อจัดจ้าง (RFP p4-5)

หมายเหตุเกี่ยวกับวันที่

• สี่แถวหลัง award (Final Negotiation, Award, Kick-off, Go-live) ถูกกำกับว่า (tentative) ทั้งหมดในต้นฉบับ (RFP p5)
• Project Go-live = TBD แสดงด้วย highlight สีเหลืองบน p5 — วัน go-live ถูกเว้นเปิดไว้โดยตั้งใจ ขึ้นอยู่กับการเจรจา/scope นี่เป็น milestone เดียวที่ไม่ระบุวันที่ และผู้ขายถูกคาดหวังให้เสนอช่วงเวลา go-live เป็นส่วนหนึ่งของแผน implementation (ดู โครงสร้างข้อเสนอที่คาดหวัง & deliverables ที่ต้องส่งมอบ, section IV.f Project Timeline & Milestones)
• ขั้นตอน evaluation/presentation ระบุชัดว่าเป็นแบบ virtual ("Virtual Presentation") วันที่ 20–23 July 2026 (RFP p4) — ดูรูปแบบการนำเสนอใน กระบวนการยื่นข้อเสนอ, การประเมิน & การนำเสนอของผู้ขาย
• ช่วงเวลาทั้งหมดตั้งแต่ public tender (20 May) ถึง kick-off (24 Aug) ราว ~3 เดือน; เวลาตอบกลับตั้งแต่วันออกเอกสาร (19 May ตามหน้าปก) ถึง Tender Joining Confirmation (27 May) มีเพียง ~8 วัน

ระยะเวลา implementation & ระยะเวลา maintenance (RFP p54)

ภายใต้หัวข้อ TIMELINE RFP ระบุความคาดหวังด้านการส่งมอบไว้ตรง ๆ

"Vendor to propose solution for implementation within 4 months. Maintenance Annual Support service should be included." (RFP p54)

ดังนั้นกรอบของลูกค้าคือ implementation ภายใน ≤4 เดือน สำหรับ solution แบบ To-Be พร้อมข้อเสนอ Annual Support / maintenance รวมอยู่ในข้อเสนอ (ตัว maintenance scope และ SLA เองอยู่ใน ขอบเขต Application Maintenance, SLA & กฎ change request)

อย่างไรก็ตาม ระยะเวลา maintenance support (PERIOD) เป็นรายการที่ยังเปิดอยู่อย่างชัดเจน หัวข้อเฉพาะ "SCOPE TO BE DISCUSSED" บน RFP p54 ระบุเพียงว่า

"Maintenance service support period."

กล่าวคือ ระยะเวลาที่ maintenance/support จะครอบคลุมถูกปล่อยให้เจรจากันระหว่าง SCCC/INSEE กับผู้ขาย แม้ว่าเกณฑ์การตั้งราคาจะถูกกำหนดในภายหลังเป็นสัญญา 3 ปี เสนอราคาแบบ price/year (RFP p57; ดู เงื่อนไขเชิงพาณิชย์ — การชำระเงิน, ค่าปรับ, IP, เกณฑ์การตั้งราคา) ทั้งนี้ implementation 4 เดือนไม่ได้ยึดโยงกับ go-live ที่ยืนยันแล้ว เพราะ go-live ยังเป็น TBD (ข้างต้น)

ประเด็นคลุมเครือ / จุดที่ต้องระวัง

• implementation "within 4 months" ไม่มีจุดเริ่มต้น (start anchor) ที่ระบุไว้ (kick-off เป็น tentative 24 Aug 2026, go-live TBD) — 4 เดือนนี้เป็นระยะเวลา ไม่ใช่ข้อผูกพันแบบกำหนดวันตายตัว
• มีความตึงระหว่าง "Maintenance service support period" ที่เป็น TBD / to be discussed (RFP p54) กับคำสั่งในโครงสร้างข้อเสนอที่ให้ตั้งราคา maintenance เป็น สัญญา 3 ปี, price/year (RFP p57) เป็นจุดที่ต้องขอ clarification จากผู้ขาย — บันทึกไว้ภายใต้ เงื่อนไขเชิงพาณิชย์ — การชำระเงิน, ค่าปรับ, IP, เกณฑ์การตั้งราคา

กระบวนการยื่นข้อเสนอ, การประเมิน & การนำเสนอของผู้ขาย

ช่องทางและกำหนดการยื่นข้อเสนอ (RFP p4)

ยื่นข้อเสนอแบบอิเล็กทรอนิกส์ผ่าน Ariba System (SAP Ariba e-procurement) ช่วงเวลายื่นคือ

"between 08:00 am – 05:00 pm by 17 July 2026 (Local Thailand Time). Any proposal received after this date and time will not be considered." (RFP p4, ข้อความวันที่/เวลาพิมพ์ด้วยสีแดง)

ดังนั้น cut-off เป็นแบบเด็ดขาด — ข้อเสนอที่ยื่นช้าจะถูกปฏิเสธทันที งานนี้เป็นการประมูลแบบ pre-qualified, invitation-only: วัตถุประสงค์ของ RFP คือ "to invite all vendors that have been selected following the pre-qualification stage" (RFP p4) เฉพาะ vendor ที่ผ่าน pre-qualified เท่านั้นที่ยื่นได้

Tender Joining Confirmation (RFP p10)

ก่อนยื่นตัวข้อเสนอ ผู้เข้าประมูลต้องยืนยันการเข้าร่วมก่อน โดย Response of Invitation to Tender เป็นการตอบรับแบบ sealed-bid: ผู้เข้าประมูลรับรองว่า "this is a bona fide tender" และประสงค์ "to participate in tendering (sealed-bid) at the defined date and time" (RFP p10) ขั้นตอน

• ส่งหนังสือยืนยันที่ลงนามแล้ว ทางอีเมลถึง SARARAT.VEERARATANAWAN@SIAMCITYCEMENT.COM ภายใน 08:00 am – 05:00 pm by 27 May 2026 (Local Thailand Time) และ
• โทรหา Ms Sararat Veeraratanawan (0626388787) เพื่อยืนยันว่าได้รับเอกสาร (RFP p10)
• แบบฟอร์มยืนยันต้องมี: Signature ("Recipient of the Invitation (Sealed-Bid)"), Date, Company Name, Email Address

กำหนด 27 May 2026 นี้ตรงกับ milestone "Tender Joining Confirmation" ใน timeline การจัดซื้อจัดจ้าง, milestones & ระยะเวลา implementation

ภาระหน้าที่ของผู้เข้าประมูล & การรักษาความลับ (RFP p8)

• กฎห้ามถอนตัว (no-withdrawal): "Once the tenderer has submitted the response of the RFP, the tenderer shall not withdraw from the tendering process" — และต้องดำเนินกระบวนการ "until completion" (RFP p8, Tenderer's Roles)
• การรักษาความลับเกี่ยวกับผู้เข้าประมูล: "Name of tenderer shall not be discussed. The technical proposal and pricing proposal shall be kept confidential at all time" (RFP p8)
• สิทธิที่สงวนไว้: "Siam City Cement Public Company Limited by the Procurement Committee has the right in its sole discretion and in accordance with any reason, to decide who the successful tenderer is" (RFP p8)
• การมอบงานพิจารณาจากข้อเสนอที่ most appropriate และ SCCC ไม่ผูกพันต้องรับราคาต่ำสุด (RFP p7; ราคาต่ำสุดไม่ใช่ตัวชี้ขาด — อ้างอิงร่วม เงื่อนไขเชิงพาณิชย์ — การชำระเงิน, ค่าปรับ, IP, เกณฑ์การตั้งราคา)

ผู้ติดต่อสำหรับสอบถาม (RFP p9-10)

หมายเหตุ: เบอร์มือถือของ Ms Sararat พิมพ์ไว้สองแบบ — 062638878 (p9) เทียบกับ 0626388787 (p10) — และเบอร์มือถือของ Mr Rachata "+661 752 5208" ดูจะมีจำนวนหลักไม่ครบสำหรับเบอร์ไทย เป็นความไม่สอดคล้องเล็กน้อยในต้นฉบับ ยกธงไว้ใน ประเด็นคุณภาพเอกสาร RFP ที่ต้องยืนยัน

การนำเสนอของผู้ขาย & การประเมิน (RFP p4, p55)

การประเมินเป็น "Vendor Presentation & Evaluation" แบบ virtual กำหนด 20–23 July 2026 (RFP p4) รูปแบบตาม RFP p55

• ระยะเวลา: 1.5 – 3 ชั่วโมง "Please bring your executive to join this session with our executive." (ต้องมีผู้บริหารเข้าร่วมทั้งสองฝ่าย)
• Overview (ไม่เกิน 15 นาที): Company Profile Overview แบบสั้น; Product และ Product Roadmap รวมถึง release management ของผู้ขาย; และข้อมูล Site reference ที่เข้าเกณฑ์สองข้อ — (1) ธุรกิจคล้ายกัน เช่น Cement, Manufacturing, Construction Materials และ (2) ตั้งอยู่ในประเทศไทย — โดยเป็น reference ที่ SCCC "can visit and discuss with them on the users experience on your solution" (กล่าวคือ reference ต้องเข้าถึง/ไปเยี่ยมได้)
• Scope to be Discuss: นำเสนอ design solution architecture ให้เข้ากับ business requirement (performance, การทำงานราบรื่น, scalability); เสนอ hardware/software ที่จำเป็นสำหรับ in-house infrastructure ล่วงหน้า (ถ้าจำเป็น); demo "How it's works" และ "How it's not works" เทียบกับ business + technical requirement ของกลุ่ม SCCC แต่ละข้อ; นำเสนอ implementation approach และ timeline; และ ระบุ assumption ทั้งหมด พร้อม แจกแจง cost/effort เป็นราย item เพื่อใช้พิจารณา

ประเด็นคลุมเครือ / จุดที่ต้องระวัง

• ถ้อยคำ "Group SCCC" (RFP p55) บ่งชี้ว่า requirement อาจครอบคลุมทั้งกลุ่ม SCCC ไม่ใช่เฉพาะโรงงาน Saraburi — คำถามด้านความกว้างของ scope ติดตามใน ขอบเขตโรงงาน — เฉพาะ SRB หรือรวม Rayong และการขยายในอนาคต
• ข้อกำหนด demo ที่ให้แสดงทั้ง "how it works" และ "how it's NOT works" ถือว่าไม่ปกตินัก — ลูกค้าต้องการให้เปิดเผยขีดความสามารถ/ข้อจำกัดอย่างตรงไปตรงมาตาม requirement ไม่ใช่ demo เฉพาะ happy-path
• การแจกแจง cost/effort "by item" ถูกร้องขอทั้งในการนำเสนอ (RFP p55) และในเอกสารข้อเสนอ (RFP p56) — ดู โครงสร้างข้อเสนอที่คาดหวัง & deliverables ที่ต้องส่งมอบ

เงื่อนไขเชิงพาณิชย์ — การชำระเงิน, ค่าปรับ, IP, เกณฑ์การตั้งราคา

การชำระเงิน / Credit Term (RFP p6-7)

• Credit term: ชำระเงินให้ผู้ขาย ภายในหกสิบ (60) วันนับจากวันที่ในใบแจ้งหนี้ และ "the invoice will be paid in the next payment cycle" (RFP p6) ทั้งนี้ไม่ได้ระบุรอบ/กำหนดตัดยอด (cut-off) ของ "next payment cycle" ไว้
• Delivery Place: "Service delivery will be located at Siam City Cement Public Company Limited" (RFP p7)
• Incoterm: "Please quote the price DDP at Siam City Cement Public Company Limited" ภายใต้ INCOTERM ®2010 RULES (RFP p7) (การอ้าง DDP/Incoterm เป็นข้อความสำเร็จรูปเชิงสินค้า (goods-oriented) ที่นำมาใช้กับงานซอฟต์แวร์/บริการ ถือเป็นความไม่สอดคล้องเชิงพาณิชย์เล็กน้อย แต่นัยคือราคาที่เสนอเป็นราคาแบบรวมเบ็ดเสร็จ ส่งมอบถึง SCCC)

RFP ไม่มีผลผูกพัน & เกณฑ์การตัดสินมอบงาน (RFP p7)

• RFP ฉบับนี้ ไม่ผูกพัน (non-binding) ต่อ SCCC "in all respects" โดย SCCC "reserves the right to withdraw, amend or alter this Request for Proposal at any time without advance notice and without any obligation" (RFP p7)
• Cost of proposal: ผู้ขายเป็นผู้รับผิดชอบค่าใช้จ่ายในการจัดทำข้อเสนอ เองทั้งหมด SCCC ไม่รับภาระค่าจัดเตรียม/ค่ายื่นข้อเสนอใด ๆ (RFP p7)
• The Award: SCCC "will award the proposal deemed most appropriate and shall not be bound to accept the lowest price proposal" (RFP p7; ย้ำอีกครั้งที่ p5: "The lowest price shall not be considered for this circumstance")
• กฎหมายที่ใช้บังคับ: กฎหมายไทย และ ศาลไทยมีเขตอำนาจแต่เพียงผู้เดียว (exclusive jurisdiction) ในข้อพิพาท (RFP p7)

โครงสร้างค่าปรับ (RFP p5)

แบ่งเป็นค่าปรับ 2 ลักษณะ

1. ไม่เข้าทำสัญญาตามกำหนด: หากผู้ชนะการคัดเลือกไม่มาเข้าทำสัญญาภายในระยะเวลาที่กำหนด จน INDG (INSEE Digital) ต้องไปจัดหาผู้ขายรายอื่นในต้นทุนที่สูงกว่า ผู้ชนะรายเดิม ต้องรับผิดชอบส่วนต่างของต้นทุนทั้งหมด โดยชดเชย/ชำระให้ SCCC ภายใน 30 วัน นับจากที่ SCCC แจ้ง (RFP p5)
2. ส่งมอบงานล่าช้า: "The penalty is calculated at 5% of the value of the delayed deliverables per day; however, the total penalty shall not be higher than the total value of the signed contract." (RFP p5)

(แยกต่างหากจาก Liquidated Damages ของช่วง maintenance ซึ่งคิดแบบเครดิต (credit-based) และเป็นเปอร์เซ็นต์ของค่าบริการรายเดือน — ดู ขอบเขต Application Maintenance, SLA & กฎ change request)

การรักษาความลับ & ทรัพย์สินทางปัญญา (RFP p8)

• การรักษาความลับแบบสองทาง (mutual confidentiality) ของเงื่อนไข/ข้อมูลในสัญญา โดยมีข้อยกเว้น 3 กรณี: (1) การเปิดเผยเท่าที่จำเป็นต่อบุคลากร/ตัวแทน/sub-supplier/sub-contractor/ที่ปรึกษา เพื่อปฏิบัติตามภาระผูกพัน; (2) การเปิดเผยตามที่กฎหมาย/ศาล/หน่วยงานรัฐบังคับ; (3) ข้อมูลที่อยู่ในที่สาธารณะอยู่แล้ว (public domain) (RFP p8)
• IP licence (RFP p8): "The Supplier hereby grants Siam City Cement Public Company Limited a perpetual, irrevocable and royalty-free license to use the Supplier's intellectual property right associated with Product and/or Service."
• ข้อนี้ประกอบเข้ากับข้อกำหนดเรื่อง ความเป็นเจ้าของ IP/source code ของงาน custom development ในส่วนอื่นของ RFP (Source Code & IP ของงาน custom development เป็นของ INDG / INSEE Digital, GitHub, no-code config) ซึ่งบันทึกไว้ใน Source code, IP ownership, GitHub และ no-code config ผลสุทธิคือ SCCC ได้สิทธิแบบกว้างและเป็นทางเดียวทั้งต่อ background IP ของผู้ขาย (perpetual licence) และต่อ deliverables ที่พัฒนาขึ้นใหม่ (ความเป็นเจ้าของ)

เกณฑ์การตั้งราคา (RFP p54, p57)

• งาน implementation ตั้งราคาเป็น deliverable ของโครงการ (proposal section X "Implementation Pricing", RFP p56 — ดู โครงสร้างข้อเสนอที่คาดหวัง & deliverables ที่ต้องส่งมอบ)
• Maintenance Support Pricing ต้องเสนอราคาเป็น สัญญา 3 ปี ตามคำสั่ง "please quote in price/year" (RFP p57, proposal section XI.f) ทั้งนี้มีจุดขัดแย้งกับ ระยะเวลา maintenance support ที่ยังเป็น "to be discussed" (RFP p54) — ดู timeline การจัดซื้อจัดจ้าง, milestones & ระยะเวลา implementation
• ผู้ขายต้องแจกแจง cost และ effort เป็นราย item (RFP p55-56) พร้อมจัดทำ rate card + detailed man-day estimation (RFP p56)

ประเด็นคลุมเครือ / จุดที่ต้องระวัง

• ตาม meeting minutes (MIN) ผู้ขายต้อง ตั้งราคารวมงาน customisation ของ API และ DAS ไว้ในข้อเสนอ และงาน integration อาจมี ต้นทุนที่คาดไม่ถึง (unforeseen cost) ส่วนเรื่องความเป็นเจ้าของ/สัญญา/ต้นทุนของ integration ฝั่ง DAS ยังไม่ได้ข้อยุติ — ติดตามใน ความเป็นเจ้าของ สัญญา และค่าใช้จ่ายของการ integrate ระบบกับ DAS / platform
• เวลาของ "Next payment cycle" เทียบกับเงื่อนไข 60 วัน ยังไม่ได้นิยามไว้ (RFP p6)
• ขอบเขต supplier-IP licence แบบ "perpetual, irrevocable, royalty-free" (RFP p8) มีนัยสำคัญเชิงพาณิชย์และเอนไปทาง SCCC ฝ่ายเดียว — ควรยกเป็นประเด็นให้ฝ่ายกฎหมาย/พาณิชย์ทบทวน

ขอบเขต Application Maintenance, SLA & กฎ change request

กรอบหลักที่กำกับ (RFP p46)

Maintenance Agreement (MA) ยึดโยงกับ Information Technology Management Policy ("IT Management Policy") และ INSEE Minimum Control (IMC) ของกลุ่ม Siam City Cement — "binding Group-wide and in compliance with regulatory requirements" (RFP p46) โดย maintenance จัดซื้อควบคู่ไปกับ implementation ("Maintenance Annual Support service should be included", RFP p54 — ดู timeline การจัดซื้อจัดจ้าง, milestones & ระยะเวลา implementation)

Maintenance Agreement Scope of Work (RFP p46-49)

SOW เป็น compliance checklist ที่ผู้ขายต้องตอบ (F/P/N + remarks) ภาระหน้าที่หลัก

• (a) จัดตั้งโครงสร้าง application support ที่ชัดเจน ระบุ contact person, ข้อมูลติดต่อ และช่องทางติดต่อ
• (b) จัดการงาน fix/change/enhance ผ่าน INDG Service Now (SNOW) ในฐานะเครื่องมือแบบ ticket + การสื่อสาร ครอบคลุม Service Request, Incident Management, Problem Management, Change Management, Release Management ทีม support ของผู้ขาย ต้องเข้าอบรม ITSM และ SNOW (RFP p46) (SNOW เป็น ITSM toolset ที่บังคับใช้ — อ้างอิงร่วม IT compliance, minimum controls, RACI & ข้อกำหนดด้าน project management)
• (c) Application Maintenance Support ครอบคลุม day-to-day operation support; ปฏิบัติตามกระบวนการ INDG ITSM (Service Request / Incident / Problem / Change / Release); ดูแลให้ application, service และ database พร้อมใช้งานอยู่เสมอ; response & resolution ของ ticket ตาม priority; สืบหาและกำหนด permanent solutions; back up ข้อมูลของ site รายเดือน; ให้ technical support เพื่อ reconfigure/ยืนยันว่าแอปทำงานได้หลัง restore; และ สนับสนุนการทดสอบ restore backup ประจำปี ให้สอดคล้องกับ IT Minimum Control (RFP p46-47)
• (d) จัดทำ monthly statistic report ด้านการใช้งานและ performance ของแอปพลิเคชัน (RFP p47)
• (e) สนับสนุนงาน preventive/corrective maintenance โดยต้องได้รับ approval จาก Customer ก่อนลงมือทำ (RFP p47)
• (f) ให้ support/troubleshooting ของ application, database และ hardware device (ถ้ามี) (RFP p47)
• (g) จัดหา solution ที่เหมาะสมสำหรับปัญหาซอฟต์แวร์ที่เกิดจากเวอร์ชันโปรแกรมปัจจุบัน หรือจัดหา feature ใหม่ (RFP p47)
• (h) ดูแล application environment, DB, software libraries, HW firmware และ infra ให้อยู่ใน เวอร์ชันล่าสุด (up-to-date); ดูแล application roadmap และวางแผน/ดำเนินการ version upgrade (RFP p47) การแบ่งความรับผิดชอบ OS-hosting: OS ของ server ใน Regional Data Center (RDC) ดูแลโดย INDG (ผู้ขายยืนยันความ compatible บน OS ใหม่); OS ของ server นอก RDC ผู้ขายดูแลเต็มรูปแบบ รวมถึงการ upgrade เวอร์ชัน OS (RFP p48)
• (i) Patch management & แก้ช่องโหว่ security/vulnerability: ผู้ขาย apply patch ให้ application, database และ HW firmware; สำหรับ RDC OS patch นั้น INDG เป็นผู้จัดการ แต่ผู้ขายต้องยืนยันก่อน patch และตรวจสอบว่าแอปทำงานปกติหลัง patch; OS patch นอก RDC ผู้ขายดูแลเต็มรูปแบบ; ยืนยันความ compatible ของ patch; แก้ Vulnerability GAP เมื่อเกิดขึ้น (RFP p48)
• (j) แก้ปัญหา security พื้นฐานตามคำแนะนำ/guideline ของ INDG (RFP p48) (อ้างอิงร่วม Application security (encryption, VA/PT, VAPT, SSL, IMC04))
• (k) ทบทวน & อัปเดตเอกสาร operation ที่เกี่ยวข้องทั้งหมดเป็น รายไตรมาส (quarterly): BAU documents, Functional documents, Technical documents, FAT/SIT/UAT results, Access-control process/procedure/documents (RFP p48)
• (l) จัด operation meeting รายสัปดาห์หรือรายเดือน กับ INDG ครอบคลุม: action items จากครั้งก่อน, Open Incident / RITM created, Ticket SLA, Ticket aging, Ticket resolution, Customer Satisfaction (CSAT), Project / CR status, Leave plan (RFP p49)
• งาน maintenance ต้อง รวมงาน change request ที่ใช้ effort ≤ 3 man-days (RFP p49) บวกกับช่องเปิด "other topic to be added for MA scope (if needed)"

Service Level Agreement — Option 1: Critical Application SLA (RFP p50)

การดำเนินธุรกิจเป็นแบบ 24 ชั่วโมง / 7 วัน flow การรับเรื่อง: user อีเมลถึง super user → super user raise ticket ใน Service Now → ผู้ขายเข้าถึง & ตอบกลับผ่าน Service Now (RFP p50)

นิยามความรุนแรง (RFP p50): P1 = ผลกระทบระดับวิกฤตที่ทำให้ความสามารถในการขาย/ส่งมอบสินค้า, รับ/ออกการชำระเงิน, หรือส่ง mandatory report เสียไป; P2 = ระบบใช้งานไม่ได้/มีปัญหา performance ที่ยังไม่ทำให้ความสามารถหลักข้างต้นเสียไป แต่อาจกลายเป็นวิกฤตหากไม่แก้ทันที; P3 = ผลกระทบทางธุรกิจต่ำ (SR = Service Request, CR = Change Request ใช้ tier เดียวกับ P4)

Liquidated Damages สำหรับ non-performance (เครดิตที่หักจาก Support Service Fees, RFP p50)

• P1: credit = 10% of the monthly Service Fee ของ System ที่เกี่ยวข้อง หากผู้ขายเกิน Expected Resolution Time
• P2 & P3: credit = 5% of the monthly Service Fee ของ System ที่เกี่ยวข้อง หากผู้ขายเกิน Expected Resolution Time
• ไม่มีการระบุตัวเลข LD สำหรับ P4 / SR / CR [ช่องว่างในต้นฉบับ — ยกธงไว้ด้านล่าง]

กฎ Change Request (RFP p51)

• "Man-Day" = 8 full working hours ซึ่ง INDG ใช้ได้แบบเศษส่วน (fractional)
• งาน enhancement ที่ใช้ มากกว่า 3 Man-Days = "Major Change": ต้องทำ approval process ให้เสร็จก่อนลงมือทำ และดำเนินการออก PR/PO แยกต่างหาก
• งาน enhancement ที่ใช้ 3 Man-Days หรือน้อยกว่า ไม่ถือเป็น Major Change และไม่ต้องผ่าน Change Request (อยู่ในขอบเขต MA ตาม RFP p49)
• INDG เป็นผู้ ตัดสินและอนุมัติขั้นสุดท้าย (finally determines and authorizes) ว่าจัดสรร man-days เท่าใด และงานเข้าข่ายเป็น enhancement หรือไม่

(วินัยด้าน release management — "no automatic release upgrade", การสื่อสารล่วงหน้าถึง SCCC — มีรายละเอียดใน การ upgrade แอปพลิเคชันและ release management)

ประเด็นคลุมเครือ / จุดที่ต้องระวัง

• Table of Contents ของ RFP ระบุ "Option 2: Non-Critical Application SLA" ไว้ แต่ page reference เสีย ("Error! Bookmark not defined.") และไม่พบ section นี้ในลำดับหน้า — ดูเหมือน Option 2 SLA จะหายไป จากเอกสาร เป็นจุดที่ต้องขอ clarification จากผู้ขาย ติดตามใน ประเด็นคุณภาพเอกสาร RFP ที่ต้องยืนยัน
• ไม่มีเปอร์เซ็นต์ Liquidated-Damages สำหรับการผิดเงื่อนไข P4/SR/CR (RFP p50) — ระบุไว้เฉพาะ P1 (10%) และ P2/P3 (5%)
• การใส่ตัวอักษรลำดับในรายการ SOW ภายในต้นฉบับไม่สม่ำเสมอ (แถวมีการ re-letter และซ้อนทับกันข้าม p46-49) — เป็นปัญหาด้านคุณภาพเอกสาร เนื้อหาด้านบนถอดความไว้ตามต้นฉบับอย่างซื่อตรง

IT compliance, minimum controls, RACI & ข้อกำหนดด้าน project management

นโยบายและแนวปฏิบัติที่มีผลผูกพัน (RFP p40-41)

ทุกอย่างอยู่ภายใต้ SCCC Group IT Management Policy ("Information Technology Management Policy") ร่วมกับ INSEE Minimum Control (IMC) ซึ่ง "binding Group-wide without exception and in compliance with regulatory requirements" (RFP p40-41)

มีแนวปฏิบัติที่มีผลผูกพันแนบมากับ RFP เป็นไฟล์ PDF 2 ฉบับ และผู้ขายต้อง ยื่นหนังสือรับรองการปฏิบัติตาม (compliance letter) อย่างเป็นทางการพร้อมกับข้อเสนอ เพื่อยืนยันว่าปฏิบัติตามครบถ้วน (RFP p40)

1. INSEE Digital Project Application Development Guideline
2. INSEE Digital Project Infrastructure and Security Guideline

แนวปฏิบัติทั้งสองฉบับนี้เป็นชุดเดียวกับที่ถูกอ้างอิงในแถว NFR ของ Application Security (req. 26) และ User Access Management (req. 33) — ดู Application security (encryption, VA/PT, VAPT, SSL, IMC04) และ การจัดการสิทธิ์ผู้ใช้ RBAC และ SSO ทั้งนี้เนื้อหา PDF จริงไม่ได้อยู่ในตัว RFP (เป็น attachment ฝังไว้เท่านั้น) — ดู เอกสารต้นทางสำคัญที่ถูกอ้างถึงแต่ยังไม่มีในมือ

INSEE Minimum Control (IMC) checklist (RFP p41-46)

มี 3 control domain แต่ละ domain เป็น compliance checklist (F/P/N + vendor remarks)

1. Access control to IT systems (RFP p42): กำหนดสิทธิ์เข้าถึงของ business user (new/change/removal) พร้อม approval flow ที่เหมาะสม; การจัดการสิทธิ์ทำได้ แบบ manual, ผ่าน Windows Active Directory (AD), หรือผ่าน SAP GRC (สำหรับ SAP สาย ABAP); แอปพลิเคชันต้องมี User Access Log ที่บันทึก User Creation / Deletion / Role Change; และระบบต้อง log & จัดการ privilege access (business admin, technical admin, emergency role) จำกัดเฉพาะผู้ได้รับอนุญาตบน production (อ้างอิงร่วม การจัดการสิทธิ์ผู้ใช้ RBAC และ SSO)

2. Data backup & restoration (RFP p43-44): กลยุทธ์ backup ขึ้นอยู่กับรูปแบบ hosting

• Regional Data Center (RDC): ใช้ centralized backup library; ทำ full backup รายวัน; verify รายวัน; retention ≥ 28 days, เก็บ tapes offsite
• Local on-premises: ดูแลโดย Local Infrastructure Team; ทำรายวันแบบ daily differential เป็นอย่างน้อย; verify รายวัน; retention ≥ 21 days, เก็บ tapes offsite
• Cloud / IaaS: ใช้ Cloud Provider Native Backup Service; full backup รายวัน; verify รายวัน; retention ≥ 28 days (กฎ offsite-tape ไม่ใช้กับ cloud)
• Restoration tests: ทำปีละครั้ง (annually) สำหรับทั้งสามรูปแบบ hosting (RDC โดย Datacenter backup admin ตามปฏิทินที่ประกาศ; on-prem โดย Local Infrastructure Team อย่างน้อยปีละครั้ง; Cloud ผ่าน Native Backup Service ตามปฏิทินที่ประกาศ)

3. IT security (RFP p45-46): ทบทวน security config (password policy, ระยะเวลา log-in/out) ทั้งระดับ application/OS/DB; บังคับทำ VA + PT ก่อน Go Live; Vulnerability Assessment (VA) อย่างน้อยเดือนละครั้ง; Penetration Test (PT) อย่างน้อยปีละสองครั้ง (ทุก 6 เดือน); database ต้องเป็นเวอร์ชันที่ OEM-supported; OS patch สม่ำเสมอ; antivirus อัปเดตอัตโนมัติ เว้นแต่ OEM แนะนำเป็นอย่างอื่น (รายละเอียดใน Application security (encryption, VA/PT, VAPT, SSL, IMC04))

RACI matrices (RFP p51-52)

มี RACI matrix 2 ชุด ที่ map กิจกรรมข้าม 5 บทบาท: Business User, INDG, Partner Team Lead, Partner Team Member, 3rd-Level Support (if applicable) ("Partner" = ทีมของผู้ขายที่ได้รับงาน; matrix ใช้เครื่องหมาย "X" แทนการมีส่วนร่วม แทนที่จะระบุตัวอักษร R/A/C/I อย่างชัดเจน)

• Operation Support (RFP p51): ครอบคลุม raise incident/SR & access approval, incident/SR/change management, access control, response & resolution, resolution confirmation, standard-change approval/implementation, FAT/SIT execution & approval, UAT & sign-off, production deployment approval, Post-Implementation Review (PIR), SLA compliance, SLA monitoring & management
• New Business requirement (RFP p52): ครอบคลุม idea/demand submission & budget approval, demand management & approval, technical assessment/effort estimation, functional spec identification/review, build/development/coding, quality monitoring, FAT/SIT execution & approval, UAT & sign-off, production deployment approval & execution, PIR, demand closed & approval

การจัดสรรบทบาทที่น่าสังเกต: Business User เป็นเจ้าของ idea/demand submission, UAT sign-off และการ raise incident/SR & resolution confirmation; INDG เป็นเจ้าของ demand approval และ production-deployment approval; ทีม Partner (ผู้ขาย) เป็นผู้นำ/ดำเนินการ assessment, build, testing และส่งมอบตาม SLA

ข้อกำหนดด้าน Project Management (RFP p53-54)

ผู้ขายที่ได้รับงานต้องปฏิบัติตาม PMO Governance และ มาตรฐาน & คุณภาพด้าน project management ของ INDG (RFP p53) เอกสาร PM ที่ต้องส่งมอบ (เป็น deliverable และมีบางส่วนที่ผูกกับ payment gating ตามที่ระบุ)

1. Kick-off presentation — ใช้ในวันแรก ครอบคลุม project background/objective/scope, assumptions, implementation timeline, project organization รวมถึง RACI, roles & responsibilities, deliverables, governance, project folder, key success factors
2. Project Detail Plan — แผนอย่างเป็นทางการเพื่อควบคุมและดำเนินโครงการ
3. Project Status Update — รายงานความคืบหน้าอย่างเป็นทางการ รายสัปดาห์ เทียบ baseline (actual vs plan, key achievements, approaching activities, risks & mitigation, issues)
4. Requirements Traceability Matrix (RTM) & Fit-Gap Analysis — ระบุว่า requirement/process ใด fit หรือ gap ในกระบวนการ To-Be พร้อมแนวทางแก้ที่สอดคล้อง (Manual, Object Development List, Work-around, Legacy app)
5. Project Closure Document — sign-off อย่างเป็นทางการ ก่อน final payment milestone (background & objective, project scope, outcome & benefit realization, After Action Review, closure checklist + ตำแหน่ง share-folder) (การผูกกับ payment — อ้างอิงร่วม เงื่อนไขเชิงพาณิชย์ — การชำระเงิน, ค่าปรับ, IP, เกณฑ์การตั้งราคา)

เครื่องมือ Project Management ที่บังคับใช้: SharePoint (เป็น repository เก็บเอกสารโครงการ) (RFP p54)

ประเด็นคลุมเครือ / จุดที่ต้องระวัง

• legend ของ "F/P/N" / "F/P/N/NA" ไม่ได้ระบุความหมายไว้ในเอกสาร (อนุมานเป็น Full/Partial/None[/Not-Applicable]); และสเกลก็ไม่สม่ำเสมอ (3 ระดับใน p40/p42 เทียบกับ 4 ระดับใน NFR matrix) — ความไม่สอดคล้องเล็กน้อย ดู ประเด็นคุณภาพเอกสาร RFP ที่ต้องยืนยัน
• เกณฑ์ backup/restoration ของ IMC (≥28d / ≥21d, annual restore tests) ขึ้นอยู่กับรูปแบบ hosting ที่เลือก — เชื่อมโยงกับ สถาปัตยกรรมโซลูชัน การ hosting และ landscape
• การควบคุมด้าน implementation/testing (IMC01 FAT/SIT/UAT, migration, cut-over, training) อยู่ในส่วน NFR — บันทึกไว้ใน Implementation, testing, migration, cut-over และ training

โครงสร้างข้อเสนอที่คาดหวัง & deliverables ที่ต้องส่งมอบ

โครงสร้างข้อเสนอที่คาดหวัง — Section III (RFP p56-57)

RFP กำหนดโครงร่างข้อเสนอเป็น 12 ส่วน (เลขโรมัน I–XII) ข้อความในวงเล็บตัวเอียงในต้นฉบับเป็นคำสั่งถึงผู้ยื่นข้อเสนอ

• I. Introduction
• II. Project Description
• III. Project Assumption — ผู้ขายระบุ assumption ทั้งหมดที่เกี่ยวกับข้อเสนอ และวิธีประเมิน effort ซึ่งสามารถ แจกแจง (cost และ effort) เป็นราย item เพื่อใช้พิจารณา
• IV. Project Scope and Requirement
  • a. Project Approach — i. Project Management Approach; ii. Implementation Approach; iii. Testing Approach; iv. Training Approach
  • b. Overall Project Scope
  • c. Detailed Project Scope
  • d. Out of Scope
  • e. Business Flow & Solution Architecture — solution architecture ที่ออกแบบให้รองรับ business requirement พร้อมข้อเสนอแนะด้าน performance ตามมาตรฐาน, การทำงานราบรื่น และ scalability
  • f. Project Timeline & Milestones
  • g. Project Keys Activities
• V. Project Resources
  • a. Resources Approach
  • b. Project Organization Structure
  • c. Roles and Responsibilities — ทีมงานต้องประกอบด้วย Project Management, SME, Functional Consultants, Technical Consultants ฯลฯ รวมถึง certified resources ที่เกี่ยวข้องกับโครงการ
  • d. Detail Man-days estimation — แจกแจงตามทีมงานและกิจกรรมของโครงการ
  • e. Rate card
• VI. Project Governance Model — ต้องรวม Change Request Management Approach
• VII. List of Deliverable and Documentation — นอกเหนือจาก deliverable มาตรฐาน ต้องรวม user manual / work procedure & instruction
• VIII. Authorization and User Management
• IX. Post Implementation Support — a. Timeline; b. Support Model, Approach and Structure; c. Warranty Period
• X. Implementation Pricing
• XI. Application Maintenance Support (if needed) — a. Maintenance Support Scope; b. Support Model/Approach/Structure; c. MA Man-days; d. Rate Card; e. Service Level Agreement (SLA); f. Maintenance Support Pricing (3-year contract, please quote in price/year)
• XII. Appendix — a. Glossary

(Section X Implementation Pricing + Section XI Maintenance pricing เป็นแกนหลักเชิงพาณิชย์ — อ้างอิงร่วม เงื่อนไขเชิงพาณิชย์ — การชำระเงิน, ค่าปรับ, IP, เกณฑ์การตั้งราคา ส่วน MA scope/SLA ที่อยู่เบื้องหลัง XI มีรายละเอียดใน ขอบเขต Application Maintenance, SLA & กฎ change request; แนวทาง testing/training/migration ภายใต้ IV.a/IX อยู่ใน Implementation, testing, migration, cut-over และ training)

deliverables ด้าน project management ที่ต้องส่งมอบ (RFP p53-54)

นอกเหนือจากตัวเอกสารข้อเสนอ ผู้ขายที่ได้รับงานต้องส่งมอบ artefact ด้าน PM ตามที่กำหนดไว้ใน Project Management Requirements ได้แก่ Kick-off presentation, Project Detail Plan, weekly Project Status Update, Requirements Traceability Matrix (RTM) + Fit-Gap Analysis, และ Project Closure Document (โดยตัวหลังเป็น sign-off ที่ gate final payment milestone) เครื่องมือ PM = SharePoint รายการเหล่านี้แจกแจงไว้ใน IT compliance, minimum controls, RACI & ข้อกำหนดด้าน project management

ข้อกำหนดการแจกแจง cost/effort (RFP p55-56)

เป็นคำสั่งที่ปรากฏซ้ำทั้งในเอกสารข้อเสนอ (RFP p56, section III) และในการนำเสนอของผู้ขาย (RFP p55): ผู้ขายต้อง ระบุ assumption ทั้งหมดและแจกแจง cost และ effort เป็นราย item เพื่อใช้พิจารณา — พร้อมจัดทำ rate card (V.e, XI.d) และ detailed man-day estimation (V.d) ดู กระบวนการยื่นข้อเสนอ, การประเมิน & การนำเสนอของผู้ขาย

RFP Appendix — Section IV (RFP p58)

ตัว RFP เองมีไฟล์อ้างอิงฝังมา 3 ไฟล์ (รายละเอียดเชิงเนื้อหาอยู่ในไฟล์เหล่านี้ ไม่ใช่ในตัว RFP)

1. Master of Service Agreement — เทมเพลต Word, caption "Template_INDG Master Service Agree…" (MSA template)
2. Workflow — "210922_Conceptual Flow.pdf" (conceptual process flow, ไฟล์ลงวันที่ 2021-09-22)
3. Excel for Business and Interface Requirement — แพ็กเกจฝัง "20211004_RFP" (รายการ business + interface requirement แบบละเอียด, ไฟล์ลงวันที่ 2021-10-04)

attachment ทั้งสามนี้เป็น input สำคัญที่ผู้ขายต้องหามา/เปิดอ่าน เนื้อหา ไม่สามารถดึงออกมาจากหน้า RFP ที่ render ได้ และ date prefix ในชื่อไฟล์ (2021) มาก่อนวันออก RFP (19 May 2026) ราว 4.5 ปี — อาจเป็น artifact เก่า/ที่นำกลับมาใช้ซ้ำ ติดตามใน เอกสารต้นทางสำคัญที่ถูกอ้างถึงแต่ยังไม่มีในมือ

ประเด็นคลุมเครือ / จุดที่ต้องระวัง

• มีแนวคิด "Appendix" สองอย่างที่ต่างกัน: proposal-structure "XII. Appendix > a. Glossary" (RFP p57, เป็น deliverable ของผู้ขาย) เทียบกับ "IV. APPENDIX" ของตัว RFP เอง (RFP p58, ไฟล์แนบ) — อย่าสับสนปนกัน
• ส่วน Application Maintenance Support เป็นแบบมีเงื่อนไข — "(if needed)" (RFP p57) — แต่ขณะเดียวกันก็ระบุว่า maintenance "should be included" (RFP p54) ผู้ขายควรถือว่า maintenance pricing เป็นสิ่งที่คาดหวัง ส่วนระยะเวลายัง TBD (ดู timeline การจัดซื้อจัดจ้าง, milestones & ระยะเวลา implementation)
• มี artefact ด้านคุณภาพเอกสารในหน้าเหล่านี้ (footer "SMART SILO" บน p56 เทียบกับ "INSEE Driver Mobile" บน p57-58; วงเล็บไม่สมมาตรในข้อ III) — ดู ประเด็นคุณภาพเอกสาร RFP ที่ต้องยืนยัน