ถ้าคุณไม่รู้จะเริ่มตรงไหน คำตอบมีเพียงข้อเดียว: อย่าเพิ่งสร้างระบบ ให้ตั้งคำถามก่อนว่าอะไรคือสิ่งที่ไม่จำเป็นและตัดทิ้งได้
ก่อนหน้านี้ ผมเคยเขียนไว้ว่า ความล้มเหลวในการพัฒนาระบบเป็นปัญหาเชิงโครงสร้าง ไม่ใช่เพราะผู้บริหารขาดความรู้ ต่อเนื่องจากแนวคิดนั้น บทความนี้จะเจาะลึกถึงขั้นตอนแรกสุดที่ลูกค้าควรทำ การตัดสินใจ "แค่สร้างระบบ" โดยที่ยังไม่ชัดเจน คือการเคลื่อนไหวที่แพงที่สุดที่คุณจะทำได้ หากเรียงลำดับผิด คุณก็จะเสียเงินไปกับการทำให้กระบวนการที่ไม่มีประสิทธิภาพทำงานโดยอัตโนมัติเท่านั้น
■ ความเข้าใจผิด: "การสร้างระบบ = ทางออก"
เมื่อให้คำปรึกษาลูกค้า คำขอเริ่มต้นมักจะเป็นแบบเดียวกันเสมอ: "การทำงานของเราไม่มีประสิทธิภาพ เราจึงอยากนำระบบมาใช้" อย่างไรก็ตาม เมื่อพิจารณาอย่างถี่ถ้วน ส่วนใหญ่กลับพบว่ามีจุดสูญเปล่า (Waste) ที่สามารถแก้ไขได้ตั้งแต่ก่อนเริ่มนำระบบเข้ามาใช้ด้วยซ้ำ
ยกตัวอย่างเช่น กระบวนการจัดทำใบเสนอราคาของบริษัทหนึ่ง พวกเขาอนุญาตให้พนักงานขายสร้างใบเสนอราคาผ่านระบบใหม่ แต่การอนุมัติภายในยังต้องพิมพ์เอกสารกระดาษและเวียนลงนามตามปกติ หลังจากได้รับอนุมัติแล้ว พนักงานก็ต้องคีย์จำนวนเงินจากใบเสนอราคาดิจิทัลลงในแบบฟอร์มกระดาษอีกครั้ง แม้จะเรียกว่า "มีระบบรองรับ" แล้ว แต่เวิร์กโฟลว์โดยรวมกลับเพิ่มขั้นตอนขึ้นมาอีกขั้น คือ "สร้างในระบบ แล้วคัดลอกไปกระดาษ" สาเหตุรากเหง้าคือไม่มีใครถามก่อนว่า "เราสามารถยกเลิกกระบวนการอนุมัติบนกระดาษได้ไหม?" ก่อนที่จะสร้างระบบ เงินลงทุนหลายล้านถูกนำไปใช้ แต่ ด้วยการทำให้ความสูญเปล่าที่ควรตัดทิ้งกลายเป็นระบบอัตโนมัติ ต้นทุนส่วนใหญ่จึงสูญเสียไปอย่างเปล่าประโยชน์
■ ตัดทิ้งก่อนเพิ่มเติม
มีหลักการปรับปรุงธุรกิจที่อยู่ยงคงกระพันมานานเรียกว่า ECRS: Eliminate (ตัดทิ้งได้ไหม?), Combine (รวมกันได้ไหม?), Rearrange (สลับลำดับได้ไหม?), Simplify (ทำให้ง่ายขึ้นได้ไหม?) คุณควรพิจารณา Automate (การสร้างระบบ) ก็ต่อเมื่อได้ไตร่ตรองสี่ขั้นตอนนี้จนละเอียดถี่ถ้วนแล้วเท่านั้น
ผู้จัดการโครงการจำนวนมากข้ามลำดับนี้และกระโดดไปที่ "Automation" ทันที ผลลัพธ์คือ งานที่ควรตัดทิ้ง การป้อนข้อมูลซ้ำซ้อนที่ควรรวมกัน และกระบวนการอนุมัติที่ควรทำให้เรียบง่าย กลับถูกฝังลงไปโดยตรงในซอฟต์แวร์ สิ่งที่ได้คือ ระบบที่ทำงานไร้สาระได้เร็วขึ้นและแม่นยำขึ้น น่าตลกที่เพราะพวกเขารู้สึกว่าตัวเอง "มีระบบแล้ว" จึงไม่มีใครสังเกตเห็นความสูญเปล่าที่อยู่เบื้องหลัง
สิ่งนี้สอดคล้องกับประเด็นที่ผมเคยกล่าวไว้ว่า ความล้มเหลวของระบบเกิดจากโครงสร้าง ไม่ใช่จากความไม่รู้ การข้ามลำดับ ECRS คือส่วนหนึ่งของโครงสร้างที่มีข้อบกพร่องนั้น
■ 4 คำถามเพื่อการตัดสินใจ
ก่อนจะพิจารณาการสร้างระบบ ให้ถามตัวเองด้วยคำถาม 4 ข้อนี้ตามลำดับ:
- งานนี้ ตัดทิ้งทั้งหมดได้ไหม? (Eliminate)
- สามารถ รวม หลายงานหรือเวิร์กโฟลว์ระหว่างแผนกเข้าด้วยกันได้ไหม? (Combine)
- สามารถปรับปรุงได้เพียงโดยการเปลี่ยน ลำดับหรือผู้รับผิดชอบ ไหม? (Rearrange)
- วิธีการเองสามารถ ทำให้เรียบง่ายลง ได้ไหม? (Simplify)
เฉพาะงานที่เหลืออยู่หลังจากตอบคำถามเหล่านี้เท่านั้นที่เป็นตัวเลือกสำหรับการสร้างระบบ ในทางกลับกัน หากคุณเข้าสู่ขั้นตอนการกำหนดความต้องการ (Requirements Definition) โดยไม่ได้พิจารณา 4 ข้อนี้ เมล็ดพันธุ์แห่งความล้มเหลวก็ได้ถูกหว่านลงไปเรียบร้อยแล้ว
■ ตอบโจทย์ความต้องการด้านความเร็ว
คุณอาจแย้งว่า "เราไม่มีเวลามานั่งคิดวิเคราะห์ เราต้องนำระบบมาใช้ให้เร็วที่สุด" อย่างไรก็ตาม การวิเคราะห์แบบ ECRS มักใช้เวลาเพียงไม่กี่วันหรือไม่กี่สัปดาห์ ตรงกันข้าม หากเร่งรีบสร้างระบบแล้วภายหลังต้องมาแก้ข้อกำหนดใหม่ คุณจะเสียเวลาไปหลายเดือน ความพยายามที่จะรีบร้อนมักนำไปสู่เส้นทางอ้อม
อีกข้อโต้แย้งหนึ่งคือ "การทำงานของเราซับซ้อนเกินกว่าจะใช้กรอบแนวคิดภายนอกได้" แต่ ECRS ไม่ได้ต้องการความรู้เชิงลึกเกี่ยวกับรายละเอียดการทำงาน ผู้ที่รู้รายละเอียดดีที่สุดคือพนักงานหน้างาน ECRS เป็นเพียงชุดคำถามเพื่อกระตุ้นให้พวกเขาถามว่า "ตัดอันนี้ได้ไหม?" หรือ "รวมอันนี้ได้ไหม?" ซึ่งสามารถนำมาใช้ได้ทันทีโดยไม่ต้องมีความเชี่ยวชาญเฉพาะทาง
■ สิ่งที่คุณทำได้ในวันพรุ่งนี้
ไม่จำเป็นต้องมีการปฏิรูปองค์กรครั้งใหญ่ เลือกหนึ่งงานที่คุณกำลังอยาก "สร้างระบบ" อยู่ตอนนี้ แล้วตอบคำถาม 4 ข้อข้างต้น บ่อยครั้งที่คำถามแรก (Eliminate) จะเผยให้เห็นทางเลือกที่คุณไม่เคยคิดถึงมาก่อน
เหตุผลแท้จริงของอาการ "ไม่รู้จะเริ่มตรงไหน" มักไม่ใช่เรื่องว่าจะสร้างระบบดีหรือไม่ แต่เป็นการไม่รู้ว่าต้องวิเคราะห์ *อะไร* ก่อนที่จะสร้างระบบต่างหาก หากคุณทำตามลำดับที่ถูกต้อง การตัดสินใจก็ไม่ใช่เรื่องยาก
ครั้งต่อไป ผมจะพูดถึงความเจ็บปวดสากลที่สุดของผู้บริหาร: "คนลาออก" เราจะมาคุยกันเรื่องโครงสร้างองค์กรที่อยู่เบื้องหลังอัตราการหมุนเวียนพนักงาน
หากสนใจ กรุณาส่งข้อความส่วนตัว (DM) หาผมผ่าน ลิงก์นี้
■ บทความเก่าที่เกี่ยวข้อง
