ความซับซ้อนของการทำ Workflow
ปัญหา จริง ๆ ของ ความซับซ้อนของการทำ Workflow คำแนะนำสำหรับการแก้ไข การป้องกัน แนวทางพัฒนามันอยู่ที่ตรงไหนแน่ การ config ระบบแล้วไม่ตอบสนองความต้องการ หรือ ความคิดในทำนอง
- Config ไม่ถูกในขบวนการ
- ไม่ Support ความต้องการของพนักงาน
- ทำงานไม่ถูก
- ใช้เวลา Config นาน
- User ไม่สามารถให้ข้อมูลความต้องการได้อย่างครบถ้วน
เรื่องแบบนี้ทำไม มันไม่สามารถแก้ไขได้ซักที จากที่ผมมีประสบการณ์เรื่อง implement มาเป็น 10 ปี ผมพบว่า สาเหตุใหญ่ ไม่ได้เกิดที่ปัญหาทาง technical แต่ปัญหาคือ ขบวนการพัฒนาระบบที่เป็น Water fall หรือ อีกกรณีคือ ขบวนการทำงานของเราเองที่ไม่มีมาตราฐาน ( กรณีประมาณ 30 % ) หรือ ความไม่เข้าใจในเครื่องมือ ( ไม่ได้ทดสอบระบบก่อนที่จะนำมาเครื่องมือมาใช้ ) ความคาดหวังที่เกินกว่าจะทำได้ในเครื่องมือปกติ
หรืออีกอย่างคือ User เองไม่เข้าใจความต้องการของตัวเองดีพอ ซึ่งไม่แปลก เพราะจากกระดาษมาเป็น Digital Process นั้นมีความต่างกันมาก
เราต้องออกแบบให้เสร็จก่อน ปัญหาเริ่มตั้งแต่ขบวนการออกแบบแล้ว ที่เอกสาร flow diagram ที่เขียนไว้ ไม่ถูก update และไม่ครอบคลุมสิ่งที่เป็นอยู่จริง ดังนั้นเวลาผู้พัฒนายึดจาก flow diagram ที่ user ส่งให้ ผลที่ได้ออกมาก็คือระบบที่ใช้งานไม่ได้
การพัฒนาระบบ โดยใช้ Agile Process
จากการพัฒนาในรูปแบบของ Water Fall ที่ไม่สามารถได้ข้อมูลที่ถูกต้องในการพัฒนาระบบ จึงเกิดแนวทางใหม่ที่เรียกว่า Agile ขึ้น โดยแนวคิดนี้ได้รับความนิยมอย่างมากในช่วงเวลา 2020 จนถึงปัจจุบัน เพราะมี Case ที่ประสบความสำเร็จ ประหยัดงบ และ ได้ผลงานที่รวดเร็วกว่าแบบเดิม
ซึ่งแนวทางของ Agile นั้นเน้นที่การพัฒนาให้เร็ว และ ให้ User มาเป็นส่วนรวมในทุกอาทิตย์ เพราะตัวการพัฒนา flow นั้นสามารถทำได้เร็ว เราจึงสามารถให้ User เข้ามาทดสอบระบบได้ตั้งแต่ อาทิตย์แรกของการพัฒนา
ทำให้ปัญหาเรื่องการให้ข้อมูลผิดพลาดน้อยลงไปมาก
สิ่งที่ขาดไปใน Flow Diagram มีอะไรบ้าง
- Field Validate ที่ต้องการให้ตรวจสอบก่อนการส่ง
- การแจ้งเตือน ในแต่ละขั้นตอนการดำเนินงาน
- การส่งกลับ กรณีข้อมูลไม่ถูกต้อง
- การบริหารจัดการ ข้อมูลของแต่ละ User ที่ต้องดำเนินงาน
- Action ที่สามารถทำได้ในแต่ละขั้นตอน
- Level ในการ Approve
- เงื่อนไขที่ Flow มีความสัมพันธ์กับ Form ที่กรอกข้อมูล
- Master Data สำหรับการส่งต่อข้อมูลเพื่อการขออนุมัติ
- ฯลฯ
สิ่งพวกนี้เป็นสาเหตุของความล่าช้าทั้งมวลในการพัฒนาระบบ และเป็นข้อมูลสำคัญที่อาจจะไม่ได้ถูกเขียนไว้ใน Diagram อย่างชัดเจน เนื่องจากเป็นภาพของ Diagram จะเป็นแค่การทำงานที่ควรจะเป็น
แต่ในกรณีที่ เร่งด่วน ยกเว้น หรือ การทำงานในกรณีที่ผิดปกติไม่ได้ถูกระบุไว้ Diagram
กรณีของ Reject ที่เกิดขึ้น แล้ววิ่งไปที่ไหน การแก้ไขระหว่างทาง เป็นเรื่องที่เราปล่อยให้เกิดขึ้นได้หรือไม่ เป็นเรื่องที่เราต้องคิดและวางแผนไว้ด้วย ครับ
ก็ได้แต่ฝากเป็นบทความไว้สำหรับผู้ที่กำลังต้องการพัฒนาระบบ flow ครับว่าเราต้องคิดเรื่องอะไรไว้บ้าง ถ้าเราคิดไว้ครบถ้วนแล้วการพัฒนาจะทำได้รวดเร็วและมีประสิทธิภาพเป็นอย่างยิ่งครับ
อีกสาเหตุที่ทำให้การพัฒนา Workflow ทำได้ยาก
- ลูกค้าคิดว่าการทำระบบ Paper Less , Workflow คือการแปลงกระดาษเป็น File จริง ๆ แล้วการมันคือการ ส่งต่อข้อมูลต่างหาก ข้อมูลไม่อยู่ในรูปของกระดาษอีกต่อไป ซึ่งแนวทางคิดพื้นฐานนี้มีผลมากต่อ Spec ที่เขียนไว้ และมันขัดกับแนวคิดของระบบในปัจจุบัน ที่ให้ลืมกระดาษไปเลย หรือ File ไปเลย สิ่งที่เกิดขึ้นคือ ทุกอย่างมันขัดกันไปหมด
- แนวคิดเรื่องการ Approve Process จะไม่เหมือนเดิม เพราะระบบสามารถตรวจสอบข้อมูลและทำเงื่อนไข ก่อนที่จะ submit data ได้ ดังนั้นสำหรับกรณีปกติ แล้ว การ Approve ก็เหมือนกับเป็นการแจ้งให้ทราบเฉยๆ เช่น การเบิกของ ปกติก็ให้เบิกกันอยู่แล้ว ถ้ามีของ หรือ กรณีของปรับปรุง ถ้าอยู่ใน Scope ก็มักจะอนุมัติกันอยู่แล้ว ดังนั้นเราก็ Setup ให้สำหรับกรณีปกติ ผ่านขั้นตอนให้เร็วขึ้น และ ถ้าระบบประเมินแล้วเป็นกรณีที่ไม่ปกติ ก็ให้เข้าไปขออนุมัติกันปกติ โดยระบบก็แสดงสถานะคำข้อที่บอกว่าไม่ปกติมาด้วย เพื่อให้ผู้อนุมัติได้เห็นอย่างชัดเจน
- แต่เนื่องจากผู้อนุมัติ ยังมีแนวคิดแบบเดิม ๆ ว่าต้องเห็น File หรือ กระดาษ ครบถ้วนจึงจะอนุมัติได้ ทำให้ผู้อนุมัติกังวนเรื่องนี้มาก และ เกิดความต้องการที่ระบบไม่สามารถทำได้เช่น อนุมัติไปแล้ว ดึงข้อมูลกลับมา แบบนี้ ซึ่งขัดกับแนวทางของระบบที่มาตราฐาน ( สำหรับกรณีที่ต้องการ Approve กระดาษหรือ PDF แนะนำให้ดู Clip นี้เป็นแนวทางครับ )
- การแนบ File ว่าอยากได้อย่างน้อย 50MB ต่อ Flow แบบนี้ ก็มาจากแนวคิดที่เป็นกระดาษ เหมือนกัน แต่ปัจจุบัน เราสามารถสร้างปุ่ม Link ไปเปิดข้อมูลที่เป็น Dynamic เห็น แบบ Realtime ได้แล้วไม่จำเป็นต้องแนบกระดาษแบบนี้
- Master Data เพื่อการส่งต่อ ขออนุมัติ ไม่มีโครงสร้างที่ชัดเจน หรือ มีโครงสร้างแต่การตั้งตำแหน่ง ไม่ได้มีการอิงโครงสร้างตามที่กำหนด ทำให้การสร้างขั้นตอนอนุมัติแบบ auto ทำได้ไม่สมบูรณ์
เครื่องมือพัฒนา Workflow Power Automate จาก Microsoft
Power Automate เป็นส่วนหนึ่งของ Office 365 เป็นเครื่องมือสำหรับการพัฒนา flow โดยเฉพาะ ซึ่งการทำงานนั้น สามารถเอามาควบคุมข้อมูลที่เก็บใน SharePoint , One Drive หรือจะเป็นข้อมูลที่สร้างจาก PowerApps ก็ได้ โดยการที่จะให้เกิดเป็น Solution ที่สมบูรณ์นั้นจะต้องมีองค์ประกอบเพิ่มเติม ดังนี้
- Power Automate สำหรับความคุมการไหลของข้อมูล
- Power App สำหรับสร้าง Interface การบันทึกข้อมูลและการเรียกดูข้อมูล
- SharePoint สำหรับเป็นฐานข้อมูลให้กับระบบ
