[Technology] The Road to Implement RPA Project with Agile

ในโลกแห่งการทำงานของพนักงานในองค์กรต่างๆ ไม่ว่าจะเป็นธุรกิจการเงิน/ธนาคาร, ธุรกิจการประกันภัย/ประกันชีวิต, ธุรกิจการขนส่ง/การคลัง หรือธุรกิจอื่นๆอีกมากมาย พบว่าในแต่ละวันพนักงานจะต้องพบเจอกับงานที่น่าเบื่อและซ้ำซาก ยกตัวอย่าง กระบวนการจ่ายเงินเดือน กระบวนการออกใบแจ้งหนี้ กระบวนการเรียกเก็บเงิน เป็นต้น จากการสำรวจเวลาในการทำงานขององค์กรธนาคารแห่งหนึ่ง พบว่า ใน 1 วัน พนักงาน 1 คน ใช้เวลากับการทำงานที่น่าเบื่อไปถึง 32% สิ่งเหล่านี้จึงก่อให้เกิดการนำเทคโนโลยี RPA (Robotic Process Automation) มาใช้กันอย่างจริงจังและแพร่หลาย

ลองนึกภาพว่ามีหุ่นยนต์บางตัวสามารถทำงานที่น่าเบื่อเพื่อคุณได้ นั่นคือแนวคิดหลักที่อยู่เบื้องหลัง RPA หุ่นยนต์เหล่านี้ไม่ใช่หุ่นยนต์ทางกายภาพ พวกมันคือหุ่นยนต์ซอฟแวร์ที่สามารถดำเนินอัตโนมัติเพื่อปลดปล่อยแรงงานมนุษย์จากงานซ้ำซาก และพวกเขาสามาถใช้เวลากับงานที่น่าตื่นเต้นและมีคุณค่ามากขึ้น นอกจากนั้นยังสามารถเพิ่มประสิทธิภาพการทำงาน, ลดต้นทุน, ลดความเสี่ยง ไปจนถึงเร่งสร้างนวัตกรรม ส่งเสริมการเติบโตขององค์กร

RPA ถือเป็นการเปลี่ยนแปลงทางดิจิทัล (Digital Transformation) แก่นหลักของการริเริ่ม RPA คือการปล่อยให้มนุษย์เป็นมนุษย์ หรือ ‘สร้างหุ่นยนต์เพื่อให้มนุษย์ไม่ต้องเป็นหุ่นยนต์’ เพื่อปลดปล่อยศักยภาพอันไร้ขอบเขตของผู้คนนั่นเอง

Mission

1) Starting

­การเริ่มต้นขับเคลื่อนการเปลี่ยนแปลงทางดิจิทัล เริ่มจากการรวมทีมและเผยแพร่แนวคิดของ RPA ให้เป็นที่รู้จักภายในองค์กร สำหรับการรวมทีมนั้นในที่นี้จะเรียกว่า CoE (Robotic Center of Excellence) ซึ่งในทีมจะประกอบไปด้วย RPA Developers, RPA Solution Architects และ RPA Infrastructure Engineers จากนั้นจึงเริ่มจัดสัมนาภายใน, เอกสารประชุมเชิงปฏิบัติการ, การฝึกฝนอบรมเกี่ยวกับ RPA เพื่อให้ข้อมูลแก่พนักงาน

ในขณะเดียวกันการเริ่มต้นโครงการนำร่อง (Pilot Project) ต้องแสดงให้เห็นถึงคุณค่าสูงสุดของ RPA อย่างเป็นรูปธรรม โครงการนำร่องนี้ควรเป็นกระบวนการที่มีศักยภาพสูง ในที่นี้หมายถึง ‘จำนวนปริมาณงานสูง ประหยัดต้นทุน/เวลาได้มาก รวมทั้งมีความซับซ้อนน้อย’ นั่นเอง ดังนั้นโครงการนำร่องนี้จึงเป็นเครื่องมือสร้างแรงบันดาลใจให้กับพนักงาน และยังทำให้เกิดความคุ้นเคยกับ RPA มากขึ้น รวมถึงลดแรงต้านที่อาจจะเกิดขึ้นได้ภายในองค์กร

2) Discovery

ในตอนแรกนั้นควรมุ่งเน้นไปที่กระบวนการภายในแผนก เพื่อให้แผนกหนึ่งทำงานได้โดยอัตโนมัติ (เช่น การเงิน, ทรัพยากรบุคคล) เนื่องจากการทำงานของระบบอัตโนมัติภายในแผนกมักจะลดเวลาประมาณ 20–30% ของเวลาทั้งหมด ในขณะที่ระบบอัตโนมัติข้ามแผนกนั้นอยู่ที่ประมาณ 7–15% ในแง่ของการลดเวลานั้น สิ่งเหล่านี้น้อยกว่าที่คาดหวังของคนทั่วไปมาก

ต่อไปคือทีม CoE จะต้องรักษาปริมาณงาน RPA (Backlog) อย่างต่อเนื่อง การค้นหากระบวนการที่มีโอกาสนำมาทำเป็นระบบอัตโนมัติมี 2 วิธี (1) Top-down Approach ซึ่งอาจจะหาได้จาก Logs ของแอปพลิเคชันต่างๆ เช่น SAP (2) Bottom-up Approach เป็นวิธีที่รวบรวมแนวคิดมาจากกลุ่มผู้ทำงาน แล้วนำมาจัดทำเป็นเอกสารการออกแบบกระบวนการ (Process Design Documents: PDD) จากนั้นจึงนำมาจัดลำดับสำคัญตามมูลค่าทางธุรกิจที่ได้รับ ซึ่งก็คือการประหยัดต้นทุนและเวลานั่นเอง

3) Model

หลังจากที่ได้ทีม CoE ได้จัดความสำคัญของ Backlog แล้ว จึงสามารถนำ Backlog นั้นๆมาพัฒนาตามลำดับ ซึ่งการพัฒนามีอยู่ 2 ประการด้วยกัน ประการที่หนึ่ง คือ ทีม CoE ทำการพัฒนาเอง ซึ่งทำได้ตั้งแต่กระบวนการที่เรียบง่ายไปจนถึงมีความซับซ้อน หรือกระบวนการภายในแผนกไปจนถึงภายนอกแผนก สำหรับประการที่สองคือ พนักงานภายในแผนกนั้นสามารถพัฒนาได้เอง ซึ่งเราจะเรียกพนักงานนี้ว่า Citizen Developers ดังนั้นทีม CoE ไม่เพียงแต่พัฒนาด้วยตนเอง แต่ยังสามารถส่งมอบให้กับ Citizen Developers ได้พัฒนาด้วย ทั้งนี้เพื่อให้เกิดความใกล้ชิดกันภายในองค์กร และยังทำให้เกิดการเปลี่ยนแปลงทางดิจิทัลได้อย่างรวดเร็วขึ้น

กระบวนการส่งมอบงานแบบคลาสสิคและเป็นที่รู้จักโดยทั่วไป คือ Waterfall-Model ซึ่งแต่ละเฟสของโมเดลนั้นประกอบไปด้วย Design, Develop, Test, Deploy และ Monitor ตามลำดับ การส่งมอบงานจะไม่วนซ้ำและไม่มีการค่อยๆพัฒนาเพิ่มเข้าไป งานถูกไหลผ่านไปในทิศทางเดียวตามเอกสาร PDD หลังจากที่งานทั้งหมดเสร็จก็จะถูก Release ออกไปครั้งเดียว

สำหรับกระบวนการส่งมอบงานแบบ Agile นั้นเริ่มเป็นที่รู้จักกันในปี 2001 ซึ่งมีแถลงการณ์หลักการ 12 ประการ และ Core Values 4 ข้อ ดังนี้ (1) การให้ความสำคัญกับความสัมพันธ์ระหว่างบุคคลและการมีปฏิสัมพันธ์กันในทีม มากกว่าเครื่องมือและขั้นตอน (2) การให้ความสำคัญกับ Software Product ที่ทำงานได้จริง มากกว่าการให้ความสำคัญกับการทำเอกสาร (3) การให้ความสำคัญกับการทำงานร่วมกันกับลูกค้า มากกว่าการต่อรองให้เป็นไปตามสัญญา (4) การให้ความสำคัญกับการตอบรับการเปลี่ยนแปลง มากกว่าแผนที่วางไว้ ในการนำ Agile มา Implement ใน RPA นั้นไม่ได้หมายถึงเทคนิค แต่เป็นปรัชญาที่จะช่วยให้ทีมส่งมอบงานได้อย่าง Proactive มากขึ้น

การส่งมอบงานแบบ Agile คือ การผสมผสานระหว่าง การส่งมอบงานแบบวนซ้ำค่อยๆแก้ไขปรับปรุง และการค่อยๆพัฒนา Feature ต่างๆเพิ่มเข้าไป ดังนั้นการส่งมอบงานในลักษณะนี้อาจไม่จำเป็นต้องตรงตามเอกสาร PDD ในตอนแรก แต่จะค่อยๆเพิ่มให้ระบบอัตโนมัติมีความสมบูรณ์และตรงกับความต้องการของผู้ใช้งานในการวนซ้ำครั้งถัดไป

กุญแจสำคัญในการส่งมอบระบบอัตโนมัติ RPA ที่แท้จริงนั้น คือ การผลิตหุ่นยนต์ทำงานบ่อยๆ ส่งมอบได้บ่อยๆ เพื่อตอบสนองต่อความต้องการของผู้ใช้งานได้บ่อยขึ้น สำหรับผู้ใช้งานที่ได้รับนั้นต้องเข้าใจตรงกันกับผู้ผลิตว่า ระบบอัตโนมัติที่ได้รับนั้นยังไม่ใช่ Final Version และระบบจะมีการพัฒนาฟังก์ชันการทำงานได้ตลอดเวลา หรือกล่าวอีกนัยหนึ่งว่า หุ่นยนต์ไม่จำเป็นต้องสมบูรณ์แบบ แต่จะมีการพัฒนาให้ฉลาดขึ้นเรื่อยๆ

4) Transition

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

ไม่ว่าจะเป็นแนวคิดแบบใด พยายามอย่ากำหนดแนวทางปฏิบัติและหลักการต่างๆ ให้กับผู้ที่ไม่เต็มใจ ต้องท่องจำอยู่เสมอว่าคุณไม่สามารถโน้มน้าวใจใครได้ แต่คุณสามารถให้ข้อมูลที่ถูกต้องแก่ผู้คนได้ สิ่งเหล่านี้จะเป็นเครื่องมือที่ดีให้กับคุณเอง สำหรับบทความถัดไป ผู้เขียนจะกล่าวถึง Approach to RPA Agile