SCALE, AND WHAT’S NEXT

Để bắt đầu bài viết, mình muốn chia sẻ 1 dữ liệu dễ hiểu thể hiện sự tăng trưởng của Tiki trong vài năm vừa qua. Đó là hiện tại, doanh số mỗi ngày của Tiki còn cao hơn doanh số … cả tháng tại thời điểm mình mới tham gia (tháng 10/2014). It’s huge.

Đi cùng với sự phát triển về doanh số là những thử thách đồng thời là những bài toán thú vị luôn mở rộng, thay đổi dành cho các phòng ban, trong đó có Engineering (công nghệ) nói chung và Operation Product (team của mình hiện tại) nói riêng. Bài viết này nhằm mục đích giới thiệu qua các bài toán này, điểm lại những phần team đã giải quyết và chia sẻ những kế hoạch trong tương lai.

Operation Product bao gồm các giải pháp phục vụ Vận hành, Tài chính kế toán và Quản trị trong công ty, là mảng mà Tiki chọn xây dựng in-house hầu như toàn bộ tương tự Amazon.

Bài toán lớn nhất về Vận hành không chỉ ở Tiki nói riêng mà của e-commerce nói chung, là làm sao có thể giao sản phẩm đến tay khách hàng trong 1 thời gian đủ nhanh với chi phí hợp lí. Tuy nhiên đó là bài toán của sau này, còn ở thời gian đầu, câu chuyện chỉ đơn giản là làm sao … xử lí được đơn hàng trơn tru cái đã :).

Cách lấy hàng đầu tiên là in danh sách sản phẩm cần lấy trong đơn hàng kèm danh sách kệ có thể chứa nó ra giấy, người xử lí đơn hàng (picker) tuần tự đi lấy theo danh sách này. Sở dĩ mỗi sản phẩm đi kèm với danh sách kệ là vì khi đó hệ thống chưa quản lí chi tiết đến mức sản phẩm nào nằm ở kệ nào với số lượng bao nhiêu. Phương pháp lấy này đơn giản khi triển khai nhưng sẽ chậm khi lượng đơn hàng tăng lên, đồng thời phụ thuộc khá nhiều vào kinh nghiệm cũng như độ quen thuộc với sản phẩm trong kho của picker.

Bước cải tiến tiếp theo của phần xử lí đơn hàng nói riêng và các giải pháp Vận hành nói chung, đó là làm sao cho con người “bớt phải nghĩ” nhưng lại đạt năng suất cao hơn, và điều này thực hiện được nhờ sự tính toán trợ giúp của máy móc 🙂 Đây là thời điểm Tiki bắt đầu đưa vào sử dụng hệ thống lấy hàng mới kết hợp thuật toán gom nhiều đơn hàng (pick by batch), tính toán ra đường đi lấy hàng tối ưu trong kho và đồng thời đưa vào sử dụng các PDA (máy tính cầm tay) chuyên dụng thay cho giấy. Chi tiết hơn về dự án này các bạn có thể xem ở đây. Thời điểm hoàn tất dự án cũng là lúc Tiki đưa vào sử dụng kho chính mới ở TPHCM rộng gấp 3 lần kho cũ, giúp đáp ứng việc xử lí khối lượng đơn hàng nhiều hơn trong 1 không gian chứa nhiều sản phẩm hơn nhưng lại nhanh hơn, là 1 phần quan trọng trong quá trình scale up Vận hành.

Tuy nhiên, để giải pháp lấy hàng nói trên có thể khả thi thì có 1 dự án khác cũng đồng thời được triển khai và đây cũng là 1 nền móng quan trọng cho 1 hệ thống Vận hành tốt, đó là quản lí tồn kho chi tiết. Nói đơn giản là nếu trước đó, hệ thống chỉ biết đại khái là sản phẩm này có ở trong kho bao nhiêu món, có thể nằm ở những kệ nào thì giờ đây, người vận hành có thể biết chính xác tại mỗi thời điểm, mỗi sản phẩm có bao nhiêu món ở vị trí nào trong kho, đây là dữ liệu chính dùng để tính toán ra đường đi tối ưu khi lấy hàng.

Quản lí tồn kho chính xác hoàn toàn không dễ. Có 2 luồng chính, khi nhận hàng vào kho (inbound) thì người vận hành cần kiểm đếm, xác nhận số lượng và cất hàng lên kệ chứa trong kho, khi xử lí đơn hàng (outbound) thì hàng hóa sẽ được lấy ra khỏi kệ và đưa đến khu vực đóng gói. Đây là những qui trình có nhiều thao tác thủ công nên sẽ có nhiều không ít khả năng sai sót, do đó việc thiết kế giao diện thế nào cho người dùng hiểu rõ mình cần làm gì, kiểm đếm những món hàng nào, hình ảnh đối chiếu là gì, số lượng bao nhiêu, khi nào là hoàn tất, khi có exception (lỗi, ví dụ nhận hàng phát hiện thiếu sản phẩm) thì xử lí ra sao là những vấn đề UX thú vị mà hệ thống quản lí tồn kho cần xử lí.

Bước tiếp theo của việc quản lí hàng hóa chính xác, lấy hàng trong kho nhanh hơn là đi giao hàng từ kho cũng cần nhanh hơn và phục vụ được khách hàng ở diện rộng hơn. Đó là lúc Tiki bắt đầu làm việc cùng các công ti vận chuyển như Giao Hàng Nhanh (GHN), Bưu điện (VNPost) và đồng thời xây dựng đội ngũ giao hàng riêng của mình (Tiki Express). Những tính năng cơ bản để quản lí đối tác vận chuyển cũng dần được triển khai, đó là khả năng cài đặt và cấu hình các tuyến giao hàng, hệ thống cần hiểu tuyến nào (chi tiết đến khoảng trên 11,000 phường/xã ở khắp Việt Nam) sẽ do đối tác nào phụ trách, đồng thời ghi nhận thời gian giao hàng từ các kho Tiki đến tuyến đó theo từng gói cước của đối tác sẽ là bao lâu. Thông tin này sẽ được dùng kết hợp với thông tin về thời gian nhập và xử lí đơn hàng để có được ngày giao hàng dự kiến thông báo cho khách hàng trên web/app Tiki.

1 phần khá quan trọng nữa trong việc quản lí đối tác vận chuyển là việc trao đổi thông tin về đơn hàng. Phần này sẽ bắt đầu khi đơn hàng được bàn giao vật lí và kết thúc khi nó đến tay khách hàng, trong đó các thông tin như giá trị, khối lượng, qui cách giao hàng (có cần 2 bên cùng kiểm tra hay không, có cần thu hộ đối với giao hàng Cash-on-delivery hay không) sẽ được Tiki gởi sang đối tác, ở chiều ngược lại, các thông tin như trạng thái của đơn hàng đang đi tới đâu, vào thời điểm nào, bằng chứng nhận hàng của khách hàng (proof-of-delivery) sẽ được đối tác gởi ngược lại cho Tiki. Thời gian đầu, thông tin này được trao đổi thủ công qua file Excel, sau đó là tích hợp API (đây cũng là 1 bài toán thú vị vì mỗi đối tác lại có khả năng kĩ thuật để tích hợp khác nhau) và đối với Tiki Express, 1 bước tiến nữa là việc cho ra đời mobile app dành cho các nhân viên vận chuyển, giúp việc cập nhật thông tin đơn hàng trở nên real-time hơn 🙂

Vậy, đơn hàng sau khi giao xong là hệ thống đã hết trách nhiệm chưa ? Câu trả lời là … còn dài lắm.

Vẫn còn những phần như Hậu mãi, bao gồm các qui trình cho phép Tiki xử lí các câu hỏi, khiếu nại của khách hàng và giải quyết nó 1 cách nhanh chóng nhất nhằm đảm bảo trải nghiệm của khách không bị sứt mẻ quá nhiều nếu sản phẩm có gì không vừa ý. Việc xử lí kho hàng lỗi, hàng nhận lại từ khách hàng thế nào cho hiệu quả cũng là 1 bài toán thú vị nhưng không phải lúc nào cũng được quan tâm đúng mức.

Đó còn là hệ thống Kế toán khi cần ghi nhận lại chính xác (ở đây có thể hiểu là đến từng đồng lẻ) doanh số của đơn hàng này và các thông tin liên quan như giá nhập của sản phẩm, giá bán của sản phẩm, lợi nhuận phát sinh của Tiki, các khoản phải thu liên quan tới đơn hàng — ví dụ thu tiền thu hộ từ đối tác giao hàng đối với đơn hàng COD hoặc từ cổng thanh toán đối với đơn hàng trả trước (module Account Receivable). Ngoài ra, hệ thống Kế toán cũng cần quản lí các luồng thông tin khác như thông tin liên quan mua hàng để biết các khoản nào phải trả, trả cho ai, trả vào thời điểm nào (Account Payable), quản lí các khoản thu chi khác (Expense), quản lí tài sản, chia ngân sách cho các phòng ban (Budget) và cuối cùng là đưa ra các báo cáo giúp công ti theo dõi các chỉ số quan trọng liên quan dòng tiền, tồn kho, lợi nhuận nhằm tối ưu các chính sách kinh doanh hợp lí. Đây là hệ thống tuy không chịu áp lực cần hỗ trợ đơn hàng xử lí được nhanh nhất như các hệ thống Vận hành, nhưng có áp lực khác là số liệu cần chính xác tuyệt đối. Số liệu này lại nhận được từ nhiều nguồn khác nhau (đơn mua và trả hàng, phiếu mua và trả hàng, phiếu thu và chi tiền v.v…) nên khả năng sai lệch hoặc thiếu là có, việc đối soát điều chỉnh (reconcile) các thông tin này là 1 bài toán phức tạp nhưng quan trọng đối với Kế toán nói riêng và hoạt động quản trị công ti nói chung.

Dưới đây là 1 sơ đồ tóm tắt các module của Operation Product nhằm giúp các bạn có cái nhìn tổng quan nhất

What’s next ?

Có thể nói Tiki đã qua giai đoạn “làm cho nó chạy được cái đã” và đang ở giai đoạn “làm cho nó chạy tối ưu hơn”. Các vấn đề thú vị đang và sẽ được giải quyết trong tương lai bao gồm cả về sản phẩm lẫn qui trình

• Hệ thống đặt hàng và cân bằng tồn kho tối ưu hơn, giúp tối ưu nguồn vốn (không chứa quá nhiều hàng ít người mua) đồng thời vẫn đảm bảo trải nghiệm khách hàng (chứa đủ hàng khi có khách đặt). Đây là các dự án đang được thử nghiệm với 1 số hướng như Machine Learning kết hợp các thuật toán tối ưu truyền thống
• Hệ thống lấy hàng thông minh hơn, tính toán không đơn thuần dựa vào quãng đường đi tối ưu trong kho mà còn quan tâm đến trạng thái của đơn hàng và ưu tiên cho những đơn nào cần xử lí trước (ví dụ khách hàng chọn gói giao hàng nhanh hơn, hoặc đơn hàng sắp bị trễ thời gian cam kết)
• Hệ thống gợi ý danh sách cần đi kiểm lại hàng trong kho, bao gồm các sản phẩm theo tính toán là có khả năng bị sai lệch giữa tồn kho hệ thống và tồn kho thực tế
• Hệ thống phân tuyến giao hàng thông minh hơn có tính toán tối ưu đường đi và bàn giao đơn hàng thời gian thực (như các app Uber/Grab) thay vì chỉ bàn giao đơn hàng đầu ngày từ kho
• Hệ thống Tài chính Kế toán ghi nhận đầy đủ thông tin của tất cả luồng thao tác, các báo cáo truy xuất được dữ liệu lớn (tập thời gian rộng, số sản phẩm nhiều) và đồng bộ với data warehouse
• Các dự án cần được track và theo dõi số liệu kĩ hơn
• Tuyển dụng nâng cao về số lượng lẫn chất lượng, trong đó bao gồm qui trình tuyển dụng, qui trình on-boarding, qui trình training/coaching, qui trình đánh giá kết quả làm việc. Đồng thời xem xét thêm việc mở các tech-hub mới để tiếp cận với nguồn chất xám chất lượng ở các vùng
• Các bạn lead trong team cũng cần có chuẩn cao hơn về chất lượng và truyền tinh thần này cho team. Mọi người cần critical thinking, giải quyết vấn đề 1 cách triệt để và luôn tò mò, khám phá, stay relevant

Có 1 chia sẻ từ 1 người anh tại Tiki mình thấy khá hay, là người dùng (các bạn lao động phổ thông) ở Vận hành đa phần hệ thống có gì là họ sẽ dùng nấy, họ không thấy là cũng công việc đó có thể giải quyết bằng những cách nào khác hay hơn. Và trách nhiệm, nghệ thuật của những người làm hệ thống là cần theo sát, ngồi cùng, làm cùng và dùng kinh nghiệm cũng như khả năng chuyên môn của mình để giúp họ mở ra những chân trời mới đó.

Khi hệ thống của mình thông minh hơn, dễ hiểu hơn, chạy nhanh hơn thì cũng là khi mình giúp họ thao tác dễ dàng, bớt sai sót, tăng năng suất hơn. Đó cũng là khi mình giúp họ cải thiện thu nhập, đồng thời giúp công ti đem lại trải nghiệm tốt cho khách hàng và phát triển vững bền hơn, cuối cùng đó cũng là giúp bản thân mình lên level hơn. It’s a proud thing to do 🙂

Author: Thong Nguyen