DITS: Cảm nhận sự chuyển hóa của bản thân

Xuất phát điểm của mình là một IT System Administrator. Công việc hằng ngày gắn với hệ thống, thiết bị, policy, compliance, và làm sao để mọi thứ chạy ổn định, không gây gián đoạn cho người dùng. Trong thế giới đó, mọi thứ khá rõ ràng: có vấn đề thì xử lý, có yêu cầu thì triển khai, làm càng nhanh càng tốt.

Nên khi bước vào DITS — một môn học về Digital & IT Strategy — phản xạ đầu tiên của mình vẫn rất “technical”. Nghe đến chuyển đổi số là mình nghĩ ngay đến hệ thống, công nghệ, và việc nên dùng giải pháp gì để tối ưu.

Tóm tắt nhanh: DITS không làm mình giỏi hơn ngay lập tức, nhưng nó giúp mình thấy rõ rằng giải pháp kỹ thuật chỉ là một phần. Điều quan trọng là hiểu đúng bài toán doanh nghiệp trước khi đi vào triển khai.

Một khoảnh khắc “khựng lại” trong đầu

Nhưng chỉ sau một vài buổi học đầu tiên, mình bắt đầu thấy “có gì đó không ổn”. Có những lúc mình ngồi trong buổi thảo luận hoặc khi team đang làm assignment, mình gần như tự động nghĩ đến solution. Ví dụ, khi nói về một doanh nghiệp đang gặp vấn đề trong vận hành, trong đầu mình sẽ bật ra ngay: có thể dùng automation, có thể triển khai thêm tool, hoặc cải thiện hệ thống hiện tại.

Nhưng khi bị hỏi lại: “vấn đề thật sự là gì?”, mình nhận ra là mình chưa trả lời được một cách chắc chắn.

Khoảnh khắc đó làm mình “khựng lại”.

Trước đây, mình luôn nghĩ nếu mình giải quyết tốt phần của mình thì tổng thể sẽ tốt lên. Nhưng khi bắt đầu nhìn dưới góc độ Business, mình thấy mọi thứ phức tạp hơn nhiều. Một hệ thống tốt chưa chắc tạo ra giá trị nếu nó không giải đúng bài toán. Một solution triển khai rất chuẩn vẫn có thể trở thành gánh nặng nếu tổ chức chưa sẵn sàng để vận hành nó.

Những câu hỏi đúng đã xuất hiện

Mình nhớ rõ nhất là lúc team “Nexus” làm case về một doanh nghiệp Logistic. Bản năng kỹ thuật khiến mình nghĩ ngay đến chuyện “họ nên dùng công nghệ gì”. Nhưng càng phân tích, càng nhìn vào Business Model, vào cách họ tạo doanh thu, vào chi phí và cách vận hành, mình mới thấy là câu hỏi đúng phải nằm trước đó rất lâu.

• Khách hàng của họ là ai?
• Hành vi của họ có đang thay đổi không?
• Điểm nghẽn trong vận hành nằm ở đâu?
• Nếu áp dụng công nghệ vào, họ có đủ năng lực để duy trì nó hay không?

Những câu hỏi này trước đây mình ít khi đặt ra, vì nó không trực tiếp thuộc phần việc của mình. Nhưng sau khi học, mình nhận ra nếu không hiểu những điều đó, thì bất kỳ giải pháp công nghệ nào mình đưa ra cũng chỉ là bồi đắp lên hệ thống, chứ chưa chắc đã tạo ra giá trị thật.

Thay đổi lớn nhất không nằm ở framework, mà ở cách mình tiếp cận vấn đề

Sự thay đổi lớn nhất của mình không nằm ở việc biết thêm framework, mà là ở cách mình tiếp cận vấn đề. Trước đây, khi nhận một yêu cầu triển khai Intune policy hay một giải pháp security, mình thường tập trung vào việc làm sao triển khai cho đúng, cho đủ và cho nhanh. Bây giờ, mình bắt đầu dừng lại một chút và tự hỏi:

• Việc này đang giải quyết vấn đề cụ thể nào?
• Nếu deploy xong thì ai sẽ được benefit rõ nhất?
• Nếu không làm thì có thực sự ảnh hưởng không?

Có một ví dụ rất thực tế trong công việc. Trước đây, khi nhận yêu cầu tăng cường security trên endpoint, cách mình làm là bật thêm policy, siết chặt rule, đảm bảo compliance đạt yêu cầu. Nhưng sau DITS, mình bắt đầu nhìn lại: người dùng có hiểu vì sao họ bị hạn chế không? Team vận hành có đủ nhân lực để support khi phát sinh issue không? Và mức độ siết chặt đó có thật sự tương xứng với rủi ro mà tổ chức đang đối mặt hay chưa?

Thay đổi nhỏ về cách đặt câu hỏi, nhưng ảnh hưởng khá lớn đến cách mình ra quyết định.

Biết framework là chưa đủ; dùng nó để ra quyết định mới là điều quan trọng

Có những framework như PESTEL, SWOT hay Business Model Canvas mình đã từng nghe qua. Nhưng khi phải áp dụng một cách nghiêm túc vào một case cụ thể, mình mới thấy việc “biết” và việc “dùng để đưa ra quyết định” là hai câu chuyện hoàn toàn khác nhau.

Đặc biệt, mình ấn tượng với Wardley Map khi kết hợp cùng cách lý giải theo “Đạo, Thiên, Địa, Tướng, Pháp”. Nó giúp mình có một góc nhìn tổng thể và rõ ràng hơn về chiến lược.

Mình không còn xem framework như những khái niệm trên giấy nữa. Chúng trở thành một cách để nhìn vấn đề, đặt câu hỏi, và hiểu cách một doanh nghiệp đang vận động trong môi trường thực tế.

IT không chỉ là “support” cho business

DITS cũng khiến mình nhìn rõ hơn vai trò của một người làm IT trong tổ chức. Trước đây mình nghĩ mình là người “support” cho business. Nhưng sau môn học này, mình thấy nếu mình chỉ dừng ở đó thì khá giới hạn.

Một người làm IT hoàn toàn có thể tham gia sâu hơn, nếu hiểu được business đang cần gì và vì sao họ cần nó. Mình không nghĩ sau 4 tuần mình đã hiểu được strategy hay có thể làm được những bài toán lớn. Ngược lại, mình thấy rõ là mình còn thiếu rất nhiều. Nhưng điểm khác so với trước đây là mình đã bắt đầu nhận ra được những khoảng trống đó.

Thói quen mới của mình trong 30 ngày tới

Và có lẽ điều thay đổi rõ nhất là ở cách mình làm việc mỗi ngày. Mình chậm lại một chút trước khi bắt đầu. Mình đặt thêm vài câu hỏi trước khi đi vào solution. Và mình bắt đầu quan tâm nhiều hơn đến outcome thay vì chỉ tập trung vào output.

Trong 30 ngày tới, mình không đặt mục tiêu phải thay đổi lớn. Mình chỉ muốn duy trì một vài thói quen nhỏ:

• trước mỗi task quan trọng, dành vài phút để hiểu rõ vấn đề;
• mỗi tuần chọn một case trong công việc để phân tích lại ở góc nhìn business;
• khi review một solution, tự hỏi liệu mình có đang đi quá nhanh vào giải pháp hay không.

DITS không làm mình giỏi lên ngay lập tức. Nhưng nó giúp mình nhận ra rằng trước đây mình đã quen giải quyết vấn đề trong một “khung nhìn hẹp”. Và nếu muốn tạo ra tác động lớn hơn, mình cần bước ra khỏi khung đó.

Trước đây mình tự tin vì mình biết phải làm gì. Còn bây giờ, mình cẩn trọng hơn vì mình hiểu rằng trước khi làm, mình cần chắc chắn là mình đang giải đúng vấn đề.