INFOCHIEF ACADEMY · CIO KNOWLEDGE SERIES
90 ngày đầu làm CIO: Đánh giá hiện trạng, chọn ưu tiên và tạo kết quả ban đầu
CIO mới thường chịu hai áp lực trái ngược: phải tạo dấu ấn nhanh nhưng chưa đủ hiểu doanh nghiệp để thay đổi lớn. Nếu hành động quá sớm, CIO dễ tối ưu nhầm vấn đề; nếu chỉ “quan sát” quá lâu, tổ chức mất niềm tin vào khả năng lãnh đạo mới. 90 ngày đầu vì vậy không phải cuộc đua tạo thật nhiều dự án mà là quá trình xây bức tranh đáng tin, thiết lập quan hệ, xử lý rủi ro tức thời và tạo vài kết quả có ý nghĩa.
Biên soạn: Infochief Academy · Chuyên đề: Giám đốc Công nghệ Thông tin – CIO

90 ngày đầu không phải để chứng minh mình biết mọi thứ
Một CIO mới thường được tuyển vì doanh nghiệp muốn thay đổi: chi phí cao, hệ thống cũ, dự án chậm, an toàn thông tin yếu hoặc IT chưa đồng hành kinh doanh. Điều nguy hiểm là coi bản mô tả vấn đề lúc tuyển dụng như chẩn đoán cuối cùng. Những gì CEO nhìn thấy có thể chỉ là triệu chứng; nguyên nhân nằm ở operating model, dữ liệu, kiến trúc, năng lực nhân sự hoặc cơ chế quyết định.
Trong 90 ngày đầu, CIO cần tạo hai tài sản: context và credibility. Context là hiểu mô hình kinh doanh, ưu tiên, phụ thuộc công nghệ và rủi ro. Credibility hình thành khi CIO lắng nghe, nói rõ sự thật, xử lý một vài vấn đề quan trọng và không hứa những điều chưa kiểm chứng.
ISO/IEC 38500:2024 nhấn mạnh governance của việc sử dụng IT hiện tại và tương lai. Với CIO mới, điều này gợi ý rằng đánh giá ban đầu không nên chỉ kiểm tra server, ứng dụng và dự án; cần nhìn cả cách tổ chức ra quyết định, phân quyền, quản lý đầu tư và giám sát hiệu suất.
Ngày 1–30: xây bản đồ doanh nghiệp và hiện trạng IT
30 ngày đầu nên dành nhiều thời gian cho các cuộc đối thoại có cấu trúc. Gặp CEO/CFO/COO để hiểu ba ưu tiên doanh nghiệp; gặp lãnh đạo bán hàng, vận hành, nhân sự và tài chính để biết điểm đau; gặp đội IT để hiểu dịch vụ, con người, supplier và backlog. Quan trọng hơn, hỏi cùng một câu ở nhiều nơi để phát hiện khoảng cách nhận thức.
CIO nên tạo một “current-state map” gồm: business capabilities quan trọng, dịch vụ IT hỗ trợ, ứng dụng/hạ tầng chính, dữ liệu trọng yếu, dự án đang chạy, vendor lớn, ngân sách và rủi ro. Không cần đánh giá chi tiết mọi tài sản; mục tiêu là xác định nơi IT có tác động lớn nhất.
| Góc đánh giá | Câu hỏi 30 ngày | Output |
|---|---|---|
| Kinh doanh | 3 ưu tiên và 3 rủi ro lớn nhất? | Business priority map |
| Dịch vụ | Dịch vụ nào nếu dừng sẽ ảnh hưởng lớn? | Critical service map |
| Đầu tư | Tiền đang đổ vào đâu và vì sao? | Portfolio baseline |
| Con người | Năng lực nào thiếu, vai trò nào mơ hồ? | Capability heatmap |
Chương trình 90 Ngày Lãnh Đạo IT có cùng tinh thần: ưu tiên chẩn đoán, stakeholder alignment và hành động có thứ tự trước khi mở rộng thay đổi.
Đánh giá rủi ro trước khi nói về chiến lược
CIO mới cần kiểm tra sớm các “red flags” có thể phá hỏng mọi kế hoạch dài hạn: backup không kiểm chứng, tài khoản đặc quyền không kiểm soát, hệ thống end-of-support, single point of failure, hợp đồng sắp hết hạn, dự án quan trọng không có owner, key person dependency hoặc sự cố tồn đọng. Đây không phải audit toàn diện; là risk triage để biết điều gì không thể chờ.
Hãy phân loại thành ba nhóm: Immediate – cần hành động ngay; Near-term – xử lý trong 90–180 ngày; Strategic – cần chương trình dài hạn. Cách này tránh việc mọi vấn đề đều được gọi là “critical”.
Nếu tổ chức chưa có phương pháp nhất quán, CIO có thể liên kết với Quản Trị Rủi Ro IT để chuẩn hóa cách nhận diện, đánh giá và theo dõi rủi ro.
Ngày 31–60: chọn 3–5 ưu tiên có logic
Sau giai đoạn nghe và đánh giá, CIO cần bắt đầu nói “không”. Danh sách vấn đề thường dài hơn năng lực thực hiện. 3–5 ưu tiên tốt phải có liên kết rõ với mục tiêu doanh nghiệp, outcome có owner, dependency khả thi và rủi ro nếu không làm. Ưu tiên không nên là tên công nghệ như “Cloud”, “AI” hay “ERP”; nên là kết quả như “rút ngắn lead time đơn hàng”, “giảm rủi ro continuity”, “chuẩn hóa dữ liệu khách hàng”.
Mỗi ưu tiên nên có một one-page charter: mục tiêu, baseline, business owner, phạm vi, chỉ số thành công, dependency, nguồn lực và 90-day next step. Khi CIO trình bày theo cấu trúc này, Ban điều hành có thể so sánh và ra quyết định thay vì thảo luận công nghệ.
Đây là điểm nối trực tiếp với năng lực lãnh đạo CIO và Xây Dựng Kế Hoạch Chiến Lược IT: biến yêu cầu rời rạc thành portfolio ưu tiên và roadmap có logic.
Tạo quick wins mà không tạo nợ mới
Quick win có ba tiêu chí: người dùng nhìn thấy, thời gian ngắn và không phá vỡ kiến trúc/kiểm soát. Những quick win tốt thường là loại bỏ một nút thắt quy trình, cải thiện service desk, minh bạch backlog, tự động hóa báo cáo thủ công, sửa một dependency gây sự cố lặp lại hoặc chuẩn hóa một chỉ số mà lãnh đạo đang tranh luận.
Không nên chọn quick win chỉ vì “dễ”. Việc thay màu dashboard hoặc mua một công cụ mới có thể nhanh nhưng không xây credibility nếu không giải quyết vấn đề thật. Mặt khác, CIO cũng cần tránh tạo nợ mới: một script tạm thời không owner, một SaaS mua vội hoặc một ngoại lệ security có thể biến thành gánh nặng sau 6 tháng.
Khi quick win liên quan vận hành và trải nghiệm người dùng, chương trình Quản Lý Dịch Vụ IT – ITSM cung cấp tư duy value stream, SLA và cải tiến liên tục giúp kết quả ban đầu không tách khỏi hệ thống quản lý lâu dài.
Ngày 61–90: thiết lập operating rhythm và roadmap
Đến ngày 90, CIO không cần có “chiến lược năm năm hoàn hảo”. Cần có một nhịp quản trị đủ tốt để tổ chức tiếp tục ra quyết định: họp portfolio hàng tháng, service review, risk review, architecture decision, vendor review và dashboard lãnh đạo. Operating rhythm giúp thành công không phụ thuộc vào việc CIO tự mình theo dõi mọi vấn đề.
Roadmap 12–18 tháng nên chia theo outcome và dependency, không theo danh sách hệ thống. Ví dụ: Q1 ổn định dịch vụ và dữ liệu chủ; Q2 chuẩn hóa quy trình và tích hợp; Q3 tự động hóa và analytics; Q4 mở rộng digital/AI. Mỗi wave phải có điều kiện vào/ra và chỉ số giá trị.
Song song, CIO cần đánh giá đội ngũ: ai có thể sở hữu dịch vụ, ai có tiềm năng lãnh đạo, năng lực nào cần tuyển hoặc thuê ngoài. Chương trình Trưởng Phòng IT Chuyên Nghiệp – IT Manager phù hợp khi cần phát triển lớp quản lý thực thi để CIO không trở thành bottleneck.
Tình huống minh họa: CIO mới không thay hệ thống ngay
Tình huống giả định: một CIO mới được tuyển với nhiệm vụ “thay ERP vì người dùng phàn nàn”. Trong 30 ngày đầu, CIO phát hiện nhiều vấn đề thực tế đến từ dữ liệu master không chuẩn, quyền phê duyệt quá nhiều tầng và giao diện báo cáo được tùy biến không nhất quán. ERP cũ có hạn chế nhưng chưa phải nguyên nhân duy nhất.
Thay vì khởi động ngay dự án thay ERP, CIO chọn ba quick win: chuẩn hóa top 20 master data issue, giảm một tầng phê duyệt và xây service dashboard cho quy trình order-to-cash. Song song, CIO tổ chức đánh giá kiến trúc và business case thay ERP trong quý tiếp theo.
Sau 90 ngày, Ban điều hành có bằng chứng rõ hơn về phần nào cần thay, phần nào cần cải tiến quy trình. CIO không “chậm chuyển đổi”; CIO đã mua thông tin để tránh một quyết định đầu tư lớn dựa trên chẩn đoán chưa đầy đủ.
Checklist bàn giao ngày thứ 90
- Đã gặp các stakeholder chính và ghi nhận kỳ vọng/xung đột.
- Có bản đồ business priority – critical service – major system – risk.
- Top rủi ro tức thời có owner và kế hoạch xử lý.
- Danh mục đầu tư có trạng thái, owner, benefit và dependency.
- Đã chốt 3–5 ưu tiên IT gắn với outcome doanh nghiệp.
- Có 2–3 quick win tạo kết quả nhìn thấy nhưng không tạo nợ mới.
- Dashboard lãnh đạo đầu tiên đã chuyển từ activity sang value/risk.
- Operating rhythm cho service, risk, project và vendor đã được thiết lập.
- Roadmap 12–18 tháng có sequence và điều kiện rõ.
- Đã xác định khoảng trống năng lực và kế hoạch phát triển lãnh đạo IT.
Hành động nên bắt đầu: trước ngày làm việc đầu tiên, chuẩn bị một bộ 15 câu hỏi stakeholder thống nhất. Sau mỗi cuộc gặp, ghi lại “mục tiêu – đau điểm – kỳ vọng – bằng chứng – quyết định đang chờ”. Đến cuối tháng đầu, CIO sẽ có một bức tranh khách quan hơn nhiều so với việc chỉ đọc báo cáo IT hiện hữu.
CIO mới cũng cần quản lý kỳ vọng về tốc độ. Một bản “listening tour” tốt không phải chuỗi cuộc gặp xã giao mà là quá trình thu thập bằng chứng có thể so sánh. Hãy dùng cùng một bộ câu hỏi cốt lõi cho các lãnh đạo: mục tiêu nào quan trọng nhất, điều gì đang cản trở, dịch vụ IT nào đáng tin hoặc gây thất vọng, rủi ro nào chưa được xử lý và quyết định nào đang chờ. Khi câu trả lời lặp lại ở nhiều chức năng, CIO có tín hiệu mạnh hơn về ưu tiên thực sự; khi câu trả lời mâu thuẫn, đó là nơi cần xác minh dữ liệu và quyền quyết định.
Trong 90 ngày đầu, CIO nên tránh công bố một “đại chiến lược” quá sớm. Một roadmap sơ bộ có giả định rõ ràng thường đáng tin hơn một kế hoạch chi tiết dựa trên hiểu biết chưa đầy đủ. Hãy phân biệt điều đã biết, điều đang giả định và điều cần kiểm chứng. Cách minh bạch này giúp Ban điều hành hiểu vì sao một số quyết định được đưa ra ngay, trong khi các quyết định đầu tư lớn cần thêm thời gian để xây business case.
Bài viết liên quan
- Xây dựng IT Operating Model: Tổ chức bộ phận IT theo năng lực, dịch vụ và giá trị kinh doanh
- Ai sẽ kế nhiệm CIO? Xây dựng năng lực lãnh đạo IT thay vì chỉ đào tạo cá nhân
- Báo cáo IT trước Ban điều hành: Nói về giá trị và rủi ro thay vì thông số
- Ngân sách IT bị cắt giảm: CIO giữ lại sáng kiến nào và dừng dự án nào?
Nguồn tham khảo
- ISO/IEC 38500:2024 – Governance of IT for the organization
- ISACA – COBIT resources
- NIST Cybersecurity Framework 2.0
- ISO/IEC 38506:2020 – Governance of IT-enabled investments
Các nguồn trên được dùng làm tài liệu tham khảo cho nguyên tắc quản trị và thực hành chuyên môn. Nội dung bài viết là diễn giải ứng dụng của Infochief Academy.