มาเล่าประสบการณ์จากการประชุมเรื่อง จัดซื้อระบบ Workflow มาเล่าให้ฟังครับ ที่อยากจะเล่าเพราะรู้สึกว่ากรณีแบบนี้ เกิดขึ้นบ่อย จนผมต้องเอามาเขียนไว้ เริ่มจากแบบนี้ครับ
เมื่อซัก 2 เดือนก่อนมีการประชุมคุยเรื่องระบบ Work Flow ที่ทางหน่วยงานต้องการนำไปใช้แทนการทำงานอนุมัติเอกสาร ผมก็นำเสนอข้อมูล Solution ที่เป็นของ Microsoft ได้ทราบไปตามปกติ ว่าทำอะไรบ้าง ใช้อะไรทำ ข้อจำกัดมีอะไร
หลังจากนั้นก็มีการส่งข้อมูลกันไปมาเป็นระยะ จนในที่สุดเมื่อวานก่อนมีประชุมด่วนที่ต้องการให้สรุป Budget การประชุมทางบริษัทก็เปิด Requirement Spec ไล่ข้อกันเลยที่ละข้อ ผมฟังแล้วตกใจ มันไม่ใช่เลย สิ่งที่ลูกค้าบอกมาระบบน่าจะทำได้ตาม Spec ไม่ถึง 40 %
ผมรู้ทันทีว่า เข้าไม่ได้และยังนึกสงสัยอยู่ว่า คู่แข่งผมเข้าได้หรือป่าว พอดีคู่แข่งก็บอกมาให้ห้องประชุมว่า น่าจะทำได้ตาม Spec ที่พูดไม่ถึง 60 %
โหหัวอกเดียวกันเลย
ลูกค้าไม่ได้ผิดนะครับ ทางทีมงานของลูกค้าได้รวบรวมข้อมูลความต้องการจากแต่ละส่วนงาน สรุปเป็นข้อชัดเจน แต่ระบบมันทำไม่ได้ ยิ่งระบบที่เป็น Cloud สมัยนี้ยิ่ง Customize ได้ยาก
ประเด็นมันอยู่ที่ ทำไมระบบของ Microsoft ที่มี User ใช้เป็นล้านคนมีบริษัทใช้งานระบบ Workflow เป็นแสนบริษัท ถึงไม่ Support ความต้องการลูกค้ารายนี้ เช่น Feature print form แบบนี้ Microsoft ก็ไม่มีให้
ผมเอามาคิดๆ เพื่อหาสาเหตุว่ามันเกิดอะไรขึ้น เอามาสรุปเป็นข้อๆ ดังนี้ครับ
- ลูกค้าคิดว่าการทำระบบ Paper Less , Workflow คือการแปลงกระดาษเป็น File จริง ๆ แล้วการมันคือการ ส่งต่อข้อมูลต่างหาก ข้อมูลไม่อยู่ในรูปของกระดาษอีกต่อไป ซึ่งแนวทางคิดพื้นฐานนี้มีผลมากต่อ Spec ที่เขียนไว้ และมันขัดกับแนวคิดของระบบในปัจจุบัน ที่ให้ลืมกระดาษไปเลย หรือ File ไปเลย สิ่งที่เกิดขึ้นคือ ทุกอย่างมันขัดกันไปหมด
- แนวคิดเรื่องการ Approve Process จะไม่เหมือนเดิม เพราะระบบสามารถตรวจสอบข้อมูลและทำเงื่อนไข ก่อนที่จะ submit data ได้ ดังนั้นสำหรับกรณีปกติ แล้ว การ Approve ก็เหมือนกับเป็นการแจ้งให้ทราบเฉยๆ เช่น การเบิกของ ปกติก็ให้เบิกกันอยู่แล้ว ถ้ามีของ หรือ กรณีของปรับปรุง ถ้าอยู่ใน Scope ก็มักจะอนุมัติกันอยู่แล้ว ดังนั้นเราก็ Setup ให้สำหรับกรณีปกติ ผ่านขั้นตอนให้เร็วขึ้น และ ถ้าระบบประเมินแล้วเป็นกรณีที่ไม่ปกติ ก็ให้เข้าไปขออนุมัติกันปก โดยระบบก็แสดงสถานะคำข้อที่บอกว่าไม่ปกติมาด้วย เพื่อให้ผู้อนุมัติได้เห็นอย่างชัดเจน
- แต่เนื่องจากผู้อนุมัติ ยังมีแนวคิดแบบเดิม ๆ ว่าต้องเห็น File หรือ กระดาษ ครบถ้วนจึงจะอนุมัติได้ ทำให้ผู้อนุมัติกังวนเรื่องนี้มาก และ เกิดความต้องการที่ระบบไม่สามารถทำได้เช่น อนุมัติไปแล้ว ดึงข้อมูลกลับมา แบบนี้ ซึ่งขัดกับแนวทางของระบบที่มาตราฐาน
- การแนบ File ว่าอยากได้อย่างน้อย 50MB ต่อ Flow แบบนี้ ก็มาจากแนวคิดที่เป็นกระดาษ เหมือนกัน แต่ปัจจุบัน เราสามารถสร้างปุ่ม Link ไปเปิดข้อมูลที่เป็น Dynamic เห็น แบบ Realtime ได้แล้วไม่จำเป็นต้องแนบกระดาษแบบนี้
ดังนั้น การที่ทีม Project ของ User จะเอาไป Requirement ของผู้ใช้งานมาเป็นตัวตั้งต้นจึงเป็นข้อควรระวังเป็นอย่างยิ่ง เพราะระบบ Solution ปัจจุบันไม่ได้อยู่บนแนวคิดเดียวกันกับประสบการณ์เดิมของ End user แล้ว
สำหรับสิ่งที่ผมจะขอนำเสนอคือ เราเอาหัวข้อมาจาก End user ได้แต่ลักษณะการทำงาน นั้นเอามาไม่ได้และทางผู้เสนอ Technology น่าจะเป็นผู้นำเสนอวิธีการใช้งานในรูปแบบปัจจุบันจะดีกว่าครับ
