Talent Marketplace & AI Screening

BTG Intelligent Talent Marketplace Hub

28 business pain pointsสรุปเฉพาะปัญหาหลัก ผลกระทบปัจจุบัน และผลลัพธ์ทางธุรกิจที่ต้องเกิดขึ้น

#	Critical Pain Point	ปัญหาและผลกระทบปัจจุบัน	Expected Outcome
1	Candidate Data กระจัดกระจายและไม่มี Candidate Master กลาง	ข้อมูล Candidate อยู่ใน Job Platform, Email, ไฟล์ส่วนตัว, Referral, Recruitment Event และระบบเดิม ทำให้ Recruiter ไม่ทราบว่าองค์กรเคยมี Candidate คนนี้แล้วหรือไม่ ประวัติ Resume และการสมัครไม่ต่อเนื่อง	เกิดฐานข้อมูล Candidate กลางที่เชื่อถือได้ ลดการค้นข้อมูลจากหลายระบบ
2	Candidate ที่องค์กรลงทุนซื้อหรือ Sourcing มาแล้วไม่ถูกนำกลับมาใช้	Candidate ที่ซื้อผ่าน CV Credit หรือใช้เวลาของ Recruiter ในการค้นหาและคัดกรอง มักถูกใช้กับ JR เดียว เมื่อไม่ผ่าน ทีมอื่นไม่ทราบว่ามี Candidate อยู่แล้วและอาจซื้อ Candidate กลุ่มเดิมซ้ำ	ลดค่า Job Platform และต้นทุน Sourcing ซ้ำ เพิ่มการใช้ประโยชน์จาก Candidate เดิม
3	Candidate ที่สมัครเองและ Candidate ที่ Recruiter Sourcing มาไม่มี Flow ที่ชัดเจน	Candidate จาก JobDB หรือ Career Site มี JR ที่สมัครชัดเจน แต่ CV ที่ Recruiter ซื้อหรือได้รับมาอาจยังไม่มี JR หากบังคับใช้ Flow เดียวกันจะเกิด Application ที่ไม่ถูกต้อง	รองรับทั้ง Applicant และ Passive Prospect โดยไม่สร้าง Transaction เกินความจำเป็น
4	Candidate ต้องกรอกข้อมูลซ้ำจาก Resume และ Recruiter ต้อง Key ข้อมูลเอง	Candidate ต้องกรอก Work Experience, Education และ Skills ซ้ำจาก CV หรือ Recruiter ต้องคีย์ข้อมูลแทน ทำให้ใช้เวลา ข้อมูลผิดพลาด และ Candidate อาจสมัครไม่สำเร็จ	ลดเวลาสมัคร ลด Human Error และเพิ่ม Completion Rate
5	Recruiter ต้องเปิด Candidate ทีละคนเพื่อ Screening	เมื่อมีผู้สมัครจำนวนมากใน JR Recruiter ต้องเปิด CV ทีละใบ ทำให้ใช้เวลานานและอาจมองข้าม Candidate ที่เหมาะสม	Recruiter เห็นผู้สมัครทั้งหมดของ JR จากหน้าเดียวและไม่ต้องเปิดทุก CV ตั้งแต่ต้น
6	Candidate, Application และ Talent Pool ถูกมองเป็นเรื่องเดียวกัน	ไม่ชัดเจนว่า Candidate สมัครงานอะไร อยู่ Pool ไหน หรือเป็นเพียง CV ที่ยังไม่มี JR ทำให้ Status และการนำ Candidate กลับมาใช้สับสน	ข้อมูลมีโครงสร้างชัดเจน และ Candidate หนึ่งคนสมัครได้หลาย JR โดยไม่สร้าง Profile ซ้ำ
7	Shared Talent Pool เดิมไม่มี Category และบริบทที่พร้อมใช้งาน	Candidate ถูกเก็บรวมกันโดยไม่ทราบว่าเหมาะกับสายงานใด สนใจงานอะไร พร้อมเริ่มงานหรือไม่ และข้อมูลอัปเดตล่าสุดเมื่อไร	Pool กลายเป็น Talent Supply ที่ค้นหาและนำกลับมาใช้ได้จริง
8	Candidate ที่สมัคร JR ยังไม่ถูกนำไปจัดกลุ่มเพื่อ Reuse อย่างเป็นระบบ	Candidate อาจสมัคร JR หนึ่งและถูกปิด Process หลังไม่ผ่าน โดยไม่มีการส่งต่อไปยัง Pool หรือสายงานอื่นที่เหมาะกว่า	Candidate ที่ไม่สำเร็จใน JR แรกยังถูกนำกลับมาใช้กับตำแหน่งอื่นได้
9	ค้นหา Candidate ที่มีอยู่ในฐานข้อมูลได้ยาก	แม้มี Candidate จำนวนมาก แต่ Recruiter ยังต้องเปิด Profile ทีละคน และ Keyword Search อาจไม่พบ Candidate ที่ใช้คำต่างจาก JD แต่มีความสามารถใกล้เคียงกัน	Recruiter ค้น Existing Candidate ได้ก่อนออกไปซื้อหรือ Sourcing Candidate ใหม่
10	ไม่มีระบบ Recommendation ที่รองรับ Candidate จำนวนมากโดยไม่เปลือง AI Cost	หากนำ CV ทั้ง 50,000 คนส่งเข้า LLM ทุกครั้ง ระบบจะช้าและมีค่าใช้จ่ายสูง แต่หากใช้ Keyword เพียงอย่างเดียวผลอาจไม่แม่น	รองรับ Candidate จำนวนมากได้โดยควบคุม Token, Cost และ Response Time
11	ผล Screening หรือ Recommendation ไม่มีเหตุผลที่ตรวจสอบได้	Match Score เพียงอย่างเดียวไม่ทำให้ Recruiter เข้าใจว่า Candidate เหมาะเพราะอะไร และอาจทำให้เชื่อ AI มากเกินไป	Recruiter สามารถตรวจสอบ AI Result และยังเป็นผู้ตัดสินใจขั้นสุดท้าย
12	Duplicate Candidate และ Duplicate Application ทำให้ข้อมูลไม่น่าเชื่อถือ	Candidate คนเดียวอาจใช้ Email, Phone หรือ Resume หลาย Version ทำให้มีหลาย Profile ขณะเดียวกัน Candidate อาจสมัคร JR เดิมซ้ำ	ลด Profile ซ้ำ โดยคนเดิมสมัคร JR ใหม่ได้ แต่คนเดิมสมัคร JR เดิมจะไม่เกิด Application ซ้ำ
13	ไม่มีระบบ Blacklist และ Candidate Restriction แบบรวมศูนย์	Candidate ที่สมัครใหม่อาจอยู่ใน Blacklist, Do Not Contact หรือมีเหตุผลที่ต้องผ่าน HR Review แต่ Recruiter คนใหม่ไม่ทราบ ขณะที่เหตุผลอ่อนไหวไม่ควรเปิดให้ทุกคนเห็น	ป้องกันการดำเนินการกับ Candidate ที่มี Restriction พร้อมรักษาความลับของข้อมูล
14	ตรวจ Current Employee, Former Employee และ Rehire Eligibility ใช้เวลานาน	Recruiter ต้องตรวจหลายระบบหรือส่ง Email เพื่อทราบว่า Candidate เป็นอดีตพนักงานและสามารถ Rehire ได้หรือไม่	ลดเวลา Manual Check และไม่เปิด Exit Reason เกินสิทธิ์
15	ไม่ทราบว่า Candidate กำลังถูกดำเนินการกับ JR ใดและใครรับผิดชอบ	Recruiter คนอื่นอาจไม่รู้ว่า Candidate อยู่ในขั้น Shortlist, Contact, Interview หรือ Offer กับ JR ใด ส่งผลให้ติดต่อหรือดำเนินการซ้ำ	Recruiter เห็นสถานะทันทีและลดการตรวจสอบหลายขั้นตอน
16	Candidate อาจถูก Shortlist, Contact หรือ Interview ซ้ำระหว่างหลาย Recruiter	Candidate คนเดียวอาจถูกดำเนินการพร้อมกันหลาย BU ทำให้ Candidate สับสนและกระทบ Employer Brand	ลด Candidate Conflict และป้องกันการติดต่อซ้ำ
17	Candidate Pool ล้าสมัยและ Candidate ไม่สามารถอัปเดตข้อมูลได้ง่าย	Candidate อาจเปลี่ยนงาน เพิ่ม Skill เปลี่ยน Salary หรือไม่สนใจงานใหม่แล้ว ทำให้ Profile เดิมไม่พร้อมใช้	Candidate Pool มีข้อมูลล่าสุดและพร้อมนำมา Match มากขึ้น
18	ไม่สามารถส่งตำแหน่งที่เหมาะให้ Candidate ใน Pool ได้อย่างเป็นระบบ	แม้มี JR ใหม่ที่ตรงกับ Candidate ใน Pool แต่ Recruiter ไม่สามารถส่งโอกาสงานเป็นกลุ่มและติดตามว่า Candidate สนใจหรือไม่	เพิ่ม Candidate Re-engagement และ Conversion จาก Existing Pool
19	การมองเห็น JR และ Candidate ไม่รองรับสายบังคับบัญชาและการช่วยกันหา	TAC Director ต้องเห็น JR ของลูกทีมทั้งหมด แต่ Recruiter ทั่วไปไม่ควรเห็นทุก Candidate ขณะเดียวกัน Recruiter ระดับเดียวกันอาจต้องช่วยกัน Sourcing	Director กำกับทีมได้ครบและ Recruiter ช่วยกันหาได้โดยไม่เปิดข้อมูลเกินสิทธิ์
20	ไม่รู้ว่า JR ใดเป็นความรับผิดชอบของ Recruiter หรือทีมใด	หาก Standalone รับเพียง JR ID และ JD จะไม่ทราบว่าใครต้องดำเนินการ Screening และ Candidate Pipeline ของ JR นั้น	JR ถูกส่งไปยังผู้รับผิดชอบถูกคนโดยอัตโนมัติ
21	สิทธิ์ Action บน JR ไม่ชัดเจนระหว่าง Recruiter, Team Lead และ Director	หากทุกคนแก้ข้อมูลได้ทั้งหมดจะไม่มี Ownership แต่ถ้าจำกัดมากเกินไปทีมไม่สามารถช่วยกันทำงาน	Primary Recruiter เป็น Owner ทีมช่วยงานได้ และ Director กำกับ/Reassign ได้โดยไม่แก้ข้อมูลประเมินของผู้อื่น
22	JR ที่สร้างจาก Position Org Chart ไม่เข้าสู่ Standalone ทันทีอย่างน่าเชื่อถือ	หากรอ Sync หนึ่งชั่วโมง Recruiter จะเริ่ม Posting และ Screening ช้า แต่หาก Poll ถี่เกินไปจะเพิ่ม SAP API Load	JR พร้อมใช้งานเร็วโดยไม่ Call SAP ทุก Page Load
23	กระบวนการ Recruitment ถูกบันทึกซ้ำระหว่าง Standalone และ SF	หาก Candidate, Screening, Pool, Interview และ Offer ต้องถูก Update ทั้งสองระบบ Recruiter จะทำงานซ้ำและ Status อาจไม่ตรงกัน	ลด Integration Complexity และลดงาน Manual ซ้ำ
24	ไม่มี Recruitment Headcount และ Vacancy Dashboard สำหรับ TAC Director	TAC Director ไม่สามารถเห็นจากหน้าเดียวว่าแต่ละ Position/JR ต้องรับกี่คน เหลือ Vacancy เท่าไร Candidate Pipeline เพียงพอหรือไม่ และ Recruiter คนใดมี Workload สูง	Management เห็น Hiring Demand, Progress และ Bottleneck อย่างเป็นระบบ
25	หลังส่ง Candidate เข้า SAP Onboarding ยังไม่ทราบชัดว่าเริ่มงานจริงหรือไม่	SAP สามารถแสดง Onboarding Status, Hire Status และ Employee Person ID ได้ แต่การสร้าง Employee Record อาจเกิดก่อนวันเริ่มงานจริง	Candidate และ Vacancy Status สะท้อนเหตุการณ์จริง ไม่อาศัยเพียงการสร้าง EC Record
26	Candidate No-show หรือยกเลิกหลัง Offer ทำให้ต้องกลับมาหาคนใหม่	เมื่อ Candidate ไม่มาเริ่มงาน JR เดิมอาจถูกปิดแล้ว Recruiter ต้องเปิด JR ใหม่และเริ่ม Process ซ้ำ	Recruiter กลับมาหาคนแทนได้เร็วโดยไม่ต้องเริ่ม Screening และ Pool Setup ใหม่
27	Management ไม่สามารถวัด Candidate Utilization, Sourcing Cost และ AI Performance	ไม่ทราบว่า Candidate ที่ซื้อมาถูกนำกลับมาใช้กี่ครั้ง Pool ใดคุ้มค่า Source ใดมี Conversion สูง หรือ AI ช่วยลดเวลาจริงเท่าไร	สนับสนุนการควบคุมงบ Sourcing และวัดผลการลงทุนในระบบ
28	Integration Failure อาจทำให้ข้อมูลระหว่าง SF และ Standalone ไม่ตรงกัน	Event อาจตกหล่น API อาจล้มเหลว หรือข้อมูลถูกส่งสำเร็จเพียงบางส่วน ทำให้ JR หรือ Onboarding Process ค้าง	ลดข้อมูลตกหล่นและช่วยทีม Support ตรวจสอบปัญหาได้รวดเร็ว

Focus pointเริ่มจากการจัดการ Candidate Data ให้เป็น Master กลาง แล้วทำให้ Talent Supply, Recruitment Operation, Governance และ Integration วัดผลได้จริง

02 / CONCEPTUAL MODEL