Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Bài 40 — Case Study: Tiki Data Foundation

Data-Driven Organization Bài 40/60

Mở đầu — vì sao bài này quan trọng

Đọc lý thuyết về "data-driven organization" thì ai cũng gật gù. Nhưng khi bắt tay vào xây thật, bạn sẽ vấp phải một câu hỏi rất khó chịu: "Bắt đầu từ đâu, và làm theo trình tự nào?" Sách vở nước ngoài thường lấy ví dụ Netflix, Amazon, Airbnb — những công ty có ngân sách gần như vô hạn, đội ngũ kỹ sư top thế giới, và một thị trường trưởng thành. Còn bạn thì đang ngồi ở Việt Nam, với một công ty vài trăm nhân sự, ngân sách hữu hạn, đội data mỏng, dữ liệu nằm rải rác trong mười cái file Excel và ba cái database không nói chuyện được với nhau.

Đó chính là lý do bài này chọn Tiki làm case study. Tiki là một công ty e-commerce sinh ra và lớn lên tại Việt Nam, cùng bối cảnh, cùng ràng buộc, cùng thị trường với đa số học viên của khóa học này. Hành trình data của Tiki — từ những báo cáo Excel thủ công năm 2014 đến một nền tảng dữ liệu phục vụ hàng chục triệu người dùng — là một tấm bản đồ rất sát với thực tế mà bạn có thể đối chiếu. Quan trọng hơn, câu chuyện của Tiki cho thấy rõ một điều: xây data foundation không phải là chuyện mua đúng công cụ, mà là chuyện tiến hóa từng bước theo đúng nhu cầu kinh doanh, và mỗi giai đoạn giải quyết đúng nỗi đau của giai đoạn đó.

Bài này không dạy bạn công cụ mới (những bài trước đã làm điều đó). Bài này dạy bạn cách các mảnh ghép đó ráp lại thành một hành trình có thật, qua lăng kính một doanh nghiệp Việt Nam mà bạn có thể học và bắt chước.

Khái niệm cốt lõi

Data foundation là gì và khác gì với "có nhiều dữ liệu"

Rất nhiều lãnh đạo nhầm lẫn: "Công ty tôi có cả terabyte dữ liệu, tức là chúng tôi mạnh về data." Không hẳn. Data foundation (nền tảng dữ liệu) là toàn bộ hạ tầng, quy trình, con người và văn hóa giúp dữ liệu chảy từ nơi phát sinh đến nơi ra quyết định một cách đáng tin cậy và lặp lại được. Có nhiều dữ liệu mà không có foundation thì cũng như có nhiều nước mà không có đường ống — nước ở khắp nơi nhưng không ai uống được.

Một data foundation trưởng thành có bốn lớp:

  • Lớp thu thập (ingestion): dữ liệu từ website, app, hệ thống bán hàng, kho vận, thanh toán được gom về một chỗ.
  • Lớp lưu trữ và xử lý (storage & processing): data warehouse hoặc data lake, nơi dữ liệu được chuẩn hóa, làm sạch, biến đổi.
  • Lớp phục vụ (serving): BI tools, API, bảng dữ liệu sạch cho các đội tự khai thác.
  • Lớp con người và quy trình (people & process): đội data, quy tắc governance, và văn hóa dùng data để quyết định.
Điểm mấu chốt của case Tiki là: họ không xây cả bốn lớp cùng lúc. Họ tiến hóa theo giai đoạn, và mỗi giai đoạn đầu tư đúng vào lớp đang là nút thắt cổ chai.

Bối cảnh Tiki

Tiki được thành lập năm 2010, khởi đầu là một cửa hàng sách trực tuyến, sau đó mở rộng thành sàn thương mại điện tử tổng hợp với mô hình lai giữa bán trực tiếp (retail/1P) và marketplace (3P). Đến giai đoạn tăng trưởng mạnh, Tiki phục vụ hàng chục triệu người dùng, với đặc thù rất "khó nhằn" về dữ liệu: một đơn hàng có thể liên quan tới hàng tồn kho ở nhiều kho, nhiều nhà bán, dịch vụ giao nhanh TikiNOW, chương trình khuyến mãi phức tạp, và thanh toán qua nhiều cổng. Mỗi mảng sinh ra một luồng dữ liệu riêng.

Chính độ phức tạp này khiến Tiki trở thành ví dụ tốt: nếu foundation không được xây bài bản, mọi con số báo cáo sẽ mâu thuẫn nhau, và không ai dám tin số liệu để ra quyết định.

Bốn giai đoạn tiến hóa (mô hình để bạn tự chiếu vào công ty mình)

Dựa trên hành trình chung của các công ty e-commerce Việt Nam ở quy mô tương tự, ta có thể chia thành bốn giai đoạn điển hình:

Giai đoạn 1 (khoảng 2014–2017) — Thủ công và rời rạc. Báo cáo chủ yếu bằng Excel, xuất thủ công từ database sản xuất, chốt số theo tháng. Mỗi phòng ban tự kéo số theo cách riêng, dẫn tới tình trạng "doanh thu của phòng A khác doanh thu của phòng B". Đây là giai đoạn "báo cáo nhìn về quá khứ".

Giai đoạn 2 (khoảng 2017–2019) — Tập trung hóa. Xây data warehouse tập trung, dựng pipeline tự động kéo dữ liệu từ các hệ thống nguồn, chuẩn hóa định nghĩa metric. Đây là lúc khái niệm "một nguồn sự thật duy nhất" (single source of truth) ra đời. Đội data engineering được thành lập nghiêm túc.

Giai đoạn 3 (khoảng 2019–2021) — Dân chủ hóa và tự phục vụ. BI tool được triển khai rộng, các đội business tự làm dashboard mà không cần chờ đội data. Xuất hiện các bài toán nâng cao: gợi ý sản phẩm (recommendation), dự báo nhu cầu tồn kho, phân khúc khách hàng.

Giai đoạn 4 (từ khoảng 2021 trở đi) — Data như một sản phẩm. Dữ liệu real-time phục vụ cá nhân hóa, thử nghiệm A/B ở quy mô lớn, machine learning nhúng vào sản phẩm. Data không còn là bộ phận hỗ trợ mà trở thành lợi thế cạnh tranh trực tiếp.

Lưu ý quan trọng: các mốc thời gian mang tính minh họa cho mô hình tiến hóa, giúp bạn hình dung nhịp độ, chứ không phải mốc chính xác được công bố nội bộ. Điều bạn cần rút ra là trình tựlogic chuyển giai đoạn, không phải con số năm.

Tình huống thực tế

Tình huống 1 — Nỗi đau "ba con số doanh thu khác nhau" ở giai đoạn 1

Hãy hình dung một cuộc họp giao ban điển hình của giai đoạn thủ công. Giám đốc tài chính báo doanh thu tháng là 48 tỷ. Giám đốc vận hành nói theo hệ thống kho, giá trị hàng xuất đi tương ứng 52 tỷ. Giám đốc marketing thì report 45 tỷ dựa trên số đơn ghi nhận trên hệ thống của họ. Ba con số, ba định nghĩa, ba thời điểm chốt sổ khác nhau — đơn hủy tính hay không, đơn đang giao tính hay chưa, khuyến mãi trừ vào doanh thu ở bước nào.

Cả buổi họp biến thành cuộc tranh cãi "số của ai đúng" thay vì bàn "làm gì tiếp theo". Đây là triệu chứng kinh điển của việc thiếu foundation: dữ liệu tồn tại, nhưng không có định nghĩa metric thống nhất và không có nguồn sự thật duy nhất.

Bài học rút ra: Nút thắt của giai đoạn 1 không phải là thiếu công cụ đắt tiền. Nút thắt là thiếu sự đồng thuận về định nghĩa. Trước khi mua Snowflake hay Looker, việc đầu tiên phải làm là ngồi lại và thống nhất: "Doanh thu ròng là gì? Tính theo thời điểm nào? Trừ những gì?" Rất nhiều công ty Việt Nam vội mua công cụ đắt tiền trong khi vấn đề thật nằm ở chỗ chưa ai chốt định nghĩa.

Tình huống 2 — Cú chuyển sang data warehouse tập trung (giai đoạn 2)

Khi Tiki chuyển sang mô hình tập trung, họ giải quyết vấn đề trên bằng cách xây một data warehouse làm điểm hội tụ. Toàn bộ dữ liệu từ hệ thống đơn hàng, kho vận, thanh toán, hệ thống nhà bán được đổ về một nơi, qua các pipeline chạy tự động hằng đêm. Metric được định nghĩa một lần, ở một chỗ, và mọi báo cáo đều lấy từ nguồn đó.

Kết quả không chỉ là "số liệu khớp nhau". Kết quả sâu xa hơn là tốc độ ra quyết định tăng lên. Trước đó, một câu hỏi kiểu "sản phẩm nào bán chạy nhất ở Hà Nội tuần qua, loại trừ đơn hủy" có thể mất hai ngày vì phải nhờ nhân sự kéo tay và đối chiếu. Sau khi có warehouse, đó là một truy vấn vài phút.

Một ví dụ Đông Nam Á song song để đối chiếu: Shopee (thuộc Sea Group) cũng đi qua giai đoạn này ở quy mô khu vực, khi phải hợp nhất dữ liệu của hàng chục thị trường với hàng trăm triệu người dùng vào một nền tảng phân tích thống nhất — nếu mỗi quốc gia định nghĩa metric một kiểu thì ban lãnh đạo khu vực không thể so sánh hiệu quả giữa các thị trường.

Bài học rút ra: Giá trị lớn nhất của việc tập trung hóa dữ liệu không phải "đẹp báo cáo", mà là giảm chi phí niềm tin (trust cost). Khi mọi người tin vào số, họ ngừng cãi nhau về số và bắt đầu tranh luận về hành động. Đó là dấu hiệu đầu tiên của một tổ chức thực sự data-driven.

Tình huống 3 — Khi tự phục vụ mở khóa tốc độ (giai đoạn 3)

Ở giai đoạn 3, một tình huống rất đời thường: đội marketing muốn biết hiệu quả của một chiến dịch flash sale theo từng giờ để quyết định có bơm thêm ngân sách quảng cáo hay không. Ở giai đoạn 2, họ phải gửi yêu cầu cho đội data và chờ. Ở giai đoạn 3, họ tự mở dashboard trên BI tool, tự lọc theo giờ, theo ngành hàng, và ra quyết định ngay trong lúc flash sale còn đang diễn ra.

Con số minh họa: giả sử một chiến dịch flash sale kéo dài 6 giờ. Nếu phải chờ báo cáo sau sự kiện, mọi tối ưu đều là "rút kinh nghiệm cho lần sau". Nếu tự phục vụ trong thời gian thực, đội marketing có thể phát hiện ngành hàng gia dụng đang chuyển đổi tốt gấp đôi bình thường sau 90 phút đầu, và dịch chuyển 30% ngân sách quảng cáo sang đó — cứu được doanh số ngay trong chính chiến dịch đó.

Nhưng tự phục vụ cũng sinh ra rủi ro: nếu ai cũng tự định nghĩa lại metric trên dashboard riêng, ta lại quay về cơn ác mộng "ba con số khác nhau" của giai đoạn 1, chỉ khác là bây giờ trên công cụ hiện đại. Vì thế giai đoạn 3 bắt buộc đi kèm với một lớp semantic/metric layer được quản trị tập trung — tức là một tầng định nghĩa metric chuẩn mà mọi dashboard đều phải dùng.

Bài học rút ra: Dân chủ hóa dữ liệu không có nghĩa là buông lỏng. Tự do khai thác phải đi cùng chuẩn hóa định nghĩa. "Tự do trong khuôn khổ" là công thức duy nhất giúp self-service không biến thành hỗn loạn.

Hướng dẫn từng bước

Nếu bạn là người chịu trách nhiệm xây data foundation cho một công ty Việt Nam quy mô vừa, đây là lộ trình rút ra từ hành trình của Tiki, áp dụng được ngay:

Bước 1 — Chẩn đoán giai đoạn hiện tại. Trước khi làm gì, xác định công ty bạn đang ở giai đoạn nào trong bốn giai đoạn trên. Dấu hiệu nhận biết: còn cãi nhau về định nghĩa số (giai đoạn 1), đã có warehouse nhưng mọi báo cáo vẫn phải qua đội data (giai đoạn 2), business đã tự làm dashboard (giai đoạn 3). Đừng cố nhảy cóc — công ty ở giai đoạn 1 mà đòi làm real-time ML là công thức thất bại.

Bước 2 — Chốt định nghĩa metric cốt lõi trước khi mua công cụ. Ngồi lại với tài chính, vận hành, marketing để thống nhất 10–15 metric quan trọng nhất: doanh thu ròng, số đơn hợp lệ, tỷ lệ hủy, giá trị đơn trung bình (AOV), khách hàng mới và cũ. Viết định nghĩa ra thành văn bản. Đây là bước rẻ nhất nhưng có sức mạnh lớn nhất.

Bước 3 — Xây điểm hội tụ dữ liệu. Chọn một data warehouse (các bài 7–8 đã bàn về Snowflake, BigQuery, Redshift) và dựng pipeline tự động kéo dữ liệu từ các hệ thống nguồn về. Ưu tiên các nguồn quan trọng nhất trước: đơn hàng, khách hàng, sản phẩm. Đừng cố kéo hết mọi thứ ngày đầu.

Bước 4 — Dựng lớp phục vụ tối thiểu. Triển khai một BI tool (bài 10) và làm sẵn 5–10 dashboard "vàng" cho các câu hỏi kinh doanh được hỏi nhiều nhất. Mục tiêu là để lãnh đạo thấy giá trị nhanh, tạo động lực đầu tư tiếp.

Bước 5 — Mở dần quyền tự phục vụ kèm quản trị. Khi các đội đã quen dùng dashboard có sẵn, mở cho họ tự tạo báo cáo — nhưng luôn trên nền metric layer chuẩn. Kèm theo là đào tạo data literacy (bài 5) để họ đọc số đúng.

Bước 6 — Đầu tư nâng cao theo nhu cầu kinh doanh thực. Chỉ khi ba giai đoạn trên đã vững mới bước sang recommendation, forecasting, real-time. Và mỗi dự án nâng cao phải gắn với một business case rõ ràng (bài 29), không làm vì "công ty khác cũng làm".

Lỗi thường gặp & mẹo

Lỗi 1 — Mua công cụ trước, giải quyết vấn đề sau. Rất nhiều công ty Việt Nam nghĩ rằng mua một data platform xịn là xong chuyện. Thực tế công cụ chỉ là 20%, còn 80% là định nghĩa, quy trình và con người. Mẹo: luôn hỏi "vấn đề kinh doanh cụ thể nào công cụ này giải?" trước khi ký hợp đồng.

Lỗi 2 — Nhảy cóc giai đoạn. Thấy Tiki hay Netflix làm ML, real-time nên muốn làm ngay dù foundation còn chưa có. Kết quả là mô hình ML chạy trên dữ liệu bẩn, cho ra kết quả sai, làm mất niềm tin của lãnh đạo vào cả chương trình data. Mẹo: "garbage in, garbage out" — không có foundation sạch thì mọi thứ nâng cao đều vô nghĩa.

Lỗi 3 — Xây foundation rồi để đó, không tạo văn hóa dùng. Có warehouse đẹp, dashboard đầy đủ, nhưng lãnh đạo vẫn quyết định theo cảm tính. Mẹo: đưa data vào chính nhịp họp — mỗi quyết định lớn phải mở kèm một dashboard. Văn hóa hình thành từ thói quen lặp lại, không từ công cụ.

Lỗi 4 — Đội data ôm hết, trở thành nút cổ chai. Nếu mọi câu hỏi đều phải qua đội data, đội đó sẽ quá tải và business mất kiên nhẫn. Mẹo: chủ động chuyển sang self-service sớm khi đã đủ vững, để đội data tập trung vào bài toán khó thay vì kéo báo cáo tay.

Mẹo tổng quát: Hãy coi việc học từ Tiki là học nhịp độ và trình tự, không phải sao chép nguyên xi kiến trúc. Quy mô của bạn khác, ràng buộc của bạn khác — nhưng logic "giải đúng nút thắt của từng giai đoạn" thì phổ quát.

Bài tập thực hành

Bài tập 1 — Tự chẩn đoán giai đoạn. Viết một đoạn ngắn (nửa trang) xác định công ty bạn (hoặc một công ty bạn biết rõ) đang ở giai đoạn nào trong bốn giai đoạn. Liệt kê 3 dấu hiệu cụ thể chứng minh cho kết luận đó.

Bài tập 2 — Danh sách nút thắt. Với giai đoạn vừa xác định, liệt kê nút thắt cổ chai lớn nhất về dữ liệu hiện nay, và đề xuất một hành động cụ thể trong 90 ngày để tháo nút đó. Hành động phải cụ thể (ví dụ "chốt định nghĩa 10 metric cốt lõi với 3 phòng ban"), không chung chung.

Bài tập 3 — Đối chiếu case. So sánh hành trình data của công ty bạn với bốn giai đoạn của Tiki. Bạn đã bỏ qua giai đoạn nào chưa làm kỹ và đang trả giá vì nó? Viết một đoạn phân tích ngắn.

Bài tập 4 (nâng cao) — Thiết kế lộ trình 3 mốc. Phác thảo lộ trình đưa công ty bạn tiến lên giai đoạn tiếp theo, chia thành 3 mốc (mỗi mốc kèm mục tiêu kinh doanh đo được, không chỉ mục tiêu kỹ thuật). Ví dụ mốc 1: "giảm thời gian ra báo cáo doanh thu từ 2 ngày xuống 2 giờ".

Tóm tắt

Case Tiki cho chúng ta một bài học cốt lõi: xây data foundation là một hành trình tiến hóa theo giai đoạn, không phải một dự án mua sắm công cụ một lần. Tiki đi từ báo cáo Excel thủ công (giai đoạn 1), sang data warehouse tập trung với một nguồn sự thật duy nhất (giai đoạn 2), sang dân chủ hóa và tự phục vụ có quản trị (giai đoạn 3), và cuối cùng là data như một sản phẩm với ML và real-time (giai đoạn 4).

Ba điểm cần ghi nhớ. Thứ nhất, nút thắt của mỗi giai đoạn khác nhau — giai đoạn đầu là định nghĩa và niềm tin vào số, không phải công nghệ. Thứ hai, giá trị lớn nhất của tập trung hóa dữ liệu là giảm "chi phí niềm tin", giúp tổ chức ngừng cãi về số và bắt đầu bàn về hành động. Thứ ba, dân chủ hóa phải đi kèm chuẩn hóa định nghĩa, nếu không self-service sẽ tái tạo lại chính sự hỗn loạn mà nó định giải quyết.

Đừng nhảy cóc. Hãy chẩn đoán đúng giai đoạn của mình, giải đúng nút thắt của giai đoạn đó, và để mỗi khoản đầu tư data gắn với một nhu cầu kinh doanh thật. Đó chính là cách một công ty Việt Nam trở thành một tổ chức data-driven bền vững — như con đường mà Tiki đã đi.