KPI 2569 — รายละเอียดผลงานสำหรับกรอกแบบประเมิน

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

สรุปตัวเลขของปี: 14 service · 428 API endpoint (พัฒนาด้วยตนเอง 116 เส้น) · การปล่อยระบบติดตามการทำงานพร้อมกัน 10 repository · 11 แผนงานความปลอดภัย · 8 มาตรฐานความปลอดภัย · ลดค่าใช้จ่ายระบบคลาวด์ประมาณ $154 ต่อเดือน

1. B-Ready Foundation (Super APP)

การพัฒนาแพลตฟอร์ม Super App ขึ้นใหม่ทั้งระบบบนสถาปัตยกรรมแบบ Microservice และ Micro-frontend เพื่อรองรับการขยายบริการของธนาคารในระยะยาว โดยมีขอบเขตดังนี้

• การพัฒนาระบบด้วยมาตรฐานเดียวกันทุก Service ด้วย Clean Architecture 4 ชั้น เพื่อให้ทีมพัฒนาเข้าใจโครงสร้างงานของกันและกันได้ทันที และลดความเสี่ยงเมื่อมีการเปลี่ยนผู้รับผิดชอบ
• การพัฒนา Service Template กลางและ Library กลาง (NuGet Package ภายในองค์กร) เพื่อนำไปต่อยอดสำหรับการสร้าง Service ใหม่ได้ทันที และลดระยะเวลาในการ Implement
• การจัดทำ Sentinel Gateway เป็นประตูเข้าออกระบบเพียงจุดเดียว ทำหน้าที่ขอ เก็บ และต่ออายุ Token แทนทุกบริการ เพื่อรวมศูนย์การควบคุมความปลอดภัยไว้ที่เดียว แทนการให้แต่ละบริการจัดการเอง
• การจัดเก็บ Token ไว้ฝั่งเซิร์ฟเวอร์ (Server-Side Token Store) บน Redis โดยเบราว์เซอร์ของผู้ใช้ถือเพียงตัวชี้ Session ที่ไม่มีข้อมูลลับ เพื่อลดความเสี่ยงจากการถูกขโมยข้อมูลผ่านฝั่งผู้ใช้
• การพัฒนา API Facade บน Azure API Management แปลง Session ของผู้ใช้เป็น Token ให้บริการปลายทางโดยอัตโนมัติ เพื่อให้ระบบหน้าบ้านไม่ต้องรับรู้ข้อมูลลับใด ๆ
• การเชื่อมต่อระบบยืนยันตัวตนกลาง Microsoft Entra ID จำนวน 2 Tenant สำหรับพนักงาน (Workforce) และลูกค้า (CIAM) รองรับทั้งการเข้าสู่ระบบแบบ OIDC และการยืนยันตัวตนด้วยรหัส OTP ทางอีเมล เพื่อให้ผู้ใช้ทุกกลุ่มเข้าถึงบริการได้ด้วยมาตรฐานความปลอดภัยเดียวกัน
• การพัฒนาระบบบริหารสิทธิ์การใช้งานที่มีผลทันที ผ่าน Middleware กลางที่อ่านข้อมูลผู้ใช้จากหน่วยความจำแคชพร้อมกลไกสำรอง เพื่อให้การเปลี่ยนแปลงสิทธิ์มีผลโดยผู้ใช้ไม่ต้องเข้าสู่ระบบใหม่ และรองรับการเพิกถอนสิทธิ์ได้ทันทีตามหลักการควบคุมภายใน
• การพัฒนาระบบแจ้งเตือนกลางของแพลตฟอร์ม รองรับการแจ้งเตือนในแอปพลิเคชัน อีเมล และแบบทันทีผ่าน SignalR รวมถึงการประกาศข่าวสารจากหลังบ้าน เพื่อให้ทุกบริการใช้ช่องทางแจ้งเตือนร่วมกันโดยไม่ต้องพัฒนาซ้ำ
• การจัดทำระบบติดตามการทำงานของแอปพลิเคชัน (Observability) ครบ 10 Repository ในรอบเดียว ด้วยมาตรฐาน OpenTelemetry เชื่อมกับ Grafana และ Tempo เพื่อให้สืบค้นสาเหตุของปัญหาข้ามบริการได้ภายในเวลาอันสั้น และลดเวลาที่ระบบหยุดให้บริการ
• การจัดทำกระบวนการส่งมอบซอฟต์แวร์อัตโนมัติ (CI/CD) และการบริหารการติดตั้งด้วย GitOps ผ่าน ArgoCD ที่ติดตั้งและดูแลเอง เพื่อให้การนำระบบขึ้นใช้งานมีขั้นตอนที่ตรวจสอบย้อนหลังได้และลดความผิดพลาดจากการดำเนินการด้วยมือ
• การจัดตั้งสภาพแวดล้อมทดสอบระบบ (SIT) แยกจากสภาพแวดล้อมพัฒนาโดยสมบูรณ์ ทั้งฐานข้อมูล หน่วยความจำแคช ตู้เก็บกุญแจ และการลงทะเบียนแอปพลิเคชัน เพื่อให้ผลการทดสอบเชื่อถือได้และไม่กระทบงานพัฒนา
• การพัฒนาระบบระงับและปลดระงับบริษัทตามรายชื่อ AMLO ครอบคลุมหลายบริการ พร้อมหน้าจอสำหรับเจ้าหน้าที่ปลดระงับและการแจ้งเตือนผู้ใช้ที่ได้รับผลกระทบแบบทันที เพื่อให้ธนาคารปฏิบัติตามข้อกำหนดด้านการป้องกันและปราบปรามการฟอกเงินได้ครบถ้วน

ปริมาณงานที่ส่งมอบ — จำนวน API รายบริการ

API ที่พัฒนาด้วยตนเอง 116 เส้น อยู่ในส่วนที่เป็นแกนหลักของระบบทั้งหมด ได้แก่ Gateway ทั้งบริการ ระบบสมัครใช้บริการ และการจัดการผู้ใช้ บริษัท และสิทธิ์ · ส่วนที่เหลืออีก 312 เส้น พัฒนาโดยทีมงานบน Service Template, Library กลาง และมาตรฐานความปลอดภัยที่ออกแบบและกำกับดูแลเอง ทำให้ API ทั้ง 428 เส้นอยู่ภายใต้มาตรฐานเดียวกันทั้งการยืนยันตัวตน การกำหนดสิทธิ์ การบันทึกการใช้งาน และมาตรการความปลอดภัยตามข้อ 4

2. POC การใช้งาน Cloud Platform

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

• การเปรียบเทียบระบบยืนยันตัวตนกลาง 3 ผลิตภัณฑ์ ได้แก่ Duende IdentityServer4, OpenIddict และ Microsoft Entra ID เพื่อเลือกเทคโนโลยีที่รองรับมาตรฐานสากลและสอดคล้องกับสถาปัตยกรรมองค์กร — ผลการศึกษานำไปสู่การเลือกใช้ Microsoft Entra ID ทั้งฝั่งพนักงานและฝั่งลูกค้า
• การทดสอบการเชื่อมต่อระหว่างแอปพลิเคชันหลักกับแอปพลิเคชันย่อยผ่านระบบยืนยันตัวตนกลาง เพื่อกำหนดรูปแบบการส่งต่อสิทธิ์ที่ใช้เป็นมาตรฐานของแพลตฟอร์ม
• การทดสอบการยืนยันตัวตนข้ามโดเมน สำหรับแอปพลิเคชันย่อยที่ไม่ได้อยู่ภายใต้โดเมนของธนาคาร เพื่อรองรับการนำระบบของหน่วยงานภายนอกเข้ามาให้บริการบนแพลตฟอร์มเดียวกัน
• การทดสอบการสมัครและยืนยันตัวตนแบบไม่ใช้รหัสผ่าน ด้วย Native Authentication และรหัส OTP ทางอีเมล เพื่อลดความเสี่ยงจากการบริหารจัดการรหัสผ่านและเพิ่มความสะดวกให้ลูกค้า
• การทดสอบการผูกอุปกรณ์ด้วย Passkey ตามมาตรฐาน WebAuthn เพื่อเตรียมรองรับการยืนยันตัวตนที่ปลอดภัยสูงในระยะถัดไป
• การทดสอบการเข้าสู่ระบบครั้งเดียว (Single Sign-On) ระหว่างแพลตฟอร์มใหม่กับระบบงานเดิม เพื่อกำหนดแนวทางนำระบบเดิมเข้ามาให้บริการภายใต้ Super App โดยไม่ต้องพัฒนาระบบใหม่ทั้งหมด
• การทดสอบรูปแบบการจัดเก็บ Session และ Token เปรียบเทียบระหว่างการเก็บที่ฝั่งผู้ใช้กับการเก็บที่ฝั่งเซิร์ฟเวอร์ เพื่อเลือกแนวทางที่ปลอดภัยที่สุด — ผลการศึกษานำไปสู่การเก็บไว้ฝั่งเซิร์ฟเวอร์ทั้งหมด
• การออกแบบโครงสร้างเครือข่ายแบบ Hub–Spoke บนคลาวด์ เพื่อแยกสภาพแวดล้อมการทำงานและควบคุมเส้นทางการเชื่อมต่อตามหลักความปลอดภัย

การจัดเตรียมสภาพแวดล้อมการทำงานบน Microsoft Azure ครบทั้งสภาพแวดล้อมพัฒนาและทดสอบระบบ ประกอบด้วย

• การจัดตั้ง Azure Kubernetes Service และ Container Registry เพื่อรองรับการขยายกำลังประมวลผลตามปริมาณการใช้งานจริง
• การนำ Azure Key Vault มาใช้จัดเก็บข้อมูลลับทั้งหมด พร้อมกลไกส่งค่าเข้าสู่ระบบขณะทำงาน เพื่อให้ไม่มีข้อมูลลับปรากฏในซอร์สโค้ดหรือไฟล์ตั้งค่า
• การแยกฐานข้อมูลและหน่วยความจำแคชตามรายบริการ เพื่อจำกัดผลกระทบเมื่อเกิดเหตุขัดข้อง และป้องกันการปะปนของข้อมูลข้ามสภาพแวดล้อม
• การนำ Azure Service Bus มาใช้สื่อสารระหว่างบริการ เพื่อให้ระบบทำงานต่อได้แม้บางบริการไม่พร้อมให้บริการชั่วคราว
• การจัดการโครงสร้างพื้นฐานด้วย Infrastructure as Code ผ่าน Repository เดียวพร้อมกลไกตรวจสอบความครบถ้วนของการตั้งค่าอัตโนมัติ เพื่อให้การเปลี่ยนแปลงโครงสร้างพื้นฐานตรวจสอบย้อนหลังและทำซ้ำได้

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

3. B-Ready Onboarding

การพัฒนาระบบสมัครใช้บริการสำหรับลูกค้านิติบุคคลแบบบริการตนเอง (Self-service) ตั้งแต่การยืนยันตัวตนจนถึงการเปิดใช้งานบัญชี เพื่อลดขั้นตอนการติดต่อสาขาและลดภาระงานเอกสารของเจ้าหน้าที่ โดยมีขอบเขตดังนี้

• การพัฒนาเครื่องยนต์ประมวลผลลำดับขั้นตอนแบบกำหนดค่าได้ (Lego Engine) ซึ่งอ่านลำดับขั้นตอนจากฐานข้อมูล พร้อมกลไกควบคุมสถานะใบสมัคร การตรึงเวอร์ชันของขั้นตอนขณะใช้งาน และตัวประมวลผลแยกอิสระในแต่ละขั้น เพื่อให้ปรับเปลี่ยนขั้นตอนตามนโยบายธุรกิจได้โดยไม่ต้องแก้ไขโปรแกรมและไม่ต้องรอรอบการติดตั้ง
• การพัฒนาการลงทะเบียนแบบไม่ใช้รหัสผ่าน ด้วยอีเมลและรหัส OTP 8 หลัก พร้อมการจำกัดจำนวนครั้งการขอรหัสและการระงับการใช้งานชั่วคราวเมื่อกรอกผิดครบตามกำหนด เพื่อป้องกันการสวมสิทธิ์และการโจมตีแบบสุ่มรหัส
• การพัฒนาการตรวจสอบสถานะนิติบุคคล เชื่อมต่อกับกรมพัฒนาธุรกิจการค้าและระบบข้อมูลลูกค้าของธนาคาร พร้อมการตรวจสอบความซ้ำซ้อนของผู้ยื่นคำขอ เพื่อให้ข้อมูลผู้สมัครถูกต้องตั้งแต่ต้นทางและลดการปฏิเสธคำขอในภายหลัง
• การพัฒนาการบันทึกข้อมูลใบสมัครตามแบบฟอร์มของธนาคาร ครอบคลุมผู้ติดต่อหลักหลายราย ผู้ใช้งานพร้อมสิทธิ์การทำรายการและวงเงินสูงสุดต่อรายการ และกรรมการผู้มีอำนาจลงนาม พร้อมการตรวจสอบความถูกต้องตามหลักเกณฑ์ที่กำหนด
• การพัฒนาระบบจัดทำใบสมัครในรูปแบบเอกสาร PDF ครบ 4 ส่วนตามแบบฟอร์มของธนาคาร พร้อมช่องทางดาวน์โหลดตามเลขที่คำขอ เพื่อใช้เป็นเอกสารประกอบการพิจารณาและการจัดเก็บตามระเบียบ
• การพัฒนาการบันทึกหลักฐานการยอมรับข้อกำหนดและเงื่อนไข โดยจัดเก็บวันเวลา เลขประจำตัวผู้เสียภาษี และเวอร์ชันของเงื่อนไขที่ลูกค้ายอมรับ เพื่อให้ตรวจสอบย้อนหลังได้ตามข้อกำหนดด้านการกำกับดูแล
• การพัฒนากระบวนการส่งคืนเพื่อแก้ไขและยื่นใหม่ (Rework / Resubmit) โดยคงเลขที่คำขอเดิม พร้อมประวัติการแก้ไขรายเวอร์ชันและความเห็นของผู้ตรวจสอบและผู้อนุมัติ เพื่อให้ติดตามความเป็นมาของคำขอได้ครบถ้วน
• การพัฒนาการเพิ่มผู้ใช้งานภายใต้บริษัท (Enroll) ผ่านการเชิญทางอีเมลและยืนยันด้วยรหัส OTP โดยตรวจสอบว่าอีเมลปรากฏอยู่ในใบคำขอที่ได้รับอนุมัติแล้วเท่านั้น เพื่อป้องกันการเพิ่มผู้ใช้งานที่ไม่ได้รับอนุญาต
• การพัฒนาการติดตามสถานะคำขอสำหรับลูกค้า แสดงความคืบหน้าเป็นรายขั้นตอนพร้อมสถานะ 10 รูปแบบ และควบคุมสิทธิ์การเข้าถึงให้เห็นเฉพาะใบสมัครของตน เพื่อลดการสอบถามสถานะผ่านเจ้าหน้าที่
• การพัฒนาระบบสำหรับเจ้าหน้าที่ธนาคาร (Bank Admin Portal) รองรับการรับ ตรวจสอบ และอนุมัติใบสมัครตามสายอนุมัติ Maker/Approver พร้อมการมอบหมายงาน เพื่อให้กระบวนการอนุมัติมีการแบ่งแยกหน้าที่ตามหลักการควบคุมภายใน
• การพัฒนาการเปิดใช้งานบัญชีบริษัทอัตโนมัติเมื่อได้รับอนุมัติ โดยเชื่อมกับระบบ Core Banking เพื่อลดขั้นตอนที่ต้องดำเนินการด้วยมือและลดข้อผิดพลาดจากการบันทึกซ้ำ
• การพัฒนาการแจ้งเตือนตลอดกระบวนการ ทั้งในแอปพลิเคชันและอีเมลทุกจุดที่สถานะเปลี่ยนแปลง พร้อมลิงก์เข้าสู่หน้ารายการที่เกี่ยวข้องโดยตรง เพื่อให้ลูกค้าและเจ้าหน้าที่ดำเนินการต่อได้ทันที

4. B-Ready Security

พัฒนาแอปพลิเคชันบนมาตรฐานความปลอดภัยที่ทันสมัยและเป็นสากล โดยมีมาตรฐานดังนี้

• การกำหนดอายุ Session Idle Timeout 24 ชั่วโมง
• การป้องกัน Cross-site Scripting ที่ฝั่ง frontend ด้วย CSP Nonce-based และ Trusted Types
• การสร้างลายเซ็นดิจิทัล (Digital Body Signature)
• การเข้ารหัสข้อมูลระดับ Field
• การเข้ารหัสข้อมูลตอนพัก (Data at Rest) และเซ็นเซอร์ข้อมูล (Data Masking)
• การสร้างกุญแจระหว่าง Server
• การกำหนดสิทธิ์การใช้งานของ API
• การใช้งานตู้เซฟนิรภัย (Key Vault) ที่ปลอดภัย

ขอบเขตและปริมาณงาน

• การจัดทำแผนงานความปลอดภัย 11 แผน ครอบคลุมการปิดช่องโหว่เร่งด่วน ความปลอดภัยของกระบวนการพัฒนา การรับส่งข้อมูล การเข้าถึงจากภายนอก การกำหนดสิทธิ์ การเสริมความแข็งแรงของ API การบริหารกุญแจและข้อมูลลับ ความปลอดภัยของหน่วยความจำแคช การคุ้มครองข้อมูลส่วนบุคคลตาม PDPA การติดตามการทำงานของระบบ และความปลอดภัยฝั่งผู้ใช้
• การจัดทำมาตรฐานกลาง 8 มาตรฐาน เป็นคู่มือพร้อมเกณฑ์ประเมินความคืบหน้า เพื่อให้ทุกทีมพัฒนาใช้เกณฑ์เดียวกันและวัดผลได้อย่างเป็นรูปธรรม
• การแตกและติดตามใบสั่งงานรายรายการมากกว่า 44 รายการ แบ่งเป็นงานฝั่งระบบหลังบ้าน 24 รายการ ฝั่งหน้าจอผู้ใช้ 20 รายการ และงานจัดทำเอกสารอีกชุดหนึ่ง
• การบริหารงาน 3 สายคู่ขนาน (ระบบหลังบ้าน / หน้าจอผู้ใช้ / เอกสารมาตรฐาน) ภายใต้แผนงานเดียวกัน เพื่อให้งานทั้งสามด้านเดินหน้าพร้อมกันโดยไม่รอกัน
• การกำหนดขอบเขตการบังคับใช้ครอบคลุม API ทั้ง 428 เส้นทั่วทั้งแพลตฟอร์ม

การควบคุมความปลอดภัยในกระบวนการพัฒนา

• การนำ SonarQube มาตรวจสอบคุณภาพและช่องโหว่ของโปรแกรมทุกครั้งที่ส่งงาน พร้อมแผนแก้ไขประเด็นระดับสำคัญครอบคลุม 5 บริการหลัก เพื่อป้องกันไม่ให้ช่องโหว่หลุดขึ้นสู่ระบบให้บริการ
• การตรวจสอบช่องโหว่ของไลบรารีภายนอกด้วย OWASP Dependency-Check เพื่อควบคุมความเสี่ยงจากส่วนประกอบที่องค์กรไม่ได้พัฒนาเอง
• การตรวจสอบ Container Image ด้วย Trivy ก่อนนำขึ้นให้บริการ
• การตรวจสอบการรั่วไหลของข้อมูลลับในซอร์สโค้ดด้วย Gitleaks
• การจัดทำบัญชีรายการส่วนประกอบซอฟต์แวร์ (SBOM) เพื่อให้ตรวจสอบผลกระทบได้ทันทีเมื่อมีการประกาศช่องโหว่ใหม่

การกำกับดูแล

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

5. ANE Onboarding LINE

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

• การพัฒนาหน้าสมัครรับข่าวสารบน LINE (LIFF) ให้ลูกค้าดำเนินการได้จากภายในแอปพลิเคชัน LINE โดยตรงหลังเพิ่มเพื่อน เพื่อลดขั้นตอนการเข้าสู่เว็บไซต์ธนาคาร
• การพัฒนาการยืนยันตัวตนด้วยเลขทะเบียนนิติบุคคลและอีเมลที่ลงทะเบียนไว้ เพื่อให้มั่นใจว่าผู้สมัครรับข่าวสารเป็นผู้แทนของบริษัทที่เป็นลูกค้าจริง
• การพัฒนาการยืนยันด้วยรหัส OTP ทางอีเมล เพื่อป้องกันการสมัครแทนกันโดยไม่ต้องให้ลูกค้าตั้งรหัสผ่านใหม่
• การพัฒนาการขอความยินยอมตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล พร้อมจัดเก็บหลักฐานการยอมรับและเวอร์ชันของข้อกำหนด เพื่อให้การเชื่อมบัญชี LINE เป็นไปตามข้อกำหนด PDPA
• การพัฒนาการยกเลิกการรับข่าวสาร ให้ลูกค้าถอนความยินยอมได้ด้วยตนเอง ตามสิทธิของเจ้าของข้อมูลส่วนบุคคล
• การพัฒนาการเชื่อมข้อมูลบริษัทและสมาชิกเข้ากับระบบ LINE เพื่อให้การส่งข่าวสารตรงกลุ่มผู้รับและลดการสื่อสารที่ไม่เกี่ยวข้อง
• การเชื่อมต่อ LINE Messaging API เข้ากับระบบแจ้งเตือนกลาง ใช้ร่วมกับช่องทางอีเมล SMS และการแจ้งเตือนบนอุปกรณ์ โดยไม่สร้างระบบส่งข้อความแยกต่างหาก
• การจัดทำชุดทดสอบสำหรับผู้ใช้ (UAT Test Case) พร้อมสถานะการทดสอบและหลักฐานการบันทึกความยินยอม เพื่อให้การส่งมอบมีเอกสารรองรับครบถ้วน
• การทดสอบระบบแบบครบวงจรผ่านหน้าจอจริงทุกขั้นตอน แทนการเรียกใช้ API เพื่อสร้างข้อมูลทดสอบ เพื่อให้ผลการทดสอบสะท้อนการใช้งานจริงของลูกค้า
• การจัดทำคู่มือการส่งมอบและบัญชีทดสอบ พร้อมเอกสารแนวทางเชื่อม LINE เข้ากับระบบยืนยันตัวตนกลางสำหรับการดำเนินการระยะถัดไป

หมายเหตุ

• จำนวน API นับจากจุดให้บริการ (Endpoint) ในโปรแกรมควบคุมของทุก Repository ณ วันที่ 27 สิงหาคม 2569 · ส่วน “พัฒนาด้วยตนเอง” นับจากประวัติการแก้ไขในระบบควบคุมเวอร์ชัน
• สถานะการใช้งานอ้างอิงจากสถานะงานที่ปิดแล้วในระบบติดตามงาน ควรตรวจสอบกับสถานะการติดตั้งจริงก่อนใช้ตอบคำถามเฉพาะเจาะจง
• งานช่วงปลายเดือนกรกฎาคมถึงสิงหาคม 2569 (แผนงานความปลอดภัย, AMLO, LINE, การลดค่าใช้จ่ายคลาวด์) บันทึกไว้ในเอกสารและคำขอรวมโปรแกรมเป็นหลัก ไม่ได้เปิดเป็นรายการในระบบติดตามงานทุกชิ้น