Câu chuyện dự án nội bộ
PHƯƠNG PHÁP QUẢN LÝ DỰ ÁN
Cùng bắt đầu từ các phương pháp quản lý dự án mà thường được sử dụng trong các dự án nội bộ.
Các dự án nội bộ thường có những đặc điểm sau:
- Hướng tới việc đạt giá trị càng nhanh càng tốt.
- Các yêu cầu đối với các dự án nội bộ thường rất linh hoạt, nghĩa là chúng thay đổi khá thường xuyên. Ban lãnh đạo của doanh nghiệp có quan điểm rất rõ ràng: "Việc duy trì độ ngũ phát triển và triển khai riêng chính là để đáp ứng các yêu cầu linh hoạt".
Dựa trên các trao đổi trên các diễn đàn và phạm vi của bài viết này (hệ thống 1C, doanh nghiệp lớn, hệ thống ERP), có thể nói rằng, các doanh nghiệp lớn sẽ không bao giờ đồng ý về duy trì đội ngũ R&D phần mềm. Doanh nghiệp lớn cần sự rõ ràng. Nhưng vì đây là một dự án nội bộ, trong đó doanh nghiệp nhìn thấy công cụ cho phép đội ngũ CNTT nhanh chóng tạo nên các giá trị và điều chỉnh các yêu cầu.
Trong 90% trường hợp, đây không phải là Agile: đây là mô hình Waterfall, nhưng có sẵn rất nhiều các khối (Block) và nguyên mẫu. Đây là cách mà doanh nghiệp đang cố gắng ngồi trên hai chiếc ghế cùng một lúc: vừa có được tính linh hoạt, đồng thời có thể dự đoán trước. Làm thế nào để có thể làm được? Đây là một câu hỏi lớn, tất cả phụ thuộc vào năng lực của lãnh đạo.
LÝ DO DOANH NGHIỆP LỰA CHỌN DỰ ÁN NỘI BỘ
Phương án dự án nội bộ được áp dụng để kiểm soát quy trình, nhưng nếu bản thân doanh nghiệp không có phương pháp và cách thức quản lý thì điều này sẽ không giúp ích được gì. Nếu doanh nghiệp hiểu rằng mình không có đủ năng lực hay khó xoay sở các nguồn lực, hoặc không có nguồn lực thì nên lựa chọn phương án thuê ngoài đơn vị triển khai.
Sự khác biệt giữa dự án thuê ngoài và nội bộ:
- Trong các dự án nội bộ, Developer được coi như một nhân viên cố định trong công ty, khác với nguồn lực thuê ngoài, khi kết thúc dự án thì cũng rời khỏi công ty.
- Trong dự án thuê ngoài, đây là những chuyên gia (thường được giới thiệu như vậy) từ một công ty khác. Nghĩa là doanh nghiệp chỉ có thể tác động đến đội ngũ triển khai bằng các thủ tục được quy định trong điều lệ dự án hoặc hợp đồng. Không thể thay đổi đơn vị triển khai một cách dễ dàng. Cần phải có có những khiếu nại rất chính đáng và thậm chí phải tranh luận gay gắt hay cãi vã một cách nặng nề…
- Bộ phận là một đơn vị của công ty và tuân theo các quy tắc chung của công ty.
- Bộ phận CNTT không chỉ tham gia vào việc triển khai các hệ thống phần mềm, nó còn có nhiều chức năng khác, chức năng chính là đảm bảo mọi thứ hoạt động.
- Được gọt rũa cho việc đáp ứng những yêu cầu thay đổi ở mức độ cao nhất.
+ Động lực. Trong dự án nội bộ, đó là tiền lương và ngân sách CNTT của công ty. Còn trong dự án thuê ngoài, đó là doanh thu từ dự án. Trong dự án nội bộ, không có quan hệ "người bán – người mua".
- Đối với một dự án thuê ngoài, đơn vị triển khai tập trung vào việc hoàn thành các yêu cầu, vượt qua kiểm thử, nghiệm thu. Những thứ khác phát sinh ngoài khuôn khổ sẽ được quyết toán trong phụ lục bổ sung. Hoàn thành dự án, nhận tiền và rời đi. Mục tiêu là tạo ra lợi nhuận, tức là tiêu tốn nguồn lực ít hơn so với doanh thu có được theo hợp đồng.
- Trong một dự án nội bộ, đơn vị triển khai là một phần của bộ phận CNTT. Mục đích của bộ phận CNTT là duy trì cơ sở hạ tầng CNTT.
Như vậy, có thể thấy rằng, thuê ngoài triển khai dự án là tập trung vào kết quả, và KPI là doanh thu. Còn dự án nội bộ tập trung vào quá trình, KPI là tiền lương và thưởng.
CÂN BẰNG GIỮA CÁC BÊN
Trong bất kỳ công ty nào cũng có thể hình dung có 3 cấp độ nhân lực: TOP (Lãnh đạo), Trưởng bộ phận và Người thực hiện.
Chúng ta hãy xem cách mà lớp nhân lực này có thái độ thế nào đối với một dự án nội bộ:
- TOP (Lãnh đạo). Trong bất kỳ dự án triển khai nào (bên ngoài hoặc nội bộ), mọi khởi xướng đều bắt đầu từ TOP. Quyết định luôn được đưa ra từ Lãnh đạo. Bất kỳ dự án triển khai nào cũng đề liên quan đến ngân sách CNTT và cần phải thống nhất từ sớm khi xây dựng ngân sách hàng năm của công ty.
Kết quả lý tưởng cho TOP là tiết kiệm tài chính từ việc áp dụng hệ thống. Đó là cắt giảm lao động hoặc thay đổi hệ thống này sang hệ thống khác, giảm chi phí sở hữu tổng thể (Total Cost of Ownership). Đó là tài chính, vì KPI cho TOP luôn gắn liền với tài chính.
- Người thực hiện. Bao giờ cũng có sự chống đối từ dưới lên, bởi vì những người thực hiện hiểu rằng, công việc của họ sẽ bị thay đổi. Ngay cả khi chỉ thay đổi một quy trình hoặc một bước duy nhất thì cũng gây ra tâm lý sợ hãi.
Kết quả lý tưởng cho người thực hiện là khi hệ thống làm đơn giản hóa công việc của người dùng cuối. Công việc ít đi, thói quen thừa biến mất, nhưng không đến nỗi nhân viên bị sa thải.
- Trưởng bộ phận (TBP). Họ là những người nằm ở lớp giữa, ở đây có sự giao thoa của các lợi ích.
Động cơ của TBP
TBP không phải là TBP khi không có nhân viên. Thành thật mà nói, bất kỳ TBP nào cũng quan tâm đến việc nhìn thấy bộ phận của mình phát triển.
Hơn nữa, TBP quan tâm đến việc anh ấy quản lý quy trình, anh ấy phải duy trì quyền lực, nghĩa là anh ấy phải thực hiện công việc mà không ai có thể làm thay, đồng thời với những nét riêng của mình.
TBP quan tâm đến việc đơn vị của mình hoạt động rõ ràng và trôi chảy. Mọi đổi mới và thay đổi đều là rủi ro và sau đó sẽ được phản ánh trong KPI của TBP. KPI của TBP phần lớn phụ thuộc vào kết quả công việc trong một đơn vị cụ thể. Ví dụ: Bộ phận pháp lý: số lượng vụ kiện đã thắng và theo đó, số tiền tiết kiệm được; Kế toán: giá trị của các khoản phạt; Chuyên gia tài chính: chênh lệch tỷ giá, các khoản vay, kế hoạch thuế…
Kết quả triển khai lý tưởng đối với một TBP phải phù hợp với các quy tắc này. Tức là bộ phận phải được bảo toàn, mức độ ảnh hưởng phải được bảo toàn, không có nguy cơ không hoàn thành KPI do áp dụng hệ thống thông tin mới.
Sự thành công của dự án phụ thuộc vào việc các TBP chọn phe nào. Họ là những người nghiệm thu công việc. Họ có ảnh hưởng tối đa đến dự án.
Triển khai hệ thống không phải chỉ là công việc của các chuyên gia CNTT mà còn là công việc quản lý hành chính. Các TBP đều có những lợi ích riêng của họ và trước khi triển khai, TOP cần phải chuẩn bị nền móng và truyền đạt cho các TBP những gì sẽ làm, và những điều này sẽ dẫn đến hậu quả gì. Nếu cần thiết, đôi khi thậm chí cần phải có những biện pháp "thiết quân luật".
NHỮNG VẤN ĐỀ TRONG CÁC DỰ ÁN NỘI BỘ
Trong dự án nội bộ sẽ không tồn tại khái niệm "kết quả tài chính" như các dự án thuê ngoài, về cơ bản là không có. Tất nhiên, có thể tính toán dựa trên chỉ tiêu tiết kiệm lao động. Nhưng những tính toán chi tiết cũng chẳng ích gì (xin phép nói thêm ở phần dưới).
Đối với một dự án nội bộ, chỉ các mốc của dự án và việc hoàn thành chúng đúng thời hạn là quan trọng đối với Project Manager (PM). Như vậy, vấn đề chính ở đây là việc không đáp ứng các mốc thời gian. Đây là chỉ số duy nhất để đánh giá hiệu quả của PM trong một dự án nội bộ.
Những điều có thể gây ra sự chậm trễ của dự án
Xin không phân tích những lý do thông thường, có lẽ tất cả mọi người đều biết, đó là:
- Có thể là do ước tính không chính xác.
- Thiếu nguồn lực dự phòng.
- Triển khai phút cuối, không đều đặn.
- Phân bổ nhiệm vụ không hợp lý.
- Nhảy qua lại giữa các đầu mục công việc, mất nhiều thời gian dành cho việc dẫn nhập.
Chúng ta cùng phân tích những điểm có liên quan đến người đặt hàng trong dự án nội bộ:
Vấn đề số 1. Không có công tác tư tưởng với các TBP
Trật tự là quy định cho biết ai cần làm gì. Các quy trình này cũng nên được thực hiện trước khi triển khai hệ thống, vì trong một số trường hợp, các quy trình nghiệp vụ cần được điều chỉnh cho phù hợp với hệ thống (có những tình huống mà điều này luôn hiệu quả và hợp lý).
Cũng có nhiều ý kiến rằng cho rằng: "Đội ngũ IT là IT, đừng nên động chạm vào các bộ phận nghiệp vụ của chúng tôi. Các bạn IT có thể làm gì đó cho chúng tôi, quan trọng là nó sẽ giúp công việc của chúng tôi dễ dàng hơn". Cách tiếp cận này là phá hoại.
Việc triển khai hệ thống không phải là câu chuyện về việc tạo điều kiện thuận lợi cho công việc của người dùng cuối, mà là về việc giảm thiểu chi phí của công ty.
Nếu từ phía TOP vẫn chưa tiến hành các công tác tư tưởng thì các TBP vẫn còn nhận thấy quyền lực của mình là luôn đứng ở vị thế phá hoại dự án.
Cần dành thời gian cho công việc triển khai. Ví dụ, có những lúc nhân viên kế toán nói: "Chúng tôi đang tổng kết của tháng, vui lòng quay lại sau hai tuần nữa". Trong phần này, công tác tổ chức nên chú trọng đến việc dành thời gian cho công việc: trong bất kỳ trường hợp nào cũng sẽ có các cuộc họp, kiểm thử, thống nhất biên bản…
Vấn đề số 2. PM có mức độ ảnh hưởng thấp trong nội bộ doanh nghiệp
PM không thể đưa ra quyết định, bởi vì anh ấy và các BA của anh ấy thường bị "xua đuổi" một cách sỗ sàng. Các vấn đề không được leo thang (Escalate) lên mức cao hơn, hoặc có leo thang nhưng muộn, hay có leo thang nhưng không đủ tầm quan trọng.
Điều này gây lãng phí thời gian mà không lấy lại được.
Vấn đề số 3. Chống đối triển khai
Chúng ta cùng xem thuật ngữ này có hàm ý gì:- Việc thống nhất các quyết định luôn bị kéo dài. Ở đây, có thể thao túng bằng cách từ chối đồng ý với các quyết định (ví dụ: mô tả lô-gic nghiệp vụ, biên bản). Có nhiều lý do biện minh cho điều này, ví dụ thiếu thời gian và đang ngập việc. Việc kiểm thử hệ thống không thể thực hiện, các lỗi và ý kiến không được ghi nhận.
- Từ chối tiếp nhận nghiệm thu mà không có lý do. TBP có thể đưa ra nhiều lý lẽ, rằng hệ thống sẽ làm phức tạp công việc, tăng thời gian hoạt động. "Thật bất tiện khi làm việc, mọi người cần được đào tạo, còn tốc độ làm việc không tăng lên".
- Liên tục bổ sung các yêu cầu mới. Dự án có thể là bất cứ thứ gì, nhưng hạng mục công việc sẽ được nghiệm thu chủ yếu bởi các TBP. Có những kỳ vọng từ phía TBP, họ cho rằng, đội ngũ CNTT chỉ làm theo đúng yêu cầu của người đặt hàng. Kết quả là với tư tưởng này, mục tiêu ưu tiên của dự án dần dần bị chuyển dịch một cách chậm rãi nhưng chắc chắn, từ "Triển khai giải pháp tổng thể với khả năng tái cấu trúc các quy trình nghiệp vụ" sang thành mục tiêu "Đáp ứng tất cả mong muốn của mỗi người dùng cụ thể".
- Từ chối điều chỉnh quy trình nghiệp vụ cho phù hợp với hệ thống. Thử hình dung cách nhìn của TBP mà từ chối mọi thay đổi về quy trình nghiệp vụ. Việc thay đổi là một phần không thể thiếu trong việc triển khai hệ thống. Một cái gì đó sẽ phải thay đổi. TBP thường biện minh cho điều này bằng cách nói rằng, các quy trình hiện tại đều đúng, không thể thay đổi được gì, nếu không sẽ có hậu quả xấu.
Phản hồi phải được tiếp nhận, nhưng không phải trong mọi trường hợp, tất cả các ý kiến đều cần dựa trên cơ sở thực tế. Trên thực tế rất hay gặp tình huống, khi mà người thực hiện công việc chính là người phá hoại quy trình, thổi phồng vấn đề, biến "con kiến thành con voi". Đây là một điểm rất tinh tế mà cần được giám sát bởi PM dự án. Nếu có bất cứ điều gì thì ngay lập tức chuyển lên cấp độ TOP (nhưng điều này không nên được thực hiện vào cuối dự án, khi đã quá muộn, mà ở giai đoạn đầu nếu như chỉ có một chút nghi ngờ về sự chống đối).
Những lý do chống đối dự án
Bây giờ chúng ta sẽ nói về 2 lớp nhân lực: Người thực hiện và TBP.
Lý do số 1. Sự lộn xộn (hay mớ hỗn độn)
Mớ hỗn độn là một thái ấp. Chúng ta có thể thường xuyên gặp các mớ hỗn độn trong các bộ phận cần tự động hóa. Mớ hỗn độn, nếu dịch sang ngôn ngữ quản lý thì thế này:
- Phần lớn các công việc đều làm thủ công.
- Thiếu quy định làm việc (hoặc có quy định nhưng được không tuân thủ).
- Hạn chế thông tin.
- Có rất nhiều thay đổi (đổi mới) trong các quy trình nghiệp vụ từ phía TBP, nhưng không được văn bản hóa và phổ biến lại.
TBP muốn giữ lại mớ hỗn độn của mình, bởi vì việc lập lại trật tự đồng nghĩa với việc bị cắt giảm quyền lực. Có những bộ phận như vậy, điều này không hiếm. Có những dự án mà trong quá trình đàm phán với các CEO, đơn vị triển khai có thể thấy những câu như: "Chúng tôi rất ngăn nắp, có hàng trăm quy định cho mỗi nhân viên". Khi khảo sát các quy định, đơn vị triển khai lại thấy rằng, các quy trình nghiệp vụ thực tế hoàn toàn khác xa với văn bản. Chỉ có một kết luận: không phải lúc nào CEO cũng nhìn thấy tình hình thực tế, bởi vì họ không xuống cấp độ của từng nhân viên (mà đúng thế, họ không nên hạ thấp đến mức đó).
* Nhìn theo một cách khác, "Sự lộn xộn" không hẳn là điều gì xấu. Đây là một giai đoạn riêng biệt trong quá trình phát triển của doanh nghiệp. Đó là khi một doanh nghiệp mới phát triển, các quy trình sẽ liên tục thay đổi va sự lộn xộn là điều dễ hiểu. Lối thoát ở đây là chuyển sang chế độ quản lý thủ công (theo tình huống). Ngoài ra, có thể xảy ra tình trạng lộn xộn ở các công ty lớn khi mở các lĩnh vực hoạt động mới. Do vậy, thuật ngữ này không phải lúc nào cũng mang ý nghĩa tiêu cực.
Lý do số 2. Thay đổi tiềm năng
Mọi thay đổi đều tiềm ẩn các rủi ro.
Lý do số 3. Khả năng thu hẹp quy mô của bộ phận
Khi có người nói ràng, sau khi triển hệ thống thì bộ phận từ 9 người sẽ chỉ còn 3. Tất nhiên, điều này sẽ không truyền cảm hứng cho nhân viên để họ đóng góp.
Lý do số 4. Sợ hãi
Người thực hiện phản ứng với điều này thế nào? Ví dụ: Một giám đốc tài chính biết cách thiết lập các báo cáo thông dụng, làm việc với các tham số lọc và có thể tự tạo báo cáo chỉ mất 5 giây. Điều này có nghĩa là không cần phải yêu cầu những người trẻ hơn làm hộ (không cần viết thư, không cần soát lại báo cáo, chỉ cần mở báo cáo và xem, nếu cần thì chọn một chỉ tiêu khác và lập báo cáo). Thời gian làm việc được giảm bớt. Các công việc chân tay tỷ mẩn bị loại bỏ. Chính vì vậy, việc giải phóng mọi người khỏi các công việc tay chân vẫn làm trước đây khiến họ sợ hãi.
Bất kỳ người nào trong tình huống tương tự cũng có cách ứng xử như vậy, đó là cố gắng chống lại.
Động lực của một chuyên gia CNTT trong các dự án nội bộ
Động lực cho một dự án nội bộ là tiền lương. Theo thống kê, mức lương của cán bộ dự án nội bộ thường cao hơn so với những chuyên gia của các đơn vị triển khai thuê ngoài. Có thể hình dung lộ trình nghề nghiệp của một chuyên gia thế này: đầu tiên là làm việc tại một đơn vị triển khai, học hỏi thật nhiều kinh nghiệm, sau đó chuyển sang doanh nghiệp để tham gia vào dự án nội bộ dài hạn.
Cán bộ dự án là một phần của bộ phận CNTT. Mục đích của bộ phận CNTT là duy trì hạ tầng và hệ thống CNTT. Ở đây dành nhiều sự tập trung vào quá trình hơn là vào kết quả.
Đối với một dự án thuê ngoài, đơn vị triển khai tập trung vào việc hoàn thành các yêu cầu, vượt qua kiểm thử, UAT để nghiệm thu. Còn tất cả những gì nằm ngoài khuôn khổ ban đầu sẽ được quyết toán riêng thông qua phụ lục bổ sung. Nhận tiền và rời đi. Mục tiêu là tạo ra lợi nhuận, sử dụng ít nguồn lực hơn so với giá trị hợp đồng.
Các vấn đề với động lực
"Duy trì công việc, nhưng không hoàn thành công việc càng sớm càng tốt, rồi sau đó xin thôi việc". Đây là một kiểu suy nghĩ trong tiềm thức, nó đều tồn tại ở tất cả mọi người trong một dự án nội bộ
Mức lương chuyên gia CNTT trong dự án nội bộ thường cao hơn so với các đơn vị triển khai thuê ngoài. Nguồn lực ngồi trên mức lương cao tất nhiên sẽ thoải mái và có lợi hơn.
Đó là lý do trong những dự án nội bộ thường cuốn hút những người có tâm lý đặc biệt và yêu thích sự ổn định.
Cách giải quyết vấn đề động lực
Có thể chỉ có một cách: xây dựng KPI phù hợp để đạt được các mốc quan trọng. Trong thực tế của tác giả và trong thực tế của những người mà tác giải đã phỏng vấn trong các dự án nội bộ, dữ liệu KPI chỉ có ở các PM hoặc hoàn toàn không có. KPI cũng nên được mở rộng cho những người thực thi dự án: BA, Developer.
KHÔNG nhất thiết phải xây dựng KPI tập trung vào số lượng yêu cầu đã hoàn thành. Khi đó, điều này sẽ khuyến khích mọi người không thực hiện dự án mà chỉ cố hoàn thành các yêu cầu càng nhiều càng tốt. Điều này sẽ tạo ra ảo tưởng về công việc, nhưng không tạo ra kết quả.
Vấn đề liên quan ngân sách CNTT hàng năm
Nếu có một KPI tập trung vào các mốc quan trọng thì là điều tốt, nhưng trường hợp này hiếm khi xảy ra. Ngay cả khi đúng như vậy, vẫn có một vấn đề khác, đó là kéo dài thời gian và tăng số lượng hạng mục công việc dự án.
Ví dụ: Một doanh nghiệp có bộ phận CNTT và ngân sách CNTT. Và có KPI cho các mốc quan trọng. PM trong một dự án nội bộ sẽ thường thiên về việc kéo dài dự án càng lâu càng tốt, biến con kiến thành con voi, và mở rộng bộ phận CNTT, hay hoàn thành vượt mức kế hoạch và giải ngân ngân sách CNTT. Đây là động lực trực tiếp.
Chứ không phải là: thuê thêm người, hoàn thành dự án trong 2 năm chứ không phải 5 năm, rồi sau đó sa thải 70% nhân viên, chỉ để lại nhóm bảo trì.
Xin nhấn mạnh rằng, về mặt hình thức thì không ai phản đối việc triển khai hệ thống, nhưng động lực gián tiếp luôn có những tác động chính. Nếu ngân sách CNTT được thông qua thì nó phải được giải ngân, nếu không, đó là một dấu hiệu của sự yếu kém trong việc lập kế hoạch.
Cách giải quyết vấn đề ngân sách
Cần duy trì mức độ cao việc huy động TOP tham gia vào các quy trình, cũng như cần có thẩm định và kiểm toán của bên thứ ba. Có lẽ đây là lối thoát duy nhất.
DỰ ÁN NỘI BỘ NÊN TẬP TRUNG VÀO ĐIỀU GÌ
Mục đích chính của doanh nghiệp là lợi nhuận. Còn dự án phải có lợi ích.
Để bắt đầu, doanh nghiệp cần phải tự mình trả lời câu hỏi là tại sao phải cần triển khai hệ thống:
- để giảm thiểu chi phí;
- hay chỉ đơn giản là cần có hệ thống, vì doanh nghiệp khác đều làm vậy.
Hiệu quả
Mục đích chính của dự án triển khai là tăng năng suất lao động. Tức là tăng chỉ số "Kết quả" / "Công việc".
Ví dụ về một dự án triển khai hệ thống quản lý ngân sách cho một bộ phận (20 người), mọi thứ đều thực hiện thủ công. Có thể có những kết quả sau:
- Triển khai dự án, sau đó thuê 2 người để hỗ trợ và sa thải 10 nhân viên trong bộ phận tài chính.
- Triển khai dự án, sau đó thuê 7-8 chuyên gia CNTT đắt tiền để hỗ trợ và sa thải 2 nhân viên trong bộ phận tài chính.
Trường hợp đầu là tốt, trường hợp hai là xấu.
Dự án đầu tư
Có thể có mục đích: "Tăng vốn hóa doanh nghiệp". Trong trường hợp này, càng đắt càng tốt (đây là một dạng đầu tư). Sẽ có một giá trị tài sản lớn. Đây là một chủ đề về các tập đoàn và doanh nghiệp lớn. Bộ phận CNTT tuân thủ theo mục tiêu chung của công ty nên cũng đi theo con đường phát triển này.
Sự hài lòng của người dùng cuối
Nếu như cần chạy theo xu hướng thì cần phải phù hợp với môi trường làm việc của công ty.
HIỆU QUẢ DỰ ÁN VÀ CÁCH ĐO LƯỜNG
Một dự án nội bộ có thể đo lường hiệu quả bằng nhiều phương pháp và công thức tính toán. Không nhất thiết phải biết, nhưng điều quan trọng là phải hiểu các nguyên tắc cơ bản. Hơn nữa, không cần thiết phải tính toán tất cả những chỉ tiêu này bằng con số. Có thể chỉ cần sử dụng một khái niệm cơ bản về mức độ hiệu quả: Lợi ích phải lớn hơn chi phí.
Lợi ích và chi phí
- Chi phí: đây chính là chi phí thực hiện. Có khái niệm về chi phí sở hữu tổng thể (TCO), ở đây có bao gồm cả chi phí phần cứng.
- Lợi ích: là khoản tiết kiệm được, nghĩa là cắt giảm lao động hoặc giảm khối lượng công việc của một người để có thể gánh thêm các việc khác.
Các khoản tiết kiệm nên lớn hơn tổng chi phí. Nhưng có lẽ chúng ta khó có thể tìm thấy một dự án nào có thể sinh lãi về mặt tài chính.
Thông thường, cần phải đảm bảo rằng, dự án không bị lỗ quá nhiều. Hầu như tất cả các dự án nội bộ đều không có lãi, khi mà có thể được đo lường bằng chi phí. Điểm mấu chốt là cách mà chúng ta đối xử với dự án triển khai.
Hiệu quả có thể được xem xét không phải trên toàn bộ dự án, mà là trên các hạng mục công việc. Hiệu quả có thể là một lý do để từ chối thực hiện một hạng mục triển khai.
Hãy xem xét một ví dụ. Có một hạng mục triển khai để hoàn thiện hệ thống. Một người dùng yêu cầu làm "mượt" một nghiệp vụ trên hệ thống, nhưng điều này lại vi phạm quy trình chuẩn của ERP (chúng ta đều hiểu điều gì sẽ xảy ra nếu ERP bị đục khoét). Ngay cả khi có thể đáp ứng yêu cầu của người dùng này thì có thể làm ảnh hưởng một số nghiệp vụ của phòng ban khác, và kết quả là sẽ làm gia tăng số giờ để xử lý. Trong khi đó, với yêu cầu ban đầu chỉ tiết kiệm được 5-10 phút.
Nghĩa là, nếu chúng ta đi theo mục tiêu hiệu quả thì cần phải loại bỏ các yêu cầu mà không mang lại lợi ích, chỉ để lại chức năng hoặc cải tiến thực sự có ý nghĩa (chúng mang lại hiệu quả tiết kiệm thời gian nhiều hơn 5 phút)
Khi nhu cầu người dùng cuối sẽ không được đáp ứng, dần dần tích tụ sẽ làm gia tăng mức độ không hài lòng.
- Nhiệm vụ này có đáng làm hay không. Trong cách tiếp cận đầu tiên, chúng tôi sẽ không làm.
- Trong trường hợp thứ hai, chúng tôi sẽ làm, những sẽ tiêu tốn nguồn lực. Mức độ khả thi của những khoản chi này thì luôn là một câu hỏi lớn.
Nhược điểm của nhiều dự án nội bộ là không ai đánh giá xem những cải tiến như vậy có phù hợp với kế hoạch ban đầu hay không, trong khi đó, những yêu cầu của người dùng luôn được đặt lên hàng đầu. Dễ hiểu thôi, vì KPI của đội ngũ CNTT phụ thuộc vào việc người đặt hàng có chấp nhận kết quả hay không. Khi cảm nhận những quyền lực của mình, người đặt hàng có thể lạm dụng cho những mục tiêu riêng cho mình.
LỜI KẾT
Bất kỳ dự án nội bộ nào cũng không chỉ là nhiệm vụ của các chuyên gia CNTT mà còn là nhiệm vụ của các TOP. Đây là một nhiệm vụ quản lý.
- (1) TOP nên hiểu rằng, họ phải sử dụng quyền năng của mình để kiểm soát và thúc đẩy các ý tưởng khi triển khai hệ thống.
- (2) Đả thông tư tưởng cho các TBP, để họ hiểu rằng các quy trình kinh doanh sẽ thay đổi và TBP phải ủng hộ dự án. Họ phải nhận thức được và sẵn sàng cho những thay đổi. Công tác tư tưởng phải được tiến hành, và không cần có các biện pháp "thiết quân luật".
- (3) Khi đặt hệ thống vào một mớ hỗn độn, chúng ta sẽ nhận được một mớ hỗn độn được tự động hóa. Trước tiên cần chuẩn hóa các quy trình, sau đó mới triển khai giải pháp.
- (4) Bộ phận CNTT nên tập trung vào việc hoàn thành dự án đúng thời hạn, tức là nên có KPI về thời hạn cho từng người trong bộ phận CNTT, chứ không phải là chỉ dành cho PM dự án.
- (5) Nếu ngân sách CNTT bị vượt quá, cần tiến hành thẩm định và kiểm toán hoạt động.
Viết tắt và thuật ngữ:
IT (Information Technology) - Công nghệ thông tin
KPI - Key Performance Indicators
Nhận xét
Đăng nhận xét