Tái kiến trúc năng lực IT từ RUN đến GROW

IT cần đảm bảo hệ thống chạy ổn định và xử lý sự cố nhanh nhất có thể

Trong một nhà máy quy mô trung bình lớn, nơi biến động xảy ra mỗi ngày, mọi ưu tiêu đều xoay quanh ba yếu tố: sản xuất, chất lượng sản phẩm, và lead time. IT thường không được nhìn như trung tâm của vận hành, mà là một bộ phận hỗ trợ. Kỳ vọng dành cho IT rất rõ ràng và thực tế:

“IT cần đảm bảo hệ thống chạy ổn định và xử lý sự cố nhanh nhất có thể.”

Từ kỳ vọng đó, một cách vận hành tự nhiên: người dùng gọi trực tiếp IT, hoặc nhắn qua bất kỳ kênh nào thuận tiện, hoặc liên hệ người IT họ “quen”.

Ban đầu, cách làm việc này có vẻ hiệu quả: nhanh chóng, ít thủ tục, tập trung vào hành động. Nhưng khi doanh nghiệp lớn dần, sự “linh hoạt” này bắt đầu tạo ra rủi ro vân hành….

Khi mọi việc đều “urgent”

Một tình huống rất quen thuộc trong nhiều doanh nghiệp:

IT đang xử lý sự cố tại khu vực sản xuất vì máy không gửi dữ liệu lên SAP. Trong lúc đó, một yêu cầu reset password từ HR xuất hiện vì cần gửi gấp email cho ứng viên Giám đốc Tài chính. Đồng thời, trưởng bộ phận thu mua cũng cần IT hỗ trợ sửa file Excel để kịp gửi thông tin cho nhà cung cấp.

Vấn đề không nằm ở việc ai đúng, ai sai. Vấn đề là mọi yêu cầu đều được gắn nhãn “gấp”, nhưng đội IT lại thiếu tiêu chí ưu tiên dựa trên tác động business.

Khi không có nguyên tắc phân loại, IT rất dễ bị kéo vào trạng thái phản ứng liên tục. Việc nào cũng gấp. Ai cũng cần được hỗ trợ ngay. Và cuối cùng, đội IT không còn đủ năng lực để tập trung vào những sự cố thực sự ảnh hưởng đến vận hành.

Đội IT không thể phối hợp vì thông tin phân tán

Ở nhiều tổ chức, thông tin xử lý sự cố nằm rải rác trong từng cá nhân.

Một lỗi truyền dữ liệu có thể đã từng xảy ra và được xử lý bởi một nhân viên IT khác. Nhưng người đó không nắm được yêu cầu hiện tại, hoặc không biết đồng đội đang cần hỗ trợ. Trong khi đó, một người khác lại đang xử lý một yêu cầu “gấp không kém”.

Kết quả là đội IT tồn tại về mặt tổ chức, nhưng vận hành như những cá nhân riêng lẻ.

Khi thông tin phân tán, lịch sử xử lý không được ghi nhận và quy trình không rõ ràng, IT khó phối hợp, khó học từ lỗi lặp và khó cải thiện chất lượng dịch vụ.

IT Head thiếu dữ liệu để đối thoại với business

Trong khi kỳ vọng của business tăng như một điều tất yếu: cải tiến quy trình, tự động hóa, sử dụng dữ liệu để ra quyết định, triển khai các giải pháp số- v.v… Thì vận hành IT lại chưa trả lời được các câu hỏi cơ bản: IT đang bận vì cái gì? Đâu nhóm yêu cầu chiếm nhiều thời gian nhất? Sự cố nào lặp lại nhiều nhất? Điểm nghẽn nào lớn nhất nằm ờ quy trình, con người hay hệ thống? Cần cải thiện ở đâu?

Nếu IT chưa kiểm soát tốt lớp vận hành hàng ngày, rất khó có thể thuyết phục business tin tưởng vào các sáng kiến lớn hơn.

“Nếu RUN chưa ổn định, thì dựa vào đâu để IT phản hồi về kỳ vọng GROW của business?”

Thiết lập lại nguyên tắc vận hành IT: Từ linh hoạt tự phát đến vận hành kiểm soát

Để IT không trở thành điểm nghẽn khi doanh nghiệp muốn cải tiến, một thực tế cần phải chấp nhận:

“Không thể vừa “linh hoạt tuyệt đối” cho người dùng, vừa “kiểm soát vận hành ổn định IT, minh bạch và có kiểm soát” cho tổ chức.”

Từ đó, quyết định trade-off được đưa ra là một tất yếu:

Để kiểm soát được RUN, IT cần thực hiện ba thay đổi quan trọng:

1. Chuẩn hóa cách tiếp nhận yêu cầu, giảm xử lý “tùy hứng” qua chat và điện thoại.

2. Thiết lập nguyên tắc ưu tiên dựa trên tác động đến business

3. Chuyển từ tư duy “xử lý việc phát sinh” sang tư duy dịch vụ và ứng dụng khung quản lý dịch vụ CNTT.

Điều này đồng nghĩa với:

1. Người dùng phải thay đổi thói quen.

2. Xuất hiện sự kháng cự ban đầu.

3. Cảm giác chậm hơn.

Nhưng đổi lại, tổ chức đạt được những lợi ích quan trọng

1. Workflow và workload IT trở nên rõ ràng.

2. IT xử lý đúng việc thực sự“gấp” và theo mức độ ảnh hưởng đến business.

3. Giảm gián đoạn trong công việc, lỗi lặp.

4. Có dữ liệu để ra quyết định và cải thiện vận hành IT.

Thiết lập 4 quy trình cốt lõi để kiểm soát RUN

Không cần bắt dầu bằng một hệ thống quá phức tạ. Điều quan trọng là chọn đúng một số quy trình đủ sức tạo kỷ luật vận hành và thay đổi hành vi của cả IT lẫn người dùng:

1. Quản lý sự cố và yêu cầudịch vụ.

Cần lưu ý, người dùng sẽ không quan tâm đâu là sự cố hay dịch vụ, đối với họ, tất cả đều là “yêu cầu IT”. Vì vậy, trải nghiệm gửi yêu cầu cần được thiết kế đơn giản từ góc nhìn business. IT sẽ cần phân loại sau đó,.

Service Catalog cũng cần được thiết kế dựa trên góc nhìn của người dùng và dễ dàng tìm kiếm. Ví dụ, khi tạo tài khoản SAP, người dùng sẽ vào danh mục “SAP”, thay vì phải hiểu khái niệm và vào danh mục “Quản lý tài khoản/truy cập”.

Nguyên tắc ưu tiên cần được thống nhất với ban lãnh đạo, thiết lập mặc định trên hệ thống và thông báo rõ ràng ở một số form khi người dùng gửi yêu cầu trên hệ thống, sự minh bạch này giúp người dùng tự thiết lập được ngưỡng kỳ vọng phù hợp, gián tiếp giảm áp lực lên đội ngũ IT.

Sự linh hoạt vẫn cần được tồn tại, nhưng phải có nguyên tắc. Ví dụ, hotline trực tiếp chỉ nên dùng cho các sự cố đang ảnh hưởng đến sản xuất hoặc hoạt động kinh doanh trọng yếu.

2. Quản lý vấn đề.

Quản lý vấn đề giúp IT đi xa hơn việc “chữa cháy” hàng ngày để nhìn vào nguyên nhân gốc của các lõi lặp lại.

Viêcj này gián tiếp tăng sự tin tưởng của người dùng vào dịch vụ IT khi các vấn đề cốt lõi được nhận dạng và xử lý, từ đó các lỗi lặp đi lặp lại được loại bỏ hoàn toàn hoặc rút ngắn thời gian xử lý và cải thiện chất lượng dịch vụ một cách bền vững. Khi đó IT không chỉ phản ứng nhanh hơn, mà còn chứng minh được năng lực cải tiến.

3. Quản lý sự thay đổi.

Mỗi thay đổi trong hệ thống IT đều có thể tạo ra tác động đến business.

Vì vậy, thay đổi cần được kiểm soát. IT cần đánh giá tác động, lập kế hoạch, truyền thông và chuẩn bị phương án xử lý rủi ro trước khi thực hiện thay đổi trong hạ tầng và dịch vụ IT

Mục tiêu không phải là làm chậm thay đổi. Mục tiêu là đảm bảo thay đổi diễn ra có kiểm soát, giảm gián đoạn và bảo vệ vận hành kinh doanh

4. Quản lý nhu cầu.

Quản lý nhu cầu là cầu nối giữa RUN và GROW

Ngoài các sự cố và yêu cầu dịch vụ hàng ngày, IT cần hiểu business đang thực sự mong đợi điều gì: cải tiến quy trình nào, dữ liệu nào cần được chuẩn hóa, điểm nghẽn nào đang làm giảm năng suất

Khi quản lý tốt nhu cầu, IT không chỉ “làm đúng việc được yêu cầu”, mà bắt đầu “làm đúng việc tạo giá trị”.

Công cụ là cần thiết, nhưng không phải điểm bắt đầu

Việc thiết lập công cụ quản lý dịch vụ IT là cần thiết, nhưng không nên bắt đầu bằng tư duy mua công cụ.

1. Kỷ luật: mọi yêu cầu cần được ghi nhận, mọi thay đổi cần được kiểm soát.

2. Minh bạch: thông tin rõ ràng và nhất quán, người dùng biết trạng thái yêu cầu, IT biết quy trình xử lý.

3. Hướng dữ liệu: Dữ liệu vận hành trở thành đầu vào cho việc ra quyết định cải tiến.

4. Đơn giản hóa: thiết lập automation giúp giảm cảm giác “chậm” và giảm “kháng cự” ban đầu.

Chỉ cần chọn đúng 20% quy trình quan trọng và tối giản chúng, IT đã có thể tạo ra 80% mức độ ổn định cần thiết cho vận hành và mang lại giá trị thực sự cho Doanh nghiệp.

Đo lường hiệu quả dịch vụ IT từ góc nhìn Business

Tái kiến trúc năng lực IT cần đi kèm với thước đo rõ ràng. Nhưng KPI không nên chỉ xoay quanh góc nhìn kỹ thuật.

Từ góc nhìn business, IT nên theo dõi:

- Tỷ lệ sự cố ảnh hưởn đến vận hành/sản xuất.

- Thời gian phục hồi vận hành, sản xuất sau sự cố CNTT.

- Thời gian phản hồi ban đầu đối với yêu cầu.

- Thời gian hoàn tất yêu cầu dịch vụ (ví dụ: quản lý truy cập, quy trình cấp phát thiết bị, v.v…)

Từ góc nhìn kỹ thuật, IT có thể theo dõi

- Phân bổ yêu cầu của từng danh mục dịch vụ để xác định 20% dịch vụ cần cải tiến nhất.

- Uptime hệ thống để cải thiện sự ổn định của dịch vụ CNTT.

Điểm quan trọng là KPI phải trở thành công cụ quản trị, không chỉ là số liệu báo cáo.

Khi KPI được thiết kế từ góc nhìn business, IT và business bắt đầu có một ngôn ngữ chung để đối thoại về giá trị.

Checklist cải tiến năng lực CNTT trong 4 tuần

Nguyên tắc xuyên sốt:

- Không tối ưu mọi thứ: tập trung vào 20% vấn đề tạo ra 80% ảnh hưởng.

- Không bắt đầu bằng công cụ. Hãy bắt đầu bằngdữ liệu.

- KPI cần có ý nghĩa đến business, không chỉ có ý nghĩa với IT

Tuần 1: Thiết lập Baseline

Mục tiêu: Có dữ liệu tối thiểu, không cần hoàn hảo.

Việc cần làm

- 100% yêu cầu cần được ghi nhận dù người dùng gửi hoặc do IT nhập nếu chưa đào tạo người dùng.

- Phân loại yêu cầu: priority theo mức độ ưu tiên, tác động, mức độ khẩn cấp, , danh mục business view, danh mục kỹ thuật

- Ghi nhận thời gian phản hồi ban đầu, thời gian hoàn tất.

- Thiết lập KPI tối thiểu

Kết quả mong đợi: IT nhìn được bức tranh thật về tình trạng vận hành dịch vụ CNTT.

Tuần 2: Tìm 20% vấn đề dựa trên dữ liệu

Mục tiêu: Tìm ra pattern chung từ dữ liệu

Việc cần làm

- Xác định 20% dịch vụ tạo ra nhiều ticket nhất.

- Tìm các sự cố/yêu cầu nào lặp lại nhiều nhất.

- Phân tích điểm nào làm tăng thời gian hoàn tất yêu cầu

- Chọn 2-3 điểm nghẽn lớn nhất để xử lý

Kết quả mong đợi: IT biết rõ cần cải tiến ở đâu trước.

Tuần 3: Xử lý điểm nghẽn lớn nhất

Mục tiêu: Cải tiến 1-2 điểm nghẽn lớn nhất có tác động lớn nhất

Việc cần làm

- Ghi nhận KPI trước khi cải tiến

- Chuẩn hóa lại quy trình hoặc biểu mẫu liên quan

- Tạo hướng dẫn ngắn hoặc knowledge base cho lỗi/ yêu cầu lặp lại

- Ap dụng automation đơn giản nếu có thể

- Truyền thông rõ thay đổi đến người dùng liên quan

Kết quả mong đợi: Điểm nghẽn lớn nhất bắt đầu giảm tải và có bằng chứng cải thiện.

Tuần 4: Đo lại và chuẩn hóa

Mục tiêu: Chứng minh cải tiến có hiệu quả và biến cải tiến thành năng lực mới

Việc cần làm

- So sánh KPI trước và sau cải tiến.

- Chuẩn hóa quy trình/cách làm đã chứng minh hiệu quả

- Cập nhật Knowlegebase Base và decision log

- Xác định điểm nghẽn tiếp theo cho chu kỳ cải tiến mới..

Kết quả mong đợi: Biến cải tiến thành năng lực mới, không phải nỗ lực tạm thời.

Một đội IT tinh gọn vẫn có thể vận hành chuyên nghiệp nếu biết chọn đúng 20% quy trình tạo ra 80% sự ổn định.

Khi IT kiểm soát được RUN, tổ chức sẽ có nền tảng tốt hơn để bước sang GROW: tự động hóa, cải tiến quy trình, dữ liệu, AI và chuyển đổi số.

Năng lực IT không chỉ nằm ở khả năng xử lý sự cố nhanh. Năng lực IT còn nằm ở khả năng tạo ra kỷ luật vận hành, minh bạch dữ liệu và niềm tin để business yên tâm trao cho IT những bài toán lớn hơn.

Next Action

1. Hiện nay, đội IT của bạn đang dành phần lớn thời gian cho nhóm yêu cầu nào?

2. Những yêu cầu “urgent” trong tổ chức đã được phân loại theo tác động business hay vẫn chủ yếu dựa trên cảm nhận của người dùng?

3. Đâu là 2–3 điểm nghẽn đang khiến IT bị kéo vào trạng thái phản ứng liên tục?

4. Dữ liệu vận hành IT hiện tại đã đủ để IT Head đối thoại với business về ưu tiên, nguồn lực và giá trị chưa?

5. Trong 4 tuần tới, đội IT có thể bắt đầu ghi nhận và phân loại 100% yêu cầu theo cách đơn giản nhất như thế nào?

6. Quy trình nào cần được chuẩn hóa đầu tiên để giúp IT kiểm soát tốt hơn lớp RUN và tạo nền tảng cho GROW?