Nghịch lý Solow và bài học dành cho kỷ nguyên AI

Nghịch lý Solow là gì?

Vào những năm 1970-1980, các doanh nghiệp tại Mỹ bắt đầu chạy đua đầu tư vào công nghệ thông tin. Nguồn đầu tư khổng lồ này xuất phát từ kỳ vọng rằng CNTT sẽ tạo ra một bước nhảy vọt về năng suất. Tiếc thay, bức tranh nền kinh tế Mỹ tại thời điểm đó lại được vẽ theo chiều ngược lại với kỳ vọng, tại thời điểm đó tốc độ tăng trưởng năng suất gia tăng tổng hợp lại bị chậm lại. Điều này lộ rõ một mâu thuẫn giữa một bên là sự bùng nổ của công nghệ máy tính (máy tính xuất hiện ở mọi văn phòng, nhà máy, cửa hàng) và một bên là con số thực tế về năng suất lao động tổng thể không tăng trưởng như kỳ vọng.

Nhà kinh tế học đoạt giải Nobel Robert Solow đã nói: “You can see the computer age everywhere but in the productivity statistics.” – Tạm dịch: “Bạn có thể thấy kỷ nguyên máy tính ở khắp nơi, trừ trong những số liệu thống kê về năng suất.” – Câu phát biểu này được biết đến như một nghịch lý, gọi là Nghịch lý Solow (Solow Paradox).

Phải đến cuối những năm 1990 thì nghịch lý Solow mới được giải quyết, khi các doanh nghiệp tại Mỹ bắt đầu tìm ra phương thức/quy trình kinh doanh phù hợp với CNTT và bắt đầu chuyển đổi để có thể phát triển xoay quanh CNTT.

Nghịch lý Solow và bài học dành cho kỷ nguyên AI

Bài học từ kỷ nguyên bùng nổ công nghệ thông tin

Trước khi đi vào phân tích về những vấn đề vì sao ngành CNTT những năm ~ 1980 lại tồn tại nghịch lý Solow thì tôi muốn chia sẻ một câu chuyện xa hơn nhưng có hình thái tương tự:

Khi điện năng xuất hiện vào cuối thế kỷ 19, các chủ nhà máy bắt đầu thay thế hàng loạt cỗ máy chạy bằng hơi nước bằng những động cơ chạy bằng điện. Các chủ này cũng kỳ vọng rằng động cơ điện sẽ giúp họ nâng cao năng suất. Nhưng thực tế thì ngược lại, trong gần 30 năm sau đó, năng suất không hề tăng! Lý do là, các nhà máy thay thế động cơ nhưng không biết cách, hoặc vẫn giữ những bố trí cũ vốn chỉ tối ưu cho động cơ hơi nước. Mãi sau này người ta mới nhận ra được lợi thế thực sự của động cơ điện là nhỏ và linh hoạt, và sau đó đã sắp xếp và bố trí lại nhà máy để có thể tối ưu hóa được lợi thế này.

Câu chuyện trên là những gì đã lặp lại ở kỷ nguyên AI. Chúng ta (con người) vẫn dính đúng cái bẫy mà mình từng vấp phải, đó là những cái bẫy mang tính hệ thống:

Trải nhựa lên lối mòn (Paving the cow path – Reengineering Work: Don’t Automate, Obliterate, HBR by Hammer): Cách thức/thói quen hoạt động cũ đã được “chứng minh”, nhưng chỉ đúng/phù hợp với môi trường cũ. Khi mọi thứ thay đổi mà vẫn dùng lại lối mòn đó và chỉ áp dụng công nghệ mới vào, việc này chẳng những không giúp giải quyết vấn đề mà còn làm cho những điểm yếu của cách cũ bị phóng đại lên. Điều này thể hiện rõ nhất ở kỷ nguyên công nghệ thông tin: khi mô hình quản lý dự án vốn chỉ phù hợp với những công việc đã có kế hoạch chi tiết, theo công thức. Trong khi công nghệ thông tin là một lĩnh vực thay đổi nhanh, khó đoán và vốn không thể lên kế hoạch dài hạn. Lối mòn ở đây chính là cách quản lý dự án cũ. Tiếp tục đi trên lối mòn đó trong một ngành khó đoán như công nghệ thông tin đã tạo ra nhiều vấn đề hơn là lợi ích. Mãi đến những năm 90, hàng loạt cách làm việc kiểu mới xuất hiện, trong đó có Scrum, thì người ta mới bắt đầu có được cách tốt và phù hợp hơn để làm việc trong lĩnh vực công nghệ thông tin.

Cấu trúc/ mô hình không đổi: Đổi mới cũng kèm theo bản thân tổ chức đó cũng phải thay đổi, về cấu trúc/ mô hình kinh doanh, đào tạo lại nhân viên với kỹ năng mới, văn hoá và mô hình quản trị mới. Thông thường những đổi mới chỉ đến ở bề mặt, và các tổ chức thường vẫn giữ mô hình kinh doanh kiểu cũ, nhân viên chưa được đào tạo để đáp ứng với những thay đổi, thêm vào đó văn hoá là thứ dễ bị bỏ bê nhưng lại có ảnh hưởng lớn nhất (việc này có liên quan đến cái bẫy tiếp theo). Ví dụ như những mô hình tổ chức cũ tập trung đo lường sản lượng và chất lượng đầu ra, nhưng khi công nghệ mới giúp cho cuộc chơi trở nên cạnh tranh hơn, ai cũng có thể tạo ra output tương tự, thì lúc này sự cạnh tranh sẽ không còn nằm ở năng lực sản xuất mà ở năng lực tạo ra giá trị cho người dùng.

Tư duy cũ: Khi công nghệ thay đổi, mô hình thay đổi, nhưng mindset của con người bên trong hệ thống chưa kịp thay đổi là một cái bẫy tự nhiên. Bản thân mindset cần thời gian và môi trường phù hợp để thay đổi. Đa phần các công ty khi đối mặt với những thay đổi lớn thì mindset là thứ khó khăn để thay đổi nhất, thực tế nếu không có những điều kiện thuận lợi, những con người có mindset cũ rất khó có thể chuyển sang mindset mới, thay vào đó họ thường phải được thay thế hoàn toàn bởi những người trẻ có mindset mới hơn. Có thể nói đây là cái bẫy khó vượt qua nhất. NUMMI (New United Motor Manufacturing, Inc.) được thành lập vào năm 1984 tại Fremont, California – liên doanh giữa General Motors (GM) và Toyota là một ví dụ: GM đã gửi 16 quản lý trẻ có triển vọng đến NUMMI để học hỏi về TPS (Toyota Production System / Lean Manufacturing), nhưng khi quay trở lại GM, những thay đổi khi áp dụng lại gặp cản trở rất nhiều từ những tư duy làm việc và quản lý cũ tại GM. Thậm chí những người trở về từ NUMMI đã bị cô lập, kỳ thị, vì tư duy mới của họ, những điều này khiến cho những đổi mới bị thất bại thảm hại. GM không chuyển hóa được chính mình dù có công thức thành công, sau đó Toyota ngày càng bỏ xa họ.

Nghịch lý Solow sẽ lặp lại trong kỷ nguyên AI?

Nó đang lặp lại. Nếu quan sát kỹ, thì hiện tại thực trạng ứng dụng AI trong công việc không khác mấy so với kỷ nguyên CNTT, và thậm chí trong lịch sử trước đó đã có bài học về việc thay thế động cơ hơi nước bằng động cơ điện. Hiện rất ít các tổ chức có lợi ích thực sự từ việc áp dụng AI, theo khảo sát của NBER, khoảng 6.000 lãnh đạo ở Mỹ, Anh, Đức, Úc: hơn 80% doanh nghiệp không thấy tác động nào từ AI lên việc làm hay năng suất. 89% quản lý không thấy năng suất thay đổi trong ba năm, dù tỷ lệ doanh nghiệp dùng AI tăng từ 61% lên 71%. Còn theo MIT NANDA: 95% tổ chức không thu được lợi nhuận có thể đo lường được.

Vậy đâu là lối ra? Lịch sử đã có bài học, và giải pháp cũng nằm trong chính bài học lịch sử đó:

Thay đổi cách làm việc cũ, xây dựng cách làm mới phù hợp và xoay quanh sự đổi mới: Việc xác định rõ những điểm mạnh và yếu của AI, kèm theo thay đổi cách làm việc, ứng dụng AI vào đúng chỗ và hợp lý sẽ giúp các tổ chức tránh được “rượu mới bình cũ”. Chấp nhận những thứ đã “đúng”, có thể giờ không còn phù hợp nữa.
Việc thay đổi cách làm việc sẽ không thể thành công nếu hệ thống, tổ chức đó không thay đổi. Để thay đổi cách làm việc, thì định hướng, hệ thống đo lường, quản trị của tổ chức đó cũng phải được thiết kế sao cho những thay đổi có cơ hội được xuất hiện, áp dụng, học hỏi. Những mục tiêu kinh doanh cũng cần được xem xét lại, vì khả năng cạnh tranh cũ có thể dễ dàng bị AI cân bằng. Lúc đó, để tránh việc lợi ích bị triệt tiêu ở cấp độ hệ thống, doanh nghiệp cũng phải tìm ra được giá trị kinh doanh mới để thoát khỏi “bẫy bão hòa” (khi ai cũng có AI, output không còn là lợi thế).
Khi hai cái bẫy trên được gỡ bỏ, thì lúc này mới có cơ hội cho bẫy tư duy được tháo gỡ. Một định hướng rõ ràng, trao cơ hội cho người có tư duy mới, tìm tòi và cải tiến sẽ là vùng an toàn để nuôi dưỡng những ý tưởng, những cải tiến.

Scrum còn phù hợp trong kỷ nguyên AI?

Bài học về nghịch lý Solow không mới, nó đã và đang lặp lại. Scrum được sinh ra khi kỷ nguyên CNTT bùng nổ, và nó là thứ được tạo ra để giải quyết những vấn đề phức tạp, bao gồm những cái bẫy của nghịch lý Solow.

Scrum hướng team đến việc trải nghiệm và thích ứng với những biến đổi thay vì đi theo lối mòn. Scrum cũng đóng góp vào việc thay đổi cách vận hành của tổ chức ở mức độ team, và cũng ở mức độ tổ chức. Scrum cũng là nơi sinh ra những True Leader (được nuôi dưỡng và phát triển trong Scrum), và chính những Leader này có trách nhiệm tạo ra những vùng an toàn để những cá nhân khác, trong hoặc ngoài Scrum team, có tư duy mới có thể thử nghiệm và sáng tạo.

Thực tế cho thấy một tổ chức có thể học tập là một tổ chức bền vững, và có thể thích nghi với những biến động hoặc thay đổi. Scrum là một framework có thể giúp xây dựng một tổ chức học tập. Bản thân Scrum có những vòng lặp phản hồi (feedback loops) như:

Sprint Planning: Scrum team cùng nhau học cách đặt mục tiêu và lên kế hoạch cho Sprint tiếp theo, như: làm thế nào để đạt được Sprint goal với việc áp dụng AI.
Daily Scrum: Developer học cách để xem nên thay đổi gì, còn cần phải làm gì, làm như thế nào khi đang áp dụng AI vào trong công việc, để đạt được Sprint Goal.
Sprint Review: Scrum team và stakeholders cùng nhau tìm hiểu về mục tiêu và những gì team đã làm được khi áp dụng AI, cũng như những thay đổi từ thị trường để có chiến lược tốt hơn cho sản phẩm trong tương lai.
Sprint Retrospective: Là cơ hội tốt để cả team nhìn lại cách chúng ta làm việc cùng nhau như thế nào, với một yếu tố kèm theo là cách chúng ta làm việc với AI.
Sprint: khi Output đã được hỗ trợ rất nhiều từ Scrum khi áp dụng AI, thì mỗi Sprint là cơ hội vàng để Product Owner, kiểm chứng Outcome của sản phẩm, thu hẹp khoảng cách giữa output và outcome của sản phẩm, tránh cho việc quá nhiều output nhưng không có cái nào mang lại outcome.

Nếu team bạn đang áp dụng Scrum, và giờ đây là AI, tôi tin cơ hội thành công sẽ lớn hơn và gần hơn rất nhiều. Vì bên cạnh AI, bạn có một cách làm việc linh hoạt, học hỏi liên tục, môi trường an toàn cho những thử nghiệm và văn hóa chấp nhận cái mới. Chính những True leader trong Scrum team sẽ là những cá nhân để lan tỏa sự đổi mới, và giúp tổ chức có thể thích nghi nhanh, phát triển và tránh những cái bẫy của nghịch lý Solow. Nếu nói nghịch lý Solow là ở cấp vĩ mô, thì nó như một cái hồ nước đang biến đổi mạnh về môi trường sống, chính tổ chức của bạn là con cá đang sống trong sự biến đổi đó. Bạn không thể thoát khỏi hồ nước, nhưng bạn có thể học cách thích nghi với nó. Cùng một hồ nước, cùng một môi trường, cũng sẽ có những con cá lớn lên và những con cá không lớn lên. Bạn chọn trở thành con cá nào?

Link tham khảo:

Nghịch lý Solow: Robert Solow, “We’d Better Watch Out”, New York Times Book Review, 12/7/1987, tr. 36. Bản scan bài gốc: http://digamo.free.fr/solow87.pdf

Động cơ điện: Paul A. David, “The Dynamo and the Computer: An Historical Perspective on the Modern Productivity Paradox”, American Economic Review 80(2), 1990: https://ideas.repec.org/a/aea/aecrev/v80y1990i2p355-61.html

Trải nhựa lên lối mòn: Michael Hammer, “Reengineering Work: Don’t Automate, Obliterate”, HBR, tháng 7–8/1990: https://folk.idi.ntnu.no/thomasos/paper/hammer_reengineering.pdf

Scrum Guide 2020 (True Leader): https://scrumguides.org/scrum-guide.html

NUMMI