Xây dựng hay Mua Phần mềm: Khung Chi phí và Rủi ro cho Lãnh đạo Doanh nghiệp

Bạn đã đánh giá một nền tảng vận hành mới được ba tuần. Hai nhà cung cấp đã gửi đề xuất bóng bẩy. Trưởng phòng kỹ thuật của bạn cứ nhắc đi nhắc lại: "Chúng ta có thể tự xây dựng cái này trong vài tháng." CFO của bạn muốn có một con số vào thứ Sáu. Và đâu đó trong tâm trí, bạn nhớ lại lần cuối cùng một đội ngũ hứa hẹn "vài tháng" và rồi biến mất trong một cuộc viết lại kéo dài mười tám tháng. Đây chính là khoảnh khắc mà hầu hết các quyết định xây-hay-mua thực sự được đưa ra: không phải bằng bảng tính, mà bằng một cái nhún vai và một hạn chót. Đó chính xác là lý do vì sao rất nhiều quyết định trong số đó đi sai hướng.

Câu hỏi xây-hay-mua nghe có vẻ là một quyết định công nghệ, nhưng thực chất nó là một canh bạc kinh doanh. Bạn đang đánh cược thời gian, tiền bạc và sự tập trung của tổ chức vào niềm tin rằng một con đường sẽ phục vụ khách hàng và hoạt động của bạn tốt hơn con đường kia trong ba đến năm năm tới. Nếu quyết định đúng, phần mềm sẽ lùi vào hậu cảnh trong khi doanh nghiệp phát triển. Nếu quyết định sai, bạn sẽ dành hai năm tới hoặc là vật lộn với một nền tảng không phù hợp, hoặc là bảo trì một codebase mà không ai muốn sở hữu.

Sau nhiều năm xây dựng hệ thống tùy chỉnh cho các công ty đã mua sai sản phẩm, và tích hợp các công cụ có sẵn cho các công ty đã tự xây dựng quá mức cần thiết, chúng tôi nhận thấy quyết định thường quy về năm câu hỏi. Không câu nào mang tính kỹ thuật. Tất cả đều có thể được trả lời bởi một lãnh đạo doanh nghiệp sẵn sàng thành thật về những gì công ty thực sự làm.

Câu hỏi 1: Quy trình này có phải là nguồn lợi thế cạnh tranh, hay chỉ là điều kiện cần?

Hãy bắt đầu từ đây. Mọi doanh nghiệp đều vận hành trên hàng chục quy trình: tính lương, kế toán, email, hỗ trợ khách hàng, theo dõi tồn kho, quản lý pipeline bán hàng. Một số quy trình là cách bạn chiến thắng. Hầu hết còn lại chỉ đơn thuần là cách bạn vận hành.

Nếu một quy trình chỉ là điều kiện cần — thứ mà mọi đối thủ trong ngành đều làm gần như giống nhau — hãy mua phần mềm. Bạn sẽ không thể vượt qua QuickBooks về kế toán hay Gmail về email. Các nhà cung cấp chuyên về những hạng mục này đã dành cả một thập kỷ và hàng trăm triệu đô la để hoàn thiện những tính năng mà bạn thậm chí chưa nghĩ đến. Cố gắng tự xây dựng không phải là tham vọng, mà là một khoản thuế đánh vào đội ngũ kỹ thuật và một sự phân tâm khỏi công việc thực sự tạo nên sự khác biệt của bạn.

Nhưng nếu một quy trình thực sự là cách bạn chiến thắng — engine định giá giúp công ty logistics của bạn đánh bại đối thủ với mức giá thấp hơn 8 phần trăm, thuật toán ghép cặp là trái tim của sàn giao dịch của bạn, mô hình thẩm định giúp tổ chức cho vay của bạn phê duyệt những khoản vay mà đối thủ từ chối — thì phép tính sẽ thay đổi. Phần mềm có sẵn sẽ khiến bạn trông giống như mọi người khác, vì nó được xây dựng để phục vụ mọi người khác. Trong những trường hợp này, phần mềm tùy chỉnh không phải là chi phí. Nó chính là sản phẩm.

Bài kiểm tra rất đơn giản: nếu bạn mô tả quy trình này cho một đối thủ, họ có ghen tị không? Nếu có, nó xứng đáng với khoản đầu tư tùy chỉnh. Nếu họ chỉ nhún vai, hãy mua công cụ.

Chúng tôi từng làm việc với một nhà phân phối cỡ trung khẳng định họ cần một hệ thống quản lý kho tùy chỉnh vì "không ai hiểu được quy trình của chúng tôi." Sau hai buổi workshop, hóa ra quy trình của họ giống đến 90 phần trăm so với bất kỳ nhà phân phối nào cùng quy mô. Mười phần trăm còn lại — một quy trình trả hàng chuyên biệt gắn với hợp đồng nhà cung cấp — mới là điểm khác biệt thực sự. Câu trả lời đúng không phải là xây dựng một WMS tùy chỉnh. Mà là mua một WMS đã được chứng minh và xây dựng một module tùy chỉnh nhỏ xử lý quy trình trả hàng và tích hợp với nó. Tổng chi phí chỉ bằng khoảng một phần năm so với việc xây dựng tùy chỉnh toàn bộ, và họ đã đưa vào vận hành trong bốn tháng thay vì mười tám tháng.

Câu hỏi 2: Quy trình cơ bản ổn định đến mức nào, và bạn thực sự hiểu nó đến đâu?

Phần mềm tùy chỉnh là một hóa thạch của những yêu cầu tồn tại vào thời điểm bạn xây dựng nó. Nếu những yêu cầu đó thay đổi sáu tháng một lần, phần mềm sẽ trở thành một cối xay bảo trì. Nếu bạn chưa hiểu đầy đủ các yêu cầu khi bắt đầu, phần mềm sẽ trở thành một tượng đài cho những giả định sớm nhất và mơ hồ nhất của bạn.

Các sản phẩm có sẵn hấp thụ sự biến động này thay cho bạn. Khi luật thuế thay đổi, nhà cung cấp phần mềm kế toán sẽ tung ra bản cập nhật. Khi một phương thức thanh toán mới trở nên phổ biến, nền tảng thương mại điện tử của bạn sẽ bổ sung nó. Bạn trả một khoản phí đăng ký để đổi lấy việc người khác lo lắng về các phần đang biến động.

Xây dựng phần mềm tùy chỉnh có ý nghĩa khi quy trình đã ổn định và được hiểu rõ, hoặc khi chính sự biến động là lợi thế cạnh tranh của bạn và bạn cần kiểm soát lộ trình phát triển. Nó hiếm khi có ý nghĩa khi doanh nghiệp vẫn đang tìm hiểu quy trình đó thực sự là gì. "Chúng ta sẽ xây dựng và tinh chỉnh dần" nghe có vẻ agile, nhưng trên thực tế điều này có nghĩa là trả tiền để khám phá các yêu cầu theo cách khó khăn — với một codebase phải được refactor mỗi khi bạn học được điều mới.

Một phép kiểm tra trực giác hữu ích: bạn có thể viết một bản mô tả hai trang về cách quy trình này hoạt động hôm nay, bao gồm tất cả các trường hợp biên, mà không có ai từ bộ phận vận hành phải sửa lại không? Nếu không, bạn chưa hiểu quy trình đủ rõ để xây dựng cho nó. Hãy mua thứ gì đó linh hoạt, vận hành quy trình trên nó trong một năm, và xem xét lại câu hỏi khi thực tế đã dạy bạn điều gì thực sự quan trọng.

Câu hỏi 3: Tổng chi phí thành thật trong năm năm là bao nhiêu, không chỉ là giá niêm yết?

Đây là nơi hầu hết các phân tích xây-hay-mua đi chệch hướng. Các đội so sánh phí đăng ký hàng năm của một sản phẩm SaaS với ước tính phát triển một lần cho một bản xây dựng tùy chỉnh, nhận thấy bản tùy chỉnh rẻ hơn trong năm đầu tiên, và tuyên bố chiến thắng. Rồi năm thứ hai đến.

Phần mềm tùy chỉnh có ba nhóm chi phí hiếm khi xuất hiện trong ước tính ban đầu. Đầu tiên là bảo trì liên tục: sửa lỗi, vá bảo mật, nâng cấp dependency, chi phí hạ tầng, và các kỹ sư hiểu codebase mà không thể dễ dàng thay thế. Một quy tắc hợp lý là chi phí bảo trì hàng năm rơi vào khoảng 15 đến 25 phần trăm của chi phí xây dựng ban đầu, mỗi năm, mãi mãi. Thứ hai là tiến hóa: các tính năng bạn chưa phát hành ở phiên bản một, các tích hợp với những công cụ bạn áp dụng sau này, việc thiết kế lại khi UI ban đầu bắt đầu lỗi thời. Thứ ba là chi phí cơ hội: mỗi giờ đội ngũ kỹ thuật của bạn dành để bảo trì các công cụ nội bộ là một giờ họ không dành cho phần mềm thực sự tạo ra doanh thu.

Phần mềm có sẵn cũng có những chi phí ẩn riêng. Cấp phép theo đầu người tăng đau đớn khi bạn phát triển. Công việc tích hợp để kết nối công cụ với phần còn lại trong stack của bạn. Phí tùy chỉnh khi cấu hình tiêu chuẩn không hoàn toàn phù hợp. Chi phí đào tạo. Chi phí chuyển đổi khi nhà cung cấp tăng giá hoặc bị mua lại. Và chi phí chiến lược của việc xây dựng một quy trình kinh doanh trên một nền tảng mà bạn không kiểm soát.

Một phân tích tổng chi phí sở hữu trong năm năm nghiêm túc thường trông như thế này. Với con đường mua, hãy lấy phí đăng ký hàng năm, nhân với năm, cộng chi phí tích hợp và tùy chỉnh, cộng chi phí đào tạo, cộng đệm 20 phần trăm cho việc tăng giá, và cộng chi phí dự kiến khi phải di dời nếu nhà cung cấp trở nên không thể sử dụng được nữa. Với con đường xây, hãy lấy ước tính phát triển ban đầu, nhân với 1.5 để tính đến việc ước tính thấp cổ điển, cộng thêm 20 phần trăm mỗi năm cho bảo trì và tiến hóa, và cộng chi phí đầy đủ của các kỹ sư sẽ sở hữu nó. Sau đó so sánh hai con số với vẻ mặt nghiêm túc.

Thông thường, phương án mua sẽ rẻ hơn trong ba năm đầu và phương án xây sẽ rẻ hơn trong năm thứ tư và năm thứ năm, giả sử hệ thống tùy chỉnh được xây dựng tốt. Nhưng rẻ hơn không phải là điểm mấu chốt. Điểm mấu chốt là nhìn thấy những con số thực sự trước khi bạn cam kết.

Câu hỏi 4: Dự án này thực sự có thể hấp thụ bao nhiêu rủi ro?

Mọi dự án phần mềm đều mang rủi ro. Xây dựng tùy chỉnh mang rủi ro về vượt ngân sách, về việc phát hành thứ gì đó không hoạt động, về việc mất các kỹ sư hiểu nó, và về việc xây dựng hoàn toàn sai thứ. Việc mua sản phẩm có sẵn mang rủi ro bị khóa vào nhà cung cấp, trả tiền cho các tính năng không bao giờ dùng, không thể thay đổi một quy trình không còn phù hợp nữa, và nhà cung cấp đóng cửa hoặc thay đổi hướng đi.

Câu hỏi là bạn có thể chịu được những rủi ro nào. Một startup được tài trợ tốt đang chạy đua để chứng minh product-market fit không thể chi trả cho một cuộc xây dựng tùy chỉnh kéo dài mười tám tháng cho bất cứ thứ gì ngoại trừ chính sản phẩm cốt lõi. Một tổ chức tài chính được quản lý chặt chẽ không thể để quy trình tuân thủ của mình chạy trên một sản phẩm SaaS có thể thay đổi chính sách data residency vào năm sau. Một nhà sản xuất tầm trung với đội ngũ IT tinh gọn không thể trở thành người bảo trì duy nhất của một ERP đặt riêng.

Một cách suy nghĩ hữu ích là hình dung dự án diễn ra tồi tệ. Nếu bản xây dựng tùy chỉnh chậm mười hai tháng và tăng gấp đôi chi phí, doanh nghiệp có sống sót không? Nếu nhà cung cấp SaaS tăng giá gấp đôi hoặc đóng cửa dòng sản phẩm, bạn có thể di dời khỏi nó nhanh đến mức nào? Con đường mà kịch bản xấu nhất còn có thể sống sót thường là con đường đúng, ngay cả khi kịch bản kỳ vọng trông tệ hơn một chút trên giấy tờ.

Một mô hình chúng tôi thường khuyến nghị: mua cho 80 phần trăm rủi ro và không tạo khác biệt, và chỉ xây cho 20 phần trăm thực sự tạo ra khác biệt cho bạn. Cách tiếp cận hybrid này mang lại cho bạn sự tin cậy và tốc độ của các sản phẩm đã được chứng minh ở những nơi mà độ tin cậy quan trọng nhất, và dành công việc đắt đỏ, rủi ro của phát triển tùy chỉnh cho những nơi tùy chỉnh thực sự có giá trị. Việc tích hợp giữa hai bên là công việc thực sự, nhưng đó là công việc có ranh giới — và nó bảo vệ bạn khỏi hai chế độ thất bại phổ biến nhất: xây tất cả và không phát hành gì, hoặc mua tất cả và trông giống như mọi công ty khác trong ngành.

Câu hỏi 5: Bạn có năng lực tổ chức để sở hữu phần mềm này không?

Câu hỏi này giết chết nhiều dự án phần mềm tùy chỉnh hơn bất kỳ thách thức kỹ thuật nào. Xây dựng phần mềm là phần dễ. Sở hữu nó trong thập kỷ tiếp theo mới là phần khó.

Sở hữu phần mềm tùy chỉnh có nghĩa là có các kỹ sư trong biên chế hiểu nó, các product manager ưu tiên lộ trình của nó, các designer phát triển giao diện của nó, QA kiểm thử nó, và bộ phận vận hành chạy hạ tầng của nó. Có nghĩa là lập ngân sách cho việc bảo trì nó hàng năm, ngay cả khi không có tính năng mới rõ ràng để biện minh cho khoản chi. Có nghĩa là đưa ra các đánh đổi khi một lỗi nghiêm trọng xuất hiện giữa một đợt ra mắt sản phẩm lớn. Và có nghĩa là chấp nhận rằng khi đội ngũ ban đầu chuyển đi, ai đó mới phải được trả tiền để học một codebase không tồn tại ở bất kỳ nơi nào khác trên thế giới.

Hầu hết các doanh nghiệp dưới 200 nhân viên đánh giá thấp chi phí này một cách nghiêm trọng. Họ tưởng tượng rằng một khi phần mềm được xây dựng, nó sẽ tự chạy. Nó sẽ không. Phần mềm là một khu vườn, không phải một tượng đài. Nó cần chăm sóc liên tục nếu không sẽ trở nên um tùm, không an toàn, và cuối cùng không thể sử dụng được.

Phần mềm có sẵn chuyển chi phí sở hữu này ra ngoài cho nhà cung cấp. Đó là một phần lớn những gì bạn đang trả tiền. Phí đăng ký không chỉ dành cho phần mềm — nó dành cho việc hàng trăm kỹ sư đang giữ cho nó sống thay cho bạn, và bạn có thể rời đi mà không để lại code mồ côi phía sau.

Nếu tổ chức của bạn không có, và không thể thực tế thuê được, một đội nhỏ chuyên trách sở hữu phần mềm sau khi ra mắt, đừng xây tùy chỉnh. Ngay cả một hệ thống được xây dựng tốt cũng sẽ suy tàn nếu không có chủ sở hữu, và một hệ thống đang suy tàn vận hành doanh nghiệp của bạn là một cuộc khủng hoảng chuyển động chậm.

Một khung ra quyết định thực tiễn

Gộp năm câu hỏi lại với nhau và bạn có một khung làm việc. Vẽ một ma trận hai-nhân-hai đơn giản. Ở một trục, đánh dấu mức độ trọng tâm của quy trình đối với lợi thế cạnh tranh của bạn. Ở trục còn lại, đánh dấu mức độ ổn định và được hiểu rõ của quy trình.

Giá trị chiến lược cao, độ ổn định cao: đây là điểm ngọt cho tùy chỉnh. Bạn biết mình cần gì, và những gì bạn cần là một lợi thế thực sự. Xây nó, sở hữu nó, đầu tư vào nó.

Giá trị chiến lược cao, độ ổn định thấp: đây là vùng nguy hiểm. Bạn biết nó quan trọng, nhưng bạn chưa biết nó nên trông như thế nào. Hãy mua công cụ linh hoạt nhất hiện có, vận hành trên nó trong mười hai đến mười tám tháng, và xem xét lại câu hỏi xây dựng khi quy trình đã ổn định.

Giá trị chiến lược thấp, độ ổn định cao: đây là lãnh thổ mua theo sách giáo khoa. Kế toán, HR, email, CRM tiêu chuẩn. Chọn một sản phẩm được hỗ trợ tốt, tích hợp nó, và không bao giờ nghĩ về nó nữa.

Giá trị chiến lược thấp, độ ổn định thấp: đây là nơi bạn nên cưỡng lại thôi thúc giải quyết vấn đề bằng phần mềm ngay từ đầu. Hãy cố gắng giải quyết bằng quy trình, hoặc một bảng tính, hoặc một con người, cho đến khi bạn hiểu nó đủ rõ để biết liệu nó có xứng đáng với khoản đầu tư thực sự hay không.

Đặt các câu hỏi về chi phí, rủi ro và quyền sở hữu lên trên ma trận này và câu trả lời thường trở nên rõ ràng. Khi không, chính sự mơ hồ đó là thông tin: nó có nghĩa là quy trình không đủ quan trọng để biện minh cho cuộc tranh luận, và bạn nên mua phương án hợp lý rẻ nhất và chuyển sang các quyết định quan trọng hơn.

Điểm chung giữa procurement tốt và product engineering tốt

Các lãnh đạo phần mềm giỏi nhất mà chúng tôi làm việc cùng đối xử với xây-hay-mua như một quyết định danh mục liên tục, không phải một phán quyết một lần. Họ thường xuyên rà soát các công cụ nội bộ và hỏi liệu mỗi công cụ có còn xứng đáng với khoản đầu tư đang nhận hay không. Họ thường xuyên rà soát các hợp đồng nhà cung cấp và hỏi liệu có bất kỳ hợp đồng nào đã trở nên đủ quan trọng để đáng được thay thế bằng bản tùy chỉnh, hoặc đủ tầm thường để được thay thế bằng thứ gì đó rẻ hơn hay không. Họ cưỡng lại hai mặc định lười biếng: "chúng ta nên xây cái này vì đội của chúng ta thông minh" và "chúng ta nên mua cái này vì xây thì quá khó."

Câu trả lời thành thật gần như luôn là câu trả lời nhàm chán. Mua hàng hóa phổ thông, xây phần tạo lợi thế, tích hợp cẩn thận, và xem xét lại sự kết hợp mỗi năm khi doanh nghiệp thay đổi. Hầu hết lợi thế cạnh tranh trong phần mềm không đến từ bất kỳ quyết định anh hùng đơn lẻ nào mà đến từ kỷ luật đưa ra quyết định nhỏ đúng đắn, lặp đi lặp lại, trong suốt một thập kỷ.

Nếu bạn đang giải quyết một quyết định xây-hay-mua cụ thể và muốn có thêm một cặp mắt nhìn vào mô hình chi phí hoặc kiến trúc tích hợp, đó chính xác là loại công việc mà một đối tác giàu kinh nghiệm có thể giúp đỡ — không phải để bán cho bạn một bản xây hay một bản mua, mà để giúp bạn nhìn thấy các đánh đổi rõ ràng trước khi cam kết. Kết quả tốt nhất là một quyết định mà bạn vẫn hài lòng ở năm thứ ba, dù đi theo hướng nào.