บทนำ
หลายองค์กรลงทุนกับระบบ RPA เพื่อเพิ่มประสิทธิภาพการทำงาน ลดงานซ้ำซ้อน และลดภาระของพนักงาน
แต่เมื่อใช้งานจริงในวงกว้าง กลับพบปัญหาใหม่ที่ไม่ค่อยถูกพูดถึง
นั่นคือ
CoE (Center of Excellence) และทีม RPA กลายเป็นคอขวดขององค์กรเสียเอง
ทุกการสร้าง Automation ใหม่
ทุกการแก้ไข Automation เดิม
ทุกการรันซ้ำเมื่อเกิดปัญหา
ทุกการขอเปลี่ยนแปลงกระบวนการ
ล้วนต้องผ่านทีมกลาง
ยิ่งองค์กรเติบโตมากขึ้น จำนวน Automation มากขึ้น และจำนวนผู้ใช้งานเพิ่มขึ้น ภาระงานของทีมกลางก็เพิ่มขึ้นตามไปด้วย
จากประสบการณ์การทำงานด้านบัญชี การเงิน และ SAP ผู้เขียนจึงเริ่มตั้งคำถามว่า
หากเจ้าของงานสามารถสร้าง ใช้งาน และดูแล Automation ของตนเองได้ จะช่วยลดคอขวดขององค์กรได้หรือไม่
คำถามนี้กลายเป็นจุดเริ่มต้นของการออกแบบแนวทางใหม่ที่เรียกว่า
Personalized RPA หรือ Decentralized Automation
ปัญหาที่พบจากแนวทางแบบรวมศูนย์
แนวทางการบริหาร Automation แบบรวมศูนย์มีข้อดีในด้านมาตรฐานและการควบคุม
แต่ในทางปฏิบัติกลับพบข้อจำกัดหลายประการ
1. การรอคิวพัฒนา
เมื่อมีงานใหม่เกิดขึ้น ผู้ใช้งานต้องส่งความต้องการให้ทีม RPA หรือ CoE พัฒนาให้
หากมีคำขอจำนวนมาก งานที่สำคัญอาจต้องรอหลายสัปดาห์หรือหลายเดือน
2. การรอแก้ไขเมื่อเกิดปัญหา
ในช่วงปิดบัญชีหรือจัดทำรายงาน หาก Automation เกิดปัญหา ผู้ใช้งานไม่สามารถแก้ไขได้เอง ต้องรอทีมกลางเข้ามาช่วยเหลือ
3. การขยายกำลังประมวลผลทำได้ยาก
เมื่อจำเป็นต้องรันงานจำนวนมากในเวลาจำกัด มักต้องพึ่งพา Bot เพิ่มเติม License เพิ่มเติม หรือทรัพยากรจากหน่วยงานกลาง
4. ผู้ใช้งานกลายเป็นผู้รอ
แม้เจ้าของงานจะเข้าใจกระบวนการมากที่สุด แต่กลับไม่มีอำนาจในการปรับปรุง Automation ของตนเอง
แนวคิดในการออกแบบระบบ
แทนที่จะสร้าง Automation แบบรวมศูนย์
ระบบนี้ถูกออกแบบภายใต้แนวคิด
“เจ้าของงาน คือ เจ้าของ Automation”
ผู้ใช้งานสามารถ
- สร้าง Automation เอง
- ใช้งานเอง
- ปรับปรุงเอง
- แก้ไขเอง
- ขยายการใช้งานเอง
โดยไม่จำเป็นต้องรอหน่วยงานกลาง
แนวทางนี้ช่วยเปลี่ยนบทบาทของพนักงานจากผู้ใช้งาน มาเป็นผู้พัฒนาและเจ้าของกระบวนการในเวลาเดียวกัน
การออกแบบเพื่อรองรับ Parallel Automation
หนึ่งในเป้าหมายสำคัญของระบบคือ
การกำจัดคอขวดด้านกำลังประมวลผล
แนวทางที่ใช้คือการออกแบบให้สามารถทำงานแบบ Parallel ได้ตั้งแต่ต้น
หากต้องการเพิ่มกำลังประมวลผล ผู้ใช้งานสามารถ
- คัดลอกไฟล์
- กำหนด Parameter ที่แตกต่างกัน
- กระจายงานไปยังหลายเครื่อง
- รันพร้อมกันได้ทันที
โดยไม่ต้องรอ Bot จากส่วนกลาง
ไม่ต้องจอง Queue
และไม่ต้องเพิ่ม Infrastructure ที่ซับซ้อน
ตัวอย่างผลลัพธ์จริง
หนึ่งในงานที่ใช้งานจริงเกี่ยวข้องกับการประมวลผลข้อมูลผ่าน SAP หลายชุดข้อมูล
เดิมกระบวนการดังกล่าวใช้เวลาประมาณ 7 ชั่วโมง
เมื่อออกแบบใหม่ให้สามารถทำงานแบบ Parallel ผ่าน SAP หลาย Instances พร้อมกัน
เวลาการทำงานลดลงเหลือประมาณ 30 นาที
คิดเป็นการลดเวลาทำงานมากกว่า 90%
และเพิ่มความสามารถในการตอบสนองต่อสถานการณ์เร่งด่วนในช่วงปิดบัญชีได้อย่างมีนัยสำคัญ
ระบบที่พัฒนาขึ้น
ตลอดระยะเวลากว่า 4 ปี ระบบได้รับการพัฒนาอย่างต่อเนื่องจนกลายเป็น Automation Platform ภายในองค์กร
ประกอบด้วยความสามารถสำคัญ เช่น
การจัดการ SAP หลาย Session
รองรับการทำงานกับ SAP หลาย Instances พร้อมกัน
สามารถ
- ดึงข้อมูล
- นำข้อมูลเข้า
- ประมวลผลธุรกรรม
- สร้างรายงาน
ได้ในระบบเดียว
การสร้าง Task แบบ Self-Service
ผู้ใช้งานสามารถสร้าง Automation ใหม่ได้ด้วยตนเอง
โดยใช้หน้าจอและแบบฟอร์มที่เตรียมไว้
ไม่จำเป็นต้องแก้ไขโค้ดโดยตรง
การจัดการ Version และ Upgrade
มีระบบตรวจสอบ Version และ Upgrade ภายในตัว
สามารถ
- ดาวน์โหลดเวอร์ชันล่าสุด
- สำรองข้อมูลเดิม
- ย้ายองค์ประกอบสำคัญ
- สร้างไฟล์เวอร์ชันใหม่
ได้โดยอัตโนมัติ
การจัดเก็บ Log
ระบบบันทึกข้อมูลสำคัญลงฐานข้อมูล SQL แบบรวมศูนย์
เช่น
- ผู้ใช้งาน
- เวลาเริ่มต้น
- เวลาสิ้นสุด
- สถานะการทำงาน
- ข้อผิดพลาดที่เกิดขึ้น
Dashboard สำหรับผู้บริหาร
ข้อมูลจาก Log ถูกนำไปวิเคราะห์และแสดงผลผ่าน Power BI
ช่วยให้สามารถติดตาม
- งานที่ล้มเหลว
- งานที่ต้องการความช่วยเหลือ
- ปัญหาที่เกิดซ้ำ
- ปริมาณงานของพนักงาน
- โอกาสในการพัฒนาทักษะของทีมงาน
ได้จากข้อมูลจริง
ผลลัพธ์ที่เกิดขึ้น
ปัจจุบันระบบมีผู้ใช้งานจริงมากกว่า 100 คน
ผู้ใช้งานแต่ละคนสามารถสร้าง Automation ได้หลายงานตามลักษณะงานของตนเอง
จำนวน Automation ที่ถูกสร้างขึ้นจึงมีมากกว่าจำนวนผู้ใช้งานหลายเท่า
แนวทางนี้ช่วยให้องค์กรได้รับประโยชน์ในหลายด้าน
ด้านประสิทธิภาพ
- ลดเวลาการทำงาน
- ลดเวลารอคิว
- เพิ่มความเร็วในการแก้ปัญหา
- รองรับการทำงานแบบ Parallel
ด้านต้นทุน
- ไม่ต้องจัดตั้งทีม RPA ขนาดใหญ่
- ไม่ต้องใช้ Control Room
- ไม่ต้องซื้อ License เพิ่มตามจำนวนผู้ใช้งาน
- ใช้ทรัพยากรที่องค์กรมีอยู่แล้ว
ด้านบุคลากร
- พนักงานสามารถพึ่งพาตนเองได้มากขึ้น
- เกิดการ Upskill และ Reskill จากการใช้งานจริง
- ลดการพึ่งพาหน่วยงานกลาง
- สร้างความเป็นเจ้าของกระบวนการทำงาน
บทเรียนที่ได้รับ
Automation ไม่จำเป็นต้องรวมศูนย์เสมอไป
สำหรับงานจำนวนมาก โดยเฉพาะในสายงานบัญชี การเงิน และงานปฏิบัติการที่ต้องการความรวดเร็ว
การกระจายอำนาจให้เจ้าของงานสามารถสร้างและดูแล Automation ของตนเองได้
อาจสร้างความคล่องตัวได้มากกว่าการรวมทุกอย่างไว้ที่ CoE
ในบางสถานการณ์
การลดคอขวดขององค์กรอาจสำคัญกว่าการเพิ่มจำนวน Bot
และการออกแบบระบบให้รองรับการทำงานแบบ Parallel อาจสร้างผลลัพธ์ได้มากกว่าการลงทุนด้านเทคโนโลยีเพิ่มเติม
สรุป
Case Study นี้แสดงให้เห็นว่า การแก้ปัญหา Automation ไม่ได้เริ่มต้นจากการเลือกเครื่องมือที่ทันสมัยที่สุด
แต่เริ่มต้นจากการทำความเข้าใจคอขวดที่แท้จริงขององค์กร
เมื่อเจ้าของงานสามารถสร้าง ใช้งาน และพัฒนา Automation ได้ด้วยตนเอง
Automation จะไม่ใช่เพียงเครื่องมือช่วยทำงาน
แต่จะกลายเป็นกลไกสำคัญในการเพิ่มความคล่องตัว ลดคอขวด และสร้างศักยภาพในการเติบโตขององค์กรในระยะยาว
Case Study ที่น่าสนใจ
- Case Study: เปลี่ยนการติดตามเอกสาร Purchase-to-Pay ให้เป็นระบบวิเคราะห์ข้อมูลด้วย Excel VBA
- Case Study: Note to Financial เมื่อ Excel กลายเป็นระบบจัดทำหมายเหตุประกอบงบการเงินระดับองค์กร
- Case Study : Bank Statement Conversion Automation
- Case Study: ระบบ Month End Monitoring อัตโนมัติด้วย Excel VBA
- Case Study: ทำไม Automation ที่ดีที่สุดถึงไม่ต้องการ CoE