Scale & risk
Cách đây 2 năm mình có viết về những cơ hội thử thách mới mà hệ thống cần giải quyết khi scale lớn hơn, điều rất vui là khi đọc lại đa phần đều rất relevant, những dự án sản phẩm mới ở Tiki về sau này đều có mục tiêu chính là cần "thông minh hơn" để tăng được sự tối ưu (efficiency) trong bối cảnh khối lượng công việc cần giải quyết (số lượng sản phẩm cần quản lí, số lượng đơn hàng cần xử lí) ngày càng tăng trưởng mạnh.
1 điểm khác cũng thú vị không kém, đó là có những góc nhìn đến bây giờ mình mới nhận ra là bài viết cũ chưa đề cập đến và thật ra mình cũng chưa nghĩ đến tại thời điểm đó. Nó chỉ được nghiệm ra sau này khi phải giải quyết cùng 1 bài toán nhưng ở scale lớn hơn và gặp các vấn đề rắc rối hơn, đồng thời được làm việc cùng những người có góc nhìn và cách tiếp cận mới hơn.
Đó là ở scale càng lớn, hệ thống không chỉ cần thông minh hơn mà có 1 điểm khác cũng sẽ trở nên quan trọng không kém, là "quản lí rủi ro chặt chẽ và chủ động hơn".
Ví dụ liên quan tồn kho
- Ở mức cơ bản hệ thống cần hỗ trợ người dùng biết chính xác là đang có bao nhiêu hàng trong kho nói chung và tại mỗi vị trí (kệ, pallet) ở mỗi thời điểm nói riêng
- Hiện đại hơn là hệ thống cần tính toán số lượng hàng trong kho như thế nào là tối ưu, dẫn đến là tính toán gợi ý số lượng hàng cần đặt mới từ nhà cung cấp hoặc cần luân chuyển giữa mạng lưới kho.
- Ở scale lớn nữa thì vấn đề quản trị rủi ro giảm thất thoát sai lệch sẽ là 1 bài toán mới, rất cần thiết và cấp thiết (do ở scale lớn thì 1 tỉ lệ thất thoát cho dù rất nhỏ cũng sẽ ảnh hưởng nhiều về mặt giá trị). Đây là bài toán có nhiều hướng tiếp cận, ví dụ hệ thống không chỉ cần quản lí tồn kho tại mỗi kệ, mỗi khu vực mà giờ đây còn cần quản lí cả "luồng di chuyển" của các tồn kho này để ngăn chặn các luồng di chuyển không đúng.
Quản lí luồng di chuyển là cần trả lời các câu hỏi sau
- Hàng hóa được di chuyển như thế nào là hợp lệ ?
Được di chuyển từ những vị trí nào đến những vị trí nào và ai là người có thể xác nhận ? Ví dụ hàng hóa di chuyển từ kho hàng bán sang kho hàng thất lạc, được xác nhận bởi 1 bạn nhân viên vận chuyển là có hợp lí hay không ?
2. Hàng hóa di chuyển cho dù là hợp lệ thì có hợp lí hay không ?
Ví dụ trong 1 tuần có khoảng $x giá trị hàng hóa được di chuyển từ kho hàng bán sang kho hư hỏng là bình thường hay không ? Nếu không cần coi lại việc đánh giá thế nào là hư hỏng cũng như cụ thể các luồng di chuyển hàng như trên có luồng nào dư không đúng ý đồ hay không
Trên đây chỉ là 1 ví dụ liên quan hàng hóa trong kho, khi mở rộng ra với các qui trình khác sẽ có các câu hỏi tương tự (ví dụ qui trình quản lí tiền mặt thu về sau khi giao hàng sẽ thế nào). Câu hỏi tổng quát là làm sao để đảm bảo qui trình được thực hiện 1 cách hợp lệ nhất, giảm thiểu rủi ro thất thoát khi có người/hệ thống làm sai qui trình ? Ngoài ra cần làm sao để quản lí và phát hiện những trường hợp qui trình thực hiện hợp lệ nhưng chưa hợp lí ?
Đó là những câu hỏi mà các bạn Product (cũng như các bạn engineer cho những phần về kĩ thuật) sẽ cần tự đặt, tự đánh giá cho các sản phẩm mình đang và sẽ làm. Ngoài việc quan tâm đến làm sao cho nó chạy được, làm sao cho nó chạy nhanh, làm sao cho nó chạy tối ưu thì mình cần quan tâm thêm đến khía cạnh là làm sao cho nó chạy với ít rủi ro phát sinh nhất và nếu có rủi ro thì có cơ chế phát hiện sớm (đặc biệt khi scale ngày càng lớn). Quản lí rủi ro là điểm cơ bản các công ty lớn và bài bản quan tâm (đặc biệt nếu liên quan đến tiền, như ngân hàng), start-up thường sẽ bỏ qua điểm này trong thời gian đầu phát triển nhưng dần dần cũng cần đầu tư nhiều và nghiêm túc cho nó. Điều đó cũng cần xuất phát top-down, vì không dễ để cho thấy giá trị của "risk management" trừ phi đã ... mất bò, khi đó sẽ có động lực làm chuồng :D
Những điểm trên cũng liên quan tới 1 kĩ năng mà mình nghĩ là quan trọng khi làm Product, đó là khi nhìn vào 1 vấn đề, mình không chỉ thấy mỗi vấn đề đó mà có thể đào sâu hơn để xem vấn đề đó bao gồm những gì, root-cause sâu xa của nó là gì; đồng thời mình cũng có thể nhìn tổng quát ra xem vấn đề đó nó nằm trong vấn đề lớn nào không (để xem nó có tương tự với vấn đề nào khác team đã giải quyết thì có thể gộp cùng, hoặc chia sẻ bài toán tổng quan và toàn diện hơn).
Nói nôm na, là nhòm cái cây, cần thấy cả con bọ đang bò trên cây (nắm chi tiết) và cũng thấy cả khu rừng (cái tổng quát), đừng chỉ thấy mỗi ... cái cây không :)
1 ví dụ cụ thể ở Tiki, đó là khi team Vận hành phát hiện 1 vài giao dịch luân chuyển tồn kho có vẻ không đúng, nếu chỉ xử lí bằng cách hủy các giao dịch này thì cũng đã giải quyết được sự vụ sự việc, nhưng không giải quyết được root-cause. Do đó team Tech liên quan phần Inventory dần dần đã xây dựng 1 bộ engine giúp Vận hành có thể cài đặt các rule tổng quát, chỉ định tồn kho chỉ được đi những luồng như thế nào, do ai/role nào/hệ thống nào thực hiện và có các report cho phép phát hiện những trường hợp vi phạm rule này (mặc dù cũng đã bị engine chặn) nhằm giúp các team liên quan có thể tìm hiểu và xử lí thêm về qui trình/hệ thống/con người nếu cần.
Chỉ với cách tiếp cận giải quyết root-cause và giúp chuẩn hóa qui trình bằng hệ thống như trên mới dần dần có thể giúp Vận hành được chính xác, tối ưu và ít rủi ro với scale lớn :)
PS: việc có cùng 1 bài toán, nhưng tại các thời điểm khác nhau, ở các scale khác nhau và khi làm việc cùng những người khác nhau dẫn đến nhiều góc nhìn mới và tổng quát hơn, từ đó tổng hợp thành các vấn đề mới cần xử lí cũng là 1 trong những điểm giúp mình vẫn cảm thấy hứng thú và thử thách với công việc hiện tại. Vì cũng không dễ để thích 1 việc, 1 domain - ở đây là hệ thống liên quan Vận hành - trong hơn 4 năm qua ;)