Nguyen Harry, Tác giả tại IT CONSULTING

Kiểm thử cài đặt

Một kiểm thử cài đặt đảm bảo rằng hệ thống được cài đặt đúng và hoạt động tại phần cứng thực tế của thiết bị.

Kiểm thử khả năng tương thích

Một nguyên nhân phổ biến của lỗi phần mềm (thực tế hay nhận thức) là thiếu khả năng tương thích với các hệ điều hành hoặc phần mềm ứng dụng khác (có thể là các phiên bản cũ hay mới của hệ điều hành), hoặc môi trường mục tiêu khác nhau rất nhiều so với bản gốc (chẳng hạn như một thiết bị đầu cuối hoặc ứng dụng giao diện dùng để chạy trên máy tính để bàn hiện nay đang được yêu cầu để trở thành một ứng dụng web, trong đó phải thực hiện trong một trình duyệt web). Ví dụ, trong trường hợp thiếu tính tương thích ngược có thể xảy ra bởi vì các lập trình viên chỉ phát triển và kiểm thử phần mềm trên phiên bản mới nhất của môi trường mục tiêu, mà không phải tất cả người dùng có thể chạy. Điều này dẫn đến hậu quả không lường được rằng các chức năng mới nhất có thể không hoạt động trong các phiên bản trước đây của môi trường mục tiêu nhưng lại có thể chạy được với phần cứng cũ hơn và phiên bản trước trước đó của môi trường mục tiêu. Đôi khi các vấn đề như vậy có thể được cố định bằng cách chủ động trừu tượng hóa chức năng hệ điều hành vào một Module chương trình riêng biệt hoặc thư viện.

Smoke & Sanity Testing

Sanity Testing xác định tính hợp lý để tiến hành các kiểm thử khác.

Smoke Testing được sử dụng để xác định xem có vấn đề nghiêm trọng với bộ phận của phần mềm, ví dụ như một bài kiểm thử xác minh khi xây dựng phần mềm.

Kiểm thử hồi quy

Kiểm thử hồi quy tập trung vào việc tìm kiếm lỗi sau khi xảy ra một thay đổi mã chính. Cụ thể, nó tìm cách phát hiện ra các hồi quy của phần mềm hoặc các lỗi cũ quay trở lại. Những hồi quy như vậy xảy ra bất cứ khi nào chức năng phần mềm trước đây đang hoạt động giờ tạm ngưng như đã định. Thông thường, những hồi quy xảy ra như một hệ quả không lường trước được những thay đổi chương trình, khi một phần mới của phần mềm được phát triển xung đột với mã tồn tại trước đó. Phương pháp phổ biến của kiểm thử hồi quy bao gồm chạy lại những kiểm thử trước đó và kiểm thử xem lỗi cố định trước đây tại sao lại xuất hiện. Độ sâu của kiểm thử phụ thuộc vào các nguy cơ và giai đoạn trong quá trình phát hành các tính năng bổ sung. Chúng có thể được hoàn tất khi thay đổi thêm vào đầu hoặc cuối bản phát hành, cũng có thể được có mức độ nguy hiểm thấp khi thực hiện kiểm thử tích cực trên mỗi tính năng.

Ví dụ: một PM đang phát triển khi kiểm tra cho thấy nó chạy tốt các chức năng A, B và C. Khi có thay đổi code của chức năng C, nếu chỉ kiểm tra chức năng C thì chưa đủ, cần phải kiểm tra lại tất cả các chức năng khác liên quan đến chức năng C, trong ví dụ này là A và B. Lý do là khi C thay đổi, nó có thể sẽ làm A và B không còn làm việc đúng nữa.

Mặc dù không là một mức kiểm tra, thực tế lại cho thấy Regression Test là một trong những loại kiểm tra tốn nhiều thời gian và công sức nhất. Tuy thế, việc bỏ qua Regression Test là “không được phép” vì có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta “tưởng rằng” những lỗi đó hoặc không có hoặc đã được kiểm tra và sửa chữa rồi!

Kiểm thử mức chấp nhận

Kiểm thử mức chấp nhận được hiểu theo một trong hai nghĩa sau:

Một Smoke Testing được sử dụng như một bài kiểm thử mức chấp nhận trước khi giới thiệu một bản built mới để thực hiện tiến trình kiểm thử chính, tức là trước khi thực hiện kiểm thử tích hợp hoặc hồi quy.
Kiểm thử mức chấp nhận do khách hàng thực hiện trong môi trường thí nghiệm riêng với những thiết bị phần cứng của họ, nó còn được biết đến như là kiểm thử mức độ chấp nhận của người dùng (UAT). Kiểm thử mức chấp nhận còn được thực hiện như là một phần của quá trình chuyển giao (hand-off) giữa hai pha của quá trình phát triển phần mềm.

Kiểm thử Alpha

Kiểm thử Alpha là việc kiểm thử hoạt động chức năng thực tế hoặc giả lập do người dùng/khách hàng tiềm năng hoặc một nhóm Tester độc lập thực hiện tại nơi sản xuất phần mềm. Kiểm thử Alpha thường được sử dụng cho phần mềm đại trà (đóng gói sẵn để bán) như là một hình thức kiểm thử mức chấp nhận nội bộ trước khi phần mềm chính thức đi vào giai đoạn kiểm thử Beta.

Kiểm thử Beta

Kiểm thử phiên bản Beta được đưa ra sau khi kiểm thử Alpha và có thể được coi là một hình thức mở rộng của kiểm thử mức chấp nhận của người dùng. Các phiên bản của phần mềm, gọi là phiên bản beta, được phát hành cho một đối tượng hạn chế bên ngoài của nhóm lập trình. Phần mềm này được phát hành cho nhiều nhóm người dùng để kiểm thử nhiều hơn nữa và nó có thể đảm bảo sản phẩm có ít thiếu sót và lỗi. Đôi khi, các phiên bản beta được phát hành rộng rãi để tăng phạm vi phản hồi thông tin từ một số lượng tối đa người dùng trong tương lai.

Kiểm thử chức năng và phi chức năng

Chức năng kiểm thử liên quan đến các hoạt động xác minh một hành động cụ thể hoặc chức năng của các mã. Đó là những điều được tìm thấy trong các tài liệu yêu cầu, mặc dù có một số phương pháp phát triển được làm từ các câu chuyện của người dùng. Kiểm thử chức năng nhằm trả lời cho câu hỏi “người dùng có hay không làm được với tính năng cụ thể này”.

Kiểm thử phi chức năng đề cập đến các khía cạnh của phần mềm có thể không liên quan đến một chức năng cụ thể hoặc hành động người dùng, chẳng hạn như khả năng mở rộng và hiệu suất khác, hành vi dưới những hạn chế hoặc bảo mật nhất định. Việc kiểm thử sẽ xác định điểm cuộn mà tại đó khả năng mở rộng và thực hiện của các điểm cực trị hoạt động không ổn định. Những yêu cầu phi chức năng thường là những phản ánh về chất lượng của sản phẩm, đặc biệt là trong bối cảnh các quan điểm phù hợp của người sử dụng nó.

Kiểm thử sự phá hủy

Kiểm thử sự phá hủy cố gắng làm hỏng phần mềm hoặc một hệ thống con. Nó xác minh rằng các phần mềm có chức năng đúng ngay cả khi nó nhận được đầu vào không hợp lệ hoặc không mong muốn, do đó tạo ra sự vững mạnh của xác nhận đầu vào và thói quen quản lý các lỗi. Chèn lỗi phần mềm ở dạng mờ nhạt là một ví dụ về kiểm thử thất bại. Các công cụ kiểm thử phi chức năng thương mại được liên kết từ các trang chèn lỗi phần mềm mà ở đó có sẵn vô số các mã nguồn mở và các công cụ miễn phí để thực hiện kiểm thử sự phá hủy phần mềm.

Kiểm thử hiệu suất phần mềm

Kiểm thử hiệu suất thường được chạy để xác định một hệ thống hay hệ thống con thực hiện như thế nào về độ nhạy và tính ổn định theo một khối lượng công việc cụ thể. Nó cũng có thể dùng để điều tra, đánh giá, xác nhận hoặc xác minh các thuộc tính chất lượng khác của hệ thống, chẳng hạn như khả năng mở rộng, độ tin cậy và sử dụng tài nguyên.

Kiểm thử lượng tải chủ yếu liên quan đến việc kiểm thử hệ thống có thể tiếp tục hoạt động dưới một lượng tải cụ thể, cho dù đó là một lượng lớn dữ liệu hoặc một số lượng lớn người sử dụng. Điều này thường được gọi là khả năng mở rộng phần mềm. Các hoạt động kiểm thử lượng tải có liên quan khi thực hiện như một hoạt động phi chức năng thường được gọi là kiểm thử sức chịu đựng.

Kiểm tra khối lượng là một cách để kiểm tra các chức năng của phần mềm ngay cả khi một số thành phần (ví dụ như một tập tin hoặc cơ sở dữ liệu) tăng triệt để kích thước. Kiểm thử độ căng là một cách để kiểm tra độ bền đột xuất hoặc ít gặp theo khối lượng công việc.

Kiểm thử tính ổn định (thường được tham chiếu lượng tải và kiểm thử độ bền) giúp kiểm tra xem phần mềm có thể hoạt động tốt liên tục trong hoặc trên một chu kỳ chấp nhận được. Có rất ít quy ước về các mục tiêu cụ thể của kiểm thử hiệu suất như là: Các thuật ngữ lượng tải, kiểm thử hiệu suất, kiểm thử tính mở rộng và kiểm thử khối lượng, thường được sử dụng thay thế cho nhau.

Hệ thống phần mềm thời gian thực có những ràng buộc chính xác thời gian. Để kiểm thử những ràng buộc thời gian được đáp ứng thì người ta dùng phương pháp kiểm thử thời gian thực.

Kiểm thử tính khả dụng

Kiểm tra tính khả dụng là rất cần thiết để kiểm tra xem giao diện có tiện dụng và dễ hiểu với người dùng không, nó liên quan trực chủ yếu đến năng lực sử dụng của ứng dụng.

Kiểm thử khả năng tiếp cận

Kiểm thử khả năng tiếp cận bao gồm việc tuân thủ các tiêu chuẩn sau:

Người Mỹ với Đạo luật bất khả thi năm 1990
Mục 508 sửa đổi của đạo luật Phục hồi năm 1973.
Sáng kiến tiếp cận Web (WAI) của World Wide Web Consortium (W3C).

Kiểm thử bảo mật

Kiểm thử bảo mật phần mềm là rất cần thiết trong việc xử lý dữ liệu mật và ngăn chặn các hacker xâm nhập hệ thống.

Tính toàn cầu và bản địa hóa

Khả năng tổng quát của phần mềm được toàn cầu và bản địa hóa có thể được tự động kiểm tra mà không dịch thực tế, bằng cách sử dụng phương thức giả bản địa. Nó sẽ xác minh rằng các ứng dụng vẫn hoạt động, ngay cả sau khi nó đã được dịch sang một ngôn ngữ mới hoặc thích nghi với một nền văn hóa mới (chẳng hạn như tiền tệ và múi giờ khác nhau).

Việc thực dịch ra nhiều ngôn ngữ phải được kiểm tra. Sự cố bản địa hóa có thể bao gồm:

Phần mềm thường được bản địa hóa bằng cách dịch một danh sách các chuỗi ra khỏi bối cảnh, và người dịch có thể chọn dịch sai đối với một chuỗi mã nguồn không rõ ràng.
Thuật ngữ kỹ thuật có thể trở nên không phù hợp nếu dự án được phiên dịch bởi một số người phối hợp không tốt hoặc nếu người dịch thiếu thận trọng.
Những bản dịch từ ngữ theo nghĩa đen có vẻ không phù hợp, giả tạo hoặc quá kỹ thuật trong mục tiêu ngôn từ.
Thông điệp chưa được dịch bằng ngôn ngữ gốc có thể khó mã hoá trong mã nguồn.
Một số thông điệp có thể được tạo ra tự động tại thời gian chạy và chuỗi kết quả có thể là sai ngữ pháp và chức năng không chính xác, dễ gây hiểu lầm hoặc khó hiểu.
Phần mềm có thể sử dụng một phím tắt mà không có chức năng trên layout phím ngôn ngữ nguồn nhưng lại được sử dụng để gõ ký tự trên layout ngôn ngữ mục tiêu.
Phần mềm có thể thiếu hỗ trợ cho các ký tự mã hóa của ngôn ngữ mục tiêu.
Phông chữ và kích thức chữ có thể phù hợp trong ngôn ngữ nguồn nhưng có thể không phù hợp trong ngôn ngữ mục tiêu. Ví dụ, ký tự CJK có thể không đọc được nếu font chữ quá nhỏ.
Một chuỗi trong ngôn ngữ mục tiêu có thể kéo dài hơn so với các xử lý của phần mềm. Điều này có thể làm cho một phần chuỗi bị ẩn đi với người dùng và gây ra một số va chạm hoặc sự cố với phần mềm.
Phần mềm có thể thiếu hỗ trợ thích hợp cho việc đọc hoặc viết văn bản hai chiều.
Phần mềm có thể hiển thị hình ảnh với văn bản mà không được bản địa hóa.
Những hệ điều hành bản địa có thể khác nhau trong cách đặt tên các file cấu hình hệ thống, các biến môi trường và các định dạng khác nhau cho ngày tháng và tiền tệ.

Kiểm thử sự phát triển

Kiểm thử sự phát triển là một tiến trình phát triển phần mềm có liên quan đến ứng dụng đồng bộ của một loạt các chiến lược phòng ngừa phát hiện lỗi và để giảm thiểu rủi ro về thời gian và chi phí. Nó được thực hiện bởi các kỹ sư hoặc các nhà phát triển trong giai đoạn xây dựng vòng đời phát triển phần mềm. Không chỉ thay thế các trọng tâm QA truyền thống mà phải bổ sung nó. Kiểm thử sự phát triển nhằm mục đích loại bỏ những lỗi xây dựng trước khi mã được đẩy mạnh QA, chiến lược này là nhằm nâng cao chất lượng của phần mềm cũng như hiệu quả của sự phát triển chung và cả quá trình QA.
Tùy thuộc vào kỳ vọng của tổ chức phát triển phần mềm, kiểm tra phát triển có thể bao gồm phân tích mã tĩnh, phân tích luồng dữ liệu, phân tích số liệu, đánh giá mã cân bằng, kiểm thử đơn vị, phân tích mã bao phủ, truy xuất nguồn gốc, và các thực hành xác minh phần mềm khác.

Kiểm thử A/B

Kiểm thử A/B là một phương pháp sử dụng trong quảng cáo được thí nghiệm ngẫu nhiên với hai biến thể A và B, trong đó có sự kiểm soát và điều trị trong các kiểm thử có kiểm soát. Những thí nghiệm này thường được sử dụng trong phát triển web và tiếp thị, cũng như trong nhiều hình thức quảng cáo truyền thống.

(Tham khảo: wikipedia.org)

0 Shares

Kiểm thử thường xuyên được nhóm lại theo địa điểm chúng được thêm vào trong quá trình phát triển phần mềm, hoặc do mức độ đặc hiệu của kiểm thử. Các cấp chính trong quá trình phát triển theo quy định của hướng dẫn SWEBOK là đơn vị, kiểm thử hội nhập, và kiểm thử hệ thống được phân biệt bởi các mục tiêu kiểm thử mà không ám chỉ một mô hình quy trình cụ thể. Các mức độ kiểm thử khác được phân loại theo mục tiêu kiểm thử.

Kiểm thử đơn vị (unit testing)

Kiểm thử đơn vị hay còn được gọi là kiểm thử thành phần, đề cập đến việc kiểm thử chức năng từng phần của mã, thường ở mức độ chức năng. Trong một môi trường hướng về đối tượng thì điều này thường là cấp độ lớp, và các kiểm thử đơn vị tối thiểu bao gồm hàm dựng và hàm hủy. Nhiều loại kiểm thử được viết bởi các nhà phát triển như họ làm việc trong mã (kiểu hộp trắng) để đảm bảo rằng từng hàm riêng biệt hoạt động đúng như kỳ vọng. Một hàm có thể có nhiều kiểm thử từ đó giúp nắm bắt được các trường hợp góc hoặc các nhánh trong Code. Kiểm thử đơn vị một mình không thể đảm bảo hết được từng chức năng của từng bộ phận trong phần phềm nhưng nó được sử dụng để đảm bảo rằng các khối kiến trúc của phần mềm hoạt động độc lập với nhau.

Kiểm thử đơn vị là một quá trình phát triển phần mềm có liên quan đến ứng dụng đồng bộ của một loạt các chiến lược phòng ngừa phát hiện lỗi và để giảm thiểu rủi ro, thời gian và chi phí. Nó được thực hiện bởi kỹ sư hay nhà phát triển trong suốt giai đoạn xây dựng của vòng đời phát triển phần mềm. Không chỉ tập trung vào việc đảm bảo chất lượng truyền thống mà phải gia tăng nó lên vì thế kiểm thử đơn vị có mục đích loại bỏ những lỗi cấu trúc trước khi mã hóa rồi mới thúc đẩy việc quản lý chất lượng. Chiến lược này nhằm nâng cao chất lượng cũng như hiệu quả của phần mềm trong tiến trình quản lý và phát triển chung.

Tùy thuộc vào kỳ vọng của tổ chức phát triển phần mềm, kiểm thử đơn vị có thể bao gồm phân tích mã tĩnh, phân tích luồng dữ liệu, phân tích dữ liệu, đánh giá mã cân bằng, phân tích mã bao phủ và các thực hành xác nhận phần mềm khác.

Kiểm thử tích hợp (integration testing)

Kiểm thử tích hợp là một hình thức kiểm thử phần mềm nhằm tìm cách xác minh các giao diện giữa các thành phần xung đột của một thiết kế. Các thành phần này có thể tích hợp theo cách lặp đi lặp lại hoặc tất cả cùng nhau (“Big Bang”). Thông thường cách thức này được coi là một thực hành tốt hơn vì nó cho phép các vấn đề về giao diện được định vị một cách nhanh chóng và cố định hơn.

Kiểm thử tích hợp làm lộ ra các khiếm khuyết trong các giao diện và tương tác giữa các thành phần tích hợp (Modules). Các nhóm thành phần đã được kiểm thử lớn dần từng bước tương ứng với các thuộc tính của cấu trúc thiết kế đã được tích hợp và kiểm thử cho đến khi phần mềm hoạt động như một hệ thống.

Kiểm thử hệ thống (system testing)

Kiểm thử hệ thống giúp xác minh rằng một hệ thống được tích hợp có đáp ứng đầy đủ các yêu cầu hay không. Ngoài ra, kiểm thử phần mềm phải đảm bảo rằng các chương trình hoạt động như kỳ vọng, không còn bị phá hủy hay lỗi phần nào đó trong môi trường hoạt động của nó hoặc không gặp sự cố khi hoạt động với tiến trình khác (điều này bao gồm bộ nhớ chia sẻ không bị hỏng, nguồn tài nguyên không bị dư thừa hay chiếm dụng quá mức và không bị đẩy ra khi hoạt động song song các tiến trình).

Kiểm thử chấp nhận (acceptance testing)

Cuối cùng hệ thống được giao cho người dùng để kiểm thử mức chấp nhận.

0 Shares

Trong lĩnh vực kiểm thử phần mềm có rất nhiều các phương pháp được áp dụng hiện nay. Trong bài viết này chúng ta sẽ cùng tìm hiểu 3 phương pháp cơ b ản được áp dụng một cách phổ biến và rộng rãi nhất cùng với các ưu điểm và nhược điểm của nó, đó là: kiểm thử hộp đen, kiểm thử hộp trắng và kiểm thử hộp xám

1.Kiểm thử hộp đen.

Kiểm thử hộp đen là một phương pháp kiểm thử mà các tester không cần quan tâm đến các hoạt động bên trong hệ thống chạy ra sao, không cần quan tâm đến các dòng lệnh bên trong hệ thống hệ thống như thế nào. mà chỉ cần tập trung vào các giá trị đầu vào và các giá trị đầu ra của hệ thống có đúng với kết quả mong đợi của các trường hợp kiểm thử không để từ đó đánh giá chất lượng hệ thống.

Chính vì cơ chế như vậy nên phương pháp này có các ưu nhược điểm như sau:

Ưu điểm	Nhựợc điểm
– Rất phù hợp và hiệu quả khi mà số lượng các dòng lệnh của hệ thống là lớn.	– Bị giới hạn ở độ bao phủ của các trường hợp kiểm thử.
– Không cần truy cập vào các dòng lệnh.	– Sẽ không hiệu quả bởi thực tế các tester bị giới hạn kiến thức về hệ thống.
– Phân biệt được rõ ràng quan điểm của người dùng với quan điểm của nhà phát triển.	– Độ bao phủ sẽ bị thiếu vì tester không kiểm tra được các đoạn lệnh của hệ thống hoặc tập trung vào các dòng lệnh dễ xảy ra lỗi.
– Không cần đòi hỏi những kiến thức về ngôn ngữ lập trình ở các tester để có thể kiểm thử hệ thống.	– Sẽ khó để có thể thiết kế đầy đủ các trường hợp kiểm thử.

2.Kiểm thử hộp trắng.

Kiểm thử hộp trắng là việc nghiên cứu cụ thể chi tiết từng luồng hoạt động cũng như các dòng lệnh bên trong hệ thống. Kiểm thử hộp trắng cũng được gọi dưới các cái tên khác như: Glass testing hay open-box testing. Kiểm thử hộp trắng đòi hỏi tester phải có kiến thức về ngôn ngữ lập trình. Tester sẽ cần phải nghiên cứu vào bên trong hê thống cụ thể là các dòng lệnh để tìm hiểu chúng có chạy đúng hay không.

Dưới đây là các ưu nhược điểm của phương pháp này:

Ưu điểm	Nhựợc điểm
– Đối với những tester có kiến thức về ngôn ngữ lập trình sẽ rất dễ dàng để phát hiện ra những lỗi ở trong các dòng lệnh.	– Trên thực tế việc sử dụng các tester có kiến thức về ngôn ngữ lập trình sẽ làm gia tăng giá thành để phát triển phần mềm.
– Giúp tối ưu hóa các dòng lệnh của hệ thống.	– Đôi lúc sẽ là không khả thi khi kiểm tra chi tiết từng dòng lệnh để có thể từ đó phát hiện ra các lỗi tiềm ẩn của hệ thống, có rất nhiều các luồng không thể kiểm tra được.
– Các dòng lệnh không cần thiết hoặc các dòng lệnh có khả năng mang đến các lỗi tiềm ẩn sẽ bị loại bỏ.	– Rất khó để duy trì phương pháp này liên tục, cần phải có những tool chuyên biệt như tool về phân tích code hay tool về phát hiện lỗi và sửa lỗi.
– Các tester có kiến thức về ngôn ngữ lập trình sau khi đã thực hiện phương pháp này thì sẽ dễ dàng đạt được độ bao phủ lớn nhất khi thực hiện thiết kế các trường hợp kiểm thử sau này.

3.Kiểm thử hộp xám.

Kiểm thử hộp xám là một phương pháp kiểm thử mà đòi hỏi tester phải có một lượng kiến thức nhất định về các luồng hoạt động ở bên trong hệ thống. Khác với kiểm thử hộp đen, phương pháp mà tester chỉ quan tâm duy nhất để việc kiểm thử thông qua giao diện người dùng, kiểm thử hộp xám đòi hỏi tester phải truy cập vào các tài liệu thiết kế hệ thống cũng như hệ thống cơ sở dữ liệu của hệ thống. Do đó mà tester có thể chuẩn bị tốt hơn những dữ liệu cho việc kiểm thử cũng như các trường hợp kiểm thử trong quá trình lên kế hoạch kiểm thử hệ thống.

Ưu điểm	Nhựợc điểm
– Vì là sự kết hợp giữa kiểm thử hộp trắng và kiểm thử hộp đen nên có được ưu điểm của cả hai phương pháp này.	– Vì phương pháp này không dựa trên việc truy cập code của hệ thống nên sẽ không tránh được việc độ bao phủ của các trường hợp kiểm thử bị giới hạn.
– Các tester sử dụng phương pháp này không dựa vào các dòng lệnh của hệ thống mà chủ yếu dựa trên các tài liệu định nghĩa giao diện cũng như các tài liệu đặc tả chức năng.	– Khi sử dụng phương pháp này thì nhiều trường hợp kiểm thử có thể bị dư thừa nếu mà những nhà thiết kế phần mềm đã chạy các trường hợp kiểm thử này trước đó.
– Trong phương pháp này các tester có thể thiết kế nên những trường hợp kiểm thử đặc biệt xung quanh các giao thức kết nối và các loại dữ liệu khác nhau.	– Việc kiểm tra tất cả các luồng đầu vào của hệ thống là không thể thực hiện được vì bị giới hạn về mặt thời gian kiểm thử và sẽ dẫn đến có rất nhiều các luồng hoạt động của hệ thống không được kiểm tra.
– Việc kiểm thử được hoàn thành từ góc nhìn của người dùng chứ không phải từ nhà thiết kế.

4.Bảng so sánh giữa các phương pháp kiểm thử.

Kiểm thử hộp đen.	Kiểm thử hộp xám.	Kiểm thử hộp trắng
Không cần quan tâm đến các luồng hoạt động trong hệ thống.	Cần có kiến thức nhất định về các luồng hoạt động bên trong hệ thống.	Cần nắm được toàn bộ các luồng hoạt động bên trong hệ thống.
Được biết đến với các tên gọi khác như: closed-box testing, data-driven testing hoặc functional testing.	Được biết đến với các tên gọi khác như: translucent testing.	Được biết đến với các tên gọi khác như: clear-box testing hoặc code-based testing.
Được thực hiện bởi người dùng cuối, kiểm thử viên và lập trình viên.	Được thực hiện bởi người dùng cuối, kiểm thử viên và lập trình viên.	Thường thì được hoàn thành bởi kiểm thử viên và lập trình viên.
Việc kiểm thử dựa trên kết quả mong muốn và kết quả thực tế mà hệ thống trả về.	Việc kiểm thử dựa trên các sơ đồ về cơ sở dữ liệu và sơ đồ về các luồng dữ liệu.	Dựa trên toàn bộ kiến thức về các luồng hoạt động bên trong hệ thống và các bộ dữ liệu kiểm thử phù hợp mà các kiểm thử viên tự thiết kế.
Vì chỉ quan tâm đến các giá trị đầu vào, kết quả đầu ra và kết quả mong đợi nên đây là phương pháp tốn ít thời gian nhất cũng như đô bao phủ các trường hợp không đầy đủ nhất.	Mức độ đầy đủ của các trường hợp kiểm thử ở mức vừa phải và mức độ tốn thời gian là vừa phải.	Đầy đủ nhất và tốn nhiều thời gian nhất
Không thích hợp để kiểm tra các thuật toán trong hệ thống.	Không thích hợp để kiểm tra các thuật toán trong hệ thống.	Thích hợp để kiểm tra các thuật toán trong hệ thống.
Phương pháp này sẽ được hoàn thành bởi cơ chế phát hiện lỗi.	Các miền dữ liệu và các giới hạn có thể sẽ được test nếu các tester có kiến thức về nó.	Các miền dữ liệu và các

0 Shares

Trước khi tìm hiểu một quy trình kiểm tra phần mềm cơ bản, ta cần hiểu hai khái niệm sau: Test Case và Test Script.

Test Case

Một Test Case có thể coi nôm na là một tình huống kiểm tra, được thiết kế để kiểm tra một đối tượng có thỏa mãn yêu cầu đặt ra hay không. Một Test Case thường bao gồm 3 phần cơ bản:

• Mô tả: đặc tả các điều kiện cần có để tiến hành kiểm tra.

• Nhập: đặc tả đối tượng hay dữ liệu cần thiết, được sử dụng làm đầu vào để thực hiện việc kiểm tra.

• Kết quả mong chờ: kết quả trả về từ đối tượng kiểm tra, chứng tỏ đối tượng đạt yêu cầu.

Test Script

Một Test Script là một nhóm mã lệnh dạng đặc tả kịch bản dùng để tự động hóa một trình tự kiểm tra, giúp cho việc kiểm tra nhanh hơn, hoặc cho những trường hợp mà kiểm tra bằng tay sẽ rất khó khăn hoặc không khả thi. Các Test Script có thể tạo thủ công hoặc tạo tự động dùng công cụ kiểm tra tự động. (Hình 04)

Phần sau sẽ giải thích rõ hơn các bước cơ bản của một quy trình kiểm tra.

Một quy trình kiểm tra cơ bản có thể áp dụng rộng rãi cho nhiều hệ thống PM với những đặc trưng khác nhau.

Lập kế hoạch kiểm tra

Mục đích: Nhằm chỉ định và mô tả các loại kiểm tra sẽ được triển khai và thực hiện. Kết quả của bước lập kế hoạch là bản tài liệu kế hoạch KTPM, bao gồm nhiều chi tiết từ các loại kiểm tra, chiến lược kiểm tra, cho đến thời gian và phân định lực lượng kiểm tra viên.

Bản kế hoạch kiểm tra đầu tiên được phát triển rất sớm trong chu trình phát triển phần mềm (PTPM), ngay từ khi các yêu cầu đã tương đối đầy đủ, các chức năng và luồng dữ liệu chính đã được mô tả. Bản kế hoạch này có thể được coi là bản kế hoạch chính (master test plan), trong đó tất cả các kế hoạch chi tiết cho các mức kiểm tra và loại kiểm tra khác nhau đều được đề cập (hình 05).

Lưu ý, tùy theo đặc trưng và độ phức tạp của mỗi dự án, các kế hoạch kiểm tra chi tiết có thể được gom chung vào bản kế hoạch chính hoặc được phát triển riêng.

Sau khi bản kế hoạch chính được phát triển, các bản kế hoạch chi tiết lần lượt được thiết kế theo trình tự thời gian phát triển của dự án. (Hình 06 minh hoạ thời điểm phù hợp để thiết lập các kế hoạch kiểm tra, gắn liền với quá trình phát triển của dự án. Quá trình phát triển các kế hoạch kiểm tra không dừng lại tại một thời điểm, mà liên tục được cập nhật chỉnh sửa cho phù hợp đến tận cuối dự án.).

Bản kế hoạch chính và các bản kế hoạch chi tiết

Các bước lập kế hoạch:

Xác định yêu cầu kiểm tra: chỉ định bộ phận, thành phần của PM sẽ được kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra. Yêu cầu kiểm tra cũng được dùng để xác định nhu cầu nhân lực.

Khảo sát rủi ro: Các rủi ro có khả năng xảy ra làm chậm hoặc cản trở quá trình cũng như chất lượng kiểm tra. Ví dụ: kỹ năng và kinh nghiệm của kiểm tra viên quá yếu, không hiểu rõ yêu cầu.

Xác định chiến lược kiểm tra: chỉ định phương pháp tiếp cận để thực hiện việc kiểm tra trên PM, chỉ định các kỹ thuật và công cụ hỗ trợ kiểm tra, chỉ định các phương pháp dùng để đánh giá chất lượng kiểm tra cũng như điều kiện để xác định thời gian kiểm tra.

Xác định nhân lực,vật lực: kỹ năng, kinh nghiệm của kiểm tra viên; phần cứng, phần mềm, công cụ, thiết bị giả lập… cần thiết cho việc kiểm tra.

Lập kế hoạch chi tiết: ước lượng thời gian, khối lượng công việc, xác định chi tiết các phần công việc, người thực hiện, thời gian tất cả các điểm mốc của quá trình kiểm tra.

Tổng hợp và tạo các bản kế hoạch kiểm tra: kế hoạch chung và kế hoạch chi tiết.

Xem xét các kế hoạch kiểm tra: phải có sự tham gia của tất cả những người có liên quan, kể cả trưởng dự án và có thể cả khách hàng. Việc xem xét nhằm bảo đảm các kế hoạch là khả thi, cũng như để phát hiện (và sữa chữa sau đó) các sai sót trong các bản kế hoạch.

Thiết kế Test

Mục đích: Nhằm chỉ định các Test Case và các bước kiểm tra chi tiết cho mỗi phiên bản PM. Giai đoạn thiết kế test là hết sức quan trọng, nó bảo đảm tất cả các tình huống kiểm tra “quét” hết tất cả yêu cầu cần kiểm tra.

Hình dưới cho thấy việc thiết kế test không phải chỉ làm một lần, nó sẽ được sửa chữa, cập nhật, thêm hoặc bớt xuyên suốt chu kỳ PTPM, vào bất cứ lúc nào có sự thay đổi yêu cầu, hoặc sau khi phân tích thấy cần được sửa chữa hoặc bổ sung.

Thời điểm phù hợp để thiết lập các kế hoạch kiểm tra

Các bước thiết kế test bao gồm:

• Xác định và mô tả Test Case: xác định các điều kiện cần thiết lập trước và trong lúc kiểm tra. Mô tả đối tượng hoặc dữ liệu đầu vào, mô tả các kết quả mong chờ sau khi kiểm tra.

• Mô tả các bước chi tiết để kiểm tra: các bước này mô tả chi tiết để hoàn thành một Test Case khi thực hiện kiểm tra. Các Test Case như đã nói ở trên thường chỉ mô tả đầu vào, đầu ra, còn cách thức tiến hành như thế nào thì không được định nghĩa. Thao tác này nhằm chi tiết hóa các bước của một Test Case, cũng như chỉ định các loại dữ liệu nào cần có để thực thi các Test Case, chúng bao gồm các loại dữ liệu trực tiếp, gián tiếp, trung gian, hệ thống…

• Xem xét và khảo sát độ bao phủ của việc kiểm tra: mô tả các chỉ số và cách thức xác định việc kiểm tra đã hoàn thành hay chưa? bao nhiêu phần trăm PM đã được kiểm tra? Để xác định điều này có hai phương pháp: căn cứ trên yêu cầu của phần mềm hoặc căn cứ trên số lượng code đã viết.

• Xem xét Test Case và các bước kiểm tra: Việc xem xét cần có sự tham gia của tất cả những người có liên quan, kể cả trưởng dự án nhằm bảo đảm các Test Case và dữ liệu yêu cầu là đủ và phản ánh đúng các yêu cầu cần kiểm tra, độ bao phủ đạt yêu cầu, cũng như để phát hiện (và sữa chữa) các sai sót.

Phát triển Test ScriptMục đích: Bước này thường không bắt buộc trong các loại và mức kiểm tra, chỉ yêu cầu trong những trường hợp đặc thù cần thiết kế, tạo ra các Test Script có khả năng chạy trên máy tính giúp tự động hóa việc thực thi các bước kiểm tra đã định nghĩa ở bước thiết kế test.

Các bước phát triển Test Script bao gồm:• Tạo Test Script: thủ công hoặc dùng công cụ hỗ trợ để phát sinh script một cách tự động (tuy nhiên trong hầu hết mọi trường hợp, ta vẫn phải chỉnh sửa ít hoặc nhiều trên các script được sinh tự động). Thông thường, mỗi bước kiểm tra được thiết kế trong phần thiết kế test, đòi hỏi ít nhất một Test Script. Các Test Script có khả năng tái sử dụng càng nhiều càng tốt để tối ưu hóa công việc.

• Kiểm tra Test script: xem có “chạy” tốt không nhằm bảo đảm các Test Script hoạt động đúng yêu cầu, thể hiện đúng ý đồ của các bước kiểm tra.

• Thành lập các bộ dữ liệu ngoài dành cho các Test Script: bộ dữ liệu này sẽ được các Test Script sử dụng khi thực hiện kiểm tra tự động. Gọi là “ngoài” vì chúng được lưu độc lập với các Test Script, tránh trường hợp vì dễ dãi, một số kiểm tra viên “tích hợp” luôn phần dữ liệu vào bên trong code của các script (thuật ngữ chuyên môn gọi là “hard-code”). Việc tách riêng dữ liệu cho phép dễ dàng thay đổi dữ liệu khi kiểm tra, cũng như giúp việc chỉnh sửa hoặc tái sử dụng các script sau này.

• Xem xét và khảo sát độ bao phủ của việc kiểm tra: bảo đảm các Test Script được tạo ra bao phủ toàn bộ các bước kiểm tra theo yêu cầu.

Thực hiện kiểm traMục đích: Thực hiện các bước kiểm tra đã thiết kế (hoặc thi hành các Test Script nếu tiến hành kiểm tra tự động) và ghi nhận kết quả.

Hình 06 cho ta thấy, việc thực hiện kiểm tra cũng được làm rất nhiều lần trong suốt chu trình kiểm tra, cho đến khi kết quả kiểm tra cho thấy đủ điều kiện để dừng hoặc tạm dừng việc thực hiện.

Quá trình thực hiện kiểm tra thường thông qua các bước sau:

• Thực hiện các bước kiểm tra: thủ công hoặc thi hành các Test Script nếu là quy trình kiểm tra tự động. Để thực hiện kiểm tra, thao tác đầu tiên cần làm là xác lập và khởi động môi trường và điều kiện kiểm tra. Việc này nhằm bảo đảm tất cả các bộ phận liên quan (như phần cứng, phần mềm, máy chủ, mạng, dữ liệu…) đã được cài đặt và sẵn sàng, trước khi chính thức bắt đầu thực hiện kiểm tra.

• Đánh giá quá trình kiểm tra: giám sát quá trình kiểm tra suôn sẻ đến khi hoàn thành hay bị treo và dừng giữa chừng, có cần bổ sung hay sữa chữa gì không để quá trình kiểm tra được tốt hơn.

– Nếu quá trình diễn ra trơn tru, kiểm tra viên hoàn thành chu kỳ kiểm tra và chuyển qua bước “Thẩm định kết quả kiểm tra”

– Nếu quá trình bị treo hoặc dừng giữa chừng, kiểm tra viên cần phân tích để xác định nguyên nhân lỗi, khắc phục lỗi và lập lại quá trình kiểm tra.

• Thẩm định kết quả kiểm tra: sau khi kết thúc, kết quả kiểm tra cần được xem xét để bảo đảm kết quả nhận được là đáng tin cậy, cũng như nhận biết được những lỗi xảy ra không phải do PM mà do dữ liệu dùng để kiểm tra, môi trường kiểm tra hoặc các bước kiểm tra (hoặc Test Script) gây ra. Nếu thực sự lỗi xảy ra do quá trình kiểm tra, cần phải sửa chữa và kiểm tra lại từ đầu.

Đánh giá quá trình kiểm traMục đích: Đánh giá toàn bộ quá trình kiểm tra, bao gồm xem xét và đánh giá kết quả kiểm tra, liệt kê lỗi, chỉ định các yêu cầu thay đổi, và tính toán các số liệu liên quan đến quá trình kiểm tra (chẳng hạn số giờ, thời gian kiểm tra, số lượng lỗi, phân loại lỗi…).

Lưu ý, mục đích của việc đánh giá kết quả kiểm tra ở bước này hoàn toàn khác với bước thẩm định kết quả kiểm tra sau khi hoàn tất một vòng kiểm tra. Đánh giá kết quả kiểm tra ở giai đoạn này mang tính toàn cục và nhằm vào bản thân giá trị của các kết quả kiểm tra.

Hình 06 cho thấy, việc đánh giá quá trình và kết quả kiểm tra được thực hiện song song với bất kỳ lần kiểm tra nào và chỉ chấm dứt khi quá trình kiểm tra đã hoàn tất.

Đánh giá quá trình kiểm tra thường thông qua các bước sau:• Phân tích kết quả kiểm tra và đề xuất yêu cầu sửa chữa: Chỉ định và đánh giá sự khác biệt giữa kết quả mong chờ và kết quả kiểm tra thực tế, tổng hợp và gửi thông tin yêu cầu sửa chữa đến những người có trách nhiệm trong dự án, lưu trữ để kiểm tra sau đó.

• Đánh giá độ bao phủ: Xác định quá trình kiểm tra có đạt được độ bao phủ yêu cầu hay không, tỷ lệ yêu cầu đã được kiểm tra (tính trên các yêu cầu của PM và số lượng code đã viết).

• Phân tích lỗi: Đưa ra số liệu phục vụ cho việc cải tiến các qui trình phát triển, giảm sai sót cho các chu kỳ phát triển và kiểm tra sau đó. Ví dụ, tính toán tỷ lệ phát sinh lỗi, xu hướng gây ra lỗi, những lỗi “ngoan cố” hoặc thường xuyên tái xuất hiện.

• Xác định quá trình kiểm tra có đạt yêu cầu hay không: Phân tích đánh giá để xem các Test Case và chiến lược kiểm tra đã thiết kế có bao phủ hết những điểm cần kiểm tra hay không? Kiểm tra có đạt yêu cầu dự án không? Từ những kết quả này, kiểm tra viên có thể sẽ phải thay đổi chiến lược hoặc cách thức kiểm tra.

• Báo cáo tổng hợp: Tổng hợp kết quả các bước ở trên và phải được gửi cho tất cả những người có liên quan.

Tóm lược: Trên đây là tóm tắt các bước cơ bản của một quy trình KTPM. Tùy theo đặc thù của dự án, loại kiểm tra và mức độ kiểm tra, quy trình kiểm tra trong thực tế có thể chi tiết hơn nhiều, tuy nhiên các bước trên là xương sống của bất kỳ quy trình kiểm tra nào.

Sau đây, chúng tôi sẽ giới thiệu một mô hình giúp các tổ chức đánh giá và nâng cao năng lực KTPM của mình, đó là mô hình TMM (Testing Maturity Model).

0 Shares

a. Chi tiết chức năng phần mềm

Quản lý nhân sự

Quản lý sơ yếu lý lịch nhân viên của bộ phận trực tiếp hoặc gián tiếp sản xuất với các thông tin sau:

Mã số nhân viên	Nguyên quán	Trực tiếp sản xuất
Họ	Nơi thường trú	Đơn vị /Phòng ban
Tên	Nơi tạm trú	Tổ
Ngày sinh	Điện thoại	Bậc thợ
Nơi sinh	Số CMND	Ngày vào làm
Giới tính	Ngày cấp	Ngày nghỉ việc
Công nhân may	Nơi cấp	Chuyên môn
Dân tộc	Ngoại ngữ	Chức vụ
Tôn giáo	Trình độ	Đoàn thể
Số sổ BHXH	Ngày đóng BHXH	Ngày chấm dứt BHXH

Quản lý quá trình công tác

Quản lý quá trình làm việc trước khi vào công ty.
Quản lý quá trình làm việc tại công ty.
Quản lý những thay đổi về phòng ban, chức vụ.
Quản lý những công đoạn công nhân có khả năng thực hiện. (Tay nghề của công nhân).

Quản lý hợp đồng lao động

Quản lý mức lương:

Quản lý mức lương nhân viên (lương theo hệ số Nhà nước và lương thực lĩnh theo công ty).
Quản lý các loại phụ cấp.
Khen thưởng và Kỷ luật:
Lập các quyết định khen thưởng cho từng nhân viên, làm cơ sở để ra quyết định tăng giảm lương.
Nhập vào xếp loại cho từng công nhân.

Tai nạn lao động:

Quản lý tình hình tai nạn lao động và chi phí của toàn công ty.
Lập các báo cáo về tai nạn cho Bộ lao động-thương binh và xã hội.

Đánh giá và đào tạo: Nhập vào các nội dung đánh giá của từng nhân viên theo các nội dung tùy chọn: tin học, Anh văn, chuyên môn… làm cơ sở lập kế hoạch đào tạo.

Quản lý bằng cấp:

Quản lý bằng cấp, chứng chỉ, chứng nhận của công nhân viên.

Quản lý quá trình đóng BHXH + BHYT

Lập các báo cáo về BHXH cho cơ quan Bảo hiểm cũng như tính tiền trợ cấp thôi việc cho từng nhân viên. Thông tin hỗ trợ:
Người thân: thông tin về người thân trong gia đình.
Liên hệ: điện thoại, địa chỉ, email, liên hệ khẩn cấp.
Đoàn thể: các thông tin về Đảng, Đoàn, công đoàn, Nhập ngũ, Quân nhân dự bị, gia đình liệt sĩ…

Chấm công

Đặc điểm chung: Giải pháp chấm công tự động hỗ trợ việc tính toán ngày giờ công với các chế độ nhiều ca (chẩn là 03 ca) và cung cấp khả năng kết nối đa dạng với tất cả các công nghệ chấm công tiên tiến nhất như máy barcode, máy chấm công dùng thẻ từ, máy đọc thẻ cảm ứng, máy nhận dạng vân tay…).

Chức năng:

Tính thời gian làm việc, dựa trên từng chế độ lànm việc (công ty có thể có rất nhiều chế độ.
Có thể set chế độ vào hay ra trên máy chấm công hoặc set tự động bằng phần mềm.
Hỗ trợ chế độ làm việc 03 ca.
Việc xác định nhân viên làm trực tiếp hay gián tiếp được xác định trước (trong danh sách nhân viên /phần Quản lý nhân sự).
Kiểm soát thời gian làm việc tăng ca của từng nhân viên. Thời gian tăng ca có thể được tính theo chế độ làm việc hay tính tự động khi tông thời gian làm việc nhiều hơn 8 giờ/ ngày.
Quản lý cho phép tăng ca hay không.
Quản lý các hệ số tăng ca theo qui định nhà nước (1.5, 1.8, 2.0, 2.8).
Kiểm soát sự vắng mặt của nhân viên.
Hỗ trợ in mã vạch để dán lên thẻ nhân viên chấm công bằng mã vạch.
Hỗ trợ chấm công cho nhân viên đi công tác (không tới chấm công trực tiếp được).
Kết nối dữ liệu từ các loại máy chấm công bằng thẻ, vân tay.
Lập bảng kế hoạch nghỉ phép.
Ngày nghỉ và ngày lễ được xác định trước cho tất cả nhân viên (thứ bảy, chủ nhật hay chỉ chủ nhật).
Các lý do nghỉ được nhập bằng tay
Báo cáo được lập theo từng tổ, đơn vị của nhân viên vào ngày chấm công.
Quản lý thai sản.

Đơn đặt hàng

Quản lý Hợp đồng, Khách hàng, Hình thức hợp đồng và một số thông tin khác của hợp đồng.
Quản lý mã hàng, orders và ngày giao hàng cho từng order của hợp đồng.

Lập Quy trình công nghệ

Lập Qui trình công nghệ cho Mã hàng mới. Bạn có thể sao chép từ mã hàng cũ hay từ quy trình công nghệ chuẩn.
Tính đơn giá cho từng công đoạn thông qua thời gian thiết kế, và hệ số bậc thợ.
Tính định mức sản lượng, số lượng lao động và thiết bị cần thiết.

Kiểm soát năng suất

Nhập phiếu công đoạn (dùng kiểm soát chuyền, tiến độ may và tính lương sản phẩm).
Thống kê năng suất các mã hàng trên các chuyền (có thể theo từng công đoạn) trong từng ngày hoặc trong từng giai đoạn.

ITLOGISTIC cung cấp khả năng tích hợp với phần cứng ứng dụng phát hành và đọc mã vạch để thống kê năng suất công đoạn có thể rút giảm được ½ số nhân viên thống kê.

Tính lương

Tổng hợp lương sản phẩm cho từng công nhân dựa trên năng suất và đơn giá công đoạn (từ Quy trình công nghệ).
Tổng hợp lương thời gian dựa trên lương cơ bản (trong module QLNS) và bảng tổng hợp công tháng, bao gồm cả thời gian tăng ca (trong module chấm công).
Người sử dụng có thể định nghĩa thêm những loại lương không cố định.
Tổng hợp lương thời gian và lương sản phẩm (có thể định nghĩa trước cách tính lương cho từng tổ/phòng ban) và các khoản khác như tạm ứng, BHXH, BHYT, phí công đoàn và lập bảng lương tháng hoàn chỉnh (tự động lập).
Kiểm soát quá trình đóng bảo hiểm xã hội và y tế.
Kiểm soát chi trả tiền tạm ứng.
Thuế thu nhập cá nhân.

b. Sơ đồ quy trình

c. Mô hình cài đặt

Sơ đồ máy chấm công

d. Phân hệ tuyển dụng

Cung cấp công cụ đắc lực hỗ trợ tuyển dụng nhân tài. Theo dõi định biên nhân sự với nhu cầu thực tế tuyển dụng, đánh giá hiệu quả tuyển dụng.Tuyển dụng theo định biên

Thiết lập định biên nhân sự theo tháng, hiệu chỉnh theo thực tế hoạt động. Nhu cầu tuyển dụng
Các phòng ban gửi nhu cầu tuyển dụng lên phòng nhân sự, nhu cầu tuyển dụng được phê duyệt theo quy trình. Hệ thống tự động kiểm tra định biên nhân sự với nhu cầu tuyển dụng, từ đó ra cảnh báo đối với nhu cầu vượt định biên. Cho phép các phòng ban theo dõi trạng thái tuyển dụng đối với yêu cầu của chính mình.

Linh động thiết lập tiêu chí tuyển dụng, phỏng vấn :

Cho phép thiết lập tiêu chí tuyển dụng tới từng chức vụ
Thiết lập linh động Vòng thi / Tiêu chí tuyển dụng tới từng chức vụ
Thiết lập lịch phỏng vấn, chấm điểm thí sinh
Tự động chuyển thông tin ứng viên trúng tuyển sang Hồ sơ nhân sự

Công cụ đắc lực hỗ trợ tuyển dụng

Ứng viên nộp hồ sơ online
Lọc ứng viên thông minh
Gửi email tự động: Gửi thư mời phỏng vấn, Gửi thư cảm ơn, Gửi thư mời trúng tuyển,…

Ngân hàng ứng viên

Lưu trữ toàn bộ hồ sơ ứng viên qua các đợt tuyển dụng
Lưu trữ lịch sử phỏng vấn, thi truyển, đánh giá ứng viên
Tự động tìm kiếm ứng viên đã nộp CV: CMTND, Mã số thuế, Tài khoản Ngân hàng, …
Lọc ứng viên thông minh với tiêu chí phù hợp với đợt tuyển dụng, chuyển các ứng viên đã lọc vào vị trí tuyển dụng.

Báo cáo quản trị

Báo cáo phân tích thực tế tuyển dụng với kế hoạch tuyển dụng
Phân tích tình hình tuyển dụng
Phân tích nguồn ứng viên
Biểu đồ phễu tuyển dụng

e. Phân Hệ Quản Lý Thông Tin Nhân Sự

Cung cấp công cụ quản lý toàn diện dữ liệu hồ sơ nhân sự từ khi tuyển dụng tới khi nghỉ hưu, thôi việc. Các cảnh báo kịp thời, cùng với dashboard chuyên sâu giúp quản lý nhân sự chủ động và dễ dàng.

Chuẩn hóa thông tin, cơ cấu tổ chức

ITLOGISTIC GHR Hỗ trợ xây dựng Cơ cấu tổ chức linh động chỉ bằng các thao tác kéo-thả. Cho phép lãnh đạo xem sơ đồ tổ chức theo nhiều chiều: Theo cây sơ đồ phòng ban, theo sơ đồ chức vụ.
ITLOGISTIC GHR Hỗ trợ chuẩn hóa thông tin chức năng / nhiệm vụ các phòng ban, chuẩn hóa mô tả công việc chức vụ, từ đó dữ liệu được dùng chung thống nhất cho các module khác.
ITLOGISTIC GHR Hỗ trợ chuẩn hóa thông tin nhân sự và import vào hệ thống.

Đầy đủ – Toàn diện – Chuyên nghiệp

ITLOGISTIC GHR lưu trữ đầy đủ, toàn diện tất cả các thông tin liên quan tới nhân sự từ khi nhân sự được tuyển dụng tới khi nghỉ hưu/thôi việc.
Quản lý toàn diện các quá trình nhân sự: Thay đổi lương/phụ cấp, điều chuyển/bổ nhiệm/miễn nhiệm, nghỉ phép, khen thưởng, kỷ luật,…
Thực hiện quy trình nhân sự chuyên nghiệp:
Employee Onboarding
Quy trình nâng lương
Quy trình điều chuyển/bổ nhiệm/miễn nhiệm
Quy trình xin nghỉ phép online
Quy trình sa thải/nghỉ việc…

Thân thiện, dễ sử dụng

Thiết kế giao diện thân thiện, trực quan hỗ trợ tối đa các thiết bị di động.
Hỗ trợ thông minh người sử dụng, nắm bắt các hành vi của người dùng để đưa ra các gợi ý phù hợp.
Cho phép truy xuất và quản lý thông tin nhanh chóng, hỗ trợ tìm kiếm thông minh.

Cảnh báo kịp thời

Hệ thống cảnh báo tự động nhắc việc cho người dùng:
Phê duyệt
Hết hạn hợp đồng
Nghỉ phép
Thai sản
Kiêm nhiệm…

Báo cáo phân tích chuyên sâu

OOS.GHR cung cấp các báo cáo phân tích chuyên sâu, đa chiều về tình hình nhân sự. Được thể hiện qua các công cụ: Dashboard, Report, Excel Report, Biểu đồ,…
Các dashboard chuyên sâu phục vụ cho lãnh đạo để cung cấp theo thông tin tổng quan nhằm đưa ra các quyết sách về nhân sự.

f. Phân hệ chấm công

Phân hệ giúp tự động hóa quy trình của doanh nghiệp. Chuẩn hóa toàn bộ chính sách liên quan tới chấm công / nghỉ phép / thêm giờ, tạo văn hóa chuyên nghiệp về giờ giấc cho doanh nghiệp.

Thiết lập linh hoạt, áp dụng nhiều bài toán công phức tạp

GHR đã được áp dụng thành công cho nhiều bài toàn Công phức tạp như: Sản xuất, Thời gian, Dịch vụ, Đa nghành nghề …
Dữ liệu chấm công có thể lấy từ nhiều nguồn:
Máy chấm công
Bảng công ký hiệu
Import từ file excel
Liên kết với các hệ thống khác (Hệ thống bán hàng check in-out bán hàng, DMS,…)
Dữ liệu chấm công được thiết lập linh hoạt cho các phòng ban / các công ty con khác nhau, mỗi đơn vị một cách chấm công.
Cho phép thiết lập linh động ca/kíp áp dụng cho từng cá nhân, có thể thiết lập lịch ca cho từng nhân viên.
Xây dựng quy trình, chính sách chấm công linh hoạt phù hợp với đặc thù của từng Công ty.

Tự động hóa

Hệ thống có thể đặt lịch tự động download dữ liệu từ máy chấm công về máy chủ, sau đó tổng hợp công. Việc download dữ liệu chấm công được phần mềm thực hiện trực tiếp không phải thông qua bất kỳ phần mềm trung gian nào.
Đăng ký nghỉ phép online: Tự động nhận diện đối với các trường hợp nghỉ phép, có thể nghỉ phép theo ngày hoặc theo giờ.
Đăng ký OT: Tự động tính thời gian OT đối với các trường hợp đăng ký OT đã được phê duyệt.
Đăng ký công tác: Nhận diện thời gian đi công tác của nhân sự, với các trường hợp đã được phê duyệt.
Tự động gửi email cảnh báo tới các trường hợp bất thường: Đi muộn, về sớm, tăng ca, nghỉ không lý do … người lao động có thể khiếu nại trực tiếp tới bộ phận Nhân sự.
Tự động bóc tách Ngày thường, ngày nghỉ, ngày lễ, ca đêm, ca ngày.
Tạo thành chu trình khép kín về chấm công: Đăng ký, dữ liệu chấm công thực tế, tổng hợp công, khiếu nại chấm công.

Xử lý thông minh

Hệ thống tự động xử lý lên đến >95% các tính huống phát sinh công trong ngày.
Một số trường hợp đặc thù, hệ thống tự động học cách làm của nhân viên từ đó tự động xử lý trong các trường hợp tương tự về sau.
Tự động nhận diện ca theo thời gian đi làm với tỷ lệ chính xác cao.

Giao diện trực quan

Giao diện sử dụng rất đơn giản, thao tác nhanh gọn
Trên một giao diện nhân viên có thể nắm bắt toàn bộ thông tin, từ đó thực hiện các bước kiểm tra dữ liệu rất nhanh.
Hỗ trợ nhiều thao tác điều chỉnh hàng loạt (Áp dụng cho nhà máy hàng nghìn công nhân)
Tốc độ tìm kiếm, thao tác dữ liệu nhanh chóng

Nhân viên tự kiểm tra: Bạn không phải mất thời gian trả lời các câu hỏi liên quan tới chấm công hàng ngày của nhân viên. Nhân viên có thể tự kiểm tra ngay lập tức giờ đi làm, và công tới thời điểm hiện tại. Nếu có sai sót, có thể khiếu nại tới phòng Nhân sự, hoặc thông qua quy trình phê duyệt của các cấp quản lý trực tiếp.

g. Phân hệ tiền lương

Cung cấp hệ thống tính lương đầy đủ, đáp ứng tối đa bài toán lương doanh nghiệp. Tin cậy – ổn định là mục tiêu hàng đầu của hệ thống.

Thiết lập linh hoạt, áp dụng nhiều bài toán lương phức tạp

GHR cho phép tự định nghĩa công thức lương, không giới hạn các phương pháp tính lương khác nhau.

Tự định nghĩa các khoản Thưởng, phụ cấp, các khoản mục lương phát sinh ngoài.
Hỗ trợ nhiều phương pháp tính lương, không giới hạn:
- Lương thời gian
- Lương khoán
- Lương sản phẩm
- Lương KPI
- Lương doanh số…
Hỗ trợ tính lương nhiều dòng: Có sự thay đổi lương / phụ cấp nhiều lần trong 1 tháng
Hỗ trợ quyết toán thuế TNCN trên cùng 1 bảng lương
Hỗ trợ tính toán bóc tách chi phí lương

Tự động liên kết dữ liệu

Tự động link dữ liệu chấm công sang bảng lương.
Liên kết các dữ liệu về kế toán, các khoản thuế TNCN, giảm trừ sang bảng lương
Liên kết các dữ liệu hồ sơ nhân sự:
Hợp đồng
Khen thưởng / Kỷ luật
Các chế độ
Cho phép import các khoản không thường xuyên, phát sinh bên ngoài.

Tốc độ nhanh / Ổn định

Tốc độ tính lương nhanh, có khả năng tính lương cho nhiều chi nhánh / nhiều công ty con cùng lúc.
Cơ chế phân luồng dữ liệu, phân tải giúp không bị quá tải khi tính lương trên toàn hệ thống.
Thuật toán tính lương ổn định, có cơ chế check lại dữ liệu sau khi tính lương đảm bảo tính chính xác của hệ thống.

Liên kết với các hệ thống khác

Đã thực hiện thành công liên kết với các hệ thống như ERP (Oracle, SAP, Fast …), CRM, DMS để lấy thông tin tính lương bao gồm: Sản phẩm, sản lượng, lương KPI, doanh số bán hàng…
Có khả năng liên kết với nhiều hệ thống khác trong cùng 1 Công ty (tập đoàn), thường áp dụng cho Tập đoàn đa nghành nghề.

Nhân viên tự kiểm tra : Cho phép nhân viên tự kiểm tra bảng lương/các khoản thu nhập của chính mình thông qua Cổng thông tin nhân sự (HR-Portal), thực hiện các khiếu nại trực tiếp tới bộ phận nhân sự (nếu có)

Phân tích chi phí lương

Hệ thống cho phép xây dựng ngân sách lương cho từng phòng ban/đơn vị, từng chức danh.
Báo cáo phân tích chi phí lương theo nhiều chiều khác nhau
Báo cáo phân tích chi phí lương thực tế so với ngân sách đã duyệt
Báo cáo phân tích lương theo thời điểm, dự đoán chi phí lương cả năm

h. Phân hệ đào tạo

Công cụ hiệu quả giúp doanh nghiệp bồi dưỡng, phát triển nguồn nhân lực hiện tại. Xây dựng lộ trình đào tạo đội ngũ kế cận, nhân sự đã được quy hoạch.

Xây dựng lộ trình đào tạo, kế hoạch đào tạo

Xây dựng yêu cầu đào tạo đối với từng vị trí, mỗi vị trí phải trải qua các khóa đào tạo bắt buộc.
Lưu trữ thông tin đào tạo vào hồ sơ đào tạo cá nhân
Quản lý đề xuất nhu cầu đào tạo của từng phòng ban
Xây dựng lộ trình đào tạo dựa vào yêu cầu đào tạo của từng vị trí, và đề xuất đào tạo

Quản lý khóa đào tạo

Cho phép học viên đăng ký khóa học online
Quản lý chi tiết các khóa đào tạo: Học viên, giảng viên, chi phí đào tạo,…
Cho phép cập nhật kết quả đào tạo của từng học viên, thông tin này được lưu vào hồ sơ đào tạo cá nhân
Cho phép quản lý cam kết sau đào tạo
Đánh giá khóa đào tạo:
Đánh giá giảng viên
Đánh giá học viên
Đánh giá công tác tổ chức

Đánh giá sau đào tạo

Mỗi khóa đào tạo nhằm nâng cao năng lực của từng nhân viên
Sau mỗi khóa đào tạo, áp dụng công cụ Đánh giá năng lực để đo lường hiệu quả đào tạo sau khoảng thời gian nhất định.

i. Phân hệ đánh giá nhân sự

Công cụ đắc lực giúp giảm thiểu công sức trong các kỳ đánh giá, thực hiện đánh giá một cách khoa học, kết quả đánh giá được cập nhật ngay lập tức từ đó đưa ra các báo cáo phân tích năng lực nhằm phát hiện và bồi dưỡng nhân tài tăng năng lực cạnh tranh của doanh nghiệp.

Xây dựng bộ chỉ tiêu đánh giá tới từng nhân viên/chức vụ

Cho phép tự xây dựng bộ chỉ tiêu đánh giá, các mẫu đánh giá theo đặc thù của doanh nghiệp
Mỗi kỳ đánh giá, loại đánh giá có thể có bộ chỉ tiêu khác nhau
Cho phép gán các bộ chỉ tiêu đánh giá tới từng chức vụ cụ thể
Cho phép gán bộ chỉ tiêu cho nhân viên theo từng thời điểm

Giao chỉ tiêu phân cấp theo Sơ đồ tổ chức

Giao chỉ tiêu dựa vào các mẫu đánh giá xuống từng đơn vị, theo sơ đồ tổ chức
Từng đơn vị, giao chỉ tiêu cho từng cá nhân
Chỉ tiêu thực tế có thể được thay đổi theo từng tháng đánh giá thực tế

Linh động xây dựng quy trình đánh giá/kỳ đánh giá

Cho phép tự xây dựng quy trình đánh giá theo từng vị trí / chức danh
Linh động quy trình đánh giá theo cây sơ đồ tổ chức
Linh động xây dựng chỉ tiêu cho kỳ đánh giá:
Đánh giá tháng
Đánh giá quý
Đánh giá năm

Hỗ trợ nhiều loại đánh giá khác nhau:

Đánh giá nhân sự
Đánh giá thử việc
Đánh giá gia hạn hợp đồng
Đánh giá bổ nhiệm / thử thách

Đa dạng phương pháp đánh giá

Đánh giá thành tích theo mục tiêu và KPI:
- Thiết lập bộ tiêu chí KPI
- Gán bộ tiêu chí KPI cho chức danh và nhân viên
- Xây dựng quy trình đánh giá
- Tổng hợp kết quả đánh giá
- Áp dụng kết quả đánh giá sang các module khác
Đánh giá năng lực nhân viên theo khung năng lực:
- Xây dựng bộ từ điển năng lực
- Gán từ điển năng lực cho từng chức vụ
- Gán khung năng lực cho chức vụ / nhân viên
- Đánh giá năng lực nhân viên
- Tổng hợp kết quả so sánh năng lực
Đánh giá theo kết quả công việc

Cập nhật kết quả đánh giá liên tục, hỗ trợ các báo cáo theo nhiều chiều

Thực hiện đánh giá mọi lúc/mọi nơi với các thiết bị kết nối internet
Thiết lập giới hạn thời gian đánh giá, tổng hợp ngay kết quả đánh giá
Phê duyệt kết quả trực quan, thông báo tức thì kết quả phê duyệt của cấp trên
Báo cáo phân tích kết quả đánh giá
Báo cáo / Biểu đồ phân tích năng lực nhân viên

0 Shares

Dệt may với đặc thù quản lý sản xuất riêng của mình luôn đòi hỏi giải pháp ERP có những tính năng linh hoạt giúp ứng dụng thuận lợi mô hình này vào thực tiễn. Bài viết nhằm chia sẻ một số vấn đề về ứng dụng ERP trong các DN dệt may.

a. Nhận diện bài toán của ngành

Dệt may là một ngành sản xuất khá đặc thù thường kéo dài trên rất nhiều công đoạn. Mỗi công đoạn lại có quy trình sản xuất riêng, phức tạp và có nhiều quy trình sản xuất con. Trong khi đó, việc sản xuất lại phục vụ cho nhiều tiêu thức như: gia công theo đơn đặt hàng hay sản xuất tự tiêu thụ… Mỗi phương thức lại có những khác biệt về việc theo dõi bán hàng, cung ứng nguyên phụ liệu cũng như các phân tích quản trị khác liên quan đến điều độ sản xuất.

Ngoài ra, việc triển khai ERP trong dệt may còn phải tính đến các vấn đề cốt tử như: kết nối với hệ thống CAD/CAM, bài toán cân đối và điều hành dây chuyền may; sự đa dạng của sản phẩm (với các tiêu thức như size, màu, mẫu mã luôn thay đổi). Như vậy, ngoài những tính năng chung, một giải pháp ERP hoàn hảo cho ngành dệt may cần phải tính đến những tính năng và tiện ích riêng để phù hợp với các đặc thù của ngành này.

b. Nhận diện giải pháp

Một giải pháp ERP được coi là đầy đủ cho ngành dệt may cần đáp ứng tối thiểu các tiêu chí sau:

Tính linh hoạt: Quản lý nguyên phụ liệu (NPL) dệt may rất đa dạng và phức tạp. Ngoài size, cỡ, màu, DN còn phải quản lý theo các tiêu thức khác như mẫu mã, hoa văn trên sản phẩm, các cách phối màu, độ co dãn của vải, độ dài của sợi bông… Do vậy, hệ thống quản lý phải linh hoạt để đáp ứng được các phân tích về tồn kho phục vụ sản suất cũng như bán hàng.
Tốc độ xử lý và nhập liệu phải nhanh: Trong dệt may, do số lượng danh điểm trong quản lý sản xuất là rất lớn và cần lưu trữ để phục vụ phân tích thống kê nên việc quản lý danh điểm ngoài yêu cầu đáp ứng theo dõi NPL, phải đảm bảo tốc độ xử lý, thời gian nhập liệu nhanh, thuận tiện trong kiểm soát danh điểm. Đây là một trong những yếu tố quyết định hệ thống ERP dùng được hay không cho ngành dệt may.
Tích hợp với hệ thống CAD/CAM: Đặc điểm của dệt may là ứng dụng hệ thống CAD/CAM trong thiết kế mẫu mã. Việc tích hợp giữa hai hệ thống CAD/CAM và ERP sẽ mang lại hiệu quả cao. Các kết quả mang lại có thể giúp tính toán giá thành thiết kế (TK) ngay từ khi sản phẩm còn trên bản vẽ. Từng chi tiết của sản phẩm ứng với màu, chất liệu vải, nếp gấp… được tính toán tự động trên phần mềm TK sẽ được cập nhật vào suất tiêu hao NPL trong BOM của hệ thống ERP kết hợp với tập hợp chi phí thực gần nhất để tính giá thành TK. Số liệu giá thành này được cập nhật ngược lại phòng TK để giúp bộ phận này có thêm chỉ tiêu giá thành khi TK sản phẩm. Việc kết nối này cũng cho phép cán bộ kinh doanh tính toán nhanh chi tiết giá thành chào hàng trong quá trình đàm phán chuẩn bị nhận đơn hàng gia công mới.
Ngoài ra, tích hợp CAD/CAM, đồng thời ứng dụng công nghệ quét sản phẩm, sẽ cho phép hệ thống ERP cập nhật trực tuyến các công việc đã hoàn thành trên từng công đoạn, từ đó hỗ trợ điều độ sản xuất phân xưởng chính xác. Đây cũng là một điểm nóng của các DN dệt may nhằm tăng hiệu quả điều hành sản xuất, cũng như giúp có thông tin cho bài toán lương khi điều động nhân công trên dây chuyền may.

Ngoài các tiêu chí cơ bản trên, nếu là một DN dệt may sản xuất tiêu thụ, đặc biệt là tiêu thụ nội địa thì giải pháp ERP cần phải có tính năng quản lý hệ thống bán hàng, thường rất phức tạp. Thông thường các công ty dệt may bán hàng qua hệ thống kênh phân phối, siêu thị hoặc qua các chuỗi cửa hàng. Chỉ tiêu quan trọng để đánh giá hệ thống quản lý bán hàng có đủ mạnh hay không là khả năng tập hợp được trạng thái tiêu thụ, doanh thu bán hàng, trạng thái tồn kho sản phẩm cũng như các dự báo tiêu thụ để phục vụ cho điều động hàng, điều chỉnh sản lượng sản xuất cũng như quyết định các chương trình khuyến mãi hay bán giảm giá. Việc theo dõi này cũng phải được phân tích tương ứng với đặc điểm đa dạng về mẫu mã, size, màu như đã phân tích ở trên.

Khi ứng dụng ERP, các DN dệt may cũng cần chú ý để khai thác thật tốt bài toán giá thành mà hệ thống ERP thường rất mạnh. Hệ thống phải tính được giá thành hoàn nguyên ứng đến từng công đoạn chi tiết trên toàn bộ dây chuyền, cho phép xử lý linh hoạt việc tại mỗi công đoạn (như tính toán giá thành trước sản xuất, giá thành kế hoạch, giá thành phân xưởng…).

c. Lợi ích của giải pháp phần mềm quản lý

Giải pháp phần mềm là một hệ thống thông tin hoàn chỉnh kết nối toàn bộ hoạt động sản xuất của doanh nghiệp theo mô hình: Hệ thống thông tin quản lý doanh nghiệp (MRP II và ERP), phần mềm giúp cho thông tin giữa các bộ phận được thông suốt, sản xuất không bị ngừng hay không kịp tiến độ do lưu chuyển thông tin giữa các bộ phận không kịp thời.

Là một hệ thống bao gồm hầu hết các công cụ quản lý như: Lập Quy trình công nghệ, Sơ đồ nhánh cây, Lập kế hoạch may, Lập kế hoạch cắt, Kiểm soát may, Kiểm soát cắt, Hoạch định vật tư, Kiểm soát tồn kho, Quản lý nhân sự, Chấm công Quản lý thiết bị và bảo trì, Quản lý chất lượng, Tính lương v.v…việc ứng dụng phần mềm sẽ hỗ trợ đáng kể cho việc cải thiện tổ chức quản lý sản xuất.

Giảm thời gian ngừng sản xuất, giảm chi phí và thời gian chuẩn bị sản xuất, nâng cao chất lượng sản phẩm, tăng năng suất gián tiếp và trực tiếp, giúp sản xuất các đơn hàng nhỏ với chi phí thấp là những ưu thế lớn nhất của phần mềm này.

Những module chính

Quản lý nhân sự

Quản lý toàn bộ tình hình nhân sự.
Lập các báo biểu cho cơ quan Nhà nước.
Quản lý quá trình đóng bảo hiểm.

Chấm công:

Tích hợp dữ liệu với máy chấm công.
Lập bảng công theo quy định tăng ca của Nhà nước.
Chế độ nhiều ca.

Tính lương:

Tính lương sản phẩm.
Tính lương thời gian.
Phương pháp tính thưởng linh hoạt.

Chuẩn bị sản xuất:

Quản lý quy trình công nghệ.
Cân đối chuyền và Bố trí chuyền.

Kiểm soát sản xuất

Kiểm soát tiến độ sản xuất trên tất cả các công đoạn.
Cập nhật tiến độ lên website cho khách hàng theo dõi.
Kiểm soát chuyền bằng hệ thống kiểm soát dùng mã vạch hay chip thông minh.

Hoạch định vật tư dùng cho loại hình FOB:

Dùng cho việc tính toán nhu cầu nguyên phụ liệu để đặt mua hàng tránh thiếu hay không đồng bộ nguyên phụ liệu

Hoạch định vật tư dùng cho lọai hình CMT:

Cân đối vật tư và thanh lý vật tư với khách hàng.
Lệnh cấp phát vật tư.
Dùng cho loại hình gia công và loại hình kinh doanh FOB.

Quản lý kho

Quản lý xuất nhập và tồn kho.
Liên kết dữ liệu với module Hoạch định vật tư nhằm theo dõi tiến độ cung cấp vật tư và tận. dụng hàng tồn kho.
Quản lý vật tư trên từng vị trí trong kho.

Báo cáo chính

Bảng lương sản phẩm các loại (tổng cộng, chi tiết, cho tổ, cho cá nhân).
Danh sách công nhân thực hiện 1 công đoạn (chọn công đoạn).
Bảng tiền tạm ứng cho từng tổ/phòng ban (chi tiết và tổng cộng).
Bảng lương tháng.
Phiếu lương cho nhân viên.
Và một số báo cáo khác.

0 Shares

CRM hay phần mềm CRM đang là những từ khoá hot được dùng thường xuyên trong các cuộc trao đổi về quản lý ở doanh nghiệp. Ấn tượng đầu tiên khi nói về CRM là nó liên quan đến việc sử dụng công nghệ để quản lý thật tốt mối quan hệ giữa doanh nghiệp với khách hàng và đối tác của mình.

Ban đầu, CRM chỉ là một hệ thống quản lý thông tin liên hệ (CMS – Contact Management System) đơn giản, nhưng theo thời gian, các nhà cung cấp hướng đến việc xây dựng một giải pháp CRM toàn diện bao gồm các hoạt động sales và marketing, đồng thời trở thành phần ‘mở rộng’ quan trọng (ví dụ, cho giải pháp ERP) trong việc giúp doanh nghiệp hiểu khách hàng tốt hơn, từ đó cung cấp thông tin cho các thay đổi về sản phẩm – dịch vụ, giúp phát triển, giữ chân khách hàng và có chiến lược gia tăng doanh số.

Khi lựa chọn một phần mềm ứng dụng, hiển nhiên khách hàng sẽ quan tâm xem nó có cải thiện được công tác quản lý và giúp họ tăng trưởng doanh số hay không. CRM (Custom Relationship Management) – phần mềm quản trị quan hệ khách hàng có thể đáp ứng những yêu cầu đó.

a. Định nghĩa

Có khá nhiều định nghĩa về CRM và mỗi định nghĩa đều phản ánh được cốt lõi về CRM, ở đây sẽ kết hợp các định nghĩa này để đưa ra cái nhìn toàn diện hơn.

CRM (hay Customer Relationship Management) bao gồm các thực tiễn, chiến lược và công nghệ mà doanh nghiệp sử dụng để quản lý và phân tích tất cả các tương tác và dữ liệu khách hàng trong suốt vòng đời của khách hàng, mục tiêu cuối cùng là cải thiện mối quan hệ với khách hàng, hỗ trợ giữ chân và thúc đẩy tăng trưởng doanh thu.

Còn phần mềm CRM là công cụ hỗ trợ cho việc lưu trữ và quản lý các mối quan hệ, dữ liệu và thông tin liên quan đến khách hàng (customer), đầu mối (lead) và khách hàng tiềm năng (prospect) hoặc có thể là đối tác kinh doanh.

Một hệ thống CRM được thiết kế để tập hợp tất cả thông tin về khách hàng trên khắp các kênh hay các điểm tiếp xúc giữa khách hàng và doanh nghiệp (gồm website, điện thoại, live chat, thư từ, tài liệu và mạng xã hội) về một mối. Từ đó, cung cấp cho các nhân sự làm việc trực tiếp với khách hàng về thông tin cá nhân, lịch sử mua, các sở thích hoặc mối quan tâm khi mua. CRM được hiểu đơn giản là một phần mềm (PM) ứng dụng trong công tác quản lý các mối quan hệ với khách hàng. Hạt nhân của PM là cơ sở dữ liệu (CSDL) thu thập từ các bộ phận trong công ty. Do vậy, cũng như tất cả các PM ứng dụng khác, để CRM trở thành một công cụ đắc dụng, phải chấp nhận thực tế “PM không phải là một dự án kỹ thuật thuần túy”. Nếu dùng phần mềm CRM, bạn cần dành cho nó mỗi ngày khoảng 20 phút nhập liệu/người (tùy theo số nhân viên kinh doanh tham gia). Nếu thực hiện tốt, CRM sẽ trở thành một trợ thủ đắc lực trong công cuộc chinh phục khách hàng của bạn với những lợi ích rõ ràng.

Nói ngắn gọn, CRM đang được xem nền tảng của sales và marketing hiện đại.

b. Các tính năng của CRM

Kiểm soát và quy hoạch thị trường

Các DN thường nhắc đến chính sách marketing “4P” khi xác lập thị trường mục tiêu: Product (Sản phẩm), Price (Giá cả), Place (Kênh luồng tiêu thụ), Promotion (Xúc tiến thị trường). Ngược lại, thị trường sẽ có nhận thức – thái độ – hành vi nhất định với sản phẩm, dịch vụ của DN.

Tuy nhiên, không hẳn khi nào và với bất cứ sản phẩm nào các công ty cũng có thể tổ chức điều tra, đánh giá phản ứng của thị trường, nhất là các công ty nhỏ. Nếu ta quản lý tốt các thông tin liên quan đến các quan hệ giao dịch (như: mục đích, phương tiện, tình trạng, nội dung, tần suất…) chúng ta có thể đo lường được hiệu quả của các giao dịch, từ đó có thể đưa ra thông điệp phù hợp với thị trường. Với khả năng tổng hợp thông tin và cung cấp các công cụ phân tích hành vi, PM CRM có thể giúp các công ty thu nhận phản hồi từ thị trường –> thay đổi trong tổ chức cho phù hợp –> đưa ra chính sách mới.

Chiếm lĩnh thị trường là cả một nghệ thuật, vì với mỗi loại sản phẩm, thị trường lại có hành vi ứng xử khác nhau. CRM sẽ hỗ trợ công ty xây dựng các CSDL thông tin phân tích thị trường rõ ràng, phân biệt các nhóm khách hàng trong thị trường mênh mông; từ đó đưa ra các chiến lược khách hàng đúng đắn.

Lập kế hoạch marketing

Các tổ chức DN nhỏ thường không có thói quen lập kế hoạch trước khi bắt đầu công việc. Đây là lý do tại sao có sự khác biệt về năng suất lao động trong các tổ chức và giữa những con người. Việc phải đề cập tới các yếu tố cụ thể của kế hoạch như: người thực hiện, sản phẩm, kênh luồng, giá cả, xúc tiến, doanh số mục tiêu, thời gian… sẽ giúp chúng ta tạo một hành lang, vạch một con đường để chiếm lĩnh thị trường. CRM có thể giúp công ty xác định các phân khúc thị trường, chọn mẫu đối tượng, lập các kế hoạch gần và xa…

Tăng năng suất lao động

Trong CRM, hoạt động của người kinh doanh được kiểm soát theo hai loại hình: theo kế hoạch chuẩn và theo lịch hẹn (kế hoạch phát sinh ). Hàng ngày, người kinh doanh mở màn hình “Công việc hàng ngày” và tại đây hiển thị các khách hàng cụ thể, các nhiệm vụ cụ thể. Điều này tưởng như tầm thường, nhưng lại là cách thức làm việc của các nhà tỷ phú, đơn giản và hiệu quả.

Khối lượng, chất lượng công việc trong quá trình được lưu vết trong “Hồ sơ giao dịch” hay “Phân tích giao dịch” sẽ chỉ ra cho người kinh doanh kết quả công việc đã làm được. Điều này rất quan trọng. Bản chất tăng năng suất lao động là phải đo lường được khối lượng, chất lượng công việc; phải có hệ thống giám sát và thúc đẩy thường xuyên. CRM đồng hành cùng DN trong việc thay đổi cách thức làm việc.

Phân loại khách hàng

Đánh giá, phân loại là một yêu cầu không thể thiếu khi kết thúc một chu trình làm việc. Do có thể phân loại khách hàng, chọn các mẫu đối tượng, phân khúc thị trường…, CRM giúp các công ty gửi thông điệp tới đúng địa chỉ và hoàn thiện kế hoạch tiếp thị.

Dự báo đặt hàng

Có nhiều số liệu để hình thành dự báo, như số liệu thống kê kế toán, số liệu của sản phẩm tương tự, số liệu cùng kỳ, số liệu phân tích theo lý thuyết dự báo… Nhưng CRM cho chúng ta số liệu trực tiếp từ sự “cam kết chưa thành văn” của từng khách hàng trong các lần giao dịch về sản phẩm, số lượng, giá, thời gian dự định mua. Cơ sở các mối quan hệ khách hàng trở thành cơ sở các đơn đặt hàng hay nói cách khác, với CRM chúng ta có thể chủ động dự báo được nguồn lực khách hàng.

Gửi thông điệp hàng loạt tới khách hàng

Một trong những giá trị của thời đại Internet là người ta có thể gửi thông điệp ngay lập tức tới hàng triệu khách hàng mà không bị giới hạn bởi không gian địa lý hay những cản trở khác. Việc này không chỉ tốt cho tuyên truyền mà còn mang lại hiệu quả kinh tế nhờ cắt giảm được các chi phí tiếp thị trực tiếp. Ngoài khả năng tiếp thị hàng loạt, đúng đối tượng, các công cụ trong CRM còn hỗ trợ nhân viên kinh doanh giữ gìn tốt các mối quan hệ với khách hàng như: thông báo ngày kỷ niệm chung, ngày sinh nhật của khách hàng…

Duy trì tính liên tục trong kinh doanh

Mỗi tổ chức, DN bao giờ cũng có sự thay đổi nhân sự hoặc thay đổi về vị trí công việc và DN nào cũng cố gắng để sự thay đổi đó ít gây ảnh hưởng xấu nhất tới hoạt động của mình. Thực ra, những ảnh hưởng xấu không phải là do khó tìm người có trình độ tương đương mà do thông tin và đặc biệt là quan hệ khách hàng thường thay đổi cùng với nhân sự. Rất nhiều tổ chức được tách ra hoặc được hợp nhất lại trên nền tảng thông tin về quan hệ khách hàng. PM quản lý quan hệ khách hàng giúp chúng ta duy trì dòng chảy liên tục về quan hệ khách hàng – chính là “dòng doanh số” của DN.

c. Các công cụ được tích hợp trong hệ thống CRM

Theo thống kê từ Capterra, 5 công cụ được sử dụng nhiều nhất của CRM, bao gồm:

Quản lý lịch (calendar management): Hỗ trợ xác định và lên lịch trình tương tác với khách hàng hoặc khách hàng tiềm năng. Điểm mấu chốt là không quá sớm cũng không quá muộn, liên hệ đúng thời điểm sẽ giúp đẩy cao khả năng chuyển đổi thành khách hàng thực sự. Với nhân viên chăm sóc, đây là tính năng giúp quản lý tốt việc liên hệ hỗ trợ sau mua nhằm giúp khách hàng có trải nghiệm dịch vụ tốt nhất từ doanh nghiệp.
Email marketing: Với cơ sở dữ liệu khách hàng được xây dựng theo thời gian, đội ngũ marketing có thể thực hiện các chiến dịch email marketing với nhiều mục đích đa dạng (thường là cung cấp bản tin, hoặc thời gian ra mắt tính năng mới hoặc chương trình khuyến mại, giảm giá), thông qua đó xây dựng mối quan hệ liên tục với khách hàng.
Quản lý báo giá, đề xuất (quote, proposal): Quản lý báo giá, đề xuất cho từng khách hàng hoặc nhóm khách hàng, tự động sử dụng giá đã báo khi thực hiện đơn hàng cho khách hàng, tránh nhầm lẫn về mặt thông tin và thể hiện hình ảnh chuyên nghiệp.
Tích hợp marketing tự động (marketing automation): Tự động cho các nhiệm vụ công việc lặp lại nhằm nâng cao hiệu quả marketing bao gồm quản lý chiến dịch và quản lý email, báo cáo và phân tích khách hàng tiềm năng, tối ưu hoá website, tạo landing page và mẫu biểu.
Chấm điểm đầu mối (lead scoring): Tính năng cho biết khả năng chuyển đổi của một đầu mối thông qua điểm đánh giá, nhằm có sự chủ động trong việc liên hệ và ưu tiên khi chăm sóc.

5 công cụ được mong muốn nhất khi sử dụng CRM:

Theo dõi mạng xã hội (social listening): Biết được thương hiệu hay sản phẩm của mình đang được lan truyền / thảo luận ra sao trên mạng xã hội, cực kì hữu ích với các doanh nghiệp thường xuyên thực hiện các chiến dịch bán hàng, quảng cáo trên các nền tảng này.
Hồ sơ mạng xã hội (social profile): Bổ sung mặt còn lại trong việc thu thập thông tin khách hàng nhằm có được bức tranh đầy đủ về khách hàng, bên cạnh các thông tin được thu thập thông qua hoạt động bán hàng và marketing.
Ứng dụng trên di động (mobile app): Tiếng nói của xu hướng hiện đại, tăng tính linh hoạt cho người dùng. Đa phần các nhà cung cấp CRM ngày nay đều đã hoặc đang có kế hoạch cung cấp giải pháp CRM trên nền tảng di động.
Theo dõi đánh giá lòng trung thành của khách hàng (customer loyalty): Cạnh tranh càng cao trong một lĩnh vực, thì tầm quan trọng của công tác chăm sóc khách hàng ngày càng cao, giữ chân khách hàng tiếp tục sử dụng sản phẩm hay dịch vụ là nhiệm vụ tối hậu trong môi trường kinh doanh ngày nay. Việc biết được mức độ trung thành của khách hàng sẽ giúp đưa ra các chiến lược phù hợp để đạt được mục tiêu này.
Tích hợp e-commerce (e-commerce integration): Đây là tính năng đang ngày càng được ưa chuộng. Với doanh nghiệp sử dụng, đây là tính năng giúp họ tận dụng được các hiểu biết về thói quen và hành vi mua hàng của người tiêu dùng, kết hợp chúng vào nền tảng thương mại điện tử, nhằm làm tăng trải nghiệm và sự hài lòng của khách hàng. Với nhà cung cấp giải pháp, tính năng này giúp họ vượt trội hơn so với đối thủ, đồng thời cũng là ‘mồi câu’ thu hút các doanh nghiệp gắn bó với giải pháp của mình.

d. Các dấu hiệu doanh nghiệp cần một hệ thống CRM

Khách hàng là mục tiêu hướng đến quan trọng nhất của doanh nghiệp. Mỗi sản phẩm được làm ra doanh nghiệp luôn mong muốn có được lượng khách hàng nhiều nhất có thể. Nắm rõ được nhu cầu khách hàng cũng như quản lý được thông tin khách hàng sẽ giúp doanh nghiệp dễ dàng hơn trong việc đưa ra các chính sách phù hợp phát triển sản phẩm. Tuy nhiên, việc kiểm soát khách hàng cũng không phải vấn đề dễ dàng, nắm bắt được thị hiếu, nhu cầu khách hàng luôn là câu hỏi thường trực trong các nhà quản lý. Một số doanh nghiệp gặp khó khăn trong việc quản lý thông tin khách hàng, lúc này doanh nghiệp cần có một hệ thống quản lý thông tin khách hàng làm việc hiệu quả hơn.

Doanh nghiệp có các dấu hiệu sau đây thì nhất thiết phải nghĩ ngay đến CRM

Thông tin khách hàng được quản lý rời rạc, không tập trung
Thông tin khách hàng bị thất lạc
Khó tìm kiếm thông tin khách hàng khi cần
Khó xác định được khách hàng cũ hay mới
Việc theo dõi, chăm khóc khách hàng khó khăn
Nhân viên hay quản lý quên lịch hẹn với khách hàng do công việc dồn dập, đột xuất mà không có công cụ nhắc nhở
Nhân viên nghỉ việc và vô số sổ sách, giấy tờ, báo cáo,… liên quan đến khách hàng cần được bàn giao
Quá trình thống kê, báo cáo thông tin, nhu cầu khách hàng gặp khó khăn
Chưa đánh giá được khách hàng tiềm năng
Các chương trình chăm sóc khách hàng còn kém hiệu quả, sơ xài, không thu hút

Trên đây là một số dấu hiệu cho thấy doanh nghiệp đang cần một hệ thống có thể giúp quản lý thông tin khách hàng một cách hiệu quả, để đưa ra các chính sách phù hợp phát triển sản phẩm, chăm sóc khách hàng.

e. Bài học khi triển khai hệ thống CRM

Doanh nghiệp triển khai hệ thống CRM luôn có mong muốn sẽ nâng cao hiệu quả và năng suất làm việc trong doanh nghiệp, có được lợi thế cạnh tranh so với đối thủ, bên cạnh các mục tiêu như phát triển mối quan hệ với khách hàng, phục vụ và chăm sóc khách hàng tốt hơn. Tuy nhiên, để có được thành công trong việc lựa chọn và triển khai hệ thống, có những bài học mà doanh nghiệp phải thực sự lưu ý nhằm tránh khỏi những thất bại không mong muốn.

Trước hết, việc lựa chọn một hệ thống CRM phù hợp không phải dễ dàng, đôi khi một hệ thống được cho là phù hợp lại không mang lại nhiều kết quả và giá trị như mong đợi. Thực ra, đối với hệ thống CRM, cần phải chọn lựa những hệ thống có chức năng cơ bản. Nếu không triển khai một hệ thống, một mô hình CRM phù hợp với nhu cầu hiện tại của doanh nghiệp cũng như phù hợp một cách tương đối cho các yêu cầu trong tương lai, thì chủ doanh nghiệp sẽ mất không ít chi phí nhằm cải thiện hệ thống. Đây chính là yếu tố đầu tiên các doanh nghiệp cần phải cân nhắc, bên cạnh yếu tố giá cả.

Bên cạnh đó, không phải hệ thống CRM nào cũng có những đặc tính giống nhau, khi triển khai một hệ thống, thông thường doanh nghiệp cần có nhiều sự điều chỉnh nhằm làm cho hệ thống đó trở nên hữu ích hơn, phù hợp hơn với nhu cầu thực tế của doanh nghiệp, tuy nhiên không phải hệ thống nào cũng có tính thích ứng cao. Chính vì thế, xem xét đến tính linh hoạt của hệ thống cũng là rất quan trọng.

Để tránh tình trạng này, doanh nghiệp cần xác định rõ nhu cầu của mình khi bỏ tiền ra mua một phần mềm nào đó, dù là được quảng cáo là “hết sức phù hợp với nhu cầu thực tế của doanh nghiệp”. Nếu không cẩn thận trong khâu chuẩn bị, xác định nhu cầu và mục tiêu, doanh nghiệp chắc chắn sẽ phải có nhiều điều chỉnh trong thói quen, thậm chí là văn hoá kinh doanh của doanh nghiệp mình khi triển khai một hệ thống hoàn toàn mới. Dù thay đổi là tất yếu, nhưng doanh nghiệp nên hạn chế điều này cũng như tiết kiệm chi phí, thời gian và hãy để cho hệ thống bạn mua về phục vụ nhu cầu của bạn một cách hữu ích nhất.

Ngoài ra, rất nhiều doanh nghiệp còn không nhận thức được tầm quan trọng của đào tạo trước và sau khi triển khai hệ thống. Cần nhớ rằng, những chương trình đào tạo phù hợp sẽ đảm bảo nhân viên cũng như các phòng, ban được trang bị kiến thức về hệ thống như công dụng, cách vận hành,… Không chỉ chú tâm đến quá trình đào tạo trước khi triển khai, doanh nghiệp cũng nên có kế hoạch đào tạo cho nhân viên, cán bộ trong suốt quá trình áp dụng hệ thống, giúp cho họ luôn được cập nhật và trở nên tự tin hơn khi sử dụng.

Áp dụng hệ thống CRM, đồng nghĩa với việc doanh nghiệp có khả năng sở hữu một kho dữ liệu đồ sộ, và luôn được cập nhật về khách hàng. Tuy nhiên, vấn đề đặt ra là doanh nghiệp khai thác được gì từ những dữ liệu ấy, do vậy, những bản báo cáo thông tin là rất cần thiết và hữu ích, nó cho biết doanh nghiệp có được gì từ những thông tin “đầu vào” của khách hàng, từ đó có thêm định hướng cho công tác phát triển, cải thiện sản phẩm cũng như dịch vụ cung ứng cho khách hàng. Một yếu tố nữa doanh nghiệp cần quan tâm, đó là hệ thống CRM chỉ được coi là được triển khai một cách toàn diện khi nó được ban quản lý sử dụng nhằm đánh giá kết quả làm việc của cấp dưới.

Nếu tận dụng tốt những bài học trên đây, cũng như luôn sáng tạo và không ngừng tạo thêm giá trị cho doanh nghiệp từ một hệ thống có sẵn, chắc chắn doanh nghiệp sẽ thu được nhiều lợi ích, khuyến khích tinh thần làm việc của nhân viên cũng như làm hài lòng khách hang.

0 Shares

Một thực tế thường thấy tại các doanh nghiệp hiện nay là tình trạng thiếu các chương trình đào tạo để triển khai ứng dụng ERP chính là nguyên nhân chính dẫn đến thất bại của các ứng dụng này.

Cách thức các nhà tư vấn về ERP được thuê từ bên ngoài thường đánh giá quá trình ứng dụng ERP cũng tương tự như cách thức mà các bác sỹ tiến hành chuẩn đoán cho bệnh nhân của mình.

Trước tiên, họ sẽ hỏi các “bệnh nhân” về những khúc mắc họ đang gặp phải (trong trường hợp này là các giám đốc công nghệ thông tin CIO, các đội dự án, bộ phận nhân sự và các nhà quản lý việc đào tạo,… ). Sau đó, họ sục sạo vào một số lĩnh vực, tìm ra những điểm nghi vấn và các vấn đề tồn tại. Họ cũng thực hiện một số bài kiểm tra để xem liệu những triệu chứng bề mặt bên ngoài ấy có nhất quán với các vấn đề nằm sâu bên trong hay không và tiến sâu hơn nữa để tìm ra những tồn tại trong khâu đào tạo còn đang ẩn giấu trong doanh nghiệp mà bằng mắt thường không thể nhận ra được.

Hầu hết chúng ta đều có những hướng dẫn “triệu chứng y khoa” hoặc có những địa chỉ trang web để giúp chúng ta quyết định xem liệu những cơn đau nơi dạ dày có phải là triệu chứng của bệnh viêm ruột thừa, bệnh về đường tiêu hóa hoặc những căn bệnh nguy hiểm hơn hay không.

Bước tiếp theo chúng ta thường làm là hỏi ý kiến tư vấn từ các bác sỹ. Cũng tương tự như quá trình trên, nếu chúng ta tin rằng quá trình đào tạo ảnh hưởng (hoặc có thể ảnh hưởng) đến việc ứng dụng ERP trong doanh nghiệp, chúng ta nên ngay lập tức liên lạc để xin ý kiến tư vấn từ các chuyên gia đào tạo ERP đáng tin cậy. Dưới đây là những tồn tại thường thấy trong việc đào tạo để ứng dụng ERP trong doanh nghiệp.

a. Chậm trễ trong việc phát hiện các tồn tại

Nếu các ứng dụng được thực hiện trên một quy mô lớn, (ví dụ như SAP), đào tạo ứng dụng thường được xem là một phần trong hợp đồng ứng dụng. Các yếu tố của quá trình đào tạo này được liệt kê cùng với các thành phần cụ thể khác và tương thích với từng giai đoạn của kế hoạch ứng dụng (ví dụ như ở SAP R/3, kế hoạch ứng dụng được gọi là ASAP). Trong điều kiện tốt nhất thì quá trình này bao gồm một kế hoạch để thay đổi kế hoạch đào tạo và đồng nhất kế hoạch này với các nguồn lực bên trong và bên ngoài doanh nghiệp.

Tuy nhiên, điều thường thấy hơn tại các doanh nghiệp chính là hiện tượng quá trình đào tạo chỉ được thể hiện khá mờ nhạt trên hợp đồng và không hề có các điều kiện cụ thể nào được đưa ra, ví dụ như chương trình đào tạo được thiết kế, ghi chép và tiến hành như thế nào. Thậm chí, trong các trường hợp xấu hơn, các khách hàng doanh nghiệp vốn đã chi hàng triệu đô la để ứng dụng ERP và quan trọng hơn là để đánh giá hiệu quả của hệ thống này trong việc đạt được các mục tiêu quan trọng của doanh nghiệp, lại không hề hay biết hợp đồng của mình có bao nhiêu phần trăm được dành cho chương trình đào tạo hay là tỷ lệ lợi suất trên đầu tư ROI và các phương pháp đào tạo là gì.

Điều chúng ta cần làm ở đây là trước khi ký một hợp đồng, chúng ta nên yêu cầu những người có chức năng thực hiện ERP nêu rõ các chi tiết về nguồn lực doanh nghiệp và nguồn ngân quỹ được phân phối như thế nào, cũng như biểu thời gian các đội dự án sẽ được đào tạo về ứng dụng ERP và chương trình đào tạo dành cho người sử dụng cuối cùng sẽ được thực hiện như thế nào. (Chúng ta thường thấy điều này khi các doanh nghiệp xác định quá trình kinh doanh của mình). Các doanh nghiệp cũng nên tham khảo ý kiến nhận xét từ một bên thứ ba về quá trình và kế hoạch đào tạo của mình. Đây là điều nên làm đối với các doanh nghiệp trước bất kỳ quyết định quan trọng nào.

b. Không có kế hoạch thực hành

Việc phỏng vấn các giám đốc có liên quan đến vấn đề ứng dụng ERP sẽ giúp xác định được các kế hoạch thực hành phản ánh chính xác công việc của những người sử dụng cuối cùng như thế nào, ví dụ như đồng nhất hóa quá trình thực hiện thực tế với các chức năng, nhưng thực tế cho thấy những dữ liệu này thậm chí không hề tồn tại trong doanh nghiệp.

c. Mất mát nguồn lực

Trước khi ngân quỹ dành cho việc ứng dụng ERP được xác lập, các doanh nghiệp thường tạo ra một kế hoạch kinh doanh trong đó có nêu chi tiết tỷ suất lợi nhuận trên đầu tư ROI, doanh thu và ảnh hưởng của hệ thống. Các quyết định nên được tiến hành dựa vào các số liệu trên. Nhờ vào việc đánh giá quá trình ra quyết định, chúng ta sẽ thấy được các quyết định chỉ dành để hỗ trợ các yếu tố phát triển riêng biệt chứ không phải là các mục tiêu kinh doanh.

Một ví dụ được đưa ra ở đây là quá trình phân bổ nguồn lực của các đội đào tạo đến các đội dự án phần mềm mà không hề có bất kỳ kế hoạch thay thế nào cho các nguồn lực được phân bổ đó. Chúng ta cũng thường thấy việc đào tạo cho người sử dụng cuối cùng bị đình trệ hoặc thậm chí bị xếp vào những nhân tố không hề đem lại được cái nhìn tổng quát về quá trình kinh doanh cũng như sự tương tác giữa chúng như thế nào và diễn ra khi nào. Điều này dẫn đến những tốn kém trong chương trình đào tạo và làm trì hoãn hoặc giảm tác dụng của ERP đến việc kinh doanh của doanh nghiệp.

d. Thiếu tính pháp lý

Chương trình đào tạo cần chỉ ra được cầu nối giữa hệ thống pháp lý đến những quá trình thực hiện mới, chúng sẽ có những điểm khác biệt nào và tại sao. Việc mặc định rằng người sử dụng cuối cùng có thể nhanh chóng chuyển từ hệ thống này sang hệ thống khác mặc dù không có chi tiết về các bước tiến hành và các lý do tiến hành được xem như một “triệu chứng” của việc người sử dụng cuối cùng sẽ không thể thích ứng nhanh chóng và đầy đủ với hệ thống mới được.

Ngoài ra, còn có một số lý do về mặt tinh thần khi thực hiện những điều đó. Việc đặt người sử dụng cuối cùng và quá trình mới, chúng ta đang cho họ thấy sự làm việc chăm chỉ và những hiểu biết của họ là điều đáng được trân trọng. Khi đó, người sử dụng cuối cùng sẽ sẵn sàng cởi mở hơn trong việc học hỏi hệ thống mới.

e. Quá nhiều thông tin

Các quá trình đào tạo thường tốn khá nhiều thời gian, trong khi chỉ cần một số thời lượng đào tạo rất nhỏ để các nhân viên hiểu được nhiệm vụ cụ thể của mình. Điều này không chỉ gây lãng phí nguồn lực đối với các nhân viên mà còn làm cho họ phải quyết định xem nôi dung đào tạo nào là phù hợp với mình. Nếu họ cố gắng hiểu tất cả các nội dung thì họ sẽ chỉ có thể có được những ý niệm mơ hồ về những nhiệm vụ cụ thể của mình.

f. Thiếu sự đồng nhất giữa các chức năng

Nếu các nhân viên chỉ tập trung hoặc tập trung phần lớn và các chương trình đào tạo dựa trên các giao dịch chứ không phải dựa trên nhiệm vụ hoặc chu trình cụ thể thì họ sẽ chỉ thực hiện được những chương trình dựng sẵn chứ không thể biết được cách thức và thời gian để thích ứng với các quy trình kinh doanh mới. Sự khác biệt giữa việc có thể sử dụng các phần mềm và việc có thể sử dụng ERP thường là nguyên nhân dẫn đến những thất bại.

g. Các phương pháp luận nghèo nàn

Chúng ta có thể dễ dàng nhận thấy các vấn đề:
Các mức đánh giá chương trình đào tạo thường khá thấp.
Việc ghi chép thường bị đánh giá là yếu kém.
Người sử dụng cuối cùng nhận thấy hệ thống khá chật hẹp và không hiệu quả.
Các phương pháp luận được thiết lập để mô tả hoạt động của doanh nghiệp thường không giống với kỳ vọng.

Các doanh nghiệp thường cho rằng hoạt động của doanh nghiệp và các phương pháp đo lường theo thời gian sẽ được cải tiến. Họ tin rằng nhóm thực hiện chương trình đào tạo sẽ đạt được các mục tiêu của mình cũng như sẽ cải tiến được các nội dung trong những giai đoạn tiếp theo. Họ cũng luôn luôn cho rằng (hoặc hy vọng rằng) những người sử dụng cuối cùng sẽ học hỏi từ chính công việc của họ. Thực tế thường hiếm khi xảy ra như vậy, thường thì nội dung của các phương pháp luận vốn đã nghèo nàn sẽ tiếp tục suy giảm theo thời gian.

Thậm chí nếu chúng được cải tiến dần thì các doanh nghiệp cũng cần phải ghi lại kế hoạch kinh doanh và các biểu giá trị thời gian dự kiến cho các hệ thống ERP. Nhưng thực tế thường hiếm khi như vậy. Đã đến lúc chúng ta điều chỉnh các chương trình đào tạo để chúng tương thích với các mục tiêu kinh doanh.

h. Có quá nhiều câu hỏi

Chúng ta có thể nhìn nhận một bài học từ các trung tâm cuộc gọi. Tỷ lệ câu hỏi của những người sử dụng cuối cùng ngày một lớn trong tổng số các câu hỏi được nêu ra, trong trường hợp này là từ các giám đốc phòng ban. Trước tiên, chúng ta hãy cùng thiết lập các phương pháp luận và sau đó xem xét rằng các số liệu này bắt đầu giảm dần và nhanh chóng giảm xuống đến gần con số 0.

Nếu ngày càng có quá nhiều câu hỏi không được trả lời thì khả năng các chương trình đào tạo không còn hiệu quả ngày càng lớn. Nếu chúng ta thấy con số câu hỏi giảm mạnh ở bất kỳ lĩnh vực nào thì cũng không nên vội vàng cho rằng “các rắc rối đã được giải quyết”. Hãy kiểm tra các phương pháp luận và so sánh chúng với kết quả và quá trình để đạt được kỳ vọng. Chúng ta đã từng chứng kiến những trường hợp trong đó các đội dự án quyết định ngừng đưa ra các câu hỏi (hoặc buộc phải ngừng) và, mặc dù các câu hỏi không còn tăng lên nữa nhưng các phương pháp luận thì vẫn không hiệu quả.

i. Hiểu biết chỉ gói gọn trong một lĩnh vực

Đây là vấn đề ngược với vấn đề 5 “chương trình đào tạo dành cho tất cả mọi người”. Ở đây, kế hoạch đào tạo không hề có bất kỳ nội dung dư thừa nào. Các nhân viên được đào tạo các nhiệm vụ và chỉ các nhiệm vụ của họ mà thôi mà không hề xem xét đến hai yêu cầu kinh doanh chủ chốt: 1) Họ có thể hoàn thành công việc của mình tốt hơn khi họ biết các nhân viên khác có nhiệm vụ gì và 2) có thể họ sẽ không có mặt tại nơi làm việc hàng ngày hoặc thậm chí, họ có thể nghỉ việc.

Ở Caveo Learning, các thư viện bài học theo tầng được sử dụng để cung cấp cho người sử dụng cuối cùng cái nhìn sâu sắc hơn về những yêu cầu và hiệu quả công việc, cũng như giúp các nhân viên mới bắt kịp với nhịp độ công việc. (Điều này sẽ cải thiện đáng kể sự linh hoạt trong việc thêm các quy trình và cập nhật mới, nhưng đó là câu chuyện cho tương lai). Trong khi còn có những cách khác để đảm bảo kiểm soát tình hình và người sử dụng cuối cùng hiểu rõ các yêu cầu và ảnh hưởng từ nhiệm vụ của mình, chúng ta cần xây dựng một số chương trình phụ thêm. Điều này không chỉ giúp cho quá trình hoạt động được liên tục mà nó còn giúp xây dựng tinh thần làm việc theo nhóm.

k. Những tư vấn viên về đào tạo là những người chưa có nhiều kinh nghiệm

Các hãng tư vấn tin rằng việc đào tạo ERP là một việc làm tốt để họ đào tạo nhân viên của mình trong việc ứng dụng ERP. Vậy, chúng ta có thể xác định mức độ kinh nghiệm của các tư vấn viên đào tạo được thuê từ bên ngoài như thế nào? Hãy trực tiếp xin ý kiến của các nhà phát triển chương trình đào tạo và những chuyên gia đào tạo về kinh nghiệm trong quá khứ cũng như trình độ học vấn của họ. Nếu họ không phù hợp với vị trí cần tuyển dụng, hãy yêu cầu các nhà quản lý dự án tìm những người có nhiều kinh nghiệm và phù hợp hơn. Giải quyết những vấn đề tiềm ẩn (hoặc ít nhất là xác định ảnh hưởng của những vấn đề tiềm ẩn).

10 vấn đề trên đã giúp chúng ta tự đánh giá được những vấn đề còn tồn tại sâu hơn bên trong hệ thống doanh nghiệp đang làm cho các chương trình đào tạo kém hiệu quả và nhiều khả năng dẫn đến thất bại trong việc ứng dụng ERP để đạt được mục tiêu về thời gian và mục tiêu kinh doanh.

Trong khi việc phân bổ ngân quỹ cho chương trình đào tạo và đưa ra các quyết định về chi phí cho chương trình này có thể được thực hiện khá dễ dàng thì chúng ta sẽ gặp khó khăn hơn trong việc đo lường ảnh hưởng của những chương trình đào tạo không hiệu quả. Hoặc, trong các trường hợp mà các nội dung đào tạo không được đánh giá thì chúng ta sẽ đo chỉ số ROI cho cả các yếu tố không hề xảy ra trên thực tế.

Điều này có nghĩa là các chương trình kinh doanh và/hoặc các kế hoạch sẽ bao gồm (hoặc nên bao gồm) các phương pháp luận được thiết kế để dành riêng cho chương trình đào tạo và nhằm mục tiêu tăng hiệu quả hoạt động của doanh nghiệp ở cấp độ chức năng. Và cũng có nhiều cách để dự đoán khả năng chính xác của các phương pháp luận thông qua việc xem xét tính hiệu quả từ các chương trình đào tạo sẽ ảnh hưởng đến hoạt động của doanh nghiệp như thế nào.

Nếu chúng ta nhận thấy bất kỳ vấn đề nào trong số các vấn đề nói trên thì có rất nhiều khả năng chúng ta đang gặp rắc rối trong khâu đào tạo. Điều còn cần xem xét ở đây chính là quy mô của các vấn đề này lớn hay nhỏ. Nếu sử dụng các phương pháp chuẩn đoán vấn đề như phần đầu bài viết đề cập, chúng ta có hai lựa chọn: 1) Không để tâm chú ý đến các hiện tượng và hy vọng rằng chúng sẽ biến mất trong một thời gian ngắn, hoặc 2) Hiểu rõ những vấn đề tiềm ẩn và thực hiện từng bước một để giải quyết chúng. Do các chương trình đào tạo là lý do thứ hai giải thích cho những thất bại trong ứng dụng ERP (thiếu hỗ trợ quản lý là lý do thứ nhất), chúng ta có thể nghĩ đến giải pháp chú ý một cách nghiêm túc đến những yếu kém trong các kế hoạch và chương trình đào tạo của doanh nghiệp để xác định những vấn đề tồn tại, cũng như tìm ra các cách thức thích hợp để khắc phục chúng.

0 Shares

a. Các tiêu chí thành công của một dự án ERP

Hệ thống ERP triển khai đúng tiến độ cam kết của dự án
Hệ thống ERP triển khai đảm bảo ngân sách dự án được duyệt
Các chức năng hệ thống ERP đáp ứng nhu cầu sử dụng của Công ty
Hệ thống ERP mang lại hiệu quả cho Công ty

b. Các yếu tố đảm bảo triển khai ERP thành công

Những câu chuyện về các dự án ERP thất bại luôn là nỗi ám ảnh cho các CEO hay CIO khi quyết định triển khai hệ thống ERP cho doanh nghiệp mình. Vì vậy, câu hỏi thường trực luôn đặt ra trong đầu họ là phải làm gì để tránh các vết xe đổ đi trước và đảm bảo rằng dự án luôn thành công?

Lựa chọn đúng giải pháp

Điều này có vẻ hiển nhiên, nhưng trên thực tế không phải luôn luôn xảy ra. Các nhà cung cấp giải pháp ERP, để đạt được mục đích bán hàng, thường có xu hướng hoàn hảo hóa khả năng của giải pháp. Tức là với bất kỳ bài toán nghiệp vụ nào doanh nghiệp đặt ra, giải pháp đều đáp ứng hoàn toàn. Tất nhiên thực tế không hẳn như vậy. Trong trường hợp này, doanh nghiệp cần đặt câu hỏi ngược lại với nhà cung cấp: Họ sẽ giải quyết bài toán như thế nào? Họ đã từng gặp bài toán này ở đâu chưa?…Đó là thực tiễn thành công của giải pháp. Ngoài ra, doanh nghiệp cần phải có quá trình lựa chọn khắt khe và có cấu trúc để tìm ra giải pháp phù hợp nhất cho mình.

Lựa chọn đúng đơn vị triển khai

Đây cũng là điều tối quan trọng tương tự như việc lựa chọn đúng giải pháp. Đơn vị triển khai phải là đối tác có đủ năng lực chuyên môn và kinh nghiệm nhằm đảm bảo doanh nghiệp sẽ nhận được tối đa những tính năng, lợi ích của giải pháp đã đầu tư. Việc lựa chọn này, doanh nghiệp có thể tự thực hiện hoặc cũng có thể thuê đơn vị tư vấn độc lập. Đây là xu hướng đã phổ biến trên thế giới, tuy nhiên tại Việt Nam mới chỉ có một số ít doanh nghiệp áp dụng, điển hình là Tân Hiệp Phát và Prime Group.

Lập kế hoạch dự án một cách cẩn thận

Lập kế hoạch triển khai một cách thực tế và chi tiết nhất, đảm bảo rằng doanh nghiệp luôn kiểm soát được những gì sẽ phải làm và từng cá nhân trong đội dự án sẽ chịu trách nhiệm phần công việc nào. Đây là những điều rất cơ bản trong việc thực hiện bất kỳ dự án nào không chỉ là dự án ERP.

Có một thực tế đang diễn ra phổ biến tại các dự án ERP tại Việt Nam: thời gian triển khai gần như luôn kéo dài hơn so với kế hoạch ban đầu. Có thể do nhiều nguyên nhân: thay đổi nhân sự, mức độ phức tạp của nghiệp vụ đòi hỏi customize, thay đổi quy mô triển khai…tuy nhiên, còn có một nguyên nhân chung, đó là khi lập kế hoạch, doanh nghiệp cũng như đơn vị triển khai thường đặt ra các mốc thời gian một cách khá “lạc quan”, trong nhiều trường hợp là “phi thực tế”. Có thể do đơn vị triển khai không ước lượng được khối lượng công việc phải làm. Cũng có thể do doanh nghiệp muốn hoàn thành dự án sớm nhất có thể.

Điều này rất nên tránh, bởi việc trễ thời gian không chỉ dẫn đến việc phát sinh công việc, phát sinh chi phí mà còn ảnh hưởng tới tinh thần của các thành viên dự án.

Xác định phạm vi dự án rõ ràng và luôn tập trung vào đó

Thay đổi phạm vi giữa chừng luôn tiềm ẩn nguy cơ lớn đối với hầu hết các dự án. Khi bổ sung một điểm triển khai, hoặc một phân hệ đồng nghĩa với việc phải đầu tư thêm nguồn lực và thay đổi cấu trúc, kế hoạch dự án. Nếu không quản lý khéo, có thể dẫn đến tình trạng chồng chéo, ảnh hưởng tới các công việc khác hoặc nghiêm trọng hơn có thể làm trì hoãn cả dự án.

Tập trung vào những lợi ích đã xác định

Làm thế nào để xác định một dự án ERP triển khai thành công? Thành công của một dự án ERP không chỉ đo đạc bằng các tiêu chuẩn thông thường như hoàn thành đúng thời gian hay đúng ngân sách. Thành công thực sự thể hiện trong việc giải quyết hoàn toàn các bài toán nghiệp vụ cũng như quản lý của doanh nghiệp, mức độ hài lòng của đội ngũ nhân viên với hệ thống mới. Từ đó doanh nghiệp đạt được những lợi ích đã kỳ vọng khi quyết định đầu tư ERP như tăng năng suất, giảm được chi phí, minh bạch hóa tài chính…

Lựa chọn đội dự án với các thành viên phù hợp

Trong nhiều trường hợp, doanh nghiệp thường mặc định rằng việc triển khai ERP là trách nhiệm của đơn vị triển khai. Họ nghĩ đơn giản chỉ cần bỏ tiền mua giải pháp, thuê triển khai và một vài tháng sẽ có hệ thống mới để sử dụng.

Đánh giá thấp các yêu cầu và vai trò của đội dự án nội bộ là một trong những nguyên nhân dễ dẫn đến thất bại. Những kỹ năng, kinh nghiệm và nỗ lực của đội dự án nội bộ là tối quan trọng đối với việc triển khai. Bởi họ chính là những người phối hợp với đơn vị triển khai để xây dựng hệ thống và cũng chính họ sau này sẽ là những người tiếp nhận, vận hành hệ thống. Hãy lựa chọn những nhân viên am hiểu nghiệp vụ cũng như nắm rõ các vấn đề mà doanh nghiệp đang gặp phải để tham gia vào đội dự án. Cũng cần đảm bảo rằng đây là những người sẽ gắn bó lâu dài với doanh nghiệp.

Trong thời gian triển khai dự án, tốt nhất hãy để họ tập trung duy nhất vào công việc triển khai, các công việc thường ngày nên chuyển giao cho những người khác.

Đảm bảo có sự cam kết từ cấp lãnh đạo

Dự án ERP cần phải được định hướng từ trên xuống dưới, cần có người từ đội ngũ lãnh đạo tham gia chỉ đạo, hỗ trợ hàng ngày. Mâu thuẫn, hay đơn giản là sự không thống nhất có thể nảy sinh bất cứ lúc nào giữa thành viên hai đội dự án, đó là lúc cần sự dung hòa cũng như quyết đoán của lãnh đạo .

Đảm bảo người dùng cuối được đào tạo đầy đủ

Việc triển khai chưa dừng lại sau khi đã thiết kế, cấu hình và cài đặt được hệ thống bởi hệ thống không thể tự nó mà vận hành được, những người dùng cuối bao gồm đội ngũ quản trị hệ thống và đội ngũ nhân viên tác nghiệp cần phải được đào tạo để sử dụng hệ thống đúng cách và hiệu quả nhất. Việc đào tạo cần được thực hiện một các nghiêm túc, hướng dẫn lý thuyết phải gắn liền với thực hành ngay trên máy. Nếu có điều kiện doanh nghiệp nên đào tạo cho tất cả người dùng tuy nhiên, trong một số trường hợp người dùng quá đông hay doanh nghiệp có nhiều quá nhiều chi nhánh tại nhiều địa điểm khác nhau, có thể lựa chọn đào tạo những người chủ chốt, sau đó chính những người này sẽ tiếp tục đào tạo lại cho người khác.

Hệ thống hóa các báo cáo

Hãy suy nghĩ về các hệ thống hiện tại và danh sách các báo cáo mà doanh nghiệp đang sử dụng trước khi triển khai ERP. Liệu rằng đơn vị triển khai có thể cung cấp được tất cả các báo cáo này trên hệ thống ERP mới? Nếu được, sẽ mất bao nhiêu thời gian để phát triển tất cả các báo cáo này?

Doanh nghiệp thường có tâm lý tận dụng tối đa đơn vị triển khai để xây dựng và phát triển hệ thống báo cáo nhiều nhất có thể, trong số đó có thể có những báo cáo thực sự không cần thiết. Điều này sẽ dẫn đến việc lãng phí nguồn lực của cả hai bên.

Quản lý thay đổi hiệu quả

Một điều chắc chắn là sự ra đời của hệ thống mới sẽ ảnh hưởng đến nhiều khía cạnh trong doanh nghiệp: các quy trình kinh doanh, thủ tục thay đổi dẫn đến vai trò của một số nhân sự sẽ khác… Do mỗi người đều có phản ứng khác nhau trước những thay đổi, nên đây sẽ là lúc doanh nghiệp cần có một chiến lược khéo léo để từng bước đưa ERP vào một cách “xuôi chèo, mát mái”.

0 Shares

Mô hình tổng chi phí được phát triển ban đầu bởi Garner Group vào năm 1987 để phân tích các chi phí liên quan đên việc mua sắm, triển khai và duy trì một hệ thống thông tin trong một khoảng thời gian cụ thể thường từ 3 đến 5 năm. Các chi phí này bao gồm chi phí bản quyền phần mềm, chi phí triển khai, chi phí liên quan đến nâng cấp hệ thống thông tin, chi phí bảo trì hàng năm bởi nhà cung cấp và nội bộ.

Theo nghiên cứu của nhóm Meta Consulting Group, chỉ khoảng 20% số công ty triển khai các giải pháp ERP hiểu được Tổng chi phí trong triển khai của họ. Phần còn lại 80% không hiểu và nhìn nhận đầy đủ các chi phí hỗ trợ đi kèm và chi phí hệ thống hạ tầng. Do đó, những công ty này thường lựa chọn phần mềm rẻ tiền hơn và nghĩ rằng đó là tiết kiệm hơn phần mềm đắt tiền. Trong thực tế, hệ thống thông tin được xem là rẻ tiền tính cả chi phí phần mềm và phần cứng có thể đắt hơn nếu xem xét Tổng chi phí triển khai bởi vì do chi phí bảo trì và các chi phí liên quan đến sửa đổi sản phẩm. Thường thì rất khó dự tính hết được Tổng chi phí, người mua hệ thống thông tin cần phải xem xét cẩn trọng khi ra quyết định lựa chọn hệ thống thông tin nào.

a. Chi phí tư vấn

Có một số dự án thất bại do không lường trước được hết các yếu tố rủi ro như yêu cầu người sử dụng không được làm rõ, không hiểu hết về thời gian và chi phí cần thiết để triển khai, lựa chọn sai các phân hệ, cấu hình hệ thống sai,… Các yếu tố này có thể phòng ngừa trước bởi nhà tư vấn. Nhà tư vấn giúp doanh nghiệp phân tích hệ thống hiện tại, tiếp cận các giải pháp đúng đắn và/hoặc nhìn trước được quá trình triển khai của các nhà cung cấp.

Một nhà tư vấn thường cần thiết hơn khi mua các sản phẩm quốc tế và chi phí khoảng từ 30% đến 70% chi phí bản quyền.

b. Chí phí bản quyền

Chi phí bản quyền là chi phí ban đầu phải trả để được sử dụng phần mềm. Chi phí này thường dựa trên số phân hệ, và số người dùng đồng thời của phần mềm. Chi phí bản quyền ở Việt Nam cho một gói bản quyền thường khoảng từ 300 đến 50.000USD.

Theo quy luật chung, các ứng dụng đóng gói thường rẻ hơn so với phần mềm phải phát triển sửa đổi vì chi phí phát triển phần mềm đóng gói được chia sẻ cho hàng trăm hoặc hàng ngàn người sử dụng khác.

c. Chí phí triển khai

Đây là chi phí triển khai ERP, nó bao gồm cả chi phí trả cho nhà cung cấp dịch vụ và thời gian tham gia của nhân viên trong công ty bỏ ra để tham gia vào triển khai hệ thống ERP. Với những dự án phức tạp, chi phí triển khai có thể bằng 5 lần chi phí bản quyền. Nhưng ở Việt Nam, nó ít khi cao đến vậy do độ phức tạp đòi hỏi còn thấp.

Dựa trên báo giá của các nhà cung cấp, với các sản phẩm ERP trung bình của Việt Nam chi phí triển khai khoảng từ 6.000 đến 75.000USD, với mức trung bình khoảng 40.000USD tức tương đương 100% chi phí bản quyền và có sự dao động lớn tuỳ theo. Tuy nhiên, các ứng dụng phát triển trong nước chi phí triển khai chỉ vào khoảng 15% chi phí bản quyền nhưng thường các nhà cung cấp báo với giá rất cao.

Đối với các sản phẩm ERP cao cấp của quốc tế thì chi phí triển khai thường cao hơn nhiều lần các sản phẩm ERP phát triển trong nước.

e. Chi phí bảo trì hàng năm (maintaince fee)

Để đảm bảo vận hành trơn tru và khai thác hiệu quả hệ thống ERP, doanh nghiệp (DN) không nên thiếu chi phí cho bảo trì và nâng cấp hệ thống. Chi phí bảo trì hàng năm thường được các nhà cung cấp phần mềm tính vào phí dịch vụ hàng năm chi việc sửa chữa các vấn đề phát sinh. Chi phí bảo trì hàng năm thường khoảng từ 8% đến 20% của chi phí bản quyền, nhưng thường là 20%.

Sau khi hết thời gian triển khai và bảo hành sản phẩm, DN cần cân nhắc đến phần hỗ trợ này. DN thường hay nhầm lẫn trách nhiệm “hỗ trợ” của nhà cung cấp giải pháp bao gồm cả việc đảm bảo hệ thống vận hành trơn tru và an toàn. Trong khi thực tế, bảo trì và nâng cấp hệ thống là hai khoản mục cần tách bạch rõ. Chi phí bảo trì dành cho việc duy tu, bảo trì hệ thống, sửa lỗi phát sinh của phần mềm. Còn nâng cấp sẽ gắn với các yêu cầu phát sinh của DN, hoặc nhu cầu nâng cấp phiên bản mới.

Chi phí bảo trì bao gồm tất cả các khoản chi phí gắn với công việc sửa lỗi phát sinh cho phần mềm ERP. Đối với DN mua Phần mềm ERP của nước ngoài, nhưng do một đơn vị thứ ba triển khai, phần chi phí bảo trì cũng tách làm hai: phần bảo trì cho sản phẩm (thường gắn vào giá bản quyền Phần mềm và quy định trước, ví dụ: Với Oracle, 15% phí là của bản quyền Phần mềm, bao gồm cả cơ sở dữ liệu) và phần bảo trì dịch vụ triển khai (bao gồm phần sản phẩm đã được thiết lập theo các quy trình dành cho DN). Tất nhiên, lỗi phát sinh thuộc “nhà” nào (nhà cung cấp sản phẩm hay nhà triển khai) thì bên đó sẽ khắc phục.

Tùy chính sách của nhà cung cấp mà việc sửa lỗi có tính phí hay không. Một số phần mềm lớn của nước ngoài thường tính phí sửa lỗi, trừ một số lỗi nghiêm trọng mà hãng đưa ra chính sách cập nhật bản sửa lỗi miễn phí.

f. Chi phí nâng cấp (upgrade fee)

Tương tự như bảo trì, việc nâng cấp tách làm hai phần: Phần nâng cấp phần mềm (thêm chức năng, tiện ích, nâng phiên bản…) và phần phát sinh trong triển khai (thay đổi về chức năng, quy trình sử dụng, thêm tiêu chí lọc, báo cáo mới…). Phần nâng cấp bao gồm cả triển khai thêm cho các phòng ban, đơn vị mới hoặc thêm quy trình tác nghiệp mới. Vấn đề này thường phát sinh khi hãng Phần mềm ERP và đơn vị triển khai là 2 đơn vị độc lập. Như vậy, khi DN đưa yêu cầu mới thì cần phân biệt nó thuộc đối tượng nào xử lý. Ví dụ, DN thấy Phần mềm ERP của mình thiếu 3 báo cáo. Nếu các báo cáo đó thuộc nhóm báo cáo chuẩn của Phần mềm ERP mà phiên bản sau đã có, còn thời điểm DN triển khai thì chưa có, DN sẽ yêu cầu hãng Phần mềm cung cấp thêm. Trong trường hợp các báo cáo là yêu cầu thêm của DN vì mục đích quản lý (dạng báo cáo customize), DN sẽ yêu cầu hãng triển khai bổ sung 3 báo cáo mới cho riêng mình. Tuy nhiên, trên thực tế, các hãng triển khai đều “bao thầu” luôn phần nâng cấp của hãng. Tùy vào phạm vi hợp đồng nâng cấp mà DN sẽ đưa ra yêu cầu phát sinh (ví dụ: sửa màn hình, thêm các báo cáo… thậm chí sửa quy trình tác nghiệp).

Ngoài ra cũng bao gồm nâng cấp và thêm mới hệ thống hạ tầng thông tin như bản quyền các hệ thống quản trị dữ liệu, máy chủ ứng dụng, đường truyền băng thông rộng, thiết bị kết nối và các máy tính, máy chủ. Chi phí phụ thuộc vào yêu cầu của công ty đưa ra. Một máy chủ trung bình thường khoảng từ 3000 đến 6000USD. Chi phí thiết lập hệ thống mạng thường khoảng 200 đến 300USD cho một thành phần mạng.

f. Chi phí quản lý nội bộ

Một chi phí nữa chiếm khá nhiều là chi phí con người trong doanh nghiệp để duy trì hệ thống ERP, hỗ trợ người sử dụng và giải quyết các vấn đề liên quan đến hệ thống ERP. Trung bình, một người IT trong công ty hỗ trợ được 50 người sử dụng, nhưng hệ thống phức tạp thì thì cần nhiều người hỗ trợ hơn cho cùng một số người sử dụng.

Một nhân tố khác liên quan đến chi phí nội bộ là thời gian người sử dụng phải bỏ ra để tham gia vào hệ thống trong quá trình triển khai và giải quyết các vấn đề phát sinh. Ví dụ, nếu công ty sử dụng một phần mềm phát triển và nhân viên của phòng kế toán phải dành thời gian cho việc sửa lỗi, chi phí cho thời gian đó được tính vào Tổng chi phí triển khai.

g. Các nhân tố ảnh hưởng chính đến Tổng chi phí

Sự tồn tại lỗi của phần mềm làm tăng đáng kể Tổng chi phí vì thời gian và công sức để giải quyết lỗi. Nói chung, các ứng dụng đóng gói với số lượng lớn khách hàng sử dụng sẽ ít lỗi hơn các ứng dụng phát triển mới.

Độ phức tạp của phần mềm tăng, Tổng chi phí cũng tăng vì sự phức tạp của ứng dụng sẽ cần nhiều thời gian hỗ trợ của phòng tin học khi phần mềm hoạt động. Ở Mỹ, chi phí hỗ trợ thường chiếm khoảng 40% Tổng chi phí triển khai ERP.

Việc dễ dàng thay đổi phần mềm dựa trên cấu hình hệ thống sẽ giảm Tổng chi phí so với can thiệp vào mã nguồn. Vì can thiệp vào mã nguồn khó hơn và dẫn đến nhiều lỗi hay nhiều vấn đề không lường trước được.

Việc dễ dàng nâng cấp lên phiên bản mới hơn cũng làm giảm chi phí. Mặt khác, các phần mềm phát triển mới khó nâng cấp hơn hoặc phải thay thế bằng một phần mềm khác thay vì việc nâng cấp. Do vậy, Tổng chi phí sẽ cao hơn nếu cần nâng cấp phần mềm nhiều lần vì phải triển khai phần mềm mới.

Thêm vào đó, lựa chọn ứng dụng không phù hợp với quy trình nghiệp vụ của công ty cũng có thể dẫn đến việc tăng chi phí do phải thay thế phần mềm khác, hoặc chi phí liên quan đến việc thay đổi quy trình nghiệp vụ của công ty để phù hợp với phần mềm. Một số ứng dụng phù hợp với ngành này nhưng lại không phù hợp với ngành khác do vậy cần xem xét kỹ lưỡng trong quá trình đánh giá

h. Một số lưu ý

Điều đầu tiên DN cần lưu ý là phần sửa lỗi không bao gồm lỗi phát sinh do người nhập liệu gây ra. Ngoài ra, các Phần mềm ERP đều có chức năng “không duyệt” của những cấp có thẩm quyền với việc làm sai hoặc chức năng thực hiện bút toán đảo đối với các bút toán đã được phê duyệt nếu làm sai. Người dùng nên sử dụng các chức năng này thay cho việc thông báo lỗi và đưa ra yêu cầu sửa lỗi nói trên.

Việc xác định nguyên nhân lỗi sẽ do đơn vị bảo hành thực hiện. Nếu lỗi do Phần mềm hệ điều hành, cơ sở dữ liệu, virus…, thông thường, đơn vị bảo hành sẽ không chịu trách nhiệm. Tuy nhiên, DN nên ràng buộc đơn vị bảo hành bằng cách yêu cầu họ phối hợp với bên thứ ba để giải quyết các lỗi nói trên.

Có hai hình thức hỗ trợ: Tại chỗ và từ xa. Phần lớn đơn vị hỗ trợ đều cung cấp dịch vụ hỗ trợ từ xa qua website, điện thoại/fax… Trên thế giới, hình thức hỗ trợ từ xa khá phổ biến. Trong trường hợp không thể khắc phục lỗi được qua hình thức hỗ trợ từ xa, đơn vị hỗ trợ bắt buộc sẽ phải hỗ trợ tại chỗ. Khi đó, DN nên đàm phán mức giá cho các khoản phát sinh đi kèm như chi phí ăn, ở, đi lại.

0 Shares