Digital Transformation
เริ่ม Digital Workflow งานนิติบุคคลอย่างไร โดยไม่ต้องเปลี่ยนทุกอย่างในวันเดียว
โครงการดิจิทัลที่ดีไม่เริ่มจากรายการฟีเจอร์ยาวที่สุด แต่เริ่มจากงานซ้ำที่มีเจ้าของ ปัญหา และผลลัพธ์ชัด แล้วออกแบบทางรับมือกรณีผิดปกติตั้งแต่แรก
หลายโครงการเริ่มเปลี่ยนระบบด้วยการรวบรวมรายการฟีเจอร์จำนวนมาก แต่ยังไม่ได้ตอบคำถามพื้นฐานว่าใครเป็นผู้เริ่มงาน ใครตัดสินใจเมื่อข้อมูลไม่ครบ และจะรู้ได้อย่างไรว่างานเสร็จจริง ผลคือทีมได้หน้าจอใหม่ แต่ยังต้องกลับไปตามงานในโทรศัพท์ กระดาษ และกลุ่มแชตเหมือนเดิม
แนวทางที่เสี่ยงน้อยกว่าคือเลือก workflow แนวตั้งหนึ่งเรื่องให้ครบตั้งแต่ต้นจนจบ เช่น รับพัสดุจนลูกบ้านรับออก หรือรับแจ้งซ่อมจนปิดงาน จากนั้นจึงใช้สิ่งที่เรียนรู้เป็นแบบสำหรับโมดูลถัดไป
1. เลือกงานแรกจากความถี่ ความเจ็บปวด และความพร้อม
งานแรกไม่จำเป็นต้องเป็นงานที่ใหญ่ที่สุด ควรเป็นงานที่เกิดซ้ำ มีขอบเขตพอควบคุมได้ และมีทีมหน้างานพร้อมร่วมทดสอบ ตัวอย่างที่พบบ่อยคือพัสดุ ผู้มาติดต่อ แจ้งซ่อม หรือประกาศเฉพาะกลุ่ม
- เกิดบ่อยพอที่จะเห็นปัญหาและผลของการเปลี่ยนแปลง
- ระบุผู้เริ่ม ผู้อนุมัติ ผู้รับผิดชอบ และผู้รับบริการได้
- มีข้อมูลตั้งต้นที่นำเข้าได้โดยไม่ต้องทำความสะอาดทั้งองค์กร
- ผลกระทบจากความผิดพลาดระหว่าง Pilot อยู่ในระดับที่บริหารได้
- มีตัวชี้วัดก่อนและหลังที่ทีมยอมรับร่วมกัน
2. วาด AS-IS จากเหตุการณ์จริง ไม่ใช่จากคู่มือที่ควรจะเป็น
ให้เดินตามงานจริงหนึ่งรายการตั้งแต่เกิดจนจบ แล้วบันทึกช่องทาง ข้อมูล ผู้รับผิดชอบ เวลารอ และจุดที่ต้องย้อนกลับไปถามซ้ำ สิ่งสำคัญคือกรณีผิดปกติ เช่น ไม่รู้ห้อง ลูกบ้านไม่มี LINE ผู้อนุมัติไม่อยู่ หรือผู้ให้บริการภายนอกตอบช้า
Workshop ที่ดีควรมีทั้งผู้จัดการ ผู้ปฏิบัติงานหน้างาน และตัวแทนผู้รับบริการ เพราะแต่ละคนเห็นความเสียหายคนละส่วน การเก็บ requirement จากผู้อนุมัติเพียงกลุ่มเดียวมักพลาดข้อจำกัดของหน้างาน
3. ออกแบบ TO-BE ให้แต่ละสถานะมีเจ้าของและทางออก
สถานะไม่ควรเป็นเพียงป้ายสีในหน้าจอ ทุกสถานะต้องตอบว่ารายการเข้ามาได้อย่างไร ใครมีสิทธิ์เปลี่ยน ต้องตรวจเงื่อนไขอะไร แจ้งใครบ้าง และจะทำอย่างไรเมื่อขั้นตอนนั้นล้มเหลว
กำหนด Trigger
เช่น เจ้าหน้าที่รับของ ลูกบ้านส่งคำขอ หรือถึงรอบออกใบแจ้งหนี้
กำหนดข้อมูลขั้นต่ำ
เก็บเฉพาะข้อมูลที่จำเป็นต่อการทำงาน การตรวจสอบ และข้อกำหนดที่เกี่ยวข้อง
กำหนด Role และ Scope
ระบุว่าใครเห็นรายการใดและทำ action ใดได้ โดยให้ server ตรวจสิทธิ์ซ้ำทุกครั้ง
กำหนด Exception
ออกแบบคิวงานผิดปกติ การ retry การมอบหมายใหม่ และผู้มีอำนาจตัดสินใจ
กำหนดหลักฐานว่าเสร็จ
เช่น เวลา ผู้ดำเนินการ ผลการส่ง เอกสาร หรือสถานะที่ยืนยันจาก provider
4. ทำ Fit–Gap ก่อนประเมินราคาและกำหนดเวลา
นำ TO-BE มาเทียบกับ Nitis Core แล้วแบ่งแต่ละข้อเป็น Standard, Configuration, Project Module หรือ External Integration วิธีนี้ช่วยให้ทุกฝ่ายเห็นว่าข้อใดใช้ได้จากระบบเดิม ข้อใดเป็นการตั้งค่า และข้อใดต้องออกแบบหรือทดสอบเพิ่ม
ผลลัพธ์ของ Fit–Gap ควรกลายเป็นเอกสารที่ตรวจรับได้ ไม่ใช่เพียงสไลด์นำเสนอ อย่างน้อยต้องมี workflow, role matrix, data fields, integration contract, acceptance criteria, migration approach, out-of-scope และผู้มีอำนาจอนุมัติการเปลี่ยนแปลง
5. Pilot ให้เล็กพอเรียนรู้ แต่ครบพอพิสูจน์งานจริง
Pilot ไม่ควรทดสอบเฉพาะ happy path ให้รวมช่วงเปลี่ยนเวร ข้อมูลไม่ครบ ผู้ใช้หลายบทบาท การส่งข้อความล้มเหลว ไฟล์ผิดรูปแบบ รายการซ้ำ และการแก้ไขย้อนหลังด้วย จึงจะเห็นว่าทีมสามารถดูแล exception ได้จริง
- แยกข้อมูลและ provider ของ Pilot ออกจาก Production ที่ใช้งานจริง
- กำหนดชุดข้อมูลทดสอบและผู้ทดสอบทุก role
- มี acceptance criteria ที่วัดได้และเจ้าของผล UAT
- บันทึกข้อสังเกตเป็น defect, configuration หรือ change request ให้ชัด
- เตรียม rollback และช่องทางทำงานสำรองก่อนเปิดใช้
6. ขยายจาก Workflow เดิมด้วยข้อมูลที่เรียนรู้จริง
เมื่อ workflow แรกนิ่งแล้ว ให้ทบทวนว่า component ใดใช้ซ้ำได้ เช่น identity, ห้อง, LINE membership, การมอบหมายงาน, การแนบไฟล์, notification และ audit จากนั้นจึงต่อยอดโมดูลใหม่บนข้อมูลและสิทธิ์ชุดเดียวกัน แทนการสร้างฐานข้อมูลแยกทุกงาน
ส่วนที่เป็นกติกาเฉพาะโครงการควรอยู่ใน configuration หรือ SOW ส่วนสิ่งที่เป็น pattern ทั่วไปสามารถพัฒนาเป็น module ที่นำกลับมาใช้กับโครงการกลุ่มเดียวกันได้ โดยไม่ปะปนข้อมูลหรือความลับทางธุรกิจของลูกค้า
สัญญาณเตือนว่าโครงการกำลัง Digitize หน้าจอ แต่ยังไม่ได้แก้ Workflow
- ต้องส่งข้อความส่วนตัวให้คนเดิมเพื่อเร่งงานทุกครั้ง
- สถานะในระบบไม่ตรงกับสิ่งที่เกิดขึ้นหน้างาน
- ข้อมูลเดียวกันถูกพิมพ์ซ้ำในหลายระบบโดยไม่มีเจ้าของข้อมูลกลาง
- ไม่มีผู้รับผิดชอบรายการผิดปกติหรือรายการที่ provider ส่งไม่สำเร็จ
- รายงานดูดี แต่ย้อนหาผู้ทำ เวลา และเหตุผลของการเปลี่ยนแปลงไม่ได้
- ทุก requirement ถูกเรียกว่า “ตั้งค่าได้” ทั้งที่ยังไม่มี acceptance criteria
สรุป
Digital Workflow ไม่ใช่โครงการติดตั้งซอฟต์แวร์ครั้งเดียว แต่เป็นวินัยในการทำให้ Trigger, Role, Data, Status, Exception และ Evidence ชัดเจน เริ่มจากหนึ่งงานที่มีผลต่อชีวิตประจำวัน พิสูจน์ด้วย Pilot แล้วค่อยขยายบน Nitis Core จะช่วยให้การลงทุนแต่ละรอบตอบโจทย์หน้างานและนำความรู้กลับมาใช้ซ้ำได้