ย้ายพอร์ทัลพนักงานจากระบบเดิมที่ดูแลเองทั้งหมด ไปอยู่บน SharePoint Online พร้อมส่วนต่อขยาย CODEMONDAY Portal Extend สำหรับงานที่แพลตฟอร์มมาตรฐานทำไม่ได้
ตัวเลขทุกตัวมาจาก ScoreCard ของลูกค้าและภาพหน้าจอระบบเดิม ไม่ได้ประมาณเอง
| สายงาน | ปริมาณ | สาระสำคัญ |
|---|---|---|
| A · แพลตฟอร์มและโครงสร้าง | 8 REQ | tenant · site + hub · โมเดลสิทธิ์ · sync พนักงานเข้า-ออก |
| B · หน้าจัดการเนื้อหา | 50 ฟีเจอร์ | ก้อนใหญ่ที่สุด ต้องจัดชั้นก่อนตีราคา |
| C · โมดูลหน้าแรก + Knowledge | 16 REQ | ข่าว · สวัสดิการ · SOP · คู่มือ · ผลิตภัณฑ์ · โปรแกรม |
| D · ข้อมูลและการเชื่อมต่อ | 3 ตาราง | AI Level 4,000 · Branch Career 6,000 · Phonebook 10,000 แถว |
| E · มือถือและความปลอดภัย | 15 ข้อ | ส่วนใหญ่เป็นงาน Intune ไม่ใช่งานพัฒนา |
| F · ค้นหาและ analytics | 3 REQ + 4 | log keyword · zero-result · dashboard |
| G · ย้ายเนื้อหา | 48 หัวข้อ | SOP 18 ฝ่าย · ผลิตภัณฑ์ 13 · ชาวเงินติดล้อ 12 · คู่มือ 5 — ตีราคาแยกจาก feature |
| H · เอกสารส่งมอบ | 3 ชุด | SRS · SOW · Training Manual |
| มีแล้ว | 18 | ใช้งานได้จริงวันนี้ สาธิตสดได้ |
| มีบางส่วน | 15 | ฐานมีแล้ว เหลือเติมให้ครบสเปก |
| ยังไม่มี | 17 | ต้องพัฒนาเพิ่ม |
คอลัมน์ Phase · Complexity · Status · Owner ว่างทั้งไฟล์ — คือส่วนที่ต้องกรอกกลับไป
ลูกค้ากรอกมาแล้วเฉพาะ Priority: P1 จำนวน 24 ข้อ จาก 34
ประมาณครึ่งหนึ่งของ requirement ได้มาจากแพลตฟอร์มโดยไม่ต้องเขียนโค้ด และ Microsoft ดูแลให้
| กลุ่ม | ได้อะไรทันที | ตอบข้อไหน |
|---|---|---|
| หน้าเว็บ | สร้าง แก้ เผยแพร่ · เก็บทุกเวอร์ชันและย้อนกลับได้ · ตั้งเวลาเผยแพร่ · แก้พร้อมกันหลายคน · บันทึกเป็น template | #5 #6 #13 #17 |
| ไฟล์ | ไลบรารีเอกสาร · อัปโหลดทับโดย URL ไม่เปลี่ยน · ไฟล์ใหญ่เกิน 50MB ได้สบาย · ถังขยะ 93 วัน | #7 #8 · REQ-014 |
| ตารางข้อมูล | SharePoint list คือ custom table · สร้างคอลัมน์เอง · นำเข้าจาก Excel ได้ในตัว · เก็บได้ถึงหลักล้านแถว | #20 #21 |
| ค้นหา | full-text ถึงเนื้อในไฟล์ · รองรับภาษาไทย · กรองตามชนิดและฝ่าย | #29 · REQ-028 |
| สิทธิ์ | กลุ่ม Owners / Members / Visitors · ใส่ Entra group เข้าไปได้ · สิทธิ์ระดับหน้าและไลบรารี | #25 · REQ-002 |
| ตรวจสอบ | audit log ของ Microsoft 365 — ใครเปิด ดาวน์โหลด ค้นหาอะไร เมื่อไหร่ | #28 #39 |
| เมนู | hub site · เมนู hub ขึ้นทุก site ที่ผูกไว้ · audience targeting บนเมนู | REQ-009 |
| มือถือ | แอป SharePoint · บังคับ policy ด้วย Intune (ห้ามดาวน์โหลด ห้ามแคปหน้าจอ) | M001 M006–M008 |
| อื่น ๆ | ฝัง Excel online · วิดีโอผ่าน Stream · รายงานการใช้งาน site · DLP และ sensitivity label · MFA / Conditional Access | #33 #35 |
| ที่เก็บข้อมูล | 1 TB + 10 GB ต่อ license → ที่ 9,000 คนได้ราว 91 TB (ระบบเดิมใช้จริง 1.5 TB) | A011 |
งานที่ทีมเดิมต้องดูแลเอง — เซิร์ฟเวอร์ ฐานข้อมูล การสำรองข้อมูล และการอัปเดตความปลอดภัย — ย้ายไปเป็นความรับผิดชอบของ Microsoft ทั้งหมด
5 web part + 1 extension + หน้า admin หนึ่งชุด · ทุกบรรทัดมีเหตุผลว่าทำไมของมาตรฐานไม่พอ
| ส่วนประกอบ | ทำอะไร | ทำไม native ไม่พอ |
|---|---|---|
| ตัวจัดโซนเนื้อหา ZoneBlock |
ประกอบหน้าจาก block 8 ชนิด ลากวางได้ · เก็บเป็นข้อมูล ไม่ใช่หน้าเว็บ | หน้ามาตรฐานแก้ได้ทีละหน้า · ของเราคัดลอกข้าม site ได้ และ web part ตัวเดียวใช้ซ้ำได้ทุกหน้า |
| ตัวสร้างฟอร์ม FormBlock |
สร้างฟอร์มเอง ตรวจค่า เก็บคำตอบ ส่งออก CSV ต่อ Power Automate ส่งเมล | ฟอร์มมาตรฐานผูกกับ list หนึ่งใบ ปรับหน้าตายาก และไม่มีที่รวมคำตอบให้ admin |
| ถาม–ตอบ QaBlock |
ถามตอบต่อหน้า · ผู้ดูแลอนุมัติก่อนขึ้นจริง | ความเห็นบนหน้ามาตรฐานขึ้นทันที ไม่มีคิวอนุมัติ |
| รายการโปรแกรม AppLauncher |
กริดโปรแกรมพร้อมไอคอน · กรองตามแผนกของผู้ใช้ | ต้องดูแลลิงก์เป็นร้อยรายการ และของมาตรฐานไม่กรองตามแผนก |
| แถบหัว–ท้ายทุกหน้า SiteChrome |
header / footer เดียวกันทุกหน้า · เก็บสถิติการใช้งานลง Application Insights | รายงานมาตรฐานบอกยอดวิวรวม ไม่ได้บอกพฤติกรรมรายคนรายหน้า (REQ-026) |
| หน้า admin | จัดการหลาย site จากที่เดียว · เตรียม list และคอลัมน์ให้ site ใหม่อัตโนมัติ · แก้เมนูและเมนู hub · คอนโซล Power Automate · ตรวจสิทธิ์ผู้ใช้ | งานเหล่านี้กระจายอยู่ 4–5 หน้าจอของ Microsoft และบางอย่าง เช่นคอลัมน์ชนิด URL API มาตรฐานสร้างไม่ได้เลย |
โครงเนื้อหา ฟอร์ม การกันโค้ดอันตราย และการกรองตามแผนก เขียนเป็น TypeScript ล้วน มีกฎในโค้ดห้ามอ้างอิงไลบรารีของ SharePoint · ย้ายไป Teams หรือเว็บแยกได้โดยไม่ต้องรื้อเนื้อหา
เล่าเป็นเรื่องเดียว — ผู้ดูแลสร้างเนื้อหา → พนักงานเห็น → ข้อมูลกลับมาที่ผู้ดูแล
ฉาก 2 → 3 → 6 เท่านั้น (จัดเนื้อหา → เห็นผลทันที → คนละแผนกเห็นคนละชุด)
อ่านจากภาพ 9 หน้าที่ลูกค้าส่งมา · ทุกข้อจำกัดด้านล่างมาจากการตรวจกับระบบจริงแล้ว
| หน้าเดิม | ทำได้แค่ไหนบนของใหม่ | ข้อจำกัดที่ต้องบอกตรง ๆ |
|---|---|---|
| AI Level ปรับวิธี |
หน้าตาทำได้ครบด้วย block · ข้อมูล 4,000 แถวอยู่ใน list ได้สบาย | “เห็นเฉพาะของตัวเอง” ต้องเลือกวิธี — กรองที่หน้าเว็บอย่างเดียวไม่ปลอดภัย และวิธีสำเร็จรูปของ SharePoint ใช้ไม่ได้ เพราะข้อมูลมาจากการนำเข้า เจ้าของทุกแถวจึงเป็นผู้ดูแล |
| AI Gang ดีขึ้น |
ทำด้วยกลุ่มใน Entra แล้วตรวจผ่าน Graph ได้เลย โดยไม่ต้องขอสิทธิ์เพิ่ม | ปัจจุบันสิทธิ์ถูกฝังเป็นคอลัมน์ในข้อมูล การให้สิทธิ์จึงเท่ากับแก้ Excel แล้วนำเข้าใหม่ · ควรย้ายมาเป็นกลุ่มจริง |
| Branch Career ใช้ซ้ำได้ |
รูปแบบเดียวกับ AI Level ใช้แบบแผนเดียวกันซ้ำได้ | เป็นชุดข้อมูลที่ต้อง sync เพิ่มอีกหนึ่งชุด (6,000 แถว) |
| Phonebook ต้องออกแบบ |
ทำได้ · UX เดิมบังคับกรองก่อนอยู่แล้ว ซึ่งพอดีกับข้อจำกัด | 10,000 แถว เกินเพดานการแสดงผล 5,000 ต่อมุมมอง ต้องทำ index และไม่มีปุ่ม “แสดงทั้งหมด” · ถ้าดึงจาก AD ตรงจะดีกว่า แต่ต้องเช็คว่ามีชื่อเล่นและเบอร์ภายในครบ |
| ฟอร์มรับค่าจาก URL ทำได้ ต้องรัดกุมกว่าเดิม |
อ่านค่าจาก query string มาเป็นค่าตั้งต้นได้ ไม่ยาก | ของเดิมกำหนดผู้รับอีเมลผ่าน URL ด้วย ถ้ายกมาตรง ๆ จะกลายเป็นช่องทางส่งเมลในนามองค์กรไปที่ใดก็ได้ — ต้องจับคู่จากรายการที่กำหนดไว้เท่านั้น |
| ฟอร์มมีเงื่อนไข เปลี่ยนวิธี |
ทำเป็นกฎในโครงสร้างฟอร์ม หรือใช้ Power Apps ปรับฟอร์มของ list ก็ได้เงื่อนไขมาฟรี | ใส่ JavaScript เองไม่ได้แล้ว SharePoint สมัยใหม่ปิดทางนั้น ซึ่งเป็นผลดีด้านความปลอดภัย แต่ต้องแปลงของเดิมเป็นเงื่อนไขที่ประกาศไว้ |
| หน้าประกาศงาน เกือบครบ |
จัดหน้าแบบนี้ได้ด้วย block | ตัวนับ “7 ตำแหน่ง” ต่อฝ่ายต้องมี block ที่นับจากข้อมูลจริง ซึ่งยังไม่มี · และอาจต้องเรียก API ของ HR ที่ยังไม่มี spec |
| เว็บเดิมเป็น HTTP ได้ฟรี |
ของใหม่เป็น HTTPS บังคับทั้งระบบ | ลิงก์เก่าที่ฝังในอีเมลและเอกสารต้องวางแผน redirect · ต้องขอรายการ URL |
เอกสารของ Microsoft ระบุว่าห้ามยิงโหลดทดสอบกับ SharePoint Online และระบบจะ throttle การทดสอบโดยอัตโนมัติ
“load-testing isn’t permitted on SharePoint in Microsoft 365 … we automatically throttle any load tests.”
สิ่งที่เราเสนอแทน: ทยอยเปิดใช้งานเป็น wave ตามฝ่ายและสาขา · วัดผู้ใช้จริงด้วย Application Insights ที่ติดตั้งไว้แล้ว · ออกแบบให้ทนการ throttle ตั้งแต่ต้น
ข้อ M010 ขอ watermark ชื่อและรหัสพนักงานทุกหน้าจอ — แอป SharePoint ไม่มีความสามารถนี้ ต้องคุมด้วย Intune (ซึ่งเอกสารลูกค้าเขียนไว้เองแล้วในข้อ M006) หรือแยกเป็นโครงการ secure viewer
ทางที่ง่ายที่สุดคือกรองที่หน้าเว็บ ซึ่งเปิดเครื่องมือนักพัฒนาก็เห็นข้อมูลคนอื่นได้ · ทางที่ปลอดภัยจริงมีสองทางและราคาต่างกัน ต้องเลือกร่วมกันตั้งแต่ต้น
4 เฟส · เฟสแรกไม่ใช่การเขียนโค้ด แต่เป็นเฟสที่ทำให้ราคาไม่บวมทีหลัง
ปิด 16 คำถามที่ยังค้างจาก ScoreCard และภาพระบบเดิม · สามข้อที่ต้องได้คำตอบก่อนอย่างอื่น:
โครง site และ hub · โมเดลสิทธิ์ที่ผูกกับ Entra group · หน้าจัดการเนื้อหาชั้นที่ใช้บ่อย · แถบหัวท้าย · รายการโปรแกรม · SOP คู่มือ ผลิตภัณฑ์ ชาวเงินติดล้อ · ถามตอบ
ส่งมอบได้เร็ว เพราะ 18 จาก 50 ฟีเจอร์มีของอยู่แล้ว และเนื้อหากลุ่มนี้เป็นการย้ายไฟล์กับจัดหน้า ไม่ต้องรอ API จากใคร
3 ตาราง 20,000 แถว · ขั้นตอนนำเข้า Excel รายเดือน · สิทธิ์รายแถวตามที่ตัดสินใจใน Phase 0 · Phonebook จาก AD ถ้าทำได้ · ตำแหน่งงานว่างเมื่อได้ spec API จาก HR
เริ่มที่ AI Level ตัวเดียวก่อน เพราะ Branch Career ใช้แบบแผนเดียวกัน — พิสูจน์ที่ตัวเดียวแล้วค่อยขยาย ไม่ทำพร้อมกันสามตาราง
log การค้นหา รายงาน keyword ที่ไม่มีผลลัพธ์ และ dashboard · รายงานการใช้งาน · ส่วนเสริมของถามตอบ (แจ้งเมล แจ้งเนื้อหาไม่เหมาะสม ส่งออกประวัติ) · เครื่องมือ Super Admin
เป็นวิธีที่ Microsoft แนะนำเอง และเป็นคำตอบของข้อ REQ-005 ไปในตัว · เปิดทีละฝ่ายหรือภูมิภาค ดูตัวเลขผู้ใช้จริงหลังแต่ละ wave · เจอปัญหาตอนคนน้อย ไม่ใช่ตอน 9,000 คนพร้อมกัน
เขียนเพิ่มเฉพาะที่มาตรฐานทำไม่ได้จริง — ค่าดูแลระยะยาวถูกกว่ามาก และได้ความสามารถใหม่ของ Microsoft ฟรีทุกปี
ย้าย คัดลอก และทำซ้ำข้าม site ได้ · ไม่ผูกกับ SharePoint ตลอดไป
ทุกข้อจำกัดในเอกสารนี้มาจากการยิง API จริงกับ tenant ไม่ใช่จากการอ่านสเปก
ของที่ทำไม่ได้ พูดตอนเสนอ ถูกกว่าพูดตอนทดสอบรับมอบ
ไล่ทีละบรรทัดจากเอกสารลูกค้า ไม่ได้ตีเป็นก้อน · รายการเต็มอยู่ในไฟล์ MANDAYS.md
| สายงาน | สาระสำคัญ | md |
|---|---|---|
| A · แพลตฟอร์มและโครงสร้าง | site + hub · โมเดลสิทธิ์ · การ sync พนักงาน | 15.0 |
| B · หน้าจัดการเนื้อหา | 50 ฟีเจอร์ — ก้อนใหญ่ที่สุด | 119.5 |
| C · โมดูลหน้าแรกและ Knowledge | 16 REQ · ส่วนใหญ่ประกอบจาก block ที่มีแล้ว | 28.0 |
| D · ข้อมูลและการเชื่อมต่อ | 3 ตาราง 20,000 แถว + ขั้นตอนนำเข้ารายเดือน | 34.0 |
| E · มือถือและความปลอดภัย | เฉพาะส่วนที่เป็นงานเรา (ที่เหลือเป็นงาน Intune ของลูกค้า) | 7.0 |
| F · ค้นหาและรายงาน | tracking · รายงานการใช้งาน · คำแนะนำการค้นหา | 10.0 |
| G · ย้ายเนื้อหา | 48 หัวข้อ ที่ ~0.5 md ต่อหัวข้อ | 28.0 |
| H · เอกสารส่งมอบ | SRS · SOW · Training Manual · อบรมผู้ดูแล | 19.0 |
| รวมงานพัฒนา | 260.5 | |
| PM / BA ตลอดโครงการ · 15% | 39.1 | |
| QA และสนับสนุน UAT · 10% | 26.1 | |
| Phase 0 · workshop ปิดคำถามที่ค้าง | 6.0 | |
| Rollout เป็น wave และเฝ้าดูตัวเลขจริง | 8.0 | |
| รวมทั้งหมด | 340 md | |
| ทางเลือก | ได้อะไร | รวม | ทีม 4 คน |
|---|---|---|---|
| A · ใช้งานได้จริง | โครงสร้าง สิทธิ์ หน้าจัดการชั้นที่ใช้บ่อย เนื้อหาทั้งหมด ถามตอบ รายการโปรแกรม ข่าวสาร | 171 | ~2 เดือน |
| B · A + โมดูลข้อมูล | เพิ่ม AI Level · Branch Career · Phonebook · custom table · นำเข้ารายเดือน · สิทธิ์รายคน | 255 | ~3.2 เดือน |
| C · ครบตาม ScoreCard | เพิ่ม search analytics · เครื่องมือ Super Admin · export PDF · page lock · ส่วนเสริมถามตอบ · เอกสารครบชุด | 340 | ~4.2 เดือน |
สูตรเดียวกันทุกทางเลือก: (งานพัฒนา × 1.25) + 14 · เดือนคิดที่ 20 วันทำงานต่อคน และไม่รวมช่วงรออนุมัติจากลูกค้า
| สิทธิ์รายแถว | 4–20 md | ตัดสินวิธีบังคับสิทธิ์ใน Phase 0 |
| Org chart access | 0–12 md | รู้ว่าจำเป็นจริงหรือไม่ |
| ย้ายเนื้อหา | 20–60 md | ได้จำนวนไฟล์จริงต่อหมวด |
| ตำแหน่งงานว่าง | 3–15 md | ได้ spec API ของ HR |
| Custom table | 10–18 md | รู้จำนวนตารางและหน้าที่ต้องแสดง |
HBD และระบบ Consent (ลูกค้าระบุเป็น Phase 2 · ประเมินไว้ราว 8 md) · การ redirect ลิงก์เก่าจากเว็บเดิม (ต้องขอรายการ URL ก่อน) · secure viewer สำหรับ watermark บนมือถือ (เป็นโครงการแยก) · งานฝั่งลูกค้าทั้งหมด ได้แก่ Intune policy · Workday→AD sync · API ของ HR · ค่า license
ทุกภาพถ่ายจากระบบที่รันจริง ไม่ใช่ภาพออกแบบ · กดที่ภาพเพื่อดูขนาดเต็ม