Mở đầu

Trong phần 1 và phần 2, chúng ta đã thấy EUC và “God Excel” có thể giúp hiện trường trong ngắn hạn nhưng để lại di sản tiêu cực cho tổ chức về lâu dài. Bài viết này chuyển góc nhìn về hiện tại, xem xét những điểm sáng và mặt tối của các nền tảng phát triển công dân hiện đại như RPA và no-code/low-code.

Chúng vừa tái hiện God Excel, vừa tiềm ẩn rủi ro lớn hơn về quy mô và mức độ phụ thuộc. Để chuẩn bị bàn về tác động của AI tạo sinh trong phần tiếp theo, chúng ta cần hiểu đúng bản chất của chúng.

Toàn bộ chuỗi

Điểm sáng — vì sao được đón nhận

Hiệu quả tức thời

Không cần viết mã vẫn có thể nhanh chóng tạo ra các tự động hóa hay ứng dụng đơn giản thông qua thao tác GUI. Chỉ mất vài ngày để thay thế các công việc nhập liệu hàng ngày hoặc quy trình chuẩn hóa là lợi ích rất lớn cho tuyến đầu.

Sức thuyết phục của khả năng hiển thị

Vì có thể mô tả luồng xử lý hay giao diện bằng trực quan, những người không chuyên môn cũng dễ hiểu. Với lãnh đạo, việc nhìn thấy “bản vẽ biết chạy” tạo cảm giác an tâm mạnh mẽ và thường trở thành yếu tố quyết định triển khai.

Bước khởi đầu của người dùng phổ thông

Trong các tình huống hạn chế như biểu mẫu nhập liệu hay luồng phê duyệt đơn giản, người không phải kỹ sư vẫn tự làm được. Ở mức này, cảm giác “ai cũng làm được” là có thật, và đó chính là cánh cửa mở rộng nền tảng phát triển công dân trong toàn tổ chức.

Mặt tối (1) — “bức tường chuyên nghiệp” xuất hiện trong thực tiễn

Bề ngoài trông như “ai cũng dùng được”, nhưng khi vận dụng nghiêm túc trong công việc, cuối cùng vẫn cần tư duy tương đương lập trình và góc nhìn thiết kế của kỹ sư hệ thống.

  • Cấu trúc điều khiển là điều tất yếu Muốn tách xử lý theo điều kiện khách hàng phải có phân nhánh (If/Else). Muốn thao tác với hàng trăm bản ghi phải có vòng lặp (ForEach). Muốn ứng phó với trễ hay lỗi từ hệ thống bên ngoài phải có xử lý ngoại lệ (Try/Catch). GUI chỉ bọc chúng thành phần tử kéo thả, nhưng bản chất vẫn là lập trình.

  • Hiểu cấu trúc dữ liệu Cần bung JSON hay mảng, ánh xạ tầng dữ liệu, chuẩn hóa định dạng ngày và số — những việc không thể thiếu trong tích hợp nghiệp vụ. Không thể chỉ thay bằng bảng; thiếu kiến thức cấu trúc dữ liệu là vỡ trận.

  • Độ phức tạp của liên kết hệ thống Quản lý thời hạn token API, đảm bảo tính nhất quán khi băng qua nhiều hệ thống, tránh giới hạn tần suất gọi — đó đều là những bài toán y hệt kỹ nghệ phần mềm truyền thống. GUI chỉ che đậy, thậm chí độ khó còn cao hơn.

  • Yêu cầu về vận hành và chất lượng Nếu thiếu thiết kế cho giám sát, thu thập log, quản lý khác biệt giữa môi trường kiểm thử và sản xuất, kế hoạch rollback khi phát hành, hỗn loạn sẽ tới rất nhanh. Không có mã nguồn để quản lý phiên bản khiến khả năng quan sát dễ suy giảm.

Đứng trước bức tường đó, người phát triển công dân khó có thể tự mình xây dựng và duy trì hệ thống đáp ứng thực tế. Cuối cùng vẫn phải phụ thuộc chuyên gia, trong khi năng lực đội kỹ thuật chưa hề tăng.

Mặt tối (2) — khóa chặt nhà cung cấp và khó khăn khi chuyển đổi

God Excel vẫn còn chút hy vọng vì suy cho cùng nó chỉ là một tệp. Dữ liệu dạng bảng có thể xuất CSV; dù hàm và macro bị khóa trong Excel, vẫn có một số phần mềm bảng tính tương thích và có thể đọc hiểu công thức hay mã. Trong khi đó, sản phẩm của RPA hay no-code/low-code gần như luôn bị giam trong UI hay tập cấu hình đặc thù của từng nền tảng.

  • Chuyển sang sản phẩm của hãng khác thực tế tương đương “làm lại từ đầu”.
  • Việc dịch vụ SaaS ngừng hoạt động hay đổi đặc tả nằm ngoài tầm kiểm soát của người dùng và có thể biến tài sản tích lũy thành vô nghĩa chỉ sau một đêm.
  • Nếu xây dựng trên PaaS, hệ sinh thái đám mây đó sẽ trói chân bạn, khiến việc mang sang môi trường khác cực kỳ khó khăn.
  • Khi logic được định nghĩa bằng UI chứ không phải mã, việc tìm kiếm và điều tra lỗi trở nên tốn công.
  • Tùy thiết kế công cụ, nhiều khi phải nhấp đúp vào từng khối mới thấy được xử lý bên trong, làm tính dễ đọc sụt giảm.

So với God Excel vốn khép kín trong phạm vi tệp bảng tính, mức phụ thuộc và nguy cơ thành gánh nặng tăng lên rõ rệt.

Mặt tối (3) — “thiên kiến hiển thị” khiến lãnh đạo lạc quan

Với kỹ thuật viên, việc sớm hay muộn đụng phải “bức tường chuyên nghiệp” nói trên là điều hiển nhiên. Nhưng khi lãnh đạo được xem các sơ đồ luồng hay màn hình dựng bằng GUI, họ rất dễ nghĩ rằng “ai cũng dùng được”.

Vì sao vậy? Trong mắt lãnh đạo, hệ thống vốn là chiếc hộp đen; chỉ cần nhìn thấy quy trình nối bằng mũi tên hay các biểu mẫu xếp thẳng hàng là họ tưởng như đã hiểu được độ phức tạp bên trong. Thực tế, phía sau vẫn là các logic điều khiển và xử lý lỗi y như lập trình, và muốn áp dụng vào thực chiến thì kiến thức kỹ thuật là điều bắt buộc.

Khoảng cách giữa “cảm giác yên tâm của lãnh đạo” và “nỗi lo của kỹ thuật” vừa thúc đẩy triển khai, vừa ươm mầm khoản nợ tương lai.

Kỷ nguyên God Excel 2.0

Nhìn tổng thể, RPA và no-code/low-code đang lặp lại mô thức của God Excel. Chúng cứu hiện trường bằng tốc độ, thuyết phục lãnh đạo bằng khả năng hiển thị và rồi để lại gánh nặng do tính hộp đen và sự phụ thuộc vào cá nhân.

Điểm khác biệt quyết định nằm ở phạm vi ảnh hưởng. God Excel khép lại trong từng tệp, còn phát triển công dân hiện đại bám sâu vào đám mây và hệ thống lõi, dễ dàng trở thành món nợ trói chặt cả tổ chức. Đã vậy, cấu trúc khóa chặt còn vững hơn Excel. Đó chính là bối cảnh khiến người ta phải gọi tên “God Excel 2.0”.

Tổng kết

  • RPA và no-code/low-code được đón nhận nhờ hiệu quả tức thời và sức thuyết phục từ khả năng hiển thị, làm hài lòng cả tuyến đầu lẫn lãnh đạo.
  • Nhưng để chịu được vận hành thực tế, cần kiến thức kỹ nghệ phần mềm — cấu trúc điều khiển, cấu trúc dữ liệu, liên kết hệ thống, thiết kế vận hành — điều mà người phát triển công dân khó duy trì một mình.
  • UI đặc thù của nền tảng khiến việc di chuyển cực kỳ khó và gia tăng khóa chặt nhà cung cấp.
  • “Thiên kiến hiển thị” ở cấp lãnh đạo khiến các rủi ro này bị đánh giá thấp.

Rốt cuộc, phát triển công dân hiện đại vừa mạnh mẽ hơn God Excel, vừa nguy hiểm hơn. Phần tiếp theo sẽ bàn về điều gì xảy ra khi AI tạo sinh tham gia vào bức tranh này.

Tiếp theo: AI tạo sinh tác động gì đến phát triển công dân 4/7