Thủ thuật
Ben Evans: Tại sao AI không phải là 'viên đạn bạc' cho chuyển đổi số doanh nghiệp?
(giờ Việt Nam)
Tóm tắt AI
Ben Evans lập luận rằng AI không tự động giải quyết được các tác vụ lặp lại như kỳ vọng, bởi thách thức thực sự nằm ở việc xác định vấn đề và quy trình thay vì chỉ là công cụ. AI chỉ tạo ra các lựa chọn mới chứ không thay đổi bản chất cốt lõi của quản trị doanh nghiệp.
Bản dịch AI
Một công ty lớn điển hình tại Mỹ ngày nay sở hữu hàng trăm, thậm chí hàng nghìn phần mềm khác nhau. Họ có những hệ thống ghi chép khổng lồ, mang tính nền tảng như SAP và Workday, hàng trăm ứng dụng SaaS theo chiều dọc, và sau đó là hàng trăm quy trình làm việc, tập lệnh (script), công cụ tự động hóa và cơ sở dữ liệu khác, kéo dài xuống tận những bảng tính 10MB đang vận hành một phòng ban. Rất thường xuyên, chính công ty đó còn không biết rõ mình đang sở hữu bao nhiêu phần mềm, cái nào thực sự đang được sử dụng và họ đang phải chi trả cho những gì. Thế nhưng, với tất cả số phần mềm đó, công ty vẫn đầy rẫy những công việc nhàm chán và lặp đi lặp lại.
Rất dễ để nghĩ rằng AI sẽ quét sạch phần lớn những thứ này. Có một câu đùa cũ rằng kỹ sư là người sẵn sàng dành một giờ để xây dựng công cụ tự động hóa một tác vụ chỉ mất 10 phút để thực hiện. Nhưng với AI, giờ đây bạn có thể tạo ra công cụ đó trong 5 phút, không cần phải là kỹ sư và cũng chẳng cần viết mã. Bạn chỉ cần yêu cầu mô hình tạo công cụ đó cho mình, hoặc cơ bản hơn là để chính nó thực hiện tác vụ đó. Thay vì phải tạo từng công cụ một, phần mềm có thể trở nên linh hoạt, mang tính tạo sinh, tự do và ngẫu hứng. Nhiều tác vụ hơn nữa có thể được tự động hóa với lượng phần mềm ít hơn đáng kể.
Nếu bạn là người xây dựng công cụ – và tất cả mọi người ở Thung lũng Silicon đều là người xây dựng công cụ – thì điều này thật say đắm. Nhưng tôi nghĩ rằng quan điểm này hiểu sai về nguồn gốc của phần mềm cũng như cách mọi người sử dụng nó, và tôi nghĩ nó bỏ lỡ cách các công ty thay đổi.
Trước hết, hầu hết mọi người không phải là người xây dựng công cụ, và họ không có bản năng suy nghĩ về việc công việc của mình có thể được thực hiện theo cách khác như thế nào. Nếu bạn dành toàn bộ thời gian trong "bong bóng" Thung lũng Silicon, bạn rất dễ quên điều này, vì cả thế giới của bạn xoay quanh việc tạo ra các công cụ thay đổi cách mọi thứ được thực hiện. Nhưng nếu bạn là một luật sư hôn nhân gia đình thực sự giỏi, bạn dành cả ngày để suy nghĩ về các vụ kiện và khách hàng của mình, chứ không phải về việc phần mềm khám phá pháp lý tuyệt vời nào đó sẽ làm gì; nếu bạn là một nhân viên kinh doanh doanh nghiệp xuất sắc, bạn dành toàn bộ thời gian để nghĩ về sản phẩm, khách hàng và đối thủ cạnh tranh, chứ không phải về việc phần mềm hỗ trợ bán hàng tuyệt vời nào đó có thể giúp bạn làm việc hiệu quả hơn ra sao.
Các sản phẩm như Excel cố gắng giải quyết vấn đề này bằng các luồng hướng dẫn (on-boarding flows), trợ lý và mẫu có sẵn - mọi thứ bạn thấy trong mục ‘File/New’ đều là gợi ý về những gì bạn có thể làm với nó. Nhưng mỗi mẫu đó vẫn trở thành một công ty, và đó cũng là điều tôi thấy ở những thứ như Claude for X - điều này hữu ích, nhưng không phải là câu trả lời.
Xét một cách hẹp, điều đó có nghĩa là tác vụ cần tự động hóa có thể đang nằm ngay trước mắt nhưng những người thực hiện tác vụ đó lại không nhìn thấy. Đây là điều dẫn đến ý tưởng về "kỹ sư triển khai tiền phương" (forward-deployed engineer) - một người là nhà xây dựng, biết AI có thể tạo ra những gì, có thể "chỉ đơn giản" đi dạo quanh một công ty luật hoặc văn phòng kiến trúc và nhìn thấy những cơ hội đang nằm trên bàn mà luật sư hay kiến trúc sư không thấy. (Đây cũng là trải nghiệm của rất nhiều người trong ngành công nghệ khi họ 15 tuổi, đi loanh quanh trong kỳ thực tập hoặc văn phòng của cha mẹ mình - "Ơ, bố ơi, bố có nhận ra là bố có thể làm như thế này không?").
Vấn đề sâu xa hơn là phần lớn những gì chúng ta đã tự động hóa trong vài thập kỷ qua không hề hiển nhiên, ngay cả khi bạn là người xây dựng công cụ, và cũng không có giải pháp rõ ràng. Tất cả chúng ta đều có thể nghĩ ra những ví dụ về những thứ chúng ta sử dụng hàng ngày mà phản ứng đầu tiên là "Tại sao tôi lại muốn thứ đó?". Rất thường xuyên, vấn đề không hiển nhiên là nó tồn tại, và rất thường xuyên nó bị nhúng, bị gộp hoặc ẩn bên trong một thứ khác. Tương tự, ngay cả khi bạn có thể nhìn thấy vấn đề, hoặc nghĩ rằng mình có thể, thì cách đúng đắn để khắc phục nó thường cũng không rõ ràng, và cách để sửa nó là định nghĩa lại hoặc tách nhỏ nó ra, và việc tìm ra điều đó rất khó khăn. Đối với nhiều công ty phần mềm thành công, đã có hàng nửa tá nỗ lực thất bại trước đó vì không tìm ra cách tiếp cận đúng hoặc vấn đề đúng.
Không điều nào trong số này được giải quyết bằng việc làm cho việc viết mã trở nên dễ dàng hơn – bằng cách làm cho việc tạo công cụ trở nên dễ dàng hơn. Phần khó nhất là biết rằng ngay từ đầu bạn cần một công cụ cho việc này, và sau đó biết công cụ đó nên làm gì.
Nhưng ngay cả khi bạn đạt đến điểm đó, bạn vẫn phải khiến những người khác sử dụng nó. Nhiều vấn đề, quy trình làm việc và tác vụ mà chúng ta muốn tự động hóa liên quan đến 50 hoặc 500 người trên năm phòng ban khác nhau, ba hệ thống ghi chép khác nhau và bốn chế độ quản lý khác nhau. Bạn có thể có một ý tưởng tuyệt vời để thực hiện quy trình thanh toán cho nhà cung cấp theo cách khác, nhưng bản thân bạn không thể thay đổi cách mọi người trong công ty làm việc đó. Đó phải là một khoản mua sắm, một quyết định và một quy trình bán hàng kéo dài 18 tháng.
Thứ hai, tất cả những điều này có nghĩa là phần mềm được mua, lựa chọn hoặc tạo ra trên một phổ từ trên xuống dưới (top-down) đến dưới lên trên (bottom-up) - công ty mua SAP và người dùng tạo bảng tính - và tôi nghĩ cũng rất hữu ích khi coi đây là một phổ từ thể chế hóa (institutionalized) đến ngẫu hứng (improvised).
Bạn có những tác vụ dễ thực hiện trong các công cụ chuyên dụng mà bạn đã có, cho dù đó là SAP, Carta hay Rippling. Những tác vụ và quy trình làm việc này đã được thể chế hóa - một nhóm người trong các công ty đó và công ty của bạn đã dành rất nhiều thời gian để tìm ra cách đúng đắn để thực hiện tác vụ đó, và điều quan trọng là mọi người đều thực hiện theo cùng một cách với cùng một công cụ. Nhưng sau đó bạn có những trường hợp ngoại lệ, các câu hỏi phát sinh một lần, vốn khó hoặc không thể thực hiện trong các công cụ đó. Người dùng của bạn, theo cách dưới lên trên và tự tạo giải pháp riêng, quản lý những thứ này trong một không gian mờ nhạt, ngẫu hứng của các nền tảng tự do như Excel, email, thư mục chia sẻ, Tableau, Powerpoint và CSV, ảnh chụp màn hình, PDF và các cuộc gọi hội nghị.
Nhưng một khi tác vụ này trở thành việc bạn làm thường xuyên, theo cùng một cách mỗi lần, và nhiều người đang làm, trở nên quan trọng và gắn liền với doanh thu cũng như rủi ro, thì tại một thời điểm nhất định, công ty phải thể chế hóa nó. Bạn cần kiểm toán, bảo mật, bảo trì và trách nhiệm giải trình. Bạn trải nhựa con đường mòn và trả tiền cho ai đó để biến nó thành quy chuẩn. Như đã nói ở trên, bạn có thể không nhận ra con đường đó tồn tại - bạn có thể không nhận ra rằng mình có hàng trăm người đang lãng phí một giờ mỗi ngày để làm việc này - và có thể rất khó để tìm ra cách khắc phục đúng, nhưng quy trình đó chính là lý do tại sao công ty có hàng trăm ứng dụng.
Chúng ta đã trải qua rất nhiều điều này với sự chuyển dịch sang SaaS, một sự thay đổi theo cấp số nhân về lượng phần mềm chúng ta có, cùng với một mô hình vận hành mới và chu kỳ thời gian mới, và điều đó đã tiêu diệt rất nhiều công ty đương nhiệm không thể thực hiện bước nhảy vọt (lý do thực sự cho "SaaSpocalypse"). Đó là một dòng chảy liên tục và hữu cơ của việc gộp lại và tách ra. Tất cả các ứng dụng SaaS đó đều làm những việc mà bạn có thể làm trong SAP, Excel hoặc email - Carta là một công ty trị giá 4 tỷ USD quản lý một bảng tính cho CFO của bạn - và đôi khi các tác vụ lại quay trở lại. Vài năm trước, tôi đã nói chuyện với một nhà tư vấn, người nói rằng một nửa công việc của họ là bảo những người dùng Excel hãy sử dụng cơ sở dữ liệu và nửa còn lại thì ngược lại.
Do đó, nếu bạn là PwC và bạn tuyển dụng 3.000-4.000 sinh viên tốt nghiệp mỗi năm, bạn sử dụng phần mềm chuyên dụng, "đã được thể chế hóa" để quản lý việc đó. Nếu bạn là một công ty nhỏ và bạn tuyển năm hoặc mười người, bạn sử dụng email, thư mục chia sẻ và Google Sheets. Khi công ty nhỏ đó phát triển, đến một thời điểm nhất định, nó sẽ vượt quá khả năng của những công cụ đó và có thể chuyển sang Notion, hoặc một SaaS HCM tập trung vào SME. Nhưng một nhóm nhỏ bên trong PwC cũng có thể đang sử dụng Google Sheets để theo dõi ứng viên cho một vị trí vì Workday quá thiếu linh hoạt - quá trình tách nhỏ lại bắt đầu.
Bây giờ AI lan tỏa trên tất cả những thứ đó. AI sẽ mở rộng tất cả các ứng dụng hiện có, và sẽ có nhiều ứng dụng theo chiều dọc mới, còn Excel, Tableau, Google Sheets, email và tất cả các không gian tự do khác để tạo giải pháp ngẫu hứng sẽ có thêm các khả năng mới. Với chu kỳ đó, bản thân chatbot là một không gian tự do mới nằm cạnh Excel và email, tiếp quản các tác vụ từ chúng và từ các ứng dụng của bạn, đồng thời cũng mất các tác vụ vào tay các ứng dụng đó.
Giờ đây, công ty nhỏ tuyển mười sinh viên tốt nghiệp đó có thể gắn bó với Google Sheets lâu hơn nhiều vì AI làm cho nó có khả năng mở rộng hơn, hoặc bạn có thể sử dụng nó làm kho dữ liệu cho Gemini, và bạn có thể tự hỏi "chúng ta có nên nhờ Claude làm thứ gì đó hay chuyển cái này sang Notion không?"... và rồi bạn thấy có một ứng dụng SaaS mới nhắm thẳng vào bạn, giải quyết vấn đề này cộng với một số vấn đề khác mà bạn chưa từng nghĩ tới. AI không thay đổi câu hỏi: nó tạo ra những lựa chọn mới và dịch chuyển các ngưỡng.
Tôi nghĩ bạn có thể thấy tất cả những điều này trong trải nghiệm triển khai AI doanh nghiệp trong ba năm qua. Mỗi công ty lớn đều cung cấp cho mọi người Copilot (hoặc có thể là ChatGPT hoặc Claude) và một số ít người đang sử dụng nó rất nhiều (một số người trong đó thực sự đã tăng năng suất), trong khi một nhóm lớn hơn đang sử dụng nó vài lần một tuần và phần còn lại của công ty bạn thực sự không sử dụng nó chút nào. Đây một phần là vấn đề quản lý thay đổi và đào tạo, nhưng phần lớn là cùng một vấn đề mà bạn sẽ gặp phải nếu bạn đưa cho mọi người trong công ty một chiếc PC và Lotus 123 vào năm 1983, hoặc một kết nối internet và trình duyệt web vào năm 1997. Chính xác thì điều này liên quan thế nào đến tác vụ của mọi người và những vấn đề họ thực sự gặp phải trong tuần này? Đúng, bạn đã đưa cho mọi người một chiếc PC và Lotus, nhưng đó không phải là cách bạn chuyển đổi hiệu quả xử lý hóa đơn của mình. Đúng, bạn đã đưa cho mọi người một trình duyệt web, nhưng đó không phải là cách bạn xây dựng lại quản lý chuỗi cung ứng xung quanh internet, và chắc chắn đó không phải là cách một nhà bán lẻ quản lý thương mại điện tử.
Xét một cách hẹp, cách các công ty nghĩ về việc thay đổi các quy trình cấu trúc đó là bắt đầu thực hiện các dự án thí điểm. Bạn chạy thử nghiệm các sản phẩm (cả mua và tự xây dựng nội bộ) sử dụng các khả năng mới của AI để tự động hóa các quy trình mà trước đây bạn không thể tự động hóa. Hiện nay có đủ loại dữ liệu về số lượng các dự án thí điểm này, bao nhiêu dự án thành công (khoảng một nửa, như bình thường - đây là lý do tại sao chúng là thí điểm!) và những gì có thể sai sót.
Nhưng một lần nữa, đây là cuộc trò chuyện rất lỗi thời của CIO về các trường hợp sử dụng, các dự án tiêu biểu, thí điểm, những người hùng, chiến thắng nhanh chóng và kết quả có thể đo lường được. Trong khi đó, CEO và hội đồng quản trị gãi đầu và nói: "Khoan đã, chúng ta có hàng trăm quy trình làm việc và chúng ta đã thực hiện 5 hoặc 10 dự án thí điểm. Điều đó có vẻ không mở rộng được?". Việc đưa cho mọi người trong công ty ChatGPT về mặt lý thuyết là có thể mở rộng, ngoại trừ việc hầu hết mọi người không thực sự tìm ra cách để sử dụng nó.
Quay lại ví dụ giả định về một ngân hàng đưa cho mọi người bảng tính vào những năm 1980, hoặc một nhà bán lẻ đưa cho mọi người trình duyệt web vào những năm 1990, vâng, tất nhiên bạn nên làm điều đó, và vâng, tất nhiên, bạn cần suy nghĩ về đào tạo, quản lý thay đổi và tất cả những thứ tốt đẹp khác mà KPMG có thể nói với bạn. Nhưng đó không phải là cách bạn nghĩ về việc chuyển đổi cách công ty của bạn vận hành xung quanh một công nghệ thế hệ mới.
Nhìn lại, đối với tôi, với mỗi công nghệ mang tính chuyển đổi mới, mọi công ty đều phải đặt ra ba loại câu hỏi. Thứ nhất, làm thế nào để chúng ta mua, xây dựng và triển khai công nghệ này? Chúng ta có thực hiện thí điểm không? Chúng ta nên lấy sản phẩm được đóng gói từ Microsoft/Google/Oracle, tự xây dựng thứ gì đó, trả tiền cho ai đó để xây dựng, hay mua thứ mới này từ một startup? Thứ hai, họ phải tự hỏi điều này thay đổi hoạt động của họ đến mức nào. Nó có ý nghĩa gì? Email có ý nghĩa gì với chúng ta? Bảng tính có ý nghĩa gì với chúng ta? Câu trả lời cho điều đó có thể hoàn toàn khác nếu bạn là một công ty bảo hiểm hoặc một công ty luật. Và thứ ba, bạn phải tự hỏi liệu điều này có tạo ra những thách thức mới cho nền kinh tế của doanh nghiệp bạn, những áp lực cạnh tranh mới, hay có lẽ là một loại mối đe dọa hiện hữu nào đó hay không.
Bạn không trả lời những câu hỏi đó bằng cách đưa cho mọi người Claude for X. Thật vậy, tất cả những điều này có nghĩa là rất nhiều lời chào hàng mới cho các dịch vụ chuyên nghiệp (điều này thật trớ trêu khi xét đến việc AI đặt ra bao nhiêu câu hỏi cho chính mô hình kinh doanh của họ). Bạn có muốn tìm cách triển khai công cụ phân tích giọng nói hỗ trợ LLM trong trung tâm cuộc gọi của mình không? Bạn có thể sẽ gọi cho Accenture. Bản thân các nhà cung cấp luôn sẵn lòng giúp đỡ, và giờ đây các phòng thí nghiệm lớn có các "công ty triển khai" (deploycos) của riêng họ - chúng ta từng nói đùa rằng một "nhà khoa học máy học" là một nhà thống kê sống ở San Francisco, vì vậy có lẽ một "kỹ sư triển khai tiền phương" là bất kỳ ai mà OpenAI thuê từ một nhà tích hợp hệ thống. Ở phía bên kia, startup của bạn đang xây dựng một công cụ mới tuyệt vời và bạn muốn đưa ra thị trường nhanh chóng? Bạn có thể sẽ gọi cho Big Four. Bạn thất vọng vì việc bán phần mềm AI vào các công ty luật hoặc công ty kế toán khó khăn như thế nào. Được thôi - hãy bắt đầu một công ty luật "hỗ trợ bởi AI" và tìm hiểu xem đó có thể là điểm đòn bẩy chính hay không (hoặc liệu nó có giống như việc bắt đầu một "công ty luật hỗ trợ bởi PC" vào những năm 1980 hay không). Và tất nhiên, nếu bạn là hội đồng quản trị, và bạn đang cố gắng tìm hiểu xem đây là một loại mối đe dọa hiện hữu hay một cơ hội doanh thu khổng lồ, thì bạn sẽ nghĩ đến việc gọi cho Bain, BCG và McKinsey (hoặc ngân hàng M&A thân thiết của bạn) - đây là những gì họ làm.
Tuy nhiên, nhìn lại tất cả những điều này, cũng có một cách đơn giản hơn nhiều để suy nghĩ về câu hỏi đó. Với mỗi công nghệ mới, chúng ta bắt đầu bằng việc sử dụng nó cho công việc chúng ta đã có, và chúng ta chỉ làm điều đó nhiều hơn và nhanh hơn. Nhưng sau đó, theo thời gian, bạn tạo ra những thứ hoàn toàn mới. Chúng ta sẽ sử dụng AI để tự động hóa các lớp công việc rộng lớn bên trong các quy trình làm việc hiện có và các công ty hiện có (mặc dù, như tôi đã nêu ở trên, điều đó sẽ gây ra nhiều rắc rối và công việc hơn nhiều so với việc chỉ đưa cho mọi người một mô hình). Nhưng với mỗi sự thay đổi nền tảng trước đây, những thứ thực sự quan trọng là những thứ thậm chí còn không thể thực hiện được trước đó và không ai từng tưởng tượng ra.
Bài viết được AI dịch và tổng hợp tự động từ Hacker News Nổi bật (buzzing.cc bản dịch tiếng Trung). Liên kết bài gốc ở phía trên. Dữ liệu đồng bộ qua API công khai được ghi nguồn tại AI HOT (canonical) ↗. AIHOT.vn luôn dẫn nguồn đầy đủ — nếu bạn thấy điểm cần chỉnh sửa, hãy gửi ý kiến tại trang phản hồi.