โพรเซสงานอัติโนมัติ ภาคปฏิบัติ (Practical Process Automation)

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

ซอฟต์แวร์ที่ทำหน้าที่นี้ ที่จริงแล้วมีหลายรูปแบบ ซึ่งจะแตกต่างกันไปตามกลุ่มผู้ใช้งานและเทคโนโลยีที่ใช้ เช่น ในองค์กรขนาดใหญ่จะใช้ซอฟต์แวร์ที่เรียกว่า BPM หรือ Business Process Management และในบริษัทที่เล็กลงมา อาจจะใช้ซอฟต์แวร์ทั่ว ๆ ไปที่เรียกว่า Workflow engine และในบริษัทเทคโนโลยีสมันใหม่ที่ใช้สถาปัตยกรรมแบบ microservice ก็จะใช้ซอฟต์แวร์ที่เรียกว่า Process Orchestration (การเรียบเรียงโพรเซสงาน) แต่ไม่ว่าจะเรียกว่าอะไร ซอฟต์แวร์เหล่านี้ก็มีพื้นฐานการทำงานไม่ต่างกัน

ไม่นานมานี้ ผมได้มีโอกาสอ่านหนังสือที่ชื่อว่า “Practical Process Automation” หนังสือเล่มนี้ได้กล่าวถึงสิ่งต่าง ๆ ที่เกี่ยวข้องกับโพรเซสงาน โดยเน้นไปในเชิงปฏิบัติ ที่ค่อนข้างครอบคลุมรูปแบบต่าง ๆ ที่ผมกล่าวไปข้างต้น

ในบทความนี้ ผมเลยอยากนำสิ่งที่ผมได้เรียนรู้จากหนังสือเล่มนี้ ร่วมกับความรู้จากประสบการณ์ทำงานของผม โดยแบ่งออกเป็นหัวข้อ ดังนี้

โพรเซสอัติโนมัติ คืออะไร

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

ทำไมถึงต้องทำ โพรเซสอัติโนมัติ

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

เครื่องมือในการทำโพรเซสอัติโนมัติ ที่ดี

จากที่ผมได้กล่าวไปข้างต้น เราต้องมีเครื่องมือที่จะช่วยสร้างโพรเซสแบบอัติโนมัติ เครื่องมือที่ดีนั้นจะต้องสามารถเข้าใจและต้องสามารถสร้างหรือแก้ไขโพรเซสได้ง่าย อีกทั้ง จะต้องมีความครบถ้วนที่จะสามารถรองรับความต้องการในการสร้างโพรเซสในโลกความเป็นจริง ที่มีความซับซ้อนและเต็มไปด้วยข้อยกเว้นต่าง ๆ นาๆ เครื่องมือที่ดีจะต้องรองรับการใช้งานทั่วไป เช่น การเริ่มต้นทำงานจากเหตุการณ์ที่เกิดขึ้นในระบบ (event) หรือ เริ่มต้นทำงานจากการตั้งเวลา (timer) รองรับการสร้างโพรเซสย่อย หรือ การวนลูป ผมพบว่าเครื่องมือที่รองรับการร่างโพรเซสด้วยสัญลักษณ์ BPMN นั้น จะช่วยตอบสนองความต้องการเหล่านี้ได้ค่อนข้างครบ

โพรเซสอัติโนมัติ ในระบบแบบกระจายศูนย์ (microservice)

ไมโครเซอร์วิส (microservice) ถือเป็นระบบแบบกระจายศูนย์ที่ได้รับความนิยมอย่างมาก ในองค์กรทางด้านเทคโนโลยีสมัยใหม่ ส่วนหนึ่งเป็นเพราะความต้องการที่จะสร้างซอฟต์แวร์หน่วยเล็ก ๆ ที่สามารถทำงานได้ด้วยตัวเอง (modular) เพื่อรองรับกับความซับซ้อนและการเปลี่ยนแปลงที่รวดเร็วในโลกปัจจุบัน ซึ่งส่งผลต่อความอยู่รอดของธุรกิจ ปัญหาหนึ่งที่เป็นผลจากการใช้สถาปัตยกรรมนี้ก็คือ การที่เซอร์วิสต่าง ๆ จะต้องสื่อสารข้ามเครือข่ายมากยิ่งขึ้นซึ่งต่างจากสถาปัตยกรรมแบบรวมศูนย์​ (monolithic)

เราสามารถแก้ปัญหานี้โดยการใช้การสื่อสารผ่านข้อมูลเหตุการณ์ (event-driven) ระหว่างเซอร์วิส ร่วมกับเครื่องมือสร้างโพรเซสแบบอัติโนมัติ โดยวิธีการที่ผมคิดว่าเหมาะสมคือ แต่ละเซอร์วิสทำการส่งข้อมูลเหตุการณ์ (event) ที่เกิดขึ้นออกมา และข้อมูลนี้จะส่งต่อไปยังระบบโพรเซสอัติโนมัติเพื่อพิจารณาสิ่งที่จะต้องทำต่อ หลังจากนั้นโพรเซสอัติโนมัติจะส่งคำสั่งไปยังเซอร์วิสที่เกี่ยวข้องให้ทำงานต่อไป

โพรเซสอัติโนมัติในระบบไมโครเซอร์วิส

แนวทางนี้ ทำให้เซอร์วิสที่ต้องทำงานต่อ ไม่จำเป็นจะต้องรู้จักเซอร์วิสต้นทาง ทำให้สามารถแยกกันได้อย่างอิสระ หรือที่เรียกว่า ทำให้ขึ้นต่อกันน้อย (loosely coupled) อีกทั้ง เรายังสามารถที่จะเห็นการทำงานรวมของโพรเซสหรือระบบผ่านเครื่องมือโพรเซสอัติโนมัติได้ และยังสามารถที่จะตรวจสอบติดตามปัญหาที่เกิดขึ้นของงานแต่ละงานได้อีกด้วย

การสื่อสารแบบ Choreography หรือ Orchestration

ในโลกของการสื่อสารผ่านข้อมูลเหตุการณ์ที่เกิดขึ้น (event-driven) ประกอบ 2 รูปแบบ คือ Choreography และ Orchestration

Choreography (อ่านว่า โครีโอกราฟฟี่) คือการที่ เหตุการณ์ หรือ event ที่ส่งออกมาจากเซอร์วิสต้นทางจะถูกใช้โดยตรงโดยเซอร์วิสปลายทาง ข้อดี ก็คือระบบก็จะไม่เรียบง่าย ไม่ต้องการตัวกลางในการสื่อสาร

Orchestration (อ่านว่า ออเคสเตรชั่น) คือการที่ มีตัวกลาง อย่างเช่น ระบบโพรเซสอัติโนมัติ ที่คอยรับเหตุการณ์ที่เกิดขึ้น และคอยส่งคำสั่งให้กับเซอร์วิสปลายทางที่เกี่ยวข้อง ซึ่งก็คือแนวทางที่ได้อธิบายถึงในหัวข้อด้านบน

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

เครื่องมือในอดีต เทียบกับ เครื่องมือสมัยใหม่

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

การนำโพรเซสอัติโนมัติ มาใช้งาน

ในการนำเอาโพรเซสอัติโนมัติมาใช้งาน ก่อนอื่น เราจำเป็นที่จะต้องเลือกเครื่องมือที่จะนำมาใช้ ไม่ว่าจะเป็น เครื่องมือในระบบคลาวด์ หรือ เครื่องมือโอเพนซอร์ส เครื่องมือในระบบคลาวด์ก็อย่างเช่น อเมซอน เวบเซอร์วิส กูเกิล หรือ ไมโครซอร์ฟอะชัว ปัญหาของระบบคลาวด์ก็คือ เครื่องมือเหล่านี้เป็นเครื่องมือเฉพาะของแต่ละเจ้า ทำให้ไม่สามารถนำมาใช้งานร่วมกันได้ ทำให้การลงทุนใช้เครื่องมือหนึ่งไม่สามารถนำไปใช้กับอีกเจ้าได้ นั่นเอง ส่วนเครื่องมือแบบโอเพนซอร์ส ก็มีหลากหลาย เช่น Netflix Conductor, JBPM หรือ Zeebe แต่เครื่องมือเหล่านี้ก็อาจจะไม่สามารถนำมาใช้ร่วมกันได้ อีกเช่นกัน โดยส่วนตัวแล้วผมชอบแนวทางของ Zeebe เนื่องจากมีสถาปัตยกรรมที่ทันสมัยเหมาะกับระบบสมัยใหม่ และยังเน้นในเรื่องความเร็วในการทำงานอีกด้วย แต่เครื่องมือนี้ก็อยู่ในขั้นต้นของการพัฒนา

เมื่อเลือกเครื่องมือแล้ว การนำเข้ามาใช้ในองค์กรได้นั้น แนะนำให้เริ่มจากการนำมาทดลองใช้กับโพรเซสงานที่จะพัฒนาขึ้นมาใหม่ เพื่อไม่ให้เกิดความยุ่งยากในการใช้งานกับสิ่งที่มีอยู่เดิม หากสำเร็จด้วยดี ก็ให้ทีมงานที่เริ่มต้น ได้ทดลองนำมาใช้กับโพรเซสงานที่มีความซับซ้อนมากขึ้น เพื่อเป็นการทดสอบความรู้และปรับปรุงสิ่งที่จำเป็น หลังจากทีมมีความสามารถมากพอ ก็สามารถที่จะเริ่มถ่ายทอดความรู้นี้ไปยังทีมอื่น ๆ โดยตั้งทีมผู้ริเริ่มนี้เป็นทีมช่วยเหลือทีมอื่น ๆ ในการเริ่มต้น (อาจจะใช้แนวทาง รูปแบบทีมสนับสนุน) และสร้างชุมชนนักพัฒนา (Community Of Practice) โดยมีตัวแทนจากแต่ละทีมเข้าร่วม เพื่อเป็นวิธีการที่จะคงและส่งเสริมความสามารถนี้ในองค์กรของคุณ

ความแตกต่างระหว่าง Saga และ Process Orchestration

คุณอาจจะเคยได้ยิมคำว่า “Saga” (อ่านว่า ซาก้า) ที่เกี่ยวข้องกับแนวทางการสื่อสารผ่านเหตุการณ์ (event-driven) แต่ถ้าไม่เคย มันก็คือ รูปแบบการสื่อสารรูปแบบหนึ่ง ที่นำมาใช้ทำทรานแซกชั่นระหว่างโพรเซสที่มีหลายๆ เซอร์วิสร่วมกันที่ใช้เวลาในการทำงานนาน เช่น โพรเซสการสั่งอาหารออนไลน์ ซึ่งจะใช้เวลานานและห่างขั้นตอนใดขั้นตอนหนึ่งมีปัญหา อย่างเกิดอุบัติเหตุระหว่างทาง ก็จำเป็นที่จะต้องยกเลิกรายการนั้น โดยเราจะใช้ Saga ในการติดตามแต่ละขั้นตอนและทำการยกเลิกขั้นตอนทั้งหมด หากว่า ขั้นตอนใดขั้นตอนหนึ่งเกิดปัญหาขึ้น ซึ่งรูปแบบนี้จะต่างจากทรานแซกชั่นที่เราคุ้นเคยในระบบฐานข้อมูลที่ ทุก ๆ อย่างที่เกี่ยวข้องจะถูกคอมมิทหรือโรลแบกทั้งหมด ภายในระยะเวลาอันสั้น

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

การใช้งาน BPMN

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

สรุป

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