ใช้ Excel จัดการงานอยู่ดี ๆ เมื่อไรถึงควรเปลี่ยนเป็น Web App?

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

ตรงนี้มักมีคำถามว่า ถึงเวลาหรือยังที่จะเปลี่ยน Excel เป็น Web App? คำตอบคือ ยังไม่ควรดูแค่ว่าไฟล์ใหญ่หรือมีคนใช้กี่คนครับ เพราะ Excel ยังเป็นเครื่องมือที่ดีมากสำหรับงานหลายประเภท และ Microsoft เองก็รองรับการทำงานร่วมกันบนไฟล์เดียวผ่านระบบ Cloud ได้ หากรูปแบบงานยังเรียบง่าย การทำระบบใหม่อาจเพิ่มค่าใช้จ่ายโดยไม่ได้แก้ปัญหาอะไรจริง

สิ่งที่ควรดูมากกว่าคือ “ทีมกำลังเสียเวลาและเสี่ยงผิดพลาดตรงไหนซ้ำ ๆ” ถ้าปัญหาเริ่มมาจาก Workflow, สิทธิ, สถานะ, ประวัติ และการเชื่อมข้อมูล ไม่ใช่แค่หน้าตาของตาราง ตรงนั้นค่อยเป็นจังหวะที่ Web App น่าสนใจขึ้นครับ

ก่อนอื่น Excel ไม่ได้ผิด และไม่จำเป็นต้องเลิกใช้เพราะบริษัทโตขึ้น

ถ้างานของคุณเป็นการเก็บรายการ วิเคราะห์ตัวเลข ทำประมาณการ สรุปรายงาน หรือมีคนรับผิดชอบข้อมูลชัดเจน Excel ยังตอบโจทย์ได้ดีมาก การที่มีผู้ใช้มากกว่าหนึ่งคนก็ยังไม่ใช่เหตุผลพอที่จะย้ายระบบ เพราะ Microsoft รองรับการ Co-author หรือแก้ไฟล์ร่วมกันเมื่อเก็บ Workbook บน OneDrive หรือ SharePoint Online อยู่แล้ว

รายละเอียดเรื่องการทำงานร่วมกันมีอธิบายไว้ใน คู่มือ Co-authoring ของ Microsoft ซึ่งตรงนี้สำคัญ เพราะช่วยให้เราแยกได้ว่า “ปัญหาแชร์ไฟล์” กับ “ปัญหา Workflow” เป็นคนละเรื่องกัน

ถ้าแค่หาไฟล์ไม่เจอหรือส่งเวอร์ชันกันทางแชต การจัด Cloud Storage และสิทธิให้ดีอาจแก้ได้โดยไม่ต้องเขียนระบบใหม่เลยครับ

สัญญาณแรก: ทีมไม่ได้กรอกข้อมูล แต่กำลัง “คัดลอกข้อมูล” ทั้งวัน

ลองดูงานหนึ่งรอบแบบไม่ต้องเปิดศัพท์เทคนิคก็ได้ครับ สมมติฝ่ายขายรับข้อมูลจาก LINE แล้วคัดลง Excel จากนั้นแอดมินเอาข้อมูลเดียวกันไปสร้างใบงาน ทีมผลิตคัดบางช่องไปอีกไฟล์ และตอนจบมีคนเอายอดกลับมาสรุปในไฟล์ Dashboard อีกครั้ง

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

ถ้าเจอภาพนี้บ่อย ๆ Web App เริ่มมีข้อได้เปรียบ เพราะข้อมูลสามารถถูกบันทึกครั้งเดียวแล้วใช้ต่อในหลายขั้นตอน เช่น ฝ่ายขายสร้างรายการ → ฝ่ายปฏิบัติการเห็นรายการเดียวกัน → ผู้จัดการอนุมัติจากรายการเดิม → Dashboard อ่านจากฐานข้อมูลเดียวกัน ไม่ต้องสร้างสำเนาหลายชุด

สัญญาณที่สอง: ทุกเช้ามีคนถามว่า “งานนี้ถึงไหนแล้ว”

Excel เก็บ Status ได้แน่นอนครับ จะใส่ Pending, In Progress, Done ก็ได้ แต่ถ้างานมีการเปลี่ยนสถานะหลายขั้น เช่น รอข้อมูล → รอตรวจ → รออนุมัติ → ส่งลูกค้า → แก้ไข → ปิดงาน ความยากจะเริ่มอยู่ที่ว่าใครมีสิทธิเปลี่ยนสถานะไหน และเปลี่ยนเมื่อไร

พอทีมโตขึ้น เรามักเห็นการใช้สีแทนสถานะ ใช้คอมเมนต์แทนประวัติ ใช้ข้อความใน LINE แทนเหตุผล แล้วสุดท้ายไม่มีใครแน่ใจว่าแถวนี้เขียวเพราะเสร็จแล้ว หรือเพราะมีคนเผลอเติมสีไว้

Web App จะเหมาะขึ้นเมื่อ “สถานะ” เป็นส่วนหนึ่งของกระบวนการจริง ไม่ใช่แค่ข้อมูลประกอบ เช่น เมื่อกดอนุมัติแล้วต้องล็อกบางช่อง ส่งแจ้งเตือน บันทึกผู้อนุมัติ หรือพาไปขั้นตอนถัดไปอัตโนมัติ

สัญญาณที่สาม: ต้องซ่อนข้อมูลบางอย่าง แต่ทุกคนเปิดไฟล์เดียวกัน

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

Web App ช่วยแยก Role ได้เป็นธรรมชาติกว่า เช่น Sales เห็นเฉพาะลูกค้าที่ดูแล Finance เห็นข้อมูลการเงิน Manager เห็นภาพรวม และ Customer เห็นเฉพาะงานตัวเอง ถึงจะทำสิทธิใน Spreadsheet ได้บางระดับ แต่หากสิทธิกลายเป็นส่วนหลักของระบบ การออกแบบบนฐานข้อมูลและหน้าจอเฉพาะบทบาทมักดูแลง่ายกว่าในระยะยาว

สัญญาณที่สี่: เวลามีข้อมูลผิด ไม่มีใครรู้ว่าใครแก้อะไร

อันนี้เป็นจุดที่หลายทีมเริ่มเหนื่อยครับ สมมติยอดจาก 85,000 กลายเป็น 58,000 หรือกำหนดส่งเปลี่ยนจากวันที่ 18 เป็นวันที่ 28 สิ่งแรกที่ต้องทำคือถามในกลุ่มว่า “ใครแก้ช่องนี้ครับ?”

ถ้าคำถามแบบนี้เกิดบ่อย แปลว่าธุรกิจเริ่มต้องการ Audit Trail หรือประวัติการเปลี่ยนแปลงที่ชัดกว่าเดิม เช่น ใครเปลี่ยน ค่าเดิมคืออะไร ค่าใหม่คืออะไร เปลี่ยนเวลาไหน และเปลี่ยนเพราะเหตุผลอะไร

ไม่ใช่ทุก Web App จะมี Audit Log อัตโนมัติครับ ต้องออกแบบตั้งแต่ Requirement แต่ข้อดีคือเราสามารถกำหนดมันเป็นส่วนหนึ่งของระบบตั้งแต่แรก แทนที่จะหวังว่าทุกคนจะพิมพ์หมายเหตุให้ครบเอง

สัญญาณที่ห้า: ข้อมูลเดียวกันกระจายอยู่ 5 ไฟล์ แล้วต้อง VLOOKUP กันไปมา

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

ความเสี่ยงจึงไม่ใช่แค่ “สูตรพัง” แต่คือถ้าคนที่รู้โครงสร้างลาออก คนใหม่อาจใช้เวลานานมากกว่าจะเข้าใจว่าข้อมูลไหลอย่างไร

Web App ที่ออกแบบ Data Model ชัดจะเปลี่ยนจากการเชื่อมไฟล์เป็นความสัมพันธ์ของข้อมูล เช่น Customer หนึ่งรายมีหลาย Order, Order หนึ่งรายการมีหลาย Task และ Task แต่ละงานมี Owner กับ Status ทำให้โครงสร้างถูกอธิบายและตรวจสอบได้ง่ายขึ้น

แต่มีข้อมูลเยอะ ไม่ได้แปลว่าต้องทำ Web App เสมอ

หลายคนชอบตั้งเกณฑ์ว่า “เกินกี่พันแถวต้องเปลี่ยนระบบ” ผมว่าใช้เกณฑ์เดียวแบบนั้นอันตรายไปหน่อยครับ เพราะตาราง 50,000 แถวที่ใช้เพื่อวิเคราะห์เดือนละครั้งอาจยังเหมาะกับ Excel มากกว่าตาราง 800 แถวที่มีคน 15 คนแก้พร้อมกัน มีการอนุมัติสามชั้น และผิดหนึ่งครั้งแล้วกระทบลูกค้า

จำนวนข้อมูลมีผลกับการออกแบบระบบแน่นอน แต่ควรดูร่วมกับรูปแบบการ Query, การค้นหา, สิทธิ และความเร็วที่ต้องการด้วย ตัวอย่างจาก Microsoft Learn เรื่อง Power Apps ก็ชี้ให้เห็นว่า Data Source แต่ละแบบรองรับการประมวลผลไม่เหมือนกัน และบาง Query ที่ไม่สามารถ Delegate ไปยังแหล่งข้อมูลได้จะมีข้อจำกัดจำนวน Records ที่นำมาประมวลผลฝั่งแอป เอกสารเรื่อง Delegation ของ Microsoft Learn จึงเป็นตัวอย่างที่ดีว่า “ย้ายออกจาก Excel” ก็ยังต้องเลือกฐานข้อมูลและสถาปัตยกรรมให้เหมาะ ไม่ใช่แค่เปลี่ยนหน้าตาเป็นแอปแล้วจบ

บางครั้งไม่ต้องสร้าง Web App ใหม่ทั้งหมด แค่ยกระดับจาก Excel ก่อนก็พอ

ก่อนลงงบพัฒนาระบบ ผมแนะนำให้ลองจัดระเบียบของเดิมก่อนหนึ่งรอบครับ เพราะถ้าจัด Excel ยังไม่ชัด การเอาความไม่ชัดนั้นไปเขียนเป็น Software ก็มีโอกาสได้ระบบที่ซับซ้อนกว่าเดิม

• กำหนดไฟล์หลักให้ชัดว่าไฟล์ไหนคือ Source of Truth
• ลดสำเนาที่ถูกส่งต่อทาง LINE หรือ Email
• กำหนดชื่อคอลัมน์และรูปแบบข้อมูลให้สม่ำเสมอ
• แยก Master Data เช่น รายชื่อลูกค้า พนักงาน สินค้า ออกจาก Transaction
• กำหนด Owner ว่าใครรับผิดชอบข้อมูลชุดไหน
• เขียน Workflow แบบง่าย ๆ ว่าข้อมูลเริ่มจากไหน ผ่านใครบ้าง และจบตรงไหน

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

ตัวอย่างง่าย ๆ: Excel รับออเดอร์ที่เริ่มโตเป็นระบบติดตามงาน

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

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

จุดนี้เราไม่จำเป็นต้องสร้าง ERP ใหญ่เลย อาจเริ่มจาก Web App เล็ก ๆ ที่ทำเพียง Request → Assign → Update Status → Approve → Complete และใช้ฐานข้อมูลเดียว จากนั้นค่อยดูว่าทีมใช้งานจริงแล้วต้องเพิ่ม Invoice, Notification หรือ Dashboard หรือไม่

Microsoft เองก็มีแนวทางที่นำข้อมูล Excel ไปเริ่มสร้าง App ได้ และอธิบายว่าข้อมูลควรจัดเป็น Table ให้ชัดก่อน เอกสาร Create a canvas app based on Excel data สะท้อนแนวคิดเดียวกันว่า Excel เดิมสามารถเป็นจุดตั้งต้นของการออกแบบข้อมูลได้ ไม่จำเป็นต้องทิ้งสิ่งที่ทีมทำมาทั้งหมด

ก่อนถามว่าคุ้มไหม ลองตีต้นทุนของ “ไม่ทำระบบ” ก่อน

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

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

ถ้าจะเริ่มจริง อย่าเริ่มจาก “อยากได้ Dashboard สวย ๆ”

Dashboard เป็นสิ่งที่ทุกคนเห็นง่าย แต่ระบบที่ดีมักเริ่มจาก Flow หลังบ้านครับ ถ้าข้อมูลต้นทางยังผิด ต่อให้ Dashboard สวยก็แค่แสดงข้อมูลผิดได้สวยขึ้น

เริ่มจาก Workflow ที่สร้างความเจ็บปวดชัดที่สุดหนึ่งเส้น เช่น Lead → Quotation → Approve หรือ Request → Assign → Complete แล้วกำหนดข้อมูลขั้นต่ำ ผู้ใช้แต่ละ Role และจุดที่ต้องแจ้งเตือนให้ครบก่อน

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

สรุป: เปลี่ยนเมื่อปัญหาอยู่ที่ Workflow ไม่ใช่เพราะเบื่อ Excel

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

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