Cách xây dựng công cụ nội bộ: trang quản trị, phê duyệt và thay thế bảng tính

Để xây dựng một công cụ nội bộ, hãy chọn một quy trình đang gây khó chịu — thường là một bảng tính dùng chung, một chuỗi email hay một kênh chat đang làm công việc của cơ sở dữ liệu — rồi biến nó thành một app nhỏ có form đúng nghĩa, danh sách với trạng thái, quyền phù hợp cho từng vai trò và lịch sử ai đã thay đổi gì. Công cụ AI xây app có thể tạo phiên bản đầu tiên chạy được trong một buổi chiều. Điều giúp dự án thành công là giữ phạm vi ở một quy trình duy nhất và xây dựng cùng những người sẽ dùng nó mỗi ngày.

Thế nào là công cụ nội bộ

Công cụ nội bộ là loại phần mềm không hào nhoáng nhưng giúp doanh nghiệp vận hành. Các loại phổ biến:

Để có thêm ý tưởng khởi đầu, xem ý tưởng công cụ nội bộ cho đội nhóm.

Có nên xây dựng không?

Hãy giữ bảng tính nếu chỉ một người duy trì nó, dữ liệu nhỏ, và sai sót không gây tổn thất đáng kể. Hãy xây công cụ khi bạn nhận thấy các dấu hiệu sau:

• Mọi người ghi đè thay đổi của nhau, hoặc không ai biết bản nào là bản hiện hành
• Bạn cần một số người chỉ xem hoặc sửa một phần dữ liệu
• Bạn đã viết cả trang hướng dẫn cách dùng bảng tính
• Thay đổi trạng thái cần thông báo cho ai đó, và thông báo đó liên tục bị bỏ sót
• Bạn cần dấu vết kiểm tra — ai đã duyệt việc này, và khi nào

Còn một lựa chọn ở giữa. Các nền tảng công cụ nội bộ low-code (Retool, giao diện Airtable, Softr và những nền tảng khác) cung cấp các khối xây dựng sẵn trên dữ liệu của bạn. Chúng phù hợp khi dữ liệu đã nằm trong một cơ sở dữ liệu hoặc bảng tính được hỗ trợ và bạn muốn màn hình kéo-thả. App xây bằng AI phù hợp hơn khi quy trình của bạn đặc thù, bạn muốn nó hoạt động và trông đúng như đội ngũ cần, hoặc bạn muốn sở hữu code. Với câu hỏi tổng quát hơn, xem tự xây hay mua phần mềm cho doanh nghiệp nhỏ.

Thiết kế quy trình trước khi thiết kế màn hình

Hãy viết quy trình thành một câu chuyện ngắn trước khi viết prompt. Ví dụ với một công cụ phê duyệt chi phí:

1. Nhân viên gửi một khoản chi: số tiền, danh mục, ngày, mô tả, ảnh biên lai.
2. Quản lý nhận thông báo và duyệt hoặc từ chối kèm nhận xét.
3. Khoản chi vượt mức cho phép cũng cần tài chính duyệt.
4. Tài chính đánh dấu các khoản đã duyệt là đã thanh toán theo đợt hằng tuần.
5. Mọi người xem được trạng thái khoản chi của mình; tài chính xem tất cả.

Từ câu chuyện đó, bạn có:

• Dữ liệu: chi phí, người dùng, vai trò, phê duyệt (ai, quyết định gì, nhận xét, ngày), tệp đính kèm.
• Trạng thái: đã gửi → quản lý đã duyệt → tài chính đã duyệt → đã thanh toán, hoặc bị từ chối.
• Vai trò: nhân viên, quản lý, tài chính, quản trị viên.
• Quy tắc: ngưỡng số tiền, ai được chuyển một mục sang từng trạng thái.
• Màn hình: form gửi, “chi phí của tôi”, “đang chờ tôi duyệt”, bảng toàn bộ chi phí của tài chính, trang chi tiết kèm lịch sử.

Hãy mô tả quy trình theo các thuật ngữ đó, và AI có thể xây đúng ngay từ lần đầu.

Phân quyền và lịch sử

Công cụ nội bộ thường chứa dữ liệu nhạy cảm — lương, thông tin khách hàng, tiền bạc. Hai nguyên tắc:

1. Kiểm tra vai trò trên máy chủ cho mọi hành động. Quản lý không được tự duyệt chi phí của chính mình bằng cách gọi thẳng endpoint phê duyệt.
2. Ghi lại lịch sử. Lưu mỗi lần thay đổi trạng thái và chỉnh sửa kèm người thực hiện và thời điểm. Điều này giải quyết phần lớn các tranh cãi “ai đã thay đổi cái này?” và rất có giá trị khi có sự cố.

Hãy quyết định cách đăng nhập. Đăng nhập bằng tài khoản Google hoặc Microsoft của công ty rất tiện cho các đội đang dùng sẵn; email và mật khẩu thì dùng được ở mọi nơi. Dù chọn cách nào, cũng cần giới hạn đăng ký để chỉ đội ngũ của bạn vào được.

Prompt đầu tiên hoạt động tốt

Xây dựng công cụ phê duyệt chi phí nội bộ cho công ty 25 người. Nhân viên gửi một khoản chi với số tiền, tiền tệ, danh mục (đi lại, ăn uống, phần mềm, thiết bị, khác), ngày, mô tả và tải ảnh biên lai lên. Quản lý thấy danh sách “Đang chờ tôi duyệt” và có thể duyệt hoặc từ chối kèm nhận xét. Các khoản trên 500 đô la còn cần phê duyệt từ người có vai trò Tài chính. Tài chính thấy bảng tất cả chi phí với bộ lọc theo trạng thái, người và tháng, và có thể đánh dấu các khoản đã duyệt là đã thanh toán. Mỗi thay đổi trạng thái được ghi lại kèm người làm và thời điểm, hiển thị như một dòng thời gian trên trang chi phí. Vai trò: nhân viên, quản lý, tài chính, quản trị viên — được kiểm tra trên máy chủ cho mọi hành động. Lưu tất cả trong cơ sở dữ liệu và tạo dữ liệu mẫu thực tế. Giao diện đơn giản, gọn, nhanh — đây là công cụ làm việc, không phải trang giới thiệu.

Các bước xây dựng

1. Bảng chính và form cho bản ghi cốt lõi, kèm dữ liệu mẫu thực tế để tìm kiếm và bộ lọc hoạt động rõ ràng.
2. Trạng thái và chuyển trạng thái, bao gồm ai được chuyển một mục sang từng trạng thái.
3. Vai trò và đăng nhập, giới hạn cho đội ngũ của bạn.
4. Nhật ký lịch sử trên mỗi bản ghi.
5. Thông báo — email hoặc tin nhắn chat khi có việc cần ai đó xử lý.
6. Nhập dữ liệu hiện có từ bảng tính. Cách biến bảng tính thành app hướng dẫn cách làm sạch và nhập dữ liệu.
7. Thử nghiệm với hai hoặc ba người dùng thật trong một tuần trước khi triển khai cho tất cả.
8. Tắt quy trình cũ vào một ngày cố định. Hai hệ thống chạy song song khiến không hệ thống nào được tin cậy.

Khiến mọi người thực sự dùng

Nhiều công cụ nội bộ hoạt động hoàn hảo nhưng vẫn thất bại vì mọi người tiếp tục làm theo cách cũ.

• Xây dựng cùng người dùng. Hãy quan sát ai đó thực hiện công việc hôm nay trước khi thiết kế phiên bản mới.
• Làm nhanh hơn cách cũ. Nếu gửi một yêu cầu lâu hơn nhắn tin, mọi người sẽ tiếp tục nhắn tin.
• Dày đặc thông tin tốt hơn là đẹp. Người vận hành thích bảng có bộ lọc tốt và form dùng được bằng bàn phím hơn là các thẻ lớn với nhiều khoảng trắng.
• Đặt hành động tiếp theo lên đầu. “Đang chờ tôi” phải là thứ đầu tiên mọi người thấy.

Lỗi thường gặp

• Xây lại toàn bộ bảng tính. Chỉ chuyển quy trình gây khó chịu nhất; phần còn lại cứ để trong bảng tính.
• Không có người phụ trách. Phải có người chịu trách nhiệm cho các thay đổi và sửa lỗi sau khi ra mắt.
• Phân quyền làm sau cùng. Thêm vai trò vào một công cụ đã xong khó hơn nhiều so với bắt đầu từ đầu với chúng.
• Bỏ qua nhật ký kiểm tra, rồi cần đến nó vào lần đầu tiền bị thất thoát.
• Đưa lên URL công khai mà không có đăng nhập. Mọi thứ nội bộ đều phải yêu cầu đăng nhập.

Duy trì sau khi ra mắt

Quy trình thay đổi vài tháng một lần — thêm bước phê duyệt, danh mục mới, đội nhóm mới. Hãy lên kế hoạch cho việc đó từ đầu:

• Giữ cài đặt trong bảng, không trong code. Danh mục, ngưỡng và phân công người duyệt nằm trong cơ sở dữ liệu thì quản trị viên có thể thay đổi mà không cần xây lại.
• Thu gom yêu cầu về một chỗ. Một liên kết “đề xuất thay đổi” ngay trong công cụ tốt hơn các yêu cầu rải rác khắp các kênh chat.
• Xuất dữ liệu thường xuyên. Xuất file CSV các bảng chính để dữ liệu không bị giam giữ, và giúp báo cáo cuối tháng dễ dàng.
• Kiểm thử sau mỗi thay đổi. Chạy lại luồng gửi, duyệt và từ chối sau bất kỳ thay đổi nào của quy trình, vì lỗi phân quyền thường xuất hiện ở đó.

Chi phí vận hành

Công cụ nội bộ xây bằng AI tốn chi phí hosting, cơ sở dữ liệu, lưu trữ tệp nếu người dùng tải tài liệu lên, và có thể cả dịch vụ email hoặc tin nhắn để gửi thông báo. Thường không có phí giấy phép theo người cho công cụ bạn sở hữu, điều này quan trọng khi có nhiều người dùng không thường xuyên cần truy cập. Chi phí lâu dài là thời gian của ai đó để bảo trì.

Xây dựng với Mythex

Công cụ nội bộ là một lựa chọn phù hợp với Mythex. Bạn mô tả quy trình, agent xây dựng nó trên bản xem trước trực tiếp, thêm cơ sở dữ liệu Postgres cho các bản ghi và lưu trữ tệp cho các tải lên như biên lai. Use case công cụ nội bộ và use case trang quản trị trong tài liệu có các prompt khởi đầu. Đồng nghiệp có thể cùng xây dựng trong workspace mà không mất phí theo chỗ ngồi.

Hai điều cần biết. Đăng nhập cho đội ngũ sử dụng công cụ là một phần của app bạn xây, với cách triển khai bạn chọn — chúng tách biệt với tài khoản Mythex. Và Mythex không có sẵn tích hợp Salesforce, HubSpot hay Slack cho chính app; các tích hợp đó được kết nối qua API với khóa của riêng bạn. Để có prompt khởi đầu, hãy thử các mẫu theo dõi phê duyệt hoặc công cụ quản trị nội bộ, và xem cách xây dựng dashboard nếu thứ bạn cần chủ yếu là biểu đồ.

Câu hỏi thường gặp