สมัยเอ๊าะๆ ที่เพิ่งเริ่มทำงาน TARAD.com ตอนนั้น E-Commerce ยังไม่ได้บูมมาก พี่ป้อม ภาวุธ CEO TARAD ยังต้องเดินสายทั่วไทยเพื่ออธิบายว่า E-Commerce คืออะไร การชำระเงินยังไม่น่าเชื่อถือมากนัก สัดส่วนโอนเงินทางธนาคารสูงถึง 80%, ระบบการขนส่งยังมีเพียงไปรษณีย์ไทยที่ใช้เวลา 5-10 วัน กว่าจะได้รับสินค้า, การส่งของก่อน จ่ายเงินทีหลัง (Buy Now Pay Later) หรือ ชำระเงินปลายทาง (Cash on Delivery) ยังถูกมองเป็นเรื่องบ้าบิ่น ไม่มีใครกล้าทำ

ผมจำได้ว่ายุคนั้น ทุกคนมอง E-Commerce เป็นของใหม่ ยังไม่ทำเงินอะไรมากนัก เป็นกิมมิกใหม่ทางเทคโนโลยีที่ใครทำก่อนก็ดูดี ทันสมัย ไม่ได้เป็นช่องทางขายหลักเฉกเช่นปัจจุบัน ดังนั้น การเช่า/ซื้อระบบสำเร็จรูป หรือทำระบบเองขึ้นมา ก็จะมีฟีเจอร์การขายไม่ซับซ้อนมาก ก็เปิดร้านขายของได้แล้ว (ฟีเจอร์ฮิตสมัยก่อน เช่น เลือกธีมสีได้ แปะรูป Gif วิ่งไปมา มีดาววิ่งตามเม้าส์ พอถึงคริสมาสต์ทำหิมะตกโปรยปราย)

ตลอดเวลาที่ผ่านมา E-Commerce มันก็มีวิวัฒนาการมาเรื่อยๆ จนถึงปัจจุบัน ผ่านมา 12 ปี ที่ผมคลุกคลีกับมัน (นานชะมัด) ร้านไหนไม่รับชำระผ่านเครดิตการ์ดเป็นเรื่องที่ไม่สะดวก เรายอมส่งของให้ลูกค้าก่อนและรับเงินทีหลัง เราเชื่อมระบบไป Warehouse เพื่อทำการ Pick & Pack และเลือกให้อัตโนมัติว่าบริษัทขนส่งไหนเหมาะสมที่สุดเพื่อมารับและส่งสินค้าให้ถึงมือลูกค้า เรามีระบบประเมินรายได้และปรับราคาสินค้าและสร้างแคมเปญให้เองอัตโนมัติเพื่อเพิ่มยอดขาย รวมถึงมีระบบอัตโนมัติให้ลูกค้ากลุ่ม Abandon Cart กลับมาชำระเงินกับเรา

E-Commerce มีความซับซ้อนมากขึ้นกว่าแต่เดิมมาก ยิ่งบริษัทขนาดใหญ่ที่เปลี่ยนแนวคิดว่า E-Commerce คือช่องทางหลักในการสร้างรายได้ ในยุคดิจิตอล (และยุค COVID-19 ที่ถูกสถานการณ์บีบให้ต้องทำ) รวมถึงการพยายามทำ O2O (Online-to-Offline) เพื่อให้ลูกค้าในโลกดิจิตอลและบนโลกความจริงสามารถช็อปปิ้งกันไปมาได้อย่างไร้รอยต่อ (Seamless)

ผู้อ่านคงเริ่มเห็นภาพตามที่ผมจั่วหัวไว้ว่า E-Commerce ตั้งแต่อดีต จนถึงปัจจุบัน คืออะไรที่ผสมผสานระหว่าง ช่องทางการซื้อขายออนไลน์ เพื่อทำงานร่วมกับระบบ กระบวนการ และคน ที่มีอยู่เดิม (หรือต้องปรับใหม่ให้เหมาะสม) ซึ่งมันจะไม่ใช่แค่ตั้งระบบ Platform เช่น Magento ขึ้นมาสักตัว หรือไปเปิดร้านกับ Shopee, Lazada แล้วจะสามารถขายได้ แพ็คของทัน ส่งของทัน กำไรดี มีความสุขแค่นั้น

แม้ทุกวันนี้ผมไม่ได้อยู่ในสายงานของ E-Commerce โดยตรง แต่ก็ยังต้องช่วยออกแบบ Solution ให้กับลูกค้ารายใหญ่ที่อยากทำ E-Commerce ซึ่งผมพบว่า บริษัทส่วนมากจะแต่งตั้งขึ้นมาทีมหนึ่ง (หรือคนไม่กี่คน) เพื่อดูแลโครงการ เช่น IT,Marketing หรือ Merchandise จากนั้น มานั่งคุยกับผู้พัฒนาระบบ ว่าอยากได้อะไรบ้าง

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

บล็อกนี้เลยอยากแชร์ประสบการณ์ที่ผมได้ทำเอง พาลูกค้าทำ และจากที่สังเกตวิธีทำงานของลูกค้าเจ๋งๆ ว่าต้องทำระบบ E-Commerce อย่างไร ถึงจะตอบโจทย์องค์กร และลูกค้า

1. ทีมทำงานต้องเข้าใจในกระบวนการ/ระบบ (ที่เกี่ยวข้อง) ภายในบริษัทตัวเองก่อน

สิ่งที่พบ

อย่างที่กล่าวไป บางบริษัทมักแต่งตั้ง บางทีม หรือบางคน ให้ดูแลโปรเจ็ค E-Commerce แล้วเขาเหล่านั้นก็ไปดูระบบตัวอย่าง ดูฟีเจอร์ ดูคู่แข่ง ทำงบประมาณและเวลา เพื่อนำเสนอผู้บริหารและทำการจัดจ้าง แต่สุดท้าย ตกม้าตายตอนเก็บ Requirement ที่ต้องเอาผู้เกี่ยวข้อง กระบวนการ ระบบที่มีอยู่ มา Integration กัน ถึงเวลานั้น ก็สายไปเสียแล้ว เพราะถูกล็อกด้วย ทรัพยากร เงิน เวลา และคำมั่นสัญญากับผู้บริหารไปแล้ว

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

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

สิ่งที่แนะนำ

ดังนั้น ถ้าเริ่มต้นด้วยการมีทีมทำงาน (ผมคิดว่าผู้ดูแลโปรเจ็คคนเดียวไม่สามารถรู้ได้หมด) ที่มีผู้เชี่ยวชาญในแต่ละฝ่ายที่ตนเองรับผิดชอบ และเกี่ยวข้องกับ E-Commerce (เช่น การเงิน, จัดซื้อ, คลังสินค้า, Support, การตลาด, ขนส่ง) มาร่วมพิจารณา หรือร่าง Requirement ร่วมกัน สิ่งที่ได้ออกมาจะค่อนข้างครบ และครอบคลุม มากๆ

หรือให้ลองคิดว่า ถ้าต้องได้สิ่งเหล่านี้มาเพื่อทำRequirement เราควรให้ใครมาตอบ เช่น

• กลุ่มลูกค้า และพฤติกรรมที่จะเข้ามาใช้งาน
• แคมเปญที่จะอาจจะเกิดขึ้นหลังเว็บไซต์เสร็จ และในอนาคตข้างหน้า
• สินค้ามีการจัดหมวดกลุ่ม หรือจัดหมวดหมู่แบบใด เข้ากับพฤติกรรมการช็อปปิ้งของกลุ่มลูกค้าเราไหม
• สินค้ามีการกำหนดคุณลักษณะไว้อย่างไร ถ้ากลุ่มลูกค้าเราต้องการเข้ามาค้นหา จะง่ายไหม พบสิ่งที่ต้องการไหม
• ข้อมูล และ Report ใด ที่จะต้องเอาไปวิเคราะห์ต่อ
• กระบวนการ หยิบของ แพ็คของ และจัดส่งไปถึงมือลูกค้าเป็นอย่างไร
• กระบวนการ รับเงินบนเว็บไซต์ ไปจนถึงเงินเข้าบัญชีบริษัทจริงๆ เป็นอย่างไร
• ถ้าลูกค้าต้องการเปลี่ยน ยกเลิก หรือมีปัญหาการใช้งาน ต้องทำอย่างไร สอบถามใคร ใครดูแล ถ้าต้องเป็น 24ชม
• ฯลฯ

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

2. คิดตั้งแต่ก่อนผู้ใช้เข้าเว็บไซต์ ไปจนถึงหลังลูกค้าได้รับของ

สิ่งที่พบ

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

ตัวอย่างเช่น เรากำหนด Persona แล้วระบุ User Journey เพื่อทำ UX/UI ภายในเว็บไซต์ และเราลืมที่จะพัฒนาส่วนของการทำ User Tracking หรือไม่ได้คิดถึง Report เพื่อนพไปทำ Data Analyst, เราอาจต้องปรับระบบภายหลังในหลายจุดแทน ยิ่งถ้าไม่เคยมีข้อมูลบางอย่างเก็บไว้ก่อน ก็ต้องเริ่มทำระบบเก็บ และใช้เวลาอีกหลายเดือน กว่าจะมี Data เพียงพอเพื่อไปปรับปรุงแผนการขาย และแผนการตลาด

บางทีอาจรื้อกันระดับโครงสร้างเลยทีเดียว ส่งผลกระทบกับทรัพยากร เงิน เวลา รายได้และชื่อเสียงของบริษัทได้เลยนะ

สิ่งที่แนะนำ

ลองพิจารณาเพื่อกำหนด Requirement เพิ่มเติมเข้าไปแต่แรกว่า ช่องทางที่จะพาเขามา และบริการหลังการขาย มีอะไร และจะต้องทำเป็นฟีเจอร์อะไรบ้าง

การคิดเกินกรอบของฟีเจอร์ในระบบ มันจะช่วยให้เราคิดถึงเรื่อง Marketing, CRM, Report และ Data Analyst ดังนั้น ถ้าไม่คิดเผื่อตั้งแต่แรก ปัญหาที่พบบ่อยๆ คือ ระบบไม่ได้ถูกออกแบบเผื่อไว้ เช่น

• ไม่ได้ทำ Optimize SEO
• ไม่ได้ทำ Facebook Open Graph, Twitter Card Tags หรืออื่นๆ ทำให้แชร์ออกไปโซเชี่ยลแล้วไม่สวย รูปไม่ถูก ไม่ชัด ไม่ได้สัดส่วน
• ไม่มี Tracking Code หรือ Conversion Tracking ในระดับ E-Commerce Enhancement ด้วย Facebook Pixel, Google Analytics หรืออื่นๆ
• ไม่มีการเก็บ Abandon Cart หรือ Drop Lead
• ไม่ได้เก็บ Activities Event ของผู้ใช้งาน
• ไม่รองรับการรับ Parameter บางอย่างจาก Ads หรือเว็บไซต์ภายนอก เช่น Google, Facebook
• ไม่มีการ Integration กับระบบ CRM เพื่อดึง/เก็บข้อมูล Personalize ของลูกค้า
• ไม่สามารถรองรับการทำแคมเปญที่ก่อให้เกิด Spike Traffic จนทำให้เว็บล่ม
• ไม่สามารถออก Report บางตัวให้ผู้บริหารได้ เพราะไม่มีการเก็บ Data ที่เพียงพอ

เห็นไหมครับว่าผลกระทบเยอะนะ และผมคิดว่าบริษัทที่อยากทำ E-Commerce ก็ต้องการทำสิ่งต่างๆในตัวอย่างที่ผมยกมาเกือบหมดแหละ จะดีกว่าไหม ถ้าเราคิดและบอกไปแต่แรกใน Requirement เลย

ปล. มันคือ Non-Functional Requirement

3. เรื่องที่ต้องถกเถียงกันให้มากคือ ถ้าลูกค้าซื้อของไม่สำเร็จ จะทำอย่างไร

สิ่งที่พบ

เรื่องหนึ่งที่เรามักถกเถียงกันไม่มากพอและไปเป็นปัญหาตอนหลัง คือ กรณีที่ลูกค้าซื้อของไม่สำเร็จ จะทำอย่างไร เช่น

• ลูกค้าบัตรเครดิตตัดเงินไม่ผ่าน ต้องแจ้งอะไร และลูกค้าต้องไปหยิบสินค้าทำ Order ใหม่ไหม
• Server ไม่ได้รับข้อมูลตัดเงินจาก Payment Gateway ทำอย่างไร
• ลูกค้าจ่ายเงินแบบออฟไลน์ (เช่น โอนเงิน) แต่เงินขาด/เกิน หรือไม่ส่งหลักฐาน
• ลูกค้าจ่ายเงินแบบออฟไลน์ (เช่น โอนเงิน) แต่โอนเกินเวลา จะยอมรับได้ไหม และถ้าขายให้คนอื่นไปแล้วด้วย จะชดเชยอย่างไร
• Order ไม่สำเร็จ แล้วคืนของกลับระบบอย่างไร มี Integration ไปอัพเดทที่ไหนบ้าง ทันทีเลยไหม
• ถ้าลูกค้าไม่พอใจ ในการซื้อไม่สำเร็จ จะแก้ปัญหาอย่างไร ชดเชยอย่างไร

ปัญหานี้เป็นมากกว่าระบบ ความรุนแรงจะมากจะน้อย อยู่ที่เราเจอลูกค้าแบบไหน ซึ่งเราควบคุมไม่ได้ก็จริง แต่เราพยายามป้องกันได้

ทั้งนี้ต้องย้อนหลับไปที่ข้อ 1 เลย ว่า Requirement เราจะทำให้เกิดเหตุการณ์เหล่านี้ได้บ้างไหม

สิ่งที่แนะนำ

ให้ลองเขียน Scenario ที่จะเกิดขึ้น ว่าแต่ละข้อจะกระทบด้านไหนบ้าง (เช่น การเงิน ปฏิบัติการ ภาพลักษณ์ กฎหมาย) ส่งผลในระดับไหน คาวมรุนแรงแค่ไหน แล้วจะแก้ปัญหาอย่างไร ใครรับผิดชอบ (และอย่าพลาดตกม้าตาย เช่น ใช้ Admin Page เด็กน้อย หรือ Outsource ไปคุยกับลูกค้า บางครั้งความรู้สึกไม่เป็นเจ้าข้าวเจ้าของ ความไม่ข้าใจ หรือคุมอารมณ์ไม่ได้ จะทำให้เรื่องบานปลายหนักกว่าเดิม)

และสุดท้าย ใน Requirement อย่าลืมใส่เรื่องของการ Logging, Monitoring, Tracking และกำหนดเรื่องของ Exception Error ไว้ให้ครอบคลุมด้วย เพื่อจะช่วยแก้ปัญหาได้ไวยิ่งขึ้น เมื่อลูกค้าสั่งซื้อไม่ได้

4. อีกปัญหาที่หนักกว่าเรื่อง Platform คือ Operation หลังบ้าน

สิ่งที่พบ

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

ซึ่งเรื่องนี้ไม่เป็นปัญหาในตอนที่ขายได้ 5 ชิ้น 10 ชิ้น ต่อวัน แต่มันจะเป็นปัญหาเมื่อขายได้ ร้อยชิ้น พันชิ้น หรือหมื่นชิ้นต่อวัน

เมื่อก่อนตอนทำ TARAD.com ผมเจอเรื่องแปลกๆที่ไม่เข้าใจ เวลามีเซลส์เล่าว่า ลูกค้าปิดร้าน ไม่ทำต่อแล้ว ด้วยเหตุผลที่ว่า ขายดีเกินไป!! (ทุกวันนี้ผมก็ยังได้ยินเรื่องแนวๆนี้อยู่บ้าง) จนเมื่อต้นปี 2563 ผมได้เปิดร้านขายของเล็กๆใน Shopee, Lazada ก็สนุกดี ขายได้อาทิตย์ละ 1-2 ชิ้น จนผมเริ่มจริงจังมากขึ้น กลายเป็นวันละ 2-3 ชิ้น บางวันก็ได้ 10 ชิ้น ดีใจมากที่ขายได้ทุกวัน และสะดวกด้วยเพราะที่บ้านและทำงานใกล้ไปรษณีย์ทั้งคู่

จนวันหนึ่ง มีออเดอร์เข้ามา 40 ชิ้น สิ่งแรกที่ผมกังวลคือ ผมจะต้องใช้เวลาแพ็คเท่าไร ขนไปไปรษณีย์อย่างไร ซึ่งแต่เดิมตอนขายได้น้อย ผมไปซื้อกล่องและแพ็คที่ไปรณีย์เลย ยืนเขียนจ่าหน้ากล่องทีละคนตรงนั้นได้เลย แต่ผมประเมินแล้วผมคงทำแบบนั้น 40 กล่องไม่ได้ ตกเย็นผมจึงรีบไปซื้อกล่อง ซื้อสก็อตเทป แล้วกลับมาแพ็คของ เขียนจ่าหน้ากล่องทีละคน กว่าจะเสร็จ เสียเวลาไป 2-3 ชั่วโมง

วันต่อๆมาเจออีก วันละ 30-50 ชิ้น ผมก็ทำแบบเดิม และเสียเวลา 2-3 ชั่วโมง ทุกวัน จนผมคิดว่า สิ่งที่ช้าสุดตอนนี้คือการแพ็คของและจ่าหน้ากล่อง ผมเลยตัดสินใจเปลี่ยนแพคเกจจากกล่อง มาเป็นซองกระดาษบับเบิลแบบมีเทปกาวปิดในตัว และซื้อ Thermal Printer มาพิมพ์แทน นอกจากย่นระยะเวลาได้อย่างมากแล้ว ยังประหยัดค่าส่งไปรษณีย์อีกด้วย ลดพื้นที่ขาส่งสินค้าด้วย

ตัวอย่างของผมเป็นเรื่องจิ๊บๆ มาก คนที่ทำจริงจังที่ผมเคยได้ยินมา เขาระดมคนทั้งบ้าน เพื่อนบ้าน มาช่วยแพ็คกันทั้งวันทั้งคืน ในทุกเทศกาล 9.9 10.10 เลย

สิ่งที่แนะนำ

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

เรื่องOperation ที่จะคุยกัน มีทั้งระบบพอช่วยได้ และทั้งกระบวนการทำงานที่ต้องจัดตั้งขึ้นมา ผมขอแบ่งเป็นสองกลุ่ม คือ “Operation มาตรฐาน” กับ “Operation ตาม Scenario”

Operation มาตรฐาน เช่น

• ลูกค้าทำ Order เสร็จ จะส่งข้อมูลไปให้ระบบ ERP/CRM/Royalty Program อะไรไหม
• ลูกค้าทำ Order เสร็จ จะส่งข้อมูลอะไรบอกเขาบ้าง ช่องทางไหนบ้าง
• ฝั่ง Pick/Pack จะรู้ได้อย่างไรต้องจัดของเมื่อไร และปริมาณเท่าไร ถ้าของไม่พอทำอย่างไร
• บริษัทขนส่ง จะรู้ได้อย่างไรต้องมารับของเมื่อไร และปริมาณเท่าไร และส่งให้ใครบ้าง ต้องเก็บเงินปลายทางด้วยหรือไม่
• การเงินจะรู้ได้อย่างไร ว่าเป็นรายรับ
• ประสิทธิภาพของทีม Pick/Pack และบริษัทขนส่ง ทำได้กี่ชิ้น ทำได้กี่ Order ต่อวัน
• การใช้เวลาของแต่ละขั้นตอนใช้เท่าไร (SLA) ตั้งแต่ลูกค้าทำรายการสำเร็จ จนส่งของถึงมือ
• ฝั่ง Marketing จะรู้ได้อย่างไรว่าปิดดีล ไม่ต้องไปตามส่ง Ads หลอกหลอนลูกค้าให้น่ารำคาญและเปลืองเงิน
• Stock สินค้าออนไลน์ กับออฟไลน์ รวมกันหรือแยกกัน จะ Sync กันอย่างไร ถ้ามีหลายสาขา จะ Sync อย่างไร
• ฯลฯ

Operation ตาม Scenario เช่น

• ถ้าลูกค้าทำ Order มากเกินประสิทธิภาพของทีม Pick/Pack และบริษัทขนส่ง จะทำอย่างไร
• ถ้าลูกค้าต้องการเปลี่ยนชนิดสินค้า, เปลี่ยนขนาด, เปลี่ยนรูปแบบ สินค้า ทำได้ไหม
• ถ้าลูกค้าต้องคืนสินค้า/คืนเงิน มีกระบวนการติดต่ออย่างไร ส่งกลับอย่างไร ใครรับภาระค่าใช้จ่าย เงื่อนไขอย่างไรบ้าง
• ลูกค้าสั่งสินค้าแล้ว ชำระเงินแล้ว บังเอิญไม่มีสินค้าส่ง จะทำอย่างไร (เช่น ของที่มีอยู่ชำรุดเสียหาย ต้องนำเข้า Stock ใหม่)
• ลูกค้าสั่งสินค้าแล้ว เก็บเงินปลายทาง แต่ลูกค้าปฏิเสธรับของทำอย่างไร
• บริษัทขนส่งสินค้าทำสินค้าหาย ทำอย่างไร
• สินค้าส่งไป มีตำหนิ มีมาตรการตรวจสอบ ส่งข้อมูล ติดต่อ และกระบวนการแก้ไขอย่างไร
• ฯลฯ

สรุป

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

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

ผมชอบได้ยินหลายๆ บริษัท บอกว่าE-Commerce เหมือนเป็นสาขาอีกสาขาหนึ่ง ซึ่งก็ถูก แต่พอคุยต่อไป กลับคุยแต่เรื่องการก่อสร้าง จะทาสีอะไร ใช้วัสดุไหน จัดวางสินค้าอย่างไร และคุยเรื่อง Operation เพียงนิดเดียว เพราะคิดว่าแบบเดิมน่าจะรองรับได้ แต่เปล่าเลย เราคิดไปไม่จบต่างหาก เราเลยมองไม่เห็นว่าความแตกต่างว่าอยู่ตรงไหน

เอาจริงๆ ถ้าไม่ติดเรื่องภาพลักษณ์ หรือค่าธรรมเนียม ระบบไม่ต้องมีก็ยังได้ ใช้พวก Platform แบบ Shopee, Lazada, Shopify เพื่อเป็นหน้าร้านช่องทางขายของ จากนั้นไป Integrate กับระบบเดิมเราเพื่อลดการทำงานแบบ Manual ก็ไม่ต้องวุ่นวายกับ Server หรือระบบอะไรเลย เรามีหน้าที่ทุ่มเทโปรโมท ขาย จัดส่ง นับเงินอย่างเดียว อิอิ

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