1.1 · ผู้มีส่วนเกี่ยวข้องและบทบาท

บทนี้ทำ map ความสัมพันธ์ระหว่างคนที่อยู่เบื้องหลังระบบ — ใครเป็นเจ้าของฟีเจอร์, ใครอนุมัติ, ใครรับผลกระทบเวลาเปลี่ยนแปลง

เอาไว้ใช้ตอนเจอ "policy ที่ดูผิดปกติ" แล้วไม่รู้จะถามใคร เช่น "ทำไม HR HQ ถึงข้าม validation การลาได้" หรือ "ใครเป็นคนกำหนดว่าเบิกบุตรได้สูงสุด 5 คน"

ภาพรวม — 5 กลุ่มคน

สภากาชาดแห่งประเทศไทย (เจ้าของระบบ)
  └── ฝ่าย HR (power user)
        ├── เจ้าหน้าที่ HR HQ (สนง. กลาง, orgCode 0734)
        ├── HR สาขา (แยกตามหน่วยงาน)
        └── ผู้อนุมัติ (ตาม orgCode)
              │
              │  เจ้าของสัญญาว่าจ้าง
              ▼
ทีมพัฒนา (vendor — i3 Thailand)
  └── ดูแล codebase ทั้ง 5 repos
              │
              │  ให้บริการ
              ▼
ผู้ใช้ระบบ
  ├── พนักงาน (end-user) — เว็บ + มือถือ
  ├── HR — backoffice
  ├── IT สภากาชาด (อนุญาต network/firewall)
  └── บุคคลที่ดึงข้อมูลผ่าน INTEGRATE_APP

กลุ่มที่ 1 — พนักงาน (end-user)

พนักงานสภากาชาดทุกคนที่เข้าใช้ระบบผ่านเว็บ vtrc.redcross.or.th หรือ mobile app

บทบาทหลักในระบบ

อ่านข้อมูลตัวเอง (สลิป, ภาษี, เวลาทำงาน, profile)
ยื่นคำขอ (ลา, เบิกสวัสดิการ, ขอทุน, เปลี่ยน contribution กองทุน)
รับ push notification

พนักงานแต่ละคน map กับ record เดียวใน HRMI ผ่าน EmpCode + identityCard — ความสัมพันธ์นี้เป็น 1:1 ยกเว้นพนักงานที่ "สังกัด 2 ที่" เช่นเป็นทั้งพนักงาน RC และ affiliated กับจุฬา จะมีหลาย profileKey แล้วเลือก currentProfile ตอน login

ในระบบเรียกว่ามีหลาย profile — ดู typeDefs/user.js:125-150 (AccordingProfile) และ changeCurrentProfile (user.js:77-79)

กลุ่มที่ 2 — HR (backoffice user)

HR คือกลุ่มที่ใช้ระบบหนักที่สุด แบ่งเป็น 4 บทบาทย่อยตามสิทธิ์ (เก็บใน Users.role เป็น JSON)

บทบาท	สิทธิ์	ตัวอย่างเมนูที่เข้าได้
`USER`	อ่านข้อมูลตัวเองเท่านั้น	(ใช้ฝั่ง end-user ไม่ใช่ HR)
`STAFF`	backoffice ระดับต้น — อนุมัติ ดูข้อมูล	ตาม `accessMenu` ที่ได้รับ
`ADMIN`	backoffice ระดับกลาง — จัดการ master data	+ เพิ่มจาก STAFF
`SUPER_ADMIN`	backoffice ทุกเมนู — รวมจัดการผู้ใช้	ทุกเมนูใน `MENUS_BACK_OFFICE`

Source of truth — vtrc-api/api/src/config.js:150-151

const ACCESS_BACK_OFFICE = ['SUPER_ADMIN', 'ADMIN', 'STAFF']
const ACCESS_USER = ['USER']

HR ที่ไม่ใช่ SUPER_ADMIN จะเข้าเมนูได้ตามที่กำหนดใน accessMenu เช่น accessMenu: ["Leave"] หรือ accessMenu: ["hospitalPaid", "hospitalHr"] — ดูรายการเมนูทั้งหมดใน config.js:159-370 (MENUS_BACK_OFFICE)

กลุ่มที่ 3 — ผู้อนุมัติ (Approver)

ผู้อนุมัติคือพนักงานที่มีหน้าที่ตรวจคำขอก่อนส่งต่อ แต่ไม่ใช่ HR ประจำ

ในระบบมี 2 ประเภทผู้อนุมัติ แยกกันโดยสิ้นเชิง

ประเภท	เก็บที่ไหน	ดึงอย่างไร
Leave approver	HRMI upstream	`hrmiGetLeaveApproverCD` (live, ทุกครั้ง)
Hospital approver	`MasterApprovers` table ใน VTRC	ดึงจาก MariaDB (`type: 'MEDICAL'`)

ความแตกต่างสำคัญ — leave approver ไม่ได้เก็บใน VTRC ถ้า HRMI ล่ม การลาทั้งระบบไม่สามารถอนุมัติได้

แต่ hospital approver เก็บใน VTRC และ HR จัดการเองผ่านเมนู MasterApprovers — แยกจาก HRMI

รายละเอียด — vtrc-api/api/src/models/core/masterData/masterApprovers.js:1-56 (field type ENUM("MEDICAL"))

กลุ่มที่ 4 — ผู้ดูแลระบบ (vendor + IT สภากาชาด)

กลุ่ม	หน้าที่
ทีม vendor (i3)	แก้โค้ด, deploy, ดูแล incident
IT สภากาชาด	network, firewall, DNS, TLS cert, ประสานกับ vendor
ทีม infra จุฬา (สำหรับ CU-affiliated users)	LDAP/AD, MSSQL HRMI

กฎสำคัญ — ทุกการเปลี่ยนแปลงใน production ต้องผ่าน IT สภากาชาดอนุมัติ ไม่ใช่ deploy เองในกลางดึก

กลุ่มที่ 5 — ระบบภายนอก (APP_TYPE `INTEGRATE_APP`)

VTRC ไม่ได้ใช้คนเดียว — มีระบบอื่นที่ยิง API เข้ามาผ่าน device key แยก

APP_NAME	APP_TYPE	ทำอะไร	config อ้างอิง
`INFOMA`	`INTEGRATE_APP`	(legacy integration, ไม่ active มาก)	`config.js:61-66`
`CONICLE`	`INTEGRATE_APP`	ระบบ training/learning — VTRC เป็น SSO bridge	`config.js:67-72`
`TWOWAY`	`TWOWAY`	sync ข้อมูล 2 ทิศกับ HRMI	`config.js:73-78`
`MEETING`	`MEETING`	ระบบจองห้องประชุม	`config.js:79-84`

แต่ละตัวมี API key เป็น UUID ที่ map ไปยัง APP_TYPE — vtrc-api/api/src/config.js:41-149

ทำไมต้องรู้เรื่องนี้

เพราะหลายครั้งที่ฟีเจอร์ "ดูแปลก" มาจาก policy ของ HR HQ ที่ไม่ได้เขียน document ไว้ ไม่ใช่ bug

ตัวอย่างที่พบจริงใน codebase

HR HQ (orgCode ขึ้นต้นด้วย 0734) สามารถข้าม validation การลาได้ — เพราะเป็นคนอนุมัติเองอยู่แล้ว การบังคับ max/min days เลยไม่มีประโยชน์ (hrmi.js:1302)
ผู้รับบำนาญ (orgCode == "88") ถูก tag empType = "บำนาญ" อัตโนมัติ (withdraw/hospital.js:1388) เพราะ flow การเบิกต่างจากพนักงานปกติ
KEY_PLASMA (config.js:153) เป็น UUID ที่ระบุกลุ่ม plasma (ธนาคารเลือด) ซึ่งมี policy เฉพาะ — ถ้าเจอ condition isPlasma ในโค้ด ให้ถาม HR ก่อนว่า policy คืออะไร อย่าเดา

เคล็ดลับตอนทำงานกับ HR

HR สภากาชาดเป็น domain expert ที่รู้ดีที่สุดว่า flow ไหน "ใช้จริง" หรือ "ทิ้งไว้"

เวลาเจอเหตุการณ์ที่ดูผิดปกติ ให้ถามด้วยคำถามปลายเปิด — หลีกเลี่ยงคำถามที่ตอบได้แค่ "ใช่/ไม่ใช่" เพราะ HR มักจะตอบ "ใช่" แล้วจบ จะทำให้ไม่ได้รับข้อมูล

ตัวอย่างคำถามที่เปิดโอกาสให้อธิบาย

"ช่วยเล่าให้ฟังหน่อยได้ไหมว่า ตอนทำเรื่องนี้จริงๆ ท่าน click ผ่านเมนูไหน แล้วเจออะไรหลังจากนั้น"
"field X ที่เห็นในระบบ — ถ้าย้อนไปตอนออกแบบ ทีม HR ตั้งใจใช้ทำอะไร"
"ตรรกะ validation ตรงนี้ — ช่วยอธิบายหน่อยได้ไหมว่า business ต้องการอะไร"

อย่าใช้ศัพท์เทคนิคเวลาถาม HR — JSON blob, GraphQL, cron พวกนี้เขาไม่รู้เรื่อง ใช้ชื่อเมนูในหน้าจอแทน

ขั้นตอนถัดไป

ไป บท 1.2 องค์กรและโครงสร้างฝ่าย HR →

1.1 · ผู้มีส่วนเกี่ยวข้องและบทบาท ​

ภาพรวม — 5 กลุ่มคน ​

กลุ่มที่ 1 — พนักงาน (end-user) ​

กลุ่มที่ 2 — HR (backoffice user) ​

กลุ่มที่ 3 — ผู้อนุมัติ (Approver) ​

กลุ่มที่ 4 — ผู้ดูแลระบบ (vendor + IT สภากาชาด) ​

กลุ่มที่ 5 — ระบบภายนอก (APP_TYPE INTEGRATE_APP) ​

ทำไมต้องรู้เรื่องนี้ ​

เคล็ดลับตอนทำงานกับ HR ​

ขั้นตอนถัดไป ​