“You are a function of what the whole universe is doing in the same way that a wave is a function of what the whole ocean is doing.”
— Alan Watts
Tháng 12 năm 1984, một nhà máy ô tô ở Fremont, California mở cửa trở lại với đúng những công nhân mà một lãnh đạo công đoàn từng gọi là lực lượng lao động tệ nhất ngành ô tô Mỹ. Hơn 85% lứa công nhân đầu tiên là người GM đã sa thải hai năm trước. Vẫn những con người đó, nhưng cách làm việc thì khác: kiểm tra chất lượng gắn ngay vào dây chuyền, làm theo tổ, mỗi ngày cải tiến một chút, và có những tốp được gửi sang tận nhà máy Toyota bên Nhật để học. Ít lâu sau, Fremont chạy với tốc độ của một nhà máy Nhật và làm ra những chiếc xe được đánh giá ngang chất lượng xe sản xuất tại Nhật.
Câu chuyện này được kể đi kể lại trong các trường kinh doanh như một cái kết có hậu. Mới đây nó xuất hiện lần nữa trong bài viết “why AI transformation doesn’t work” của Mark Ajzenstadt, nhà sáng lập công ty kỹ thuật Limestone Digital, như một hình mẫu cho các doanh nghiệp đang loay hoay đưa AI vào vận hành.
Thú thật, mình đọc chuyện Fremont không dưới chục lần, và lần nào cũng gập sách ở đoạn “chất lượng ngang Nhật”. Lần này đọc tới đoạn cuối câu chuyện Fremont trong bài của Mark mới khựng lại: GM sau đó cố mang cách làm của Fremont sang các nhà máy khác, phần lớn không thành. Đến năm 1998, mười bốn năm sau, GM vẫn chưa áp dụng được sản xuất tinh gọn cho phần còn lại của hệ thống nhà máy tại Mỹ.
Mười bốn năm. Câu chuyện thành công nhất của GM thập niên 80 hóa ra là một trận thắng không lan ra được đến đâu.
Bản checklist gần như đúng
Đặt chuyện Fremont sang một bên một chút. Bài của Mark mở bằng hai con số mà ai làm chiến lược cũng nên dán lên bàn. Theo dự báo Gartner mà ông dẫn, chi tiêu AI toàn cầu năm nay chạm 2.700 tỷ USD, tăng 49,5% chỉ trong mười hai tháng. Một tháng sau, cũng Gartner, tại hội nghị CIO ở Orlando: chỉ 13% CIO nói công ty mình thu được giá trị đáng kể hoặc mang tính chuyển đổi từ AI. Xác suất một use case AI đơn lẻ thành công vẫn là một phần năm.
Chẩn đoán của Mark không mới nhưng sắc. Các chương trình chuyển đổi AI đang lặp lại đúng sai lầm của làn sóng ERP cuối thập niên 90: coi việc thay đổi cách con người làm việc như một bản nâng cấp phần mềm cắm vào là chạy. Hershey là ví dụ kinh điển: tháng 7 năm 1999, hãng bật hệ thống ERP 112 triệu USD đúng lúc đơn hàng Halloween bắt đầu đổ về, và khoảng 100 triệu USD kẹo nằm kẹt trong kho không giao đi được. Lợi nhuận quý ba giảm 19%, cổ phiếu rơi khoảng 8% trong một ngày.
Đơn thuốc của ông thì thực dụng tới mức khó cãi. Mỗi lần chỉ làm một quy trình trong một tháng, với một mốc đo ban đầu (baseline) mà cả hai bên ký trước khi ai bắt tay vào xây. Chạy được thì mở rộng, không được thì khách hàng bỏ đi, và nếu Limestone không giao được kết quả thì khách khỏi trả tiền. Use case phải lấy từ đầu người vận hành, những người làm việc đó hằng ngày, thay vì từ một bộ slide giá cả trăm nghìn đô của hãng tư vấn. Ông nói thẳng là đội kỹ sư của chính mình đã chống lại việc chuyển sang lập trình bằng agent suốt nhiều tháng. Gartner cũng chỉ ra rằng chỉ 17% CIO có quy tắc khai tử những dự án AI đang chạy mà không hiệu quả, và chỉ 4% có kế hoạch thiết kế lại vai trò cho người làm việc cùng agent. Nhóm thiểu số đó có khả năng lọt vào nhóm dẫn đầu, tức những công ty thu được giá trị thật từ AI, cao gấp 2,4 lần.
Mình đồng ý gần hết. Nếu phải đưa một danh sách kiểm tra cho ai đó sắp khởi động dự án AI đầu tiên, mình sẽ đưa bản này.
Vấn đề là cả bản checklist đặt cược vào một giả định ngầm: thắng nhỏ sẽ tự cộng dồn. Mark viết rằng khi một quy trình chạy tốt, người vận hành có lý do để tin thay đổi tiếp theo, và quy trình thứ hai sẽ nhanh hơn quy trình thứ nhất. Nghe rất hợp lý, cho đến khi bạn nhớ ra ví dụ đắt giá nhất trong chính bài viết của ông đã chứng minh điều ngược lại.
Mười sáu người được gửi đi
Năm 2010, chương trình This American Life dành hẳn một tập để hỏi đúng câu Mark bỏ ngỏ: vì sao GM không nhân bản được Fremont?
Câu trả lời đau hơn mình tưởng. GM không hề thờ ơ. Ngay từ đầu, ban lãnh đạo đã gửi mười sáu ngôi sao đang lên sang Fremont, với ý định rằng sau này họ sẽ quay về và thay đổi cả tập đoàn. Hai phóng viên báo Wall Street Journal về sau gọi họ là “biệt kích NUMMI” (NUMMI là tên liên doanh GM và Toyota ở Fremont). GM lập văn phòng liên lạc riêng, bay các quản lý sang tham quan, cho đứng dây chuyền vài ngày để học cách làm theo tổ. Họ có tiền, có người, có cả ý chí.
Nỗ lực nhân bản thật sự đầu tiên diễn ra ở nhà máy Van Nuys, cách Fremont vài trăm dặm về phía nam. Giám đốc nhà máy Ernie Schaefer mời đúng vị lãnh đạo công đoàn từng giúp Fremont thành công sang hỗ trợ. Kết quả thì khác hẳn. Nhà máy Van Nuys chưa từng bị đóng cửa, nên công nhân không tin lời dọa đóng cửa và nhìn hệ thống mới như một mối đe dọa. Các quản lý cũng không khá hơn: họ có đặc quyền cần bảo vệ, có thưởng tính theo số xe lăn bánh khỏi dây chuyền bất kể bao nhiêu lỗi. Khi được yêu cầu dùng chung nhà ăn và bãi đỗ xe với công nhân, họ dọa nghỉ việc tập thể. Mỗi lần Schaefer gọi về Detroit xin thiết kế lại một linh kiện lỗi, đầu dây bên kia hỏi ngược: nhà máy khác không cần sửa, sao nhà máy anh lại đặc biệt thế?
Chất lượng ở Van Nuys không cải thiện. Năm 1992, GM đóng cửa nhà máy, 2.600 người mất việc. Schaefer tổng kết một câu mà mình nghĩ nên in to treo trong mọi văn phòng chuyển đổi số: một nhà máy cô lập không thể tự làm được chuyện này.
Mình gọi hiện tượng này là bẫy ốc đảo pilot: dự án thí điểm thắng thật, đo được thật, người trong cuộc tin thật, nhưng tất cả sự cộng dồn chỉ diễn ra bên trong hàng rào. Ra khỏi hàng rào, nó gặp đúng những thứ đã giết Van Nuys: thưởng theo sản lượng, đặc quyền cần bảo vệ, và một trụ sở hỏi “sao anh đặc biệt thế”.
Giờ thay vài danh từ. Một đơn vị trong tập đoàn chạy pilot AI đối soát hóa đơn, rút từ ba ngày xuống vài giờ, demo cuối quý được vỗ tay rần rần. Mình từng ngồi trong mấy buổi demo kiểu này và thường là người vỗ to nhất phòng. Sáu tháng sau, đơn vị anh em được giao nhân rộng. Hệ thống ERP của họ khác, KPI của họ thưởng theo số chứng từ xử lý, trưởng phòng của họ nhìn cái agent như một dòng cắt giảm nhân sự sắp xuất hiện trong ngân sách năm sau. Và câu hỏi quen thuộc lại vang lên: bên đó làm được vì bên đó đặc thù thôi.
Chép được code, khó chép người
Phản biện mạnh nhất cho lập luận trên là: AI khác nhà máy ô tô. Fremont là một liên doanh tách biệt có ban điều hành riêng, thỏa thuận công đoàn riêng, Toyota giám sát riêng, nghĩa là bị cô lập có chủ đích. Còn pilot AI chạy ngay trong sơ đồ tổ chức của khách hàng, do chính người vận hành của khách hàng làm. Quan trọng hơn, phần mềm sao chép gần như miễn phí. Không ai phải xây thêm dây chuyền.
Mình chấp nhận phản biện này cho phần code, và bác bỏ nó cho phần công việc. Agent đối soát hóa đơn có thể triển khai sang đơn vị thứ hai trong một buổi chiều. Lòng tin của người vận hành, vai trò được thiết kế lại, quyền ra quyết định, cách tính thưởng thì không có nút sao chép. Con số 4% CIO có kế hoạch thiết kế lại vai trò nói lên đúng chuyện đó: gần như ai cũng mua được công cụ, rất ít người sửa được cái khung mà công cụ phải sống trong đó.
Còn một chi tiết nhỏ trong chuyện Van Nuys mà mình thấy rợn khi đặt cạnh năm 2026: quản lý được thưởng theo số xe lăn bánh, bất kể lỗi. Thay “số xe” bằng “số use case đã triển khai” là ra ngay bảng KPI của không ít văn phòng AI hiện nay. Nhà phân tích Alicia Mullery của Gartner nói trên sân khấu Orlando một câu gọn lỏn: số lượng không phải giá trị.
Bài học thứ tư của Mark cũng gợi ra một kịch bản mà chính ông chưa đi hết. Ông kể khi đội kỹ sư dùng AI xây nhanh hơn, nút thắt dời sang khâu viết yêu cầu, rồi sang kiểm thử. Nhưng nếu cách làm từng quy trình một thành công đủ nhiều, nút thắt sẽ còn leo cao hơn nữa: lên cơ cấu tổ chức, lên việc ai giữ P&L, đơn vị nào còn tồn tại, vai trò nào biến mất. Một nhà cung cấp làm hợp đồng theo tháng không có thẩm quyền chạm tới tầng đó. Con số 4% kia cho thấy phía khách hàng cũng gần như chưa ai nhận việc này.
Nếu phải nén lại, mình sẽ viết thế này:
Giá trị chuyển đổi = Pilot thành công × Tốc độ lan sang đơn vị thứ hai
Vế đầu bằng mười mà vế sau bằng không thì kết quả vẫn bằng không. Phép nhân đó gợi ra hai vòng lặp chạy ở hai tốc độ. Vòng nhanh chạy theo tháng, do người vận hành làm chủ, có mốc đo ban đầu và quy tắc khai tử, đúng như Mark mô tả. Vòng chậm chạy theo quý, do ban điều hành làm chủ, và được kích hoạt đúng vào lúc nút thắt leo ra khỏi tầng đội nhóm. Lúc đó, cách làm từng quy trình một đã hoàn thành nhiệm vụ của nó. Phần việc còn lại là tổ chức phải tự thiết kế lại mình.
Ai đo đường về nhà?
Công bằng với Mark, bài của ông là một bài chào hàng. Cuối bài có đường link đặt lịch gọi tư vấn, và chuyện đó hoàn toàn bình thường. Nhưng cũng vì vậy mà phải đọc kỹ cách ông dùng số liệu. Gartner dự báo đến năm 2028, 70% doanh nghiệp sẽ bỏ các hệ thống agent do kỹ sư của nhà cung cấp xây, vì chi phí phình to và không tự phát triển tiếp được. Khảo sát của Dataiku trên 685 CIO cho thấy 47% đã khai tử hơn 20 agent ngay trong năm nay. Mark dùng hai con số này để ủng hộ mô hình không ràng buộc của Limestone. Có điều chúng cũng khớp hoàn hảo với một cách đọc khác: agent đang bị thổi phồng, chấm hết. Cách đọc đó thì chẳng có lợi cho nhà cung cấp nào.
Và qua hơn 170 dự án, bài viết không có lấy một con số của chính Limestone: tỷ lệ pilot một tháng vượt mốc đo là bao nhiêu, bao nhiêu khách hàng đã bỏ đi, bao nhiêu khách hàng thật sự tự vận hành được 80% sau giai đoạn ba như ông mô tả. Khoảng trống này chưa chắc là gian dối, nhưng người mua nên biết đường mà hỏi. Nhà cung cấp nào công bố được mình đã tự tay khai tử bao nhiêu pilot mới là người đáng tin khi nói “không ràng buộc”.
Nếu chỉ được đề xuất một thước đo, mình chọn thời gian tới đơn vị thứ hai: mất bao lâu để một thay đổi đã được chứng minh ở đơn vị A chạy được ở đơn vị B, khi không còn đội gốc kè bên. Con số đó mà không ngắn lại sau mỗi vòng thì công ty đang xây thêm ốc đảo, chưa xây được năng lực. Mình đoán sẽ ít ai báo cáo con số này, vì nó phơi ra đúng chỗ đau.
Cú lật dễ thương nhất là Mark đã viết sẵn chương còn thiếu, chỉ là ở một bài khác. Tháng 9, ông lập luận rằng thứ khan hiếm trong cơn sốt kỹ sư triển khai tiền tuyến (forward deployed engineer) là văn hóa vận hành có khả năng sản xuất ra những kỹ sư đó từ những lập trình viên bình thường, chứ đi săn người giỏi sẵn thì không mở rộng được. Áp đúng lập luận đó vào bài này: lợi thế thật của Toyota là bộ máy quản trị có thể dựng thêm một Fremont nữa, rồi thêm một cái nữa.
Trong Odyssey của Homer, Odysseus mất hai mươi năm để về tới Ithaca, mười năm chiến tranh và mười năm lưu lạc. Về tới nơi, ông phải cải trang thành kẻ ăn mày ngay trong nhà mình, vì cung điện đã bị đám người cầu hôn chiếm chỗ, ngày ngày mổ gia súc, uống rượu của ông, và gần như không ai nhận ra người chủ đã trở về. Ông chỉ lấy lại được ngôi nhà khi giương nổi cây cung mà không kẻ cầu hôn nào kéo được.
Mười sáu biệt kích NUMMI về Detroit bằng máy bay, chỉ mất vài tiếng. Họ thay đổi thật, học được thật, rồi trở về một ngôi nhà đầy những người có chỗ đỗ xe riêng và thưởng tính theo số xe lăn bánh. Một quản lý đi tham quan Fremont về còn viết hẳn báo cáo, tóm gọn lại là: không hợp ở đây. Đội biệt kích không có cây cung.
Thử bấm giờ cho GM theo đúng thước đo ở trên xem. Fremont mở cửa cuối năm 1984, còn lần nhân bản nghiêm túc đầu tiên ở Van Nuys kết thúc năm 1992 với 2.600 người mất việc. Đến năm 1998 đồng hồ vẫn chạy, mười bốn năm chưa có điểm dừng. Nói vui thì GM lo đủ vé khứ hồi cho cả đội biệt kích, chỉ quên lo chuyện nhà cửa lúc họ về. Trước khi gửi đội pilot tiếp theo đi học, có hai câu đáng hỏi: mất bao nhiêu tháng để trận thắng đầu tiên chạy được ở phòng bên cạnh, và khi đội pilot về, cây cung đang nằm trong tay ai?