เคยไหม? ลงทุนทำระบบใหม่ทั้งที กลับใช้งานยาก เจอปัญหาซ้ำซาก หรือที่แย่สุดคือ ระบบเสร็จ แต่คนไม่ใช้
ทำไมไอทีถึงพัง? เพราะลืม "ปรับปรุงกระบวนการ" ก่อนเขียนโค้ด
ปัญหาส่วนใหญ่ไม่ได้อยู่ที่โค้ด หรือเทคโนโลยี แต่เกิดจากสิ่งเดียวกับที่คนไอทีมักมองข้าม นั่นคือ Business Process Redesign (BPR) หรือการปรับปรุงกระบวนการทางธุรกิจครั้งใหญ่
ไอทีไม่ใช่แค่เครื่องมือ แต่คือ "ภาพสะท้อน" ของกระบวนการ
ถ้ากระบวนการเดิมยุ่งเหยิง ระบบไอทีที่สร้างขึ้นมาก็จะยุ่งเหยิงตามไปด้วย เหมือนเอาข้อมูลขยะใส่ระบบ ก็ได้ขยะออกมา (Garbage in, Garbage out)
ความสำคัญของ BPR กับงานไอทีมี 3 ข้อหลัก
1. ลดความผิดพลาดจากการสื่อสาร BPR ทำให้ทุกฝ่ายเห็นภาพเดียวกันว่า "จะปรับปรุงการทำงานร่วมกันยังไง" ไม่ใช่ฝ่ายธุรกิจว่าอย่างหนึ่ง ฝ่ายพัฒนาทำอีกอย่าง
2. ประหยัดงบและเวลาในการพัฒนา ยิ่งเจอปัญหากระบวนการช่วงออกแบบใหม่ (Redesign) ยิ่งสามารถแก้ได้ด้วยงบประมาณที่ถูกกว่าตอนเขียนโค้ดไปแล้ว 10-20 เท่า และถูกกว่าตอนไปแก้หลังระบบขึ้นใช้งานถึง 100 เท่า
3. ระบบพร้อมปรับเปลี่ยนตามธุรกิจ กระบวนการที่ปรับปรุงใหม่จะถูกออกแบบให้แยกส่วน (Modular) ทำให้เมื่อธุรกิจเปลี่ยน ระบบก็ปรับได้โดยไม่ต้องเขียนใหม่ทั้งระบบ
5 ขั้นตอนหลักทำ BPR ให้เวิร์กในโลกไอที
1. ทำความเข้าใจ "กระบวนการปัจจุบัน" ให้จริง (As-Is Process Mapping)
อย่าเพิ่งคิดระบบใหม่! ลงไปนั่งดูว่าปัจจุบันพนักงานทำงานกันยังไง มีขั้นตอนไหนที่เสียเวลาหรือซ้ำซ้อน
เทคนิค: ใช้ เดินตามงาน (Walk-the-Process) แทนการนั่งประชุม ถ้าอยากรู้ขั้นตอนรับสินค้า ก็ไปยืนที่หน้าร้านกับคลังเลย จะทำให้เห็นปัญหาที่ไม่มีใครบอกในเอกสาร
2. ตั้งเป้าหมาย "กระบวนการอนาคต" ให้ชัดเจน (To-Be Process Design)
ถามให้ได้ว่า "การปรับปรุงครั้งนี้จะทำให้ดีขึ้นกว่าปัจจุบันตรงไหน" ลดเวลาลง 50%? ลดเอกสาร? เพิ่มความแม่นยำ?
เทคนิค: ใช้หลัก Value-Added Analysis – ขั้นตอนไหนที่ไม่เพิ่มมูลค่าให้ลูกค้า หรือไม่จำเป็นตามกฎหมาย ให้ตัดหรือลดให้มากที่สุด
3. อย่าลืม "คน" และ "ข้อมูล" ที่ต้องเปลี่ยน
คนไอทีมักโฟกัสที่ฟังก์ชันในระบบ แต่ลืมว่า คนต้องเปลี่ยนวิธีทำงาน และ ข้อมูลต้องถูกแปลงให้อยู่ในรูปแบบที่ระบบใหม่ใช้ได้
เทคนิค: ทำ Data Mapping คู่ไปกับการปรับปรุงกระบวนการ จะได้ไม่เจอปัญหาเวลา migrate ข้อมูล
4. ออกแบบกระบวนการใหม่ให้ "ยืดหยุ่น" และ "มีข้อยกเว้น"
กระบวนการจริงมีทางเลือกเสมอ (Approved / Rejected / Pending) อย่าออกแบบเป็นเส้นตรงตายตัว
เทคนิค: ใช้ BPMN (Business Process Model and Notation) ในการวาด เพราะมีสัญลักษณ์มาตรฐานที่ทั้งสายธุรกิจและสายเทคอ่านเข้าใจตรงกัน
5. ทดสอบกับผู้ใช้จริง ก่อนลงมือพัฒนาเต็มรูปแบบ
ทำ Prototype หรือ Simulation ให้ผู้ใช้ลอง "เล่น" กระบวนการใหม่บนกระดาษหรือเครื่องมือ mock-up ก่อน
เทคนิค: จัด Workshop Role-Play ให้พนักงานสวมบทบาทเป็นแต่ละสถานะในระบบ (เช่น พนักงานขาย -> หัวหน้า -> บัญชี) เพื่อเช็กว่าข้อมูลไหลครบวงจรหรือไม่
สรุปสั้น ๆ
ปรับปรุงกระบวนการก่อน เขียนโค้ดทีหลัง ถึงแม้จะใช้เวลาตอนแรก แต่จะช่วยประหยัดเวลาแก้ไขทีหลังเป็นเท่าตัว และที่สำคัญ ทำให้ระบบไอทีที่คุณทำ ถูกใช้จริง และสร้างมูลค่าให้องค์กรได้อย่างเต็มศักยภาพ
Image: Pexels.com
