7 ปี 4 ระบบ และสิ่งที่ไม่เคยหายไปเลย
ผมดูแลระบบ Maintenance ในโรงงานมากว่า 7 ปี ใช้มาแล้ว 4 ระบบ ไม่มีระบบไหนที่อยู่ได้ตลอด
ไม่ใช่เพราะระบบไม่ดี แต่เพราะ workflow จริงเปลี่ยนเร็วกว่าที่ระบบตามทัน องค์กรโต ทีมโต กระบวนการซับซ้อนขึ้น ระบบที่เคยตอบโจทย์ได้ดีก็เริ่มเป็นอุปสรรคแทน
สิ่งที่เหลืออยู่ทุกครั้งไม่ใช่ตัวระบบ แต่คือ ความเข้าใจ workflow ที่สะสมมาจากทุกยุค
ยุคที่ 1: CMMS — ซื้อระบบสำเร็จรูปหลักแสน
เริ่มต้นด้วยการซื้อ CMMS software สำเร็จรูป ราคาหลักแสนบาท ตามหลักการที่ว่า "ระบบดี ต้องลงทุน"
ฟีเจอร์ครบทุกอย่างที่อยากได้:
- แจ้งซ่อม (Work Request) และสั่งการทำงาน (Work Order)
- วางแผน Preventive Maintenance
- จัดการคลังอะไหล่ เบิกของเข้างานซ่อม
- ติดตาม man-hour รายงานสรุปค่าใช้จ่าย
บนกระดาษดูสมบูรณ์แบบ
แต่ในทางปฏิบัติ ปัญหาค่อยๆ ชัดเจนขึ้นเรื่อยๆ
workflow ในระบบไม่ตรงกับหน้างาน — ระบบออกแบบมาสำหรับโรงงานทั่วไป แต่โรงงานที่ผมดูแลมีกระบวนการเฉพาะที่ไม่ตรงกับที่ระบบสมมติไว้ ขั้นตอนบางอย่างในระบบไม่มีในงานจริง และขั้นตอนที่ใช้จริงกลับไม่มีในระบบ
ปรับแก้ยาก ต้องรอ vendor — อยากเปลี่ยน field หนึ่ง เพิ่ม approval step หนึ่ง ต้องส่ง request ไปรอคิว ไม่รู้ว่าจะได้เมื่อไหร่
ผลลัพธ์คือคนใช้ระบบไม่เต็มที่ — เมื่อ workflow ไม่ตรง พนักงานก็ใช้แค่บางส่วนที่ตรง ส่วนที่เหลือก็วนกลับไปจดในกระดาษหรือ Excel แทน ระบบหลักแสนที่ซื้อมาถูกใช้งานจริงไม่ถึงครึ่งของที่จ่ายไป
บทเรียน: ระบบที่ฟีเจอร์ครบแต่ไม่ตรง workflow จริง = คนใช้ไม่เต็มที่ และส่วนที่ไม่ได้ใช้คือเงินที่จมไป
ยุคที่ 2: AppSheet — สร้างเองตาม workflow จริง
หลังจากผิดหวังกับ CMMS สำเร็จรูป องค์กรย้ายมา Google Workspace ผมจึงตัดสินใจสร้าง app เองด้วย AppSheet
แนวคิดเปลี่ยนไปสิ้นเชิง — แทนที่จะให้คนปรับ workflow ตามระบบ เปลี่ยนเป็นสร้างระบบตาม workflow ที่คนทำจริง
สิ่งที่ดีขึ้นชัดเจน:
- ปรับ workflow ได้เองทันทีโดยไม่ต้องรอ vendor
- ระบบตรงกับการทำงานจริงของทีมหน้างาน
- ทีมเริ่มใช้จริงเพราะมันทำงานแบบที่พวกเขาคุ้นเคย
แต่พอเวลาผ่านไป ปัญหาชุดใหม่ก็เริ่มชัดเจน
AppSheet ชนเพดานเมื่อ workflow ซับซ้อนขึ้น — ข้อมูลสะสมหลายปี ทำให้ performance ลดลง หน้าจอโหลดช้า บางครั้ง sync ไม่ทัน
Business logic ที่ซับซ้อนต้องไปเขียน Apps Script — พอ logic มีเงื่อนไขหลายชั้น ต้องไปเขียน script เพิ่ม กลายเป็น workaround ที่แก้ยาก ไม่มี version control ที่ดี ถ้าคนที่เขียนออกไปก็จบ
ข้อจำกัดของแพลตฟอร์ม — AppSheet ตอนนั้นใช้แบบ free tier ตามข้อจำกัดที่มี ไม่ได้เสียค่า license ต่อ user ซึ่งดีสำหรับทดลอง แต่ก็ทำให้ชนข้อจำกัดด้านจำนวน record, automation, และ feature ที่ถูกล็อกไว้
บทเรียน: No-code ดีสำหรับเริ่มต้นและพิสูจน์ workflow ด้วยต้นทุนต่ำ แต่ถ้า workflow โตขึ้นจะชนกำแพงเสมอ
ยุคที่ 3: SAP B1 — Enterprise ERP ประยุกต์ใช้
องค์กรนำ SAP Business One เข้ามาสำหรับ Finance และ Procurement
ผมเลือกประยุกต์ใช้ PR (Purchase Requisition) Module ใน SAP มาทำงาน Maintenance แทนที่จะซื้อ SAP PM module แยก เพราะ core ของงาน Maintenance ส่วนใหญ่คือการจัดการอะไหล่และค่าใช้จ่าย
workflow ที่ใช้จริง:
- เปิด Work Order → สร้าง PR เพื่อเบิกอะไหล่
- วางแผน PM ตามรอบชั่วโมงเครื่องจักร
- tracking สถานะการซ่อมและการจัดหาอะไหล่
- ดูต้นทุน Maintenance แยกตามเครื่องจักร
ใช้งานจริงมาจนปัจจุบัน ทำได้ครบ ข้อมูลถูกต้อง เชื่อมโยงกับ Finance ได้โดยตรง
แต่ปัญหาที่ตามมาชัดเจนมาก:
ค่า SAP user license แพง — ไม่ใช่ทุกคนในทีมมี license ได้ หมายความว่าช่างหน้างานที่ต้องการดูสถานะงานซ่อม หรือ supervisor ที่ต้องการเห็นรายงาน — เข้าถึงไม่ได้
ข้อมูลอยู่ใน silo — มีแค่คนที่มี license ถึงจะเห็นข้อมูล คนที่ต้องการข้อมูลมากที่สุดในหน้างานกลับเข้าถึงไม่ได้ ต้องรอให้คนที่มี license ดึงรายงานออกมาให้
บทเรียน: ระบบที่ข้อมูลดีแต่คนเข้าถึงไม่ได้ ก็ไม่ต่างจากระบบที่ไม่มีข้อมูล
ยุคปัจจุบัน: Materialized View — เปิดข้อมูลให้ทุกคน
ปัญหาของ SAP ชัดเจน — ไม่ใช่เรื่องคุณภาพข้อมูล แต่เรื่องการเข้าถึง
แนวทางที่เลือก: ดึงข้อมูลจาก SAP B1 ออกมาทำ materialized view แล้วเปิดให้ผู้ใช้หน้างานเข้าถึงโดยไม่ต้องเพิ่ม SAP user license
สิ่งที่ทำได้ตอนนี้:
- ช่างหน้างานติดตามสถานะอะไหล่ได้จากมือถือ
- เปิด PR จาก Work Order ได้โดยตรง
- Supervisor ดูสรุปงบและค่าใช้จ่าย Maintenance ได้แบบ real-time
- เร่งติดตามงานที่ค้างอยู่ในขั้นตอนไหนก็ได้
ข้อมูลต้นทางยังอยู่ใน SAP B1 ครบ — ไม่ได้ย้ายออก ไม่ได้ duplicate ข้อมูล แค่เปิดให้อ่านได้เพิ่มผ่าน layer ที่สร้างขึ้น
ทำไมถึงสร้างได้เร็ว
เพราะ workflow ที่สะสมมาจาก CMMS → AppSheet → SAP ไม่ได้หายไปไหน มันกลายเป็น spec ที่ชัดเจน ที่รู้ว่าต้องการ field อะไร approval step เป็นแบบไหน รายงานแบบไหนที่ใช้จริง
ทำให้ระบบใหม่สร้างได้เร็วและตรงจุดตั้งแต่รอบแรก ไม่ต้องเดาอีกต่อไป
ความเร็วในการพัฒนา — กราฟเปรียบเทียบ
ในช่วง 4-5 เดือนที่ผ่านมา AI เข้ามามีบทบาทในการพัฒนาระบบ ทำให้ระบบ Materialized View ที่ต่อยอดจาก workflow เดิมทั้งหมด สร้างได้เร็วกว่าทุกยุคที่ผ่านมา
workflow ที่สะสมมา 7 ปี กลายเป็น spec ที่ชัดเจน เมื่อรวมกับ AI ที่ช่วยเขียนโค้ดและ prototype ทำให้ระบบใหม่ที่เคยต้องใช้เวลาหลายเดือน สร้างได้ภายในไม่กี่สัปดาห์
บทเรียนจาก 4 ยุค
หลังผ่านมาครบ 4 ระบบ สิ่งที่เห็นชัดขึ้นทุกครั้ง:
ไม่มีระบบไหนสมบูรณ์แบบตลอดไป — ระบบที่ดีวันนี้จะมีข้อจำกัดของมันในวันข้างหน้า เมื่อองค์กรโต เมื่อ workflow เปลี่ยน เมื่อทีมขยาย
สิ่งที่มีค่ากว่าตัวระบบคือความเข้าใจ workflow — ทุกครั้งที่เปลี่ยนระบบ domain knowledge ที่ได้จากระบบเก่าไม่ได้หายไป มันสะสมอยู่และพกข้ามระบบได้
ทุกครั้งที่เปลี่ยนระบบ ไม่ได้เริ่มจากศูนย์ — แต่เริ่มจาก workflow ที่ refined มาแล้วหลายรอบ ทำให้แต่ละครั้งที่เปลี่ยนได้ระบบที่ดีขึ้นเสมอ
ระบบที่ใช้ได้จริง = ระบบที่คนเข้าถึงข้อมูลได้ — ไม่ใช่ระบบที่ฟีเจอร์เยอะที่สุด ไม่ใช่ระบบที่แพงที่สุด แต่ระบบที่คนที่ต้องการข้อมูลสามารถเข้าถึงได้จริงในเวลาที่ต้องการ
แผนต่อไป
เป้าหมายถัดไปคือ เชื่อมต่อ SAP B1 กับ app ภายนอก ให้ทำงานด้วยกันเป็นระบบเดียว
SAP ยังเป็น core ที่เก็บข้อมูลการเงินและ procurement ทุกอย่าง ไม่มีแผนเปลี่ยน
แต่ app ภายนอกจะเป็น front-end ที่ user ใช้งานจริงหน้างาน — ออกแบบตาม workflow ของช่าง supervisor และ manager แต่ละกลุ่มโดยเฉพาะ ไม่ใช่หน้าจอ ERP ที่ทำทุกอย่างในหน้าเดียว
ผลลัพธ์ที่ต้องการ: ทุกคนในองค์กรเข้าถึงข้อมูลที่ต้องการได้ โดยไม่ถูกจำกัดด้วย license
สรุป
Maintenance ไม่ใช่แค่การเลือก software — มันคือ workflow ที่วิวัฒน์ได้ตามองค์กร
ถ้าองค์กรของคุณกำลังติดอยู่กับระบบที่ไม่ตรง workflow หรือคนเข้าถึงข้อมูลไม่ได้ — ปัญหาไม่ได้อยู่ที่ต้อง "ซื้อระบบใหม่" แต่อยู่ที่ต้อง เข้าใจ workflow จริงก่อน แล้วค่อยหาระบบที่ตรง
4 ระบบที่ผ่านมาไม่ใช่ความผิดพลาด มันคือ iteration ที่ทำให้รู้ว่าต้องการอะไรจริงๆ
ถ้าองค์กรของคุณกำลังมองหาทางเชื่อม ERP กับระบบหน้างาน หรืออยากปรับ workflow Maintenance ให้ตรงกับการทำงานจริง — ปรึกษาฟรี ไม่มีข้อผูกมัด