Cách cân bằng chiến lược công nghệ ngắn hạn và dài hạn

Cách quản trị phù hợp là đánh giá mỗi quyết định trên hai chiều: business outcome hiện tại và technology capability tích lũy cho tương lai. Danh mục công nghệ chỉ thực sự cân bằng khi doanh nghiệp vừa đạt được kết quả có thể đo lường trong thời gian đủ ngắn, vừa duy trì kiến trúc, dữ liệu, bảo mật, khả năng tích hợp và năng lực đội ngũ ở mức cho phép doanh nghiệp tiếp tục thay đổi với chi phí hợp lý.

Cân bằng công nghệ là bài toán danh mục đầu tư, không phải lựa chọn giữa ngắn hạn và dài hạn

Mục tiêu ngắn hạn thường gắn với một kết quả tương đối cụ thể: triển khai một chức năng mới, tự động hóa một quy trình, giảm chi phí vận hành, cải thiện trải nghiệm khách hàng hoặc đáp ứng yêu cầu kinh doanh mới. Giá trị của chúng dễ quan sát vì khoảng thời gian từ đầu tư đến kết quả tương đối ngắn.

Đầu tư dài hạn lại thường tạo ra năng lực thay vì doanh thu trực tiếp. Chuẩn hóa dữ liệu, hiện đại hóa kiến trúc, xây dựng API, nâng cấp nền tảng, cải thiện bảo mật, phát triển năng lực kỹ thuật hoặc giảm nợ kỹ thuật có thể chưa tạo ra một khoản doanh thu riêng ngay lập tức. Giá trị xuất hiện khi nhiều sáng kiến sau đó được triển khai nhanh hơn, ổn định hơn hoặc với chi phí thấp hơn.

Vì hai loại giá trị khác nhau, dùng cùng một tiêu chí để lựa chọn sẽ tạo thiên lệch. Nếu mọi sáng kiến đều phải chứng minh hoàn vốn trong vài tháng, các khoản đầu tư nền tảng dễ bị trì hoãn. Ngược lại, nếu các chương trình công nghệ dài hạn không phải chứng minh tác động đến hoạt động kinh doanh, doanh nghiệp có thể đầu tư lớn vào kiến trúc hoặc nền tảng nhưng tạo rất ít giá trị thực tế.

Do đó, đơn vị quản trị phù hợp không phải từng dự án riêng lẻ mà là toàn bộ danh mục. Một số khoản đầu tư có nhiệm vụ tạo kết quả ngay; một số khác giảm rủi ro hoặc tạo năng lực dùng chung; một số phải làm đồng thời cả hai.

Phân biệt mục tiêu ngắn hạn và dài hạn bằng loại giá trị mà công nghệ tạo ra

Thời gian không phải tiêu chí duy nhất để xác định một sáng kiến thuộc ngắn hạn hay dài hạn. Một dự án kéo dài 12 tháng vẫn có thể chủ yếu phục vụ mục tiêu trước mắt, trong khi một thay đổi kiến trúc thực hiện trong vài tuần có thể tạo năng lực được sử dụng nhiều năm.

Mục tiêu ngắn hạn nên được mô tả bằng outcome. Các chỉ số có thể gồm doanh thu tăng thêm, chi phí trên mỗi giao dịch, thời gian xử lý, tỷ lệ sử dụng tính năng, tỷ lệ lỗi hoặc thời gian đưa một thay đổi ra thị trường. Khi mục tiêu được gắn với outcome, doanh nghiệp có thể xác định khá rõ liệu đầu tư có giải quyết vấn đề hiện tại hay không.

Mục tiêu dài hạn nên được mô tả bằng capability. Ví dụ gồm khả năng tái sử dụng dịch vụ, mức độ chuẩn hóa dữ liệu, khả năng mở rộng hệ thống, tốc độ tích hợp sản phẩm mới, khả năng quan sát hệ thống, mức tự động hóa triển khai, mức độ kiểm soát bảo mật hoặc năng lực chuyên môn của đội ngũ.

Sự phân biệt này giải quyết một nhầm lẫn phổ biến: đầu tư dài hạn không đồng nghĩa với dự án lớn, còn đầu tư ngắn hạn không đồng nghĩa với giải pháp tạm thời. Một thay đổi nhỏ nhưng làm tăng khả năng tái sử dụng có thể là đầu tư dài hạn tốt. Ngược lại, một hệ thống lớn được triển khai chỉ để giải quyết yêu cầu riêng của một đơn vị mà không tạo năng lực dùng chung vẫn có thể mang bản chất ngắn hạn.

Phân bổ nguồn lực theo nhiều horizon thay vì để nhu cầu khẩn cấp chiếm toàn bộ ngân sách

Áp lực vận hành khiến nguồn lực công nghệ dễ bị hút vào các công việc có thời hạn gần. Khi từng yêu cầu khẩn cấp được xử lý riêng, doanh nghiệp vẫn có thể hoàn thành nhiều dự án nhưng phần năng lực nền tảng liên tục bị trì hoãn.

Một cách kiểm soát là chia danh mục thành các horizon rõ ràng. Chẳng hạn, doanh nghiệp có thể dùng 60% nguồn lực cho kết quả kinh doanh và vận hành hiện tại, 30% cho năng lực có giá trị trong trung hạn và 10% cho thử nghiệm hoặc năng lực chiến lược dài hạn. Tỷ lệ 60/30/10 chỉ là điểm khởi đầu để thiết kế danh mục, không phải benchmark chung cho mọi doanh nghiệp.

Doanh nghiệp đang xử lý sự cố nghiêm trọng có thể phải tăng tỷ trọng ngắn hạn. Công ty đang bước vào giai đoạn mở rộng nhanh có thể dành nhiều nguồn lực hơn cho nền tảng. Ngành chịu yêu cầu an toàn hoặc tuân thủ cao cũng cần một phần ngân sách dài hạn lớn hơn cho resilience, security và governance.

Điểm quan trọng không nằm ở một tỷ lệ cố định mà ở việc khóa trước một phần năng lực cho các mục tiêu không thể liên tục bị công việc ngắn hạn lấn át. Nếu phần đầu tư dài hạn chỉ được thực hiện khi còn ngân sách hoặc nhân lực dư, trên thực tế nó rất dễ trở thành bằng không.

Doanh nghiệp cũng nên đặt ngưỡng điều chỉnh. Ví dụ, nếu sự cố nghiêm trọng tăng liên tiếp, lead time của thay đổi kéo dài hoặc chi phí duy trì hệ thống cũ tăng nhanh, tỷ trọng dành cho hiện đại hóa và giảm nợ kỹ thuật cần được nâng lên thay vì tiếp tục bổ sung tính năng.

Mỗi sáng kiến ngắn hạn nên để lại một phần năng lực có thể sử dụng trong tương lai

Cân bằng hiệu quả nhất khi mục tiêu ngắn hạn và dài hạn không được triển khai thành hai dòng công việc hoàn toàn tách biệt. Doanh nghiệp có thể yêu cầu các dự án tạo kết quả gần hạn đồng thời đóng góp vào một năng lực dùng chung.

Ví dụ, khi triển khai chức năng bán hàng mới, nhóm công nghệ có thể đáp ứng yêu cầu kinh doanh trước mắt nhưng đồng thời chuẩn hóa API kết nối dữ liệu khách hàng. Khi tự động hóa một quy trình tài chính, doanh nghiệp có thể xây dựng cơ chế phân quyền và logging có khả năng tái sử dụng cho các quy trình tiếp theo. Khi triển khai AI cho một nghiệp vụ cụ thể, phần dữ liệu, kiểm soát truy cập và đánh giá chất lượng có thể được thiết kế thành thành phần dùng chung thay vì giải pháp riêng biệt.

Cơ chế này tạo ra hiệu ứng tích lũy. Dự án đầu tiên có thể phải chịu thêm một phần chi phí để xây dựng thành phần nền tảng, nhưng những dự án sau không phải giải quyết lại cùng vấn đề. Giá trị dài hạn vì vậy không nhất thiết phải chờ một chương trình chuyển đổi nhiều năm mới xuất hiện.

Tuy nhiên, không nên biến mọi dự án thành dự án nền tảng. Thiết kế quá tổng quát trước khi có nhu cầu thực tế làm tăng thời gian triển khai và có thể tạo ra kiến trúc phức tạp không cần thiết. Chỉ nên đầu tư khả năng tái sử dụng khi có dấu hiệu hợp lý rằng thành phần đó sẽ phục vụ nhiều use case, giảm một rủi ro quan trọng hoặc loại bỏ một điểm nghẽn có tính hệ thống.

Dùng architecture guardrail để tốc độ ngắn hạn không tạo ra chi phí dài hạn

Một nguyên nhân phổ biến khiến mục tiêu ngắn hạn phá vỡ chiến lược dài hạn là mỗi dự án được tối ưu riêng. Nhóm dự án chọn công nghệ, cấu trúc dữ liệu hoặc phương thức tích hợp nhanh nhất cho yêu cầu của mình; tổng hợp nhiều quyết định như vậy có thể tạo ra hệ thống khó bảo trì.

Architecture guardrail giải quyết vấn đề bằng cách xác định một số giới hạn không nên bị phá vỡ, trong khi vẫn cho đội triển khai quyền lựa chọn bên trong các giới hạn đó. Guardrail có thể bao gồm nguyên tắc quản trị API, tiêu chuẩn dữ liệu, yêu cầu logging, quản lý danh tính, bảo mật, khả năng quan sát hoặc điều kiện để đưa thêm một công nghệ mới vào stack.

Guardrail khác với quy trình phê duyệt nặng nề. Mục tiêu là giảm số quyết định phải tranh luận lại trong từng dự án. Khi tiêu chuẩn dùng chung đã rõ, nhóm triển khai có thể ra quyết định nhanh hơn mà vẫn giữ tính nhất quán của hệ thống.

Ngoại lệ vẫn cần tồn tại. Một cơ hội kinh doanh có thời hạn rất ngắn đôi khi buộc doanh nghiệp chấp nhận giải pháp tạm thời. Trong trường hợp đó, ngoại lệ nên có người chịu trách nhiệm, phạm vi, mức rủi ro và thời hạn xử lý rõ ràng. Nếu không có điều kiện kết thúc, “giải pháp tạm thời” rất dễ trở thành thành phần lâu dài của kiến trúc.

Theo dõi đồng thời KPI kinh doanh và KPI sức khỏe công nghệ

Một chiến lược dễ nghiêng về ngắn hạn khi bảng điều hành chỉ hiển thị doanh thu, chi phí và tiến độ dự án. Những con số đó phản ánh kết quả hiện tại nhưng không cho biết khả năng tiếp tục tạo kết quả trong tương lai đang cải thiện hay suy giảm.

Doanh nghiệp nên sử dụng hai tầng chỉ số.

Tầng thứ nhất đo business outcome: time-to-value, mức độ sử dụng, doanh thu hoặc chi phí liên quan, năng suất quy trình, tỷ lệ chuyển đổi hay SLA nghiệp vụ.

Tầng thứ hai đo technology health và capability: lead time của thay đổi, tần suất triển khai, tỷ lệ triển khai thất bại, thời gian khôi phục sau sự cố, mức độ tự động hóa, số thành phần được tái sử dụng, tốc độ tăng nợ kỹ thuật hoặc chi phí vận hành trên một đơn vị giao dịch.

Các chỉ số như deployment frequency, lead time for changes, change failure rate và thời gian khôi phục cũng là nhóm thước đo được DORA sử dụng để đánh giá khả năng cung cấp phần mềm. Giá trị của chúng trong quản trị chiến lược nằm ở việc cho thấy tốc độ có đang được mua bằng sự bất ổn hay không.

Không cần tối ưu tất cả KPI cùng lúc. Nếu một nhóm tăng tốc độ phát hành nhưng change failure rate và thời gian khôi phục đều xấu đi, doanh nghiệp đang chuyển chi phí sang tương lai. Ngược lại, nếu hệ thống rất ổn định nhưng lead time kéo dài đến mức cơ hội kinh doanh bị bỏ lỡ, kiến trúc hoặc quy trình có thể đang tạo quá nhiều ma sát.

Đánh giá hai nhóm chỉ số cùng nhau giúp doanh nghiệp phân biệt tốc độ bền vững với tốc độ được tạo ra bằng cách tích lũy rủi ro.

Quản lý nợ kỹ thuật như một khoản nợ có chủ đích thay vì cố gắng loại bỏ hoàn toàn

Không phải mọi nợ kỹ thuật đều là quyết định sai. Trong một số tình huống, doanh nghiệp có thể chủ động chọn giải pháp đơn giản hơn để kiểm chứng thị trường, đáp ứng một thời hạn quan trọng hoặc tránh đầu tư lớn trước khi nhu cầu được xác nhận.

Vấn đề xuất hiện khi chi phí của quyết định đó không được theo dõi. Nợ kỹ thuật có xu hướng thể hiện qua thời gian phát triển dài hơn, lỗi lặp lại, chi phí vận hành tăng, khó thay đổi dữ liệu hoặc phụ thuộc vào một số ít nhân sự.

Vì vậy, thay vì mục tiêu mơ hồ như “xóa nợ kỹ thuật”, doanh nghiệp nên quản lý từng khoản nợ theo bốn yếu tố: giá trị đã nhận được khi chấp nhận nợ, chi phí tiếp tục duy trì, rủi ro nếu không xử lý và thời điểm nên trả nợ.

Một khoản nợ chỉ ảnh hưởng đến hệ thống sắp ngừng sử dụng có thể được chấp nhận. Một khoản nợ nằm trên nền tảng đang phục vụ phần lớn các sáng kiến tăng trưởng có mức ưu tiên khác hẳn.

Cách tiếp cận này tránh hai cực đoan: dành quá nhiều nguồn lực để đạt trạng thái kiến trúc “hoàn hảo”, hoặc liên tục hoãn hiện đại hóa cho đến khi tốc độ thay đổi giảm rõ rệt.

Thiết lập nhịp đánh giá để tỷ trọng ngắn hạn và dài hạn thay đổi theo bối cảnh

Danh mục công nghệ cân bằng tại một thời điểm không có nghĩa sẽ tiếp tục cân bằng sau sáu hoặc mười hai tháng. Thị trường, dòng tiền, mức tăng trưởng, rủi ro bảo mật và trạng thái của hệ thống đều thay đổi.

Doanh nghiệp có thể đánh giá danh mục theo quý, trong khi theo dõi các chỉ số vận hành quan trọng thường xuyên hơn. Mỗi kỳ đánh giá nên trả lời bốn câu hỏi:

1.    Các khoản đầu tư ngắn hạn có tạo outcome đã cam kết không

2.    Các năng lực dài hạn có thực sự được sử dụng hoặc làm giảm điểm nghẽn không

3.    Chất lượng, rủi ro và chi phí thay đổi của hệ thống đang đi theo hướng nào

4.    Có khoản đầu tư nào nên tăng, giảm, dừng hoặc chuyển sang horizon khác không

Điểm cần tránh là giữ nguyên dự án chỉ vì đã đầu tư nhiều. Một chương trình nền tảng không tạo ra adoption hoặc không còn phù hợp với chiến lược kinh doanh nên được xem xét lại giống như một sản phẩm không đạt kết quả. Đầu tư dài hạn không được miễn khỏi yêu cầu chứng minh giá trị.

Tương tự, một sáng kiến ngắn hạn tạo doanh thu tốt có thể xứng đáng được mở rộng, nhưng trước khi mở rộng cần đánh giá kiến trúc hiện tại có chịu được quy mô mới hay không. Khi cả outcome và capability cùng tham gia quyết định, danh mục có thể thay đổi mà không mất định hướng.

Biết khi nào nên nghiêng về ngắn hạn và khi nào phải bảo vệ dài hạn

Cân bằng không đồng nghĩa với duy trì tỷ trọng cố định trong mọi hoàn cảnh.

Doanh nghiệp có thể ưu tiên ngắn hạn hơn khi cần bảo vệ dòng tiền, xử lý gián đoạn kinh doanh, đáp ứng thay đổi pháp lý cấp bách, kiểm chứng một giả thuyết thị trường hoặc tận dụng cơ hội có thời hạn rõ ràng. Khi đó, tốc độ có giá trị lớn hơn mức tối ưu kiến trúc.

Ngược lại, cần tăng đầu tư dài hạn khi nhiều nhóm cùng gặp một điểm nghẽn, chi phí thay đổi tăng liên tục, sự cố lặp lại, dữ liệu phân mảnh cản trở nhiều sản phẩm, hệ thống không thể đáp ứng quy mô mới hoặc các ngoại lệ kiến trúc bắt đầu trở thành cách làm mặc định.

Một dấu hiệu quan trọng là marginal cost of change — chi phí để thực hiện thêm một thay đổi. Khi mỗi chức năng mới ngày càng mất nhiều thời gian, cần nhiều phối hợp hơn hoặc gây nhiều sự cố hơn dù độ phức tạp nghiệp vụ không tăng tương ứng, năng lực nền tảng có thể đã tụt lại phía sau nhu cầu kinh doanh.

Trong trường hợp đó, tiếp tục tối đa hóa output ngắn hạn thường chỉ làm vấn đề lớn hơn. Một phần nguồn lực cần được chuyển từ “thêm tính năng” sang “khôi phục khả năng thay đổi”.

Biến cân bằng ngắn hạn và dài hạn thành cơ chế ra quyết định

Chiến lược chỉ có tác dụng khi các nhóm biết cách xử lý một yêu cầu cụ thể. Doanh nghiệp có thể áp dụng một cơ chế đơn giản cho mọi khoản đầu tư công nghệ bằng cách đánh giá bốn chiều:

Một sáng kiến có giá trị hiện tại cao nhưng chi phí tương lai cũng cao không nhất thiết phải bị từ chối. Doanh nghiệp có thể vẫn triển khai nếu cơ hội đủ quan trọng, nhưng cần xác định rõ khoản nợ phát sinh và thời điểm xử lý.

Ngược lại, một sáng kiến tạo năng lực tương lai lớn nhưng chưa có use case rõ ràng cần được kiểm tra kỹ trước khi đầu tư. Công nghệ nền tảng chỉ tạo giá trị khi có nhu cầu sử dụng thực tế hoặc giải quyết một giới hạn đã được chứng minh.

Nhờ đó, “ngắn hạn hay dài hạn” không còn là tranh luận giữa bộ phận kinh doanh và công nghệ. Nó trở thành quyết định về giá trị nhận ngay, năng lực tích lũy, rủi ro chấp nhận và khả năng thay đổi còn lại sau quyết định.

Doanh nghiệp cân bằng chiến lược công nghệ ngắn hạn và dài hạn bằng cách quản trị đồng thời hai loại tài sản: kết quả kinh doanh hiện tại và khả năng thay đổi trong tương lai. Không có tỷ lệ đầu tư cố định phù hợp cho mọi tổ chức; tỷ trọng cần phản ánh trạng thái kinh doanh, mức nợ kỹ thuật, rủi ro và tốc độ tăng trưởng.

Một chiến lược bền vững vì vậy không yêu cầu doanh nghiệp hy sinh tốc độ để đổi lấy kiến trúc hoàn hảo. Nó yêu cầu mỗi quyết định nhanh phải biết mình đang tạo ra khoản nợ nào, mỗi khoản đầu tư dài hạn phải chứng minh năng lực nào được cải thiện, và toàn bộ danh mục phải được điều chỉnh khi dữ liệu cho thấy một trong hai phía bắt đầu lấn át phía còn lại.

:::