Low-cost Analytics Architecture - ไม่ต้องทำทุกอย่างใน ERP ก็ได้

เมื่อ Cloud ERP สามารถใช้ Google Sheets เป็นพื้นที่สร้างสรรค์ร่วมกันได้ คุณจะเอาไปทำอะไร? 

นอกจากใช้ audit ตรวจข้อมูล บางคนอาจตกแต่งจัดรูปแบบเพื่อพิมพ์ออกมาได้สวยงาม บางคนทำ Pivot Table สรุปตัวเลขเพื่อวิเคราะห์ บางคนทำ Chart หรือเอาไปต่อกับ Looker Studio อีกทีหนึ่ง 

ผมคิดว่า ตอนนี้อาจมีบางคนเริ่มคิดได้ว่าน่าจะเอาไปให้ AI อ่านแล้วสั่งให้ช่วยหา Insight สั่งให้ทำ Infographic หรือทำ Slide สวยๆ  ..บางคนอาจคิดไปไกลกว่านั้นแล้ว

สมัยก่อน เวลาพูดถึงการส่งออกรายงานจาก ERP เรามักนึกถึงไฟล์ .txt หรือ .csv ที่ผู้ใช้ดาวน์โหลดไปเก็บไว้ในเครื่อง บางคนเปิดตรวจสอบ บางคนเอาไปคำนวณต่อใน Spreadsheet และบางคนมีหน้าที่จัดทำรายงานตามคำสั่ง แล้วส่งไฟล์ให้ผู้บริหารทางอีเมล หรือวางไว้ใน Shared Folder ที่ตกลงกันไว้

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

เมื่อเริ่มพัฒนา Cloud ERP เราจึงคิดว่า นอกจากส่งออกเป็นไฟล์แล้ว ทำไมรายงานจึงไม่สามารถส่งข้อมูลไปยัง Google Sheets ที่อยู่บน Cloud ได้ด้วย

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

แต่เมื่อมองย้อนกลับไป ผมคิดว่าการตัดสินใจเล็ก ๆ นี้เปิดความเป็นไปได้มากกว่าที่เราคาดไว้

จากรายงานที่ต้องขอให้โปรแกรมเมอร์แก้ มาเป็นรายงานที่ผู้ใช้จัดการเองได้

เหตุผลหนึ่งที่ผู้ใช้ชอบ Spreadsheet อาจไม่ใช่เพราะต้องการวิเคราะห์ข้อมูลที่ซับซ้อน แต่เพียงเพราะอยากจัดรูปแบบรายงานให้ถูกใจ

อยากใส่สีเพื่อเน้นรายการบางอย่าง อยากเพิ่มคอลัมน์ หรืออยากใส่สูตรคำนวณเพิ่มเติม เรื่องเหล่านี้ทำได้ง่ายกว่าเมื่อไม่ต้องกลับมาแก้โปรแกรม ERP ทุกครั้ง

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

รายงานหนึ่งจึงอาจประกอบด้วยข้อมูลจาก ERP อยู่ส่วนหนึ่ง และมีสูตร การจัดรูปแบบ หรือการคำนวณเพิ่มเติมที่ผู้ใช้สร้างเองอยู่อีกส่วนหนึ่ง

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

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

เมื่อรายงานกลายเป็นพื้นที่ทำงานร่วมกัน

ประโยชน์อีกอย่างเริ่มปรากฏชัดเมื่อรายงานไม่ได้มีไว้สำหรับอ่านตัวเลขเพียงอย่างเดียว

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

ตัวอย่างหนึ่งคือฝ่ายจัดซื้อมี Google Sheets สำหรับติดตามสินค้าที่กำลังจะเข้ามา มีทั้งจำนวนที่รอนำเข้า วันที่คาดว่าจะมาถึง และหมายเหตุความคืบหน้า เช่น สินค้าออกจากท่าเรือต้นทางแล้ว

ข้อมูลชุดนี้เป็นส่วนหนึ่งของงานที่ฝ่ายจัดซื้อดูแลอยู่ ไม่จำเป็นต้องมีทุกอย่างอยู่ใน ERP แต่ฝ่ายขายก็ต้องการข้อมูลเหล่านี้เพื่อวางแผนรับคำสั่งซื้อจากลูกค้า

เราจึงอาจทำรายงานที่แสดงยอดคงเหลือ ยอดค้างส่ง และยอดค้างรับจาก ERP พร้อมกับวันที่สินค้าจะเข้าซึ่งอ่านมาจาก Sheet ของฝ่ายจัดซื้อ

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

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

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

พื้นที่ที่ผู้ใช้สามารถ "ซน" ได้

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

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

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

การแชร์ Sheet ยังทำให้การช่วยเหลือสะดวกขึ้นด้วย เพราะทั้งสองฝ่ายสามารถดูพื้นที่ทำงานเดียวกันได้ ไม่ต้องส่งไฟล์กลับไปกลับมา และไม่ต้องคอยตรวจสอบว่าแต่ละคนกำลังใช้ไฟล์ฉบับไหน

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

ในมุมนี้ การเลือกใช้เครื่องมือที่มีอยู่แล้วไม่ได้ช่วยลดเฉพาะงานของโปรแกรมเมอร์ แต่ยังช่วยลดต้นทุนในการเริ่มต้นเรียนรู้และค้นหาความเป็นไปได้ใหม่ ๆ ด้วย

เราไม่ต้องสร้างทุกอย่างใน ERP ก็ได้

เมื่อก่อน ผมอาจมองการพัฒนาระบบในลักษณะว่า หากผู้ใช้ต้องการความสามารถอะไร เราก็ควรหาวิธีเพิ่มความสามารถนั้นเข้าไปในโปรแกรม

แต่ประสบการณ์จากการเชื่อมต่อกับ Google Sheets ทำให้เห็นอีกทางเลือกหนึ่ง เราอาจไม่จำเป็นต้องสร้างทุกอย่างขึ้นมาเอง หากมีเครื่องมือที่เหมาะสมอยู่แล้ว

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

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

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

หากมองในแง่นี้ สิ่งที่ผมเรียกว่า Low-cost Analytics Architecture อาจไม่ได้เริ่มจากการวางสถาปัตยกรรมวิเคราะห์ข้อมูลขนาดใหญ่ แต่เริ่มจากการนำความสามารถที่มีอยู่แล้วมาเชื่อมต่อกันอย่างเหมาะสม ค่อย ๆ เปิดพื้นที่ให้ข้อมูลจาก ERP ถูกนำไปใช้ต่อได้มากขึ้น โดยไม่ต้องเพิ่มภาระการพัฒนาในทุกขั้นตอน

บางครั้ง สิ่งที่สร้างคุณค่าให้ ERP อาจไม่ใช่ความสามารถใหม่ที่เราเขียนเพิ่มเข้าไป แต่เป็นสิ่งที่เราเลือกจะไม่สร้างเอง

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

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

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

บางที งานของคนทำ ERP อาจไม่ใช่การสร้างทุกอย่างที่ผู้ใช้ต้องการ แต่อาจเป็นการทำให้ผู้ใช้ไม่ต้องรอเราในทุกครั้งที่เขาคิดอะไรใหม่ ๆ ขึ้นมาได้หรือเปล่า?