5 สัญญาณว่าระบบ Excel ไม่พอสำหรับโรงงานคุณอีกต่อไป (และเริ่มแก้ได้โดยไม่ต้องเปลี่ยนทั้งระบบ)

หลายโรงงานในไทย โดยเฉพาะโรงงานที่ทายาทรุ่นใหม่เพิ่งเข้ามาช่วยดูกิจการ กำลังเจอจุดเดียวกัน คือระบบที่ใช้มาตั้งแต่รุ่นพ่อแม่อย่าง Excel เริ่มตามธุรกิจไม่ทัน แต่การเปลี่ยนไปใช้ระบบ ERP เต็มรูปแบบก็ดูเป็นการลงทุนที่ใหญ่เกินไปสำหรับปัญหาที่ยังไม่รู้ขอบเขตแน่ชัด

มีจุดที่น่าสนใจคือ หลายบริษัทที่ใช้ Microsoft 365 อยู่แล้ว ทั้งอีเมลและ Excel มีเครื่องมือสร้างแอปแบบ Low-code อย่าง Power Apps รวมอยู่ในแพ็กเกจโดยไม่รู้ตัว คุณฟ้า Head of Low Code No Code Service ที่ ZyGen เปรียบไว้ในพอดแคสต์ ชวนคุยเทคสไตล์ ZyGener EP.4 ว่าเหมือนมี “โรงงานผลิตระบบ” อยู่ในมือ แต่ยังไม่เคยเปิดใช้งาน

บทความนี้จะพาเช็ก 5 สัญญาณที่บอกว่าระบบ Excel ของโรงงานเริ่มโตไม่ทันธุรกิจ และจุดเริ่มต้นที่ทำได้จริงโดยไม่ต้องรื้อระบบทั้งหมดในครั้งเดียว

รู้ได้อย่างไรว่าระบบ Excel ของโรงงานเริ่ม “โตไม่ทัน” ธุรกิจ

สัญญาณที่ชัดที่สุดไม่ใช่ Excel พังหรือใช้งานไม่ได้ แต่คือช่วงเวลาที่ทีมงานต้องเสียเวลากับการ “ดูแลไฟล์” มากกว่าการทำงานจริง เช่น ต้องเช็กว่าใครแก้ไฟล์ล่าสุด ต้องรอคนคนเดียวที่เข้าใจสูตรมาช่วยดึงรายงาน หรือตัวเลขในไฟล์ไม่ตรงกับของจริงบนไลน์ผลิต 

Excel เองไม่ใช่ปัญหา มันยังเป็นเครื่องมือที่ดีสำหรับการคำนวณและวิเคราะห์ข้อมูลชุดเล็ก แต่พอธุรกิจโตขึ้น จำนวนคนใช้งานมากขึ้น และข้อมูลต้องอัปเดตแบบเรียลไทม์มากขึ้น Excel ที่ออกแบบมาสำหรับคนคนเดียวทำงานบนไฟล์เดียว ก็เริ่มไม่พอกับงานที่ต้องมีหลายคนป้อนข้อมูลพร้อมกัน 

ลองเช็ก 5 สัญญาณต่อไปนี้ ถ้าโรงงานของคุณเจอตั้งแต่ 2 ข้อขึ้นไป นั่นคือจุดที่ควรเริ่มคุยเรื่องนี้จริงจัง 

สัญญาณที่ 1: นับสต๊อกด้วยกระดาษ แล้วค่อยคีย์ลง Excel ทีหลัง 

ทีมงานยังเดินนับสต๊อกด้วยกระดาษ แล้วนำตัวเลขมาคีย์ใส่ Excel ทีหลังที่โต๊ะทำงาน ระหว่างทางนี้มีจุดเสี่ยงความผิดพลาดอย่างน้อย 2 รอบ คือตอนจดด้วยมือ และตอนคีย์ข้อมูล และกว่าตัวเลขจะเข้าระบบ ของจริงบนไลน์ก็เปลี่ยนไปแล้ว 

ในพอดแคสต์เดียวกัน คุณฟ้ายกตัวอย่างเคสที่เจอบ่อยคือ การเปลี่ยนจากนับสต๊อกด้วยกระดาษแล้วคีย์ลง Excel มาเป็นแอปบนมือถือที่สแกน QR Code หรือ Barcode แล้วตัดสต๊อกเข้าระบบกลางทันที ข้อมูลที่ได้จึงเป็นแบบเรียลไทม์ และลดขั้นตอนที่ต้องพึ่งการจดจำหรือคีย์ซ้ำของคน 

สัญญาณที่ 2: มีไฟล์ Excel หลายเวอร์ชัน ไม่รู้ไฟล์ไหนคือของจริง 

“stock_final.xlsx”, “stock_final_v2.xlsx”, “stock_final_ใช้อันนี้.xlsx” ถ้าชื่อไฟล์แบบนี้คุ้นตา นี่คือสัญญาณคลาสสิกของระบบที่โตเกินขีดจำกัดของไฟล์เดียว เพราะ Excel ไม่ได้ออกแบบมาให้หลายคนแก้ไขพร้อมกันแบบปลอดภัย พอมีคนก๊อปไฟล์ไปแก้แยก ความจริงก็แตกเป็นหลายเวอร์ชันทันที 

ทีมวิจัยนำโดย Pak-Lok Poon ซึ่งตีพิมพ์ในวารสาร Frontiers of Computer Science ปี 2024 โดยรวบรวมงานวิจัยด้านคุณภาพสเปรดชีตย้อนหลังกว่า 35 ปี พบว่าสเปรดชีตที่ใช้งานจริงในการตัดสินใจทางธุรกิจราว 94% มีข้อผิดพลาดอย่างน้อย 1 จุด ยิ่งไฟล์ถูกคัดลอกและแก้ไขแยกกันหลายทาง โอกาสที่ตัวเลขจะคลาดเคลื่อนก็ยิ่งสูงขึ้นตามไปด้ว

สัญญาณที่ 3: งานค้าง เพราะต้องรอคิวทีม IT หรือ Vendor ภายนอก 

ทีมปฏิบัติงานมีไอเดียอยากได้ฟอร์มอนุมัติแบบง่าย ๆ หรืออยากได้หน้าจอบันทึกข้อมูลเพิ่มอีกนิด แต่ต้องรอคิวทีม IT ซึ่งมีงานสำคัญกว่าต้องทำก่อน หรือรอ Vendor ภายนอกที่คิดค่าพัฒนาเป็นโปรเจกต์ ใช้เวลาเป็นไตรมาส ทั้งที่งานที่ต้องการแก้จริง ๆ ไม่ได้ซับซ้อนขนาดนั้น 

คุณฟ้าอธิบายไว้ว่า ถ้าให้ทีม IT พัฒนาระบบเองทั้งหมด จะได้ระบบที่ครบถ้วนสมบูรณ์เกือบ 100% แต่ต้องแลกกับเวลาที่นานขึ้น ในขณะที่ถ้าให้ทีม Business ที่เข้าใจปัญหาหน้างานที่สุดสร้างแอปแก้ปัญหาเฉพาะจุดด้วยตัวเอง แม้ความสมบูรณ์ของระบบอาจได้แค่ราว 70% แต่ใช้เวลาแค่ไม่กี่วัน และช่วยพิสูจน์ได้ก่อนว่าฟีเจอร์ไหนจำเป็นจริง ก่อนจะตัดสินใจลงทุนเพิ่มในจุดที่คุ้มค่า 

สัญญาณที่ 4: เวลาส่วนใหญ่หมดไปกับ “การรวมข้อมูล” ไม่ใช่ “การตัดสินใจ” 

ก่อนจะประชุมทุกครั้ง ต้องมีคนนั่งรวมตัวเลขจากหลายไฟล์ หลายแผนกเข้าด้วยกัน กว่าจะได้ภาพรวมมาใช้ตัดสินใจ เวลาส่วนใหญ่ในสัปดาห์จึงหมดไปกับการ “เตรียมข้อมูล” มากกว่าการวิเคราะห์หรือลงมือแก้ปัญหาจริง 

สัญญาณที่ 5: ทายาทรุ่นใหม่อยากเห็นข้อมูลเรียลไทม์ แต่ระบบเดิมไปไม่ถึง 

เมื่อทายาทรุ่นใหม่เข้ามาช่วยบริหาร มักต้องการเห็นข้อมูลต้นทุนและสต๊อกแบบเรียลไทม์เพื่อตัดสินใจเรื่องราคาให้ทันสถานการณ์ แต่ระบบ Excel เดิมให้ได้แค่ภาพย้อนหลังของเมื่อวาน หรือของสัปดาห์ก่อน ความต้องการของคนรุ่นใหม่กับขีดจำกัดของระบบเดิมจึงเริ่มชนกัน นี่เป็นโจทย์ที่เราเคยพูดถึงไว้ในแง่การแข่งขันด้านราคาด้วยเช่นกัน ในบทความเรื่อง Low-Code กับโรงงานครอบครัวในสงครามราคา

ไม่ต้องเปลี่ยนทั้งระบบ ทำไม Low-code คือจุดเริ่มต้นที่เหมาะกับโรงงานขนาดนี้

คำตอบสั้น ๆ คือ Low-code แก้ปัญหาทีละจุดได้เร็ว โดยไม่ต้องรอโปรเจกต์ใหญ่ทั้งระบบ

Low-Code Application Platform (LCAP) คือเครื่องมือพัฒนาแอปพลิเคชันที่เน้นการลากวางองค์ประกอบหน้าจอ แล้วใส่ลอจิกเพิ่มเติมทีหลัง แทนที่จะต้องเขียนโค้ดทุกบรรทัดตั้งแต่ต้น จึงพัฒนาได้เร็วกว่าการพัฒนาแบบดั้งเดิมมาก งานศึกษา Total Economic Impact ของ Forrester Consulting ซึ่งสัมภาษณ์องค์กรที่ใช้งาน Power Apps จริง 4 แห่ง พบว่าการพัฒนาแอปด้วย Power Apps ใช้เวลาน้อยลงราว 50% เมื่อเทียบกับการพัฒนาแบบเขียนโค้ดทั้งหมด โดยผู้ให้สัมภาษณ์รายหนึ่งระบุว่า “ถ้าประมาณจำนวนชั่วโมงที่ใช้สร้างงานด้วย low-code เทียบกับ high-code ตัวเลขคร่าวๆ คือลดลงไปประมาณครึ่งหนึ่ง”

สำหรับโรงงานที่ยังไม่มีทีม IT ของตัวเอง หรือมีแต่ทีมเล็กที่ต้องดูแลหลายเรื่องพร้อมกัน จุดแข็งของ Low-code คือให้คนที่เข้าใจหน้างานที่สุด อย่างหัวหน้าไลน์ผลิตหรือฝ่ายคลังสินค้า สร้างเครื่องมือแก้ปัญหาเฉพาะจุดของตัวเองได้ โดยไม่ต้องรอทีมพัฒนาระบบจากภายนอก

ปัจจุบันหลายแพลตฟอร์ม Low-code รวมถึง Power Apps ยังมีผู้ช่วย AI ที่ทำให้สามารถสร้างแอปพลิเคชันได้ง่ายมากยิ่งขึ้น เพียงพิมพ์คุยเป็นภาษาทั่วๆ ไป

คำนวณ ROI ง่าย ๆ ก่อนเริ่ม 

วิธีที่ตรงไปตรงมาที่สุดคือคำนวณจากเวลาที่ประหยัดได้ต่อรายการ 

คุณฟ้ายกตัวอย่างไว้ในพอดแคสต์ว่า งานที่เดิมต้องค้นเอกสารหรือคีย์ข้อมูลย้อนหลังใช้เวลาราว 30 นาทีต่อรายการ เมื่อเปลี่ยนมาเป็นระบบที่ค้นและบันทึกผ่านแอป เวลาที่ใช้ลดเหลือต่ำกว่า 5 นาทีต่อรายการ เท่ากับประหยัดไปประมาณ 25 นาทีต่อรายการ ถ้าทีมงาน 2 คนทำงานลักษณะนี้คนละ 10 รายการต่อวัน จะประหยัดเวลารวมได้ราว 8 ชั่วโมงต่อวัน คิดเป็นต้นทุนที่ประหยัดได้ประมาณ 1,600 บาทต่อวัน หรือราว 32,000 บาทต่อเดือน 

ตัวเลขนี้เป็นแค่ตัวอย่างจากงานหนึ่งประเภท แต่กรอบการคิดใช้ได้กับแทบทุกงานที่ทำซ้ำในโรงงาน ลองแทนค่าด้วยตัวเลขของงานที่โรงงานคุณทำซ้ำบ่อยที่สุด เช่น เวลาต่อรายการก่อนและหลัง จำนวนรายการต่อวัน และจำนวนคนที่ทำงานนี้ ก็จะเห็นภาพคร่าว ๆ ว่าคุ้มค่าจะเริ่มหรือไม่ ก่อนตัดสินใจลงทุนอะไรเพิ่ม

กรณีที่ไม่ควรใช้ Low-code 

Low-code ไม่ใช่คำตอบสำหรับทุกปัญหา และการเลือกเครื่องมือไม่ตรงกับความต้องการอาจทำให้ต้นทุนสูงกว่าที่คิด 

ตัวอย่างที่คุณฟ้ายกไว้คือ งานที่ต้องเซ็นเอกสารจำนวนมากร่วมกับบุคคลภายนอก ผ่านระบบอย่าง DocuSign หรือ Adobe Sign ถ้าพยายามทำบน Power Apps จะต้องเสียทั้งค่า License ของระบบเซ็นเอกสารภายนอก และค่า Power Apps Premium License ซ้อนกัน กรณีแบบนี้การพัฒนาเป็น Web App แยกต่างหากมักคุ้มค่ากว่า 

หลักคร่าวๆ คือ ถ้างานนั้นต้องพึ่งระบบภายนอกที่มีค่าใช้จ่ายเฉพาะทางอยู่แล้ว หรือมีปริมาณธุรกรรมสูงมากจนต้องการโครงสร้างเฉพาะ ควรพิจารณาทางเลือกอื่นควบคู่ไปด้วย ไม่ใช่ใช้ Low-code เป็นคำตอบเดียวสำหรับทุกงาน 

ต้องกังวลเรื่องความปลอดภัยไหม 

ไม่จำเป็นต้องปล่อยให้ทุกคนสร้างแอปได้อย่างอิสระโดยไม่มีการควบคุม ทีม IT ยังกำหนดกรอบความปลอดภัยได้ตามปกติ เช่น การกำหนดสิทธิ์การเข้าถึงตามบทบาทของผู้ใช้งาน การแยกสภาพแวดล้อมสำหรับพัฒนา ทดสอบ และใช้งานจริงออกจากกัน และการตั้งค่านโยบายข้อมูลตามมาตรฐานองค์กร 

จุดนี้สำคัญโดยเฉพาะเมื่อธุรกิจเริ่มมีหลายคนสร้างแอปใช้งานเอง เพราะถ้าไม่มีแนวทางกำกับดูแลตั้งแต่ต้น แอปเล็ก ๆ หลายตัวที่ต่างคนต่างสร้างอาจกลายเป็นข้อมูลกระจัดกระจายที่ตามดูแลยากในภายหลัง การเริ่มต้นกับทีมที่มีประสบการณ์วางกรอบตั้งแต่แรกจึงช่วยลดความเสี่ยงนี้ได้ 

เริ่มต้นอย่างไรดี 

เริ่มจากงาน Manual เล็กๆ ที่ทำซ้ำบ่อยที่สุดก่อน เช่น ฟอร์มขออนุมัติ หรือการบันทึกข้อมูลประจำวันที่ยังใช้กระดาษหรือ Excel อยู่ ทำเป็นแอปเล็กๆ ให้เห็นผลลัพธ์จริงก่อน แล้วค่อยขยายไปยังจุดอื่น การมีผู้เชี่ยวชาญหรือคู่มือแนะนำตั้งแต่ต้นจะช่วยให้เริ่มต้นได้เร็วขึ้น และวางกรอบความปลอดภัยไว้ตั้งแต่แอปตัวแรก แทนที่จะย้อนกลับมาแก้ทีหลัง 

คำถามที่พบบ่อย

ถ้าโรงงานของคุณใช้ Microsoft 365 อยู่แล้ว มีโอกาสสูงที่ Power Apps รวมอยู่ในแพ็กเกจโดยที่ยังไม่เคยเปิดใช้ ทีม ZyGen ช่วยประเมินได้ว่าโรงงานของคุณมีเครื่องมือนี้อยู่แล้วหรือไม่ และงานไหนควรเริ่มก่อน อ่านรายละเอียดเพิ่มเติมเกี่ยวกับ Microsoft Power Apps หรือติดต่อทีมที่ปรึกษาเพื่อคุยถึงจุดเริ่มต้นที่เหมาะกับโรงงานของคุณ