หลายปีก่อน ผมได้รับโจทย์สำคัญจากระบบงานของ Shared Services ในกลุ่มธุรกิจขนาดใหญ่แห่งหนึ่ง
โจทย์นั้นไม่ใช่แค่ “เขียนโปรแกรมให้ทำงานได้”
แต่คือการทำให้ “รายได้ขององค์กร” เดินต่อได้ทุกสิ้นเดือน
จุดเริ่มต้นของปัญหา
องค์กรมีการรวมทีมบัญชีจากหลายบริษัทเข้ามาอยู่ในศูนย์กลางเดียว
โมเดลนี้เรียกว่า Shared Services
หน้าที่ของหน่วยงานนี้คือทำงานบัญชีให้บริษัทลูกทั้งหมด
และรายได้ของหน่วยงานก็มาจาก “ค่าบริการทางบัญชี”
ทุก Transaction ที่เกิดขึ้นจะมีต้นทุนแตกต่างกัน เช่น
- งานที่ผ่านพนักงานระดับทั่วไป ราคาหนึ่ง
- งานที่ต้องผ่าน Senior หรือ Manager ราคาสูงขึ้น
- บางงานผ่านหลายขั้นตอน หลายฝ่าย หลายระดับ
สุดท้ายองค์กรจำเป็นต้องรู้ว่า
“แต่ละบริษัทต้องถูก Charge ค่าใช้จ่ายเท่าไร”
ปัญหาคือ…
Transaction มีจำนวนมหาศาล
และระบบเดิมที่พัฒนาโดย Vendor ใช้เวลาประมวลผลนานมาก
ทุกสิ้นเดือนจะต้องมีทีมเข้ามา Support ระบบโดยเฉพาะ
สิ่งที่ผมสังเกตเห็นคือ
- มีการสร้าง Table ใหม่ทุกเดือน
- ตั้งชื่อตาม Period
- Query จำนวนมากถูกผูกกับตารางเฉพาะเดือน
- การประมวลผลใช้เวลาระดับ “วัน”
ในมุมของผม
นี่คือสัญญาณของระบบที่ “ขยายต่อยาก” และ “ดูแลยากมาก”
แนวคิดที่ผมใช้ในการออกแบบใหม่
ผมเริ่มจากคำถามง่าย ๆ
“ถ้าระบบพังวันนี้ เราจะทำให้มันกลับมาทำงานได้เร็วที่สุดอย่างไร”
คำตอบจึงกลายเป็นแนวคิดหลักของระบบใหม่
1. Excel คือ UI ที่ดีที่สุดสำหรับคนทำงาน
ผมไม่ได้สร้าง Web Application
ผมเลือกใช้ Excel เป็น Front End
เพราะผู้ใช้งานคุ้นเคยอยู่แล้ว
ไม่ต้องเสียเวลาเรียนรู้ใหม่
สิ่งที่ Excel ทำหน้าที่คือ
- เป็นหน้าจอเลือก Period
- Upload Template
- กำหนด Logic บางส่วน เช่น Rate หรือ Allocation
- กดปุ่ม Submit เพื่อส่งข้อมูลเข้าระบบ
ผมใช้ Ribbon XML สร้างเมนูเฉพาะของระบบโดยตรง
เช่น
- FTE
- PIT
- FTE Customize
- Submit Data
ทั้งหมดถูกควบคุมด้วย VBA เพียงชุดเดียว
ผู้ใช้งานจึงรู้สึกเหมือนกำลังใช้ Application จริง ๆ
ทั้งที่เบื้องหลังคือ Excel Workbook
2. Database ต้อง Stateless และย้ายระบบได้ทันที
ผมออกแบบให้ระบบมีองค์ประกอบสำคัญเพียง 2 อย่าง
- Excel UI
- ชุดไฟล์ .sql
หาก Server เดิมมีปัญหา
สิ่งที่ต้องทำมีเพียง
- เปลี่ยน Connection String ใน VBA
- รันไฟล์ .sql ทั้งหมด
ระบบจะกลับมาทำงานได้ทันที
ไม่มี Dependency ซับซ้อน
ไม่มีการ Deploy แบบหนัก ๆ
ไม่มี Middleware จำนวนมาก
แนวคิดนี้ทำให้ระบบมีความ “ทนทาน” สูงมาก
3. ใช้ SQL Server ทำงานในสิ่งที่มันเก่งที่สุด
แทนที่จะดึงข้อมูลมหาศาลมา Loop ใน Excel
ผมเลือกให้ SQL Server ทำงานหนักแทน
ข้อมูลจำนวนมากถูกดึงจาก Data Warehouse โดยตรง
ผ่าน Stored Procedure และ TVP (Table-Valued Parameter)
TVP คือหัวใจสำคัญของความเร็ว
เพราะมันสามารถส่งข้อมูลจำนวนมากเข้า SQL Server ได้ในครั้งเดียว
โดยไม่ต้อง Insert ทีละ Row
สิ่งที่เคยใช้เวลาหลายชั่วโมง
ถูกลดลงเหลือเพียงไม่กี่นาที
สิ่งที่ผมให้ความสำคัญมากกว่าความ “ล้ำ”
หลายครั้งคนมองระบบจากหน้าตา
แต่สำหรับผม
ระบบที่ดีต้องตอบคำถามเหล่านี้ได้
ถ้าคนพัฒนาหายไป ระบบยังรอดไหม
ผมพยายามทำให้ทุกอย่างเรียบง่ายที่สุด
- Stored Procedure แยกชัดเจน
- VBA แบ่งตามหน้าที่
- ไม่มี Framework ซับซ้อน
- ไม่มี Service จำนวนมาก
เพราะผมเชื่อว่า
ความเรียบง่ายคือความเสถียรระยะยาว
ถ้าระบบล่มตอนสิ้นเดือนจะเกิดอะไรขึ้น
นี่คือระบบระดับ “Critical”
เพราะถ้าคำนวณ Chargeback ไม่ทัน
รายได้ของ Shared Services จะเข้าช้า
และจะกระทบต่อองค์กรทันที
ดังนั้นเป้าหมายของผมจึงไม่ใช่แค่ “ระบบต้องเร็ว”
แต่ต้อง
- เสถียร
- กู้คืนง่าย
- ย้ายเครื่องได้เร็ว
- และต้องไม่ล่มเกิน 1 วัน
เบื้องหลังของโค้ดที่ดูธรรมดา
ถ้ามองจาก VBA
หลายคนอาจเห็นเพียงการเปิดไฟล์ Excel แล้ว Loop ข้อมูล
แต่สิ่งที่ซ่อนอยู่จริง ๆ คือแนวคิดด้าน Architecture
เช่น
- แยก Template ตาม Business Logic
- ใช้ Dynamic Ribbon UI
- ใช้ Generic Function สำหรับส่งข้อมูลเข้า SQL
- ออกแบบ Stored Procedure ให้ Reuse ได้
- ลด Coupling ระหว่าง Front End และ Database
ทั้งหมดนี้ทำให้ระบบถูกใช้งานมายาวนาน
โดยแทบไม่ต้องพึ่ง Vendor อีกเลย
บทเรียนสำคัญที่ผมได้จากระบบนี้
ผมค้นพบว่า
ระบบที่มีคุณค่าจริง
ไม่จำเป็นต้องใช้ Technology ที่ซับซ้อนที่สุด
บางครั้ง
Excel + VBA + SQL Server
ก็สามารถสร้างระบบระดับองค์กรได้
หากเข้าใจปัญหาทางธุรกิจอย่างแท้จริง
สุดท้ายแล้ว
ผู้ใช้งานไม่ได้สนใจว่าเราใช้ภาษาอะไร
แต่เขาจะจำได้ว่า
- ระบบเร็วขึ้นไหม
- งานง่ายขึ้นไหม
- องค์กรเดินต่อได้ไหม
และสำหรับผม
นี่คือความหมายที่แท้จริงของคำว่า “System Design”