ภาพในหัว: สายพานในโรงงานที่ไม่มี QC ที่จุดส่งต่อ#

ลองนึกถึงโรงงานประกอบรถยนต์ ชิ้นส่วนเดินทางบนสายพานยาวต่อกันหลายช่วง ช่วงแรกเชื่อมงานปั๊มกับงานเชื่อม ช่วงที่สองเชื่อมงานเชื่อมกับงานพ่นสี ช่วงที่สามเชื่อมงานพ่นสีกับงานประกอบ

ในแต่ละสถานีมี QC ทำงานเข้มมาก ทุกชิ้นถูกตรวจ

แต่ที่รอยต่อระหว่างสายพาน ไม่มีใครยืน ไม่มีใครเช็คว่าชิ้นส่วนที่ออกจากสายพาน A เข้าสายพาน B ครบมั้ย ขนาดถูกต้องมั้ย หรือถูกขย้ำตอนเปลี่ยนสายพานรึเปล่า

System interface ก็เหมือนกันครับ ระบบ A กับระบบ B ทั้งคู่มี internal control แน่นหนา แต่ระหว่างที่ข้อมูลเดินทาง จากระบบหนึ่งไปอีกระบบหนึ่ง ใครคุม?

3 ประเภทของ interface ที่ต้องแยก#

Case study ที่เห็นซ้ำในวงการ#

กรณีที่ 1 — โรงพยาบาลเอกชน: ระบบลงทะเบียนผู้ป่วยส่งข้อมูลไประบบ billing ผ่าน system-to-system interface

วันหนึ่ง developer คนหนึ่งแก้ field mapping ของระบบลงทะเบียนโดยไม่ผ่าน change management

ผลลัพธ์: ชื่อผู้ป่วยถูก truncate ก่อนส่งเข้า billing ใบ invoice ออกไปโดยที่ชื่อผิด ลูกค้าหลายเคสปฏิเสธจ่าย เพราะชื่อบนใบเสร็จไม่ตรงกับที่ลงทะเบียน

control gap: ไม่มี field-level validation ที่ interface และไม่มี change management สำหรับ interface config

กรณีที่ 2 — ผู้ผลิตชิ้นส่วน: partner-to-partner interface ส่งคำสั่งซื้อรายวันไปยัง supplier tier 2

วันหนึ่ง encoding ของไฟล์ที่ส่งเปลี่ยน (แค่ encoding ไม่ใช่ logic) supplier system รับไฟล์ได้โดยไม่ error แต่อ่านได้แค่ 10% ของข้อมูล

3 วันต่อมา line ผลิตขาดชิ้นส่วน ไม่มีใครรู้ว่าทำไม

control gap: ไม่มี reconciliation ที่ interface ฝั่งรับไม่เคยตอบกลับว่ารับครบกี่ record

Reconciliation = control ที่ exam ออกบ่อย#

reconciliation control คือคำตอบของคำถาม: “ที่รับมา = ที่ส่งไป จริงมั้ย?”

ทำได้ 3 ทาง:

• Record count — นับจำนวน record ที่ส่ง vs ที่รับ ต้องตรงกัน
• Hash checksum — เช็คค่า hash ของไฟล์ ก่อนส่ง vs หลังรับ
• Acknowledgment — ฝั่งรับยืนยันกลับ ว่ารับ batch ID นี้ครบ

control นี้ดูเหมือน “เพิ่มงาน” แต่จริงๆ มันคือสิ่งเดียวที่ทำให้ interface ไม่ใช่แค่ “ส่งแล้วลืม”

MFT — เครื่องมือที่จัดการ person-to-person ให้กลับมาควบคุมได้#

Person-to-person transfer (อีเมลแนบไฟล์, share drive, SFTP แบบไม่มีใคร audit) คือรอยต่อที่ควบคุมยากที่สุด

MFT (Managed File Transfer) = ระบบที่บังคับให้การส่งไฟล์ทุกครั้งมี:

• การยืนยันตัวตนของผู้ส่ง/ผู้รับ
• encryption ระหว่างส่ง
• log ทั้ง action — ใครส่งอะไรให้ใคร เมื่อไหร่
• integrity check
• non-repudiation (ปฏิเสธไม่ได้ว่าไม่ได้ส่ง)

ในมุม auditor ถ้าองค์กรยัง rely บน email สำหรับส่งข้อมูล sensitive อยู่ → flag เป็น finding ทันที

Trap pattern ของข้อสอบเรื่อง interface#

ภาพในหัว: ครัวฝ่าย ที่ไม่ผ่านครัวกลาง#

ลองนึกถึงโรงแรมใหญ่ที่มี main kitchen ดูแลโดยเชฟใหญ่และทีม มีมาตรฐานทุกขั้นตอน มีตู้แช่แยก มี HACCP ครบ

แต่ฝ่ายจัดเลี้ยงรู้สึกว่าครัวกลางช้าเกินไป เวลามี request ด่วนตอน 2 ทุ่ม

ฝ่ายจัดเลี้ยงเลยตั้งครัวเล็กของตัวเอง ใน room ข้างๆ อุปกรณ์ไม่ครบ ไม่มีตู้แช่แยก ไม่มี HACCP ไม่มีคนตรวจ

แต่มันทำงานได้ เร็ว ทันใจ ลูกค้าได้ของ

จนกระทั่งวันหนึ่ง มีลูกค้ากลุ่มหนึ่งติดเชื้อ salmonella

นี่แหละคือ Shadow IT ในรูปแบบ analogy เกิดเพราะระบบทางการช้าเกินไป แก้ปัญหาเฉพาะหน้าได้ แต่อยู่นอก governance ทั้งหมด

EUC vs Shadow IT — แยกให้ชัด#

ทั้งคู่มีรากเดียว: business ต้องการความเร็ว/ความยืดหยุ่นที่ official IT ให้ไม่ได้

ตัวอย่างที่เห็นบ่อย#

EUC ที่ชลบุรี: ฝ่าย HR ของโรงงานสร้าง Excel ตามค่า OT พนักงาน เพราะ HRMS ทางการดึง report ช้า

3 ปีผ่านไป Excel มี 50,000 row, มี macro ซับซ้อน, ผู้สร้างคนเดียวที่เข้าใจ

วันที่ผู้สร้างลาออก ไม่มีใคร maintain ได้เลย

ปีถัดมา auditor เจอว่า formula error คำนวณ OT ผิดมา 6 เดือน บริษัทต้องชดเชย/เรียกคืน OT หลายล้านบาท

control gap:

• ไม่มี version control / change management ของ Excel
• ไม่มี backup / disaster recovery
• ไม่มี documentation
• ไม่มี second person ตรวจ formula

Shadow IT ที่กรุงเทพ: หัวหน้าฝ่ายของโรงพยาบาลเอกชน สมัคร Google Drive ฟรี เพื่อ share consultation note กับแพทย์ผู้เชี่ยวชาญที่โรงพยาบาลอื่น

ผลลัพธ์: ชื่อ-ID-การวินิจฉัย-ยา ของผู้ป่วยอยู่บน server ของ Google นอกประเทศ นอก data governance ของโรงพยาบาล

ทีม PDPA compliance ทำ audit เจอ → critical finding ทันที

ทำไม “ห้าม” ไม่ใช่คำตอบ#

ปฏิกิริยาแรกของ IT/CISO หลายคน — “ออก policy ห้าม Shadow IT”

ผมว่านั่นแก้ไม่ได้หรอกครับ เพราะมัน treat symptom ไม่ใช่ root cause

Shadow IT มันเกิดเมื่อ — official IT ตอบสนองความต้องการ business ไม่ได้

ถ้า ban อย่างเดียว Shadow IT ก็ลงใต้ดินลึกขึ้น IT มองเห็นน้อยลงไปอีก ความเสี่ยงสูงขึ้นไม่ใช่ลด

วิธีที่ work กว่า:

1. Discovery — ใช้ tool หา cloud app ที่กำลังใช้ในองค์กร (CASB)
2. Triage — แต่ละ tool ที่เจอ = ban / sanction / replace
3. Sanction the safe ones — tool ที่ปลอดภัย + business ต้องการ → bring under official governance
4. Provide alternative — สำหรับ tool ที่ ban ต้องมี official tool แทน

Trap pattern ที่ exam ออก#

มุมผู้บริหาร#

คำถามที่ผมว่าผู้บริหารควรถามก่อนจะโกรธพนักงาน: “ทำไมพนักงานต้องหา workaround?”

ถ้าคำตอบคือ official tool ช้า ใช้ยาก ไม่ตอบ business need — นั่นคือสัญญาณว่า IT governance ของบริษัทตอบไม่ทันธุรกิจ

Shadow IT ในมุมหนึ่งคือ vote of no-confidence ใน IT department นั่นเอง

แก้ที่ root: ทำให้ official IT ตอบสนองดีขึ้น ความต้องการสร้าง shadow tool ก็จะลดลงเอง