Automation ขยายผลไม่ได้ ปัญหาไม่ได้อยู่ที่บอท แต่อยู่ที่ไม่มีคนและมาตรฐานมารองรับ

Citizen Developer คือพนักงานสายธุรกิจที่สร้างและดูแลระบบอัตโนมัติ (Automation) ขึ้นใช้เองผ่านเครื่องมือ Low-Code/No-Code ภายใต้กรอบที่ทีม IT อนุมัติไว้ และ Center of Excellence (COE) คือหน่วยงานกลางที่กำกับมาตรฐาน Governance ของระบบเหล่านั้นทั้งองค์กร สองแนวคิดนี้คือคำตอบที่องค์กรที่ “เคยทำ RPA แล้วแต่ไปต่อไม่ได้” กำลังมองหาครับ

บทความนี้จะพาดูว่า Automation ในงาน P2P และ O2C ทำอะไรได้จริง หลุมพรางที่มักเจอหลังเริ่มทำไปแล้ว และวิธีแก้ด้วยโมเดล Citizen Developer + COE เราจะไม่พูดถึงเครื่องมือว่าตัวไหนดีกว่าตัวไหน แต่จะโฟกัสที่โครงสร้าง “คน” และ “มาตรฐาน” ที่ขาดหายไปครับ

RPA + ERP ทำอะไรได้จริงใน P2P และ O2C?

ก่อนจะพูดเรื่องปัญหาการขยายผล เราขอโชว์ก่อนว่า Automation ในงาน Back-Office ทำอะไรได้จริงบ้าง ไม่ใช่แค่ “ลดขั้นตอน” แบบกว้างๆ แต่ลงรายละเอียดทีละจุดครับ

Procure-to-Pay (P2P): ตั้งแต่ขอซื้อถึงจ่ายเงิน

Order-to-Cash (O2C): จากคำสั่งซื้อสู่เงินเข้าบัญชี

พูดง่ายๆ คือ ทุกจุดที่ “คนนั่งคีย์ข้อมูลซ้ำๆ” หรือ “คนนั่งเทียบเอกสาร” คือจุดที่ RPA + IDP เข้ามาแทนได้ทันทีครับ

ทำ Automation ไปแล้ว แต่ทำไมขยายผลต่อไม่ได้?

นี่คือส่วนที่บทความ automation ส่วนใหญ่ไม่พูดถึงครับ สิ่งที่เกิดขึ้น หลังจาก เริ่มทำไปแล้ว จากประสบการณ์ที่ทีมเราเห็นมา หลายองค์กรมาติดที่หลุมพราง 3 ข้อนี้:

1. พึ่งพา Vendor มากเกินไป (External Dependency) ว่าจ้าง Outsource ทำ automation ทุกกระบวนการ สร้างภาระค่าใช้จ่ายระยะยาว และขาดความยืดหยุ่นเมื่อต้องปรับกระบวนการ 
2. คอขวดที่ทีม IT (IT Bottleneck) ทีม IT มีภาระพัฒนาระบบหลักอยู่แล้ว จึงตอบสนองความต้องการ automation ของทุกแผนกไม่ทัน 
3. ขาดมาตรฐานกลาง (Lack of Governance) แต่ละฝ่ายสร้างบอทเอง ไม่มีมาตรฐานร่วม พอระบบเปลี่ยน บอทพัง หรือเกิดช่องโหว่ด้านความปลอดภัย 

ปัญหานี้ไม่ได้เกิดเฉพาะในไทย งานวิจัยของ Deloitte ที่ Automation Anywhere นำมาอ้างอิงพบว่ามีองค์กรเพียงส่วนน้อยที่ขยาย RPA ไปถึงระดับหลักร้อยบอทในระบบจริง ส่วนใหญ่ยังติดอยู่ที่ pilot ไม่กี่จุด สาเหตุหลักสอดคล้องกับ 3 หลุมพรางข้างต้นทั้งหมดครับ

ถ้าใช้ Citizen Developer แล้วทีม IT จะไม่เกี่ยวเลยหรือ?

คำตอบตรงๆ คือ ไม่ใช่ครับ Citizen Developer ไม่ได้หมายถึง “ให้ทุกคนทำอะไรก็ได้” แต่หมายถึง พนักงานสายธุรกิจ (เช่น ทีมบัญชี จัดซื้อ HR) ที่เข้าใจกระบวนการของตัวเองดีที่สุดอยู่แล้ว ได้รับการ Upskill ด้วยเครื่องมือ Low-Code/No-Code ให้สร้างและดูแล automation เบื้องต้นได้เอง ภายใต้สภาพแวดล้อมที่ทีม IT อนุมัติไว้แล้ว

ตามคำนิยามของ Gartner: Citizen Developer คือผู้ใช้งานที่สร้างแอปพลิเคชันทางธุรกิจขึ้นใช้เองโดยใช้เครื่องมือและสภาพแวดล้อมที่ได้รับอนุมัติจากทีม IT ขององค์กร

ประโยชน์ที่เห็นชัด:

• ลดเวลาพัฒนา – ทีมธุรกิจไม่ต้องรอคิว IT ทุกครั้งที่อยากปรับกระบวนการ 
• ลดการพึ่งพา Vendor – องค์กรสร้างขีดความสามารถภายในได้เอง 
• เพิ่มความยืดหยุ่น – คนที่เข้าใจงานจริงเป็นคนสร้าง automation เอง ไม่ต้องอธิบายผ่านตัวกลาง

Gartner คาดการณ์ว่าสัดส่วนงานพัฒนาแบบ Low-Code ที่เกิดขึ้นนอกทีม IT จะเพิ่มขึ้นต่อเนื่อง เพราะทีม IT ส่วนใหญ่มีงานในมือมากกว่ากำลังที่จะรองรับไหว นี่ไม่ใช่เรื่องของอนาคต แต่กำลังเกิดขึ้นแล้วครับ

แล้ว COE ทำหน้าที่อะไร ถ้ามี Citizen Developer แล้ว?

การมี Citizen Developer โดยไม่มี COE เหมือนให้ทุกคนขับรถได้แต่ไม่มีกฎจราจร — อาจเวิร์คในช่วงแรก แต่ยิ่งมีคนเยอะยิ่งวุ่นวายครับ 

Center of Excellence (COE) คือหน่วยงานกลางที่กำหนด Governance เพื่อให้ทุกฝ่ายทำงานบนมาตรฐานเดียวกัน โดยมี 4 บทบาทหลัก: 

พูดสั้นๆ: Citizen Developer ทำให้ขยายผลได้เร็วขึ้น, COE ทำให้ขยายผลได้อย่างปลอดภัยและยั่งยืน ทั้งสองต้องทำงานคู่กันครับ

สรุป: Road Map ยกระดับ Back-Office ที่ยั่งยืนต้องมี 3 ขา

การเปลี่ยนผ่านสู่ Autonomous Back-Office ไม่ได้เป็นเรื่องเทคโนโลยีอย่างเดียว แต่ต้องผสมผสาน 3 ด้าน:

1. Process – ระบุกระบวนการที่ automation ทำได้จริง (เริ่มจาก P2P/O2C ที่ ROI ชัด) 
2. People – Upskill พนักงานสายธุรกิจให้เป็น Citizen Developer 
3. Governance – ตั้ง COE เป็นแกนกลางกำหนดมาตรฐานและวัดผล 

ถ้าองค์กรของคุณเคยเริ่มทำ automation ไปแล้วแต่ไม่แน่ใจว่าจะขยายผลต่ออย่างไรให้ยั่งยืน หรือกำลังเริ่มมองหาว่าจะวาง Citizen Developer และ COE อย่างไรให้เหมาะกับบริบทขององค์กร

ZyGen ยินดีคุยด้วยเพื่อช่วยประเมินความพร้อมของ Automation ที่มีอยู่วันนี้เพียงกรอกฟอร์มด้านล่างครับ