ข้อ 1 และ 2: ซื้อเครื่องมือก่อนรู้ปัญหา และไม่มีเจ้าของ
ข้อแรกคือเริ่มจากเครื่องมือ เช่น "เราต้องมี ERP" หรือ "เราต้องมี AI" ทั้งที่ยังไม่ได้ระบุว่าปัญหาจริงคืออะไร ผลคือได้ระบบที่ฟีเจอร์มากแต่ไม่ตรงกับงานที่ทีมทำทุกวัน ให้เริ่มจากการเขียนปัญหาเป็นประโยคเดียว เช่น "ใบเสนอราคาใช้เวลาสามวันกว่าจะถึงลูกค้า" แล้วค่อยหาเครื่องมือที่แก้ตรงนั้น
ข้อสองคือไม่มีเจ้าของ โครงการที่ทุกแผนกเป็นเจ้าของร่วมกันมักจบลงด้วยการที่ไม่มีใครเป็นเจ้าของเลย ควรมีคนหนึ่งคนที่มีอำนาจตัดสินใจและรับผิดชอบผลลัพธ์ทางธุรกิจ ไม่ใช่แค่ดูแลทางเทคนิค และต้องได้รับเวลาจากงานประจำเพื่อทำเรื่องนี้จริง ๆ
ข้อ 3: ทำแบบ big bang
การเปลี่ยนทุกระบบพร้อมกันในวันเดียวฟังดูเด็ดขาด แต่ความเสี่ยงสูงมาก ถ้ามีจุดผิดพลาดเพียงจุดเดียว ทั้งองค์กรจะหยุดชะงัก และไม่มีทางถอยกลับง่าย ๆ
ทางที่ปลอดภัยกว่าคือแบ่งเป็นขั้นเล็ก ๆ เลือกแผนกหรือกระบวนการหนึ่งเป็นตัวนำร่อง เรียนรู้จากมัน ปรับ แล้วจึงขยาย ระหว่างนั้นให้ระบบเก่ากับใหม่ทำงานคู่กันช่วงหนึ่ง เพื่อให้มีทางถอยถ้าพบปัญหา
ระบบที่คนใช้ครึ่งเดียวทุกวัน ดีกว่าระบบสมบูรณ์แบบที่ไม่มีใครเปิด
ข้อ 4: ไม่ฟังคนที่ต้องใช้งาน
พนักงานหน้างานรู้ดีที่สุดว่ากระบวนการจริงเป็นอย่างไร รวมถึงทางลัดและเหตุผลที่ไม่เขียนไว้ในคู่มือ ถ้าระบบใหม่ออกแบบโดยไม่ถามพวกเขา ก็เป็นเรื่องปกติที่จะพบการต่อต้านหรือหาทางหลบไปใช้ Excel และกลุ่ม LINE เหมือนเดิม
ให้เชิญคนใช้งานจริงเข้ามาตั้งแต่ช่วงออกแบบ ทำ prototype ให้ลองใช้ ฟังว่าติดขัดตรงไหน และจัดอบรมที่ใช้ข้อมูลจริงของงานเขา ไม่ใช่สไลด์ทั่วไป การทำ UX research กับพนักงานภายในก็สำคัญเท่ากับกับลูกค้า
ข้อ 5: ข้อมูลรกแล้วย้ายเข้าระบบใหม่ทั้งอย่างนั้น
ระบบใหม่ไม่ได้ทำให้ข้อมูลเก่าสะอาดขึ้นเอง ถ้าลูกค้าคนเดียวมีสามชื่อ รหัสสินค้าไม่ตรงกัน หรือฟิลด์สำคัญว่างอยู่ ก็จะเอาปัญหาเดิมไปอยู่ในระบบที่แพงกว่าเดิม
ก่อนย้ายข้อมูลให้สำรวจคุณภาพ ตัดสินว่าอะไรควรทิ้ง อะไรต้องแก้ และกำหนดเจ้าของข้อมูลแต่ละประเภท รวมถึงดูเรื่อง PDPA ว่าข้อมูลส่วนบุคคลที่เก่าเกินความจำเป็นไม่ควรถูกย้ายตามไปด้วย
ข้อ 6: วัดผลด้วยตัวเลขที่ดูดีแต่ไม่มีความหมาย
ตัวชี้วัดแบบ vanity เช่น จำนวนผู้ใช้ที่ลงทะเบียน จำนวนฟีเจอร์ที่ปล่อย หรือจำนวนหน้าแดชบอร์ด ดูดีในรายงานแต่ไม่ได้บอกว่าธุรกิจดีขึ้นหรือไม่ ให้ผูกตัวชี้วัดกับปัญหาที่ตั้งไว้ตั้งแต่ต้น เช่น เวลาจากรับออเดอร์ถึงส่งของ จำนวนครั้งที่ต้องคีย์ข้อมูลซ้ำ หรือจำนวนเรื่องที่ลูกค้าติดต่อมาถามสถานะ
อย่าลืมวัดก่อนเริ่มโครงการด้วย ถ้าไม่มีตัวเลขก่อนหน้า ก็ไม่มีทางรู้ว่าดีขึ้นจริงหรือแค่รู้สึกว่าดีขึ้น
ข้อ 7: ไม่เผื่องบหลังขึ้นระบบ และสรุปเป็นเช็กลิสต์
หลายองค์กรตั้งงบสำหรับการสร้างระบบ แต่ไม่ได้ตั้งงบสำหรับการใช้งานต่อ ทั้งที่ต้องมีค่าโฮสติ้ง ค่าสมัครใช้บริการ การแก้บั๊ก การปรับตามธุรกิจที่เปลี่ยน และคนดูแล ระบบที่ไม่มีงบดูแลจะเสื่อมลงเงียบ ๆ จนกลายเป็นระบบเก่าตัวใหม่ที่ต้องรื้อในไม่กี่ปี
ให้เผื่องบดูแลรายปีเป็นสัดส่วนที่สมเหตุสมผลของงบสร้างตั้งแต่ตอนอนุมัติโครงการ และกำหนดว่าใครมีหน้าที่ดูแล ก่อนเริ่มโครงการ ลองใช้รายการนี้ตรวจตัวเอง
- เรารู้ปัญหาที่จะแก้และเขียนเป็นประโยคเดียวได้ไหม
- มีเจ้าของคนเดียวที่มีอำนาจและเวลาไหม
- แบ่งเป็นขั้นเล็กและมีทางถอยไหม
- คนใช้งานจริงมีส่วนร่วมตั้งแต่ออกแบบไหม
- ข้อมูลที่จะย้ายสะอาดพอและมีเจ้าของไหม
- ตัวชี้วัดผูกกับปัญหาและวัดก่อนเริ่มไว้แล้วไหม
- มีงบและคนดูแลหลังขึ้นระบบไหม
สรุปสั้น ๆ
- เริ่มจากปัญหาที่เขียนเป็นประโยคเดียวได้ ไม่ใช่จากชื่อเครื่องมือ
- ต้องมีเจ้าของคนเดียวที่มีอำนาจตัดสินใจและมีเวลา
- แบ่งเป็นขั้นเล็กพร้อมทางถอย แทนการเปลี่ยนทั้งหมดในวันเดียว
- ให้พนักงานที่ใช้งานจริงมีส่วนร่วม และทำความสะอาดข้อมูลก่อนย้าย
- วัดผลที่ผูกกับปัญหา และเผื่องบดูแลระบบหลังขึ้นใช้งาน
คำถามที่พบบ่อย
บริการที่เกี่ยวข้อง
มีโปรเจกต์แบบนี้อยู่ในใจไหม
เล่าให้เราฟังว่าตอนนี้อยู่ตรงไหน เดี๋ยวเราแนะนำก้าวแรกที่เหมาะให้ โดยไม่มีข้อผูกมัด
คุยกับเรา
