Mô hình Một-stop vs Phân chia chuyên môn
Một trong những điều tôi nhận ra sâu sắc nhất là sự khác biệt giữa mô hình một-stop và phân chia chuyên môn. Nhà đầu tư thường hỏi chúng tôi về đối thủ cạnh tranh hoặc công ty nào mà chúng tôi có thể so sánh với ở Mỹ. Trước đây, chúng tôi luôn nói rằng chúng tôi có thể so sánh với Snowflake hoặc Databricks, đặc biệt sau khi Snowflake niêm yết (vì hầu hết các nhà đầu tư không thể đánh giá công nghệ nên họ chỉ có thể so sánh với các công ty nổi tiếng để hiểu). Trong nhiều trường hợp, lãnh đạo hoặc người ra quyết định của khách hàng cũng dựa vào những so sánh này để hiểu khả năng và ứng dụng của chúng tôi. Tuy nhiên, khi nhìn kỹ hơn, chúng tôi nhận ra rằng chúng tôi khác biệt, và quan trọng hơn, nhu cầu của khách hàng ở Mỹ và Trung Quốc rất khác nhau.
Thị trường Mỹ có sự phân chia chuyên môn rất chi tiết và hoàn thiện. ETL là ETL, DW là DW, BI là BI, và hầu hết mỗi lĩnh vực đều có một số công ty niêm yết trên thị trường chứng khoán, miễn là chúng có sự khác biệt, chúng có thể kiếm tiền và bán được không rẻ. Điều này giải thích tại sao việc nói về “mô hình dữ liệu hiện đại” (Modern Data Stack) ở Mỹ rất hữu ích, vì bạn có thể dễ dàng xác định được công nghệ thuộc phần nào và các giao diện giữa các lớp tương đối chuẩn mực. Tuy nhiên, rõ ràng là điều này không hoạt động ở Trung Quốc, nơi mà sự khác biệt về công nghệ rất lớn, thậm chí còn gặp khó khăn khi phải kết nối với môi trường đã được tùy chỉnh.
Khách hàng Trung Quốc thường muốn tất cả mọi thứ chỉ bằng một khoản tiền duy nhất. Mới đây, một công ty hàng đầu đã đưa ra yêu cầu cho chúng tôi bao gồm OLAP, ETL, liên quan đến truy vấn liên hợp, và truy vấn thời gian thực, nhưng khi hỏi họ sẵn sàng trả bao nhiêu thì họ lại nói không nhiều – giống như những gì người sáng lập Geek Park Zhang Peng từng nói: “Khách hàng đưa ra những yêu cầu như khám phá mặt trăng, nhưng chỉ sẵn lòng trả tiền cho việc chuyển hàng nội thành” – đó là tình trạng hiện nay, chúng tôi cần thích nghi thay vì thay đổi (chúng tôi tất nhiên muốn thay đổi, nhưng chi phí giáo dục rất lớn và cần một quá trình dần dần), tất nhiên chúng tôi không phải là đi tới sự thỏa hiệp, mà là tìm ra sự cân bằng.
Trí tuệ nhân tạo vs AI
AI rất phổ biến, hai bên đều rất phổ biến, nhưng hướng và nội dung khác nhau. Ngoài việc cuồng nhiệt về mô hình lớn, về ứng dụng và hệ sinh thái của AI, hai bên có những con đường khác nhau. Từ sự phổ biến của Midjourney và Pika, có thể thấy thị trường Mỹ đang làm nhiều sáng kiến đổi mới mà không cần một mô hình kinh doanh cụ thể rõ ràng, nhiều ứng dụng AI SaaS, thậm chí gần đây GPT Store đã chứng kiến hàng triệu ứng dụng xuất hiện trong thời gian ngắn. Có rất nhiều ứng dụng thú vị, giải quyết vấn đề nhỏ, thậm chí nhiều ứng dụng này có thể nhanh chóng có thu nhập (từ thói quen thanh toán và đăng ký tốt).
Trong khi đó, các ứng dụng và cảnh quan AI mà chúng ta có thể thấy ở Trung Quốc hiện tại vẫn còn rất hạn chế và sơ khai, hầu hết những gì chúng ta có thể thấy và nghe đều đến từ ứng dụng 2C như văn bản thành hình ảnh, văn bản thành video. Trong các công cụ, dịch vụ doanh nghiệp, nó vẫn còn rất ít.
Quản lý vs Vận hành
Dữ liệu và phân tích, từ góc độ rộng hơn, thuộc về hệ thống hỗ trợ quyết định (DSS, Decision Support System). Theo nội dung từ Wikipedia, bắt đầu từ khoảng năm 1990, kho dữ liệu và xử lý phân tích trực tuyến (OLAP) đã mở rộng phạm vi của DSS. Hệ thống hỗ trợ quyết định là phần mềm giúp con người ra quyết định và quản lý.
Tuy nhiên, phần mềm chỉ là công cụ, là phương pháp, điều quan trọng hơn là tư duy quản lý và quy tắc. Đó chính là “Đạo” và “Pháp”. Đây mới chính là sự khác biệt lớn nhất giữa phần mềm Mỹ và Trung Quốc: môi trường văn hóa khác nhau, giai đoạn phát triển khác nhau tạo nên những tư duy quản lý và quy tắc rất khác biệt. Dù là hệ thống quản lý sản xuất ERP, hay hệ thống quản lý bán hàng CRM, cho đến các hệ thống cơ bản về nhân sự, lương bổng, đều có sự khác biệt rất lớn. Chuyên gia tư vấn Chen Guo từng viết rằng anh ấy đã làm việc ở một số công ty nước ngoài, và các ý tưởng và cách thức hoạt động cơ bản của phần mềm nhân sự và lương bổng đều rất nhất quán, dù là từ các nhà cung cấp khác nhau. Anh ấy kết luận rằng điều này là do tư duy quản lý đằng sau giống nhau, dường như mọi người đều vận hành tổ chức (Operation) theo cùng một quyển sách (Handbook) để hoàn thành công việc và đạt được mục tiêu. Giống như việc chỉ cần tuân theo cuốn sổ tay bay, một phi công sau khi được đào tạo nhất định có thể lái máy bay (cuốn sách này có thể mua ở Walmart của Mỹ).
Mua một lần vs Thanh toán theo nhu cầu
Thuê bao, đó là mô hình kinh doanh mà mọi người đều ngưỡng mộ. Đặc biệt là năm nay, khi Instacart niêm yết, họ đã công bố rằng họ đã “chi 13 triệu đô la cho Snowflake vào năm 2020”, con số này tăng lên 28 triệu đô la vào năm 2021 và lên đến 51 triệu đô la vào năm 2022 cho “dịch vụ kho dữ liệu dựa trên đám mây”. Nhưng đến năm 2023, con số này dường như đã đảo ngược, Instacart cho biết “chúng tôi dự kiến sẽ chi khoảng 15 triệu đô la cho Snowflake trong cả năm.” Đây là con số rất đáng sợ, không có công ty nào ở Trung Quốc chi hơn 51 triệu nhân dân tệ cho kho dữ liệu một năm, chưa kể mô hình thuê bao.
Đây cũng là do môi trường kinh doanh ở Trung Quốc quyết định, hầu hết khách hàng vẫn chưa chấp nhận mô hình thuê bao, chưa chấp nhận phương thức trả tiền hàng năm. Tuy nhiên, trong những năm gần đây, điều này đã cải thiện đáng kể, khách hàng dần dần cũng bắt đầu chấp nhận và thử nghiệm. Chúng tôi đã tìm ra một con đường độc đáo ở Trung Quốc, chúng tôi cung cấp cho khách hàng tài chính lớn như trả tiền hàng năm, và điều này rất hiếm trên thị trường. Tuy nhiên, khách hàng lớn của chúng tôi vẫn có sức mạnh đàm phán rất mạnh, chúng tôi không thể mở rộng như ở Mỹ một cách dễ dàng – đây cũng là kết luận từ thực tế và tổng kết trong những năm qua: khách hàng Trung Quốc thường hạn chế việc mua một sản phẩm đơn lẻ để tránh bị khóa, và thực tế của chúng tôi cho thấy, chỉ có việc cung cấp các module, sản phẩm khác nhau, tạo ra nhu cầu mới, tiếp tục mở rộng và mua thêm, chứ không phải là hy vọng có thể làm như ở Mỹ.
Triển khai cục bộ vs Cloud
Đây là sự khác biệt khiến chúng tôi đau đầu nhất. Môi trường triển khai ở Trung Quốc rất phức tạp, chúng tôi đã phải tốn rất nhiều chi phí để kết nối và kiểm tra các hệ thống khác nhau. Ở Mỹ, hầu hết chỉ có ba nền tảng đám mây cơ bản, hầu hết các công ty khởi nghiệp trong một thời gian dài chỉ hỗ trợ một nền tảng đám mây, ví dụ như Snowflake đã hỗ trợ AWS trong một thời gian dài; Databricks đã phải mất rất nhiều công sức để giúp Databricks chạy trên Azure sau khi được Microsoft đầu tư. Ở Trung Quốc, chúng tôi phải đối mặt với nhiều “nền tảng kỳ lạ” khác nhau. Gần đây, một khách hàng của chúng tôi có Spark phiên bản 2.x, họ đã yêu cầu chúng tôi chỉnh sửa sản phẩm của mình, may mắn là cuối cùng khách hàng đã được thuyết phục nâng cấp Spark của họ lên phiên bản 3.x. Nếu mỗi trường hợp như vậy đều cần tùy chỉnh, công việc sẽ tiêu tốn rất nhiều nguồn lực.
Ở thời đại mô hình lớn, chúng tôi đột nhiên nhận ra rằng chúng ta lại phải kết nối với nhiều phiên bản “kỳ lạ” khác nhau. May mắn thay, hiện nay GPU vẫn còn đắt đỏ, may mắn thay chúng tôi đã tạo ra một khung đánh giá (xem chi tiết: Khả năng của mô hình lớn trong phân tích dữ liệu), giúp chúng tôi dễ dàng kết nối với nhiều môi trường khác nhau. Tuy nhiên, có thể dự đoán, công việc tinh chỉnh trong tương lai sẽ chiếm rất nhiều thời gian.
Tự phát triển vs SaaS
Xây dựng vs Mua, khách hàng Trung Quốc thích tự xây dựng “thực hiện nội bộ”, nhiều lập trình viên đã lãng phí thời gian vào các “sửa đổi kỳ lạ”. Mới đây, cuộc tranh luận về việc liệu MySQL có nên chạy trên container hay không là một ví dụ điển hình. Nhiều lúc, khách hàng tìm đến chúng tôi khi họ không thể tự làm, thậm chí họ còn học từ sản phẩm của chúng tôi sau đó quay lại tự nghiên cứu.
Theo báo cáo, doanh nghiệp vừa và nhỏ ở Mỹ trung bình sử dụng hơn 100 dịch vụ SaaS, và doanh nghiệp lớn hơn sử dụng hơn 200 dịch vụ. Ở Mỹ, một đội ngũ khởi nghiệp ngày nay xây dựng ứng dụng của mình, ngoại trừ các thành phần cốt lõi, phần còn lại đều được xây dựng nhanh chóng bằng SaaS, không lãng phí một lập trình viên nào. Đây cũng là lý do tại sao nhiều công cụ SaaS sống tốt ở Mỹ.
Chúng tôi cũng đã sử dụng khoảng mười dịch vụ SaaS, nhưng so với Mỹ, con số này vẫn còn rất ít. Hơn nữa, khách hàng lớn của chúng tôi, do bị hạn chế bởi chính sách, mua sắm và các lý do khác, thời gian mua sắm dịch vụ SaaS thuần túy ở Trung Quốc vẫn cần vài năm nữa. Chúng tôi không thể chờ đợi, chúng tôi cần thích nghi với thị trường này, nhưng có thể sáng tạo để cải thiện hiệu quả và giảm chi phí. Kế hoạch gần đây của chúng tôi là cho phép khách hàng sử dụng SaaS hoặc PaaS để thử nghiệm, PoC; thông qua SOP PoC tiêu chuẩn để giúp hoàn thành đánh giá nhanh chóng; thông qua mô hình triển khai kịch bản, giao hàng cho khách hàng trong vòng vài ngày.
Tính năng / Hiệu suất vs Trải nghiệm người dùng
Người dùng Trung Quốc nhấn mạnh tính năng, người dùng Mỹ nhấn mạnh trải nghiệm người dùng; người dùng Trung Quốc thích dịch vụ theo yêu cầu, người dùng Mỹ thích tự mày mò, yêu cầu tài liệu rất cao. Những khác biệt này đã trở nên rất rõ ràng trong thực tiễn trong những năm gần đây. Đặt lời của đồng nghiệp Mỹ: “Người dùng Mỹ đều là những đứa trẻ giàu có, chúng ta ở Trung Quốc vẫn vui vẻ nếu được cho một viên kẹo, còn đâu mà quan tâm đến bao bì có đẹp hay không”.
Sự khác biệt này rất lớn, đến mức đôi khi chúng tôi cảm thấy bị chia rẽ. Về bản chất, đây là do thói quen xã hội, sản phẩm đã tồn tại (cách người khác phục vụ khách hàng) và môi trường kinh doanh gây ra. Do phần lớn phần mềm ở Mỹ đã rất trưởng thành, người sử dụng là khách hàng, họ có những yêu cầu mặc định, và yêu cầu rất cao. Ví dụ, tiếng Anh, một nhân viên người Mỹ đã nói với tôi rằng, ở Mỹ, một email có lẫn tiếng Trung (Chinglish) sẽ được mặc định là lừa đảo, thư rác. Viết thông tin Stack của Java trực tiếp vào giao diện người dùng, điều đó có nghĩa là sản phẩm không tốt. Quá trình hoạt động trong tài liệu không khớp với phần mềm (ví dụ, thứ tự trước sau sai), khách hàng sẽ không sử dụng.
Mọi thứ đều làm vs Kinh tế API
Chúng tôi đã gặp rất nhiều yêu cầu kết nối với nguồn dữ liệu, dịch vụ SaaS. Một sự khác biệt lớn trong thực tế là phần lớn phần mềm ở Mỹ đều có API/SDK, thậm chí nhiều phần mềm hiện tại có webhook rất tiện lợi, rất dễ dàng để kết nối và tích hợp với các hệ thống khác. Hơn nữa, nhiều công ty khởi nghiệp ở Mỹ khi xây dựng ứng dụng của mình, thường sẽ xem xét trước có dịch vụ SaaS nào có thể sử dụng (và điều kiện tiên quyết là có API có thể sử dụng), và thường là API tiêu chuẩn và cách sử dụng, thậm chí dịch vụ như Zapier rất phổ biến và quan trọng. Điều này rất dễ dàng để kết nối nhiều dịch vụ SaaS, không cần phải xây dựng mọi thứ từ đầu.
Tôi luôn phản đối việc làm mọi thứ trong sản phẩm của riêng mình. Mới đây, một khách hàng đã đưa ra N yêu cầu, tôi nói rằng đây ít nhất là 5 loại hệ thống, từ truy vấn liên hợp, xử lý luồng hàng loạt đến phân tích thời gian thực, thậm chí còn quá đáng khi đưa cả yêu cầu ETL vào. Những công việc này thực tế có thể được hoàn thành bằng các chuỗi công cụ khác nhau, nhưng nhiều khách hàng lại mong muốn chúng tôi cung cấp tất cả mọi thứ trong một sản phẩm.
Ví dụ đơn giản, nhiều khách hàng, đối tác rất thích Kyligence Zen, nhưng ban đầu họ đã đưa ra yêu cầu: phải kết nối với một số nguồn dữ liệu nhất định, họ rất khó chấp nhận việc chuyển dữ liệu vào S3 như một giao diện trao đổi chung. Nhiều người không hiểu tại sao tôi lại từ chối thực hiện những yêu cầu này, một phần vì yêu cầu này sẽ làm cho sản phẩm càng ngày càng nặng nề, càng ngày càng tùy chỉnh; và quan trọng hơn, có vô số công cụ và dịch vụ SaaS có thể hoàn thành, ví dụ như gần đây chúng tôi cần xuất dữ liệu từ bảng đa chiều Feishu vào S3 (yêu cầu kết nối với bảng đa chiều này đã có từ lâu), điều này có thể được hoàn thành bằng Byzer (có rất nhiều công cụ khác), thông qua nền tảng mã thấp của Feishu, chúng tôi đã thực hiện các tự động hóa đẩy, sao lưu, phê duyệt giấy phép/bản quyền.
Hệ thống ranh giới rõ ràng là một yêu cầu cơ bản của một sản phẩm phần mềm tốt, với S3 (tương tự như Hive trong thời kỳ Kylin) là giao diện đầu vào, và SQL là giao diện đầu ra, trong phạm vi này, chúng tôi tập trung vào việc tối ưu hóa mọi khả năng, cải thiện trải nghiệm người dùng, và thông qua các chuỗi công cụ thứ ba, giúp khách hàng hoàn thành công việc liên quan.
Từ khóa:
- API Economy
- Trải nghiệm người dùng
- Mô hình đám mây
- Trí tuệ nhân tạo
- Phân tích dữ liệu