สำหรับผู้ที่มีหน้าที่ขับเคลื่อนโครงการ RPA หรือมีบทบาทในโครงการ RPA นั้น ขั้นตอนของ Process Discovery จัดว่าเป็นขั้นตอนหนึ่งที่สำคัญมากของโครงการ เนื่องจากเรื่องนี้เกี่ยวข้องโดยตรงกับความสำเร็จในการนำเทคโนโลยี RPA ไปใช้กับงานในองค์กรของเรา
เราลองนึกภาพดูถ้าองค์กรของเราเลือก process การทำงานที่ (ไม่ทราบมาก่อนว่า) ซับซ้อน เกิดปัญหามากมายในขั้นตอนการพัฒนาอันทำให้โครงการล่าช้ากว่ากำหนดมากและได้ผลลัพท์ที่สุดท้ายแล้ว ไม่ได้ช่วยให้ผู้ใช้งานมีชีวิตการทำงานที่ง่ายขึ้น โครงการนี้ก็จะหมดความน่าสนใจจากทุกๆฝ่ายไปในที่สุด
Process Discovery เป็นขั้นตอนที่สมาชิกโครงการ RPA (ผู้ที่มีบทบาทหลักคือ หัวหน้าโครงการ ผู้ใช้งาน นักวิเคระห์และออกแบบระบบ เป็นต้น) คัดเลือกและวิเคราะห์กระบวนการทำงานที่มีอยู่ภายในองค์กรเพื่อพิจารณาว่ากระบวนการใดเหล่านี้เหมาะสำหรับพัฒนา เป็นระบบทำงานอัตโนมัติด้วย RPA โดยเป็นการค้นหากระบวนการที่มีลักษณะต่อไปนี้ เช่น เป็นการทำงานซ้ำในรูปแบบเดิม ใช้เวลามากจนกระทบงานอื่น มีเงื่อนไขการทำงานที่แน่นอน เกี่ยวข้องกับงานที่ต้องอาศัยข้อมูลจากระบบต่าง ๆ ในองค์กรมาประกอบการใช้งานเป็นจำนวนมาก
เป็นต้นโดยเรียกคุณลักษณะเหล่านี้ว่าเกณฑ์การพิจารณา ส่วนผลลัพธ์ของการทำงานส่วนนี้จะเป็น Process List ที่ผู้ใช้งานหรือสมาชิกโครงการระดมความคิดออกมาว่า กระบวนการทำงานไหนบ้างที่สมควรถูกเลือกขึ้นมาศึกษาในเชิงลึกว่ามีความเหมาะสม คุ้มค่ากับการพัฒนาให้เป็นระบบทำงานอัตโนมัติบ้าง
ในการทำ workshop ของขั้นตอน Process Discovery เราอาจใช้วิธีแบ่งกลุ่มผู้ใช้งานออกเป็นกลุ่มต่างๆ ที่ค่อนข้างมีความเข้าใจการทำงานในปัจจุบันของแต่ละคน และเลือก process ที่เห็นร่วมกันออกมาชุดหนึ่งเพื่อหารือกันในที่ประชุมรวม
ผู้ใช้งานจะต้องพยายามคิดว่างานของตนยังมีสิ่งใดที่เป็นปัญหาหรือสามารถทำให้ได้ดีกว่าที่เป็นอยู่ หากไม่แน่ใจก็สามารถซักถามเพื่อนร่วมกลุ่มหรือวิทยากรที่มีหน้าที่ให้คำปรึกษา เพื่อที่ว่าสุดท้ายกลุ่มของตนจะสามารถได้ Process List ที่มั่นใจได้ว่าสามารถช่วยปรับปรุงการทำงานของเราให้ดีขึ้นได้
การทำ workshop นี้ ยังเป็นโอกาสอันดีที่
- พนักงานบุคคลากรในกลุ่มสามารถแลกเปลี่ยนข้อมูลและความเข้าใจในการทำงานของแต่ละคนซึ่งอาจอยู่คนละแผนก ซึ่งการเข้าร่วม workshop ลักษณะนี้ไม่ใช่เป็นแค่การประชุมเฉพาะกิจเวลาที่เกิดปัญหาและต้องการการแก้ไขเฉพาะหน้า แต่เป็นเรื่องของการมองภาพใหญ่ของโอกาสในการปรับปรุงกระบวนการทำงานให้มีประสิทธิภาพมากขึ้น
- ได้รับฟังความคิดเห็นและมุมมองในการทำงานที่กว้างขึ้นจากพนักงานที่ปกติอาจจะไม่ได้มีโอกาสแสดงความคิดเห็นออกมา เนื่องจากในแต่ละวันเราก็จะให้ความสนใจเฉพาะกับงานที่เราต้องรับผิดชอบ ทำให้ขาดโอกาสในการเห็นภาพรวม
- ได้รับความรู้และข้อมูลจากฝั่งของเทคโนโลยีจากผู้เชี่ยวชาญที่นำมาถ่ายทอดแลกเปลี่ยนระหว่างการทำworkshop ซึ่งทำให้องค์กรสามารถรับทราบความเป็นไปของเทคโนโลยีที่ตนเองสามารถนำมาใช้ประโยชน์ แม้บางแนวคิดที่ได้จาก workshop อาจยังไม่เหมาะสมที่จะหยิบมาพัฒนาได้เลยทันที แต่ก็ยังสามารถุศึกษาเพิ่มเติมหากเป็นประโยชน์ในอนาคตได้
ทั้งนี้ Process List ที่สมาชิกโครงการได้รวบรวมออกมาจะถูกนำมาจัดกลุ่มเป็น 4 กลุ่มหรือ 4 Quadrants ตามการประเมินจากมุมมองแรกคือ มองประโยชน์ที่ผู้ใช้งานหรือองค์กรคาดหมายจะได้รับ และอีกมุมคือมุมมองของต้นทุนและความซับซ้อนของการพัฒนางานเหล่านี้ให้เป็นระบบ RPA
โดยที่กลุ่มของกระบวนการทำงานใน Process List ทั้ง 4 กลุ่มสามารถอธิบายได้ดังนี้
- Quick-Win: กลุ่มกระบวนการทำงานที่จะก่อให้เกิดประโยชน์แก่องค์กรได้มาก ในขณะที่ต้นทุนหรือความซับซ้อนในการพัฒนากระบวนการทำงานให้เป็น RPA มีไม่มากนัก เหมาะสมกับการเลือกมาทำเป็นระบบ RPA เป็นกลุ่มแรก ซึ่งเราต้องการได้ผลลัพท์ที่รวดเร็วเพื่อรักษาโมเมนตัมของโครงการ
- Low-Hanging Fruits: กลุ่มกระบวนการทำงานที่จะก่อให้เกิดประโยชน์แก่องค์กรได้พอประมาณ แม้ไม่มากเท่ากับกลุ่ม Quick-Win ในขณะที่ต้นทุนการทำงานก็ไม่ได้สูงมากหรือทำได้ไม่ยากเท่าไหร่ หากพิจารณาว่าสามารถได้รับประโยชน์ที่เพียงพอ ก็สามารถเลือกทำเป็นกลุ่มถัดไป
- Must-Do Improvements: กลุ่มกระบวนการทำงานที่คาดหวังให้เกิดประโยชน์แก่องค์กรได้มาก แม้มีต้นทุนค่าใช้จ่ายที่สูงหรือมีความซับซ้อนในประเด็นต่างๆของการพัฒนาระบบอยู่พอสมควร ก็ยังคุ้มที่จะลงทุนทำ
- Long-Term Improvements: กลุ่มกระบวนการทำงานที่มีประโยชน์หรือคุณค่าต่อองค์กรไม่มาก โดยเฉพาะเมื่อเทียบกับต้นทุนความซับซ้อนที่ต้องใช้พัฒนาโครงการ อาจมองกลุ่มงานนี้เป็นกลุ่มสุดท้าย อาจพิจารณายังไม่ต้องทำในตอนนี้ หรือรอพิจารณาเชิงคุณประโยชน์ที่มีโอกาสเพิ่มขึ้นได้ในอนาคต
เราสามารถใช้เกณฑ์การให้คะแนน (Automation Score) ที่คำนึงจากปัจจัยทั้งด้านประโยชน์ที่คาดว่าจะได้รับและด้านต้นทุนการพัฒนา มาช่วยเราในการจัดกลุ่มได้
อย่างไรก็ตามแม้การทำ workshop ในขั้นตอน Process Discovery นี้จะดูมีขั้นมีตอน มีเกณฑ์การคัดเลือก Process List ที่ค่อนข้างชัดเจนและสามารถคำนวนเป็นตัววัดเชิงปริมาณอย่างคะแนนที่จะช่วยให้เราจัดกลุ่ม process เหล่านี้ได้ เรายังมีข้อสังเกตบางประการจากการสังเกตกิจกรรมที่เกิดขึ้นใน workshop ซึ่งอาจทำให้เราไม่ได้ Process List ที่ดีที่สุดสำหรับการวางแผนโครงการ RPA ในระยะถัดไป คือ
- การขาดบุคคลากรที่มีความเข้าใจจริงในกระบวนการทำงานที่กำลังประเมินอยู่ ในกรณีที่ผู้ใช้งานที่ลงมือทำเองหรือมีความเข้าใจในขั้นตอนและปัญหาการทำงานจริงๆไม่ได้อยู่ร่วมใน workshop ซึ่งทำให้ Process List ที่ทำออกมาไม่ได้แสดงถึงกลุ่มงานที่เหมาะสมที่สุดที่จะพัฒนาให้เป็นระบบ RPA
- การขาดข้อมูลที่จำเป็นสำหรับการตัดสินกระบวนการทำงานที่กำลังประเมินอยู่ เวลาเราพูดถึงประโยชน์ที่คาดหวังจากการเพิ่มประสิทธิภาพการทำงานหรือความซับซ้อนของการทำงานที่เรากำลังเผชิญอยู่ เราควรมีวิธีที่จะเก็บค่าสถิติของการทำงานนี้ให้ได้อย่างครบถ้วนและใกล้เคียงความจริงให้ได้มากที่สุด เช่น ขั้นตอนและเงื่อนไขการทำงานที่เราทำอยู่ เวลาที่ใช้อยู่ เวลาที่คาดการณ์ว่าจะลดลงเมื่อมีระบบ RPA มาใช้เป็นต้น ถ้าสมมุติฐานหรือค่าสถิติเหล่านี้คลาดเคลื่อนจากความจริงไปมาก เราจะได้ Process List ที่ไม่เหมาะสมและจะส่งผลต่อความสำเร็จและการยอมรับของโครงการ RPA
- การที่ผู้ใช้งานหรือบุคคลากรที่มีหน้าที่ประเมินความเหมาะสมของโครงการ ยังไม่ได้รับทราบข้อมูลด้านเทคโนโลยีที่จะนำมาใช้ออกแบบและทำงานจริงอย่างเพียงพอ ทำให้เป็นอุปสรรคต่อการประเมินความซับซ้อนของการพัฒนาและการเลือกรูปแบบการทำงานใหม่ที่เหมาะสม
การได้ Process List จากการทำ workshop เป็นเพียงผลลัพท์แรกเท่านั้น process ต่างๆที่คิดได้ยังต้องผ่านการพิจารณาในรายละเอียดและจัดทำเป็น business case ที่มีข้อมูลสนับสนุนในเชิง costs & benefits ที่เพียงพออีก เพื่อให้ผู้มีอำนาจตัดสินใจอนุมัติและรวบรวมเข้าไปในแผนการพัฒนาโครงการต่อไป
ปัญหาที่พบจากข้อสังเกตที่กล่าวถึงในบทความสามารถแก้ไขได้โดยการจัดการเวลาที่เหมาะสมเพียงพอ เช่นการให้ความรู้เชิงเทคโนโลยีกับผู้ใช้งานที่เพียงพอก่อนที่จะประเมินความเป็นไปได้ของการพัฒนากระบวนการทำงานต่างๆ และการใช้เครื่องมือหรือเทคนิคในการเก็บค่าสถิติของการทำงาน เช่น เวลาและขั้นตอนการทำงานที่แท้จริงไม่ใช่มาจากการคาดเดา จุด bottleneck ต่างๆของแต่ละกระบวนการทำงาน เป็นต้น เพื่อให้การทำ Process Discovery ได้ผลลัพท์ที่เกิดประโยชน์ที่แท้จริงแก่องค์กร