CMMI (Mô hình tích hợp trưởng thành năng lực, Capability Maturity Model Integration)
1. Tổng quan
Định nghĩa: CMMI (Capability Maturity Model Integration) là khung cải tiến quy trình hướng hiệu quả nhằm chẩn đoán·cải tiến từng bước năng lực và mức trưởng thành quy trình của tổ chức; mô hình hệ thống hóa các thực hành tốt (Practice) theo từng miền như phát triển·dịch vụ·chuỗi cung ứng thành cấu trúc 5 mức trưởng thành và 4 mức năng lực.
Bối cảnh ra đời của CMMI là cuộc khủng hoảng mua sắm phần mềm của Bộ Quốc phòng Mỹ (DoD) những năm 1980. Khi phần mềm của các hệ thống vũ khí lớn liên tục vượt ngân sách và tiến độ mà chất lượng không được bảo đảm, SEI (Software Engineering Institute) của Đại học Carnegie Mellon, với sự hỗ trợ của DoD, đã nghiên cứu phương pháp đánh giá khách quan năng lực quy trình của nhà cung cấp, và kết quả là SW-CMM năm 1991. Sau đó các mô hình khác nhau như kỹ thuật hệ thống (SE-CMM), phát triển sản phẩm tích hợp (IPD-CMM), quản lý nhân lực (P-CMM) xuất hiện tràn lan khiến gánh nặng áp dụng trùng lặp nhiều mô hình tăng lên; việc hợp nhất (Integration) chúng thành một chính là CMMI 1.1 năm 2002.
Xu hướng hợp nhất này tiếp tục về sau: CMMI tiến hóa từ ba mô hình riêng rẽ cho phát triển (CMMI-DEV)·dịch vụ (CMMI-SVC)·mua sắm (CMMI-ACQ) ở V1.3, qua V2.0, đến V3.0 tái hợp nhất thành một hệ thống miền duy nhất. Nghĩa là bản thân lịch sử CMMI là quá trình “hội tụ các thực hành tốt phân tán vào một khung nhất quán”, đáp ứng yêu cầu thực tiễn giảm bớt sự kém hiệu quả khi tổ chức phải quản lý trùng lặp nhiều chứng nhận.
Lý do căn bản cần CMMI nằm ở tiền đề chất lượng phần mềm·hệ thống phụ thuộc vào chất lượng của quy trình tạo ra nó. Tổ chức dựa vào năng lực của cá nhân xuất sắc sẽ sụt giảm hiệu quả khi nhân sự chủ chốt rời đi, còn tổ chức đã định hình quy trình vẫn duy trì chất lượng và tiến độ có thể dự đoán dù nhân sự thay đổi. Tức CMMI là cách tiếp cận bảo đảm hiệu quả bằng “quy trình đã được tài sản hóa của tổ chức” chứ không phải bằng “người hùng (hero)”, và đối với bên đặt hàng, nó là thước đo khách quan để kiểm chứng trước năng lực thực hiện dự án. Thực tế, cấp độ CMMI thường được yêu cầu làm điều kiện dự thầu hoặc điểm cộng trong các dự án SI công·quốc phòng·tài chính tại Hàn Quốc và quốc tế, nên từ góc độ Kỹ sư chuyên nghiệp (Professional Engineer), đây là khái niệm cốt lõi liên kết mức trưởng thành tổ chức với mua sắm và quản lý chất lượng.
Năm 2016 CMMI Institute tách khỏi SEI, và tháng 4 năm 2023 khi tổ chức sở hữu hiện tại là ISACA công bố CMMI V3.0, trọng tâm của mô hình đã chuyển từ “tuân thủ quy trình được văn bản hóa” sang cải thiện hiệu quả kinh doanh (Performance). V3.0 bổ sung các miền Bảo mật (Security)·An toàn (Safety)·Dữ liệu (Data)·Nhân lực (People)·Làm việc ảo (Virtual) bên cạnh phát triển·dịch vụ·chuỗi cung ứng hiện có, mở rộng thành hệ thống tổng cộng 8 miền.
Có thể tóm tắt các đặc trưng cốt lõi của CMMI như sau. Thứ nhất, hướng tới cải tiến từng bước dựa trên mức trưởng thành, giúp tổ chức tích lũy năng lực với tốc độ có thể đáp ứng. Thứ hai, trung lập về phương pháp luận, có thể kết hợp với bất kỳ cách phát triển nào như thác nước·Agile·DevOps. Thứ ba, là tập đại thành các thực hành tốt (Practice), cung cấp kinh nghiệm ngành tích lũy hàng chục năm dưới dạng có thể tham chiếu. Thứ tư, có thể so sánh giữa các tổ chức và giữa các thời điểm nhờ đánh giá khách quan và benchmarking. Bốn đặc trưng này biến CMMI từ một danh mục kiểm tra đơn thuần thành lộ trình năng lực của tổ chức.
2. Cấu trúc tổng thể và cách biểu diễn của CMMI
CMMI là mô hình tham chiếu quy định “cái gì (What)” nhưng để “như thế nào (How)” tùy tổ chức. Cấp cao nhất là miền (Domain), mỗi miền gồm nhiều vùng thực hành (Practice Area, PA), và PA chứa các thực hành (Practice) được phân tầng theo mức trưởng thành/năng lực. Thực hành mô tả “ý định (intent)” của hoạt động mà tổ chức nhất thiết phải thực hiện, còn việc hiện thực bằng phương pháp luận nào (Agile·Waterfall v.v.) do tổ chức lựa chọn. Nhờ tính linh hoạt này, CMMI không phụ thuộc vào phương pháp phát triển cụ thể và có thể áp dụng cho cả nhóm Agile.
Theo V3.0, vùng thực hành được chia thành PA cốt lõi (core) dùng chung cho nhiều miền và PA đặc thù miền chỉ dùng trong miền cụ thể. PA cốt lõi chứa các hoạt động được yêu cầu chung bất kể miền như phát triển yêu cầu·quản lý cấu hình·kiểm tra (verification)·xác nhận (validation)·quản lý rủi ro·đo lường, còn PA đặc thù miền chứa các hoạt động chỉ có ý nghĩa trong lĩnh vực đó như bảo mật·an toàn·quản lý dữ liệu. Nhờ cấu trúc mô-đun này, tổ chức có thể chọn áp dụng chỉ những miền cần thiết, nên tổ chức chỉ phát triển và tổ chức vận hành cả dịch vụ sẽ áp dụng CMMI với tổ hợp PA khác nhau.
graph TD
A["Mô hình CMMI V3.0"] --> B["Miền (Development·Services·Suppliers·Security·Safety·Data·People·Virtual)"]
B --> C["Vùng thực hành (Practice Area, tổng 31)"]
C --> C1["17 PA cốt lõi (nền tảng chung)"]
C --> C2["14 PA đặc thù miền"]
C --> D["Thực hành (Practice, hoạt động theo mức)"]
D --> E1["Mức năng lực (Capability Level 0~3): đánh giá theo từng PA"]
D --> E2["Mức trưởng thành (Maturity Level 1~5): đánh giá cấp tổ chức theo nhóm PA"]
E2 --> F["Thẩm định (Appraisal): Benchmark·Sustainment·Evaluation"]
Về lịch sử, CMMI cung cấp hai cách biểu diễn (Representation). Thứ nhất là liên tục (Continuous): tổ chức chọn từng PA muốn cải tiến và nâng mức năng lực (Capability Level, CL 03) của nó. Ví dụ tổ chức yếu về quản lý cấu hình có thể tập trung nâng riêng PA “Quản lý cấu hình”, nên độ tự do cải tiến cao. Thứ hai là theo giai đoạn (Staged): đạt tuần tự các nhóm PA định sẵn theo đơn vị mức trưởng thành (Maturity Level, ML 15); có thể biểu thị cả tổ chức bằng một cấp độ nên thuận lợi cho giao tiếp với bên ngoài. Trong thực tế, khi nói “công ty chúng tôi đạt CMMI mức 3” thì cấp độ đó là mức trưởng thành của cách biểu diễn theo giai đoạn.
Khác biệt giữa mức năng lực và mức trưởng thành xuất phát từ phạm vi đối tượng đánh giá. Mức năng lực xem một PA được thực hiện·quản lý tốt đến đâu, còn mức trưởng thành xem nhiều PA được định hình cùng nhau ở cấp tổ chức và mức độ dự đoán được của toàn tổ chức ra sao. Do đó một PA cụ thể đạt CL3 không có nghĩa tổ chức đạt ML3; ML chỉ được cấp khi mọi PA mà mức đó yêu cầu đều được đáp ứng.
Hàm ý thực tiễn của cấu trúc kép này là tổ chức có thể thiết kế lộ trình cải tiến phù hợp tình huống. Tổ chức cần gấp chứng nhận bên ngoài nên đặt mục tiêu ML theo cách giai đoạn và chỉnh đốn cùng lúc nhóm PA cần thiết, còn tổ chức có một quy trình cụ thể (ví dụ quản lý rủi ro, quản lý cấu hình) lặp đi lặp lại gây sự cố thì nâng mức năng lực của PA đó theo cách liên tục sẽ hiệu quả đầu tư hơn. Tức CMMI không áp đặt “một đáp án duy nhất” mà được thiết kế để tối ưu thứ tự cải tiến theo điểm đau (pain point) và mục tiêu kinh doanh của tổ chức.
| Phân loại | Mức năng lực (Capability Level) | Mức trưởng thành (Maturity Level) |
|---|---|---|
| Đơn vị đánh giá | Từng vùng thực hành (PA) | Nhóm PA (tổ chức/dự án) |
| Phạm vi mức | 0~3 | 1~5 |
| Cách biểu diễn | Liên tục (Continuous) | Theo giai đoạn (Staged) |
| Khai thác | Cải tiến chọn lọc PA yếu | Công bố cấp độ tổ chức ra bên ngoài |
| Ví dụ | "Đạt CL3 quản lý yêu cầu" | "Chứng nhận ML3 toàn công ty" |
3. Năm mức trưởng thành và đặc trưng từng mức
Mức trưởng thành có thể hiểu như chiếc thang mà quy trình của tổ chức tiến hóa từ “hỗn loạn không thể dự đoán” đến “trạng thái liên tục tự cải tiến”. Mỗi mức đều lấy mức dưới làm tiền đề nên không thể nhảy cóc, và càng lên cao thì mức độ định lượng hóa·tối ưu hóa quy trình càng cao.
graph LR
L1["ML1 Khởi đầu (Initial): ứng biến·phụ thuộc người hùng"] --> L2["ML2 Được quản lý (Managed): quản lý theo dự án"]
L2 --> L3["ML3 Được định nghĩa (Defined): quy trình chuẩn toàn công ty"]
L3 --> L4["ML4 Quản lý định lượng (Quantitatively Managed): quản lý thống kê"]
L4 --> L5["ML5 Tối ưu hóa (Optimizing): cải tiến liên tục"]
Tổ chức ở mức ML1 Khởi đầu (Initial) thực chất không có quy trình được định nghĩa, và thành công phụ thuộc vào năng lực và sự tận tụy của cá nhân cụ thể. Thường xuyên vượt tiến độ và ngân sách, và ngay cả các dự án tương tự cũng có kết quả chênh lệch lớn. Vấn đề là hiệu quả không tái lập được. Dù một nhóm tình cờ thành công, cách làm đó không được tích lũy thành tài sản tổ chức nên dự án sau lặp lại cùng sai lầm. Ví dụ điển hình là mỗi lần quản lý cấu hình theo cách khác nhau nên ngay trước khi phát hành các phiên bản mã nguồn bị lẫn lộn, gây sự cố triển khai. ML1 là “trạng thái cơ bản” không yêu cầu đáp ứng thực hành nào, chỉ là điểm xuất phát của cải tiến chứ không thể là mục tiêu.
Ở mức ML2 Được quản lý (Managed), các thực hành quản lý cơ bản ở cấp dự án như quản lý yêu cầu·lập kế hoạch dự án·giám sát dự án·quản lý cấu hình·đo lường phân tích·quản lý nhà cung cấp·bảo đảm chất lượng được định hình. Cốt lõi là “kỷ luật (discipline)”. Lập kế hoạch, theo dõi thực tế so với kế hoạch và kiểm soát cấu hình sản phẩm. Tuy nhiên quy trình ở mức này có thể khác nhau theo dự án, cách làm việc của nhóm A và nhóm B khác nhau. Ví dụ cả hai nhóm đều quản lý cấu hình nhưng công cụ và chiến lược nhánh khác nhau nên khi điều chuyển nhân sự phát sinh chi phí học tập.
Giá trị tức thì mà ML2 mang lại là “khả năng nhìn thấy (visibility)”. Khi bắt đầu theo dõi kế hoạch và thực tế, chậm tiến độ hay tăng phạm vi sẽ lộ ra sớm, giúp nhà quản lý có cơ hội can thiệp. Ở tổ chức ML1 vấn đề chỉ bùng nổ khi sát hạn, còn tổ chức ML2 nắm bắt dấu hiệu bất thường trước qua dữ liệu tiến độ. Tuy nhiên hạn chế là khả năng nhìn thấy này bị giới hạn trong ranh giới dự án, và mở rộng nó lên cấp tổ chức là nhiệm vụ của mức tiếp theo, ML3.
Ở mức ML3 Được định nghĩa (Defined), tài sản quy trình chuẩn cấp tổ chức (OSSP) được thiết lập và mỗi dự án điều chỉnh (tailoring) để sử dụng. Chênh lệch giữa các dự án giảm, cả tổ chức chia sẻ ngôn ngữ chung và biểu mẫu sản phẩm nên việc luân chuyển nhân sự và tái sử dụng tri thức trở nên dễ dàng. Các thực hành kỹ thuật và cấp tổ chức như kỹ thuật yêu cầu·thiết kế kỹ thuật·kiểm tra·xác nhận·quản lý rủi ro·phân tích quyết định được tăng cường. Lý do ML3 là chuẩn thực chất mà phần lớn dự án SI công tại Hàn Quốc yêu cầu là vì từ mức này tổ chức được xem là bảo đảm chất lượng có thể dự đoán và có thể chuyển giao.
Khác biệt quyết định giữa ML2 và ML3 nằm ở “chủ thể sở hữu” quy trình. Ở ML2 mỗi dự án tự định nghĩa quy trình của mình, còn ở ML3 tổ chức sở hữu chuẩn và dự án điều chỉnh để dùng. Vì khác biệt này, tổ chức ML3 có thể phản hồi bài học kinh nghiệm (lessons learned) và dữ liệu thực đo sau khi kết thúc dự án vào chuẩn tổ chức, nên cải tiến không bị giới hạn trong cá nhân hay nhóm mà được tích lũy thành tài sản tổ chức. Đó là lý do ML3 được xem là điểm khởi đầu của “tổ chức học tập”.
Ở mức ML4 Quản lý định lượng (Quantitatively Managed), quy trình và hiệu quả cốt lõi được quản lý bằng kỹ thuật thống kê·định lượng (SPC v.v.). Ví dụ, đặt giới hạn kiểm soát (control limit) cho các chỉ số như mật độ lỗi, hiệu suất rà soát, năng suất và phát hiện sớm biến động bất thường bằng biểu đồ kiểm soát (control chart). Khác biệt quyết định so với ML2·3 chỉ “thu thập” chỉ số là phân tích thống kê nguyên nhân biến động của chỉ số để xây dựng mô hình dự đoán. Chẳng hạn, ra quyết định dựa trên quan hệ nhân quả định lượng “tăng thời gian rà soát 20% thì lỗi hiện trường giảm có ý nghĩa thống kê”.
Khái niệm quan trọng ở đây là phân biệt nguyên nhân chung (common cause) và nguyên nhân đặc biệt (special cause). Tổ chức ML4 tách biệt bằng thống kê biến động tự nhiên vốn có của quy trình (nguyên nhân chung) với biến động do sự kiện bất thường (nguyên nhân đặc biệt), ứng phó cái trước bằng cải tiến quy trình và cái sau bằng loại bỏ nguyên nhân. Nếu không có sự phân biệt này sẽ mắc lỗi phản ứng thái quá với biến động bình thường hoặc bỏ lỡ vấn đề thật, nên ML4 là mức chỉ đạt được khi năng lực đọc hiểu dữ liệu (data literacy) được nội tại hóa trong tổ chức.
Ở mức ML5 Tối ưu hóa (Optimizing), dựa trên hiểu biết định lượng, tổ chức liên tục đổi mới chính quy trình. Loại bỏ nguyên nhân lỗi bằng phân tích nguyên nhân gốc (RCA), thử nghiệm công nghệ·phương pháp mới và khi hiệu quả được kiểm chứng thì đưa vào chuẩn tổ chức. Tổ chức ở mức này không ứng phó sau khi vấn đề xảy ra mà chủ động tiến hóa quy trình dựa trên dữ liệu.
Như vậy các mức trưởng thành đi theo lộ trình tiến hóa logic “kiểm soát (ML2) → chuẩn hóa (ML3) → định lượng hóa (ML4) → tối ưu hóa (ML5)”. Lý do mỗi mức lấy mức dưới làm tiền đề rất rõ ràng. Nếu thử quản lý thống kê (ML4) mà không có quy trình chuẩn (ML3) thì mỗi dự án có tiêu chuẩn đo khác nhau nên không thể so sánh dữ liệu, và nếu thử tối ưu hóa (ML5) mà không có đường cơ sở định lượng (ML4) thì không thể chứng minh khách quan hiệu quả cải tiến. Vì vậy CMMI không cho phép nhảy cóc, và đây là tính chặt chẽ về phương pháp luận phân biệt CMMI với cải tiến kiểu ứng biến.
4. Phương thức thẩm định (Appraisal) và quy trình đạt cấp độ
Cấp độ CMMI không phải tự tuyên bố mà được cấp qua thẩm định chính thức (Appraisal). Trước đây ở V1.3 dùng phương thức SCAMPI (A/B/C), từ V2.0 trở đi được tái tổ chức thành ba loại thẩm định theo mục đích. Chứng nhận cấp độ chính thức được thực hiện qua thẩm định chuẩn đối sánh (Benchmark Appraisal), do trưởng đoàn thẩm định được chứng nhận (Certified Lead Appraiser) thực hiện và kết quả được đăng ký công khai. Cấp độ đạt được thường có thời hạn hiệu lực (thẩm định Benchmark V3.0 khoảng 3 năm), nên để duy trì phải nhận thẩm định duy trì (Sustainment Appraisal) hoặc thẩm định lại. Kiểm tra mức sẵn sàng nội bộ hoặc chẩn đoán một phần dùng thẩm định đánh giá (Evaluation Appraisal).
| Loại thẩm định | Mục đích | Kết quả |
|---|---|---|
| Benchmark | Chứng nhận cấp độ chính thức (ML/CL) | Đăng ký·công bố, cấp thời hạn hiệu lực |
| Sustainment | Duy trì·gia hạn cấp độ hiện có | Gia hạn cấp độ |
| Evaluation | Chẩn đoán nội bộ·kiểm tra mức sẵn sàng | Rút ra điểm cải tiến (không chính thức) |
Quy trình đạt cấp độ thực tế thường theo luồng ① Khởi động·xác định phạm vi → ② Phân tích khoảng cách (Gap) → ③ Định nghĩa·định hình quy trình (thí điểm·triển khai) → ④ Thẩm định trước (chẩn đoán sơ bộ) → ⑤ Thẩm định Benchmark chính thức → ⑥ Đăng ký·duy trì cấp độ. Giai đoạn tốn nhiều nguồn lực nhất là ③, vì không chỉ tạo quy trình trên giấy mà phải áp dụng vào dự án thực tế để tích lũy bằng chứng khách quan (objective evidence). Thẩm định viên kiểm chứng tam giác tài liệu·phỏng vấn·dữ liệu nên chỉ với tài liệu hình thức thì không thể đạt cấp độ.
flowchart LR
S1["① Khởi động·xác định phạm vi"] --> S2["② Phân tích khoảng cách (so với hiện trạng)"]
S2 --> S3["③ Định nghĩa·định hình quy trình (thí điểm→triển khai toàn công ty)"]
S3 --> S4["④ Thẩm định trước (chẩn đoán sơ bộ)"]
S4 --> S5["⑤ Thẩm định Benchmark chính thức"]
S5 --> S6["⑥ Đăng ký·duy trì cấp độ (Sustainment)"]
S6 -.->|"Thẩm định lại sau khoảng 3 năm"| S5
Trường hợp cụ thể (hiệu quả cải tiến qua kịch bản giả định): Giả sử một doanh nghiệp SI công 200 nhân viên ở mức ML1 thúc đẩy cải tiến trong 3 năm với mục tiêu ML3. Trước khi áp dụng, tỷ lệ đúng hạn dự án của tổ chức khoảng 60%, lỗi hiện trường phát hiện sau khi bàn giao (delivery) xảy ra nhiều trên mỗi KLOC, và chi phí làm lại (rework) chiếm tới 30% tổng chi phí phát triển. Ở giai đoạn định hình ML2, khi quản lý thay đổi yêu cầu và quản lý cấu hình đi vào nề nếp thì nhầm lẫn khi phát hành giảm, và ở ML3 khi quy trình chuẩn tổ chức và rà soát đồng cấp (peer review) được định hình thì lỗi bắt đầu được loại bỏ sớm ở giai đoạn thượng nguồn (yêu cầu·thiết kế). Việc loại bỏ lỗi thượng nguồn giảm mạnh chi phí làm lại ở hạ nguồn là nguyên lý nổi tiếng của công nghệ phần mềm (lỗi phát hiện càng muộn thì chi phí sửa tăng theo cấp số nhân), tạo thành căn cứ kinh tế cho cải tiến CMMI. Tuy nhiên con số thực tế chênh lệch lớn theo đặc tính tổ chức·dự án, nên trong bài làm nên nhấn mạnh cơ chế nhân quả của cải tiến (kỷ luật quy trình → loại bỏ lỗi thượng nguồn → giảm làm lại → tăng khả năng dự đoán) hơn là con số tuyệt đối.
5. So sánh với các mô hình tương tự — ISO/IEC 15504 (SPICE), ISO 9001
Mô hình thường được so sánh với CMMI là ISO/IEC 15504 (SPICE), hiện đã phát triển thành họ ISO/IEC 330xx. Cả hai đều đánh giá năng lực quy trình theo mức, nhưng nguyên nhân căn bản của khác biệt nằm ở “triết lý thiết kế”. CMMI xuất phát từ mua sắm quốc phòng Mỹ nên mạnh về tập đại thành thực hành tốt và chứng nhận cấp độ (benchmarking), còn SPICE là tiêu chuẩn quốc tế tập trung vào tách biệt mô hình tham chiếu quy trình và khung đo lường, đánh giá mức năng lực theo từng quy trình. Trong thực tế, như Automotive SPICE trong ngành ô tô, có những ngành mà họ SPICE được yêu cầu như tiêu chuẩn trên thực tế, nên tổ chức chọn hoặc song hành mô hình theo yêu cầu của bên đặt hàng.
Quan hệ với ISO 9001 (hệ thống quản lý chất lượng) cũng quan trọng. ISO 9001 bao quát quản lý chất lượng toàn tổ chức, còn CMMI chuyên biệt cho quy trình phát triển·dịch vụ phần mềm·hệ thống, nên hai thứ thường được vận hành cùng nhau như bổ trợ chứ không thay thế. Ví dụ, hệ thống kép phổ biến là chính sách chất lượng toàn công ty quản lý bằng ISO 9001, còn mức trưởng thành quy trình phát triển quản lý bằng CMMI.
Ngoài ra, thang mức năng lực của CMMI và SPICE khác nhau cũng gây nhầm lẫn trong thực tế. Mức năng lực của CMMI là 03, còn SPICE (ISO/IEC 33020) chia mức năng lực theo quy trình thành 05. Khác biệt này bắt nguồn từ góc nhìn khác nhau về “năng lực” của hai mô hình. CMMI xem mức năng lực là bàn đạp để leo thang trưởng thành nên giữ tương đối đơn giản, còn SPICE cố gắng đo chính xác đến mức dự đoán·tối ưu hóa của từng quy trình riêng lẻ. Do đó có xu hướng họ SPICE được ưa chuộng trong các ngành đòi hỏi chẩn đoán chính xác từng quy trình như ô tô·hàng không, còn CMMI được ưa chuộng trong môi trường mua sắm cần truyền đạt mức trưởng thành toàn tổ chức bằng một cấp độ.
| Phân loại | CMMI | ISO/IEC 15504 (SPICE) | ISO 9001 |
|---|---|---|---|
| Tính chất | Mô hình tham chiếu trưởng thành/năng lực | Tiêu chuẩn quốc tế đánh giá năng lực quy trình | Tiêu chuẩn quốc tế quản lý chất lượng |
| Đơn vị đánh giá | ML(1 |
Mức năng lực theo quy trình (0~5) | Phù hợp/không phù hợp |
| Điểm mạnh | Benchmarking cấp độ·thực hành tốt | Đánh giá chi tiết theo quy trình | Quản lý chất lượng toàn công ty |
| Ví dụ áp dụng | Đấu thầu quốc phòng·SI công | Chuyên biệt ngành như Automotive SPICE | Phổ dụng mọi ngành |
6. Chuyên sâu — CMMI trong thời đại Agile·DevOps và chuyển hướng hướng hiệu quả
Đã có lúc CMMI bị chỉ trích là “chủ nghĩa văn bản nặng nề” và bị hiểu lầm là đối lập với Agile. Nhưng CMMI không phải phương pháp luận mà là mô hình tham chiếu quy định “cần đạt được cái gì”, nên hoàn toàn có thể đáp ứng ý định của nó bằng các thực hành Agile. Ví dụ, backlog·burndown chart của Scrum trở thành bằng chứng cho thực hành lập kế hoạch·giám sát dự án, và log build·test tự động của pipeline CI/CD trở thành bằng chứng khách quan mạnh cho thực hành quản lý cấu hình·kiểm tra. Việc V3.0 nhấn mạnh rõ hiệu quả (Performance) và tính linh hoạt là sự chuyển hướng nhằm bao dung môi trường phát triển hiện đại như vậy.
Thực tế Agile và CMMI bổ trợ lẫn nhau. Agile cung cấp chiến thuật thực thi “làm thế nào để chuyển giao giá trị nhanh”, nhưng tương đối yếu trong bảo đảm tính nhất quán·khả năng dự đoán cấp tổ chức; còn CMMI cung cấp khung xương của mức trưởng thành tổ chức nhưng không quy định cách thực thi cụ thể. Do đó kết hợp thực thi bằng Agile và chẩn đoán·cải tiến năng lực tổ chức bằng CMMI là mạnh nhất trên thực tế. Lập luận “đã Agile thì không cần CMMI” gần với sự hiểu lầm do nhầm lẫn tầng bậc của hai khái niệm.
Hơn nữa, thu thập bằng chứng tự động của CMMI mở ra khả năng mới trong môi trường phát triển dựa trên AI·dữ liệu. Lịch sử quản lý cấu hình, issue tracker, log pipeline, hồ sơ code review đã được lưu dạng số, nên gánh nặng văn bản hóa thủ công khổng lồ khi chuẩn bị thẩm định trước đây giảm đi, và ngược lại có thể giám sát thường xuyên việc tuân thủ quy trình bằng dữ liệu thời gian thực. Điều này ăn khớp tự nhiên với quản lý định lượng mà các mức cao của CMMI yêu cầu, và trở thành chất xúc tác chuyển cải tiến quy trình từ “sự kiện thẩm định định kỳ” sang “hoạt động vận hành thường xuyên”.
Một thay đổi có ý nghĩa khác của V3.0 là mở rộng miền. Khi bổ sung các miền quản lý dữ liệu (Data)·quản lý nhân lực (People)·làm việc ảo (Virtual), các vấn đề mới như vận hành nhóm từ xa·phân tán và quản lý tài sản dữ liệu có thể được xử lý từ góc độ trưởng thành. Điều này phản ánh thực tế tổ chức CNTT được tái cấu trúc theo đám mây·lấy dữ liệu làm trung tâm·làm việc kết hợp; trong bài làm của Kỹ sư chuyên nghiệp, trình bày theo góc nhìn “CMMI đang tiến hóa vượt khỏi chất lượng mã để bao trùm cả mức trưởng thành về dữ liệu·nhân lực·cộng tác của tổ chức” sẽ thể hiện hiệu quả xu hướng mới nhất. Tuy nhiên cấu thành miền chi tiết hay số lượng thực hành có thể thay đổi theo sửa đổi mô hình, nên trong bài làm an toàn hơn khi nhấn mạnh định hướng hướng hiệu quả·linh hoạt·mở rộng hơn là con số cụ thể.
7. Các điểm cần xem xét và hàm ý (góc độ Kỹ sư chuyên nghiệp)
Thứ nhất, phải cảnh giác với “bẫy chứng nhận” khi việc đạt cấp độ trở thành mục đích. Nếu chỉ lấy cấp độ vì điểm cộng đấu thầu hay marketing trong khi quy trình thực tế bị hình thức hóa, thì chỉ còn lại chi phí duy trì mà không cải thiện hiệu quả. Thành công của việc áp dụng CMMI phải được đánh giá không bằng con số cấp độ mà bằng cải thiện thực chất các chỉ số kinh doanh như tỷ lệ lỗi·tỷ lệ đúng hạn·chi phí làm lại. Chuyển hướng hướng hiệu quả của V3.0 cũng gắn với nhận thức vấn đề này. Đặc biệt, thói quen bỏ mặc quy trình ngay sau khi đạt cấp độ rồi chỉ vội vàng phục hồi bằng chứng ngay trước lần thẩm định tiếp theo là mẫu thất bại điển hình biến CMMI thành yếu tố chi phí, nên cần chuyển sang hệ thống vận hành thường xuyên.
Thứ hai, điều chỉnh (tailoring) phù hợp quy mô·tính chất tổ chức là bắt buộc. Nếu tổ chức nhỏ áp dụng nguyên quy trình nặng nề kiểu doanh nghiệp lớn thì chỉ làm trầm trọng thêm chủ nghĩa quan liêu. Từ góc độ đánh đổi, phải cân nhắc khả năng dự đoán có được nhờ tăng cường kiểm soát với gánh nặng về tính linh hoạt·chi phí do nó gây ra để chọn lọc áp dụng các thực hành cần thiết. Với startup hay nhóm nhỏ, cải tiến trước một số ít PA gây đau nhất theo cách liên tục sẽ thực tế và hiệu quả hơn so với cố theo đuổi cấp ML toàn công ty.
Thứ ba, mức trưởng thành cao (ML4·5) lấy dữ liệu định lượng làm tiền đề nên cần đầu tư trước vào hệ thống đo lường (Measurement). Không thể nhảy vọt lên quản lý thống kê nếu không có chỉ số đáng tin cậy và pipeline dữ liệu. Ở điểm này, các mức cao của CMMI liên kết tự nhiên với quản trị dữ liệu·khả năng quan sát (observability)·hệ thống chỉ số DevOps.
Thứ tư, ý chí của ban lãnh đạo và văn hóa vì cải tiến liên tục là yếu tố thành công then chốt (CSF). Cải tiến quy trình không phải thành quả ngắn hạn mà là thay đổi tổ chức kéo dài nhiều năm, nên nếu không có sự bảo trợ của ban lãnh đạo, tổ chức cải tiến (EPG/SEPG) và thiết kế khuyến khích thì sẽ không định hình được. Trong tương lai, CMMI dự kiến sẽ kết hợp với Agile·DevSecOps·tự động hóa phát triển dựa trên AI, phát triển theo hướng tự động hóa thu thập bằng chứng và đo lường hiệu quả.
Thứ năm, cần góc nhìn vận hành tích hợp với các công nghệ·chế độ liên quan. Quản lý định lượng ở các mức cao của CMMI chỉ có hiệu lực khi kết hợp với chỉ số DORA của DevOps (tần suất triển khai·tỷ lệ thay đổi thất bại·MTTR v.v.), dữ liệu observability và hệ thống quản trị dữ liệu. Ngoài ra, tại Hàn Quốc cấp độ CMMI được dùng làm điều kiện dự thầu hoặc điểm cộng đánh giá kỹ thuật cho các dự án công·quốc phòng, nên tổ chức phải căn chỉnh chiến lược mua sắm với lộ trình cải tiến quy trình để tối đa hóa hiệu quả đầu tư. Rốt cuộc CMMI không phải chứng nhận độc lập mà chỉ bảo đảm cải thiện hiệu quả bền vững khi được vận hành ăn khớp với toàn bộ hệ thống quản lý chất lượng·dữ liệu·tự động hóa của tổ chức.
Tổng hợp lại, CMMI vừa là “tấm gương” chẩn đoán năng lực quy trình của tổ chức vừa là “bản đồ” cải tiến. Trong bài làm của Kỹ sư chuyên nghiệp, cần trình bày chính xác logic tiến hóa của 5 mức trưởng thành và sự phân biệt mức năng lực·mức trưởng thành, nhưng vượt khỏi liệt kê học thuộc lòng để giải thích theo quan hệ nhân quả vì sao không thể nhảy cóc, vì sao hiệu quả chứ không phải văn bản mới quan trọng, và liên kết thế nào với Agile·DevOps·quản trị dữ liệu — đó là chìa khóa đạt điểm cao. Các chủ đề liên quan gồm chi phí chất lượng phần mềm, ISO/IEC 15504 (SPICE), quản trị CNTT, DataOps·DevOps; học liên kết cùng sẽ tăng chiều sâu cho bài làm.
Tài liệu tham khảo
- ISACA, "ISACA Updates CMMI Model with Three New Domains" (2023): https://www.isaca.org/about-us/newsroom/press-releases/2023/isaca-updates-cmmi-model-with-three-new-domains-that-help-organizations-improve-quality
- ISACA Now Blog, "2023 CMMI Updates Take Performance Improvements to the Next Level": https://www.isaca.org/resources/news-and-trends/isaca-now-blog/2023/cmmi-updates-take-performance-improvements-to-the-next-level
- Wikipedia, "Capability Maturity Model Integration": https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration
Tóm tắt một câu: CMMI là khung hướng hiệu quả chẩn đoán·cải tiến năng lực quy trình của tổ chức theo 5 mức trưởng thành·4 mức năng lực, bảo đảm chất lượng bằng quy trình đã được tài sản hóa của tổ chức chứ không phải cá nhân, và ở V3.0 (2023, ISACA) đã mở rộng tới các miền bảo mật·dữ liệu·nhân lực·làm việc ảo.