การปรับปรุงกระบวนการทำงานภายในองค์กรก่อนทำระบบใหม่ควรเริ่มอย่างไร

เริ่มจากรวบรวมปัญหาที่เกิดขึ้นซ้ำในแต่ละวัน

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

เมื่อรวบรวมปัญหาเหล่านี้อย่างเป็นระบบ จะช่วยให้เห็นว่าจุดไหนเป็น pain point ที่กระทบหลายฝ่าย และควรได้รับการแก้ไขก่อน

การเริ่มจากปัญหาจริงทำให้โครงการพัฒนาระบบมีเป้าหมายชัด และช่วยลดการออกแบบโดยอิงความรู้สึกเพียงอย่างเดียว

• เก็บตัวอย่างงานที่ล่าช้าหรือผิดพลาดบ่อย
• ดูว่าปัญหากระทบฝ่ายใดบ้าง
• แยกปัญหาที่เกิดจากข้อมูลกับปัญหาที่เกิดจากขั้นตอน

มองภาพการไหลของข้อมูลและผู้เกี่ยวข้องให้ครบ

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

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

เมื่อภาพการไหลของข้อมูลชัด ระบบที่จะออกแบบต่อจะรองรับการใช้งานจริงได้มากกว่า และลดจุดที่ต้องกลับมาแก้ทีหลัง

• ระบุเจ้าของข้อมูลแต่ละส่วน
• แยกบทบาทผู้ใช้งานตามหน้าที่จริง
• ดูเส้นทางของข้อมูลตั้งแต่ต้นจนจบงาน

จัดลำดับความสำคัญก่อนลงมือพัฒนาระบบ

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

ส่วนที่ควรเริ่มก่อนมักเป็นส่วนที่กระทบข้อมูลหลัก กระทบหลายฝ่าย หรือเป็นจุดคอขวดที่ทำให้งานทั้งกระบวนการช้าลง

เมื่อแก้จุดสำคัญได้แล้ว จึงค่อยขยายไปยังส่วนอื่นตามลำดับความคุ้มค่าและความพร้อมขององค์กร

• เลือก pain point ที่สร้างผลกระทบสูงก่อน
• กำหนดเป้าหมายที่วัดผลได้ในแต่ละระยะ
• ลดความเสี่ยงจากการทำโครงการใหญ่เกินไปตั้งแต่ต้น

ใช้การปรับปรุงกระบวนการเป็นฐานของ requirement

Requirement ที่ดีไม่ใช่รายการเมนูจำนวนมาก แต่ควรสะท้อนว่ากระบวนการใหม่ควรทำงานอย่างไร ใครเกี่ยวข้อง และข้อมูลใดที่ต้องถูกใช้ร่วมกัน

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

นี่คือเหตุผลที่การปรับปรุง Workflow ก่อนทำระบบใหม่ ช่วยให้การลงทุนด้านซอฟต์แวร์มีโอกาสคุ้มค่ามากขึ้นในระยะยาว

• ทำ requirement ให้สัมพันธ์กับงานจริง
• ลดการขอแก้ไขจากความไม่ชัดเจนในภายหลัง
• ทำให้ทีมธุรกิจกับทีมพัฒนาเห็นภาพตรงกันมากขึ้น