CHIA SẺ KIẾN THỨC

AI READINESS PART 5 TRIỂN KHAI LỚP AI TRONG DOANH NGHIỆP HIỆN HỮU: ĐỪNG BẮT ĐẦU TỪ NỀN TẢNG

Đăng vào bởi hgiahuy
AI READINESS PART 5
TRIỂN KHAI LỚP AI TRONG DOANH NGHIỆP HIỆN HỮU: ĐỪNG BẮT ĐẦU TỪ NỀN TẢNG
Một trong những câu hỏi xuất hiện sớm nhất khi doanh nghiệp bắt đầu tìm hiểu về AI thường là:
Nên chọn Azure, Google Cloud, một nền tảng AI đóng gói sẵn hay lấy mã nguồn mở trên GitHub về tùy biến?
Đây là một câu hỏi hợp lý.
Nhưng trong phần lớn trường hợp, nó được đặt ra quá sớm.
Trước khi chọn công nghệ, doanh nghiệp còn phải trả lời những câu hỏi nền tảng hơn:
Công việc thực tế đang được thực hiện như thế nào?
Quy trình nào đang tạo ra nhiều ma sát nhất?
Dữ liệu cần thiết đang nằm ở đâu?
Hệ thống nào là nguồn dữ liệu chính thức?
Những bước nào vẫn đang được nối với nhau bằng Excel, email hoặc thao tác thủ công?
AI nên hỗ trợ ở đâu?
Những đầu ra nào bắt buộc phải có con người kiểm tra?
Sau pilot, hệ thống hiện tại nên được giữ lại, tích hợp, hiện đại hóa hay thay thế?
Vì vậy, triển khai lớp AI trong một doanh nghiệp hiện hữu không nên bắt đầu bằng việc chọn nền tảng.
Nó nên bắt đầu bằng AI Readiness Assessment, bằng việc hiểu rõ cách tổ chức đang vận hành và bằng một kiến trúc đích được xác định rõ ràng.
DOANH NGHIỆP KHÔNG BẮT ĐẦU TỪ MỘT TỜ GIẤY TRẮNG
Về lý thuyết, triển khai AI thường được mô tả theo một chuỗi khá sạch:
Business → Process → Data → System → AI
Doanh nghiệp xác định bài toán kinh doanh, chuẩn hóa quy trình, tổ chức dữ liệu, xây dựng hệ thống rồi mới bổ sung AI.
Về mặt khái niệm, trình tự này là đúng.
Nhưng phần lớn doanh nghiệp không vận hành trong một môi trường được thiết kế mới hoàn toàn từ đầu.
Họ đã có sẵn:
Các hệ thống nghiệp vụ cốt lõi.
Nền tảng tài chính và kế toán.
Hệ thống quản lý văn bản.
Các phần mềm chuyên ngành.
Kho tài liệu dùng chung.
Excel, email và biểu mẫu kết nối các phần khác nhau của quy trình.
Những công việc vẫn phụ thuộc nhiều vào kinh nghiệm cá nhân.
Các hệ thống được xây dựng ở nhiều thế hệ công nghệ khác nhau và do nhiều đơn vị khác nhau quản lý.
Có hệ thống hiện đại.
Có hệ thống đã cũ nhưng chưa thể thay ngay.
Có hệ thống có API.
Có hệ thống gần như đóng hoàn toàn.
Có quy trình đã số hóa tương đối tốt, nhưng cũng có quy trình phải đi qua nhiều ứng dụng, vẫn phải xuất dữ liệu, nhập lại, tổng hợp thủ công và kiểm tra bằng con người.
Đây là môi trường brownfield: doanh nghiệp phải chuyển đổi trong khi hoạt động hiện tại vẫn phải tiếp tục vận hành.
Thách thức thực sự vì thế không phải là thiết kế một hệ thống AI lý tưởng rồi yêu cầu cả doanh nghiệp chuyển sang dùng nó.
Thách thức thực sự là:
Làm thế nào để đưa AI vào đúng những điểm có thể tạo ra giá trị, mà không làm gián đoạn hoạt động hiện tại hoặc tạo thêm một thế hệ công cụ phân mảnh mới?
AI READINESS PHẢI BẮT ĐẦU TỪ CÔNG VIỆC THỰC TẾ
Một sơ đồ quy trình chính thức thường mô tả công việc lẽ ra phải diễn ra như thế nào.
Nhưng để thiết kế một hệ thống có AI, doanh nghiệp phải hiểu công việc thực tế đang diễn ra như thế nào.
Doanh nghiệp cần làm rõ:
Đầu vào đến từ đâu?
Ai tiếp nhận?
Hệ thống nào ghi nhận dữ liệu?
Bước nào vẫn diễn ra qua email hoặc Excel?
Thông tin nào phải nhập nhiều lần?
Ai kiểm tra và phê duyệt?
Thiếu thông tin hoặc phát sinh ngoại lệ thì xử lý thế nào?
Báo cáo được tổng hợp ở đâu?
Hệ thống nào là system of record?
Hoạt động nào phụ thuộc vào một số ít người có nhiều kinh nghiệm?
Những khoảng trống nào hiện đang được vá bằng thao tác thủ công?
Những thông tin này không thể được thu thập đầy đủ chỉ bằng một bảng khảo sát.
Một AI Readiness Assessment nghiêm túc nên kết hợp:
Khảo sát baseline.
Phỏng vấn chuyên sâu.
Trao đổi với người trực tiếp thực hiện công việc.
Rà soát quy trình và biểu mẫu.
Rà soát dữ liệu, tài liệu và kho tri thức.
Rà soát hệ thống, phân quyền và khả năng tích hợp.
So sánh giữa quy trình chính thức và cách vận hành thực tế.
Đánh giá dựa trên bằng chứng thay vì chỉ dựa trên cảm nhận tự báo cáo.
Vì vậy, AI Readiness không phải là bài kiểm tra xem nhân viên sử dụng ChatGPT thành thạo đến đâu.
Đó là đánh giá xem tổ chức đã sẵn sàng đưa AI vào công việc thật, dữ liệu thật và hệ thống thật hay chưa.
ĐIỂM AI READINESS KHÔNG PHẢI ĐỂ XẾP HẠNG CÁC PHÒNG BAN
Sau khảo sát và phỏng vấn, doanh nghiệp có thể đánh giá mức độ sẵn sàng theo một số chiều như:
Business.
Process.
Data.
System.
Human and Change.
Governance.
Nhưng bản thân điểm số không phải là mục tiêu cuối cùng.
Một phòng ban có thể có pain point rất lớn nhưng dữ liệu chưa đủ sẵn sàng.
Một phòng ban khác có pain point nhỏ hơn, nhưng quy trình rõ hơn, dữ liệu đáng tin cậy hơn, hệ thống dễ kết nối hơn và người dùng cũng sẵn sàng tham gia hơn.
Vì vậy, AI Readiness Scorecard nên giúp doanh nghiệp trả lời các câu hỏi thực tế:
Quy trình nào đã đủ rõ để triển khai?
Nguồn dữ liệu nào đủ tin cậy?
Hệ thống nào có thể tích hợp?
Điểm bàn giao nào đang tạo ra nhiều công việc thủ công nhất?
Use case nào có thể tạo ra giá trị đo được?
Rủi ro nào phải xử lý trước?
Use case nào có thể đưa vào pilot ngay?
Use case nào cần cải thiện quy trình hoặc dữ liệu trước?
Use case nào chưa nên dùng AI?
Use case đầu tiên không cần phải là use case tham vọng nhất.
Nó nên nằm tại giao điểm của:
Giá trị kinh doanh × Tính khả thi × Mức độ sẵn sàng của dữ liệu × Rủi ro × Khả năng được chấp nhận
Một use case AI tốt phải giải quyết một vấn đề có thật, tạo ra giá trị có thể đo lường, khả thi về kỹ thuật và vận hành, có mức rủi ro chấp nhận được và có khả năng được người dùng sử dụng trong thực tế.
Mục đích của AI Readiness Scorecard không phải để kết luận phòng ban nào “tốt hơn” hay “kém hơn”.
Nó nhằm hỗ trợ một quyết định:
Cái gì nên làm trước, cần chuẩn bị gì và kiến trúc cần phát triển theo hướng nào?
ĐỪNG CHỌN NỀN TẢNG TRƯỚC RỒI ĐI TÌM BÀI TOÁN SAU
Một sai lầm phổ biến là bắt đầu bằng những câu hỏi như:
Nên dùng Azure hay Google Cloud?
Nên chọn mô hình nào?
Nên xây chatbot hay AI Agent?
Nên triển khai cloud, on-premises hay hybrid?
Có nên lấy mã nguồn mở về tùy biến?
Đây đều là những câu hỏi quan trọng.
Nhưng chúng chỉ nên được đặt ra sau khi doanh nghiệp đã hiểu:
Người dùng là ai?
Mỗi bộ phận thực sự cần gì?
Quy trình hiện tại đang vận hành ra sao?
AI sẽ tham gia ở bước nào?
Cần sử dụng những nguồn dữ liệu nào?
Cần kết nối với những hệ thống nào?
Phải hạn chế truy cập ra sao?
Điểm nào bắt buộc phải có con người kiểm tra?
Giá trị sẽ được đo bằng gì?
Điều gì xảy ra khi AI sai hoặc hệ thống gặp sự cố?
Khi doanh nghiệp thiết kế hệ thống trước khi hiểu những điều kiện này, họ thường tạo ra một giải pháp:
Chạy tốt khi demo.
Giao diện đẹp.
Trả lời nghe có vẻ thông minh.
Nhưng không bao giờ trở thành một phần của công việc hằng ngày.
AI Transformation không phải là đi tìm một bài toán phù hợp với nền tảng đã mua.
Công nghệ phải phục vụ bài toán kinh doanh, kiến trúc và roadmap chuyển đổi.
BROWNFIELD KHÔNG CÓ NGHĨA LÀ CHẤP NHẬN SỰ PHÂN MẢNH
Điểm phân biệt này rất quan trọng.
Doanh nghiệp có thể bắt đầu triển khai AI trước khi mọi hệ thống trở nên hoàn hảo.
Nhưng điều đó không có nghĩa là doanh nghiệp nên tiếp tục bổ sung chatbot, workflow, script và kho dữ liệu rời rạc mãi mãi.
Cách tiếp cận brownfield modernization của Microsoft không coi môi trường hiện tại là kiến trúc cuối cùng.
Nguyên tắc cốt lõi khá đơn giản:
Không làm gián đoạn những hệ thống vẫn đang phải vận hành, nhưng cũng không coi hiện trạng là đích đến.
Logic này có thể được áp dụng vào AI Transformation thông qua ba trạng thái kiến trúc.
1. CURRENT STATE ARCHITECTURE
Current State Architecture phải phản ánh trung thực:
Hiện nay đang có những hệ thống nào.
Quy trình đi qua các hệ thống đó như thế nào.
Dữ liệu chính thức được lưu ở đâu.
Ứng dụng nào là system of record.
Hoạt động nào vẫn làm thủ công.
Hệ thống nào có API.
Hệ thống nào khó hoặc gần như không thể thay đổi.
Ai đang kiểm soát từng hệ thống.
Có những ràng buộc nào về bảo mật, hạ tầng và vận hành.
Bản đồ hiện trạng không phải là một sơ đồ làm ra để trình bày cho đẹp.
Nó phải làm lộ ra:
Các bước bàn giao thủ công.
Việc nhập dữ liệu lặp lại.
Dữ liệu bị trùng.
Các file trung gian.
Quyền phê duyệt.
Các phụ thuộc ẩn.
Những cách nhân viên đang tự xoay xở để hoàn thành công việc.
Nếu không hiểu được những điều này, việc thiết kế hệ thống AI phần lớn chỉ là phỏng đoán.
2. TRANSITION ARCHITECTURE
Transition Architecture cho phép doanh nghiệp chạy pilot mà không làm gián đoạn hoạt động hiện tại.
Nó có thể bao gồm:
API gateway.
Adapter.
Workflow engine.
Data staging.
Nhập và xuất dữ liệu có kiểm soát.
RPA.
AI extraction.
Trợ lý tri thức.
Cơ chế human-in-the-loop.
Logging và monitoring.
Một giao diện mới đặt phía trước hệ thống legacy.
Một orchestration layer kết nối nhiều hệ thống.
Một cách tiếp cận brownfield thực tế là xây dựng nền tảng đích song song với môi trường hiện hữu, đánh giá khoảng cách rồi dịch chuyển workload hoặc capability theo từng giai đoạn.
Nguyên tắc này đặc biệt phù hợp với AI Transformation:
Không thay thế tất cả cùng một lúc.
Xây dựng một lớp chuyển tiếp.
Pilot trong phạm vi có kiểm soát.
Đo lường giá trị và rủi ro.
Sau đó mới mở rộng hiện đại hóa.
Nhưng cần phải làm rõ một điểm:
Transition Architecture là cơ chế để chuyển đổi, không phải giấy phép để duy trì một kiến trúc phân mảnh mãi mãi.
3. TARGET ARCHITECTURE
Target Architecture xác định trạng thái mà doanh nghiệp muốn hướng tới.
Nó không nhất thiết phải là một “siêu hệ thống” chứa mọi thứ.
Doanh nghiệp vẫn có thể sử dụng nhiều ứng dụng khác nhau, nhưng các ứng dụng đó phải vận hành như một phần của một kiến trúc thống nhất.
Một kiến trúc đích tốt phải làm rõ:
Hệ thống nào tiếp tục giữ vai trò lõi.
System of record của từng miền dữ liệu là gì.
Dữ liệu nào có thể được tái sử dụng giữa các bộ phận.
Năng lực nào cần được cung cấp qua API hoặc service.
Lớp tích hợp và workflow dùng chung.
Identity và access control.
Metadata, taxonomy và data ownership.
Logging, monitoring và audit.
Các yêu cầu phê duyệt bởi con người.
Model gateway và các AI service.
Cơ chế đánh giá chất lượng AI.
Quy trình quản lý sự cố.
Hệ thống nào sẽ được giữ lại, hiện đại hóa, thay thế hoặc loại bỏ.
Các use case AI không nên được xây dựng thành những hòn đảo độc lập.
Chúng nên tái sử dụng các năng lực dùng chung như:
Identity.
Data access.
API và dịch vụ tích hợp.
Retrieval service.
Model gateway.
Logging.
Evaluation.
Governance.
Metadata và taxonomy.
Nếu không, doanh nghiệp sẽ tạo thêm một thế hệ silo mới, chỉ khác là lần này các silo được gắn thêm AI.
PILOT NÊN GIẢI QUYẾT MỘT KHOẢNG TRỐNG TÍCH HỢP CÓ GIÁ TRỊ
Hãy xem một ví dụ chung.
Một doanh nghiệp đã có một hệ thống nghiệp vụ cốt lõi.
Hệ thống vẫn thực hiện tốt vai trò chính, nhưng các file đầu vào đến từ nhiều nguồn và theo nhiều định dạng khác nhau.
Nhân viên phải:
Mở từng tài liệu.
Đọc nội dung.
Trích xuất thông tin cần thiết.
Chuẩn hóa theo một biểu mẫu.
Xác định trường thông tin còn thiếu.
Nhập lại dữ liệu vào hệ thống lõi.
Kiểm tra và xử lý ngoại lệ.
Doanh nghiệp không nhất thiết phải xây lại toàn bộ hệ thống.
Một pilot AI có thể được đặt phía trước hệ thống:
File đầu vào
→ AI trích xuất
→ Chuẩn hóa về schema chung
→ Kiểm tra trường thiếu và ngoại lệ
→ Tạo bản ghi nháp
→ Con người xác nhận
→ Cập nhật vào hệ thống lõi
AI không thay thế hệ thống lõi.
Nó xử lý phần công việc thủ công nằm giữa dữ liệu đầu vào, nhân viên và ứng dụng hiện tại.
Nhưng pilot không nên chỉ được đánh giá bằng câu hỏi AI có đọc được file hay không.
Nó phải đo:
Thời gian xử lý trước và sau.
Độ chính xác khi trích xuất.
Số trường dữ liệu phải sửa.
Mức giảm lỗi nhập liệu.
Tỷ lệ hồ sơ phải làm lại.
Thời gian con người kiểm tra.
Chi phí trên mỗi hồ sơ.
Mức độ chấp nhận của người dùng.
Khả năng tích hợp.
Rủi ro về dữ liệu và bảo mật.
Khả năng mở rộng.
Trong giai đoạn đầu, giá trị AI không nên chỉ được đo bằng doanh thu trực tiếp.
Nó còn nên bao gồm:
Thời gian tiết kiệm.
Chất lượng được cải thiện.
Chi phí được giảm.
Rủi ro được giảm.
Năng lực tổ chức được nâng lên.
Một pilot không chỉ chứng minh AI có thể làm một công việc.
Nó còn cung cấp bằng chứng cho quyết định kiến trúc tiếp theo.
ANTI-CORRUPTION LAYER: KẾT NỐI NHƯNG KHÔNG ĐỂ HỆ THỐNG CŨ ĐỊNH HÌNH HỆ THỐNG MỚI
Khi kết nối một ứng dụng AI với hệ thống legacy, giải pháp mới không nên phụ thuộc trực tiếp vào toàn bộ cấu trúc dữ liệu, giao thức và giới hạn kỹ thuật của hệ thống cũ.
Anti-Corruption Layer đóng vai trò như một facade hoặc adapter giữa các hệ thống không dùng chung mô hình hoặc ngữ nghĩa.
Nó cho phép nền tảng legacy tiếp tục vận hành, đồng thời bảo vệ hệ thống mới khỏi việc bị thiết kế xoay quanh các giới hạn cũ.
Trong AI Transformation, lớp này có thể:
Ánh xạ dữ liệu legacy sang schema mới.
Chuyển đổi định dạng.
Thực thi quyền truy cập.
Loại bỏ dữ liệu AI không được phép sử dụng.
Chuẩn hóa yêu cầu gửi tới hệ thống lõi.
Giới hạn hành động AI được phép thực hiện.
Ghi log toàn bộ trao đổi.
Ngăn AI truy cập trực tiếp vào cơ sở dữ liệu lõi.
Đây là một pattern kiến trúc rất hữu ích.
Tuy nhiên, nó cũng tạo ra thêm một thành phần cần được vận hành, bảo trì, bảo mật và mở rộng.
Vì vậy, doanh nghiệp phải trả lời ngay từ đầu:
Lớp này mang tính chiến lược hay chỉ là tạm thời?
Ai sở hữu?
Ai duy trì?
Bao lâu rà soát một lần?
Có SLA hay không?
Business logic nào được phép đặt trong lớp này?
Khi nào lớp này nên được hấp thụ vào kiến trúc mới?
Trong điều kiện nào thì nên loại bỏ?
Nếu không có vòng đời rõ ràng, một thành phần chuyển tiếp rất dễ trở thành technical debt mới.
MỖI PILOT PHẢI DẪN ĐẾN MỘT QUYẾT ĐỊNH HIỆN ĐẠI HÓA
Pilot không phải là kiến trúc cuối cùng.
Khi đã có kết quả, doanh nghiệp phải quyết định điều gì sẽ xảy ra với hệ thống và capability liên quan.
Hướng dẫn application modernization của Microsoft sử dụng mô hình 6R để hỗ trợ quyết định ở cấp danh mục:
Rehost.
Replatform.
Refactor.
Rebuild.
Retire.
Retain.
Mỗi ứng dụng phải được đánh giá dựa trên giá trị kinh doanh, độ phức tạp, khả năng kỹ thuật và yêu cầu vận hành thay vì áp dụng một chiến lược duy nhất cho toàn bộ danh mục.
Khi áp dụng vào AI Transformation, các phương án có thể bao gồm:
RETAIN
Hệ thống lõi vẫn tiếp tục đáp ứng được yêu cầu chính.
AI đứng bên cạnh để hỗ trợ:
Tìm kiếm.
Trích xuất dữ liệu.
Báo cáo.
Phân tích.
Giảm công việc thủ công.
REPLATFORM
Chức năng chính của ứng dụng được giữ lại, nhưng môi trường vận hành hoặc nền tảng tích hợp được nâng cấp để cải thiện:
Khả năng mở rộng.
Bảo mật.
Monitoring.
Tính nhất quán khi triển khai.
Hiệu quả hạ tầng.
REFACTOR
Hệ thống hiện tại vẫn còn giá trị nhưng cần thay đổi cấu trúc, ví dụ:
Bổ sung API.
Tách module.
Bổ sung webhook hoặc event.
Chuẩn hóa dữ liệu.
Thay đổi workflow.
Cải thiện identity và access control.
REBUILD
Pilot chứng minh mô hình mới tạo ra giá trị, nhưng hệ thống legacy không thể đáp ứng yêu cầu dài hạn.
Khi đó, xây dựng một capability hoặc hệ thống mới là một quyết định hoàn toàn hợp lý.
RETIRE
Các file trung gian, script tạm thời, ứng dụng trùng lặp hoặc module lỗi thời được loại bỏ khi capability mới đã ổn định.
REHOST
Ứng dụng phần lớn được giữ nguyên nhưng được chuyển sang môi trường vận hành phù hợp hơn khi có business case rõ ràng.
Ngoài ra còn một phương án quan trọng khác.
STOP
Nếu giá trị không đủ lớn, dữ liệu không đáp ứng, người dùng không chấp nhận hoặc chi phí tích hợp quá cao, dừng use case là một kết quả hoàn toàn hợp lệ.
AI Transformation không có nghĩa là phải ép AI vào mọi quy trình.
KHI CẦN XÂY LẠI, HÃY THAY THẾ DẦN THAY VÌ BIG BANG
Khi hệ thống legacy không còn đáp ứng được yêu cầu tương lai, doanh nghiệp không nhất thiết phải thay thế tất cả trong một bước.
Strangler Fig Pattern cung cấp một cách tiếp cận hiện đại hóa theo từng giai đoạn.
Một facade được đặt giữa người dùng, hệ thống legacy và các service mới.
Ban đầu, phần lớn yêu cầu vẫn được chuyển tới hệ thống cũ.
Khi capability mới được xây dựng và ổn định, chức năng và lưu lượng dần được chuyển sang kiến trúc mới.
Khi chức năng cũ không còn cần thiết, nó có thể được loại bỏ.
Áp dụng vào AI Transformation:
1. Xây dựng một capability mới bên ngoài hệ thống legacy.
2. Dùng pilot để chứng minh giá trị.
3. Kết nối thông qua facade hoặc integration layer.
4. Chuyển một bước của quy trình sang capability mới.
5. Mở rộng sang người dùng hoặc chức năng khác.
6. Giảm dần sự phụ thuộc vào thành phần legacy.
7. Loại bỏ chức năng cũ khi capability mới đã ổn định.
Cách tiếp cận này ít rủi ro hơn đáng kể so với thay thế kiểu big bang.
MỌI KẾT NỐI TẠM THỜI ĐỀU PHẢI CÓ VÒNG ĐỜI
Trong giai đoạn chuyển tiếp, doanh nghiệp có thể cần sử dụng:
RPA.
File trung gian.
Quy trình import và export.
Adapter.
Script.
Workflow bán tự động.
Phê duyệt thủ công.
Data staging.
Những cơ chế này không phải lúc nào cũng xấu.
Một giải pháp tạm thời có thiết kế rõ ràng và có người chịu trách nhiệm hoàn toàn có thể là một phần hợp lệ của Transition Architecture.
Nhưng mỗi thành phần phải có:
Owner.
Mục đích rõ ràng.
Data schema.
Access control.
Logging.
Tài liệu vận hành.
SLA hoặc mức dịch vụ kỳ vọng.
Ngày rà soát.
Tiêu chí nâng cấp.
Tiêu chí thay thế.
Tiêu chí loại bỏ.
Vấn đề không nằm ở công nghệ tạm thời.
Vấn đề là:
Một giải pháp tạm thời không có thời hạn kết thúc và không đóng góp rõ ràng vào kiến trúc đích.
GOVERNANCE PHẢI ĐƯỢC THIẾT KẾ NGAY TRONG PILOT
Khi AI chỉ hỗ trợ soạn thảo, rủi ro chính thường là chất lượng đầu ra.
Nhưng khi AI bắt đầu kết nối với dữ liệu, workflow và hệ thống nghiệp vụ, rủi ro mở rộng sang:
Rò rỉ dữ liệu.
Truy cập trái phép.
Cập nhật sai vào hệ thống.
Thực hiện hành động ngoài phạm vi được phê duyệt.
Thiếu lịch sử thay đổi.
Không rõ trách nhiệm.
Lưu trữ credential không an toàn.
Shadow AI và shadow integration.
Vì vậy, mỗi pilot tối thiểu phải xác định:
AI được phép sử dụng dữ liệu nào.
Nguồn nào là nguồn chính thức.
Ai được phép truy cập giải pháp.
AI chỉ được đọc hay được phép ghi.
Hành động nào cần phê duyệt.
Có audit trail đầy đủ hay không.
Ai sở hữu business use case.
Ai sở hữu quy trình.
Ai sở hữu dữ liệu.
Ai vận hành AI workflow.
Cơ chế fallback là gì khi AI hoặc kết nối gặp lỗi.
Governance không phải là một lớp được bổ sung sau khi pilot hoàn thành.
Nó phải được nhúng vào workflow ngay từ đầu.
LỰA CHỌN CÔNG NGHỆ PHẢI ĐẾN SAU ĐÁNH GIÁ VÀ KIẾN TRÚC
Doanh nghiệp chỉ thực sự sẵn sàng lựa chọn công nghệ sau khi đã có:
Kết quả phỏng vấn chuyên sâu.
AI Readiness Scorecard.
Current State Map.
Pain Point Map.
Integration Gap Map.
AI Opportunity Backlog.
Danh sách use case ưu tiên.
Pilot Blueprint.
Transition Architecture.
Target Architecture.
Modernization Roadmap.
Chỉ khi đó doanh nghiệp mới có đủ cơ sở để lựa chọn giữa:
Azure.
Google Cloud và Vertex AI.
Hạ tầng nội bộ.
Private cloud.
Kiến trúc hybrid.
Các thành phần mã nguồn mở.
Hoặc kết hợp nhiều phương án.
Azure Landing Zone cung cấp một cấu trúc chuẩn hóa để quản trị, bảo mật và vận hành môi trường Azure.
Nó phù hợp khi Azure đã được lựa chọn là nền tảng cloud chiến lược của doanh nghiệp.
Nó không thay thế được việc chẩn đoán bài toán kinh doanh hoặc thiết kế AI use case.
Mã nguồn mở có thể rất hữu ích cho:
Prototyping.
Thử nghiệm RAG.
Xử lý tài liệu.
Phát triển connector.
Kiểm chứng workflow.
Đẩy nhanh việc xây dựng một capability.
Nhưng repository mã nguồn mở chỉ cung cấp các building block.
Một repository trên GitHub không nên được coi là kiến trúc đích của doanh nghiệp.
Công nghệ phải phục vụ kiến trúc.
Công nghệ không nên quyết định kiến trúc.
AI READINESS PHẢI TẠO RA TECHNOLOGY ROADMAP
Một chương trình AI Readiness tốt không nên kết thúc bằng một điểm số trưởng thành.
Nó phải tạo ra các đầu ra cần thiết để triển khai.
CURRENT STATE MAP
Bản mô tả quy trình, hệ thống, dữ liệu, người dùng và các điểm bàn giao hiện tại.
AI READINESS SCORECARD
Đánh giá mức độ sẵn sàng hiện tại dựa trên bằng chứng và những năng lực cần cải thiện.
PAIN POINT AND INTEGRATION GAP MAP
Bản đồ các điểm nhập liệu lặp lại, tổng hợp thủ công và ma sát giữa các hệ thống.
AI OPPORTUNITY BACKLOG
Danh mục use case được đánh giá theo giá trị, tính khả thi, mức độ sẵn sàng của dữ liệu, rủi ro và khả năng được chấp nhận.
PRIORITIZED PILOT SCOPE
Một use case đủ nhỏ để kiểm soát nhưng đủ thật để tạo ra bằng chứng có ý nghĩa.
PILOT BLUEPRINT
Mô tả workflow tương lai, yêu cầu dữ liệu, thành phần hệ thống, vai trò, kiểm soát và KPI.
TRANSITION ARCHITECTURE
Các API, adapter, workflow, staging area, AI service và phê duyệt của con người cần thiết trong giai đoạn chuyển tiếp.
TARGET ARCHITECTURE
Kiến trúc mà doanh nghiệp muốn hướng tới.
MODERNIZATION ROADMAP
Kế hoạch xác định hệ thống và capability nào sẽ được:
Giữ lại.
Tích hợp.
Mở qua API.
Refactor.
Replatform.
Rebuild.
Retire.
AI OPERATING MODEL
Làm rõ:
Ai chịu trách nhiệm lãnh đạo.
Ai sở hữu kết quả kinh doanh.
Ai sở hữu quy trình.
Ai sở hữu dữ liệu.
Ai vận hành giải pháp.
Ai phê duyệt đầu ra.
Ai quyết định scale, pivot hoặc stop.
Một đánh giá chỉ tạo ra điểm số nhưng không dẫn đến quyết định tiếp theo thì có giá trị rất hạn chế.
KẾT LUẬN
AI không được triển khai trong một tổ chức hoàn hảo.
Nó thường được đưa vào một môi trường nơi cùng lúc tồn tại:
Hệ thống legacy.
Hệ thống mới.
Dữ liệu phân mảnh.
Quy trình thiếu nhất quán.
Các bước bàn giao thủ công.
Những ràng buộc chưa thể xử lý ngay.
Nhưng thực tế đó không phải là lý do để tạo thêm một thế hệ công cụ rời rạc mới mang nhãn AI.
Một cách tiếp cận thực tế là:
Phỏng vấn chuyên sâu để hiểu công việc thật.
Đánh giá AI Readiness dựa trên bằng chứng.
Ưu tiên use case theo nhu cầu thực tế.
Thiết kế Current, Transition và Target Architecture.
Chạy pilot trong phạm vi có kiểm soát.
Đo giá trị, mức độ chấp nhận và rủi ro.
Sau đó quyết định tích hợp, hiện đại hóa, xây lại hay dừng.
Nguyên tắc brownfield cần được ghi nhớ:
Không làm gián đoạn những hệ thống vẫn phải tiếp tục vận hành, nhưng cũng không được nhầm hiện trạng với đích đến.
Brownfield không có nghĩa là chấp nhận một kiến trúc phân mảnh vĩnh viễn.
Đó là một con đường có kỷ luật để đi từ môi trường hiện tại tới một kiến trúc tốt hơn, trong khi vẫn duy trì liên tục hoạt động kinh doanh.
Vì vậy:
Doanh nghiệp không cần chờ đến khi mọi hệ thống hoàn hảo mới triển khai AI. Nhưng mỗi pilot phải nằm trong một technology roadmap rõ ràng và phải đóng góp vào kiến trúc đích.
AI Readiness không chỉ nên cho doanh nghiệp biết mình đang đứng ở đâu.
Nó phải giúp doanh nghiệp quyết định:
Nên làm gì trước, đưa AI vào đâu, hệ thống cần phát triển như thế nào và tổ chức sẽ đi từ môi trường hiện tại tới kiến trúc đích ra sao.