Chuyên đề Giải pháp nâng cao hiệu quả triển khai dự án EDOCMAN của công ty cổ phần giải pháp phần mềm CMC (CMCSoft)

= 0.5 <= 0.5 40% 12 Tỉ lệ NC/NX đóng đúng hạn % >=70% >=70% >=70% >=70% 30% 13 Tỉ lệ NC/NX lặp % <=20% <=20% <=20% <=20% 30% Nguồn:Phòng P&Q(Phòng chất lượng) 3.3. Đánh giá chi tiết tình hình thực hiện các chỉ tiêu 3.3.1. Nhóm chỉ tiêu năng suất 3.3.1.1.Độ lệch thời gian thực hiện Chỉ tiêu Độ lệch thời gian thực hiện nhằm cung cấp thông tin độ lệch về tiến độ của dự án. Kết thúc mỗi giai đoạn, mỗi mốc kiểm soát và khi kết thúc dự án Quản trị dự án sẽ là người phải trực tiếp tiến hành tính toán chỉ tiêu này. Công thức tính toán: Độ lệch thời gian thực hiện = (Ngày kết thúc thực tế - Ngày kết thúc dự kiến) / (Ngày dự kiến kết thúc - Ngày dự kiến bắt đầu) Trong đó nguồn thông tin được lấy từ các biên bản: Quyết định tổ chức dự án, Kế hoạch dự án, Báo cáo tiến trình dự án, Báo cáo kết thúc giai đoạn, Báo cáo tổng kết dự án, Biên bản nghiệm thu Với quy ước là: Thông tin về ngày dự kiến được lấy trong bản KHDA được phê duyệt gần nhất, Chỉ tiêu này khi tính cho toàn SBU thì lấy trung bình các chỉ tiêu của dự án trong SBU đó Bảng 10: Số liệu về độ lệch thời gian thực hiện của Dự án Edocman DLTGTH Năm 2004 2005 2006 2007 <=20% 8 15 23 18 >20% 12 7 5 22 Trung bình 31% 18% 7.13% 60.67% Nguồn: Phòng chất lượng Theo như tài liệu hướng dẫn về các chỉ tiêu chất lượng của dự án phần mềm thì mức tiêu chuẩn mà chỉ tiêu Độ lệch thời gian thực hiện cần thỏa mãn là <=20%, nếu vượt mức 20% tức là tiến độ thực tế của dự án thực hiện đã quá khác biệt so với kế hoạch. Điều này có thể là lí do khách quan mà người lập dự án cũng như người đi triển khai chưa thể lường trước được, cũng có thể do những lí do chủ quan của cả bên khách hàng và của đội ngũ cán bộ triển khai của Trung tâm. Theo bảng số liệu trên có thể thấy: Năm 2004: Đây là thời điểm trung tâm Edocman vẫn thuộc sự quản lí của Công ty máy tính truyền thông CMC, số lượng các dự án Edocman được triển khai trên thị trường đã là khá lớn do những giải thưởng những uy tín mà sản phẩm Edocman có được. Nhưng trong số 20 dự án được triển khai thì thì chỉ có 8 dự án tức là 40% đạt tiêu chuẩn về độ lệch thời gian thực hiện còn lại 12 dự án vẫn có sự sai lệch vượt quá mức độ cho phép. Dự án Edocman đã được khẳng định về tính hiệu quả của nó trên tính toán nhưng việc áp dụng triển khai vào thực tế hoạt động của các tổ chức còn rất nhiều vấn đề mà cần có thực tế để rút kinh nghiệm nên những gì mà trung tâm Edocman đạt được đã là những thành quả đáng ghi nhận. Tính trung bình độ lệch về thời gian thực hiện của 20 dự án năm 2004 đạt tới 31% vẫn là quá cao. Trung tâm cần có những chỉnh sửa hợp lí trong kế hoạch để nâng cao tính quy trình cũng như đảm bảo chất lượng của phầm mềm khi đến tay khách hàng Năm 2005: Sau một năm có kinh nghiệm trong việc triển khai, đã có những điều chỉnh về kế hoạch cho phù hợp với thực tế, sự cải thiện trong Độ lệch về thời gian thực hiên đã đạt được hiệu quả trông thấy, trung bình về độ lệch thời gian thực hiện của các dự án chỉ còn 18% tức là mức trung bình đã đạt yêu cầu đặt ra. Trong 22 dự án chỉ còn 7 dự án >20%. Năm 2006: Trung bình về Độ lệch thời gian thực hiện của toàn SBU chỉ là 7.13% thấp hơn rất nhiều so với ngưỡng mà tài liệu hướng dẫn đặt ra. Đây là năm của một mốc sự kiện lớn đó là năm công bố mô hình mới của Tập đoàn CMC, mặc dù sự kiện này đã ảnh hưởng đến cơ cấu tổ chức bộ máy quản lí mới, nhân sự trong toàn công ty nhưng kết quả mà trung tâm Edocman đạt được thì gần như không bị tác động và ngày càng to lớn. Có một vấn đề mà những người lập dự án cũng nên lưu tâm, đó là ngưỡng 20% mà Trung tâm P&Q đưa ra không phải là đòi hỏi việc triển khai phải luôn đạt mức càng thấp càng tốt mà cũng cần phải có những sai lệch nào đó ở mức cho phép để tạo tiền đề cho những cải tiến mới nhằm hoàn thiện và phát triển phần mềm Edocman Năm 2007: Năm 2006 sự sai lệch về thời gian thực hiện là con số rất nhỏ thì năm 2007 sự sai lệch này đã lên tới 60,67%.Điều đáng lưu ‎y' là trong 40 dự án được triển khai cũng chỉ có 22 dự án vượt 20% nhưng độ lệch trung bình lại quá lớn. Đó là do có những dự án mà độ sai lệch đạt tới 276%. Đó là những phát sinh vượt ngoài tầm kiểm soát của doanh nghiệp hay có những dự án mà khách hàng yêu cầu kéo dài hơn thời gian triển khai với sự bổ xung về kinh phí 3.3.1.2. Tỉ lệ sử dụng nguồn lực Chỉ tiêu tỉ lệ sử dụng nguồn lực được tính toán nhằm mục đích theo dõi mức độ sử dụng nguồn lực thực tế trên nguồn lực kế hoạch Cũng như chỉ tiêu độ lệch thời gian thực hiện, Tỉ lệ sử dụng nguồn lực được Quản trị dự án trực tiếp tính toán khi hết mỗi giai đoạn, hết mốc dự án, và khi kết thúc dự án. Công thức tính toán: Tỉ lệ sử dụng nguồn lực = Nguồn lực sử dụng thực tế / Nguồn lực Kế hoạch Chỉ tiêu này được tính toán dựa trên nguồn: Quyết định tổ chức dự án, Kế hoạch dự án, Báo cáo tiến trình dự án, Báo cáo kết thúc giai đoạn Báo cáo tổng kết dự án, Biên bản nghiệm thu Với quy ước là: Chỉ tiêu này khi tính cho toàn SBU phải lấy tổng của nguồn lực thực hiện của tất cả các dự án/ tổng nguồn lực dự kiến của tất cả các dự án Với mỗi dự án, cần phải theo dõi cả chỉ số sau là chỉ số về sản lượng của dự án. - Số MM kế hoạch * chi phí trên 1MM (cost 2: đã tính billable) của SBU - Số MM thực tế * chi phí trên 1 MM (cost 2: đã tính billable) của SBU Bảng 11: Số liệu về tỉ lệ sử dụng nguồn lực Năm TLSDNL 2004 2005 2006 2007 <=120% 16 16 25 35 >120% 4 6 3 5 Trung bình 97% 108% 86.42% 91.3% Nguồn: Phòng chất lượng Nói chung tỉ lệ sử dụng nguồn lực của các dự án Edocman trong 4 năm 2004-2007 gần như toàn bộ đều nằm trong kế hoạch thậm chí thực tế còn rất nhiều dự án giảm được mức độ sử dụng nguồn lực. Điều này được gây lên bởi cả yếu tố bên trong và bên ngoài doanh nghiệp. Có thể do trình độ của khách hàng nên thời gian mà cán bộ triển khai đào tạo tập huấn có thể được rút ngắn hoặc kéo dài ra, do có những cán bộ cùng một lúc tham gia triển khai nhiều dự án chỉ cần một dự án gặp sự cố nếu không điều chỉnh kịp thời sẽ ảnh hưởng đến nhiều dự án, trong kế hoạch dự án luôn có thời gian và nguồn lực dự trù để xử lí khi có sự cố xảy ra nên nếu trong quá trình tiến trình triển khai mà không gặp rủi ro gì thì dự án sẽ được hoàn thành trước thời hạn. Năm 2004: Chỉ có 3 dự án không sử dụng hết nguồn lực kế hoạch còn lại các dự án đều sử dụng 100% nguồn lực kế hoạch của dự án. Giai đoạn đầu mới đưa phần mềm Edocman vào triển khai, kết quả đạt được như vậy là do sự nỗ lực cố gắng của tập thể SBU cũng như sự hỗ trợ của các SBU, các phòng ban chức năng khác Năm 2005: So với năm 2004, năm này có nhiều dự án lớn với nhiều mốc quan trọng nên sau mỗi mốc dự án theo yêu cầu của khách hàng cũng như tự nhận thấy cần có những đánh giá thêm về thực tế triển khai để có những điều chỉnh hợp lí nên nguồn lực sử dụng tăng nhiều đạt mức trung bình là 108%. Như vậy dù nguồn lực sử dụng tăng nên nhưng vẫn nằm trong tầm kiểm soát của doanh nghiệp.Điều quan trọng nhất là đội ngũ cán bộ triển khai thu được rất nhiều kinh nghiệm trong việc triển khai các dự án lớn nhiều giai đoạn nhiều mốc. Năm 2006: Từ những kinh nghiệm rút ra trong việc triển khai dự án năm 2005, năm 2006 này việc sử dụng nguồn lực trở nên hiệu quả và tiết kiệm hơn rất nhiều.Mức trung bình đạt 82,46% Năm 2007: phần mềm Edocman đã xuất hiện trên thị trường 4 năm, nhiều tổ chức doanh nghiệp đã áp dụng và thấy được hiệu quả to lớn khi đầu tư cho dự án này. Chính vì thế Edocman đã đạt được doanh thu tăng vượt bậc so với 3 năm trước đạt mức 42,5 tỷ đồng. Đây vừa là niềm vui nhưng cũng là nỗi lo của Trung tâm Edocman khi đội ngũ nhân sự triển khai chưa đáp ứng được nhưu cầu to lớn của thị trường. Trong hoàn cảnh đó trung tâm đã phải chia tách nguồn lực phân tới các dự án khác nhau, huy động nguồn lực từ các SBU khác cũng như phải tiến hành tuyển dụng đào tạo thêm nguồn nhân lực. Dù vậy tỉ lệ sử dụng nguồn lực trung bình vẫn chỉ có 91.3- đây là một kết quả vượt ngoài sự mong đợi của toàn trung tâm. 3.3.1.3. Tính đúng hạn bàn giao các sản phẩm của dự án Đo khả năng bàn giao đúng hạn cho khách hàng là mục tiêu của việc tính toán chỉ tiêu Tính đúng hạn trong việc bàn giao các sản phẩm của dự án Quản trị dự án vẫn là người phải trực tiếp tính toán chỉ tiêu này. Công thức tính toán: Tổng số các sản phẩm bàn giao đúng hạn / Tổng số sản phẩm phải bàn giao Nguồn dữ liệu lấy từ: Kế hoạch dự án Các báo cáo của dự án Biên bản bàn giao Bảng 12: Mức độ bàn giao đúng hạn các sản phẩm của dự án Edocman Năm TĐHBGSP 2004 2005 2006 2007 >=80% 18 19 24 36 <80% 2 3 4 4 Trung bình 95,6% 93,15% 91,3% 94,2% Nguồn: Phòng chất lượng Tuy chỉ tiêu về độ lệch thời gian thực hiện là khá lớn nhưng tính đúng hạn về việc bàn giao sản phẩm lại rất cao.Trung bình của cả 4 năm đều lớn hơn 90% vượt xa so với định mức mà phòng P&Q đặt ra. Hầu như các sản phẩm trong hợp đồng CMC kí với khách hàng đều được hoàn thành đúng hạn trừ việc có một số yêu cầu phát sinh từ phía khách hàng. Đây là một trong những hoạt động đảm bảo được uy tín của Doanh nghiệp với khách hàng, không kéo dài thời gian triển khai của cả 2 bên đảm bảo đúng hạn đưa phần mềm vào hoạt động 3.3.1.4. Tỷ lệ hoàn thành các yêu cầu Chỉ tiêu Tỷ lệ hoàn thành các yêu cầu được tính toán nhằm mục đích đo mức độ hoàn thành các yêu cầu của dự án Quản trị dự án tính toán chỉ tiêu này vào các thời điểm: hết mỗi giai đoạn, hết mốc kiểm soát, và khi kết thúc dự án Công thức tính toán: Tỉ lhoàn thành các yêu cầu = Total (Yêu cầu * trọng số * Tỉ lệ hoàn thành) / Total(Yêu cầu * trọng số). Yêu cầu có trọng số: có thể nhân giá trị từ 1 (thấp nhất) đến 5 (cao nhất) tùy vào độ phức tạp của yêu cầu do Quản trị dự án đánh giá VD: Tỷ lệ trạng thái của yêu cầu SRS : 15% Thông qua : 20% Thiết kế xong : 50% Lập trình xong : 70% Kiểm tra xong : 90% Triển khai xong : 95% Được nghiệm thu : 100% Trọng số của yêu cầu được tính (nếu có) Lấy nguồn từ: Đặc tả yêu cầu người sử dụng, Biểu mẫu quản lí yêu cầu dự án (Excel) Với quy ước: Các giá trị trên có thể thay đổi tuỳ theo đặc thù của dự án. Yêu cầu của khách hàng được ghi nhận trong tài liệu URD và các bằng chứng thay đổi yêu cầu nếu có, được xác nhận bởi khách hàng hoặc GĐDA Bảng 13: Tỷ lệ hoàn thành các yêu cầu của dự án Edocman Năm TLHTCYC 2004 2005 2006 2007 100% 20 20 28 39 <100% 0 2 0 1 Trung bình 100% 96,4% 100% 99,1% Nguồn: Phòng chất lượng Sản phẩm phần mềm Edocman là sản phẩm được đội ngũ lập trình viên của trung tâm sáng tạo và thuộc bản quyền của trung tâm Edocman vì vậy thành viên của Edocman chính là những người hiểu rõ nhất về phần mềm này. Phần mềm Edocman liên tục được hoàn thiện nhằm năng cao khả năng đáp ứng những đòi hỏi khác nhau trong yêu cầu của khách hàng. Hiện tại việc quan trọng nhất của trung tâm vẫn là tìm kiếm khách hàng có nhưu cầu để triển khai chuyển giao phần mềm đi vào thực tế áp dụng, chính vì thế mọi ưu tiên đều tập trung vào việc đáp ứng tốt nhất các yêu cầu của khách hàng. Do xác định rõ ràng được định hướng chiến lược cho sự phát triển của Trung tâm nên trong cả 4 năm từ khi dự án Edocman được đưa đi triển khai thì gần như tỉ lệ hoàn thành các yêu cầu đều đạt 100% trừ một số dự án không hoàn thành yêu cầu là do lí do khách quan. Những dự án không hoàn thành cũng chính là những dự án được huy động tối đa nguồn lực nên cũng chính là những dự án vượt quá tỉ lệ sử dụng nguồn lực cho phép. Đó là 4 chỉ tiêu thuộc hệ thống nhóm chỉ tiêu năng suất 3.3.2. Nhóm chỉ tiêu chất lượng Phân tích các thông tin chất lượng Chỉ tiêu là công cụ kiểm soát tiến độ dự án và dự đoán xu hướng tiến triển của dự án, tiêu chuẩn để đánh giá mức độ thành công của dự án, cơ sở để cải tiến quy trình và xác định tình trạng năng suất chất lượng của CMCSoft Phòng QLCL tiến hành việc thu thập và phân tích các thông tin chất lượng nhằm: Xem xét tính thích hợp và hiệu lực của hệ thống Đánh giá, xác định các điểm cần cải tiến. Việc phân tích phải cung cấp thông tin theo các nhóm chỉ tiêu Thỏa mãn của khách hàng Sự phù hợp với các yêu cầu về sản phẩm Đặc tính, xu hướng của các quá trình, sản phẩm, cơ hội cải tiến Năng suất chất lượng Chỉ tiêu chất lượng Chỉ tiêu quy trình Tài liệu liên quan Qui trình đánh giá chất lượng nội bộ (03/QT/CL) Qui trình khắc phục, phòng ngừa, cải tiến (04/QT/CL) Qui trình thống kê và xử lý số liệu (06/QT/CL) Qui trình xử lý thông tin phản hồi (07/QT/CL) 3.3.2.1. Điểm hài lòng của khách hàng Chỉ tiêu điểm hài lòng của khách hàng được tìm hiểu nhằm mục đích đánh giá về sự hài lòng của khách hàng đối với dự án, sản phẩm, dịch vụ. Cán bộ chất lượng dự án sẽ là người phải tính toán chỉ tiêu này đối với từng dự án, còn đối với toàn SBU thì người đánh giá là Cán bộ phụ trách chất lượng của SBU. Thời điểm đánh giá: chỉ khi dự án kết thúc mới cần tiến hành đánh giá Công thức tính toán: Điểm hài lòng của khách hàng = Tổng điểm trên phiếu – 5*Tổng số khiếu nại trong dự án Nguồn thông tin được thu nhận từ Bản thăm dò ý kiến khách hàng Các khiếu nại và thông tin phản hồi của khách hàng Quy ước: Phiếu survey khách hàng của P&Q , Đo vào thời điểm kết thúc dự án Bảng14: Mức độ hài lòng của khách hàng Năm ĐHLCKH 2004 2005 2006 2007 >=80% 16 15 15 0 <80% 4 7 13 40 Trung bình 81% 71,65% 78,32% 67,3% Nguồn: Phòng chất lượng Kết quả của chỉ tiêu này giúp các cán bộ quản lí chất lượng đánh giá một cách chính xác công tác triển khai dự án cũng như những hiệu quả mà phần mềm triển khai mang lại có đạt mức kì vọng của khách hàng không? Từ đó có những giải pháp, chỉnh sửa, khắc phục các lỗi gặp phải Năm 2004: Đây là năm đạt được độ hài lòng của khách hàng cao nhất trong 4 năm khảo sát, trung bình vượt trên mức 80% mà Bảng hướng dẫn chỉ tiêu đề ra. Vào thời điểm này số lượng các tổ chức doanh nghiệp áp dụng các phần mềm quản lí trong hoạt động của mình chưa nhiều do đó với những hiệu quả mà dự án mang lại làm cho khách hàng không những hài lòng mà còn rất phấn khích. Năm 2005: Lúc này trên thị trường đã có thêm rất nhiều phần mềm của nhiều doanh nghiệp trong nước cũng như nước ngoài, các tổ chức các doanh nghiệp kinh doanh cũng bắt đầu quan tâm đến việc áp dụng giải pháp phần mềm để nâng cao hiệu quả hoạt động.Chính vì thế đòi hỏi của khách hàng cũng trở nên khắt khe hơn, họ có thêm những yêu cầu, kiến nghị mới đòi hỏi dự án phải hoàn thành. Đồng thời vào năm này có nhiều tổ chức công kí hợp đồng triển khai với Trung tâm Edocman nên quy mô của dự án rất lớn và rộng, cán bộ triển khai phải đi tới nhiều tỉnh với những điều kiện, trình độ của khách hàng rất khác nhau chính vì vậy hiệu quả chung cho toàn bộ dự án mà yêu cầu của khách hàng đặt ra để đạt được là điều không dễ thực hiện. Trung bình chỉ đạt mức 71,65% thấp hơn rất nhiều so với năm 2004. Năm 2006: Nhìn chung vào năm này số dự án không đạt mức 80% so với yêu cầu đặt ra là khá lớn nhưng mức đạt được chỉ thấp hơn 80% một chút.Điều đó khuyến khích đội ngũ cán bộ triển khai cần có sự cố gắng hơn nữa trong việc làm thỏa mãn yêu cầu của khách hàng Năm 2007: Con số là khá bất ngờ khi có tới 40 hợp đồng được kí kết và triển khai nhưng lại không có bất kì một dự án nào đạt mức 80%.Điều này thật đáng báo động. Theo phản ánh của khách hàng có thể thấy có lẽ do số lượng dự án quá lớn nên độ tập trung vào từng dự án là thấp và chất lượng của cán bộ triển khai cũng cần phải xem xét lại. Số lượng và doanh thu là quan trọng nhưng Trung tâm cũng cần phải xem xét lại việc triển khai hiện nay của mình. Edocman là sản phẩm mũi nhọn của toàn Công ty,hơn nữa dựa trên nền công nghệ Edocman, các cơ quan doanh nghiệp có thể phát triển nhiều ứng dụng khác nữa như Bussiness Process Management, Web Content Management, Portal, Interprise Intergrated Applications nên nếu không làm cho khách hàng hài lòng tức là sẽ làm giảm uy tín của Công ty cũng như làm mất cơ hội kí tiếp hợp đồng với khách hàng đó vào lần sau nữa. 3.3.2.2. Số lỗi phần mềm phát hiện trong dự án Đối với nhóm chỉ tiêu liên quan tới lỗi phát hiện và khắc phục, công cụ chủ yếu dùng để phân tích các chỉ tiêu này là các công cụ thống kê như là biểu đồ Pareto và biểu đồ nhân quả Dựa trên các phân tích từ các công cụ này, người chịu trách nhiệm sẽ có những báo cáo lên ban quản l‎y' để có thể đưa ra các hành động khắc phục hợp ly' và kịp thời Để phân tích các chỉ tiêu dưới đây chúng ta sẽ sử dụng các công cụ thống kê là biểu đồ Pareto và biểu đồ nhân quả Biểu đồ nhân quả: Biểu đồ phản ánh mối quan hệ giữa nguyên nhân và kết quả do nguyên nhân đó gây ra. Kết quả là những chỉ tiêu lỗi phát hiện còn nguyên nhân là những yếu tố ảnh hưởng tới chỉ tiêu đó. Mục đích của sơ đồ nhân quả là tìm kiếm, xác định các nguyên nhân gây ra những trục trặc ảnh hưởng tới chất lượng cũng như quy trình triển khai phần mềm. Từ đó đề xuất những biện pháp khắc phục nguyên nhân nhằm cải tiến và hoàn thiện chất lượng đối tượng quản l‎y'. Nguyên nhân gây ra lỗi phần mềm Hình 8: Minh họa biểu đồ nhân quả Biểu đồ Pareto: Là đồ thị hình cột phản ánh các dữ liệu chất lượng thu được, sắp xếp thu thứ tự từ cao đến thấp, chỉ rõ các vấn đề cần ưu tiên giải quyết trước. Nhìn vào biểu đồ ta thấy rõ kiểu lỗi phổ biến nhất, thứ tự ưu tiên khắc phục vấn đề cũng như kết quả của hoạt động cải tiến chất lượng Hình9: Minh họa biểu đồ Pareto Chỉ tiêu số lỗi phần mềm phát hiện trong dự án được tính toán nhằm mục đích theo dõi tỷ lệ số lỗi phần mềm được phát hiện trên tổng số ngày công lập trình trong dự án Trưởng nhóm kiểm thử sẽ là người chịu trách nhiệm tính toán chỉ tiêu này trong 2 trường hợp: Kết thúc giai đoạn kiểm thử Kết thúc dự án Công thức tính toán: Tỷ lệ lỗi dự án [weight defects] / MD lập trình Nguồn dữ liệu lấy từ: Timesheet Jira Báo cáo kết quả kiểm tra phần mềm Bảng 15: Tỷ lệ lỗi phần mềm phát hiện trong dự án Năm TLLDA/MDLT 2004 2005 2006 2007 <=5% 7 16 16 15 >5% 13 6 12 25 Trung bình 5,18% 4,25% 5,13% 7,52% Nguồn: Phòng chất lượng Chỉ tiêu tỷ lệ lỗi dự án trên một ngày công lập trình nói chung là khá lớn trong cả 4 năm do có những dự án chỉ có khoảng 250 MD lập trình mà có tới 4248 lỗi tức là Tỷ lệ lỗi dự án [weight defects] / MD lập trình =19.66, lại có những dự án không xảy ra bất kì một lỗi nào. Điều này có nghĩa là nếu thực hiện chính xác từ đầu sẽ rất khó xảy ra lỗi, ngược lại nếu ban đầu thực hiện đã có lỗi sẽ kéo theo rất nhiều lỗi khác nữa. Các lỗi gặp phải mang tính dây truyền, đồng thời dù đã sử dụng các công cụ thống kê để phân tích tìm ra nguyên nhân lỗi và ưu tiên khắc phục những lỗi nghiêm trọng, tần suất lớn trước nhưng việc làm này vẫn tỏ ra chưa có hiệu quả hoặc do viêc áp dụng chưa tốt mới để tỉ lệ lỗi quá cao như vậy.Năm 2007 là năm đạt tỉ lệ lỗi cao nhất có tới 25/40 dự án vượt quá chỉ tiêu cho phép và trung bình gấp tới 1,5 lần.Điều này cần được đội ngũ triển khai cũng như các lập trình viên xem xét lại việc thực hiện nếu tiếp tục để xảy ra tình trạng như hiện nay thì việc đạt được các chỉ tiêu về chất lượng tiến độ cũng như hiệu quả là một điều rất khó 3.3.2.3. Tỷ lệ lỗi bỏ xót trên quy mô dự án Chỉ tiêu này có chỉ số lỗi phần mềm bị khách hàng phát hiện trong quá trình thực hiện dự án. Việc tính chỉ tiêu này nhằm mục đích cung cấp số liệu về xu hướng và đo chất lượng sản phẩm. Quản trị dự án sẽ là người phải tính toán chỉ tiêu này vào các thời điểm sau: Hết mỗi giai đoạn Hết mốc kiểm soát Kết thúc dự án Công thức tính toán: Tỷ lệ lỗi bỏ sót = tổng số (số lỗi sau khi sản phẩm đưa vào vận hành * trọng số) / quy mô dự án Nguồn được lấy từ: Timesheet Jira Báo cáo kết quả kiểm tra phần mềm Biên bản triển khai Với quy ước là: Sản phẩm đưa vào vận hành bao gồm các tài liệu và chương trình VD: tài liệu Phân tích sau khi được phê duyệt, được dùng làm căn cứ để thiết kế mà phát hiện ra lỗi thì lỗi này cũng được tính là lỗi bỏ sót Bảng 16: Tỷ lệ lỗi bỏ xót trên quy mô dự án Năm TLLBX/QMDA 2004 2005 2006 2007 <=5% 18 18 26 32 >5% 2 4 2 8 Trung bình 2,16% 2,34% 1,89% 3,35% Nguồn: Phòng chất lượng Ngược lại với chỉ tiêu lỗi phần mềm phát hiện trong dự án, tỉ lệ lỗi bỏ xót trên quy mô dự án tức là lỗi phần mềm bị khách hàng phát hiện không lớn hầu như trong suốt 4 năm triển khai mỗi năm chỉ có một vài dự án bị phát hiện lỗi mà tỉ lệ lại rất nhỏ nên số trung bình thấp hầu như đều đạt tiêu chuẩn quy định. Có thể lí giải tình trạng này như sau: thực tế vẫn gặp rất nhiều lỗi nhưng do khách hàng không nhiều người có hiểu biết sâu về lĩnh vực này nên sẽ rất khó phát hiện ra các lỗi phần mềm đặc biệt là các lỗi nhỏ. Cho nên tỉ lệ lỗi bỏ xót nhỏ trong khi tỷ lệ lỗi phần mềm mà chính các cán bộ thực hiện phát hiện không phải là điều tốt mà chỉ là có thêm thời gian cho Trung tâm sửa chữa và điều chỉnh các lỗi gặp phải để ngay cả khi gặp những khách hàng chuyên nghiệp nhất họ cũng phải hài lòng Đây cũng là chỉ tiêu sử dụng biểu đồ nhân quả và biểu đồ Pareto để phân tích nguyên nhân và tìm ra giải pháp điều chỉnh 3.3.3. Nhóm chỉ tiêu quy trình 3.3.3.1. Số NC/NX trên một MM Chỉ tiêu số NC/NX trên 1 MM được cán bộ chất lượng tính toán nhằm mục đích tìm ra sự không phù hợp với quy trình trong quá trình hoạt động Chỉ tiêu này được tính toán vào các thời điểm: Hết mỗi giai đoạn Hết mốc kiểm soát Kết thúc dự án Công thức tính toán: Số NC/NX trên 1MM= Tổng số NC/NX/1 MM Dữ liệu lấy từ: Báo cáo đánh giá nội bộ Phiếu mô tả nguyên nhân, hành động khắc phục Quy ước: Tính trên từng dự án Với SBU = Tổng số NC/NX trên Tổng số MM thực hiện các dự án của SBU 3.3.3.2. Tỉ lệ NC/NX đóng đúng hạn Chỉ tiêu Tỷ lệ NC/NX đóng đúng hạn được tính toán nhằm mục đích tìm ra những NC/NX được khắc phục phòng ngừa từ đó suy ra các điểm không phù hợp với quy trình trong quá trình hoạt động được phát hiện mà không thực hiện mô tả nguyên nhân, hành động khắc phục. Cán bộ chất lượng thực hiện đánh giá tại các thời điểm sau: Theo tháng Theo qu‎y' Theo năm Công thức tính toán: Tỷ lệ NC/NX đóng đúng hạn = Tổng số NC/NX đóng đúng hạn/ Tổng số NC/NX được phát hiện Nguồn dữ liệu được lấy từ: Báo cáo đánh giá nội bộ Phiếu mô tả nguyên nhân, hành động khắc phục Với quy ước là Tính trên toàn bộ SBU 3.3.3.3. Tỷ lệ NC/NX lặp Chỉ tiêu Tỷ lệ NC/NX lặp được tính toán nhằm mục đích tìm ra sự không phù hợp bị lặp lại so với quy trình trong quá trình hoạt động Cán bộ chất lượng tiến hành đánh giá Theo qu‎y' Theo tháng Theo năm Công thức tính toán: Tỷ lệ NC/NX lặp = Số NC/NX lặp /Tổng số NC Nguồn dữ liệu được lấy từ: Báo cáo đánh giá nội bộ Phiếu mô tả nguyên nhân, hành động khắc phục Với quy ước là : Tính trên toàn bộ SBU NC/NX lặp là các NC/NX phát hiện trong kỳ trùng với danh sách NC/NX hay gặp do P&Q công bố. Danh sách này được cập nhật hàng quý NC(non comformity) là sự không phù hợp trong hệ thống chất lượng tiêu chuẩn đề ra. NC có 2 loại: NC đã xảy ra và cần các hành động khắc phục và NC có thể xảy ra trong tương lai và cần các hoạt động phòng ngừa(Các NC loại này được gọi là NX) Các biện pháp đã được Trung tâm Edocman thực hiện nhằm hạn chế những lỗi gặp phải và có thể gặp phải trong quá trình triền khai.Đó là: Thiết lập, áp dụng và duy trì các quy định bằng văn bản để xác định và áp dụng các hành động phòng ngừa liên quan đến phần mềm, dự án , quy trình và hệ thống quản trị Trung tâm Edocman Ghi nhận và xem xét các sự không phù hợp hiện thời để xác định nguyên nhân của các sự không phù hợp này. Ghi nhận xem xét và xử lí kịp thời các khiếu nại của khách hàng Sử dụng các báo cáo hoạt động, các kết quả đánh giá các hồ sơ chất lượng và các khiếu nại của khách hàng nội bộ để phát hiện và phân tích các nguyên nhân của sự không phù hợp tiềm năng Theo dõi các hành động khắc phục và phòng ngừa được xác định, kể cả việc kiểm tra xác nhận các hành động này và báo cáo về các kết quả kiểm tra xác nhận đó Tiến hành xem xét các thông tin cần thiết về các hành động khắc phục và phòng ngừa tại các cuộc xem xét của lãnh đạo chất lượng và quản trị dự án. Kiểm tra các hồ sơ về các hành động khắc phục và phòng ngừa Với những việc làm đó, trung tâm Edocman đã đạt được một số kết quả tương đối khả quan trong việc khắc phục và phòng ngừa các sai phạm trong quá trình triển khai phần mềm này Bảng 17: Tỷ lệ đảm bảo tính quy trình của dự án Năm Hạng mục Số NC/NX trên 1 MM Tỷ lệ NC/NX đóng đúng hạn Tỷ lệ NC/NX lặp <=0.5%(a) >0.5%(b) >=70%(a) <70%(b) <=20%(a) >20%(b) 2004 6 3 8 1 2 3 2005 1 5 3 3 3 0 2006 2 1 3 0 0 0 2007 1 0 1 0 0 0 Nguồn: Phòng chất lượng Trong đó cột(a) là cột đạt yêu cầu,cột (b) là cột chưa đạt yêu cầu theo hướng dẫn chỉ tiêu dự án phần mềm Nhận xét: + Năm 2004: Đây là năm đạt tỷ lệ cao nhất về cả 3 chỉ tiêu Về chỉ tiêu Số NC/NX trên 1 MM, trung bình có tới 9 lỗi gặp phải nhưng chủ yếu là lỗi nhỏ, lỗi lớn chỉ có 3 lỗi trong đó đã tìm được nguyên nhân và phương hướng giải quyết cho 8 lỗi làm cho tỷ lệ NC/NX đóng đúng hạn đạt tỷ lệ rất cao, vẫn còn một NX chưa tìm ra được phương án giải quyết. Việc giải quyết được nhanh chóng8/9 lỗi gặp phải cũng là do