Business Systems · WHITE FORCES KNOWLEDGE
Digital Transformation ควรเริ่มจาก Workflow ไหนก่อน
เผยแพร่ · ตรวจทานล่าสุด · อ่านประมาณ 5 นาทีการเปลี่ยนผ่านดิจิทัลไม่จำเป็นต้องเริ่มด้วยระบบใหญ่ งานแรกที่เลือกถูกจะสร้างผลลัพธ์และบทเรียนให้ทีมขยายต่อได้
ทำแผนที่งานปัจจุบัน
เขียนตั้งแต่ข้อมูลเข้า ผู้ทำ การอนุมัติ ไปจนถึงผลลัพธ์ จุดที่ต้องคีย์ข้อมูลซ้ำ รอเอกสาร ค้นหาไม่เจอ และงานที่พึ่งคนเดียว
เครื่องมือที่ใช้ไม่ต้องซับซ้อน กระดาษหรือไวต์บอร์ดก็เพียงพอ สิ่งสำคัญคือให้คนหน้างานเป็นผู้เล่าขั้นตอนจริง ไม่ใช่ให้หัวหน้าเขียนตามที่คิดว่าควรเป็น เพราะขั้นตอนจริงมักมีทางลัด ข้อยกเว้น และงานแฝงที่ไม่อยู่ในคู่มือ การเห็นภาพตรงกันตรงนี้คือครึ่งหนึ่งของการออกแบบระบบที่ใช้ได้จริง
ให้คะแนนผลกระทบกับความพร้อม
งานที่ทำบ่อย ใช้เวลามาก รูปแบบค่อนข้างชัด และข้อมูลพร้อม เหมาะเป็นโครงการแรกมากกว่างานซับซ้อนที่เกิดน้อย
วิธีให้คะแนนอย่างง่ายคือให้แต่ละ workflow มีคะแนนสองแกน แกนแรกคือผลกระทบ ดูจากความถี่ เวลาที่ใช้ และความเสียหายเมื่อผิดพลาด แกนที่สองคือความพร้อม ดูจากความชัดของขั้นตอน คุณภาพข้อมูล และความยินดีของทีมที่เกี่ยวข้อง งานที่คะแนนสูงทั้งสองแกนคือโครงการแรกที่ดี ส่วนงานผลกระทบสูงแต่ความพร้อมต่ำ ให้ไปเตรียมความพร้อมก่อน อย่าฝืนเริ่ม
วัดผลหลังเปิดใช้
ติดตาม adoption เวลาต่อรายการ error และงานที่ยังทำนอกระบบ นำข้อมูลกลับมาปรับ workflow แทนการบังคับทีมให้เข้ากับซอฟต์แวร์
สัญญาณที่ต้องรีบดูคือ “งานเงา” หรือการที่ทีมกลับไปใช้วิธีเดิมนอกระบบ เช่น จดใส่กระดาษแล้วค่อยคีย์ตาม หรือส่งไฟล์กันทางแชตแทนการใช้ระบบ สาเหตุมักไม่ใช่ความดื้อ แต่เป็นเพราะระบบใช้ยากกว่าวิธีเดิมในบางจังหวะ การแก้ที่ถูกคือปรับระบบให้เข้ากับงาน ไม่ใช่ออกคำสั่งห้าม
ตัวอย่างสถานการณ์การใช้งานจริง
ลองพิจารณาธุรกิจซื้อมาขายไปที่การขอซื้อสินค้าเข้าคลังยังใช้กระดาษ พนักงานเขียนใบขอซื้อ เดินไปให้ผู้จัดการเซ็น แล้วส่งต่อฝ่ายจัดซื้อคีย์ลงไฟล์ Excel ขั้นตอนนี้เกิดทุกวัน มีรูปแบบชัด ข้อมูลไม่ซับซ้อน และทุกคนเห็นตรงกันว่าช้า การแปลงงานนี้เป็นแบบฟอร์มดิจิทัลที่มีลำดับอนุมัติ จึงเป็นโครงการแรกที่เหมาะกว่าการเริ่มด้วยระบบ ERP ทั้งองค์กร เพราะเห็นผลเร็วและทีมได้เรียนรู้การทำงานกับระบบใหม่ในขอบเขตเล็ก
ในทางกลับกัน งานอย่างการวางแผนการผลิตที่มีข้อยกเว้นเยอะและพึ่งประสบการณ์ของคนเก่ง แม้ผลกระทบสูงแต่ยังไม่พร้อมแปลงเป็นระบบทันที ควรเริ่มจากบันทึกกติกาการตัดสินใจให้เป็นลายลักษณ์อักษรก่อน เมื่อกติกานิ่งแล้วจึงค่อยแปลงเป็นซอฟต์แวร์ นี่คือเหตุผลว่าทำไมการจัดลำดับจึงสำคัญกว่าการรีบทำทุกอย่างพร้อมกัน
ขั้นตอนดำเนินงานที่แนะนำ
ใช้ลำดับนี้เพื่อเปลี่ยนผ่านทีละขั้นโดยไม่สะดุดงานประจำ
- ทำแผนที่ workflow หลักเลือกงานหลักห้าถึงสิบงาน แล้วเขียนขั้นตอนจริงร่วมกับคนหน้างาน
- ให้คะแนนและจัดลำดับประเมินผลกระทบกับความพร้อมของแต่ละงาน เลือกงานแรกที่คะแนนสูงทั้งสองด้าน
- ออกแบบร่วมกับผู้ใช้จริงให้ทีมที่ทำงานนั้นมีส่วนออกแบบหน้าจอและขั้นตอน ไม่ใช่รับระบบสำเร็จมาใช้อย่างเดียว
- นำร่องกับกลุ่มเล็กเปิดใช้กับทีมเดียวหรือสาขาเดียวก่อน เก็บปัญหาและปรับจนนิ่ง
- วัดผลและประกาศผลลัพธ์เทียบเวลาและคุณภาพกับก่อนเริ่ม แล้วสื่อสารให้ทั้งองค์กรเห็นว่าได้อะไร
- ขยายไปงานถัดไปนำบทเรียนจากงานแรกไปใช้เลือกและออกแบบงานที่สอง ทำเป็นวงจรต่อเนื่อง
เช็กลิสต์ก่อนเลือก workflow แรก
- งานนี้เกิดบ่อยและใช้เวลารวมมากพอที่การปรับปรุงจะคุ้ม
- ขั้นตอนปัจจุบันมีรูปแบบชัด ข้อยกเว้นไม่มากเกินไป
- ข้อมูลที่เกี่ยวข้องมีอยู่จริงและคุณภาพพอใช้
- ทีมที่ทำงานนี้เห็นปัญหาและอยากให้แก้ ไม่ใช่ถูกบังคับ
- มีเจ้าของโครงการที่ตัดสินใจได้และมีเวลาให้จริง
- ประเมินได้ว่าจะวัดผลสำเร็จด้วยตัวเลขอะไร
- ถ้าระบบใหม่มีปัญหา ยังกลับไปใช้วิธีเดิมได้ชั่วคราว
เปรียบเทียบการเริ่มเล็กกับการยกเครื่องทั้งองค์กร
ทั้งสองแนวทางมีที่ใช้ แต่สำหรับองค์กรที่เพิ่งเริ่ม การเริ่มเล็กมักเสี่ยงน้อยกว่า
| ประเด็น | เริ่มจาก workflow เดียว | ยกเครื่องพร้อมกันทั้งองค์กร |
|---|---|---|
| ระยะเวลาเห็นผล | สั้น เห็นผลได้ในไม่กี่สัปดาห์ถึงไม่กี่เดือน | ยาว มักใช้เวลาหลายเดือนถึงหลายปีก่อนได้ใช้จริง |
| ความเสี่ยง | จำกัดอยู่ในงานเดียว ถอยกลับได้ง่าย | สูง หากออกแบบพลาดจะกระทบหลายฝ่ายพร้อมกัน |
| การเรียนรู้ของทีม | ทีมได้เรียนรู้และปรับตัวทีละขั้น | ทีมต้องเปลี่ยนพฤติกรรมหลายอย่างพร้อมกัน |
| ความเหมาะสม | องค์กรส่วนใหญ่ โดยเฉพาะที่เพิ่งเริ่มเปลี่ยนผ่าน | องค์กรที่ระบบเดิมไปต่อไม่ได้จริง ๆ และมีทรัพยากรพร้อม |
ข้อผิดพลาดที่พบบ่อย
- เริ่มจากระบบใหญ่ที่สุดก่อนโครงการใหญ่ใช้เวลานานกว่าจะเห็นผล ทีมหมดแรงและความเชื่อมั่นก่อนได้ใช้จริง
- ซื้อซอฟต์แวร์ก่อนเข้าใจงานได้เครื่องมือที่ไม่ตรงกับขั้นตอนจริง สุดท้ายทีมกลับไปใช้วิธีเดิมและเงินเสียเปล่า
- ออกแบบโดยไม่ถามคนหน้างานระบบที่คนใช้ไม่มีส่วนออกแบบ มักพลาดรายละเอียดเล็ก ๆ ที่ทำให้งานจริงติดขัด
- ไม่เก็บตัวเลขก่อนเริ่มเมื่อไม่มีข้อมูลเปรียบเทียบ จะพิสูจน์ไม่ได้ว่าการลงทุนคุ้มค่า และของบประมาณรอบถัดไปยาก
- ประกาศใช้แล้วจบการเปลี่ยนผ่านต้องติดตาม adoption ต่อเนื่อง ระบบที่ไม่มีใครดูแลหลังเปิดตัวจะค่อย ๆ ถูกทิ้งร้าง
คำถามที่พบบ่อย
ธุรกิจเล็กมากควรเริ่มตรงไหน
เริ่มจากงานที่กินเวลาเจ้าของมากที่สุด เช่น การตอบลูกค้า การออกเอกสาร หรือการเช็กสต็อก เครื่องมือสำเร็จรูปราคาไม่แพงจำนวนมากครอบคลุมงานเหล่านี้ได้โดยไม่ต้องพัฒนาระบบเอง
ต้องจ้างที่ปรึกษาไหม
ไม่จำเป็นเสมอไป ขั้นการทำแผนที่งานและจัดลำดับทำเองได้ด้วยกรอบง่าย ๆ ที่ปรึกษาหรือผู้พัฒนาภายนอกจะคุ้มเมื่อถึงขั้นออกแบบระบบที่ซับซ้อนหรือเชื่อมหลายระบบเข้าด้วยกัน
ทีมไม่ถนัดเทคโนโลยี จะเปลี่ยนผ่านได้ไหม
ได้ ถ้าเริ่มจากงานที่ทีมเห็นประโยชน์ชัดและระบบใช้ง่ายกว่าวิธีเดิม ความไม่ถนัดมักหายไปเมื่อระบบช่วยให้งานเบาลงจริง สิ่งที่ทำให้ล้มเหลวคือระบบที่เพิ่มภาระโดยไม่ให้อะไรกลับมา
จะรู้ได้อย่างไรว่าโครงการแรกสำเร็จ
ดูจากตัวเลขที่ตั้งไว้ก่อนเริ่ม เช่น เวลาต่อรายการลดลง ข้อผิดพลาดน้อยลง หรือหางานย้อนหลังได้เร็วขึ้น และดูจากพฤติกรรม คือทีมใช้ระบบเป็นช่องทางหลักโดยไม่ต้องบังคับ ถ้าทั้งสองอย่างเป็นจริง ค่อยขยายไปงานถัดไป
แหล่งอ้างอิง
แหล่งข้อมูลสำหรับศึกษาต่อ
- สำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์ (ETDA) — ข้อมูลการเปลี่ยนผ่านดิจิทัลของไทย
- สำนักงานส่งเสริมวิสาหกิจขนาดกลางและขนาดย่อม (สสว.) — องค์ความรู้สำหรับ SME
- พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) — ข้อพิจารณาเมื่อแปลงข้อมูลลูกค้าเป็นดิจิทัล