Ứng Dụng Web Tùy Chỉnh So Với SaaS Đóng Gói Sẵn

Gần như không dự án phát triển ứng dụng web tùy chỉnh nào khởi đầu từ bản đặc tả. Nó khởi đầu từ một bảng tính ai đó lập ra để theo dõi một việc, rồi mọc thêm cột thứ hai, rồi một tab, rồi một công thức chỉ một người hiểu. Ba năm sau, tệp đó giữ lịch làm việc, bảng giá và nửa số hồ sơ khách hàng, bốn người sửa cùng lúc, và không ai dám chắc bản nào mới nhất.

Đó mới là điểm ra quyết định thật, và phần lớn bài viết về tự làm hay mua đều bỏ qua nó. Bạn không chọn giữa trang giấy trắng và một sản phẩm hoàn chỉnh. Bạn chọn giữa ba lối thoát khỏi một quy trình còn chạy được nhưng đã mong manh: mua sản phẩm, lắp ráp trên nền tảng no code, hoặc đặt làm phần mềm theo đúng cách bạn vận hành.

Nên xây ứng dụng web tùy chỉnh hay mua SaaS? Hãy mua, trừ khi ít nhất hai trong ba điều kiện đúng: quy trình là lợi thế cạnh tranh chứ không phải chi phí gián tiếp, không sản phẩm nào vừa mà không bóp méo cách bạn làm việc, và phần lớn công việc nằm ở tích hợp. Nếu chỉ một điều kiện đúng, mua sản phẩm rồi cấu hình gần như luôn rẻ hơn. Bản làm riêng còn kéo theo sàn chi phí thường xuyên khoảng 15 đến 20 phần trăm giá xây dựng mỗi năm, mãi mãi.

Bảng tính đã trở thành trụ cột vận hành

Mô thức này cụ thể đến mức đặt tên được, và thường phải gọi tên ra thì đội ngũ mới nhận ra chính mình.

Nó bắt đầu với một người và một mục đích. Ai đó cần biết tuần này nhận những việc nào nên mở một bảng tính. Người thứ hai cần đọc, nên tệp chuyển sang ổ dùng chung. Người thứ ba cần sửa, nên bây giờ nhiều người gõ vào cùng những ô đó. Rồi mỗi tháng một tab. Rồi một hàm tra cứu sang tệp thứ hai. Rồi một macro do một nhà thầu đã nghỉ việc viết.

Dấu hiệu luôn giống nhau. Tên tệp có ngày tháng và hậu tố phiên bản. Có một bản gốc và ai cũng biết nó nằm ở đâu. Nhận việc cho nhân sự mới nghĩa là cho họ xem tệp đó chứ không phải mô tả quy trình, vì quy trình không được ghi ở chỗ nào khác.

Đến lúc này bảng tính không còn là tài liệu. Nó là một ứng dụng không có phân quyền, không có nhật ký kiểm toán, không có kiểm tra dữ liệu nhập, không có chính sách sao lưu nào bạn dám bảo vệ, và chỉ một người bảo trì. Nó chạy được, đó chính là lý do chưa ai thay nó, và cũng là lý do thay nó bây giờ rất tốn kém.

Cái giá thật của việc giữ nguyên hiện trạng

Không ai lượng hóa bảng tính nên nó trông như miễn phí. Nó không miễn phí, và phép tính này bạn tự làm được với số liệu của mình.

Bắt đầu từ việc nhập lại. Nếu hai người mỗi ngày dành 45 phút chuyển dữ liệu giữa bảng tính, phần mềm kế toán và hộp thư chung, đó là bảy tiếng rưỡi mỗi tuần, tức khoảng 340 giờ trong một năm làm việc 45 tuần. Với chi phí nhân công đầy đủ GBP 22 mỗi giờ, bạn tiêu khoảng GBP 7.500 mỗi năm để chép số từ màn hình này sang màn hình khác, và khoản đó chỉ mua thêm cơ hội gõ nhầm.

Rồi cộng khâu đối soát, khi hàng tháng có người rà bảng tính với nguồn dữ liệu gốc và mất nửa ngày để quyết bản nào đúng. Rồi cộng những lỗi phát hiện muộn: báo giá gửi theo giá tháng trước, một việc bị xếp trùng lịch, một kỳ gia hạn bị bỏ sót. Mỗi lỗi là một khoản nhỏ và một khách hàng khó chịu, và không lỗi nào nằm trong dòng ngân sách nào.

Rồi cộng rủi ro phụ thuộc một người. Chỉ một người hiểu các công thức, và khi người đó ốm, nghỉ phép hay nghỉ việc, quy trình rơi xuống mức phỏng đoán.

Dữ liệu cá nhân trong bảng tính vẫn là dữ liệu bị quản lý

Nếu tệp đó chứa họ tên, thông tin liên hệ, hồ sơ nhân sự hay thông tin khách hàng thì đó là dữ liệu cá nhân, và UK GDPR áp dụng đúng như với một cơ sở dữ liệu.

ICO nói rất rõ về yêu cầu này. Hướng dẫn bảo mật dữ liệu của cơ quan này nêu rằng một nguyên tắc then chốt của UK GDPR là xử lý dữ liệu cá nhân một cách an toàn bằng các biện pháp kỹ thuật và tổ chức phù hợp, và các biện pháp đó phải bảo đảm tính bảo mật, toàn vẹn và sẵn sàng của hệ thống cùng dữ liệu cá nhân bên trong. Một bảng tính trên máy tính xách tay không có quyền theo dòng, không có quy tắc lưu trữ, không có ghi nhận ai đã đọc gì, và nó tự nhân bản trọn vẹn mỗi lần có người gửi kèm email.

Hậu quả không hề lý thuyết. Tháng 10 năm 2024, ICO đã phạt Cảnh sát Bắc Ireland GBP 750.000 sau khi dữ liệu ẩn trong một bảng tính công bố theo yêu cầu tự do thông tin làm lộ họ, chữ cái đầu tên, cấp bậc và chức vụ của toàn bộ 9.483 sĩ quan và nhân viên PSNI. Thông báo cưỡng chế viện dẫn Điều 5(1)(f), 32(1) và 32(2). Nếu không có cách tiếp cận dành cho khu vực công của ICO, mức phạt đã là GBP 5.600.000.

Tổ chức nào vận hành quy trình trên bảng tính cũng có một trang tính như vậy ở đâu đó.

Mua sản phẩm: khi SaaS rõ ràng là đúng

Đây là câu trả lời cho phần lớn trường hợp, và nó xứng đáng được lập luận trước tiên chứ không bị gạt sang đoạn kết.

Nếu quy trình của bạn là quy trình phổ biến thì sản phẩm đã có sẵn, và nó rẻ hơn mọi thứ bạn có thể tự xây. Tính lương, hoàn ứng chi phí, phiếu hỗ trợ, đặt lịch hẹn, chữ ký điện tử, sổ sách kế toán, quản lý tuyển dụng. Ai đó đã bỏ ra một thập kỷ và một đội kỹ thuật lớn cho những tình huống biên bạn chưa gặp: lỗi năm nhuận, thay đổi thuế suất VAT, khoản hoàn tiền về sau kỳ chốt sổ.

Bạn cũng đang mua phần lao động lẽ ra tự trả. Nhà cung cấp gánh thời gian hoạt động, vá bảo mật, biến động trình duyệt, phần việc tiếp cận và bằng chứng tuân thủ mà khách hàng của bạn đòi. Không thứ nào hiện ra như một tính năng, và tất cả đều là tiền thật.

Phép thử trung thực không phải sản phẩm có làm được mọi thứ hay không. Mà là nó có làm tốt 80 phần trăm quan trọng mà không buộc bạn đổi bất cứ điều gì bạn coi trọng hay không. Nếu khác biệt duy nhất là đội bạn gọi là việc còn phần mềm gọi là phiếu, hãy mua phần mềm và đổi từ ngữ.

Ba điều kiện biện minh cho ứng dụng web tùy chỉnh

Bản làm riêng được biện minh bằng chiến lược chứ không bằng sự bực bội. Có ba điều kiện thật sự ủng hộ nó, và quy tắc hữu ích là bạn cần ít nhất hai. Một điều kiện đơn lẻ gần như luôn rẻ hơn khi giải bằng sản phẩm cộng cấu hình. Phép thử này cũng đúng ở quy mô doanh nghiệp, điều mà hướng dẫn tự làm hay mua CRM và ERP của chúng tôi bàn ở một cấp độ khác.

Quy trình là lợi thế hay chỉ là chi phí gián tiếp

Hãy hỏi khách hàng có nhận ra gì không nếu quy trình tốt gấp đôi. Nếu câu trả lời là không, đó là chi phí gián tiếp và bạn nên mua, vì tính lương xuất sắc chẳng mang về hợp đồng nào. Nhưng một nhà thầu lắp đặt chuyên biệt có logic xếp lịch giúp mỗi xe làm thêm một việc mỗi ngày, hay một tổ chức cho vay mà bộ quy tắc thẩm định chính là sản phẩm, đang vận hành lợi thế cạnh tranh qua phần mềm đó. Bạn không mua được lợi thế mà đối thủ cũng mua được với cùng mức phí tháng.

Không sản phẩm nào vừa mà không bóp méo quy trình

Mọi sản phẩm đều mã hóa sẵn giả định về cách công việc chảy, và dấu hiệu chúng sai với bạn là việc áp dụng sản phẩm buộc bạn dừng một việc đang sinh lời. Nếu bạn báo giá theo cơ sở mà sản phẩm không diễn đạt được, và chính cách báo giá đó là lý do khách chọn bạn, thì sản phẩm đang đòi bạn trở nên tầm thường hơn để đổi lấy một khoản phí bản quyền.

Bề mặt tích hợp mới là công việc thật

Đôi khi phần thú vị không nằm ở các màn hình. Nó là kéo tồn kho từ hệ thống này, giá từ hệ thống thứ hai, lịch rảnh của kỹ thuật viên từ hệ thống thứ ba, rồi ghi kết quả vào hệ thống thứ tư. Khi phần lớn công sức là tích hợp, giao diện chỉ là lớp mỏng phủ trên đường ống của chính bạn, còn màn hình dựng sẵn của sản phẩm lại là thứ bạn cần ít nhất. Điều kiện này hay bị đánh giá thấp nhất, và cũng là nơi cái bẫy ở giữa nằm chờ.

Cái bẫy ở giữa: mua rồi vẫn phải tự làm

Kết cục đắt nhất là không đi trọn vẹn lối nào. Đó là mua sản phẩm vì trông rẻ hơn, rồi tiêu nhiều hơn cả một bản làm riêng để bẻ nó theo quy trình của mình, mà vẫn phải trả phí bản quyền.

Nó diễn ra dần dần và từng bước đều có lý. Sản phẩm không vừa nên bạn thuê một đối tác triển khai. Đối tác viết cấu hình trong lớp kịch bản độc quyền của nhà cung cấp, vốn là mã nguồn, nhưng không giống mã nguồn vì nó sống bên trong sản phẩm. Rồi bạn cần nó nói chuyện với hai hệ thống khác nên mua một nền tảng tích hợp. Rồi nhà cung cấp phát hành phiên bản lớn và phần tùy biến của bạn cần kiểm thử hồi quy.

Đến lúc đó bạn chịu mọi chi phí của phần mềm tùy chỉnh mà không có quyền sở hữu nào: một mã nguồn bạn không đọc được, chạy ở nơi bạn không kiểm soát, viết bằng thứ ngôn ngữ chỉ tồn tại trong một sản phẩm, do một đối tác mà đơn giá ngày công giờ đã thành một dòng ngân sách bảo trì. Hướng dẫn về chi phí phát triển phần mềm tùy chỉnh của chúng tôi nói rõ các con số đó tích tụ ra sao.

Dấu hiệu cho thấy bạn đang mắc bẫy

Cái bẫy dễ nhận ra hơn là dễ thoát, và tín hiệu rất rõ khi bạn chịu tìm.

• Phí của đối tác triển khai lớn hơn phí bản quyền năm đầu.
• Việc quản trị một sản phẩm trên thực tế đã thành công việc toàn thời gian của ai đó.
• Bạn đã viết logic bằng ngôn ngữ kịch bản độc quyền của nhà cung cấp, và ngoài công ty không ai đọc nổi.
• Mỗi lần nhà cung cấp nâng cấp là phải kiểm thử hồi quy phần tùy biến, nên bạn cứ hoãn nâng cấp.
• Bạn trả tiền cho một nền tảng tích hợp tồn tại chỉ để bơm dữ liệu cho đúng sản phẩm này.
• Bạn vẫn duy trì một bảng tính chạy song song, vì sản phẩm không diễn đạt được một thứ bạn cần.

Dấu hiệu cuối là rõ nhất. Nếu bảng tính vẫn sống sót sau khi mua phần mềm, phần mềm đó chưa giải quyết được vấn đề.

No code và low code như lối đi thứ ba nghiêm túc

Câu hỏi no code hay tùy chỉnh xứng đáng hơn một chú thích, vì trong phát triển công cụ nội bộ, các nền tảng low code thường là câu trả lời đúng và chúng không phải đồ chơi.

Những nền tảng như Airtable, Retool và Microsoft Power Apps cho phép bạn dựng một ứng dụng nhiều người dùng thực thụ với cơ sở dữ liệu, biểu mẫu, phân quyền và tự động hóa, trong vài ngày thay vì vài tháng, mà không cần tuyển ai. Chúng lo hosting, sao lưu, xác thực và bố cục di động. Với đúng việc đưa một bảng tính trụ cột vào một nơi có phân quyền tử tế và nhật ký kiểm toán, chúng thường là con đường nhanh nhất để giảm rủi ro thật nhiều.

Chúng cũng tính tiền theo chỗ ngồi, và chính điều đó quyết định liệu chúng còn đúng khi bạn lớn lên hay không.

Nơi no code thắng thật sự

Nó thắng khi hình dạng bài toán là bản ghi, biểu mẫu, khung xem và quy tắc đơn giản: sổ tài sản, hàng đợi phê duyệt, danh mục tiếp nhận khách hàng, hệ thống đặt phòng họp. Nó thắng đậm nhất khi chính người hiểu quy trình tự dựng được, vì yêu cầu không phải sống sót qua vòng dịch sang đặc tả rồi dịch ngược lại.

Nó cũng thắng về thời gian tạo giá trị. Một công cụ chạy được sau hai tuần và được dùng mỗi ngày hơn hẳn một công cụ hoàn hảo sau sáu tháng còn nằm trên bản vẽ, và bản đã dựng sẽ dạy bạn yêu cầu thật là gì.

Nơi no code đụng tường

Bức tường thường là một trong năm thứ. Hiệu năng ở số dòng thật, khi một khung xem phải lọc hàng trăm nghìn bản ghi. Phân quyền phức tạp thật sự, kiểu quy tắc theo dòng phụ thuộc trạng thái bản ghi và đội của người xem. Toàn vẹn giao dịch, khi hai việc phải cùng xảy ra hoặc cùng không. Kiểm thử và quản lý phiên bản, vì thường không có cách xem lại một thay đổi trước khi nó lên thật. Và bất cứ thứ gì có máy trạng thái thật, nơi quy tắc định đoạt chuyển tiếp nào là hợp lệ.

Bạn không đụng tường dần dần. Bạn đụng nó khi một thay đổi đáng ra mất một giờ hóa ra là bất khả thi.

Giá theo chỗ ngồi làm gì ở quy mô lớn

Giá theo chỗ ngồi rẻ ở mười người và khó biện minh ở bốn trăm người, và biểu giá công khai cho thấy điều đó dễ dàng.

Trang giá của Retool niêm yết gói Business cho đám mây Anh ở mức GBP 40 mỗi tháng cho mỗi người dựng và GBP 12 cho mỗi người dùng nội bộ, còn gói Team là GBP 8 và GBP 4. Microsoft niêm yết Power Apps Premium ở GBP 16,90 mỗi người dùng mỗi tháng khi trả theo năm, chưa gồm VAT, giảm còn GBP 10,80 nếu tối thiểu 2.000 chỗ. Airtable công bố Team ở USD 20 và Business ở USD 45 mỗi người dùng mỗi tháng, cả hai đều tính theo năm bằng đô la Mỹ.

Hãy chiếu tới. Bốn mươi người dùng trên Retool Business, trong đó 3 người dựng, tốn khoảng GBP 6.800 mỗi năm. Cùng cấu hình đó ở 400 người dùng là khoảng GBP 59.600 mỗi năm, và nó lại tăng ngay khi bạn thêm người. Trên Power Apps Premium, 400 chỗ là khoảng GBP 81.000 mỗi năm trước VAT.

Không mức giá nào trong đó là vô lý. Điểm mấu chốt là hóa đơn bám theo số nhân sự chứ không theo giá trị tạo ra, và số nhân sự thì tăng.

Bài toán thoát ra khi logic nằm trong công cụ độc quyền

Nền tảng nào cũng xuất được dữ liệu của bạn. Không nền tảng nào xuất được ứng dụng của bạn.

Các dòng dữ liệu ra dưới dạng CSV hoặc qua API, và ai cũng kiểm tra phần đó trước khi ký. Thứ không ra được là thứ bạn đã dựng: các luồng tự động, cột công thức, quy tắc phân quyền, biểu mẫu điều kiện, dòng chảy biến một yêu cầu thành ba thông báo và một lần đổi trạng thái. Logic đó mới là tài sản, phải mất nhiều tháng cân nhắc mới đúng, và chỉ một bộ thực thi của một nhà cung cấp chạy được nó.

Hệ quả thực tế là rời một nền tảng low code không phải là di trú mà là làm lại. Bạn lấy lại dữ liệu rồi viết lại ứng dụng ở chỗ khác, từ một bản đặc tả chưa từng được viết ra, vì chính nền tảng đã là bản đặc tả.

Đó không phải lý lẽ chống việc dùng nó, chỉ là lý lẽ để giữ một mô tả quy tắc bằng văn bản ở ngoài công cụ.

Tổng chi phí sở hữu năm năm của ba lối đi

Phép so sánh người ta hay làm thiếu trung thực ở một chỗ: nó đặt bản đã tính đủ chi phí của lối này cạnh giá niêm yết của lối kia. Hãy lấy 40 người dùng và một ứng dụng vận hành thay cho một bảng tính cùng hai gói thuê bao nhỏ. Các con số dưới đây là số liệu minh họa để lập kế hoạch, không phải báo giá, và giá xây dựng là biến động nhiều nhất.

Đọc thành lời: ở 40 người dùng, nền no code thắng với khoảng GBP 75.800 cho năm năm. Bản làm riêng đứng thứ hai ở khoảng GBP 94.500, vì GBP 45.000 xây dựng cộng GBP 1.800 hosting và GBP 8.100 bảo trì hằng năm vẫn thấp hơn phần bản quyền, middleware và quản trị chồng lên nhau của lối SaaS. Mua sản phẩm về chót ở khoảng GBP 135.000, và lý do là cái bẫy ở giữa chứ không riêng phí bản quyền.

Vì sao cũng bảng đó lại đảo ở bốn trăm người dùng

Đổi đúng một tham số, số nhân sự, và thứ tự đảo hoàn toàn. Đây là lý do phổ biến nhất khiến việc tự xây trở nên hợp lý.

Ở 400 người dùng, riêng phí bản quyền SaaS GBP 30 mỗi chỗ mỗi tháng đã là GBP 144.000 một năm, và với cùng middleware cộng gánh nặng quản trị lớn hơn, tổng năm năm vượt GBP 800.000. Lối no code rơi vào khoảng GBP 375.000. Bản làm riêng gần như không nhúc nhích: nhiều người dùng hơn chỉ nghĩa là hóa đơn hosting và ngân sách bảo trì nhích lên, nên dù nhân đôi giá xây dựng lên GBP 70.000 thì tổng năm năm vẫn quanh GBP 153.000.

Lý do mang tính cấu trúc. Giá theo chỗ ngồi là chi phí biến đổi tăng theo tổ chức, còn hệ thống tùy chỉnh là chi phí cố định cộng một phần biến đổi nhỏ, và phần biến đổi đó là hạ tầng, vốn rẻ. Việc đảo chiều này có quan trọng với bạn hay không là một dự báo kinh doanh chứ không phải một phán đoán kỹ thuật.

Sàn chi phí thường xuyên của một bản làm riêng

Dòng người ta hay bỏ khỏi bảng dự toán tùy chỉnh chính là dòng không bao giờ dừng. Một ứng dụng làm riêng có sàn chi phí, và nó không rơi về không trong một năm yên ả khi chẳng ai yêu cầu tính năng mới.

Sàn đó gồm hosting, giám sát, những bản sao lưu bạn đã thử phục hồi thật, chứng chỉ TLS, vá bảo mật, nâng cấp thư viện phụ thuộc, và một người nhấc máy khi hệ thống hỏng lúc chín giờ sáng thứ Hai. Hãy lập kế hoạch quanh mức khoảng 15 đến 20 phần trăm chi phí xây dựng ban đầu mỗi năm. Đó là một giả định lập kế hoạch rút ra từ cách các dự án này vận hành chứ không phải một thống kê đã công bố, nhưng đó là con số chúng tôi dùng để lập ngân sách, và một báo giá thiếu nó không phải báo giá hoàn chỉnh. Bài viết về chi phí bảo trì phần mềm của chúng tôi phân tách kỹ hơn.

Mọi tổng năm năm ở trên đều giả định dòng đó có ngân sách. Dự án bỏ qua nó không tiết kiệm được khoản tiền ấy, chỉ hoãn lại rồi trả sau dưới dạng một lần viết lại, đúng như nợ kỹ thuật mô tả.

Phần mềm không được bảo trì sẽ mục ruỗng

Một ứng dụng chạy hai năm không ai đụng tới thì không phải là ổn định. Nó là chưa vá, và khác biệt đó rất quan trọng.

Mã của bạn không đổi gì, nhưng mọi thứ quanh nó đều đổi. Các bộ thực thi ngôn ngữ hết vòng đời theo lịch công bố: Node.js hiện hỗ trợ phiên bản 26 ở nhánh Current cùng phiên bản 24 và 22 ở nhánh LTS đang hoạt động, nghĩa là mọi thứ dựng trên phiên bản 20 trở về trước nay đã hết hỗ trợ và không nhận bản vá bảo mật nào. Thư viện phụ thuộc tích tụ lỗ hổng đã công bố. Trình duyệt đổi cách xử lý cookie và bộ nhớ. Nhà cung cấp thanh toán khai tử phiên bản API và cho bạn một hạn chót.

Không điều nào là lỗi của bạn và tất cả đều là vấn đề của bạn, vì trong một hệ thống làm riêng không có nhà cung cấp nào hấp thụ chúng thay bạn. Đây chính là lợi thế cấu trúc thật sự của việc mua: đội kỹ thuật của người khác dành mỗi tuần để giữ cho sàn nhà khỏi mục, và phí bản quyền là cái giá của việc đó. Ngân sách bảo trì của bạn mua đúng phần việc ấy, và bạn hoặc trả nó có chủ đích, hoặc trả nó trong một tình huống khẩn cấp.

Tìm điểm hòa vốn theo chỗ ngồi của riêng bạn

Bạn tính được điểm hòa vốn trong khoảng mười phút, và nó thuyết phục giám đốc tài chính hơn mọi lập luận về quyền sở hữu.

Lấy chi phí hằng tháng của lối mua sản phẩm, tính đủ: bản quyền, middleware, và phần lương dành cho việc quản trị nó. Trừ đi chi phí vận hành hằng tháng của hệ thống tùy chỉnh, tức hosting cộng một phần mười hai ngân sách bảo trì năm. Lấy giá xây dựng chia cho phần còn lại. Kết quả là số tháng cho tới khi bản làm riêng tự hoàn vốn.

Tính ở 40 người dùng: lối SaaS tốn khoảng GBP 2.150 mỗi tháng và hệ thống tùy chỉnh khoảng GBP 825, nên khoản tiết kiệm hằng tháng là khoảng GBP 1.325. Bản dựng GBP 45.000 chia cho con số đó ra khoảng 34 lần, nên điểm hoàn vốn rơi vào quãng hai năm mười tháng. Ở 400 người dùng, hoàn vốn rút xuống dưới một năm.

Hai lưu ý. Giá xây dựng là con số kém chắc chắn nhất ở đây, nên hãy tính theo báo giá bạn nhận rồi tính lại với mức cao hơn 50 phần trăm. Và thời gian hoàn vốn dài hơn khoảng ba năm là một lập luận yếu, vì quy trình của bạn có thể không giữ nguyên lâu đến vậy.

Dữ liệu và sự phụ thuộc cắt về cả hai phía

Phụ thuộc nhà cung cấp là lập luận chuẩn mực cho việc tự xây, và nó có thật. Nó cũng chỉ là một nửa bức tranh, vì một hệ thống tùy chỉnh không ai viết tài liệu cũng bị khóa chặt y như vậy.

Ở phía sản phẩm, hãy kiểm tra trước khi ký xem thực sự lấy ra được gì. Bản ghi thường xuất sạch sẽ. Tệp đính kèm, nhật ký kiểm toán lịch sử, các luồng bình luận, cấu trúc phân quyền và quan hệ giữa các bản ghi thì thường không. Thước đo thực tế không phải là có nút xuất hay không, mà là bạn có dựng nổi một hệ thống thay thế chạy được chỉ từ bản xuất đó hay không.

Ở phía tùy chỉnh, rủi ro tương đương và ngược chiều là một hệ thống do một nhà thầu dựng nên, không README, không kiểm thử, không sổ tay vận hành, thông tin đăng nhập nằm trong một tệp cấu hình trên máy xách tay, và kho mã nằm trong tài khoản cá nhân của ai đó. Thứ đó còn tệ hơn phụ thuộc SaaS, vì ít nhất nhà cung cấp vẫn đang kinh doanh.

Cách khắc phục nằm ở hợp đồng và rất rẻ nếu đòi ngay từ đầu. Hãy tự sở hữu kho mã, yêu cầu tài liệu và sổ tay vận hành như những hạng mục bàn giao có tên, và yêu cầu một kỹ sư thứ hai triển khai được chỉ từ tài liệu đó. Hãy kiểm chứng điều này trước lần thanh toán cuối. Hướng dẫn toàn diện cho bên mua của chúng tôi bàn kỹ hơn về điều khoản hợp đồng.

Bảo mật và tuân thủ theo từng mô hình

Cách chia trách nhiệm khác nhau theo từng lối đi, nhưng có một thứ không dịch chuyển chút nào, và hiểu sai chỗ này là chuyện thường gặp.

Theo UK GDPR bạn là bên kiểm soát. ICO định nghĩa bên kiểm soát là chủ thể tự mình hoặc cùng với chủ thể khác xác định mục đích và phương tiện xử lý dữ liệu cá nhân, còn bên xử lý là chủ thể xử lý dữ liệu cá nhân thay mặt bên kiểm soát. Nhà cung cấp SaaS của bạn hầu như luôn là bên xử lý. Trách nhiệm chứng minh tuân thủ vẫn thuộc về bạn, và ICO nói rõ rằng bên kiểm soát chịu trách nhiệm về các bên xử lý của mình và phải có hợp đồng ràng buộc chứa những điều khoản mà Điều 28(3) yêu cầu.

Thứ nhà cung cấp thật sự gánh là lớp hạ tầng: an ninh vật lý, vá nền tảng, kiểm soát mạng và thường là cả chứng nhận. Mô hình trách nhiệm chung của NCSC nói rõ rằng ngay cả với SaaS bạn vẫn giữ ba việc: đánh giá dịch vụ có đáp ứng nhu cầu bảo mật của bạn không, cấu hình nó an toàn, và quyết định đưa dữ liệu nào vào.

Trong một bản làm riêng, bạn thừa hưởng luôn cả lớp kỹ thuật: vá lỗi, kiểm soát truy cập, mã hóa, ghi nhật ký, sao lưu và phục hồi. Bài viết về tuân thủ GDPR về mặt kỹ thuật của chúng tôi cho thấy điều đó trông ra sao trong mã nguồn. Vị thế pháp lý không đổi giữa các lối đi.

Khả năng tiếp cận áp dụng cả cho công cụ nội bộ

Công cụ nội bộ thường được dựng như thể không ai dùng chúng có thể là người khuyết tật, điều vừa sai vừa trái luật với một số tổ chức.

Theo mục 20 của Đạo luật Bình đẳng 2010, người sử dụng lao động có nghĩa vụ thực hiện điều chỉnh hợp lý, gồm cả việc tiến hành các bước hợp lý để tránh bất lợi đáng kể do một quy định, tiêu chí hay thông lệ gây ra, và cung cấp thiết bị hỗ trợ. Một hệ thống xếp ca không dùng được bằng bàn phím đặt nhân viên khuyết tật vào bất lợi đáng kể, và không có ngoại lệ nào cho phần mềm mà khách hàng của bạn không bao giờ nhìn thấy.

Với tổ chức khu vực công, quy định còn nói thẳng. Hướng dẫn của GOV.UK về yêu cầu tiếp cận nêu rằng các trang mạng nội bộ và ngoại bộ đều nằm trong phạm vi quy định về tiếp cận, phải đạt WCAG 2.2 AA, và các trang nội bộ cũ công bố trước ngày 23 tháng 9 năm 2019 phải được làm cho tiếp cận được khi cập nhật.

Những tiêu chí công cụ nội bộ hay trượt nhất lại rất bình thường: 2.1.1 Bàn phím và 3.3.2 Nhãn hoặc hướng dẫn ở mức A, 1.4.3 Độ tương phản tối thiểu ở mức AA, và trong phần bổ sung của WCAG 2.2 là 2.4.11 Tiêu điểm không bị che và 2.5.8 Kích thước vùng chạm, cả hai đều ở mức AA.

Trên no code, trần tiếp cận không do bạn quyết

Đây là luận điểm tiếp cận làm thay đổi hẳn quyết định tự làm hay mua, chứ không chỉ thêm việc cho nó.

Trên nền tảng no code, bạn không viết mã đánh dấu. Nền tảng sinh ra nó, nên mức tiếp cận của ứng dụng bị chặn trần bởi mức của thư viện thành phần mà nền tảng cung cấp. Nếu bộ chọn ngày không dùng được bằng bàn phím, hoặc hộp thoại bẫy tiêu điểm sai, bạn không sửa được. Bạn chỉ có thể mở phiếu hỗ trợ rồi chờ.

Điều đó ổn khi trần đủ cao, và vài nền tảng thật sự coi trọng vấn đề này. Nó không ổn khi bạn có một nghĩa vụ cụ thể, một nhân viên cụ thể hoặc một trách nhiệm khu vực công, vì cách khắc phục nằm ngoài tầm kiểm soát và ngoài lịch trình của bạn.

Trong một bản làm riêng, phần việc tiếp cận là của bạn phải làm cho đúng, tốn hơn lúc đầu nhưng gỡ bỏ sự phụ thuộc. Hãy hỏi mọi nhà cung cấp tiềm năng về bản tuyên bố phù hợp tiếp cận trước khi thiết kế quy trình quanh thành phần của họ, và coi việc họ không có là một câu trả lời.

Giảm rủi ro bản làm riêng bằng lát cắt mỏng đầu tiên

Cách các dự án tùy chỉnh thất bại thường không mang tính kỹ thuật. Đó là dồn toàn bộ ngân sách vào một bản đặc tả viết trước khi có ai dùng thử bất cứ thứ gì.

Lựa chọn thay thế là một lát cắt mỏng: một luồng công việc, từ đầu đến cuối, chạy trên môi trường thật, được một người thật đang làm việc thật sử dụng, trong sáu đến tám tuần. Không phải bản mẫu, cũng không phải bản trình diễn, mà là đường hẹp nhất xuyên qua hệ thống tạo ra một kết quả thật, với dữ liệu thật, xác thực thật và một lần triển khai thật. Nếu quy trình là báo giá thì lát cắt đó tạo báo giá, tính giá và gửi đi.

Lát cắt ấy làm được bốn việc mà đặc tả không làm nổi. Nó chứng minh các tích hợp, nơi mọi bất ngờ ẩn nấp. Nó đo tốc độ giao hàng thật của đội thay vì ước lượng. Nó đặt phần mềm chạy được trước mặt người sở hữu quy trình, việc luôn làm thay đổi yêu cầu. Và nó cho bạn một lối ra: bạn đã tiêu một khoản xác định và bạn sở hữu một thứ chạy được.

Sau đó hãy đặt một mốc quyết định ở đó, bằng văn bản, trước khi giải ngân khoản lớn hơn. Hướng dẫn cách xây một ứng dụng web của chúng tôi bàn về hình hài kỹ thuật của lát cắt đầu tiên, còn trang dịch vụ phát triển phần mềm giải thích cách chúng tôi khoanh phạm vi cho nó.

Khung ra quyết định chạy gọn trong một buổi chiều

Không phần nào ở đây cần một hợp đồng tư vấn. Nó cần vài giờ và sự trung thực với các con số.

Thứ nhất, viết quy trình ra đúng như nó đang chạy, theo từng bước, gồm cả những ngoại lệ người ta xử lý bằng tay. Riêng việc này thường kết thúc tranh luận, vì nó phơi ra rằng có ba quy trình chứ không phải một.

Thứ hai, đếm số chỗ ngồi hôm nay và dự báo cho ba năm tới. Thứ ba, chọn đúng ba sản phẩm và chấm điểm chúng theo quy trình bạn đã viết chứ không theo danh mục tính năng, đánh dấu mọi chỗ mà việc áp dụng sản phẩm sẽ đổi cách bạn làm việc và ghi rõ thay đổi đó có khiến bạn mất gì không.

Thứ tư, định giá cái bẫy ở giữa một cách tường minh: phí triển khai, middleware, và phần lương sẽ dùng để quản trị nó. Thứ năm, áp phép thử hai trong ba. Thứ sáu, tính điểm hòa vốn theo tháng ở cả hai mức chỗ ngồi. Thứ bảy, nếu câu trả lời là làm riêng, hãy đặt một lát cắt mỏng chứ không phải cả một hệ thống.

Ai nên đóng tab này lại và đi mua

Một số bạn đọc nên dừng ở đây, và nói thẳng như vậy hữu ích hơn một kết luận cân bằng.

Nếu quy trình của bạn là quy trình phổ biến mà hàng nghìn doanh nghiệp chạy theo cách gần giống nhau, hãy mua sản phẩm. Nếu bạn có dưới khoảng hai mươi người dùng và không có dự báo nào làm điều đó thay đổi, hãy mua sản phẩm hoặc dựng trên nền tảng no code, vì phép tính theo chỗ ngồi sẽ không nghiêng về phía bạn trong bất cứ khoảng thời gian nào bạn lập kế hoạch được. Nếu sau khi bàn giao không ai sở hữu phần mềm, hãy mua sản phẩm, vì một hệ thống tùy chỉnh vô chủ nhanh chóng mục thành gánh nặng.

Nếu bạn không mô tả nổi quy trình bằng văn bản, đừng đặt làm gì cả lúc này. Hãy viết nó ra trước. Nhiều dự án đổ vỡ được đặt hàng dựa trên một mô tả mà ba người trong cùng một phòng hiểu theo ba cách khác nhau, và không lượng kỹ thuật nào sửa được điều đó.

Nếu chỉ một trong ba điều kiện đúng, hãy mua sản phẩm và xem lại sau một năm. Các điều kiện có thay đổi, thường vì nhân sự đã tăng. Và nếu thứ bạn thật sự cần là một trang công khai chứ không phải công cụ nội bộ thì đó là một dự án khác, thuộc mảng phát triển website của chúng tôi.

Xin ý kiến thứ hai trước khi cam kết

Sai lầm đắt giá theo cả hai hướng đều xảy ra trước khi có dòng mã nào, nên thứ rẻ nhất bạn mua được lúc này là một đánh giá trung thực.

Mecanik xây các ứng dụng web vận hành cho doanh nghiệp Anh, và một phần lớn công việc đó là nói với người ta rằng họ không cần một cái. Hãy mang theo bảng tính, số chỗ ngồi và ba sản phẩm bạn đã chọn lọc, đội phát triển phần mềm tùy chỉnh của chúng tôi sẽ hoặc báo giá một lát cắt mỏng đầu tiên, hoặc chỉ cho bạn nên mua sản phẩm nào thay thế. Nếu ứng dụng hướng tới khách hàng chứ không phải nội bộ, hãy bắt đầu từ phát triển website và đọc bài so sánh phát triển web tùy chỉnh và các nền tảng SaaS, bài bàn về phía đó của câu hỏi.

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

Một ứng dụng web tùy chỉnh ở Anh tốn bao nhiêu? Một ứng dụng nội bộ gọn gàng thay cho một bảng tính và một hoặc hai gói thuê bao thường tốn từ GBP 25.000 đến GBP 60.000 để xây, trong đó lát cắt mỏng đầu tiên chiếm GBP 8.000 đến GBP 15.000. Hãy dự trù thêm 15 đến 20 phần trăm giá xây dựng mỗi năm cho hosting, vá lỗi và nâng cấp thư viện phụ thuộc, vì sàn chi phí đó không bao giờ về không.

No code có phải lựa chọn thay thế thật sự cho ứng dụng web tùy chỉnh không? Có. Với bản ghi, biểu mẫu, khung xem và quy tắc đơn giản, nó thường là câu trả lời đúng và nhanh hơn nhiều. Nó đụng tường ở số dòng lớn, phân quyền phức tạp, toàn vẹn giao dịch, quản lý phiên bản và máy trạng thái thật. Nó cũng tính theo chỗ ngồi: Retool niêm yết gói Business ở GBP 40 mỗi người dựng và GBP 12 mỗi người dùng nội bộ mỗi tháng, rẻ ở mười chỗ và đáng kể ở bốn trăm chỗ.

Ở số người dùng nào thì tự xây rẻ hơn đi mua? Lấy giá xây dựng chia cho khoản tiết kiệm hằng tháng, tức chi phí sản phẩm tính đủ trừ đi hosting cộng một phần mười hai ngân sách bảo trì năm. Ở 40 người dùng, một bản dựng GBP 45.000 so với chi phí sản phẩm GBP 2.150 mỗi tháng hoàn vốn trong khoảng 34 tháng. Ở 400 người dùng, nó hoàn vốn dưới một năm, vì phí theo chỗ ngồi tăng theo nhân sự còn chi phí vận hành hệ thống tùy chỉnh gần như không đổi.

Ai chịu trách nhiệm bảo vệ dữ liệu nếu chúng tôi mua SaaS thay vì tự xây? Bạn. ICO định nghĩa bên kiểm soát là chủ thể xác định mục đích và phương tiện xử lý, còn nhà cung cấp SaaS của bạn hầu như luôn là bên xử lý hành động theo chỉ dẫn của bạn. Bạn vẫn chịu trách nhiệm chứng minh tuân thủ, chịu trách nhiệm về tuân thủ của các bên xử lý, và phải có hợp đồng theo Điều 28(3). Mua phần mềm chuyển phần việc hạ tầng chứ không chuyển trách nhiệm pháp lý.

Quy tắc tiếp cận có áp dụng cho công cụ nội bộ mà bên ngoài không ai thấy không? Có. Mục 20 của Đạo luật Bình đẳng 2010 buộc người sử dụng lao động thực hiện điều chỉnh hợp lý, và một công cụ không dùng được bằng bàn phím đặt nhân viên khuyết tật vào bất lợi đáng kể. Mạng nội bộ và ngoại bộ của khu vực công còn thuộc phạm vi quy định về tiếp cận và phải đạt WCAG 2.2 AA. Trên nền tảng no code, trần tiếp cận do thành phần của nhà cung cấp quyết định.