• Thứ Sáu, 02/12/2005 15:31 (GMT+7)

    Chất lượng ERP qua góc nhìn nhà triển khai

    Chât lượng là gì? Một trong những câu trả lời: "Đó là cái khách hàng trả tiền để có được". Vậy khách hàng (KH) trả lời cho cái gì khi bỏ tiền mua hệ thống ERP và dịch vụ triển khai?

    Chất lượng là gì? Một trong những câu trả lời: "Đó là cái khách hàng trả tiền để có được". Vậy khách hàng (KH) trả cho cái gì khi bỏ tiền mua hệ thống ERP và dịch vụ triển khai?

    Chất không đi đôi với lượng

    Có thể nói, khi DN định mua hệ thống quản lý tổng thể, họ muốn thực hiện những mục tiêu chiến lược hoặc đơn thuần chỉ cải tổ một số bộ phận cụ thể. Đây là trường hợp lý tưởng cho cả KH lẫn nhà cung cấp. Một bên đã hiểu rất rõ họ muốn gì, bên kia biết mình cần làm gì. Sẽ còn tốt hơn nữa nếu các thành viên tham gia dự án biết cách đo hiệu quả của dự án, hay nói cách khác đánh giá được chất lượng hệ thống. Lúc đó, tại mỗi thời điểm đều có thể xác định chính xác tiến độ của dự án.

    Nói thì dễ. Nhưng thực tế, rất ít khi người ta xác định rành mạch phạm vi dự án. Bản thân tính tích hợp của hệ thống ERP khi không cho phép triển khai rời rạc, đã là điều cản trở. Ngay cả khi đã có định hướng chiến lược cụ thể, ví dụ "cải tổ hệ thống thông tin với KH và nâng cấp hệ thống đặt hàng", vẫn rất dễ bị lệch lạc trong các bước tiếp theo.

    Trong giai đoạn lựa chọn giải pháp, các nhà dự thầu luôn nhấn mạnh mọi tính năng ưu việt trong giải pháp của mình, kể cả những điểm thực sự không cần thiết cho KH. Cán bộ kinh doanh (KD) khi không đủ khả năng tư vấn cho KH về những vấn đề cần giải quyết trong DN, thường hết lời ca ngợi tính năng giải pháp anh ta đang chào, nhất là khi các giải pháp cạnh tranh không có các tính năng đó. Đại diện DN nhân đó sẽ kéo dài thêm danh sách yêu cầu để tận dụng hết những tính năng mới, hiện đại, để rồi bắt nhà tư vấn phải "tống" tất cả yêu sách đó vào hợp đồng triển khai.

    Cuối cùng, một cán bộ KD nào đó cũng sẽ toại nguyện sau khi thuyết phục được KH "hạ bút" ký toẹt một cái là xong. Nhưng anh ta biết đâu rằng, chính anh ta là người "bỏ bom" các đồng nghiệp bên bộ phận triển khai. Bọn họ sẽ phải gò lưng ra làm tất cả những gì ghi trong hợp đồng, chẳng biết là KH có cần thật sự hay không. Chẳng bên nào dám lược giảm quy mô dự án sau khi đã khởi động. Nhà cung cấp dịch vụ sợ mang tiếng bòn rút, sẽ khó hạch toán. Bên KH chẳng ai dám công nhận yêu cầu của mình đưa ra là không cần thiết. Đây chính là nguồn gốc của mọi vấn đề trong quá trình triển khai.

    Những năm 90, nói chung các dự án tôi tham gia đều có cơ chế "mở", nghĩa là quy mô dự án được phát triển dần trong quá trình KH làm quen với hệ thống, còn nhà cung cấp dịch vụ có sự hiểu biết đầy đủ về KH. Sang đầu thế kỷ 21, hầu hết các dự án ở Ba Lan đều mang tính "fixed price", nghĩa là quy mô và giá được xác định cứng từ đầu. Tôi cho rằng, phương pháp này gây thiệt hại cho cả hai bên. KH luôn có xu hướng mở rộng giới hạn dự án, với ý nghĩ: "mình lèn "nó” càng nhiều càng tốt". Bên triển khai lăm lăm: "làm thế nào để đỡ tốn công nhất". Những vấn đề mấu chốt cần được giải quyết rất dễ bị bỏ sót trong cuộc xô đẩy ấy. Vấn đề ở chỗ KH luôn "có lý”. Nhà triển khai khôn ngoan phải biết điểm dừng, để "thượng đế” còn quay lại với những dự án mới chứ!

    Thành công của ERP trong thực tế

    Hãy xét trường hợp một công ty "con" nhận được yêu cầu triển khai hệ thống từ công ty "mẹ”, trong khuôn khổ chuẩn hóa tổ chức và quy trình KD. Thoạt nghe, những dự án dạng này rất "ngon ăn" với nhà triển khai: quy trình KD đã được chuẩn hoá, các bước triển khai đã được chuẩn bị sẵn.

    Nhưng... nhân viên công ty "con" chỉ quan tâm làm thế nào để mọi thứ vẫn y nguyên. Họ thường chẳng tin vào những áp đặt của "trung ương" và sẽ rất "sung sướng" nếu dự án thất bại. Nhà triển khai khi đó có thể dùng phép "chia để trị” để bao biện cho những thiếu sót trong hệ thống của mình: Với công ty "mẹ”, họ báo cáo rằng, bên công ty con không chấp nhận quy trình từ trung ương, hoặc có một số vấn đề đặc thù của địa phương làm cản trở quá trình triển khai. Với công ty "con", họ lại phân trần: chúng tôi làm theo chuẩn của trung ương. Nhân viên công ty "con" không có thời gian kiểm định "chuẩn trung ương", còn tác giả của chúng từ "trên" lại e ngại, không biết còn sơ suất gì không. Và mọi người đều thở phào nhẹ nhõm khi dự án kết thúc trong thời hạn và ngân sách, còn hiệu quả không phải là vấn đề đặt ra nữa.

    Thực tế cho thấy, việc mua bán hệ thống ERP thường không đi đôi với việc xác định hiệu quả kinh tế của hệ thống tương lai. Nhiều DN mua ERP chỉ để khuếch trương tên tuổi. Một vị giám đốc quản lý bằng cảm tính có thể cho rằng đã đến lúc phải hiện đại hóa DN của mình thông qua CNTT!!! Trong nhiều trường hợp khác, mục đích triển khai được nêu ra rất chung chung, ví dụ "nâng cấp môi trường ứng dụng CNTT trong tương lai". Khi không có tiêu chí rõ ràng để đánh giá sự thành công, việc triển khai chỉ còn lại 2 thông số là thời hạn và ngân sách. Khi đó, các bên liên đới chỉ tập trung hoàn thành trong kế hoạch, miễn sao DN sau triển khai hoạt động không tồi hơn trước.

    Lúc này, sự thành công của dự án với nhà cung cấp thật đơn giản – làm sao KH không kêu ca là được. Để đạt được điều đó, hai bên đôi khi phải có những thoả thuận ngầm. Gay go nhất là khi một hay vài tính năng trong hệ thống không hoạt động. Vì vậy, nhà triển khai muốn nhận đủ thù lao phải tập trung thực hiện nghiệm thu một cách hoàn hảo. Việc hoàn thành nghiệm thu đóng vai trò sống còn đối với nhà triển khai để tồn tại cùng uy tín. Ngoài ra, rất cần chú trọng chuẩn bị tài liệu cho các cấp sử dụng và đào tạo, hỗ trợ nhân viên phía KH trong thời gian vận hành đầu tiên. Ngạn ngữ Ba Lan có câu: "Sự kết thúc sinh ra tác phẩm!".

    Yếu tố con người - mấu chốt của sự thành công

    Cán bộ tư vấn có quan điểm thế nào về chất lượng của quá trình triển khai? KH luôn mong muốn được làm việc với một đội ngũ tư vấn lịch thiệp mà có trách nhiệm, hiểu biết mà biết giữ lời, biết trân trọng đối tác lại hăng say làm việc, có thể làm chỗ dựa cho người sử dụng hệ thống sau này.

    Việc tuyển chọn nhân sự, đào tạo nghiệp vụ và tạo động cơ làm việc cho họ là cả một vấn đề không đơn giản. Trong quá trình thiết kế hệ thống, không ai có thể hoạch định chính xác lượng nỗ lực cần thiết cho mỗi giai đoạn cụ thể. Vì vậy các cán bộ triển khai phải xác định sẽ vất vả vật lộn đến khi đạt thành quả cuối cùng. Chuyên gia tư vấn luôn phải nắm kiến thức vững hơn KH cả về nghiệp vụ lẫn công nghệ, dù nhiều dù ít, dù phải thức trắng đêm để nghiên cứu tìm tòi. Từ phía lãnh đạo, cần có sự động viên, khuyến khích thích hợp, tránh trường hợp cán bộ bỏ đi giữa chừng. Các công ty tư vấn thường phải xếp "đúp" hai chuyên gia ở những phân hệ quan trọng trong một dự án, khi cần một người có thể "cáng" luôn nhiệm vụ của người kia.

    Một điều quan trọng nữa là cần có sự hợp tác chặt chẽ giữa nhóm triển khai của nhà tư vấn và nhóm triển khai của DN. Cần cung cấp cho KH kế hoạch triển khai cụ thể, nhiệm vụ rõ ràng của từng cán bộ tư vấn. Một kinh nghiệm thường được áp dụng là thăm dò đánh giá của KH về từng người trong nhóm triển khai, sau đó kín đáo để mỗi người biết mà rút kinh nghiệm cho bản thân. Cán bộ tư vấn triển khai không những phải là chuyên gia giỏi, mà còn cần biết cách truyền đạt thông tin trong sáng, biết cách đàm phán, có phương pháp sư phạm. Hơn nữa, cần có ý thức xây dựng, tích cực thúc đẩy sự phát triển của công ty. Theo kinh nghiệm của tôi, công ty tư vấn triển khai nào giữ vững được đội ngũ nhân viên đều phát huy được thế mạnh riêng của mình, một điều kiện cần thiết để tồn tại và phát triển.

    Không thể coi thường biên bản họp

    Mặc dù kết quả của dự án sẽ được nghiệm thu theo các điều kiện hợp đồng, các yêu cầu từ phía KH có thể phát sinh hoặc thay đổi. Để tránh mọi sự phiền phức, các bạn cần rất chú ý làm các biên bản họp thật chi tiết. Không biết chừng có lúc chúng sẽ thành phao cứu hộ trước các cuộc cãi lộn về các quyết định hay ý tưởng được phát sinh từ bên nào. Ngoài ra, do mọi chi tiết đều được ghi chép trong biên bản, các bên sẽ thận trọng hơn trong khi đàm phán để, đưa ra những quyết định xác đáng. Khi một bên đã ra quyết định, không đơn giản có thể thay đổi, nếu có cũng trên cơ sở thoả thuận bằng văn bản.

    Bartlomej Seidel 
     Tư vấn ERP, Ba Lan
    Nguyễn Huy Cương dịch

    ID: B0512_35